Die größten Herausforderungen für Unternehmen ihre gesammelten Daten wertschöpfend auszuwerten, besteht darin, die verschiedenen Datenquellen zusammenzuführen, die Analyseergebnisse korrekt zu interpretieren und das fachliche Verständnis für die Bedeutung der Daten vorzuhalten. Ein Anwendungsbeispiel zeigt Faktoren, die jedes Analyse-Projekt gefährden können – und mögliche Gegenmaßnahmen.

Die Autorin:   Dr. Lisa Wagner beschäftigte sich schon in ihrem Studium der Mathematik und Informatik an der RWTH Aachen mit Data Analysis, Algorithmik und Optimierung. Gleichzeitig sammelte sie Erfahrungen in der Software-Entwicklung. Bis Anfang des Jahres arbeitete sie als IT Consultant bei MaibornWolff. Im Rahmen dieser Tätigkeit entstand auch die im Artikel beschriebene Analyse. Inzwischen arbeitet sie als Data Scientist bei ONE LOGIC. Der Artikel von Frau Dr. Lisa Wagner erschien zuerst im BI Spektrum der SIGS DATACOM GmbH.

BIG-DATA-TOOLS können Datenmengen darstellen, die weit über die Möglichkeiten von Excel hinausgehen. Gängige Mining-Algorithmen stehen als Bibliothek für quasi jede Programmiersprache zu Verfügung und können ohne großes Vorwissen verwendet werden. Trotzdem – oder gerade deshalb – tun sich viele Unternehmen schwer, ihre gesammelten Daten wertschöpfend auszuwerten.

Das Zusammenführen der verschiedenen Datenquellen, das fachliche Verständnis für die Bedeutung der Daten und die korrekte Interpretation der Analyseergebnisse stellen die größten Herausforderungen dar. Auch passt der agile, iterative Lernprozess einer Datenanalyse oft nicht zu den Wasserfall-artigen Strukturen vieler Unternehmen. Das Ergebnis sind falsche Erwartungshaltungen und Enttäuschung nach der ersten Iteration bis hin zum Abbruch des Projektes.

Anwendungsbeispiel abstrahiert reale Situationen in Projekten

Das lässt sich vermeiden, wie das folgende Anwendungsbeispiel zeigt. Es beginnt als sehr klar umrissene und von festen Vorannahmen belastete statistische Analyse und wird schnell zu einer ergebnisoffenen Prozessanalyse mit überraschenden Erkenntnissen. Dabei liegt der Fokus nicht auf der Anwendung eines besonders komplexen Algorithmus, sondern auf dem Wechselspiel von Erkenntnis und nächstem Analyseschritt. An diesem Beispiel zeigen sich eine Reihe von Faktoren, die jedes Analyse-Projekt gefährden können, und mögliche Gegenmaßnahmen. Das Beispiel abstrahiert reale Situationen in Projekten.

Die Tochtergesellschaft eines Weiße-Ware-Herstellers übernimmt alle anfallenden Aufgaben an Gemeinschaftswaschmaschinen in Wohnanlagen. Sie betreut das System für das Reservierungsmanagement, übernimmt Support und Abrechnung und ist für die Wartung der Maschinen zuständig. Mieter starten Waschvorgänge mit ihren Kundenkarten an einem Lesegerät, das mit der Maschine verbunden ist. Über eine App mit persönlichem Login können sie zusätzlich Zeiten reservieren. Bei Problemen ruft der Kunde die Support-Hotline an.

Die Maschinen vollziehen den Ablauf einer Buchung über Zustände mit vorgegebenen Zustandsübergängen nach. Diese werden zum Beispiel durch Eingaben des Benutzers ausgelöst. Diese Zustände lassen sich grob in Nutzungsphasen einteilen:

  • „Nutzbar“: die Maschine wird aktuell weder benutzt noch ist sie vorreserviert.
  • „Reserviert“: Ein Kunde hat die Maschine reserviert. Es handelt es sich um eine zeitlich begrenzte Vorreservierung via App, ein echtes Zeitbuchungssystem gibt es nicht.
  • „Einstellungen für Wäsche“: die Buchung ist gestartet, aber noch kein Waschgang.
  • „Waschvorgang“: der eigentliche Waschvorgang.
  • „Warten auf Öffnung“: der Waschgang ist vorbei, der Kunde hat die Tür aber nicht mit seiner Karte geöffnet.
  • „Buchung beenden“: der Kunde hat die Tür mit seiner Karte geöffnet. Er kann nun einen weiteren Waschvorgang anstoßen oder sich mit seiner Karte abmelden; in diesem Zustand fährt die Maschine automatisch eine Reihe Checks.

Hohe Reset-Quote deutet auf regelmäßig auftretendes Problem hin

Bei den Standard-Auswertungen über die Maschinen-Performance fällt auf, dass zwei bis drei Prozent der Buchungsvorgänge manuell vom Support durch einen Reset-Befehl abgeschlossen werden. Das ist zum Beispiel notwendig, wenn an einer Maschine ein Fehler auftritt; der Kunden wendet sich in diesem Fall an die Support-Hotline. Den Mitarbeitern dort stehen verschiedene Befehle zu Verfügung, die sie remote an die Maschine senden können. Der Reset-Befehl, der die Maschine in jeder Phase in den Zustand „nutzbar“ zurücksetzt, ist einer davon.
Die hohe Quote von zwei bis drei Prozent ist für den Leiter im Kundenservice auf Dauer nicht hinnehmbar, da er auf ein regelmäßig auftretendes Problem hindeutet und die hohe Zahl von Buchungen sich in viele unzufriedene Kunden übersetzt. Er gibt ein Analyseprojekt in Auftrag, das die Ursachen für das häufige Zurücksetzen aufdecken soll.

Analyse vermuteter Fehlerquellen

Der Leiter Kundenservice hat zwei Fehlerquellen im Verdacht:

  1. Es gab bereits Probleme mit bestimmten Kartenlesertypen, teilweise im Zusammenspiel mit bestimmten Kartentypen.
  2. Die Maschine verhindert in bestimmten Situationen, dass die Buchung beendet werden kann, beispielsweise wenn noch Wäsche in der Trommel ist oder das Waschmittelfach fehlt. Dies ist grundsätzlich ein gewünschtes Verhalten; es könnte aber auch durch fehlerhafte Sensorik oder falsche Bedienung ausgelöst werden, wenn alles in Ordnung ist.

Eine Analyse des jeweiligen Zustands vor dem Reset sowie der im zeitlichen Zusammenhang gesendeten oder angezeigten Fehlermeldungen soll zeigen, ob und in welchem Ausmaß die vermuteten Fehlerquellen für Resets verantwortlich sind.

Die Arbeit für den Analysten hierbei liegt hauptsächlich in dem Zusammenführen der verschiedenen Datenquellen, dem Bereinigen der Daten und der fachlich korrekten Zuordnung der Zustände.

Von der Zustands- zur Prozessanalyse

Da die beiden Fehlerquellen sehr unterschiedlich sind und sich auch auf verschiedene Zeitpunkte im Ablauf beziehen, betrachtet der Analyst sie einzeln.

Best Practice: Es ist sinnvoll, verschiedene Fragen oder Szenarien einzeln zu behandeln und mehrere Analysen zu machen. Das liefert schneller genauere Ergebnisse als der Versuch, mit einer einzigen großen Analyse alle Aspekte auf einmal abzudecken.

Da der Kunde einen Waschvorgang durch Einlesen der Karte beginnt, beschränkt der Analyst die Analyse zu Kartenfehlern auf Resets im Zustand „reserviert“. Bei Problemen bei spontanen Buchungsversuchen im Zustand „nutzbar“ hilft ein Reset (nach „nutzbar“) nicht weiter. Die Fälle mit diesem Zustand machen allerdings nur etwa 13 Prozent der Resets aus. Der Analyst kontrolliert, ob es vor diesen Resets ein Problem beim Lesen der Karte gab. Dazu überprüft er, ob der gleiche Kunde danach eine neue Buchung gestartet hat und welche Zeit zwischen Reset und neuer Buchung vergangen ist. Die Analyse wird dadurch von einer Zustands- zu einer simplen Prozessanalyse.

Das überraschende Ergebnis: Nur bei der Hälfte der Resets kommt es direkt danach zu einer erneuten Buchung. Bei den anderen Buchungen wird die Maschine erst nach einiger Zeit wieder verwendet, und fast immer von einem anderen Kunden. Eine Nachfrage beim Support-Team ergibt, dass sich mit der App veranlasste Reservierungen nicht aufheben lassen. Kunden, die eine reservierte Maschine wieder freigeben wollen, rufen also beim Kundenservice an und dieser schickt in Ermangelung eines Stornierungsbefehls einen Reset.

Best Practice: Die Aktionen direkt nach Behebung eines Fehlers geben oft Aufschluss darüber, was die eigentliche Intention war, als der Fehler auftrat. Auch Zeitabstände bis zur Entdeckung des Fehlers und Wiederbenutzung nach Behebung liefern Anhaltspunkte. Sie sollten in einer Prozessanalyse auf jeden Fall einbezogen werden.

Hot-Fixes verzögern die Problemerkennung

Jedoch ist die Anzahl der Resets mit Bezug zu Kartenlesefehlern damit viel zu gering im Vergleich zu den bereits dokumentierten Problemen zwischen bestimmten Karten und Kartenlesegeräten. In einer erweiterten Prozessanalyse bezieht der Analyst weitere vom Support an die Maschine versendete Befehle in sein Datenset ein. Dabei zeigt sich, dass die Mitarbeiter im Kundenservice oft remote einen „Buchung starten“-Befehl an die Maschine senden, um dem Kunden den Waschgang zu ermöglichen. Nach dem Waschvorgang öffnen sie die Tür durch einen Reset und schließen die Buchung ab. Die Resets, die sich auf Kartenprobleme beziehen, kommen also oft erst im Zustand „Warten auf Öffnung“ (siehe Abbildung ).

Mehrwert der kombinierten Betrachtung mehrerer Akteure: Werden nur die Daten der Waschmaschine ausgewertet, so scheint es, dass erst beim Öffnen der Maschine nach der Wäsche ein Problem auftritt. Erst die Hinzunahme der Remote-Befehle zeigt, dass der Kunde bereits zu Beginn der Buchung auf Probleme gestoßen ist.

 

 

Best Practice: Wenn es wichtig ist, dass schnell wieder eine (Teil-)Funktionalität zu Verfügung steht (etwa wenn der Support dem Kunden oder Mitarbeiter sofort helfen will), werden als erste Lösung oft Hot-Fixes verwendet, die das eigentliche Problem nicht beheben. Dadurch kann es einen Zeitverzug zwischen Problementstehung bzw. -erkennung und finaler Behebung geben, eventuell mit weiteren Aktionen in der Zwischenzeit. Dies muss der Analyst bei der Auswahl der Daten und des Zeitfensters berücksichtigen.

Reine Zustandsanalyse führte nicht zu aussagekräftigen Ergebnissen

Der Analyst hat sich bis hierher mit der ersten Vermutung beschäftigt, ob bestimmte Kartenleser Probleme verursachen. Die reine Zustandsanalyse führte nicht zu aussagekräftigen Ergebnissen. Er erweiterte sein Verfahren zu einer zum Schluss schon recht komplexen Prozessanalyse. Trotzdem blieb eine Vielzahl an Resets unerklärt.

Bleibt der zweite vom Leiter Kundendienst formulierte Verdacht: Möglicherweise verursacht fehlerhafte Sensorik Probleme beim Beenden der Buchung. Der Analyst kombiniert deswegen die Resets mit von der Maschine angezeigten Fehlermeldungen. Dabei stellt sich heraus, dass nur vor sehr wenigen Resets überhaupt eine Fehlermeldung angezeigt wird. Wird die Analyse auf versendete Fehlernachrichten und Remote-Befehle ausgeweitet, zeigt sich immer noch kein signifikantes Problem. Die Annahme, dass die Sensorik Probleme verursacht, kann also nicht bestätigt werden.

Der Analyst klärt daraufhin mit dem Auftraggeber, ob die Annahme eine reine Hypothese war, und verworfen werden kann oder ob diese auf bekannten Fakten basiert. Dann liegt der Schluss nahe, dass wichtige Informationen nicht geloggt werden. In dieser Auswertung ist ersteres der Fall.
Bis jetzt ist nur für eine kleine Anzahl von Resets ein Grund bekannt (Kartenlesefehler oder zurückgezogene Reservierung). Eine statistische Auswertung des letzten Zustands vor dem Reset zeigt außerdem, dass die überwiegende Mehrzahl der unerklärten Resets in der Phase „Buchung beenden“ stattfindet. Dieses Szenario muss also genauer analysiert werden.

Best Practice: Bei einem begründeten Verdacht ist es durchaus legitim, die Fragestellung sehr eng und zielgerichtet zu fassen. So schränkt man den Aufwand für die Analyse ein und verhindert, dass durch irrelevante Daten Ergebnisse verfälscht oder verwässert werden. Man sollte sich jedoch bewusst sein, dass man mit einer zielgerichteten Fragestellung auch nur die Probleme findet, nach denen man Ausschau hält. Außerdem sollten Vorannahmen schnell fallengelassen und die Fragestellung offener gefasst werden, wenn die Daten diese nicht unterstützen. Oft suchen Beteiligte mit viel Energie nach Fehlern in der Datengrundlage, bevor sie ihre Vermutung hinterfragen.

Sinnvolle Suche erfordert ausgewogenes Verhältnis von Attributen zu vorhanden Datensätzen

Nachdem keine der beiden vermuteten Ursachen für einen Großteil der Resets verantwortlich ist, startet der Analyst eine umfassende Prozessanalyse. Zuerst macht er sich bewusst, welche Datenquellen zur Verfügung stehen. In diesem Fall sind dies der Verlauf der Buchung mit Zustandsübergängen, Eingaben und Displayanzeigen, jeweils mit Zeitstempel; von der Maschine versandte Fehlermeldungen; an die Maschine gesendete Remote-Befehle sowie technische Daten, etwa das Modell von Maschine und Buchungsmodul oder die Softwareversion.

Als erster Schritt bietet sich auch hier wieder eine einfache statistische Auswertung an. Weichen die Verteilungen von Modell, Modul, Softwareversion oder gewähltem Waschprogramm deutlich von den Verteilungen bei erfolgreich verlaufenen Buchungen ab? Wurden bestimmte Fehlermeldungen oder Remote-Befehle vermehrt versendet? In diesem Anwendungsfall ergeben sich keine Auffälligkeiten, so dass eine umfangreichere Analyse notwendig ist.

Mit einer Prozessanalyse der Resets in der Phase „Buchung beendet“ versucht der Analyst, den gesamten Ablauf der Buchung einzufangen. In der ersten Iteration betrachtet er nur die Maschine selbst, das heißt Zustandsübergänge, Anzeigen, Fehlermeldungen und erhaltene Eingaben. Über die Eingaben ist indirekt auch ein Teil des Kundenverhaltens zu sehen. Jedes der Events besitzt einen Zeitstempel. Diese können verwendet werden um die Dauer der Phasen zu bestimmen. Für eine sinnvolle Analyse sind das schon zu viele Attribute im Verhältnis zu der relativ geringen Menge an Datensätzen. Der Analyst muss also eine Auswahl treffen beziehungsweise Attribute ausschließen, die voraussichtlich kaum Analyse-relevante Informationen enthalten.

Gegenprobe eliminiert Attribute

Da die Analyse nur Resets im Zustand „Buchung beenden“ betrachtet und die Zustandsübergänge zur Erreichung dieses Zustandes immer in der gleichen Reihenfolge auftreten, können diese Angaben aus der Analyse ausgeschlossen werden. Als eine Art Gegenprobe überprüft der Analyst, ob Reihenfolge und Zeitabstände zwischen den Übergängen innerhalb der Menge an Reset-Datensätzen und auch im Vergleich zu erfolgreichen Buchungen stark voneinander abweichen. Da dies nicht der Fall ist, können die Zustandsübergänge als Attribute fallen gelassen werden. Analog verhält es sich mit Fehlermeldungen, Anzeigen und entgegengenommenen Eingaben.

Best Practice: Parameter, die für (fast) alle Datensätze der Analyse gleich oder sehr ähnlich sind, sollten nicht als Features/Attribute für eine Szenario-Unterscheidung verwendet werden. Im besten Fall bläht sich der algorithmische Aufwand auf, ohne zum Ergebnis beizutragen. Im schlimmsten Fall verfälschen leichte Abweichungen das Ergebnis. Das gleiche gilt für Parameter, die in fehlerhaften und fehlerfreien Abläufen gleich sind.

Von den Maschinendaten bleibt also der Abschnitt vom Übergang in „Buchung beenden“ über den Reset bis zum Antritt der nächsten Buchung. Eine Analyse des zeitlichen Verlaufs zwischen diesen drei Ereignissen zeigt erste Auffälligkeiten. In der Mehrheit der Fälle kommt der Reset nicht kurz nach dem Übergang in „Buchung beenden“ sondern mit deutlichem Abstand. Auch schließt sich in diesen Fällen meist keine Buchung direkt an. Es ist also unwahrscheinlich, dass der Reset von einem Kunden angefordert wird, der einen eigenen Vorgang starten will.

Um besser zu verstehen, was passiert, zieht der Analyst nun die Daten der Support-Mitarbeiter hinzu. Eine Auswertung der anderen vom Support an die Maschine gesendeten Befehle zeigt keine Auffälligkeit. Es ist damit unwahrscheinlich, dass der Support dem Kunden bei Buchungsende anders weiterhilft und erst später einen Reset auslöst. Eine Aufschlüsselung nach Support-Rolle gibt jedoch endlich Aufschluss: Die fraglichen Resets werden gar nicht von den regulären Hotline-Mitarbeitern versendet, sondern von den Objektmanagern, die die Maschinen remote überwachen und bei Bedarf vor Ort warten. Diese überprüfen regelmäßig die von ihnen verwalteten Maschinen auf. Dabei resetten sie Maschinen, die sich schon länger im Zustand „Buchung beenden“ befinden.

Best Practice: In der ersten Auswertungsrunde sollten Akteure, das können sowohl Menschen als auch Geräte zum Beispiel im Internet of Things sein, in möglichst grobe Gruppen unterteilt werden. So hält der Analyst die Komplexität gering und die Anzahl der ähnlichen Datensätze hoch. Wenn die Analyse dann jedoch keine zufriedenstellenden Ergebnisse liefert, sollten für die weiteren Iterationen feinere Gruppeneinteilungen oder sogar Einzelakteurs-Betrachtungen gewählt werden.

Ein genauer Blick auf die Eingaben an der Maschine zeigt, dass der Kunde in vielen Fällen gar nicht mehr mit der Maschine interagiert, nachdem er die Tür geöffnet hat. Insbesondere meldet er sich nicht aus dem System ab. Der Reset des Objektmanagers bewirkt, dass die Maschine wieder für Buchungen zur Verfügung steht. Da der Kunde, nachdem er die Tür geöffnet und seine Wäsche entnommen hat, nicht bei der Hotline anruft, nimmt er vermutlich kein Problem beim Buchungsende wahr. Analyst und Unternehmen schließen aus dieser Beobachtung, dass der Kunde in diesen Fällen vermutlich der Ansicht ist, dass für das Abschließen seiner Buchung keine weiteren Aktionen vom ihm nötig sei. Kurz: Der Kunde weiß nicht, dass er sich aktiv aus dem System abmelden muss.

Best Practice: Die Interaktion zwischen den Akteuren gibt mehr Aufschluss über die Situation als das Verhalten jedes einzelnen Akteurs für sich betrachtet. Auch wenn der Analyst für eine Interaktionsbetrachtung Datenquellen zusammenführen muss – und damit Probleme und Aufwände verbunden sind –, lohnt sich dieser Schritt in der Regel.

Maßnahmenpaket für gezielte Aktionen entwickeln

Die verschiedenen Analysen über das Auftreten von Resets haben eine Reihe von Problemen ans Tageslicht gebracht. Für diese kann das Unternehmen gezielt Gegenmaßnahmen entwickeln. Der Verdacht bezüglich der Probleme zwischen Karte und Lesegerät hat sich bestätigt, aber nicht im vermuteten Ausmaß. Außerdem hat der Support über Remote-Start und späteren Reset bereits eine Strategie entwickelt, um den Kunden kurzfristig zu helfen. Dadurch ist das Thema weniger dringlich als angenommen.

Durch sukzessiven Austausch der fehlerhaften Karten kann das Problem nach und nach behoben werden.
Dass die Kunden eine Reservierung nicht absagen können, und auf den Support zurückgreifen müssen, war den Verantwortlichen für das Buchungssystem bisher nicht bewusst. Durch eine Anpassung der App wird diese Lücke in der Funktionalität schnellstmöglich behoben.

Vollkommen unerwartet für das Unternehmen war die Erkenntnis, dass die Kunden offenbar den Abmeldungsprozess falsch verstehen. Glücklicherweise wurden diese Fehler oft von Bestandsmanagern behoben. Sie waren für den Kunden in der Regel nicht sichtbar. Jedoch wurde dadurch die Maschine unnötig blockiert.
Als Konsequenz wird der Abmeldeprozess umgestellt, so dass jetzt eine automatische Abmeldung und damit Freigabe der Maschine erfolgt, wenn 10 Minuten nach Türöffnung keine weiteren Eingaben getätigt werden.

Best Practice: Die beste Analyse hilft nicht weiter, wenn aus den Ergebnissen keine Konsequenzen gezogen werden. Hier hapert es bei vielen Unternehmen noch. Wichtig ist, dass aus den Erkenntnissen konkrete Maßnahmen (mit Zuständigkeiten) abgeleitet werden. Außerdem sollte die Wirksamkeit der Maßnahmen überprüft werden, indem nach deren Umsetzung gezielt einzelne Analysen wiederholt werden.

Menschliche Faktor bedingt Ergebnisqualität

Die Beteiligten im oben beschriebenen Projekt weiteten die Suche nach dem Fehler Schritt für Schritt aus. Der Analyst hat bei jedem Schritt das Fachwissen der Mitarbeiter aus dem Kundenservice einbezogen. Beides war entscheidend für den Erfolg des Projektes. Es zeigt auch: Der menschliche Faktor bedingt allzu oft die Ergebnisqualität in einem Analyseprojekt. Um Daten Sinn zu geben, braucht ein Analyst Zugang zu allen Beteiligten, um Informationen einholen zu können. Der Auftraggeber der Analyse tut gut daran, nicht auf seinen ursprünglichen Annahmen zu beharren.

Best Practice: Oft treten Auftraggeber mit einem vorgefertigten Annahme, Erwartungshaltung oder Meinung an den Analysten heran, welche sie mit Fakten untermauert sehen wollen. Hier liegt es am Analysten, Hypothese kritisch zu hinterfragen, die Aussagekraft der Daten und Analyseergebnisse verständlich zu erklären und Erwartungsmanagement zu betreiben.

Literatur-Empfehlung von Dr. Lisa Wagner: Für die Analysen wurden keine innovativen Algorithmen verwendet, auf die hier speziell verwiesen werden sollte. Vorrangig wurde hier mit einfachen statistischen Methoden und Clusterverfahren gearbeitet. Wer einen Einstieg in Prozessanalysen sucht, dem seinen jedoch folgende Themen ans Herz gelegt: Für eine korrekte Analyse ist eine gute Datenqualität von großer Wichtigkeit. Diese ist jedoch in den Rohdaten oft nicht gegeben, Insbesondere, wenn sie von manuellen Eingaben oder fehleranfälligen Sammel- und Übertragungsmethoden abhängen. Daher ist als erster Schritt ein Data Cleaning von Nöten. Hierzu siehe zum Beispiel Rahm, E./ Do, H.H.: Data Cleaning: Problems and Current Approaches . Für Prozessanalysen selbst bietet die folgende Website einen guten Startpunkt: http://www.processmining.org/

Dr. Lisa Wagner/hei

Anzeige

Trovarit: Unsere Kompetenz im Datenmanagement

Im Competence Center „Datenmanagement“ unterstützt die Trovarit AG Unternehmen in den Belangen „Informationsaufbereitung“ und „Informationsfluss“

  • durch die Untersuchung der Qualität von Stamm- und Transaktionsdaten, der Datenmodelle und der Datenflüsse in den Applikationslandschaften,
  • durch eine auf diesen Datenqualitätsuntersuchungen beruhende Sanierung, Optimierung und Migration der Daten in der bestehenden Applikationslandschaft und bei der Einführung von neuen Applikationen,
  • durch die Einrichtung eines optimalen Datenflusses von den operativen Applikationen zu neu einzurichtenden oder schon vorhandenen Business-Intelligence-Lösungen und
  • durch die Konzeption und Umsetzung von „Product-Life-Cycle“-Projekten (d.h. die Verbindung von CAD/CAM, PDM und Systems Engineering).

 

Verwandte ArtikelMehr vom Autor