Eine rollenbasierte Oberfläche für die Mitarbeiter der BA
Die Informationstechnik der Bundesagentur für Arbeit (BA) ist komplex. Etwa 120 eigenständig entwickelte IT-Verfahren sind im Einsatz, um die Arbeitsvermittlung zu unterstützen, Fördermaßnahmen abzuwickeln und etwa das Arbeitslosengeld auszuzahlen. Zwischen 2011 und 2016 hat die BA etwa 4,5 Milliarden Euro für IT-Entwicklungen aufgewendet. Insofern überrascht es nicht, dass sich unter IT-Erfolgen der BA (elektronische Aktenhaltung) auch Fehlschläge wie RobasO finden. In der 2015 gestarteten Pilotphase wurde jedoch deutlich, dass die Lösung nicht in der Lage war, die Komplexität von Kundenanliegen und der damit verbundenen Fachverfahren zu managen. Immer wieder gab es Probleme, die Mitarbeiter waren unzufrieden. Nach einer Investition von 60 Millionen Euro und mehr als fünf Jahren Entwicklungszeit beschloss die BA im Februar 2017 den Abbruch des Projektes. Was die Anwendung im einzelnen so unbrauchbar machte, führte die Behörde nicht weiter aus. In Berichten machten das Problem bei der Korrektur einer Kontonummer die Runde – der Anwender hätte den Satz mit sämtlichen Leistungs- und Vermittlungsdaten komplett neu eingeben müssen.
RobasO
Später Praxistest
SOA (Service-Oriented Architecture) ist ein Architekturmuster der Informationstechnik aus dem Bereich der verteilten Systeme, um Dienste von IT-Systemen zu strukturieren und zu nutzen. Unter dem Geschäftsführer Informationstechnologie Klaus Vitt (2006-2014) bildeten rollen-basierte Oberflächen, die bis 2015 nach den Prinzipien Serviceorientierter Architektur (SOA) 14 verschiedene Anwendungenfür Geschäftsprozesse verbinden, einen Schwerpunkt der IT-Strategie.
Das IT-Projekt RobasO kombinierte die Dienste der Behörde auf einer Plattform. Auf dieser sollten den Mitarbeitern 50 - 60 einheitliche, auf die Notwendigkeit ihrer jeweiligen Rolle reduzierte grafische Oberflächen, mit genau den Informationen und Inhalten, die für die jeweiligen Aufgaben und Rollen benötigt werden zur Verfügung gestellt werden. Ziel war es, das Hin- und Her-springen zwischen einer Vielzahl einzelner IT-Verfahren zu beenden und Mehrfacheingaben von Daten zu verhindern.
Die Oberflächen sollten über eine intelligente Benutzersteuerung verfügen und die Dokumentation aller Geschäftsvorfälle über eine medienbruchfreie Oberfläche in hoher Qualität erleichtern. Aufgrund von Gesetzesänderungen, Regularien werden und anderen Anforderungen müssen die Geschäftsprozesse in der größten Behörde Deutschlands auf 170.000 Arbeitsplatzsystemen häufig und schnell angepasst werden können. Gleichzeitig müssen die IT-Verfahren, die den Geschäftsprozessen zugrunde liegen, kontinuierlich stabil zur Verfügung stehen.
Voraussetzung für den Aufbau solcher Oberflächen und Funktionen war die Modularisierung der bisherigen IT-Verfahren in fachliche Services, die sich dann flexibel kombinieren lassen. In Bezug auf die Softwarearchitektur setzte die BA auf das proprietäre Oracle Application Development Framework (ADF), für das man sich (dem Vernehmen nach) Herstellersupport versprach. Abhängigkeiten der SOA IT-Landschaft führten zu Abstimmungsproblemen und verlangsamten die Entwicklung. Probleme wie die Korrektur eingegebener Daten per Implementation eines “Zurück-Button” konnten durch den Einsatz von 42 Millionen Euro für zeitweise bis zu 500 externe Entwickler nicht gelöst werden.
RobasO war ein Vorzeigeprojekt. Verantwortliche und Dienstleister publizierten auf Konferenzen und in Fachartikeln Buzzwords wie SOA, Enterprise Service Bus und Agile. Aus diesem Grund könnte es für die Methodik des Projektmanagements besonders lehrreich sein die Geschichte dieses Projektes zu untersuchen.
Lessons Learned?
Ein Strategiepapier der BA aus dem Mai 2016 stellt dar, dass die, werden dass die Softwareprojekte der BAAgile entwickelt werden. Das Projektende von RobasO und seine Begründung deuten jedoch darauf hin, dass dies nicht der Fall war. Schon weil die Pilotphase von RobasO im erst Oktober 2015 gestartet wurde, was mit agilem Projektmanagement nicht zu vereinbaren ist. Ein Projekt, bei dem erst nach Abschluss auffällt, dass es das Ziel verfehlt – das ist eigentlich ein typisches Problem der klassischer Top Down Projektplanung. Offenbar wurden die 2010 definierten Anforderungen an das Projekt bis zum Praxistest nichtmehr kontrolliert. Offensichtlich gab es Defizite in der Kommunikation von Auftraggeber und IT-Dienstleistern. Oder sind die Scrum Sprints, die Methoden des agilen Projektmanagements bei 500 Entwicklern an eine quantitative Grenze gestoßen? Leider verwehrt die BA eine detaillierte Auswertung des mit öffentlichen Mitteln finanzierten Projektes RobasO. Folglich kann hier über die ursächliche Beteiligung von methodischen Ansätzen am Misserfolg nur spekuliert werden.
Unabhängig von der Frage, ob RobasO klassisch Top Down, Agile oder Hybrid projektiert wurde bleibt offen, ob das verwendete Oracle Application Development Framework (ADF) für einen Einsatz in der Größenordnung der BA tatsächlich geeignet ist.
