Sectorlens gestaltet Target Operating Models, IT-Reorganisationen und Veränderungsvorhaben für CIOs und IT-Vorstände. Klare Rollen, belastbare Schnittstellen, gelebte Service-Management-Routinen. Wir liefern nicht nur den Plan, sondern führen die Veränderung bis ins Alltagsverhalten der Teams. Auch in der M&A-Integration und bei Carve-outs.
Die meisten Reorganisationen kommen zu spät. Diese Signale zeigen an, dass die Ist-Organisation die Geschäftsstrategie strukturell nicht mehr trägt und Handlungsbedarf besteht.
Sechs Prinzipien, die den Unterschied zwischen einem Plan auf Papier und einer Veränderung machen, die im Alltagsverhalten der Teams ankommt. Sie resultieren aus Mandaten, in denen wir gelernt haben, was trägt und was nicht.
Sechs Bausteine. Wir kombinieren sie je nach Reifegrad, Größe und Anlass. Vom fokussierten TOM-Mandat bis zur vollständigen IT-Reorganisation oder M&A-Integration.
Zielbild der IT-Organisation auf allen fünf Layern: Governance, Service-Delivery-Modell, Rollen, Prozesse und Sourcing. Mit klaren Architektur- und Service-Entscheidungen statt offener Wunschliste. Das TOM ist nicht das Ergebnis der Reorganisation, sondern deren Ausgangspunkt.
Strukturwandel der IT-Organisation. Neue Abteilungen, Rollen und Berichtswege, die aus dem TOM abgeleitet sind, nicht umgekehrt. Mit stufenweisem Roll-Out aus Pilot, Skalierung und Stabilisierung. Keine Big-Bang-Reorganisation, die an der Stabilisierung scheitert.
IT-Integration nach Übernahme oder Fusion. Tag-1-Plan zur Service-Sicherstellung, Tag-100-Plan mit Quick-Wins, gemeinsames TOM für die Ziel-Organisation. Carve-outs strukturieren wir analog: Inventarisierung aller Assets, Entkopplungspfad, Day-1-Plan mit eigenständiger Infrastruktur.
Vom klassischen Plan-Build-Run zu Product-Teams oder Platform-Engineering. Modell-Wahl mit begründeter Entscheidung aus dem Service-Portfolio, dem technischen Reifegrad und der Geschäftsstrategie. Schrittweiser Roll-Out, klare Übergaben zur Linie, messbare Adoptionsziele.
Veränderungsbegleitung mit Stakeholder-Mapping, Co-Design-Prozess, Kommunikations-Plan und Adoption-Tracking mit messbaren Zielen. Operativ statt PowerPoint-Change. Begleitung bis das neue Modell im Alltagsverhalten der Teams angekommen ist, nicht nur im Org-Chart steht.
Steerings, Boards und Entscheidungswege. RACI für die wichtigsten Prozesse, klare Eskalationspfade, geklärte Schnittstellen zu Vorstand und Aufsichtsrat. Governance ist die Ebene, die über alle anderen Ebenen des TOM entscheidet und daher als erste konsistent gestaltet sein muss.
70 Prozent großer Transformationsvorhaben erreichen ihre Ziele nicht (McKinsey, 2023). Die Ursachen sind bekannt und vermeidbar. Diese sechs Muster beobachten wir in nahezu jedem gescheiterten Mandat.
Eine neue Struktur wird eingeführt, aber Rollen, Prozesse und Governance bleiben ungeklärt. Mitarbeitende wissen, an wen sie berichten, aber nicht, wie Entscheidungen getroffen und Services erbracht werden. Das neue Org-Chart ist nach 90 Tagen durch informelle Strukturen überlagert.
Das neue Modell wird auf die gesamte Organisation ausgerollt, bevor es in einem kontrollierten Bereich getestet wurde. Fehler im Design treffen alle gleichzeitig. Korrektur ist aufwändig, weil kein isolierter Bereich mehr existiert. Pilotierung in zwei bis drei Bereichen hätte das verhindert.
Das Konzept wird fertiggestellt, die Berater verlassen das Haus, die interne Umsetzung stockt. Ohne monatliche Reviews, dokumentierte Adoptionsziele und klare Stabilisierungs-Verantwortung kehrt die Organisation innerhalb von 6 bis 12 Monaten in alte Muster zurück.
Rollen sind nominell definiert, aber die RACI für die wichtigsten Prozesse fehlt. Folge: Doppelarbeit, fehlende Übergaben, eskalierende Konflikte. Eine sauber dokumentierte RACI für 12 bis 15 Kernprozesse ist eine der wirkungsvollsten Maßnahmen in der Transformation und eine der am häufigsten übersprungenen.
Outsourcing oder Near-Shoring werden entschieden, bevor das Service-Delivery-Modell steht. Ergebnis: Sourcing-Verträge passen nicht zur Governance, Übergaben sind unklar, Steuerbarkeit sinkt. Sourcing-Entscheidungen müssen aus dem TOM folgen, nicht umgekehrt.
Das TOM wird im kleinen Kreis entwickelt und dann kommuniziert. Die Betroffenen waren nicht beteiligt. Adoption-Probleme entstehen nicht aus Böswilligkeit, sondern aus fehlendem Verständnis und fehlender Mitgestaltung. Co-Design ist eine Erfolgsvoraussetzung, kein Komfort.
Ein TOM ist kein Org-Chart. Es beschreibt auf fünf konsistenten Ebenen, wie eine IT-Organisation ihre Services erbringt, steuert und weiterentwickelt. Alle fünf Ebenen müssen aufeinander abgestimmt sein. Eine Entscheidung auf Ebene 2 zieht immer Konsequenzen auf Ebene 3, 4 und 5 nach sich.
Auf dieser Ebene werden die grundlegenden Ausrichtungsentscheidungen der IT verankert: Ist die IT ein Cost Center, Profit Center oder Value Center? Wer entscheidet über IT-Investitionen, welche Steerings und Boards gibt es, wie ist das Verhältnis zwischen Zentral-IT und Business-IT geregelt? Ohne klare Governance-Ebene entstehen informelle Entscheidungsstrukturen, die das gesamte TOM dauerhaft untergraben. Governance ist nicht das Erste, worauf Organisationen achten, aber es ist das Erste, was sie brauchen.
Auf dieser Ebene wird entschieden, wie Services erbracht werden: klassische Plan-Build-Run-Organisation, Product-Team-Modell oder Platform-Engineering-Ansatz? Welche Service-Cluster werden unterschieden, welche SLAs gelten, wie ist die Übergabe zwischen Entwicklung und Operations geregelt? Das Service-Delivery-Modell hat direkte Auswirkungen auf Struktur (Ebene 3) und Sourcing (Ebene 5). Es kann nicht los-gelöst von diesen Ebenen entschieden werden.
Rollen sind nicht gleich Stellen. Auf dieser Ebene werden die funktionalen Rollen definiert, die das Operating Model benötigt: Product Owner, Platform Engineer, Service Owner, Demand Manager, Enterprise Architect. Für jede Rolle wird beschrieben, was sie verantwortet, welche Entscheidungsbefugnis sie hat und wie sie mit anderen Rollen zusammenarbeitet. Die RACI-Matrix übersetzt diese Rollen in konkrete Prozessverantwortung für 12 bis 15 Kernprozesse. Erst dann leitet sich der Org-Chart aus den Rollen ab, nicht umgekehrt.
Auf dieser Ebene werden die operativen Abläufe beschrieben: Incident-Management, Change-Management, Demand-to-Delivery, Service-Onboarding, Vendor-Management. Für jeden Kernprozess werden Ablauf, beteiligte Rollen (RACI) und Übergabepunkte dokumentiert. Service-Management-Routinen wie wöchentliche Service-Reviews, monatliche Governance-Steerings und quartalsweise Portfolio-Reviews werden auf dieser Ebene verankert. Prozesse, die dokumentiert aber nicht gelebt werden, sind kein Gewinn. Deshalb ist die Einführungsbegleitung unersetzlich.
Die fünfte Ebene beschreibt die technische und vertragliche Basis des Operating Models: Welche Plattformen werden intern betrieben, welche eingekauft? Wo wird Outsourcing eingesetzt, wo Near-Shoring, wo strategische Partnerschaft? Sourcing-Entscheidungen auf dieser Ebene müssen mit dem Service-Delivery-Modell (Ebene 2) und den Rollen (Ebene 3) kompatibel sein. Ein Outsourcing-Vertrag, der nicht zur Governance-Struktur passt, schafft Steuerungsprobleme, die nachträglich teuer zu beheben sind.
Wir bringen eigene Werkzeuge ins Mandat ein. Die RACI-Matrix für die saubere Rollen-Klärung und den TOM-Atlas für die Gesamtsicht über alle fünf Operating-Model-Ebenen. Im Mandat aufgesetzt, nach Mandatsende dauerhaft im Haus.
Die RACI-Matrix klärt für die wichtigsten Prozesse, wer verantwortet (Accountable), wer ausführt (Responsible), wer konsultiert (Consulted) und wer informiert wird (Informed). 12 bis 15 Kernprozesse abgebildet, Eskalationspfade definiert, Vertretungsregeln dokumentiert, verknüpft mit dem Governance-Modell. Im Mandat aufgesetzt, danach dauerhaft im Haus.
Der TOM-Atlas zeigt das Target Operating Model über alle fünf Ebenen: Strategie und Governance, Service-Delivery, Rollen, Prozesse und Sourcing. Mit aktuellem Status je Ebene, benanntem Eigentümer und nächster Quartals-Lieferung. Reifegrad-Sicht für Vorstand und Aufsichtsrat, die den Detail-Kontext nicht benötigen.
Das Adoption-Dashboard zeigt nach Go-Live, ob das neue Modell im Alltag ankommt: Prozess-Nutzungsfrequenz, Governance-Adoption, Service-Review-Kadenz, Eskalationsquote und Rollenklarheit-Score aus monatlichen Pulse-Surveys. Monatliche Grundlage für die Service-Reviews.
Kein Service-Delivery-Modell ist universell richtig. Die Entscheidung folgt aus dem Service-Portfolio, der Geschäftsstrategie und dem technischen Reifegrad. Hybridmodelle sind häufig die pragmatischere Lösung.
Klare Trennung zwischen strategischer Planung, Entwicklung und operativem Betrieb. Bewährt für stabile, gut abgegrenzte Service-Landschaften mit hoher Infrastruktur-Intensität und vergleichsweise geringem Veränderungsdruck. Stärke: Vorhersehbarkeit, klare Kostenstruktur, gut zu steuern. Schwäche: Langer Übergabe-Overhead bei häufigen Änderungen.
Kleine, stabile Teams mit End-to-End-Verantwortung für eine Business-Capability. Hohe Eigenverantwortung, kurze Time-to-Market, direkte Business-Nähe. Erfordert reifen Product-Owner-Ansatz und klares Portfolio-Management. Schwäche: Coordination-Overhead bei teamübergreifenden Abhängigkeiten, die nicht sauber entflochten sind.
Zentrale Platform-Teams stellen Self-Service-Fähigkeiten für stream-aligned Teams bereit. Reduziert kognitive Last, erhöht Standardisierung, ermöglicht schnellen Developer-Self-Service. Erfordert hohe technische Reife, Cloud-native Infrastruktur und Platform-as-a-Product-Mindset. Wirkt erst ab kritischer Organisationsgröße.
Wie schnell verändern sich Anforderungen? Hoher Veränderungsdruck spricht für Product Teams oder Platform Engineering. Stabiles, vorhersehbares Service-Portfolio spricht für Plan-Build-Run oder ein konservatives Hybridmodell mit selektiver Einführung moderner Elemente.
Platform Engineering setzt CI/CD-Reife, Cloud-Betrieb und starke DevOps-Kompetenz voraus. Ohne diese Basis ist ein Hybridmodell mit selektiver Product-Team-Einführung in ausgewählten Clustern sinnvoller als ein vollständiger Platform-Ansatz.
Platform Engineering wirkt ab einer kritischen Größe. Kleine IT-Organisationen profitieren häufig mehr von klar definierten Plan-Build-Run-Prozessen mit sauberer RACI als von Platform-Ansätzen, die Investitionen erfordern, bevor der Nutzen sichtbar wird.
IT-Transformation ist kein Einmal-Projekt, sondern ein gestufter Prozess. Zu viel Veränderung auf einmal überfordert Organisationen und produziert Widerstand. Zu wenig Veränderung und das neue Modell bleibt Papier. Wir arbeiten in drei konsistenten Phasen, die aufeinander aufbauen.
Bestandsaufnahme der aktuellen IT-Organisation: Rollen, Prozesse, Governance, Kultur, Service-Portfolio und Kostenstruktur. Stakeholder-Interviews auf allen Ebenen. Formulierung eines klaren Zielbilds, das Strategie und operative Notwendigkeit verbindet.
Entwicklung des Target Operating Models über alle fünf Ebenen: Governance, Service-Delivery, Rollen, Prozesse, Sourcing. RACI-Matrix für 12-15 Kernprozesse. Pilotierung in einem ausgewählten Bereich der IT-Organisation, um das Modell unter realen Bedingungen zu validieren und anzupassen.
Stufenweiser Roll-out des neuen Operating Models auf die Gesamtorganisation. Trainings, Kommunikationsmaterial und Coaching für Führungskräfte. Aufbau des Adoption-Dashboards. Begleitung der ersten Governance-Zyklen, bis das neue Modell stabil im Alltag verankert ist.
Transformationserfolg ist nicht das fertige Konzept. Er ist messbar in der Zeit bis zur ersten unabhängigen Governance-Entscheidung, der Eskalationsquote im zweiten Quartal nach Go-live und dem Rollenklarheit-Score aus den Pulse-Surveys.
70% aller Transformationsprojekte scheitern nicht an schlechten Konzepten, sondern an mangelnder Akzeptanz (McKinsey, 2023). Ein Target Operating Model ist ein Veränderungsprojekt, das Menschen betrifft. Rollen verschieben sich, Verantwortlichkeiten werden klarer und damit verbindlicher, informelle Machtstrukturen werden sichtbar und manchmal abgebaut. Ohne professionelles Change Management entsteht Widerstand, der das neue Modell im Alltag aushöhlt, bevor es wirken kann.
Zu Beginn jedes Mandats identifizieren wir die Stakeholder-Landschaft: Wer gewinnt durch das neue Modell, wer verliert formalen Einfluss, wer ist neutral? Diese Analyse bestimmt die Kommunikationsstrategie und die Reihenfolge der Einbindung. Wir bauen bewusst eine Koalition der frühen Unterstützer auf, die als Multiplikatoren in die Organisation wirken.
Veränderung braucht Erzählungen, nicht nur Folien. Wir entwickeln für jedes Mandat ein konsistentes Narrativ, das erklärt, warum das neue Modell notwendig ist, was es konkret für verschiedene Gruppen bedeutet und wie der Weg dorthin aussieht. Dieses Narrativ wird über alle Kommunikationskanäle konsistent gespielt und von der Führungsebene persönlich vertreten.
Widerstand gegen Veränderung ist normal und kein Zeichen von schlechtem Willen. Er ist ein Signal, dass Unsicherheit, Kontrollverlust oder unzureichende Information vorhanden sind. Wir arbeiten mit strukturierten Interventionsformaten für verschiedene Widerstandsmuster und coachen Führungskräfte in der Handhabung schwieriger Gespräche, die jede Transformation mit sich bringt.
IT-Führungskräfte stehen in Transformationsphasen unter besonderem Druck: Sie müssen das Neue vertreten, obwohl sie selbst noch nicht in den neuen Strukturen angekommen sind. Wir begleiten CIOs, Bereichsleiter und IT-Manager in regulären 1:1-Formaten durch die kritischen Phasen und helfen dabei, die eigene Führungsrolle im neuen Modell zu definieren und auszufüllen.
Teams müssen nicht nur wissen, was ihre neue Rolle bedeutet, sie müssen sie auch üben. Wir führen strukturierte Workshops durch, in denen Teams ihre neuen Rollen in simulierten Governance-Situationen ausprobieren, Eskalationspfade üben und offene Fragen klären, bevor das neue Modell scharfgestellt wird.
Wir messen Adoption nicht am Ende, sondern laufend. Monatliche Pulse-Surveys mit standardisierten Fragen zu Rollenklarheit, wahrgenommener Unterstützung und Konfidenz im neuen Modell geben frühzeitig Signal, wo Nachsteuerung erforderlich ist, bevor Probleme zu Blockaden werden.
Theorie ist notwendig, aber Mandatserfolg entsteht aus der Fähigkeit, Modelle in realen Organisationen mit ihren Widersprüchen, Machtstrukturen und Zeitdruck umzusetzen. Vier Beispiele aus unserer Beratungspraxis.
Ein mittelständischer Maschinenbauer (2.800 Mitarbeitende) nutzte den CIO-Wechsel als Anlass für eine grundlegende TOM-Überarbeitung. Ausgangsproblem: Eine gewachsene IT-Abteilung mit unklaren Rollen, 23 direkten Berichten an den neuen CIO und einer informellen Entscheidungskultur, die Geschwindigkeit systematisch verhinderte. In 14 Wochen entwickelten wir ein neues Operating Model mit 6 Service-Clustern, klarer Governance und einer RACI-Matrix für 14 Kernprozesse.
Nach der Übernahme eines regionalen Versicherungsunternehmens stand der Käufer vor der Aufgabe, zwei gewachsene IT-Organisationen mit unterschiedlichen Plattformen, Service-Modellen und Kulturen zu einer integrierten IT zusammenzuführen. Besondere Herausforderung: Die übernommene IT hatte ihre Eigenständigkeit als Qualitätsmerkmal verinnerlicht. Die Lösung war ein bewusst gestuftes Integrationsmodell, das föderale Elemente bewahrte, wo es strategisch sinnvoll war.
Eine Landesbehörde mit über 5.000 Mitarbeitenden stand vor der Aufgabe, ihre IT-Organisation für die Anforderungen des OZG (Onlinezugangsgesetz) und der EU-NIS2-Direktive neu aufzustellen. Besonderheit: Die Transformation musste innerhalb des beamtenrechtlichen Rahmens und mit hoher politischer Sichtbarkeit stattfinden. Wir entwickelten ein TOM, das regulatorische Anforderungen strukturell verankerte, ohne die notwendige Agilität zu opfern.
Ein regionaler Energieversorger wollte von einer klassischen Plan-Build-Run-Organisation zu einem Product-Team-Modell mit zentralem Platform Engineering wechseln, um Time-to-Market zu verkürzen. Herausforderung: Ein reguliertes Umfeld (EnWG, KRITIS) mit hohen Anforderungen an Prozessdokumentation und Nachweispflichten. Wir passten das Platform-Engineering-Modell an die regulatorischen Anforderungen an und entwickelten ein Compliance-kompatibles DevSecOps-Modell.
Was nicht gemessen wird, wird nicht gesteuert. IT-Transformation ohne KPI-Framework produziert Statusberichte, aber keine Steuerung. Wir etablieren für jedes Mandat ein schlankes, aber belastbares Messsystem über sechs Dimensionen, das monatlich in den Governance-Reviews genutzt wird und Abweichungen frühzeitig sichtbar macht.
Werden die neuen Rollen im Alltag gelebt? Werden Governance-Meetings gehalten und mit den richtigen Stakeholdern besetzt? Werden Entscheidungen auf der richtigen Ebene getroffen oder wandern sie nach oben? Gemessen über Pulse-Surveys (Rollenklarheit-Score), Protokollanalyse der Governance-Meetings und Eskalationsquoten-Tracking.
Werden die definierten Prozesse tatsächlich genutzt? Verbessern sich Incident-Response-Zeiten, Change-Durchlaufzeiten und Service-Verfügbarkeit nach Einführung des neuen Modells? Service-Qualitäts-KPIs sind die härteste Probe für jedes neue Operating Model, weil sie sich nicht schönrechnen lassen.
Fühlen sich Mitarbeitende in den neuen Strukturen sicher und kompetent? Wird das neue Modell als Verbesserung oder als Bürokratisierung wahrgenommen? Gemessen über monatliche Pulse-Surveys mit standardisierten Fragen zu Rollenklarheit, wahrgenommener Unterstützung und Bereitschaft zur Weiterempfehlung des neuen Modells.
Wie schnell werden Business-Anforderungen von der Entstehung bis zur Lieferung umgesetzt? Wie hoch ist der Anteil des IT-Backlogs, der innerhalb des vereinbarten Service-Fensters bedient wird? Diese Kennzahlen machen die Wertschöpfung der IT-Transformation für das Business unmittelbar sichtbar.
Verändert sich die Kostenstruktur der IT? Sinkt der Anteil der Run-Kosten relativ zum Budget für Change und Innovation? Werden Sourcing-Entscheidungen auf Basis belastbarer TCO-Daten getroffen? Finanzielle KPIs sind häufig die entscheidenden Steuerungsgrößen im Vorstandsreporting und dürfen nicht dem Controlling allein überlassen werden.
Verbessert sich die Compliance-Quote nach Einführung des neuen Governance-Modells? Reduziert sich die Anzahl kritischer Security-Findings? Werden Audit-Anforderungen schneller und vollständiger erfüllt? Gerade in regulierten Branchen sind diese KPIs nicht nur steuerungsrelevant, sondern oft gesetzlich verpflichtend zu dokumentieren.
Schildern Sie kurz Ihre Transformations-Situation. Sie bekommen eine ehrliche Einschätzung, ob und wie wir helfen können. Unverbindlich, vertraulich, ohne Verkaufsdruck.