Mit intelligenter Automation Krisen beherrschen - Fall 6 #Marketing #Kampagnenmanagement


Der Trend hin zum digitalisierten- und automatisierten Marketing und Kundenkontakt wurde durch Covid-19 stark beschleunigt. Wenn der persönliche Maklerkontakt ausfällt, bleibt nichts anderes übrig, als die Produkte online zu bewerben und damit den Bedarf digitalisiert und möglichst automatisiert zu wecken. Um solche Prozesse entwickeln zu können, wird ausgefeilte Software benötigt. Der Erfolg liegt hier einerseits in der Kreativität von Marketingkampagnen, aber auch in den zugrundeliegenden Lead- und Kundendaten. Nur auf Basis einer spezifischen Datenanalyse kann der Inhalt personalisiert und terminiert an den Interessenten oder Kunden geliefert werden. Diese Daten abzufragen und hierauf möglichst präzise Cluster zu erstellen, erweist sich als sehr anspruchsvoll, besonders in einer heterogenen Anwendungslandschaft. In diesem Blogeintrag stellen wir mehreren Anwendungsfälle im Marketing vor, wo RPA durch Automatisierung und entsprechende Datenaufbereitung unterstützen kann.

Fachbereich: Marketing und Vertrieb
Sparte: Allgemein
Anwendungsfall: Kampagnenmanagement und - Durchführung

Datenaufbereitung

Eine heterogene Anwendungslandschaft in der Marketings- und Vertriebsabteilung behindert nicht nur die Automatisierung von Marketingkampagnen, sondern führt zu zeitintensiven und repetitiven manuellen Tätigkeiten für den Sachbearbeiter, wie z.B. die Zuweisung bzw. das „Zumappen“ der Leaddaten aus dem Automatisierungstool in das CRM-System oder die Lead- bzw. Vertriebsdatenbank. Diese manuellen Aufgaben kann ein RPA-Bot übernehmen und zusätzlich über den Bearbeitungsweg des Leads entscheiden. Der Bot wertet die erhaltenen Daten (über Verhalten, Einwilligung, Interesse usw.) aus und weist dementsprechend einen Score-Wert zu. Je nach Höhe des Scores, benachrichtigt der Bot entweder die Vertriebsabteilung über die qualifizierten Leads, oder richtet die Daten direkt für Weiterbearbeitung ein (sehe Abbildung 1). Der Bot kann je nach Anforderung unterschiedlich gestartet werden: entweder werden Leads direkt einzeln im Anschluss an die Aufbereitung der Kundendaten qualifiziert und weitergeleitet, oder zeitlich geplant, z.B. jeden Morgen in einer Batchverarbeitung.






Next Best Action

RPA-Lösungen kann nicht nur bei der Verwaltung der Leaddaten unterstützen, sondern auch automatisierte Marketingprozesse starten und die Informationen dazu zur Verfügung stellen. Beispielsszenario: der Kunde ist für eine Rückzahlung der Beiträge durch seine KFZ-Versicherung berechtigt, weil vergleichsweise wenige km gefahren wurden und somit die Fahrleistung einen bestimmten Grenzwert unterschritten hat. In diesem Fall kann das RPA-Bot anhand der vordefinierten Regeln ausrechnen, ob sich ein Umstieg in einen Telematik-Tarif für den Versicherungsnehmer lohnt. Falls ja, sammelt der Bot die Kontaktdaten aus dem Drittsystem und lässt dem Kunden über den bevorzugten Kommunikationskanal ein entsprechendes Angebot zum Telematik-Tarif zukommen.

Viele Grüße

Petra Horvath

P.S.: Nähere Informationen sowie unser Leistungsangebot finden Sie unter: ppi.de/rpa-versicherungen

CarHack: Wenn der Hacker den Airbag fernsteuern kann

Linke Spur auf der Autobahn. Der Tacho klebt an der 250 Km/h-Marke. Stellen Sie sich vor, dass Ihr Auto in dem Moment eine Vollbremsung durchführt. Oder das Airbag auslöst. Was dann passieren kann, mag man sich gar nicht vorstellen. Theoretisch könnte es allerdings sein, dass ein Hacker das Auto „fernsteuert“ und die beschriebene Situation herbeiführt. In diesem Blogbeitrag möchte ich Sie etwas über potentielle Gefahren durch Carhacks aufklären.
Wie kommt es überhaupt dazu, dass Hacker Autos manipulieren können?

Früher wurden Autos rein mechanisch betrieben. Seit dem 21 Jahrhundert hat sich das schlagartig verändert. Mittlerweile könnte man fast sagen, dass die neuesten Modelreihen der Automobilindustrie fahrende Computer sind. Es werden mehrere Kilometer Kabel pro Auto verbaut und 90% der Weiterentwicklung im Automobilbereich stammen aus den Bereichen Elektronik und Software (Quelle: https://www.auto.de/magazin/acht-kilometer-kabel-im-auto/).

Mittlerweile gibt es schon Autos, die selbst bzw. autonom fahren können. Und überall, wo Software und Computer eingesetzt werden, ergeben sich Angriffsfelder für Cyberkriminelle.

Welche Risikoszenarien gibt es?

Grundsätzlich gibt es drei Risikoszenarien, die im Zusammenhang mit Carhacking stehen:

1. Diebstahl: Hacker manipulieren auf elektronischem Weg das Zugangssystem und die Wegfahrsperre für einen Diebstahl des Fahrzeugs.

2. Funktionsstörung: Ein Fahrzeug wird gehackt, und es kommt zunächst nur zu einer Funktionsstörung, zum Beispiel, um Lösegeld zu erpressen.

3. Unfall: Durch einen Hackerangriff wird ein Unfall initiiert, der zu Schäden am

Fahrzeug, aber auch zu Personenschäden führen kann.

Wie groß ist die Gefahr?

Die gute Nachricht vorweg: Glücklicherweise spielen Cyberangriffe bei dem schlimmsten Risikoszenario, Unfall durch Cyberangriff, aktuell kaum eine Rolle. So hat die Allianz nach eigenen Aussagen noch keinen Schadensfall durch einen Unfall, der auf eine Cyberattacke zurückzuführen ist, wahrnehmen können. Gleiches gilt für die Funktionsstörung. Nichtsdestotrotz ist das Szenario nicht unrealistisch, dass ein Hacker auf einen Knopfdruck alle Fahrzeuge eines bestimmten Typs lahmlegt und erst gegen Bitcoin wieder freischaltet. Nicht bloß ein Zukunftsszenario, sondern bereits Realität ist der durch einen Hackerangriff ermöglichte Diebstahl eines Fahrzeugs. Dem Hacker gelingt es dabei, Tools zu entwickeln, mit denen der elektronische Schlüssel des Fahrzeugs überwunden werden kann. Dies liest man immer mal wieder in den Medien.

Wie kann man sich als Verbraucher schützen? 

Richtig wehren kann man sich leider als Verbraucher nicht. An dieser Stelle ist man zu sehr vom Automobilhersteller abhängig. Man sollte sich jedoch Gedanken machen, dass wenn man Opfer einer solchen Cyberattacke wird, dass man zumindest finanziell gut abgesichert ist. Es lohnt zu prüfen, ob in der Vollkaskoversicherung Cyberattacken mitversichert sind oder man diese inkludieren lassen kann. Denn nichts ist ärgerlicher, als wenn Sie als Verbraucher auf dem Schaden sitzen bleiben. Wie kulant die Fahrzeughersteller in solchen Fällen sind, wird die Zukunft zeigen.

Mit freundlichen Grüßen

Linus Töbke



Mit intelligenter Automation Krisen beherrschen - Fall 5 #Sachversicherung #Schadenbearbeitung

Die politischen Maßnahmen der Bundesregierung als Reaktion auf die anhaltende Corona-Epidemie haben weitreichende Auswirkungen auf unser Wirtschaften und unser Zusammenleben. Unter dem Stichwort „Social Distancing“ mussten ganze Industriezweige, wie z.B. das Hotel- und Gaststättengewerbe und der Tourismus zwischenzeitlich ihren Betrieb gänzlich einstellen. Folglich verzeichnen viele Unternehmen starke Umsatzeinbußen und befinden sich in einer wirtschaftlichen Schieflage. Betriebsschließungen, Insolvenzwellen und Kreditausfälle führen zu einer erhöhten Anzahl von Schadenmeldungen und damit zu einer hohen Last in den Schadenabteilungen. Hinzu kommt, dass in Zeiten von Covid-19 mit Kapazitätsengpässen zu rechnen ist, da viele Mitarbeiter krankheitsbedingt ausfallen oder etwa die Kinderbetreuung (teilweise) übernehmen müssen.

In unserem heutigen Blog zeigen wir am Beispiel der Sparten Sach / KFZ wie die Schadenbearbeitung automatisiert und repetitive Arbeitsschritte wie z.B. die Schadenanlage in verschiedenen Systemen durch einen Roboter gesteuert werden können. Die dadurch gewonnene Zeit können Sachbearbeiter für die umfangreiche Prüfung der Schadenakte verwenden. Der positive Nebeneffekt: die Schadenbearbeitung geht wesentlich schneller und die Kundenzufriedenheit steigt.

Fachbereich: Schaden
Sparte: Sach / KFZ
Anwendungsfall: Automatisierte Schadenbearbeitung

Was können Roboter leisten?

In der Schadenbearbeitung gibt es eine Vielzahl einfacher, immer wiederkehrender Arbeitsschritte. Schadenmeldungen müssen eingesehen, Schäden in einem oder mehreren Systemen angelegt, Zahlungen aufgegeben und Dokumente archiviert werden. Gerade zu Peakzeiten (z.B. erhöhte Last aufgrund von Corona) kosten solche Aufgaben viel Zeit, die Sachbearbeiter an anderer Stelle besser einsetzen könnten. Hier kann ein Roboter genutzt werden, der automatisch Schadenfälle im Schadenverwaltungssystem anlegt, Gutachter beauftragt, Dokumente erzeugt, archiviert und versendet. Gegebenenfalls können auch zugehörige Buchungen, wie z.B. Entschädigungszahlungen oder Sachverständigenkosten, in den nachgelagerten Umsystemen vorbereitet oder unter Einhaltung der Compliance-Vorgaben des Unternehmens ganz ausgeführt werden. Roboter schließen Systemgrenzen zwischen Anwendungen, die sonst der Mensch manuell überbrücken müsste.

Schnelle Integrierbarkeit von automatisierter und KI-gestützter Entscheidungsfindung


Gerade im Bereich der KI-gestützten Entscheidungsfindung sind die Einsatzmöglichkeiten von RPA vielschichtig und besonders erfolgsversprechend. Für Schadenfälle im Zusammenhang mit KFZ- Haftpflichtversicherungen, wo Lockerungen der Corona-Maßnahmen zu einem erneuten Anstieg der Fallzahlen geführt haben, kann beispielsweise automatische Bilderkennung bzw. Image Recognition eingesetzt werden. Eine selbstlernende Software hilft, Foto-Aufnahmen von KFZ-Schäden zu analysieren und unterstützt somit bei der Entscheidungsfindung. Im Falle von Unwetterschäden im Rahmen der Hausrat- oder Wohngebäudeversicherung müssen oftmals zeitintensive Wetterdatenprüfungen in anderen Systemen vorgenommen werden. Hier kann eine KI integriert werden, um eine Plausibilitätsprüfung der Wetterdaten durchzuführen und so den Sachbearbeiter zu entlasten.

Der Faktor Mensch bleibt wichtig


Trotz eines immer höheren Automatisierungsgrades in den Schadenabteilungen der Versicherer bleibt der Faktor Mensch immens wichtig. Maschinen können bisher nur in den wenigsten Fällen umfangreiche Schadenfallprüfung durchführen und Gutachter sowie den Kundenservice vollständig ersetzen. Vielmehr geht es darum, die am Schadenfall beteiligten Experten so gut es geht zu unterstützen und ihnen Zeit für Ihre Kernaufgaben zu verschaffen.

Viele Grüße,

Konstantin Starke

P.S.: Nähere Informationen sowie unser Leistungsangebot finden Sie unter: ppi.de/rpa-versicherungen

Tagebuchauszug eines Product Owners - Teil 2 mit Tim Sonntag

Es geht weiter: Hier kommt der zweite Teil der neuen Blogbeitragsserie "Tagebuch eines Product Owners" - Wir berichten aus unserem Alltag als Product Owner in Versicherungsunternehmen.* Ziel ist es Ihnen, unsere Herausforderungen der Praxis zu transportieren. Sollte Ihnen gefallen was wir berichten, würden wir uns freuen, Sie auf unserer Website begrüßen zu dürfen.

Los gehts mit dem zweiten Beitrag von mir Tim Sonntag:

 
07:00 Uhr: Die neue Normalität… Um 7 Uhr startet der Tag. Warum so spät? Seit dem der Großteil unseres Projektes aus dem Home-Office arbeitet fallen an vielen Tagen die Reise- und Rüstaufwände deutlich geringer aus oder entfallen sogar komplett… Direkt aus dem Bad mit einem kurzen Abstecher in der Küche, am mittlerweile gut ausgestatteten Arbeitsplatz im Büro angekommen.

07:30 Uhr
: Ran die Mails, die sich angesammelt haben. Das war zumindest der Plan… Und schon klingelt das ViKo-Tool und der Chat schmeißt drei neue Nachrichten raus. Die Zusammenarbeit mit den doch zunächst neuen und etwas hakelig laufenden Tools - lääääuft! ;-)

08:30 Uhr: Nach den ersten (unter uns: viel zu frühen🤪, ungeplanten Telefonaten mit den Kollegen aus dem Team), meldet sich der fachliche Projektleiter. Es gibt Abstimmungsbedarf zu dem von den Kollegen aus der Entwicklung erstellen Angebot für die Umsetzung des kommenden Releases. Die Wichtigkeit wird mit Blick auf den Kalender schnell deutlich. Bald gehen wir mit der nächsten Komponente in Produktion. Das Angebot muss also schnell beschlossen werden, damit mit der Umsetzung begonnen werden kann.

9:42 Uhr: Die Unstimmigkeiten sind ausgeräumt. Die im Angebot fehlenden Anforderungen werden nachgetragen. Befürchtete Lücken oder gar fehlende Konzepte, die eine Schätzung im Angebot unmöglich machten, sind nach wenigen Klicks im Confluence gefunden und mit den Anforderungen verlinkt, sodass nun alles fehlende ergänzt werden kann. So ist das eben in den Los Wochos 🌮 – wie wir mittlerweile intern die Tage der Angebotserstellung nennen.

09:45 Uhr: Jetzt schnell ins Daily zu den Kollegen. Taskboard auf, fix die im vergangenen Planning formulierten Sprint-Goals in den Fokus rufen und los geht’s.

09:52 Uhr: Das Ausschweifen des Dailys verhindern. Konzentration auf das Wesentliche, auf die Sprint-Goals. Details gern in den entsprechenden Runden im Nachgang klären… Und da hat doch wieder einer nicht seine Aufwände auf die dafür vorgesehenen Tasks gebucht... Warum macht das der PO? In der Praxis gibt es nicht immer DEN PO und DEN Scrum-Master. Wir haben für uns als Projekt die bestmögliche „agile Organisation“ gefunden, die sich immer weiterentwickelt, aber definitiv nicht rein nach Lehrbuch funktioniert.

10:07 Uhr: Doch wieder das Daily überzogen. Aber bei mittlerweile mehr als 10 Kollegen, die von fachlich komplexen Zusammenhängen und Erkenntnissen berichten, vertretbar. Kurz mal durchschnaufen und dann endlich an die Mails.

12:00 Uhr: Jetzt der Nachteil des Home-Office… Das Essen mit den Kollegen beim Inder um die Ecke oder in der Kantine gegenüber fällt leider flach. Schnell in die Küche huschen und den Inhalt des Kühlschranks einem kritischen Blick unterziehen. Okay… Doch schnell zum Bäcker nebenan ;-)

12:45 Uhr: Die Vorbereitung des nächsten Plannings steht an. Klingt trivial, aber erstmal den Termin am Donnerstag bei den Kollegen blocken. Schnell den neuen Sprint erstellen und schonmal die Kollegen bitten ihre Abwesenheiten für den Zeitraum zu erfassen. Spart am Ende im eigentlichen Meeting Zeit. Ist das eine originäre PO-Aufgabe? Bei uns ja. Warum auch nicht?

13:00 Uhr: Welche Themen haben wir denn vom letzten Gremium, welches uns die Themen mit ihren Anforderungen zur Konzeption freigibt denn „genehmigt“ bekommen? Ein Glück haben wir die Entscheidungen alle zentral und transparent im Confluence-Bereich Organisation dokumentiert. Schnell mal im Protokoll nachschauen und dann die Stories dazu erstellen.

14:30 Uhr: Die Stories sind entsprechend der Gremien-Entscheidung erstellt und priorisiert im Backlog abgelegt. Bei der Gelegenheit habe ich direkt alte, überholte Stories aus dem Backlog geworfen. Schön oedentlich sieht das jetzt wieder aus ;-) Die zu berücksichtigenden Anforderungen sind verknüpft. Das Planning kann also kommen.

14:42 Uhr: Unser Hund muss kurz vor die Tür… Endlich, kurze Chance Luft zu schnappen und einen klaren Kopf vor der Befundbesprechung zu bekommen. Trotz der vielen Videokonferenzen, gar nicht so schlimm das Home-Office.

14:55 Uhr: Ich bin bereit für die Befundbesprechung mit Kollegen aus der Entwicklung und dem Test-Team. Gestern habe ich mir schon die anstehenden Bugs/ Abweichungen oder waren es doch Features angesehen. Da gibt’s einiges zu besprechen…

14:56 Uhr: Nicht schon wieder ein Anruf per ViKo aus der Reihe, aber es ist bestimmt wichtig. Ich denke 4 Minuten reichen.

15:03 Uhr: Die restlichen ToDos der Story sind mit dem Kollegen besprochen und die Verwirrung hat sich aufgelöst. Lieber einmal zu viel als zu wenig darüber sprechen. Jetzt aber ab in die Befundbesprechung… „Sorry für die Verspätung, ihr wisst ja wie das zurzeit ist …“

15:10 Uhr: Jetzt sind wir endlich vollzählig. Es geht also doch allen gleich. Viele Anrufe und noch mehr Videokonferenzen. Immer erreichbar wenn das ViKo Tool (ausversehen?) auf „grün“ steht… ;-)

16:00 Uhr: Es ist wie so oft. Die für uns als Fachseite offensichtlich kleinen Anpassungen ziehen große Implikation auf Seiten der IT nach sich. Eine kleine Plausibilitätsänderung (in ca. 2 Minuten beschrieben) lässt die Entwickler verzweifeln. Letztlich geht es um Lösungen und um eine Software, die den Anwender in seiner Arbeit bestmöglich unterstützt. Gemeinsam finden wir einen Kompromiss und können die Anpassung noch berücksichtigen. Ein enger Austausch der Entwickler und der Fachseite ist dafür zwingend erforderlich. Wieder frage ich mich, warum das nicht schon früher aufgefallen ist. Aber Hauptsache wir haben eine gute Lösung.

16:15 Uhr: Da war doch noch was… Ah ja, die angesammelten Mails. Abstimmungsbedarf bzgl. der Konzeption, Fragen der Kollegen aus dem Test zu den neu geplanten Features und und und. Jetzt aber ran an den Speck.

16:17 Uhr: ViKo-Tool auf „bitte nicht stören“ setzen… Fast vergessen, Glück gehabt ;-)

17:30 Uhr: Geschafft. In der Menge der Mails noch die eine oder andere Anforderung identifiziert, die es zu bewerten gilt. Das kann dann aber doch noch bis morgen früh warten…



Kennen Sie solche Tage auch? - An dieser Stelle möchten wir Ihnen danken, dass Sie unseren Beitrag gelesen haben und laden Sie herzlich an unserem kostenfreien sowie virtuellen Austausch "Meet & Greet der Product Owner" am 01. Oktober 2020 - 16:00 -18:00 Uhr teilzunehmen. Melden Sie sich hier unverbindlich für die Websession an.

Preview: Am 07. Oktober 2020 erzählt Ihnen meine Kollegin Katrin Paul von ihrem Alltag und Erfahrungen als Product Owner. Bis dahin.

Viele Grüße
Ihr Tim Sonntag


* Wir berichten in dieser Beitragsserie aus unserem Alltag als Product Owner in Versicherungsunternehmen. Natürlich ist ein Rückgriff auf Unternehmen, Personen oder konkrete Projekte nicht möglich. Jeder Autor erzählt aus seinen persönlichen Erfahrungen.


Tim Sonntag | Senior Consultant | PPI AG



Cyberwiki E wie Exploit #CyberABC

„Hacker haben mit Hilfe eines Exploit ...“ oder „Zero Day Exploit“ liest man immer mal wieder in der Presse. Doch was ist überhaupt ein Exploit? In diesem Blogbeitrag unseres CyberWiki erkläre ich Ihnen kurz und verständlich in „normalem“ Deutsch, was es mit dem Exploit auf sich hat.

Wenn ein Cyberkrimineller sich in ein Unternehmen hacken möchte, dann kann man das mit einem Einbrecher vergleichen, der sich Zugang zu einem physischen Gebäude verschaffen möchte. Und wie geht ein Einbrecher in der Regel vor? Er sucht das Gebäude nach Schwachstellen bzw. einfachen Einstiegspunkten ab. Denn warum sollte er es sich schwer machen und z.B. die gut gesicherte Eingangstür aufbrechen, wenn doch 10 Meter weiter ein Fenster offen steht? Der Einbrecher nimmt immer den für ihn leichtesten Weg, um in das Gebäude einzudringen. Ähnlich geht auch ein Cyberkrimineller vor. Dieser sucht in der IT-Infrastruktur des Unternehmens nach Schwachstellen, um sich Zugang zu den Firmensystemen zu verschaffen.

Wenn ein Angreifer nun eine Schwachstelle identifiziert hat, dann muss er diese „angreifen“, um in das System einzudringen. Diesen Angriff nennt man Exploit. Hacker, die die sogenannte „Hackerethik“ beherzigen auch „Whitehats“ genannt, wenden sich oft an die Öffentlichkeit, um auf Schwachstellen aufmerksam zu machen. Sie verfolgen meist nicht das Ziel, aus der Ausbeutung von Schwachstellen persönliche Vorteile, wie finanzielle Gewinne oder bewusste wirtschaftliche Schäden Dritter, zu ziehen. Durch die Veröffentlichung werden meist recht schnell Patches zum Schließen der ausgebeuteten Schwachstellen zur Verfügung gestellt (z.B. unter https://www.securityfocus.com/).

Hacker, die nicht die Hackerethik leben, sondern hauptsächlich Cyberkriminelle sind, können diese Schwachstellen für ihre Zwecke ausnutzen, ohne selber über großes technisches Know-how verfügen zu müssen. Stellen Sie sich mal vor, dass eine Autoreihe eines großen Herstellers eine Sicherheitslücke in dem Keyless Go-Verfahren[1] hat. Ein Angreifer kann mit einem „Fake-Schlüssel“ den eigentlichen Schlüssel nachahmen und so den Motor starten. Dieser „Fake-Schlüssel“ wäre dann der Exploit und auch ein Laie könnte ohne technisches Verständnis mit dem „Fake-Schlüssel“ irgendein Auto der betroffenen Serie entsperren und losfahren.

Wirklich schützen kann man sich gegen Exploits nur, wenn man immer die aktuellsten Patches so schnell wie möglich einspielt. Dadurch funktioniert der Exploit nicht mehr und der Angreifer kann nicht in ihre IT-Infrastruktur eindringen bzw. wie in dem Keyless GO Bespiel das Auto nicht öffnen.

Problematisch wird es bei sogenannten Zero-Day-Exploits. Diese sind im Prinzip normale Exploits mit der Besonderheit, dass die Schwachstelle direkt am ersten Veröffentlichungstag ausgenutzt wird. Somit gibt es noch keinen Patch, um die Sicherheitslücke zu schließen. Eine Cyberversicherung kann hier zumindest die finanziellen Schäden kompensieren.

Mit freundlichen Grüßen

Linus Töbke


[1] Unter Keyless GO versteht man eine Technologie, bei der ein Auto ohne aktive Benutzung des Schlüssels entriegelt und gestartet werden kann. In der Regel genügt es den entsprechenden Schlüsselersatz (z.B Chipkarte) am Körper zu tragen.

Mit intelligenter Automation Krisen beherrschen - Fall 4 #Inkasso #Vertragskündigung

Mittlerweile haben wir Wege gefunden, wie wir privat und beruflich mit den krisenbedingten Rahmenbedingungen zurechtkommen können. Unter dem Stichwort „neue Normalität“ bewältigen wir unseren Alltag. Dazu gehört auch, dass wir unseren wohl-verdienten Urlaub nehmen und es so auch in diesem Jahr wieder vorkommt, dass sich in den Sommermonaten „Arbeitsvorräte“ in den Versicherungsunternehmen sammeln, die viel Zeit in Anspruch nehmen.
In unserem heutigen Blog zeigen wir am Beispiel Beitragseinzug KFZ auf, wie RPA Vorgänge automatisch abzuwickeln und so Versicherer bei der Vorgangsprüfung unterstützen kann. Dadurch wird Bearbeitungszeit für Routineaufgaben eingespart, die an anderer Stelle wiederum für wertschöpfende Tätigkeiten eingesetzt werden kann.

Fachbereich: Inkasso
Sparte: KFZ
Anwendungsfall: Zahlung nach erfolgter Vertragskündigung

Häufig kommt es vor, dass Kunden Ihren Zahlungsverpflichtungen nicht nachkommen (dies ist vor allem in „Corona-Zeiten“ gehäuft der Fall). In diesen Situationen muss in der KFZ-Haftpflicht-Versicherung den säumigen Beitragszahlern der Vertrag gekündigt werden. Viele Kunden zahlen jedoch ihre offenen Beiträge – vollständig oder teilweise – zur oder unmittelbar nach der Kündigung. Nun beginnt eine anstrengende und zeitraubende Detektivarbeit für den Sachbearbeiter.

Genau hier setzt RPA als „digitaler Assistent“ ein: Kollege Roboter führt nun voll-automatisch die Arbeitsschritte „Suche & Validierung Zahlungseingang“, „Vertragssuche“, „Prüfung Höhe Beitragszahlung zu offenen Posten“, „Zuordnung Zahlung zu Vertrag“ usw. durch.

Beispiel-Prozess zur Automatisierung von Zahlungen nach erfolgter Vertragskündigung

 Die langwierige und repetitive Identifikation und Suche der Vorgänge in Software-Programmen, die normalerweise von Sachbearbeitern durchgeführt wird, übernimmt der Bot voll-automatisch. Können die Ergebnisse eindeutig zugeordnet werden, aktualisiert der Bot die Kundeninformationen. Muss der Sachbearbeiter einige Schritte von Hand prüfen, werden ihm diese Vorgänge automatisch zugesteuert.

Folglich werden die meisten Vorgänge automatisch abgearbeitet. Sollte der Vertrag durch die zugeordnete Zahlung fortbestehen bzw. wieder aufleben, werden die notwendigen Schritte – z. B. Information an die Zulassungsstelle – eingeleitet.

Auch an diesem Beispiel wird sehr deutlich, wie RPA dabei hilft, die Sachbearbeiter – gerade in der jetzigen Krisenzeit – nachhaltig durch die Automatisierung von einfachen Arbeitsschritten zu entlasten und nachhaltige Kundenbeziehungen zu bewahren. Dadurch werden nicht nur Kosten eingespart und Arbeitsrückstände vermieden, sondern auch die Servicequalität enorm verbessert. Dies wird Kunden auch in Zeiten nach der Krise positiv in Erinnerung bleiben.

Nähere Informationen sowie unser Leistungsangebot finden Sie unter: ppi.de/rpa-versicherungen

Viele Grüße,

Dirk Daners & Konstantin Starke



Tagebuchauszug eines Product Owners - Teil 1 mit Ronny Kant

Endlich startet die neue Blogbeitragsserie "Tagebuch eines Product Owners" - Wir berichten aus unserem Alltag als Product Owner in Versicherungsunternehmen.* Ziel ist es Ihnen, unsere Herausforderungen der Praxis zu transportieren. Sollte Ihnen gefallen was wir berichten, würden wir uns freuen, Sie auf unserer Website begrüßen zu dürfen.

Und nun viel Spaß mit dem ersten Beitrag von mir Ronny Kant:

06:00 Uhr: Der Wecker klingelt… Erstmal die Schlummer-Taste drücken.

06.10 Uhr: Der Wecker klingelt schon wieder… Na gut, aufstehen, fertig machen, schnell das Frühstücksbuffet im Hotel nutzen und dann ab ins Büro.

07:30 Uhr: Die erste halbe Stunde gehört den unbeantworteten Mails und neuen Eingängen. Der Großteil ist nicht dringend, doch eine neue Anforderung hat sich implizit eingeschlichen, die nehme ich mal mit.

08:00 Uhr: Backlog-Pflege. Stimmt die Priorisierung? Sind alle notwendigen Informationen vorhanden? Ein, zwei Stories hatte ich vor den nächsten Sprint vorgesehen, aber da fehlt gefühlt noch alles: Business Value, Akzeptanzkriterien und Story Points. Was ist da los? Im Telefonat mit dem Kollegen aus dem Bereich Business Analyse stellt sich heraus, dass Vertrieb und Betrieb hier unterschiedliche Erwartungen haben – die müssen erstmal geklärt werden, dann lässt sich die Story auch vorbereiten für den nächsten Sprint. Denn: Nach dem Sprint ist während dem Sprint und vor dem Sprint – oder wie war das nochmal?🤔

09:00 Uhr: Kurz mit im Daily lauschen… Läuft! Das Format wird eingehalten, jeder kriegt einen guten Überblick und die Stimmung ist gut – so soll es sein.

09:15 Uhr: Ist die Kaffeemaschine eigentlich schon gelaufen? Völlig vergessen, einen heißen Kaffee kann ich jetzt erstmal gebrauchen.

09:30 Uhr: Heute steht eine Austauschrunde mit den Stakeholdern an. Die ungeklärten Stories sowie die Priorisierung der Features mit Hilfe des Business Values sollen hier nochmal besprochen werden. Das muss noch etwas vorbereitet werden. Business Analyst und ich stecken die Köpfe zusammen – natürlich virtuell – das ist der beste Abstand in Corona-Zeiten.

10.00 Uhr: Die Austauschrunde per WebEx startet. Mittlerweile haben sich auch alle gut daran gewöhnt. Was steht heute an? Kurzer Blick in das Backlog und die Releasplanung sowie Klärung, ob es neue Themen gibt. Für das nächste Release sind wieder drei Sprints vorgesehen, jedoch bedingt durch die Urlaubszeit mit deutlich reduzierter Kapazität. Umso wichtiger ist es, sich jetzt über die Priorisierung einig zu werden. Die relevanten Teamleiter sowie Kundenbetreuer sind zugeschalten. Wir haben uns angewöhnt, den Business Value qualitativ zu erheben, mit Hilfe einer Referenz-Story aus den Anfängen des Systems. Mit Hilfe dieser Baseline stimmen wir in der Runde ab, ob neue Anforderungen u.a. in den Bereichen: Kundennutzen, Betriebsnutzen, Risiko, wirtschaftliche Vorteile wertvoller oder weniger wertvoll als die Vergleichsstory sind.

13:00 Uhr:
Wir sind durch, es war hitzig und irgendwie sitzt man gefühlt immer zwischen den Stühlen, keine Frage, aber am Ende haben wir Einigkeit erreicht und für die Kunden/User ein super Päckchen für das nächste Release im Blick. Freue mich schon auf das Refinement und Planning mit dem Team. Jetzt erst mal Mittagessen…

14.00 Uhr:
Erkenntnisse aus der Stakeholderrunde müssen jetzt erstmal nach Jira gebracht werden. Aufräumen, sortieren, ergänzen… Fehlt da nicht eine Story? Drei Minuten später und ein kurzer Anruf beim Scrum Master: Die Story fehlt nicht, sondern ist bereits in Entwicklung – korrelierte stark mit einer anderen Anforderung im Sprint Backlog, daher hat sich das Team entschieden, dass schon mitzunehmen.

14:47 Uhr: Unser Scrum Matser kommt aufgeregt ins Büro – hatten wir nicht gerade telefoniert? Er meldet, dass wiederholt von einer Teamleiterin versucht wurde Änderungswünsche ins Projekt zu bringen. Hier müssen wir gegensteuern, aber: mit Augenmaß.

15:30 Uhr: Zum Glück ließ sich kurzfristig eine Telko mit der Kollegin organisieren. In der Runde beschreibt unser Scrum Master nochmal sensibel, wie der Prozess abläuft im Rahmen des erarbeiteten Vorgehensmodells und insbesondere warum. Ziel ist es ein Gleichgewicht zwischen Flexibilität hinsichtlich Anforderungen und Stabilität für die Entwicklung auf der anderen Seite hinzubekommen. Nur so ist gewährleistet, dass wir schnell auf neue Anforderungen der Auftraggeber oder Kunden reagieren können und bei der Umsetzung genügend Stabilität haben, um nicht nur qualitativ werthaltige Lösungen zu entwickeln, sondern auch ein zufriedenes Team zu halten.

Im Gespräch stellt sich heraus, dass die vermeintlich „kleine“ Anpassung in der Oberfläche – ein neues Attribut soll im Abschlussprozess vom User abgefragt werden – in Summer weitreichendere Folgen hat: Das neue Attribut dient einer angepassten Darstellung der erzeugten Rechnung und muss somit durch alle Folgesysteme gereicht und auch verarbeitet werden. Ich kann den Wunsch der Teamleiterin absolut verstehen und werden vor dem nächsten Sprint mit den übrigen Stakeholder klären, wie wichtig uns das Thema im Verhältnis zu den anderen, bereits vorgesehenen Stories ist. Reden hilft.

16:30 Uhr: Grobe Releaseplanung steht, Backlog ist aufgeräumt, jetzt heißt es kurz den morgigen Tag durchgehen, Termine vorbereiten und nochmal beim Team rein schauen, ob es offene Fragen gibt.

17:35 Uhr: Ab ins Hotel, Laufschuhe an und eine Runde durch den Wald joggen. Mal schauen, was morgen auf mich wartet…

Kennen Sie das auch? - An dieser Stelle möchten wir Ihnen danken, dass Sie unseren Beitrag gelesen haben und laden Sie herzlich an unserem kostenfreien sowie virtuellen Austausch "Meet & Greet der Product Owner" am 01. Oktober 2020 - 16:00 -18:00 Uhr teilzunehmen. Melden Sie sich hier unverbindlich für die Websession an.

Preview: Am 17. September 2020 erzählt Ihnen mein Kollege Tim Sonntag von seinem Alltag und Erfahrungen als Product Owner. Bis dahin.

Beste Grüße
Ihr Ronny Kant


* Wir berichten in dieser Beitragsserie aus unserem Alltag als Product Owner in Versicherungsunternehmen. Natürlich ist ein Rückgriff auf Unternehmen, Personen oder konkrete Projekte nicht möglich. Jeder Autor erzählt aus seinen persönlichen Erfahrungen.
Ronny Kant | Senior Consultant | PPI AG




Mit intelligenter Automation Krisen beherrschen - Fall 3 #Vermittlerwechsel #Bestandsübertragung


Je länger eine Krise dauert, um so wahrscheinlicher stehen auch einige Versicherungsvermittler unter enormen wirtschaftlichem Druck. Sei es, dass deren Kunden aufgrund wirtschaftlicher Nöte keine neuen Versicherungen mehr abschließen bzw. ihre laufenden Verträge herabsetzen müssen. Oder ganze Versicherungssparten sich nicht mehr vertreiben lassen, da der Versicherungszweck durch die Pandemie nahezu weggefallen ist – wie zum Beispiel Reiseversicherung oder Veranstaltungshaftpflicht. Daher ist zu erwarten, dass es im Herbst vermehrt zu Zusammenschlüssen und Geschäftsaufgaben seitens der Vermittler kommen wird. In diesen Fällen ist es dann notwendig, die die provisionsrelevanten Bestände bei dem Versicherer auf einen oder mehrere andere Vermittler zu übertragen. Dies ist in der Regel ein äußersts aufwendiger Prozess, da die hierfür benötigten Informationen oft in getrennten Systemen manuell gepflegt werden und händische Fehlerkontrolle und Qualitätssicherung erfordern.

Fachbereich: Vertriebsorganisation
Sparte: Diverse
Anwendungsfall: Vermittlerwechsel – Bestandsübertragung

Ein durch RPA unterstützer Prozess kann hier helfen, schnell und richtig die Bestandsübertragung durchzuführen in dem beispielsweise sehr große Excel Listen automatisch verarbeitet. Dabei wird ohne Mitarbeiter-Eingriff jeder Vertrag automatisch in Ihren Vermittler- und Bestandsführungssystemen angepasst und überprüft . Dieses Vorgehen reduziert Fehlerquellen durch Bedienfehler oder Datenübertragung enorm und verhindert, dass in Zeiten von rückläufigem Umsatz die Prozesskosten steigen. Die Konfiguration mittels Aufzeichnung von Arbeitsabläufen des Robots erfolgt in wenigen Tagen. Nach Test und Abnahme des RPA-Prozess erfolgt die Bestandsübertragung im Rahmen des Vermittlerwechsels innerhalb von Minuten – und nicht mehr wie vorher in Tagen.

Nähere Informationen sowie unser Leistungsangebot finden Sie unter: ppi.de/rpa-versicherungen

Viele Grüße
Juri Baltjan