Angebote
Ownership-Setup nach dem Go-live
Damit nach der Einführung nicht die Frage offenbleibt, wer das System eigentlich trägt.
„Es wird geliefert, aber niemand steht für das Gesamtergebnis gerade.“
- Format
- 3–6 Wochen begleitend zum Rollout
- Für wen
- Projekte kurz vor oder nach dem Go-live
Woran Sie es merken
- Nach dem Go-live landen Anfragen bei der Person, die zufällig erreichbar ist.
- Für Fehler gibt es keinen definierten Weg — nur Chatgruppen und Zuruf.
- Weiterentwicklung passiert nebenbei, priorisiert wird nach Lautstärke.
- Das Projekt gilt als abgeschlossen, aber niemand kann sagen, ob es wirkt.
- Der externe Dienstleister ist weg und das interne Team wurde nie richtig eingearbeitet.
Ergebnis
- Rollen- und Verantwortungsmodell für Betrieb, Weiterentwicklung und Support
- Onboarding-Material und interne Kommunikation
- Betriebsroutinen: Incidents, Releases, Feedbackschleifen
- Wirkungsmessung mit wenigen belastbaren Kennzahlen
Wie wir vorgehen
01
Woche 1 — Realitätscheck
Gespräche mit Betrieb, Support, Fachbereich und Entwicklung. Wir schreiben auf, wer heute faktisch zuständig ist — nicht, wer es laut Organigramm sein sollte.
02
Woche 2 — Rollen und Routinen
Ein Verantwortungsmodell für Betrieb, Weiterentwicklung und Support, dazu Routinen für Incidents, Releases und Feedback. Wenige Regeln, die tatsächlich eingehalten werden.
03
Woche 3–4 — Einarbeitung
Onboarding-Material, Runbooks und begleitete Durchläufe: erster Incident, erstes Release, erste Feedbackrunde unter realen Bedingungen.
04
Danach — Wirkung messen
Drei bis fünf Kennzahlen, die zeigen, ob das System trägt. Nach vier bis sechs Wochen schauen wir gemeinsam drauf und justieren.
Häufige Fragen
- Ist das nicht Aufgabe des Projektleiters?
- Projektleitung endet mit dem Projekt. Ownership beginnt danach und braucht andere Rollen: Betrieb, Weiterentwicklung, Support. Genau diese Lücke schließen wir.
- Brauchen wir dafür neue Stellen?
- In der Regel nicht. Meist geht es darum, vorhandene Verantwortung explizit zu machen und Kapazität dafür zu reservieren, statt sie unsichtbar nebenherlaufen zu lassen.
- Wie greift das mit ITIL oder bestehenden Prozessen ineinander?
- Wir bauen auf dem auf, was es gibt. Wenn ein Serviceprozess existiert, hängen wir das Produkt dort ein, statt ein zweites System danebenzustellen.
- Welche Kennzahlen empfehlen Sie?
- Wenige und belastbare: Zeit bis zur Reaktion bei Störungen, Durchlaufzeit einer Änderung, Nutzung durch den Fachbereich. Keine Dashboards, die niemand liest.
- Was passiert nach den sechs Wochen?
- Das Team arbeitet eigenständig. Wenn Sie wollen, bleiben wir mit einem monatlichen Review-Termin in Reichweite — ohne Mindestlaufzeit.
Wann das nicht passt
Wenn die Software technisch noch nicht betriebsfähig ist, kommt das Ownership-Setup zu früh. Dann ist Production-Readiness der bessere erste Schritt.
Passt oft dazu
Hintergrund dazu im Beitrag Ownership statt Rollen: wer nach dem Go-live wirklich zuständig ist.