Digitale Organisation

Digitale Organisation

Richtig gestalten - nachhaltig transformieren

ca. 13 Min. Zeitbedarf

Digitale Organisation

Wer kennt es nicht? “Hurra, wir Digitalisieren!” und alles läuft begeistert los, um aus dem Alten das Neue zu machen. Aber wie soll das funktionieren? Hat sich jemand Gedanken gemacht, wie das Neue abläuft? Ist schon klar, welche Veränderungen das Neue mit sich bringen wird? Agile hin, agile her. Mal eben eine alte Organisation durch eine neue zu ersetzen ist schon schief gegangen.

Evolutionär versus revolutionär

Die Organisation als Gestaltungsperspektive kommt in der Regel zu kurz. Fast alle von uns beobachteten Vorhaben versuchen, die neuen Modelle mit oder in der bestehenden Organisation umzusetzen. Ich sehe diesen Ansatz im Regelfall als Fehler an. Bevor ich jedoch hier in die Begründung einsteige, möchte ich die Motivation differenzieren.

Neue Geschäftsmodelle mit der bestehenden Organisation umzusetzen, halte ich für einen Fehler!

Es gibt zwei Ansätze, sich dem „Neuen“ zu nähern: evolutionär oder revolutionär. Im evolutionären Ansatz wird versucht, die bestehenden Lösungen – zumeist eine IT-Landschaft mit mehr oder weniger langer Historie – für die digitale Welt umzugestalten. Im revolutionären Ansatz bleibt die Landschaft „unberührt“ und es wird das Neue daneben gestellt. Sobald sich das Neue bewiesen hat, kann das Alte migriert/angepasst/erweitert werden. (s. a. Abschnitt zur Architektur)

Neue Ansätze, insbesondere die auf Geschwindigkeit, Skalierbarkeoit und Flexibilität ausgelegten Ansätze sind stets verbunden mit Variabilität, Ungewissheit, einem hohen Maß an Experimentierfreude. Alles Eigenschaften, die eine gut geführte IT-Organisation der letzten 10 /15 Jahre mit Hilfe von Prozessen, ITIL und Quality-Gates versucht hat, zu eliminieren. Das soll keines Falls als Abwertung begriffen werden! Beide Welten sind für den jeweiligen Einsatzzweck wertvoll! Dennoch sind es gegensätzliche Zielbilder: Das Eine autoritär und zentralistisch, das Andere autonom und dezentral.

Wer seinen Job jahrelang in einer der Welten gut gemacht, die Kontrollstrukturen etabliert, diese Kultur gelebt und ins Blut übernommen hat, mag Schwierigkeiten bekommen, plötzlich die Eigenverantwortung in Teams zu fördern und dezentrales Deployment zu unterstützen.

Die Unterschiede der Produkt-IT und der Enterprise-IT (s.a. „IT der zwei Geschwindigkeiten“) sind in vielen Artikeln zu Genüge diskutiert worden. Sobald ein Geschäftsmodell maßgeblich durch IT abgebildet werden soll, ist jedenfalls – auch wenn SAP-Systeme betroffen sind – von Produkt-IT auszugehen. Daher sollten hier auch die Paradigmen Flexibilität, Geschwindigkeit und Skalierbarkeit in der Organisation reflektiert werden.

Unternehmen, die bisher keine eigene Produkt-IT unterhalten, müssen den Schritt des Aufbaus einer Produkt-IT ohnehin gehen. Dabei sollte der Fokus auf den tatsächlich differenzierenden  Fähigkeiten liegen. Wer seine Zielsetzung gut kennt, kann die differenzierenden und die zuzuliefernden Aspekte klar unterscheiden. Somit kann man sich beim Personalaufbau gezielt auf die differenzierenden Fähigkeiten fokussieren. Jeder, der heutzutage eine neue IT-Organisation aufbauen darf, sollte die sich weiterhin verschärfende Mitarbeiterknappheit vor Augen haben. Bisher sind alle mir bekannten Unternehmen, die nicht maßgeblich in Projekten organisiert sind, dabei gescheitert, in kurzer Zeit eine signifikante Anzahl neuer Entwickler anzuwerben und sie auch zeitnah wertschöpfend einzusetzen.

Der neue Architekt

Der CIO stellt begeistert den neuen Kollegen vor: Für viel Geld von einem Vorreiter des deutschen e-Commerce abgeworben, soll der neue Chef-Architekt nun den Umbau der Web-Lösung gestalten. Endlich jemand, für den Micro-Service mehr als nur ein Begriff auf Folien ist!

24 Monate später räumt der CIO entnervt seine Posten. Der Chef-Architekt hat vor 2 Monaten gekündigt, 8 der 20 neuen Entwickler ebenfalls. Das Projekt hat trotz des großen Drucks keines seiner Ziele erreicht. Wieso?!

Leider hat das moderne Konzept nicht zur bestehenden Team-Struktur und den Prozessen gepasst. Die gelebten Prozesse und die Kenntnisse stimmten nicht mit den Erfordernissen der technischen Konzepte überein, sodass Organisation und Technik sich gegenseitig behindert anstatt ergänzt haben.

Eine stimmige Organisation ist die Grundvoraussetzung für Produktivität. Je mehr Personal aufzubauen ist, desto wichtiger wird sie.

Unternehmen, die jedoch schon Software für Produkte entwickeln, wie bspw. Steuerungssoftware für Maschinen oder eigene Web-Anwendungen betreiben, haben die Qual der Wahl: Sollen die bestehenden Bereiche ausgebaut werden? Das Wissen um die ganzen Lösungen und die Entwicklungen der letzten Jahre sind ja selten expliziert genug, um sie an Dritte zu übergeben. Auch wäre es der naheliegende, organisatorische Schritt, die Weiterentwicklung in die bereits erfahrenen Hände zu legen.

Im Regelfall rate ich hiervon jedoch ab. Und das hat mehrere Gründe:

  • Risikoreduktion
  • Operative Verstrickung
  • Kompetenzproblematik
  • Denk- und Verhaltensmuster

Zum einen verdient das Unternehmen derzeit vermutlich mit dem jetzt verfügbaren Modell sein Geld. Das bedeutet im Regelfall, dass die Ressourcen, die sich mit der Entwicklung beschäftigen, in dem bestehenden Geschäft eingebunden sind. Es gibt auch hier Entwicklungen, neue Feature-Requests, Kunden, die Unterstützung oder Sonderlösungen benötigen. Jede Schwächung dieser Möglichkeiten ist auch eine Schwächung der gegenwärtigen Wettbewerbsposition. Gerade in mittelständischen Unternehmen sind Kundennähe und Anpassungsfähigkeit oft wichtige Differenzierungsmerkmale. Es ist demnach gut zu prüfen, welchen Einfluss eine Reduktion dieser Kompetenz auf das Geschäft, den Cash-Flow und die Kundenbeziehungen haben wird.

Auch ist darauf zu achten, dass eine operative Verstrickung der Ressourcen, die sich um die Zukunft bemühen sollen, nicht ungefährlich ist. Zu Beginn des Aufbaus unserer AWS-Service-Tochter haben wir das „nebenbei“ mitgemacht. Das war nicht immer einfach. Wenn auf der einen Seite ein Server stillsteht oder ein neues Gateway nicht so will, wie es soll, und gleichzeitig auf der anderen eine strategische Richtungsentscheidung drängt. Es erfordert außerordentliche Disziplin und Fokus, hierbei die langfristigen Aspekte nicht aus den Augen zu verlieren.

Beispiel aus der Landmaschinentechnik

Einer unserer Kunden bietet Maschinen im Wert von 20-300 TEUR an. Die Vertriebsstrukturen sind darauf ausgelegt; Händlernetze, Vertriebsprozess und -provisionen hängen an diesen Volumina. Die Vertriebler gehen zu dem Kunden und überzeugen ihn in mehreren persönlichen Gesprächen von den Vorteilen. 

Die Einführung eines Subskriptions-Modells mit hoher Bindungswirkung ist geeignet, bei hinreichender Verbreitung auch mit wenigen EUR pro Monat einen soliden und nachhaltigen Cash flow zu generieren. Dennoch fand der Service keine Beachtung in der bestehenden Vertriebsstruktur, da die Belohnung des Verkäufers beim Abschluss einer Subskription in keiner Relation zu der beim Verkauf einer Maschine stand. 

Um in dieser Situation dennoch das bestehende Vertriebsnetz zu aktivieren, ist eine auf die Laufzeit der Subskription bezogene Belohnungsstruktur einzuführen oder ein ergänzender Vertriebsweg zu wählen. Wir haben in diesem Kontext die bestehenden Relationen nur als Markenbotschafter genutzt, um Nutzungsgutscheine zu verteilen und eine direkte Abschlussmöglichkeit gewählt.

Hinzu kommt der nicht zu unterschätzende Kompetenz-Aspekt. Neue Anforderungen und Ziele erfordern oft neue Konzepte und neue Technologien. Wer mit einem Sack voll Altlasten und operativem Druck im Nacken schnell etwas liefern soll, versucht zumeist Vorhandenes anzupassen bzw. umzubauen. Wir bezeichnen dies gerne als den MacGyver-Effekt. Die Leistung dieser MacGyvers ist zumeist beachtlich; ob hinreichend Raum für Erfahrungen mit neuen Technologien existiert, bleibt dahingestellt. Ist dafür kein Raum im Arbeitsplan vorgesehen, existiert er vermutlich nicht.

Weiterhin gibt es Gründe, dass das Alte so ist, wie es ist. Oft sind es unzureichende Budgets, Zeitdruck und ehemals erzwungene oder übriggebliebene Kompatibilitätsanforderungen, die zu suboptimalen Implementierungen und Architekturen geführt haben. Oft leben diese Beschränkungen in den Köpfen ihrer Erzeuger weiter. Ein befreites, nur auf den Kunden bzw. die Lösung fokussiertes Arbeiten ist nicht für jeden eine beherrschbare Herausforderung.

Das Gleiche gilt auf der Vertriebsseite für bestehende Belohnungsstrukturen. Wer darauf gepolt ist, wenige Transaktionen mit großen Volumina abzuschließen, nutzt vollkommen andere Strukturen und Mechanismen als jemand, der viele kleine Abschlüsse erzeugen soll. Da die meisten digitalen Geschäftsmodelle eine Verschiebung von Anschaffungskosten in laufende, nutzerbezogene Kosten mit sich bringen, sind die Vertriebswege anzupassen.

Wir nutzen in unseren Projekten, wann immer es sich einrichten lässt, Entwickler der Vorgänger-Lösungen im Bereich des Anforderungsmanagements der neuen Lösung. Sie bringen viel un-dokumentiertes Fachwissen mit, das auf diesem Weg Eingang finden kann. Allerdings passiert es regelmäßig, dass beim Hinterfragen der Anforderungen alte Rahmenbedingungen auftauchen, die unnötige Komplexität produzieren. Es ist also Vorsicht geboten und eine Reflexion durch weniger eingefleischte Kollegen durchaus wichtig und erstrebenswert.

Konkurrenz belebt das Geschäft – Das gilt auch für Organisationsformen

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.

DEV-OPS vs. ITIL - Rollen frühzeitig klären

Diese Fragen sind recht umfassend, greifen in Arbeitsverträge ein und erfordern eine klare Zielsetzung. Ob ein Team eigenverantwortlich den von ihm entwickelten Service betreut (DEV-OPS-Philosophie) oder ihn nach Bereitstellung an ein Operations-Team übergibt (ITIL-Philosophie) erfordert sehr grundlegende Entscheidungen. Wir empfehlen daher, diese frühzeitig und mit Bedacht zu treffen.

Entscheidungen über die Organisation des Betriebes sollten möglichst frühzeitig getroffen werden, da sie erheblichen Einfluss auf die Leistungserstellung haben.

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.

Product Owner Rolle nachhaltig implementieren

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.

Um die Vorteile des agilen Konzeptes voll zu erschließen, trägt im Idealfall der Product Owner die Ergebnis-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.

Um dieses Dilemma zu überwinden, haben wir auf Basis von Maliks lebensfähigem System (x) eine Organisationsstruktur geschaffen, die mit Hilfe eines „Backlog-Prio-Boards“ einen Rahmen zur Verfügung stellt, um die mittel- und langfristigen Ziele und Prioritäten zu klären. Hier sitzt der Visionär mit seinen POs, den Architekten und den Lieferverantwortlichen.

Gestaltung Backlog-Prio-Board als Heilmittel einer unheilbaren organisatorischen Dysfunktion (Projektbeispiel)

In diesem Rahmen ließ sich die Produktvision hinreichend konkretisieren und die erforderlichen Teilschritte abstimmen.  Das Forum ermöglichte zudem den „Product Ownern“, bzw. „Product Proxies“ ausreichend Gewissheit über die als nächstes zu fokussierenden Teilziele. Zudem entstand ein Forum, welches auch durch frühzeitige Abstimmung mit dem eigentlichen Visionär nebenbei den Software-Produktionsprozess vor plötzlichen Prioritätswechseln geschützt hat.

Leider ist es oft noch so, dass Organisation nur als Organigramm mit “Reporting”-Linien begriffen wird. Hilfreicher wäre ein Verständnis als Struktur, deren Elemente  Stellen und Rollen) die Prozesse reibungsfrei abbilden und zur gewünschten Leistung führen.

Diese Struktur so auszurichten bzw. anzupassen, dass sie eine performante Leistungserbringung fördert, bleibt im Digital-Transformation-Kontext eine wichtige Gestaltungsaufgabe. Die bisherigen Strukturen folgen ja anderen Prinzipien da sie auf die bisherigen Wirkmechanismen ausgerichtet wurden. Und genau die ändern sich ja. Es wäre also überraschend, wenn die vorherigen auch im neuen Kontext noch geeignet wären.

Scrum und Agile sind exzellente Methoden bzw. Konzepte, um eine sich stetig verbessernde Software-Produktionsfunktion zu etablieren. Aber sie sind nur einzelne Aspekte einer funktionierenden Organisation. Performant wird ein Organisation nur, wenn auch die Rahmenbedingungen stimmen. Der Rolle des Product Owners kommt in dieser Konstruktion eine Schlüsselrolle zu. Sie ist aus unserer Sicht so extrem relevant für den Erfolg einer jeden Digitalen Initiative, dass wir ihr sogar ein eigenes Kapitel widmen werden.

Ist Ihre Digitale Transformation bereits im Gange? Sind Sie sicher, auf dem richtigen Weg zu sein? Das richtige Modell zu verfolgen?

Externe als Chance begreifen

Letztendlich ist abschließend noch eine Lanze für unsere Zunft zu brechen. Die Nachfrage im Bereich IT-Fachkräfte wird bereits seit einigen Jahren nicht mehr hinreichend gedeckt. Von den derzeit in Deutschland knapp 950.000 Fachkräften im Bereich SW und SW-Services ist aufgrund der demographischen Entwicklung von einer wachsenden Unterdeckung auszugehen. Gegenwärtig wächst die Nachfrage recht stabil um jährlich gut 5 Prozent (Bitkom Referenz). Das sind gut 50.000 Fachkräfte pro Jahr. Auch scheiden jedes Jahr ca. 3 bis 4 Prozent der Workforce, also gut 30.000 Köpfe, altersbedingt aus. Gleichzeitig schließen aber nur gut 26.000 Studierende ein Informatikstudium ab. Demnach wächst die Lücke in den kommenden 5 Jahren um gut 55.000 Köpfe jährlich.

Hinzu kommt, dass es andere Qualifikationen erfordert, eine Organisation im laufenden Geschäft zu leiten, als eine Organisation auf Touren zu bringen und in neue, unbekannte Fahrwasser zu lenken. Das bedeutet, nicht jeder schon in der Industrie befindliche Recke eignet sich für jede Aufgabe. An dieser Stelle sei noch einmal auf das SFIA verwiesen. Wir empfehlen dringend, die Stellen zunächst zu beschreiben und sie auch mit wirklich geeigneten Kandidaten zu besetzen. 

Personalentwicklung Deutschland (IT Fachkräfte)

Personalentwicklung Software und SW-Services, Deutschland.
Quellen: Bitkom, Statistisches Bundesamt, EACG Research

Der Schaden, den eine Unterdeckung mit Qualifikationen nach sich zieht, ist nicht zu unterschätzen. Umfasst ein Team, welches sich mit den neuen Ideen beschäftigen soll, 20 Köpfe, entspricht dies in einem Quartal 1.200 Arbeitstagen (gut 6 FTEs), oder in EUR – je nach Verrechnungssatz – zwischen 0,5 und 1 Mil. EUR. Diese Investition ist zu hoch, als dass man sie nicht fokussiert ausrichten, bzw. einige Monate ineffizient herumdümpeln lassen sollte. Es ist daher empfehlenswert, bestehende Lücken zeitnah, auch interimistisch, mit geeigneten Externen zu besetzen, um das Invest zu schützen.

Weitere Artikel

Dies ist der erste einer Reihe von Artikeln, die sich mit unterschiedlichen Aspekten der Digitalen Transformation und ihrer Umsetzung beschäftigen. Weitere Aspekte werden die Kultur, die Organisation, die Finanzierung sowie die technischen Aspekte darstellen. Sie erscheinen in den kommenden Wochen im gleichen Format. Registrieren Sie sich für unseren Newsletter, wenn Sie keinen Artikel verpassen möchten.