dot.research - Die drei Betriebsmodelle einer IT

Vor mehr als fünfzehn Jahren sprach man auch in der Schweiz von einer IT der zwei Geschwindigkeiten. Damals war Agile in der Manifestation als Scrum "the fastest kid on the block" - wie es Jurgen Appelo in einem Newsletter resümierte. Seitdem hat sich die Corporate IT der Schweiz verändert. In diesem Beitrag möchte ich die drei Betriebsmodelle einer Corporate IT zusammenfassen. Willkommen. 

Übersicht der Betriebsmodelle

Gemäss SAFe - verzeiht mir die Referenz - bildet der Development Value Stream das primäre Schnittmuster für die untergeordneten Agile Release Trains (ART). Ein Agile Release Train (ART) ist übrigens eine virtuelle "Einsatzorganisation", um eine Solution gemeinsam interdisziplinär zu entwickeln und zu betreiben, so SAFe. Der Development Value Stream hingegen beschreibt den "Entwicklungsprozess", der den allgemeinen Operational Value Stream (den eigentlichen Geschäftsprozess) gezielt unterstützt. Der primäre Diskriminator ist also die Art der Entwicklungsarbeit - erst danach werden ART gemäss materieller Einheit geschnürt. SAFe sieht also vor, dass komplett unterschiedliche Betriebsmodelle existieren können. 

In der Praxis erlebe ich allerdings, dass Organisationen ein Framework für alle Arten der Entwicklungsarbeit aufzwingen möchten - um die Sehnsucht nach Einheitlichkeit und Vergleichbarkeit zu erfüllen. Das widerspricht selbst dem grossen Standardisierer der Corporate IT: SAFe und dessen abgewandelten "Playbooks". 

Im Blog zum Target Operating Model habe ich ein fiktives Industriebeispiel skizziert. Dieses Beispiel möchte ich wiederverwenden und drei Betriebsmodelle von IT-Leistungen anleiten.

Commodity & Global Sourcing

Grundleistungen einer jeden IT sind weltweit standardisiert. Die Anforderungen sind vergleichsweise stabil, die Lösungen mögen sich entwickeln - aber sind grundsätzlich vorhersehbar. Alle Unternehmen müssen Speicherlösungen betreiben (lassen). Alle Unternehmen müssen Kommunikations- und Kollaborationswerkzeuge bereitstellen. Alle Unternehmen müssen Laptops verteilen. Und so weiter. Diese Liste entwickelt sich. Eine solche IT ist auf Stabilität getrimmt. ITIL-Prozesse unterstützen die Bereitstellung dieser Services. Dieser Markt ist übrigens auch komplett globalisiert. Solche Grundleistungen werden verteilt erbracht. 

Hier entscheiden Projektmanagement-Kompetenzen über den Erfolg oder Misserfolg einer solchen Organisation. Es gilt, unzählige Stakeholder zu überblicken, globalisierte Dienstleister mit unterschiedlichen Vertragsbedingungen zu konditionieren - und möglichst standardisiert zu beschaffen. Ein solches Betriebsmodell lässt sich beispielsweise mit einem klassischen Scrum kaum führen. 

Engineering

Hier kann man auch vom klassischen Software-Engineering sprechen. Es geht nicht darum, eine Lösung zu beschaffen - sondern eine Lösung zu entwickeln, die den eigenen Bedürfnissen entspricht. Hier haben sich agile Vorgehensmodelle durchgesetzt. ITIL-Prozesse würden bloss behindern respektive den Prozess unnötig verkomplizieren. Diese Teams sind meistens klein, meistens auf eine konkrete Aufgabe konzentriert. Sie können aber auch verteilt sein, werden in virtuellen Gruppen gebündelt und teilen sich einen Backlog. Hier versprechen SAFe und LeSS ausreichende Struktur, um diese Aufgaben angemessen zu hierarchisieren. Diese Entwicklungsorganisationen sind relativ stabil - lediglich die Aufgaben verändern sich permanent. Es sind klassische teamorientierte Produktentwicklungsorganisationen, wo das Produkt faktisch einer Individualentwicklung für den Eigenbedarf der Gesamtorganisation entspricht. 

Dieses Betriebsmodell hat sich in den letzten zehn Jahren verfestigt. Agile Vorgehensmodelle haben sich auch bewährt und wurden auf unzählige Kontexte adaptiert. Dieser Markt gilt überdies als "gesättigt" - die meisten Organisationen beherrschen die methodische Kunst des Software Engineerings. Scheitern tun sie höchstens in der Ausführung - dort in der Führung und Verkettung unterschiedlicher Teams zu einer integrierten Lösung. 

Exploration

Und wer ist nun "the new kid"? Jurgen Appelo empfiehlt eine "machine lane", verweist gleichzeitig aber auf die Schnittstelle zur "human lane" - was dem Betriebsmodell "Engineering" dieses Blogs entspricht. Für mich ist es nicht eine Maschinenschiene. Das wäre zu kurz, würde sich bloss auf eine Technologie beschränken. Ich möchte stattdessen ein älteres Konzept auffrischen. Es ist die IT an der "langen Leine", die frei von Governance, SOP oder sonstigen Vorgaben explorieren darf. Es ist die "MVP-IT". Sie war auch mal als "Design-Thinking-IT" bekannt. Jene Einheiten, die möglichst rasch Wert schaffen wollten - ohne wegen Integrationskosten sich bekümmern zu müssen. Zeitlang war diese IT auch aufs Thema RPA angesetzt - das heute durch AI Agents ersetzt wurde. Vor einigen Jahren war auch Nakamoto angesagt. 

Die grosse Dominanz des Engineering-Modells, die sich in (tendenziell) überkomplexen "Playbooks" in grossen Organisationen zeigt, hat das Exploration-Betriebsmodell ein wenig verdrängt. Alle Ideen und Vorhaben sollen vom grossen Engineering "zerhäxelt" und in verdaubare Epics, Features und Stories geschnitten werden. Was einst sich anschickte, die Entwicklung zu beschleunigen, lähmt nun die Innovation und Weiterentwicklung der Organisation.

Vermutlich ist das auch bloss ein Missverständnis. Denn selbst SAFe bietet mit dem SAFe Lean Startup Cycle einen budgetierten MVP-Prozess auf Epic-Stufe an. Das wäre ein klassisches Exploration-Element - das allerdings in der Praxis selten gemäss SAFe umgesetzt ist. 

Elemente der Exploration

Die Exploration basiert auf drei Grundsätze:

1. Opportunity Enablement / Value Exploration
   Exploration ist futuristisch. Es gilt Möglichkeiten zu erkunden, welche Werte versprechen.
2. Decoupling / Desintegration
   Die Exploration soll eben konsequenzlos erfolgen. Die Aktivitäten sind per Design entkoppelt und müssen nicht mühsam integriert werden. Integration bleibt die Domäne beispielsweise von Engineering - sobald sich etwas bewährt hat. 
3. Rapid Sourcing / Small Teams
   Lieferanten sollen möglichst rasch und in mehreren Optionen beschafft werden. Einst haben grosse Unternehmen das "single sourcing" verboten, daraus konnten ganze Industrien sich entwickeln. Unterschiedliche Lieferanten sollen explorieren - aber eng geführt. 

Damit gelingen folgende Aktivitäten, die typischerweise der Exploration zugewiesen werden können. Diese Liste ist gewiss nicht abschliessend und kann um den eigenen Kontext komplettiert werden. 

• Explore new technologies
  Ob Blockchain, KI - alles darf ausprobiert werden. Alles muss ausprobiert werden gemäss priorisiertem Technologie-Monitoring. Allerdings mit "multi sourcing". Weil es gibt nicht nur den einen Hoflieferanten. 
• Explore new requirements
  Was wollen die Kunden? Hier darf mit dem Double-Diamond experimentiert werden. Alle Techniken des Requirements Engineering sind zulässig. Annahmen über die Probleme oder Anforderungen des Kunden sollen möglichst rasch überprüft werden können. 
• Explore new business models
  Nicht nur die IT kennt drei Geschwindigkeiten. Selbst das Business hat mehrere. Organisatorische, technische und auch geschäftliche Schulden können einen blockieren - nun braucht's einen Befreiungsschlag. Ein komplett neues Geschäftsmodell muss exploriert und gebaut werden. 
• Explore new cost savings
  Das Gefühl der Dringlichkeit, das Gefühl der Verletzbarkeit motivieren Organisationen, permanent Kosten zu optimieren. Wo ein kontinuierlicher Verbesserungsprozess bloss Mehr-Vom-Selben liefert, muss das Thema Kosten unbefangen und frei von Integrationskosten gelöst werden. 

Welches ist das beste Betriebsmodell?

Dieses dritte Betriebsmodell "Engineering" ist ein Spielfeld für Futuristen, Design Thinkers, Innovationssachverständige, Automatisierungsverantwortliche, AI-Evangelisten. Sie sind bewusst entkoppelt und dürfen explorieren. Einige Unternehmen haben solche Einheiten vor mehr als zehn Jahren teils ausgegründet. Ich habe dieses dritte Betriebsmodell stets als "Spielplatz" belächelt - weil eben keine mühselige Integration erforderlich war. Im Nachhinein will ich mich entschuldigen, ich habe mich geirrt. Dieses dritte Betriebsmodell ist notwendiger denn je. Es braucht alle drei Betriebsmodelle einer IT.

Gewiss variiert die Intensität. Das Engineering-Betriebsmodell dominiert den Engineering-Bereich aller Industrien. Doch auch für Sales oder Customer Care kann das Engineering-Betriebsmodell hilfreich sein. Eventuell gilt es, eine Standardsoftware präzise in die Unternehmenslandschaft zu integrieren - das kann bloss Engineering leisten und keine Commodity irgendwo in allen grossen Zeitzonen dieser Welt. Commodity hingegen braucht es überall - selbst Engineering kann ohne einigermassen standardisierte Entwicklungswerkzeuge und -plattformen keinen Wert produzieren.

Achtung: Mitarbeitende in den einzelnen Betriebsmodellen bedingen ebenso unterschiedliche Führungsmodelle

Diese drei Betriebsmodelle koexistieren. Sie haben gewiss Schnittstellen. Allerdings sollten Führungskräfte die unterschiedlichen "Verhältnisse" in den einzelnen Betriebsmodellen berücksichtigen. Commodity lässt sich nicht gleich führen wie Engineering oder Exploration. Diese Betriebsmodelle ziehen jeweils einen eigenen Schlag "Mensch" an. Das ist okay. 

Grundsätzlich differenzieren wir bei der dot consulting AG maximal zwischen vier Führungsdimensionen. Diese Dimensionen können je nach Komplexität auf einzelne Personen aufgeteilt werden - oder natürlich auch in einer Person vereinigt werden. In KMU oder kleineren IT-Einheiten kann eine Person womöglich alle Leadership-Rollen vereinen. In grösseren IT-Einheiten unterstützen in der Regel spezialisierte Rollen wie z.B. die Rolle "Enterprise Architect" in "SAFe Portfolio" für Technology Leadership oder die Rolle "STE" in "SAFe Large Solution" für Process Leadership. 

• Product Leadership
  Darunter verstehen wir die Fähigkeit, "Produkte" gestalten und treiben zu können. Das beinhaltet auch die Priorisierung von Produktfeatures sowie die Abstimmung derselben mit einem übergeordneten Zeitplan (Portfolio, Strategie). Product Leadership beantwortet in der Regel, was zu tun sei und vor allem warum. 
• Technology Leadership
  Auch Technologie verlangt Führung. Das kann einen definierten Technologie-Stack umfassen, ein aktives Technologie-Monitoring meinen oder die Weitergabe von alltagstauglichen Architektur-Prinzipien bedeuten.  
• Process Leadership
  Wo Menschen zusammenarbeiten, sind auch minimale Zusammenarbeitsmodelle notwendig. Diese Modelle müssen gestaltet, definiert und auch umgesetzt werden. Ein Service-Team innerhalb Commodity hat andere Anforderungen als ein spontanes Exploration-Team. 
• People Leadership
  Insbesondere bei Engineering arbeiten grösstenteils Menschen, welche der Organisation mit einer Festanstellung verpflichtet sind. Diese gilt es zu entwickeln. Aber auch bei Commodity, insbesondere bei Beschaffungsvorhaben, sind hauptsächlich Menschen betroffen - man denke an "neue" Kommunikations- und Kollaborationslösungen. Diese "Stakeholder" im weitesten Sinne sind ebenfalls zu respektieren. 

Die nachfolgende Illustration zeigt diese vier Führungsdimensionen auf die drei Betriebsmodelle verteilt. In der IT sind Technology Leadership und Product Leadership eng verwandt. Das "Produkt" entspricht ja in der Regel einem IT-Service. Ebenso sind Process und People Leadership eng verknüpft; der Prozess (Ablauf) definiert oftmals auch die Struktur (Aufbau) einer Organisation - muss aber nicht, Ablauf und Aufbau könnten übrigens auch komplett entkoppelt, was übrigens SAFe als "virtual second operating system" empfiehlt. 

Die Illustration ist gewiss nicht abschliessend, sondern versuchte bloss die unterschiedlichen Leadership-Fähigkeiten möglichst branchenneutral zu generalisieren. Sie müssen sooderso auf den Kontext adaptiert werden. 

Was bleibt?

Die gesamte IT einer Organisation in ein Betriebsmodell zu zwängen, ist nicht zu empfehlen. Alle Commodity-Teams z.B. in einem gemeinsamen ART mit Engineering-Teams zu drücken, hilft weder den einen noch den anderen. Wir empfehlen hier einen entspannteren Ansatz: das richtige Modell für den richtigen Kontext zu wählen und schliesslich anzupassen. Wie so oft gibt es keine Grösse, die allen passt. Zudem darf man das dritte Betriebsmodell - die Exploration - nicht vernachlässigen. Hier befürworten wir eine maximale Selbstorganisation dieser Exploration-Teams, die mit ausreichendem Risikokapital ausgestattet sind, um eben "Mehrwert" für die Organisation wortwörtlich zu explorieren.