VOICE-Frühstücksgespräch IT-Produktorganisation: Zusammenarbeit schlägt Struktur

Eigentlich ist der frühe Morgen nicht die beste Zeit, um kreativ zu sein und neue Gedanken aufzunehmen. Die fast 100 Gäste beim 1. VOICE-Frühstücksgespräch des Jahres legen nahe, dass das für IT- und Digitalentscheider zumindest nur eingeschränkt gilt. Aber vielleicht lag es auch am spannenden Thema IT-Produktorganisation und den interessanten Vortragenden: Professor Ayelt Komus von her Hochschule Koblenz, Dr Jochen Göttelmann, CIO Lufthansa Cargo und last, but not least Bernd Rattey, CIO Deutsche Bahn.

Den Anfang macht eine Blitzumfrage unter den Teilnehmern nach ihrer Form der IT-Organisation. Danach gaben 25 Prozent der Teilnehmer an, sich analog zu den verschiedenen IT-Systemen aufgestellt zu haben, 14 Prozent pflegen bereits eins Produktorganisation, klassisch nach Plan-Build-Run aufgestellt sind 11%. Eine Projektorganisation haben lediglich 3 %. Mit 45 % der größte Teil gab an, in einer Kombination der verschiedenen Formen organisiert zu sein.

Produkte die Kunden wahrnehmen

Danach erklärte Professor Komus die verschiedenen Organisationsformen. Demnach wird die sogenannte Produktorganisation nach den Wertströmen strukturiert. Das heißt, alles, inklusive der IT, was nötig ist, um den Kunden mit einem Produkt oder Service zu versorgen, wird in einem Team und einem System zusammengefasst. Dabei ist aber klar, dass in der Praxis die verschiedenen Wertströme auf mehrere Systeme zugreifen. Das heißt, es gibt nicht ein System pro Produkt, sondern mehrere Produkte teilen sich ein oder mehrere Systeme. Komus zieht das Fazit, dass es in der Regel für Unternehmen gut ist, sich in einer Mischung von Organisationsformen zu strukturieren, weil es keine Form gibt, die alle Bedürfnisse eines Unternehmen gleich gut abdeckt.

Entscheidungen treffen Product Owner

Jochen Göttelmann erzählte in einem Rückblick auf seine Anfangszeit bei Lufthansa Cargo, dass es zu Zeiten der Plan Build Run Organisation immer wieder zwischen den Teams zu Spannungen gekommen sei, besonders zwischen Entwicklern Betrieb. Es habe zu wenig intrinsische Motivation gegeben, nicht nur das eigene, sondern auch die Arbeit des jeweils anderen Teams zu erleichtern. Das habe zu mehr Komplexität Bürokratie und letztlich sogar zu Qualitätsproblemen geführt, weil mitunter die nichtfunktionalen Requirements (Skalierbarkeit, Resilienz etc.) nicht eingehalten wurden. Inzwischen ist die IT-Organisation nach Produkten aufgestellt. Das funktioniere sehr gut, die Qualitätsprobleme sowie die Reibungen zwischen den Teams haben stark abgenommen. Göttelmann hob besonders hervor, dass Entscheidungen im Gegensatz zu früher auf der richtigen, nämlich auf der Ebene der Productowner getroffen würden. Zurzeit wird überlegt, ob das gesamte Unternehmen auf Biz/Devops bzw. Produktorganisation umgestellt werden soll, allerdings ist da noch nichts entschieden.

Domänen orientiert ist der erste Schritt zur Produktorientierung

Bernd Rattey, seit drei Monaten CIO der Deutschen Bahn, berichtet in erster Linie von Erfahrungen, die er als CIO der Fernverkehrssparte der Bahn gemacht hat. Dort wirkte er fünf Jahre bevor er die Verantwortung für die IT im Gesamtkonzern übernommen hat. Anfangs stand dort die IT keineswegs im Mittelunkt. Digitalisierung ist für ihn das mathematische Produkt aus Geschäftsprozessen, IT und Zusammenarbeit. Wenn ein Faktor davon 0 ist, dann habe ich nichts gewonnen. Deshalb waren für ihn zwei Dinge wichtig: Denken von den Prozessen und Denken von den Geschäftsfähigkeiten her, nicht von der Technologie. Deshalb wählt er eine Domänen orientierten Ansatz, fasste Arbeiten aus verschiedenen Bereichen in Domänen zusammen. Das sei noch keine Produktorganisation, bedeute aber den ersten Schritt in diese Richtung. Er hat dann Produktorganisation in kleineren Bereichen ausprobiert. Ein sehr wichtiges Learning sei gewesen, die zentrale Rolle der Product Owner zu erkennen. Sie hätten auch die anfangs kleinen Teams schützen müssen, auch ein wenig vor dem klassisch aufgestellten Management.

Die verschiedenen Projekte, um WLAN in den Zügen der Bahn bereitzustellen, hat Rattey dann ebenfalls Produkt orientiert aufgestellt. Es wurden acht Kernprodukte identifiziert zum Beispiel das WLAN selbst oder die Reservierungsanzeige. Da arbeiten Gewerke mit aus ganz unterschiedlichen Abteilungen gemeinsam. Sie haben End-to-End-Verantwortung. Doch auch das betreffe, wie die anderen Versuche, eine Zelle, damit sei bei weitem nicht der Konzern umgestellt. Rattey ist allerdings absolut überzeugt von dem Weg.

Nach den Kurzvorträgen entspann sich eine sehr lebhafte Diskussion. Hier die wichtigsten Aussagen daraus:

• Mit Produkt Orientierung sind keine internen IT-Services oder Produkte gemeint, sondern solche, die der Endkunde eines Unternehmens wahrnimmt.
• Sehr wichtig, bevor Umstellungen in Richtung Produkt Orientierung beginnen, ein gemeinsames Verständnis davon zu erzeugen, was angestrebt wird.
• Agile Methoden unterstützen Produktorientierung, weil agile Teams integriert und über verschiedene Wertschöpfunggstufen von Unternehmen hinweg reichen können.Deshalb ist agiles Arbeiten entweder Produkt orientiert oder nach BizzDevOps aufgestellt.
• Zusammenarbeit schlägt Struktur. Zusammenarbeit ist viel relevanter als die Struktur, die sich eine Organisation gibt.
• Der Product Owner spielt die zentrale Rolle, gleichgültig ob Produktorientierung sich auf die IT begrenzt oder ein Bizz-Ops-Ansatz gefahren wird.
• Product Owner können aus dem Fachbereich oder der IT kommen. Häufiger aus den Fachbereichen. Aber sie müssen in jedem Fall noch einmal eine vorbereitende Schulung durchlaufen. Persönlichkeit ist dabei wichtiger als beruflicher Hintergrund.
• Unternehmen, die auf Produktorientierung umstellen möchten, brauchen einen ausreichenden Reifegrad in der Beherrschung ihrer End-to-End-Prozesse.
• Organisatorische Mischformen sind „reinen“ Strukturformen in der Regel überlegen.
• Produktorientierung ist auch deshalb gut, weil sie Business und IT zusammenbringt, was bisher die schwierigste Schnittstelle war.