Produktion steigern durch Prozessdigitalisierung

Auf bto analysieren und diskutieren wir intensiv die Auswirkungen von monetären Schulden auf die Wirtschaft. Aber es gibt Schulden, auf die ich hier noch gar nicht eingegangen bin, die aber eine ebenso große Sprengkraft wie monetäre Schulden haben: technische Schulden. Auf diese Schuldenart wurde ich von einem unserer bto-Leser aufmerksam gemacht: Volker Stiehl, Professor für Wirtschaftsinformatik und Entwicklung von Unternehmensanwendungen an der Technischen Hochschule Ingolstadt. Er zog in einem Leserbrief Parallelen zwischen Schulden in der Ökonomie auf der einen und Schulden in der Informatik auf der anderen Seite. Dabei wies er nicht nur auf diese Parallelen und deren verheerende Auswirkungen hin, sondern bot auch einen konstruktiven Lösungsvorschlag an. Interessanterweise ist es derselbe Lösungsvorschlag, auf den mich Volker Stiehl schon als Reaktion auf einen anderen bto-Artikel zur Produktivitätssteigerung hinwies. Sein „prozessgesteuerter Ansatz“ erlaubt Unternehmen und Behörden also eine vielschichtige Produktivitätssteigerung bei gleichzeitiger Reduktion technischer Schulden. Wir weisen in unseren Diskussionen immer wieder auf mehr Digitalisierung hin, ohne allerdings zu konkretisieren, wie diese genau zu realisieren ist. Genau das finden wir in dem Vorschlag von Volker Stiehl. Daher bat ich ihn um einen Gastbeitrag, der die Thematik in einer Art und Weise darstellt, die auch für einen nicht so IT-affinen Leser verständlich ist. Nehmen Sie sich die Zeit, sich mit konkreten Lösungsvorschlägen auseinanderzusetzen, die uns aus der aktuellen Krisensituation herausführen können und bilden Sie sich Ihre eigene Meinung vom „prozessgesteuerte Ansatz“.

Noch ein Hinweis vorab: Volker Stiehl schrieb den ursprünglichen Artikel als Lösungsvorschlag zur Produktivitätssteigerung. Nach seinem neuerlichen Leserbrief zur aktuellen Schuldenkrise und den Parallelen zwischen monetären und technischen Schulden sowie seinem Hinweises, dass der prozessgesteuerte Ansatz auch für dieses Problem eine Lösung bietet, bat ich ihn, diese Gedanken ebenfalls noch zu Papier zu bringen. Lesen Sie daher zunächst seine Ausführungen zu technischen Schulden und der Einordnung seines eigentlichen Artikels in diesen Kontext. Im Anschluss daran finden Sie seinen Beitrag zur Produktivitätssteigerung durch Prozessdigitalisierung.

————————————————————————————————————————————————

Volker Stiehl zu  Parallelen zwischen monetären und technischen Schulden sowie zur Einordnung des prozessgesteuerten Ansatzes als Lösungsoption auch für dieses Problem

Liebe Leser von bto,

die Ereignisse überschlagen sich derzeit. Es vergeht kein Tag ohne neue Krisenmeldungen. Und auch Sie haben sicherlich die zahlreichen Ankündigungen unseres Wirtschafts- und unseres Finanzministers in dieser Woche gehört. Umfangreiche Förderungen in unvorstellbarer Höhe und eine Vielzahl an Beschlüssen sollen auf den Weg gebracht werden. Betrachtet man diese Ankündigungen durch die IT-Brille, so bedeutet dies eine Mammutaufgabe, denn all diese Beschlüsse müssen prozesstechnisch so schnell wie irgend möglich umgesetzt werden. Mir ist dieser Zusammenhang wirklich sehr wichtig:

Jeder getroffene Beschluss hat zwangsläufig die Erstellung neuer oder die Anpassung bestehender Prozesse in Computersystemen zur Folge!

Es geht also letztendlich um Schnelligkeit bei der Bereitstellung dieser Prozesse unter Einbeziehung von Informationstechnologien. Und diese schon für sich genommen sportliche Anforderung trifft aktuell auf ohnehin schon stark belastete IT-Abteilungen in den betroffenen Behörden und Unternehmen. Denn diese haben in der Regel so viele technische Schulden angehäuft, dass sie gar nicht schnell genug reagieren können. Ja, es gibt nicht nur monetäre Schulden, auch in der Informatik gibt es Schulden – eben technische Schulden. Sie bedeuten umgangssprachlich ausgedrückt: IT-Abteilungen haben in der Vergangenheit ungeeignete Methoden und Technologien eingesetzt sowie Maßnahmen ergriffen, die als Folge eine schlechte Wartbarkeit und Anpassbarkeit der erstellten Softwarelösungen an (und damit schlechte Reaktionsfähigkeit auf) neue Herausforderungen mit sich bringen. Neben Krisen gehören neue Konkurrenten, neue Geschäftsmodelle aber auch neue Marktgegebenheiten zu diesen Herausforderungen. Kurz gefasst stehen technische Schulden also einer schnellen Prozessumsetzung neuer Forderungen im Wege. Und genau dies können wir vermeiden, wenn Behörden und Unternehmen zukünftig dem „prozessgesteuerten Ansatz“ folgen, den ich im Hauptartikel noch thematisieren werde.

Ich kann mir sehr gut vorstellen, was jetzt in den IT-Abteilungen los ist. Unter höchstem Druck müssen die notwendigen Prozesse in Nacht-und-Nebel-Aktionen sowie Wochenendarbeit erstellt werden. Da sie aber aufgrund der angehäuften technischen Schulden in den bestehenden Programmen recht unflexibel sind und nicht ohne Weiteres die bestehende Software anpassen können, werden die Prozesse wieder mit denselben untauglichen Methoden neu gebaut. Und es sind genau dieselben Methoden (z. B. herkömmliche Programmierung), die uns bereits in diesen IT-seitigen Morast hineingeritten haben. In anderen Worten: Die IT-Abteilungen häufen zu den bereits existierenden technischen Schulden weitere technische Schulden an. Und das führt am Ende des Tages, wie in der Ökonomie, zu einem Zusammenbruch. Die Verantwortlichen kennen sich schlicht nicht mehr in ihren Programmen aus. Die Unternehmen können IT-technisch nicht mehr reagieren (geschweige denn agieren). Sie sind bei zu hohen technischen Schulden schlussendlich nahezu handlungsunfähig.

Lassen Sie mich das beschriebene Szenario anhand eines kleinen Beispiels verdeutlichen. Letzten Sonntag (22.03.2020) veröffentlichte Dr. Daniel Stelter in seinem Podcast die charmante Idee des künstlichen Komas für die Wirtschaft. Eine zentrale Rolle in dieser Idee spielen die Finanzämter, die für die Dauer dieser Krise monatlich „einen Betrag in Höhe von einem Zwölftel des Jahresumsatzes des letzten verfügbaren Jahres auf das Konto des Unternehmens überweisen“ sollen. Die Finanzämter müssen im Gegenzug bei den nächsten Steuererklärungen diese Beträge berücksichtigen und mit den jeweiligen Einnahmen verrechnen. Außerdem sollen Unternehmer jederzeit die erhaltenen Beträge zurückzahlen können. So einfach dieser Ansatz zu verstehen ist, so schwierig dürfte die Umsetzung dieser neuen Prozesse in der Software der Finanzämter zu bewerkstelligen sein. Idealerweise möchte man diese neue Abwicklung in die existierende Software einbauen. Jedoch gibt es da ein nicht unerhebliches Problem: Eben weil man die vielfältigen Wechselwirkungen in herkömmlich programmierter Software schwer überblicken kann, wird eine noch so einfache Anpassung extrem schwierig. Ganz zu schweigen von den vielfältigen Sonderregelungen, die unser Finanzsystem so zu bieten hat. Letztendlich müssen Sie sich das wie einen chirurgischen Eingriff in einem hochkomplexen System vorstellen. Das macht man nicht mal so eben nebenbei. Statt also die bestehende Software schnell anpassen zu können, was aufgrund der genannten Gründe höchst unwahrscheinlich ist, wird zu einer Neuprogrammierung gegriffen, die neben der bestehenden Lösung zusätzlich parallel betrieben wird. Und auf diese Weise kommt eine Sonderlocke zu der nächsten und der (technische) Schuldenhaufen wächst munter weiter, bis man sich schließlich überhaupt nicht mehr auskennt. Die Umsetzung wird letztendlich gelingen. Doch zu welchem Preis?

So sieht es also aktuell in den Behörden und Unternehmen aus, die zumindest noch auf eine eigene IT-Abteilung zurückgreifen können. Noch schlimmer trifft es Institutionen, die ihre IT ausgelagert haben, beispielsweise in die Cloud, und diese von einem Dienstleister pflegen lassen. Denn in diesen Zeiten benötigen wir individuelle Prozesslösungen, die, wie ich auch in meinem Hauptartikel ausführen werde, von Cloud- und Standardsoftwareanbietern so nicht geliefert werden können (und schon gar nicht in der Kürze der Zeit). Sie haben keine Handlungsoption mehr.

Laut Aussage unserer Minister sollen die Hilfen unbürokratisch bereitgestellt werden. Eine Berechtigungsprüfung erfolgt erst im Nachgang. Ob später allerdings Zeit für angemessene Prüfungen sein wird, sei einmal dahingestellt. Leider muss man auch den Missbrauch in Betracht ziehen. Wo Fleischtöpfe prall gefüllt sind, ist der Betrug, um etwas davon zu ergattern, nicht weit. Auch hier kann der prozessgesteuerte Ansatz helfen, denn er sorgt nicht nur für eine produktivere, sondern durch Einsatz sogenannter Entscheidungsregeln gleichzeitig für eine qualitativ hochwertigere Prozessumsetzung. So kann man das eine (Schnelligkeit) mit dem anderen (Qualität durch Einbau automatisierter Prüfungen) kombinieren, sodass dem Betrug, wenn auch nicht zu hundert Prozent, so doch in großem Umfang einen Riegel vorgeschoben wird. Der Verlust für den Steuerzahler hält sich demzufolge in Grenzen.

Eine weitere Fehlentwicklung, die wir jetzt bereuen müssen, ist die einseitige Fokussierung auf Hype-Themen wie beispielsweise der künstlichen Intelligenz (KI). Ich weiß nicht, wie oft auch auf bto immer wieder Investitionen in die KI gefordert wurden. KI ist sicherlich wichtig – das stelle ich nicht in Frage. In der aktuellen Situation hilft uns KI leider nicht ausreichend genug. KI wird den Behörden und Unternehmen nicht die neuen Prozesse schreiben, die sie jetzt brauchen. Mehr denn je benötigen wir eine effiziente, effektive, praktikable und gleichzeitig nachhaltige Methodologie, die uns schnellstmöglich aus dieser Misere bringt. Und genau die liefert der „prozessgesteuerte Ansatz“.

Auch an Universitäten und Hochschulen steht die Ausbildung ganz im Zeichen derartiger Hype-Themen. KI-Studiengänge und Lehrstühle schießen förmlich wie Pilze aus dem Boden. Eine Prise mehr Methodik wäre wahrscheinlich auch hier zuträglicher gewesen. Technologien kommen und gehen (wobei die KI sicherlich bleiben wird – keine Frage). Eine vernünftige Methodik hingegen hat Bestand und ändert sich bei Weitem nicht so schnell. Ein Studiengang „Digital Process Engineering“ ist sicherlich eine Überlegung wert. Er könnte das Wissen um nachhaltige Prozessumsetzungen vermitteln, damit Unternehmen zukünftig generell besser aufgestellt und insbesondere für Krisen dieser Art besser gerüstet sind.

Doch zurück zu unseren Themen „Technische Schulden“ und „Produktivitätssteigerungen“: Generell kann man, wie in der Ökonomie, sagen: Hätten die Firmen mal gestreut. Sie hätten nicht nur auf ein Pferd setzen, sondern auch in der IT streuen müssen. Und der prozessgesteuerte Ansatz gehört in jedes gut aufgestellte IT-Portfolio. Der prozessgesteuerte Ansatz ist sozusagen das Gold in einem Anlegerportfolio: nicht gerade spektakulär, geradezu langweilig, aber stabilisierend, beruhigend und damit wertvoll. Zum Glück habe ich es an dieser Stelle auf der IT-Seite einfacher als Dr. Daniel Stelter auf der ökonomischen Seite: Zur Bewältigung der angehäuften Schulden und zur Produktivitätssteigerung gibt es eine konkrete Lösung, von der wir genau wissen, dass sie funktioniert. Dazu aber gleich mehr im Hauptartikel.

Sie sehen: Sowohl ökonomisch als auch prozesstechnisch geht es um angehäufte Schulden, die schlussendlich zum Kollaps führen. Und der prozessgesteuerte Ansatz bietet sich als eine effiziente und effektive Lösungsoption an, da er sowohl aus dem Blickwinkel der Produktivitätssteigerung als auch aus Sicht des Abbaus technischer Schulden Verbesserungen liefert. Damit möchte ich ein wenig Hoffnung verbreiten in diesen düster wirkenden Zeiten und meinen Beitrag aus Prozesssicht zur Bewältigung der Folgen dieser Krise leisten! Ich wünsche Ihnen nun viel Freude bei der Lektüre meines Artikels, in dem es neben dem prozessgesteuerten Ansatz als Lösungsoption auch um die generelle fundamentale Rolle von Prozessen in der Digitalisierung geht.

————————————————————————————————————————————————

Prozessdigitalisierung als Mittel zur Produktivitätssteigerung

Es war Ende Juli 1973, Madison Square Garden, New York, als Robert Plant den Song “Stairway to heaven” mit den Worten “I think this is a song of hope” einleitete. Was danach folgte, ist mittlerweile Geschichte. Led Zeppelin zelebrierten „Stairway to heaven“ in unnachahmlicher Weise und Jimmy Page lief auf seiner Gibson EDS-1275 „Doubleneck“ in seinem legendären Gitarrensolo zur Höchstform auf.

So wie Robert Plant seinen Zuhörern Hoffnung geben wollte, so will auch dieser Blog-Beitrag Zuversicht verbreiten. Zuversicht, dass wir das mit der Digitalisierung sehr gut meistern und dadurch einen massiven Beitrag zur Produktivitätssteigerung in unserem Land leisten können. Denn es gibt ein relativ neues Verfahren zur Digitalisierung, das uns in dieser Beziehung behilflich sein kann. Dieses Verfahren möchte ich Ihnen in diesem Beitrag näherbringen. Der Fahrplan dazu sieht wie folgt aus:

  1. Neue digitale Geschäftsmodelle hängen untrennbar mit neuen Prozessen zusammen
  2. Prozesse sind allgegenwärtig
  3. Wie sehen die derzeit am häufigsten eingesetzten Lösungsmöglichkeiten zur Prozessdigitalisierung aus und warum sind diese nicht mehr zeitgemäß?
  4. Der prozessgesteuerte Ansatz als neue Alternative zur Prozessdigitalisierung
  5. Der prozessgesteuerte Ansatz in der Praxis
  6. Erfolgsfaktoren beim Einsatz des prozessgesteuerten Ansatzes
  7. Wie passen künstliche Intelligenz und prozessgesteuerter Ansatz zusammen?
  8. Zusammenfassung: Der prozessgesteuerte Ansatz als Digitalisierungskatalysator

Hintergrund dieses Beitrags ist einmal mehr das Thema Produktivität. Im Beitrag von Prof. Schneider vom 10.02.2020 auf bto zum Thema „Deutschlands prekäre Wachstums- und Produktivitätsentwicklung“ [1] wurde uns allen die Misere, in der Deutschland steckt, vor Augen geführt. Ähnliche Ergebnisse finden wir immer wieder auf dieser Plattform. Die zentrale Frage ist doch: Wie kommen wir aus dieser ungemütlichen Gemengelage heraus? Die immer wieder genannte (und somit offensichtlichste) Reaktion lautet: Wir müssen mehr in Digitalisierung, neue digitale Technologien und künstliche Intelligenz investieren! Dies wird gebetsmühlenartig heruntergebetet. Sicherlich richtig, aber viel zu unspezifisch. Wie muss man sich denn die Digitalisierung konkret vorstellen? Eine greifbare Variante der Digitalisierung möchte ich Ihnen daher nun vorstellen: die Prozessdigitalisierung. Warum gerade diese Digitalisierungsvariante so wichtig ist, zeigt der nächste Abschnitt.

Neue digitale Geschäftsmodelle hängen untrennbar mit neuen Prozessen zusammen

Jeder redet über Prozesse, jeder ist Teil von Prozessen, aber wie man von einer Prozessfokussierung tatsächlich massiv profitieren, Produktivität sowohl kurzfristig als auch nachhaltig steigern und neue Geschäftsmodelle umsetzen kann, ist weitestgehend unbekannt. Denn es geht nicht darum, dass wir Prozessdigitalisierung vorantreiben müssen, sondern wie es konkret umzusetzen ist!

Dazu müssen wir zunächst einmal verstehen, was bei neuen erfolgreichen digitalen Geschäftsmodellen tatsächlich passiert. Denn unglücklicherweise sind die Prozesse für den Endverbraucher größtenteils nicht sichtbar – sie sind in Software gegossen und werkeln im Hintergrund. Wir sehen als Endanwender lediglich die schönen neuen Plattformen à la Facebook, Apple, Netflix, Google, Amazon, Airbnb, Uber usw. Zur Realisierung mussten aber in allen Fällen ausnahmslos neue Prozesse in Form von Softwareprojekten umgesetzt werden. Allein Apple hat die Musikindustrie gleich doppelt verändert. Apple, von Haus aus ein Hardwarehersteller, kollaborierte seinerzeit auf einmal mit der Musikindustrie und warf mit der Einführung des iPods sämtliche existierende Geschäftsmodelle in dieser Branche über den Haufen. Kein Verkauf von Tonträgern mehr, sondern die Bereitstellung und der Verkauf von Musik in einem Online-Store. Ein genialer Schachzug – er wurde aber erst durch die begleitende Etablierung neuer Prozesse (z. B. Bereitstellung neuer Musikalben im iTunes Store, Abrechnung nach Nutzung usw.) zwischen einem Hardwarehersteller und den Unternehmen der Musikindustrie ermöglicht. Mittlerweile hat Streaming auch dieses Geschäftsmodell schon wieder abgelöst.

Gehen Sie gedanklich ruhig einmal die Geschäftsmodelle der anderen oben genannten Unternehmen durch. Netflix zum Beispiel: Wir sehen vordergründig wieder „nur“ die Plattform, die von Netflix zum Streamen von Filmen bereitgestellt wird. Die unzähligen Prozesse im Hintergrund, die diese neue Dienstleistung erst ermöglichten, sehen wir nicht. Aber nur weil wir sie nicht sehen, heißt das nicht, dass sie unbedeutend oder gar nicht vorhanden sind. Das genaue Gegenteil ist der Fall! In diesen zudem stürmisch wachsenden Geschäftsmodellen ist ein Überleben ohne einen extrem hohen Automatisierungsgrad durch die Prozessdigitalisierung undenkbar.

Die Allgegenwart von Prozessen

Warum schreibe ich Ihnen das? Weil wir die Allgegenwart und die fundamentale Bedeutung von voll automatisierten Prozessen verstehen und akzeptieren müssen. Gerade in der aktuellen Ära der Digitalisierung nimmt die Bedeutung von Prozessen weiter zu. Diese Abhängigkeit von Prozessen steigt durch einen im größer werdenden Anteil von Dienstleistungen in der Gesamtwirtschaftsleistung kontinuierlich an. Selbst klassische Produkthersteller erweitern ihr Portfolio um Dienstleistungen rund um ihre Produkte – alles aus einer Hand lautet das Motto. Denken Sie beispielsweise an den bevorstehenden rapiden Wandel in der Automobilindustrie. Sollten sich Elektromobilität und autonomes Fahren etablieren, ist eine deutliche Veränderung des Kundenverhaltens zu erwarten. So wird sich das Geschäftsmodell vom Verkaufen hin zum automobilen Dienstleister wandeln. Der Kunde mietet sich das zur aktuellen Situation passende Auto zu dem Zeitpunkt, an dem er es benötigt, und lässt es sich autonom vom Vermieter vorfahren. Es ist ein sonniger Tag und man möchte in die Natur zum Wandern fahren? Oder ein größeres Möbelstück ist zu transportieren? Kein Problem: Mit einem Klick ist ein Cabrio oder ein Kleinlaster für den Tag zu einer bestimmten Uhrzeit bestellt. Es fährt autonom vor und nach der Rückkehr steht es sofort für einen anderen Kunden bereit. Der Kauf von Autos ist für Kunden einfach nicht mehr attraktiv und zukünftig wohl nicht mehr das Kerngeschäft der Automobilindustrie. Typisch für Produkthersteller wird aber zukünftig die Kombination aus erstklassigem Produkt und dazu passenden kundenfreundlichen Dienstleistungen sein. Ermöglicht wird dies alles, wie könnte es anders sein, durch neue Prozesse.

Was passiert, wenn wir die Prozesse nicht beherrschen? Das erleben Sie und ich jeden Tag. Kürzlich wollte ich im Online-Banking eine Überweisung tätigen. Mein Limit für eine Online-Überweisung war jedoch um genau fünf Euro zu niedrig, sodass das System die Überweisung aufgrund von Limitüberschreitung ablehnte. Kein Problem, so dachte ich mir. Bei anderen Banken ist die Korrektur des Limits kein Thema. Nicht so bei dieser Bank. Ich selbst konnte die Anpassung nicht vornehmen und eine per Online-Chat zugeschaltete Mitarbeiterin durfte aufgrund von Sicherheitsrichtlinien diese Anpassung nicht vornehmen. Es war zutiefst frustrierend, neben der Zeit, die ich hierfür verschwendete. Werde ich bei dieser Bank bleiben? Wohl kaum. Zufälligerweise erhöhte genau diese Bank ihre Gebühren am Anfang des Jahres. Was zuvor kostenlos zur Verfügung stand, war nun kostenpflichtig. Weniger Leistung, dafür aber höherer Preis – das passt nicht zusammen. Über die Zukunftsaussichten dieser Bank lässt sich nun vortrefflich spekulieren …

Apropos Banken: Sie werden derzeit von sogenannten FinTechs überrollt – Unternehmen mit volldigitalen Geschäftsmodellen im Banking-Umfeld, die etablierte Banken mit ihren unprofitablen Geschäftsmodellen (siehe Deutsche Bank, die nur noch ein Schatten ihrer selbst ist) gefährden. Bezeichnend war auch der Wechsel im DAX im Jahre 2018: Commerzbank raus, Wirecard, eine dieser FinTechs, rein. Das erinnert mich an eine Aussage von Commerzbank-CEO Martin Zielke aus dem Jahre 2016, als er bei einer Handelsblatt Jahrestagung sagte: „Kunden erwarten von ihrer Bank zunehmend mehr Geschwindigkeit. Dafür müssen wir die im Hintergrund laufenden Prozesse verändern. Das ist der eigentliche Umbruch in der Branche. Es sind mehrere Tausend Prozesse, die wir weitgehend automatisieren müssen.“ [2]
Lassen Sie sich diese Worte auf der Zunge zergehen: Es ist von „mehreren Tausend Prozessen“ die Rede. Aber tatsächlich geht es bei der Digitalisierung für alle Branchen um nichts anderes!

Ähnliche Entwicklungen sehen wir bei Versicherungen (InsurTechs), Steuerberatern (TaxTechs), in der Reisebranche, im Gesundheitsbereich, Buch- und Verlagswesen usw. Es gibt nahezu keine Industrie, die nicht betroffen ist. Natürlich bieten sich auch im öffentlichen Bereich zahllose Beispiele für Prozessverbesserungen an. Es gibt kaum einen Behördengang, der kein Ärgernis ist. Sie wollen ein Haus bauen? Richten Sie sich schon mal auf lange Genehmigungsverfahren ein! Ein Auto zulassen? Ich saß kürzlich erst wieder mit meiner gezogenen Nummer über eine Stunde im Warteraum, bis ich schließlich an der Reihe war, mit dem Ergebnis, dass lediglich meine Unterlagen gescannt wurden. Ach ja, ein Dokument zum automatischen Einzug der KFZ-Steuer musste ich auch noch unterschreiben. Man muss kein Hellseher sein, um das baldige Ende dieses Prozesses zur KFZ-Anmeldung vorauszusagen.

Denken Sie nur an den Ansturm der Migranten: Waren die Behörden vorbereitet? Waren die Prozesse etabliert oder wurden zumindest innerhalb kürzester Zeit softwaretechnisch unterstützt? Abwrackprämie für Heizungen? Prozesse noch nicht etabliert. Jüngstes Negativbeispiel (16.02.2020): Betriebsrentner sollten eigentlich eine Entlastung bei ihren Betriebsrenten erfahren. Doch die Systeme sind noch nicht so weit. Grund: Die Kranken- und Versorgungskassen konnten ihre technischen Systeme nicht rechtzeitig umstellen [3]. Wann stehen die Prozesse dafür bereit? Dazu ein weiteres Zitat [3]: „Dies kann jedoch noch einige Monate dauern, vielleicht sogar bis zum Ende des Jahres 2020.“ Noch Fragen? Dabei bewirkt doch nahezu jede Gesetzesänderung Veränderungen an Prozessen, die von den betroffenen Organisationen schnellstmöglich umgesetzt werden müssen (man denke nur an die starke Regulierung der Banken nach der Finanzkrise).

All diese nicht funktionierenden Prozesse verhindern Produktivitätssteigerungen. Und die Liste ließe sich nahezu endlos fortsetzen und auch Ihnen fallen sicherlich zahllose Beispiele ein, bei denen Prozesse versagen. Umso dringlicher brauchen wir Lösungen!

Zwischenfazit soweit: Prozesse sind das Nervensystem unserer Wirtschaft. Sie sind allgegenwärtig, an ihnen hängt zu einem erheblichen Teil das Wohl und Wehe von Unternehmen und damit der Wohlstand der gesamten Gesellschaft. Die Digitalisierung stellt uns dabei vor neue Herausforderungen. Die Digitalisierung ist disruptiv, sie bricht mit Existierendem, sie ist vor allem schnell und sie ist existenzbedrohend. Zudem geht die Digitalisierung immer einher mit neuen Prozessen, die in immer kürzerer Zeit umzusetzen sind, damit Unternehmen ihren Wettbewerbsvorteil halten können. Davon sind letztendlich Unternehmen jeder Größe und aller Branchen betroffen.

Bisherige Lösungsmöglichkeiten zur Prozessdigitalisierung: Standardsoftware, neue Technologien, Programmierung

Nun stellt sich die Frage nach dem „Wie“. Wie können wir die genannten Herausforderungen der Prozessdigitalisierung meistern? Da Prozessumsetzungen größtenteils Softwareprojekte sind, es sich also im weitesten Sinne um ein Softwareproblem handelt, ist eine erste intuitive Reaktion der Unternehmen die Suche nach Standardsoftware. Wie der Name schon vermuten lässt, beinhalten diese Lösungen Prozesse von der Stange. Kunden können diese Lösung kaufen, nach einer kurzen Anpassung der Software an die Besonderheiten des jeweiligen Unternehmens sofort einsetzen und dadurch relativ kurzfristig Prozessverbesserungen erzielen. SAP ist mit diesem Konzept groß geworden und ist auch heute noch sehr erfolgreich damit. Problem dieser Vorgehensweise: Standardsoftware liefert auch nur Standardprozesse ab, die in allen Branchen oder zumindest innerhalb einer Branche nahezu identisch ablaufen, sonst lohnt sich deren Entwicklung für den Hersteller nicht. Standardsoftware liefert keine neuen Prozesse ab, sondern nur solche Abläufe, die sich sowohl branchenübergreifend als auch branchenspezifisch längst etabliert haben. Unternehmen können sich folglich mit Standardsoftware nicht von der Konkurrenz differenzieren. Sie können sich kein Alleinstellungsmerkmal erarbeiten. Sollte sich ein Unternehmen durch den Kauf von Standardsoftware einmal einen Vorteil verschafft haben, z. B. weil es die Software als erstes Unternehmen der Branche nutzt, so ist es doch für die Konkurrenz ein Leichtes, den Vorsprung durch Kauf genau dieser Software wieder aufzuholen. Daher ist Standardsoftware für die oben beschriebene Ausgangssituation, sich nämlich durch neue Prozesse von dem Wettbewerb zu unterscheiden, neue Geschäftsmodelle anzubieten, ganz sicher nicht der richtige Weg!

Nur um Missverständnisse zu vermeiden: Standardprozesse werden auch zukünftig ihre Bedeutung nicht verlieren, ganz im Gegenteil: Unternehmen tun gut daran, ihre Hausaufgaben zu erledigen und zumindest Standardabläufe wie beispielsweise die Finanzbuchhaltung, das Controlling, die Lagerhaltung, aber auch Personalprozesse wie die Lohnbuchhaltung oder das Recruiting durch Kauf von Standardsoftware zu automatisieren. Nur für die Differenzierung ist durch den Kauf von Standardsoftware eben keine Lösung zu erwarten.

Doch welche Alternativen bieten sich für die Differenzierung dann noch an? Und genau an dieser Stelle kommt nahezu unisono der Ruf nach Investitionen in neue digitale Technologien wie künstliche Intelligenz, Industrie 4.0, Big Data usw. (hier lassen sich jetzt beliebig viele IT-Schlagwörter ergänzen). Um es klar zu sagen: Technologien und technischer Fortschritt sind wichtig, keine Frage, aber sie sind am Ende nur Mittel zum Zweck. Die Lösung liegt im sachdienlichen Einsatz und der intelligenten Kombination von Technologien zu innovativen Abläufen. Es sind also abermals die Prozesse, die die Richtung vorgeben. Es sind Prozesse, die den Einsatz von Technologien den Weg weisen und nicht umgekehrt. Alles andere ist blinder Aktionismus. Aus eigener Erfahrung weiß ich nur allzu gut, wie sich Unternehmen von neuen IT-Trends verunsichern und blenden lassen. Ganz nach dem Motto „die Konkurrenz beschäftigt sich gerade mit Technologie xy; schauen wir doch mal, ob wir das auch nutzen können“ wird zu einer Technologie das Problem gesucht. Dieses Vorgehen ist leider völlig kontraproduktiv. Unternehmen müssen sich Gedanken darüber machen, wie sie sich und ihr aktuelles Geschäftsmodell gefährden können. Sie müssen sich selbst infrage stellen. Aus den gewonnenen Erkenntnissen dieses Gedankenexperiments müssen sie dann neue Prozesse für neue Geschäftsmodelle unter Zuhilfenahme der Technologien entwickeln. Wer mehr darüber erfahren möchte, wie man sein eigenes Geschäftsmodell attackiert, dem empfehle ich das sehr lesenswerte Buch von Christoph Keese mit dem Titel Disrupt Yourself [4].

Sind die neuen Prozesse erst einmal identifiziert, geht es an die Umsetzung. Wieder stellt sich die Frage nach dem „Wie“ und allgemein hat die IT-Branche keine wirklich gute Antwort auf diese drängende Frage. Prozesse werden am Ende des Tages noch immer programmiert. Daran hat sich über die letzten Jahrzehnte fundamental tatsächlich nichts geändert. Nur: Programmierung ist langsam, fehleranfällig, schwer zu warten, erschwert die Fehleranalyse und erlaubt während des Betriebs nahezu keinerlei Einblicke in den Zustand der aktuell laufenden Prozesse. Mit anderen Worten: Programmierung ist für die Prozessdigitalisierung denkbar ungeeignet. Wir befinden uns diesbezüglich, bildlich gesprochen, noch immer in der IT-Steinzeit. Wir stecken in einer Softwarekrise.

Der prozessgesteuerte Ansatz als neue Alternative zur Prozessdigitalisierung

Mittlerweile hat sich allerdings ein Vorgehen bei der Prozessdigitalisierung entwickelt, das unter dem zugegeben etwas sperrigen Namen „Prozessgesteuerter Ansatz“ (gerne auch mit PDA für „process-driven approach“ abgekürzt) eine Verbesserung dieser Situation verspricht. Sie ist neu und noch weithin unbekannt. Es handelt sich um eine Methodik, also keine Technologie, zur Umsetzung von Abläufen jeder Art, nicht nur die Umsetzung betriebswirtschaftlicher Prozesse (Ihnen wird sicherlich nicht entgangen sein, dass ich den weithin gebräuchlichen Begriff „Geschäftsprozess“ bewusst vermieden habe, da der prozessgesteuerte Ansatz viel weitreichender und somit nicht auf Geschäftsprozesse beschränkt ist). Ob in der Fabrik während der Produktion, in der Spielekonsole, im Auto, im Traktor, im Flugzeug, im Roboter, im Diagnosegerät, im Fernseher, in Städten und Gemeinden, natürlich in Unternehmen – Prozesse sind überall und genauso vielseitig ist der prozessgesteuerte Ansatz einsetzbar.

Welchen Hebel zur Produktivitätssteigerung und welche Vorteile verspricht nun der prozessgesteuerte Ansatz? Es sind nicht weniger als sieben Hebel, die der prozessgesteuerte Ansatz gleichzeitig (!) ermöglicht:

  1. Produktivitätssteigerung durch die neuen/verbesserten Prozesse selbst
  2. Produktivitätssteigerung bei der Abwicklung von Prozess-Digitalisierungsprojekten durch die Eliminierung von Missverständnissen in der Kommunikation zwischen Fach- und IT-Beteiligten (generell eines der größten Probleme bei der Umsetzung von Softwareprojekten)
  3. Produktivitätssteigerung bei der Erstumsetzung der Prozesse (wesentlich effizienter als Programmierung)
  4. Produktivitätssteigerung bei dem Betrieb der Prozesse
  5. Produktivitätssteigerung bei der Wartung und Weiterentwicklung der Prozesse
  6. Flexibilitätsverbesserung bei Veränderungen im Marktumfeld, bei neuen Wettbewerbssituationen/Geschäftsmodellen oder beim Auftauchen neuer Technologien. Dieser Punkt ist von besonderer Bedeutung, da dadurch auch die Hemmschwelle zur fundamentalen Änderung des Geschäftsmodells und der damit einhergehenden Änderungen an den Prozessen gesenkt wird.
  7. Transparenz: Unternehmen können visuell in Echtzeit nachvollziehen, wie ihre Prozesse ablaufen und verstehen, was in ihrem Unternehmen aktuell passiert

Sie fragen sich jetzt sicherlich, wie und warum diese Ergebnisse tatsächlich erreicht werden. Leider kann ich im Rahmen dieses Beitrags nicht auf die Details des Ansatzes eingehen, da er doch sehr IT-lastig ist und ich tief in das Thema Softwarearchitekturen eintauchen müsste. Was allerdings sehr einfach zu verstehen ist, ist der Grundgedanke des prozessgesteuerten Ansatzes. Denn tief im Kern beruht die Idee auf der direkten Ausführbarkeit von Prozessmodellen, ohne dass diese in großem Stil programmiert werden müssen. Ganz ohne Programmierung geht es naturgemäß nicht, der Aufwand reduziert sich jedoch in ganz massivem Maße, wie später an einem konkreten Projektbeispiel noch zu sehen sein wird. Lassen Sie mich den Gedanken der direkten Ausführbarkeit von Prozessmodellen anhand eines Beispiels erläutern. Schauen Sie sich dazu einmal das folgende Modell in Abbildung 1 an. Es handelt sich dabei um einen Prozess zur Auftragsabwicklung eines Handyvertrages mit Rufnummernmitnahme:

Abbildung 1: Prozess zur Auftragsabwicklung eines neuen Handyvertrags mit Rufnummernmitnahme

Wahrscheinlich sehen Sie ein solches Modell jetzt zum ersten Mal. Aber es ist nach kurzer Eingewöhnungszeit relativ einfach, sich darin zurechtzufinden. Der Prozess startet ganz links bei dem Kreis mit dem weißen Briefsymbol. Das Symbol verdeutlicht sehr schön den Grund des Prozessstarts, nämlich das Eintreffen einer Nachricht vom Kunden mit dem Handy-Neuantrag. Offensichtlich möchte der Kunde seine aktuelle Handynummer mitnehmen. Folgen Sie ausgehend von dem Kreis nun einfach dem schwarzen Pfeil nach rechts. Der Pfeil bestimmt letztendlich, wie der Prozess später auszuführen ist. Er legt die Abarbeitungsreihenfolge der einzelnen Schritte fest. Es wird also eine Auftragsbestätigung an den Kunden gesendet, gefolgt vom Versand einer Nachricht an den vorherigen Telefonanbieter des Kunden, damit dieser die Nummer freigeben kann. Nun folgt ein etwas komplizierterer Abschnitt, da drei unterschiedliche Szenarien abzubilden sind. Ursache dafür sind die Reaktionsmöglichkeiten des vorherigen Anbieters des Kunden (wir sind jetzt bei der Raute mit dem Kreis und dem darin enthaltenen Pentagon ):

  1. Der Anbieter bestätigt die Rufnummernmitnahme durch eine entsprechende Nachricht (oberer Pfad): Wir können unserem neuen Kunden die Rufnummernmitnahme bestätigen und die Auftragsabwicklung erfolgreich abschließen.
  2. Der Anbieter lehnt die Rufnummernmitnahme durch eine entsprechende Nachricht ab (mittlerer Pfad): Wir müssen unseren Neukunden über diesen Sachverhalt informieren und schließen die Abwicklung ohne Erfolg ab.
  3. Der Anbieter reagiert innerhalb von zwei Tagen nicht (unterer Pfad): Nun ist manuell einzuschreiten. Die Vertragsabteilung (achten Sie ganz links auf die Beschriftung des Rechtecks, in dem sich der Schritt befindet – sie legt die Rolle fest, die für die Ausführung des Schrittes verantwortlich ist) setzt sich telefonisch mit dem Anbieter in Verbindung und klärt den Sachverhalt. Der Prozess wird anschließend wieder zur Warteposition (der o. g. Raute) zurückgeführt und abermals auf die Reaktion des Anbieters gewartet.

Damit ist der Kern des Prozesses geklärt. Ergänzend habe ich noch das Verhalten bei Eintreffen einer Stornierung modelliert (im Modell rechts unten zu sehen). Da eine Stornierung jederzeit eintreffen kann, befindet sich die Behandlung eines solchen Ereignisses außerhalb des normalen Ablaufs. In jedem Fall ist auch dieses Mal die Vertragsabteilung mit der Abwicklung beauftragt, ehe der gesamte Prozess mit dem Resultat „Abbruch wegen Stornierung“ endet.

Sie sehen, im Grunde sind diese Modelle nicht schwer zu verstehen. Die verwendeten Elemente sind standardisiert und für jedermann, der die Notation beherrscht, leicht nachzuvollziehen. Der Standard nennt sich BPMN (Business Process Model and Notation) und hat sich mittlerweile längst in der Prozesswelt durchgesetzt. Das Besondere an BPMN: Die derart erstellten Modelle sind durch spezielle Software genauso, wie sie modelliert wurden, ausführbar. Mit anderen Worten: Das oben abgebildete Modell ist bereits der ausführbare Prozess, ohne dass für den Prozessablauf eine weitere Programmierung notwendig wird. Allein dies bringt ungeahnte Produktivitätssteigerungen für Prozessdigitalisierungen. Eine Programmierung ist nur noch bei den einzelnen Schritten selbst notwendig. Sie müssen mit Leben gefüllt werden, wie z. B. das Bereitstellen eines Eingabeformulars bei der Ausführung interaktiver Schritte (Schritt „Stornierung behandeln“ in Abbildung 1).

Damit die auf diese Weise erstellten Lösungen allerdings auch auf lange Sicht wartbar und flexibel anpassbar bleiben, braucht es aber noch weiteres Wissen. Und genau dies umfasst der prozessgesteuerte Ansatz: Er beschreibt im Detail sowohl das methodische Vorgehen als auch die Architektur derart erstellter Lösungen. Er ist Wegweiser für eine erfolgreiche und nachhaltige Prozessdigitalisierung.

Wie können Unternehmen von dem prozessgesteuerten Ansatz profitieren?

Die Verwendung des BPMN-Standards ist tatsächlich ein gewichtiger Grund, weshalb obige Vorteile erzielt werden. Dank der eindeutigen Prozessmodelle vermeidet man Missverständnisse bei der Kommunikation, da jedes Element eine eindeutige Funktion übernimmt und Fehlinterpretationen (ein immer wiederkehrendes Übel bei textuellen Beschreibungen) ausgeschlossen sind (Punkt 2 in obiger Liste der Vorteile). Da die Prozessmodelle unverändert zur Ausführung gelangen, gelingt die Erstumsetzung in einem Bruchteil der ursprünglichen Zeit (Punkt 3). Der Betrieb arbeitet während der Prozessausführung ebenfalls mit den Prozessmodellen und kann jederzeit Einblick in die aktuellen Prozesszustände nehmen. Fehler lassen sich einfacher finden und korrigieren (Punkt 4). Punkt 5, die Wartung und Weiterentwicklung der Prozesse, ist Folge des architektonischen Konzepts, das prozessgesteuerten Anwendungen zugrunde liegt: Sämtliche Entwicklungskomponenten sind wie Bausteine sorgfältig voneinander zu trennen und können separat entwickelt, erweitert und ausgetauscht werden – eine Art Lego-Baukasten für die Softwareentwicklung. Dieser Aspekt bildet gleichzeitig die Basis für Punkt 6, die Erhöhung der Flexibilität: Jede Komponente kann leicht gegen eine bessere ausgetauscht und Prozesse anhand ihres Prozessmodells schnell geändert und neuen Marktgegebenheiten angepasst werden. Last but not least ist allein die Sichtbarkeit der Prozessmodelle während des Prozessablaufs für das Management Gold wert (Stichwort Transparenz): Jederzeit Übersicht über die Prozesszustände zu besitzen, Kennzahlen im Blick zu haben und in Notsituationen gezielt eingreifen zu können sind von unschätzbaren Wert (Punkt 7).

Sie merken schon: Der Fokus prozessgesteuerter Projekte liegt eindeutig auf den Prozessen! Aber ist es nicht so, dass es für Unternehmen eigentlich nichts Wichtigeres geben sollte? Volle Konzentration auf das Geschäft und nicht auf IT. Der prozessgesteuerte Ansatz hat genau dieses Denken in Form einer Methodologie konsequent und kompromisslos umgesetzt. Die Prozesse bestimmen ausnahmslos alle Entscheidungen, sie geben die Antworten auf sämtliche Projektfragen, sie steuern das Projekt – daher auch der ungewöhnliche Name „prozessgesteuerter Ansatz“. Liegen die Prozesse dann erst einmal vor (und das ist tatsächlich harte Arbeit), ist die nachfolgende IT-Umsetzung größtenteils Routine, da der prozessgesteuerte Ansatz alles Weitere in einer Art „Blaupause“ (sozusagen eine methodische und architektonische Vorlage) vorgibt. Unternehmen müssen sie „nur noch“ anwenden.

Der prozessgesteuerte Ansatz in der Praxis

Die nächste Frage, die Ihnen zwangsläufig in den Sinn kommt, ist: Funktioniert das Ganze auch in der Praxis? Können die Versprechungen real erzielt werden? Hier möchte ich auf ein Projekt bei der SAP verweisen, das unter anderem in einem Webinar [5], in einer Online-Veröffentlichung der SAP [6] und seit Juli 2019 auch in Buchform [7] dokumentiert ist. In der Online-Quelle heißt es beispielsweise wörtlich: „Compared to traditional methodologies for implementing processes using programming languages such as ABAP and Java, the PDA approach has a time savings of roughly 75 %.“ Es wird dem Verfahren also eine Zeitersparnis von 75 Prozent attestiert. Lässt man sich diese Zahl durch den Kopf gehen, so bedeutet dies (im übertragenen Sinne), dass bei einer ursprünglichen Planung eines Großprojektes von 10 Jahren (Ihnen fallen bei dieser Größenordnung bestimmt die Erfolgsprojekte wie beispielsweise Flughafen Berlin, Stuttgart 21, Elbphilharmonie usw. ein ;-)) nach zweieinhalb Jahren jemand vorbeikommt und sagt, alles ist fertig (natürlich verbunden mit den entsprechend reduzierten Kosten). Das ist schon beeindruckend.

Im Projekt wurden 65 hochkomplexe Prozesse unter Einbindung von mehr als 700 externen Systemen innerhalb von 9 Monaten zur Ausführung gebracht [6][7]. Das ist für Softwareentwicklungsprojekte schon sehr sportlich. Details zum Projekt und den Prozessen sowie die aktuellen Zahlen finden sich in [7]. Neben des eingehaltenen Zeit- und Kostenplans sticht jedoch eine weitere essenzielle Eigenschaft des finalen Ergebnisses heraus: die Anpassbarkeit an Veränderungen. Aufgrund der modularen Architektur erlaubt der prozessgesteuerte Ansatz der SAP nun, auf Veränderungen schnellstmöglich zu reagieren, bis hin zum kompletten Austausch von Teilprozessen. Unternehmen bekommen also ihre Handlungsfähigkeit wieder zurück.

Leider lassen sich derartige Zahlen derzeit noch nicht verallgemeinern – dazu ist das Verfahren einfach noch zu jung. Trotzdem ist gerade dieses Projekt ein wichtiger Meilenstein für den prozessgesteuerten Ansatz, da er dessen Potenzial eindrucksvoll dokumentiert, zumal das Projekt zu der Zeit (2015) von einem in der prozessgesteuerten Methodik eher unerfahrenen Team gestemmt werden musste. Es sind also weitere Verbesserungen zu erwarten, wenn bei allen Beteiligten die prozessgesteuerte Vorgehensweise in Fleisch und Blut übergegangen ist.

Auch wenn es bei der SAP um ein Großprojekt ging, möchte ich den Einsatz der Methodik auch für Kleinprojekte betonen. Die Botschaft lautet: Jedes Unternehmen, egal welcher Größe, egal welcher Branche, kann von dem Ansatz profitieren und kann den Ansatz als neue strategische Waffe seinem Arsenal hinzufügen.

Erfolgsfaktoren beim Einsatz des prozessgesteuerten Ansatzes

Ich hoffe, mit diesem Beitrag Ihre Neugier bereits geweckt zu haben. Sicher fragen Sie sich, wie ein Einstieg in die Methodik konkret aussehen könnte und was kostet dies Unternehmen? Hier die gute Botschaft: Die Einstiegsbarrieren liegen vergleichsweise niedrig, da die benötigten technischen Voraussetzungen im Open Source-Bereich (und somit kostenlos) zur Verfügung stehen. Unternehmen müssen einzig in die Ausbildung ihrer Mitarbeiter investieren. Im Projekt bei der SAP wurde das gesamte Projektteam in den prozessgesteuerten Ansatz eingeführt, inklusive der Entscheidungsträger, da deren uneingeschränkte Unterstützung erfolgsentscheidend ist. Die PDA-Einführung wurde in Form eines 3-Tage-Workshops mit umfangreichen praktischen Modellierungsanteilen erreicht, den alle Teammitglieder zu durchlaufen hatten. Zur Ausbildung gehörte auch die Überführung der Prozessmodelle in eine Ablaufumgebung, sodass die Teilnehmer ihre Prozesse während der Abarbeitung beobachten und bei Problemen eingreifen konnten. Dadurch wurden Methodik, Arbeitsweisen, Architektur und das PDA-spezifische Vokabular trainiert. Da der prozessgesteuerte Ansatz sehr viel Wert auf die enge Zusammenarbeit von Fach- und IT-Abteilung legt, hängt der Erfolg von zwei Schlüsselpositionen ab: Je einen „Evangelisten“ des prozessgesteuerten Ansatzes auf Fach- und IT-Seite, die eng kooperieren und als Multiplikatoren für ihre jeweiligen Kollegen und Kolleginnen dienen. Ergänzt wird dieses Set-up um einen erfahrenen PDA-Berater, der bei dem Projekt als Sparringspartner zu allen Fragen des prozessgesteuerten Ansatzes bereitsteht und sowohl Fortschritt als auch Qualität überwacht. Derart aufgestellt sind die Voraussetzungen für einen erfolgreichen Projektverlauf gegeben. Weitere Details für Interessierte finden sich in [7].

Wie passen künstliche Intelligenz und prozessgesteuerter Ansatz zusammen?

Ein Thema darf bei dieser Diskussion natürlich nicht fehlen: die künstliche Intelligenz (KI). Ist sie nicht der lang erwartete digitale Heilsbringer? Die Antwort lautet: Ja, aber! Die künstliche Intelligenz ist ein wichtiges Thema, keine Frage und sie wird in vielen Lebensbereichen Erleichterungen bringen. Man muss sich allerdings schon sehr wundern, welch Hype dieses Thema aktuell entfacht. Es scheint ja gerade so, als ob die Zukunft der ganzen Welt einzig und allein von KI abhinge. So ist es ganz sicher nicht. Betrachtet man KI nüchtern, so gehört KI zu den Lösungen zur Erkenntnisgewinnung und sie kann auf diese Weise zur Entscheidungsfindung in Prozessen beitragen. So diagnostiziert laut einer neuesten Studie des „Skin-Classification-Projects“ [8] des Deutschen Krebsforschungszentrums (DKFZ) KI den schwarzen Hautkrebs präziser, als Hautärzte es können [9]. Das Spannende ist aber doch, welche Handlung wir der Erkenntnis folgen lassen! Wie ist also zu handeln, wenn eine entsprechende Diagnose gestellt wurde? Genau an diesem Punkt kommen die Prozesse wieder ins Spiel. Prozesse können auf Erkenntnisse reagieren, die durch eine KI festgestellt wurde, und Handlungen automatisiert einleiten. Isoliert betrachtet ist KI nur halb so wertvoll. Erst durch die Kombination mit Prozessen kann sie ihren ganzen Nutzen ausspielen. Die beiden Ansätze widersprechen sich also nicht oder ersetzen einander. Sie sind komplementär und ergänzen sich prächtig. So kann KI innerhalb von Prozessen Entscheidungen aufgrund des Erkenntnisgewinnes direkt einbringen oder zumindest Entscheidungen vorbereiten, die anschließend durch Experten (in unserem Beispiel der Krebserkennung nahe liegender Weise der Arzt) nachzuverfolgen sind. Sie sehen: Erkenntnisgewinnung und Handlungsableitung sind zwei Seiten ein und derselben Medaille und Prozesse sind auch in diesem Fall ein entscheidender Erfolgsfaktor.

Der prozessgesteuerte Ansatz als Digitalisierungskatalysator

Damit nähere ich mich dem Ende meines Blog-Beitrags. Halten wir zusammenfassend fest:

  • Prozesse sind allgegenwärtig.
  • Digitalisierung und innovative Prozesse sind untrennbar miteinander verflochten.
  • Geschwindigkeit sowohl bei der Erstumsetzung von Prozessen als auch bei der Anpassbarkeit an geänderte Marktbedingungen ist in der Digitalisierungsära entscheidend.
  • Programmierung ist zur Bewältigung der Herausforderungen keine zeitgemäße Alternative mehr. Aber es gibt eine neue Option: Der prozessgesteuerte Ansatz weist den Weg zu einer effizienten und nachhaltigen Prozessdigitalisierung.
  • Achten Sie bei Ihren Prozessdigitalisierungsprojekten auf die Anwendung des prozessgesteuerten Ansatzes. Fordern Sie von Ihrem Dienstleister explizit den Nachweis einer prozessgesteuerten Ausbildung ein (z. B. über ein Zertifikat) oder kontaktieren Sie mich bei Zweifeln direkt (info@volkerstiehl.de).
  • Gerade der deutschsprachige Raum ist aufgrund seiner Prozesshistorie prädestiniert für den Einsatz des prozessgesteuerten Ansatzes und kann daher als Erster davon profitieren.

Die disruptive Digitalisierung und die aufgrund des demografischen Wandels dringend benötigte Produktivitätssteigerung sind über Prozesse auf allen Ebenen (von der Management- bis zur Maschinen- und Roboterebene) zu bewältigen. Natürlich können Prozesse lediglich ein Baustein in den Maßnahmen zur Produktivitätssteigerung eines Unternehmens sein. Aber, und das sollte deutlich geworden sein, handelt es sich um einen sehr gewichtigen Baustein mit großer Reichweite und enormer Hebelwirkung.

Zum Schluss meine Bitte an Sie: Denken Sie über die skizzierten Möglichkeiten nach, sondieren Sie die Anwendung des prozessgesteuerten Ansatzes auch in Ihrem Umfeld und (natürlich) tragen Sie zur Verbreitung des Wissens um den prozessgesteuerten Ansatz bei. Ich bin mir sicher, der Ansatz besitzt das Potenzial, als ein wichtiger Baustein signifikant zu der Produktivitätssteigerung beizutragen, die unsere Wirtschaft zum Wohle aller so dringend benötigt. Wir brauchen tatsächlich eine neues Prozessdenken in den Unternehmen, ein Denken der gelebten Prozesse, eine neue Prozessinitiative.

Sollte ich Ihr Interesse geweckt haben, so empfehle ich Ihnen folgende beiden Webinare von jeweils ca. einer Stunde Dauer:

Webinar zur Digitalisierung mit dem „Prozessgesteuerten Ansatz“ (Teil 1 – Motivation, Einführung) [10]

Webinar zur Digitalisierung mit dem „Prozessgesteuerten Ansatz“ (Teil 2 – Architektur, Nutzen, Live-Demos) [11]

Sie finden in den Webinaren weitere Anregungen zur Vertiefung. Für weiterführende Diskussionen erreichen Sie mich auch unter info@volkerstiehl.de.

Mein Ziel ist es, ein wenig Zuversicht in Sachen Produktivitätssteigerung durch Prozessdigitalisierung zu verbreiten, so wie dies eingangs Robert Plant mit seiner Ansage zu Stairway to heaven bei seinem Publikum versuchte. Die allgemeine wirtschaftliche Situation ist sicherlich nicht einfach, aber uns steht mit dem prozessgesteuerten Ansatz eine vielversprechende Option zur Verfügung. Zu hoffen ist, dass sich die Idee des prozessgesteuerten Ansatzes so viral wie seinerzeit Stairway to heaven verbreitet. Ich jedenfalls hole mir jetzt das Album aus meiner Plattensammlung hervor und freue mich auf gut 10 Minuten feinste Rockmusik …

Quellen:

[1] https://think-beyondtheobvious.com/deutschlands-prekaere-wachstums-und-produktivitaetsentwicklung/

[2] https://blog.commerzbank.de/finanzwelt/16q3/handelsblatt-tagung-2016.html

[3] https://www.tagesschau.de/inland/betriebsrenten-entlastung-101.html

[4] Keese, Christoph: Disrupt Yourself. Vom Abenteuer, sich in der digitalen Welt neu erfinden zu müssen. München: Penguin Verlag, 2018, ISBN-13: 978-3328600336

[5] https://youtu.be/txUSOCgFqUQ

[6] http://sapinsider.wispubs.com/Assets/Articles/2016/January/SPI-managing-modern-business-processes

[7] Stiehl, Volker, Marcus Danei, Juliet Elliott, Matthias Heiler und Torsten Kerwien: Effectively and Efficiently Implementing Complex Business Processes: A Case Study, in: Lübke, Daniel und Cesare­ Pautasso (Hrsg.): Empirical Studies on the Development of Executable Business Processes. 1. Auflage. Cham: Springer, 2019, S. 33-57

[8] https://www.researchgate.net/project/Artificial-Intelligence-in-Skin-Lesion-Diagnosis-The-Skin-Classification-Project

[9] https://medtech-zwo.de/aktuelles/nachrichten/nachrichten/ki-erkennt-hautkrebs-praeziser-als-aerzte.html

[10] https://www.signavio.com/de/events/digitalisierung-mit-prozessgesteuerten-ansatz-022019/

[11] https://www.signavio.com/de/events/webinar-prozessgesteuerter-ansatz-architektur-nutzen-062019/

 

 

Kommentare (37) HINWEIS: DIE KOMMENTARE MEINER LESERINNEN UND LESER WIDERSPIEGELN NICHT ZWANGSLÄUFIG DIE MEINUNG VON BTO.
  1. Christian K.
    Christian K. sagte:

    Super Ausführungen in aktuell sehr relevantem Kontext, Danke!
    Besonders relevant erachte ich zwei weitere Aspekte, die unter den Prozessbegriff i.A. fallen und für die PDA ein großes Potential bietet:
    – Technische Prozesse in Produktion, Logistik und Servicemanagement werden auch orchestriert und sind heute manuell verschalten oder unflexibel in Software gegossen (und: nein, ich meine damit nicht echtzeitfähige Steuerungs- und Regelungsprozesse, sondern die darüberliegende Prozessebene
    – Partnerübergreifende Prozesse im Geschäftsnetzwerk können systemübergreifend gemeinsam definiert und implementiert werden.
    Außerdem ist es wichtig, (technische und semantische) Anbindungspunkte (‘Services’) in allen anzuknüpfenden Komponenten zu definieren – mit SOA/Webservices/Microservices ist da schon viel passiert, aber noch sehr viel zu tun.

    Antworten
  2. Markus M.
    Markus M. sagte:

    Aus meiner Sicht sind hier noch zwei wichtige Aspekte wichtig, die miteinander in Wechselwirkung stehen und im Artikel auch nur sehr vage angeschnitten wurden:
    1. Unternehmenskultur: Nach meiner Erfahrung als Informatiker mit Aufbaustudium in „Interkultureller Kommunikation“ sind solche Ansätze einfacher umzusetzen, wenn das betreffende Unternehmen eine Tech-DNA besitzt, d. h. die Gründer und auch die aktuellen Geschäftsführer eine Informatik-Ausbildung haben und dadurch das Unternehmen häufig von Beginn an darauf konditioniert ist Prozess- und Service-orientiert zu denken. Sollte dies nicht der Fall sein, ist es häufiger einfacher mit einer Tech-DNA noch einen entsprechenden Wandel zu initiieren. Eine solche DNA erleichtert auch häufig das Abtragen oder sogar das Nicht-Entstehen von technischen Schulden, weil in einer solchen Organisation oftmals ein langfristigerer Zeithorizont existiert, als häufig in sehr ergebnisorientierten Konsumgüter- oder Marketing-Unternehmen. Das stellt auch eine Parallele zu den monetären Schulden dar, die häufig durch eine recht kurzfristige und konsumgetriebene Sichtweise entstehen.
    2. Organisationsstruktur: Aus meiner Sicht muss die Organisation entlang der unterschiedlichen Prozessketten strukturiert werden, d. h. es müssen die unterschiedlichen an einem Prozess beteiligten Rollen interdisziplinär in einem Team / Abteilung zusammengefasst werden, was auch im Kontext mit Conway’s Law zutreffen muss: Das Organisations-Design spiegelt die Kommunikationsstruktur in einem Unternehmen wieder. In einem Software-Unternehmen gestalten nun diese Kommunikationsmuster wiederum im Wesentlichen die Software-Architektur. Es wäre in diesem Zusammenhang auch denkbar, dass zusätzlich zur bestehenden Aufbauorganisation eine Prozessorganisation etabliert wird, in dem die eigentlichen Prozesse dann operativ über alle technischen, operativen Rollen sowie der Produkt-Management-Rolle sowie über alle Kanäle (Web, Mobile, Interfaces) hinweg umgesetzt werden, was dann in einer Matrix-Organisation resultiert.
    Deshalb kann der PDA als Zielbild dienen, am Anfang sollte aber immer das Organisations-Design stehen.

    Antworten
    • Dietmar Tischer
      Dietmar Tischer sagte:

      @ Markus M.

      >…am Anfang sollte aber immer das Organisations-Design stehen.>

      Meiner Erfahrung nach sollte am Anfang IMMER etwas anderes stehen:

      Eine für das Unternehmen verbindliche und an die Mitarbeiter soweit wie möglich in der Hierarchie nach unten vermittelte und von ihnen verfolgte ZIELVORSTELLUNG wie etwa:

      In dieser sich verändernden Welt stehen wir HIER und wollen mit Leistungen X bei Zielgruppen Y erfolgreich sein.

      Damit ergeben sich Identität und Selbstverständnis des Unternehmens und seiner Mitarbeiter.

      An der Zielvorstellung richtet sich ALLES andere aus – die Stellung im Markt (Positionierung), Unternehmenskultur, Organisationsstruktur, Ressourcengewichtung etc.

      IT hat da einen bestimmten Platz, ist MITTEL wie andere Mittel auch, die für die Zielerreichung eingesetzt werden.

      Welchen Platz die IT-Abteilung mit welcher Gewichtung einnimmt, d. h wie sie ausgestattet ist und welche Kompetenzen sie hat, hängt ganz wesentlich von dem ab (in „offenen“ Unternehmen), was das IT-Management für die Zielerreichung anbieten kann.

      DAVON hängt wiederum der Einsatz oder Nichteinsatz bzw. das wieviel PDA ab.

      Heißt:

      PDA hat eine GEWICHTUNG im KONTEXT.

      Es kann dabei durchaus zur REFERENZ aufsteigen – aber nur im Rahmen des Kontexts, in dem es funktional wirkt – eben „seiner“ IT-Welt im Unternehmen Z:

      Überlegene Methodik (Verfahren), um zu „dienlicheren“ Softwarelösungen zu gelangen.

      INSOWEIT, aber auch nur insoweit kann PDA als Zielbild dienen.

      Aber natürlich auch das:

      Genaues, richtiges PROZESSVERSTÄNDNIS als VORAUSSETZUNG für PDA und damit Teil von PDA kann sich natürlich verselbständigen und auch dort eine Operationsbasis sein, wo IT praktisch keine Relevanz hat.

      Antworten
      • Markus M.
        Markus M. sagte:

        @Dietmar Tischer: > Eine für das Unternehmen verbindliche und an die Mitarbeiter soweit wie möglich in der Hierarchie nach unten vermittelte und von ihnen verfolgte ZIELVORSTELLUNG >
        Sie haben natürlich Recht, dass man im Gesamtkontext die Vision und die sich daraus abgeleitete Strategie an den Anfang setzen sollte, nur IMMER unter der Einbeziehung der Kenntnis der eigenen Unternehmenskultur. Denn die Umsetzbarkeit der Strategie wird maßgeblich von dieser beeinflusst. Wie hat schon Peter Drucker geschrieben: “Culture eats Strategy for breakfast.” Sprich, wenn die propagierte Strategie nicht zur im Unternehmen vorhandenen Kultur passt, wird diese bei ihrer Umsetzung IMMER scheitern.
        Und die Organisationsstruktur wiederum ist eben auch ein maßgeblicher Faktor (einer von mehreren wie Kommunikation, Führungs- und Management-Stil, etc.) zur Gestaltung der Unternehmenskultur. Alle genannten Faktoren stehen wahrscheinlich in der Realität in wechselseitiger Abhängigkeit zueinander. Insofern steht also auch die Formulierung der Strategie nicht zwangsläufig immer am Anfang, sondern ist wohl auch vom Reifegrad und Entwicklungsstand des betreffenden Unternehmens abhängig.

        >IT hat da einen bestimmten Platz, ist MITTEL wie andere Mittel auch, die für die Zielerreichung eingesetzt werden.<
        Und auch da würde ich sagen: Kommt auf die DNA bzw. Kultur des Unternehmens an: Reden wir von einem originären Technologie-Unternehmen, wird der Einsatz oder die Entwicklung von (neuen) Technologien ein wesentlicher Treiber der Strategie sein, hingegen bei anderen Unternehmen nur ein Mittel zum Zweck zur Umsetzung der vorher ausformulierten Strategie bzw Ziele.

  3. Horst
    Horst sagte:

    „Jedes Unternehmen, egal welcher Größe, egal welcher Branche, kann von dem Ansatz profitieren und kann den Ansatz als neue strategische Waffe seinem Arsenal hinzufügen.“

    An dem Punkt bin ich vorerst ausgestiegen. Lieber Herr Professor Diehl, vielleicht mögen Sie erklären, wie die Unternehmen im Kampf um Kunden, Märkte und Rendite Vorteile erzielen (können), wenn es, wie Ihrerseits gewünscht, alle Unternehmen parallel umsetzen?

    Hinkt der Vergleich zum Marketing?

    Dies entbehrt freilich nicht der Tatsache, dass jedes Unternehmen früher oder später im zeitlichen Verlauf um eine Einführung nicht herumkommt, da a) der Mitbewerber diese bereits umgesetzt hat und b) das Unternehmen wohl weiterhin leisten oder produzieren möchte.

    ad Thomas, Herr Diehl:

    Die Sicht ihres Kontaktes würde mich interessieren, wie er sich ein Gesellschaftsmodell vorstellt (wer soll wie dessen Produkte oder Leistungen zukünftig erwerben?) in dem er diejenigen Mitarbeiter, die dessen Ansicht nach nicht mehr produktiv genug sind, austauscht, respektive entlässt und warum, da er gleichzeitig sich darüber beklagt, nicht genügend Fachkräfte akquirieren zu können, er diese nicht selbst ausbildet?

    Antworten
    • V. Stiehl
      V. Stiehl sagte:

      “An dem Punkt bin ich vorerst ausgestiegen. Lieber Herr Professor Stiehl, vielleicht mögen Sie erklären, wie die Unternehmen im Kampf um Kunden, Märkte und Rendite Vorteile erzielen (können), wenn es, wie Ihrerseits gewünscht, alle Unternehmen parallel umsetzen?”

      PDA in den Unternehmen parallel einzusetzen wäre in der Tat fast zu schön um wahr zu sein ;-). Ich befürchte jedoch, dass ich das nicht mehr erleben werde. Allerdings mag ich über derartige Aussichten jetzt auch nicht spekulieren.
      Lassen Sie mich einige Gedanken dazu mit Ihnen teilen:
      Zunächst müssen wir verstehen, dass PDA wie ein neues Werkzeug zu sehen ist. Um also Vorteile erzielen zu können, kommt es primär auf die Idee an, was Sie konkret mit dem Werkzeug umsetzen wollen. PDA ist ja nicht die Lösung selbst. PDA hilft der Unternehmung lediglich dabei, diese Ideen dann effizienter umzusetzen. Und auf eine effizientere Lösung (nämlich PDA) zu verzichten, nur weil die Gefahr besteht, dass andere es auch nutzen, ergibt doch keinen Sinn. Ein Unternehmen kann es sich einfach nicht leisten, ineffizienter zu arbeiten als die Konkurrenz. Und wenn das am Ende des Tages bedeutet, dass alle PDA einsetzen, was ist so schlimm daran? Wichtig ist aus meiner Sicht lediglich, dass wir die Ersten sein sollten!
      Denn natürlich profitieren Unternehmen am meisten, wenn sie jetzt auf PDA setzen, denn dann profitieren sei vom FMA (First Mover Advantage). Da gerade der deutschsprachige Raum aufgrund seiner Historie (ich erinnere hier an die herausragende Leistung von Prof. Scheer) prozessafiner als die restliche Welt ist, könnte die hiesige Wirtschaft als First Mover den Vorsprung anderer Länder bei der Produktivität verringern. Gebrauchen könnten wir es.
      Der First Mover hat einen weiteren wichtigen Vorteil: Er sammelt Erfahrung beim Umgang mit diesem neuen Werkzeug und kann seinen Vorsprung stetig ausbauen. Deshalb ist es mir im Hinblick auf unsere Wirtschaft auch so wichtig, dass wir JETZT beginnen – jetzt ist die Zeit reif. Schließlich stehen wir in einem scharfen internationalen Wettbewerb.

      Bedenken Sie auch einmal den Vorteil einer einzelnen Unternehmung, wenn sie morgen auf PDA umsteigen würde: Woher sollte die Konkurrenz überhaupt mitbekommen, wie die Prozesse, die ja im Hintergrund arbeiten, konkret umgesetzt wurden? Nach Außen werden Sie eine Anwendung, die mit PDA erstellt wurde, von einer herkömmlich programmierten Lösung nicht unterscheiden können. Dies ist ein weiterer wichtiger positiver Nebeneffekt! Unternehmen werben mit ihren Produkten und Dienstleistungen – Neuerungen in den Angeboten sind für die Konkurrenz leicht zu erkennen und ggf. zu kopieren. Ich erinnere an dieser Stelle immer gerne an Steve Jobs’ grandiose Präsentation des iPhones aus dem Jahre 2007 (unbedingt ansehen – Gänsehautgarantie). Er glaubte an einen Vorsprung von 5 Jahren gegenüber der Konkurrenz. Wie schnell dieser technologische Vorsprung zusammenschmolz, wissen wir alle nur zu gut. Sie haben aber bestimmt noch kein Unternehmen gesehen, das mit tollen Prozessen wirbt. Mit anderen Worten: Ein differenzierender Vorteil, den eine Unternehmung in seiner Prozesswelt erarbeitet, ist nachhaltiger als ein differenzierender Aspekt in seinen Produkten und Dienstleistungen, eben weil er von der Konkurrenz extrem schwer zu erkennen und zu kopieren ist! Diesen Trumpf sollten Unternehmen ausspielen!

      Danke nochmals für Ihren Kommentar und ich hoffe, ich konnte meinen Standpunkt verständlich erklären.

      @Administrator: Ich habe auch auf andere Beiträge bereits ausführlich geantwortet, kann meine Kommentare aber nirgends finden. Könnten Sie dem bitte nachgehen? Danke!

      Antworten
  4. JürgenP
    JürgenP sagte:

    Korrektur:
    >> Nice to have, fun to play (for professionals). <Letztendlich müssen Sie sich das wie einen chirurgischen Eingriff in einem hochkomplexen System vorstellen. Das macht man nicht mal so eben nebenbei.Prozesse sind das Nervensystem unserer Wirtschaft.<

    Antworten
    • Dietmar Tischer
      Dietmar Tischer sagte:

      @ JürgenP

      >Nice to have, fun to play (for professionals).>

      Es ist mir klar, dass dies eine flapsige Bemerkung ist, die für sich genommen – dem Kontext meiner weiteren Ausführungen entrissen – missverständlich ist.

      Ich möchte sie als RELATIVIERUNG von PDA verstanden wissen mit Blick auf das zumindest suggestive „Versprechen“, DAMIT die gesamtwirtschaftliche Produktivität deutlich steigern zu können.

      Andere Parameter und Wirkmechanismen sind m. A. n. zumindest in der Summe wichtiger, auch wenn unbestreitbar ist, dass die Digitalisierung ein wesentlicher, wenn nicht der wesentlichste technologische Faktor für die zukünftige Produktivität und damit auch Wertschöpfung ist.

      Er hat damit hohe Bedeutung.

      Soweit zur Einordnung.

      Zu „Eingriff in ein hochkomplexes System“:

      Das System der Volkswirtschaft ist INSGESAMT gesehen hochkomplex und man sieht ja anhand der Krise, dass bereits EINFACHE Eingriffe wie „Läden schließen“ enorme Wirkungen auslösen mit Folgen, die mit normalen Mitteln nicht zu beherrschen sind.

      Verglichen damit geht es bei PDA um PUNKTUELLE Eingriffe, die eine OPTIMIERUNGSSTRATEGIE in einem zwar auch komplexen, aber dennoch ÜBERSCHAUBAREN Kontext verfolgen.

      Das erfolgt selbstverständlich „chirugisch“, d. h. “handwerklich” mit hoher Kompetenz (Informatik!) bis hin zu einer Abschätzung von Chancen und Risiken, insbesondere dann, wenn es nicht um konstante Prozesse geht, sondern solche mit moving targets.

      Heißt unterm Strich:

      Verfolgt und unterstützt werden muss bezüglich PDA eine bottom up-Strategie, d. h. punktuelle Lösungen, die sich auf Basis erfolgsbezogener Verifizierung sozusagen beschleunigend durch das Gesamtsystem arbeiten.

      Offen ist, was dies in der Interaktion mit anderen Wirkmechanismen für das Gesamtsystem bewirkt.

      Sicher ist für mich, dass die Einzelzielsetzungen und die gesamtgesellschaftlichen Zielsetzungen sich durch eine Methodik wie PDA direkt nicht beeinflussen lassen.

      PDA wird nie ein gesamtgesellschaftliches Ziel sein.

      Allenfalls läuft es mit, wenn das Ziel ist “mehr Digitalisierung im Gesamtsystem”.

      Das unterscheidet diese Methodik von einem Impfstoff, mit dem Immunität gegen das Coronavirus bewirkt werden kann.

      Ihn möglichst schnell zu entwickeln und einsetzen zu können, ist ein gesamtgesellschaftliches Ziel, das man top down nahezu kompromisslos – gerade auch mit Blick auf zeitraubende klinische Tests – zu erreichen suchen wird.

      Antworten
      • JürgenP
        JürgenP sagte:

        @ DT
        >> Andere Parameter und Wirkmechanismen sind (…) wichtiger, auch wenn unbestreitbar ist, dass die Digitalisierung ein wesentlicher, wenn nicht der wesentlichste technologische Faktor für die zukünftige Produktivität und damit auch Wertschöpfung ist. <<

        Diese Aussage trifft m.E. den Kern und stellt sogleich die Prämisse der Anwendung jeglicher IT-Lösung auf.

        Unter Komplexitätsbedingungen heißt „schneller“ heißt nicht „besser“ zu programmieren und „variabel“ auch nicht automatisch „richtig“ zu handeln. Das gilt auch für die hier vorgestellte IT-Methodologie, deren Hintergründe sich für mich noch nicht erschließen.

  5. JürgenP
    JürgenP sagte:

    @ Dr. Stelter,
    Es ist sehr gut, dass Sie in Ihrem Blog auch ein solches Thema zur Sprache bringen.

    @ Herr Tischer
    In Ihrer unnachahmlichen Art nehmen Sie Inhalte und Zusammenhänge auseinander und zeigen auch „die“ andere Sichtweise auf. Das Resumee zum Potenzial des Produktivitätswachstums der angesprochenen IT-Lösung lautet:

    Nice to have, fun to play (for professionals).
    Vermutlich habe Sie gewisse Praxiserfahrungen mit neuen Methoden der IT. Was ist daran neu, dass Prozesse – besser Prozessmechanismen – in IT-Lösungen umgesetzt werden?

    In dem Artikel von Prof. Stiehl ließ mich folgender Satz aufhorchen:

    “Letztendlich müssen Sie sich das wie einen chirurgischen Eingriff in einem hochkomplexen System vorstellen. Das macht man nicht mal so eben nebenbei.”

    An anderer Stelle seht:
    “Prozesse sind das Nervensystem unserer Wirtschaft.”

    @ Prof. Stiehl
    Zu meinem Verständnis: das Nervensystem, bestehend aus Kabeln u.dgl. (Technik) oder Nervenbahnen (Synapsen) ist sind Vernetzungen, deren grundlegenden Konstruktionsmerkmale relativ gleich sind. Was sich darin abspielt sind Informationsübertragungen zur Lenkung von Prozessen mit einer unendlichen Vielfalt von Verhaltensmustern, einer immensen Dynamik und Veränderbarkeit.

    Diese Vielfalt nehmen wir als „Komplexität“ war.

    Sie haben nun, so verstehe ich Ihren Beitrag, eine „effiziente, effektive, praktikable und gleichzeitig nachhaltige Methodologie“ entwickelt, um einen „chirugischen Eingriff“ in bestehende und/oder neue komplexe Systeme ohne Probleme (?) vornehmen zu können.

    Meine erste Frage an IT-ler mit neuen Programmen lautet: „Kennen Sie die physikalische Grenze der IT und können Sie diese ins Verhältnis setzen zur Komplexität des Systems, in welches mit der Lösung eingegriffen werden soll?

    Meine zweite Frage zielt auf die Qualität der Lösung: „Unter welchen Systembedingungen wurde die IT-Lösung mit welchem Ergebnis erprobt: einfache, komplizierte, komplexe oder chaotische“.

    Da Sie von Methodologie sprechen noch eine dritte Frage: „welches Verständnis vom Management komplexer Systeme verfolgt diese Methodologie?“.

    Antworten
    • V. Stiehl
      V. Stiehl sagte:

      …Ihre Fragen lassen darauf schließen, dass es eine längere Konversation werden könnte. Dürfte ich Sie bitten, mir an meine o.g. Email-Adresse zuschreiben? Ich würde gerne mit Ihnen das Thema vertiefen, ggf. auch telefonisch.
      Recht herzlichen Dank!

      Antworten
  6. Dietmar Tischer
    Dietmar Tischer sagte:

    Vorbemerkung:

    Ich habe der ausführlichen Argumentation wegen drei Kommentare geschrieben.

    Ich empfehle an dem Thema Interessierten mit dem hier anschließenden Kommentar 1 zu beginnen und mit Kommentar 3 zu enden, sie also der Reihe nach am Thread von „oben nach unten“ zu lesen.

    Kommentar 1

    Erst einmal danke ich Dr. Stelter dafür, dieses Blog für neue Lösungsvorschläge und damit auch Diskussionsansätze, die aus dem Rahmen enger ökonomischer Betrachtungen fallen, zu öffnen.

    Unsere Welt ist zu komplex und zu gefährdet, als dass wir uns mit einer nur ökonomischen Nabelschau – und sei sie noch so erhellend – begnügen könnten.

    Herrn Prof. Dr. Stiehl danke ich für sein Engagement, uns hier am Blog mit einem beachtlichen Konzept die Augen für innovative Produktivitätssteigerungen zu öffnen.

    Sein Gastbeitrag wirft unterschiedliche Fragen auf, die auf mehreren Ebenen zu würdigen und zu bewerten sind.

    Das betrifft nicht nur den Staat und die Unternehmen als unterschiedliche Operationsfelder für die von Prof. Dr. Stiehl dargelegte Methodik PDA.

    Es geht bei dieser Methodik auf noch abstrakterer Ebene um die Einordnung von Prozessen in einem System unterschiedlicher Phänomene, die in Bezug zueinander stehen.

    Ich werde versuchen, meine Ansichten dazu in diesem und anhand zweier weiterer Kommentare in verständlicher Form darzulegen.

    Dabei beziehe ich mich auf Aussagen von Prof. Dr. Stiehl.

    In diesem Kommentar kritisiere ich eine Auffassung, die zwar nicht im Mittelpunkt des Gastbeitrags steht und auch keinen Anlass gibt, PDA zu kritisieren oder abzuwerten, aber m. A. n. falsch und damit irreführend ist.

    Es geht um folgende Aussage:

    >Ja, es gibt nicht nur monetäre Schulden, auch in der Informatik gibt es Schulden – eben technische Schulden. Sie bedeuten umgangssprachlich ausgedrückt: IT-Abteilungen haben in der Vergangenheit ungeeignete Methoden und Technologien eingesetzt sowie Maßnahmen ergriffen, die als Folge eine schlechte Wartbarkeit und Anpassbarkeit der erstellten Softwarelösungen an (und damit schlechte Reaktionsfähigkeit auf) neue Herausforderungen mit sich bringen.>

    Monetäre Schulden und „technische Schulden“ (im hier verstanden Sinn) können nicht gleichgesetzt werden.

    Es gibt keine “technischen Schulden”.

    Der Begriff ist eine Metapher.

    Meine Begründung*:

    Monetäre Schulden existieren aufgrund einer FREIWILLIG eingegangenen VERPFLICHTUNG, zukünftig eine GEGENLEISTUNG dafür zu erbringen, dass über neues bzw. zusätzliches Geld verfügt werden kann.

    IT-Abteilungen agieren nicht freiwillig, sondern sind ANGEWIESEN, Aufgaben zu lösen.

    Sie unterliegen damit einer Handlungsdeterminante, die qualitativ eine VÖLLIG andere ist als die, durch die Schulden entstehen.

    Ob die IT-Abteilung andere Methoden oder Technologien hätte einsetzen können, ist hier eine offene Frage, die ich später in anderem Zusammenhang erörtern werde. Es getan zu haben, kann den aufgezeigten Unterschied jedenfalls nicht vom Tisch wischen.

    Denn selbst eine freiwillige Selbstverpflichtung der IT-Abteilung, derartige nicht „Schulden“ generierende Methoden und Technologien einzusetzen, kann die Kritik nicht aushebeln.

    Zwar mag die IT-Abteilung die Kompetenz haben, aber ganz gewiss hat sie nicht die AUTONOMIE, darüber zu entscheiden, ob die Verpflichtung, die sie sich und dem sie beauftragenden Umfeld damit auferlegt, u. a. HÖHERE Kosten zu tragen, die Gegenleistung generieren wird, die diese Verpflichtung rechtfertigt.

    Kurzum:

    Die IT-Abteilung regiert nicht den Staat und leitet auch nicht Unternehmen.

    Was man allerdings VERGLEICHEND sagen kann:

    Das herrschende monetäre System der Schuldengenerierung hat die Gesamtverschuldung kontinuierlich so hochgefahren, dass nicht nur das Finanzsystem, sondern das Gesamtsystem vor der Wand steht.

    Das konventionelle IT-Lösungsverfahren, vorgefertigte modulare IT-Bausteine ohne tieferliegenden Prozessbezug einzusetzen, hat Staat und Unternehmen in eine Lage gebracht, in der auf Veränderungen nicht mehr mit Produktivitätsfortschritten reagiert werden kann. Insoweit steht auch dadurch die Wirtschaft an der Wand.

    Das ist ein anderer Vergleich als der von Prof. Dr. Stiehl.

    Er vergleicht die PROZESSE, ich die EFFEKTE dieser Prozesse.

    Damit komme ich zu einer Einordnung von Prozessen, um die es hier ja geht. Sie ist übergeordnet und daher grundsätzlich.

    Es gibt ZIELE und MITTEL. Sie stehen in einer Beziehung zueinander.

    Ziele können prinzipiell WILLKÜRLICH gesetzt werden, wobei das in der politischen und wirtschaftlichen Praxis regelmäßig nicht der Fall ist, weil hier jeweils Abhängigkeiten herrschen, die nicht übergangen werden können.

    Es gibt aber natürlich Ziele und sie haben eine PRIMÄRE Stellung in Bezug zu Mitteln.

    Denn Ziele zu setzen bzw. zu haben, BEINHALTET, Mittel einzusetzen zu wollen, um sie zu realisieren.

    Wer sich Ziele setzt, aber keine Mittel für ihre Realisierung haben will, handelt IRRATIONAL.

    Das ist so, weil mit Zielen NOTWENDIGERWEISE das Bestreben, sie erreichen zu wollen, verbunden ist.

    Das gilt nicht für Mittel im Verhältnis zu Zielen.

    Mittel setzen NICHTS – sie sind da, ERMÖGLICHEN etwas, eben Ziele zu erreichen.

    Prozesse sind keine Ziele, sondern Mittel – brauchbare oder nicht brauchbare, effiziente oder nicht effiziente etc.

    Sie sind es auch, wenn sie, wie Prof. Dr. Stiehl sagt, das
    >Nervenzentrum unserer Wirtschaft> sind.

    Was immer sie in welcher Ausprägung auch sind, es kann ihnen GRUNDSÄTZLICH keine inhärente Zielsetzungsmacht zuerkannt werden. Darauf ist einzugehen, wenn die Methodik von PDA anwendungsbezogen zur Sprache kommt.

    Ob Mittel auch Ziele WERDEN können, und wenn so, unter welchen Bedingungen und mit welchen Folgen, ist eine interessante Frage, die ich hier nicht erörtere.

    Wäre es so, müsste das wiederum in einem Ziel-Mittel-Kontext beurteilt werden.

    * Variantenreiche Auflistung von Bemerkungen und INTERPRETATIONEN von IT-Fachleuten zu „technical debt“ für diejenigen, die tiefer einsteigen wollen mit Blick darauf, ob die Behauptung bzw. der Vergleich von Prof. Dr. Stiehl trägt:

    https://www.productplan.com/glossary/technical-debt/

    Der beste Satz steht am Ende des Textes:

    “So the takeaway here is, context matters when determining whether technical debt is good or bad. In general, you can think of technical debt in the same way you do financial debt: it’s not problematic until it is.”

    Auf den KONTEXT kommt es an.

    Der bestimmt sich für das MITTEL, d. h. einen Prozess bzw. seine IT-Lösung durch das vorgegebene ZIEL.

    Antworten
  7. Dietmar Tischer
    Dietmar Tischer sagte:

    Kommentar 2

    Ich kommentiere hier nur kurz die Auffassung von Prof. Dr. Stiehl zur Problematik von IT-Lösungen beim Staat.

    Die Situationen, die er mit Defiziten beschreibt, sind nachvollziehbar, richtig und angemessen bewertet mit – in meinen Worten – unbefriedigend bis an sich völlig unakzeptabel bei Missbrauch und Betrug.

    Er benennt als (eine) Ursache, ohne andere auszuschließen, dass IT-Abteilungen bezüglich ihrer bestehenden Software-Lösungen überfordert sind, wenn neue Beschlüsse umgesetzt werden müssen und daher durch An-, Über- und/oder Neuprogrammierung in Lähmung verfallen.

    Das kann so stehen bleiben.

    Es geht mir nicht darum, sondern ich befasse mich vielmehr im Folgenden damit, WIE Prof. Dr. Stiehl für die Methodik PDA argumentiert und wie dies mit Blick auf die im Staat ablaufenden Prozesse zu bewerten ist.

    Er argumentiert so:

    >Jeder getroffene Beschluss hat zwangsläufig die Erstellung neuer oder die Anpassung bestehender Prozesse in Computersystemen zur Folge!
    Es geht also letztlich um Schnelligkeit bei der Bereitstellung dieser (neuen, D. T.) Prozesse>

    Das ist richtig.

    Denn es ist klar, dass bestehende Prozesse und Computersysteme unauflösbar miteinander verknüpft sind und natürlich immer noch die alte kapitalistische Weisheit „time is money“ gilt.

    Das Problem bei der Anpassung:

    >…schlechte Wartbarkeit und Anpassbarkeit der erstellten Softwarelösungen an (und damit schlechte Reaktionsfähigkeit auf) neue Herausforderungen …>

    Die Lösung des Problems:

    >… dies können wir vermeiden, wenn Behörden und Unternehmen zukünftig dem „prozessgesteuerten Ansatz“ folgen,…>

    Ich stelle demnach als These fest:

    Wenn Softwarelösungen mit dem prozessgesteuerten Ansatz (PDA) erstellt werden, lassen sich die getroffene Beschlüsse mit leichterer Anpassung hinreichend schnell umsetzen.

    Worüber nichts gesagt wird, ist „getroffene Beschlüsse“.

    Prof. Dr. Stiehl scheint nichts darüber sagen zu müssen, weil er von „JEDER getroffene Beschluss“ spricht.

    Für ihn ist Beschluss demnach offensichtlich eine KONSTANTE.

    Ich behaupte, dass er eine VARIABLE ist, die seine Behauptung im Kontext Ziel/Mittel PRINZIPIELL nicht in jedem Fall und tendenziell in immer weniger Fällen erfüllen kann.

    Bevor ich an einem aktuellen Beispiel demonstriere, was ich damit meine, will ich kurz auf das Beispiel „Auftragsabwicklung eines Handyvertrage mit Rufnummernmitnahme“ (Abb. 1) eingehen.

    Es stellt FIXIERTEN Ablaufroutinen und damit einen DEFINIERTEN Prozess dar.

    Dazu sagt Prof. Dr. Stiehl:

    >Da die Prozessmodelle unverändert zur Ausführung gelangen, gelingt die Erstumsetzung in einem Bruchteil der ursprünglichen Zeit…>

    UNVERÄNDERT – das ist bei diesem Beispiel ersichtlich so.

    Es ist aber nicht die REALITÄT im Alltag staatlicher Maßnahmen.

    Mein Gegenbeispiel ist ein aktuelles und bekanntes, auch mir seiner Komplexität nach nur erahnbares, das nicht die Corona-Krise betrifft und somit einer unergiebigen Diskussion über Ausnahmefälle entgehen sollte.

    Ich beziehe mich auf die GRUNDRENTE, die letztes Jahr als neue soziale Errungenschaft von der Regierung beschlossen wurde und am 1.1.2021 operativ als „Prozess“ umgesetzt werden soll.

    Wir erinnern uns an die vielen Talkshows mit parteilich unterschiedlichen Zielsetzungen und die Beschlussverkündung durch die Regierung, die nur ein MEDIEN-Ereignis war.

    Denn dahinter verbirgt sich als DARAUFHIN auszuführen: Gesetzesänderungen mit Prüfung auf mögliche rechtliche Anfechtbarkeit, Durchführungsbestimmungen und organisatorische Weichenstellungen u. a. mit Blick auf die verfügbaren Ressourcen sowie die Anforderungen an mögliche Betroffene.

    Das betrifft u. a., aber nicht nur die beschlossene Einkommensprüfung, die lt. Bundesministerium für Arbeit und Soziales „weitgehend automatisiert durchgeführt werden soll, um Rentnerinnen und Rentner mit möglichst wenig Verwaltungsaufwand zu konfrontieren“.

    Die Einkommensprüfung soll durch einen automatisierten Datenabgleich zwischen der Rentenversicherung und den Finanzbehörden erfolgen.
    Die Rentenversicherung verweist auf große operative Probleme. Die Koalition ist trotz großer Bedenken der Fachleute entschlossen, am Starttermin 2021 festzuhalten.

    Unabhängig davon, ob die als groß angesehenen Probleme bei vorherigem Einsatz der PDA-Methodik aufgetreten wären oder nicht, ist zu fragen:

    WARUM wird TROTZ der Bedenken am Starttermin 1.1.2021 als ZIELVORGABE festgehalten?

    Der Grund liegt auf der Hand:

    Wenn der Starttermin auf eine spätere Zeit festgelegt würde, um – angenommen – u. a. mit der PDA-Methodik den Grundstein für eine ZUKÜNFTIG bessere Softwareentwicklung zu legen und so zukünftige Rentenprozesse BESSER umsetzen zu können, würde möglicherweise bis sehr wahrscheinlich DIESES Rentenprojekt nicht zu verwirklichen sein.

    Denn bei absehbaren Neuwahlen und einer neuen Regierung käme vermutlich zur Einkommensprüfung die Vermögensprüfung.

    Zumindest käme sie wieder auf den Tisch neuer Koalitionsverhandlungen.

    Teilen der CDU und insbesondere die SPD entging damit der Nachweis, für bestimmte, ausgewählte Bevölkerungsgruppen etwas getan zu haben.

    Das wird in unserem System konsensualer Interessenbedienung von der Bevölkerung nicht akzeptiert und daher bei Nichterfüllung von ihr sanktioniert mit der Folge von noch mehr politischem Vertrauensverlust und gesellschaftlicher Instabilität.

    Deshalb MUSS der 1.1.2021 als Liefertermin gehalten und die IT-Abteilungen der Rentenversicherung und den Finanzbehörden diesem ZIEL mit wie auch immer gearteten Lösungen gerecht werden.

    Die MÖGLICHKEIT, ein Modul „Vermögensprüfung“ mit oder aufgrund der PDA-Methodik vorbereitend im IT-Prozess mit zu generieren, darf man als definitiv ausgeschlossen annehmen.

    Wenn es aufgrund einer neuen Koalition irgendwann für schnelle Anpassung dennoch gebraucht würde, muss WIE BISHER unter Druck an der IT-Lösung „gebastelt“ werden.

    Meine damit beispielhaft belegte These zur REALITÄT lautet daher:

    Es gibt praktisch KEINEN Makro-Prozess im Bereich staatlicher Maßnahmen, der die Aussage erlaubt, dass die Prozessmodelle UNVERÄNDERT zur Ausführung gelangen.

    Zugespitzt der Auffassung von Prof. Dr. Stiehl entgegentretend, behaupte ich:

    „Eine Art Lego-Baukasten für die Softwareentwicklung“ lässt sich bei den verfügbaren Ressourcen in den IT-Bereichen der öffentlichen Hand nicht herstellen, weil die REALEN Prozesse von ihnen verlangen, dass sie praktisch KONTINUIERLICH die Lego-Bausteine UMFORMEN, um überhaupt etwas zum Laufen zu bringen.

    Kurzum, es kann bei ZIELSETZUNGEN, die in Breite und Tiefe hochgradig VARIABEL sind, keinen Lego-Baukasten geben.

    Das FUNDAMENTALE Problem liegt nicht bei den IT-Abteilungen, die auch ihre Probleme haben, sondern bei den REALEN Prozessen, die sie abbilden und operativ optimieren sollen, es aber nicht können, weil diese regelmäßig ein MOVING TARGET sind.

    Hierzu ergänzend aus dem Koalitionsvertrag für diese Legislaturperiode eine Vereinbarung, die ich als perspektivisch für die Intensivierung dieser Problemsituation ansehe:

    „Damit Bürgerinnen und Bürger sowie Unternehmen ihre Daten nur einmal angeben müssen, entwickeln wir ein behördenübergreifendes Datenmanagement, das die Weitergabe von Daten zwischen Behörden erleichtert und gleichzeitig das hohe deutsche Datenschutzniveau erhält.“

    Mit einer derartigen VERFÜGBARKEIT von Daten im Raum staatlicher Maßnahmen ist praktisch JEDE politische Zielsetzung eine REALISIERBARE Option BELIEBIG austarierter Interessenvielfalt, die IT-Abteilungen nicht TROTZ, sondern WEGEN behördenübergreifenden Datenmanagements ausweglos überfordern dürfte.

    Fazit meiner Kritik:

    Prof. Dr. Stiehl argumentiert auf der Basis von UNVERÄNDERT ablaufenden realen Prozessen, die es selbstverständlich auch gibt, für eine Methodik der Softwareentwicklung (PDA), die sich auf Staatsebene nicht PRODUKTIVITÄTSSTEIGERND realisieren lässt, weil die realen Prozesse wegen VARIIERENDER Zielsetzung in weit überwiegender Zahl VERÄNDERT ablaufen (müssen).

    Antworten
    • V. Stiehl
      V. Stiehl sagte:

      Lieber Hr. Tischer,
      auch Ihnen recht herzlichen Dank für Ihren ausführlichen Kommentar, der einen ganz wichtigen Aspekt thematisiert, nämlich den des “MOVING TARGET”, wie Sie es formulieren. Tatsächlich ist es genau so, wie Sie es sagen: Prozesse sind IMMER in Bewegung und ganz besonders die unternehmenskritischen bzw. differenzierenden Prozesse. Auch wenn mein Beispiel den Eindruck vermittelt, es ginge nur um relativ starre Vorgaben, die sich nicht mehr ändern würden, so ist dies eher dem Umstand geschuldet, dass der Beitrag ohnehin schon recht umfangreich geworden ist. Von daher stimmt Ihre Einschätzung leider nicht, dass es sich für mich um eine Konstante handelt – das genaue Gegenteil ist der Fall. Um so wichtiger ist es, IT-seitig best möglich aufgestellt zu sein. Die Veränderung können wir nicht verhindern, sie gehört zum System. Aber ich kann mich dafür bestmöglich positionieren! Ich benötige ein solides Fundament, das mir schnellstmögliche Anpassbarkeit ermöglicht. Und genau deshalb brauche ich auch wieder den prozessgesteuerten Ansatz, der genau eine solche Grundlage bildet. Auch wenn, um bei Ihrem Beispiel zu bleiben, die Vermögensprüfung kommen sollte, so müsste sie am Ende des Tages in Software gegossen werden. Wieder stehen die Alternativen “Programmieren” oder “PDA” im Raum. Meine Behauptung ist: Mit PDA haben ich die deutlich bessere Basis, derartige neue Anforderungen einzubringen als mit Programmierung. Ich habe in meinem Buch zum prozessgesteuerten Ansatz diesem Thema ein ganzes Kapitel gewidmet, eben weil es so wichtig ist. Von daher: Ja, Veränderungen und sich ständig ändernde Anforderungen gehören zu unserem Leben. Aber, und das ist die gute Nachricht, der prozessgesteuerten Ansatz ist darauf vorbereitet und berücksichtigt dies explizit.

      Antworten
      • Dietmar Tischer
        Dietmar Tischer sagte:

        @ Prof. Dr. Stiehl

        Fair enough – und danke für Ihre Erläuterungen.

        Mir ist klar, dass Sie – mit dem Verständnis eines Informatikers – krude sein und vereinfachen müssen, um überhaupt Gehör dafür zu finden, um was es geht.

        Dass Sie dabei die SIGNIFIKANZ von PDA betonen, ist erforderlich im medialen Getöse, wenn Sie über das Fachpublikum hinaus wirken wollen.

        Ich bin kein Informatiker und habe Ihr Buch nicht gelesen. Daher maße ich mir kein definitives Urteil über PDA an.

        Wenn das nicht so angekommen sein sollte, betone ich das hiermit ausdrücklich.

        Ich kann nur kommentieren, was ich lese.

        Dabei kommentiere ich aus einer ANDEREN Perspektive, nicht der, die Sie der Sache nach einnehmen (müssen).

        Mir ging es vor allem um eine EINORDNUNG, jedenfalls war meine Kritik darauf gerichtet.

        Ich glaube, dass wir da gar nicht weit auseinander sind.

        Ihre folgende Schlüssel-Aussage kann ich jedenfalls nur unterstreichen:

        >Die Veränderung können wir nicht verhindern, sie gehört zum System. Aber ich kann mich dafür bestmöglich positionieren!

        Diese Einsicht reicht über IT/PDA hinaus und betrifft fast alles.

        Es wäre uns allen geholfen, wenn sie weite Verbreitung finden würde.

  8. Dietmar Tischer
    Dietmar Tischer sagte:

    Kommentar 3

    Es geht hier um die Möglichkeit der PDA-Methodik in Unternehmen.

    Ich unterscheide zwei Unternehmenstypen:

    A) konventionell agierenden Unternehmen, die sich MIT Lösungen auf IT-BASIS verbessern wollen und müssen

    und

    B) Start up-Unternehmen, die NUR digital agieren.

    Unternehmenstyp A)

    Bei aller Vielfalt stehen diese Unternehmen in einem Renditewettbewerb, der bei vergleichsweise anhaltend geringem Wirtschaftswachstum vorrangig nur durch KOSTENSENKUNG zu bestehen ist.

    Dem steht die PDA-Methodik gegenüber, die nach Ausführung von Prof. Dr. Stiehl an ZUSÄTZLICHEM Personaleinsatz erfordert:

    >Je einen „Evangelisten“ des prozessgesteuerten Ansatzes auf Fach- und IT-Seite, die eng kooperieren und als Multiplikatoren für ihre jeweiligen Kollegen und Kolleginnen dienen. Ergänzt wird dieses Set-up um einen erfahrenen PDA-Berater, der bei dem Projekt als Sparringspartner zu allen Fragen des prozessgesteuerten Ansatzes bereitsteht und sowohl Fortschritt als auch Qualität überwacht>

    Wo Kostensenkung die Rendite sichert, verursacht die PDA-Methodik Kostensteigerung.

    Angeblich sind deren Kosten auf human ressources beschränkt, denn so Prof. Dr. Stiehl:

    >Unternehmen müssen einzig in die Ausbildung ihrer Mitarbeiter investieren>

    Abgesehen davon, dass die Ausbildung von Mitarbeitern etwas anderes ist als der Einsatz von Mitarbeitern, widerspreche ich dieser Aussage mit folgendem anekdotischem Beispiel aus der
    Investitionsgüterindustrie:

    Ein Werkzeughersteller unterbreitet seinen Kunden folgendes Angebot:

    Schickt uns die Daten, die unsere Werkzeuge bei Euch im Einsatz generieren und so ihren „digitalen Lebenslauf“ schreiben. Werden die Werte online an uns übermittelt, verfügen wir bezogen auf das reale Werkzeug über einen „digitalen Zwilling“. Dieser lässt sich mit spezieller Software auswerten. Dafür werden die Daten der eigenen Werkzeugentwicklung und, soweit vorliegend, die Daten aller anderen Anwender genutzt. Algorithmen errechnen die vorteilhaftesten Einsatzparameter und erschließen dadurch enorme Optimierungspotenziale in der Bearbeitung.

    Das Win-Win-Potenzial:

    Beim Kunden/Anwender zahlt sich das insbesondere durch eine Bearbeitungsqualität mit weniger Ausschuss sowie durch geringere Werkzeug- und Lagerhaltungskosten aus. Der Werkzeughersteller wiederum kann mit deutlich geringeren Kosten sein Werkzeugdesign verbessern sowie den Einsatz des beratenden Außendienstes vor Ort beim Kunden/Anwender reduzieren.

    Das Projekt konnte nicht realisiert werden, weil die Kunden des Werkzeugherstellers es sich nicht leisten konnten bzw. wollten, die für die digitale Datengewinnung, -aufbereitung und -Dokumentierung entstehenden Kosten zu schultern.

    Kurzum:

    Hier scheiterte eine erkennbare vorteilhafte IT-Lösung und damit PDA noch BEVOR es überhaupt eine Chance hatte, angewendet zu werden.

    Denn, wie sagt Prof. Dr. Stiehl:

    >Die Digitalisierung ist disruptiv, sie bricht mit Existierendem, sie ist vor allem schnell und sie ist existenzbedrohend.>

    Eben.

    Deshalb belässt man es vielfach beim absolut Notwendigen der Digitalisierung und erwägt gar nicht erst eine „Luxus-Methodik“ wie PDA.

    Der Fairness halber muss gesagt werden, dass diese Kunden/Anwender einer Branche angehören, die vor allem durch osteuropäische Hersteller vor dem Ruin steht.

    Das relativiert dieses Beispiel, entwertet aber nicht die generelle Problematik.

    Unternehmenstyp B:

    Start up-Unternehmen zeichnen sich in aller Regel dadurch aus, dass sie jahrelang NUR mit VK finanziert werden und damit ihre Existenzberechtigung NICHT durch Rendite, sondern durch AKZEPTANZ ihres Geschäftsmodells beweisen müssen.

    Dies erfolgt durch UMSATZWACHSTUM.

    Das bekannteste Beispiel dafür dürfte Amazon sein, das als on line-Buchladen gegründet wurde, sein Sortiment kontinuierlich erweiterte und diesen Prozess in immer neuen Ländern (Märkten) replizierte.

    Der Sortimentserweiterung und den Kundenerwartungen entsprechend musste die IT-Landschaft angepasst werden.

    Inwieweit dabei Methoden wie PDA zum Einsatz kamen, weiß ich nicht.

    Vermutlich erfolgte dies in erheblichem Umfang, weil zumindest die Bestell-, Zahlungs- und Lieferprozesse auf Kundenseite sehr homogen und quasi UNVERÄNDERT sein dürften, im Prinzip nicht anders als die dargestellte Auftragsabwicklung eines Handyvertrags mit Rufnummernmitnahme.

    Wenn das stimmt, wäre es ein Beleg für die These, dass PDA seine unbestreitbaren Vorteile im STANDARDISIERTEN MASSENGESCHÄFT ausspielen kann.

    Das ist ein großes Feld für IT-Lösungen und sicher auch PDA, speziell im Handel.

    Wie weit es für eine Wirtschaft von Bedeutung sein kann, deren Wertschöpfung vermehrt zu fragmentierten Dienstleistungen tendiert, bleibt offen.

    Meine Schlussbewertung:

    Der methodische Effizienzgewinn des Verfahrens PDA ist beachtlich, seine Einsatzmöglichkeiten sind gleichwohl begrenzt und das Produktivitätswachstum, das es in der Volkswirtschaft generieren kann, zwar expansiv (weil IT-Lösungen zunehmen), aber möglicherweise von untergeordneter Bedeutung mit Blick auf das Gesamtpotenzial der Wirtschaft.

    Nice to have, fun to play (for professionals).

    Antworten
    • V. Stiehl
      V. Stiehl sagte:

      Lieber Hr. Tischer,
      in diesem Kommentar gehen Sie auf die Kosten ein, die mit PDA verbunden sind und schließen aus meinen Ausführungen, dass PDA “ZUSÄTZLICHEN Personaleinsatz” erfordert. Dem ist nicht so. Denn die Evangelisten, von denen ich in meinem Beitrag spreche, rekrutieren sich aus dem vorhandenen Personal. In dem Abschnitt, aus dem Sie zitieren, geht es ja um die Idealbedingungen für den schnellstmöglichen Erfolg beim Einsatz von PDA. Es geht um Empfehlungen. Folglich wäre es gut, wenn es diese Evangelisten gäbe. Aber natürlich geht es auch ohne. Erfahrungsgemäß dauert es dadurch nur etwas länger – steht dem Einsatz von PDA aber keinesfalls im Wege. Ähnlich verhält es sich mit dem (externen) Berater. Natürlich kann man sich das alles selbst aneignen. Sie können das alles in meinen Büchern nachlesen. Die Gefahr besteht allerdings, dass kostspielige Fehler gemacht werden, die mit Einsatz eines Beraters vermieden worden wären. Aber eine Notwendigkeit ergibt sich daraus nicht. Im schlimmsten Fall wird aufgrund von Unerfahrenheit und den damit verbundenen Fehlern PDA selbst in Misskredit gebracht. Daher empfehle ich den Berater.
      Anschließend folgern Sie aufgrund dieser Kosten, dass es ein Luxus ist, PDA einzusetzen und argumentieren anhand eines Beispiels. Sie schreiben: “Das Projekt konnte nicht realisiert werden, weil die Kunden des Werkzeugherstellers es sich nicht leisten konnten bzw. wollten, die für die digitale Datengewinnung, -aufbereitung und -Dokumentierung entstehenden Kosten zu schultern.” Natürlich sind Innovationen mit Investitionen und damit Kosten verbunden. Und jede Investition muss natürlich auf der Gegenseite einen entsprechenden Nutzen generieren. Es sind die klassischen Kosten/Nutzen-Überlegungen. Wenn der Kunde zur Entscheidung kommt, es lohnt sich für ihn nicht, dann unterlässt er seine Investition. Das ist sein gutes Recht. Kann er es sich nicht leisten, dann stellt sich ja auch die Frage überhaupt nicht. ABER: Diese Überlegungen haben doch nichts mit PDA zu tun. Diese Überlegungen sind doch grundsätzlich bei jeder Entscheidung zu treffen. Im Gegenteil: Das Kosten/Nutzen-Verhältnis bei PDA steht aufgrund der genannten zahlreichen Vorteilen in einem höchst attraktiven Verhältnis. Luxusinvestitionen sehen meiner Meinung nach tatsächlich anders aus.
      Am zweiten Beispiel des Start up-Unternehmens attestieren Sie PDA seine unbestreitbaren Vorteile. Vollkommen richtig. In diesem Teil schimmert zudem die Argumentation Ihres zweiten Kommentars durch, nämlich der Einsatz von PDA in standardisierten Abläufen. An dieser Stelle verweise ich auf meine Antwort zu Ihrem zweiten Kommentar: PDA eignet sich sowohl für standardisierte als auch für sich ständig wechselnde Prozesse! ABER: Gerade für die sich ständig ändernden Prozesse spielt PDA seine Stärken aus und ist sämtlichen Alternativen überlegen. Daher ist meine Schlussfolgerung (wie könnte es anders sein ;-): PDA ist kein Luxus, es ist das genaue Gegenteil. Es gehört in jedes Unternehmen.

      Antworten
    • V. Stiehl
      V. Stiehl sagte:

      Lieber Hr. Tischer,
      in diesem Kommentar gehen Sie auf die Kosten ein, die mit PDA verbunden sind und schließen aus meinen Ausführungen, dass PDA “ZUSÄTZLICHEN Personaleinsatz” erfordert. Dem ist nicht so. Denn die Evangelisten, von denen ich in meinem Beitrag spreche, rekrutieren sich aus dem vorhandenen Personal. In dem Abschnitt, aus dem Sie zitieren, geht es ja um die Idealbedingungen für den schnellstmöglichen Erfolg beim Einsatz von PDA. Es geht um Empfehlungen. Folglich wäre es gut, wenn es diese Evangelisten gäbe. Aber natürlich geht es auch ohne. Erfahrungsgemäß dauert es dadurch nur etwas länger – steht dem Einsatz von PDA aber keinesfalls im Wege. Ähnlich verhält es sich mit dem (externen) Berater. Natürlich kann man sich das alles selbst aneignen. Sie können das alles in meinen Büchern nachlesen. Die Gefahr besteht allerdings, dass dennoch kostspielige (und vor allem unnötige) Fehler gemacht werden, die mit Einsatz eines Beraters vermieden worden wären. Aber eine Notwendigkeit ergibt sich daraus nicht. Im ungünstigsten Fall wird aufgrund von Unerfahrenheit und den damit verbundenen Fehlern PDA selbst in Misskredit gebracht. Daher empfehle ich den Berater.
      Anschließend folgern Sie aufgrund dieser Kosten, dass es ein Luxus ist, PDA einzusetzen und argumentieren anhand eines Beispiels. Sie schreiben: “Das Projekt konnte nicht realisiert werden, weil die Kunden des Werkzeugherstellers es sich nicht leisten konnten bzw. wollten, die für die digitale Datengewinnung, -aufbereitung und -Dokumentierung entstehenden Kosten zu schultern.” Natürlich sind Innovationen mit Investitionen und damit Kosten verbunden. Und jede Investition muss natürlich auf der Gegenseite einen entsprechenden Nutzen generieren. Es sind die klassischen Kosten/Nutzen-Überlegungen. Wenn der Kunde zur Entscheidung kommt, es lohnt sich für ihn nicht, dann unterlässt er seine Investition. Das ist sein gutes Recht. Kann er es sich nicht leisten, dann stellt sich ja auch die Frage überhaupt nicht. ABER: Diese Überlegungen haben doch nichts mit PDA zu tun. Diese Überlegungen sind doch grundsätzlich bei jeder Entscheidung zu treffen. Im Gegenteil: Das Kosten/Nutzen-Verhältnis bei PDA steht aufgrund der genannten zahlreichen Vorteilen in einem höchst attraktiven Verhältnis. Luxusinvestitionen sehen meiner Meinung nach tatsächlich anders aus.
      Am zweiten Beispiel des Start up-Unternehmens attestieren Sie PDA seine unbestreitbaren Vorteile. Vollkommen richtig. In diesem Teil schimmert zudem die Argumentation Ihres zweiten Kommentars durch, nämlich der Einsatz von PDA in standardisierten Abläufen. An dieser Stelle verweise ich auf meine Antwort zu Ihrem zweiten Kommentar: PDA eignet sich sowohl für standardisierte als auch für ständig anzupassende Prozesse! ABER: Gerade für die sich fortlaufend ändernden Prozesse spielt PDA seine Stärken aus und ist sämtlichen Alternativen überlegen. Daher ist meine Schlussfolgerung (wie könnte es anders sein ;-): PDA ist kein Luxus, es ist das genaue Gegenteil. Es ist eine Notwendigkeit und gehört in jedes Unternehmen.

      Antworten
      • Dietmar Tischer
        Dietmar Tischer sagte:

        @ Prof. Dr. Stiehl

        Dank auch für diese Antwort – gern gehe ich darauf ein.

        1. Kosten beim Einsatz von PDA

        Selbst wenn kein zusätzliches Personal eingesetzt würde oder wenn doch, dann um Erarbeitungs-, Implementierungs- oder Folgekosten zu senken (externe Berater), ist der Aufwand meiner Prozesserfahrung nach – ohne IT-Bezug erworben – größer.

        Das liegt m. A. n. daran, dass (erfolgreiches) PDA auf einer TIEFENKENNTNIS der Prozesse beruht und diese erarbeitet werden muss. Das benötigt Zeit, insbesondere wenn die IT-Abteilung mit ihrer Außensicht einen unbefangenen Blick auf die Prozesse wirft und möglicherweise andere Ablaufroutinen anstößt, die wiederum in der Matrix derer, die für die Prozessgestaltung verantwortlich sind, zusätzlichen Aufwand generieren.

        Das hat nichts mit der Frage zu tun, ob die höheren Kosten gerechtfertigt sind.

        Sie werden insbesondere dann gerechtfertigt sein, wenn ein Unternehmen beginnt, PDA einzusetzen, also im Unternehmen kaum oder keine Ressourcen vorhanden sind, die zu PDA-Lösungen hinführen können.

        2. Unternehmens-Entscheidungen für den Einsatz von PDA

        Es ist klar, dass mein Beispiel (sich verweigernde Werkzeuganwender) nichts mit der Methodik von PDA zu tun hat. Daher ist völlig richtig, dass das Kosten/Nutzen-Verhältnis von PDA von diesem Beispiel nicht tangiert ist.

        Das ist aber nicht mein Punkt.

        Mein Punkt ist die RELEVANZ, mit der Ihr Gastbeitrag im Blog von Dr. Stelter „positioniert“ wird, nämlich einen wesentlichen Beitrag für die Produktivitätssteigerung der deutschen Volkswirtschaft leisten zu können.

        Mit Blick auf diese Thematik habe ich argumentiert.

        Ich habe dabei nicht verneint, dass dies auch mittels PDA zu leisten ist, aber GRENZEN aufgezeigt mit Verweis auf Segmente unserer Volkswirtschaft.

        Insofern widerspreche ich Ihnen:

        PDA gehört NICHT in jedes Unternehmen.

        Oder ich drücke es einmal überpointiert so aus:

        Ja, es gehört in jedes Unternehmen, also auch in jene, die praktisch pleite sind, aber durch die Einführungskosten für PDA schneller und damit effizienter pleitegehen.

        3. PDA und sich fortlaufend ändernde Prozesse

        Ich kann mir dazu kein Urteil erlauben, weil ich nicht Informatiker bin und die „methodische Reichweite“ von PDA nicht kenne. Wenn es aber so sein sollte, dass sich PERMANENT die Zielvorgaben so ändern, dass praktisch nur noch hinterher gerannt werden kann, um einigermaßen brauchbare reale Prozesse zu formen, könnte es für IT generell und PDA speziell fragwürdig sein, tragfähige Lösungen zu erarbeiten.

        Ich sage dies mit dem Bewusstsein, dass diese Aussage spekulativ ist und möglicherweise nur für einen Chaoten-Club, aber nicht eine einigermaßen rationale operierende Organisation gilt.

  9. Thomas M.
    Thomas M. sagte:

    Vielen Dank für den interessanten Beitrag; dieser ist erfrischend praxisnah!

    Zu einer Stelle hätte ich als “unbedarfter Praktiker” eine Frage. (Ich erhoffe/erwarte keine personalisierte Antwort; dies ist eher als Anregung zu verstehen…)

    Ich war gleich vom BPMN angetan – schließlich bringt dies zu Papier, was man sich zum Prozess überlegt und nötigt auch im positiven Sinne zum vollständigen Durchdenken und deckt ggf. Lücken im Prozess auf.

    Ich fragte mich an der Stelle spontan: Gibt es eine Softwarelösung, bei der man die Segmente wie Ereignisse, Meldungen, Datenbankänderungen erstellt und verbindet?

    Sie schrieben: “Die derart erstellten Modelle sind durch spezielle Software genauso, wie sie modelliert wurden, ausführbar. Mit anderen Worten: Das oben abgebildete Modell ist bereits der ausführbare Prozess, ohne dass für den Prozessablauf eine weitere Programmierung notwendig wird.”

    Diese Software würde ich mir als gute Schnittstelle (im Sinne einer gemeinsamen bildlichen Sprache) zwischen den Prozessarchitekten und der IT vorstellen. Auch wären damit die Prozesse transparent dokumentiert.

    Vielleicht könnte man hier noch etwas ausführlicher beschreiben, wie und womit (Software) der Prozessarchitekt in der Praxis aktiv wird. Könnte der Architekt zum Beispiel selber die Prozesse in einer Software bauen und der IT diese dann übermitteln? Oder ist es doch eher konzeptionelle Arbeit, die von der IT interpretiert und ggf. abweichend umgesetzt wird? Das könnte das Interesse noch steigern.

    Ich sende einmal zwei Kontakten diesen Ansatz. Der eine hat eine große Digitalisierung von Geschäftsprozessen vor sich. Der Hintergrund passt perfekt: Langfristiger Personalabbau zur Kostenreduktion, bei gleichzeitig zunehmenden Problemen qualifizierte Mitarbeiter zu finden. Daher die Strategie der Reduktion des Workloads pro Mitarbeiter pro (B2B-) Bestellbearbeitung durch konsequente Digitalisierung. Der andere kennt es vielleicht auch schon – er erzählt mir immer von den neuesten BI-Entwicklungen – aber mit etwas Glück kann ich dann auch einmal glänzen ;)

    Vielen Dank!

    Antworten
    • V. Stiehl
      V. Stiehl sagte:

      …und ich bedanke mich recht herzlich für…
      – …die Zeit, die Sie sich für die Lektüre des Beitrags genommen haben
      – …Ihren ausführlichen Kommentar, der viele wichtige Fragen stellt
      – …das Weiterleiten des Beitrags in Ihrem Bekanntenkreis!
      Ich gehe jetzt auf einige Punkte Ihres Kommentares ein:

      1. Sie schreiben: “Ich war gleich vom BPMN angetan”: Absolut korrekt: Ein wirklich vorzüglicher Standard! Es ist beeindruckend, wie präzise Prozesse ausgedrückt werden können. Auch Ihren Punkt “im positiven Sinne zum vollständigen Durchdenken und deckt ggf. Lücken im Prozess auf” kann ich aus der Praxis bestätigen: Erst durch intensive Arbeit am Modell wird deutlich, wie Unternehmen arbeiten bzw. wie sie zukünftig arbeiten wollen. Ich zitiere gerne aus einem konkreten Projekt, in dem der Satz fiel: “Jetzt wissen wir endlich einmal, wie wir wirklich arbeiten!” Es ist traurig, aber wahr: Die meisten Unternehmen wissen nicht, was im Detail gerade abläuft. Transparenz? Fehlanzeige!
      Von daher: Ja, BPMN ist alleine aus diesem Grund schon wichtig! Aber bitte nicht bei der Dokumentation von Prozessen stehenbleiben: Erst durch dessen Ausführbarkeit wird BPMN so richtig wertvoll.

      2. Sie schreiben: “Gibt es eine Softwarelösung, bei der man die Segmente wie Ereignisse, Meldungen, Datenbankänderungen erstellt und verbindet?”. Um BPMN ausführbar zu machen, braucht es tatsächlich einer speziellen Software, sogenannte Process Engines. Diese Engines können die BPMN-Modelle verarbeiten und die modellierten Schritte ausführen. Hinter jedem Schritt muss hinterlegt werden, was konkret zu tun ist: So hinterlegt man beispielsweise bei einem interaktiven Schritt ein Formular, das zur Laufzeit vom Endanwender auszufüllen ist. Hier ist teilweise noch Programmierung notwendig, allerdings ist der Aufwand im Vergleich zur vollständigen Ausprogrammierung von Prozessen deutlich geringer. Der Einsatz von Process Engines trägt ganz erheblich zur Aufwandsreduzierung bei. Für mich gehören Process Engines zu einer neuen Kategorie von Infrastruktursoftware, die in jedes Unternehmen gehört. Ich vergleiche es gerne mit Datenbanken: Heute ist es bei Softwareprojekten eine Selbstverständlichkeit, Datenbanken nicht selbst zu programmieren, sondern Produkte etablierter Hersteller zu nehmen. Nur bei den Prozessen glaubt jedes Unternehmen, sie könnten es sich leisten, aufs Neue Umgebungen zur Prozessausführung zu programmieren. Was für eine Zeitverschwendung! Dabei ist der Einstieg so einfach. Es gibt hervorragende Open Source-Lösungen, die auch produktiv einsetzbar sind. Die Einstiegshürde ist also wirklich niedrig.

      3. Sie schreiben: “im Sinne einer gemeinsamen bildlichen Sprache”: Genau darum geht es! Eine gemeinsame Sprache, die Missverständnisse vermeidet und zu einer effizienten Umsetzung führt – ein ganz wichtiger Baustein im prozessgesteuerten Ansatz! Ich nenne es ganz gerne die “Kommunikationsrevolution”: Beide Seiten (Fachabteilung und IT) sprechen endlich eine gemeinsame Sprache, die keine Interpretationen zulässt und durch die bildliche Darstellung wissen beide Seiten auch stets, worüber gerade gesprochen wird (banal ausgedrückt: man kann ja darauf zeigen). Bei verbaler Kommunikation hängt es von vielen Faktoren ab, was beim Zuhörer ankommt (z.B. Vorbildung, Erfahrung,…) und wir wissen nie, welches Bild sich im Kopf des gerade Zuhörers aufbaut. Das ist die Quelle aller Missverständnisse und darauf aufbauend die Quelle falscher Umsetzungen in Software, die wir uns in Unternehmen nicht leisten können. Durch die richtige Verwendung von BPMN wird dies alles vermieden. Ein weiterer Baustein zur Produktivitätssteigerung.

      4. Sie schreiben: “Vielleicht könnte man hier noch etwas ausführlicher beschreiben, wie und womit (Software) der Prozessarchitekt in der Praxis aktiv wird. Könnte der Architekt zum Beispiel selber die Prozesse in einer Software bauen und der IT diese dann übermitteln? Oder ist es doch eher konzeptionelle Arbeit, die von der IT interpretiert und ggf. abweichend umgesetzt wird?”: Hier sind wir jetzt an einem ganz entscheidenden Punkt angekommen! Im prozessgesteuerten Ansatz gibt es zunächst einmal keinen zentralen “Prozessarchitekten”, der allein verantwortlich die Prozesse modelliert. Es sind stets Teams bestehend aus Fach- und IT-Abteilung, die zusammen die BPMN-Modelle erarbeiten. Aber (und jetzt kommt das Entscheidende): Es ist keine (!) konzeptionelle Arbeit, die interpretiert oder gar abweichend umgesetzt wird. Es ist so, wie ich es geschrieben habe: Es wird nicht ein einziges Element des Fachmodells später bei der Umsetzung verändert, hinzugefügt oder gelöscht! Genau auf diesen Aspekt habe ich bei der Entwicklung des prozessgesteuerten Ansatzes besonderen Wert gelegt. Es kann (und darf) nicht sein, dass die Energie, die das Team in die Entwicklung der Fachmodelle gesteckt hat (und das ist die wirklich harte Arbeit – glauben Sie mir), umsonst war und die wertvollen Modelle später in der IT-Abteilung während der Implementierung über den Haufen geworfen werden. Dann werden sämtliche Ideen, die der BPMN zugrunde liegen, ad absurdum geführt! Man darf nie vergessen: Die erstellten Modelle repräsentieren die Kernprozesse des Unternehmens. Sie sind für das Unternehmen von unschätzbarem Wert, schließlich beinhalten sie differenzierende Aspekte. Ich sage immer ganz gerne: Das sind die Diamanten des Unternehmens – sie müssen unter allen Umständen geschützt werden (also unverändert bleiben und durch nichts verunreinigt werden).

      Bei der Nutzung von Software unterscheidet man BPMN-Modellierungstools, die eher für Fachabteilungen geeignet sind und BPMN-Editoren für Entwickler. Dank des Standards BPMN kann man die Modelle aber zwischen den Produkten austauschen. Für Fachabteilungen bieten sich webbasierte Editoren an, während sich Entwickler ihre Editoren eher auf ihrem Rechner fest installieren.
      Achten Sie bei der Auswahl der Tools und Ablaufumgebungen auf die vollständige Abdeckung des BPMN-Standards. Im Gegensatz zur (leider) weit verbreiteten Meinung, man benötige nicht den gesamten BPMN-Sprachumfang, halte ich den gesamten Sprachumfang für eine professionelle Arbeit mit BPMN für unumgänglich!

      Ich hoffe, ich konnte Ihnen mit meinen Antworten weiterhelfen. Ich möchte Ihnen die beiden im Beitrag verlinkten Webinare (jeweils eine Stunde Dauer) ans Herz legen, da Sie dort weitere Details zum und den Ideen hinter dem prozessgesteuerten Ansatz erfahren. Gerade Teil 2 mit Live-Demos dürfte einige Fragen beantworten.

      Nochmals vielen Dank für Ihre Mühe und Ihren Kommentar!

      Antworten
    • V. Stiehl
      V. Stiehl sagte:

      …und ich bedanke mich recht herzlich für…
      – …die Zeit, die Sie sich für die Lektüre des Beitrags genommen haben
      – …Ihren ausführlichen Kommentar, der viele wichtige Fragen stellt
      – …das Weiterleiten des Beitrags in Ihrem Bekanntenkreis!
      Ich gehe jetzt auf einige Punkte Ihres Kommentares ein:

      1. Sie schreiben: “Ich war gleich vom BPMN angetan”: Absolut korrekt: Ein wirklich vorzüglicher Standard! Es ist beeindruckend, wie präzise Prozesse ausgedrückt werden können. Auch Ihren Punkt “im positiven Sinne zum vollständigen Durchdenken und deckt ggf. Lücken im Prozess auf” kann ich aus der Praxis bestätigen: Erst durch intensive Arbeit am Modell wird deutlich, wie Unternehmen arbeiten bzw. wie sie zukünftig arbeiten wollen. Ich zitiere gerne aus einem konkreten Projekt, in dem der Satz fiel: “Jetzt wissen wir endlich einmal, wie wir wirklich arbeiten!” Es ist traurig, aber wahr: Die meisten Unternehmen wissen nicht, was im Detail gerade abläuft. Transparenz? Fehlanzeige!
      Von daher: Ja, BPMN ist alleine aus diesem Grund schon wichtig! Aber bitte nicht bei der Dokumentation von Prozessen stehenbleiben: Erst durch dessen Ausführbarkeit wird BPMN so richtig wertvoll.

      2. Sie schreiben: “Gibt es eine Softwarelösung, bei der man die Segmente wie Ereignisse, Meldungen, Datenbankänderungen erstellt und verbindet?”. Um BPMN ausführbar zu machen, braucht es tatsächlich einer speziellen Software, sogenannte Process Engines. Diese Engines können die BPMN-Modelle verarbeiten und die modellierten Schritte ausführen. Hinter jedem Schritt muss hinterlegt werden, was konkret zu tun ist: So hinterlegt man beispielsweise bei einem interaktiven Schritt ein Formular, das zur Laufzeit vom Endanwender auszufüllen ist. Hier ist teilweise noch Programmierung notwendig, allerdings ist der Aufwand im Vergleich zur vollständigen Ausprogrammierung von Prozessen deutlich geringer. Der Einsatz von Process Engines trägt ganz erheblich zur Aufwandsreduzierung bei. Für mich gehören Process Engines zu einer neuen Kategorie von Infrastruktursoftware, die in jedes Unternehmen gehört. Ich vergleiche es gerne mit Datenbanken: Heute ist es bei Softwareprojekten eine Selbstverständlichkeit, Datenbanken nicht selbst zu programmieren, sondern Produkte etablierter Hersteller zu nehmen. Nur bei den Prozessen glaubt jedes Unternehmen, sie könnten es sich leisten, aufs Neue Umgebungen zur Prozessausführung zu programmieren. Was für eine Zeitverschwendung! Dabei ist der Einstieg so einfach. Es gibt hervorragende Open Source-Lösungen, die auch produktiv einsetzbar sind. Die Einstiegshürde ist also wirklich niedrig.

      3. Sie schreiben: “im Sinne einer gemeinsamen bildlichen Sprache”: Genau darum geht es! Eine gemeinsame Sprache, die Missverständnisse vermeidet und zu einer effizienten Umsetzung führt – ein ganz wichtiger Baustein im prozessgesteuerten Ansatz! Ich nenne es ganz gerne die “Kommunikationsrevolution”: Beide Seiten (Fachabteilung und IT) sprechen endlich eine gemeinsame Sprache, die von beiden Seiten akzeptiert wird, keine Interpretationen zulässt und durch ihre bildliche Darstellung klarstellt, worüber konkret gesprochen wird (banal ausgedrückt: man kann ja darauf zeigen). Bei verbaler Kommunikation hängt es von vielen Faktoren ab, was beim Zuhörer ankommt (z.B. Vorbildung, Erfahrung,…) und wir wissen nie, welches Bild sich im Kopf des Zuhörers gerade aufbaut. Das ist die Quelle aller Missverständnisse und darauf aufbauend die Quelle falscher Umsetzungen in Software, die wir uns in Unternehmen nicht leisten können. Durch die richtige Verwendung von BPMN wird dies alles vermieden. Ein weiterer Baustein zur Produktivitätssteigerung.

      4. Sie schreiben: “Vielleicht könnte man hier noch etwas ausführlicher beschreiben, wie und womit (Software) der Prozessarchitekt in der Praxis aktiv wird. Könnte der Architekt zum Beispiel selber die Prozesse in einer Software bauen und der IT diese dann übermitteln? Oder ist es doch eher konzeptionelle Arbeit, die von der IT interpretiert und ggf. abweichend umgesetzt wird?”: Hier sind wir jetzt an einem ganz entscheidenden Punkt angekommen! Im prozessgesteuerten Ansatz gibt es zunächst einmal keinen zentralen “Prozessarchitekten”, der allein verantwortlich die Prozesse modelliert. Es sind stets Teams bestehend aus Mitarbeitern der Fach- und IT-Abteilungen, die zusammen die BPMN-Modelle erarbeiten. Aber (und jetzt kommt das Entscheidende): Es ist keine (!) konzeptionelle Arbeit, die interpretiert oder gar abweichend umgesetzt wird. Es ist so, wie ich es geschrieben habe: Es wird nicht ein einziges Element des Fachmodells später bei der Umsetzung verändert, hinzugefügt oder gelöscht! Genau auf diesen Aspekt habe ich bei der Entwicklung des prozessgesteuerten Ansatzes besonderen Wert gelegt. Es kann (und darf) nicht sein, dass die Energie, die das Team in die Entwicklung der Fachmodelle gesteckt hat (und das ist die wirklich harte Arbeit – glauben Sie mir), umsonst war und die wertvollen Modelle später in der IT-Abteilung während der Implementierung über den Haufen geworfen werden. Dann werden sämtliche Ideen, die der BPMN zugrunde liegen, ad absurdum geführt! Man darf nie vergessen: Die erstellten Modelle repräsentieren die Kernprozesse des Unternehmens. Sie sind für das Unternehmen von unschätzbarem Wert, schließlich beinhalten sie differenzierende Aspekte. Ich sage immer ganz gerne: Das sind die Diamanten des Unternehmens – sie müssen unter allen Umständen geschützt werden (also unverändert bleiben und durch nichts verunreinigt werden).

      Bei der Nutzung von Software unterscheidet man BPMN-Modellierungstools, die eher für Fachabteilungen geeignet sind und BPMN-Editoren für Entwickler. Dank des Standards BPMN kann man die Modelle aber zwischen den Produkten austauschen. Für Fachabteilungen bieten sich webbasierte Editoren an, während sich Entwickler ihre Editoren eher auf ihrem Rechner fest installieren.
      Achten Sie bei der Auswahl der Tools und Ablaufumgebungen auf die vollständige Abdeckung des BPMN-Standards. Im Gegensatz zur (leider) weit verbreiteten Meinung, man benötige nicht den gesamten BPMN-Sprachumfang, halte ich den gesamten Sprachumfang für eine professionelle Arbeit mit BPMN für unumgänglich!

      Ich hoffe, ich konnte Ihnen mit meinen Antworten weiterhelfen. Ich möchte Ihnen die beiden im Beitrag verlinkten Webinare (jeweils eine Stunde Dauer) ans Herz legen, da Sie dort weitere Details zum und den Ideen hinter dem prozessgesteuerten Ansatz erfahren. Gerade Teil 2 mit Live-Demos dürfte einige Fragen beantworten.

      Nochmals vielen Dank für Ihre Mühe und Ihren Kommentar!

      Antworten
  10. Ortner
    Ortner sagte:

    Lieber Volker,

    bei uns in Konstanz ist aus Deinem Prozess-orientierten Ansatz inzwischen ein ganz neuer Anwendungssystem-Typ hervorgegangen, der sich in etlichen IT-Projekten in Unternehmen und Verwaltungen bewährt hat. Wir nennen diesen AWS-Typ, mit Basissoftware und Applikationen:„Interaktions-Management Systeme & Anwendungen“. Er scheint das IoT der nächsten Generation – Plattformen-basiert und von den Apps her – zu dominieren.

    Antworten
  11. Michael Stöcker
    Michael Stöcker sagte:

    „Produktion steigern durch Prozessdigitalisierung“

    Keine Frage, eine sehr wichtige Aufgabe. Der werden wir uns aber nur dann erfolgreich widmen können, wenn wir aktuell den (Geld)Kreislauf stabilisieren und den totalen System-Kollaps vermeiden. Insofern als Kompromissvorschlag, wenn Deutschland und Österreich keinen generellen Eurobonds zustimmen können:

    1.000 EUR pro Monat für jeden Bürger von Euroland über 18 Jahre sowie 500 EUR für alle unter 18 Jahre für die kommenden 6 Monate. Die Finanzierung erfolgt über gemeinsame Eurobonds mit einer Laufzeit von 100 Jahren zu 1 %.

    Alle weiteren Programme können/müssen dann auf bisherigem Wege finanziert werden.

    Ohne Eurobonds wird der Euro diese Krise vermutlich nicht überstehen: https://makroskop.eu/2020/03/corona-die-politik-und-die-europaeische-herausforderung/

    Antworten
  12. 1ruby
    1ruby sagte:

    Betriebswirtschaftlich müssen Kosten abbilden, um Entscheidungsgrundlagen zu liefern
    Dazu empfehle ich die Erläuterungen zu Prozeßkosten bei Coenenberg/Fischer/Günther
    “Kostenrechnung und Kostenanalyse”
    7. Aufl. 2009
    Seiten 151 bis 170
    wichtig sind die Bewertungen.

    Antworten

Trackbacks & Pingbacks

  1. […] meines Gastbeitrags auf der Webseite des Ökonomen Dr. Daniel Stelter zum Thema „Produktivitätssteigerung durch Prozessdigitalisierung“ erhielt ich folgende […]

  2. […] verständlichen Einblicken in ökonomische Zusammenhänge. Dort ist u.a. auch mein Beitrag über Produktivitätssteigerungen durch den prozessgesteuerten Ansatz veröffentlicht worden. Weniger bekannt ist hingegen der Podcast von Dr. Daniel Stelter, der nicht […]

Ihr Kommentar

An der Diskussion beteiligen?
Hinterlassen Sie uns Ihren Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.