Mittwoch, 23. Mai 2012


Artikel

Juni 2008 | Artikel

Was bringt Business Process Management? Fortsetzung, Teil 2

Teil 1   Teil 2   Teil 3   

DIE PROCESS ENGINE FÜHRT ZUM ZIEL

Papier ist geduldig, warum also sollten die oben genannten Vorteile tatsächlich erreichbar sein? Man muss zunächst verstehen, dass der Anspruch der Prozessautomatisierung über den reinen Abbau von Medienbrüchen und manuellen Aufwänden weit hinausgeht. Es ist wichtig, das Kernprinzip dieses Ansatzes zu verinnerlichen:

Prozesse automatisieren bedeutet nicht, dass hinterher alles automatisch abläuft. Es bedeutet lediglich, dass die Steuerung des Prozesses durch eine spezielle Software, die Process Engine, vorgenommen wird. Diese Engine entscheidet, wann welche Akteure (Mitarbeiter, Partner, Manager, aber auch IT-Systeme) welche Aufgaben durchzuführen haben, um das letztendliche Prozessziel zu erreichen. Die Zuweisung dieser Aufgaben an menschliche Akteure erfolgt beispielsweise über Webbrowser-basierte Aufgabenlisten, virtuelle Eingangskörbe oder einfach per E-Mail. Die Zuweisung von Aufgaben an IT-Systeme geschieht durch den Aufruf von Schnittstellen, über die diese Systeme angesprochen werden können. Ein wichtiger Erfolgsfaktor ist hierbei die Flexibilität der Engine im Umgang mit verschiedenartigen Schnittstellen, da die meisten derzeit im Einsatz befindlichen IT-Systeme nicht über standardisierte Web Services verfügen, sondern auf proprietären Wegen über Datei- oder Datenbankschnittstellen angesprochen werden müssen.

Die Process Engine "schwebt" also über allen am Prozess beteiligten Personen und IT-Systemen, und das in bestimmten Fällen sogar unternehmensübergreifend. Ein Paradebeispiel wäre hier die Bonitätsauskunft der Schufa, eine Leistung, die schon seit Jahren auch als Service auf Basis von http und XML via Internet angeboten wird und zum Beispiel durch Banken und Finanzdienstleister in automatisierten Prozessen zur Kreditvergabe (Stichwort "Kreditfabrik") genutzt wird.

AUF DEM WEG ZUR SOA

Ausgehend von diesem Kernprinzip kommen weitere Methoden und Technologien zum Einsatz: Die Reihenfolge der Aufgabenzuweisung orientiert sich an der definierten Prozesslogik, bestehend aus Kontrollstrukturen mit Sequenzen, Parallelisierungen, Verzweigungen, Schleifen und so weiter. Gerade die Verzweigungen nehmen eine zentrale Rolle ein, da diese inhaltlich häufig auf Geschäftsregeln basieren, was das Business Rules Management und die entsprechenden Systeme ins Spiel bringt (zum Beispiel für das Management der Geschäftsregel, dass der Kreditantrag bei Unterschreiten eines definierten Schufa-Scores abgelehnt werden soll). Prozesskennzahlen wie Durchlaufzeiten oder die Quote abgelehnter Kreditanträge werden aufgrund der zentralisierten Steuerung durch die Process Engine zu einem Abfallprodukt, das die Engine im Rahmen der Ausführung "nach oben durchreichen" kann, wo es von Reporting-Systemen oder Business-Intelligence-Lösungen ausgewertet wird. Und letztendlich führt die prozessorientierte Nutzung von IT-Schnittstellen über kurz oder lang zwangsläufig zu einer Serviceorchestrierung mit den entsprechenden spezifischen Herausforderungen in der Definition, Verwaltung und Nutzung der Services, was uns zum Hypethema SOA bringt.

VERSTÄNDLICHE MODELLE

Eine standardisierte Sprache für die Prozessautomatisierung ist die Business Process Execution Language (BPEL), die auf XML basiert und von vielen namhaften Anbietern wie Oracle, IBM und Microsoft getragen wird. Hintergrund von BPEL ist unter anderem der Wunsch, automatisierbare Prozesse in einer Form definieren zu können, die von unterschiedlichen Process Engines verstanden wird, um von einzelnen Herstellern unabhängiger zu werden. Auch wenn dieses ambitionierte Ziel aufgrund unterschiedlicher Probleme beim praktischen Einsatz von BPEL heute noch in weiter Ferne liegt, macht es doch deutlich, wohin die Reise geht. Für den Laien ist es zunächst nur entscheidend zu verstehen, dass BPEL keine grafische Visualisierung von Prozessen unterstützt, sondern lediglich deren technische Beschreibung in XML, was uns zur nächsten Frage bringt: Wie lassen sich die feingranularen, technischen Workflows mit grafischen Prozessmodellen verknüpfen, um die Methoden des organisatorischen Prozessmanagements wirksam anwenden zu können?

Teil 1   Teil 2   Teil 3   

Kommentare

Gravatar Bernhard Kern 08.12.2008
um 17:24 Uhr
Danke Jakob,

wirklich einer der besten BPM-Artikel, den ich bis jetzt gelesen habe (und ich habe viele gelesen)! Er zeigt den Unterschied zwischen den Visionen von BPM und der Realität auf. Der Traum ein Prozessmodell "einfach mal so" zusammenzuklicken und zu automatisieren gelingt heute bei weitem nicht so einfach, wie es die Marketingartikel der jeweiligen Hersteller propagieren. Finde ich auch super, dass du einerseits den Bogen zwischen Betriebswirtschaft und IT spannst und andererseits auch auf die nötigen Technologien wie ESB und SOA eingehst.

Naja, lange Rede kurzer Sinn: Für alle BPM Anfänger: lest den Artikel und ihr habt einen guten Einstieg was BPM in Zukunft leisten kann, oder auch nicht!

Hast du den Artikel auch auf dem BPM-Netzwerk veröffentlicht?

Viele Grüße
#zitieren
Gravatar Philipp Waibel 18.01.2009
um 16:17 Uhr
Ich stimme vollkommen zu.

Als angehender Wirtschaftsinformatiker kann man sich in dieser Hinsicht super an deinem BPM-Artikel orientieren und mit dem aktuellen Vorlesungsstoff abgleichen.

Auch das BPM Videointerview war sehr informativ auf den Punkt gebracht.

Viele Grüße
Philipp
#zitieren
Gravatar John 11.05.2010
um 23:13 Uhr
Hallo,

eine kurze Frage wie kann BPM + SOA zusammen bei der Optimierung von Prozessen helfen?
#zitieren