Katalog
concept#Operating Model#Governance#Organisationsdesign

Target Operating Model (TOM)

Ein Target Operating Model (TOM) beschreibt das Zielbild, wie eine Organisation zukünftig arbeitet – inklusive Struktur, Governance, Prozesse, Rollen, Fähigkeiten und Unterstützungsplattformen.

Ein Target Operating Model (TOM) ist ein konsistentes Zielbild für die operative Leistungsfähigkeit einer Organisation.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Organisatorisch
  • Organisation
  • Fortgeschritten

Technischer Kontext

Strategie- und OKR-ProzessEnterprise Architecture & ADRsPortfolio- und Programmmanagement (Roadmaps, Initiativen)

Prinzipien & Ziele

Klar definierte Verantwortlichkeiten und EntscheidungsrechteWertstromorientierung statt SilodenkenTransparente Steuerung über wenige, relevante Metriken
Erkundung
Unternehmen, Domäne

Use Cases & Szenarien

Kompromisse

  • Über-Formalierung: Governance blockiert Delivery statt sie zu unterstützen
  • Falsche Abgrenzungen von Verantwortungen erzeugen neue Silos
  • Unterinvestition in Enablement (Plattform, Skills) macht das TOM unwirksam
  • Mit wenigen Bausteinen starten und iterativ verfeinern
  • Entscheidungsrechte explizit machen (z. B. RACI/Decision Matrix)
  • Metriken so wählen, dass sie Verhalten steuern, nicht nur berichten

I/O & Ressourcen

  • Strategie, Ziele und Prioritäten
  • Ist-Struktur und Prozesslandkarte
  • Capability-/Service-Übersicht
  • TOM-Blueprint (Bausteine, Prinzipien, Zielzustand)
  • Governance- und Entscheidungsmodell
  • Transformations-Roadmap mit Übergangsschritten

Beschreibung

Ein Target Operating Model (TOM) ist ein konsistentes Zielbild für die operative Leistungsfähigkeit einer Organisation. Es verbindet Strategie und Ausführung, indem es festlegt, wie Wert geschaffen wird (Value Streams), wie Verantwortung verteilt ist (Rollen, Entscheidungsrechte, Governance), wie Arbeit organisiert wird (Strukturen, Prozesse, Zusammenarbeit) und welche Fähigkeiten, Daten und Technologien dies unterstützen. Ein TOM dient als Referenzrahmen für Transformationen, Reorganisationen, Operating-Model-Redesign, Skalierung und Standardisierung. Typische TOM-Bausteine sind: Operating-Model-Prinzipien, Organisations- und Teamstruktur, Entscheidungs- und Steuerungsmodelle, Prozess- und Service-Design, Capability Model, Sourcing/Partnering, KPI-System sowie Enablement durch Plattformen und Tooling.

✔

  • Schnellere Entscheidungen durch klarere Governance
  • Bessere Ausrichtung von Struktur, Prozessen und Enablement auf Strategie
  • Reduzierte Reibung durch definierte Schnittstellen und Erwartungen

✖

  • Kann zu komplex werden, wenn zu viele Bausteine gleichzeitig modelliert werden
  • Erfordert Commitment von Führung und Stakeholdern für Governance und Umsetzung
  • Gefahr eines Papier-Target-Models ohne echte Verankerung im Alltag

  • Entscheidungsdurchlaufzeit

    Zeit von Problem-/Change-Antrag bis zur Entscheidung inklusive Governance-Schleifen.

  • Time-to-Market

    Dauer von Idee/Discovery bis Release in Produktion für relevante Wertströme.

  • Betriebsstabilität (SLO-Erfüllung)

    Erfüllung definierter Service Level Objectives über Produkte/Services hinweg.

TOM für Plattform-Enablement in einer Produktorganisation

Eine Plattform-Funktion wird als Enablement-Team aufgebaut, mit klaren Service-Angeboten, SLOs und Schnittstellen zu Stream-aligned Teams.

TOM zur Harmonisierung internationaler Domain-Strukturen

Mehrere Länderorganisationen werden über gemeinsame Capability-Definitionen, Governance und Standardprozesse konsistent ausgerichtet.

TOM als Zielbild für M&A-Integration

Nach einer Akquisition wird ein gemeinsames Operating Model definiert, um Verantwortlichkeiten, Prozesse und Systeme schrittweise zusammenzuführen.

1

Ziele, Scope und Leitprinzipien für das TOM festlegen

2

Value Streams, Capabilities und Verantwortungsbereiche modellieren

3

Zielstruktur (Teams, Rollen, Interaktionen) definieren

4

Governance, Entscheidungsrechte und Cadence designen

5

Enablement (Plattformen, Skills, Daten) und Metriken verankern

⚠️ Technische Schulden & Engpässe

  • Uneinheitliche Tooling- und Plattformlandschaft erschwert Standardisierung
  • Shadow-Governance und inoffizielle Entscheidungswege bleiben bestehen
  • Metriken sind nicht belastbar oder werden nicht in Entscheidungen genutzt
Unklare VerantwortlichkeitenZu viele Abhängigkeiten zwischen TeamsEntscheidungen dauern zu lange
  • TOM wird genutzt, um Kontrolle zu erhöhen statt Wertfluss zu verbessern
  • TOM wird als Blaupause kopiert, ohne Kontext und Reifegrad zu berücksichtigen
  • TOM wird technisch dominiert, obwohl organisatorische Probleme im Vordergrund stehen
  • Zu frühes Festlegen von Strukturen ohne ausreichende Discovery
  • Stakeholder-Alignment wird unterschätzt
  • Enablement wird als nachgelagert betrachtet statt als zentraler TOM-Baustein
Organisationsdesign und Change ManagementProzess- und Service-Design, WertstromdenkenStakeholder-Management und Moderation
Skalierbarkeit der Organisation bei wachsendem PortfolioKürzere Time-to-Market ohne QualitätsverlustRisikoreduktion durch klare Governance und Controls
  • • Bestehende regulatorische Anforderungen und Auditierbarkeit
  • • Legacy-Systeme und organisatorische Pfadabhängigkeiten
  • • Begrenzte Veränderungskapazität in Teams und Führung