Ing. Erich Wlasak, geschäftsführender Gesellschaft der Beratungsfirma „next level consulting“, verdeutlichte die zentrale Herausforderung des ÖBB-Projektes LDZ (Leistungsdaten Zugfahrt) anschaulich anhand eines ähnlich gelagerten Falles: „Nehmen Sie die Telekomm-Branche als Beispiel. Wenn sich da ein Unternehmen marketingmäßig überlegt, Abrechnung nach Sekundentakt anzubieten, ist das an sich eine clevere Idee und freut die Kunden. Nur -  um diese Abrechnung überhaupt durchführen zu können, müssen Sie im Hintergrund ein System haben, das in der Lage ist, die dafür erforderlichen Daten zu erfassen. Denn ohne Erfassung der relevanten Daten keine Abrechnung und ohne Abrechnung kein Angebot. Was also machen Sie, wenn Sie ein System haben, das vor 10, 20 Jahren entwickelt wurde, wo sekundengenaue Abrechnung noch nicht einmal angedacht war? Da bedeutet so eine schnell dahergesagte Marketingüberlegung mitunter einen enormen Programmieraufwand und tiefgreifende Veränderungen in den dahinter liegenden Prozessen.“

Auslöser Gesetzesänderung

Im Fall der ÖBB bedeutete das: Solange die im selben Unternehmen beheimateten Geschäftsbereiche Personenverkehr und Güterverkehr die einzigen Kunden des Geschäftsbereiches „Netz“ waren, war es sinnvoll und völlig ausreichend, das Benutzungsentgelt für die vom Bereich Netz zur Verfügung gestellten Bahntrassen mithilfe eines Verteilungsschlüssels auf die beiden internen Kunden aufzuteilen. Mit der europaweiten Liberalisierung der Schienenwege erhielten nun aber auch andere Eisenbahngesellschaften die Möglichkeit, das heimische Schienennetz mit eigenen Zügen zu nutzen. Und da ist eine ungefähre Abrechnung alles andere als ausreichend, weshalb das Billing-System der ÖBB nun ganz anderen Anforderungen genügen muss als früher. Gefragt war daher eine „völlig neue Kernprozess-IT“, wie es Peter Minar-Hödel, Leiter der Abteilung „Informationstechnologie, Projekt- und Prozessmanagement“ im Geschäftsbereich Netz das hohe Ziel formulierte.

Übliche Prozedere scheiden aus

Die zweite Herausforderung an das System neben Genauigkeit hieß Flexibilität. Zwar war schon Ende der 90-er Jahre klar, dass eine Neuentwicklung des Systems notwendig werden würde, um die  ab 2002 gesetzlich geforderten Abrechnungsmodalitäten erfüllen zu können. Aber die spezifischen Anforderungen und Geschäftsfälle, die das System konkret abdecken können muss, waren höchstens in vagen Ansätzen erkennbar.

Dementsprechend hoch war die Gefahr, mit viel Aufwand an den tatsächlichen Erfordernissen vorbeizuentwickeln. Schließlich ist die Erkenntnis alles andere als neu, dass viele EDV-Entwicklungen daran kranken, dass die klassische Vorgangsweise - Definition der Anforderungen, Entwicklung eines Pflichtenhefts, Programmierung, Testlauf, Implementierung – das Risiko birgt, dass sich das Geschäft zum Zeitpunkt der Fertigstellung der Software bereits wieder weiterentwickelt hat und damit zumindest ein Teil der Entwicklung zwischenzeitlich obsolet geworden ist und kostenintensiv umprogrammiert werden muss. Und die Erfahrung, dass die Anwender neuen Programmen oft sehr skeptisch gegenüberstehen, weshalb mit Millionenaufwand programmierte, aus IT-Sicht zu Recht hervorragende Programme manchmal schicht und einfach nicht verwendet werden, hatte auch die ÖBB in der Vergangenheit schon einmal gemacht.

In Anbetracht der enormen Investition von rund 70 Millionen Schilling entschieden sich Minar-Hödel und sein Geschäftsbereichsleiter DI. Peter Klugar nach Absprache mit dem Vorstand für einen bislang in Europa in dieser Dimension noch nie gewählten Ansatz, das sogenannte „conversion engineering“, eine „objektorientierte Softwareentwicklung“, die große Flexibilität und ein Mitwachsen mit dem Geschäft ermöglicht, indem sie auf Perfektion verzichtet, dafür schnell und unter frühzeitiger Einbeziehung der späteren Anwender Prototypen produziert und diese dann in mehreren, schon zu Beginn festgelegten Schleifen, weiterentwickelt und anpasst.

Ein Programm, kein IT-Projekt

Gerade weil es in diesem Fall um weit mehr ging als ein reines EDV-Projekt, setzte sich in der ÖBB die Sprachregelung „Programm“ durch. Als Auftraggeber, dessen Rolle es war, die Unternehmensstrategie und –sicht im Programm sicherzustellen sowie dafür zu sorgen, dass Programmleiter und zugeordnete Projektleiter so arbeiten können wie es nötig ist, fungierte der zuständige Bereichsleiter, DI. Klugar. Peter Minar Hödel, der zum Programmleiter bestellt wurde, war auch Mitglied des sogenannten Steuerungsteams, in dem einflussreiche Linienmanager mitarbeiteten und dafür sorgten, dass das in vier Projekten vorangetriebene Vorhaben tatsächlich im Arbeitsalltag verankert wurde. Schließlich handelte es sich beim Bereich Netz um einen Bereich mit über 12.000 Mitarbeitern, von denen ein Großteil besagtes EDV-System tagtäglich für ihre Arbeit nutzten.

Ein neues Business-Verständnis

Dass der Weg von der IT schnurstracks über die damit verfolgte Geschäftsstrategie zur Geschäftsbereichsentwicklung führte, wurde bereits nach wenigen, zu Beginn des Programms gestellten Fragen klar: Auf die Frage „wo müssen wir welche Daten wie ins System einspeisen, damit wir unsere Leistungen auch kundengerecht abrechnen können?“ folgten sofort die Fragen „von welchen Leistungen reden wir überhaupt; wem wollen bzw. können wir überhaupt welche Dienstleistungen anbieten; wie müssen daher jeweils unsere Leistungsprozesse ausschauen; und schließlich wie schnell müssen wir neue Dienstleistungen bei Bedarf überhaupt anbieten, d.h. abrechnen können, damit das noch ein attraktives Angebot ist? Noch allgemeiner gefragt: Wie müssen wir uns als Bereich aufstellen, um für künftige Herausforderungen bestens positioniert zu sein?

Klar war, dass die Beantwortung dieser Fragen massive Änderungen bei den bisherigen Aufgaben- und Verantwortungsbereichen mit sich bringen und massiv in existierende Machtgefüge eingreifen und man sich garantiert nicht nur Freunde damit machen würde.

Hätte es in dieser kritischen Phase nicht klare und eindeutige Signale von ganz oben gegeben, dass die bessere Lösung den Sieg davon trägt, wäre das Programm/Projekt bereits hier gestorben, auch wenn es von besonders engagierten Leuten noch einige Zeit künstlich beatmet und am Leben gehalten worden wäre.

Das LDZ-Programm der ÖBB hat diese kritischen Phasen bisher hervorragend gemeistert – auch wenn es selbst hier immer wieder das eine oder andere „Tal der Tränen“ zu durchqueren galt. Erfüllt das Programm die damit verbundenen Erwartungen, dann schafft die ÖBB damit ein System, um das sie die europäische Logistikbranche noch gehörig beneiden dürfte.

Lessons learned:

Einige Gefahrenquellen und wie man ihnen in der ÖBB ausgewichen ist:

 

• Aufgrund des Zeitdrucks gibt es die Neigung, heiklen, konflikthaften Punkten auszuweichen und damit suboptimale Prozesse edv-mäßig abzubilden („Lassen wir es so, uns fehlt die Zeit, uns darum auch noch zu kümmern“). Die Antwort hier bestand in der Projektbegleitung durch einen externen Berater, der immer wieder den Finger in die Wunden legte, um halbherzige Lösungen aufzuzeigen: „Stop, da brauchen Sie noch eine saubere Lösung!“)
• Wenn die Projektleiter aus dem IT-Bereich kommen, neigen die Linienmanager dazu sich zurückzulehnen, „die mal machen zu lassen“ und den Mühen der Implementierung dadurch auszuweichen, dass dem Programm dann jede Praxistauglichkeit abgesprochen wird. Die Antwort hier: die Projektleiter waren Manager aus der Linie, keine Spezialisten aus der IT, um die Akzeptanz vor Ort zu gewährleisten.
• Wenn bei notwendigen Neufestlegungen von Aufgaben- und Verantwortungsbereiche kein klares und unmissverständliches Backup von oben passiert, sondern das Powerplay von Revierverteidigern die Oberhand behält, bedeutet das das Ende des Projekts. Die Antwort hier bestand in den klaren Botschaften des Bereichsleiters, indem er Vorschläge, die keine Lösungen, sondern eine Verlängerung des Problems bedeuten würden, kategorisch zur weiteren Bearbeitung zurückverwies.

...zurück zum Seitenanfang