1. Natürlich sind in jedem Unternehmen Geschäftsprozesse von besonders hoher Bedeutung, ob sie nun formal dokumentiert sind oder nicht. Aber oft sind die Geschäftsprozesse nicht so konstant, wie man es sich wünschen würde – und vor allem: oft sind sie nicht so einheitlich, dass eine vollständige Beschreibung überhaupt möglich ist (es sei denn, man möchte sich zu 90% der Zeit mit der Formalisierung von Ausnahmen beschäftigen).
2. Wenn sie beschrieben wurden, sind die Modelle in aller Regel auf einem Niveau, das eine Diskussion erlaubt – sie unterstützen die Kommunikation zwischen beteiligten “Stakeholdern” und erfüllen dazu (hoffentlich) einen guten Zweck. Sie sind aber weit, weit davon entfernt, so formalisiert zu sein, dass man sie ausführen könnte.
3. Wollte man das ändern – d.h. die Modelle auf Ausführungsniveau beschreiben -, verändern die Modelle ihren Charakter. Sie werden zu etwas anderem – etwas, das man gemeinhin Programm nennt. Und solche Dinge – Programme – werden in der Regel von Personen erzeugt, die man üblicherweise Programmierer nennt. Mit gutem Grund – die formale Beschreibung von Abläufen ist eine Disziplin mit eigenen Regeln, Erfahrungen, Best Practices … und so wenig wie so von einem Programmierer (oder vornehmer: Entwickler) erwarten würden, dass er auf einmal Vertriebsaufgaben übernimmt, sollten Sie z.B. vom Vertriebsspezialisten Programmierkenntnisse erwarten.
4. Der letzte Haken: Damit die ganze Idee mit den ausführbaren Geschäftsprozessen funktioniert, müssen Sie ein Service-Portfolio zur Verfügung haben, dass Dienste auf der richtigen (d.h. zu den Prozessen passenden) Granularitätsebene zur Verfügung stellt. Und diese brauchen Sie eigentlich, noch bevor Sie mit der Geschäftsprozessmodellierung anfangen … sofern Sie nicht in der ungewöhnlichen Lage sind, Ihr Unternehmen für ein paar Jahre zu stoppen, um diese Herkulesaufgabe anzugehen, werden Sie von der Erreichung Ihrer Ziele eine lange Zeit träumen müssen.

Zynisch? Defätistisch? Keineswegs, ich erkenne durchaus einen hohen Wert der Geschäftsprozessmodellierung auf der einen und von Orchestrierungs-Engines auf der anderen Seite. Aber das eine mit dem anderen zu verbinden, erfordert eine Transformation, eine Abbildung – und das ist ein kreativer Schritt, der von Menschen durchgeführt werden muss und für den der Aufwand nicht unterschätzt werden sollte.

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)