So kann es nach der Abkündigung von DOPiX weitergehen

von Ingo Simon und Marian Grzabel, Geschäftsführer der SAVISCON GmbH

Die Abkündigung der Text- und Output-Lösung DOPiX hat Anfang 2022 viele Versicherer unvorbereitet getroffen. Nach anfänglicher großer Unruhe konzentrieren sich nun die meisten auf die Auswahl eines Nachfolgesystems. Die Einführung einer neuen Output-Lösung und die Migration des Textbestandes verursachen Projektaufwände, die wohl die wenigsten eingeplant hatten. Also ist es nachvollziehbar, dass die Verantwortlichen nach einem möglichst kosteneffizienten Vorgehen suchen. Der erste Reflex ist es hier, die Quellbestände mithilfe einer automatischen Transformation 1:1 in ein neues Zielsystem zu migrieren. Mit der heutigen Technologie und den populären KI-Ansätzen erscheint das auf den ersten Blick realistisch und machbar.

Doch ist dieses Vorgehen tatsächlich zielführend? Was sind die Erfolgsfaktoren in einem solchen Migrationsprojekt? Wie nutzt man die ungeplante Belastung als Chance, die nicht nur Migrationskosten verursacht, sondern auch einen langfristigen Mehrwert bringt? Schauen wir uns dazu die verschiedenen Ausgangssituationen an:

• Fall A Das abgekündigte System ist in einem definierten Zustand. Vollständige und aktuelle Fachspezifikationen der Schriftstücke liegen vor. Die Implementierung im Textsystem ist stringent, mit einheitlicher Dokumentenarchitektur über alle Sparten und ohne Altlasten.
• Fall B Das abgekündigte System ist seit mehreren Jahren im Einsatz. Spezifikationen und Implementierung sind „historisch gewachsen“ und über die Sparten uneinheitlich. Vielleicht gibt es auch noch Text-Altlasten aus vorangegangenen Host-Migrationen.
• Fall C Verschiedene Systeme sind im Einsatz. Ein Teil ist bereits migriert und relativ aktuell, der Rest ist noch auf dem Host und beinhaltet vor allem über die Zeit gewachsene und undokumentierte Strukturen und Altlasten.

Im Falle von A) lässt sich eine voll- oder teilautomatische Migration ins Auge fassen. Limitierender Faktor ist hier die Frage, ob Ziel- und Quellsysteme von den technischen Paradigmen her kompatibel sind. Nur dann ist ein strukturelles Mapping überhaupt darstellbar, welches eine automatische Migration zwischen Quelle und Ziel erst ermöglicht. Unsere Erfahrung zeigt, dass dieser Zustand bei den wenigsten Unternehmen vorherrschen dürfte.

Vielmehr wird man die Fälle B) oder C) vorfinden: Ein in sich stabiles System, das zwar gut funktioniert, allerdings schlecht dokumentiert ist und dessen Zustand in der Folge nicht wirklich transparent ist. Wäre ein Systemwechsel durch die gegebenen äußeren Umstände nicht notwendig, wäre dieser Zustand wahrscheinlich akzeptabel. Es läuft ja. Im Fall 3.) würde das alte Host-System nach und nach abgelöst werden. Aber die Abkündigung macht eine Migration früher oder später notwendig. Welche Erfolgsfaktoren sind für eine Migration in den Fällen B) und C) wichtig:

• Projektvorbereitung und Planung: Transparenz über den Zustand des vorhandenen Textbestandes herstellen (Menge, Abhängigkeiten, Komplexität, Redundanzen, Besonderheiten der genutzten Datenobjekte und Identifikation der nicht (mehr) genutzten Datenobjekte). Nur mit diesem Wissen lässt sich ein Projekt verlässlich planen. Die fehlende Transparenz sorgt für eine fehlerhafte Budgetkalkulation. Kurz vor Ende des Projektes kommt es dann regelmäßig zu Überraschungen, die das Budget und die Zeitplanung sprengen. Hier empfiehlt sich der Einsatz eines entsprechenden Analyse-Tools.

• Konsolidierung des Textbestandes: Ist der Textbestand aufgrund von Altlasten, Redundanzen, Programmierungen im Text (z.B. DCF) und ungenutzten Objekten in einem uneinheitlichen Zustand, ergibt eine Konsolidierung Sinn, um den Migrationsaufwand zu minimieren. Dabei kann es sich um eine technische Konsolidierung, also die Reduktion von ungenutzten Objekten, komplexen Logiken und Ersatz der DCF-Programmierung mit anderen Mitteln, handeln. Eine weitere Möglichkeit ist eine fachliche Konsolidierung, welche die Reduktion gleicher, ähnlicher oder obsoleter Texte oder auch eine generelle Neuausrichtung der Texte (auch für neue Kanäle) zum Ziel hat. Insofern sollte geprüft werden, ob der Zwang zur Migration gleichzeitig als Chance für eine Konsolidierung genutzt werden kann. Eine Konsolidierung kann bereits unabhängig von der Entscheidung für ein neues Output-Zielsystem im Fachbereich begonnen werden, sinnvollerweise mithilfe eines geeigneten Redaktionssystems.

• Nach der Migration muss getestet werden: Basis für den (Fach-)Test ist die Fachspezifikation. Nach einer fachlichen Konsolidierung muss gegen die neue Fachspezifikation getestet werden. Hier ist eine (automatisierte) Unterstützung zur Testfallerstellung schon während der Erstellung der Spezifikationen aus dem Redaktionssystem heraus ein wichtiger Aspekt, der sich im Laufe des Projektes auszahlt. Ein (automatisierter) Vergleichstest „Alt vs. Neu“ funk­tioniert in der Regel nur dort, wo eine fachliche Konsolidierung nicht erfolgt ist.

• Nicht nur auf die Textmigration schauen, denn es gibt viel mehr zu beachten. Hier ein kurzer Auszug: Wie integriert sich das neue Textsystem in die vorhandene(n) Anwendung(en)? Wo sind die Versandsteuerungsregeln abgelegt (Priorisierungen im Versand, Steuerung der Kopien etc.) und wie müssen diese im Zielsystem abgebildet werden? Schafft das neue System den Durchsatz der Versandspitzen (Monats- oder Jahresläufe)? Kann das bisherige Reporting aufrechterhalten werden und wie erfolgen Fehlermonitoring und -behandlung? Wer muss wie auf das neue System geschult werden? Wichtige Anmerkung: Diese Fragen stellen sich ebenfalls für den o. g. Fall A!

Fazit

Ein solches Projekt ist auch eine Chance, um die zum Teil sehr alten Text-Paradigmen auf den Prüfstand zu stellen und im Sinne der Digitalisierung neue Wege in der Kundenkommunikation zu gehen. Dann produziert das ungewollte Projekt auch einen sinnvollen Mehrwert.

Übrigens: Mit unserer Software, dem SAVISCON BRIEF-ASSISTENTEN, kann dieser Prozess schnell und einfach unterstützt werden.

Über den Autor

Ingo Simon ist Geschäftsführer der SAVISCON GmbH. Er hat das Unternehmen im Jahr 2010 gegründet und war bis 2018 größtenteils mit einigen Beratern in Kundenprojekten auf Basis von Dienstleistungsverträgen unterwegs. Ende 2018 übernahm die SAVISCON GmbH die Software des heutigen GRC-COCKPITs und weitete das Geschäftsfeld von Corporate Communication und Enterprise Content Management auf das GRC-Management aus. Ingo Simon ist zertifizierter Compliance & Integrity-Manager und ebenfalls zertifizierter ISMS-Manager. Kontakt: ingo.simon@saviscon.de oder vernetzen Sie sich mit mir: