Nutzung von BPM für die Belange eines Service Centers

Viele von euch haben bestimmt schon mal beim Service Center, auch bekannt als Callcenter, angerufen. Sicherlich aus verschiedenen Gründen: zum Beispiel, um zu erfahren, warum die Adresse im Portal immer noch die alte ist, obwohl sie schon mehrfach mit Hilfe eines Portal-Online-Services geändert wurde oder warum ihr immer noch die Informationen zu euren Beiträgen per Post bekommt, trotz der Anmeldung für ausschließlich elektronische Benachrichtigungen. Noch gravierender wäre folgender Fall: ihr könnt euch trotz der erfolgreichen Meldung nach der Registrierung in dem besagten Portal nicht anmelden. Unabhängig von der jeweiligen Branche gibt es immer einen kleinen Hinweis oder Link auf der Seite, namens „Kontakt“, unter dem die Telefonnummer des Service Centers zu finden ist, bei dem ihr schließlich anruft.

„Wie kann ich Ihnen helfen?“

Diesen Satz hört man dann meistens, wenn man sich entsprechend nach einigen Fragen des Service-Center-Mitarbeitenden authentifiziert hat. Nehmen wir das obere Beispiel mit der anscheinend erfolgreichen Registrierung, nach der man sich aber immer noch nicht im Portal anmelden kann. Ihr seid ein wenig verwirrt und manchmal sogar aufgebracht, erläutert dann dem Mitarbeitenden im Service Center die Situation und den Grund eures Anrufes. Typische Fragen an den Mitarbeitenden sind dabei: „Was ist denn passiert?“ oder „Wann kann ich mich einloggen?“.

Was sowohl Kunden sowie Service-Center-Mitarbeitende nicht wissen, ist, dass die Registrierung beispielsweise als asynchroner Prozess läuft. Dem Kunden wird direkt die Meldung „Die Registrierung war erfolgreich“ angezeigt, sobald er alle notwendigen Daten eingegeben hat. Der Service-Center-Mitarbeitende schaut in der Regel nur auf eure Daten, die ihm das Bestandsystem anzeigt und nicht auf den Prozess, den ihr angeblich erfolgreich abgeschlossen habt. Aus den Daten, die er sieht, kann meistens nur erkannt werden, ob der ein oder andere Schritt in der komplexen Registrierung durchlaufen worden ist. Aber welcher Schritt war denn nicht erfolgreich? Dazu fehlen dem Service-Center-Mitarbeitenden meistens die notwendigen Kenntnisse. Auch die Anzeige der Daten aus dem Bestandsystem gibt keine aufschlussreiche Auskunft. Was folgt, ist die ernüchternde Antwort: „Ich kann leider in unserem System nicht sehen, was genau schiefgelaufen ist. Aber ich nehme Ihre Daten auf und erstelle einen Incident dazu“. Schon seid ihr noch verwirrter oder gar enttäuscht, denn eure Erwartung ist, im Service Center den entsprechenden Service und Support zum jeweiligen Anliegen zu erhalten.

Was in dieser Zeit geschah

Besonders bei den großen Unternehmen, wo die Systeme sozusagen „historisch zusammenwachsen“ und immer komplexer und unübersichtlicher werden, greift man in der IT zu den Lösungen, die „pragmatisch“ erscheinen. Schließlich sind die Systeme schwer zu durchblicken und meistens fehlen auch die Fachkräfte, die das notwendige Know-how mitbringen. Nicht zuletzt spielt auch der Kostenpunkt eine entscheidende Rolle. Auch der zeitliche Druck, ein Produkt oder eine Lösung schnell auf den Markt zu bringen, führt dazu, dass eine nicht vollständig durchdachte Entwicklung entsteht. Man entwickelt somit eine Art „Notlösung“, die dann mit den nächsten Anforderungen womöglich verkompliziert wird. Oft werden auch die alten und bereits produktiv laufenden Prozesse genutzt und um eine weitere Iteration erweitert. Diese Prozesse schreiben zwar weiterhin die Daten in den großen Bestandsystemtopf, bringen aber für einen Service-Center-Mitarbeitenden nicht wirklich den gewünschten Durchblick, aus welchem Prozess die Daten stammen und in welchem Zusammenhang sie entstehen könnten.

In unserem Beispiel wäre es das Szenario, wenn der Kunde im System zwar als registriert markiert ist, ihm aber die Kommunikationsdaten (E-Mail-Adresse und die Mobilfunknummer) fehlen, die zum Beispiel beim asynchronen Schreiben aus irgendeinem Grund nicht vollständig im Bestandssystem gespeichert oder noch nicht hinein geschrieben werden konnten. Dadurch entsteht ein unvollständiger Kundendatensatz. Diesen kann ein Service-Center-Mitarbeitender zwar sehr oft ergänzen, den Datensatz jedoch nicht vervollständigen. Der Grund: nach dem Speichern der Kommunikationsdaten würde beispielsweise ein weiterer Schritt in der Registrierung angestoßen werden. Dieser Schritt ist dem Service-Center-Mitarbeitenden allerdings nicht bekannt. Es fehlt demnach die Übersicht über die gesamte Registrierungskette.

Wie wäre es, wenn die Prozesse von A bis Z durchdacht wären?

In Zeiten von Start-ups und Vergleichsportalen befindet sich die Versicherungsbranche in einem sehr stark umkämpften Markt. Die großen Versicherungsunternehmen mit ihren nicht oder kaum dynamischen Bestandsystemen haben meist Schwierigkeiten damit, schnell auf die Veränderungen zu reagieren. Es ist nicht mehr entscheidend, wie hoch oder niedrig der Versicherungsbeitrag ist. Moderne Kunden wollen auch eine gute Kundenbetreuung, auf die Verlass ist und zwar sowohl in einem Schadensfall als auch im Falle von Komplikationen, die im Portal entstandenen sind. Der Kunde möchte nicht nur vor dem Abschluss der Versicherung betreut werden, sondern auch während der Laufzeit dieser Versicherung und insbesondere dann, wenn er sich die Zeit nimmt und die freundlichen Mitarbeiterinnen und Mitarbeitern des Callcenters anruft - und diese Situation ist sicherlich vielen bekannt.

Wie könnte also eine Lösung in unserem Beispiel aussehen? Die mögliche Antwort ist ein Prozess der Registrierung, der mittels einer Process Engine modelliert und dem Mitarbeitenden im Callcenter bekannt oder gar ersichtlich ist. Sehr oft wird bei der Entwicklung einer Funktionalität im Rahmen des Portals oder einer kleinen Anwendung, wie beispielsweise der „Registrierung“, vergessen, sich eine entscheidende Frage zu stellen: „Was passiert, wenn der Kunde mit dem Prozess nicht klar kommt?“ und noch viel wichtiger „Wer oder was würde dabei dem Kunden helfen?“.

Ob Projekte agil, hybrid oder klassisch entwickelt werden, die Frage des Einsatzes einer Process Engine stellt sich, sobald Prozesse vom Kunden im Portal bedient werden. Je komplexer sie sind, desto größer ist die Wahrscheinlichkeit, dass beim Durchlaufen ein Fehler auftreten könnte. Der mittels BPM (Business Process Model) beschriebene und mittels Workflow Engine erstellte Prozess, kann vorteilhafterweise auch einem Service-Center-Mitarbeitenden zur Verfügung gestellt werden. Ruft der Kunde im Service Center an, kann der Mitarbeitende sehen, in welchem Schritt der Prozess einen Fehler hat. Der Kunde bekommt in dem Fall eine für ihn wichtige Auskunft und Hilfe. Der Service-Center-Mitarbeitende kann hierbei entweder die IT informieren oder den Prozess nochmal anstoßen – also wenn der Mitarbeitende dazu die entsprechenden Rechte hat. Ein weiterer Vorteil bei der Modellierung mittels BPM besteht darin, dass durch eine einfache Notation auch die Zuarbeit und die Erfahrungen von Kolleginnen und Kollegen aus dem Service Center inkludiert werden können. In dem Fall würde der Prozess nicht nur für ein Best Case „A“ erstellt werden, sondern auch für den möglichen Ausfall „Z“. Für beide Szenarien würde dies von demjenigen fachlich betrachtet werden, der am Ende des Tages mit dem Kunden in so einem Fall auch in Kontakt tritt.

Und nun …

Welche Workflow Engine man für die Erstellung eines Prozesses nutzt, ist nicht entscheidend. Davon gibt es sowohl kostenfreie (zum Beispiel Activiti, Camunda BPM) als auch kommerzielle Varianten (zum Beispiel Enterprise Architect, Tibco BW). Viel wichtiger ist hier aber die Frage, ob im Fehlerfall der Prozess vom Service Center betreut werden soll - schließlich meldet der Kunde den Fehler im Callcenter und nicht direkt bei der IT. Meistens sind es sogar Einzelfälle, bei denen ausschließlich für den Kunden eine Korrektur vorgenommen werden muss. In diesen Fällen sollte man auch eine Möglichkeit eines administrativen Zugangs für so einen Prozess für Service-Center-Mitarbeitende betrachten. Auf diese Weise kann nach einer Analyse der Prozess angestoßen und somit auch die IT entlastet werden.

Am Ende zählt selbstverständlich der Kunde, dem nicht nur direkt geholfen wird, sondern bei Bedarf auch erklärt werden kann, warum ein Fehler passierte - denn auch das gehört dazu. Ein behobener Fehler bringt dem Kunden nicht nur Freude, sondern auch Zufriedenheit und das ist es, was letztlich zählt - denn ein zufriedener Kunde bleibt.

Ihr möchtet erfahren, mit welchen Leistungen wir unsere Kunden im Versicherungssektor außerdem unterstützen? Dann werft einen Blick auf unsere Website.