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.

Andererseits wird unter „SOA“ häufig mehr verstanden als eine Neuorientierung auf technologischer Ebene. Zu Recht wird SOA in diesem Fall als Management-Thema mit strategischer Relevanz begriffen, das neben der IT auch die Fachbereiche und die Prozessverantwortlichen mit einbezieht und zu einer höheren Wettbewerbsfähigkeit sowie teilweise gar zu neuen Geschäftsmodellen führen kann.

Dies ist nicht verwunderlich, da die Zusammenschaltung (Orchestrierung) von Services zu Geschäftsprozessen oder zumindest Teilprozessen führt. Ein Teilprozess kann im Sinne einer SOA dann flexibel mit anderen Services oder Teilprozessen wiederum zu Geschäftsprozessen orchestriert werden. Man erkennt hier die Symmetrie zwischen Service und Prozess sowie die betriebswirtschaftliche Relevanz einer SOA.

Weitere betriebswirtschaftlich relevante Faktoren einer SOA liegen in der gewünschten Fähigkeit Prozesse/Services an Dritte auslagern zu können (Business Process Outsourcing) und Prozesse/Services Dritter aktiv in die eigenen Abläufe einzubinden (SaaS, „Software as a Service“ respektive ASP, „Application Service Providing“). Auch die Einbindung neuer Technologien wie RFID oder Digitale Signatur erfordert eine Ankopplung an die Geschäftsprozesse, damit der mögliche Nutzen auch tatsächlich realisiert wird.

Wenn als Ziel einer SOA-Einführung also die Verbesserung der eigenen Wettbewerbsfähigkeit definiert wird, genügt es nicht, einzelne Services unter technischen Aspekten zu betrachten. Vielmehr muss die Perspektive erweitert und die gesamte Prozesskette in das Blickfeld genommen werden. Dafür bedarf es einer anderen Begrifflichkeit und einer über die reine SOA hinausgehenden Produktkategorie.

Prozesszyklen ganzheitlich denken

BPM, ein Kürzel, das bisher meist im Sinne von „Business Process Modeling“ verwendet wurde, kann in puncto Pressewirksamkeit als Buzzword noch nicht wirklich mit SOA konkurrieren, holt aber derzeit stark auf. Viel ist hier im Fluss. Die Umwertung und Umbenennung von „BPM“ zum „Business Process Management“ als ganzheitlicher Ansatz statt des beschränkteren „Business Process Modeling“ ist praktisch vollzogen. Auf der Softwareseite haben die meisten Anbieter von SOA-Suiten begonnen, prozessorientierter zu denken. Auf der Unternehmensseite wiederum kann man beobachten, dass Etats für SOA und BPM zunehmend zusammengelegt werden.

Im Gegensatz zur SOA, die vom einzelnen Service und seiner technischen Orchestrierung ausgeht, liegt beim BPM der Fokus auf dem gesamten Prozess – man könnte daher auch von Prozess-orientierter Architektur sprechen. Moderne BPM-Systeme verfolgen den Ansatz, einen ganzheitlichen Zyklus abzubilden: von der Modellierung und Simulation, insbesondere die Ausführung und Koordination der Prozesse, über die Einkopplung von Systemen und Mitarbeitern bis hin zur Auswertung der erzielten Prozesseffizienz.

Dieser Ansatz geht mit dem Bestreben einher, die IT-Systeme nicht nur immer durchgängiger und flexibler, sondern insbesondere für Prozessverantwortliche und Management transparenter werden zu lassen sowie den Grad der Prozessautomatisierung ständig zu erhöhen. Auch dem Fachnutzer soll stärker die Möglichkeit gegeben werden, seine Prozesse zu überprüfen und frühzeitig steuernd eingreifen zu können. Erforderlich ist ein Prozess-Cockpit, mit dem Soll-Ist-Abweichungen erkannt werden können. Mit einer Begriffsprägung aus der amerikanischen IT-Welt wird dieser innovative Ansatz auch „BPM 2.0“ genannt, was insofern Sinn macht, als es unter anderem auch Web-2.0-Techniken sind, die diese Systeme mit konstituieren.

BPM als Konvergenzthema

BPM 2.0 hat im Grunde mehrere Themen aufgesaugt, die bisher schon einzeln eine gewisse Karriere am Markt gemacht haben – SOA ist nur eines davon, wenngleich das Jüngste. Des Weiteren sind hier Workflow-Systeme und Integrations-Systeme (EAI), Auswertungssysteme (BI) aber auch Portale zu nennen.

Integrierte Portale bieten erstmals eine intuitive, einheitliche und flexible Oberfläche für Prozessanwendungen und sind ein wichtiger Schritt dahin, Fachnutzern ein großes Maß an Kompetenz und Kontrolle über die Prozesse wiederzugeben, das vorher bei der IT-Abteilung lag.

BPM 2.0 Systeme ermöglichen solche integrierten Portale mit Hilfe frei konfigurierbarer und kombinierbarer Portlets (Portal-Bausteinen, die mit dem Prozess korrespondieren), die jedem Mitarbeiter individualisiert Zugang zu den Geschäftsprozessen bieten. Durch den Einsatz solcher Portale wird die Transparenz des Gesamtsystems für alle an den Geschäftsprozessen Beteiligten deutlich erhöht. Als Einstieg in ein Unternehmens-Intranet kann ein Portal beispielsweise die Schnittstelle zwischen der Lagerverwaltung und externen Partnern bilden, die selbstständig Bestellvorgänge auslösen können, welche dann automatisch mit dem Warenbestand im zentralen ERP-System abgeglichen werden. So sind Portale für das BPM der zweiten Generation ein entscheidender Schritt hin zu weniger IT, dafür aber mehr Transparenz für den Nutzer.

Die Zukunft von SOA heißt BPM

Was das Verhältnis von SOA und BPM angeht, so wäre es theoretisch denkbar und praktisch möglich, ein Tool zum Geschäftsprozessmanagement mit einer anderen als einer serviceorientierten Architektur umzusetzen. Umgekehrt liegt der Fall anders, denn das SOA-Terrain ist begrenzt. Eine SOA bietet nicht die Möglichkeiten der ständigen Rückkopplung auf ein Prozessmodell, an dem die laufenden Prozesse gemessen und kontrolliert werden können. Darüber hinaus besteht praktisch nirgendwo eine reinrassige SOA-Welt aus Systemen, die sämtlich Webservice-fähig wären; denn in der Praxis geht es immer auch darum, eine Reihe von Legacy-Systemen mit proprietären Schnittstellen zu integrieren. Früher wurde dieses Thema unter dem Schlagwort „EAI“ geführt, mittlerweile wird es ganz selbstverständlich als Teil des Business Process Management begriffen.

Es bleibt spannend zu sehen, wohin der BPM-Markt sich entwickelt. Die marktgängigen, SOA-basierten BPM-Produkte bemühen sich mittlerweile intensiv darum, den „closed loop“ der Prozesskette abzubilden, können diesen aber bis auf wenige Ausnahmen nur mit Hilfe von Zukäufen und Kooperationen realisieren. Dies führt jedoch zu heterogenen, schwer konfigurierbaren BPM-Suiten, die einen nachhaltigen Kundennutzen nicht ermöglichen. Die allgemeine Entwicklung hin zur funktionalen Durchgängigkeit der BPM-Produkte ist momentan voll im Gange. Auf diesem Feld wird sich in den nächsten Jahren noch viel tun.

Dr. Torsten Schmale, Vorstandsvorsitzender der inubit AG