Vom Geschäftsprozess zum Workflow. Ein Leitfaden für die Praxis. [Gebundene Ausgabe]

Mit Hilfe des Buches habe ich einen Education Call strukturiert. Es ist sauber aufgebaut, Begriffe werden erst verwendet nachdem sie definiert wurden. Die Probleme von Geschäftsprozessorientierung und deren Umsetzung in die IT werden sauber dokumentiert. Mir gefällt im Besonderen die Analyse möglicher Umsetzungen von der Fachlichkeit in die IT, S.129.
Jeder der sich mit den Konsequenzen des Titels auseinander setzen will lege ich es ans Herz.

Angeregt durch eine Diskussion auf XING habe ich mich zum Kauf dieses Buches entschieden weil es angeblich die Unschärfen und Mängel von BPM aufzeigt und hilft diese mit praktischen Ansätzen zu überwinden. Aber dem ist nicht so. Es ist nicht mehr als ein Überblick über Konzepte und Begriffen der BPM Welt ohne klare Struktur und Inhalt. Die Checklisten am Ende sind nicht für den Fachmann geeignet. Eine wirtschaftliche Betrachtung der immensen Aufwände der Prozessumsetzung und vor allem Wartung und Adaption wird unterlassen, obwohl die entsprechenden Probleme angedeutet werden.

Das Beispiel auf Seite 16 soll einen Anlass zur Prozessoptimierung darstellen, ließe sich jedoch mit einer einfachen Auftragsverwaltung lösen. Anstatt wird aber Winslow Taylor (1911 - scientific management) zitiert und übergeleitet, dass eben Prozesse die funktionellen Abteilungsgrenzen überbrücken. Das an sich ist schon falsch weil Prozesse dazu dienen sollten Aktivitäten und deren Ziele den Prozesseignern in der Organisation zuzuordnen. Eine Prozessoptimierung sollte dann dazu dienen solche funktionellen Prozessbrüche aufzuheben und nicht sie technisch zu überbrücken.

Auf Seite 17 wird die richtige Antwort zum Problem genannt, dass ein übergreifender Zugriff auf eine gemeinsame elektronische Akte Freiheitsgrade für Prozesse bringt und das Problem löst. Auf den Folgeseiten wird dann, anstatt dies weiter gedanklich auszubauen, Michael Hammer zitiert, wieder weggelegt und sprunghaft zu der heiligen Dreifaltigkeit von starrem BPM-Workflow - Mitarbeiterreduktion, Durchlaufzeit, Überwachung - als implizierter, unbewiesener Nutzen übergegangen. Dabei wird dann einfach in den Raum gestellt, dass die Transparenz erhöht, die Qualität verbessert, und die Abläufe flexibilisiert werden.

Dabei wird dann zugegeben, dass ARIS in großen Unternehmen nur zur Dokumentation eingesetzt wird und daraus implementierte Prozessmanagementsysteme starr und unverwaltbar sind. Angeblich werden jedoch 'modernere' Software und vor allem SOA (Service Orientierte Architektur) das Problem in Zukunft lösen. Wie und zu welchen Kosten steht nicht dabei.

Nun gut, es ist verständlich, dass in so einem 'Praxisbuch' auf die arbeitspsychologischen Nachteile von BPM nicht eingegangen wird. Es sind aber auch wichtige Prozessmanagementthemen unbekannt, unbenannt oder nur flüchtig angemerkt:

1) Die Notwendigkeit eines Metadatenmodels (nicht Suchattribute)
2) Die Notwendigkeit von Qualitätskriterien (nicht BPM Messung)
3) Verknüpfung von Organisation und Prozessen mit den Zielen.
4) Definition des Prozesseigners in der Organisation.
5) Problematik Vernetzung von Human Workflows und Orchestration.
6) Diskussion der SOA Kosten als Voraussetzung von BPM.
7) Wichtigkeit der Geschäftsdokumente (1 Seite am Ende ...)
8) Zu erstellende, ausgehende Dokumente (Bausteine, Daten, Logik)

Es gibt auch klare Fehlempfehlungen, zum Beispiel das Regelwerke und Prozesse getrennt sein sollten. Auch die Fähigkeiten von ereignisgesteuerter Kollaboration (Case Management) wird am starren Flowchart bewertet und nicht an seiner Fähigkeit die Realität abzubilden.

Richtig sind die Beobachtungen am Anfang des 4. Kapitels zum Thema Modellierung. Hier wird zugegeben, dass sich Modelle nicht direkt in Prozesse umsetzen lassen und die technische Realisierung sich nicht ins Modell rückführen lässt. Mit diesem Status Quo muss man angeblich leben. Dies ist falsch, da eben 'flusslose' Prozesse aus diesem Grund überlegen sind! Dass diese Tatsache Flussdiagramm-BPM als IT-Technik in der empfohlenen Form aus Kostengründen in Frage stellt, fehlt als Gedanke, wie auch dass aus diesem Grund die Agilität von Unternehmen mit BPM nicht erhöht sondern reduziert wird. Es wird dann zwar noch kurz die Option von ereignisgesteuerten kollaborativen Prozessen behandelt (s137) nur um sofort zu erkennen, dass sich damit technische Workflows nicht realisieren lassen. Dabei wird übersehen oder übergangen, dass die Realität der Unternehmenswelt nicht aus Flussdiagrammen besteht sondern aus ereignisgesteuerter Kollaboration. Es wird das Flussdiagram zum Dogma und zum Massstab aller Dinge. Die IT vergisst, dass Flussdiagramme nur zur technischen Umsetzung benötigt werden.

Das Buch ist leider tatsächlich ein Leitfaden für die heute total irregeleitete Prozessmanagement-Praxis mit BPM Software.

Das Buch ist einer der wenigen Ratgeber, die ich kenne, die es tatsächlich erfolgreich schaffen, einen praxisrelevanten Bogen vom Geschäftsprozess bis hin zur Implementierung in einem Workflow Management System (oder Business Process Management System - BPMS, da gibt es keinen Unterschied mehr) zu spannen, ohne im theoretisch-methodischen Geschwafel stecken zu bleiben. Das heißt aber nicht, dass das Buch ohne einen zugrunde liegenden methodisch fundierten Rahmen wäre: Er wird nur nicht überbetont, sondern durch handliche und ganz konkrete Handlungsanweisungen und Ratschläge (bis hin zu Checklisten im Anhang) ergänzt.

Damit kann das Werk wirklich zu einem Standardleitfaden für alle diejenigen werden, denen in ihrer heutigen oder zukünftigen Rolle einmal eine der zahlreichen Aufgaben in derartigen (IT-technischen) Umsetzungsprojekten heran getragen wird: Sei es als Projektmanager, als Analytiker, als Requirements Engineer, aber auch als Software Entwickler mit Affinität zu Workflow Management Systemen. Ganz wichtig und besonders als Zielgruppe hervorzuheben sind natürlich die Architekten und Designer von derartigen 'Workflow basierten Lösungen'. Das Buch ist aber auch ' vor allem durch seine klare und leicht zugängliche, aber deshalb nicht ungenau Sprache ' empfehlenswert für Prozessmanager oder Organisatoren und sonstige Mitarbeiter der Organisationsabteilung, die ein bisschen mehr die IT-Seite von Workflow Management Systemen und entsprechenden Implementierungsprojekten verstehen wollen. Da auch die Problematik und der Prozess der Auswahl möglicher BPMS Systeme sehr gut dargestellt wird, sind auch die Personen derartiger Evaluierungsteams ('Proof of Concept' etc.) im Fokus des Werks.

Das Werk richtet sich auch an Einsteiger (auch absolute Neulinge!) in diese Problematik im 'Graben' zwischen Prozessabteilung und IT, also auch an Personen, die noch nie derartige (Prozess oder Workflow) Projekte gesehen haben und sich auch (noch) nicht anderweitig über derartige Vorhaben informiert haben. Mit zunehmender Erfahrung werden die potenziellen Leser die Kapitel etwas selektiver in Anspruch nehmen und vor allem diejenigen Inhalte nutzen, die sie noch nicht in den Projekten benötigt haben. Die Darstellung ist dabei so schlank gehalten, dass man immer ganz nah an der Praxis bleiben muss: Auf langatmige theoretische Abschweifungen verzichten die Autoren zu Recht und bringen lieber eine Checkliste mehr.

Hinsichtlich der technischen und methodischen Inhalte kann ich nur bestätigen, dass diese absolut state-of-the-Art repräsentieren. Auch Standards (WS-BPEL, XPDL, BPMN) werden dem Leser locker aber exakt und richtig nahe gebracht, ebenso wie die etwas technischeren Konzepte von Integrationsarchitekturen im Rahmen einer service-orientierten Architektur oder Probleme im B2B (Business to Business) Bereich.

Am meisten gefällt mir aber die differenzierte und nuancierte Herangehensweise der beiden Autoren in einigen wichtigen Bereichen, die sich wohltuend vom Marketinggetöse der BPMS Hersteller unterscheiden. Hier merkt man die langjährige Projekterfahrung und die exzellenten Kommunikationsfähigkeiten der beiden Autoren in diesem Bereich.

Beispiel 'Schwach strukturierte Workflow': Hier wird zu Recht darauf hingewiesen, dass klassische BPMS Systeme tendenziell von fixen und vorstrukturierten Prozessen ausgehen. Sollte diese Voraussetzung nicht zutreffen, müssten man dann eben IT-technisch eher Case Management oder Collaboration Tools für die 'Automatisierung' einsetzen und nicht ein BPMS System.

Beispiel 'Direkte Überführung meines ARIS/ADONIS/whatever Modells in mein BPMS: Da kann ich mein Prozessmodell dann gleich ausführen': Hier wird endlich einmal nicht das Einhorn vom 'universellen und einheitlichen Prozessmodell für alle' beschreiben, sondern sachlich und absolut richtig mehrere Varianten für diese Transformationsleistung vorgestellt. Die formulierten Empfehlungen decken sich dabei exzellent mit unseren (Software AG) eigenen Erfahrungen aus wirklich sehr vielen derartigen Implementierungsprojekten (wir haben sogar unabhängig von diesem Buch eine isomorphe Terminologie entwickelt).

Beispiel: Abwägung Open Source BPMS Produkte versus Lizenzprodukte: Die vorgestellten Checklisten eines Anforderungsmanagements erlauben es, diese Frage ganz sachlich und unemotional anzugehen, ohne gleich Glaubenskriege anzetteln zu müssen.

Andererseits scheut das Buch auch nicht davor, möglicherweise 'heilige Kühe' zu opfern, bspw. was den aktuellen internationalen Standard zur Prozessmodellierung, die Business Process Modeling Notation (BPMN) anbelangt, die natürlich der (in Deutschland 1993 erfundenen) EPK (ereignisgesteuerten Prozessknoten) vorzuziehen ist. Aber auch hier bleiben die Autoren sachlich und abwägend und sind nie dogmatisch, gerade was die viel zu oft und zu Unrecht geforderte Frage nach 'Welche Standards unterstützen sie' anbelangt.

Hervorzuheben ist weiters die Qualität der Handlungsanleitungen: Die vorgeschlagenen Gliederungen, Aktivitäten, Listen, Anforderungskatalogen, Checklisten, Workshop Agenda u.a.m. bieten einen wirklich guten ersten Einstiegspunkt für die ganz konkrete Projektarbeit über alle Phasen von derartigen BPMS Auswahl- und Implementierungsprojekten. Wenn sie für das nächste Workshop, für die nächste Präsentation noch nichts vorbereitet haben, könnte man ganz leicht als Einstieg und exzellenten Start einfach die entsprechenden Vorschläge des Buchs präsentieren. Der Text und die gut dosierten Hintergrundinformationen erlauben es weiters auch, dass sie als Projektleiter oder Präsentator das Workshop professionell und vor allem gut und heil überstehen.

Der leichte Text wird durch wirklich viele (gute) Graphiken und Tabellen ergänzt; an manchen Stellen finden sich sogar Ausschnitte aus (WS-BPEL oder XML) 'Code', um das Geschriebene auch technisch abzusichern (Das Buch ist natürlich kein BPMS, WS-BPEL, Java oder XML Programmier-Buch).

Der guten Ordnung halber möchte ich noch auf die Rezension von Hrn. Max J. Pucher eingehen: Hr. Pucher qualifiziert das Werk in einer irreführenden und nicht mehrheitsfähigen Weise herab, die von derart groben Missverständnissen (auf Seite von Hrn. Pucher) und falschen Behauptungen strotzt, dass ich mich frage, ob das Buch (und ich selbst) und Hr. Pucher über dieselben Begriffe 'Geschäftsprozesse' und 'Workflow Management Systeme' sprechen. Offensichtlich ist das nur eine Gegenreaktion auf einen länglichen und mühsamen Thread in der XING Gruppe 'Geschäftsprozessmanagement', in dem Hr. Pucher nicht konsensfähig eine extrem eigenwillige Interpretationen dieser Begriffe (samt Software) kommuniziert hat. Seine Meinung entspricht keinesfalls dem, was die nationale und internationale BPM Community sowohl in Wissenschaft als auch in der informierten Praxis über diesen Gegenstand denkt und handelt.

Jetzt aber wieder zurück zum Buch: Natürlich hätte man an der einen oder anderen Stelle noch mehr (vertiefende) Informationen bringen können (schauen sie einfach im online Inhaltsverzeichnis nach, wie viele Seiten ihrem ganz persönlich wichtigen Thema gewidmet sind!): Die 271 Seiten Text (ohne Glossar und Index!) sind aber ein derart exzellenter Einstiegstext in diese Materie, dass eine Vertiefung in weiterer Fachliteratur locker und mühelos möglich ist.

Abschließend kann ich meine Kaufempfehlung für die oben angeführte Zielgruppe nur nochmals wiederholen: Sie werden es nicht bereuen!