Wer dem Neuen eine reale Chance geben will, der sollte sich zutrauen, es mit dem Alten in Konkurrenz zu setzen. Konkurrenz belebt das Geschäft. Zum einen wird es die Motivation des Alten erhöhen, sich zu ändern. Zum anderen erhöht es den Druck auf das Neue, Resultate zu zeigen und sich nicht in Technik zu ergehen.

Ein weiterer Vorteil ist dabei auch die Geschwindigkeit. Neue, kleine Bereiche, idealerweise mit eigenen Budgets und Beschaffungshoheit, haben wesentlich weniger Abstimmungskosten und daher die Möglichkeit, sich schneller zu bewegen. Wie oft beschaffen wir für unsere Kunden Dienste, Personal oder Lösungen, damit sie schnell verfügbar sind? In Gesamtsicht ist das für das das Unternehmen in der Regel erheblich kostengünstiger, als eine durch den zentralen Einkauf prozessierte Bestellung.

In einem unbekanntem Terrain – wie einem neuen Geschäftsmodell – ist es nicht ungewöhnlich, dass auch ungeplante Ausgaben auftreten können. Steht das Unterfangen in einem eigenen, entkoppelten Kontext, sind viele sinnvolle Policies vernachlässigbar, da das Kerngeschäft keine Nebeneffekte erleidet. Alles Vorteile, die ein evolutionärer Ansatz nicht nutzen kann.

Die ggf. erforderliche Integration mit den Bestandssystemen kann als Anforderung an die neuen Lösungen übergeben werden. Aber auch erst dann, wenn sie sich bewiesen hat!

Egal welcher Ansatz – evolutionär oder revolutionär – gewählt wird: die Aufbauorganisation sollte rechtzeitig geklärt sein. Dabei geht es weniger um die Anzahl Fenster oder Schreibtischlänge, die mit einer Position verbunden sind, als um die Verantwortlichkeiten. Nichts bringt eine Operation mehr zum stottern, als ungeklärte Verantwortlichkeiten. 

Leider findet sich gerade in der IT jedoch immer wieder ein heilloses Verantwortungs-Nirwana. Wer ist verantwortlich für die Infrastruktur, wer für den Betrieb? Wie werden Fehler eskaliert? Wer hat bis wann für welche Dienste zu sorgen? Wer muss sie bereitstellen?

Sehr oft sind diese Fragen ungeklärt, wenn die Produkt-IT in F&E-Bereichen verankert ist. Bisher wurde dort eine Software für die Maschine produziert. Diese ist irgendwann fertig und geht mit der Maschine ins Feld. Und tschüß, nächstes Thema!

In einem Web- oder Mobile-Kontext ist damit jedoch nicht Schluss. Die Entwicklung geht weiter,  Aktualisierungen werden durch Updates der zugrundeliegenden Plattform (Betriebssystem) erforderlich. Neue Features sollen umgesetzt und nachgereicht werden. Das benötigt eine kontinuierliche Betreuung und operative Begleitung; ein Projekt ohne Ende.

Diese Umstellung ist keine leichte Aufgabe. Sie wird um so schwieriger, je mehr neue Kollegen mit unterschiedlichen Erfahrungen zusammenkommen und plötzlich versuchen, ihr Erfahrungsbild durchzusetzen. Da kollidieren positive und negative Erfahrungshorizonte mit ITIL und DEV-OPS-Konzepten. Fans autonomer Service-Designs beginnen sich mit Freunden des frühen Feierabends über die Verantwortlichkeiten im Betrieb zu streiten und plötzlich ist die Arbeitnehmervertretung auf dem Plan, weil die elf Stunden Ruhephase durch die erforderlichen Bereitschaftszeiten gefährdet sind.

Dabei gibt es keine Empfehlung für eine spezifische, zu bevorzugenede Richtung. Es muss vor allem auf die Gegebenheiten der verfügbaren bzw. zu gestaltenden Organisation passen. Persönlich habe ich eine Präferenz für die Eigenverantwortlichkeit der DEV-OPS-Konzepte. Regulatorische oder Risiko-Management-Anforderungen können diese jedoch auch so aufwändig werden lassen, dass sie schlicht nicht wirtschaftlich umsetzbar sind, da beispielsweise der Trainingsaufwand zu hoch wird. Auch Mischformen sind denkbar. Jedoch benötigen gerade diese eine klärende Erläuterung / Dokumentation, da sonst die operative Verwirrung mit Sicherheit folgt.

Um bei der Gestaltung der Rollen nicht im leeren Raum zu starten, empfehlen wir das Skill-Framework der SFIA Foundation. In diesem Framework sind nicht nur typische Rollenbilder definiert, sondern auch unterschiedliche Erfahrungsstufe für einzelne Aufgabenbereiche abgeleitet. Das Framework liegt mehrsprachig vor und es ist für den Einsatz in Unternehmen entwickelt. Als Ausgangspunkt für die Konzeption der eigenen Organisation halte ich es für ausgesprochen geeignet und ziehe es immer wieder gerne zu Rate.

Ein weiterer Schlüssel-Aspekt der Organisationsgestaltung ist die Rolle des Anforderungsgebers. Die agilen Konzepte kennen hier das Konzept des Product Owners (PO), der als Produkt- oder Service-Verantwortlicher die Spezifikation abgibt und die Umsetzung abnimmt. Dieses Principal-Agenten-Konzept krankt jedoch in unserer wirtschaftlichen Praxis zu oft an mangelnder Ermächtigung der Rolle. Um die Vorteile der Konzeptes voll zu erschließen, steht der jeweilige PO im Idealfall in der Profit- & Loss-Verantwortung für sein Produkt.

Zu oft wird die Product Owner-Rolle im agilen Prozess zwar an eine Person übertragen, jedoch ohne sie mit den erforderlichen Entscheidungsbefugnissen auszustatten. Zentrale Aufgabe sollte es sein, die Produktinkremente und damit die schrittweise Umsetzung der Produktvision zu definieren. Sobald die Rolle nur durch einen Vertreter des eigentlich Verantwortlichen ausgeübt wird, ist die Wahrscheinlichkeit groß, dass die Abnahmen nicht Hand-in-Hand mit der Produktvision gehen, fachlich weitere Schleifen erforderlich werden oder das erste marktfähige Produkt (Minimum Viable Product= MVP) mächtiger als notwendig wird.

Es mag diverse Gründe (Budget-Prozess, Vertrauen, Kompetenzen etc.) geben, weshalb sich das kurzfristig nicht so umsetzen lässt. Dann wird es wichtig, hinreichende Ersatz und Kontroll-Mechanismen zu schaffen, um den Wirkmechanismus zu erhalten, bzw. ihm nahezukommen. 

Beispielsweise hatten wir bei einem unserer Kunden, einem mittelständischen Hersteller von Messtechnik, die Herausforderung, dass die Produktverantwortung unteilbar in den Händen des Eigentümers lag. Das Produktmarketing wurde durch ein junges Team möglicher Nachwuchstalente gestemmt. Das ist ein gutes Konzept, um junge Leute in der Firma zu entwickeln. Es steht jedoch im Gegensatz zu dem erfahrenen, eigenverantwortlichen Product Owner eines Software-Produktes. Weder verfügen die jungen Leute über die jeweilige Branchenerfahrung, um die Nutzerperspektive des Kunden einnehmen zu können, noch über das Standing und die Entscheidungsgewalt, Priorisierungen über die Produkteigenschaften zu treffen. Gleichzeitig hat der Eigentümer aber zu viele Themen auf dem Tisch, um in jeder Scrum-Iteration seine Produktvision zu vertreten.