Transparenz und Beschleunigung

So klappt BPM in der Praxis

21.04.2011
Von 
Daniela Hoffmann ist freie IT-Fachjournalistin in Berlin.

HanseMerkur

HanseMerkur-Zentrale: Mit BPM-Tools das schnelle Wachstum auffangen.
HanseMerkur-Zentrale: Mit BPM-Tools das schnelle Wachstum auffangen.
Foto: Joachim Hackmann

Beim Versicherungsunternehmen HanseMerkur ist über die Jahre in den verschiedenen Sparten eine komplexe Systemlandschaft mit einem Host-basierenden Krankenleistungssystem gewachsen, die das Unternehmen mit Hilfe von BPM gründlich konsolidieren will. "Die Prozesse in den verschiedenen Bereichen sind sehr heterogen abgebildet, Synergiepotenziale werden nicht genutzt. Unser Ziel war es, Prozesse schneller zu durchblicken und einfacher zu optimieren. Dafür sollte eine einheitliche Plattform geschaffen werden, auch um den Wartungsaufwand möglichst gering zu halten", schildert Horst Karaschewski, Leiter Anwendungsentwicklung, das Vorhaben.

2008 machte sich die IT-Abteilung, die rund 1000 Mitarbeiter betreut, an die Arbeit und baute für einen Beispielprozess einen BPM-Stack auf. Grundlage bildete eine Service-orientierte Architektur auf Basis der Open-Source-Software jBoss. Hinzu kam eine Process Engine. Für die Auswahl entwickelte HanseMerkur ein Proof of Concept und ließ sich anhand einer konkreten Aufgabenstellung die Performance der Systeme inubit, jBPM, Cordys, PegaSystems und Intalio zeigen. Die Wahl fiel auf den Berliner Hersteller inubit. Als weitere Teile der BPM-Architektur kamen Visual Rules von Innovations als Regel-Engine und das quelloffene Riena-Framework auf Basis von Eclipse RPC für die Oberflächenentwicklung hinzu, da es sich nicht um eine reine Web-Anwendung handelte.

Horst Karaschewski, Leiter Anwendungsentwicklung bei HanseMerkur: "Die enge Zusammenarbeit zwischen IT und Fachbereichen ist erfolgsentscheidend."
Horst Karaschewski, Leiter Anwendungsentwicklung bei HanseMerkur: "Die enge Zusammenarbeit zwischen IT und Fachbereichen ist erfolgsentscheidend."
Foto: Joachim Hackmann

"Es ging uns um flexiblere Prozesse, ein hohes Maß an Automatisierung und letztlich darum, das starke Wachstum im Krankenversicherungsbereich aufzufangen", erinnert sich Karaschewski. Der gewählte Beispielprozess für die BPM-Einführung bestand darin, Unterlagen im Zahnzusatzleistungs-Bereich automatisiert zu prüfen und den damit verbundenen manuellen Aufwand zu reduzieren. Die seit 2005 angebotene Zusatzversicherung wurde mit einer Kostendeckelung für die ersten fünf Jahre vertrieben. Daher musste sich HanseMerkur darauf einstellen, dass die Kunden ab 2010 deutlich mehr Versicherungsleistungen in Anspruch nehmen würden.

Mit dem neuen Prozess wollten die Verantwortlichen den erheblichen Mehraufwand abfangen und zugleich die Anwender entlasten. In enger Zusammenarbeit mit den Fachbereichen startete die IT ein agiles Softwareentwicklungsprojekt nach Scrum und konnte die Arbeiten im Herbst 2009 fristgerecht fertigstellen. Seit Ende letzten Jahres läuft der Prozess produktiv, zunächst mit einer Automatisierungsquote von 15 Prozent. "Wir tunen den Prozess weiter und rechnen mit einer Automatisierung von rund 30 Prozent bis Ende 2010", so der IT-Entwicklungsleiter.

Die Fachbereiche modellieren die Prozesse mit der Spezifikationssprache BPMN. Unterstützung kommt von einem externen Berater und einem BPM-Architekten aus der eigenen IT. "Die enge Zusammenarbeit zwischen IT und Fachbereichen ist erfolgsentscheidend, deshalb sitzen sie auch zusammen", erläutert Karaschewski die Arbeitsweise. Die Idee, BPMN-Modelle direkt in Software umzusetzen, hält er trotz der Versprechungen vieler Anbieter für unrealistisch, sobald es sich um etwas komplexere Prozesse handelt. "Der Informationsgehalt muss auf der technischen Ebene weitaus höher sein als auf der Geschäftsebene. Schon deshalb ist eine zweite, technische Modellierung notwendig", so Karaschewski.

Im nächsten Schritt sollen ähnlich funktionierende Prozesse aus anderen Bereichen in die BPM-Plattform einbezogen werden. Der neue Ansatz soll auch helfen, die häufigen Änderungen durch den Gesetzgeber leichter umzusetzen, schon weil sich der Testaufwand nach Softwareänderungen erheblich verringert. Die Risiken des Projekts schildert Karaschewski folgendermaßen: "Bei einem solchen Konzept ist ein systematisches Vorgehen sehr wichtig, denn mehr Komponenten bergen auch mehr Komplexität. Auch die Mitarbeiter müssen entsprechend eingebunden werden: Durch die neuen Abläufe und Vorgehensweisen ändern sich Prozesse und damit Aufgaben oft gravierend, das erzeugt natürlich Ängste. Hier ist eine klare und frühzeitige Kommunikation entscheidend, bei der vor allem auch die neuen Möglichkeiten aufgezeigt werden".