In den vergangenen Monaten ist es uns gelungen, zusammen mit unserem Kunden HanseMerkur Krankenversicherung beachtliche und vor allem messbare Erfolge im Bereich der Automatisierung der Leistungsabrechnung zu erzielen. Nun musste sich der erstellte Prozess Einflüssen von außen stellen und seine durch den Ansatz BPM/SOA beworbene Flexibilität unter Beweis stellen.

Inhalte und Anwendung der GOZ.2012

In der GOZ sind – etwas vereinfacht ausgedrückt – die zahnärztlichen Behandlungen und deren abrechenbare Kosten beschrieben. Die einzelnen Behandlungen werden dabei textuell, aber auch durch einen Schlüssel, die Gebührenordnungsziffer, beschrieben bzw. können darüber identifiziert werden. Um die durchgeführten Behandlungen für eine eingereichte Zahnarztrechnung zu bewerten und daraus den Erstattungsbetrag zu errechnen, bedient sich ein Versicherungsunternehmen eben jener Gebührenordnungsziffern und gleicht darüber die Inhalte der Rechnung mit den versicherten Leistungen ab.

Die GOZ.2012 löst ihren etwa 25 Jahre alten Vorgänger, die GOZ.1988 ab. Ein Beweggrund für die Reform waren über diesen Zeitraum entstandene Behandlungsmethoden, die nun durch die Etablierung von neuen Gebührenordnungsziffern expliziten Einzug in die Gebührenordnung gehalten haben. In der Vergangenheit wurden diese Behandlungen in der Regel unter Zuhilfenahme sogenannter Analogziffern berechnet. Diese haben allerdings einen direkten Rückschluss auf die tatsächlich durchgeführte Behandlung und damit die Errechnung des Erstattungsbetrags erschwert.

Auswirkungen der Reform auf die Versicherungsunternehmen

Der Gesamtablauf des Prozesses vom Input Management über die verschiedenen Leistungsprüfungen und die Regulierung bis zur Erstellung des ausgehenden Druckstücks und der Zahlungsanweisung wird an diversen Stellen von der Einführung der GOZ.2012 betroffen. Diese gilt es in ihrer Gesamtheit zu berücksichtigen, um einerseits einen zielgerichteten, reibungslosen internen Ablauf zu gewährleisten und andererseits dem Kunden gegenüber weiterhin eine kurze Bearbeitungszeit und vor allem korrekte, nachvollziehbare Abrechnungen gewährleisten zu können.

Von der Verabschiedung durch den Bundesrat bis zum Inkrafttreten der GOZ.2012 lagen nur zwei Monate, so dass auch schon in den ersten Monaten des Jahres 2012 mit Einreichungen, die nach der GOZ.2012 abgerechnet wurden, zu rechnen war. Es war also Eile geboten, die allerdings keinesfalls zu Lasten der Qualität des bestehenden Prozesses gehen durfte – weder für den Kunden, noch für die HanseMerkur.

Und damit nicht genug – eine zusätzliche Herausforderung bestand darin, im gleichen Zuge das Expertensystem ZABAS in die vormals eigenentwickelte Prüfstrecke für Zahnarztrechnungen einzubetten.

Prozessorientierung und automatisierte Abnahmetests machen das Leben leichter

Die Einphasung der GOZ.2012 beginnt bereits im Input Management. Die Regelwerke zur automatischen Erkennung der Belegdaten und zu den manuellen Nachkorrekturstellen mussten entsprechend um die geänderten Gebührenordnungsziffern ergänzt bzw. angepasst werden.

Im Fachprozess selbst bestand die Herausforderung darin, die Belege nun so durch den Prozess zu leiten, dass sie durch das Expertensystem ZABAS GOZ geprüft werden. Während die Zusteuerung durch lokale Eingriffe in entsprechende, bereits existierende Steuertabellen realisiert werden konnte, stellten der Aufbau und die Anpassung des Regelwerks zur Prüfung der Belege in ZABAS die größere und komplexere Aufgabe dar.

Weitere essentielle Anpassungen gab es sowohl im Bereich der Ermittlung geeigneter Sachbearbeiter für die manuelle Bearbeitung als auch hinsichtlich der Dialoge und weiterer unternehmensspezifischer Schlüssel- bzw. Regelsysteme.

Bei Anforderungen mit den oben geschilderten Ausmaßen gilt es zunächst, die betroffenen Stellen im Prozess und die notwendigen Maßnahmen zu identifizieren. Ein prozess- und serviceorientierter Ansatz und eine durch Modelle gestützte End-to-End-Betrachtung des Gesamtprozesses machen einem das Leben an dieser Stelle erheblich leichter und helfen dabei, Konsens über die Vision zu erreichen, um schnell mit der Feinkonzeption und der Umsetzung beginnen zu können.

So auch in unserem Fall. Dennoch ist dieser Ansatz keine Garantie für fehlerfreie Konzepte und Software oder für eine reibungslose Integration von Fremdsystemen in die eigene IT- und Prozesslandschaft. Es soll an dieser Stelle nicht verschwiegen werden, dass wir vor Inbetriebnahme mit Fehlern und den allseits ungeliebten Integrationsschwierigkeiten an der Schnittstelle zum Fremdsystem zu kämpfen hatten. Glücklicherweise haben wir schon in der Vergangenheit in den konsequenten Einsatz von automatisierten Modul- und Abnahmetests auf Basis des FIT-Frameworks investiert, so dass wir in der Lage waren, die Fehler zeitnah zu identifizieren und zu beheben.

Bemerkenswert war meiner Meinung nach der Umgang mit den Problemen und miteinander in der „heißen Phase“ vor der Produktivsetzung. Trotz einiger Widrigkeiten wurde nicht in operative Hektik verfallen. Sowohl das Team – Fachbereich und IT – als auch das Management haben durch ihre besonnene Art und das respektvolle, kollegiale Miteinander den konstruktiven, lösungsorientierten Umgang mit dieser Situation ermöglicht.

Fazit

Die Umstellung auf die GOZ.2012 hat zwar etwas länger gedauert als erhofft, aber alles in allem hat sie weniger Zeit in Anspruch genommen, als manche Prognosen und der marktübliche Schnitt erahnen ließen. Ob dies auch ohne Prozess- und Serviceorientierung sowie automatisierte Tests gegangen wäre? Sicher nicht. Und das gesamte Team, Fachbereich, IT, Interne wie Externe, ist froh, es nicht probiert haben zu müssen.

Dass diese Frage alles andere als trivial und doch manchmal ganz leicht zu beantworten ist, haben wir kürzlich im Projekt erfahren.

Als Payload (engl. für „Nutzlast“) bezeichnet man üblicherweise die Daten, die in einem Prozess von Aktivität zu Aktivität transportiert werden. In vielen Fällen ist die Payload eine XML-Struktur, die den Transport beliebiger Daten zulässt. Eine Aktivität nimmt die Payload, führt darauf eine Operation aus (dies kann alles sein: von einer lokalen XSL-Transformation bis zum Aufruf eines Webservices) und schreibt das Ergebnis zurück in die Payload, worauf die nächste Aktivität dann ihrerseits operiert.

Extrem 1: Payload mit IDs

In unserem Projekt ist die BPE, in unserem Fall die inubit Suite, aufgesetzt auf einer serviceorientierten, mit EJB3 realisierten Architektur, die in einem JBoss Application Server läuft. Geschäftslogik findet nur in der Business Service-Schicht statt, die BPE übernimmt ausschließlich die Prozesssteuerung und orchestriert im Wesentlichen die Business Services, die sie über Webservices aufruft. Die Tatsache, dass die zugrunde liegende SOA in Hinblick auf ihre Schnittstellen sehr homogen ist, hat dazu geführt, dass die Prozesse mit einer sehr schlanken Payload auskommen. Wir schleusen in den meisten Fällen nur die IDs von Fachobjekten durch den Prozess, die dann an die Services gereicht werden.

Dieses Vorgehen stellt gewisse Anforderungen an die Business-Service-Schicht. Diese muss nämlich alle Daten, die sie benötigt, anhand der IDs, die sie vom Prozess bekommt, über Domain Services aus der Datenbank beschaffen und die Änderungen nach der Verarbeitung über Domain Services auch wieder persistieren.

Extrem 2: Payload mit Fachobjekten

Das andere Extrem ist es, komplette Fachobjekte am Beginn des Prozesses einmal über einen Service in den Prozess zu laden und dann in der Payload mitzuführen. Die Objekte werden dann an die Services gereicht, die dann nur noch die Änderungen durchführen und das manipulierte Objekt an den Prozess zurückgeben müssen. Der Prozess muss dann an geeigneter Stelle die Objekte persistieren. In einer heterogenen Welt könnte der Prozess so auch Schnittstellen bedienen, die unterschiedliche Strukturen erwarten, indem die Fachobjekte ggf. in die jeweilige Zielstruktur gemapped werden.

Auf der Service-Schicht würde dieses Vorgehen einerseits Datenbankzugriffe, andererseits remote calls auf die Domain Service-Schicht sparen.

And the winner is…?

Wir haben kürzlich beide Varianten auf ihr Laufzeitverhalten untersucht. Das Ergebnis war eindeutig: Die Ersparnis an Datenbankzugriffen und remote calls wird durch die Verwaltung der Payload in der BPE, bei der große XML-Strukturen häufig in das Filesystem geschrieben und wieder geladen werden, bei weitem neutralisiert. Die Variante mit Fachobjekten war in unseren Tests bis zu fünf Mal langsamer als die Variante mit IDs. Die Ergebnisse bei der Laufzeit waren so eindeutig, dass wir weiterführende Untersuchungen, z.B. in Richtung Netzlast, gar nicht mehr angestellt haben.

Was wir daraus lernen können

Mindestens genauso interessant wie das eigentliche Ergebnis der Untersuchung waren aber die Erkenntnisse, die ich als Nebenprodukt gewinnen konnte. Die eine wie die andere Variante hätte nämlich erheblichen Einfluss auf die gesamte Architektur und das Prozessdesign.

Persistiert jeder Service immer alle Änderungen sofort, braucht man sich keine Gedanken darüber zu machen, zu welcher Zeit man welchen Datenzustand benötigt und wann manuelle Synchpoints aus dem Prozess heraus nötig sind. Möglicherweise reicht es dabei gar nicht aus, am Anfang des Prozesses zu laden und am Ende zu speichern. Gibt es im Prozess manuelle Rückkopplungen mit Mitarbeitern, so muss vor diesen gespeichert werden, damit der Mitarbeiter auf dem aktuellen Stand aufsetzt.

Dazu kommt, dass die Fachobjekte in der BPE, z.B. als XSD, modelliert werden müssen. Existiert in der SOA ein Versionskonzept, das den parallelen Betrieb verschiedener Versionen eines Services erlaubt, so muss dieses in der BPE entsprechend nachgebildet werden. Außerdem wird ein Konzept für den Transport von Fachobjekten über die (Web-)Service-Schnittstellen hinaus notwendig. Setzt man auf abstrakte DTOs (seit EJB3 manchmal als Anti-Patterns verschrien), entsteht zusätzliches Mapping auf der Service-Schicht, das sowohl zur Entwicklungs- als auch Laufzeit Aufwand bereitet. Werden echte JPA-Entitäten verwendet, verliert man die lose Kopplung, die den Charme einer SOA ausmacht, da die (Web-)Service-Consumer direkt von Änderungen an den Entitäten abhängig sind.

Auf der anderen Seite muss man sagen, dass eine Payload, die nur auf IDs operiert, eine homogene Servicelandschaft voraussetzt, in der alle Services mit diesen IDs auch umgehen können und Zugriff auf die Daten haben. Werden Dritt- oder Legacysysteme angebunden, so müssen möglicherweise Fachobjekte durch den Prozess geschleust werden, um diese Systeme zu bedienen.

Fazit

Eine eindeutige Empfehlung für den einen oder anderen Weg kann es an dieser Stelle nicht geben. Ich möchte aber die Sinne dafür schärfen, dass diese Entscheidung durchaus weitreichende Folgen haben kann und gründliche Überlegungen erfordert.

Beispiele für das Szenario gibt es viele. Es ist z.B. denkbar, dass eine Loop-Activity Bewerbungen für einen Zeitraum entgegennimmt und in einer Liste sammelt. Diese werden dann zusammen in der HRM-Abteilung bearbeitet und später einzeln auf die Fachbereiche verteilt. In unserem rein technischen Beispiel warten wir auf die Eingabe von fünf Namen, die wir in einer einfachen Parallel-Ausführung und dann in einem parallelen Sub-Prozess einzeln anzeigen.

Unser Prozess beinhaltet eine Liste von Namen, die in der ersten Loop-Aufgabe abgefragt und über einen Connector der Namens-Liste hinzugefügt werden. Der zweite Schritt besteht aus einer einfachen Nutzer-Aufgabe, die für jeden Namen aufgerufen wird und diesen dann ausgibt. Hierzu wählt man die Aufgabe aus und selektiert unter “Advanced” die Einstellung “is Multi-Instantiated”. Es erscheinen zwei Felder, die das Instantiieren und das Zusammenführen von den Aufgaben-Instanzen organisieren. Der “Instantiator” ermittelt die Anzahl und Parameter für die Aufgaben-Instanzen, während der “Join Checker” überprüft, ob alle Aufgaben abgeschlossen wurden, die für die Fortführung des Prozesses nötig sind. Demnach läuft der Instantiator auch vor allen Enter-Methoden, und wir erzeugen uns für unser Beispiel einen ”Variable number von instances”-Connector. Wichtig ist, dass die lokalen Variablen in der Instantiator-Phase noch nicht zur Verfügung stehen.

Bonita: Mit "Variable number von instances" eine Liste auf eine lokale Variable mappen

Im Wizard-Verlauf müssen nun der Name einer lokalen Aufgaben-Variablen und die Liste der Werte angegeben werden. Die Variable können wir im Drop-Down über “Create data …” wie gewohnt erzeugen. Wichtig ist, dass unter “Name” kein GString angegeben wird, wie ihn Bonita fälschlich automatisch dort einfügt. Das heißt, der Name muss ohne Dollar und geschweifte Klammern in dem Feld stehen. Um die Werte nun zuzuweisen, muss man auf den Link “Set value as expression” klicken, um in eine Ansicht zu kommen, die nur eine Liste erwartet. Hier geben wir unsere Liste als GString an.

Über den Join Checker stellt Bonita fest, ob alle Aufgaben-Instanzen beendet wurden, und fährt dann mit dem Prozess fort. Hier kann ein einfacher “Percentage of completed instances”-Connector ausgewählt werden, den wir mit “1.00″ für 100% versehen. Dies soll schon genügen: Wir teilen über den Instantiator Anzahl und Werte der BPE mit, und diese Werte werden bei der Aufgaben-Instanziierung den lokalen Variablen zugewiesen. Wenn alle Aufgaben abgeschlossen, sprich alle Namen angezeigt wurden, führen wir die Arbeit fort.

Bei einem mehrfach ausgeführten Sub-Prozess kann man das Vorgehen fast analog anwenden. Es muss zusätzlich die lokale Variable der Aufgabe auf eine Variable des Sub-Prozesses gemapped werden, mit der dieser dann arbeiten kann.

Wir hatten nun die Anforderung, dass wir an der Aktivität die eigentliche Liste der Daten erst ermitteln mussten, um den Sub-Prozess mit mehreren Daten aufzurufen. Man könnte dies mit einer Java-Klasse lösen, die die MultiInstantiator-Klasse der Bonita-API erweitert. Um eine schon bestehende Methode nutzen zu können, entschieden wir uns für die Groovy/Java-Lösung. In diesem Fall muss man ein Groovy/Java-Code-Snippet schreiben, das eine Liste von Aufgaben-Variablen zurückgibt. Konkret: List<Map<String, Object>>. Für jeden Listen-Eintrag wird eine Instanz gestartet, und die lokalen Variablen der Aufgabe werden durch Einträge aus der Map gefüllt. Für unser Namens-Beispiel sieht unser Java-Snippet so aus:

List<Map<String, Object>> initParams = new ArrayList<Map<String, Object>>(); // Liste aus Parametern.

for (Object processVar : listOfNames) {
  Map<String, Object> entry = new HashMap<String, Object>();
  entry.put("name", processVar);
  initParams.add(entry);
}
return initParams;

Bonita: Groovy-Instantiator mit einem Java-Snippet befüllen

Für Groovy und Java-Code wählt man den “Groovy”-Connector unter Instantiator. Hier erwartet Bonita ein Code-Snippet, das dann ausgeführt wird. Sehr tückisch ist auch hier, dass Bonita gern GStrings bei der Verwendung des Expression-Editors einfügt. So wird der komplette Code nach dem Verlassen des Expression-Editors, der  auch Code-Highlighting und Hilfe beim Import von Klassen bietet, in einen GString gewrapped. Dieser kann dann nicht ausgeführt werden – es müssen manuell alle GStrings entfernt werden. (Dies gilt auch für Variablen im Snippet, da der Inhalt ansonsten später als Groovy-Code ausgewertet wird). Sollte man dies mal übersehen, wird der Prozess an der Stelle abbrechen. Man erhält in der engine.log eine Fehlermeldung wie:

org.ow2.bonita.util.BonitaRuntimeException: Unable to find a method with name: setScript and parameters: [classjava.util.ArrayList=[{a=1, b=1}, {a=2, b=2}, {c=3, c=3}, {d=4, d=4}],] in connector: class org.bonitasoft.connectors.bonita.instantiators.GroovyInstantiator
    at org.ow2.bonita.definition.activity.AbstractActivity.instantiateMultiInstanceActivity(SourceFile:225)
    at org.ow2.bonita.definition.activity.AbstractActivity.execute(SourceFile:168)

Bonita: Lokale Variablen auf SubProcess mappen

Das ganze Beispiel kann als Bonita-Prozess herunter geladen werden.

Wie dieses Vorgehen auch bei der Implementierung automatisierter Prozesse in einer Process-Engine funktionieren kann, soll dieser Beitrag zeigen.

Alles Attrappe!

Eine große Hilfe bei testgetriebenem Vorgehen sind Mock-Objekte, die es erlauben, Funktionalität zu simulieren, die für den Test eines Features nötig, aber noch nicht fertig implementiert ist. Außerdem ermöglichen Mock-Objekte das isolierte Testen von Funktionalitäten unabhängig von anderen, die im Rahmen des Tests nicht mitgetestet werden sollen. Ein Beispiel: Ein Business-Service, der getestet werden soll, verwendet andere Business- und Domain-Services einer SOA. Für die benutzten Services existieren bereits Unit-Tests, es gibt also keinen Grund, die Funktionalität dieser Services mit zu testen. Die Services werden “gemocked”, zur Testlaufzeit werden sie nicht aufgerufen, sondern es wird nur ein vorher am Mock-Objekt definiertes Ergebnis zurückgeliefert. Das hat viele Vorteile: Steht ein aufgerufener Service einmal nicht zur Verfügung, beeinflusst das den Test nicht, es müssen z.B. keine eventuell aufwändigen Datenkonstellationen für die aufgerufenen Services erzeugt werden.

Für die Entwicklung mit Java und JUnit gibt es dafür gute und akzeptierte Frameworks, ein Beispiel hierfür ist Mockito.

TDD in der Prozessentwicklung

Schwieriger ist das testgetriebene Entwickeln, wenn es um die Automatisierung von Prozessen in einer Process-Engine geht. Viele Process-Engines nutzen für die Modellierung ausführbarer Prozesse eine eigene Notation. Frameworks, die eine testgetriebene Entwicklung unterstützen, gibt es in aller Regel nicht. Gerade die Prozessschicht, die nur Business-Services orchestriert, ist also darauf angewiesen, dass alle aufgerufenen Komponenten zur Verfügung stehen, um den Prozess testen zu können. So kann die Implementierung der Prozesse oft erst dann beginnen, wenn die Entwicklung der Services abgeschlossen ist. Agiles, iteratives Vorgehen ist dann auf dieser Ebene nur schwer möglich.

Um diesem Problem zu begegnen, haben wir in unserem laufenden Projekt ein Framework entwickelt, das uns an dieser Stelle gezielt hilft. Das Framework ist zwar in der spezifischen Notation der im Projekt eingesetzten Process-Engine implementiert, die Idee ist aber übertragbar.

Schematische Darstellen der Funktionsweise des Mock-Frameworks

Kernstück des Mocks ist eine Datenbank, in der alle für den Testlauf relevanten Informationen abgelegt werden: welcher Prozess gestartet werden soll, ob einzelne Prozessschritte gemocked oder tatsächlich ausgeführt werden und welche Response ein Mock zurückliefern soll. Dafür stellt das Mock-Framework einen Webservice-Endpoint zur Verfügung, alle Informationen werden in der SOAP-Nachricht verpackt. Das Framework parst die SOAP-Nachricht, schreibt die Mock-Informationen in die Datenbank und startet dann den angeforderten Prozess.

Mocken einzelner Services

Implementierung eines Service-Mock

Um zur Laufzeit dann einzelne Schritte mocken zu können, muss für jeden Service ein Mock-Prozess bereit gestellt werden. Dieser Prozess stellt einen Webservice-Endpoint bereit, auf den die Aufrufe aus den Fachprozessen zielen. Der Mock-Prozess ermittelt dann in der Datenbank, wie mit dem konkreten Aufruf zu verfahren ist – wird er gemocked, liest er die Response und liefert diese direkt zurück. Soll der Service aufgerufen werden, so wird der tatsächliche Endpoint angesprochen und dessen Response dann an den Fachprozess durchgereicht.

Das klappt mit Services ohne größeren Aufwand, da dort sowieso über Webservice-Calls kommuniziert wird. Beim Deployment auf die nächsthöhere Staging-Stufe wird bei den Service-Calls in den Fachprozessen der Endpoint des Mock-Frameworks durch den des echten Service ersetzt, es entsteht kein zusätzlicher Aufwand und es ist nicht nötig, das komplette Mock-Framework mit zu stagen.

Und ganze Prozesse?

Implementierung eines Subprozess-Mock

Subprozesse werden nicht per Webservice aufgerufen, sondern sind direkt in den darüber liegenden Prozess eingebettet. Dadurch kann nicht einfach ein Webservice-Call auf das Framework umgebogen werden. Soll ein Subprozess gemocked werden, muss daher ein künstlicher Aufruf des Mock-Frameworks eingebaut werden. Das Mock-Framework liefert dann die definierte Response zurück. Subprozesse lassen sich auf diese einfach als Ganzes mocken. Ist der Subprozess implementiert, muss der künstliche Aufruf des Mock-Frameworks wieder entfernt werden. Einzelne Services im Subprozess lassen sich dann wieder gezielt mocken.

Fazit

Diese relativ einfache Implementierung eines Mock-Frameworks ermöglicht uns, die Entwicklung der Prozesse schon parallel zur Entwicklung der Services zu beginnen – oder, wenn nötig, schon davor. Das lässt sich nicht nur hervorragend mit unserem agilen Vorgehen vereinbaren, es trägt auch zur Akzeptanzbildung bei. So waren wir schon im zweiten Entwicklungssprint in der Lage, den Top-Level-Prozess in der “Happy-Path”-Variante fertig zu stellen, größtenteils mit gemockten Services und Subprozessen, an geeigneten Stellen den vertikalen Durchstich zu erproben und das Ganze dann im Review erfolgreich zu präsentieren.

Die HanseMerkur Versicherungsgruppe ist bei den 2011 Global Awards for Excellence in Business Process Management and Workflow mit dem Gold Award für die Region Europa ausgezeichnet worden. Die international besetzte Jury aus Vertretern der Workflow Management Coalition und BPM.com würdigte damit ein herausragendes Projekt zur Automatisierung der Leistungsabrechnung in der privaten Krankenversicherung. Die mit Weitsicht geplante und professionell umgesetzte BPM/SOA-Lösung basiert auf einer serviceorientierten Architektur für die prozessübergreifende Geschäftslogik des Unternehmens, auf der eine Business Process Management Suite (BPMS) zur Steuerung und Automatisierung der Leistungsprozesse aufsetzt. Mit diesem Projekt konnte die Auto­matisierungsquote (vollständige Dunkelverarbeitung) über alle Leistungsabrechnungen von anfänglich 8% auf rund 30% gesteigert werden – ein hervorragender Wert im Bereich der privaten Krankenversicherungen, der es der HanseMerkur ermöglicht, die deutlich gestiegenen Fallzahlen mit dem vorhandenen Mitarbeiterstamm zu bewältigen. Zudem sind die Durchlaufzeiten der Leistungsabrechnungen massiv verkürzt worden, was sich für die Kunden der HanseMerkur positiv bemerkbar macht. Eine ausführliche Beschreibung des mit dem Award ausgezeichneten Projekts bietet die Success Story „Automatisierte Leistungsabrechnung bei der HanseMerkur Versicherung“ .

Diesem Projekt zugrunde liegt eine BPM/SOA-Initiative, an deren fachlicher und IT-technischer Ausgestaltung mehrere Holisticon-Berater maßgeblich beteiligt waren. Deren Empfehlung, den Fokus auf die Geschäftsprozesse zu legen und diese technologisch optimal zu unterstützen, war einer der wesentlichen Erfolgsfaktoren. Das bestätigt auch Gunnar Grund, Abteilungsleiter Organisationsentwicklung bei HanseMerkur: “Ein wesentlicher Wettbewerbs­faktor für die HanseMerkur ist es, die Kundenprozesse End­ to­ End zu beherrschen. Dies konnten wir mit der Hilfe von Holisticon erreichen!” Die Holisticon-Berater waren Teil eines interdisziplinären Teams, bestehend aus Abrechnungsexperten, Business-Architekten, Softwarearchitekten, Entwicklern und Mitarbeitern verschiedener Abteilungen. Für Dr. Horst Karaschewski, Abteilungsleiter Anwendungsentwicklung bei HanseMerkur, war es faszinierend zu sehen, wie dieses Team gemeinsam an innovativen Themen arbeitete und dabei oft die traditionellen Denkweisen verließ, aber nie die gemeinsame Vision aus den Augen verlor. Dieser gemeinsame Geist, so Karaschewski bei der Dankesrede anlässlich der Preisverleihung, machte in diesem Projekt den Unterschied aus – und ein solch beeindruckendes Ergebnis erst möglich.

Über HanseMerkur

Das Unternehmen mit Sitz in Hamburg kann bereits auf eine lange Tradition zurückblicken. Ein Vorgänger­unternehmen, die Hanseatische Krankenversiche­rung VVaG, wurde 1875 gegründet. Damit ist die HanseMerkur Deutschlands zweitältester Krankenversicherer. Bis heute ist die private Krankenver­sicherung (PKV) beim Hamburger Personenver­sicherer die Hauptsparte mit einem Beitragsvolumen von 806 Mio. Euro (2010). Mit 1.750 Mitarbeitern im Innen­- und Außendienst erwirtschaftete die Hanse­Merkur 2010 einen Jahresumsatz von 1,1 Mrd. Euro.

Über Holisticon

Die Holisticon AG ist eine Management- und IT-Beratung mit Sitz in Hamburg. Wir begleiten Unternehmen im Wandel, indem wir Menschen, Geschäftsprozesse und Technologie passend aufeinander abstimmen. Bei allem, was wir tun, bringen wir unsere umfassende Erfahrung aus den Bereichen Softwareentwicklung, Architektur, Geschäftsprozessmanagement sowie dem Projektmanagement mit ein. Unsere Kunden schätzen an Holisticon genau diesen ganzheitlichen Beratungsansatz. So können wir sie auf technischer, taktischer wie auch auf strategischer Ebene in ihren Entwicklungsprojekten optimal unterstützen und durch eine allzeitgemäße IT zu neuem Geschäftswert führen. Zu unseren Kunden zählen namhafte große und mittelständische europäische Unternehmen sowie weltweit agierende Konzerne.

Rundumsichtige Beratung bedeutet für uns, organisatorische, fachliche und technologische Aspekte im Blick zu haben – nicht in jedem Projekt, aber immer dort, wo dieser Blick angemessen ist und weiterhilft. Dabei ist Holisticon anbieterneutral und branchenübergreifend.

Wir machen genau das, was wir besonders gut können: Agil, BPM/SOA, Softwarearchitektur und Enterprise Java. Und das, was wir gut können, machen wir wirklich gut. Unaufgeregt, gradlinig, schnörkellos.

Ansprechpartner

Oliver Ihns
Vorstand
Holisticon AG
Friedensallee 120
22763 Hamburg
Fon +49 40 5074 2722
oliver.ihns@holisticon.de
www.holisticon.de

BPM meets Java EE:
Automatisierte Leistungsabrechnung bei der HanseMerkur Versicherung

Ende 2008 startete die HanseMerkur Versicherung eine BPM/SOA-Initiative mit der Vision, die vormals monolithische und systemorientierte Sichtweise der hausinternen Informationstechnik gezielt der Prozess- und Serviceorientierung weichen zu lassen. Im Einzelnen bedeutete dies die Bereitstellung einer entsprechenden Infrastruktur, die Entwicklung einer Basisarchitektur und darauf aufsetzend Schritt für Schritt eine weitgehende Ablösung der bestehenden Leistungsabrechnungssysteme durch ablauffähige Prozessbeschreibungen, wiederverwendbare Komponenten und Services auf Basis der Java Enterprise Edition.

In ihrem Artikel beleuchten Jo Ehm und Olaf Fricke (HanseMerkur) die technischen Details der Umsetzung von BPM/SOA bei der HanseMerkur Versicherung: das Design und die Entwicklung einer Komponenten- und Servicearchitektur auf der Basis von EJB3 unter JBoss, das dazu entwickelte Framework mit einer ComponentRegistry, die den parallelen Betrieb verschiedener Versionen der gleichen Services, den versionierten Zugriff sowie den Austausch dieser Services zur Laufzeit ermöglicht, die Modellierung, Orchestrierung und Automatisierung der Geschäftsprozesse mit Hilfe der inubit BPM-Suite und die Best Practices im Bereich des Testens – von UnitTests bis hin zu FIT-Tests für den Fachbereich.

Der komplette Artikel ist online zugänglich im Archiv des JavaSPEKTRUMs.

Der Dämpfer zuerst

Ein Blick in das agile Manifest fördert zunächst Ernüchterung zutage:

„Individuals and interactions over processes and tools”

Na toll, das klingt auf den ersten Blick wenig erfolgversprechend. Aber schauen wir hinter die Kulissen und machen uns ein eigenes Bild.

BPM: ein weites, facettenreiches Feld

Unbestritten ist, dass BPM ein weitreichender Themenkomplex aus technischen, fachlichen und Aspekten aus der Organisationsentwicklung ist.Die Umsetzung eines einzelnen Geschäftsprozesses stellt nur einen kleinen Ausschnitt dar. Da dieser Blog-Beitrag aber kein abendfüllender Ersatz für schlechtes TV-Programm sein soll, beschränke ich mich zumindest für den Moment auf die Konzeption und technische Umsetzung eines zuvor dafür identifizierten Geschäftsprozesses.

Was kann BPM beisteuern?

In der Regel folgen wir bei der Fragestellung von Konzeption und Modellierung der Methodik von Bruce Silver und anderen: Wir gehen über die BPMN und die Level 1, 2 und 3 vor.

Level 1 nutzen wir, um einen Überblick über den Gesamtprozess zu bekommen. Daraus lassen sich schon recht gut Inhalte und Verantwortlichkeiten sowie die Abhängigkeiten der fachlichen Einheiten – der Bausteine – des Gesamtprozesses ableiten, wenn das Level 1 einen ausreichenden Reifegrad erreicht hat.

Auf dieser Basis beginnen wir, mittels Level 2 die Prozessmodellierung in die Tiefe zu treiben. Da wir über das Level-1-Modell die Verantwortlichkeiten herausgearbeitet haben, können wir dies tatsächlich in den meisten Fällen seiteneffektfrei tun. Die konkrete Ausgestaltung eines Subprozesses A hat also in der Regel keinen Einfluss mehr auf die Inhalte von Subprozess B. Dies gilt für den Regelfall –  natürlich kann das vorkommen, aber durch ein reifes Level 1 lässt sich dies deutlich minimieren. Bestandteile von Level 2 sind insbesondere Prozessmodelle bis auf Task-Ebene und fachliche Fehler- und Ausnahmebehandlungen jenseits des „Happy Path“.

Mit Level 3 gehen wir recht pragmatisch um. Heißt: wir meinen damit nicht per se „ausführbares BPMN“. Generell verstehen wir darunter die Einbringung von technischen Gegebenheiten in die Prozessmodelle. Das ist einerseits die Unterfütterung mit konkreten Service-Modellen und Dialogen, andererseits zählen aber auch aus technischen Gründen notwendige Schritte wie beispielsweise die Ermittlung von prozessrelevanten Daten zu einer ID dazu.

Zusammenspiel mit Scrum

Die spannende Frage ist nun, wie sich dieses Vorgehen mit Scrum verheiraten lässt, bzw., wie sich die Elemente von Scrum daraus ableiten lassen.

Produktvision

Der Scrum-Prozess beginnt mit einer Produktvision. Für das Produkt eines umzusetzenden Geschäftsprozesses lässt sich diese recht gut durch ein Prozessdiagramm in BPMN Level 1 untermauern, konkretisieren und anschaulich an die Teammitglieder transportieren. Das entbindet den Product Owner aber nicht davon, eine wohlformulierte Vision zu verfassen. Diese sollte die Essenz dessen, was das Prozessmodell darstellt, transportieren und neben dem fachlichen Inhalt auch den Zweck bzw. das Ziel, den Geschäftswert und die Zielgruppe beinhalten. Wie gesagt, das Prozessmodell unterstützt die Vision, ersetzt diese aber nicht. Sie trägt aber definitiv zu deren Konkretisierung und zur Schärfung der Vorstellung des Produkts bei.

Backlog

Als nächstes gilt es, das Backlog mit Features und den dazugehörigen User Stories zu füllen und diese zu priorisieren.

Wir haben dabei folgenden Ansatz gewählt:

Das zuvor erstellte Prozessmodell haben wir so weit verfeinert, bis sich die fachlichen Anforderungen in Form von Prozessbausteinen (Prozess, Subprozess, Prozessschritt) identifizieren ließen und wir ihr Zusammenspiel und ihre jeweiligen Verantwortlichkeiten betiteln und bewerten konnten.

Dazu mussten wir keine flächendeckende Tiefenbohrung machen und auch nicht jede Eventualität oder fachliche Ausnahmesituation berücksichtigen. In Silver’schen BPMN-Sprech bedeutet das, dass wir uns oberhalb von Level 1 und deutlich unterhalb von Level 2 bewegt haben. Damit ist genau der Reifegrad des Modells gemeint, der weiter oben schon angesprochen wurde.

Aus den Prozessbausteinen, die wir zuvor aus den Anforderungen abgeleitet haben, haben wir dann jeweils ein eigenes Feature gemacht und dieses mit relevanten Abnahmekriterien versehen. Bei Prozessen und Subprozessen beschränkten sich Inhalt und Abnahmekriterien auf die Ablaufsteuerung bzw. deren Korrektheit. Die Features für die Prozessschritte rankten sich um die Geschäftslogik der durch die Schritte repräsentierten Services (Service Tasks) oder Dialoge (Human Tasks).

Ein Backlog in einer ersten Fassung inkl. Features hatten wir nun also. Allerdings waren die Features noch nicht nach Geschäftswert priorisiert und die Reihenfolge orientierte sich zunächst am Prozessablauf. Die Priorisierung warf dann einige spannende Fragen auf. Nämlich, ob ein Prozess oder die enthaltenen Services höher zu priorisieren sind. Für die Konzeption ist ein Top-Down-Vorgehen analog der Prozesshierarchie einfacher, weil grobe fachliche Einheiten in immer kleinere Teile zerlegt und beschrieben werden können. In der Entwicklung wirkt dagegen ein Bottom-Up-Ansatz intuitiver, da sich die entstandenen Bausteine so zu größeren Einheiten zusammenfassen lassen. Letztlich haben wir uns für einen pragmatischen Umgang entschieden und in der Entwicklung mit Elementen wie Mocks gearbeitet – was ja grundsätzlich keine schlechte Idee ist – oder in anderen Fällen die Einbindung von Services und damit Prozessschritten erst dann vorgenommen, als diese im Backlog an der Reihe waren.

Die tägliche Arbeit

Im Sprint haben wir dann die Konzepte und Modelle in die Tiefe getrieben. Neben einer strukturierten textuellen Beschreibung war das Ergebnis ein BPMN-Level-2-Modell. Das bedeutet, dass wir uns um Ausnahmebehandlungen Gedanken gemacht und die konkrete Fachlichkeit von Services sowie die Dialoge genauer beschrieben haben. Da wir uns vorher schon mittels des Level-1-Modells Gedanken über Abhängigkeiten und fachlich abgeschlossene Bereiche Gedanken gemacht haben, hielten sich spätere Umbaumaßnahmen erfreulicherweise im Rahmen. In der Regel haben wir bestehende Dinge erweitert und nicht substantiell geändert.

Aber natürlich haben sich Anforderungen geändert und das anfängliche Modell war Änderungen unterworfen, da wir anfänglich auch einfach „mal falsch lagen“ – das Leben ist gemein.

An dieser Stelle ist die Erkenntnis einer eigentlich bekannten Tatsache unumgänglich: ein Feature entspricht nicht einem Software-Artefakt. Bedeutet: das Fertigstellen eines Features heißt nicht, dass ein zugehöriges Artefakt nicht durch weitere Features geändert wird – genau das wäre die Illusion des Wasserfalls! Ein neuer Prozessschritt zieht neben der Erstellung eines Services oder Dialogs auch die Änderung des nutzenden Prozesses nach sich.

Ein Beispiel: die Anforderung, Rechnungen in Fremdwährungen bearbeiten zu können, kann zu einem Prozessschritt zur Umrechnung in Systemwährung, aber auch zu Änderung von mehreren bestehenden Services führen, die dann mit der Fremdwährung umgehen können müssen. In beiden Fällen müssen bestehende Artefakte geändert werden. Genau dieser flexible Umgang mit neuen oder geänderten Anforderungen und den damit einhergehende Refactorings sind Grundfesten von agilen Methoden.

Fazit

BPM und Scrum können sich, richtig angewendet, sinnstiftend ergänzen. Weder wirkte sich Scrum invasiv auf die BPM-Methodik aus, noch hemmte diese andersherum das Vorgehen mit Scrum. Vielmehr haben einige Elemente aus BPM sogar einen förderlichen Beitrag zum Vorgehen mit Scrum geleistet. Zurückblickend, aber auch ausblickend, würde es mir mittlerweile wahrscheinlich fast unorganisch vorkommen, in weiteren Projekten anders vorzugehen und den alten Wasserfall wieder rauszukramen.

Und nebenbei: die „processes“ im agilen Manifest beziehen sich weniger auf die Fachprozesse eines Unternehmens als auf das Vorgehensmodell bei der Produktentwicklung – Schwein gehabt

Die OMG, bekannt für Industriestandards wie UML und CORBA, ist ebenfalls Schöpfer der “Business Process Model and Notation”, BPMN, die sich zunehmender Beliebtheit erfreut. Und im Zeichen eben dieser BPMN sollte der OMG Infoday 2011 stehen.

Begrüßung und Keynote

Jakob Freund, Autor des “Praxishandbuch BPMN 2.0″, eröffnete die Konferenz mit einer Begrüßung und dem Statement, BPMN habe inzwischen die Hype-Phase und das darauffolgende Tal der Ernüchterung hinter sich gelassen und einen gewissen Reifegrad erreicht, was sich in gesundem, aber nicht überproportionalem Wachstum widerspiegele. So erfreute sich BPMN, nach Umfragen in der bpm-netzwerk.de-Community, in den Jahren 2009 bis 2011 eines 41%-igen Wachstums in Bezug auf Praxiserfahrung der Community-Mitglieder. Zum Vergleich: Im selben Zeitraum wuchs das Interesse an UML und an EPK jeweils nur um 27%. Grund genug also, den OMG Infoday 2011 in das Zeichen des Business Process Managements zu stellen.

Die Keynote wurde von Andrew Watson gehalten, dem Vice President und Technical Director der OMG. Nach einigen Daten und Fakten über die OMG selbst und deren Tätigkeitsfelder, ging Andrew im Detail auf die BPMN ein und schilderte die Tätigkeiten der OMG auf diesem Gebiet. Zu guter Letzt gab es noch einen Ausblick auf zukünftig zu erwartende Standards der OMG. Dieser fiel für meinen Geschmack leider etwas kurz und oberflächlich aus, zumal auf der Agenda der OMG durchaus spannende Themen stehen, wie etwa Case Management, der Modellierung von sich nicht wiederholenden Ad-hoc-Tätigkeiten, die sich nicht in Prozessmodelle gießen lassen.

BPM(N) in der Praxis

Aber keine Zeit, dem nachzutrauern, es folgten schnell die ersten Vorträge von Unternehmen, die ihre Erfahrungen bei der Einführung und Anwendung von BPM schilderten. Themen waren die BPM-Initiative bei der 1&1 Internet AG, die das Modellieren der Prozesse allen Mitarbeitern freigegeben haben. Ein Team von internen Trainern schult die Mitarbeiter bei Interesse in BPMN. Spannend zu hören, dass dieser Weg erfolgreich ist, und bei allen ein hohes Verständnis für die Prozesse schafft. Bei ATLAS, dem automatisierten Aufuhrverfahren des deutschen Zolls, gibt es Dutzende Varianten alleine des “Happy-Paths”. Zuletzt wurde das Zusammenspiel von BPMN und UML unter agilen Bedingungen, bei denen auch noch User Stories eine Rolle spielen, thematisiert und aufgezeigt, wie Prozessmodelle und UML-Diagramme zur Ergänzung von User-Stories beim Requirements-Engineering zum Einsatz kommen können.

Es war sehr interessant zu sehen, mit welchen Problemen und Herausforderungen Unternehmen bei Umsetzung ihrer BPM-Initiativen zu kämpfen haben und wie sie diesen begegnen.

Thinktank

Nach der Mittagspause stand dann der BPM-Thinktank auf dem Programm. Es entstand eine offene Diskussion darüber, was der BPMN-Standard leisten sollte (und es bisher nicht tut) und wo heute Schwachstellen sind. Als Beispiel hierfür wurde die Definition von Metadaten genannt, die in zukünftigen Versionen des Standards verbessert werden könnte, um Simulation schon in der Spezifikation besser zu unterstützen. Andere Schwächen erkannte das Plenum bei der Verknüpfung von BPMN-Modellen mit anderen Repositories, wie zum Beispiel dem Service-Repository einer SOA. Die Anregungen wurden von Jakob Freund von camunda, die als “influencing member” der OMG direkten Einfluss auf die Entwicklung des Standards hat, mit großem Interesse aufgenommen.

OCEB-Zertifizierung

Als letzten Programmpunkt stellte Matthias Schrepfer die OCEB-Zertifizierung der OMG vor. Dahinter verbirgt sich eine mehrstufige Zertifizierungsreihe bis zum “OMG Certified Expert in Business Process Management – advanced (IT oder Business)”. OCEB ist die einzige von der OMG zertifizierte Weiterbildungsmaßnahme im BPM-Umfeld, und sie ist weltweit anerkannt. Mehr zu der OCEB-Zertifizierung gibt es bei der OMG.

Fazit

Zusammenfassend war der OMG Infoday 2011 ein sehr interessanter und abwechslungsreicher Tag mit anschaulichen Vortägen aus der BPM-Praxis. Einzig von der OMG hätte ich bei dieser Konferenz in Hinblick auf aktuelle und zukünftige Tätigkeiten etwas mehr Tiefe erwartet – aber dann hätte ein Tag vermutlich auch nicht ausgereicht. Insofern war der BPM Infoday 2011 ein gelungener Tag für alle, die sich im BPM-Umfeld tummeln und dabei mit BPMN zu tun haben und ein schönes Forum, um Erfahrungen auszutauschen und andere Sichtweisen kennenzulernen.

Wiederverwendung bei SOA: Erfolgsfaktoren und Best Practices

Bei der Einführung von Serviceorientierten Architekturen (SOAs) ist Wiederverwendung nur eines von vielen Zielen, die miteinander um Priorität konkurrieren. Wiederverwendung erreicht man also keinesfalls allein durch die Wahl einer entsprechenden technischen Plattform, sondern nur in Verbindung mit vielen Entscheidungen auf organisatorischer Ebene.

Die aus unseren Erfahrungen wichtigsten Vorgehensweisen und Erfolgsfaktoren, die bei der Erreichung einer hohen Wiederverwendung innerhalb einer SOA kritisch oder hilfreich sind, beschreiben wir in unserer Titelstory “Wiederverwendung bei SOA: Erfolgsfaktoren und Best Practices” in der aktuellen Ausgabe des OBJEKTspektrum.

Die gute Nachricht ist, dass dies nicht grundsätzlich darauf zurückzuführen ist, dass der Ansatz BPM/SOA nicht trägt oder dass bei der Prozess- und Servicegestaltung eklatant „danebengelegen wird“. Aber was ist es dann, was zum letztlichen Kick fehlt, wenn doch die fachliche Schneidung von Prozessen und Services sinnvoll ist und auch die technische Umsetzung den Regeln der Kunst folgt?

Align auf weiter Flur

Meiner Meinung nach ist die wichtigste Erkenntnis, dass ein sauberer Serviceschnitt, getrieben von fachlicher Abhängigkeit und Kohäsion, sowie eine für das Unternehmen maßvolle Prozessorientierung zwar zwei enorm wichtige Schritte in Richtung auf Business-IT-Alignment sind, aber organisatorische und sogar kulturelle Dinge eine mindestens ebenso große Rolle spielen.

Zusammenarbeit

Die Fachbereiche und die IT müssen zumindest an den entscheidenden Stellen die gleiche Sprache sprechen, und sie müssen dies auf Augenhöhe tun. Ein Fachbereich, der nur halbausgegorene Konzepte über den Zaun wirft und danach in bester Nach-mir-die-Sintflut-Manier den Rückzug probt, sitzt nicht mit der IT im gleichen Projektboot. Genauso wenig tut dies die IT, die für sich selbst die fachliche Gestaltung in Anspruch nimmt und die Fachbereiche nicht im gebotenen Maße einbindet und in die Verantwortung nimmt. IT-Projekte, die einen fachlichen Mehrwert bieten sollen, sind eine Gemeinschaftsleistung von Fachbereich und IT, und dabei ist eine Zusammenarbeit „Hand in Hand“ nun mal der Schlüssel zum Erfolg. Was wir also brauchen, sind interdisziplinäre, gleichberechtigte Teams, die über den gesamten Projektverlauf optimalerweise in räumlicher Nähe zusammenarbeiten.

Die gemeinsame Sprache

Der Fachbereich wird nicht aus dem Stand exakte Modelle (BPMN oder UML) erzeugen oder auf den Punkt formulierte, lückenlose und widerspruchsfreie Konzepte liefern. Hier kann aber die IT den Anschub geben und helfend zur Seite stehen. Wir verwenden in unseren Projekten gern ein speziell entwickeltes Use-Case-Template, das der Fachbereich anstelle von Prosabeschreibungen nutzt, um seine Anforderungen zu definieren. Es beinhaltet neben einer strukturierten Ablaufbeschreibung auch Abschnitte zu weiteren Aspekten, die in der Prozess- und Serviceorientierung eine Rolle spielen: Verantwortlichkeit des Prozesses bzw. Services, Vorbedingungen, Nachbedingungen, etc. Häufig sind es genau diese Dinge, die zwar anfänglich Schwierigkeiten in der Benennung beim Fachbereich bereiten, aber letztlich sind auch genau diese Fragestellungen gemeinsam mit anschaulichen Modellen der Schlüssel dazu, einen Prozess oder Service als fachlich getriebene Einheit, also etwas Plastisches zum Anfassen und nicht nur als abstraktes Stück Software, zu verstehen.

Parallel zur Use-Case-Beschreibung entstehen die ersten, fachlichen Modelle in BPMN und UML. Entscheidend ist, dass die Modelle die Fachlichkeit sauber und für ALLE Beteiligten verständlich herausarbeiten und darstellen. Sie dienen während der Konzeption als Diskussionsgrundlage und werden in der Folge immer weiter verfeinert und um technische Aspekte angereichert. Letztlich beschreiben sie sehr strukturiert die zu entstehenden Prozesse, Services und Geschäftsobjekte.

Entwicklungsprozess

Die fachliche Konzeption und Beschreibung ist aber nur ein Teil in der Kette von der „Vision“ oder dem „Big Picture“ zum laufenden System. In unseren Projekten bettet sich dieser in einen integrierten Entwicklungsprozess ein. Integriert? Ein Schlüsselaspekt des Entwicklungsvorgehens ist, dass der Fachbereich und die IT über sehr weite Strecken gemeinsam arbeiten.

Wie weiter oben erwähnt, ist gerade zu Beginn einer BPM/SOA-Initiative Unterstützung des Fachbereichs bei der prozess- und serviceorientierten Konzeption durch IT gefragt. Der Unterstützungsbedarf nimmt allerdings mit der Zeit ab. Dennoch ist es sinnvoll, die fachliche Konzeption durch die IT begleiten zu lassen, um den Übergang von der fachlichen in die technische Konzeption mit ihren Hürden und Rückkopplung möglichst fließend zu gestalten. Im Optimalfall können Optimierungspotenziale oder technische Restriktionen, die sich tatsächlich auch auf fachlicher Ebene auswirken können, schon sehr früh im Entwicklungsprozess berücksichtigt und direkt gemeinsam eine Alternative erarbeitet werden.

Das Konzept ist also fertig und es beginnt die Entwicklung. Spätestens jetzt kann der Fachbereich aber wirklich nicht mehr unterstützen, oder? So ideal ist die Welt in der Praxis leider nicht. Wie oft gibt es Verständnisfragen oder doch erst während der Entwicklung festgestellte Lücken oder Hindernisse? Machen wir uns nichts vor: wir brauchen auch hier den ständigen Dialog zwischen IT und Fachbereich oder zumindest kurze, direkte Kommunikations- und Entscheidungswege.

Wir können diese Kette nun fortführen bis hin zu automatisierten Abnahmetests, aber die Argumentation bleibt dieselbe: es bleibt der Bedarf, dass IT und Fachbereich ständig und auf Augenhöhe miteinander reden und arbeiten.

Fazit

Software-Artefakte allein – seien sie noch so toll fachlich gestaltet und technisch programmiert – sind kein Business-IT-Alignment, allenfalls Teil der Grundlage dafür. Business-IT-Alignment findet erst statt, wenn es in der Praxis im Lebenszyklus von Prozessen und Services in der täglichen Zusammenarbeit Berücksichtigung findet.

Das soll niemanden abschrecken, im Gegenteil: ich bin immer wieder positiv überrascht, wie schnell bei Fachbereichen das Verständnis von Prozess- und Serviceorientierung reifen kann und wie sehr sich dies auf die Qualität von Konzepten und die Entwicklungsgeschwindigkeit auswirkt.