Herr Kranstedt, unter welchen Handicaps hat das Programm der Dienstekonsolidierung bisher ganz besonders gelitten? Könnten diese Handicaps abgestellt werden?
Man sollte weniger von „Handicaps“ und eher von Erkenntnissen reden, da die Dienstekonsolidierung durchaus als eine Erfolgsgeschichte angesehen werden kann. Angesichts der Ausgangslage wurde mit begrenzten Ressourcen eine Menge geschafft, selbst wenn es in der ersten Phase Probleme gab. Aus der bisherigen Erfahrung gab es vor allem die folgenden Erkenntnisse:
- Statt eines reinen Wasserfallmodells wurde der agile Ansatz eines „Learning by doing“ verwendet. Dieser Ansatz, bei dem mit der Dienstekonsolidierung bereits vor der Finalisierung aller organisatorischen Rahmenbedingungen (inkl. einer neuen Behörde) operativ begonnen wurde, hat sich als richtig erwiesen.
- Durch vorher finalisierte Rahmenbedingungen hätten zwar einige der bisher aufgetretenen Fehler verhindert werden können, doch die parallele Entwicklung der Rahmenbedingungen zur Projektdurchführung ermöglichte eine schnellere Entwicklung der Dienste. Dafür war neben einer guten Fehlerkultur auch die Akzeptanz wichtig, dass sich die Dienstekonsolidierung noch in einem Lernprozess befindet, d.h. Fehler wurden gemacht und aus ihnen gelernt.
- Jetzt ist es an der Zeit, den bisherigen agilen Modus zu verlassen und die Dienstekonsolidierung in einer Nachfragemanagementorganisation zu institutionalisieren, um sie langfristig zu stärken. Dafür gilt es, eine schlanke Organisation mit rechtlich abgesicherten Zuständigkeiten und Pflichten zu schaffen, die gewonnene Erkenntnisse der letzten Jahre nutzt. Die große Anzahl der IT-Verfahren, die die Verwaltung benötigt, wird dabei auch in Zukunft eine große Herausforderung darstellen und schwer beherrschbar bleiben. Langfristig muss daher die NMO in der Lage sein, eine dreistellige Anzahl an Diensten parallel zu konsolidieren und weiterzuentwickeln. Ein serieller Ansatz, in dem Dienste zunächst entwickelt und anschließend geliefert werden, funktioniert dafür nicht. Stattdessen müssten Dienste parallel weiterentwickelt und gepflegt werden. Dazu bedarf es eines kontinuierlichen Verbesserungsprozesses (z.B. über Lean-Management), der Anforderungen verschiedener Bedarfsträger in künftigen Releases konsolidiert und umsetzt.
Weitere Erkenntnisse für das zukünftige Vermeiden von Handicaps sind folgende:
- Rollouts stellen bei komplexen Basisdiensten enorme Anforderungen an die Zusammenarbeit zwischen den Beteiligten. Dafür müssen sowohl organisatorische als auch technische Rahmen- bedingungen geschaffen werden. Zunächst wurde die Wichtigkeit dieser Rahmenbedingungen unterschätzt.
- Ein ressortübergreifendes, hierarchisch aufgebautes und funktionierendes IT-Sicherheitsmanagement wäre für die Formulierung effektiver Sicherheitsanforderungen an Anwendungen und Dienste als auch für den laufenden Betrieb nötig. Weiterhin sollte eine Zertifizierung ohne jahrelange Diskussionen mit diversen Stakeholdern ermöglicht werden, um schnell zu kontrolliert-sicheren Diensten zu kommen.
- Bis heute wurde nicht abschließend gelöst, wie mit Themen wie Datenschutz oder den Mitbestimmungsrechten von Interessenvertretungen umgegangen werden soll.
- Es gibt eine berechtigte Erwartungshaltung an die Leistungsfähigkeit der von der Dienstekonsolidierung berührten IT. Daher sollten durchaus so viele Ressourcen investiert werden, wie sie sinnvoll organisatorisch integriert werden können. Nichtsdestotrotz ist eine Priorisierung innerhalb der Dienstekonsolidierung notwendig. Für diese existiert mittlerweile ein Priorisierungsprozess der Maßnahmen nach Dringlichkeit.
An welchen Vorbildern sollte sich die Nachfragemanagementorganisation orientieren? Was kann die Bundesverwaltung in diesem Kontext von der Wirtschaft oder von anderen Staaten lernen?
Andere Staaten sind zur Orientierung nur bedingt geeignet, da Staaten im Vergleich zu Deutschland oft mit anderen Ausgangslagen und Voraussetzungen als Vorbilder herangezogen werden. Beispielsweise hatte Estland den Vorteil, nach dem Systemwandel vor einigen Jahrzehnten komplett neu auf einer grünen Wiese anfangen zu können. In Deutschland müssen hingegen lang bestehende Voraussetzungen, wie der Föderalismus berücksichtigt werden. Nichtsdestotrotz sollten wir zielgerichtet aus Erfahrungen anderer Länder lernen, wo sie relevant sind.
Die Nachfragemanagementorganisation basiert in ihrer Grundidee auf dem Ansatz, dass jede Verwaltungsebene und Verwaltungseinheit in der Zukunft eigenständig über ihre Ideen entscheiden und sie beauftragen können sollte. Dabei dient die NMO als Institution, die verantwortlich für Ausdefinition dieser Anforderungen an eine IT-Lösung ist und nachfolgend IT-Dienstleister für die Umsetzung beauftragt.
Die NMO muss daher adäquat ausgestattet werden, um mit der Durchsetzungskraft und den rechtlichen Handhaben eines klassischen Auftraggebers tätig werden zu können, d.h. sie sollte Verträge abschließen und klassische Aufträge vergeben können, sowie ein Budget haben, mit dem sie agieren kann. Genau für diesen Aspekt kann die NMO von der Wirtschaft lernen, da dort mehr über klare Kompetenzzuweisungen und Geld als über proportional konsensuale Verhandlungsprozesse gesteuert wird. Eine derartige Vorgehensweise würde besser ermöglichen, das für die Digitalisierung nötige Tempo an den Tag zu legen.
Wie sollte die ressortübergreifende Abstimmung von Anforderungen an Basis-, Querschnitts- und Infrastrukturdienste koordiniert werden? Wie können dabei unnötige Verzögerungen vermieden werden?
Folgender Ansatz könnte die Heterogenität der Anforderungen reduzieren: für alle Prozesse, die von der Ziel-IT-Lösung abweichen, sollte hinterfragt werden, ob sie wirklich zwingend individuelle Prozessausprägungen benötigen. Das Ziel der durch die Dienstekonsolidierung eingeführten IT-Lösungen sollte nicht sein, alle vorhandenen Prozessvarianten abzudecken, sondern eben eine Konsolidierung der Fachlichkeit herbeizuführen. Diese fachliche Konsolidierung ist ausdrücklich ein Hauptziel der Dienstekonsolidierung. Nur mit einem solchen Ansatz könnten aus meiner Sicht wirtschaftliche IT-Lösungen mit großer Abdeckung über alle nutzenden Behörden erreicht werden.
IT-Lösungen sollten andererseits technisch auch so konzipiert werden, dass eine gewisse Variabilität sichergestellt werden kann. Das heißt, es gäbe einen Basiskatalog von Funktionalitäten für die IT-Lösungen und ausprägbare Erweiterungspakete. Hierdurch eröffnete sich die Möglichkeit, bestimmte Variantenbreiten auch zuzulassen.
Außerdem sollte der Prozess der Anforderungsabstimmung effektiver gestaltet werden. Dafür sind klare Entscheidungsbefugnisse der NMO nötig, um Kontroversen bei divergierenden Anforderungen schnell ausräumen zu können. Dies könnte über eine oberste Instanz geschehen (wie z.B. momentan der IT-Rat), die als höchste Eskalationsinstanz fungieren und wichtige Entscheidungen treffen kann.
Folgende zusätzliche Erkenntnisse für Anforderungsabstimmung könnten zudem aus der Maßnahme E-Akte abgeleitet werden:
- Die Maßnahme kam in einer akzeptablen Zeit zu einem akzeptablen Ergebnis, hatte aber mit einigen Widrigkeiten zu kämpfen. Dies hat in der Vergangenheit zu einigen Herausforderungen geführt welche sich weniger auf den Prozess der Verwaltung einer Akte selbst, sondern eher auf die Integrationsfähigkeit der anvisierten Lösung in die jeweilige behördliche IT-Landschaft beziehen.
- Der Grund dafür war, dass viele Behörden ihre Veraktung stark an ihr jeweiliges Hauptverfahren gekoppelt haben, wie z.B. das Bundesamt für Migration und Flüchtlinge, die MARIT benutzen. Diese Verknüpfung führte zu einer Vielzahl zusätzlicher funktionaler und nicht funktionaler Anforderungen an die IT-Lösung für die E-Akte.
- Zukünftig sollte in einem solchen Fall entschieden werden, ob die Behörde weiterhin ihr eigenes System als Standard nutzen kann oder ihre bisherigen Prozesse umstellen muss.
Wie sollten im Spannungsfeld von Individualisierung und Standardisierung für Basis-, Querschnitts- und Infrastrukturdienste Entscheidungen herbeigeführt werden? Wie kann dabei verhindert werden, dass das Konsensprinzip zu einer Pulverisierung von Verantwortung führt?
Man braucht nicht überall Konsens. Wenn ein gewisser gemeinsamer Nenner gefunden wird, können darauf Basisdienste aufgebaut werden und je nach Bedarf Erweiterungspakete angeboten werden. Alles weitere kann dann stark über Geld und Kosten gesteuert werden. Der Basisdienst ist sehr günstig. Wer etwas anderes haben will, muss Geld in die Hand nehmen. Dadurch relativiert sich häufig das Bedürfnis an individuellen Wünschen.
Ansatzpunkte für eine mögliche Individualisierung der Dienste wären:
- Es sollte zwischen unterschiedlichen Kategorien von Diensten unterschieden werden. Aus einem technischen Blickwinkel ist der Standardisierungsbedarf unterschiedlich für die jeweiligen Architekturebenen der IT.
- Es gibt einen hohen Standardisierungsdruck für die unteren Infrastruktur-Ebenen. Für diese Ebenen könnte daher eine geringere Abweichung von Standards wünschenswert sein, z.B. einer Standard-Server-Plattform, Standard-Netzdiensten und einem Basis-Arbeitsplatz, auf dem alles aufgebaut ist.
- Bei oberen Infrastruktur-Ebenen können individuellere Ausprägungen zugelassen werden, wenn diese den Betrieb des Gesamtpaketes nicht gefährden. In jedem Fall ist wichtig abzuwägen, für welche Dienste eine Standardisierung zwingend notwendig ist und bei welchen eine gewisse Variantenbreite zugelassen werden kann.
Die NMO sollte institutionell ausgegründet werden und über eine effektive Entscheidungsstruktur verfügen. Das bedeutet die Schaffung eines neuen Gremiums unter Einbindung einer Person, die im Zweifelsfall über alle strittigen Punkte entscheiden kann. Diese Person sollte der Bundes-CIO sein. Ein Gremium, indem alle gleichrangig sind führt dazu, dass lange über Konflikte diskutiert wird, bis ein Minimalkonsens hergestellt ist oder der Konflikt an die nächsthöhere Instanz weitergeleitet werden muss. Das wäre nicht zielführend. Allerdings ist auch eine ausreichende Beteiligung der wichtigsten Stakeholdergruppen erforderlich. Ihnen sollte im Gremium eine Stimme gegeben werden, ohne die Entscheidungsfähigkeit zu gefährden.
