Erfolgreiche Einführung von Business Process Management (BPM)

Architektur/Methoden  –  0 Kommentare

Ein Klischee im Zusammenhang mit Business Process Management (BPM) hat sich lange Zeit hartnäckig gehalten: Es sei komplex, teuer und scheitere häufig. Heute besteht allerdings kein Grund mehr zu jenem Pessimismus, denn mittlerweile hat sich auf dem Gebiet einiges getan. Bei Beachtung der folgenden acht Regeln sollte einer erfolgreichen BPM-Einführung nichts mehr im Wege stehen.

Dieser Artikel dient nicht als Einführung in BPM, sondern beginnt vielmehr mit einem Anwendungsfall als Beispiel, um Best Practices und häufig begangene Fehler im BPM-Umfeld zu erläutern. Die dafür ausgewählte Anwendung ist ein Kreditantrag. Abbildung 1 zeigt den zustandsbehafteten, lang laufenden Geschäftsprozess eines solchen Antrags. Das Schaubild beschreibt den Prozess und umfasst die Ausführung automatischer Skripte und Services sowie die Interaktionen mit den Menschen. An der Modellierung sind sowohl Fachbereich als auch der IT-Bereich beteiligt. Abhängig von den Ergebnissen der einzelnen Bearbeitungsschritte wird der Kreditantrag schließlich am Ende des Prozesses akzeptiert oder abgelehnt.

Geschäftsprozess für einen Kreditantrag (Abb. 1)

BPM ist kein Schweizer Taschenmesser, das als Allzweckwaffe für jedes Problem das passende Werkzeug bereithält. Oder anders formuliert: Es ist nicht die Antwort auf alle Fragen und sollte in bestimmten Situationen sogar vermieden werden. Insbesondere ist nicht für jeden Geschäftsprozess oder Workflow gleich BPM notwendig. Abläufe, bei denen BPM keinen Mehrwert schafft, sollte man wie bisher einfach ausprogrammieren. BPM schafft insbesondere Mehrwert bei lang laufenden, zustandsbehafteten Prozessen, sich häufig ändernden Prozessen und dem manuellen Eingriff durch Menschen.

Der Kreditantrag ist ein gutes Beispiel für lang laufende, zustandsbehaftete Prozesse und menschliche Interaktionen. Bei ihnen lohnt sich die Einführung von BPM. Denn durch seinen Einsatz wird spürbarer Mehrwert geschaffen, indem sich die Transparenz und die Flexibilität der Prozesse bemerkbar erhöhen. Die eigenständige Implementierung der Prozesslogik dagegen wäre mit deutlich mehr Aufwand verbunden und fehleranfälliger.

Regel 1: Um BPM erfolgreich zu gestalten, darf es nur eingesetzt werden, wenn es wirklich Mehrwert schafft.

BPM hat das Ziel, Geschäftsprozesse fortlaufend zu verbessern und lässt sich insofern als "Prozessoptimierungsprozess" verstehen. Vor allem das Business/IT-Alignment – die Abstimmung von
Geschäftsfunktionen und IT – ist der Schlüssel zum Erfolg. Denn bei der Prozessoptimierung geht es weder allein um die IT noch ausschließlich um das Geschäft. Für eine erfolgreiche Einführung von BPM sind viel Kommunikation und gute Zusammenarbeit zwischen den Fachabteilungen und der IT notwendig. Das zu erreichen ist eine der größten Herausforderungen von BPM. Dabei werden folgende Ziele verfolgt:

  • erhöhte Effizienz
  • erhöhte Transparenz
  • erhöhte Flexibilität
  • bessere Qualität
  • reduzierte Kosten
  • Erschließung neuer Geschäftsmodelle

Das wichtigste Ziel im konkreten Anwendungsfall ist, mehr Transparenz und höhere Flexibilität während des gesamten Verlaufs eines Kreditantrags zu schaffen. Fachbereich und IT sollen gemeinsam die einzelnen Prozessschritte optimieren und, wo immer möglich, auch automatisieren. Die Einführung von BPM ist nur erfolgreich, wenn diese Ziele von Beginn an im Mittelpunkt stehen. Mindestens ebenso wichtig ist, dass die Entscheidungsträger das Projekt von Anfang an unterstützen und ihr Rückhalt für alle Projektbeteiligten erkennbar ist. Ein BPM ohne konkretes Ziel funktioniert nicht. Zudem sollten Leistungskennzahlen festgelegt werden, um den Erfolg oder Nichterfolg der Einführung messen zu können.

Regel 2: Um BPM erfolgreich zu gestalten, sind die Ziele klar zu definieren und transparent zu machen.

Serviceorientierte Architekturen (SOA) sind das Grundgerüst, auf dem Ansätze wie BPM, Cloud Computing oder Mashups beruhen, wie es Anne Thomas Manes 2009 in ihrem Artikel "SOA is dead; Long Live Services" treffend beschrieben hatte. Insofern ist BPM eine logische Evolution, die sich aus SOA heraus entwickelt hat.

Ein auf SOA beruhendes BPM ist die passende Antwort auf das steigende Verlangen nach einer flexiblen Anwendungslandschaft, anstatt wie bislang in den engen Grenzen starrer Silos zu verharren. Moderne Anwendungen und Ressourcen sollten lose gekoppelt und abgegrenzt von den Prozessen sein. Ansonsten wird die Prozesslogik fest in eine bestimmte technische Plattform gezwängt, wodurch Änderungen zeitaufwendig und teuer werden und damit den eigentlichen Zweck von BPM ad absurdum führen. Ohne SOA und dessen Services mit sauber definierten Schnittstellen ergibt eine BPM-Einführung wenig Sinn. Denn die Vorteile einer erfolgreichen BPM-Anwendung lassen sich ohne Services nicht realisieren.

Im Anwendungsfall ist der Kreditantrag in zahlreiche lose gekoppelte Services aufgeteilt, etwa Skript- oder Java-Service-Tasks und menschliche Interaktion. Das Fundament für eine erfolgreiche BPM-Einführung ist damit gelegt. Würde man den gesamten Kreditantrag hingegen als eine einzige, große Aufgabe betrachten, wären BPM-Ziele wie höhere Flexibilität und verbesserte Effizienz nicht erreichbar.

Regel 3: Um BPM erfolgreich zu gestalten, muss es auf einer serviceorientierten Architektur beruhen.

BPM ist nicht nur Tooling. Stattdessen geht es bei der Prozessoptimierung um ein lang laufendes Vorgehen mit zahlreichen Individuen, Techniken und Tools. Der BPM-Lebenszyklus besteht aus folgenden Phasen, die sich iterativ wiederholen: Analyse, Modellierung, Ausführung, Überwachung und Optimierung.

Das Tooling ist wichtig und sollte den gesamten Lebenszyklus unterstützen. Dennoch wäre die Strategie, zunächst ein BPM-Tool einzuführen und danach mit der Modellierung sowie der Umsetzung zu beginnen, wenig ratsam und kann schnell scheitern. Sobald die ersten Geschäftsprozesse modelliert wurden und klar ist, wie sie ausgeführt und überwacht werden sollen, kann man BPM-Tools evaluieren, vorher nicht.

Nicht selten sind zu Beginn eines Projekts viele Anforderungen noch unbekannt oder unklar. So werden in dem Prozess für einen Kreditantrag vermutlich einige komplexe Geschäftsregeln zur Ermittlung der Kreditfähigkeit des Kunden benötigt. Da sich die Regeln häufig ändern, müssen sie flexibel konfigurierbar sein. Dann wäre ein Tool, das keine Rules Engine integriert hat, sicherlich nicht die beste Entscheidung. Denn die nachträgliche Integration einer eigenen Rules Engine bedeutet zusätzlichen Aufwand und erhöht die Komplexität. Daher empfiehlt es sich, dem BPM-Lebenszyklus zu folgen und nicht schon zu Beginn das möglicherweise falsche Produkt auszuwählen. Durch das Vorgehen reduziert man nicht nur den Aufwand, sondern versteht auch die Rollen und Prozesse einfacher. Letztlich ermöglicht das die Auswahl richtiger beziehungsweise sinnvoller Tools.

Regel 4: Um BPM erfolgreich zu gestalten, ist von Beginn an der gesamte Lebenszyklus zu betrachten.