Warum öffentliche IT-Organisationen trotz hoher Kompetenz an ihrer eigenen Struktur scheitern können
Die Digitalisierung der öffentlichen Verwaltung ist längst keine Frage einzelner IT-Projekte mehr. Cloud-Plattformen, Automatisierung, digitale Identitäten, moderne Entwicklungsumgebungen und hochverfügbare Infrastrukturen sind zu Voraussetzungen staatlicher Handlungsfähigkeit geworden. Gleichzeitig entsteht trotz erheblicher Investitionen, zahlreicher Programme und vieler qualifizierter Fachkräfte vielerorts der Eindruck, dass öffentliche IT-Organisationen mit der technologischen Entwicklung nur schwer Schritt halten. Projekte dauern lange, ähnliche Lösungen werden mehrfach aufgebaut, strategische Entscheidungen immer wieder neu diskutiert und externe Beratungsunternehmen gewinnen erheblichen Einfluss.
Die Verwaltung organisiert Zuständigkeiten – der Kunde erwartet Ergebnisse
Klassische öffentliche IT-Organisationen sind funktional aufgebaut. Strategie, Architektur, Informationssicherheit, Infrastruktur, Netzwerk, Betrieb, Projektmanagement, Beschaffung und Kundenmanagement liegen in unterschiedlichen Organisationseinheiten. Diese Spezialisierung ist zunächst sinnvoll, denn moderne IT benötigt all diese Kompetenzen. Problematisch wird sie dort, wo fachliche Spezialisierung gleichzeitig zur organisatorischen Grenze wird.
Besonders deutlich wird das bei Cloud-Plattformen. Eine Cloud besteht nicht einfach aus Servern. Sie benötigt Netzwerk, Identitätsmanagement, Security, Backup, Monitoring, Automatisierung, Support und Lifecycle-Management. Der Kunde möchte diese Bestandteile aber nicht einzeln bei verschiedenen Stellen bestellen. Er erwartet einen funktionierenden Service.
Hier treffen zwei Organisationslogiken aufeinander: Die Verwaltung organisiert Zuständigkeiten. Der Kunde erwartet Ergebnisse.
Das kann zu einer geradezu paradoxen Situation führen. Die Strategieeinheit hat ihr Zielbild erstellt, die Architektur ihre Standards definiert, die Informationssicherheit ihre Anforderungen formuliert, das Infrastrukturteam seine Umgebung geplant, das Netzwerkteam die Konnektivität entworfen und das Projektmanagement die Termine koordiniert. Auch der Betrieb hat seine Anforderungen an eine spätere Übernahme formuliert.
Jede beteiligte Stelle kann ihre Aufgabe korrekt erledigt haben – und trotzdem steht die Plattform Monate oder Jahre später noch nicht produktiv zur Verfügung. Auf die Frage nach dem Warum gibt es dann ebenso korrekte Antworten: Die Planung sei abgeschlossen gewesen, eine Sicherheitsanforderung noch offen, die Betriebsübernahme noch nicht möglich, eine Architekturentscheidung noch ausstehend oder die Finanzierung ungeklärt.
Niemand muss dabei individuell versagt haben. Das System selbst kann dazu führen, dass die Erfüllung von Teilaufgaben wichtiger wird als das Gesamtergebnis.
Das ist der Kern dessen, was man als organisierte Verantwortungslosigkeit bezeichnen könnte: nicht weil Menschen keine Verantwortung übernehmen wollen, sondern weil Verantwortung so weit verteilt wurde, dass sie kaum noch vollständig wahrgenommen werden kann.
Verantwortung ohne Entscheidungsmacht
Noch problematischer wird die Situation, wenn Verantwortung und Entscheidungskompetenz auseinanderfallen. Eine Stelle definiert die Anforderungen, eine andere finanziert, eine dritte legt technische Rahmenbedingungen fest, eine vierte steuert das Projekt – und eine fünfte soll die entstandene Lösung anschließend zehn oder fünfzehn Jahre betreiben.
Derjenige, der die langfristigen Folgen einer Entscheidung tragen muss, hat dann möglicherweise nur begrenzten Einfluss auf diese Entscheidung.
Das widerspricht einem elementaren Organisationsprinzip: Verantwortung benötigt Kompetenz, Ressourcen und Entscheidungsspielraum. Wer für das Ergebnis verantwortlich sein soll, muss maßgeblich beeinflussen können, wie dieses Ergebnis erreicht wird.
Gerade in der öffentlichen IT ist diese Verbindung häufig schwer herzustellen. Ministerien oder Fachverwaltungen haben legitime fachliche Anforderungen und stehen selbst unter Zeit- und Handlungsdruck. Ein zentraler IT-Dienstleister müsste ihnen deshalb frühzeitig überzeugende technische Lösungen anbieten. Kann er das nicht, entsteht ein Vakuum.
Wenn der zentrale IT-Dienstleister keine Antwort hat
Eine Fachverwaltung kann sehr gut beschreiben, was sie fachlich benötigt. Sie sollte jedoch nicht selbst entscheiden müssen, welche Cloudarchitektur langfristig geeignet ist, welche Containerplattform strategisch sinnvoll ist, wie das Identitätsmodell aussehen muss oder welche Automatisierungstechnologie in zehn Jahren noch wirtschaftlich betrieben werden kann.
Genau dafür sollte ein professioneller IT-Dienstleister existieren.
Er müsste seinen Kunden sagen können:
Das sind unsere strategischen Plattformen. Das sind unsere Produkte. Das sind Sicherheitsniveau, Kosten und Servicelevel. So erfolgt die Migration. Und das ist unsere Roadmap für die kommenden Jahre.
Fehlt eine solche Antwort, können Auftraggeber nicht unbegrenzt warten. Sie werden selbst aktiv.
Damit beginnt ein problematischer Kreislauf. Der zentrale IT-Dienstleister besitzt kein überzeugendes Angebot. Die Fachverwaltung verliert Vertrauen und startet ein eigenes Projekt. Zur Unterstützung werden externe Beratungsunternehmen hinzugezogen. Diese entwickeln Zielbilder, Architekturen und Technologieentscheidungen. Anschließend soll der zentrale Dienstleister die entstandene Lösung integrieren oder dauerhaft betreiben.
Dadurch wird die technische Landschaft heterogener. Der Betrieb wird komplexer und teurer. Die Entwicklung eigener Standardprodukte wird für den IT-Dienstleister noch schwieriger. Weitere Auftraggeber verlieren das Vertrauen und starten wiederum eigene Projekte.
Am Ende gibt es mehr Projekte, mehr Technologien und mehr Plattformen – aber nicht zwangsläufig mehr digitale Leistungsfähigkeit.
Warum externe Beratung dabei so mächtig wird
Es wäre zu einfach, Beratungsunternehmen dafür verantwortlich zu machen. Häufig füllen sie lediglich ein Vakuum, das die Organisation selbst geschaffen hat.
Ein Beratungsunternehmen kann innerhalb weniger Wochen ein Zielbild entwickeln, Entscheidungsoptionen strukturieren und eine überzeugende Transformationsgeschichte präsentieren. Für Entscheidungsträger entsteht damit zunächst genau das, was sie benötigen: Orientierung und ein scheinbar klarer Weg nach vorne.
Der erfahrene technische Mitarbeiter formuliert dagegen vielleicht:
„Das können wir umsetzen. Vorher müssen wir allerdings Identitätsmanagement, Netzwerksegmentierung, Backup, Monitoring, Personal, Betriebsprozesse und Sicherheitsanforderungen klären.„
Die Aussage kann technisch wesentlich belastbarer sein. Sie klingt aber kompliziert.
Daneben steht möglicherweise eine übersichtliche Präsentation mit einer modernen Zielarchitektur und einem Transformationspfad.
So entsteht ein gefährliches Wahrnehmungsproblem:
Interne Fachleute beschreiben Realität und Risiken. Externe Beratung präsentiert Zukunft und Lösung.
Die Präsentationsfähigkeit einer Idee darf aber nicht mit ihrer technischen und betrieblichen Tragfähigkeit verwechselt werden. Wer eine Plattform langfristig betreiben muss, beschäftigt sich zwangsläufig mit Problemen, die auf einer strategischen Folie kaum sichtbar sind.
Wenn aus Gestaltern Prüfer werden
Besonders gefährlich wird es, wenn erfahrene technische Mitarbeiter wiederholt erleben, dass externe Einschätzungen höher gewichtet werden, grundlegende Entscheidungen bereits außerhalb ihrer Organisation getroffen wurden und technische Einwände vor allem als Hindernis wahrgenommen werden. Gleichzeitig sollen dieselben Mitarbeiter anschließend die Umsetzung verantworten.
Das verändert eine Organisation.
Menschen, die ursprünglich gestalten wollten, beginnen sich abzusichern. Aus „Wir bauen eine Lösung“ wird irgendwann: „Wir haben auf das Risiko hingewiesen.“
Das ist kein individuelles Charakterproblem, sondern eine rationale Reaktion auf ein System, in dem Verantwortung und Einfluss auseinanderfallen.
Langfristig entsteht ein weiterer Kreislauf: Weniger interne Gestaltungskraft führt zu mehr externer Beratung. Mehr externe Gestaltung reduziert die Möglichkeit, eigenes Know-how aufzubauen. Die Organisation wird noch abhängiger von externem Wissen.
Eine moderne Verwaltung benötigt aber das Gegenteil: technisch erfahrene Mitarbeiter, die gestalten wollen, Verantwortung übernehmen dürfen und das institutionelle Gewicht besitzen, ihre Erfahrung in Entscheidungen einzubringen.
Das Projekt ist sichtbar – das Produkt nicht
Hinzu kommt ein struktureller Anreiz der öffentlichen Verwaltung. Ein neues Digitalisierungsprojekt ist sichtbar. Es hat einen Namen, ein Budget, einen Projektstart, Meilensteine und einen Lenkungskreis. Erfolge lassen sich kommunizieren.
Der dauerhafte Betrieb einer Plattform ist weniger spektakulär.
Dabei entstehen gerade dort über viele Jahre die wesentlichen Aufwände: Patchmanagement, Monitoring, Sicherheitsupdates, Herstellerpflege, Automatisierung, Personal, Modernisierung und schließlich die Ablösung der Plattform.
Eine Organisation kann deshalb eine große Zahl erfolgreicher Projekte starten und gleichzeitig eine immer schwerer beherrschbare IT-Landschaft erzeugen.
Die entscheidende Veränderung besteht deshalb im Übergang von der Projekt- zur Produktorientierung.
Ein Projekt hat ein Ende. Ein digitales Produkt nicht. Es besitzt einen Lebenszyklus und muss kontinuierlich weiterentwickelt werden.
Cloud macht die Schwächen besonders sichtbar
Cloud-Technologie verschärft diese organisatorischen Probleme. Klassische Rechenzentrums-IT ließ sich vergleichsweise stark in Server, Netzwerk, Storage, Backup und Betrieb aufteilen. Cloud lebt dagegen gerade von der Integration dieser Disziplinen.
Compute, Netzwerk, Security, Identity, Automatisierung und Monitoring werden zu einem Service zusammengeführt. Wenn eine Organisation diese Bestandteile weiterhin über unabhängige Zuständigkeiten und nacheinander geschaltete Prozesse liefert, kann technisch durchaus eine Cloudplattform entstehen – organisatorisch aber noch lange keine Cloud.
Ein Self-Service-Portal nutzt wenig, wenn eine notwendige Netzwerk- oder Sicherheitsfreigabe anschließend mehrere Wochen manueller Abstimmung benötigt.
Ein prägnanter Grundsatz lautet deshalb:
Automatisierung endet dort, wo organisatorische Schnittstellen beginnen.
Ein weiteres Gremium löst das Problem nicht
Die klassische Reaktion großer Organisationen auf Koordinationsprobleme besteht häufig darin, zusätzliche Koordination zu schaffen. Ein neues Gremium, eine zusätzliche Abstimmungsrunde, ein Transformationsprogramm oder eine Stabsstelle sollen die bestehenden Strukturen miteinander verbinden.
Das kann kurzfristig sinnvoll sein. Langfristig kann es das Problem jedoch sogar verschärfen, weil zu bestehenden Zuständigkeiten lediglich eine weitere hinzukommt.
Die entscheidende Frage lautet deshalb nicht: Wer muss noch beteiligt werden?
Sondern: Wer trägt am Ende die Verantwortung dafür, dass das vollständige Produkt funktioniert?
Von Zuständigkeiten zu echter Produktverantwortung
Für jedes strategische digitale Produkt sollte es eine eindeutig verantwortliche Rolle geben. Diese Person erledigt natürlich nicht selbst Architektur, Betrieb, Informationssicherheit, Finanzen und Kundenbetreuung. Sie trägt aber die Verantwortung dafür, dass diese Disziplinen zu einem funktionierenden Produkt zusammengeführt werden.
Fachorganisationen bleiben dabei notwendig. Security muss unabhängig bleiben, Netzwerkexperten werden weiterhin benötigt und der Betrieb braucht eigene Kompetenzen. Der Unterschied liegt darin, dass diese Einheiten gemeinsam für ein Produkt arbeiten, statt nacheinander Teilaufträge abzuarbeiten.
Damit muss auch die traditionelle Trennung zwischen Planung, Aufbau und Betrieb hinterfragt werden. Moderne Plattformen sind niemals fertig. Ihr Lebenszyklus lautet nicht mehr planen – bauen – übergeben – betreiben, sondern planen – bauen – betreiben – messen – verbessern – erneut bauen. Engineering und Operations müssen deshalb dauerhaft miteinander verbunden werden.
Eine Strategie muss irgendwann bestellbar werden
Auch Strategien müssen sich an ihrem Ergebnis messen lassen. Eine Cloud- oder Digitalstrategie, aus der keine konkreten Produkte entstehen, bleibt eine Absichtserklärung.
Ein IT-Dienstleister benötigt deshalb ein verständliches Portfolio: virtuelle Infrastruktur, Containerplattformen, Entwicklungsplattformen, Datenbankdienste, Identitätsdienste, Observability, Backup oder sichere Cloudanbindungen. Entscheidend ist weniger die konkrete Bezeichnung als die Tatsache, dass der Kunde tatsächlich etwas bestellen kann.
Zu einem Produkt gehören Leistungsumfang, Verantwortlichkeit, Sicherheitsniveau, Servicelevel, Kosten, Roadmap und Lifecycle. Erst dann verändert sich auch das Verhältnis zwischen Fachverwaltung und IT: Der Kunde beschreibt sein Problem und seine Anforderungen – der IT-Dienstleister entwickelt beziehungsweise empfiehlt die technische Lösung.
Nicht jeder Auftraggeber muss seine eigene Cloudarchitektur entwickeln.
Standard zuerst, Ausnahme wenn notwendig
Das setzt allerdings Standardisierung voraus. Nicht jedes neue Projekt darf seine eigene Technologieplattform mitbringen.
Das Grundprinzip sollte lauten: Standard zuerst – Ausnahme bei begründetem Bedarf.
Eine neue Technologie sollte erst dann eingeführt werden, wenn vorhandene Plattformen die Anforderungen tatsächlich nicht erfüllen können. Sonst optimiert jedes Projekt seine eigene Welt, während niemand die Kosten und Komplexität der entstehenden Gesamtlandschaft verantwortet.
Dazu muss auch die Finanzierung passen. Wenn neue Einzelprojekte leichter finanziert werden als gemeinsam genutzte Basisplattformen, produziert das System zwangsläufig Parallelstrukturen. Gemeinsame digitale Basisdienste brauchen daher eine verlässliche Finanzierung; projektspezifische Sonderanforderungen können dagegen weiterhin vom jeweiligen Auftraggeber getragen werden.
Beratung berät – Verantwortung entscheidet
Schließlich braucht technische Fachlichkeit institutionelles Gewicht. Experten dürfen nicht erst dann beteiligt werden, wenn grundlegende Entscheidungen bereits getroffen wurden.
Daraus lässt sich eine einfache Regel ableiten:
Wer die langfristige Betriebsverantwortung trägt, muss auch maßgeblichen Einfluss auf Architektur- und Technologieentscheidungen besitzen.
Das bedeutet keineswegs, auf externe Beratung zu verzichten. Externe Expertise kann Marktkenntnis einbringen, Alternativen aufzeigen, Entscheidungen challengen und fehlende Spezialkenntnisse ergänzen.
Aber die Rollen müssen eindeutig bleiben: Beratung berät. Verantwortung entscheidet.
Vom Auftragsnehmer zum Lösungsanbieter
Vielleicht liegt hierin der wichtigste notwendige Wandel öffentlicher IT-Organisationen.
Ein professioneller IT-Dienstleister darf nicht ausschließlich darauf warten, dass seine Auftraggeber fertige technische Anforderungen formulieren. Er muss technologische Entwicklungen antizipieren und daraus eigene Angebote entwickeln.
Er muss seinen Kunden sagen können:
„Wir sehen, wohin sich die Technologie entwickelt. Dafür bauen wir folgende Fähigkeiten auf. Hier ist unsere Roadmap. Hier sind Produkte, Kosten und Migrationswege.“
Damit wird aus einem reaktiven Auftragsnehmer ein aktiver Lösungsanbieter. Und genau dadurch entsteht Vertrauen. Auftraggeber werden nur dann darauf verzichten, eigene Plattformen und Parallelstrukturen aufzubauen, wenn sie davon überzeugt sind, dass der zentrale Dienstleister rechtzeitig eine belastbare Alternative anbieten kann.
Die eigentliche Reform ist organisatorisch
Viele Probleme der Verwaltungsdigitalisierung sind damit keine primären Technologieprobleme. Sie sind Organisationsprobleme.
Öffentliche IT verfügt häufig über qualifizierte Mitarbeiter, moderne Technologien und erhebliche finanzielle Mittel. Was ihr fehlt, ist nicht zwangsläufig Kompetenz. Entscheidend ist die Fähigkeit, vorhandene Kompetenz über organisatorische Grenzen hinweg in verbindliche, nutzbare und dauerhaft verantwortete Produkte zu übersetzen.
Dafür braucht es nicht noch mehr Strategien, Projekte und Gremien. Es braucht klare Ende-zu-Ende-Verantwortung, Entscheidungskompetenz dort, wo Verantwortung getragen wird, dauerhafte interdisziplinäre Produktteams, verbindliche Standards und IT-Dienstleister, die ihren Kunden Lösungen anbieten, bevor diese gezwungen sind, selbst welche zu entwickeln.
Vielleicht sollte die entscheidende Frage der Verwaltungsdigitalisierung deshalb künftig weniger lauten:
„Wie starten wir schneller das nächste Digitalisierungsprojekt?“
Sondern:
„Wie schaffen wir Organisationen, die aus Wissen Entscheidungen, aus Entscheidungen Produkte und aus Produkten dauerhaft verlässliche staatliche Leistungen machen?“
Denn am Ende zählt nicht, wie viele Stellen beteiligt waren oder wie viele Projekte gestartet wurden.
Entscheidend ist, ob jemand die Verantwortung dafür trägt, dass es funktioniert.