Systemübergabe planen

Ein neues System ist gebaut, getestet, integriert – und dann? Ohne sorgfältige Übergabe kommt es nicht in den Live-Betrieb. Genauer: kann es nicht. Denn alles, was bisher das Projektteam wusste – Konfigurationen, Eigenheiten, Notfallpläne, Wartungsroutinen – muss zur Betriebs-Mannschaft wandern. Anwender müssen lernen, das neue System zu benutzen. Support-Strukturen müssen stehen. Sonst ist der „Go-Live" eine Vollkatastrophe mit hunderten Tickets, frustrierten Mitarbeitern und einer IT, die nicht weiß, was warum eingerichtet wurde. Diese Lektion zeigt dir, wie eine systematische Systemübergabe geplant wird – damit aus dem Projekt-Ergebnis ein langlebiges Produktivsystem werden kann.

1) Was gehört in eine Übergabe?

Eine Systemübergabe besteht aus mehreren Komponenten, die alle vorhanden sein müssen, damit das System produktionsreif ist. Hak ab, was bei dir vorbereitet ist:

Übergabe-Checkliste (interaktiv)

Technische Dokumentation

✓

Architektur-Doku (Komponenten, Datenflüsse, Netzwerkpläne)

✓

Installations- und Konfigurations-Anleitungen

✓

Schnittstellen-Beschreibungen (intern und extern)

✓

Inventar / CMDB-Einträge der Komponenten

Betriebsunterlagen

✓

Betriebshandbuch: Start/Stop, Routine-Wartung, häufige Fragen

✓

Notfallplan / Disaster-Recovery (siehe RTO/RPO)

✓

Monitoring-Setup und Alarm-Eskalation

✓

Backup-Konzept und Restore-Tests

✓

Patch- und Wartungsfenster festgelegt

Sicherheit & Compliance

✓

Berechtigungskonzept (Rollen, Zugriffe)

✓

DSGVO-VVT-Eintrag erstellt, ggf. DSFA

✓

Sicherheits-Konzept & Penetration-Test-Ergebnis

✓

Zertifikate, Lizenzen, Verträge aktenkundig

Anwender und Support

✓

Anwender-Handbuch / Quick-Start-Anleitung

✓

Schulungs-Plan (wer, wann, was?)

✓

Support-Prozess geklärt (1st/2nd/3rd Level)

✓

Akzeptanzkriterien dokumentiert und abgenommen

Vollständigkeit

0 / 16

Praxis: Schon vor dem geplanten Übergabetermin sollte die Liste zu 80–90 % erfüllt sein. Wer am Übergabetag noch viele rote Punkte hat, muss den Termin verschieben – sonst startet der Live-Betrieb mit Lücken, die hinterher wesentlich teurer zu schließen sind. Mehr in Welche Doku für welchen Zweck?.

2) Stakeholder der Übergabe

Eine Systemübergabe ist nie nur „Projektteam an Betrieb". Mehrere Gruppen müssen einbezogen werden – jede mit eigenem Informationsbedarf:

Wer muss bei der Übergabe an Bord sein?

Build-Team

übergibt

Projekt-Manager, Entwickler, Integrator. Haben das System gebaut und kennen jedes Detail.

Betriebs-Team

übernimmt

Admins, DevOps, Monitoring. Übernehmen den laufenden Betrieb. Brauchen alle Run-Books.

Help-Desk / 1st Level

übernimmt

Erste Anlaufstelle für Anwender-Tickets. Brauchen FAQ, häufige Probleme, Eskalationsweg.

Endanwender / Power-User

nutzt

Brauchen Schulung und Handbuch. Power-User werden oft zu Multiplikatoren in den Abteilungen.

Fachbereich / Auftraggeber

freigibt

Gibt formell die Abnahme – ohne ihre Unterschrift kein produktiver Betrieb. Mehr in Abnahme.

Sicherheit & Datenschutz

freigibt

IT-Sec und DSB prüfen Konzepte gegen Vorgaben. Pflicht-Stationen bei personenbezogenen Daten.

Betriebsrat (ggf.)

stimmt zu

Bei Systemen mit Mitarbeiterüberwachung oder Auswertungsmöglichkeit zwingend einzubeziehen.

Externe Dienstleister

supportet

Hersteller, Wartungsdienstleister. Ansprechpartner, SLA, Eskalationswege klären.

Wichtig: RACI-Matrix erstellen – für jede Aufgabe klar machen, wer Responsible, Accountable, Consulted, Informed ist. Verhindert die häufigste Übergabe-Falle: „Ich dachte, du machst das" / „Nein, das macht IhrTeam". Mehr in Erwartungsmanagement.

3) Akzeptanzkriterien definieren

Eine zentrale Frage vor der Übergabe: Woran erkennen wir, dass das System fertig ist? Antwort: an klar definierten Akzeptanzkriterien. Diese müssen vor dem Test/Abnahme schriftlich fixiert sein – sonst gibt es endlose Debatten am Abnahmetag. Wichtige Eigenschaften guter Akzeptanzkriterien:

Akzeptanzkriterien – Beispiele aus der Praxis

Funktion Alle 47 Use Cases aus dem Pflichtenheft sind implementiert und durch Funktionstest bestanden.

Performance Login-Vorgang < 2 Sekunden bei 100 gleichzeitigen Nutzern. Dashboard-Aufruf < 3 Sekunden im 95-Perzentil.

Verfügbarkeit Last-Test über 8 h ohne Fehler. SLA ≥ 99,5 % im Pilotbetrieb.

Datenmigration 100 % der Stammdaten übernommen, < 0,01 % Abweichungen bei Bewegungsdaten. Stichprobe von 100 Datensätzen manuell verifiziert.

Sicherheit Vulnerability-Scan zeigt 0 High/Critical CVEs. Penetrationstest bestanden.

Dokumentation Betriebshandbuch, Anwender-Handbuch, Notfallplan, DSGVO-VVT-Eintrag liegen vor und sind reviewed.

Schulung Schulung für mindestens 90 % der Endanwender durchgeführt, Multiplikatoren benannt.

Support Help-Desk-Mitarbeiter eingearbeitet, Eskalationspfade dokumentiert, externe Service-Verträge unterschrieben.

Goldene Regel: Akzeptanzkriterien müssen SMART sein – Spezifisch, Messbar, Akzeptiert, Realistisch, Terminiert. „System soll schnell sein" ist nicht messbar. „Login < 2 s bei 100 Usern" schon. Wenn der Lieferant Akzeptanzkriterien vorab nicht akzeptiert, ist das ein deutliches Warnsignal – dann sollte der Vertrag nochmal überdacht werden.

4) Schulungs-Plan erstellen

Ohne Schulung verpufft das beste System. Anwender, die nicht wissen, wie sie ihren Job mit dem neuen Werkzeug machen sollen, fallen entweder zurück auf alte Wege oder produzieren Fehler. Eine gute Schulungsplanung berücksichtigt verschiedene Zielgruppen:

Zielgruppe	Inhalt	Format
Endanwender	Tägliche Bedienung, häufige Fälle, Tipps	2–4 h Workshop pro Gruppe, mit Übungen
Power-User / Multiplikatoren	Vertiefte Funktionen, Sonderfälle, Tipps weitergeben	1 Tag intensiv, mit Schulungsmaterial
Help-Desk / 1st Level	Häufigste Probleme, FAQ, Diagnose-Werkzeuge	2 Tage mit Praxis-Tickets
Administratoren	Konfiguration, Wartung, Troubleshooting	3–5 Tage technisch, ggf. mit Hersteller-Zertifikat
Manager / Reports-Nutzer	Reports, Dashboards, KPIs	1–2 h Präsentation mit Übungen

Tipps: Schulungen vor dem Go-Live, aber nicht zu früh (sonst vergessen). Idealerweise mit echten Daten in einer Test-Umgebung – nicht mit fiktiven Beispielen. Train-the-Trainer-Modell: Externe Trainer schulen die Power-User intensiv, diese geben es weiter in ihre Abteilungen. Skaliert und schafft interne Expertise.

5) Support-Konzept einrichten

Was passiert, wenn nach dem Go-Live ein Anwender ein Problem hat? Ohne klares Support-Konzept landet jedes Problem entweder direkt beim Projektteam (überlastet) oder versickert (Frustration). Übliche dreistufige Struktur:

1st Level – Help-Desk: Erste Anlaufstelle, oft per Telefon oder Ticket-System. Löst Standardprobleme („Passwort vergessen", „Anwendung startet nicht"). Eskaliert komplexe Fragen an 2nd Level. Mehr in Aufgaben im IT-Betrieb.
2nd Level – Fach-Support: Tiefere Kenntnisse, kann konfigurieren, Daten korrigieren, mittlere Fehler beheben. Eskaliert weiter an 3rd Level.
3rd Level – Spezialisten / Hersteller: Tiefste Eingriffe, oft externe Spezialisten oder direkt Hersteller-Support. Code-Änderungen, Datenbank-Eingriffe.

Wichtig: Service-Levels definieren – wie schnell muss welches Level reagieren? Klassisch: 1st Level innerhalb 4 h, 2nd Level innerhalb 1 Arbeitstag, 3rd Level innerhalb 3 Arbeitstagen. Bei kritischen Systemen 24/7-Rufbereitschaft. Mehr in Incident Management nach ITIL und SLA.

6) Migrationsfenster und Cutover-Plan

Der Wechsel vom Alt- zum Neusystem geschieht selten „in einem Moment", sondern in einem geplanten Übergangsfenster. Wichtige Elemente:

Cutover-Termin festlegen: Bevorzugt am Wochenende oder über die Feiertage – wenn wenige Anwender aktiv sind. Mit Fachbereich abstimmen.
Detail-Zeitplan (Stunde-für-Stunde): Wer macht wann was? Wer ist erreichbar? Wer entscheidet im Zweifelsfall?
Rollback-Plan: Wenn nach 3 Stunden klar wird, dass etwas Grundlegendes nicht funktioniert – wie gehen wir zurück zum Altsystem? Bis wann ist der Rollback noch möglich?
Kommunikation: Anwender wissen vorab, wann das System nicht verfügbar ist, wann sie wieder loslegen können, wen sie bei Problemen anrufen können.
War-Room einrichten: Während des Cutovers sind alle wichtigen Personen zusammen (physisch oder online). Schnelle Entscheidungen möglich.
Hypercare-Phase: Nach dem Go-Live (oft 2–4 Wochen) ist das Projektteam noch verfügbar und reagiert besonders schnell auf Probleme. Erst danach wird komplett übergeben.

Eine Falle: Manche planen den Cutover „mal eben am Freitagnachmittag". Falsch – wenn etwas schief geht, hat man das ganze Wochenende, um Schaden zu reparieren. Besser: Cutover Freitag früh, sodass am Tag selbst noch Korrekturen möglich sind. Mehr in Rollout-Szenarien.

7) Übergabe-Termin durchführen

Die eigentliche Übergabe ist ein formaler Termin (oder mehrere). Idealer Ablauf:

Vorbereitung: Alle Dokumente liegen in einem zentralen Ort (SharePoint, Wiki, Confluence). Teilnehmer haben sie vorab gesichtet.
System-Demo: Build-Team führt durch alle wichtigen Funktionen, Konfigurations-Bereiche, Monitoring-Ansichten.
Frage-Antwort: Betriebsteam stellt Fragen, kann auch unbequem („Was passiert, wenn die DB voll ist?"). Antworten dokumentieren.
Walk-through der Doku: Wichtigste Dokumente durchgehen, Lücken markieren, ggf. live ergänzen.
Hands-on: Betriebsteam macht Routine-Tätigkeiten selbst (Backup, Restore, Patch, Restart), mit Build-Team daneben.
Protokoll: Was wurde übergeben, was noch offen, welche Verantwortlichkeiten? Schriftlich, von beiden Seiten unterschrieben.

Wichtig: Übergabe ist kein Einzeltermin – es ist ein Prozess. Oft beginnen Übergabe-Aktivitäten Wochen vor dem Go-Live (Schulungen, Test-Betrieb) und enden Wochen danach (Hypercare). Wer das nicht plant, scheitert. Mehr in Change Management nach ITIL.

Zusammenfassung

Eine Systemübergabe überträgt Wissen und Verantwortung vom Projekt- zum Betriebsteam. Inhalte: Technische Doku (Architektur, Installation, Schnittstellen, CMDB), Betriebsunterlagen (Betriebshandbuch, Notfallplan, Monitoring, Backup, Wartungsfenster), Sicherheit (Berechtigungen, DSGVO-VVT, Pen-Test, Lizenzen), Anwender/Support (Handbücher, Schulung, Help-Desk-Prozess, Akzeptanzkriterien). Stakeholder: Build-Team (übergibt), Betriebs-Team + Help-Desk (übernimmt), Endanwender + Power-User (nutzen), Auftraggeber + Sicherheit + DSB + Betriebsrat (geben frei). RACI-Matrix für klare Verantwortungen. Akzeptanzkriterien SMART formulieren: Funktion, Performance, Verfügbarkeit, Migration, Sicherheit, Doku, Schulung, Support – messbar und vorab vereinbart. Schulungsplan nach Zielgruppen (Anwender, Power-User, Help-Desk, Admins, Manager), Train-the-Trainer-Modell. Support-Konzept: 1st/2nd/3rd Level mit definierten Service-Leveln. Cutover-Plan: Termin, Stundenplan, Rollback-Strategie, Kommunikation, War-Room, Hypercare-Phase. Übergabe ist kein Einzeltermin, sondern ein Prozess über Wochen.