Digital beschlossen, aber noch nicht betriebsbereit: Im April 2026 waren in Berlin erst rund 10.000 der ursprünglich vorgesehenen 70.000 Beschäftigten für die E-Akte registriert. Als Hindernisse nennt die WELT unter Berufung auf dpa fehlerhafte Software, schwierige Schnittstellen, Personalmangel, Akzeptanzprobleme und Defizite in der Projektsteuerung.
Der Fall zeigt exemplarisch, woran viele IT-Vorhaben scheitern. Nicht an einer einzelnen Technikfrage, sondern am Zusammenspiel von Prozessen, Verantwortlichkeiten, Infrastruktur und organisatorischen Rahmenbedingungen. Genau dieses Zusammenspiel vor Einführung oder Änderung eines IT-Services beschreibt der Begriff Service Readiness.
Was bedeutet Service Readiness?
Ihre Organisation ist auf kritische IT-Services angewiesen. Fallen etwa das ERP-System für Auftragsabwicklung und Abrechnung, die Produktionssteuerung oder das zentrale Identity- und Access-Management aus, stehen im schlimmsten Fall ganze Fachbereiche oder das Kerngeschäft still.
Für IT-Verantwortliche beginnt die Absicherung solcher Services daher nicht erst im laufenden Betrieb. Ein technisch verfügbares System ist noch kein zuverlässig erbringbarer Service. Service Readiness prüft vor Einführungen, Änderungen und Betriebsübergaben, ob alle Voraussetzungen für einen stabilen Regelbetrieb erfüllt sind. Vier Bereiche sind dabei besonders wichtig.
1. Dokumentation allein schafft keine Prozessreife
Bei einer zentralen Datenplattform eines Energieversorgers funktionierte das Incident-Management formal einwandfrei: Vorfälle wurden erfasst, priorisiert und geschlossen. Das Problem-Management existierte dagegen nur auf dem Papier. Für die Ursachenanalyse waren keine Kapazitäten eingeplant.
Die Folge: Eine fehlerhafte Datenlieferung wurde monatelang immer wieder einzeln korrigiert. Die eigentliche Ursache – eine fehlerhafte Datentransformation im Quellsystem – blieb unbearbeitet.
| Tipp | Ein Prozess ohne eingeplante Kapazitäten existiert faktisch nicht, selbst wenn er vollständig dokumentiert ist. |
| Trick | Definieren Sie verbindliche Auslöser für den Gesamtprozess. Tritt dieselbe Störung beispielsweise dreimal innerhalb von 30 Tagen auf, wird automatisch ein Problem-Record eröffnet. |
| Best Practice | Überprüfen Sie halbjährlich nicht nur die Existenz, sondern auch die tatsächliche Wirksamkeit Ihrer Betriebsprozesse. |
2. Rollen benötigen Zeit und Mandat
Ein Analyse-Service wurde von zwei Fachbereichen eines Versicherungsunternehmens genutzt. Ein Service Owner war zwar benannt, verfügte jedoch weder über ausreichende Entscheidungsbefugnisse noch über ein festes Zeitbudget.
Als ein Konflikt über eine Funktionserweiterung eskalierte, konnte niemand verbindlich entscheiden. Erst ein Eingriff des Vorstands löste die Situation – verbunden mit einem spürbaren Vertrauensverlust in die IT-Steuerung.
| Tipp | Rollen ohne Mandat können schädlicher sein als fehlende Rollen. Sie suggerieren klare Verantwortlichkeiten, die in der Praxis nicht bestehen. |
| Trick | Halten Sie Aufgaben, Entscheidungsbefugnisse, Eskalationswege und Zeitkontingente in einem verbindlichen Rollensteckbrief fest. |
| Best Practice | Trennen Sie die strategische Verantwortung des Service Owners von der operativen Steuerung durch den Service Manager. Bei einer Personalunion sollten Zuständigkeiten und Sparringsrollen trotzdem eindeutig definiert sein. |
3. Realistische Testumgebungen sind unverzichtbar
In einem Kundenprojekt sollte eine neue Fachanwendung eingeführt werden. Das Team war aufgestellt, das Change-Management etabliert und die Betriebsprozesse dokumentiert. Was fehlte, war eine referenznahe Umgebung zwischen Test und Produktion. Aus Kostengründen sollte diese erst später aufgebaut werden.
Kurz nach dem Go-live installierte das Infrastrukturteam ein Betriebssystem-Update in der Produktivumgebung. Da das Update zuvor nicht unter realistischen Bedingungen mit der Fachanwendung getestet werden konnte, fiel die Anwendung aus. Die Ursachenanalyse dauerte mehrere Tage.
| Tipp | Ein durchgängiges Staging-Konzept aus Test-, Referenz- und Produktivumgebung ist eine Grundvoraussetzung für einen stabilen Betrieb. |
| Trick | Testen Sie Backup und Restore sowie Failover vor dem Go-live unter realistischen Bedingungen, statt diese Abläufe ausschließlich zu dokumentieren. |
| Best Practice | Bewerten Sie Einsparungen bei der Infrastruktur immer im Verhältnis zu möglichen Ausfällen, Nacharbeiten und Vertrauensverlusten im späteren Betrieb. |
4. Services brauchen eine tragfähige Organisation
In einem weiteren Kundenprojekt wurde ein neuer Service erfolgreich produktiv gesetzt. Rollen, Prozesse und Governance waren klar definiert. Trotzdem kam seine Weiterentwicklung nach wenigen Monaten zum Stillstand.
Die Verantwortung war auf zwei Abteilungen verteilt, die unterschiedlichen Vorständen unterstanden. Beide Bereiche verfolgten andere Prioritäten. Der Service Owner konnte formal entscheiden, war für jede Umsetzung aber auf Ressourcen aus beiden Abteilungen angewiesen. Die Organisationsstruktur blockierte damit die Weiterentwicklung des Services.
| Tipp | Prüfen Sie frühzeitig, ob Ihre Organisationsstruktur einen dauerhaft steuerbaren Servicebetrieb tatsächlich ermöglicht. |
| Trick | Machen Sie strukturelle Hindernisse transparent – auch wenn sie außerhalb der unmittelbaren IT-Verantwortung liegen oder unangenehme Entscheidungen erfordern. |
| Best Practice | Denken Sie Service Readiness gemeinsam mit notwendigen organisatorischen Veränderungen. Häufig ist die wirksamste Serviceoptimierung keine technische, sondern eine strukturelle. |
Service Readiness beginnt vor dem Go-live
Die Beispiele folgen einem gemeinsamen Muster: Ausfälle, Konflikte und Stillstand entstehen selten durch eine einzelne technische Ursache. Häufig fehlen Kapazitäten, Befugnisse, realistische Tests oder geeignete organisatorische Strukturen.
Um viele dieser Probleme künftig zu verhindern und erhebliche Folgekosten zu vermeiden, fragen Sie nicht nur, ob Ihr nächster IT-Service technisch fertig ist. Fragen Sie auch, ob Ihre Organisation bereit ist, ihn dauerhaft zu erbringen, zu steuern und weiterzuentwickeln.
Ist Ihr nächster IT-Service bereit für den Regelbetrieb?
Vor Go-live, größerer Änderung oder Betriebsübergabe prüfen wir einen konkreten IT-Service entlang von Anforderungen, Beteiligten, operativer Vorbereitung und Durchführung. Sie erhalten eine priorisierte Maßnahmenliste mit konkreten Handlungsempfehlungen für einen stabilen Regelbetrieb.
Ihr Ansprechpartner
Akar Alkadi
Stabile IT-Services brauchen klare Prozesse, verlässliche Steuerung und einen reibungslosen Übergang in den Betrieb. Ich unterstütze Sie bei Service Readiness, IT-Servicemanagement und der Optimierung operativer IT-Strukturen. Lassen Sie uns sprechen – Ihr leistungsfähiger IT-Betrieb beginnt mit einer klaren Serviceorganisation.
Akar Alkadi ist Managing Consultant und Team Manager bei HiSolutions. Er begleitet Organisationen bei IT-Servicemanagement, Service Readiness und IT-Service-Transition sowie bei der Steuerung und Optimierung operativer IT-Services.