"Heute kann ich sagen, dass wir genau dieselben Entscheidungen wieder treffen würden"
Vor fünf Jahren begann die Groupe Mutuel ihre Informatik komplett neu aufzusetzen. Das Projekt ist nun bald abgeschlossen, und CIO Jacques Secnazi erklärt im Gespräch mit unserer Westschweizer Redaktion, was die Herausforderungen bei diesem ehrgeizigen Projekt waren.
Herr Secnazi, Sie haben vor fünf Jahren begonnen, die Informatik der Groupe Mutuel komplett neu aufzubauen und das Projekt ist jetzt fast abgeschlossen. Welche Vorteile bietet das neue Informationssystem?
Das Nova-Projekt zielt hauptsächlich darauf ab, die Informatik zu modernisieren, den Funktionsumfang zu verbreitern und dabei an Unabhängigkeit zu gewinnen. Ursprünglich betrieben wir nur ein Mainframe-System, das zwar sehr leistungsfähig, aber nicht besonders ergonomisch war. Die Herausforderung bestand also darin, einen grossen Funktionsumfang und eine hohe Benutzerfreundlichkeit zu schaffen und gleichzeitig etwa das Leistungsniveau der AS/400 zu halten. Das alles unter einen Hut zu bringen, gleicht schon fast einem Husarenstück. Wir haben zwei oder drei Technikgenerationen übersprungen. Dabei hatten wir das Glück, dass der "Rich Client" genau zum richtigen Zeitpunkt auf den Markt kam. Mit dieser Technik konnten wir Benutzeroberflächen schaffen, die Microsoft oder Apple bezüglich Bedienungsfreundlichkeit in nichts nachstehen, aber auf der Architektur von Thin Clients beruhen.
Wie müssen wir uns dieses Projekt vorstellen?
Es ist ein riesiges Projekt, dessen wahren Umfang wir erst mit der Zeit begriffen. Es ist auch sehr schwerfällig zu organisieren und es braucht unbedingt eine starke Unterstützung durch die Generaldirektion. Wir halten alle Beteiligten intensiv zur Mitarbeit an – die Angestellten, die Generaldirektion, das Business. Von den Fachabteilungen verlangen wir prozessorientiertes Denken. Wir erwarten, dass sie Businessanalysten bereitstellen, Tests durchführen, Änderungen annehmen und manchmal auch, dass sie sich umstrukturieren. Wir zwingen sie seit vier Jahren zur Mitarbeit und "belästigen" sie. Während der Spitzenzeiten des Projekts werden die Mitarbeiter aus allen Bereichen Tag und Nacht gebraucht, auch am Wochenende. Am Ende handelt sich auch um ein sehr anspruchsvolles Projekt. Wir werden jeden Tag von unseren Teams gefordert, unsere Entscheidungen werden hinterfragt, wir müssen beschlussfähig sein und Kurs halten und Visionen haben.
Das Nova-Projekt wird 18 Monate später fertig und kostet mehr als ursprünglich vorgesehen. Was hat zu diesen Abweichungen geführt?
Ja, das Budget ist zwar höher als ursprünglich geschätzt, aber auch der Umfang des Projekts ist mit der Zeit signifikant gewachsen. Er hat sich in jeder Hinsicht quasi verdoppelt, bei der Komplexität, der Anzahl der unterstützten Prozesse und Verfahren sowie bei der Automatisierung. Für Aussenstehende ist es nicht leicht zu erkennen, welchen Grad an Automatisierung wir mit Nova mittlerweile erreicht haben. Heute haben wir über 400 Mitarbeiter, die die Leistungen verwalten. Morgen, wenn alles gut läuft, könnte ein Grossteil dieser Arbeit mit deutlich weniger menschlichen Ressourcen erledigt werden.
Wie haben Sie den Informationsaustausch mit den Fachabteilungen gesteuert, und wie sind Sie mit deren Bedürfnissen umgegangen?
Wir haben von Anfang an ein Team von Businessanalysten eingesetzt, das bis auf etwa zwanzig Mitarbeiter angewachsen ist. Wir haben Leute aus den Fachabteilungen rekrutiert, die den Businessteil aufgearbeitet und an uns weitergeleitet haben. So haben wir detaillierte Spezifikationen für Daten, Bearbeitungsmethoden, Verwaltungsregeln und Bildschirmansichten erhalten. Von da an übernahmen die Leiter der Informatikprojekte das Ruder und erstellten eine technische Bedarfsanalyse. Im Laufe des Projekts haben wir die entstandenen Anforderungen jedes Mal dahingehend geprüft, ob sie unser Grundkonzept infrage stellen. Dies war nur in einem einzigen Bereich der Fall. Ansonsten entsprach das Konzept unseren Vorstellungen und war ausreichend modulierbar, um Änderungen zu berücksichtigen.
Der Personalbestand und das versammelte Fachwissen haben sich im Laufe Ihres Projekts ansehnlich entwickelt. Wie haben Sie das Problem der Ressourcen angepackt?
Während des Projekts ist unsere Organisation bis auf 280 Mitarbeiter gewachsen, darunter sind viele Entwickler. Um die Ressourcenprobleme anzugehen, setzen wir einerseits auf Schulung und Koordination, andererseits auf eigenständige Projektleiter und auf die zentrale Verwaltung der Kompetenzen. Wir haben auch das gesamte Projektmanagement mit internen Leuten besetzt. Übrigens haben wir eine ganz einfache Praxis in all unseren Verträgen mit externen Dienstleistern eingeführt. Wir haben einerseits verlangt, dass die Kündigungsfrist nur einen Monat für beide Seiten beträgt, und andererseits, dass wir ihre Mitarbeiter ohne Strafzahlungen übernehmen können. So konnten wir das Team über Monate hinweg aufbauen und weiterentwickeln, indem wir die kompetentesten Personen gesucht und eingestellt haben, sofern sie gewillt waren, ins Wallis zu ziehen.
Konnten Sie die von Ihnen geschulten Mitarbeiter halten?
Wir konnten die Personalrotation eindämmen, indem wir eine flexible Lohnpolitik schufen. Die erlaubt es uns, Unterstützung zu holen und die Fachkräfte zu behalten, die wir brauchen. Weil die Schweiz hinsichtlich Verfügbarkeit von Senior-Spezialisten in der IT hinter anderen Ländern hinterherhinkt, haben wir viele Fachkräfte aus dem Ausland geholt.
Haben Sie bei den ständig wechselnden Anforderungen und gesetzlichen Bestimmungen im Lauf der letzten Jahre auch schon daran gezweifelt, dass das Projekt je fertig werden könnte?
Diese Frage und dieser Druck standen ständig im Raum. Unser Geschäftsführer wiederholte ständig, dass in unserer Branche alles passieren könne, sowohl in rechtlicher als auch in verwaltungstechnischer oder wirtschaftlicher Hinsicht. Es kann von heute auf morgen ein Gesetz verabschiedet werden, aufgrund dessen das Projekt schnell unter Dach und Fach gebracht werden muss oder auch hinfällig werden kann. Was die Bedarfsentwicklung angeht: Ich befasse mich seit 25 Jahren mit Informatik im Versicherungswesen, und ich habe nicht erlebt, dass sich das Kerngeschäft der Branche auch nur um einen Millimeter verändert hätte. Wir arbeiten noch immer mit denselben Verfahren hinsichtlich Verträgen, Schadensfällen und Partnern.
Und was ist mit den Produkten?
Das ist sicher das grösste Problem einer Versicherung. Deshalb haben wir sehr viel in den Aufbau eines Bezugssystems investiert. Dies ist eine hoch komplexe intellektuelle Struktur mit einer Fülle von Informationen über Produkte, Garantien, Deckungen, Unterdeckungen und Tarife. Wir haben das Bezugssystem innerhalb von zwei Jahren mit einem unserer talentiertesten Mitarbeiter entwickelt. Mit diesem System sind wir heute auf der sicheren Seite und können der stetigen Weiterentwicklung unserer Produkte gerecht werden. In Kürze werden wir es den Anwendern zur Verfügung stellen, die es dann eigenständig verwalten können. Das Bezugssystem ist zentral für unsere Geschäftstätigkeit, da es täglich für die Übernahme der historischen Daten aus den Kassen, zum Erstellen von Angeboten und Verträgen und auch für die Rechnungsstellung benötigt wird.
Wie haben Sie die Regeln der Rechnungsstellung eingebunden?
Wir waren eine der ersten Versicherungen, die ein Regelwerk eingeführt haben, um den gesetzlichen, finanziellen und politischen Bestimmungen zu entsprechen. Es umfasst rund 20 000 Regeln, die von unseren Businessanalysten und von Spezialisten erstellt wurden. Wir haben auch die ehemalige Blackbox Tarmed in das Regelwerk eingebunden. Aufgrund dieser wichtigen Vorarbeiten beherrschen wir das Regelwerk heute vollständig.
Wenn Sie die Zeit zurückdrehen könnten, was würden Sie anders machen innerhalb des Nova-Projekts?
Im Rahmen des gesamten Projekts haben wir uns ständig dahingehend abgesichert, das wir die richtige Wahl bezüglich der eingesetzten Technik treffen. Heute kann ich sagen, dass wir genau dieselben Entscheidungen wieder treffen würden. Ein Fehler war aber sicher, dass wir die Menge der umzusetzenden Funktionen unterschätzt haben. Wir hätten von Anfang an einen Plan erstellen, den Umfang des Projekts festlegen und ins Detail gehen müssen, anstatt mit repräsentativen Untergruppen gemäss dem damals gebräuchlichen Merise-Ansatz zu arbeiten. Die Fachabteilungen, die Informatikabteilung, die Generaldirektion und die Finanzabteilung waren erst nach und nach in der Lage, das Ganze zu überschauen. Oft mussten wir die Anwender davon überzeugen, noch ein Stück zum Gesamtwerk hinzuzufügen. Heute würde ich dies anders machen. Ich würde mit der Analyse des Funktionsspek¬trums beginnen, um der Geschäftsleitung ein klares Bild vermitteln zu können, wenn auch nur in finanzieller Hinsicht.
Wenn Sie Ihr Projekt heute lancierten, käme dann die Anschaffung einer Drittlösung in Betracht?
Hinsichtlich des Kerngeschäfts würden wir auf jeden Fall wieder dieselbe Wahl treffen. Lassen Sie mich dies erläutern: Vor fünf Jahren hatten wir den Markt analysiert und eines der seltenen ERP-Pakete für Versicherungen untersucht, die auf dem Schweizer Markt erhältlich sind. Wie sich zeigte, bestand dieses Produkt einfach aus einer Ansammlung verschiedener Software, und das zu einem sehr hohen Preis. Deshalb kamen wir zum Schluss, dass wir unser eigenes System entwickeln mussten. Fünf Jahre später stellen wir fest, dass der europäische Markt für Versicherungslösungen immer noch klein ist, zumindest was die Softwarepakete angeht. Man findet fast nur Teillösungen wie die Partner- oder Finanzverwaltung. Dieser Befund bestärkte uns in unserem damaligen Entscheid. Er erklärt auch, weshalb sich andere grosse Versicherer für unser Projekt interessieren. Falls eine Versicherung heute ihre Informatik neu aufsetzen will, hat sie in der Tat keine andere Wahl, als einen ähnlichen Ansatz wie wir zu wählen. Das heisst, sie muss ihr System fürs Kerngeschäft neu entwickeln und für spezielle Bereiche wie DMS oder Workflow-Software von Drittanbietern hinzukaufen – so haben wir das auch gemacht. Zugegeben, wir waren teilweise sehr ehrgeizig und haben mit Autonomy sogar eine eigene OCR-Scan-Lösung entwickelt. Auch für diese Lösung interessieren sich mittlerweile andere Firmen. Übers Ganze gesehen, haben wir aber alles eingekauft, was es Sinnvolles zu kaufen gab.
Wäre es nicht günstiger gewesen, mit einem grossen Hersteller Kontakt aufzunehmen und ihm vorzuschlagen, gemeinsam ein Produkt zu entwickeln?
Da kennen Sie die Groupe Mutuel aber schlecht. Wir haben mit Pierre-Marcel Revaz einen charismatischen Geschäftsführer, zu dessen Prinzipien es zählt, immer die Unabhängigkeit zu wahren. Natürlich sind wir von Lieferanten abhängig. Wir haben IBM-Maschinen und eine Oracle-Datenbank – aber diese Abhängigkeit ist beschränkt, besonders bei unseren Versicherungsanwendungen. Betrachtet man den strategischen Aspekt dessen, was wir geleistet haben, so beruhen 95 Prozent auf Entwicklungen und nur 5 Prozent auf Drittprodukten. Letztere basieren ausserdem in der Regel auf Standards. Das versetzt uns in die Lage, sie relativ problemlos auszutauschen. Wenn wir morgen beschliessen, unseren derzeitigen Anwendungsserver zu ersetzen, dauert das sicher sechs Monate, aber es ist möglich. Für die Groupe Mutuel war es schon immer strategisch wichtig, ihre Lösungen im Griff zu haben und frei und zügig auf neue Anforderungen des Marktes oder auf Gesetzesänderungen reagieren zu können.
Welche wirtschaftlichen Auswirkungen hatte die Entscheidung, so viel selbst zu machen?
Es bringt nicht zwingend mehr Vorteile, wenn man einen solchen Auftrag an einen grossen Partner vergibt. Nehmen wir als konkretes Beispiel die Erstellung unserer Softwarearchitektur. Wir haben dieses Vorhaben zusammen mit einem der grössten Anbieter auf dem Markt begonnen. Er hat 15 Mitarbeiter darauf angesetzt – die Zeit drängte ja, da es ohne SOA keine modulare Entwicklung gibt. Nach einem Jahr jedoch wurde uns als einziges Resultat ein mehr als 400-seitiges Dokument übergeben. Wir haben es gelesen, haben das Wertvolle behalten und dann alleine weitergemacht.
Sie haben erwähnt, dass sich andere Versicherer für Ihre Lösung interessieren. Ist die überhaupt so konzipiert, dass sie auch in anderen Firmen eingesetzt werden kann?
Ja – wir haben verschiedene Möglichkeiten hierfür analysiert. Ein Grund dafür ist in der Struktur der Groupe Mutuel selbst zu finden. Es ist nämlich durchaus denkbar, dass morgen eine andere Kasse bei uns eingebunden werden muss, die vielleicht mehrere hunderttausend Versicherte hat.
Das ist aber nicht dasselbe, wie eine neue Instanz einzurichten …
In der Tat würde dies einige Anstrengungen bei der Architektur und beim Packaging erfordern. Wir haben uns als geistige Übung vorgestellt, dass wir die Lösung verkaufen möchten. Zunächst einmal sind wir heute schon in der Lage, eine Hosting-Lösung anzubieten. Die umfasst die Datenspeicherung und die Bereitstellung von Ressourcen, Prozessen und Verfahren mit anschliessender Rechnungsstellung. Manche Kassen arbeiten bereits auf diese Weise. Wir können auch eine neue Instanz einrichten. Hierzu könnten wir beispielsweise unser Produkt-Bezugssystem leeren und es mit den Produkten eines anderen Versicherers füllen. Ein weiteres denkbares Szenario wäre, dass sich eine Firma nur für den Finanzteil oder nur für Verträge und Schadensfälle interessiert. Das wäre dann etwas komplexer. Im Packaging müssen wir uns noch anstrengen. Dies ist eine Entwicklung, die wir im Übrigen bereits geplant haben, weil sie bei der Wartung und Produktionsverwaltung sehr nützlich sein kann. Im Allgemeinen eröffnet das, was wir mit Nova geleistet haben, eine Vielzahl an Möglichkeiten, inklusiv die Einrichtung eines Service-Centers.