hamburger-customhamburger-custom-close
custom-cover-arrow

Das Moral Hazard-Problem

Die Nichtberücksichtigung nachhaltiger Softwareentwicklung und die gefährlichen folgen für Unternehmen:
Das Moral Hazard-Problem

In meinen Beiträgen zum Prozessgesteuerten Ansatz betone ich stets die Bedeutung nachhaltiger Prozessdigitalisierung, so auch in meinem Artikel über die Motivation für den Prozessgesteuerten Ansatz. Aber was ist konkret mit Nachhaltigkeit bei der Prozessdigitalisierung oder in der Softwareentwicklung allgemein gemeint und warum spielt sie eine so wichtige Rolle? Diesen Fragen möchte ich mich in diesem Beitrag widmen.

Das Thema Nachhaltigkeit in der Softwareentwicklung begleitete mich mein gesamtes berufliches Leben hindurch. Leider musste ich selbst nur allzu oft schlecht entwickelte Software pflegen, habe mich geärgert über Programme, die niemand mehr durchblickte und wo jede Änderung zu einem reinen Glücksspiel ausartete. Ganz zu schweigen von der Zeit und den damit verbundenen Kosten, die es das Unternehmen letztlich kostete, um das Chaos zu durchdringen und schlussendlich zu beseitigen. Diesbezüglich bin ich ein gebranntes Kind. Ich weiß daher den Wert qualitativ hochwertiger Softwareentwicklung sehr zu schätzen und Unternehmen tun gut daran, dessen Bedeutung nicht zu unterschätzen. Auf meiner Homepage unter www.volkerstiehl.de habe ich meine eigene Vorstellung nachhaltiger Softwareentwicklung bereits kurz angerissen. Diese Vorstellung lässt sich mit den drei Begriffen Effizienz, Transparenz und Flexibilität treffend zusammenfassen. 

Dabei ist es mir wichtig, dass Software:

  • zeiteffizient zu entwickeln
  • leicht zu erweitern und anzupassen
  • leicht zu warten
  • leicht zu betreiben
  • leicht an sich ändernde Marktgegebenheiten anzupassen
  • leicht an sich ändernde IT-Systeme, die von den Lösungen genutzt werden, anzupassen
  • transparent (im Sinne von: Sie sehen, was passiert)

ist. Diese Anforderungen erfüllen beispielsweise Softwaresysteme, die nach dem Prozessgesteuerten Ansatz entwickelt werden und die mich seinerzeit auch zur Entwicklung des Prozessgesteuerten Ansatzes veranlasst hatten (Details zu meiner Motivation für den Prozessgesteuerten Ansatz finden Sie hier).

Beobachtet man allerdings aktuelle Trends in der Softwareentwicklung und dem Einsatz von Software in Unternehmen ganz allgemein, so kann man sich des Eindrucks nicht erwehren, dass sämtliche guten Vorsätze über Bord gespült, ja geradezu mit den Füßen getreten werden. Es lohnt sich also, mal genauer hinzusehen und die Auswirkungen bestimmter Entwicklungsmoden hinsichtlich Nachhaltigkeit zu untersuchen. Außerdem gehe ich der Frage nach, warum es zu einer qualitativ schlechteren Softwareentwicklung kommt und warum trotz besseren Wissens nichts unternommen wird. Zur Verdeutlichung meiner Argumente werde ich u.a. die aktuell stark gehypte Technologie Robotic Process Automation (RPA) heranziehen. Zunächst möchte ich aber auf das Moral Hazard-Problem eingehen, ehe ich dann RPA auf Basis dieses Problems hinsichtlich dessen Nachhaltigkeit analysiere. Legen wir also los.

Moral Hazard (Moralisches Risiko, Verhaltensrisiko)
Ausgangspunkt und Motivation für diesen Artikel ist ein Video von Prof. Christian Rieck und seinen Ausführungen zu den Zusammenhängen zwischen Nachhaltigkeit und Spieltheorie. Die wesentlichen Aussagen dieses Videos möchte ich im Folgenden zusammenfassen.

In besagtem Video untersucht Prof. Rieck, wieso Menschen dazu neigen, eben nicht nachhaltig zu handeln. Der Grund dafür liegt in dem Problem des Moral Hazards, das ich nun anhand des im Video genutzten Beispiels eines Försters, der für die Bewirtschaftung eines Waldstücks verantwortlich ist, verdeutlichen möchte.

Ursprünglich stammt der Begriff der Nachhaltigkeit aus der Forstwirtschaft. In diesem Kontext bedeutet Nachhaltigkeit, in einem Waldstück nicht mehr Bäume pro Jahr abzuholzen, als in eben diesem Jahr dort nachwächst. Das Problem bei einem Waldstück besteht nun darin, dass der Förster nicht weiß, wie viele Bäume er pro Jahr eigentlich schlagen darf, da zwischen dem Pflanzen der Bäume und deren späteren Abholzung (und damit das Einfahren des Ertrages) ein großer Zeitraum besteht. Der Zusammenhang zwischen Ursache und Wirkung, also zwischen dem, was gewachsen ist und was man dafür getan hat und dem, was man bekommt, wenn man es abholzt, ist aufgrund des großen zeitlichen Abstands nicht mehr offensichtlich. Prof. Rieck führt aus, dass genau dieser große zeitliche Abstand zu Problemen führt, da in letzter Konsequenz Verhaltensanreize gesetzt werden, die nicht nachhaltig sind!

Woran liegt das? Dazu muss man sich lediglich vergegenwärtigen, wie der für das Waldstück verantwortliche Förster Geld verdient. Er verdient sein Geld letztendlich mit dem Verkauf der geschlagenen Bäume. Versetzt man sich in die Lage des Försters, so kann er jedes Jahr aufs Neue entscheiden, ob er viel oder wenig abholzt. Schlägt er viel Holz, verdient er entsprechend viel Geld, schlägt er wenig Holz, verdient er weniger. Erschwerend kommt hinzu, dass niemand weiß, wie viel Holz in einem Jahr nachgewachsen ist. Gemäß obiger Regel (nicht mehr Bäume abholzen als nachgewachsen sind) ist aber genau dieses Wissen notwendig, um eine nachhaltige Entscheidung treffen zu können. Diese Unkenntnis öffnet unserem Förster natürlich Tür und Tor, die nachgewachsene Holzmenge einfach ein weniger höher zu schätzen, um auf diese Weise das Schlagen einer größeren Holzmenge verargumentieren zu können. Das Gemeine daran: Ein Außenstehender kann das Handeln des Försters noch viel weniger beurteilen als der Förster selbst. Ja, der Förster selbst weiß ja noch nicht einmal, wo die Grenze zwischen nachhaltig und nicht nachhaltig genau liegt. Die Grenze ist also unscharf.

Genau diese Ausgangssituation ist in der Spieltheorie, so Prof. Rieck, unter Moral Hazard (moralisches Risiko, Verhaltensrisiko) zu verstehen. Ein Handelnder ist bei dem Moral Hazard in einer moralischen Zwickmühle. Auf das Beispiel unseres Försters bezogen kann dieser jetzt so viel abholzen, wie er will und niemand merkt, dass er falsch gehandelt hat. Ja selbst wenn er wenig abholzt und dementsprechend weniger Geld bekommt, kann niemand sein Handeln hinsichtlich richtig oder falsch beurteilen.

Wie wird der Förster bei dieser Ausgangslage wohl handeln? Da ohnehin niemand beurteilen kann, ob er im Sinne der obigen Regel richtig oder falsch handelt, wird er wohl ein wenig mehr abholzen und auf diese Weise mehr Geld bekommen. Dieses Verhalten wird er nun Jahr für Jahr wiederholen, ohne das vorerst irgendwas (Negatives) passiert oder er Konsequenzen spürt. Er überholzt also seinen Wald regelmäßig mit der Konsequenz, dass der Wald über einen relativ langen Zeitraum ausdünnt. Offensichtlich handelt er eben nicht nachhaltig, mit dem Ergebnis eines über die Zeit noch größer werdenden Problems des abgewirtschafteten Waldes.

Das Gemeine daran: Das Ergebnis wird erst nach einer sehr langen Zeit sichtbar (zwischen Ursache und Wirkung liegt eine große Zeitspanne) und der Förster, der den Zustand eigentlich zu verursachen hat, wird wahrscheinlich dann in Rente sein oder nicht mehr leben. Noch Schlimmer: Der Förster, der diesen schlimmen Zustand verursachte, stand die ganze Zeit über gut dar, wurde für seine herausragende Bewirtschaftung des Waldes wahrscheinlich auch noch übermäßig gelobt. Der Nachfolger hingegen, der den Wald übernimmt, steht vor einem Trümmerhaufen und es wird ihm zugerechnet, dass sich der Wald jetzt in diesem schlimmen ausgedünnten Zustand befindet.

Was können wir aus diesem Beispiel lernen? Es zeigt sich letztendlich, dass bei langfristigen Entwicklungen ein ganz starker Hang dazu besteht, nicht nachhaltig zu arbeiten!

Wie formuliert es Prof. Rieck in seinem Video so schön: Man kann etwas machen, was von anderen nicht beurteilt werden kann und man macht dann natürlich das, was für einen selbst gut ist und nicht das, was für andere gut ist! Man handelt also nicht nachhaltig.

Soweit die Zusammenfassung der wesentlichen Aussagen des sehr sehenswerten Videos von Prof. Rieck.

Moral Hazard und Robotic Process Automation
Dieses soeben geschilderte Szenario lässt sich nun treffend auf aktuelle Trends in der Softwareentwicklung übertragen. Ich ziehe zur Verdeutlichung zunächst das Beispiel Robotic Process Automation (RPA) heran. RPA ist aktuell in aller Munde. In der aktuellsten Ausgabe der Zeitschrift „Anwendungen und Konzepte der Wirtschaftsinformatik“ (kurz AKWI, Ausgabe Nr. 13 vom 23. Juli 2021) beispielsweise wird der „gestiegenen Relevanz“ (so die Formulierung im Editorial der Ausgabe) von RPA gleich mit drei Artikeln Rechnung getragen. Unternehmen mit RPA-Lösungen sprießen wie Pilze aus dem Boden und kein Wirtschafts-Podcast kommt umhin, Aktien von RPA-Anbietern für den Vermögensaufbau zu empfehlen. Ja, sogar für ein sogenanntes Konfirmations-Portfolio, das eigentlich langfristig ausgerichtet sein sollte, werden derartige Aktien empfohlen (siehe Deffner & Zschäpitz-Podcast, Folge 171, Minute 24:22). Da frage ich mich schon, ob die Technologie wirklich verstanden wurde bzw. wie so fragwürdige Empfehlungen überhaupt zustande kommen. Denn ein Langfristinvestment sind Aktien von RPA-Anbietern sicherlich nicht. Die Begründung für das Investment kommt in dem Podcast dann auch entsprechend schwammig daher und basiert eher auf einer mehr oder minder verstandenen Menge von Buzzwords und dem Prinzip Hoffnung.

Von daher scheint es angebracht, einen kurzen Blick auf die Technologie zu werfen. Denn im Grunde verbirgt sich hinter der Bezeichnung „Robotic Process Automation“ lediglich eine Software zum Ausfüllen von Bildschirmmasken. Eingaben, die sonst vom Menschen erfolgen, übernimmt jetzt ein Stück Software. Das ist im Grunde das ganze Geheimnis. Nicht sonderlich weltbewegend und in der Softwarebranche schon seit Jahrzehnten bekannt, aber jetzt im Zuge der Prozessautomatisierung natürlich ein schlagendes Argument, diese Software in großem Stil in Unternehmen einzuführen.

Die Argumentation der Befürworter verläuft dabei immer gleich: langweilige repetitive, teilweise stupide Arbeiten übernimmt der Softwareroboter, er entlastet den Menschen, der, von verhassten langweiligen Tätigkeiten befreit, jetzt mehr Raum für die wirklich wichtigen Arbeiten bekommt. Schauen Sie sich dazu beispielsweise nur mal das Werbefilmchen der Firma UiPath zur Erklärung von RPA auf YouTube an und Sie verstehen, was ich meine. Softwareroboter arbeiten sieben Tage die Woche rund um die Uhr bei höherer Zuverlässigkeit mit weit geringerer Fehlerrate, werden nicht krank und benötigen keine Kaffeepause. Ein Anwendungsfall ist schnell durchgerechnet. Dazu wählt man einen Prozess des Unternehmens aus, der möglichst häufig pro Tag durchlaufen wird und der menschliche Interaktionsschritte enthält. Nun setzt man anstelle des Menschen den Softwareroboter ein und rechnet hoch, wie viel der Roboter im Vergleich zum Menschen leistet. Durch die Multiplikation mit der großen Anzahl an Prozessinstanzen pro Tag und den o.g. Eigenschaften der Verfügbarkeit rund um die Uhr lässt sich der Einsatz von RPA sehr schnell schönrechnen. Lässt der Befürworter des RPA-Einsatzes dann auch noch Schlagwörter (Buzzwords) wie „Künstliche Intelligenz“, die einige RPA-Lösungen zum Trainieren des Roboters nutzen, „Automatisierung“, „Roboter“ und „Prozessdigitalisierung“ fallen, ist das Budget für die Anschaffung der RPA-Software und die Schulung der Mitarbeiter beim Management schon so gut wie bewilligt. Schließlich ist man bei den wichtigen Themen der Digitalisierung, Automatisierung und sogar künstlicher Intelligenz dabei. Und das alles nur durch den Einsatz einer einzigen Lösung. Grandios!

Die RPA-Software wird folglich beschafft, eingesetzt, das Unternehmen spart womöglich die angepeilten Kosten, die Qualität der Datenversorgung steigt, die Fehlerquote sinkt, die Prozessdurchlaufzeiten reduzieren sich, alle sind glücklich und der Projektverantwortliche wird ob seines wertvollen Beitrags für das Unternehmen und seines Projekterfolgs auf eine noch verantwortungsvollere Stelle befördert.

So weit, so gut, könnte man meinen. Und wo ist da jetzt der Pferdefuß? Nun ja, Sie ahnen es schon. Es hat etwas mit der Nachhaltigkeit und dem Moral Hazard zu tun. Denn durch jeden Einsatz von RPA laden sich Unternehmen gewaltige technische Schulden auf, die, wie könnte es anders sein, nicht sofort sichtbar werden, sondern sich erst nach relativ langer Zeit offenbaren. Dann aber umso desaströser! Laut Wikipedia sind technische Schulden „eine in der Informatik gebräuchliche Metapher für die möglichen Konsequenzen schlechter technischer Umsetzung von Software. Unter der technischen Schuld versteht man den zusätzlichen Aufwand, den man für Änderungen und Erweiterungen an schlecht geschriebener Software im Vergleich zu gut geschriebener Software einplanen muss.“

Warum lädt sich ein Unternehmen durch den Einsatz von RPA überhaupt technische Schulden auf und warum ist der Einsatz von RPA nur mit höchster Vorsicht zu genießen? Weil RPA auf der schwächsten und fragilsten Schnittstelle zu einem System aufbaut, die es überhaupt gibt: Den Bildschirmmasken oder User Interfaces! Wenn sich etwas in einem System am häufigsten und grundlegendsten ändert, dann sind es seine Bildschirmmasken, über die das System mit Daten versorgt wird. Ändert sich die Bildschirmmaske, so funktionieren leider all die schönen Regelwerke und Skripte, die den Softwareroboter letztendlich steuern, nicht mehr. Denn die Regelwerke und Skripte sind ja auf die alten Bildschirmmasken ausgelegt und können bei einer neuen Version des zugrundeliegenden Systems, das derart über Bildschirmmasken befüllt wird, ihre Arbeit nicht mehr korrekt verrichten. Neue Felder werden beispielsweise nicht gefüllt oder der Roboter versucht Felder zu füllen, die es auf der Maske nicht mehr gibt. Die Felder wurden vielleicht auf eine andere Maske verschoben oder sind generell nicht mehr notwendig, da sie durch andere Felder ersetzt wurden. Derartige Umgestaltungen an Masken sind nicht etwa die Ausnahme, sondern die Regel. Sie finden ständig statt und sei es „nur“ aus Gründen besserer Nutzbarkeit (Stichwort: Usability erhöhen). Und je mehr Systeme über Softwareroboter derart bedient werden, umso höher ist das Risiko für das Unternehmen, dass wichtige Prozesse zusammenbrechen. Aber das wird der Verantwortliche, der dieses Desaster dann eigentlich zu verantworten hat, wahrscheinlich nicht mehr ausbaden müssen, da er längst wegbefördert wurde oder bereits zu einem anderen Unternehmen gewechselt ist.

Sie erkennen wahrscheinlich sehr schön die Parallelen zu obigen Moral Hazard-Beispiel mit unserem Förster. Der für die RPA-Einführung verantwortliche Projektleiter ist unser Förster. Da niemand die langfristigen Folgen des RPA-Einsatzes überschaut bzw. versteht, kann er bedenkenlos einen Roboter nach dem anderen installieren. Der kurzfristige Erfolg gibt ihm recht, denn die aufgebauten technischen Schulden sind zunächst nicht sichtbar. Erst nach vergleichsweise langer Zeit wird die ganze Breite des Problems offensichtlich. Doch dann wird der Verursacher nicht mehr greifbar sein. Der Projektverantwortliche handelte nach unserer oben gegebenen Nachhaltigkeits-Definition eben nicht nachhaltig. Langfristiger, der Allgemeinheit dienender Unternehmenserfolg wurde dem kurzfristigen persönlichen Erfolg geopfert. Ausbaden muss das Desaster letztendlich dessen Nachfolger, der, wie der Nachfolger unseres Försters, völlig zu Unrecht schlecht dasteht, obwohl er für die möglichen Ausfälle nun wirklich nichts kann.

Deshalb sollte jeder Projektverantwortliche beim Einsatz von RPA, so er denn tatsächlich nicht zu vermeiden ist, unbedingt einen Plan zum zeitnahen Ausstieg aus der RPA-Lösung ausarbeiten: Bis wann wird die geplante RPA-Lösung durch eine nachhaltige Schnittstelle ersetzt? Die Antwort auf diese Frage ist unbedingt vor Projektstart zu beantworten und dessen Durchführung natürlich später auch zu überwachen. Der Projektverantwortliche selbst muss auch für die Einhaltung dieses Planes einstehen. Auf diese Weise wird ein verantwortungsbewusster Umgang mit der RPA-Technologie gefördert und vermeidet (hoffentlich) einen späteren größeren Flächenbrand im Unternehmen.

Noch eine letzte Anmerkung zum Abschluss dieses Absatzes zu RPA: Die Marketingabteilungen haben mit der Bezeichnung „Robotic Process Automation“ wirklich ganze Arbeit geleistet. Chapeau! Durch die geschickte Kombination dreier Buzzwords werden die Leser geradezu elektrisiert: Roboter automatisieren meine Prozesse – wie toll ist das denn?! In Wirklichkeit werden letztendlich, wenn man es genau nimmt, einzelne Prozessschritte automatisiert und keineswegs vollständige Ende-zu-Ende-Prozesse. Und der vermeintliche Roboter ist ein Stück Software, das Bildschirme steuert. Hier wird also in gewisser Weise Etikettenschwindel betrieben, da Erwartungen geweckt werden, die die Lösung nicht liefert, nicht liefern kann.

Nach dem Lesen dieses Abschnitts verstehen Sie vielleicht, weshalb ich Ihnen empfehle, sich den RPA-Einsatz reiflich zu überlegen und sich der Technologie mit gebührender Skepsis zu nähern. Wichtig ist mir, dass Sie eine bewusste Entscheidung treffen, auch unter Berücksichtigung der nicht unerheblichen Risiken, die Sie durch den RPA-Einsatz eingehen.

Moral Hazard und weitere Beispiele aus der IT-Industrie
Doch ist RPA das einzige Beispiel, bei dem so gehandelt wird? Sie ahnen es schon: Leider nein. Gerade die IT-Branche ist äußerst anfällig für derartige geradezu panikartigen Handlungsweisen. In keiner Industrie ist die Redensart „Welche Sau wird denn jetzt schon wieder durchs Dorf getrieben?“ so allgegenwärtig wie in der IT. Der FOMO-Effekt (Fear Of Missing Out), also der Angst, eine entscheidende Entwicklung zu verpassen, ist hoch.

Microservices
So werden aktuell beispielsweise Microservices und deren Verknüpfung zu Prozessen über Ereignisse (sogenannte Event-Driven Microservices) heiß diskutiert. Auch hier halte ich deren Einsatz für nicht nachhaltig, ja sogar für fatal, da die Transparenz über Verknüpfungen und Abhängigkeiten zwischen Services über einen längeren Zeitraum hinweg vollständig verlorengeht. Auswirkungen von Änderungen an den Ereignisverknüpfungen sind nicht mehr vorhersagbar, die Anpassung der Software an neue Marktgegebenheiten wird zu einem Glücksspiel, so wie ich es in meiner Einleitung zu diesem Beitrag beschrieben hatte. Am Ende des Tages endet derart entwickelte Software in einem unwartbaren Prozess-Monolithen, obwohl es der ursprüngliche Gedanke von Microservices einmal war, genau diese Monolithen zu vermeiden.

Ironie des Schicksals: Die per Ereignisse verknüpften Microservices enden in einem Prozess-Monolithen, der viel schwieriger zu pflegen und zu handhaben ist, als die programmierten Prozess-Monolithen. Warum? Bei dem programmierten Prozess-Monolithen sehe ich die einzelnen Schritte eines Prozesse repräsentiert durch Interaktionen zwischen den Services immerhin noch im Programmcode. Bei den Publish-Subscribe-Beziehungen zwischen ereignisgesteuerten Microservices wird das Abhängigkeitsgeflecht über die Zeit jedoch derart unübersichtlich, dass Änderungen nahezu unmöglich werden. Auch hier offenbart sich das Problem allerdings erst nach längerer Zeit – Moral Hazard „at its best“ also.

Auch gegenüber meiner eigenen Definition von Nachhaltigkeit gemäß der Anforderungen Effizienz, Transparenz und Flexibilität fällt der Microservices-Ansatz ab: weder effizient, noch transparent, noch flexibel. Nichtsdestotrotz kommt der Ansatz in den Unternehmen zum Einsatz. Muss man das verstehen?

Programmierte Prozesse
Sie werden sich jetzt sicherlich fragen, ob programmierte Prozesse die bessere Lösung sind? Nun ja, zumindest besser als über Ereignisse verknüpfte Microservices. Wenigstens im Punkt „Transparenz“ schneiden programmierte Prozesse aufgrund der im Code sichtbaren Prozessschritte ein klein wenig besser als die ereignisgesteuerte Microservices ab. Ansonsten sieht es bei den Punkten Effizienz und Flexibilität ähnlich duster aus. Eine zukunftsfähige und damit tragfähige Basis ist das aus meiner Sicht jedenfalls nicht.

Kauf von Standardsoftware
Betrachten wir eine weitere Lösungsoption, die nach meinen gemachten Erfahrungen mit Unternehmen reflexartig gezogen wird: Der Kauf von Standardsoftware. Mit Sicherheit ist dies die zeit- und wahrscheinlich auch kosteneffizienteste Art, Prozessprobleme schnell zu lösen. Aber ist sie auch auf lange Sicht nachhaltig? Ich hege starke Zweifel, da diese Lösungsoption bei den Punkten Transparenz und Flexibilität ebenfalls versagt. Gekaufte Lösungen sind Black Boxen und verweigern dem Käufer die Sicht auf die innere Arbeitsweise der Prozesse, deren Zustände und damit der Möglichkeit, zur Laufzeit in das Geschehen einzugreifen. Transparenz und Flexibilität sind damit praktisch nicht vorhanden und nach meinem Verständnis und Definition von Nachhaltigkeit ist der Kauf von Standardsoftware eben keine nachhaltige Option mehr.

Damit Sie mich nicht falsch verstehen: Gerade die Programmierung von neuen Prozessen und der Kauf vorgefertigter Lösungen zur Abdeckung von Standardprozessen waren über viele Jahrzehnte hinweg die richtige Vorgehensweise. Sie ist es nur jetzt, im Zeitalter der digitalen Transformation (siehe hierzu auch meinen Artikel über Digitalisierung vs. Digitale Transformation), eben nicht mehr! Hier muss ein grundlegendes Umdenken in allen Unternehmen stattfinden!

No-Code/Low-Code-Plattformen
Auch die aktuell heiß diskutierten No-Code- bzw. Low-Code-Plattformen gehören für mich in die Kategorie der nicht nachhaltigen Angebote. Die Sirenen-Rufe der Plattform-Hersteller sind für Unternehmen allerdings auch zu verlockend, versprechen sie doch eine kinderleichte Entwicklung von Apps ohne Programmierkenntnisse – ein lang gehegter Traum scheint endlich wahr zu werden. Die Hersteller überschlagen sich auch förmlich mit Versprechungen. Microsoft Power Apps, die angeblich jeder entwickeln kann. ServiceNow mit ihrer Now Platform oder SAP mit ihrem Kauf von AppGyver unterstreichen die Bedeutung dieses aktuellen Trends. Dabei rückt neben der einfachen Entwicklung von Benutzeroberflächen auch die Erstellung von Workflows zusehends in den Vordergrund.

Aber ist die Nutzung derartiger Plattformen wirklich nachhaltig? Ich bin der festen Überzeugung: NEIN! Neben den Vorteilen der schnellen Bereitstellung neuer Lösungen, wiegen aus meiner Sicht die Nachteile zu schwer. Ganz offensichtlich ist hier der Nachteil der Herstellerabhängigkeit (Vendor Lock-In) zu nennen. Natürlich versuchen die Hersteller aktuell mit allen Mitteln, von diesem aufstrebenden Markt den größten Teil des Kuchens abzubekommen und die Kundschaft auf ihre Seite zu ziehen. Schließlich lockt im Plattformmarkt das „The winner takes it all“-Prinzip. Neben der Abhängigkeit, die Unternehmen hiermit offensichtlich eingehen (sie sind dem Hersteller auf Gedeih und Verderb ausgeliefert und ein späterer Wechsel ist mit enormen Kosten verbunden), sollten sie die Gefahr eines Fehlgriffs bei der Auswahl ihres Herstellers nicht unterschätzen. Was ist, wenn auf das falsche Pferd gesetzt wurde und sich der Plattformhersteller der Wahl letztendlich nicht durchsetzen kann und aufgibt? Welcher Hersteller überlebt also und wer geht unter? Man braucht schon eine Glaskugel, um dies sicher vorhersagen zu können. Und wer kann das schon?

Außerdem wird man im realen Leben immer an Grenzen einer Plattform stoßen. Wie einfach ist es dann, diese Lücken zu schließen? Die Frage der Erweiterbarkeit stellt sich also zwangsläufig. Der Hersteller wird seinerseits versuchen, den Wünschen der Kunden zu entsprechen und ihre Plattform kontinuierlich diesen Wünschen anzupassen, mit dem Ergebnis eines immer umfangreicheren Molochs, der immer schwerer zu handhaben ist. Was klein und leichtgewichtig begann, endet in einem schwergewichtigen Fiasko. Diese Entwicklung haben wir in der Geschichte der Informatik unzählige Male erlebt. Anscheinend werden daraus aber nicht die entsprechenden Lehren gezogen…

Selbst wenn die Auswahl auf den zukünftigen Gewinner ausfiel und die Grenzen der Plattform selten ausgereizt werden, wer garantiert, dass dieser Hersteller zukünftig nur noch kompatible Aktualisierungen der Plattform zur Verfügung stellen wird? Auch hier zeigt die Erfahrung: Sobald neue Technologien am Horizont auftauchen (und das werden sie, seien Sie sich dessen gewiss), wird ein Hersteller diese nutzen, auch wenn es den Bruch mit der Kompatibilität zur bestehenden Plattform bedeutet. Kunden sind dann aufgrund der Herstellerabhängigkeit zu kostenintensiven Migrationsprojekten gezwungen. Kein angenehmer Gedanke!

Wie eingangs kurz angedeutet, beinhalten einige dieser neuen Plattformen auch Workflow-Funktionalität. Hier ist der Einsatz proprietärer Modellierungsumgebungen zu beanstanden. Die Unterstützung anerkannter Standards wie BPMN? Fehlanzeige. Jeder kocht hier sein eigenes Süppchen. Eine Austauschbarkeit von Prozessmodellen ist von vornherein ausgeschlossen. Wohl dem, der sich dieser Abhängigkeiten entziehen kann.

Selbst wenn man die bereits aufgeführten Argumente kennt und für sich entscheidet, mit diesen Risiken leben zu wollen, stellt sich doch noch immer die alles entscheidende Frage, ob Unternehmen es sich überhaupt leisten können, wenn an allen Ecken und Enden neue Apps und Workflows wie Pilze aus dem Boden schießen? Unternehmen müssen sich fragen lassen: Will ich das wirklich? Denn Apps und Workflows können in der Regel ohne Zugriffe auf die bereits existierende Systemlandschaft (z.B. für Stamm- und Bewegungsdaten) kaum vernünftige Funktionalität bereitstellen. Für die IT-Abteilungen bedeutet dies aber zwangsläufig ein Mehr an Verwaltungsoverhead: Welche Apps/Workflows greifen wann auf welche Systeme zu? Ein nicht mehr zu kontrollierender Wildwuchs ist zu befürchten! Hier wird die Büchse der Pandora geöffnet! Und genau wie in Goethes Zauberlehrling werden Unternehmen früher oder später erkennen müssen, dass sie nicht mehr Herr der Lage sind. Ein Albtraum!

Sie ahnen schon, wie dies enden könnte? Die ausführliche Antwort folgt gleich im nächsten Abschnitt über die Konsequenzen nicht nachhaltiger Softwareentwicklung. Mein Fazit für den Einsatz von No-Code- bzw Low-Code-Plattformen kann daher nur lauten: Finger weg!

Process Mining
Last but not least stellt sich unweigerlich die Frage, wie Unternehmen versuchen, insbesondere dem Transparenz-Problem zu begegnen, das sich aufgrund des Einsatzes aller in diesem Artikel diskutierten „Lösungsoptionen“ zwangsläufig ergibt? Die Antwort lautet: Durch noch mehr Software, konkret in Form von Process Mining. Allerdings geht der Einsatz von Process Mining mit anderen Problemen einher, wie ich in meinem kritischen Artikel zu dessen Einsatz ausführlich dargelegt habe. Ein Teufelskreis also! Doch man kann ihm entrinnen, wie Sie gleich noch sehen werden.

Konsequenzen nicht nachhaltiger Softwareentwicklung bzw. des nicht nachhaltigen Einsatzes von Software oder: Wie man ein Unternehmen unter Einsatz von IT ruinieren kann

Sie merken schon, mir liegt das Thema der nachhaltigen Softwareentwicklung bzw. des nachhaltigen Einsatzes von Software sehr am Herzen. Es ist aber auch zu wichtig, als dass dies Unternehmen vernachlässigen oder gar ignorieren könnten, da die langfristigen Auswirkungen, die ich in diesem Abschnitt thematisiere, so gravierend sind.

In meinem Webinar vom 08.09.2021 über die nachhaltige Prozessentwicklung mit dem Prozessgesteuerten Ansatz, nachzuschauen unter diesem Link, zeigte ich folgende Abbildung (Abbildung 1):

 

keepingTheLightsOn-2

Abbildung 1: Ist-Zustand der Kapazitäten in IT-Abteilungen und angestrebter Soll-Zustand

Die Abbildung stammt ursprünglich von meinen ehemaligen SAP-Kollegen, die mit dieser Abbildung die dringende Notwendigkeit nach Veränderung in ihrem Geschäftsbereich zum Ausdruck brachten. Sie liefen kapazitätsmäßig am Limit, hauptsächlich getrieben durch immer wiederkehrende Routine- und Verwaltungstätigkeiten. Es blieb immer weniger Zeit für Arbeiten an dringend notwendigen Geschäftsinnovationen. Ihr Wunsch nach mehr Freiheiten für Innovationen im Kerngeschäft symbolisiert die gewünschte Kapazitätsverteilung in der rechten Säule der Abbildung. Tatsächlich erreicht wurde der Sollzustand letztendlich durch das bisher größte Projekt basierend auf dem Prozessgesteuerten Ansatz. Aber das nur am Rande.

Die grundlegende Aussage dieser Abbildung lässt sich nun leicht auf die derzeitige Situation von IT-Abteilungen in Unternehmen übertragen, die ich aus vielen Gesprächen mit Unternehmen gewinnen konnte. Sie zeigt auf der linken Seite den Ist-Zustand der Belastungen für IT-Abteilungen in Unternehmen. In der Vertikalen ist die Gesamtkapazität der IT-Abteilungen zu erkennen. Damit ist die für Arbeiten zur Verfügung stehende Gesamtzeit sämtlicher IT-Mitarbeiter gemeint.

Diese Kapazität ist nun typischerweise für zwei Arten von Aktivitäten nutzbar. Zum einen kann die Kapazität für Grundlast-Aufgaben verwendet werden. Dabei handelt es sich um immer wiederkehrende Verwaltungs- und Routineaufgaben, die den „Laden“ sprichwörtlich am Laufen halten (zu erkennen an dem dunklen Rechteck, beschriftet mit „Keeping the lights on“). Zu diesen Aufgaben zählen beispielsweise (um nur einige wenige zu nennen):

Einrichten neuer Nutzer

  • Rechtevergabe für die verschiedenen Systeme
  • Einspielen von Sicherheits-Patches
  • Aktualisierung von Software
  • Überwachen des korrekten Betriebs der Systeme
  • Korrekte Beendigung diverser Batch-Verarbeitungsläufe
  • Sehr beliebt: Aufwändige Release-Wechsel der gekauften Standardsoftware
  • Konsolidierung von Systemen zur Reduzierung der IT-Landschaft
  • Integration von Systemen bei Neukäufen bzw. nach dem Zusammenschluss von Unternehmen.
  • Auslagerung von Funktionalitäten in die Cloud
  • Fehleranalysen aller Art

Die Liste erhebt natürlich keinen Anspruch auf Vollständigkeit.

Zum anderen kann die Kapazität aber auch für Geschäftsinnovationen genutzt werden (in Abbildung 1 zu erkennen an dem orangenen Kasten, beschriftet mit „Geschäftsinnovation“). Anhand der Höhen der jeweiligen Rechtecke wird die Verteilung der Kapazitäten für den Ist- und den angestrebten Soll-Zustand ausgedrückt.

Die Kernbotschaft der Abbildung lässt sich demnach wie folgt kurz zusammenfassen: Aktuell sind IT-Abteilungen mit viel zu vielen Arbeiten belastet, die lediglich der Aufrechterhaltung des Betriebes dienen (eben die Grundlast). Für Geschäftsinnovationen bleibt, wenn überhaupt, nur vergleichsweise wenig Raum (Ist-Situation, linke Säule). In Anbetracht der digitalen Transformation wäre aber eine genau umgekehrte Kapazitätsverteilung notwendig (Soll-Situation, rechte Säule): Weniger Zeitverbrauch für die Grundlast und mehr Freiraum für Geschäftsinnovationen. Denn die digitale Transformation wird durch IT-basierte Prozessinnovationen getrieben! Wie soll diese Innovationskraft für Unternehmen allerdings wirken, wenn seitens der IT überhaupt keine Kapazität mehr vorhanden ist?

Um es auf den Punkt zu bringen: Im Zeitalter der digitalen Transformation ist es eine der fatalsten Entscheidungen überhaupt, die IT-Kapazitäten durch Einsatz zweifelhafter Lösungen weiter einzuschränken und dem Unternehmen damit die Innovationskraft zu nehmen!

Allerdings scheint diese im Grunde einfache Binsenweisheit von vielen Unternehmen noch immer nicht verstanden worden zu sein. Wie lässt sich sonst der unverhältnismäßig hohe Anteil an Investitionen in Software, Technologien und Implementierungsansätze erklären, die die Grundlast-Säule anwachsen lassen und der IT noch mehr Luft zum Atmen nehmen? Sämtliche obig diskutierten Technologien, Implementierungsansätze und Lösungen mit negativem Beitrag zur Nachhaltigkeit tragen dazu bei, dass sich die IT zwangsläufig nur noch mehr mit sich selbst beschäftigen muss!

Genau diese Entwicklung empfinde ich als verhängnisvoll und in höchstem Maße besorgniserregend!

Erkennen Unternehmen diese Entwicklung? Meiner Beobachtung nach sehen die Verantwortlichen diese schlummernden Gefahren nicht (oder wollen sie nicht sehen), zumal sich der durch diese Entwicklung steigende technische Schuldenstand, wie es bei dem Moral Hazard-Problem typisch ist, über einen langen Zeitraum erstreckt. Jede Einzelentscheidung für sich genommen mag logisch nachvollziehbar und vermeintlich gerechtfertigt sein. In der Summe akkumulieren sich über die Zeit aber derart hohe technische Schulden, dass diese Entwicklung für die Unternehmen über kurz oder lang nur in einem IT-Fiasko enden kann! Die akkumulierten Schulden sind eine tickende Zeitbombe. Bildlich gesprochen fahren die Unternehmen mit Vollgas auf eine Betonmauer zu. Nur wird diese Mauer nicht magisch zur rechten Zeit zur Seite springen. Überspitzt ausgedrückt manövrieren sich Unternehmen durch den Einsatz obiger Ansätze geradezu ins digitale Aus.

Die kombinierte Anwendung von RPA, ereignisgesteuerten Microservices, dem ständigen Kauf von Standardsoftware, programmierten Prozessen, dem Einsatz von No-Code/Low-Code-Plattformen usw. hat für Unternehmen sogar das Potenzial, einen „perfect storm“ in der IT zu produzieren und ein Unternehmen zu ruinieren.

Jedoch liegt es mir fern, nur klagen zu wollen. Konstruktive Kritik ist an der Stelle gefragt. Von daher möchte ich diesem ruinösen Trend den Prozessgesteuerten Ansatz entgegenstellen. Ausschließlich der Prozessgesteuerte Ansatz liefert die Basis, auf der dann technische Schulden real abgebaut werden können und die den IT-Abteilungen den Freiraum zurückgibt, den sie für Prozess- und damit Geschäftsinnovationen so dringend benötigen!

Die Kenntnis über den Prozessgesteuerten Ansatz ist für Unternehmen daher wertvoller denn je. Helfen Sie also mit, zur Verbreitung des Wissens um den Prozessgesteuerten Ansatz beizutragen!

Fazit
Dieser Artikel ist ein Appell an die Unternehmen, nachhaltige Softwareentwicklung sowie den nachhaltigen Einsatz von Software endlich zu einem Kernthema werden zu lassen, gerade weil dies im Zeitalter der digitalen Transformation so unglaublich wichtig ist. Die Zukunft von zu vielen Unternehmen hängt davon ab. Die digitale Transformation braucht die Freiheit für Prozessinnovationen durch IT so dringend wie die Luft zum Atmen. Sämtliche Investitionen in Software, Technologien und Implementierungsansätze, die nicht nachhaltig sind, wirken diesem Bestreben nach Freiheit entgegen und sind folglich kritisch zu hinterfragen. Unglücklicherweise trägt das tückische Problem des Moral Hazards zu einer schleichenden Erhöhung des technischen Schuldenstandes in Unternehmen bei. Führungskräfte müssen für die verheerenden Auswirkungen des Moral Hazards-Problems sensibilisiert werden, wozu dieser Artikel einen Beitrag leisten möchte.

Daher meine Empfehlung: Jede IT-Investitionsentscheidung ist bezüglich seiner Auswirkungen auf den technischen Schuldenstand eines Unternehmens hin zu untersuchen. Gegebenenfalls sind Maßnahmen zu ergreifen und zu überwachen, die den Schuldenstand wieder senken. Eine kontinuierliche Anhäufung von technischen Schulden ist zu vermeiden.

Der Prozessgesteuerte Ansatz setzt genau an dem Punkt der Reduzierung technischer Schulden an und ist damit einzigartig. Nur der Prozessgesteuerte Ansatz ermöglicht es Unternehmen aktuell, sich endlich von dem Trend der immer weiter steigenden Grundlastanteile in der Kapazität von IT-Abteilungen zu befreien. Helfen Sie daher bei der Verbreitung des Wissens um den Ansatz mit, damit so viele Unternehmen wie möglich davon profitieren können! Seien Sie Teil der PiDiArtify-Initiative, die sich zum Ziel gesetzt hat, ihren Beitrag für eine nachhaltige Softwareentwicklung zu leisten. Weitere Informationen zur Initiative finden Sie hier.