|
|
|
»manage
it«
als
|
SOA und BPM Ein perfektes Paar? Wo endet BPM, wo beginnt SOA? Ergibt die Kombination dieser beiden Konzepte wesentliche Vorteile für Unternehmen oder bestehen weiterhin Grabenkämpfe zwischen dem Lager der business-orientierten Verfechter von BPM und den im IT-Umfeld angesiedelten SOA-Anhängern?
usammen sind BPM (Business Process Management) und SOA (serviceorientierte Architektur) eine leistungsstarke Kombination für Unternehmen. BPM bietet einen hohen Abstraktionsgrad zur Definition von Geschäftsprozessen sowie wichtige Fähigkeiten für das Monitoring und Management dieser Prozesse. Services liefern die erforderlichen Anwendungsfunktionen, um diese Prozesse zu unterstützen. Eine SOA schließlich verbindet die Services miteinander und bildet so die Basis für ein agiles und flexibles Unternehmen. BPM ohne eine SOA ist hilfreich beim Aufbau von Applikationen, aber trägt nicht wesentlich dazu bei, die Unternehmensfunktionen zu erweitern, das heißt innovative Lösungen zu entwickeln. Auf der anderen Seite lassen sich mit einer SOA ohne BPM wieder verwendbare und konsistente Services entwickeln, aber es fehlt die Fähigkeit diese Services in Lösungen zu orchestrieren, die in agilen und wettbewerbsfähigen Unternehmen die Prozesse unterstützen. SOA und BPM können sich also ergänzen. Nach wie vor werden diese unterschiedlichen Ansätze aber auch als Waffen in der Auseinandersetzung zwischen Business und IT benutzt. Vertreter aus Management und Fachabteilung auf der BPM-Seite und Techniker an der SOA-Front machen das Thema zur Glaubensfrage. Historisch betrachtet war der Ausgangspunkt für BPM in den 80er Jahren die Forderung nach Flexibilität und Änderbarkeit der Geschäftsprozesse. Die Unternehmen mussten schneller auf neue Kunden- und Marktanforderungen reagieren, um wettbewerbsfähig zu bleiben. Da man einmal festgelegte Prozesse nicht in den Fachabteilungen ändern konnte, wurde die Lücke zwischen Businessanforderungen und IT immer größer. Der Journalist Christopher Koch formuliert diese Erwartungen der Fachabteilungen in seinem Blog: »Wir könnten viel effizienter sein, wenn wir Systeme hätten, die die Art wie wir arbeiten angemessen unterstützen und die geändert werden können, wenn Geschäftsregeln und Prozesse einer Anpassung bedürfen. Es sollte möglich sein, dass die Prozessdiagramme, die wir entwerfen, von unseren Systemen so unterstützt werden, dass wir bruchlos vom Prozessmodell zur Implementierung gelangen. Ist das nicht genau die Aufgabe, für die IT da ist?« Die 'Verteidigungsstrategie' der IT-Mannschaft bestand aus Standardisierungen und dem Aufbau einer IT-Architektur. Aber diese Ansätze waren nicht durchgehend erfolgreich, der Anspruch der Business-Seite nach selbstständiger Kontrolle und Änderung ihrer Prozesse blieb bestehen und wurde bis heute nicht vollständig erfüllt. BPM dient als Werkzeug und Mittel der strategischen Kriegsführung der Fachseite die Kontrolle über die Prozesse zu erlangen. Auf der anderen Seite wurde SOA zum Motto der IT-Experten. Denn: SOA konzentriert sich stark auf die IT und die Integration der Prozesse. BPM – zwischen Mythos und Realität. Die gefordert Konvergenz von Business und IT beziehungsweise BPM und SOA zielt geradewegs auf den Kern dieses Prozesskonflikts. Die Fachseite hat BPM und die IT hat SOA – beide sind in der gleichen Weise an die Prozesse gebunden. Jetzt soll BPM die Unternehmen in der neuen Welt der SOA unterstützen. Doch um BPM ranken sich noch einige Mythen. Mythos 1: Jede SOA fordert BPM Wahr ist, dass reine BPM-Anbieter Lösungen entwickelt haben, die jede Art von Service in ihren Managed Processes verarbeiten können. Dadurch kann man später Services durch Plug and Play einbinden, wenn in eine SOA-Umgebung migriert werden soll. Die Anwender profitieren also von den Vorteilen einer SOA, auch wenn sie im Augenblick noch keine SOA implementiert haben. Auf diese Weise können Prozesse über BPM Lösungen stufenweise in eine SOA-Umgebung integriert werden. Mythos 2: Jede BPM-Software ist unreif Da viele »BPM-Standards« (BPMN, BPEL, etc.) als nicht ausgereift gelten, geht man davon aus, dass die Angebote ebenfalls nicht vollständig entwickelt sind. Tatsächlich bieten reine BPM-Anbieter im Augenblick mehr Unterstützung für neu entstehende und De-facto-BPM-Standards als für die Standards der großen Infrastrukturanbieter wie IBM, Microsoft und Oracle. Viele Global-500-Unternehmen wenden sich deshalb mehr und mehr dem großen Funktionsumfang, der Systemoffenheit und Skalierbarkeit von BPM Plattformen zu, um ihre Technologie-Stacks zu erweitern. Diese ausgereiften Systeme bringen niedrigere Risiken mit sich. Mythos 3: BPM ist eine Eintagsfliege Viele Unternehmen sehen nur den aktuellen Hype und werden Opfer des Mythos, dass BPM eine Plattformentscheidung ist, statt den unmittelbaren Wert zu erkennen, den es für heutige Geschäftsabläufe bietet. Es stimmt zwar, dass größere Global-500-Unternehmen BPM bisher als Bestandteil ihrer gesamten Technologie-Stacks, ähnlich wie Datenbanken und andere Applikationen bewerten. Aber viele von ihnen wollen jetzt verschiedenste BPM-Technologien innerhalb ihrer Organisation einsetzen. Ausgereifte BPM-Lösungen generieren überzeugende Ergebnisse für Geschäftsprozesse in so kurzer Zeit, dass es sinnvoll ist zwei bis drei Prozesse zu identifizieren und sofort mit der Einführung zu beginnen. Die größere, langfristige Plattformentscheidung kann hierzu parallel stattfinden. Mythos 4: BPM ist eine große Investition an Zeit und Geld Dagegen spricht, dass ausgereifte BPM-Lösungen innerhalb von 30 bis 60 Tagen implementiert werden können und nach dieser Zeitspanne bereits konkreten Nutzen für die Unternehmen generieren. Kleinere Standardlösungen erfordern in der Regel weniger Serviceaufwand bei der Installation und Implementierung als die Lösungen großer Infrastrukturanbieter. Jedes implementierte Projekt mit einem ausgereiften BPM-Produkt erbringt normalerweise einen messbaren ROI. Mythos 5: Prozesse und die damit verbundenen Geschäftsregeln verändern sich ständig massiv Wahr ist, dass sich Prozesse gemäß Marktbedingungen, Wettbewerb und behördlichen Anforderungen ständig weiterentwickeln, die meisten Geschäftsprozesse verändern sich aber innerhalb von 2 bis 4 Jahren nur wenig. Zudem gibt es in vielen Unternehmen Vorschriften, die die Modifizierung der Geschäftsregeln durch die Endanwender ohne wesentliche Beteiligung der Geschäftsführung verbieten. So wird sichergestellt, dass exakte Prüfungen durchgeführt werden, bevor eine Änderung stattfindet. Mythos 6: Nur Anwendungsanbieter liefern richtige BPM-Lösungen Tatsache ist, dass Applikationsanbieter gutes Prozessmanagement für individuelle Aktivitäten innerhalb ihrer Anwendungs-Stacks liefern. Umfassende BPM-Lösungen sind jedoch darauf ausgelegt Cross-Enterprise- und Cross-Application-Prozesse zu unterstützen, die jede Anwendung, jedes System und jede Organisation einschließen, um End-zu-End-Prozesse zu verwalten. Mythos 7: Infrastrukturanbieter liefern die wahren BPM-Lösungen In Wahrheit haben viele Infrastrukturanbieter durch Mergers & Acquisitions Produkte zusammengeschustert, die Prozesslösungen eher verkomplizieren als vereinfachen. Wenn man sechs oder mehr Produkte in den Stack einbindet, um BPM-Funktionalitäten zu liefern, erhöht sich die Komplexität der entwickelten Lösungen; der ROI, der durch den Einsatz einer BPM-Lösungen erzielt werden kann, reduziert sich auf diese Weise dramatisch. Worin besteht die Beziehung zwischen BPM und SOA wirklich? Business Process Management hilft den Geschäftsanalysten dabei, strategische Ziele mit den IT-Systemen in Einklang zu bringen. Es werden präzise definierte Geschäftsprozesse entwickelt sowie die Performance überwacht und optimiert, um eine höher operationale Effizienz zu erlangen. Jeder Prozess wird dabei als Set von individuellen Aufgaben modelliert. Diese Tasks werden normalerweise als Services innerhalb des Unternehmens implementiert. Ein BPM-System liefert ein Toolset, das es den Geschäftsanalysten ermöglicht, Prozessmodelle zu entwickeln, indem sie Notationen wie BPMN (Business Process Modeling Notation) nutzen. Anschließend folgt die Prozessautomatisierung oder Ausführung des Modells durch die Services. Zusätzlich liefert das BPM-System Monitoring- und Management-Fähigkeiten um die implementierten Prozesse zu überwachen. Der Haken daran? Natürlich möchten Unternehmen ihre bestehenden Systeme einsetzen und sie in neue Geschäftsprozesse einbinden. Aber: meist sind die IT-Umgebungen sehr komplex. Sie haben sich über die Jahre entwickelt und nutzen verschiedene Plattformen, Technologien (wie JAVA, .NET, CICS, etc) und Kommunikationsstandards. Web Services haben das Potenzial, diese Plattform- und Kommunikationsprobleme zu lösen und neue Schnittstellen für die bestehenden Systeme zu liefern. Genau diese neuen Interfaces brauchen die BPM-Systeme, um Verarbeitungsfunktionen aufzurufen. Jedoch: Die Verwendung von Web Services oder das Wrapping von bestehenden Anwendungen als Services an sich, bildet noch keine serviceorientierte Architektur. Hierzu gehört viel mehr. Web Services liefern eo ipso Geschäftsfunktionalitäten in Form von Services. Dagegen geht eine SOA weiter als nur bis zur Ebene der Konvektivität und der Schnittstellen von Services. SOA ermöglicht den unabhängigen Aufbau von Services, die kombiniert werden können, um höherwertige Geschäftsprozesse im Kontext des Unternehmens zu realisieren. Mit SOA können Unternehmen also ihre Fähigkeiten kombinieren und zu Prozessen bündeln, die über einzelne Anwendungen und organisatorische Grenzen hinweg zusammenarbeiten. Da die unterschiedlichen Services von verschiedenen Fachbereichen entwickelt werden, muss die SOA die Struktur und den nötigen Kontext vorgeben, damit Services unabhängig aufgebaut werden können und trotzdem zusammen auf Unternehmenslevel arbeiten. Eine SOA regelt daher, wie Services technisch zusammenarbeiten, wie sie aufgebaut werden müssen, wie unterschiedliche Servicearten voneinander abhängen, wie sie miteinander kombiniert und orchestriert werden, wie sie auf semantischem Niveau interagieren und wie sie Geschäftsprozesse und letztendlich die IT- und Geschäftsstrategie unterstützen. BPM liefert eine Abstraktion, um Fachanwendungen aufzubauen. Oft jedoch werden mit BPM höherwertige, effizientere Anwendungen erstellt, die aber dennoch Silo-Applikationen bleiben, statt ein flexibles, agiles Unternehmen zu unterstützen. Genau an diesem Punkt kommt SOA ins Spiel. SOA liefert eine Applikationsplattform, die Geschäftsprozesse und operationale Ressourcen verbindet. Für das Niveau der Geschäftsprozesse liefert SOA Schnittstellen, die Prozessaufgaben direkt unterstützen. Diese Interfaces sind im Kontext des Unternehmens definiert, um Konsistenz und Wiederverwendbarkeit zu unterstützen. Auf dem Niveau der operationalen Ressourcen stellt SOA vorhandene Funktionen als Integrationsservices dar. Dazu werden die bestehenden Anwendungen jedoch nicht direkt als Services abgebildet. Es werden vielmehr neue Serviceschnittstellen auf Basis der Unternehmens-Semantik und funktionaler Anforderungen angeboten und dann in den bestehenden Systemen abgebildet. Diese beiden Ebenen aus Interfaces und Integrationsservices werden in einer SOA über Service Composition verbunden, die zusammen das Application Platform Layer bilden. Um die bisherige Kluft zwischen BPM- und SOA-Anhängern zu überwinden, haben Anbieter wie etwa BEA Systems BPM-Tools in ihre Integrationsplattformen aufgenommen und bieten eine eigene BPM-Suite an. In Kombination mit der Aqua-Logic-Produktlinie ist eine SOA-Plattform entstanden, die geschäftszentriert Personen und Anwendungen verbindet. Während die meisten Anbieter ihre SOA nach wie vor auf die IT beziehen, kann so BPM und eine zugehörige Portal-Lösung auf die Mitarbeiter angepasst werden. Das Ergebnis ist ein SOA-Konzept, das die Arbeitsweise verändert und neu definiert. IT auf der einen Seite und Management und Fachabteilungen auf der anderen Seite können jetzt in einer produktiven und effizienten Arbeitsumgebung nahtlos miteinander verzahnt werden. Und: es gelingt Änderungen der Geschäftsprozesse mit den notwendigen Änderungen an den IT Systemen zu verbinden. Wolfgang Weigend
___________________________________________________________
Viele Geschäftsprozesse erstrecken sich über verschiedene Abteilungen oder technische Systeme, die einer Automatisierung im Wege stehen. Bei der Ausführung führt das zu Fehlverbindungen, Zeitverlusten und hohen Abwicklungskosten.
___________________________________________________________
Beispiel für ein vollständiges Management des Prozess-Lebenszyklus. |
|
