Zwei Krankenkassen wollten fusionieren und ab dem Fusionszeitpunkt den Bestand von Privat- und Firmenkunden nur noch in einem System pflegen. Eine Aufgabe war deshalb die Konsolidierung der Bestände am Wochenende der Fusion. Der Bestand sollte von einem Bestandssystem mit Standardsoftware in ein anderes Bestandssystem überführt werden. Das erste Hindernis war, dass der Hersteller des Standardsystems die Datenstrukturen nicht offenlegte. Das zweite Hindernis war, dass für die Vorbereitung nur 5 Monate vorgesehen waren.

Schlüssel zum Erfolg: neutrale Sicht und agiles Vorgehen

Für den Zugang zu den Datenstrukturen wurde ein Unternehmen gefunden, das regelmäßig in dem Standardsystem Releasewechsel durchführte und somit über dieses Wissen verfügte. Mit diesem Unternehmen konnte eine neutrale Sicht auf die Daten für die Bestandsübernahme entwickelt werden.

Allerdings waren nun 3 Unternehmen bei der Umsetzung der Datenkonsolidierung beteiligt. Entgegen der klassischen Projektplanung mit stufenweisem Vorgehen wurde ein sehr agiler Ansatz mit starker Überlappung sowie eine direkte Verzahnung der Unternehmen über 3 Standorte hinweg gewählt. Die sehr enge Abstimmung sorgte für einen reibungslosen Ablauf.

Vor einer Fusion war ein Unternehmen dabei, die Bestandsführung von Privat- und Firmenkunden von einem Individualsystem in ein Standardsystem zu überführen. Dabei wurde jede Bestandsänderung im Individualsystem synchron im Standardsystem gepflegt. Nach der Fusion kam vom fusionierten Unternehmen ein weiteres Bestandssystem hinzu. Das Aufgabe war, die Bestandsführung parallel in 3 Systemen synchron zu pflegen. Das Hindernis war, dass es technisch keine Möglichkeit gibt, eine Änderungen in 3 Systemen synchron durchzuführen.

Schlüssel zum Erfolg: asynchrone Pflege

Das 3. System wurde nicht synchron, sondern asynchron über eine Warteschlagen (Queue) gepflegt. Dazu wurde vom Individualsystem die Änderung synchron in die Warteschlage eingestellt. Die erfolgreiche Verbuchung im Individualsystem war weiterhin der fachliche Konsistenzpunkt. Das 3. System verarbeitete die Änderung aus der Warteschlage und quittierte die erfolgreiche Verarbeitung. Das war der technische Konsistenzpunkt.

Das Verfahren arbeitete bis zur Konsolidierung der 3 Systeme in ein Bestandssystem erfolgreich.

Nach einer Fusion von zwei Krankenkassen gab es zwei sehr unterschiedliche Strukturen der Beitragsbearbeitung. Im Unternehmen A war sie deutschlandweit in über 100 Einheiten verteilt. Im Unternehmen B war sie an einem Ort zentralisiert. Im fusionierten Unternehmen sollten schrittweise 8 Beitragszentren mit jeweils räumlich umschriebenen Zuständigkeitsbereichen gegründet werden. Für die Ermittlung der Zuständigkeit von Privat- und Firmenkunden waren somit 3 verschiedene Modelle zu berücksichtigen: die beiden Ausgangsmodelle für die noch nicht umgestellten Bereiche sowie das neue Modell für die gegründeten Beitragszentren.

Schlüssel zum Erfolg: einfrieren – auftauen

Im ersten Schritt wurden die bisherigen Zuständigkeiten „eingefroren“, um eine klare Abgrenzung zu ermöglichen, das heißt es wurden keine Zuständigkeitsänderungen mehr durchgeführt. Bei der Gründung eines Beitragszentrums wurden erst alle im Zuständigkeitsbereich liegenden Kunden „aufgetaut“ und anschließend die Zuständigkeit anhand des neuen Modells ermittelt.

Die Beitragszentren wurden jeweils an einem Wochenende erfolgreich gegründet.

Das Ziel war, die Bearbeitung der Einkommensanfrage zu verbessern. Beim bestehenden Vorgang wurde vom Bestandssystem ein Brief auf Papier gedruckt, versandt und der Papier-Rückläufer zur Sachbearbeitung an den Schreibtisch gebracht. Nach der Umstellung sollte der Brief als eDokument in einer eAkte abgelegt werden und der Rückläufer direkt beim Posteingang gescannt und der Sachbearbeitung in einem Arbeitsvorrat auf dem Bildschirm angezeigt werden. Das Hindernis war die starke Trennung zwischen Bestandssystem und Dokumentensystem.

Schlüssel zum Erfolg: Interaktion

Es wurde eine enge Interaktion zwischen Bestandsverarbeitung und Dokumentenverarbeitung über standardisierte Service-Schnittstellen entwickelt. So war es möglich den Brief bei der Erstellung nicht nur dem Drucksystem, sondern auch dem Archivsystem zu übergeben. Die Indizierung erfolgte im Bestandssystem. Bei der Verarbeitung des Eingangs erfolgte die Interaktion in die entgegengesetzte Richtung. Der Brief wurde gescannt und vom Dokumentensystem indiziert, indem beim Bestandssystem angefragt wurde.

Durch die Interaktion über die Schnittstelle gelang es, den Vorgang vollständig zu optimieren. Zudem erlaubte es die Standardisierung, innerhalb eines Jahres ca. 80 % aller Dokumentenvorgänge auf die elektronische Aktenführung umzustellen.

Für die Ablaufsteuerung in einem Rechenzentrum sollte von einem Produkt auf ein anderes Produkt umgestellt werden. Dazu waren etwa 1200 Abläufe und 4000 Jobs umzustellen. Es gab keine Möglichkeit der Datenmigration zwischen den beiden Anwendungen, da sie zueinander inkompatibel waren. Betroffen waren Jobs auf 6 zOS-Systemen, 80 Unix-Systemen und 30 Windows-Servern.

Schlüssel zum Erfolg: Segmentierung, Job-Konvertierung und jira-Steuerung

Im ersten Schritt wurden die Abläufe in Aufgabenpakete segmentiert, die unabhängig voneinander umgestellt werden konnten.
Im zweiten Schritt wurde für die Job-Umstellung ein Job-Center gebaut, das in der Lage war, aus der alten Job-Schreibweise die neue Job-Schreibweise zu generieren.
Im dritten Schritt wurde für die Erstellung der Ablaufsteuerung im neuen Produkt eine Zusammenarbeit zwischen Anwendungsentwicklung und Arbeitsvorbereitung vom RZ-Betrieb über jira-Steuerung hergestellt.

Durch diese Maßnahmen gelang es, die Umstellung innerhalb von einem Jahr erfolgreich durchzuführen.