Rahmenwerk für Portable Geschäftsprozesse

Transkript

1 Rahmenwerk für Portable Geschäftsprozesse Schlüsselworte: Uwe Ritter People at Work Systems AG München Business Process Management, Geschäftsprozesse, BPM, EAI, SOA Einleitung Das Management von Geschäftsprozessen ist eines der übergeordneten strategischen Themen in vielen Unternehmen. Das Bestreben der Firmen, sich zu einer prozessorientierten Organisation zu entwickeln, wird unter anderem dadurch deutlich, dass das Thema Prozessverantwortung zunehmend in deren Organisationsstruktur verankert wird, nicht zuletzt in Form eines Chief Process Officer (CPO). Zwar wird die Rolle eines Prozess- Verantwortlichen noch sehr unterschiedlich interpretiert und gelebt, doch ist der Trend eindeutig. Computergestützte, übergreifende Geschäftsprozesse bedingen, dass die dazu notwendigen Anwendungssysteme entlang der einzelnen Prozessschritte miteinander kommunizieren können. In der Vergangenheit wurden dazu die Anwendungssysteme zumeist auf einer 1:1 Basis miteinander vernetzt und die entsprechende Verbindungslogik bilateral zwischen den Kommunikationsknoten erstellt. Während dies bei wenigen Systemknoten noch relativ einfach zu bewältigen ist, so steigt die Anzahl der notwendigen Verbindungen will oder muss man dafür alle Systeme jeweils miteinander vernetzen mit einer quadratischen Funktion ( n*(n-1) / 2 ) zur Anzahl der Systemknoten. Dies führt zu schwer wartbaren und teuren Systemlandschaften. Um dieser Komplexität entgegenzuwirken, wurden von Unternehmen vermehrt EAI (Enterprise Application Integration) Systeme eingesetzt. Mit diesen gelang es zwar, die Anzahl der physikalischen Verbindungen zu reduzieren, jedoch folgte die Anzahl der logischen Verbindungen zwischen den Anwendungssystemen zumeist immer noch der oben beschriebenen Mimik. Abhilfe stellten BPM (Business Process Management) Systeme in Aussicht, also Plattformen, die neben der Bereitstellung einer Schnittstelleninfrastruktur auch die Orchestrierung und Ausführung von anwendungsübergreifenden Geschäftsprozessen unterstützen. Diese setzen zwar die Bereitschaft voraus, Teile der geschäftlichen Abläufe auf eine solche BPM Middleware-Umgebung zu übertragen, bieten allerdings weitreichende Möglichkeiten, um die Komplexität einer stark vernetzten Anwendungslandschaft deutlich zu reduzieren.

2 Doch gemäß dem Postulat A Real Programmer can write FORTRAN programs in any language 1 (Ein echter Programmierer kann FORTRAN Programme in jeder Programmiersprache erstellen), funktioniert dies nur, wenn man die Möglichkeiten einer solchen Plattform ausnutzt, denn oft sind so automatisierte Geschäftsprozess-Systeme ihrerseits monolithisch aufgebaut. Monolithisch bedeutet hier, geschäftliche Logik und technische Logik werden nicht getrennt. Die technischen Sub-Prozesse, die den individuellen Anforderungen der angeschlossenen Basissysteme gerecht werden, sind mit den eigentlichen Geschäftsprozessen untrennbar verwoben. Dadurch sind die Prozesse nach der Implementierung für Fachabteilungen kaum noch lesbar, der Wiedererkennungswert der auf dem Papier entworfenen Prozesse ist gering und die Agilität einer solchen Umgebung ist immer noch sehr niedrig, Änderungen im geschäftlichen Ablauf können von solchen Systemen nur mit beträchtlichem Ressourcen- und Zeitbedarf nachvollzogen werden und nicht selten haben sich bis zur Implementierung der Änderung die Anforderungen bereits wieder verschoben. Die Wartbarkeit sinkt hier ebenfalls und die Betriebskosten der gesamten Umgebung steigen, da jeder Releasewechsel oder Änderungen der Schnittstellenstruktur sich unmittelbar auf die Funktionsbereitschaft des Gesamtsystems auswirken. Die Anforderungen Zusammenfassend lassen sich folgende übergeordnete Anforderungen an eine automatisierte Geschäftsprozess-Umgebung formulieren: Lesbarkeit der Prozesse für Fachabteilungen nach deren Implementierung Agilität der Gesamtumgebung Flexibilität und Erweiterbarkeit Wartbarkeit der Umgebung Portabilität der Prozesse Reduktion der Notwendigkeit für manuelle Ausnahmebehandlung Releasefähigkeit (von Plattform und Anwendungssystemen) Investitionsschutz Wie es möglich ist, auf Basis einer BPM Middleware-Plattform eine Umgebung aufzubauen, die in der Lage ist, diese oben genannten Aspekte zu erfüllen, soll der vorliegende Erfahrungsbericht zeigen. 1 Aus Real Programmers Don t Use Pascal, Datamation Ausgabe 29, 7. Juli 1983

3 Die Architektur Das grundsätzliche Design-Ziel der gesamten Prozessarchitektur für die Datenschnittstellen ist deren Unabhängigkeit von der Prozessebene. Durch dieses Design-Merkmal wird erreicht, dass Änderungen, Ergänzungen und Anpassungen der Geschäftsprozesse unabhängig von den Schnittstellen und den dahinter liegenden Hostsystemen durchgeführt werden können. Gleichfalls erlaubt ein solches Design Änderungen, Releasewechsel etc. auf der Seite der Backendsysteme ohne die Prozessebene zu tangieren. Weiterhin wird es hierdurch möglich, die technischen Sub-Prozesse, die den Spezifika der Hostsysteme entsprechen müssen komplett aus den eigentlichen Geschäftsprozessen herauszuhalten, so dass sich die Prozessebene auf Geschäftsinhalte konzentriert und dadurch auch von Fachseite verstanden und bearbeitet werden kann. Die gesamte Prozessarchitektur stellt sich wie unten abgebildet dar. Als Trägermedium für deren Implementierung dient der BPM Server, der sämtliche Funktionen zur Verfügung stellt, die für die Implementierung einer solchen Lösung benötigt werden. Diese Architektur ermöglicht einen sehr hohen Grad Flexibilität hinsichtlich der Geschäftsprozesse und der technischen Infrastruktur. Dieses Prozessrahmenwerk ist konsequent strukturiert und nach Schichten aufgeteilt. Die wesentlichen Vorteile dieses Vorgehens lassen sich folgendermaßen zusammenfassen: Eine transparente und nicht-technische Sicht auf die Geschäftsprozesse Flexibilität, um Geschäftsprozesse zu ändern Flexibilität, um die Backendsysteme zu ändern oder zu tauschen Flexibilität, um sich schnell wechselnden IT-Szenarien anpassen zu können Erweiterbarkeit für künftige Szenarien Investitionssicherheit Dies wird erreicht durch Eine mehrschichtige Architektur Eine konsequente Trennung von Technik und Geschäftslogik Ein lose gekoppeltes Datenmodell Einen leistungsfähigen Satz von Systemmodulen Einheitliche Ausnahmebehandlung Eine standardisierte Datenschicht (wenn Standards existieren)

4 Abb. 1: Architektur Die Schnittstellen Erreicht wird die Entkopplung von Schnittstellen und Prozessen durch so genannte Systemmodule. Systemmodule sind mehr als nur technische Schnittstellenadapter, z.b. zur Host-Seite, denn sie beinhalten auch die technischen Sub-Prozesse und Datentransformationen, die für die Kommunikation mit einem Hostsystem spezifisch sind. Abb. 2: Bespiel Systemmodule

5 Nach oben hin, also in Richtung der Prozessebenen kommunizieren die Systemmodule in Form von festgelegten Rollen. Dies stellt einen Teil der Meta-Ebene dar, die die Unabhängigkeit zwischen technischen Systemen und Prozessen gewährleistet. Die Datenschicht Die Kommunikation zwischen den Systemmodulen und der Prozessebene erfolgt über eine Datenschicht, ein so genanntes gemeinsames Datenmodell. Dieses gemeinsame Datenmodell entspricht typischerweise den jeweils verfügbaren Standards. Beispielhaft seien NGOSS / etom im Telekommunikationsumfeld oder der GDV Standard im Versicherungsumfeld genannt. Dynamische Prozessausführung Die meisten aller Geschäftsprozesse bestehen nicht aus nur einem Anfangs- und einem Endzustand, sondern aus verschiedensten möglichen Ausgangs- und Endszenarien und den damit verbundenen Verarbeitungspfaden, sogenannten Use Cases. Da es sowohl ressourcenintensiv als auch unübersichtlich ist, jeden möglichen Use Case manuell als Prozesspfad zu implementieren, wird auf eine regelbasierte, dynamische Ausführung der Prozessschritte gesetzt. Im ersten Schritt wird der Status Quo durch gezieltes Sammeln von Informationen festgestellt. Danach werden Ist- und Soll-Situation verglichen. Ein Regelwerk erzeugt schließlich eine individuelle Sequenz von (vordefinierten) Operationen, die dazu geeignet ist, die Ist-Situation in die Soll-Situation zu überführen. Abb. 3: Dynamische Prozessausführung am Beispiel von DSL Provisionierung Transaktionen und Ausnahmebehandlung Eine weitere Herausforderung bei lose gekoppelten Szenarien stellt das Transaktionskonzept und die Behandlung von Ausnahmefällen dar. Im vorliegenden Lösungsansatz wurden diese Hürden sehr effektiv besser: genommen oder Problemstellung gelöst. Falls bei der Ausführung eines Prozessablaufes ein Ausnahmefall eintritt, so kann dieser entweder automatisch anhand von Regeln aufgelöst werden oder es wird eine Meldung an einen Bearbeiter / eine Bearbeiterin weitergegeben. Diese Person kann dann entscheiden, ob der Prozessablauf fortgesetzt, mit neuen Parametern neu gestartet oder abgebrochen werden soll.

6 Für den Fall, dass ein Prozessablauf mitten in der Ausführung abgebrochen werden muss, kennt jeder einzelne Prozessschritt die Operation, mit der er zurückgenommen werden kann, das bedeutet der Ablauf wird rückwärts ausgeführt. Hierdurch wird die Konsistenz der Daten in sämtlichen angeschlossenen Systemen gewährleistet. Abb. 4: Ausnahmebehandlung Fazit Mit Hilfe des oben beschriebenen (branchenunabhängigen) Vorgehens gelingt es, Prozessumgebungen zu erreichten, die nicht nur flexibel, wartbar und portabel sind, sondern die es auch den Fachabteilungen ermöglichen, den Lebenszyklus der Prozesse aktiv zu begleiten. Weiterhin fügt sich eine solche Umgebung nahtlos in SOA- oder Cloud Computing-Strategien ein und ist für Oracle AIA gerüstet. Unterstützt werden BPM Plattformen wie die Oracle Fusion Middleware und andere. Kontaktadresse: Uwe Ritter People at Work Systems AG D München Telefon: +49(0) Fax: +49(0) Internet: