dot.tipp - Was ist ein Target Operating Model (TOM)?

Was ist eigentlich ein Target Operating Model (TOM)? Es ist der "Nordstern"; ein gewünschter Endzustand, ein Einsatzkonzept. Ein TOM beantwortet, wie ein Unternehmen oder eine strategische Geschäftseinheit idealerweise strukturiert sein sollte, um strategische Ziele zu erreichen respektive Wirkung zu erzeugen. In diesem Beitrag beantworten wir die wichtigsten Fragen zum Thema Target Operating Model (TOM).

Warum braucht man ein Target Operating Model (TOM)?

Was bleibt, ist der Wandel. Kaum eine Organisation ist stabil. Ob eine "grosse" Transformation für beispielsweise stärkere Teams oder Team von Teams, eine strategische Neuausrichtung oder ein externer Stellvertreter - Organisationen müssen sich anpassen.

Ein TOM fasst mehrere Perspektiven eines Zielbildes zusammen. Das reduziert Komplexität und vereinfacht die Kommunikation. TOM können auch rasch mittels Nordstern-Workshops erarbeitet werden. Das erhöht die Ausrichtung aller am Prozess beteiligten Mitarbeitenden. Beliebt sind auch Canvas, z.B. das Operating Model Canvas, das man aspirierend einsetzen kann.

Woraus besteht ein Target Operating Model (TOM)?

Erfahrungsgemäss beinhaltet ein TOM mindestens folgende Perspektiven:

• Strategie: Was treibt die Organisation um? Was möchte die Organisation bezwecken? Warum?
• Ablauforganisation: Welche Fähigkeiten respektive Hauptprozesse sind notwendig? Welche logischen Zusammenhänge sind zu folgern respektive welchen ist zu folgen?
• Aufbauorganisation: Wie könnte die Organisation gemäss TOM aufgebaut sein? Wo wird abgegrenzt? Was sind die grossen Linien?

Die nachfolgende Visualisierung zeigt ein fiktives und primitives TOM einer marktorientierten Organisation. Schwarz repräsentiert den Treiber, Blau die grobe Aufbauorganisation nach Prozess geschnitten und Grau die notwendigen Schlüsselfähigkeiten.

In diesem Beispiel wird deutlich, dass Engineering Projekte gleichmässig führt ("Run the project"), Sales aber Prozesse nach Kundensegment differenziert. Das Bild deutet an, dass "Run the project" in einem skalierten Scrum abgewickelt wird, hingegen Sales im Kanban-Modus.

Es können weitere Perspektiven in ein TOM integriert werden. Wo der Kontext gebietet, sind auch kritische Lieferanten oder externe Abhängigkeiten eingebunden.  

Welche Vorlagen existieren für ein Target Operating Model (TOM)?

Bevor Vorlagen konsultiert werden können, muss das TOM eingegrenzt werden. Ist die komplette Organisation betroffen oder "nur" eine strategische Geschäftseinheit? In einer strategischen Geschäftseinheit sind insbesondere die Schnittstellen zur Restorganisation zu klären. Das verlangt lokale Anpassungen.

Ebenso muss die Art der Arbeit differenziert werden. Folgende Szenarien sind in diesem Beitrag wiederholt:

• Kundenspezifisch: Produktentwicklung für einen internen Kunden
• Marktorientiert: Produktentwicklung für einen Markt

Die Modelle, die original aus der Softwareentwicklung stammen, sind für das kundenspezifische Szenario geeignet. Wer direkt für den Markt entwickelt, muss den Anforderungen des Marktes entsprechen. Manche Waren oder Dienstleistungen haben umfangreichere Vertriebszyklen oder höhere Kundenbetreuungsaufwände, die ebenfalls in einem TOM gewürdigt werden müssen. Die gesamte Wertschöpfung muss in einem TOM abgebildet werden können.

Populäre TOM der Softwareentwicklung, die eben in das kundenspezifische Szenario passen, sind:

• LeSS: Das leichtgewichtige Framework basiert auf Prinzipien - Fokus auf Ablauforganisation. 
• SAFe: Das umfassende Framework setzt Regeln und gilt als die grösste Toolbox - Fokus auf Ablauforganisation. 

Die wichtigsten Unterschiede beider Frameworks haben wir in unserem Blog zusammengefasst: LeSS oder SAFe: Was sind die Unterschiede?

Für das marktorientierte Szenario startet man gut mit folgenden Vorlagen:

• Team Topologies: Ein Handbuch, wie man Teams organisiert und strukturiert; zeitigt eine erste Version eines TOM und ist auch im SAFe zitiert - Fokus auf Aufbauorganisation.
• unFIX Model: Eine Sammlung von Mustern für die Aufbauorganisation (Teamschnitt) und Strategie (Operationalisierung), Hinweise auf Prozesse (z.B. Planungs- und Steuerungsprozesse).

So oder so muss für das marktorientierte Szenario der jeweilige Markt respektiert werden. Erfahrungsgemäss münden solche Analysen in einem lokalisierten Modell, das kombiniert, was der Methodenmarkt offeriert.

Ist das Scaled Agile Framework (SAFe) auch ein Target Operating Model (TOM)?

SAFe in der ersten Version war ein Agile Requirements Engineering Framework für Softwareentwicklungsvorhaben, um die Arbeit mehrerer Teams (Team von Teams) zu koordinieren. SAFe legt ein virtuelles zweites "Betriebssystem" auf eine Organisation. SAFe regelt insbesondere die Prozessperspektive. Im Portfolio-Plugin verknüpft SAFe auch eine strategische Dimension. Im 10. SAFe Prinzip "Organize around value" lässt SAFe frei, die physische Aufbauorganisation ebenfalls nach den SAFe-Strukturen zu gliedern.  

So ist SAFe tatsächlich ein Target Operating Model. Allerdings ist SAFe auf Produktentwicklungsorganisationen beschränkt. Vorgelagerte respektive nachgelagerte Aktivitäten sind enthalten, z.B. Continuous Exploration, um Kundenbedürfnisse zu verstehen, sowie Continuous Deployment, um die Lösung an den Markt zu bringen. Diese sind im SAFe in den Agile Release Trains (ART) integriert. Für eine interne, im Jargon kundenorientierte Softwareentwicklung ist das ausreichend; für einen Maschinenhersteller mit Marktfokus jedoch nicht.

Freilich beherrscht SAFe die Ablauforganisation. Allfällige Koordinationen zwischen Teams, zwischen Teams von Teams sind hinlänglich beschrieben und werden in standardisierten Trainings vermittelt.

Wie implementiert man ein Target Operating Model (TOM)?

Ein Bild ist rasch gezeichnet. Wesentlich anspruchsvoller ist die Umsetzung eines TOM. Weil mindestens drei Perspektiven zu beachten sind, ist ein Transformationsvorhaben dementsprechend zu planen:

• Strategie: Ein Prozess, um die Strategie im Tagesgeschäft zu etablieren und Wirksamkeit regelmässig zu überwachen
• Ablauforganisation: Neue Prozesse erfordern ein detailliertes Zusammenarbeitsmodell auf Ebene Team sowie Team von Teams, damit Wert geschaffen werden kann
• Aufbauorganisation: Eine pragmatische Organisation unterstützt die Wertschöpfung und behindert sie nicht. 

Die drei Perspektiven können im Transformationsprojekt als eigene Schwimmbahnen angeordnet werden. Die Strategie treibt die Ablauforganisation, die Ablauforganisation wiederum beeinflusst die Aufbauorganisation.

Man sollte also nicht sofort mit der Aufbauorganisation starten, diese kann vielmehr die Transformation krönen. Im Einzelfall kann eine vorzeitige Aufbauorganisation jedoch die Transformation begünstigen. Auch hier gilt: es kommt drauf an.

Ebenso sollte der Strategie-Prozess nicht vernachlässigt werden. Ansonsten ist eine Strategie zwar initiiert, aber nirgends operationalisiert. Viele TOM-Initiativen sind strategisch motiviert, aber vergessen die Strategie und deren Umsetzung.  

Die Zusammenarbeit in und zwischen den Teams entscheidet schliesslich über den Erfolg oder Misserfolg eines TOM. Bleibt das TOM zu abstrakt, wird also nicht ausreichend in der Prozessperspektive detailliert, ändert sich in der täglichen Zusammenarbeit nichts bis wenig. In den Teams beweist sich die Wirkung eines neuen TOM.

Ein TOM zu implementieren, ist gleichsam Teamarbeit. Eine einzelne Person innerhalb der Organisation, mag sie noch so einflussreich sein, kann kein TOM durchsetzen. Die einzelnen Schwimmbahnen sind als eng geführte Teilprojekte aufzusetzen, die idealerweise zur gleichen Zeit am gleichen Ort wirken. Das Transformationsprojekt kann mit einem Scrum Framework beschleunigt werden.