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.
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.
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.
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.
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.
Die Exploration basiert auf drei Grundsätze:
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.
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.
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.
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.
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.