Planung ist zwar für jedes Projekt wichtig, aber BPM-Projekte brauchen einen sehr viel flexibleren Planungsansatz als „normale“ Projekte, da sich Geschäftsprozesse über den Lebenszyklus hinweg häufig ändern können. Die zugrundeliegenden Technologien sollten diese Flexibilität zulassen, daher sollte man nicht versuchen, Prozesse hardkodiert in Form von Programmcode zu unterstützen. Ein guter Plan gibt dabei vor, wer was ändern darf, und welche Änderungen wann aktiviert werden sollen.

Flexibilität ist nicht nur in der Planung wichtig, sondern auch das Stichwort für die gesamte Unternehmenskultur. BPM ist anders, und es erfordert neue Denkweisen und Ansätze. Es sind Mitarbeiter gefragt, die einen kompletten Geschäftsprozess von Anfang bis Ende durchschauen und Wertschöpfungen erkennen können. Eine Kultur, in der Ideen und kreative Ansätze belohnt und gefördert werden, ist auch förderlich für BPM. Werden hingegen BPM Projekte als Rechtfertigung für Entlassungen angeführt, ist das für den Aufbau einer solchen Kultur schädlich. Ziel ist es, intelligentes, schnelleres, konsistentes Arbeiten zu erreichen. Kreative Mitarbeiter sind dabei der Schlüssel zum Erfolg.

Doch bei aller Liebe zum Prozess und den zugehörigen Planungsdetails sollte das ultimative Ziel nicht aus den Augen verloren werden: Der Nutzen für den Kunden. Letztendlich zielt BPM darauf ab, das gesamte Geschäft so zu sehen, wie der Kunde es sieht: als eine Reihe von zusammengehörigen Prozessen, die einen Kundenauftrag in eine Lieferung in Form eines Wirtschaftsguts oder einer Dienstleistung transformieren. Dem Kunden ist es dabei egal, wie es gemacht wird. Zum Schluss kommt es nur darauf an, ob Kunden einen Mehrwert erzielt haben. Das kann aber dazu führen, dass die Grenzen interner Zuständigkeiten neu definiert werden müssen.

Zurück zu Best Practices: Das erste BPM Projekt sollte sich im überschaubaren Rahmen befinden. Es gilt zwischen Risiko und Nutzen, Learning-by-doing und dem Appetit auf Veränderungen abzuwägen. Andererseits darf ein Projekt auch nicht zu klein sein, um einen messbaren Erfolg zeigen zu können. Messbarkeit bleibt gerade im BPM-Umfeld ein wichtiges Entscheidungskriterium und schafft Transparenz darüber, ob das Projekt erfolgreich läuft oder nicht.

Da Prozesse von der Zusammenarbeit im Unternehmen leben, ist es ebenfalls sinnvoll, verschiedene Verantwortliche mit den einzelnen BPM-Projekten zu beauftragen. In einem solchen Fall versteht jeder, dass man das BPM-Projekt des Kollegen am besten richtig unterstützt. Schließlich wird man dessen Hilfe bei dem eigenen Projekt ebenfalls benötigen. Das sorgt für die nötige Kollaboration.

Bei all den Änderungen, die sich durch BPM für ein Unternehmen ergeben, ist es schließlich nicht ratsam, alles alleine lösen zu wollen. Das Rad muss nicht immer wieder neu erfunden werden. Unabhängige Berater oder der Professional Service von Anbietern sind gute Informationsquellen, die im Ernstfall jederzeit angezapft werden können.

Gehören SOA und BPM wirklich zusammen, wie es Softwarehersteller und Analysten gerne propagieren? Spielt die Kombination in der Praxis überhaupt eine Rolle? In einer Diskussionsrunde auf der CeBIT prallten die Meinungen dazu aufeinander. “Mit SOA findet BPM endlich die vollständige Durchdringung in einem Unternehmen”, konstatierte etwa Daniel Liebhart vom Schweizer IT-Dienstleister Trivadis. Ganz anders Stefan Tilkov, Geschäftsführer der innoQ Deutschland GmbH: “Die Bedeutung der Synergie zwischen SOA und BPM wird überschätzt”, urteilte er. Die wenigsten Unternehmen hätten heute Prozessmodelle etabliert, die so formal sind, dass sie sich für die Ausführung eigneten. Tilkov: “Eine SOA, die sich als Rechtfertigung nur auf BPM verlässt, wird ihre Ziele kaum erreichen.”

Eine Zusammenfassung der Diskussion finden Sie hier.

Zum Autorenkreis stoßen vorerst vier ausgewiesene BPM-Experten, die auch die Brücke zum Thema SOA schlagen können: Sven Schnägelberger vom Kompetenzzentrum für Prozessmanagement, Jakob Freund, Gründer der Community BPM-Netzwerk.de, Dirk Stähler, Bereichsleiter Business Engineering bei Opitz Consulting, und Stefan Tilkov, Geschäftsführer der innoQ Deutschland GmbH.

Wir möchten Ihnen damit noch mehr Inhalte an der Schnittstelle zwischen SOA und BPM anbieten. Natürlich behandeln die Autoren auch weiterhin technisch orientierte SOA-Themen ohne den BPM-Aspekt. Zugleich aber gibt es Raum für klassische Prozessthemen. Ein neues Erscheinungsbild soll Ihnen das Navigieren in Beiträgen und weiteren Informationsangeboten erleichtern. Mit einem Mausklick gelangen Sie direkt zu passenden Fachartikeln und in das SOA Knowledge Center der COMPUTERWOCHE. Über die obere Navigationsleiste steht Ihnen eine SOA-FAQ und ein SOA-Glossar zur Verfügung.

Traditionell wird Geschäftsprozessmanagement als Management-Disziplin verstanden, die Unternehmen bei der kontinuierliche Verwaltung ihrer operativen Geschäftsprozesse unterstützt. Daneben wird BPM aber auch als Technologie zur Beschreibung, Steuerung, Ausführung und Überwachung von Prozessen, inkl. der Einbindung von Mensch und Maschine, im Sinne von Workflow einerseits und Systemintegration andererseits gesehen. Die Umsetzung von grafisch modellierten Geschäftsprozessen in ausführbaren Code in Form eines automatisierten Prozesses stellt hierbei die größte Herausforderung dar.
Der Grundgedanke einer SOA verspricht durch die Bereitstellung von Standards auch den entsprechenden Technologieplattformen Nutzen. Im Rahmen einer SOA sind im Wesentlichen zwei Ebenen zu unterscheiden: Die erste Ebene dient dazu, Services durch die Basisapplikationen bereitzustellen. Die zweite Ebene unterstützt die Konsumierung von Services, im Weiteren auch Service-Orchestrierung genannt. Gerade bei der zweiten Ebene spielen BPM Technologiekomponenten zur Umsetzung von End-To-End Geschäftsprozessen eine zentrale Rolle.

SOA Technologieplattformen bieten umfangreiche Funktionalitäten für die technische Bereitstellung von Services. Der effiziente Einsatz von BPM Technologiekomponenten ist allerdings wesentlich von der Bereitstellung semantisch integrierter und betriebswirtschaftlich eindeutig definierter Services abhängig. Mit ihrer Hilfe sollen End-To-End Geschäftsprozesse flexibel orchestriert werden. Die schnelle und einfache Orchestrierung von Services aus unterschiedlichen heterogenen Systemen funktioniert nur, wenn der abgebenden und der konsumierenden Applikation dieselbe semantische Struktur zugrunde liegt. Voraussetzung dafür ist, dass auch die involvierten Stakeholder aus Business und IT das gleiche Verständnis dieser semantischen Struktur haben.

Welche Rolle spielen nun Modellierungssprachen wie die Business Process Execution Language (WS-BPEL) oder die Business Process Modeling Notation (BPMN) im Rahmen von BPM Technologiekomponenten? Die Möglichkeit, modellbasiert Applikationen zu erstellen, unterstützt zum einen die von einer SOA propagierte schnelle und flexible Änderung von Geschäftsprozessen, zum anderen aber auch die Dokumentation und das Monitoring dieser Geschäftsprozesse. Mit BPEL lässt sich ein Prozess beschreiben und der dadurch erzeugte Workflow anschließend in einer BPEL-Engine automatisiert ausführen. BPEL hat jedoch zwei wesentliche Nachteile: die mangelnde Unterstützung bei der Ausführung von Prozessschritten durch den Menschen und die fehlende Möglichkeit, Geschäftsprozessmodelle End-To-End abzubilden. Die Nutzung von BPEL-Modellen zur Dokumentation von Geschäftsprozessen und damit als gemeinsame Sprache für Business und IT ist daher sehr eingeschränkt.
Diese beiden Schwachpunkte werden durch den BPMN Standard, eine Spezifikation der Object Management Group (OMG), teilweise ausgeglichen. Die BPMN Notation bietet eine einheitliche Sprache für eine klare, vollständige und effiziente Darstellung von Geschäftsprozessen, die es erlaubt, sowohl menschliche Interaktion als auch automatisierte System-Interaktionen zu modellieren. Durch die Nutzung einer entsprechenden BPM Engine besteht die Möglichkeit, automatisiert ausführbaren Code zu erstellen. Im Gegensatz zu BPEL bietet BPMN eine Notation, die von allen gleichermaßen verstanden wird, von Geschäftsprozess- wie auch von IT-Experten.

An dieser Stelle darf nicht vergessen werden, dass der Einsatz und der Erfolg von BPMN Technologien wesentlich von dem zur Verfügung gestellten betriebswirtschaftlichen Inhalt abhängt. Notwendig sind demnach vor allem betriebswirtschaftlich und semantisch korrekt beschriebene Services aber auch vordefinierte Prozessmodelle. SOA Plattformen müssen hierbei die einheitliche Nutzung von betriebswirtschaftlichem Inhalt und BPM-Funktionalitäten einheitlich und integriert unterstützen.

Insgesamt betrachtet bleibt zu sagen, dass SOA eine hervorragende technische Grundlage ist, um BPM im Unternehmen umzusetzen.

Was sich bei der Projektrealisierung jedoch immer wieder zeigt: Prozesse finden selten in einer homogenen Umgebung statt. Abläufe sind nicht voll automatisiert und meist auch nicht vollständig in einer Anwendung abgebildet. Darüber hinaus laufen die Prozesse in der Regel über mehrere Abteilungen, verbinden zahlreiche Anwender und müssen organisatorische sowie technologische Barrieren überwinden. Gerade diese komplexen Prozesse sind es, die es einem Unternehmen erschweren, dem Kunden gegenüber professionell und serviceorientiert aufzutreten.

Geschäftsprozesse rücken in den Vordergrund
Das Ziel muss sein, eine neue BPM-basierende Prozessinfrastruktur in die bestehende System- und Anwendungslandschaft zu integrieren. An dieser Stelle kommt der zentrale Vorteil der Verknüpfung von Geschäftsprozessmanagement und SOA zum Tragen. Fachliche Abläufe haben spezifische Anforderungen, die selten eine identische Abbildung in den vorhandenen Applikationen finden. Vielmehr benötigen diese Prozesse passgenaue Komponenten, die die Komplexität der technischen Infrastruktur verbergen. Die Lösung besteht darin, für jede Prozessaktivität einen Service zu definieren und diesen innerhalb einer SOA anzubieten. Aus Sicht eines Geschäftsprozesses ist es dabei unerheblich, ob hinter diesem Service nur ein einfacher Web Service oder eine andere Implementierung steckt. Wichtig ist nur, dass die Bereitstellung der Komponenten mit der Anpassung eines Prozessmodells Schritt hält.

Flexibilität, Agilität, Effizienz, Transparenz und Konsistenz in der IT-Infrastruktur sind demnach erfolgskritische Faktoren im Rahmen einer BPM-Implementierung. Eine SOA liefert hierfür adäquate Lösungen: das Architekturmodell definiert die Vorgehensweise zur Bereitstellung von standardisierten Services und stellt die Wiederverwendung sicher, was wiederum die Produktivität der SOA-Landschaft fördert. Die Durchsetzung und Kontrolle eines Regelwerks lässt sich mit Hilfe der SOA technologisch effizient und nachvollziehbar umsetzen. Damit unterstützt SOA die BPM-Anforderungen nach Prozess-Transparenz und einer gleichzeitig erhöhten Agilität der Abläufe.

Die Motivation für BPM und SOA ist demnach bei den beiden Zielgruppen Fachbereich und IT-Abteilung in vielen Fällen identisch. Auf die Frage, ob BPM oder SOA der richtige Weg für die flexible Anpassung von Geschäftsprozessen ist, gibt es daher nur eine Antwort: Beide ergänzen sich hervorragend und liefern gemeinsam die Basis, um zukünftigen Anforderungen gewachsen zu sein.

… “It is not the strongest species, nor the most intelligent that survive, but the ones that are most adaptive to change.” (Charles Darwin)