Ownership statt Rollen: wer nach dem Go-live wirklich zuständig ist

Ein System geht live. Die Pipeline ist grün, die Dokumentation fertig, das Projektteam löst sich auf. Drei Monate später tritt ein kritischer Fehler auf, niemand weiß, wer ihn beheben soll, und der Fachbereich greift wieder auf seine Excel-Liste zurück. Was fehlt, ist keine bessere Technik. Es ist Ownership.

Rollen sind die stillen Trugschlüsse der Organisationsgestaltung. Sie suggerieren, dass jemand verantwortlich ist, nur weil eine Stelle so heißt. In der Praxis bedeutet eine Rolle ohne klare Befugnis, Ressourcen und Verfügbarkeit oft nichts. Ownership entsteht erst, wenn eine Person oder ein kleines Team sagt: „Dieses System, dieser Prozess, diese Entscheidung — das ist bei mir."

Was Ownership unterscheidet

Ownership hat vier Eigenschaften, die Rollen nicht automatisch mitbringen:

• Benannt: Eine konkrete Person oder ein konkretes Team, keine anonyme Funktion.
• Befugt: Die Person darf Entscheidungen treffen, ohne sie durch Gremien schleifen zu müssen.
• Ressourciert: Es gibt Zeit, Budget und Kompetenz, um die Verantwortung auszuüben.
• Messbar: Es ist klar, woran sich der Erfolg des Ownerships festmachen lässt.

Eine Rolle kann all das haben, muss es aber nicht. Gerade in kleinen und mittleren Unternehmen, in denen eine Person mehrere Hüte trägt, verwischt schnell die Grenze zwischen „zuständig für" und „informiert über". Das Ergebnis ist eine Organisationsstruktur, die auf dem Papier ordentlich aussieht und im Betrieb Lücken lässt.

Wo Ownership am meisten fehlt

Die kritischen Stellen sind die Übergänge: von der Architektur zur Delivery, von der Delivery zum Betrieb, vom Betrieb zur Adoption. An jedem dieser Punkte wechselt die Verantwortung den Besitzer — und wenn das nicht laut ausgesprochen wird, fällt sie zwischen die Stühle.

Der Übergang in den Betrieb wird besonders unterschätzt. Ein System, das technisch läuft, aber niemandem gehört, altert schneller als erwartet. Security-Updates, Anpassungen an neue Geschäftsprozesse, das Beheben von Fehlern, die nicht sofort sichtbar sind — all das passiert nicht, weil niemand einen Anreiz hat.

Die Adoption ist der teuerste Übergang. Hier geht es darum, ob Menschen tatsächlich mit dem System arbeiten. Das ist kein Schulungsproblem, sondern ein Verbindungsproblem. Die Person im Fachbereich, die das System vertritt, muss die Sprache der Abteilung sprechen, die Prozesse kennen und genug Autorität haben, um Fragen zu klären und Widerstände anzugehen.

Die Ownership-Karte

Ein einfaches Werkzeug, das wir in der Anfangsphase nutzen, ist die Ownership-Karte. Sie beantwortet vier Fragen für ein Vorhaben:

1. Wer entscheidet? Wer hat das letzte Wort bei Architektur-, Prioritäten- und Budgetfragen?
2. Wer baut? Wer ist für die technische Umsetzung und Qualität verantwortlich?
3. Wer betreibt? Wer kümmert sich um Monitoring, Incidents, Updates und Wartung?
4. Wer erklärt? Wer ist Ansprechpartner für Fachbereich und Nutzer, wer vertritt das System?

Diese Karte nimmt eine Stunde in Anspruch und beantwortet später die Fragen, die sonst wochenlang kreisen. Sie gehört in jedes größere Vorhaben und wird mit jeder signifikanten Änderung neu geprüft.

Ownership und Dienstleister

Wenn ein externer Partner ein System baut, wird die Ownership-Frage noch wichtiger. Viele Projekte enden mit einer Übergabe, die dokumentiert, aber nicht gelebt wird. Der Dienstleister geht, und das Unternehmen bleibt mit einem System zurück, das intern niemand versteht.

Deshalb planen wir die Ownership-Übergabe vom ersten Tag an. Das bedeutet: Das zukünftige Betriebsteam ist früh involviert, Entscheidungen werden dokumentiert, und die Übergabe ist kein einmaliges Event, sondern ein Prozess, der über Wochen läuft. Unser Ownership- und Team-Setup ist genau dafür gedacht.

Ownership kultivieren

Ownership lässt sich nicht einfach zuweisen. Es entsteht, wenn drei Dinge zusammenkommen:

• Verständnis: Die Person versteht das System, den Nutzen und die Grenzen. Das braucht Zeit und Einbindung.
• Befugnis: Sie darf Entscheidungen treffen, ohne jede Kleinigkeit eskalieren zu müssen.
• Rückendeckung: Die Organisation steht hinter der Entscheidung, auch wenn sie mal unbequem ist.

Wer diese drei Punkte nicht zusammenbringt, bekommt stattdessen Verantwortung ohne Macht — das klassische Rezept für Frust und Flucht.

Kurzfassung

Rollen beschreiben, wer was tun sollte. Ownership sagt, wer tatsächlich dafür einsteht. Nach dem Go-live zählt nur das. Die Übergänge zwischen Architektur, Delivery, Betrieb und Adoption sind die Stellen, an denen Ownership am leichtesten verloren geht. Eine Ownership-Karte, die von Anfang an benennt, wer entscheidet, baut, betreibt und erklärt, schließt diese Lücken — und ist der Unterschied zwischen einem System, das läuft, und einem, das ankommt.

Warum Teams das überhaupt tragen können müssen, steht in Teams, die Transformation tragen.