Make or buy? So finden Versicherer die Antwort auf den Modernisierungsdruck

Finanzdienstleister sind längst digitale Unternehmen und stehen unter hohem Modernisierungsdruck. Ohne den Einsatz von Software, IT und weitgehend digitalisierten Prozessen ist das Geschäftsmodell schon lange nicht mehr kosteneffizient abbildbar. Vielmehr ist die IT zu einem zentralen Wertschöpfungsfaktor geworden. Versicherer haben deshalb schon frühzeitig begonnen, Teile des Geschäfts zum Beispiel auf Großrechnersystemen abzubilden. Aber wie weiter: Make or buy?

von Tobias Florian, Wirtschaftsinformatiker der adesso insurance solutions

In den letzten Jahren ist aber ein Modernisierungsdruck entstanden, weil die eigenentwickelten Systeme „in die Jahre gekommen sind“:

• Mitarbeiter, die die Großrechnersysteme betreuen, erreichen oft das Rentenalter und Nachwuchs ist schwer zu bekommen.
• Die Systeme sind bereits lange im Betrieb und auch auf Grund technischer Rahmenbedingungen nur noch schwer wartbar oder erweiterbar. Somit sind neue Anforderungen, egal ob gesetzliche oder individuelle, nur schwer umsetzbar.
• Dezentrale Systeme sind oft betriebswirtschaftlich günstiger zu betreiben.
• Die Integration in die Umsysteme wird immer schwieriger und kostenintensiver. Unter Umständen müssen Daten dupliziert werden, um 24/7 eine Auskunft zum Beispiel in einem Kundenportal bereitstellen zu können, oder eine gewünschte Automatisierung erfordert den Einsatz zusätzlicher (Brücken-)Technologie wie zum Beispiel Robotic Process Automation (RPA).

Risikominimierung bei der Modernisierung der Legacy-IT

Die Ablösung der Legacy-Systeme und die Überführung in eine moderne Infrastruktur ist oft ein risikoreicher Prozess, der auch mit hohen Investitionen verbunden ist. Um Risiken zu minimieren, stellen sich Versicherungsunternehmen die Frage, ob und in welchem Umfang der Einsatz von Standardsoftware in Frage kommt. Mittlerweile bieten mehrere Hersteller für alle Sparten und Bereiche in einem Versicherungsunternehmen Standardsoftware an.

Je nach Anbieter werden „nur“ einzelne Bereiche bis hin zur Abbildung sämtlicher Prozesse in einem Versicherungsunternehmen aus einer Hand angeboten.”

Die Entscheidung für oder gegen den Einsatz von Standardsoftware ist eine strategische. Sie wird das Unternehmen auf Jahre hinaus prägen und dies gilt insbesondere dann, wenn es um Kernsysteme wie die Bestandsführung oder die Leistungs-/Schadenbearbeitung geht.

Make or buy? Wie kann ich als Verantwortlicher eine Entscheidung herbeiführen?

Die Frage „Make or buy?“ ist zentral für die weitere Ausrichtung der IT-Organisation einer Versicherung. Um die eine Antwort zu finden, können folgende Fragestellungen bei der Entscheidungsfindung helfen.

• Ist das technische Know-how auch zukünftig im eigenen Haus vorhanden?

Die Versicherer haben umfangreiches fachliches Know-how und entwickeln dieses auch immer weiter. Das technische Know-how bezieht sich aber oft auf die bestehende Mainframe-Architektur und die oft komplexen Zusammenhänge der darauf betriebenen Software. Diese wurde inhouse vom eigenen Team entworfen und weiterentwickelt, wohingegen moderne objektorientierte Architekturen manchmal noch Neuland sind oder zumindest noch nicht bei der kompletten Neuentwicklung von Kernsystemen eingesetzt wurden. Hier gilt es abzuwägen, wieviel Erfahrung im Unternehmen mit diesen modernen Technologien vorherrscht.

Anbieter von Standardsoftware bieten oft eigene Schulungsprogramme für Fachspezialisten und IT-Mitarbeiter an. Damit wird das notwendige Wissen zur Konfiguration strukturiert und mit Übungen auf die Mitarbeiter übertragen. Einige Anbieter stellen auch Zertifikate für die Teilnahme an Schulungen oder für bestandene Prüfungen aus. So kann auch geprüftes Wissen am Arbeitsmarkt eingekauft werden.

• Wie hoch ist das Risiko eines Fehlschlags?

Der Austausch eines Kernsystems stellt einen erheblichen Eingriff in das Unternehmen dar. Vergleichbar mit einer Herztransplantation wird das bestehende entnommen und im Gegenzug ein neues Kernsystem eingesetzt. Misslingt ein derartiges Großprojekt oder treten erhebliche Probleme auf, gefährdet das im schlimmsten Fall die wirtschaftliche Zukunft dieses Unternehmens erheblich. Ziel muss es also sein, dieses Risiko zu reduzieren. Eine Eigenentwicklung lässt sich zum Beispiel gut inkrementell oder gar agil umsetzen. Problematisch kann es dann werden, wenn zu einem späten Zeitpunkt in der Implementierung grundlegende Änderungen notwendig werden, weil wichtige Anforderungen sonst nicht oder nur unzureichend umgesetzt werden können.

Standardsoftware bietet den Vorteil, dass andere Unternehmen die Software bereits verwenden und der prinzipielle Einsatz somit möglich ist und auch bewiesen wurde. Damit wird das Risiko eines Fehlschlags deutlich reduziert. Zu prüfen ist aber, ob und in welchem Umfang die Standardsoftware an die eigenen Belange angepasst werden kann oder muss. Unter Umständen werden Versicherungsprodukte angeboten, welche die Standardsoftware gar nicht oder nur schwer abbilden kann. Dafür bietet es sich an, im Vorfeld detailliert mit dem Anbieter über die Leistungsfähigkeit der jeweiligen Standardsoftware zu sprechen. Die Anbieter haben meist Erfahrung in der Erarbeitung solcher „Deltas“ und bieten entsprechende Workshops an. Im Ergebnis kann sehr granular entschieden werden, welche Individualisierungen notwendig sind und ob sich diese wirtschaftlich rechnen.

• Welcher Grad an Flexibilität wird benötigt?

Eine Eigenentwicklung birgt die Gefahr, sich ausschließlich auf die aktuellen Anforderungen zu konzentrieren. Flexibilität in Software vorzudenken, zu implementieren und zu testen, kostet Zeit und Geld und lässt sich meist nur schwer in einem Projekt vertreten, wenn es keine konkrete Anforderung dazu gibt. Bei der Entscheidung zwischen “Make or buy” für “Make”, droht darüber hinaus eine „Über-Flexibilisierung“ (also das Vordenken von Flexibilität, die niemals notwendig wird), was im Anschluss die Wartbarkeit verringert.

Anbieter von Standardsoftware müssen, um selbst wirtschaftlich erfolgreich zu sein, ihr Produkt so gestalten, dass es möglichst flexibel einsetzbar ist und viele mögliche Anforderungen durch Konfigurationsänderungen abdeckt. Somit ist eine Standardsoftware eher in der Lage, auf neue Anforderungen zu reagieren. Die Anpassungen können dann an vordefinierten Erweiterungspunkten vorgenommen werden und sind so auch Release-sicher umsetzbar.

• Welche individuellen Anforderungen müssen abgedeckt werden?

Eine Individualentwicklung bietet den Vorteil, dass alle Funktionen passgenau auf die eigenen Erfordernisse abgestimmt sind. Alle spezifischen Anforderungen werden genauso abgebildet, wie der jeweilige Fachbereich das wünscht.

Standardsoftware bringt bereits vordefinierte Prozesse und Masken mit, die der Kunde einsetzen kann.”

Gegebenenfalls sind die Prozesse individualisierbar, indem im Einführungsprojekt zum Beispiel eigene Oberflächen entwickelt werden und der Standard gegen diese Oberflächen ausgetauscht wird. Dabei sollte bedacht werden: Stellt der Anbieter seine Software um, muss die Versicherung gleichzeitig die eigenen Oberflächen anpassen. Das kann dann mit erheblichem Aufwand verbunden sein. Besser ist es, wenn der Software-Anbieter Erweiterungspunkte in der Software vorgesehen hat, mit denen eine Release-sichere Erweiterung des Standards möglich ist. Die Maskenfolge bleibt dann zwar vielleicht vom Anbieter vorgegeben, im Gegenzug sind die Wartungsaufwände planbarer und geringer.

• Wie gut lässt sich eine Standardsoftware in die bestehende Systemlandschaft integrieren?

Standardsoftware bietet üblicherweise eine Vielzahl von vordefinierten Schnittstellen in die üblichen Umsysteme. Diese enthalten im Idealfall bereits die üblichen Attribute und müssen dann nur noch vereinzelt angepasst werden. Anbieter, die mehrere Produkte anbieten, gewährleisten selbst, dass diese optimal untereinander kommunizieren (z. B. ein Partnersystem, ein Bestandsführungssystem und ein Leistungssystem). Auf diese Weise können weitere Synergieeffekte gehoben werden.

• Inwieweit besteht eine Abhängigkeit vom Anbieter?

Eine Individualentwicklung hat den Vorteil, dass das tiefste Know-how für das neue System im Haus ist und bleibt. Die eigenen Mitarbeiter haben das System vollständig entwickelt und kennen daher auch alle Möglichkeiten des Systems am besten. Bei komplexen, zeitlich knappen Anforderungen (Einführung eines ganz neuartigen Produktes, Umsetzung einer neuen gesetzlichen Anforderung) muss man dies aber mit dem bestehenden Team abbilden, da Externe nicht über ausreichende Kenntnisse zur Individualsoftware verfügen.

Je nach Anbieter, Betriebsmodell und Art der Anforderung kann es bei der Standardsoftware der Fall sein, dass nur der Anbieter Änderungen an der Software vornehmen kann.”

Damit entstehen dann bei neuen Anforderungen zusätzliche Kosten und für die Umsetzung muss der Anbieter diese Ressourcen auch bereitstellen können. Das Know-how für die Anpassung der Software befindet sich nicht im eigenen Haus.

Andere Anbieter lösen das flexibler. So kann die Versicherung mit eigenem Personal prinzipiell selbst alle Änderung vornehmen und die Software erweitern. Das Know-how dafür wird im Rahmen des Einführungsprojektes oder durch das Schulungsprogramm des Software-Anbieters aufgebaut. Bei komplexen oder sehr aufwändigen Anforderungen kann der Anbieter darüber hinaus mit Experten unterstützen, die bereits tiefe Kenntnisse vom System mitbringen. Das hat den Vorteil, dass damit Ressourcenengpässe überwunden werden können, falls diese auftreten sollten.

• Welches Betriebsmodell soll genutzt werden?

Eine Individualentwicklung wird üblicherweise selbst betrieben. Nur im eigenen Haus ist das notwendige Know-how für den Betrieb vorhanden.

Standardsoftware bietet da oft mehr Möglichkeiten. Die Anbieter können die Software mit unterschiedlichen Modellen bereitstellen: zwischen einer „klassischen“ On-Premise-Installation und einer umfassenden SaaS-Lösung ist fast alles möglich. Auch eine Änderung des Betriebsmodells ist mit Standardsoftware einfacher möglich: die Anbieter ermöglichen oft den Wechsel von SaaS zu einer On-Premise-Lösung oder umgekehrt.

• Welche Ressourcen sind nötig und welche Kosten entstehen?

Die Eigenentwicklung eines neuen Kernsystems kann sehr hohe Kosten verursachen. Neben der Entwicklung des neuen Systems müssen auch die Integration in die Systemlandschaft und die Datenmigration aus dem Legacy-System umgesetzt werden. Die Entwicklungsdauer sollte möglichst klein gehalten werden, um störende Einflüsse (z. B. durch gesetzliche Änderungen) zu reduzieren. Daher ist für die Projektlaufzeit mit erhöhtem Personalbedarf zu rechnen. Dies kann zum Beispiel durch den Einsatz von Freelancern erreicht werden. Nach Abschluss des Projektes muss die Software durch das eigene Team komplett gewartet werden: Umsetzung neuer Anforderungen, gesetzlicher Änderungen, laufende Modernisierung des Technologiestacks etc.

Dafür müssen entsprechende Ressourcen in der Linie aufgebaut und bereitgehalten werden.”

Standardsoftware enthält im Wesentlichen die notwendige Funktionalität bereits und muss „nur“ eingerichtet werden. Je nach Lizenzierungsmodell wird die Software durch den Anbieter technologisch weiterentwickelt und gesetzliche Änderungen umgesetzt. Dies entlastet dann das eigene Team und gibt eine gewisse Planungssicherheit. Bei einer On-Premise-Installation wird üblicherweise eine entsprechende Lizenz erworben. Mit Abschluss eines zusätzlichen Wartungsvertrags erhält man regelmäßig Updates der Software, die dann in die eigene Systemlandschaft übernommen werden müssen. Darüber hinaus bringen die Anbieter oft auch Erfahrungen, „Best Practices“ sowie vordefinierte Schnittstellen für eine Datenmigration mit. Somit wird auch dieser komplexen Aufgabe in einem Projekt risikominimierend begegnet.

Make or buy? Kostenreduktionspotenziale und Modernisierung

Zusammenfassend lässt sich sagen, dass Standardsoftware mittlerweile in allen Bereichen einer Versicherung eine echte Alternative ist, die IT- und Projektverantwortliche ernsthaft in Betracht ziehen sollten, wenn es darum geht, Kernsysteme zu modernisieren.

Je nach Anbieter und Unternehmensstrategie lassen sich zudem Synergieeffekte realisieren, wenn mehrere Systeme eines Anbieters integriert werden.”

Viele Software-Anbieter schaffen dazu die Möglichkeit von hohen Dunkelverarbeitungsquoten, sofern dies fachlich gewünscht ist. So lassen sich weitere Kostenreduktionspotenziale realisieren und Geschäftsprozesse auch flexibler anpassen.Tobias Florian, adesso insurance solutions