Geschäftsprozessmanagement mit IBM WebSphere

Geschäftsprozesse und Wettbewerbsfähigkeit

Die Optimierung der Geschäftsprozesse hat wesentlichen Anteil an der Wettbewerbsfähigkeit eines Unternehmens: Je effizienter, schneller, kostengünstiger und qualitativ hochwertiger die Prozesse ablaufen, desto höher ist die Zufriedenheit bei Endkunden, weil das Unternehmen im Vergleich mit der Konkurrenz Produkte und Dienstleistungen günstiger und mit besserer Qualität anbieten kann – entscheidend für die Kaufentscheidung der Endkunden.

Neben diesem eher statischen Vorteil der Geschäftsprozesse wird ihr dynamischer Aspekt heute immer wichtiger: In einem sich schnell ändernden Umfeld mit weltweiten Wettbewerbern und Kunden müssen Unternehmen in der Lage sein, ihre Produkte und Dienstleistungen ebenfalls schnell an sich ändernde Märkte anzupassen. Nur so erreichen sie entweder einen Wettbewerbsvorteil, oder erhalten bereits erworbene Wettbewerbsvorteile auch in Zukunft. Damit das möglich ist, müssen sie ihre Geschäftsprozesse erst im Detail kennen, um sie dann schnell ändern und besser managen zu können. Wenn ihnen das gelingt sind sie in der Lage, neue Märkte und Kunden mit neuen oder veränderten Produkten und Dienstleistungen auf eventuell neuen Vertriebskanälen zu erreichen. Kenntnis über die eigenen Geschäftsprozesse und wie diese zum eigenen Unternehmensmodell passen, oder eben nicht passen, helfen auch entscheident sich als Unternehmen weiterzuentwickeln, um die möglicherweise notwendigen Änderungen erfolgreich anzugehen (Stichwort ‚Business Transformation’).

Was ist Geschäftsprozessmanagement?

Was aber genau ist nun Geschäftsprozessmanagement? Gemäß der Definition der Analysten von Gartner beschreibt Geschäftsprozessmanagement „einen Satz von Services und Werkzeugen für explizites Prozessmanagement, welches Prozessmodellierung, Prozessanalyse, Prozesssimulation, Prozessautomation, Prozessüberwachung und Prozessverwaltung beeinhaltet, und das idealerweise die Integration von komplett automatisierten Prozessschritten sowie manuellen Prozessschritten unterstützt“. Die Betonung dieser Definition liegt dabei auf ‚explizit’: Geschäftsprozessmanagement erfordert, dass Prozesse visuell in Form von Prozessmodellen, zum Beispiel in Form von Graphen, vorliegen.

Klicken zum Vergrößern

Modellierung, Automatisierung und Monitoring von Geschäftsprozessen

Wenn man sich diese Definition genau ansieht, erkennt man, dass Geschäftsprozessmanagement im wesentlichen aus vier Phasen besteht:

1. Erstellung und Analyse der Prozessmodelle aus fachlicher Sicht
2. Überführung der fachlichen Prozessmodelle in technische Prozessmodelle, die automatisch, das heisst Softwareunterstützt, ausgeführt werden können
3. Bereitstellen der für die automatische Prozessausführung benötigten Komponenten (das heisst zum Beispiel: Möglichkeiten zur Einbindung vorhandener und neu zu schreibender Anwendungen, Bereitstellen von Benutzeroberflächen zur manuellen Interaktion, etc)
4. Beobachtung und Kontrolle der automatisierten Prozesse dahingehend, ob im Vorfeld definierte Kenngrössen eingehalten werden oder nicht

Diese Zusammenhänge sind in der nebenstehenden Graphik dargestellt

Produktportfolio der IBM für Geschäftsprozessmanagement

IBM hat mit seiner Produktpalette ‚IBM WebSphere Process Integration’ ein Komplettangebot für Geschäftsprozessmanagement und verfügt damit über eine Familie von Produkten, die primär die Modellierung, Analyse, Ausführung und die Überwachung von Geschäftsprozessen zum Ziel hat.
Hier die Produktliste der Kernprodukte für Geschäftsprozessmanagement von IBM:

Klicken zum Vergrößern

IBM WebSphere Process Integration Produkte

• WebSphere Business Modeler – Für Geschäftsprozessmodellierung und Analyse (hier erstellte Prozessmodelle werden in den nachfolgenden Produkten wiederverwendet)
• WebSphere Integration Developer – Für die technische Anreicherung der fachlichen Prozessmodelle, die aus WebSphere Business Modeler übernommen werden, und dann von WebSphere Process Server ausgeführt werden
• WebSphere Process Server – Für die Automatisierung von Prozessen, die dem BPEL-Standard folgen und als moderne J2EE Anwendung basierend auf WebSphere Application Server realisiert werden
• WebSphere ESB – Das Rückgrat der SOA IT-Infrastruktur, welches es erlaubt, alle benötigten Services zu verwalten, zu finden und zu verwenden
• WebSphere Business Monitor – Für das Überwachen der Ausführung von Geschäftsprozessen, und für das Aufbereiten und Darstellen der vordefinierten Key Performance Indikatoren (KPIs)

Geschäftsprozessmanagement und SOA – wie geht das zusammen?

Geschäftsprozessmanagement und SOA (Service-orientierte Architektur) ergänzen sich hervorragend – und mehr als das, sie beschreiben die zwei Seiten der gleichen Medaille. Wenn man so möchte ist SOA die technische Umsetzung – oder Vorraussetzung – von Geschäftsprozessmanagement, und Geschäftsprozessmanagement ist das, was man schlussendlich bekommt, wenn man in SOA investiert hat. Der entscheidende Punkt ist nun zu wissen, wer sich für was interessiert. Die Antwort hierfür ist denkbar einfach: Fachbereiche und vor allem die Entscheidungsträger auf der fachlichen Seite interessieren sich für ihre Geschäftsprozesse, und wie sie diese besser beherrschen können, also für Geschäftsprozessmanagement, wohingegen sich die IT Seite dafür interessiert, mit welcher Technologie sie den Fachbereich besser unterstützen kann, und damit also für SOA.

Klicken zum Vergrößern

Trennung von Geschäftsprozesslogik und IT-Implementierung durch SOA -Einsatz

Der wichtigste Vorteil in der Verknüpung von Geschäftsprozessmanagement und SOA liegt in der Trennung von Geschäftslogik und IT-Implementierung: Im Rahmen der Geschäftsprozessmodellierung werden die Geschäftsprozesse vollkommen losgelöst von ihrer späteren Implementierung betrachtet, und werden von den Prozessmodellierern auch nach ganz anderen – nämlich nicht-technischen – Gesichtspunkten analysiert. Bei der späteren Automatisierung mit einer process engine muss dann für jede Prozessaktivität ein Service vorhanden sein, der in einer SOA bereitgestellt wird, und von der process engine entsprechend angefordert wird. Der grösste Vorteil der SOA liegt hierbei in der standardisierten Beschreibung dieser Services: Aus Prozesssicht ist es vollkommen irrelevant – und oberhalb eines bestimmten Levels auch unklar – wie der jeweilige Service implementiert ist, da dessen Implementierung hinter dem standardisierten Service-Interface versteckt ist..... Das heisst, dass die process engine nicht weiss, und auch nicht wissen muss, ob sich hinter dem Service ein Web Service versteckt, oder ein SAP BAPI Aufruf, oder ein DB2 Call, oder ein EJB, oder eine MQ Message, oder ein Mensch (!), oder eine beliebig andere wie auch immer geartete Implementierung.

Diese Trennung von Business Logik und Service-Implementierung ermöglicht auch das, was heute so dringend benötigt wird, nämlich: Ungeahnte Flexibilität! Der Einsatz von SOA für BPM erlaubt es folgendes zu tun:

1. Die Prozesse können geändert oder angepasst werden, ohne dass die darunterliegenden Services geändert werden müssen (so lange sich an der Serviceanfrage nichts ändert).
2. Die Implementierung der Service selbst kann geändert oder angepasst werden, ohne dass sich am Prozessmodell und am Prozessablauf etwas ändert.

So kann man beispielsweise die Abfolge der Serviceaufrufe im Prozessmodell ändern, um den Prozess einer bestimmten neuen geschäftlichen Anforderung anzupassen. Oder, wenn es um die Implementierung eines bestimmten Services geht, kann man eventuell statt einem manuell auszuführenden Service diesen austauschen durch eine Implementierung mit einer Business Rules Engine. Tatsächlich bietet diese Trennung zwischen Geschäftslogik und Service-Implementierung die Möglichkeit hochgradig flexible neue Lösungen bereit zu stellen.

Im Rahmen von eher groß angelegten SOA Projekten stellt sich allerdings auch die zentrale Frage, wie denn die benötigten Services identifiziert werden können. Um diesen Schritt zu unterstützen, gibt es eine auch von der IBM verwendete Methode, nämlich SOMA – Service Oriented Modeling Architecture. SOMA beschreibt im wesentlichen drei verschiedene Ansätze um die Suche nach den benötigten Services zu unterstützen:

1. Existing System Analysis – Hier verwendet man Software Tools, um bestehende Anwendungen (wie zum Beispiel CICS oder andere) auf deren existierenden Interfaces hin zu untersuchen. Die gefundenen Interfaces können dann in SOA-konforme Interface transformiert und im Rahmen von SOA-Lösungen verwendet werden.
2. Goal-Service Modeling – Hier werden vordefinierte Unternehmensziele den vielleicht noch zu erstellenden Services zugeordnet, die dazu dienen sollen, diese Unternehmensziele zu implementieren.
3. Domain Composition – Bei diesem Ansatz wird das Unternehmen in seine Geschäftseinheiten zerlegt, wobei untersucht wird, welche Services von einer bestimmten Geschäftseinheit gebraucht werden, oder welche Services sie anderen Geschäftseinheiten anbieten können. (Diese Untersuchungen werden in der Regel im Rahmen von Beratungsprojekten durchgeführt.) Diese Zerlegung kann in beliebiger Detailtiefe gemacht werden, und wird von IBM durch die Methode CBM (Component Business Modeling) unterstützt. Bei diesem Ansatz schaut man sich auch die Geschäftsprozesse an, so dass die Geschäftsprozessmodellierung einen wichtigen Beitrag bei der ‚Domain Composition’ bieten kann: Die Kenntnis der Geschäftsprozesse gibt demnach wichtige Einblicke in die Art von Services, die man braucht, damit die Geschäftsprozesse ausgeführt werden können.

Ausgehend von Geschäftsprozessmanagement (und das ist ja Gegenstand dieses Artikels) ist die Geschäftsprozessmodellierung der natürliche Einstieg um die für die Geschäftsprozessautomatisierung benötigten Services zu identifizieren. Andere Methoden wie CBM oder SOMA können die reine Geschäftsprozessmodellierung natürlich ergänzen.

Abschliessend zu SOA sei noch gesagt, dass IBM für SOA fünf verschiedene Einstiegspunkte definiert hat: People, Process, Information, Reuse und Connectivity. Der SOA-Einstiegspunkt ‚Process’ behandelt das hier diskutierte Thema Geschäftsprozessmanagement. Weitere Information über SOA ist verfügbar über den am Ende des Dokumentes angegebenen Link.

Menschen und Geschäftsprozesse – Zwei verschiedene Sichtweisen

Im Zusammenhang mit Menschen und Geschäftsprozessen im Rahmen der hier in diesem Dokument diskutierten Punkte für Geschäftsprozessmanagement gibt es zwei wesentliche und unterschiedliche Betrachtungsweisen, die anfänglich kurz gegenübergestellt werden sollen:

1. Der Mensch als Implementierungsdetails eines Services: In diesem ersten Fall ist der Mensch nur als Mittel zum Zweck zu betrachten, nämlich als das ausführende Organ eines Services, der im Rahmen von BPM auf SOA zu einem bestimmten Zeitpunkt im Prozessablauf angefordert wird. Aus reiner Prozesssicht ist es uninteressant, ob hinter der Komplettierung des Services ein Mensch gebraucht wird, oder nicht. Alles was zählt ist, ob der angeforderte Service – wie in seinen Service-Level Agreements beschrieben – mit den versprochenen Charakteristiken (Geld, Zeit und Qualität) komplettiert hat oder nicht.


2. Der Mensch und seine Arbeitsliste: In diesem Fall ist von Bedeutung, was die Mitarbeiter auf ihren Arbeitslisten alles machen können, vom einfachen Bearbeiten einer Aufgabe (work item) bis hin zur Umverteilung bereits verteilter Aufgaben, oder das Erstellen von neuen Aufgaben, oder vielem anderen mehr. Ebenfalls betrachten muss man, wie die Aufgabe dem Mitarbeiter präsentiert werden muss, das heisst, was der Mitarbeiter auf seinem Bildschirm sieht, wenn er die Aufgabe von der Arbeitsliste ausgewählt und gestartet hat. Im Prinzip muss man über den kompletten Reichtum an Funktionen nachdenken, die über eine User-Shell oder ein Unternehmensportal angeboten werden können. Wichtig ist hier, dass gestellte Aufgaben möglichst effizient erledigt werden; ob eine bestimmte Aufgabe dann von einer process engine im Rahmen eines automatisierten Prozesses erstellt wurde, kann für den Endbenutzer vollkommen transparent sein.

Im Rahmen von Geschäftsprozessmanagement sollte man beide Sichtweisen durchaus auch separat betrachten, und jede Sicht entsprechend optimal implementieren: Human Task Manager implementiert entkoppelt von der process engine entsprechende Services, die von Menschen unterstützt werden, und die Präsentation dieser ‚Human Tasks’ (als work items au