Teil 1: Moderne Projektorganisationsformen

Gartner vs. Forrester: Agil und bimodal = labil und bipolar?

Thomas Mahringer

© Shutterstock / gvictoria

Wir neigen dazu, an essenzielle Themen mit einem gewissen Dualismus heranzugehen. „0 oder 1“, „dafür oder dagegen“, „Freund oder Feind“. Agile, für die digitalisierte Welt geeignete Projektorganisationsformen eignen sich hervorragend für dualistische Debatten. Gartner befürwortet bimodal, Forrester kritisiert es. Lassen Sie uns gemeinsam hinter die Fassade der Diskussion sehen und erkunden, ob es nicht doch einen pragmatischen Mittelweg gibt.

Ausgehend von der Lean Production Taiichi Ōnos haben sich agile Prinzipien ihren Weg in die Softwareentwicklung gebahnt. Natürlich nicht als soziologische und humanistische Spielwiese, sondern aus ökonomischer Notwendigkeit heraus. Die überstrapazierten Schlagworte Disruption, Industrie4.0 und Forschungsausverkauf machen Angst, doch gleichzeitig sind die Chancen für Ingenieursstandorte wie Deutschland, Österreich und die Schweiz nach wie vor groß. Aber ohne eine drastische Anpassung von Mitarbeiterentwicklung, Prozessen und Systemen lassen sich die Spannungsfelder Geschwindigkeit– Innovation– Effizienz und Effektivität nicht mehr unter einen Hut bringen. Jedes für sich ist notwendig, aber nicht hinreichend – darüber besteht Einigkeit, über den Weg zu ihrer gemeinsamen Umsetzung hingegen ganz und gar nicht. Werfen wir zuerst einen Blick auf die Herausforderungen der digitalen Beschleunigung und Lösungsansätze, die sich mit dem Buzzword bimodal beschreiben lassen.

Artikelserie

  • Teil 1: Agil und bimodal = labil und bipolar?
  • Teil 2: Schrittweise, API-basierte Modernisierung von Bestandssystemen

Speed kills, oder: Die unterschätztesten Funktionen der Welt

Di style=“text-align: center;“e Wurzel des Übels für die treibende Geschwindigkeit von disruptiven Themen sind die am meisten unterschätzten Funktionen der Welt: Exponentialfunktionen. Bei einer Exponentialfunktion findet sich die veränderliche Größe im Exponenten. Eine Wachstumsfunktion ist beispielsweise definiert durch:
Endgröße = Ausgangsgröße * (1 + Wachstumsrate)Zeit

Viel interessanter ist oft die Frage, wie lange es dauert, bis sich etwas verdoppelt oder ver-x-facht. Das lässt sich mit einfachster Schulmathematik durch die Umkehrfunktion der Exponentialfunktion berechnen, mit dem Logarithmus zur Basis (1 + Wachstumsrate) des Faktors x:
Zeit bis zur Ver-X-Fachung = Log (1 + Wachstumsrate) x

Das bedeutet zum Beispiel bei einer Wachstumsrate von 10 Prozent eine Verdoppelung innerhalb von 7,27 Jahren oder eine Verzehnfachung innerhalb von 24,16 Jahren. Abbildung 1 zeigt ein exponentielles Wachstum mit einem Wachstumsfaktor von 10 Prozent, anhand dessen das Problem sichtbar wird: Das Wachstum schrammt zunächst asymptotisch an der Ausgangslinie, explodiert aber ab einem gewissen Zeitpunkt regelrecht. Unser Gehirn kann exponentielles Wachstum schlecht visualisieren, da es in der makroskopischen Alltagswelt selten vorkommt.

Abb. 1: Wachstum von 10 Prozent, Ausgangsmenge 1 – beginnt unscheinbar und steigt rasant

Abb. 1: Wachstum von 10 Prozent, Ausgangsmenge 1 – beginnt unscheinbar und steigt rasant

Kodak und Instagram haben etwas gemeinsam?

Im Jahr 2012 fand der prognostizierte Weltuntergang nicht statt, für einen damaligen Unternehmensriesen schien es aber doch so: Kodak hat 2012 Insolvenz angemeldet, während Instagram im gleichen Jahr von Facebook für eine Milliarde US-Dollar gekauft wurde. Der Fall ist als Musterbeispiel für Disruption bekannt geworden. Das Ironische und nicht so Bekannte dabei ist, dass Kodak 2012 noch die Patente für digitale Fotografie hielt. Was war passiert? Kodak hat in den 1970ern die digitale Fotografie erfunden und in den 1990ern eine Digitalkamera am Markt platziert. Allerdings war die Aufösung für Fotografen zu schlecht und der Preis von etwa 20.000 US-Dollar zu hoch. Das Management entschied daraufhin, dass die Technologie noch auf Jahre nicht gut genug für Fotografen wäre, und nahm sie vom Markt.

Ray Kurzweil – The Law of Accelerating returns

Ray Kurzweil ist Director of Engineering bei Google und hat viele technologische Entwicklungen immer wieder erstaunlich genau vorausgesehen. Er beschreibt digitale Beschleunigung in seinem Buch „The Singularity is Near“ so: „Informationsbasierte Technologien unterliegen einem exponentiellen Wachstum. Immer mehr Branchen, Produkte, Dienstleistungen und Technolgoien sind informationsbasiert und springen daher auf ein exponentielles Wachstum auf.“ [1].

Abgesehen von der digitalen Fotografie gibt es noch zahlreiche Beispiele für eine rasante Verbesserung des Preis-Leistungs-Verhältnisses auf Basis von IT-gestützten Prozessen [2]:

  • 3-D-Druckkosten von 2008 auf 2013 um das 400-fache
  • Kosten für Industrieroboter von 2008 auf 2013 um das 23-fache
  • Kosten für Drohnen von 2007 auf 2014 um das 10.000-fache
  • Das wohlbekannte Mooresche Gesetz: Die Anzahl der Transistoren in CPUs verdoppelt sich bei gleichleibenden Preisen alle zwei Jahre

Now every Company is a Software Company

Was bedeutet dieser IT-basierte Geschwindigkeitsfaktor für Unternehmen? Die Nutzung von IT-basierten Prozessen ist ein Schlüsselfaktor für das Mithalten in einem sich beschleunigenden Umfeld. IT-Prozesse sind schon längst zu Kernprozessen der Unternehmen geworden, entweder weil die Geschäftsprozesse digital sind ( E-Commerce, E-Procurement, digitale Kundenbeziehung, Analytics …) oder weil die Produktion von analogen Produkten digital gesteuert und automatisiert wird. Das Forbes-Magazin hat daher 2013 das vielkolportierte Zitat geprägt: „Now Every Company is a Software Company.“ [3].

Was ist in den 1990ern bei Kodak passiert? Warum wurde so eine zukunftsweisende digitale Technologie vom Markt genommen? Zwei „Naturgesetze“ wurden übersehen: Erstens Kurzweils „Law of Accelerating Returns“ und zweitens, dass sich durch die rasante Entwicklung ganz neue Anwendungsfelder, Zielgruppen und Märkte ergeben. Agile Firmen, die zuvor als „Down-Market“ nicht ernst genommen worden sind, wachsen dank dieser Naturgesetze exponentiell, sie sind exponentielle Organisationen: „An Exponential Organization is one whose impact is disproportionally large – at least 10x larger – compared to its peers because of the use of new organizational techniques that leverage accelerating technologies.“ [2].

Der Schlüssel dabei sind nicht die beschleunigenden oder disruptiven Technologien, sondern die Organisationstechniken, die diese Technologien als Hebel verwenden.

People Challenges

Das klingt logisch, stellt in der Praxis aber Nicht-Startup-Unternehmen vor Herausforderungen: Etablierte Unternehmen sind in ihren Prozessen und „Value Networks“ (Kunden, Lieferanten, Partner, Mitarbeiter) verwurzelt. Je erfolgreicher und effizienter sie sind, umso stärker ist die Verwurzelung und umso schwieriger wird es, neue Wurzeln zu schlagen. In Unternehmen entwickeln sich über die Jahre Immunsysteme: etablierte Prozesse und Mitarbeiter, die sie verinnerlicht haben. Das ist prinzipiell gut so, denn es dient der Wertschöpfung und Profitabilität. Leider wehrt sich dieses Immunsystem gegen „Eindringlinge“: radikal neue Ideen, Prozesse, Märkte und Technologien.

System Challenges

Aber nicht nur die Prozesse und Mitarbeiter können bremsend wirken, sondern oftmals die IT-Systeme selbst: Was passiert, wenn Bestandssysteme über die Jahre gewachsen sind? Der Vorteil eines umfassenden Systems (etwa ERP), das möglichst viele Unternehmensprozesse integriert, verwandelt sich schnell in einen Hemmschuh, wenn man sich aufgrund von möglichen Seiteneffekten nicht mehr traut, Prozesse marktgerecht und schnell anzupassen. Man spricht dann von technischen Schulden: Verbindlichkeiten, die in keiner Bilanz zu finden sind, aber das Unternehmen in (naher) Zukunft Geld kosten werden. Was bedeutet es beispielsweise, wenn Produktentwicklung und Marketing ein neues Produkt am Markt platzieren wollen, es aber Monate dauert, um die zugehörigen Prozesse im ERP abzubilden? Wie kann man Innovationen schnell im Gesamtablauf von der Idee bis zum Markttest treiben? Was passiert, wenn ein Bestandssystem schon so ge- oder verwachsen ist, dass ein nachhaltiges Unternehmenswachstum (Produktion, Kunden, Mitarbeiter usw.) damit gar nicht mehr abbildbar ist? Ist es vertretbar, dann zwei bis drei Jahre in die Einführung eines neuen Systems zu investieren und zu hoffen, dass es die bereits heute benötigten Prozesse gut abdeckt? Ist das eine Wette auf die Zukunft?

People Change – Die Zukunft der Arbeit

Das World Economic Forum hat in einer Studie im Jahr 2016 untersucht, wie sich die Digitalisierung auf Organisationen und Mitarbeiter auswirken wird [4]. Es wird sich nicht nur die Anzahl der Arbeitsplätze verändern, sondern disruptive Veränderungen werden die Fertigkeiten und Fähigkeiten jedes Berufs beeinflussen. Das World Economic Forum verwendet dafür den Begriff Skill Disruption: Der Job bleibt, die Skills dafür aber nicht. Welche Skills werden in naher Zukunft vorrangig benötigt? Die Antwort lautet: komplexes Problemlösen, kognitive Fähigkeiten (Flexibilität, logisches Schlussfolgern/Argumentieren), inhaltliche Fähigkeiten (aktives Lernen, mündliche und schriftliche Ausdrucksfähigkeit), soziale Fähigkeiten (Koordination, Zusammenarbeit, Verhandeln und Überzeugen, Serviceorientierung, Coaching), Prozessfähigkeiten (aktives Zuhören, kritisches Denken, sich selbst und andere monitoren), Ressourcenmanagement (Menschen, Finanzen, Material).

Kunden erwarten diese Fertigkeiten und Fähigkeiten auch immer mehr von IT-Unternehmen und -Mitarbeitern. Während vor einigen Jahren agile DevOps-Teams die Rolle von Softwarearchitekten und -entwicklern um den Bereich des Application Managements erweitert haben, geht es jetzt noch einen Schritt weiter in Richtung BizDevOps: Es genügt nicht mehr, das Handwerkszeug gut zu beherrschen. Kunden können und wollen aufgrund der hohen Veränderungsgeschwindigkeit keine umfangreichen Pflichtenhefte mehr erstellen. Der Lieferant muss stattdessen nahe am Kunden sein, Prozess-Know-how mitbringen oder sich zumindest schnell in die Prozesse hineindenken können. Er muss als Berater in die richtige Richtung führen, Beziehungen aufbauen, gut kommunizieren und organisieren. Alles andere ist Commodity und wird vorausgesetzt. Klaus Straub, CIO von BMW, erklärt, dass „… bald alle 4.500 Mitarbeiter in der BMW-Group-IT agil arbeiten – auch solche, die in den Infrastrukturbereichen beheimatet sind und selbst nichts entwickeln.“ und „… dass der agile Funke auch auf die Fachbereiche überspringt, die dann BizOps statt DevOps betreiben …“ [5].

Diese Skills lassen sich allerdings nur bedingt mit klassischen Schulungs- und Ausbildungsmaßnahmen aneignen. Es braucht viel mehr Training on the Job, Coaching und Mentoring sowie vernetztes und skalierbares Lernen innerhalb des Unternehmens und über die Organisationsgrenzen hinweg.

W-JAX 2018 Java-Dossier für Software-Architekten

Kostenlos: 40+ Seiten Java-Wissen von Experten

Sie finden Artikel zu Enterprise Java, Software-Architektur, Agilität, Java 11, Deep Learning und Docker von Experten wie Kai Tödter (Siemens), Arne Limburg (Open Knowledge), Manfred Steyer (SOFTWAREarchitekt.at) und vielen weiteren.

System Change

Parallel zum Veränderungsprozess der Mitarbeiter müssen auch die IT-Systeme agiler werden. Die oben beschriebenen technischen Schulden dürfen kein Unternehmen daran hindern, schneller zu werden. Doch wie stellt man es an, wenn Änderungen in den Bestandssystemen oft Wochen oder Monate benötigen? Ein Ansatz dafür sind Schnellbootprojekte: Überschaubare, agile und funktionsübergreifende Teams identifizieren Quick Wins und setzen sie projektartig um. Der Fokus liegt durch Design-Thinking-Methoden sehr stark auf der Kundensicht: Für welche Kunden- oder Zielgruppen ergeben sich wodurch konkrete Nutzen? Welche neuen Services oder Produkte lassen sich dadurch platzieren? Wie wirkt sich das auf die Customer Journey und die Kundenbindung aus? Da man noch gar nicht weiß, ob das Schnellboot sein Ziel erreichen wird, visiert man im ersten Schritt nur bestimmte Kundengruppen an. Anstatt den neuen Prozess mit all seinen möglichen Seiteneffekten in die Bestandssysteme zu übernehmen, wird er bewusst als Prototyp oder Minimum Viable Product (MVP) außerhalb davon umgesetzt. Das Schnellboot ist relativ gut abgegrenzt und autonom unterwegs, und man nimmt die resultierenden Nachteile bewusst in Kauf.

Es gibt Mehrgleisigkeiten: Die vom Schnellbootprozess benötigten Daten müssen gegebenenfalls über Schnittstellen bereitgestellt werden, oder man akzeptiert, dass sie für den Prototyp-/MVP-Zeitraum doppelt gepflegt werden müssen. Daneben muss man mit potenziellen Medienbrüchen rechnen: Vor- und nachgelagerte Prozesse, die im Bestandssystem bereits vorhanden sind, stehen für das Schnellboot eventuell nicht zur Verfügung. Der Übergang vom Bestandssystem zum neuen Prozess muss daher eventuell manuell oder jedenfalls mit Mehraufwand sichergestellt werden. Auf der anderen Seite ergeben sich durch den Ansatz aus Kunden-, Markt- und Organisationssicht große Vorteile:

  • Die agilen Teams erlernen die neuen Prozesse. Sie sammeln wertvolle Erfahrung, wie der Prozess entlang der Wertschöpfungskette von der Idee bis zum Kundennutzen funktioniert.
  • Fail fast: Anstatt monatelang Mutmaßungen anzustellen, wie der neue Prozess, das Produkt oder der Service angenommen werden, erhält man sofort Feedback vom Markt und kann schnell pivotieren.
  • Kostengünstiger: Auch wenn der Prozess die oben beschriebenen Nachteile verursacht, ist er in Summe durch die rechtzeitigen Kurskorrekturen deutlich günstiger.
  • Die agilen Teams tragen die neuen Prozesse schrittweise in das Unternehmen. Sie bringen dabei gleich den Beweis eines erfolgreichen Schnellboots mit statt nur einer Idee.
  • Durch die funktionsübergreifenden Teams wächst das Unternehmen zusammen, Silos werden leichter überwunden und der BizDevOps Flow wird schrittweise eingeübt.

Bimodal – Was passiert mit den alten Abläufen, Systemen und Strukturen?

Wenn innovative Themen nach der agilen Schnellbootvariante umgesetzt werden, was passiert dann mit den bestehenden Prozessen, Systemen und Mitarbeitern? In der bimodalen IT ist man sich dieses Spannungsfelds bewusst und managt es: Es gibt weiterhin die Bestandssysteme, die den IT-Backbone des Unternehmens darstellen und die wertschöpfenden Prozesse unterstützen. Sie werden als die stabile IT (reliable IT) bezeichnet. Daneben läuft eine gut gemanagte Anzahl von Schnellbootprojekten. Wenn diese erfolgreich abgeschlossen sind und bewiesen haben, dass sie am Markt erfolgreich sind, werden sie sukzessive in das Bestandssystem, die stabile IT, überführt. Damit werden sie zu etablierten Prozessen in etablierten Systemen.

Agil und Bimodal oder Labil und Bipolar? Gartner vs. Forrester

An der Grundidee der bimodalen IT scheiden sich die Geister. Auf der einen Seite stehen Befürworter wie Gartner, die die bimodale IT als Mittel sehen, in etablierten Unternehmen Prozesse zu beschleunigen, auf der anderen stehen Kritiker wie Forrester, die glauben, dass die bimodale IT nicht weit genug gehe. Ihrer Meinung nach verschleiere sie nur das eigentliche Problem, dass Unternehmen in ihren Strukturen und Prozessen zu verhaftet sind. Forrester warnt davor, dass eine bimodale IT dazu führen kann, dass unternehmensweite Change-Prozesse schlussendlich auf die IT abgeladen werden, weil es ja um „IT-Systeme“ gehe („bimodales Unternehmen“ wäre treffender als „bimodale IT“). Außerdem biete der Ansatz eine bequeme Ausrede dafür, dass Bestandssysteme mit dem Killerargument „reliable“ der Diskussion entzogen würden.

In oben zitiertem Interview berichtet der BMW-CIO beispielsweise: „Ich hatte bis September letzten Jahres auch noch eine bimodale Welt im Kopf, aber dann war das Konzept für mich nicht mehr nachvollziehbar.“ Er beschreibt, dass Mitarbeiter nicht gerne zu den langsamen gehören, während andere die hippen, modernen und innovativen Projekte umsetzen. Die einen werden frustriert und erledigen ihren Job nach Vorschrift, während die anderen enthusiastisch für neue Themen brennen.

Andererseits gibt es um Agilität viele Missverständnisse. Muss man agile Projekte nach erfolgreichem Abschluss wirklich in eine stabile IT zurückführen? Bedeuten agile Projekte und Teams automatisch „labile IT“? Nein! Denn die Definition eines Schnellboots ist ja gerade, dass es hinsichtlich Umfang und Qualität noch nicht perfekt sein muss. Es soll Beweis für die Sinnhaftigkeit und Machbarkeit sein. Das bedeutet aber nicht, dass man es nicht entsprechend professionell entwickeln, betreiben und managen kann. Große Firmen wie Amazon, Netflix und Spotify machen vor, wie hoch agile Ansätze hoch professionelle IT-Systeme und -Prozesse hervorbringen. Ausfälle würden diese Unternehmen innerhalb kurzer Zeit Millionen kosten.

Nichtdualismus und die Wahrheit der Mitte

Wer hat nun recht? Gartner oder Forrester? Wir meinen, dass man sich für keine Seite entscheiden muss, sondern dass die Wahrheit in der Mitte liegt: Wenn der Markt Unternehmen mit Innovationen und hoher Geschwindigkeit im Nacken sitzt, müssen sie rasch reagieren. Sie können nicht warten, bis alle Prozesse und IT-Systeme agilisiert sind. Andererseits ist es unrealistisch, Bestandssysteme innerhalb kurzer Zeit durch modernere Backend-Systeme abzulösen und zu hoffen, dass dadurch Prozesse schneller werden.

Wenn man die Mitarbeiter eines typischen Unternehmens betrachtet, findet man ganz unterschiedliche Persönlichkeiten, Geschwindigkeiten, Innovationswillen und Selbstorganisationsgrade. Viele fühlen sich wohl dabei, wenn sie ein bewährtes System, Lösung oder Produkt über Jahre verbessern können. Diese Mitarbeiter würden sich in einem agilen Team oder Projekt wahrscheinlich nicht pudelwohl fühlen. Mit der Koexistenz von Bestandssystemen und agilen Projekten werden wir uns also noch eine Zeit lang abfinden müssen.

Eine Zusatzoption: Serviceorientiert und API-basiert statt Reliable vs. Agile

Die Ausprägungen reliable und agil sind nicht die einzigen Herangehensweisen, man kann sich auch von beiden Seiten nähern: Während Schnellboote für kurze Time to Market sorgen, wird das Bestandssystem schrittweise service- und API-basiert modernisiert und geöffnet – nicht in einem Gießkannenansatz oder Big Bang, sondern nur für jene Funktionalitäten, die für die jeweiligen Schnellboote benötigt werden. Man schafft damit einen vertikalen „Durchstich“ von der User Experience über die Services bis hin zum Bestandssystem. Mit jedem Durchstich werden die Services iterativ erweitert und getestet. Genau darum, wie man ein Bestandssystem schrittweise und sicher modernisiert und dabei agile Schnellboote perfekt unterstützt, geht es im nächsten Artikel dieser Reihe.

Geschrieben von
Thomas Mahringer
Thomas Mahringer
ist bei DCCS im Lösungsvertrieb und in der Lösungsberatung tätig. Als gelernter Informatiker hat er bei verschiedenen, auch internationalen, Projekten Software entwickelt, Kunden beraten, Projekte und Teams geleitet, Application Performance analysiert und optimiert, Presales- und Salesstrukturen aufgebaut sowie Partnermanagementund Wissenstransferkonzepte erarbeitet. Aus dieser Erfahrung ergibt sich seine Leidenschaft, Kunden bei der effizienten Einführung von zeitgemäßen und wertschöpfenden Lösungen zu unterstützen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: