"A fool with a tool is still a fool" - Dieser Satz fällt immer wieder, wenn es um die IT-Unterstützung von Business-Process-Management (BPM) geht. Er steht stellvertretend für eine lange Reihe schlechter Erfahrungen, die Unternehmen beim Beschaffen, Einführen und Nutzen von BPM-Software in den letzten Jahren gemacht haben. Diese Erfahrungen gehen primär auf zwei Ursachen zurück: erstens die außerordentliche Bandbreite des Themas BPM, die sich in der Heterogenität des Tool-Markts niederschlägt. Einfache Grafikeditoren zur Visualisierung von Prozessdiagrammen werden ebenso mit "BPM" etikettiert wie schwergewichtige EAI-Server (Enterprise Application Integration) für die prozessorientierte Applikationsintegration oder Dokumenten-Management-Systeme, die Workflow-Funktionen enthalten.

Zweitens haben die Softwarehersteller die Angewohnheit, möglichst viele ihrer Lizenzen verkaufen zu wollen. Das führt dazu, dass auf bunten Powerpoint-Folien immer häufiger der Himmel auf Erden versprochen wird: Wer den XYZ-BPM-Server beschaffe, praktiziere von heute auf morgen die Balanced Scorecard und Six Sigma, erhalte die vollständige Prozesstransparenz, setze dank Service-orientierter Architekturen (SOA) ein konsequentes Business-IT-Alignment um und werde im Großen und Ganzen einfach schneller, kostengünstiger und am Ende auch noch irgendwie sexy.

Risiken beim Tool-Einkauf

Vor diesem Hintergrund ist jeder Interessent zwei großen Risiken ausgesetzt: Er beschafft eine Lösung, die für seine aktuellen Bedürfnisse nicht wirklich geeignet ist. Und er verlässt sich auf die im Tool hinterlegte "Methodik", ohne selbst eine methodische BPM-Kompetenz aufzubauen oder einzukaufen. Wird auch nur einer dieser beiden Fehler begangen, scheitern Projekte in vielen Fällen. So ergab eine Befragung unter gut 100 Anwendern von BPM-Tools im Jahr 2007, dass die beschaffte Software die Erwartungen bei mehr als einem Drittel der Teilnehmer nur teilweise erfüllen konnte. Eine vollständige Auswertung der Befragung ist unter www.BPM-Software.de verfügbar.

Andererseits prognostizieren ernst zu nehmende Analysten wie Gartner gigantische Wachstumsraten für den BPM-Softwaremarkt, manch ein Experte vergleicht den Siegeszug solcher Programme gar mit dem der ERP-Systeme in den neunziger Jahren. Zur Bewertung dieser Prognosen muss man wissen, dass sich Gartner auf solche Lösungen bezieht, die das gesamte Spektrum von BPM abdecken, also sowohl die fachlich-organisatorische Seite zur Modellierung und Analyse von Geschäftsprozessen als auch die IT-zentrierte Seite zur Prozessautomatisierung.

Nutzen der Prozessautomatisierung

Der mögliche Nutzen der Prozessautomatisierung reicht über den reinen Abbau von Medienbrüchen und manuellen Aufwänden weit hinaus. Sie könnte die vielbeschworene prozessorientierte Unternehmenskultur in kleinen wie in größeren Unternehmen maßgeblich fördern. Um diese Potenziale zu erkennen, muss man das Kernprinzip der Prozessautomatisierung verstanden haben (siehe Grafik "Prozessautomatisierung").

Prozesse automatisieren bedeutet nicht, dass hinterher alles automatisch abläuft. Es bedeutet lediglich, dass die Steuerung des Prozesses durch einen Teil der BPM-Software, die Process Engine, vorgenommen wird. Diese Engine entscheidet, wann welche Akteure (Mitarbeiter, Partner, Manager, aber auch IT-Systeme) welche Aufgaben zu erledigen haben, um das Prozessziel zu erreichen. Die Zuweisung dieser Aufgaben an menschliche Akteure erfolgt beispielsweise über Web-basierende Aufgabenlisten, virtuelle Eingangskörbe oder auch einfach per Mail. Die Zuweisung von Aufgaben an IT-Systeme sind schlicht und ergreifend Service-Calls, womit wir schon beim "Popstar" Service-orientierte Architekturen (SOA) wären, ohne dieses komplexe Thema an dieser Stelle vertiefen zu wollen. Die Process Engine "schwebt" also über allen übrigen 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. Prozesskennzahlen wie etwa Durchlaufzeiten, werden aufgrund dieser zentralisierten Steuerung 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.

Natürlich sind in dieser vereinfachten Darstellung wichtige Aspekte ausgeklammert, zwei davon sollen exemplarisch skizziert werden: Die Reihenfolge der Aufgabenzuweisung orientiert sich an der definierten Prozesslogik, bestehend aus Kontrollstrukturen mit Sequenzen, Parallelisierungen, Verzweigungen, Schleifen etc.. Gerade die Verzweigungen nehmen eine zentrale Rolle ein, da diese inhaltlich häufig auf Geschäftsregeln basieren - das Business-Rules-Management (BRM) lässt grüßen. Weiterhin finden die Service Calls mitnichten immer in Form von Web-Service-Calls statt. Die Mehrheit der heute anzutreffenden IT-Landschaften besteht aus Systemen, die lediglich über proprietäre Schnittstellen verfügen, seien das BAPIs, Edifact-Formate oder auch ganz individuelle Textdateien auf Segmentbasis (Flatfiles). Selbst der Eintrag in einer Datenbanktabelle durch die Engine oder einen angeschlossenen Enterprise Service Bus (ESB) kann aus Sicht der Prozessautomatisierung ein Service Call sein, wenn dieser erfolgt, um ein IT-System, das auf der Tabelle arbeitet, dadurch zur Ausführung einer Aufgabe zu bewegen. Auch wenn diese großzügige Auslegung des Servicebegriffes so manchem SOA-Evangelisten die Zornesröte ins Gesicht steigen lässt, ändert das nichts daran, welchen Herausforderungen Unternehmen bei der Prozessautomatisierung begegnen, und wie sich diese - auf pragmatische Weise - bewältigen lassen.

Vision und Wirklichkeit

Das vorgestellte und im Grunde sehr einfache Kernprinzip ist die Grundlage zahlreicher Visionen, die mit BPM in Zusammenhang gebracht werden. Eine davon ist die Hoffnung, man könne zukünftig Prozessmodelle durch das Business erstellen und anpassen lassen. Sobald dies erfolgt ist, werde das Modell auf Knopfdruck in die Realität überführt, also an die Process Engine übergeben, und der Prozess genauso ausgeführt, wie das vom Business gewünscht ist. Diese Hoffnung als Illusion zu entlarven ist mittlerweile die Lieblingsbeschäftigung vieler Berater, deren Kernkompetenzen in anderen Themengebieten liegen. Tatsächlich sind wir heute noch weit davon entfernt, reale Prozessabläufe per "Drag and Drop" gestalten zu können, und es stellt sich mitunter auch die Frage, ob das überhaupt zielführend ist. Man sollte jedoch nicht den Fehler machen, die sehr wohl vorhandenen Möglichkeiten einer gesteigerten Agilität auf Basis von Prozessmodellen, die in der Automatisierung ausgewertet werden, einfach als "Buzzword-Bingo" abzutun.

Welche Rolle spielt BPMN?

In diesem Kontext spielt die Business Process Modeling Notation (BPMN) eine zunehmend wichtige Rolle. Dabei handelt es sich um eine durch die Object Management Group (OMG) standardisierte Prozessnotation, die sich mit rasantem Tempo weltweit verbreitet. Diese Popularität beruht vor allem auf der Fähigkeit von BPMN, bestimmte für die Prozessautomatisierung relevante Informationen so zu visualisieren, dass Mitarbeiter aus den Fachabteilungen sie verstehen und teilweise sogar selbst modellieren können.

Ein Beispiel: Die Grafik "Prozessdiagramm" zeigt einen sehr kleinen Ausschnitt eines möglichen Business Process Diagram (BPD), so die offizielle Bezeichnung von BPMN-Modellen. Dargestellt ist hier, dass die Aktivität "Anfrage prüfen" maximal zwei Tage in Anspruch nehmen darf (im Sinne der Durchlaufzeit). Ist diese Zeitspanne überschritten, dauert die Abarbeitung dieser Aufgabe also zu lange, soll eine Eskalation eingeleitet werden ("Vorgesetzten informieren"). Eine Process Engine kann genau diesen Sachverhalt zur Steuerung verwenden: Die Aufgabe "Anfrage prüfen" wird dem Sachbearbeiter zugewiesen. Erhält die Engine nach zwei Tagen noch kein Signal, dass die Anfrage geprüft wurde (zum Beispiel durch einen veränderten Datensatz in einer Tabelle des CRM-Systems oder eine Mail, die der Sachbearbeiter an die Engine geschickt hat), informiert sie automatisch per Mail, SMS oder Ähnliches diejenige Person, welche im Organigramm, das in der BPM-Software hinterlegt ist, als Vorgesetzter des Sachbearbeiters gilt. An dieser Stelle ist anzumerken, dass auch dieses Organigramm wiederum aus führenden Systemen importiert werden könnte, etwa aus SAP-HR oder einem Active Directory.

Dank BPMN und der geeigneten BPM-Software ist dieser Sachverhalt fachlich eindeutig und in standardisierter Form dokumentiert, er entspricht der Realität. Selbst eine Prozessanpassung durch das Business ist möglich, denn die an der Uhr eingetragene Zahl von zwei Tagen lässt sich beliebig verändern, genauso wie die Rolle desjenigen, der im Falle der Zeitüberschreitung benachrichtigt werden soll. Der Prozess könnte zum Beispiel etwas "sanfter" gestaltet werden, indem der säumige Sachbearbeiter zunächst an seine Aufgabe erinnert wird, bevor der Vorgesetzte eingeschaltet werden muss.

Dieses Beispiel soll jedoch nicht den Eindruck erwecken, es sei problemlos möglich, komplexe Prozesse mittels BPMN komplett fachlich zu gestalten und direkt zur Ausführung an die Engine zu übergeben. Insbesondere ein komplettes Mapping von BPMN auf die Business Process Execution Language (BPEL), das gern propagiert wird, ist aufgrund syntaktischer Differenzen zwischen der Notation (BPMN) und der Sprache (BPEL) heute noch nicht möglich. Das sehr große öffentliche Interesse an BPEL steht aufgrund dieser Fehleinschätzung in krassem Widerspruch zur verfügbaren Praxiserfahrung, wie eine aktuelle Auswertung von Profilen zeigt, die in der Online-Community BPM-Netzwerk.de hinterlegt sind: Mehr als 400 Personen, die sich für BPEL interessieren, stehen lediglich 43 Personen gegenüber, die diese Sprache tatsächlich schon praktisch genutzt haben.

Die Kernfrage ist jedoch nicht, wie gut oder schlecht BPMN, BPEL oder andere Standards heute funktionieren. Es geht vielmehr darum, zu erkennen, dass mit der Prozessautomatisierung eine neue Form der Unternehmensorganisation ermöglicht wird, die sich gleichermaßen auf Menschen wie auf Software bezieht. Diese kann eine prozessorientierte Denkweise in den Unternehmen Schritt für Schritt etablieren, ohne quälende Motivations-Workshops und endlose Papierschlachten, deren Ergebnisse häufig so nachhaltig wie Strohfeuer sind.

Nichtsdestotrotz haben auch die Softwarehersteller noch einen langen Weg vor sich, um ein IT-gestütztes Prozess-Management wirklich zu ermöglichen. All diese Baustellen hier aufzuzählen würde zu weit führen, nur einige wenige sollen genannt werden: Da wäre zunächst die konsequente Verzahnung der fachlichen und technischen Prozessmodelle. Das vorgestellte Beispiel der Eskalation bei Zeitverzögerung ist längst nicht in allen Werkzeugen verfügbar, und auch bei der Zuordnung gemessener Kennzahlen zu fachlichen Prozessmodellen haben die meisten Produkte noch große Defizite. Dieses Problem besteht insbesondere bei "Patchwork-Lösungen", also Paketen aus ursprünglich isolierten Tools, die bestimmte Teilbereiche (beispielsweise fachliche Modellierung und technische Ausführung) abdecken und über Schnittstellen miteinander integriert wurden. Aber auch die konsequente Abbildung von Notationsregeln oder Funktionen für das Service-Management fehlen häufig oder sind, je nach Herkunft der Lösung, nur halbherzig umgesetzt.

Tipps für die Praxis

Es stellt sich nun die Frage, wie sich innovationsbereite Unternehmen angesichts dieser Situation verhalten sollen. Abwarten, bis die Produkte reifer sind? Oder mutig ins kalte Wasser springen und frühzeitig Strukturen schaffen, die eine Differenzierung gegenüber dem Wettbewerb erlauben? An dieser Stelle soll der "Step-by-Step"-Ansatz empfohlen werden, das heißt die Beschaffung und Nutzung einer BPM-Software für ein begrenztes Szenario, um aus diesem zu lernen und eine weitere Ausdehnung der Nutzung kontrolliert zu planen und zu steuern. Dieser Ansatz ist wegen der Preise und Schulungsaufwände für solche Lösungen allerdings problematisch. Die Kosten können in der Summe schnell im sechsstelligen Bereich liegen und lassen sich durch "begrenzte Szenarien" selten rechtfertigen. Für dieses Problem existieren drei Lösungsansätze.

Erstens sind im Markt durchaus preisgünstige und in der Bedienung relativ einfache Lösungen verfügbar. Der Nachteil dieser Tools ist häufig ihr beschränkter Funktionsumfang. Viele von ihnen eignen sich lediglich für die fachliche Dokumentation von Prozessen oder die Analyse mit Hilfe geschätzter Kennzahlen. Auch wenn sie ein organisatorisch getriebenes BPM sehr gut unterstützen können, reichen sie für die Prozessautomatisierung allein nicht aus. Sie können aber die ersten konzeptionellen Schritte hervorragend abbilden.

Zweitens entwickeln sich auch im Open-Source-Markt mittlerweile ernst zu nehmende Produkte wie etwa JBoss jBPM. Diese Process Engine konnte ihre Praxistauglichkeit auch in kritischen Szenarien schon häufig unter Beweis stellen. Unternehmen sollten jedoch bedenken, dass solche Lösungen in der Regel weniger benutzerfreundlich sind als ihre kommerziellen Pendants und deshalb einen höheren Schulungsaufwand oder den Einkauf externer Unterstützung erfordern. Unglücklicherweise wird der Begriff Open Source darüber hinaus immer häufiger von Herstellern verwendet, deren Tools keineswegs quelloffen verfügbar sind, sondern lediglich in deutlich abgespeckter Form als Community Edition.

Drittens wird mittlerweile auch das Prinzip der Software as a Service (SaaS) mit BPM kombiniert. Dabei beschaffen Firmen keine eigene BPM-Software, sondern nutzen die Lösung, die der Anbieter auf eigenen Servern bereitstellt. Die Zuweisung der Aufgaben an die Mitarbeiter und IT-Systeme erfolgt dann via Internet, wobei die notwendige besondere Sicherheit der Kanäle und Datenspeicher mit Hilfe moderner Verfahren gewährleistet werden kann. Da dieses "Process Hosting" oder "Process as a Service" (PaaS) nicht pauschal, sondern monatlich oder transaktionsbasiert vergütet wird und die Umsetzung der eigenen Prozesse durch die Mitarbeiter des Anbieters erfolgen kann, ist dieser Ansatz für die ersten Schritte gut geeignet. Sind diese erfolgreich absolviert, können Nutzer die Ausdehnung der Automatisierung und das Insourcing der Prozesse mit einer inhouse betriebenen Lösung erwägen.

Die optimale Lösung zu finden, sei sie nun kommerziell oder Open Source, inhouse oder gehostet, ist in keinem Fall ein triviales Unterfangen. Für viele Unternehmen dürfte sich diese Suche trotz alledem auch heute bereits lohnen.