Fünf Elemente eines agilen IT-Betriebsmodells

Spätestens mit der Corona-Krise hat die digitale Transformation den Einzug in die Chefetagen diverser Organisationen gefunden. Neben der Digitalisierung von Produkten und Dienstleistungen, Lieferketten und Kundeninteraktionen ist auch die digitale Zusammenarbeit aus dem Homeoffice bzw. Remote Work relevant geworden.

Dies stellt insbesondere IT-Organisationen vor bisher ungeahnte Herausforderungen. In den letzten Jahren waren viele IT-Organisationen im Spagat zwischen Ressourcenmangel, veralteter Arbeitsmethodik und steigenden Anforderungen an Geschwindigkeit gefangen. Daher beschäftigen sich viele IT-Leiter derzeit mit solchen Themen wie Kulturwandel und Umdenken in der Art und Weise des Betriebs der hauseigenen IT. Nicht zuletzt spricht man in diesem Zusammenhang über ein neuartiges schlankes agiles und digitales IT-Betriebsmodell.

Nachfolgend sind fünf Elemente beschrieben, welche für ein zukunftsorientiertes agiles digitales IT-Betriebsmodell charakteristisch sind und den Weg dahin erleichtern:

1. Product Owner aus dem Business

Product Owner (PO) ist eine der zentralen und wichtigen Rollen im agilen Setup. Er entwickelt eine Vision des Produkts bzw. vom Endergebnis des Projekts. Der PO ist zuständig für den wirtschaftlichen Erfolg des Vorhabens. Er definiert, konsolidiert und priorisiert fachliche Anforderungen und ist somit die zentrale Anlaufstelle für Stakeholder und künftige Nutzer vom Ergebnis. Der PO repräsentiert den Kunden im Projekt.

Neben der fachlichen Gesamtverantwortung bzw. Verantwortung für den wirtschaftlichen Erfolg des Projekts ist der PO für die Erstellung des Business Case zuständig. Dort wird üblicherweise festgehalten welchen Nutzen das Projekt bringt (Steigerung Umsatz, Reduktion Kosten, Investition in die Sicherung der Zukunftsfähigkeit). Da die Projekte im Einklang mit agilen Werten und Prinzipien oft in kleineren Scheiben bzw. MVPs (Minimal Viable Product) realisiert werden, gehört auch die fachliche Umsetzungsplanung in den Business Case. Hier soll beschrieben werden nach welcher Etappe welcher Business Value realisiert wird.

Nicht zuletzt gehören kommunikationsrelevante Aufgaben zum Aufgabenspektrum eines PO: Abstimmung der Anforderungen mit Stakeholdern, Vermitteln zwischen Stakeholdern, Austausch mit dem Lösungsarchitekten und dem Umsetzungsteam.

Idealerweise soll ein Product Owner aus dem Business bzw. aus dem Fachbereich gestafft werden. Die benötigte Verfügbarkeit variiert in der Regel nach Projektgrösse, bewegt sich aber grundsätzlich im Rahmen 0.5-1 FTE.

Aktuelle Digitalisierungsprojekte erfordert oft einen Generalisten in der Rolle eines PO. Digitale Projekte haben oft breite Auswirkungen in der Organisation und umfassen gleichzeitig mehrere Themenbereiche. Daher haben viele Organisationen, welche den Fachbereich zu stark spezialisiert in Sub-Units geschnitten haben, Schwierigkeiten bei der Besetzung einer solchen Rolle. Es bedarf jemand mit den Querschnittskenntnissen vom Business gepaart mit einer gewissen IT-Affinität.

2. MVP-Ansatz bzw.«Slice the elephant»

Bei vielen traditionell aufgesetzten Projekten wird die vollständige Funktionalität der Lösung zu Beginn des Projekts definiert, da sie sonst bei der Umsetzungsplanung nicht berücksichtigt und letztendlich nicht umgesetzt wird. Ein MVP-Ansatz bietet eine Alternative: man beginnt mit dem kleinsten «überlebensfähigen» Produkt und entwickelt die Endlösung stets mit dem Fokus auf Kunden in kleinen iterativen Schritten.

Üblicherweise enthält ein MVP die minimale erforderliche Funktionalität mit ausreichender Qualität und dem definierten Business-Nutzen. Dieses MVP wird in kürzest möglicher Zeit geliefert und produktiv geschaltet. Ab da beginnt der Lernprozess, welcher aus der Interaktion mit dem Kunden entsteht. Die Lösungen bzw. digitale Produkte werden somit iterativ und inkrementell entwickelt.

Auch grössere Vorhaben wie CRM-Ablösung und ERP-Migrationen lassen sich nach diesem Prinzip in kleinere, verdaubare Scheiben «schneiden». So kann beispielsweise eine CRM-Migration in mehrere Einzelprojekte heruntergebrochen werden: Migration der Accounts, Verträge, Sales Pipeline und abteilungsübergreifende Aufgaben. Alternativ kann die Migration auch nach Geographie oder Gesellschaft «geschnitten» werden.

Die grösste Herausforderung beim MVP-Ansatz ist das «M» zu finden, was minimal genug ist, um das «V» viable / überlebensfähig zu machen bzw. Business-Nutzen zu stiften. Eine Vorstudie ist dabei kein MVP.

3. Einbindung des Architekturmanagements in die Projektarbeit

Das Ausmass an Veränderungen innerhalb von Organisationen ist gross und somit ist die eigene IT-Landschaft diesen Veränderungen ausgesetzt. Damit man den Überblick nicht verliert ist ein schlankes agiles Architekturmanagement notwendig. Der grosse Mehrwert entsteht daraus, dass man den Trade-Off zwischen dem opportunistischen Handeln und Nachhaltigkeit bewusst treffen kann. Die Auswirkungen auf eigene Landschaft werden gerne bei der IT-Entscheidungsfindung vergessen und führen über kurz oder lang zu Folgekosten (höhere Anschaffungs- und Wartungskosten) sowie vermeidbaren erhöhten  Anforderungen an die IT-Organisation  (Komplexität und Doppellösungen, Abhängigkeit von auslaufenden Technologien, keine passenden IT-Skills in-house für moderne Technologien usw.).

Die Probleme lassen sich oft durch die Einbindung des Architekturmanagements in die Projektarbeit beheben. Varianten dazu sind die direkte personelle Einbindung des Unternehmensarchitekten bei der Konzepterstellung eines grösseren Vorhabens, sporadische Architektur-Reviews der langlaufenden Initiativen oder ganz einfach die Einführung verbindlicher Architekturprinzipien. Das letztere ist eine wirkungsvolle Methode. Wenn richtig aufgestellt und implementiert, dienen Architekturprinzipien als Nordstern für die Entscheidungsfindung in der Projektarbeit oder in den Value Streams, ohne die personellen Kapazitäten des Unternehmensarchitekten zu stark zu  beanspruchen. Lediglich die Abweichungen von diesen Prinzipien müssen wohlbegründet sein und abgestimmt werden.

4. Agile Zielführungssysteme, z.B. mit OKR

OKR (Objectives & Key Results) ist eine Managementmethode, welche die Ziele einer Organisation mit den Zielen der Teams und einzelner Mitarbeitenden verbindet und dadurch die Fokussierung und das Alignment in der gesamten Organisation herstellt. Im Unterschied zu den herkömmlichen Jahreszielen werden OKRs quartalsweise überprüft und angepasst. Durch das iterative rollierende Überprüfen behalten die persönlichen und Gruppenziele somit ihre Aktualität. Daher wird OKR oft als Framework für agile Zielvereinbarung bezeichnet.

OKRs sind von jeder Person in der Organisation einsehbar. Dadurch schaffen die OKRs Klarheit und Transparenz darüber, woran eine Person, Gruppe oder Abteilung arbeitet und vor allem wie es in die Gesamtzielerreichung einfliesst. Die Summe aller OKRs bilden die Priorität der Gesamtorganisation.

OKR ist kein Performance-Review-System. Individuelle Leistungsbeurteilung ist davon entkoppelt.

5. Portfolio-Prozess mit kurzen Review-Zyklen

Jährliche Budgetierungsrunden bieten ebenfalls wenig Flexibilität und Anpassungsfähigkeit bei sich ändernden Business-Anforderungen. Hier empfiehlt sich die Einführung von kürzeren Review-Zyklen (halbjährlich oder quartalsweise). Die Budgetpositionen und deren Zuordnungen auf wichtigste Themen können somit viel öfter aktualisiert werden. In diesem Zusammenhang kann auch die Zuteilung der Mitarbeiter auf Projekte und Review benötigter Skills erfolgen. Nicht zuletzt ist die Kapazitätsallokation für Wartung, technische Schulden und neue Architekturen notwendig.

Autor: Ivan Kovynyov ist Principal Business Consultant bei Zühlke in Zürich und berät die Kunden im Bereich der CIO Advisory. Ivan Kovynyov studierte Wirtschaftsinformatik an der Universität Karlsruhe und absolvierte sein MBA-Studium am Imperial College London und New York University. Ivan Kovynyov ist Autor und schreibt für diverse Online-Medien zu den Themen der Einführung von Agilität, der digitalen Transformation in Unternehmen, Digitalisierung von Prozessen und Innovation. Der Fokus seiner Beiträge liegt auf der Schnittstelle zwischen Business und IT.

Bild: Bonneval Sebastien on Unsplash

Disclaimer: Zühlke ist ein swissICT Firmen-Mitglied. Firmen-Mitgliedern steht unser Blog offen für Themen-Inputs und Fachartikel. Die Beiträge müssen journalistischen Anforderungen genügen und dürfen nicht werblich sein. Sie möchten auch einen Beitrag publizieren? Für Fragen dazu benutzen Sie gerne dieses Kontaktformular.