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.
Prozesse sind chic. Egal welches betriebswirtschaftlich oder technisch ausgerichtete Medium man heute aufschlägt, alles dreht sich um Prozesse. Sei es eine durch SOX erzwungene Dokumentation der Finanzprozesse, der Wunsch nach einer ISO- konformen Einführung von prozessorientiertem TQM. Ganz besonders oft begegnet man dem Thema aber im Zusammenhang mit einer von der IT verlangten SOA-kompatible Beschreibung von Abläufen. Als Voraussetzung dafür wird schnell ein funktionierendes Business Process Management (BPM) genannt. Wenn man es nicht besser wüsste, und manchmal stelle ich mir diese Frage ernsthaft, dann könnte man sich in eine „Drei-Buchstaben-Akronym“-Welt versetzt fühlen. Lassen Sie uns einmal komplett auf diese verzichten und beleuchten, wie uns die Welt des Prozessmanagements der Zukunft aus Sicht der Hersteller und Berater verkauft wird, was davon tatsächlich Wirklichkeit werden kann und, noch viel wichtiger, Wirklichkeit werden sollte.
Alles ist neu, alles wird besser!
Das kennen wir. Die Welt der Informationstechnologie hat ein (nicht mehr so) neues Thema. Es heißt „serviceorientierte Architektur“ und verspricht uns endlich von allen Problemen zu befreien. Endlich wird es gelingen, die Betriebswirtschaft mit der Informationstechnologie zu versöhnen. Und da ein wesentlicher Bestandteil jeder serviceorientierten Architektur das genaue Verständnis der zugrunde liegenden Geschäftsprozesse ist, müssen diese zentral betrachtet werden.
Ich möchte kurz Daniel Liebhart vom Schweizer IT-Dienstleister Trivadis zitieren: “SOA stellt Standards und Techniken zur Verfügung, die eine direkte Umsetzung von grafisch modellierten Prozessen in ausführbaren Code erlauben. Wird nun der Prozess oder die Geschäftsregel geändert, so werden die Informationssysteme dank SOA automatisch auf den aktuellen Stand gebracht“. Ähnliche Aussagen verbreiten auch andere namhafte Hersteller und Berater.
Zugegeben etwas vereinfacht, aber als Ingenieur versuche ich das zum Leidwesen meiner Kollegen immer wieder, sollen etwa zukünftig Mitarbeiter ihre Arbeitsprozesse individuell grafisch modellieren, dann die betroffenen Systeme selbstständig auf Knopfdruck neu konfigurieren, neue Dienste kollaborativ im weltweiten Datennetz suchen und verbinden sowie die völlige Flexibilität in der Gestaltung von Abläufen eigenverantwortlich gestalten?
Geht es Ihnen wie mir? Ich höre die Botschaft, aber irgendwo tief in mir drin regt sich ein Zweifel. Die Aussage „das wird niemals gehen“ habe ich mir abgewöhnt, aber ein „das wird so schnell nicht gehen“ muss erlaubt sein.
Die Praxis zeigt, dass zwischen der Vision und ihrer Realisierung heute noch methodische, technische und organisatorische Fragestellungen liegen.
> Die Praxis zeigt, dass zwischen der Vision und ihrer
> Realisierung heute noch methodische, technische und
> organisatorische Fragestellungen liegen.
Dem kann ich nur zustimmen. Das Bild, das viele Anbieter von der schönen neuen BPM-SOA-Welt zeichnen, kann bestenfalls als naiv bezeichnet werden. In einem Paper (zum Donwload unter http://kurze-prozesse.de/?p=46) habe ich für einen einfachen Geschäftsprozess einmal die komplette Umsetzung eines fachlichen Modells in eine komplette BPMS-Anwendung beschrieben. Hier nur zwei Erkenntnisse aus dieser (recht mühsamen) Übung:
1. Fachliche und ausführbare Prozessmodelle unterscheiden sich deutlich. Das liegt nicht daran, dass in dem Beispiel das fachliche Modell als EPK und das ausführbare Modell mit BPMN erstellt wurde. Man hätte auch das fachliche Modell in BPMN erstellen können, und es wäre trotzdem noch ein großer Schritt zum ausführbaren Modell gewesen, weil ein ganz anderer Formalisierungsgrad erforderlich ist, weil bestimmte technisch begründete Anforderungen spezielle Strukturen im Prozessmodell erfordern, die aus fachlicher Sicht so nicht benötigt werden (und mit einem anderen BPMS vielleicht anders zu lösen wären). Auch wenn Business und IT beide BPMN sprechen, sind die Modelle der Business-Seite dennoch nicht ausführbar.
2. Der reine Kontrollfluss macht nur einen kleinen Teil einer BPMS/SOA-Anwendung aus. Der ganze BPMN/BPEL-Ansatz ist zweifelsohne nützlich, doch brauchen wir auch Datenstrukturen, Benutzungsoberflächen, Datentransformationen und Mappings zwischen Services usw. Wir brauchen einen ganzheitlichen Ansatz, bei dem alle Aspekte einer Anwendung aus fachlicher Sicht so spezifiziert werden, dass sie möglichst einfach und korrekt umgesetzt werden können. Hier würde zunächst schon ein einheitlicher methodischer Ansatz weiter helfen, der noch gar nicht automatisiert sein muss.
„Aus der Summe der Applikationen ergeben sich die Prozesse eines Unternehmens.“
Solange ich solche und ähnliche Aussagen immer wieder in renommierten Fachblättern lese, wird mir klar, wie groß der Graben zwischen Business und IT immer noch ist. In manchen Unternehmen hat er bereits die Größe des Grand Canyon erreicht.
Dies gilt leider auch immer wieder für viele Diskussionen zum Thema “SOA versus BPM”
Das Thema Prozessmangement prägt mehr als jedes andere Thema der letzten Jahre das Spannungsfeld zwischen Business und IT.
Allerdings hat auch kein anderes Thema stärker aufgezeigt, wie notwendig der zukünftige Dialog sein wird.
Das Berufsbild des Prozess Manager existiert noch nicht einmal, schon beginnt der unternehmensintere Kampf um die Position des Chief Process Officer (CPO).
Viele beanspruchen diese Rolle für sich. IT, Qualitätsmanagement, Organisation und Unternehmensentwicklung: alle argumentieren, dass Prozessmanagement doch schon immer Ihre Domaine war.
Doch wer wird das Rennen machen? Oder wird diese Situation nur einen Verlierer hervorbringen – das betroffene Unternehmen?
In einem Punkt sind sich viele in Wissenschaft und Wirtschaft einig. Die erfolgreiche Auseinandersetzung mit Prozessmanagement wird für viele Unternehmen eine zwingende Notwendigkeit sein, um sich im immer stärker werdenden globalen Wettbewerb auch zukünftig behaupten zu können.
Die erfolgreiche Implementierung von Prozessmanagement ist also viel zu wichtig, als mit einem Grabenkampf diverser Unternehmensbereiche zu beginnen und damit auch in der Regel erfolglos zu enden. Gefragt sind daher sauber formulierte Strategien und vor allem ein klares, eindeutiges Commitment des Top-Managements.
Prozessmanagement ist ein Management-Prozess und sollte auch so wahrgenommen werden.
Ich denke, hier muss noch einiges an Aufklärung betrieben werden, damit Aussagen wie zu Beginn des Textes zitiert, zukünftig nicht mehr in Fachzeitschriften zu finden sind und die Diskussionen zu SOA und BPM stärkeren Bezug zum eigentlichen Business bekommen.
Sven Schnägelberger
Es gibt bei der Frage, ob man einen Geschäftsprozess auf Knopfdruck automatisieren kann, ein prinzipielles Missverständnis. Es hat was mit horizontalen vs. vertikalen Transformationen zu tun. Bei einer horizontalen Transformation findet keine Verfeinerung statt, sondern es wird lediglich von Darstellung A in Darstellung B umgewandelt. Typisches Beispiel sind die BPM Systeme wie beispielsweise Intalio. Es wird ein automatisierbarer Geschäftsprozess in BPMN modelliert und in ein ausführbares Format serialisiert. Das ist automatisierbar und wird auch recht gut von den entsprechenden Produkten beherrscht.
Ganz anders hingegen sind vertikale Transformationen. Hier findet eine Verfeinerung statt. Das ist genau das, was Prof. Allweyer in seinem ARIS-Intalio Tutorial beschrieben hat. Es ist auch genau das, was wir bei der IDS Scheer AG (http://www.aris.de/soa/) mit der EPK nach BPEL Transformation passiert. Die EPK enthält keine technischen Informationen wie z.B. Exceptions und diese müssen dann folgerichtig nach der Transformation in BPEL noch hinzugefügt werden.
Fazit: Horizontale Transformationen sind relativ einfach, vertikale Transformation über Abstraktionsebenen hinweg sind es nicht. Das gilt auch für die Automatisierung von Geschäftsprozessen – egal ob mit oder ohne SOA.
Gruß,
Sebastian Stein
Ich stimme Herrn Stein 100%ig zu – leider wird die Illusion, man könne aus bestehenden (!) Prozessmodellen auf der typischen Abstraktionsstufe einer Unternehmensprozessmodellierung direkt Code generieren, noch von zu vielen aufrecht erhalten.
Ein High-Level-Prozessmodell in ein ausführbares Modell zu überführen ist ein kreativer Akt, der sich nicht automatisieren lässt.