Betriebsmodell entwerfen: das Skelett, nicht die Verkabelung

„Betriebsmodell“ ist einer der am stärksten überfrachteten Begriffe der Unternehmenssprache. Fragen Sie fünf Führungskräfte, was er bedeutet, und Sie bekommen ein Organigramm, eine Prozesslandkarte, eine Technologiearchitektur, ein Governance-Modell und eine Liste von Standorten.

Die Verwirrung ist nicht akademisch. Sie ist der Grund, warum Arbeit am Betriebsmodell so oft ein Dokument hervorbringt, das alle freigeben und mit dem niemand arbeiten kann: Die Beteiligten haben verschiedene Dinge entworfen.

Eine Arbeitsdefinition

Das Betriebsmodell ist die aus der Strategie abgeleitete Blaupause dafür, wie die Organisation tatsächlich arbeiten wird: welche Capabilities sie braucht, wie diese Capabilities angeordnet sind, wie die Arbeit zwischen ihnen fließt und wo entschieden wird.

Zwei Wörter in diesem Satz tragen die Last.

Aus der Strategie abgeleitet. Ein Betriebsmodell wird nicht im luftleeren Raum entworfen. Es leitet sich aus einer Strategie ab – aus Where-to-Play-Entscheidungen, aus der Art, wie die Organisation im Wettbewerb bestehen will. Ein Betriebsmodell, über dem keine Strategie steht, ist nur eine Reorganisation mit besserem Vokabular.

Blaupause. Es ist ein Entwurf, keine Umsetzung. Es legt Struktur und Absicht fest. Es legt nicht fest, welches System welche Transaktion abwickelt.

An dieser zweiten Unterscheidung scheitern die meisten Betriebsmodellprogramme, und es lohnt sich, hier genau zu sein.

Skelett und Verkabelung

Denken Sie in zwei Schichten.

Das Skelett ist der strukturelle Entwurf: das Capability-Modell, wie sich Capabilities zu Einheiten gruppieren, die Entscheidungsrechte, der Fluss der Arbeit zwischen den Capabilities, die Schnittstellen, die es geben muss. Das leitet sich aus der Strategie ab, und es ist eine Frage der Methodik – es hat richtige und falsche Antworten, gemessen an der Strategie, der es dient.

Die Verkabelung ist die Umsetzung: welche Systeme, welche Integrationen, welche Datenflüsse, welche Plattform, welcher Anbieter. Das ist eine Frage der Architektur, und es ist Handwerk. Es hängt von der bestehenden Systemlandschaft ab, von technischen Randbedingungen, von den verfügbaren Kenntnissen, von zehntausend Einzelheiten, die keine Methodik vorwegnehmen kann.

Beides ist nötig. Sie sind nicht dieselbe Disziplin, und sie sollten nicht vermengt werden.

Wir sagen ausdrücklich, auf welcher Seite wir arbeiten: UNITE entwirft das Betriebsmodell – das aus der Strategie abgeleitete Skelett. Die Verkabelung Ihrer IT-Architektur bleibt das Handwerk Ihrer Architekten.

Diese Grenze ist mit Absicht gezogen. Ein System, das beides zu leisten behauptete, würde zu viel versprechen, und der Fehlschlag fiele auf Ihre Architekten zurück.

Warum Programme beides vermengen

Weil die Verkabelung konkreter ist und sich deshalb eher wie Fortschritt anfühlt.

Sechs Wochen nach Beginn eines Betriebsmodellprogramms bringt die Arbeit am Skelett Capability-Definitionen und Karten der Entscheidungsrechte hervor – abstrakte Artefakte, die sich schlecht vorführen lassen. Ein paralleler Arbeitsstrang kann derweil ein Integrationsdiagramm zeigen. Die Aufmerksamkeit der Führung wandert zum sichtbaren Artefakt, und die Arbeit am Skelett wird still zusammengestrichen.

Das Ergebnis ist eine Umsetzung, hinter der kein haltbarer Entwurf steht. Sechs Monate später, wenn die Frage aufkommt, warum die Capability Kundenservice dort sitzt, wo sie sitzt, lautet die ehrliche Antwort: Dort haben die Systeme sie hingestellt.

Was gute Arbeit am Skelett hervorbringt

Vier Artefakte, und sie sind alle struktureller und nicht technischer Natur.

Ein Capability-Modell. Was die Organisation können muss, ausgedrückt in Capabilities statt in Abteilungen – denn Abteilungen sind eine Umsetzung von Capabilities, nicht umgekehrt. Aus der Strategie abgeleitet: Jede Capability sollte auf etwas zurückführbar sein, das die Strategie verlangt.

Eine Begründung der Gruppierung. Welche Capabilities zusammen sitzen und warum. Hier findet der größte Teil der eigentlichen Entwurfsarbeit statt, und hier sitzt der größte Teil des Streits, denn die Gruppierung bestimmt die Koordinationskosten.

Entscheidungsrechte. Wer entscheidet was, auf welcher Ebene. Das ist chronisch unterbestimmt. Die meisten Dokumente zum Betriebsmodell beschreiben Struktur und lassen die Entscheidungsrechte im Ungefähren – womit sicher ist, dass die erste schwierige Entscheidung eskaliert.

Schnittstellen. Wo Capabilities aneinander übergeben müssen und was über die Grenze gehen muss. An den Schnittstellen scheitern Betriebsmodelle in der Praxis, und fast nie werden sie ausdrücklich entworfen.

Das Ziel-Betriebsmodell als entworfene, nachvollziehbare Blaupause – nicht als Reorganisation mit besserem Vokabular.

Die Forderung nach Nachvollziehbarkeit

Eine einzige Eigenschaft trennt ein Betriebsmodell, das überlebt, von einem, das still aufgegeben wird: Jedes Element sollte auf die Strategie zurückführbar sein, aus der es sich ableitet.

Nicht als Pflege der Dokumentation. Als ein Mechanismus, der arbeitet.

Wenn sich die Strategie ändert – und im Lauf der Umsetzung eines Betriebsmodells wird sie das –, lautet die Frage, welche Teile des Entwurfs noch gelten. Ist der Entwurf nachvollziehbar, lässt sich diese Frage durch Verfolgen der Verkettung beantworten: Diese strategische Entscheidung hat sich geändert, also stehen diese Capabilities und diese Gruppierung zur Debatte.

Ist er nicht nachvollziehbar, steht die Organisation vor der Wahl, einen Entwurf umzusetzen, der nicht mehr zu ihrer Strategie passt, oder von vorn zu beginnen. Beides ist teuer; das Erste ist schlimmer, weil die fehlende Ausrichtung unsichtbar bleibt, bis sie Symptome hervorbringt.

Die Reihenfolge, die funktioniert

Das Muster, das nach unserer Erfahrung funktioniert, ist oben unmodisch linear und darunter iterativ.

Zuerst die Strategie, genau genug, dass sich daraus Anforderungen an die Capabilities ableiten lassen. Dann das Skelett, entworfen gegen diese Strategie und auf sie zurückführbar. Dann die Verkabelung, entworfen gegen das Skelett, von den Leuten, die die Systemlandschaft kennen.

Was nicht funktioniert, ist, Skelett und Verkabelung gleichzeitig von verschiedenen Teams mit verschiedenen Herren entwerfen zu lassen. Das ergibt zwei Entwürfe, die sich im Lenkungsausschuss treffen, und die Verkabelung gewinnt, weil sie Termine hat.

Ein praktischer Test

Nehmen Sie Ihre aktuelle Dokumentation des Betriebsmodells und greifen Sie ein beliebiges strukturelles Element heraus – eine Einheit, eine Gruppierung, eine Berichtslinie.

Fragen Sie: Aus welcher strategischen Entscheidung leitet sich das ab? Stellen Sie dann der Person, die dieses Element verantwortet, dieselbe Frage.

Weichen die Antworten voneinander ab, oder ist eine von beiden eine historische statt einer strategischen Erklärung, dann ist das Betriebsmodell nicht aus der Strategie abgeleitet. Es ist der angesammelte Rückstand früherer Reorganisationen, und es wird weiter Koordinationsprobleme hervorbringen, die keine noch so gute Umsetzung beheben kann.