Welches Ziel verfolgte der BR mit dem Bau des neuen digitalen Sendezentrums in München-Freimann (SZFM)?
Herbert Gerstmayr: Wir wollten eine ganzheitliche Technik und durchgängige, effektive Workflows ohne Medienbrüche. Das haben wir auch realisiert, wenn auch mit einigen Höhen und Tiefen sowie einer langen Projektlaufzeit, effektiv von September 2002 bis März 2007. Heute haben wir ein System aus einem Guss.
Wie funktionierte dabei der Abstimmungsprozess innerhalb des BR?
HG: An der Entwicklung des Systems konnten von Beginn an alle betroffenen Betriebsbereiche teilhaben: die Sendeabwicklung, die aktuelle Produktion, der MAZ-Bereich in Hinsicht auf die Nachrichtensendungen, das Archiv, die Studioabwicklung – wir haben hier ja inzwischen vier Live-Studios – und die Bearbeitung mit über 40 Avid-Schnittplätzen, an denen nicht nur für das Bayerische Fernsehen, sondern auch für BR-Alpha, „Das Erste“, arte, 3sat, KiKa und weitere öffentlich-rechtliche Programme produziert wird. Es war schnell klar, dass es keinen Sinn macht, nur einen neuen Sendekomplex zu bauen und alles darum herum in der alten Technik zu belassen. Das heißt, im eigentlichen Sinne haben wir hier nicht nur ein Sende-, sondern ein neues Produktionszentrum gebaut.
Natürlich gab es gelegentlich auch unterschiedliche Sichtweisen, insbesondere zwischen Archiv- und Produktionsbereich. Die Anforderungen sind nun mal nicht identisch. Das Gesamtsystem wurde dadurch zwangsläufig komplexer – nicht zuletzt auch auf Grund der Metadaten-Problematik. Von Anfang an haben wir eng mit dem IRT zusammen gearbeitet. Das hat uns bei den Grundüberlegungen sehr geholfen.
Die funktionalen Anforderungen wurden im Wesentlichen vor dem Hintergrund der BR-internen Arbeitsabläufe definiert. Alle Bereiche wurden dabei einbezogen. Da wird dann auch nicht von einer externen Consulting-Firma einfach ein Konzept vorgegeben, sondern es wurde ein abgestimmtes Konzept entwickelt, das 100 %ig zu uns passt.
Dann bedarf es aber Partner, die es auch umzusetzen verstehen.
HG: Das ist grundsätzlich bei jedem IT-Projekt so.Für einen Gerneralunternehmer ist es naturgemäß schwierig, die Problematik spezifischer Anforderungen rechtzeitig zu erkennen. Der darf sich da auch nicht einfach auf die Zusicherung von Zulieferfirmen verlassen. Die Einschätzung von Umsetzungsrisiken beim GU muß gut funktionieren.
Was waren die Gründe für die Verzögerungen?
HG: Ein Grund war, dass wir das Projekt nicht modular, Stück für Stück, sondern auf einmal realisieren mussten. Ein weiterer zeitbestimmender Faktor war der zukunftsweisende Ansatz auf Basis von MPEG IMX und dem MXF-Fileformat (Material EXchange Format) 2002, im Jahr der Auftragsvergabe befand sich die Interoperabilität auf Basis von MXF praktisch noch in der Entwicklung. Erst zwischen 2003 und 2004 kamen dann herstellerübergreifend die ersten Geräte die sich im MXF-Format austauschen konnten.
Also waren sie mit ihrer Planung zu früh dran?
WE: Der BR hat frühzeitig die aktuellen Entwicklungen mit einbezogen. Immerhin besitzt er, im Vergleich zu vielen anderen Sendern, jetzt einen durchgängigen High-Res- Produktions- und Sende- Workflow incl. eines, in die Arbeitsabläufe vollständig integrierten, filebasierten Archivs.
Gerade im Archivbereich lassen sich dadurch auch Kosten einsparen – ich denke da vor allem an die Lanzeitsicherung von Archivmaterial – die ja jetzt weitestgehend automatisiert erfolgen kann.
Waren die Erwartungen und Anforderungen des BR bei Projektbeginn zu hoch?
HG: Die Anforderungen waren hoch, geprägt durch das Gesamtkonzept, für alle vier Bereiche, Sendung, Bearbeitung, Archiv und Studioanbindung eine homogene Technik zu schaffen. Ein bestimmender Faktor war die Anzahl der Arbeitstationen mit direktem Zugriff auf das Produktionsmaterial mit den daraus resultierenden Bandbreitenanforderungen. Ein anderer bestimmender Faktor war der hohe Live-Anteil, also die Echtzeitanforderungen. Wir bilden hier ja schließlich gleichzeitig ein Produktionssystem für den Live-Einsatz mit ab. Das heißt, wir müssen sehr schnell mit dem System arbeiten können.
Unser Content Management System (CMS) war jedoch ursprünglich nicht dafür vorgesehen, dass viel nachjustiert wird. Da mußte man sehr viel weitere Entwicklungsarbeit investieren, um die Performance zu optimieren.
Die mangelnde Interoperabilität, bedingt durch fehlende Standardisierungen, hat uns dabei das Leben nicht leichter gemacht.
WE: Es gab zum Beispiel damals praktisch keine Möglichkeit, Files vernünftig in die Avid-Systeme zu importieren. Die entsprechende Marquis-Software Medway, die wir heute einsetzen, ist erst hier im Rahmen dieses Projekts entstanden. Im Ergebnis ist das eine tolle Sache. Schnittlisten aus dem CMS (mit mehreren Files) lassen sich gebündelt aus dem Archiv bestellen und in einem Rutsch und in einen bestimmten Workspace auf das Avid-Unity System schieben. Durch den Import mit der Marquis Software landen die Files nicht nur auf dem richtigen Filesystem, sondern man bekommt diese auch gleich in Form einer Sequenz auf der AVID-Timeline angezeigt. Weiterhin wird ein ganzer „Sack“ Metadaten aus dem Archiv beim Import mit in den AVID übernommen.
Wie war denn der Support durch Avid gewesen?
HG: Bei der Realisierung haben wir feststellen müssen, dass sich projektspezifische Softwareänderungen nur schwer mit der laufenden Softwareentwicklung eines globalen Players wie AVID in Einklang bringen lassen.
WE: Da muß man sich eben auf Firmen aus dem mittelständischen Bereich stützen, wie das bei Marquis, aber auch im Bereich des Content Managament Systems (CMS) der Fall war. Das von uns genutzte CMS („Media Archive“ von Blue Order) wurde hier in weiten Teilen völlig neu entwickelt und mit vielen Softwareänderungen versehen. Wenn die Firmen da nicht so flexibel gewesen wären, wären wir heute nicht so weit.
Und wie war das bei der Harris-Automation?
HG: Auch die HARRIS-Automation musste in vielerlei Hinsicht angepasst werden. Hierzu ist eine direkte Kommunikation zwischen dem Kunden und dem Softwareentwickler eminent wichtig.
Dies betrifft auch die Lieferanten-interne Kommunikation, wenn einzelne Teile an verschiedenen Standorten entwickelt werden. Für das BR-Projekt wurde HARRIS-Software in den USA, in Frankreich und in Ungarn entwickelt.
Hinzu kommt der Umstand, daß der Entwickler im Labor i.d.R. nicht die erforderliche Peripherie zur Verfügung hat, um ein komplexes Softwaresystem ausreichend zu testen. Ein guter Teil des HARRIS-Bugfixings musste bei unserem Projekt vor Ort durch die entsprechenden SW-Entwickler durchgeführt werden.
Und jetzt funktioniert alles?
HG: Bei uns ist die HARRIS-Automation das entscheidende System für durchgängige Workflows. Diese können wir herstellen. Nachdem die funktionalen Anforderungen mit zunehmender Betriebserfahrung einem ständigen Veränderungs- und Optimierungsprozeß unterworfen sind, muß auch die Software nachgezogen werden. Dazu werden noch weitere Patches und Updates erforderlich sein.
Darüber hinaus gibt es gegenwärtig natürlich noch Softwarefehler, welche nur bei bestimmten Konstellationen auftreten und deren Lokalisierung Zeit kostet und Ressourcen bindet.
Wie lassen sich Probleme zwischen Sendern und Lieferanten vermeiden?
HG: In einer Ausschreibung können funktionale Anforderungen nur in begrenzter Tiefe beschrieben werden, insbesondere wenn das Gesamtsystem und das Zusammenspiel der Komponenten erst in der Realisierungsphase in allen Details festgelegt wird. Es besteht zwangsläufig ein Definitionsdefizit, welches erst in der Feinplanungs- und Pflichtenheftphase endgültig aufgelöst werden kann.
Dem Lieferanten muß klar sein, daß der Kunde immer vom „bestimmungsgemäßen Gebrauch“ ausgehen wird. In der Ausschreibung muß also stehen, was mit dem System gemacht wird, vom Lieferanten wird erwartet, daß er ausreichende Kenntnisse über die branchenüblichen Betriebsabläufe hat, um zu erkennen, ob mit dem System so gearbeitet werden kann.
Kritische Faktoren sind hier die Softwareanforderungen, welche sich aus dem Live-Einsatz und dem Arbeiten unter Stressbedingungen ergeben. Auch dies sind Eigenschaften, welche sich, zumindest aus der Sicht des Kunden, aus dem „bestimmungsgemäßen Gebrauch“ ergeben. Der einzelne Softwareentwickler wird das in der Regel nicht wissen. Es liegt nun in der Verantwortung des Lieferanten oder GU´s dies frühzeitig zu erkennen, gegenzusteuern und damit Verzögerungen bei der Realisierung zu vermeiden.
In der IT-Branche geht man oft davon aus, dass Software alles regeln kann. Beim Broadcast-Einsatz zeigt sich dann häufig, dass bestimmte funktionale Anforderungen auch schnell eine gesteigerte System-Performance oder spezielle Hardware-Architektur erfordern.
Wenn sie Lieferanten wie Blue Order haben, die ihr Kerngeschäft auch in der SW-Integration sehen,, dann funktioniert das in der Regel einfacher. Wenn man aber mit Lieferanten arbeitet, die in erster Linie eine Produktlinie haben und Standardsoftware anbieten, tut man sich schwer. Das dauert dann, bis kundenspezifische Wünsche in die Software-Entwicklungspläne aufgenommen werden.
Wie kam die Zusammenarbeit mit Blue Order zustande?
Die Zusammenarbeit hat sich erst mit dem Projekt im Rahmen der CMS-Archiv-Anforderungen ergeben. Blue Order kommt ja eigentlich mehr aus dem Archivierungsbereich. Media Archive war damals das einzige System, bei dem die Chance bestand, daß es einmal annähernd unseren Anforderungen genügen würde. Die waren einfach flexibel und ich hatte den Eindruck, die haben verstanden, was wir wollten.
Sie sind also mit der Blue Order-Kooperation zufrieden?
Ja, auch wenn manche Dinge dann doch länger gedauert haben als erwartet. – aber das lag sicher auch an dem hohen Entwicklungsaufwand.. Die Spezifikationen für die Schnittstelle CMS – Automation musste beispielsweise mehrfach modifiziert werden. Kompetenz, Motivation und Eigeninitiative von BO haben uns dabei sehr beeindruckt.. Lobend sei hier der Einsatz der Fa. FlyingEye erwähnt, die im Auftrag von BlueOrder den CMS-Part projekttechnisch auf der Lieferantenseite abgewickelt hat.
Und wie lief es mit T-Systems?
TSI hat ein hervorragendes Projektmanagement geleistet. Es hat sich auch sehr positiv ausgewirkt, dass TSI als Teil eines großen Konzerns kurzfristige weitere Spezialisten in das Projektteam einbringen konnte. Man musste allerdings erkennen, dass relativ viel Broadcast-spezifisches Know-how notwendig ist und dies im Gegensatz zur allgemeinen IT-Technik oft nur bei kleineren Spezialfirmen verfügbar ist.
WE: Letztlich kam dann sehr viel Initiative von uns, ich meine vom BR. Nicht nur die. Planung mußte in die Bresche springen sondern auch die Betriebskollegen wurden teilweise in erheblichem Maße mit eingebunden. Wir alle haben sehr viel investiert und konnten aber auch eine Menge dazulernen.
Was würden sie heute anders machen?
HG: Wir würden uns mit unserer Mannschaft von Beginn an breiter aufstellen und mit einem größeren Engineering-Team in das Projekt reingehen und bei Projektbeginn die künftigen Workflows in ausreichender Tiefe definieren.
Wann war die Pflichtenheft-Phase beendet?
HG: Die meisten Pflichtenhefte wurden im Jahr 2005 freigegeben, also ca. 18 Monate nach der Auftragsvergabe. Bei einzelnen Gewerken, wie z. B. bei der AVID-Integration gab es keinen klaren Meilenstein für den Abschluß des Pflichtenhefts. Hier konnten einzelne Punkte erst im Zuge der weiteren AVID-Produktentwicklung geregelt werden. Trotzdem musste mit der Software-Entwicklung begonnen werden, um nicht unnötig Zeit zu verlieren. Aus praktischen Gründen, insbesondere um den Abstimmungsaufwand zu begrenzen, hat der BR die Schnittstellensoftware (von der Fa. MARQUIS) direkt beauftragt. Die Notwendigkeit dazu hat sich erst im Gestehungsprozeß des Pflichtenhefts gezeigt.
Gab es auch Alternativen zur Harris-Automation?
WE: Omnibus war bei uns lange in der Prüfung. Allerdings zeigte sich innerhalb der Phase der Detailklärungen, dass OMNIBUS eine Produktumstellung beabsichtigte, deren Entwicklung von uns nicht eingeschätzt werden konnte. Die Entscheidung für HARRIS war von der größeren Kontinuität und Marktpräsenz geprägt.
Wir haben bei der Harris-Integration auch sehr von der Zusammenarbeit mit der Mainzer BIC4 GmbH profitiert. Die Firma wußte sehr gut über die Harris-Produkte Bescheid, hat gerade was die Sendungsabläufe betrifft noch mal sehr viel Know how mitgebracht und am Ende viel dazu beigetragen, dass das Projekt hier erfolgreich realisiert werden konnte.. Ein Kollege von BIC4 war seit Ende 2002 bis vor Kurzem im Projekt-Team. Das know-how vom BIC4 wird gegenwärtig noch zur Betriebsunterstützung genutzt.
BIC4 macht jetzt auch den Support für unser DIVA-Management-System im Archivspeicher-System. Hier setzen wir auf das Front Porch-Produkt DIVArchiv.
Ursprünglich sollte SGI das zentrale Speichersystem liefern. Wie kam es zum Wechsel zu Omneon?
HG: Entsprechend dem GU-Auftrag war zur Feststellung der Eignung des SGI-Systems ein Kernkomponententest vorgesehen. Der erforderliche Funktionsnachweis konnte allerdings trotz einer sehr langen Nachbesserungsfrist nicht erbracht werden. Der BR hat sich deshalb im Mai 2004 auf ONMEON festgelegt.
Mit Abstrichen?
HG: Statt eines haben wir jetzt drei Systeme bekommen, die alle gekoppelt sind und zwischen 20 und 30 Ports haben. In der Summe bieten sie 84 Ein- und Ausgänge, also genauso viele wie ursprünglich geplant. Aber auf Grund der Aufteilung auf drei Systeme haben wir einen gewissen Mehraufwand an Materialmanagement und an Kopierprozessen. Das belastet auch wieder die Bandbreite und damit die Performance des Systems. Dies musste an anderer Stelle, z. B. auf der Automationsseite wieder kompensiert werden.
Die Omneon-Server wurden zwar mit DV und QuickTime ziemlich schnell zum Laufen gebracht. Aber erst unter IMX MXF haben wir dann festgestellt, dass wir nicht mehr die Bandbreite bekommen, die wir uns vorgestellt haben: Das heißt die Anzahl der gleichzeitigen Play-Kanäle, die wir in den Tests gesehen haben, war nicht mehr vorhanden. Da mußte Omneon dann auf Softwareseite nachbessern. Das hat auch eine Weile gedauert, aber letztendlich zum Erfolg geführt.
Wie ist die Zusammenarbeit mit Omneon- und Marquis-Vertriebspartner Netorium?
HG: Netorium ist ein sehr wichtiger Partner, der auch viel Know-how in das Projekt eingebracht hat.
Wann gingen die finalen Tests im SZFM über die Bühne?
HG: Die Tests gingen von Mitte 2005 bis Ende 2006. Das war mehr oder weniger die Softwareimplementierungs- und Nachbesserungsphase. Bestimmendes Element war da die Harris-Integration einschließlich der Beseitigung der dort vorhandenen Mängel..
Die Anforderung einer durchgängigen Timecode-Verarbeitung, dass man Echtzeitcode aufzeichnet und über alle Bearbeitungsschritte hinweg bis zur Ausspielung durchgängig erhält hat allen Zulieferern Probleme gemacht.
Und wie lief der Umstieg vom alten auf das neue Sendezentrum?
HG: Am 7. Januar 2005 sind wir mit BR Alpha auf Sendung gegangen.Damit haben wir dann wertvolle Betriebserfahrung mit der HARRIS-Automation gesammelt. Wir haben damals eine Senderegie so umkonfiguriert, dass sie netzwerk- und steuerungstechnisch wie eine Insel im Gesamtsystem eingesetzt werden konnte. Die Installation mit filebasiertem Playout via Omneon-Server war im Vergleich zum Gesamtkonzept jedoch insgesamt einfacher angelegt. Wir haben da aber noch mit alter, bewährter Harris-Software gearbeitet.
Insgesamt haben wir hierbei fest gestellt, dass die letzten zehn Prozent der Anforderungen einen gehörigen Anteil an der Komplexität ausmachen.
Worin liegt denn dann die besondere Schwierigkeit?
WE: Das Playout über Sendeserver im Alpha Sendekomplex funktionierte auf Anhieb. Da hätte man auch noch ein digitales Archiv mit anbinden können. Material aus dem Archiv über die Automation auf Server zu schieben, ist kein Problem. Aber Files Richtung Produktion mit den ganzen Bestellvorgängen durchgehend konsistent zu realisieren, ist eine andere Herausforderung gewesen und ist es eigentlich immer noch.
Und wie ging es dann weiter mit der Inbetriebnahme?
HG: Ab Mitte 2005 haben wir Schulungen durchgeführt. Die hat die SRT (Schule für Rundfunktechnik – heute ARD.ZDF medienakademie) für uns koordiniert. Wir mußten dann aufgrund von Softwareänderungen noch viel nachschulen. Selbst 2006 gab es noch Schulungen. Daneben lief schon ein Probebetrieb des Gesamtsystems, der allerdings noch stark durch Software-Bugs und Fehlerbeseitigung tangiert war. Das dauerte von Ende 2005 bis Ende 2006. Im Laufe des Probebetriebs haben wir im Wesentlichen gelernt, wie man Störungen vermeidet und Havariemanagement betreibt.
Am 17. Januar 2007 hat die Inbetriebnahmephase begonnen und am 28. März war dann Abschluß der Inbetriebnahmephase. Bis dahin gab es also einen sanften Übergang. Ab dem Herbst 2006 wurden Zug um Zug alle Redaktionen mit einbezogen. Auch die mußten noch auf die neuen Abläufe geschult werden. Wir haben insgesamt 600 Redaktionsmitarbeiter und 50 Sendezentrum-Mitarbeiter von Blue Order am CMS schulen lassen. Das war natürlich mit hohem Aufwand verbunden.
Wie war denn die erste Resonanz der Mitarbeiter nach der Umstellung?
WE: Die normale, anfängliche Skepsis vor der neuen Technik sowie den neuen Abläufen ist verschwunden. Mit der Jahreswende haben immer mehr die Vorteile des Systems erkannt. Bei den aktuellen Redaktionen wie Rundschau und Abendschau ging das am schnellsten. Die Redakteure dort sind gewohnt manchmal auf Risiko zu arbeiten und haben schon im alten System auch immer hart am Limit gearbeitet. Natürlich kommen jetzt die Änderungswünsche und die Usability muß noch an vielen Stellen verbessert werden.
HG: Bei SZFM haben wir einen evolutionären Ansatz gewählt, bei dem bewährte Arbeitsweisen weitgehend erhalten werden mit der Folge, dass sich die Mitarbeiter in der Arbeitsumgebung auch wiederfinden können. Dies hat sehr stark dazu beigetragen, dass das System schnell angenommen wurde.
Und was bedeutet das neue Sendezentrum nun für die Konvergenzentwicklung beim BR?
WE: Das Zusammenführen von TV, Hörfunk und Internet haben wir nicht aus dem Auge verloren. Das machen wir jetzt in den nächsten Stufen. Zu meinen nächsten Aufgaben gehört z. B. die Integration der Rechtedatenbank in das Content Management-System.
Außerdem werden wir zusammen mit der Redaktion Multimedia die Entwicklung der Hörfunk- und TV-Konvergenz weiter treiben. Dafür müssen wir natürlich auch neue Technik einführen bzw. die alte erweitern. Grundsätzlich haben wir mit dem Sendezentrum aber auch gute Voraussetzungen dafür geschaffen. Allein die Tatsache, dass wir Inhalte von Hörfunk und TV besser im zentralen Archiv recherchieren und filebasiert austauschen können, ist schon ein großer Schritt nach vorne. Mehrfachverwertung von Content spielt auch für den BR eine ganz große Rolle. Wir wollen künftig auch das vorhandene Rohmaterial besser verwerten. Das Verhältnis des gedrehten zum gesendeten Material liegt zum Teil bei 15:1. Nicht gesendete TV-Aufzeichnungen und O-Töne können unter Umständen auch für die Hörfunkredaktionen ganz wertvoll sein.
Eckhard Eckstein (MB 05/07)
