Auf dieser Seite erkläre ich Ihnen anhand eines beispielhaften Projektablaufes die Kernideen des prozessgesteuerten Ansatzes.
Der „Prozessgesteuerte Ansatz“ ist eine auf Prozessmodellen basierende Projektabwicklungs- und Implementierungsmethodik für digitale Transformationsprojekte, bei denen beliebige innovative Abläufe umzusetzen sind.
Da sämtliche digitalen Geschäftsmodelle in irgendeiner Form mit Prozessen zu tun haben, ist der „Prozessgesteuerte Ansatz“ folglich für alle unternehmerisch tätigen Personen relevant. Lesen Sie dazu auch meinen Beitrag über die Motivation zum „Prozessgesteuerten Ansatz“, in dem ich sehr ausführlich auf die fundamentale Bedeutung von Prozessen aller Art eingegangen bin.
Der „Prozessgesteuerte Ansatz“ ist also kein Produkt, das man mal soeben von der Stange kaufen kann, sondern eine Methodik, die man erlernen muss. Von daher sind die Einstiegshürden vergleichbar niedrig: Mit etwas gutem Willen können auch Sie relativ schnell von den vielen Vorteilen des prozessgesteuerte Ansatzes profitieren. Denn die technologische Seite lässt sich insbesondere in der Anfangsphase vollständig mit Open Source-Angeboten abdecken.
Das Ergebnis eines Projektes nach dem „Prozessgesteuerte Ansatz“ ist eine sogenannte prozessgesteuerte Anwendung. In meinem Buch „Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN“ habe ich folgende Definition einer prozessgesteuerten Anwendung gegeben (S. 24, hier leicht abgeändert):
Prozessgesteuerte Anwendungen sind fachlich orientierte Applikationen, die differenzierende Ende-zu-Ende-Prozesse unterstützen, wobei die Prozesse Funktions-, System- und Organisationsgrenzen überschreiten, indem sie die von Plattformen und Anwendungen bereitgestellten Daten und Funktionalitäten wiederverwenden.
Die Definition betont bereits die Bedeutung von fachlichen Anforderungen und Prozesslogik als Triebfeder für alle Entscheidungen, die während der Entwicklung von prozessgesteuerten Anwendungen getroffen werden müssen. Wenn wir uns Prozesse allgemein genauer ansehen, so können wir zwischen Standardprozessen (wie z.B. Lagerhaltungsprozesse, Einkaufsprozesse, Personal-Einstellungsprozesse, Abrechnungsprozesse usw.) und unternehmensspezifischen, differenzierenden Prozessen unterscheiden. Standardprozesse werden durch Standardprodukte adäquat abgedeckt und es macht auch nicht allzu viel Sinn, wenn Unternehmen diese selbst programmieren wollen. Von daher gilt: Sollte es zu einem Problem eine passende Standardlösung geben, ist diese der Individualentwicklung vorzuziehen.
Allerdings wird es Unternehmen schwer fallen, sich von der Konkurrenz durch die Verwendung von Standardverfahren zu unterscheiden, so dass sich zwangsläufig die Frage stellt: Wie können Unternehmen schnell und nachhaltig differenzierende Prozesse aufbauen und diese im Anschluss effizient verwalten und überwachen? Genau hierauf gibt der „Prozessgesteuerte Ansatz“ Antworten, indem er eine effektive und effiziente Implementierungsmethodik bereitstellt!
Wie erklärt man aber mit wenigen Worten eine Methodik? Leider lässt sich die gesamte Methodik nicht im Rahmen dieses Übersichtsartikels abdecken. Dazu empfehle ich mein oben bereits kurz erwähntes Buch. Ich kann Ihnen aber zumindest einen kleinen Einblick in die Kerngedanken der Methodik geben, indem ich Sie beispielhaft durch ein kleines Projekt führe. Dazu greife ich auf mein Beispiel aus dem Buch zurück, in dem es um einen einfachen Bestellprozess geht. Ich nehme bewusst einen Bestellprozess, da er für jedermann leicht verständlich ist. Die gleich gezeigte Lösung ist nun wahrlich nicht sonderlich innovativ. Aber es geht mir nicht um einen möglichst attraktiven, hoch innovativen, aber erklärungsbedürftigen Prozess, den niemand versteht. Mir geht es jetzt ausschließlich um die Methodik und davon soll der Prozess nicht allzu sehr von ablenken.
Stellen Sie sich jetzt also vor, Sie sind in Ihrem Unternehmen für die Digitalisierung verantwortlich und wollen den Bestellprozess modernisieren. Wie fangen Sie an?
Die prozessgesteuerte Methodik als Teil des prozessgesteuerten Ansatzes gibt Ihnen hierzu klare Vorgaben: Sie starten mit einem Team bestehend aus Teilnehmern aus den Fach- und IT-Abteilungen sowie den Endanwendern, die später an dem Prozess beteiligt sind. Idealerweise befindet sich in dem Team zumindest ein Teilnehmer, der sich fachlich nicht mit der Materie auskennt. Er ist wichtig, um sämtliche Schritte kritisch zu hinterfragen, da er (noch) nicht betriebsblind ist. Ein Teilnehmer des Teams muss zudem den prozessgesteuerten Ansatz beherrschen. Er steht dem Team als Coach für alle Fragen rund um den „Prozessgesteuerten Ansatz“ zur Seite. Diese enge Kollaboration zwischen Fach- und IT-Abteilung bezeichne ich in Anlehnung an DevOps mit BizDevs, also die prozessgesteuerte Zusammenarbeit zwischen Business (Biz) und IT (Developer = Devs) und ist ein entscheidender Aspekt für den Erfolg eines prozessgesteuerten Projektes.
Gemäß des Leitsatzes des prozessgesteuerten Ansatzes…
„Beginne mit Prozessen – Start With Processes“,
…starten Sie direkt mit der Diskussion der neuen Prozesse ohne vorherige Ist-Analyse. Schließlich geht es um Innovationen und nicht um einfache lokale Anpassungen des aktuellen Zustandes. Daher beginnen Sie in solchen Fällen niemals mit einer Ist-Aufnahme! Warum sollten Sie auch etwas aufnehmen, von dem Sie doch genau wissen, dass es nicht taugt? Das ist eine überflüssige Zeit- und Geldverschwendung. Außerdem beeinflussen Sie die vorhandenen Prozesse unweigerlich negativ. Sie denken nicht mehr frei, sondern haben im Unterbewusstsein stets die aktuellen Prozesse im Hinterkopf. Wie kann da wirkliche Innovation entstehen?
Sie beginnen also zwingend mit den Prozessen und zwar top-down. Sie skizzieren für jeden neuen Prozess zunächst die Hauptschritte und verfeinern diese in jeder weiteren Iterationsrunde, bis keine Verfeinerung mehr möglich ist. Lassen Sie sich bei der Arbeit an den Prozessen auch von der existierenden IT-Landschaft nicht beeinflussen. Die Systemlandschaft, gegen die Ihre neuen Prozesse später einmal laufen müssen, schränken Sie in Ihrem Denken nur unnötigerweise ein. Dies ist unbedingt zu vermeiden! Es geht um Ihr Geschäft, Ihre Zukunft und da spielen ihre existierenden Systeme eine untergeordnete Rolle. Für eine spätere Verbindung Ihrer neuen Prozesse mit Ihrer Systemlandschaft sorgt die prozessgesteuerte Architektur. Der Aspekt der Anbindung an die IT-Landschaft wird also nicht vergessen. Sie darf nur nicht Ihr Denken und die Diskussion um die bestmöglichen Prozesse zur Unterstützung Ihres Geschäftsmodells bestimmen!
Die Diskussion der Prozesse erfolgt dabei stets anhand von Modellen nach dem graphischen Notationsstandard BPMN (Business Process Model and Notation). Tatsächlich ermöglichte die Veröffentlichung von BPMN den „Prozessgesteuerte Ansatz“ erst. Die Notation stellt folglich das Fundament des Ansatzes dar. Als Konsequenz müssen sämtliche Projektbeteiligten die BPMN beherrschen. Nicht jeder muss fehlerfreie BPMN-Modelle erzeugen können. Allerdings wird lesendes Modellverständnis von allen Mitgliedern erwartet. Aufgrund der Vielzahl der zur Verfügung stehenden BPMN-Elemente findet man in recht vielen Publikationen zu BPMN Aussagen zur Einschränkung der BPMN-Palette speziell zur Modellierung von Fachprozessen. Ich persönlich halte rein gar nichts von derartigen Einschränkungen und lehre grundsätzlich die gesamte BPMN-Palette. Diese Anforderung an das Team ist für mich unabdingbar.
Natürlich taucht hier die Frage nach „guten BPMN-Modellen“ auf. Hier verweise ich auf die Ausführungen von Bruce Silver, der in seinen Büchern zu „Methode und Stil“ („Method and Style“) wertvolle Modellierungsrichtlinien zusammengetragen hat. Daran orientiert sich auch der „Prozessgesteuerte Ansatz“, der diese Richtlinien allerdings noch um das prozessgesteuerte Denken erweitert hat. Dabei hat der Modellierer eben nicht nur das Fachmodell im Fokus, sondern er weiß, dass diese Prozesse später einmal exakt in der Form, wie sie modelliert werden, als Anwendung auszuführen sind. Denn wir wollen als Anwender des „Prozessgesteuerten Ansatzes“ ja nicht einfach nur irgendwelche Prozessmodelle erstellen. Unser Anspruch ist höher: Diese Modelle sollen unverändert durch eine sogenannte Process Engine ausgeführt werden und müssen dabei gleichzeitig die Anforderungen der prozessgesteuerten Architektur berücksichtigen, die ich gleich noch näher beleuchten werde.
Doch zunächst zurück zur Process Engine: Bei einer Process Engine handelt es sich um ein Stück Software, das BPMN-Modelle ausführen kann. Es handelt sich also um eine Infrastrukturkomponente, die selbst keine fachliche Funktion wie beispielsweise eine Rechnungsstellung oder einen Lagereingang abdeckt. Sie liefert eine Dienstleistung, nämlich die Ausführung von BPMN-Modellen. Datenbanken sind beispielsweise auch eine solche Infrastrukturkomponente. Datenbanken sind auf die transaktionsgesicherte Datenverwaltung spezialisiert und kein anspruchsvolles IT-Projekt kommt heute mehr ohne Datenbanken aus. Zudem würde niemand auf den Gedanken kommen, eine Datenbank für sein Projekt selbst entwickeln zu wollen. So müssen Sie sich das auch für eine Process Engine vorstellen. In der heutigen Zeit ergibt es schlicht keinen Sinn mehr, für Abläufe aller Art eigene Programme zu entwickeln. Tatsächlich gewinnt der prozessgesteuerte Ansatz durch den Einsatz von Process Engines einen Teil seiner Entwicklungseffizienz.
Aus diesem Grund lehre ich die BPMN beispielsweise anders als dies in vergleichbaren Kursen der Fall ist, da ich stets die Ausführbarkeit nach dem „Prozessgesteuerten Ansatz“ im Hinterkopf habe. Die daraus resultierenden Modelle müssen folglich ganz anderen Ansprüchen genügen, als wenn ich einfach nur so „drauf los“ modellieren würde. Die Anforderungen an Präzision und Modularisierung sind wesentlich anspruchsvoller. Dafür erhalten die Unternehmen qualitativ hochwertige, sofort aus dem Modell heraus verständliche Prozesse mit bestmöglicher Modularisierung und garantierter Ausführbarkeit in einer prozessgesteuerten Architektur. Sie sind das Ergebnis des prozessgesteuerten Denkens!
Kommen wir jetzt aber wieder zu unserem Projekt zurück. Sie haben bis jetzt verstanden, worauf es bei der Erstellung der Modelle ankommt. Tatsächlich ist die Diskussion um die Prozesse der wirklich anstrengende Teil eines prozessgesteuerten Projektes. Hier wird im Team auf Basis graphischer BPMN-Modelle so lange diskutiert, bis im Team Einigkeit über die Prozesse herrscht. Da sich in dem Team neben den späteren Endanwendern auch Teilnehmer aus sowohl Fach- als auch IT-Abteilungen befinden, weiß nach Fertigstellung des Prozesses jeder, was ihn später während und nach der Implementierung erwartet. Dank der BPMN-Modelle können Diskussionen wesentlich zielgerichteter geführt und Missverständnisse im Keim erstickt werden („Kommunikationseffizienz“). Die BPMN-Modelle sind der Grund für die enorme Effizienzsteigerung im gesamten weiteren Verlauf des Projektes. Deswegen ist es auch vollkommen gerechtfertigt, sich zur Ausgestaltung der Prozesse besonders viel Zeit zu nehmen. Es wird förmlich um jeden Schritt gerungen. Aber diese Aufwände, diese Zeiten sind gut investiert, denn schließlich geht es um das Geschäft des Unternehmens! Kann es etwas Wichtigeres für ein Unternehmen geben?
Die Erfahrung aus realen Projekten zeigt, dass der eine oder andere Projektmanager oder Vorgesetzte in dieser Projektphase nervös wird, da man ja angeblich „noch nichts sieht“. Sie kennen sicherlich diese Frage aus Softwareprojekten: „Kann man schon was sehen?“. Diese Frage müssen Manager und Projektverantwortliche bei prozessgesteuerten Projekten zumindest zu Beginn des Projektes aus Ihrem Sprachschatz entfernen, denn sie ist wenig konstruktiv und fördert lediglich die verfrühte Implementierung von vermeintlich sichtbaren Projekterfolgen, die im Anschluss oft genug revidiert werden müssen. Erneut eine Verschwendung von Zeit und Geld. Haben sich die Projektmitglieder auf die Prozesse geeinigt, kann mit der prozessgesteuerten Entwicklung begonnen werden. Als Basis nehmen wir dazu den in Abbildung 1 dargestellten Bestellprozess:
Sie sehen hier den Ablauf in BPMN modelliert. Der Prozess beginnt links oben bei dem Kreis mit der Unterschrift „Lagerbestand unterhalb Schwellenwert“ und drückt den Grund aus, warum der Prozess startet. Danach erfolgt durch einen Mitarbeiter (achten Sie auf die Beschriftung „Mitarbeiter“ ganz links) die Eingabe bzw. Überarbeitung der Produktbestellung. Weiter geht es mit dem Schritt „Bestellung genehmigen“, der durch den Vorgesetzten des Mitarbeiters durchzuführen ist. Lehnt er ab, verfällt der Prozess in eine Schleife und der Mitarbeiter überarbeitet seine Eingaben, bis sein Antrag schlussendlich genehmigt wird. Erst dann erfolgt die Verbuchung in einem oder mehreren Systemen des Unternehmens. Der Prozess endet schließlich in dem Kreis mit der Unterschrift „Bestellung abgeschlossen“.
Das BPMN-Modell erfüllt einige Anforderungen an Prozessmodelle für prozessgesteuerte Anwendungen. So werden Sie in fachlichen Prozessmodellen des prozessgesteuerten Ansatzes niemals Schritte mit Beschriftungen wie „Bestellung durch Transaktion abc in System xyz eingeben“ finden. Grundsätzlich sind Fachmodelle des prozessgesteuerten Ansatzes gänzlich unabhängig von einer existierenden Systemlandschaft im Unternehmen. Es handelt sich also stets um systemunabhängige Fachprozesse. Dies ist eine der Grundregeln des „Prozessgesteuerten Ansatzes“.
Warum sind die Prozessmodelle aber so wichtig, dass man mit der Implementierung tatsächlich so lange wartet, bis die Modelle von allen Teammitgliedern abgesegnet wurden? Weil die Prozessmodelle im Anschluss sämtliche Antworten auf die anfallenden Entwicklungsfragen geben. Sind die Modelle noch nicht abgeschlossen, können auch keine eindeutigen Programmiervorgaben gegeben werden. Deshalb sind sie so wichtig und deshalb ist zwingend bis zu ihrer Finalisierung zu warten. Das ist auch der Grund, warum ich die Methodik „Prozessgesteuerter Ansatz“ genannt habe. Die Prozesse stehen im Mittelpunkt und steuern im Anschluss den gesamten Entwicklungsprozess! Beispiele für derartige Fragen sind:
- Welche Benutzeroberflächen sind zu erstellen? Frag den Prozess!
- Welche Daten sollen auf den Benutzeroberflächen zu sehen sein? Frag den Prozess!
- Welche Daten sollen nach außen gegeben werden? Frag den Prozess!
- Welche Daten kommen von außen? Frag den Prozess!
- Wie soll die Anwendung modularisiert werden? Frag den Prozess!
- Welche (Micro-)Services werden benötigt und welche fachliche Funktionalitäten enthalten sie? Frag den Prozess!
Diese Liste ließe sich beliebig verlängern – aber ich denke, Sie verstehen mittlerweile, worauf es ankommt. Die Prozesse sind unsere Richtschnur, sie weisen uns den Weg. Denn in der Softwareentwicklung kann man es sich meiner Meinung nach nicht leisten, ziellos irgendwelche Software zu entwickeln, nur um irgendwem irgendetwas zu zeigen, das im Anschluss ohnehin nochmal geändert werden muss (was durchaus auch als Kritik an dem bestehenden agilen System verstanden werden darf). Warum macht man es denn nicht gleich richtig? Weil nur allzu oft das Ziel fehlt, ganz nach dem folgenden Zitat von Seneca:
Wer den Hafen nicht kennt, in den er segeln will, für den ist kein Wind der richtige.
Seneca
Beim „Prozessgesteuerten Ansatz“ kann genau das nicht passieren. Die Prozesse weisen uns unmissverständlich den Weg!
Bei der prozessgesteuerten Entwicklung kann ab der Bereitstellung der Fachprozesse mit der parallelen Entwicklung begonnen werden. Die Betonung liegt hier auf „parallel“. Die prozessgesteuerten Architektur, die der konsequenten Anwendung des in der Informatik bewährten Prinzips des „separation of concerns“ (zu Deutsch: „Trennung der Belange/Zuständigkeiten“) folgt, ermöglich eine höchst effiziente Entwicklung, da folgende Komponenten in der prozessgesteuerten Architektur getrennt wurden und daher parallel vorangetrieben werden können:
- Prozesse
- Benutzeroberflächen
- Entscheidungen
- Geschäftslogik
- Datenhaltung
- Integration
- Ereignisverarbeitung
Im Verlaufe des Artikels ist mittlerweile vermehrt der Begriff der prozessgesteuerten Architektur gefallen. Doch was hat es konkret damit auf sich? Zur Beantwortung dieser Frage schauen wir nochmal auf das Prozessmodell aus Abbildung 1. Richten Sie Ihr Augenmerk auf den Schritt „Bestellung verbuchen“. Aus fachlicher Sicht soll die Bestellung „irgendwie“ verbucht werden. Der fachlichen Seite ist es schlichtweg egal, wie und wo die Bestellung überall gespeichert werden soll. Aus fachlicher Seite ist lediglich der Fakt von Bedeutung, dass die Daten gespeichert werden. Aber Sie haben natürlich völlig recht: Am Ende des Tages müssen die Daten in der existierenden Systemlandschaft des Unternehmens gesichert werden. Hier trifft der systemunabhängige Fachprozess auf die real existierende Systemlandschaft. Man spricht in der Informatik von einer „Integrationsaufgabe“. Der Fachprozess ist in die Landschaft des Unternehmens zu integrieren. Das Schöne ist, auch diese Anforderung kann man mit BPMN umsetzen. Dies habe ich in Abbildung 2 konkret genutzt:
Keine Sorge, Sie müssen dieses gesamte Szenario jetzt nicht verstehen. Sie sollten trotzdem den unveränderten Fachprozess am oberen Rand des Bildes wiedererkennen. In dem unteren Modell sehen Sie die Kommunikation mit der Systemlandschaft (z.B. mit dem ERP-System, dem Statistik-System und dem Marketing-System). Dies ist ein erstes grobes Architekturbild, das Ihnen zumindest ein Gefühl dafür vermittelt, wie die Trennung von Zuständigkeiten konkret vollzogen wird. Das obere Modell umfasst den Fachprozess, der Prozess darunter die Integration. Letzterer ist ein systemabhängiger Integrationsprozess. Die prozessgesteuerte Architektur umfasst eine Fülle von Blaupausen für mögliche architektonische Ansätze, die die Modularisierung und gleichzeitig die Flexibilität für Unternehmen erhöhen. Anwender des „Prozessgesteuerten Ansatzes“ müssen lediglich die für sie passendste Architekturvariante auswählen. Im Anschluss können Sie sofort mit der Umsetzung beginnen. Langwierige und somit kostspielige Architekturdiskussionen entfallen!
Durch die in Abbildung 2 gezeigte Trennung ergeben sich Vorteile wie die unabhängige Weiterentwicklung des Fachprozesses oder der Austausch von Systemen in der IT-Landschaft. Letztendlich gewinnt ein Unternehmen durch diese Trennung an Flexibilität und Reaktionsfähigkeit: Unternehmen können schneller auf sich ändernde Marktgegebenheiten reagieren als dies mit anderen Ansätzen möglich ist. Ein weiterer wichtiger Aspekt des prozessgesteuerten Ansatzes.
Bleibt zum Abschluss meines Artikels noch die Betrachtung des Betriebs einer prozessgesteuerten Anwendung. Hier schlägt erneut die Stunde der Process Engine. Da Process Engines BPMN-basierte Prozesse ausführen, können sie auch die aktuell laufenden Prozessinstanzen (so der Fachausdruck für Prozesse, die sich in Ausführung befinden) graphisch anzeigen sowie statistische Daten über die Prozessinstanzen sammeln und visualisieren. So behalten Process Engines stets den Überblick über ihre aktuell laufenden Prozessinstanzen, wo sie gerade stehen, was bisher ablief und wie die Instanzen fortgesetzt werden. Aus abgelaufenen Instanzen können statistische Daten wie durchschnittliche/maximale/minimale Prozessdurchlaufzeiten gesammelt und für Prozessoptimierungen herangezogen werden. Der Möglichkeiten sind hier nahezu keine Grenzen gesetzt. Die von der Process Engine gesammelten Zahlen lassen sich vergleichbar eines Armaturenbretts eines Autos attraktiv visualisieren. Dies führt im Management zu informierten Entscheidungen und erhöht die Transparenz über die Abläufe im Unternehmen massiv. Das Management leitet das Unternehmen nun nicht mehr wie ein Kapitän sein Schiff im dicksten Nebel. Es hat, um im Bilde zu bleiben, endlich klare Sicht.
Auch in Fehlerfällen findet der Betrieb dank der grafischen BPMN-Modelle die fehlerhaften Instanzen schnell und kann anstehende Probleme zielsicher lösen. Was früher in unübersichtlichen Programmen verborgen war, wird durch BPMN nun transparent vor Augen geführt.
Nach der Lektüre diese Beitrags verstehen Sie vielleicht, warum ich auf meiner Homepage die Begriffe „Effizienz – Transparenz – Flexibilität“ als stellvertretend für den „Prozessgesteuerten Ansatz“ gewählt habe. Es sind die Hauptvorteile, die Sie aus der Anwendung des Ansatzes ziehen können. Dem Ansatz können auch die in der Softwareentwicklung ansonsten gefürchteten Themen wie „Heterogenität“, „Komplexität“ und „Veränderung“ nichts anhaben, da die Konstruktion des Ansatzes genau diese Herausforderungen von vornherein berücksichtigte.
Bleibt noch ein Blick auf die Technologien, die zur Umsetzung von prozessgesteuerten Anwendungen notwendig sind. Ich fasse sie unter dem Begriff „prozessgesteuerte Technologien“ zusammen. Für einen ersten Prototypen genügt eine beliebige BPMN-basierte Process Engine. In der Regel beinhalten sie einen BPMN-Editor. Da Fachabteilungen entwicklerorientierte Editoren eher meiden, empfehle ich ein webbasiertes BPMN-Modellierungswerkzeug. Für Integrationsaufgaben empfehle ich entweder einen Enterprise Service Bus oder eine Kombination aus einer Messaging-Lösung (z.B. Apache ActiveMQ) und einem Integrations-Framework (z.B. Apache Camel). Zudem ist der Einsatz von Regel-Engines zur Automatisierung von Entscheidungen und Geschäftsregeln nach dem DMN-Standard (Decision Model and Notation) anzuraten. Wer sich in Richtung Industrie 4.0 und dem Internet der Dinge weiterentwickeln möchte, der sollte einen Blick auf ereignisverarbeitende Angebote wie Esper richten.
Damit bin ich am Ende meines kleinen Ausflugs in die Welt des prozessgesteuerten Ansatzes angekommen. Vielleicht erahnen Sie, welche massiven Auswirkungen der Ansatz auf die bisherige Prozessumsetzung in Unternehmen hat. Aber die Unternehmen sollten den Paradigmenwechsel hin zum „Prozessgesteuerten Ansatz“ zum Wohle ihrer Kunden und damit ihres Geschäftes vollziehen. Die Vorteile sprechen eine eindeutige Sprache. Vielleicht motiviert Sie das folgende Zitat von Robert Lee Frost:
Im Wald zwei Wege boten sich mir dar, ich ging den, der weniger betreten war. Dies veränderte mein Leben!
Robert Lee Frost
Lassen Sie den „Prozessgesteuerten Ansatz“ auch Ihr Leben verändern!
Zusammenfassung der wichtigsten Begriffe
Der „Prozessgesteuerten Ansatz“ umfasst:
- Ein Kooperationsmodell zwischen Fach- und IT-Abteilungen namens „BizDevs“ zur Überwindung von Kommunikationsproblemen zwischen diesen beiden Parteien (prozessgesteuerte Zusammenarbeit).
- Eine neue Art des Denkens über BPMN-basierte Geschäftsprozess-Implementierungen (prozessgesteuertes Denken).
- Eine neue Methodik für Geschäftsprozess-Implementierungsprojekte (prozessgesteuerte Methodik).
- Eine konkrete Software-Architektur-Empfehlung für prozessgesteuerte Anwendungen (prozessgesteuerte Architektur) bestehend aus der Trennung zwischen systemunabhängigen Fachprozessen und systemabhängigen Integrationsprozessen sowie einen dazu passenden innovativen Entwicklungsansatz (prozessgesteuerte Entwicklung).
- Eine konkrete Empfehlung für einen Technologiestack, der prozessgesteuerte Anwendungen bestmöglich unterstützt (prozessgesteuerte Technologie).
- Die Anwendung des „Prozessgesteuerten Ansatzes“ führt letztendlich zu prozessgesteuerten Applikationen.