Wer übernimmt, wenn ein IT-Projekt in den Betrieb geht?

Ein IT-Projekt kann fachlich abgeschlossen wirken und trotzdem im ersten Supportfall scheitern. Entscheidend ist nicht nur, ob die Lösung läuft. Entscheidend ist, ob der Betrieb weiß, wer übernimmt, was geprüft wurde und wo die Grenze der Verantwortung liegt.

Eine Betriebsübergabe ist der Moment, in dem aus Projektarbeit ein verlässlicher Service werden soll. Für ITSM-Generalisten ist sie deshalb keine Formalität am Ende, sondern ein eigener Qualitätsfilter. Sie verbindet technische Dokumentation, Supportfähigkeit, Zuständigkeit, Messpunkte und Entscheidungswege. Ohne diese Verbindung landet der erste Fehler oft dort, wo gerade jemand erreichbar ist.

Der Go-live beantwortet nicht die Supportfrage

Viele Projektpläne behandeln den Go-live als Zielmarke. Aus Betriebssicht ist er eher der Beginn einer neuen Verantwortung. Nutzer stellen Fragen, Schnittstellen fallen aus, Berechtigungen fehlen, ein Monitoring schlägt an oder ein Anbieter verweist auf eine andere Zuständigkeit. Dann reicht es nicht, dass das Projektteam eine Abnahmefolie besitzt.

Atlassian beschreibt IT Service Management als Praxis, mit der IT-Teams Services über den ganzen Lebenszyklus planen, liefern, betreiben und unterstützen. Microsoft ordnet in seiner Cloud Adoption Framework Manage-Methodik ebenfalls ein, dass Betriebsprozesse, Verantwortlichkeiten und Überwachung bewusst vorbereitet werden müssen. Genau an dieser Stelle wird die Übergabe praktisch: Sie muss den laufenden Service erklären, nicht nur die Einführung.

Eine gute Übergabe nennt den nächsten Verantwortlichen

Der wichtigste Test ist einfach: Wer entscheidet beim ersten echten Problem? Wenn diese Antwort unklar bleibt, wandert das Ticket durch Teams, obwohl die Technik vielleicht gar nicht kompliziert ist. Ein Supportfall braucht einen Service Owner, eine fachliche Ansprechperson, einen technischen Betreiber und einen Weg zur Eskalation. Diese Rollen müssen nicht immer getrennte Personen sein. Sie müssen aber sichtbar sein.

Besonders kritisch sind Schnittstellen. Ein neues Portal hängt an Identität, Datenbank, Netzwerk, Fachprozess, Monitoring und vielleicht an einem externen Dienstleister. Wenn jede Gruppe nur ihren eigenen Baustein übergibt, entsteht kein betrieblicher Service. Dann fehlt die Stelle, die den Gesamtzustand bewertet und dem Nutzer eine klare Antwort gibt.

Dokumentation ist nur dann nützlich, wenn sie im Ticket hilft

Übergabedokumente werden oft zu lang oder zu abstrakt. Für den Betrieb zählt, ob sie im Supportfall die nächste Handlung erklären. Wo sieht der Service Desk den Status? Welche Fehlermeldung ist kritisch? Welche Information muss ins Ticket? Welche Änderung darf der First Level selbst anstoßen? Wann muss die Bereitschaft eingebunden werden?

IBM beschreibt ITIL als Rahmenwerk für IT Service Management, das Services, Prozesse und kontinuierliche Verbesserung strukturiert. In diesem Sinn ist Dokumentation kein Archiv, sondern ein Arbeitsmittel. Eine kurze Betriebsseite mit Verantwortlichen, Betriebszeiten, Abhängigkeiten, bekannten Fehlerbildern und Eskalationswegen kann wertvoller sein als ein vollständiges Projekthandbuch, das im Ernstfall niemand liest.

Der Übergabetest gehört vor den ersten Nutzerärger

Ein sauberer Übergabetest simuliert nicht die perfekte Demo, sondern den normalen Störfall. Ein Nutzer meldet eine Fehlfunktion, ein Alarm kommt aus dem Monitoring, eine Schnittstelle liefert falsche Daten oder ein externer Dienst antwortet nicht. Danach wird geprüft, ob Ticketannahme, Priorisierung, Diagnose, Kommunikation und Eskalation funktionieren.

NIST SP 800-53 behandelt unter anderem Konfigurationsmanagement, Änderungssteuerung und Kontrollen für Informationssysteme. Für einen ITSM-Artikel muss daraus kein Auditkapitel werden. Der praktische Punkt ist: Änderungen und neue Services brauchen nachvollziehbare Kontrolle. Wer nicht weiß, was produktiv ist, welche Abhängigkeiten bestehen und wer Änderungen freigibt, kann den Service später kaum verlässlich betreiben.

Die Abnahme braucht Betriebsfragen statt Projektlob

Eine Projektabnahme fragt häufig, ob Anforderungen umgesetzt wurden. Die Betriebsabnahme muss zusätzlich fragen, ob der Service im Alltag tragfähig ist. Sind Monitoring und Alarmwege aktiv? Gibt es einen bekannten Rückweg bei Fehlern? Ist die Wissensbasis für den Service Desk verständlich? Sind Datenschutz, Berechtigungen und Anbietergrenzen geklärt? Gibt es eine Person, die nach vier Wochen prüft, ob Annahmen aus dem Projekt noch stimmen?

Diese Fragen wirken manchmal unbequem, weil sie das Projekt kurz vor dem Ziel bremsen können. Genau deshalb gehören sie früh in den Plan. Ein Betrieb, der erst nach dem Go-live merkt, dass Zuständigkeit, Kostenstelle, Service Level oder Eskalation fehlen, bezahlt die Lücke später mit Wartezeit, unklaren Tickets und Vertrauensverlust bei den Nutzern.

Aus Projektende wird Serviceanfang

Der bessere Übergabepunkt ist nicht das Abschlussmeeting, sondern der bestandene Betriebsnachweis. Das Projekt zeigt, dass der Service Desk den Fall versteht, der Betreiber die Abhängigkeiten kennt, der Owner Entscheidungen trifft und der Nutzer eine nachvollziehbare Antwort bekommt. Erst dann ist der neue Dienst nicht nur installiert, sondern betreibbar.

ITSM-Teams können dafür eine kurze Checkliste verwenden: Service Owner benannt, Supportweg getestet, Monitoring geprüft, Wissensartikel freigegeben, Eskalation beschrieben, Anbietergrenzen dokumentiert, Rückweg geklärt und erster Review-Termin gesetzt. Diese Liste ersetzt keine Governance. Sie verhindert aber, dass ein Projekt formal fertig ist, während der Betrieb noch keinen echten Ansprechpartner hat.

Quellen und Einordnung: Atlassian zu IT Service Management, Atlassian zu Incident Management, Microsoft Cloud Adoption Framework Manage, IBM zu ITIL, NIST SP 800-53 Rev. 5. Stand der Quellenprüfung: 17.07.2026. Bildquelle: Pexels, Foto-ID 6592368.