8.1 Motivation – Outputmanagement als Schlüssel für eine erfolgreiche Kundenkommunikation
Wenn wir über den Trend „Digitalisierung“ sprechen, so meinen wir damit oft fortschrittliche technologische Fähigkeiten, die Unternehmen in die Lage versetzen, besser auf Kundenwünsche einzugehen. „Besser“ wird dabei oft als schneller, individueller oder zielgerichteter interpretiert.
In der Versicherungswirtschaft bedeutet der Trend der „Digitalisierung“ aber noch etwas viel Banaleres: „Den Kunden in den Mittelpunkt zu stellen“ heißt auch zu akzeptieren, dass der Kunde nicht unterscheidet, ob er gerade mit einem Versicherungsunternehmen oder seinem bevorzugten Online-Lieferservice kommuniziert. Warum sollte der erwartete Service-Level in Punkto Geschwindigkeit und Bequemlichkeit ein anderer sein.
Oder noch direkter formuliert: Wenn es ein Online-Lieferservice schafft, physikalische Güter innerhalb weniger Stunden vor meine Haustür zu liefern, warum sollte ich dann mehrere Tage auf eine Versicherungspolice warten?
Die aus dieser banal klingenden Fragestellung resultierenden Herausforderungen für die Versicherungswirtschaft sind vielfältig: Digitale Kontaktpunkte, die dem Kunden sämtliche benötigten Services von der Information über den Vertragsabschluss bis zur Vertragsänderung und -kündigung ermöglichen, sind neu zu errichten oder den aktuellen Anforderungen anzupassen.
Das Geschäftsmodell vieler Serviceversicherer basiert zudem auf einer ausgeprägten Vertriebsstruktur. Auch hier gilt es, den Informationsaustausch im Rahmen der gesetzlichen Vorgaben möglichst effizient zu gestalten. Die Optionen, die sich aus der Digitalisierung ergeben, bieten hier vielfältige Ansatzpunkte.
Am Ende gilt es die über Jahrzehnte erprobte Regelkommunikation mit dem Kunden komplett zu überdenken. Wer möchte in dem beschriebenen Szenario noch eine Standardrechnung per Papier, die keinen persönlichen Mehrwert liefert?
Den besonderen Herausforderungen, die ein Versicherungsunternehmen in diesem Kontext erwartet, widmen wir uns in dem folgenden Artikel.
8.1.1 Analyse einer heterogenen Systemlandschaft
In großen Versicherungsunternehmen weisen zentrale IT-Systeme oftmals einen langen Lebenszyklus auf. Dies gilt für die Kern-Anwendungen der Bestandsführung genauso, wie für querschnittlich orientierte Systeme, zu denen auch die Installationen im Bereich Outputmanagement zählen.
Phasenmodell der Softwarenutzung
Die Erkenntnis an diesem Punkt führte dazu, dass auch im Management die Notwendigkeit zur Veränderung verstanden wurde. Es wurde daher der Auftrag zur Durchführung einer Vorstudie formuliert, um den aktuellen Status der Output-Anwendungslandschaft (Entwicklungsstand, Stabilität, Erfüllung der Nutzererwartungen) und deren Zukunftsfähigkeit zu untersuchen. Hinsichtlich des Ergebnisses gab es keine Vorgaben. Sowohl eine Modernisierung der bestehenden Software, als auch die vollständige Ablöse waren als Option denkbar.
Das Ergebnis nach Beendigung der Vorstudie zeigte eine sehr heterogene Systemlandschaft, die sich über viele Jahre herausgebildet hatte. Technisch gesehen konnten drei Outputsysteme identifiziert werden: Neben einer moderneren Variante, mit eigener Format- und Struktursprache zur Spezifikation der Dokumente und Geschäftsregeln, waren dies auch klassische HOST-Anwendungen, mit einem einfachen zeilenorientierten Dokumentenaufbau und einem statischen Layout mit nichtproportionaler Schrift.
Fachlich divergente Anforderungen führten dazu, dass die bestehenden Outputsysteme in unterschiedlichen Prozesskontexten und Infrastrukturen eingebunden wurden. So entstanden diverse Anwendungsderivate mit jeweils eigenen Migrationsanforderungen. Insgesamt wurden so neun relevante (Haupt-)Installationen dokumentiert.
Neben der technischen Bewertung wurden auf Basis einer SWOT-Analyse [1] weitere Dimensionen der bestehenden Anwendungen herausgearbeitet. Die Ergebnisse können in vier Segmente untergliedert werden: Strengths (Stärken), Weaknesses (Schwächen), Opportunities (Chancen) und Threats (Bedrohungen).
Strengths
Die Anwendungen laufen im Betrieb sehr stabil und weisen eine geringe Fehler-/Ausfallquote auf.
Technologisch sind die Systeme ausentwickelt und in der Praxis vielfach erprobt.
Auch große Druckmengen können innerhalb der definierten Service-Levels problemlos verarbeitet werden.
Basisanforderungen hinsichtlich der Qualität (z. B. Druckergebnis und Dokumentenlayout) werden erfüllt.
Weaknesses
Erforderliche Entwicklerskills sind aufgrund der proprietären Systemkomponenten und den Marktgegebenheiten (insbesondere bei den HOST-Anwendungen) nur sehr eingeschränkt verfügbar.
Die Kosten für den Betrieb der Infrastruktur (CPU-Zeiten, Speicherplatz) sind vergleichsweise hoch.
Für die Nutzung der Anwendungen fallen redundante Lizenzkosten an.
Eine Skalierbarkeit hinsichtlich Volumen und Funktionsumfang ist nur sehr eingeschränkt möglich.
Opportunities
Die Anforderungen der Kunden unterliegen einem stetigen Wandel. Der Wunsch nach alternativen Kommunikationskanälen nimmt stark zu.
Technologisch findet gerade eine Transformation statt, die den Fokus auf neue Formate im digitalen Umfeld richtet.
Bei einer konsequenten Umsetzung einer zukunftsorientierten digitalen Strategie lassen sich erhebliche Kosteneffekte erzielen.
Threats
Die Entwicklung der Digitalisierung zeigt im Outputmanagement disruptive Auswirkungen (das Prinzip der klassischen Papierverarbeitung wird sukzessive verdrängt)
Der Markt fordert neue Formen der Kommunikation, um die Kundenbedürfnisse zu befriedigen. Die Frage des Wandels erfährt damit strategischen Charakter.
8.1.2 Ermittlung des konkreten Bedarfs
Auf Grundlage der erkannten Handlungsfelder wurde ein fachliches Zielbild formuliert: Die Outputanwendung sollte bestehende Stärken aufgreifen und die erkannten Defizite oder Schwächen kompensieren. Daraus wurden folgende Ziele abgeleitet:
Zukunftsfähigkeit
Die Anwendung soll flexible und offene Formate unterstützen. Das Ausgabeformat ist nicht mehr auf DIN A4 beschränkt, sondern soll hinsichtlich des gewählten Versandkanals und der spezifischen Anforderungen dynamisch gewählt werden können (sog. responsiver Ansatz).
Redaktionsprozess
Die Pflege der Dokumente und zugehörigen Sendungsspezifikationen soll primär durch Fachspezialisten möglich sein, die nicht über ausgewiesene IT-Skills verfügen. Ziel ist es, den Redaktionsprozess möglich weit nach vorne zu verlagern.
Prozessunterstützung
Sofern Sendungen und Dokumente nicht bereits durch Geschäftsregeln automatisch ermittelt werden können, sind entsprechende Workflows und Tools für die Sachbearbeiter bereitzustellen. Diese sollen die zugrunde liegenden fachlichen Prozesse optimal unterstützen.
Format und Darstellung
Dokumente sollen so bereitgestellt werden, dass sie den Anforderungen der Empfänger in Bezug auf die gewünschte Darstellung, in Verbindung mit dem jeweiligen Endgerät, genügen. Dabei soll die Formatierung nicht auf reinen Text beschränkt sein, sondern auch die Option zur Einbindung anderer Objekte, wie zum Beispiel Grafiken, ermöglichen.
Versandkanäle
Der Prozess soll im Idealfall den korrekten Kanal ermitteln – abhängig von den Kundenpräferenzen und den rechtlichen Voraussetzungen zur Übermittlung. Dem Sachbearbeiter soll eine Möglichkeit zur Übersteuerung eingeräumt werden, wenn dies aus fachlichen oder prozessualen Gründen notwendig ist.
8.1.3 Balance zwischen Eigen- und Fremdentwicklung
Korrespondierend zu den fachlichen Festlegungen wurden grundsätzliche Leitplanken der Architektur definiert. Die Basis bildete dabei die Anforderung, Dokumente mit allen Daten im Format XML zu verarbeiten. Zur vollständigen Spezifikation der Dokumentenausgabe sollte XSL-T (XSL-Transformation) als Teil der XSL Sprache (Extensible Stylesheet Language) genutzt werden. Diese Sprache wird durch das World Wide Web Consoritum unterstützt und unterliegt den W3C-Normen.1
Der Vorteil dieses Standards liegt darin, dass eine hohe Kompatibilität zu existierenden Anwendungen gegeben ist. Durch den Verzicht auf proprietäre Elemente können einzelne Komponenten ausgetauscht oder neue Prozesse implementiert werden. Hinzu kommt eine durchgängige Architektur, die alle Aspekte von der Datenmodellierung bis hin zur Transformation und Konvertierung in das benötigte Zielformat abdeckt. Die Nähe zu Webstandards erleichtert die Nutzung moderner Technologien, wie die Einbindung des Dokumenten-Contents in Webdarstellungen über das HTML-Format.
Sämtliche Rahmenbedingungen wurden als Anforderungen ausformuliert und dienten als Leistungskatalog für die Ausschreibung der Software-Lösung. Bei der Konzeption stand zu einem relativ frühen Zeitpunkt fest, dass nicht alle Anforderungen durch den Zukauf externer Softwarekomponenten abgedeckt werden können. Dies galt insbesondere für den Bereich der Sendungssteuerung.
Diese Komponente bildet die prozessuale Nahtstelle zwischen dem Fachsystem und der eigentlichen Outputanwendung. Der auslösende Geschäftsvorfall in dem Backend-System bildet dabei den Trigger zur Ermittlung einer passenden Sendung an einen oder mehrere definierte Empfänger. Im Idealfall geschieht dies über eine logische Verknüpfung der Geschäftsvorfälle und Sendungen oder über entsprechend definierte Geschäftsregeln dunkel, d. h. ohne Eingriff durch den Sachbearbeiter.
Entsprechend definierte Kennzahlen geben einen Richtwert von mehr als 80 % Dunkelverarbeitungsquote im Mittel der unterschiedlichen Fachprozesse vor. Dies wirkt sich unmittelbar auf die Komplexität aus, da sehr viel spezifisches fachliches Know-how in Regelwerke verpackt werden muss. Letztlich verbirgt sich dahinter ein Großteil der Kommunikationslogik in einem Versicherungsunternehmen, die je Sparte zudem Besonderheiten aufweist.
Beispiel zur Verdeutlichung
Den Geschäftspartnern, wie Kunden oder Vertriebskontakten, werden über Rollen bestimmte Eigenschaften zugeordnet. In der Sparte Krankenversicherung ist der Versicherungsnehmer als eigentlicher Vertragspartner hinterlegt. Hinzu kommen 1-n versicherte Personen, die im Rahmen des bestehenden Vertrages Leistungen erhalten können. Abhängig von dem Geschäftsvorfall werden unterschiedliche Rollen (Personen) in der Kommunikation angesprochen. Bei der Vertragsbearbeitung steht der Versicherungsnehmer im Vordergrund, im Leistungsfall jedoch oft die versicherte Person. Das Wissen um den richtigen Empfänger ist in dem Regelwerk der Sendungsermittlung definiert. Hinzu kommen noch Anforderungen zur Einsteuerung von Sendungskopien, die zum Beispiel dem Vertragsvermittler zur Verfügung gestellt werden.
Das Beispiel lässt die Möglichkeiten der Kombinatorik erahnen. So lassen sich verschiedene Szenarien aufbauen, die in einer komplexen Matrix unterschiedlichste Rollen (Versicherungsnehmer, versicherte Person, Abtretungsgläubiger, gesetzlicher Vertreter, Vermittler, usw.) mit entsprechenden Geschäftsvorfällen verknüpfen. Es fiel daher die Entscheidung, diesen Teil der Lösung selbst zu entwickeln.
Dispatcher
Aufgabe der Outputsteuerung ist es, die unterschiedlichen Ausgabekanäle in einem closed loop zu bedienen. Die closed loop Verarbeitung stellt sicher, dass alle übergebenen Versandaufträge zuverlässig abgearbeitet werden. Treten Fehler zum Beispiel in dem Druckprozess auf, wird der Vorgang bis zur erfolgreichen Abarbeitung als offen gekennzeichnet und bis zur erfolgreichen Verarbeitung wiederholt.
Bei der elektronischen Übermittlung kann alternativ ein Kanalwechsel erfolgen. Scheitert zum Beispiel der E-Mail-Versand aufgrund einer fehlerhaften Adresse, wird eine Ersatzzustellung per Brief vorgenommen.
8.2 Planung der Pilotanwendung
Nach der Ermittlung des konkreten Bedarfs und der Festlegung, welche Komponenten selbst entwickelt oder zugekauft werden sollen, startete die Planung der Pilotanwendung. Inhalt war hier sowohl die Auswahl des Kooperationspartners, als auch die Festlegung eines fachlichen Kandidaten.
8.2.1 Faktoren zur Produktauswahl
Nach den Vorarbeiten wurde das Ausschreibungsverfahren in der ersten Runde mit 19 Anbietern gestartet. Die Auswahl basierte auf einer Marktanalyse und einer Vorselektion von potenziellen Partnern, die generell Lösungen im Outputumfeld anbieten.
Für die nächste Stufe der Selektion wurde ein strukturierter Fragenkatalog entwickelt, der neben gewichteten Einzelkritierien auch einige Ausschlussfaktoren enthielt. Die Rückmeldungen wurden konsolidiert und durch die Spezialisten des Teams bewertet. Über die Gewichtung einzelner Kriterien konnten Prioritäten in fachlicher und technischer Hinsicht herausgearbeitet werden. Die Auswahl wurde über Interviews, Produktvorstellungen und Testinstallationen soweit verfeinert, dass am Ende des Prozesses nur noch zwei Anbieter zur Disposition standen.
Die wesentlichen Kernanforderungen in Bezug auf den Funktionsumfang und die technischen Vorgaben wurden von beiden Unternehmen erfüllt. Hinsichtlich der Unternehmenscharakteristika stand jedoch ein junges innovatives Unternehmen in Konkurrenz zu einem etablierten Anbieter, der bereits eine gewisse Entwicklungsstrecke durchlaufen hatte.
An diesem Punkt wurde der Entscheidungsraum um eine Dimension erweitert: Die Frage der strategischen Ausrichtung bei der Auswahl eines geeigneten Partners. Bei einer derartigen Konstellation gilt es die Vor- und Nachteile hinsichtlich der mittel- und langfristigen Effekte abzuwägen.
Junges innovatives Unternehmen, geringe Marktreife
Vorteile | Nachteile |
|---|---|
• Hoher Innovationsgrad (Anpassung an Markttrends) • Bereitschaft zur Berücksichtigung individueller Kundenwünsche • Aktive Mitgestaltung der Weiterentwicklung durch den Kunden • Stärkere Ausrichtung an technischen Standards, wenig proprietäre Lösungen zur Wahrung von Abwärtskompatibilitäten | • Softwareprodukt ist möglicherweise in Teilaspekten unausgereift • Die wirtschaftliche Überlebensfähigkeit kann aufgrund der fehlenden Kundenbasis nur eingeschränkt gewährleistet werden • Langfristiges Risiko hinsichtlich fehlender Innovationen, sofern wirtschaftliche Impulse fehlen |
Etabliertes Unternehmen, hohe Marktreife
Vorteile | Nachteile |
|---|---|
• Die Lösung ist in weiten Teilen ausgereift und in der Praxis erprobt • Aufgrund der bereits erzielten Marktdurchdringung ist von einer beständigen Weiterentwicklung auszugehen • Kundenwünsche können aufgrund der Größe des Developer-Teams berücksichtigt werden • Die Rahmenbedingungen schaffen eine höhere Planungssicherheit bei einem geringeren Umsetzungsrisiko | • Kundenanforderungen aus der Vergangenheit haben zu spezifischen Lösungen innerhalb der offenen Standards geführt • Der Innovationsgrad ist hoch, hängt aber in weiten Teilen von den Anforderungen der Bestandskunden ab • Individuelle Weiterentwicklungen fließen nicht in den Produktstandard ein, sondern sind Teil eigener Erweiterungen, die zusätzliche Wartungsaufwände verursachen |
Zur Eingrenzung des Risikos wurden jedoch zwei weitere Rahmenparameter fixiert: Ein etabliertes und solventes Softwareunternehmen übernahm als formaler Vertragspartner die Bürgschaft hinsichtlich der Erfüllung der vertraglichen Pflichten. Durch die konsequente Verfolgung der Strategie der offenen Standards wurde zudem die Option offengehalten, einen Produktwechsel – gegebenenfalls auch nur auf den Austausch einzelner Komponenten bezogen – durchzuführen.
8.2.2 Suche eines geeigneten fachlichen Umsetzungskandidaten
In der nächsten Phase galt es einen fachlichen Kandidaten für die Verprobung zu definieren, der im Rahmen eines PoC (Proof of Concept) als Auftraggeber und späterer Nutzer fungiert.
Die Migration einer Outputanwendung ist generell mit hohen Aufwänden verbunden. Der technische Aufwand hält sich je nach Reifegrad der Anwendung mit dem fachlichen Anteil die Waage. Fachlich schlagen insbesondere die konzeptionellen Vorarbeiten – besonders die redaktionelle Umsetzung jedes einzelnen Dokuments – und die durchzuführenden Tests zu Buche.
Der Umsetzungskandidat muss das Vorhaben vorbehaltlos unterstützen. Für den Erfolg ist es wichtig, dass ein konkretes fachliches Interesse besteht und geeignete Ressourcen im erforderlichen Umfang bereitgestellt werden.
Das Projekt muss in einem vertretbaren Rahmen (innerhalb eines Jahres) durchführbar sein. Längere Laufzeiten bei Initialprojekten erschweren die Planung und machen Risiken kaum kalkulierbar. Es besteht zudem das Risiko bei fortschreitender Dauer, dass das Vorhaben kritisch diskutiert und unter Umständen gestoppt wird, wenn keine sichtbaren Erfolge erzielt werden.
Das Vorhaben darf nicht zu klein dimensioniert werden, um genügend Erkenntnisse für die Tragfähigkeit der Lösung und weitere Migrationsschritte zu erhalten. Insbesondere bei den Eigenentwicklungen sollten wesentliche Funktionen implementiert und abgenommen sein.
Bei übergreifenden Vorhaben, die alle Unternehmensbereiche tangieren, sollte ein aktives Stakeholdermanagement betrieben werden. Der Rückhalt des Top-Managements ist essenziell, um das Vorhaben auch langfristig voranzutreiben.
Unter Berücksichtigung dieser Aspekte fiel die Wahl auf den Bereich Realkredit (Vergabe von Darlehen zur Baufinanzierung), der in der Versicherungswirtschaft eine Sonderrolle einnimmt. Das Backend-System zur Vertragsverwaltung ist nicht so stark mit der technischen Infrastruktur verwoben, wie die Anwendungen der großen Versicherungssparten. Die Anpassungen konnten daher auf einen eng gefassten Bereich begrenzt werden. Durch die vielschichtigen Geschäftsprozesse konnten dennoch alles wesentlichen Anforderungen an ein Outputsystem verprobt werden.
Neben der Anbindung an eine bestehende HOST-Altanwendung bestand die Anforderung darin, eine komplexe Sendungssteuerung und die Möglichkeit zur Hell- und Dunkelverarbeitung umzusetzen. Dies bot die Möglichkeit, das System bis zu einem Reifegrad zu entwickeln, der sich als Basis für weitere Migrationsvorhaben eignet.
Ein weiteres Argument ergab sich aus dem Aspekt des Risikomanagements. Die neu zu entwickelnde Anwendung konnte parallel zu der existierenden Lösung realisiert werden, ohne den bestehenden Prozess zu einem fixen Termin zu überführen. Dieses Fallback sicherte die Arbeitsfähigkeit auch bei technischen Problemen.
8.3 Projektphase
Im Rahmen der Projekt-Aufplanung wurde auch die Frage der geeigneten Methodik geklärt. Das Vorhaben war aufgrund der gesetzten Rahmenbedingungen prädestiniert für den Einsatz agiler Methoden. Es wurde daher entschieden, für die Entwicklung der neuen Komponenten das Scrum-Verfahren anzuwenden.
8.3.1 Methodik: Scrum und Wasserfall bilden eine Einheit
Zwei – scheinbar – gegensätzliche Vorgehensweisen erfreuen sich dabei in der Unternehmenspraxis großer Beliebtheit: Konkret das Scrum-Modell, sowie das Wasserfall-Modell.
Scrum-Modell
Exemplarische Darstellung des Scrum-Prozesses
Der Product Owner stellt die fachlichen Anforderungen und priorisiert diese.
Der Scrum Master achtet darauf, dass die Methodik eingehalten wird beseitigt Hindernisse während des Scrum-Prozesses.
Das Development Team entwickelt das Produkt. Insbesondere das selbstbestimmte Arbeiten des Development Teams ist kennzeichnend für Scrum [3].
Sogenannte Sprints kennzeichnen dezidierte Zeitabschnitte innerhalb des Projekts, die eine maximale Länge von vier Wochen umfassen und als Ziel ein Produktinkrement verfolgen. Dadurch kann sichergestellt werden, dass mittels kurzer Feedback-Schleifen ein hohe Ergebnisgeschwindigkeit sowie ein möglichst hoher Kundennutzen erreicht wird [3].
Wasserfall-Modell
Das Wasserfall-Modell besteht hingegen aus mehreren einzelnen, fixierten Phasen. Jede Phase ist dabei von der vorherigen abhängig, was bedeutet, dass diese abgeschlossen sein muss, bevor die nächste beginnen kann. Aus diesem Grund ist das Wasserfall-Modell häufig mit dem Ruf behaftet, schwerfällig und langwierig zu sein. Als Resultat folgt erst eine späte Sichtbarkeit des produzierten Ergebnisses und damit einhergehend eine verzögerte Erkennung von Fehlern. Auch Änderungen an gewünschte Anforderungen sind häufig schwierig zu realisieren und mit einem erheblichen Mehraufwand verbunden [4].
An dieser Stelle soll bewusst kein weiterer vertiefender Einblick in die einzelnen Phasen vorgenommen werden. Vielmehr werden kurz die Vor- und Nachteile des Modells skizziert, die auch im Vorfeld des Projektvorhabens diskutiert wurden, um die geeignete Methodik auszuwählen.
Zusammenfassende Darstellung der Vor- und Nachteile beider Methodiken
Vorteile | Nachteile | |
|---|---|---|
Scrum-Modell | • Flexibilität • Transparenz • Ausrichtung an Kundenbedürfnissen | • Planungsunsicherheit |
Wasserfall-Modell | • Klare Definition von – Umfang – Zeit – Kosten | • Späte Sichtbarkeit des Ergebnisses • Starre Vorgaben • Spätes Erkennen von Fehlern • Hoher Konzeptionsaufwand |
Genau diese Diskussion führte auch im Vorfeld der Umsetzung des konkreten Use-Cases zu dem Schluss, dass eine Kombination beider Modelle Sinn machen kann. Somit bediente man sich beider Methodiken zur Nutzung gemeinsamer Synergieeffekte.
Die dezidierte Entwicklung der neuen Outputanwendung erfolgte demnach anhand der Scrum-Methodik; die eigentliche Integration des Outputsystems in die bestehende Systemlandschaft hingegen wurde durch die klassische Linienanwendungsentwicklung umgesetzt, welche nach dem Wasserfallprinzip agierte.
Aus dieser Kombination von Methoden ergab sich die Herausforderung der Steuerung und engen Verzahnung. Die normalen Entwicklungszyklen sind an Releasetermine geknüpft, die sich einer unternehmensweiten Planung unterordnen. Entsprechende Ergebnistypen konnten daher nicht beliebig zur Verfügung gestellt werden. Dieses Problem setzt sich bei der Integration und der Bereitstellung in den Testumgebungen fort, da es hier im Vorfeld definierte Zeitkorridore gibt, die in einem gewissen Gegensatz zu den Scrum-Anforderungen stehen, nach jedem Sprint ein vorzeigbares und potenziell testbares Artefakt zur Verfügung zu stellen.
Die Lösung bestand darin, die agile Entwicklung soweit als möglich zu entkoppeln. Neue Komponenten konnten autark umgesetzt und in eigenen Testumgebungen verprobt werden. Das umfasste den Prozess von der (simulierten) Beauftragung bis zur Transformation und Konvertierung. Ein Vorteil war an der Stelle, dass sich das Entwicklungsteam aus Mitgliedern einer Organisationseinheit rekrutierte und so leichter eine sehr enge Zusammenarbeit – abseits der methodischen Rahmenbedingungen – realisiert werden konnte.
8.3.2 Ruby on Rails und offene Formate als technische Leitplanken
Neben der Methodik musste nun noch die Entscheidung getroffen werden, auf welcher technischen Grundlage der Use-Case umgesetzt werden soll. Die Wahl fiel dabei auf das quelloffene Webframework Ruby on Rails, kurz RoR. Es basiert auf der Programmiersprache Ruby und lässt sich grundsätzlich anhand zwei Grundprinzipien abgrenzen: „Don’t repeat yourself“ (Wiederhole dich nicht) und „Convention over configuration“ (Konvention vor Konfiguration).
Das Prinzip „Don’t repeat yourself“ verfolgt das Ziel, möglichst wenige Entwicklungstätigkeiten redundant durchführen zu müssen. Sich wiederholender Code und sich wiederholende Arbeitsschritte (z. B. das Generieren von Klassengerüsten, die sich nur in wenigen Zeilen Code unterscheiden) werden im Framework größtenteils vermieden.
„Convention over configuration“ fordert von Entwicklern, dass anstatt einer variablen, aber komplexen Konfiguration Konventionen für die Benamung von Objekten wie Seiten oder Funktionen einzuhalten sind [5]. Als Ergebnis der beiden Prinzipien ergibt sich eine äußerst schnelle effiziente Entwicklung mit verständlichem Code.
Warum fiel nun die Wahl auf RoR? Was sind die wesentlichen, konkreten Vorteile dieses Frameworks?
RoR ist auf die schnelle und agile Entwicklung moderner Web-Applikationen ausgerichtet. Das Herzstück von RoR bildet der Model-View-Controller. Dieses Pattern teilt die Programmierlogik in drei unterschiedliche Ebenen auf: Das „Model“ beinhaltet die eigentliche Geschäftslogik, zum Beispiel versicherungsmathematische Berechnungen. Der „Controller“ nimmt Benutzereingaben entgegen und leitet diese an das „Model“ weiter, um beispielsweise HTML oder JSON Vorlagen zur Ausgabe oder Darstellung von Inhalten als View zu erzeugen. An diesen Beispielen lässt sich bereits erkennen, dass viele Werkzeuge und Funktionen bereits „out of the box“ in dem Framework enthalten sind.
Bei Java EE ist hingegen eine große Auswahl an Bibliotheken zu verzeichnen, was unzählige Optionen eröffnet, das gleiche Ergebnis auf verschiedenen Wegen zu erzielen. Dieser Rahmen sorgt einerseits für fast unerschöpfliche Möglichkeiten des Code-Designs – kein Problem, das sich nicht mit Java lösen lässt. Für die Entwickler entsteht dadurch aber viel Detailarbeit in der Umsetzung und Identifikation der optimalen Lösung, was am Ende Zeit kostet.
RoR bietet hier den leichteren Zugang mit klareren Strukturen. Viele Funktionen sind, wie eingangs erwähnt, vordefiniert. Der Weg zur Umsetzung ergibt sich durch die Leitplanken des Frameworks deutlich schneller. Entsprechend gut lassen sich bereits nach kurzer Zeit sichtbare Erfolge erzielen, was wiederum die Motivation der Entwickler steigert.
An der Stelle sollte nicht unerwähnt bleiben, dass mit Projektstart RoR zwar in der Community sehr „gehyped“ wurde, aber dieses Framework im Versicherungsumfeld noch nicht etabliert war. Die Basis war bei Java EE deutlich breiter, sowohl was verfügbare Know-how Träger am Markt anbelangte, als auch in Bezug auf den Einsatz der Plattform.
Die Dynamik der RoR Community kompensierte dies durch eine breite Unterstützung. Das Entwicklerteam konnte sich hier intensiv einbringen, so dass auch Entwicklungsergebnisse des eigenen Projekts in die Community eingeflossen sind.
Beispiel
Im Rahmen der Entwicklung entstand so ein JDBC-Adapater für DB2 auf Z/OS. Dieser ermöglicht die Ausführung entsprechender SQL-Anweisungen am HOST.
Aufgrund der erkennbaren Vorteile bei der Umsetzung und des ausgewogenen Risikomanagements fiel die Wahl auf RoR für die Eigenentwicklungen im Umfeld der Sendungssteuerung. Diese Entscheidung fügte sich zudem gut als technologischer Mosaikstein in das Zielbild der innovationsgetriebenen Strategie ein.
8.4 Trends und Erfolgsfaktoren für die weitere Transformation
Wie bereits zu Beginn formuliert, orientieren sich Dokumente in der Versicherungswirtschaft, aber auch in sehr vielen anderen Wirtschaftszweigen, an bekannten Normen und Standards. Der Aufbau eines Geschäftsbriefes ist mit den Schreib- und Gestaltungsregeln unter anderem nach DIN 5008 sehr detailliert beschrieben [6]. Die folgenden Punkte beleuchten verschiedene Aspekte der Outputverarbeitung und deren Bezug zur digitalen Transformation.
8.4.1 XML und XSL bilden die Basis für eine weborientierte und flexible Dokumentenausgabe
Die Definitionen in den verschiedenen DIN-Normen haben ihren Ursprung in den bekannten Ausgangsformaten, wie DIN A4, das in weiten Teilen der Welt eingesetzt wird oder dem Letter-Format, das in den USA und Kanada Verwendung findet.
Um Informationen künftig empfängergerecht darzustellen, ist es notwendig, sich von diesen Rahmenbedingungen zu lösen. Das Format DIN A4 ist künftig nur eine mögliche Ausgabevariante, die einem oder mehreren Kanälen, zum Beispiel dem Papierversand, zugeordnet wird.
Wechselt der Kanal, muss sich die Aufbereitung und Darstellung der Informationen den neuen Gegebenheiten anpassen. Aus dem Webumfeld ist diese Eigenschaft als Responsive Design bekannt. Die Darstellungen der Webseite passen sich dem Gerät – ob Handy, Tablet oder Notebook – an und sorgen dadurch für eine möglichst optimale Nutzbarkeit durch den User.
Diese Eigenschaften gilt es auf das Outputmanagement zu übertragen. Am Ende muss man den Content – sprich den fachlichen Inhalt – von der Darstellung trennen. Dies ist eines der Designprinzipien, das mit der neuen Outputanwendung verfolgt wurde.
Kern dieser Bemühungen ist die Nutzung von XML und XSL als Basis für die Dokumentenspezifikation. Das XML liefert in einer hierarchisch strukturierten Form Daten, die sowohl von Menschen, als auch von Maschinen lesbar sind. Für das Outputmanagement werden dazu die erforderlichen Teile des Datenmodells aus den Backendsystemen ausgelesen und über eine entsprechende Schnittstelle übergeben.
Für die Anbindung anderer Systeme (zum Beispiel der Partner-Anwendung) und für den Aufruf des Outputsystems durch andere Anwender (nutzende Systeme) wurden SOAP-Webservices eingerichtet. Diese werden über den ESB (Enterprise Service Bus) orchestriert und über Datapower abgesichert. Die Kommunikation innerhalb der Output-Komponenten (zum Beispiel Browser zu Backend) läuft über REST-Aufrufe. Diese Variante wird perspektivisch bei der Anbindung von Schnittstellen präferiert.
Das XML-Dokument besitzt in dieser Phase bereits die essenziellen Metadaten für die spätere Ausgabe. Dazu zählen Versandinformationen, wie Adressdaten des Empfängers, auszugebende Werte als einzelne Attribute oder iterierende Listen. Aber auch Attribute zur späteren Regelsteuerung sind bereits enthalten.
Was noch fehlt, sind die Parameter zur Transformation. Diese werden durch XSLT Anweisungen ergänzt. Dabei handelt es sich einerseits um Text, also den sprachlichen Content und andererseits um Stylesheets, die Informationen zur Formatierung beinhalten.
Dokumentenbezogene Regelwerke können über XPath-Ausdrücke realisiert werden. Dies umfasst einfache Geschäftsregeln auf Basis von IF-THEN-ELSE Strukturen, aber auch komplexere Ausdrücke und verschachtelte Regeln.
So definierte Dokumente können über XSLT-Prozessoren eingelesen werden, die das gewünschte Ausgabeformat erzeugen. Moderne Webbrowser haben bereits XSLT-Prozessoren integriert. Sie sind damit in der Lage, derartige Dokumente anzuzeigen.
Für die professionelle Weiterverarbeitung und ein CI-getreues Layout (Corporate Identity) kommt XSL-FO (Extensible Stylesheet Language-Formatting Objects) zum Einsatz. Diese Anwendung aus dem XML-Umfeld sorgt für die notwendigen Elemente und Attribute zur Darstellung. Dazu zählen Ränder, Seitendimensionen, Seitenfolgen, Nummerierungen, Rahmen, Abstände, Spalten, Blöcke, Absätze, Listen, Tabellen, Satzformate, Silbentrennungen und grafische Elemente wie Linien oder Bilder.
Schematische Darstellung des Gesamtprozesses der Outputerzeugung
Den Ausgangspunkt bildet das XML-Dokument, das mittels XSLT-Stylesheet in eine XSL-FO Datei transformiert wird. Dieser strukturierte FO-Baum kann mit einem geeigneten Konverter (vgl. FO-Prozessor) in unterschiedlichste Ausgabeformate überführt werden.
Neben dem bekannten PDF-Format (Portable Document Format) sind hier das Format AFP (Advanced Function Presentation) für den Transaktionsdruck oder XHTML (Extensible Hypertext Markup Language oder erweiterbare HTML) in unserem Beispiel relevant.
8.4.2 AFP und PDF, zwei konkurrierende Ansätze
Welche Formate sind im Kontext bestehender oder künftiger Ausgabekanäle von Bedeutung? Auch wenn die Papierausgabe langfristig nicht mehr im Fokus steht, so deckt sie heute dennoch den größten Teil der ausgehenden textbasierten Kommunikation ab.
Im Umfeld des Transaktionsdrucks ist seit langem das AFP-Format Standard. Dieses Format wurde von IBM entwickelt, um große Druckdatenströme möglichst effizient und layoutgetreu verarbeiten zu können. Die Drucker im professionellen Umfeld verfügen über entsprechende Prozessoren, um aus den Daten Rasterformate zu generieren. Die so erzeugten Seiten beinhalten vom Prinzip her ein Abbild des Dokuments, das in feinen Bildpunkten aufgelöst vorliegt und so produziert werden kann.
Für die Weitergabe oder digitale Nutzung ist das Format jedoch gänzlich ungeeignet, da es keine der Anforderungen erfüllt, die im Rahmen der digitalen Strategie formuliert wurden.
Das PDF-Format hat sich in diesem Kontext zu einer Alternative entwickelt und ist heute an vielen Stellen als Standard etabliert. Von Adobe im Jahr 1993 entwickelt, hatte das Format zum Ziel, einen plattformübergreifenden Austausch zu ermöglichen. Dabei sollte gewährleistet sein, dass die Darstellung und Ausgabe auf allen Geräten möglichst identisch ist.
Diese Anforderung und die Hinzunahme weiterer Features (zum Beispiel die Einbettung von Video-Dateien) stehen in einem gewissen Widerspruch zu den Anforderungen des Transaktionsdrucks. Hier ist ein schlankes Format vonnöten, das möglichst ressourcenschonend die notwendigen Informationen liefert.
Um diesem Umstand Rechnung zu tragen, hat sich aus dem PDF-Standard die Subform PDF/VT herausgebildet. Der Zusatz VT (Volume Transactional Output) oder auch VDP (Variable Data Printing) lässt bereits Rückschlüsse auf den Einsatzzweck zu.
Mit Hilfe dieses 2010 entwickelten Standards soll der Brückenschlag zwischen zwei wesentlichen Ausgabekanälen erreicht werden: Die Dokumente sind sowohl im Bereich der Massenproduktion, als auch auf den Endgeräten nutzbar.
Die Vorteile liegen dabei auf der Hand. Der Prozess muss an dieser Stelle nur auf ein Ausgabeformat hin optimiert werden. Über entsprechende Formatierer oder Konverter lässt sich der jeweils benötigte Substandard erzeugen, ohne wesentliche Eigenschaften des Dokuments zu verlieren.
In unserem Beispiel wurde das PDF-Format konsequent eingesetzt – zum Beispiel im Rahmen der Archivierung. Da die Prozesse im Rahmen der Outputverarbeitung noch nicht vollständig umgestellt sind und die Verarbeitung bei den Druckern von der Vorverarbeitung der Daten abhängig ist, wurde in der ersten Stufe noch ein Zwischenschritt eingefügt: Die bereits im PDF-Format vorliegenden Dokumente werden noch in das AFP-Format konvertiert, um die existierende Verarbeitungsstrecke für den physischen Druck unverändert nutzen zu können.
8.4.3 Ausgabekanäle der Zukunft: Omnichannel -Kommunikation
Werden damit die künftigen Anforderungen einer Omnichannel-Architektur erfüllt? Nein! Dieser Stand repräsentiert im Grunde den Status Quo im Bereich Outputmanagement. Bislang genügte es, den Papierversand zu optimieren und parallel die elektronische Strecke als Derivat zu unterstützen. Die elektronische Zustellung fokussiert sich dabei primär auf den E-Mail-Versand und die Bereitstellung über Portale.
Von Kundenseite wird jedoch eine völlig andere Erwartungshaltung formuliert. Im Alltag nehmen mobile Geräte einen immer größeren Stellenwert ein. Die Vereinfachung von Prozessen, die der Kunde an dieser Stelle erfährt, überträgt sich auch auf die Erwartungshaltung im Outputmanagement.
Informationen sollen auf jedem beliebigen Gerät abrufbar sein und das zu jeder Zeit und an jedem beliebigen Ort. Dabei spielen proprietäre Anwendungen (wie zum Beispiel PDF-Reader) nur noch eine untergeordnete Rolle. Beschränkungen auf bestimmte Betriebssysteme oder Plattformen lösen sich auf. Durch den Wegfall des Papiers spielt auch der eingangs erwähnte starre DIN-Rahmen keine Rolle mehr. Formate und Medien werden beliebig.
Die gewählte Architektur bietet hier eine Grundlage, um diesen Anforderungen zu begegnen. Das PDF-Format ist nur eine Variante, um die Übergangszeit zu begleiten. Mit der Ausgabe von XHTML eröffnen sich neue Möglichkeiten, Informationen darzustellen. Der Content kann so mit grundsätzlichen Anweisungen versehen werden, um den Inhalt beispielsweise in einer browsergestützten Darstellung anzuzeigen. Ein responsiver Ansatz liefert dazu die erforderliche Dynamik, um unterschiedlichste Geräte zu bedienen.
Ein Beispiel verdeutlicht die Notwendigkeit:
Beispiel
Der Leistungsprozess in der Krankenversicherung hat sich im Bereich des Zugangskanals bereits in Richtung Digitalisierung verändert. Man kann es heute im Grunde als Marktstandard bezeichnen, dass Leistungsbelege über entsprechende Apps erfasst und elektronisch eingereicht werden können.
Die Folgeprozesse waren oftmals noch konventionell angelegt. Nach der Leistungsbearbeitung wurde in der Regel an den Kunden ein Leistungsbrief versandt, der Informationen über die Höhe der Erstattung enthielt.
Aus Kundensicht findet hier ein Medienbruch statt. Sofern der eingereichte Betrag voll erstattet wird, ist in der Regel auch kein umfangreiches Schreiben erforderlich, sondern es genügt die Information über die Bearbeitung und die bevorstehende Auszahlung.
Diese Information sollte nun über den vom Kunden gewünschten Kanal, der für diesen definierten Geschäftsvorfall auch aus prozessualen und rechtlichen Gründen geeignet ist, übermittelt werden. Das kann in Form einer SMS sein, als E-Mail erfolgen, in dem Kontext von Social-Media oder als Hinweis in der zu Beginn genutzten Leistungs-App.
Für das Outputmanagement besteht hier die Herausforderung, die Informationen kanalgerecht aufzubereiten. Während im Fall einer umfangreichen Abrechnung ein normales Schreiben mit unterschiedlichen Abschnitten, wie einer tabellarischen Aufstellung der Einzelbelege, benötigt wird, enthält eine SMS nur einen kurzen Bestätigungstext.
An dieser Stelle kommt die Sendungssteuerung zum Tragen. Neben der Berücksichtigung der korrekten Empfängerrolle muss sich die zum Geschäftsvorfall und Kanal passende Sendung mit den zugehörigen Dokumenten regelbasiert ermittelt werden. Bei Auflösung der Regel würde im Falle der SMS nur ein Textfile generiert werden, das neben dem Kanal die Mobilnummer als „Adresse“ enthält.
Diese Flexibilität ist es, was in der Output-Kommunikation unter dem Begriff Omnichannel zu verstehen ist. Bei der Initiierung entsprechender Projekte ist darauf zu achten, dass die Voraussetzungen dazu konsequent in das Design der Anwendungen und in die entsprechenden Architekturentscheidungen einfließen.
8.4.4 Automation von Prozessen – aus Output wird Input
Bei all den genannten Aspekten der Outputverarbeitung darf man in der Kommunikation nicht außer Acht lassen, dass es sich hier um einen bidirektionalen Prozess handelt. Entweder wird der Dialog durch den Kunden initiiert oder der Kunde antwortet auf die empfangene Information. Diesen Prozess kann man unter dem Begriff inputfähiger Output zusammenfassen.
Im Zuge der Umsetzung wurde die Möglichkeit implementiert, vorhandene PDF-Formulare zu nutzen. In vielen Unternehmen existieren umfangreiche Bibliotheken – in aller Regel bereits als statische oder beschreibbare PDF-Dokumente. Das Refactoring ist bei Formularen extrem aufwändig, da ein statisches Layout mit vielen Detailinformationen umgesetzt werden muss. Klassische Outputmanagement-Systeme sind aber mehr auf die Formatierung dynamischer Textinhalte ausgelegt.
Sofern bereits Eingabefelder angelegt wurden, können diese über die definierten XML-Datenströme befüllt werden. Der Kunde erhält dann elektronisch ein Dokument, das mit den bekannten Daten vorkonfiguriert wurde. Die am Bildschirm editierbaren Felder bleiben in diesem Prozess erhalten, können also weiterhin genutzt werden, um die Daten am Bildschirm zu bearbeiten.
Nutzt der Empfänger diese Option, dann wird ein Dokument erzeugt, dessen Inhalt über entsprechende OCR-Verfahren mit einer hohen Erkennungsquote auslesbar ist. Definierte Folgeprozesse können durch die Fachdatenextraktion mit Werten versorgt werden und im Idealfall dunkel ablaufen.
Eine andere Option ergibt sich aus der Bereitstellung digitaler Formulare. Der Content wird dazu in einer webbasierten Darstellung eingebunden. Die erfassten Daten werden so nicht nur als lesbare Information weitergerecht, sondern im Hintergrund gespeichert und an die Backend-Systeme zur Weiterverarbeitung übertragen.
8.4.5 White-labeling als Unterstützung flexibler Vetriebskanäle
Ein ganz anderer Aspekt ergibt sich aus dem Thema White-labeling. Nicht nur im Bereich der Versicherungen ist ein Trend zu verzeichnen, dass Produktgeber und Vertriebsmarke nicht zwingend identisch sind. Für das Outputmanagement ergibt sich dadurch die Anforderung, dass bei Dokumenten letztlich eine Art „Verkaufshülle“ übergestülpt wird. Das kann Layoutmerkmale, wie zum Beispiel Logos umfassen, aber auch rechtliche Angaben zum Unternehmen, die in der Regel in sogenannten Fußzeilen erscheinen.
Bei der Konzeption der Outputanwendung wurde daher penibel darauf geachtet, zwei Elemente voneinander zu trennen: Es gibt einerseits ein Masterlayout, das Definitionen der Marke oder eines Mandanten enthält und andererseits das eigentliche Dokument, hinter dem sich der fachliche Content verbirgt.
Im späteren Prozess werden diese getrennten logischen Einheiten über Regeln zusammengeführt. Über diesen Weg kann ein Prozess mit den zugehörigen Dokumenten für unterschiedlichste Marken eingesetzt werden. Dies wirkt sich nachhaltig auf Wartungsaufwände und damit letztlich auch auf Kosten aus.
8.4.6 Guter Stil ist mehr als nur Rechtschreibung
Neben der mediengerechten Aufbereitung von Inhalten sind weitere Faktoren vonnöten, um Kunden bedarfsgerecht anzusprechen.
Ein Faktor, dem dabei im Outputmanagement eine hohe Relevanz beigemessen wird, ist die Ausgestaltung der Sprache – neben der korrekten Rechtschreibung, welche als selbstverständlich aufgefasst wird, ist die Verständlichkeit der Texte ein weiterer Punkt. Diese ist im Versicherungsumfeld allerdings häufig schwerfällig und von einer Vielzahl an Fachbegriffen geprägt. Dies liegt in der Natur der Sache, da eine Versicherung an sich immer immateriell, komplex und abstrakt ist.
Im Sinne der Kundenorientierung ist es jedoch unabdingbar, Schriftstücke so auszuformulieren, damit der Kunde auch versteht, was ich ihm als Unternehmen vermitteln will. Der korrekten Ausgestaltung der „Unternehmenssprache“ und ihrer Verständlichkeit kommt im Outputmanagement neben Rechtschreibung und Form somit also eine weitere zentrale Rolle zu.
Beispiel
Um die Verständlichkeit von Texten zu untersuchen, lassen sich verschiedene Methoden heranziehen. Eine der bekanntesten Methoden ist der sogenannte Hohenheimer Verständlichkeitsindex, welcher aus einzelnen Skalenwerte einen Indexwert errechnet – dem Text wird also eine Note vergeben, die von 0 (= geringe Verständlichkeit) bis 20 (= hohe Verständlichkeit) reichen kann. Für Briefe, die der Kundenkommunikation dienen, wird ein Wert von mindestens 14 empfohlen [7].
Durchschnittliche Satzlänge in Wörtern
Durchschnittliche Wortlänge in Buchstaben
Anteil der Wörter mit mehr als 6 Buchstaben
Anteil der Satzteile mit mehr als 12 Wörtern
Anteil der Sätze mit mehr als 20 Wörtern
Negative Formulierungen
Füllwörter und Abkürzungen
Weitere probate Mittel wie Verben statt Substantive, der Verzicht von Fremdwörtern sowie der Einsatz positiver Anreize kennzeichnen „gute“ Briefe.
Wie können Unternehmen nun in der Praxis ausformulierte Schriftstücke auf ihre Verständlichkeit schnell und einfach untersuchen? Eine beispielhafte Software, die auf den Hohenheimer Verständlichkeitsindex aufsetzt, ist TextLab. Das Textanalyseprogramm wird von Sprach- und Kommunikationswissenschaftlern stetig weiterentwickelt und bietet dem Nutzer konkrete Verbesserungsvorschläge und wertvolle Hinweise zur Optimierung des Textstücks: Ist die Mitteilung an den Kunden höflich, zu abstrakt, zu distanziert oder zu fachlich? Darüber hinaus lässt sich durch eine Einbindung des Corporate Wordings und definierter Terminologien die Unternehmenssprache im Output verankern [8].
Somit liegt nun neben flexiblen Outputformaten und einer Realtime-Ausgabe auch hinsichtlich des Inhalts eine kundenorientierte Aufbereitung vor. Als nächstes beleuchten wir, wie im Rahmen des Outputmanagements Sachbearbeiterprozesse optimiert werden können.
8.4.7 Vereinfachung in der Sachbearbeitung durch intelligente Regelwerke und eine stärkere Dokumentenorientierung
Das Stichwort Kosten findet im Outputmanagement auch einen ganz anderen Bezug. Neben den bekannten Faktoren, wie den Betriebskosten (Infrastruktur, Lizenzen, Wartung, usw.) und den versandabhängigen Kosten (in erster Linie Porto), spielen auch die Prozesskosten eine entscheidende Rolle. Dies gilt zumindest für Branchen mit einem hohen Anteil manueller Sachbearbeiterprozesse.
In der Versicherungswirtschaft hat die Automation immer mehr Einzug gehalten. Die Policierung erfolgt im Antragsprozess zumindest bei einfachen Produkten in der Regel dunkel – d. h. ohne Sachbearbeiter-Interaktion. Auch die zugehörigen Sendungen und Dokumente werden automatisiert erzeugt und versandt.
Anders verhält es sich bei bearbeitungsintensiven Vorgängen mit einem hohen Grad der Individualität. Das ist insbesondere bei komplexen Produkten oder schwierigen Sachverhalten (zum Beispiel in der Leistungs- oder Schadenbearbeitung) der Fall.
Der Grad der manuellen Bearbeitung ist dabei fließend und reicht von der Komposition eines Dokuments mit Hilfe vordefinierter Textbausteine bis hin zur völlig freien Formulierung. Letzterer Fall lässt sich derzeit technisch nur bedingt unterstützen. Hier helfen einzig optimale Werkzeuge, die möglichst alle Anforderungen an die Editierung von Texten erfüllen.
Ein möglichst hoher Grad der Wiederverwendbarkeit – eingebettet in komplexe Regelwerke und hohe Abhängigkeiten von Textbausteinen und Dokumenten.
Ein dokumentenorientierter Ansatz, bei dem redundante Textbausteine bewusst in Kauf genommen werden.
Sachbearbeiter wählen im Prozess zunächst immer eine Sendung, bzw. ein Dokument. Für den Sachbearbeiter ist das Dokument der natürliche Repräsentant der zu versendenden Informationen.
Die Auswahl aus sehr vielen Textbausteinen innerhalb eines Dokuments wird sehr schnell unübersichtlich und kostet Zeit. Die Auswahl aus maximal 5 Textbausteinen ist hingegen sehr effizient.
Im Redaktionsprozess führt die Verwendung von Textbaustein-Referenzen ebenfalls sehr schnell zu Abhängigkeiten und hohen Aufwänden (siehe nächster Abschnitt). Ein in sich möglichst vollständiges Dokument lässt eine Fokussierung zu und ist damit ebenfalls effizienter – insbesondere vor dem Hintergrund, dass es sich bei den Redakteuren in der Regel um fachliche oder juristische Kollegen handelt.
8.4.8 Von der Idee bis zum produktionsreifen Dokument – Redaktionsprozesse optimiert
Neben den Sachbearbeiter-Prozessen ist der Redaktionsprozess zur Erstellung der Dokumente ein wichtiger Hebel zur Optimierung. In der Versicherungswirtschaft werden Inhalte in der Regel von Fachspezialisten und Juristen definiert. Das Customizing der Outputanwendungen – also die Pflege der Sendungen, Dokumente, Textbausteine und Geschäftsregeln – ist jedoch aufgrund der Komplexität fachlichen Spezialisten vorbehalten. Die Systeme haben sich weiterentwickelt, so dass keine ausgebildeten IT-Fachkräfte erforderlich sind. Dennoch verlangt die Tätigkeit ein gewisses Maß an technischem Verständnis und eine kontinuierliche Auseinandersetzung mit dem Thema.
In Zeiten der Digitalisierung und einer hohen Dynamik steht dies aber in einem Widerspruch zu den Anforderungen. Es ist kaum vorstellbar, dass die neue und innovative Produkteinführung nicht parallel auf allen Kommunikationskanälen verbreitet wird. Von daher ist auch dieser Prozess ein Teil der digitalen Transformation.
Ein Lösungsansatz dafür ist eine intelligente Mischung unterschiedlicher Vorgehensmodelle. Für statische Textinhalte wurde dazu ein eigener Workflow entwickelt. Die Redakteure sind in der Regel mit den gängigen Textverarbeitungssystemen vertraut. Daher wurden in Word Templates definiert, die in einer Netto-Darstellung (Druckbereich ohne Seitenränder) bearbeitet werden können.
Den Spezialisten stehen so alle Werkzeuge zur Verfügung, um den Inhalt schnell und effizient auszuformulieren. Besonders Funktionen, wie die Änderungsverfolgung, sind bei umfangreichen und übergreifenden Abstimmungen sehr hilfreich.
Diese Dokumentvorlagen werden dann über automatisierte Prozesse in verschiedene Endformate konvertiert. Aktuell werden PDF-Dokumente und AFP-Dokumente ausgegeben. PDF-Dokumente können unmittelbar verwendet werden, um zum Beispiel Info-Datenbanken zu füllen oder einen Download auf der Homepage zu ermöglichen.
Die AFP-Dokumente werden als Ressourcen in dem Output-Repository abgelegt. Bei dem Verarbeitungsprozess werden diese Ressourcen in zuvor definierte Hüllendokumente eingebettet, die ähnlich der Mastertemplates Formatinformationen, wie Seitenränder, enthalten. So entstehen vollständige verarbeitbare Dokumente.
Für dynamisch erzeugte Dokumente kann ein Transfer der Fachlichkeit nicht vermieden werden. Der Redakteur muss den Inhalt definieren, aber auch die Konditionen unter denen Werte ausgegeben oder variable Textbausteine angedruckt werden sollen. Hier zeigt sich das Dilemma, das bereits in dem vorangegangenen Abschnitt formuliert wurde. Eine zu hohe Komplexität sorgt an dieser Stelle für erhebliche Aufwände. Je einfacher das Dokument strukturiert ist, desto leichter fallen die fachliche Spezifikation und letztlich auch der Test am Ende der Entwicklung.
Um die Dokumentation möglichst effizient zu gestalten, wurden Redaktionstemplates entworfen, die in einer simplifizierten Form dem technisch designten Dokument entsprechen. Redakteure können so ihre Änderungen für das Customizing ausformulieren.
Ziel der Anwendung ist es jedoch, den Zugang weiter zu erleichtern. So können einfache Änderungen, die sich nur auf einzelne Texte beziehen, durch die Fachredakteure künftig selbst vorgenommen werden.
8.4.9 Dokumente werden bunt – auch in Papier
Der letzte Abschnitt ist dem Thema Farbe im Outputmanagement gewidmet. Als Teil der digitalen Transformation wurden die Gestaltung und die physische Produktion von Dokumenten grundlegend reformiert. Neben der Nutzung von dynamisch zu steuerbaren Objekten, wie Markenzeichen, Unterschriften oder Text, wurden auch Optionen zur Konfektion (u. a. das Aufbringen einer Mikro-Perforation) realisiert.
Das neue Outputsystem unterstützt diese Prozesse bereits im Design, da in dem Dokument visuell festgelegt werden kann, an welcher Stelle und nach welchen Regeln zum Beispiel eine Grafik ausgegeben werden soll. Im Verarbeitungsprozess werden dann Druckdaten erzeugt, die alle Objekte und Farbinformationen enthalten.
Die digitale Variante entspricht dabei dem physischen Ergebnis. Unabhängig von dem gewählten Kanal erhält der Kunde so Dokumente, die alle wesentlichen Anforderungen aus dem CI (Corporate Identity) erfüllen. Unter dem Gesichtspunkt, die Marke in der Außenwirkung zu stärken, ist dies ein wichtiger Faktor.
Um dies auch in der Produktion umzusetzen, wurden die existierenden Laserdrucker durch hochmoderne Inkjet-Systeme ersetzt. Die Farbinformationen aus dem Druckdatenstrom können damit im CYMK-Farbraum in sehr guter Qualität gedruckt werden. Die Profile zur Einhaltung der Farbvorgaben werden mit den Druckdaten geliefert, bzw. durch das Colour-Management direkt am Drucker generiert.
Für die Qualität der Ausdrucke und die Erfüllung der Farbvorgaben ist die Auswahl einer geeigneten Papiersorte entscheidend. Über mehrere Testiterationen wurde ein optimales Zusammenspiel von Hardware und Verbrauchsmaterial erzielt. Das Ergebnis ist so gut, dass für den normalen Kunden ein Unterschied zu der Offset-Variante kaum erkennbar ist. Dies ist insoweit bemerkenswert, da die Vorgaben Farbtöne aus dem HKS-Spektrum2 vorsehen, die selbst bei der Offset-Produktion nicht immer einfach umzusetzen sind.
Neben den beschriebenen qualitativen Effekten ergaben sich auch Auswirkungen auf Prozesse und deren Effizienz. Der Transaktionsdruck war früher auf die Verarbeitung vorgedruckter Geschäftspapiere ausgerichtet. Die vorkonfektionierten Briefbögen mussten in unterschiedlichsten Ausprägungen bevorratet und im Prozess der Verarbeitungskette zugeführt werden. Da die Aufnahmekapazitäten der Papierfächer begrenzt waren, führte dies zu einem vergleichsweise hohen Personaleinsatz. Zudem kam es dadurch immer wieder zu Störungen oder Fehlern in der Verarbeitung.
Mit dieser neuen Technik konnten hier wesentliche Verbesserungen erzielt werden. Das Papier wird über eine Rolle dem Druckprozess zugeführt. Eine Rolle entspricht ca. 75.000 Blatt im DIN A4 Format. Die Prozesse zur Papierbestückung oder Umrüstung können so deutlich reduziert werden.
Die vollständigen Druckdaten werden dann im Prozess an den Spool3 übergeben. Dieser Prozess ist neben der Steuerung der Verarbeitung auch für das Farbmanagement verantwortlich. Ein Beispiel: Liefern Anwendungen im Farbraum CMYK Maximalwerte,4 was der Farbe schwarz entspricht, wird diese Information in echtes schwarz umgesetzt (Verwendung der Key-Farbe). Der Tonerverbrauch kann dadurch erheblich reduziert werden.
Eine Problemstellung ergab sich in dem Prozess jedoch dadurch, dass zum Zeitpunkt der technischen Umstellung nicht alle Anwendungen auf das neue Outputsystem migriert waren. Es wurden daher sowohl Komplettdokumente mit allen Farbinformationen geliefert, aber auch Dokumente, die eigentlich einen vorgedruckten Geschäftsbriefbogen erfordern.
Die Lösung bestand an der Stelle darin, einen zusätzlichen virtuellen Schacht zu implementieren. Dazu wurde die Schachtsteuerung, die eigentlich der korrekten Zuführung der vorgedruckten Briefbögen dient, beibehalten. Die in der Schachtsteuerung mitgelieferte Kennung des zu verwendenden Vordrucks wurde mit einem entsprechenden Image des Briefbogens gemapped. Für die Produktion werden die Druckdaten mit den Images zusammengeführt, so dass die Dokumente in einer verarbeitbaren Form vorliegen.
Die so produzierten Druckseiten werden wieder aufgerollt und dann an der Kuvertieranlage weiterverarbeitet. Zunächst erfolgt der Schnitt auf Endformat (aktuell DIN A4). Abhängig von der späteren Kuvertgröße erfolgt eine Bruchfalzung (1fach oder 2fach) aller zu einer Sendung gehörenden Blätter. Das Sendungspaket wird nach Bedarf um Beileger ergänzt und automatisiert in Kuverts verpackt.
In einem weiteren Schritt wurde die Steuerung dahingehend erweitert, dass Teilgruppen in den Sendungen (eine Gruppe zusammenhängender Einzelseiten) mit einem Kennzeichen zur Heftung versehen werden können. Dies erlaubt eine maschinelle Heftung im Verarbeitungsprozess. Die bereits kuvertierten Sendungen können am Ende noch individuell farbig bedruckt werden. Die Kuvertieranlage wurde um ein entsprechendes Inkjet-Modul erweitert, um Text oder Grafiken im Prozess aufzubringen.
Der letzte Punkt der Prozesskette betrifft die Versandsteuerung. Die produzierten Einzelsendungen werden in Postkisten aufbereitet und an den Versanddienstleister übergeben. Im Zuge der Optimierung wurden weitere Partner mit hinzugenommen. Die Steuerung wurde daher dahingehend erweitert, das Sendungsaufkommen zu splitten. Zu diesem Zweck wurde in die Anwendung zur Portooptimierung und Versandaufbereitung ein Geocoder integriert. Dieses Modul erlaubt die Steuerung nach Geodaten, um die Sendungen zum Beispiel nach Postleitzahlen zu trennen. Über eine entsprechende Erweiterung der Postkistenverarbeitung können so teilautomatisiert unterschiedliche Postauflieferungen realisiert werden.
Betriebswirtschaftlich führten die skizzierten Investitionen in die Transformation der Verarbeitung zu erheblichen Einspareffekten. Neben einem geringeren Personaleinsatz konnten auch die Sachkosten deutlich reduziert werden. Ergänzt wird dieser Effekt durch eine deutlich größere Flexibilität bei der Steuerung und Umsetzung von fachlichen Anforderungen. Durch die Verwendung neutraler Papierrollen ergibt sich zudem eine positive Umweltbilanz, da weniger vorkonfektionierte Papierbögen bei fachlichen Änderungen vernichtet werden müssen.
8.5 Ausblick
Wie haben gesehen, welche Herausforderungen auf Versicherungsunternehmen im Kontext der Flexibilisierung des Outputmanagements warten und mit welchen Methoden und Technologien hier Lösungen geschaffen werden können.
In Bezug auf den in der Einleitung beschriebenen Trend der „Digitalisierung“ ist dies nur ein Etappenziel auf dem Weg zur Erfüllung der Kundenerwartungen. Kommunikation auf jedem Kanal, verbunden mit der Möglichkeit, den Kanal flexibel und zeitlich unabhängig zu verändern, wird ein wichtiges Element sein. Dass die Informationen kanalgerecht aufbereitet und präsentiert werden, versteht sich dabei fast schon von selbst.
Ergänzt wird diese Erwartung durch die Forderung, dass alle Beteiligten jederzeit Transparenz über den Fortschritt der zugrunde liegenden Transaktion und den dazugehörigen Inhalt haben. Konkret: Die Kommunikation über schnell zugängliche Kanäle, wie E-Mail oder WhatsApp, verfehlt ihr Ziel, wenn der Kunde beim Anruf im Service-Center oder bei seinem Vermittler nicht die identische Information erhält. Der Begriff Omnichannel-Management erhält daher eine weitere Dimension, die sich als Synchronität von Informationen beschreiben lässt.
Sind diese Herausforderungen gemeistert, so lassen sich weitere Evolutionsstufen deutlich einfacher in den Outputprozess integrieren. Im Kundensinne freuen wir uns auf diese Entwicklungen: Personalisierte Videos, die Versicherungsbedarf und Leistungsumfang adressatengerecht erläutern, personalisierte Botschaften, die eine Beitragsanpassung wirklich erklären und vieles andere mehr.