IT und Versicherung: “Die Zeit der Individualentwicklungen für Aufgaben wie das Berechnen und Verwalten der Vermittlerprovisionen ist vorbei”

Oliver von Ameln. Quelle: Adesso

Respekt, wer’s selber macht? Das gilt bestimmt für Heim- und Hobbybastler als Zielgruppe dieser Baumarktwerbung. Für Versicherungsmanager stellt sich diese Frage in Bezug auf die IT-Systeme für die Kernprozesse ihres Unternehmens heute aber kaum mehr. Ein Gastbeitrag von Oliver von Ameln.

Die Zeit der großen Individualentwicklungen für Aufgaben wie die Bestandsführung, das Leistungs- und Schadenmanagement, die Zahlungsverkehrsabwicklung oder das Berechnen und Verwalten der Vermittlerprovisionen ist vorbei. Zu viele dieser Eigenentwicklungsprojekte sind in der Vergangenheit gescheitert.

Ein kritischer Blick auf die notwendigen eigenen Ressourcen, die es braucht, um große Softwareentwicklungsprojekte im jeweiligen Zeit- und Budgetrahmen mit der nötigen Qualität stemmen zu können, hätte der Landschaft einige Bauruinen erspart: Benötigt werden Softwarearchitekten, die mit allen relevanten aktuellen Technologien vertraut sind, um die richtigen Weichen für die Zukunft zu stellen. Anforderungsanalysten, die nicht nur profundes Fach- und Praxiswissen mitbringen, sondern dieses auch so aufschreiben können, dass Softwareentwickler daraus den richtigen Code generieren können.

Integrationsexperten, die von Beginn an auch die weiteren Umsysteme des Unternehmens im Blick haben, um eine schnelle Einführung der Software zu gewährleisten. Migrationsexperten, die das Zielsystem kennen und verstehen sowie Erfahrung aus möglichst vielen ähnlichen Projekten mitbringen, um den Produktivdatenbestand richtig zu analysieren und zu übertragen, und die verhindern, dass man in eine der gefährlichsten Kostenfallen eines solchen Projektes tritt. Spezialisten für das Oberflächendesign (GUI), die eine maximale Benutzerfreundlichkeit ermöglichen und den Sachbearbeitern optimale Unterstützung sowie dem Management größtmögliche Effizienz garantieren.

Nützlich sind auch erfahrene Projekt- und Teilprojektleiter, die sich mit den unterschiedlichen Phasen einer Einführung z. B. von Bestandssystemen auskennen und auch hier helfen, die unterschiedlichen Sichten von Fachbereichen, IT und Management unter einen Hut zu bringen, und durch ihre Kompetenz souverän die richtigen Kompromisse aushandeln.

Diese Positionen sind allesamt wichtig, aber leider ist die Liste noch lange nicht vollständig. Schon während der Softwareentwicklung muss der zukünftige Wartungsbetrieb aufgebaut werden: Technologische Weiterentwicklung tut Not, außerdem muss sichergestellt werden, dass regulatorisch notwendige Änderungen rechtzeitig in der Software umgesetzt werden können.

Kein Wunder, dass wir heute kaum mehr solche großen In-House-Projekte erleben. Nach mehrjährigen Entwicklungsprojekten darf man die aufgebaute Kompetenz auf keinen Fall wieder ziehen lassen. Das Wissen in Bezug auf die Software, und zwar sowohl in fachlicher als auch in technischer Hinsicht, muss auf einer möglichst breiten Personalbasis sicher und langfristig zur Verfügung stehen.

Also fällt die Wahl immer häufiger auf Kaufsoftware. Aber nach welchen Kriterien soll man sich hier entscheiden?

Produktstrategie des Anbieters

Die Organisation des Anbieters muss als Produkthaus die Weiterentwicklung in der DNA haben: Keine Vermischung von Professional-Service-Einheiten und Produktentwicklung. Für den Kunden muss die inhaltliche Entwicklung der Releases jedes Produkts bereits ein Jahr im Voraus sichtbar sein. Eine professionelle Produktentwicklung arbeitet mit mittelfristigen Roadmaps und hat sowohl die Meilensteine als auch die Ressourcen – auf für den Kunden nachvollziehbare Art und Weise – ständig geplant.

Ziel muss sein, dass die Kunden zehn Jahre nach dem Kauf kein zehn Jahre altes System im Haus haben, sondern ein aktuelles. Wichtig ist zudem, dass die Software code-identischbei mehreren Kunden im Einsatz ist.

Reifegrad von Organisation und Software

Mindestens vorliegen sollten ausführliche Handbücher für den Betrieb der Anwendung, die Schnittstellen, die Architektur, Mathematik / Produktmodellierung und die Anpassungsmöglichkeiten (User-Exits).

Die Organisation des Anbieters bietet eine klare Aufteilung in Professional Service (fachlich und technisch), Produktentwicklung, Support und Wartung. Und die Menschen, die dahinterstehen, lassen sich auch kennenlernen und interviewen.

Die Organisation des Herstellers sollte eine zertifizierte fachliche und technische Aus- und Weiterbildung für eigene und Kundenmitarbeiter anbieten. Bei adesso insurance solutions bieten wir mit der „in|sure Academy“ einen zertifizierten Ausbildungsgang für die Produkte unserer Anwendungslandschaft in|sure Ecosphere an, bei dem ein Foundation-, Advanced- oder Expert-Level erreicht werden kann. Hier werden beispielsweise Softwareentwickler des Kunden in wenigen Wochen in die Lage versetzt, kundenindividuelle Anpassungen selbstständig zu entwickeln, oder Fachbereichsspezialisten lernen Anforderungen so zu formulieren, dass sie in der Software umgesetzt werden können.

Vollständigkeit des Angebotsportfolios

Der Einsatz von Systemen unterschiedlicher Hersteller erfordert auf Kundenseite die Kompetenzen für die diversen Technologien. Bei jeder Releaseanhebung sind alle möglichen Anbieter zu koordinieren. Einführungsprojekte kranken an Schnittstellenproblemen und mangelnder Zuständigkeit.

Klug ist es also – wie bei vielen Technologien – sich bei einer Modernisierung die Perspektive einer Plattform wie unserer in|sure Ecosphere zumindest offenzuhalten. Wenn das Zusammenspiel aller möglichen Zielsysteme bereits durch Wartungsverträge und regelmäßige Updates durch den Anbieter gewährleistet wird, spart man sich viele unnötige Probleme und kann sich auf diejenige Arbeit konzentrieren, die wertschöpfend ist und Wettbewerbsvorteile bringt.

Technologische Kompetenz / “Cloud-Readyness” / praktische SaaS-Erfahrung in vergleichbarem Kontext

Die Software sollte out-of-the-box sowohl on-premises als auch in der private oder der öffentlichen Cloud laufen können. Die Lauffähigkeit auf Container-Anwendungsplattformen wie OpenShift ist hier Pflicht, um einen wirtschaftlichen Betrieb sicherzustellen.

Leistungsfähigkeit für Integrationsprojekte

Für die Einführung muss ausreichend geschultes Personal zur Verfügung stehen. Hier ist weniger wichtig, ob der Produktgeber selbst die Einführungsprojekte durchführt, sondern vielmehr, dass die Mitarbeiter für ein geplantes Einführungsprojekt genau dieses Softwareprodukt schon bei einem anderen Kunden eingeführt haben und dass die Qualifikation für die Beherrschung der fachlichen Domäne und des Produktes (siehe in|sure Academy) nachgewiesen werden kann.

Wartungs- und Incidentmanagement

Vorhandene Organisationseinheiten für langfristigen Support mit ausreichendem Service Level sind unerlässlich. Genau wie bei den Professional-Service-Einheiten für die Einführung schadet es hier nicht, nach den dedizierten Personen zu fragen, die sich um die Kundenbetreuung im Servicefall kümmern. Auch eine technische Plattform für die Fehler- / Supportkommunikation sollte vorhanden sein, allerdings darf man als Kunde hier darauf bestehen, dass das unternehmensweit eingesetzte Tool an das des Anbieters angeschlossen wird, damit die Mitarbeiter sich nicht für jedes System an andere Tools gewöhnen müssen.

Individualisierbarkeit der Software

Und zwar ohne die Releasefähigkeit zu korrumpieren! In der Individualisierbarkeit, insbesondere auf Prozess- und Produktebene, liegen die Möglichkeiten für Alleinstellungsmerkmale im Wettbewerb. Hier sollte sichergestellt werden, dass keine schmerzhaften Kompromisse eingegangen werden müssen, nur um “nah am Standard” zu bleiben. Gute Softwareprodukte benötigen das Argument “das ist eben der Standardweg” kaum, weil sie sich durch Variationspunkte auszeichnen, die z. B. beliebige Änderungen der Bildschirmmasken und der Prozesse oder die Einbindung externer Dienste, z. B. Nachschlagewerke, Verzeichnisdienste, Prüfdienstleister, etc., ermöglichen. Und das, ohne dass die Individualentwicklung bei jedem neuen Release der Software – idealerweise etwa alle sechs Monate – mühevoll angepasst werden muss. Echte Standardsoftware wie unsere in|sure Ecosphere liefert eine genaue Dokumentation über die Anpassungsmöglichkeiten und deren Grenzen.

Überlassung des Source-Codes

Ein Produzent, der nichts zu verbergen hat, überlässt dem Kunden nach Kauf oder Miete der Nutzungsrechte auch seinen Quellcode. Hierdurch sind die Architekten des Kunden in der Lage, die Qualität der Programmierung und der Code-Dokumentation einzuschätzen und vor allem erspart man sich vertragliche Kunststückchen um irgendwelche „Escrow-Agreements“ für den Fall des Untergangs des Anbieters oder der streitigen Auseinandersetzung. Die Sicherheit der Investition ist so bereits zu Projektstart weitestgehend gewährleistet.

Die genannten Kriterien für die Auswahl der geeigneten Standardsoftware sind gewiss nicht erschöpfend, aber es sind die wichtigsten. Doch auch mit dieser Orientierungshilfe ist das Identifizieren der richtigen IT-Lösungen für den Aufbau einer modernen und flexiblen IT-Infrastruktur alles andere als einfach.

Autor: Oliver von Ameln, Geschäftsführer der adesso insurance solutions GmbH

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

5 + acht =