Werden in einem Versicherungsunternehmen Geschäftsprozesse geändert, so erfordert dies durch die digitale Natur des Versicherungsgeschäfts in der Regel immer Anpassungen an der IT-Anwendungslandschaft des Unternehmens. Weil der Großteil der Versicherungswirtschaft auf eigenentwickelte Systeme setzt und diese oft in Eigenregie weiterentwickelt, sind zumindest theoretisch beliebige Anpassungen an den Systemen möglich, um Veränderungen in den Geschäftsprozessen umzusetzen. In der Praxis sehen sich die Unternehmen jedoch mit komplexen Anwendungslandschaften konfrontiert, die über Jahre gewachsen sind und durch ihre Querabhängigkeiten aufwändig anzupassen sind. Um diese Komplexität zu beherrschen und somit Auswirkungen von Geschäftsprozessänderungen nachvollziehen zu können, bietet sich die grafische Darstellung von Übersichten der Prozess- und Anwendungslandschaften in Form von Bebauungsplänen an. Ausgehend von diesen Plänen werden beim Process-Based Application Scoping (auf Deutsch: Definition des Anwendungsumfangs auf Basis von Prozessen) vertiefende Analysen durchgeführt, um schließlich entstehende IT-Kosten dem erwarteten Businessnutzen zuordnen zu können.
Bebauungspläne sorgen
für Übersicht
Die Erstellung von Bebauungsplänen ist ein mittlerweile etablierter Ansatz. Diese Pläne stellen intuitiv sowohl für Fachbereich als auch IT verständlich dar, welche Prozesse durch welche Anwendungen unterstützt werden. Unterschiedliche Darstellungsformen lassen die detailliertere Betrachtung von Ausschnitten (zum Beispiel alle Prozesse im Bereich Vertrieb) oder auch das Clustern von Informationen (beispielsweise nach Fachdomänen oder Geschäftsbereichen) zu.
Voraussetzung für die Erstellung solcher Pläne ist ein integriertes Modell der Geschäftsprozesse und Informationssysteme im Versicherungsunternehmen. Dabei werden alle relevanten Elemente in einer Datenbasis erfasst. Sofern wie beim Process-Based Application Scoping eine Toolunterstützung vorliegt, können die gewünschten Übersichten einfach und mit wenig Aufwand erzeugt und angepasst werden. Ohne Toolunterstützung gerät die Erstellung von Bebauungsplänen zu einem zeitfressenden Unterfangen, das oftmals aufgegeben wird, wenn die einmal erstellten Diagramme auch noch kontinuierlich gepflegt werden müssen.
Zeitdimension und Analysen
Erweitert man das integrierte Modell der Geschäftsprozesse und Informationssysteme noch um eine Zeitdimension in Form von Projekten, so können in das Modell auch Veränderungen in den Bebauungsplänen (etwa Unterstützung eines Geschäftsprozesses durch ein neues System) erfasst werden. So lässt sich wie in einem Film darstellen, wie einzelne Projekte den Bebauungsplan verändern.
Zuschnitt von Anwendungen
Das Process-Based Application Scoping geht über die bekannten Ansätze im Bereich Bebauungsmanagement hinaus und unterstützt die Bewertung der Kosten-Nutzen-Relation von IT-Projekten. Dazu werden an denjenigen Stellen im Modell (Geschäftsprozesse, Systeme), an denen Veränderungen geplant sind, detailliertere Informationen erhoben.
Solche Details sind auf Prozessseite einzelne Prozessschritte oder Subprozesse, zum Beispiel für automatische oder manuelle Bearbeitung. Auf Systemseite werden die in den Prozessschritten verwendeten Systemfunktionen detaillierter betrachtet. Die Prozessdaten werden nun mit Erfahrungswerten verfeinert. So erfasst man beispielsweise im Modell, dass in der Antragsbearbeitung 80 Prozent der Anträge den Subprozess „automatische Verarbeitung“ durchlaufen, die restlichen 20 Prozent den Subprozess „manuelle Nachbearbeitung“. Fügt man nun die ungefähren mittleren Kosten für einen Durchlauf der manuellen Nachbearbeitung sowie die Anzahl der Anträge pro Jahr hinzu, lassen sich erste Optimierungspotenziale ermitteln.
Für das weitere Vorgehen ist nun der Fachverstand von Experten notwendig: Welche IT-Unterstützung ist nötig, um den Automatisierungsgrad von derzeit 80 Prozent zu erhöhen? Welche neuen beziehungsweise geänderten IT-Funktionen sind dazu notwendig? Haben Experten hierzu Ideen gesammelt, kann das Modell um Projekte erweitert werden, die die erforderlichen Funktionen in den IT-Systemen sowie die entstehenden Projektkosten beinhalten. Bei diesen Änderungen am Zuschnitt von Anwendungen lassen sich auch Alternativen erfassen. Es kann ja sein, dass dieselbe Unterstützung durch unterschiedliche Systeme realisiert werden kann zu unterschiedlichen Kosten und mit unterschiedlichen Vor- beziehungsweise Nachteilen verbunden. Analog zu den systemseitigen Auswirkungen der Veränderungen wird bei den Prozessmodellen für die Projekte dann vermerkt, welche Verbesserungen sich ergeben (beispielsweise: Automatisierungsgrad steigt von 80 Prozent auf 85 Prozent). Unterstützt werden diese Modellerweiterungen ganz praktisch durch Checklisten und Templates.
Durch dieses Vorgehen lässt sich darstellen, welcher Nutzen auf der Businessseite entsteht, wenn durch Anpassungen an den Informationssystemen bestimmte Veränderungen an den Prozessen möglich werden, und welche IT-Kosten dadurch entstehen. Durch die saubere Darstellung sind die Veränderungen sofort für alle Beteiligten in Fachbereich und IT nachvollziehbar. Durch das integrierte Modell erfolgt die Betrachtung zudem nicht losgelöst vom Rest der Prozess- und Anwendungslandschaft. Das bedeutet, eventuell vorhandene Querabhängigkeiten zu anderen Prozessen oder Systemen werden unmittelbar offensichtlich und somit für alle Beteiligten transparent. Das verhindert Nachfragen der Art „warum ist diese kleine Änderung denn so teuer?“ beziehungsweise macht die Antwort auf solche Fragen leichter.
Und weil Softwarekosten nicht nur transparent gemacht werden, sondern auch ganz konkreten Verbesserungen in den Geschäftsprozessen zugeordnet werden, lässt sich über die Angemessenheit der Projekte und damit über Softwarekosten diskutieren.
Für das Risikomanagement ist es ebenfalls nützlich, dass die für gewünschte Prozessänderungen notwendigen Applikationsänderungen nachvollziehbar sind. So wird früh deutlich, welche kritischen Systeme von den Umgestaltungen betroffen sind und welche Qualitätssicherungsmaßnahmen (im weitesten Sinne) daher vorgesehen werden müssen. Und so wird beispielsweise wiederum für alle Beteiligten deutlich, dass eine Verbesserung an einem unkritischen Prozess Anpassungen an mehreren hochkritischen Systemen nach sich zieht und daher mit erhöhten Aufwänden einhergeht.
Durch die Analyse- und Planungsschritte im Process-Based Application Scoping nähert man sich so (wie in der Grafik dargestellt) ausgehend vom Iststand der IT-Bebauung dem Sollstand quasi als Zielfoto. Leitplanken in diesem Veränderungsprozess sind die Geschäftsanforderungen und die strategischen Rahmenbedingungen, die in die Bewertung der Projektalternativen einfließen.
Den Aufwand im Auge
Ein häufiger Kritikpunkt ähnlicher Verfahren ist, dass sie zu viel Aufwand bei zu wenig Nutzen verursachen. Gerade für mittlere und kleine Unternehmen lohnt sich nach Meinung vieler Anwender die umfängliche Modellierung von Prozessen und Systemen nicht. Das Process-Based Application Scoping als ein Element des No-Frills Software Engineering (Softwareentwicklung ohne Schnickschnack) macht hierbei einen Unterschied. Es ist eben nicht notwendig, die komplette Prozess- und Systemlandschaft zu erfassen, bevor erste Auswertungen möglich sind. Eine schlanke Befüllung des Modells mit den wichtigsten Systemen und Prozessen reicht für den Einstieg aus. Soll einer konkreten Fragestellung nachgegangen werden, sind nur an den betroffenen Stellen gezielt Details hinzuzufügen. Das Gesamtmodell sorgt als große Klammer für den Zusammenhalt des Modells insgesamt.
Autoren: Prof. Dr. Volker Gruhn, Professur für Angewandte
Telematik/E-Business, Universität Leipzig; Clemens Schäfer, it factum, Garching bei München