Über Volker Stiehl

Volker Stiehl

Meine Motivation für den „Prozessgesteuerten Ansatz“

Auf dieser Seite erfahren Sie mehr über mich und meinen bisherigen Werdegang. Ich möchte diese Seite aber auch dazu nutzen, Ihnen meine Motivation für das Engagement rund um den „Prozessgesteuerten Ansatz“ zu erklären. Denn die hängt eng mit meinem beruflichen Leben zusammen. Um es kurz zu machen: Es ist die Frustration über die Art und Weise, wie Softwareprojekte für Prozessimplementierungen abgewickelt wurden (und noch immer werden). Von der frühen Phase der Projektplanung, die missverständliche Kommunikation zwischen den Projektbeteiligten über die Implementierung bis hin zur Wartung und Weiterentwicklung ist die Softwareentwicklung für Prozesse so unglaublich ineffizient und mangelhaft, dass man sich nur wundern kann, dass überhaupt etwas dabei rauskommt. Würde man Häuser so bauen, wie Software entwickelt wird, wäre die Welt ein einziger Trümmerhaufen!

Es war für mich schlicht unfassbar, warum keine fundamentalen Änderungen an diesen untragbaren Zuständen versucht wurden, zumal dieses System nur unzufriedene Teilnehmer hinterlässt: Unzufriedene Kunden, Projektleiter, Architekten, Entwickler, Betreiber, Endanwender,…

Aus dieser Frustration heraus erwuchs der Wunsch nach einer Alternative. Es war mir von vornherein klar, dass es eines fundamental anderen Ansatzes bedurfte, um die vielfältigen Herausforderungen (siehe unten) zu lösen. Letztendlich mündete die Suche nach dieser Alternative im „Prozessgesteuerten Ansatz“. Der Ansatz stellt einen Paradigmenwechsel in der Softwareentwicklung für Prozesse dar und verlangt von allen Projektbeteiligten Innovationsfreude und Offenheit für ein neues, prozessorientiertes Denken. Doch ein Wechsel lohnt sich für Unternehmen aufgrund der vielen offensichtlichen positiven Auswirkungen (siehe auch meine Liste von Vorteilen auf meiner Visions/Missions-Seite). Letztendlich braucht es genau eine Voraussetzung für den „Prozessgesteuerten Ansatz“: Man muss es wollen!

Wie Sie meinem Lebenslauf unten entnehmen können, lag mein Fokus seit Anbeginn auf Prozessen, deren Implementierung (insbesondere während der Jahre bei Siemens) sowie deren Unterstützung durch passende Werkzeuge (insbesondere während der Jahre bei SAP). Dabei fielen mir die oben angesprochenen Ineffizienzen im gesamten Softwareentwicklungszyklus auf. Ich war selbst viele Jahre als Entwickler Teil von Entwicklungsprozessen und konnte später in meiner Rolle als Produktmanager in Unternehmen ähnliche Mängel beobachten. Dabei stehen Softwareentwicklungsabteilungen, die die Prozesse letztendlich umzusetzen haben, mindestens folgenden schwerwiegenden Herausforderungen gegenüber:

  • Unzählige Missverständnisse aufgrund mangelhafter Kommunikation
    Jeder kennt die folgende Abbildung, die schon zu meiner Zeit als Student aufgelegt wurde:
Copyright © www.projectcartoon.com under the Creative Commons Attribution 3.0 Unported License

Wir lachten damals darüber (ich begann mein Studium 1983!) und so lachen auch heute noch Studierende darüber. Ist das nicht erschreckend? Fast 40 Jahre später keinerlei Fortschritt? Aber es spiegelt die Realität wieder: Software wird fehlgeleitet entwickelt, weil zuvor keine klare Kommunikation stattfindet. Diese Lücke versucht man heute durch agile Methoden zu übertünchen. Doch warum löst man dieses Problem nicht fundamental? Der „Prozessgesteuerte Ansatz“ tut genau dies auf Basis von Prozessmodellen!

  • Das unendliche Ping-Pong-Spiel zwischen Fach- und IT-Abteilungen
    Eine Folge der mangelhaften Kommunikation ist das Ping-Pong-Spiel zwischen Fach- und IT-Abteilungen. Die Fachabteilung spezifiziert eine neue Lösung und formuliert diese in Prosa (also nicht formal). Die IT-Abteilung interpretiert diese Vorgaben und liefert eine erste Version der Lösung ab, die von der Fachabteilung zu reviewen ist. Natürlich stimmt nicht alles sofort aufgrund von Fehlinterpretationen. Es kommt zu Korrekturen, die abermals zu reviewen sind usw. Bis die finale Lösung steht (wenn man nicht bereits vorher mit einem „ist gut genug“ kapituliert), vergehen völlig überflüssige Entwicklungsschleifen. Dies ist für beide Seiten nervend und demotivierend.
    Durch das modellbasierte Vorgehen im „Prozessgesteuerten Ansatz“ werden diesem Ping-Pong-Spiel die Grundlagen entzogen. Es wird nicht eher mit der Implementierung begonnen, ehe über den Prozess und den damit benötigten Benutzeroberflächen und Diensten Einigkeit besteht. Das Ping-Pong-Spiel ist beendet!
  • Ausufernde Kosten und nicht eingehaltene Termine
    Unzählige Softwareentwicklungsprojekte werden nicht rechtzeitig fertig oder überziehen das zuvor kalkulierte Budget. Man kann dieses Problem auch als Elbphilharmonie- oder Berliner Flughafen-Problem bezeichnen. Zu meiner Zeit war der Begriff „Bananensoftware“ allgegenwärtig: Die Software wurde aufgrund des Drucks in einem unfertigen Zustand ausgeliefert und dann durch kontinuierliche Aktualisierungen (Patches bzw. Updates im Fachjargon) weiterentwickelt. Die Software reifte also beim Kunden.
    Im Gegensatz dazu wurde in einem Großprojekt bei der SAP dem „Prozessgesteuerten Ansatz“ eine hohe Effizienzsteigerung attestiert. So wurde eine Ersparnis von 75% im Vergleich zur herkömmlichen Entwicklung bescheinigt (siehe diese Veröffentlichung der SAP).
  • Fehlende Transparenz
    Wenn Sie neue Mitarbeiter sowohl auf der Fach- als auch auf der IT-Seite einarbeiten müssen, wissen Sie, wovon ich rede. Die Einarbeitungsaufwände sind teilweise enorm! Bis die neuen Mitarbeiter eingearbeitet und wirklich produktiv einsetzbar sind, vergeht vergleichsweise sehr viel Zeit. Die Kosten sind entsprechend hoch. Woran liegt dies? In der Regel sind die Abläufe, wenn überhaupt, schlecht dokumentiert. Und wenn sie dokumentiert sind, stimmen sie in den seltensten Fällen mit der Realität überein. Die Folge sind lange Gespräche mit den Prozessbeteiligten. Die neuen Mitarbeiter müssen von Pontius bis Pilatus rennen, um sich die Informationen über die Abläufe zu beschaffen. Auch der geduldigste Kollege wird irgendwann entnervt antworten, insbesondere wenn das Unternehmen rasch wächst und viele neue Mitarbeiter einzuarbeiten sind. Es fehlt schlicht an Transparenz über das, was im Unternehmen vorgeht.
    Noch schlimmer ist die Situation in den Entwicklungsabteilungen, da sich die neuen Kollegen und Kolleginnen neben den Prozessen auch noch in die dazugehörige Software einarbeiten müssen. Hier sind die Einarbeitungszeiten aufgrund unzulänglicher Dokumentationen noch wesentlich höher. Ein eigentlich untragbarer Zustand, den man nur mit „katastrophal“ beschreiben kann. Doch auch hier hat sich über die Jahrzehnte nichts geändert. Man wundert sich, wie Unternehmen auf einer solchen Basis überhaupt existieren können.
    Die fehlende Transparenz hat aber nicht nur Auswirkungen auf die Einarbeitung neuer Mitarbeiter. Viel schlimmer sind die Folgen mangelnder Transparenz auf Ebene der Unternehmensleitung, denn: Fehlende Transparenz über die Situation im Unternehmen führt zu falschen Entscheidungen auf Managementebene und damit zu weitreichenden Konsequenzen bis hin zur Insolvenz! Das starke Wachstum von und die immense Nachfrage nach analytischen Anwendungen (Stichwort: Big Data) bis hin zum Process Mining (siehe auch meine kritische Auseinandersetzung zu Process Mining-Lösungen in meinem Blog) sind nichts anderes als ein gigantischer Hilfeschrei nach mehr Transparenz!
    Der „Prozessgesteuerte Ansatz“ spielt gerade in diesem Punkt seine Stärken aus, da die Prozessmodelle auch während der Betriebsphase allgegenwärtig sind und sich anhand dieser Modelle sämtliche Transparenzfragen beantworten lassen! In welchem Status befinden sich die Prozesse? Was ist bisher passiert? Wie geht es weiter? Wo haben wir besonders lange Bearbeitungszeiten? Welche Aufträge hängen an welchen Schritten? Die Antwort findet sich stets in den Prozessen!

Aus all den genannten Punkten (und die Liste ließe sich nahezu endlos verlängern) stellte sich mir die eine zentrale Frage: Wie kann man Softwareentwicklung fundamental verbessern? Wie kann man das „Rumwurschteln“ vermeiden und die Softwareentwicklung auf ein gesundes Fundament stellen? Tja, die Ergebnisse dieser Überlegungen haben sich im „Prozessgesteuerten Ansatz“ manifestiert, der umfassend die aufgeführten Herausforderungen konkret adressiert und löst. Es ist mein Beitrag zu einer zielgerichteten, effizienten und dabei nachhaltigen Umsetzung von Implementierungsprojekten, in denen innovative Prozesse umzusetzen sind!

Vita

Akademisch:

  • Seit Sommersemester 2012:
    Lehraufträge an der Friedrich-Alexander Universität Erlangen-Nürnberg und der DHBW Mosbach über die Entwicklung prozessgesteuerter Anwendungssysteme
  • Sept. 2011:
    Promotion zum Dr. rer. pol. im Fachbereich Wirtschaftswissenschaften  der Technischen Universität Darmstadt zum Thema „Systematisches Konstruieren von Verbundanwendungen unter Verwendung von BPMN“ bei Prof. Dr. Erich Ortner, Zweitgutachter Prof. em. Dr. Dr.-Ing. E.h. Hartmut Wedekind (Friedrich-Alexander Universität Erlangen-Nürnberg) und Prof. Dr. Mathias Weske (Hasso Plattner Institut Potsdam)
  • 1983 – 1988:
    Studium der Informatik an der Friedrich-Alexander Universität Erlangen-Nürnberg

Beruflich:

  • Seit März 2016:
    Professor für Wirtschaftsinformatik und Entwicklung von Unternehmensanwendungen an der Technischen Hochschule Ingolstadt
  • Juli 2004 – Feb. 2016:
    SAP SE, Walldorf: Chief Product Expert (SAP Process Orchestration, SAP Process Integration, SAP HANA Cloud Integration)
  • 1992 – Juni 2004:
    Siemens AG, Siemens Business Services, Nürnberg: Senior System Architect für Java EE-basierte betriebswirtschaftliche Prozessautomatisierungssysteme
  • 1989 – 1991:
    CSEG GmbH, Nürnberg: Softwareentwickler für technische Prozessautomatisierungssysteme (Anlagensteuerung)