Interview: Das System muss mit den Anforderungen wachsen

Zusammenfassung

Karsten Köster, Ralf Müller und Waldemar Schäfer verfügen über langjährige Erfahung mit BPM bei der Xchanging Transaction Bank. In diesem Interview diskutieren sie mit Ralph Nelius ihre Erfahrungen bei der Auswahl und dem Einsatz einer BPM-Plattform.

Dabei sprechen sie über folgende Aspekte:

• Geschäftliche Ziele
• Auswahlprozess
• Kernfragen zu Hersteller und Produkt
• Modulare Komponenten einer BPM-Plattform
• Auswahltipps entlang der IBPM-Säulen
• Abschließende Fragen

Geschäftliche Ziele

R. Nelius: Die Xchanging Transaction Bank betreibt seit vielen Jahren Geschäftprozessmanagement im Sinne von Business-BPM. Vor drei Jahren haben Sie auch Ihr IT-BPM weiter ausgebaut und ein BPM-System (BPMS) ausgewählt und eingeführt. Können Sie uns kurz den geschäftlichen Hintergrund für diese Maßnahme schildern?

K. Köster: Xchanging liefert vielfältige Services in der Abwicklung von Backoffice-Tätigkeiten. Das können administrative Tätigkeiten im Versicherungs- oder Finanzdienstleistungssektor – wie beispielsweise die Wertpapierabwicklung – sein, oder aber branchenübergreifende Dienstleistungsprozesse wie Beschaffung, Personaldienstleistungen und IT. Das Service-Angebot reicht vom Business Processing über Technologie-Services bis hin zu entsprechenden Integrationsprojekten und Beratungsdienstleistungen. Um hochwertige und zugleich effiziente Services in diesen Bereichen zu liefern, setzen wir auf bewährte Methoden wie Lean Six Sigma, Kaizen oder sogar Offshoring.

Im Transaktionsgeschäft gehört das Prozessmanagement zum alltäglichen Handwerkszeug. So sind in unserem BPM-Team beispielsweise alle Mitarbeiter zertifizierte Six Sigma Black Belts. Unsere Geschäftsprozesse sind allesamt modelliert und die jeweiligen Prozessressourcen definiert. Eine ISO-Zertifizierung gehört ebenfalls dazu. Da ist es klar, dass wir wichtige Prozess- und IT-Trends wie den Aufbau von BPM und einer serviceorientierten Architektur (SOA) prüfen und umsetzen. Durch diese Tools können wir signifikante Potentiale in den Backoffice-Prozessen heben und das Unternehmen insgesamt agiler gestalten. Es ist elementar, auf Veränderungen im Markt oder bei sich ändernden Kundenbedürfnissen schnell reagieren zu können. Somit können Wettbewerbsvorteile entstehen.

Der Entschluss, ein BPM-System einzuführen, war ein Entschluss der gesamten Xchanging Gruppe. In verschiedenen Bereichen verlangten die Marktentwicklungen nach einer noch besseren technischen Unterstützung. Die primäre Motivation der Xchanging Transaction Bank war damals in diesem Zusammenhang die Optimierung der Prozess-Steuerung für ausgelagerte Prozesse an unseren Standort in Indien.

R. Nelius: Ihre primäre geschäftliche Motivation für die BPMS-Toolauswahl war also eine bessere Prozess-Steuerung?

R. Müller: Das war zumindest am Anfang der BPM-Initiative der Fokus. Mit dem Projektverlauf und den Erfahrungen ändern und konkretisieren sich die Ziele und Anforderungen. Wenn Sie ein oder zwei Projekte mit so einer Plattform gemacht haben, erhalten Sie ein konkreteres Bild vom Tool und von den Möglichkeiten.

K. Köster: Ich war zu der Zeit beispielsweise längere Zeit bei unserem Standort in Indien und konnte feststellen, dass die Steuerung von Offshore-Prozessen gewisses Verbesserungspotential hat. Von daher war dies eines unserer zentral angestrebten Ziele für das BPM-System.

In der Folge kamen Themen wie eine weitergehende Prozess-Standardisierung als bisher, sowie eine intensivere Automatisierung von Routineaufgaben dazu. Daraus ergaben sich sehr schnell neue fachliche Anforderungen an das BPMS, die wir dann in den letzten Jahren implementiert haben. Zusammengefasst haben sich die  geschäftlichen Ziele, die wir mit BPM und einer BPM-Plattform verfolgen, daher über die Prozessteuerung hinaus erweitert auf die Themen Qualitätssteigerung und Kostenreduktion.

Auswahlprozess

R. Nelius: Wie lief der Auswahlprozess für das BPMS damals bei Xchanging ab?

K. Köster: Über die gesamte Xchanging Gruppe hinweg haben in jeder Unternehmenseinheit kleine Expertengruppen definiert, wofür das BPMS lokal jeweils eingesetzt werden sollte. Im Wesentlichen wurden hier Prozesskandidaten untersucht und priorisiert. Wir sind Prozess für Prozess durchgegangen, es gab sogenannte Business Value Assessments, die dann zu einem Business Case verdichtet wurden. Es wurden global mögliche Anbieter identifiziert, eine Longlist aufgestellt und weiter zu einer Shortlist verdichtet. Die Shortlist-Anbieter haben wir uns dann ins Haus geholt und ihre Tools näher angeschaut. Daneben gab es natürlich auch Referenzbesuche bei Kunden. Die Auswahl erfolgte dann auf Basis des Gesamteindrucks und mit Hilfe einer Scoring-Tabelle, mit der die Anforderungen bewertet und gewichtet wurden. Dieser Auswahlprozess hat knapp vier Monate gedauert.

R. Nelius: Wie konnten Sie das so schnell durchziehen?

K. Köster: Na ja, wir sind in unserem Hause sehr stark an ein prozessorientiertes Denken gewöhnt. Des Weiteren ist das „Beschaffungswesen“ einer unserer Kernkompetenzen, die wir auch für andere Unternehmen durchführen. Und wenn sie ein dediziertes Team für die IT-Beschaffung im Einkauf und genügend Praxis in der Software-Auswahl haben, ist es auch weniger ausschlaggebend, was für eine Art Tool sie gerade aussuchen.

Kernfragen zu Hersteller und Produkt

R. Nelius: Vor einer solchen Anbieterauswahl muss man ja einige strategische Fragen beantworten, etwa in der Art: Präferiere ich ein kleines Haus, auf das ich selber Einfluss nehmen kann? Oder ein großes Haus, das mit Sicherheit in den nächsten Jahren ein Player auf dem Markt bleibt? Gibt es Experten, auf die ich zugreifen kann? Was war Ihre Strategie?

K. Köster: Wir suchten schon nach einer Enterprise Lösung von einem arrivierten Hersteller, der auch lieferfähig ist. Ein anderer Aspekt ist, dass die Kulturen beispielsweise im angelsächsischen und im deutschen Markt unterschiedlich sind. Wir in Deutschland wollen alles möglichst verstehen und selber machen können. Im angelsächsischen Raum geht man eher davon aus, dass die Kernkompetenzen woanders liegen und alles inkl. Entwicklung von außen eingekauft wird. Entsprechend gibt es unterschiedliche Anforderungen und Erwartungen.

W. Schäfer: Daher sind der lokale Support und eine offene Community, auf die man bei Problemen zurückgreifen kann, eminent wichtig. Die Community sollte von Entwicklern und Anwendern gebildet werden und nicht nur eine Hersteller-interne Veranstaltung sein. Eine Plattform braucht ein offenes Forum.

R. Nelius: Die lokale Präsenz des Anbieters, die Verfügbarkeit von Skills und Know-how und eine offene Produktcommunity spielen also eine wichtige Rolle. Worauf kommt es nach Ihrer Erfahrung noch wesentlich an?

Modulare Komponenten einer BPM-Plattform

R. Nelius: Wer „Enterprise BPM“ gelesen hat, sieht auch gleich einige Parallelen zwischen den Komponenten, die wir als notwendig erachten, und den 10 Säulen der IBPM-Projektmethodik. Warum ist Ihnen diese Modularität so wichtig?

R. Müller: Bei einer modularen Aufstellung können Sie Ihre Plattform entsprechend Ihrer Bedürfnisse schrittweise mitwachsen lassen bzw. modifizieren. Schaut man beispielsweise auf die Komponente „Business Rules Engines“, so reichen diese von einfachen Entscheidungstabellen bis hin zu neuronalen Netzen und somit künstlicher Intelligenz. Was man genau benötigt, ist am Anfang des Projekts oftmals schwierig zu detaillieren. Mit einer modularen Plattform können Sie einzelne Komponenten austauschen und das bereits Vorhandene integrieren.

K. Köster: Sie gehen auch geringere Risiken ein, weil sie nicht in Abhängigkeit von einem Anbieter geraten. Was, wenn der pleite geht, das Produkt nicht mehr supported? Oder wenn sie selber fusionieren und der neue Partner hat schon etwas im Haus? Mit modularen Komponenten können Sie unterschiedliche Strategien fahren. Gerade wenn Sie andere BPMS-Komponenten bzw. Nicht-BPMS-Komponenten integrieren wollen - und das ist vermutlich in vielen Unternehmen eher die Regel als die Ausnahme - muss das BPMS modular aufgebaut sein. Und es muss hochgradig interoperabel sein. Wenn Sie beispielsweise Prozesstransparenz im Fokus haben, benötigen Sie ein gutes Dashboard für Ihre Prozesse. Aber ein Manager benötigt natürlich auch Informationen aus HR, Finance und Kundenbereichen, um sein Geschäft zu steuern. Das Dashboard muss daher auch Nicht-BPMS-Anwendungen integrieren können.

W. Schäfer: Das gilt dann z.B. auch für Business Rules, die auch von Nicht-BPM-Anwendungen aufgerufen werden können müssen.

R. Nelius: Dem stehen aber auch die Kosten für die Integration gegenüber.

K. Köster: Sicher, aber Sie werden niemals die „All-In-One -BPM-Lösung“ bekommen. Das fängt schon damit an, dass Sie mit einem typischen BPMS alleine einzelne Prozesse zunächst einmal relativ rasch und problemlos gekapselt als IT-Lösung implementieren können. Wenn aber Ihre Stakeholder wie vorhin angedeutet kurze Zeit später auch eine Verbindung mit der HR- und Finance-Welt wünschen und Sie das nicht so einfach realisieren können oder wenn Sie die eine oder andere Best Practice nicht implementieren können, weil Ihr BPMS die nötigen technischen Features nicht bietet, werden Sie sich schnell wegen der nicht realisierbaren Nutzenpotenziale ärgern.

W. Schäfer: Und schließlich dürfen Sie den Lifecycle der einzelnen Komponenten nicht vergessen. Wenn Sie an einen Zeitraum von 20 Jahren denken – wie kann man ein solches großes System wieder ersetzen? Das ist bei Monolithen immer relativ schwer.

Auswahltipps entlang der IBPM-Säulen

R. Nelius: Lassen sie uns doch einmal entlang der IBPM-Säulen bzw. BPM-Komponenten durchgehen, welche Tipps Sie für die Produktauswahl parat haben. Beginnen wir bei der Prozessmodellierung und –dokumentation. Das sollte aus Ihrer Sicht eine eigenständige Komponente der BPM-Plattform sein. Was sollte diese unbedingt können?

R. Müller: Wir sehen die Modellierung in einer standardisierten Notation wie der BPMN (Business Process Model Notation) als wichtig an. Durch die aktuelle Version 2.0 der BPMN ist nun auch das Austauschformat der Modelle standardisiert. Dadurch wird die Beschreibung der Prozesse unabhängig vom Tool. So kann der Prozess z.B. in einem spezialisierten Modeller des BPMS entwickelt, aber auch in das Enterprise Architecture Modell des zentralen Architektur-Teams übernommen werden.

K. Köster: Viele Produkte versprechen die Ausführbarkeit des fachlichen Prozesses. Wir haben allerdings gelernt, dass der Fachbereich eine andere Prozessdarstellung als ein Techniker benötigt. Deshalb haben wir es auch akzeptiert, dass ein Prozess aus verschiedenen Sichten modelliert sein kann.

R. Nelius: In der IBPM-Methodik arbeiten wir deshalb auch mit verschiedene Modellierungsebenen.

W. Schäfer: Ja, genau das tun wir auch. Prozessmodellierung ist allerdings grundsätzlich noch ein großes Thema. Jeder Prozessexperte modelliert unterschiedlich. Deshalb versuchen wir Patterns für die Modellierung zu etablieren. Über verschiedene Modellierungsebenen und einige Guidelines lässt sich die Modellierung ganz gut standardisieren.

R. Müller: Interessant ist aber auch, dass der Prozess und somit die Modellierung meist im Mittelpunkt eines BPMS steht. Der Prozess an sich deckt aber nur eine von vielen Sichten auf die technische BPM-Unterstützung ab. So ist z.B. die Frage, was von wem bearbeitet wird, durch Pools und Lanes nicht immer gut zu modellieren. Oder das Datenmodell und die Bearbeitungsmasken werden im Prozess überhaupt nicht berücksichtigt.

R. Nelius: Das bringt uns zur nächsten Säule Prozessorganisation und –rollen. Organisation ist für Sie keine eigene Komponente – warum? Was kommt hier an Auswahlkriterien hinzu?

R. Müller: Die Organisation sehen wir nicht als Komponente eines BPMS an, sondern als notwendige Struktur in z.B. einem Directory Service, auf den das BPMS zugreifen kann.

W. Schäfer: Meistens ist die Organisation des Unternehmens bereits in einem System wie z.B. Active Directory abgebildet. Daher ist für ein BPMS wichtig, über eine ausgereifte LDAP Schnittstelle auf dieses Directory zugreifen zu können. Ich fände es aus Architektursicht kritisch, die Unternehmensorganisation in ein zweckgebundenes System wie ein BPMS zu verlagern. Schließlich werden dann andere Systeme sicher den Bedarf haben, sich an das BPMS anzudocken um Organisationsinformationen zu beschaffen. Bei einem Systemwechsel würde dies die Komplexität mittel- bis langfristig unnötig erhöhen, was wiederum negative Auswirkungen auf Ihre Projektrisiken, Projektlaufzeiten und Kosten haben wird. Für das BPM-Team hat diese Entkopplung außerdem den Vorteil, dass es einen bereits bestehenden Directory Service nutzen kann. Wodurch viele Probleme bezüglich Organisation und Rollen schon gelöst sind.

R. Nelius: Human Task Management?

K. Köster: Das ist ein ganz entscheidender Bereich. Wir hatten es schon bei der Prozessmodellierung angesprochen: Sie werden nach kurzer Zeit die Erfahrung machen, dass Ihre Prozessmodelle nur einen Teil dessen abdecken, was an Arbeitsorganisation tatsächlich zu beschreiben und zu entscheiden ist, um Ihre Prozesse in Ihrer Organisation mit Ihren Mitarbeitern in realer IT ablaufen zu lassen.

R.Müller: In ihrem fachlichen Prozessmodell mag beispielsweise nur die Lane „Sachbearbeiter“ auftauchen, während im realen Prozess tatsächlich mehrere Sachbearbeiter mit unterschiedlichen Skills zusammen in einen Arbeitskorb reinschauen müssen. Wenn das BPMS dann mit einer Liste wie beim E-Mail-Eingang arbeitet, funktioniert das nur gut, wenn es einen einzelnen Sachbearbeiter gibt. Aber bei 20 Sachbearbeitern würden 20 Leute versuchen, den gleichen Top-Task aus der Liste zu bearbeiten. 19 würde dann u. U. nur die Meldung bekommen, dass dieser Task schon bearbeitet wird. Ein gutes Taskmanagement kann freien Mitarbeitern den von der Priorität und Skills am besten passenden Task zuweisen. Dies kann z.B. durch einen Pull-Mechanismus geschehen.

W. Schäfer: Ein interessantes Szenario ist, wenn ein Mitarbeiter ungeplant ausfällt. Das System sollte eine Möglichkeit bieten, die Arbeit von seiner Worklist wegzunehmen und an die Kollegen zu verteilen. Generell haben die Anwender oft die Anforderung, ihre Verfügbarkeit getrennt nach Prozessen im System zu setzen.

K. Köster: Das sind alles Aspekte, die man bei der Toolauswahl gezielt abfragen kann. Ich kann hier nur raten, sich das Human Task Management mit dem Routing der Arbeitsaufträge an einem konkreten Beispiel zeigen zu lassen.

R. Nelius: Business Rules?

R. Müller: Die Business Rules geben dem Fachbereich Flexibilität. Nach unserem Verständnis sollte der Fachbereich die Möglichkeit haben, innerhalb von Minuten auf im Dashboard erkannte Probleme über eine Anpassung der Business Rules oder Prozesskonfiguration zu reagieren. Wir sind derzeit in der Situation, dass für die Prozesse, die wir auf dem BPMS fahren, Business Rules in Form von Entscheidungstabellen ausreichen. Das kann sich in Zukunft durchaus ändern. Mit den Entscheidungstabellen kann der Fachbereich gut umgehen. In der Regel ist es allerdings bereits heute so, dass der Fachbereich die Tabellen nicht alleine pflegt, sondern dass Anpassungen gemeinsam von Fachbereich und IT vorgenommen werden.

W. Schäfer: Im Prinzip kann jede Raute im Prozessdiagramm eine Entscheidung auf der Basis einer Business Rule bedeuten. Ein gutes BPMS sollte diese Verknüpfung gut visualisieren und die JSR-94 als Standard API zum Ansprechen von Business Rules Engines unterstützen – zumindest wenn wir uns in der Java-Welt bewegen. Aus SOA-Sicht ist eine Business Rules Engine ein Enterprise Service, der von anderen Systemen benutzt wird. Die Kopplung zwischen BRE und BPMS sollte somit zwar performant aber nicht zu eng sein.

R. Müller: Leider zeichnen sich bezüglich der Business Rules keine Standards ab, die eine Business Rules Engine austauschbar machen würden. Es gibt zwar die JSR-94 Spezifikation für den Zugriff auf eine Business Rules Engine, die Definition der eigentlichen Geschäftsregeln erfolgt jedoch in jeder Engine unterschiedlich, so dass derzeit ein Vendor Lock-In noch unausweichlich ist.

R. Nelius: Monitoring und Reporting?

R. Müller: Hier würden wir uns von allen BPMS, die wir uns angesehen haben, mehr Orientierung an Lean Six Sigma wünschen. Am Ende des Tages wollen sie optimierte, nachhaltige Prozesse. Um dorthin zu kommen, gibt es in Six Sigma beispielsweise sogenannte Control Charts als Steuerungsinstrument. Diese sind bisher in keinem uns bekannten BPM-Produkt in ausreichender Reife vorhanden. Wichtig ist auch die Fähigkeit, beim Abweichen von bestimmten Zielkorridoren proaktiv Alarme auslösen zu können.

K. Köster: Die bisherigen Six-Sigma Tools sind eher auf Management-Ebene angesiedelt, während die BPMS mit ihren Analyse- und Reportingfähigkeiten viel zu sehr Low- Level sind und „Lean“-BPM nicht wirklich vernünftig unterstützen. Hier kann ich auch wieder nur raten, sich nicht auf High-Level-Powerpoint-Präsentationen zu verlassen, sondern sich die Tools anhand von praktischen Beispielen anzusehen, was genau geleistet wird und wo die Grenzen liegen.

W.Schäfer: Wir haben die Erfahrung gemacht, dass es immer einen Report geben wird, an den man während der Implementierung nicht gedacht hatte. Daher ist die flexible Erstellung von Reports seitens der Fachseite ein wichtiges Auswahlkriterium für die Reporting-Engine. Eine „Excel-Export“ Funktionalität ist ein guter Anfang.

R. Nelius: Kommen wir zur SOA-Komponentisierung. Bei BPM-Lösungen geht es ja immer um das Design verteilter Lösungen. Wir sind in diesem Gespräch auch schon mehrfach mit SOA-Services in Berührung gekommen. Haben Sie schon Erfahrungen mit den SOA-Maps aus dem Buch gemacht? Wäre ein Modellierungstool mit SOA-Maps built-In hilfreich?

R. Müller: Wir benutzen in der Tat SOA-Maps. Zu diesem Zweck haben wir unser UML-Tool entsprechend erweitert. Die SOA-Maps helfen uns, einen Überblick über die im jeweiligen Prozess verwendeten Services zu gewinnen. Auch umgekehrt können wir in unserem Tool so leicht abfragen, von welchen Prozessen bestimmte Services verwendet werden.

R. Nelius: Frontends und UI-Design?

W. Schäfer: Fachlich gesehen unterscheidet sich ein prozessorientiertes UI von konventionellen Applikationsoberflächen. Zum Beispiel bietet ein konventionelles Ticketing System alle Informationen zum Ticket auf einen Blick. Je nach Status können unterschiedliche Felder befüllt werden. Baut man das Ticketing System mit einer BPMS, so zeigt man für jeden Prozessschritt nur die relevanten Felder an („Need to Know“ bzw. „Need to Do“ Prinzip). Somit wird ein Rahmen geschaffen, der den User durch den Prozess führt. Das reduziert die Anforderungen an die Fähigkeiten des Benutzers und ermöglicht die Umsetzung von bestimmten Lean-Prinzipien. Allerdings sollte man das s.g. „UI-Tailoring“ nicht zu exzessiv nutzen. Je erfahrener der Nutzer ist, desto mehr werden Einschränkungen als störend empfunden.

R. Müller: HTML-basierte User-Interfaces haben für prozessorientierte UIs aus unserer Sicht eindeutig die Nase vorn, allerdings gefallen uns die Editoren meist nicht. Mit den Standard-UI-Komponenten stößt man immer irgendwann an Grenzen und muss gegenüber dem Fachbereich erklären, warum eine Funktionalität auf Website XY geht, in unserer UI aber nicht möglich oder teuer umzusetzen ist.

W. Schäfer: Aber ein in das BPMS integriertes UI-Framework ist meistens die pragmatischere Lösung. Die Abbildung zwischen den Feldern und UI-Screens ist transparent und man kommt sehr schnell voran. Interessant wird es, wenn man das BPMS-UI in ein bestehendes Unternehmensportal einbinden möchte oder andere UI-Komponenten im BMPS eingebunden werden müssen.

Ein weiteres Auswahlkriterium ist die Testbarkeit des Systems. Oft werden die fachlichen Tests über die UI-Oberfläche gemacht. Daher ist ein BPMS, das automatisierte Tests der Oberfläche ermöglicht, zu bevorzugen.

Ralph Nelius: Kommen wir zu den Prozesskomponenten. Die Workflow-Engine muss natürlich die modellierten Prozesse inkl. Human Task Management gut abbilden können.

W. Schäfer: Ja richtig. Generell sollte man auch hier die Sicht der Enterprise Architektur nicht aus den Augen verlieren. Die zentrale Frage dabei ist, wo die Daten gehalten werden. Viele BPMS speichern die Daten (Felder) in der BPMS-Datenbank, vermischt mit Prozessdaten wie Statusinformationen und Bearbeitungszeiten.

Eine gute Lösung aus unserer Sicht ist, wenn eine Workflowengine möglichst als ein schlanker Service implementiert ist, der nur die Taskmanager- und Prozesssteuerungsfunktionalitäten bietet. Das UI und die Datenhaltung können dann die Applikationen übernehmen. Dabei orientiert man sich am besten an den Skills der eigenen Entwickler. In übergreifenden Prozessen mit mehreren beteiligten Applikationen kann die Workflowengine dann die Fluss-Steuerung übernehmen.

K. Köster: Ein weiterer wichtiger Aspekt ist die Taktung des Arbeitsflusses. Wie viel Zeit wollen Sie für ein Workitem zur Verfügung stellen? Fahren Sie zu schnell, leidet die Qualität. Fahren Sie zu langsam, haben sie einen schlechten Durchsatz. Um hier die richtigen Einstellungen zu finden, braucht ein BPMS verschiedene Timer. Sie müssen in der Lage sein, Arbeitsdauern nicht nur für den Gesamtprozess, sondern auch für einzelne Aktivitäten zu definieren und zu überwachen. Denn dauert eine Einzelaufgabe zu lange, kann das Auswirkungen auf ein Gesamt-SLA haben. Kann das BPM-Tool ermitteln, ob die Zeit für die nachfolgenden Schritte ausreicht? Hinzu kommt, dass fachlich häufig mit einem internen und einem externen SLA gearbeitet wird, um einen Puffer zu haben. Der externe SLA kann beispielsweise ein Kundenversprechen sein. Das BPMS muss in der Lage sein, beide SLAs zu tracken und zu unterscheiden. Das finden Sie nicht überall.

R. Müller: Ein dritter wichtiger Punkt im Bereich Prozesskomponenten ist die Frage, inwieweit das BPMS die Versionierung von Prozessmodellen und der dazugehörigen deploybaren Artefakte unterstützt. Am Anfang ist das noch kein großes Thema, weil viele Prozesse erstmals auf das BPMS gehoben werden. Später werden sie dann immer häufiger mit der Anforderung konfrontiert, im Rollout und im operativen Betrieb mit mehreren Versionen ausführbarer Prozessmodelle umgehen zu können. Für bereits bestehende Prozessinstanzen muss steuerbar sein, auf welchen Versionen sie ausgeführt und zu Ende gebracht werden sollen. Und die Migration lang laufender Prozesse muss unterstützt werden.

R. Nelius: Backend-Komponenten?

R. Müller: Hier spielen u.a. die Konnektoren zu anderen Systemen eine große Rolle. Eine Standardplattform wie Java kann hier ihre Asse ausspielen – es gibt eigentlich für alle erdenklichen Schnittstellen freie Libraries, die man meist einfach in das System einbetten kann. Da die Schnittstellen in die Außenwelt meist eh von entsprechenden Java-Entwicklern erstellt werden müssen, sollten diese auch mit den vertrauten Tools eines Entwicklers erstellt werden können. Mit speziellen Konfigurations-Wrappern erschwert man den Entwicklern aus unserer Sicht teilweise nur die Arbeit. Ein Entwickler arbeitet lieber mit einer Konfigurationsdatei als mit einem HTML-Formular.

Ralph Nelius: Und schließlich die technische Architektur?

R. Müller: Über die Bedeutung einer modularen Gesamtarchitektur der BPM-Plattform haben wir ja schon gesprochen. Aus unserer Sicht ist das eines der wichtigsten Kriterien, auf das man bei der Produktauswahl hinsichtlich der technischen Architektur achten sollte. Viele andere Aspekte der technischen Architektur sind aus unserer Sicht einfach Vorraussetzung für ein Enterprise Produkt.

W. Schäfer: Das bedeutet, dass es z.B. für das Deployment eines Prozesses oder von Geschäftsregeln den gleichen Zyklus wie in der klassischen Softwareentwicklung geben muss. Also Entwicklung, Test und Produktion in gesonderten Umgebungen mit Versionierung des Codes und der Konfiguration, automatisiertem Testing und notfalls auch der Möglichkeit eines Rollbacks. Dazu kommen noch Aspekte wie

• Mock-Ups für Integrationstests
• Möglichkeit zur Simulation von Prozessmodellen und Geschäftsregeln
• Unterstützung im Betrieb (klares Konfigurationskonzept, Unterstützung des techn. Loggings, davon getrennt Unterstützung der fachlichen Protokollierung und Ãœberwachung, Einbettung in eine vorhandene Application- / System Management-Infrastruktur)
• Hilfestellungen bei Fehlerbehandlung im Betrieb (alle relevanten Informationen übersichtlich an einer Stelle, klare Fehlermeldungen in den Log-Dateien, Möglichkeiten zu Korrekturen an invaliden Prozessinstanzen und Datenbeständen, Recovery-Konsole)
• Skalierbarkeit und Performance
• Sicherheit, beispielsweise eine revisionssichere Speicherung von Prozessabläufen 

K. Köster: Die technische Architektur eines BPMS sollte Sie grundsätzlich in die Lage versetzen, schnell Änderungen zu machen und mit Zuversicht in die Produktion bringen zu können.

Abschließende Fragen

R. Nelius: Abschließend würde mich noch interessieren, wie breit und wie tief man Ihrer Meinung nach in ein BPM-Tool hineinschauen sollte. Sie hatten oben an mehreren Stellen empfohlen, sich das Tool anhand von praktischen Beispielen zeigen zu lassen. Das ist natürlich immer besser, auf der anderen Seite darf der Auswahlprozess ja auch nicht zu lange dauern und zu viele Ressourcen binden.

K. Köster: Ja, nach unserer Erfahrung ist es schon so, dass es ein „window of opportunity“ gibt und man in dieser Zeit auch zu tragfähigen Ergebnissen kommen muss. Leider ist es so, dass man 1-2 Projekte gemacht haben muss, bis man sich mit BPM und einem Tool besser auskennt. Wie breit und wie tief sie einsteigen müssen, hängt primär von der fachlich-technischen Erfahrung des Produktauswahlteams ab. Daher fällt es mir schwer, hier konkretere Ratschläge zu geben.

R. Müller: Das Ganze würde einfacher, wenn die Anbieter, wie oben gewünscht, modulare Komponenten zur Verfügung stellen würden. Stellt sich später heraus, dass die Entscheidung für eine Komponente nicht passend war, so kann man diese einfach austauschen.

R. Nelius: Sollte man dann besser mit Open Source erste Schritte versuchen?

R. Müller: Open Source ist bestimmt ein interessanter Weg, um erste Schritte im BPM-Umfeld zu gehen und einige Open Source Komponenten machen sich sehr gut im Gesamtsystem. Allerdings decken die uns bekannten Open Source Lösungen nur jeweils einen Teil der oben genannten Komponenten ab, so dass auf jeden Fall schon zu Beginn des Projekts Integrationsaufwand betrieben werden muss.

W. Schäfer: Wichtig ist dann auch, sich im eigenen Unternehmen umzuschauen, was es alles schon gibt. Häufig sind einzelne Komponenten wie eine Workflow Engine, eine Reporting Engine etc. schon da. Dokumentenmanagementsysteme hat beispielsweise jedes Unternehmen im Haus und fast alle bringen Workflow-Funktionalitäten mit. Außerdem gibt es häufig schon IT-gestützte Mechanismen, um die Arbeit im Unternehmen zu verteilen. Das können große Prozessportale mit integrierten Arbeitplätzen sein, aber auch lokale Arbeitslisten in einzelnen Anwendungen. Hierauf könnte man anfangs dann aufbauen.

R. Nelius: Herzlichen Dank für diese wertvollen Einsichten!