Analysten mit Domänenwissen: Die wahre Geschichte hinter den Ergebnissen
Heute möchte ich kurz auf einen Artikel eingehen, auf den mich mein Kollege Christoph aufmerksam gemacht hat. Er ist erschienen auf www.heise.de, Autor ist Rudolf Jansen, datiert ist der Artikel 07.07.2015 - 12:29. Titel ist "Data Scientist - ein neues Berufsbild für die Big-Data-Welt", und noch schöner finde ich den Zusatz "Celebrate Data". [Heise]
Referenziert wird darin auch ein Artikel im HBR (Harvard Business Review) in dem "Data Scientist" sogar als "Sexiest Job of the 21 Century" bezeichnet wird; der Artikel „Data Scientist: The Sexiest Job of the 21st Century“ - immerhin schon aus dem Jahr 2012! - stammt von Thomas H. Davenport und D.J. Patil und ist hier ebenfalls verlinkt. [HBR]
Abbildung 1: Sehen wir uns Daten nur an, oder verstehen wir ihre Bedeutung?
Nun, ich weiß nicht, ob das mit dem "Sexiest Job" jeder unterschreiben würden, der gerade mal wieder knietief in den Daten steckt, und mit schlechter Datenqualität, Hard-und Softwarelimitierungen, Schnittstellenproblematiken und mit vermeintlich "einfachen" Fragestellungen zu kämpfen hat, die sich bei genauerer Betrachtung öfter drehen und wenden lassen als ein Rubik Würfel. Trotzdem kommt unbestritten dem Data Scientist (oder allgemeiner und weniger mit Forschungsbezug vielleicht auch einfach "Data Analyst") in der Zukunft eine enorm wichtige Rolle zu.
In erstgenanntem Artikel wird angesprochen, dass es noch keine klare Definition dafür gibt. Die Rolle wird darin aus meiner Sicht relativ Informatik/Mathematiklastig dargestellt, etwa mit Verweisen auf Aspekten wie NoSQL, Machine Learning, Predictive Analytics, Statistiksprache R oder Python.
Das will ich auch nicht bestreiten, allerdings ist aus meiner Sicht der folgende Abschnitt des Artikels, den ich hier zitiere, interessant:
"Data Science = Mathematik + Informatik + Domänenwissen
Ein Data Scientist benötigt (mindestens) Kenntnisse in zwei klassischen Fächern: Mathematik und Informatik. Dazu kommt idealerweise noch Wissen aus dem jeweiligen Anwendungsgebiet, denn Kernaufgabe eines Data Scientist ist es, aus diversen Datenquellen Antworten auf Fragen zu finden, die dem (internen oder externen) Kunden einen Mehrwert für einen konkreten Themenkomplex gibt." [Heise]
Domänenwissen als Teil von Data Science also - Wir haben in der Vergangenheit einen Gastbeitrag hier veröffentlicht von Prof. Dr. Georg Herde, der den Studiengang Wirtschaftsinformatik an der Technischen Hochschule Deggendorf beschreibt. Meiner Meinung nach ist der Studiengang genau darauf ausgelegt, die drei oben genannten Bereiche Mathematik, Informatik und Domänenwissen zu kombinieren. Ich würde letzteres persönlich noch stärker gewichten, als es in der zitierten Textpassage der Fall ist. Das "idealerweise" in obigem Zitat würde ich zu "unbedingt" umformulieren. Die stärksten Analysen, die besten Data Analysts / Data Scientists zeichnen sich meiner Meinung nach durch fundiertes, umfangreiches Domänenwissen aus. Natürlich kann man argumentieren, dass manche analytische Methoden und Verfahren eben gerade auf "vorurteilsfreie", und rein den Daten immanenten Informationen aufbauen (etwa um Zusammenhänge zwischen Daten/Attributen festzustellen, die vorher eben nicht bekannt waren). Trotzdem ist es für "Analysen des Tagesgeschäfts" von enormen Vorteil, genau dieses Domänenwissen einzubringen. Nur so lässt sich auch der oben angesprochene Mehrwert für den internen oder externen Kunden erzielen.
Vielleicht ist diese Sichtweise auch geprägt von unserer Arbeitsweise, dass der Analyseansatz beim Lokalisieren der Daten beginnt, und nach der "toolgestützten Datenanalyse" nicht stoppt, sondern die Ergebnisse auch bewertet und nach außen kommuniziert werden müssen. Domänenwissen, das ist für uns das Wissen über betriebswirtschaftliche Prozesse, branchenspezifische Kenntnisse, sowie eine Sensibilität für mögliche Risiken, die durch die Analysen zu Tage gefördert werden.
Lassen Sie mich das mit einem kurzen Beispiel verdeutlichen. Angenommen, die Fragestellung war "Ermittlung der durchschnittlichen Gutschriftsquote insgesamt, sowie der Gutschriftsquote pro Kunde". D.h. wir betrachten die Summe der Gutschriften im Kalenderjahr, und teilen sie durch die Summe der Rechnungen pro Kalenderjahr. OK, dafür reicht eigentlich ein Taschenrechner aus, und die Methoden der Mathematik und Informatik halten sich in Grenzen - aber es geht bei dem Beispiel primär um das Domänenwissen. Wir setzen voraus, dass die Daten entsprechen im Quellsystem lokalisiert wurden (sie liegen zum Beispiel in einem SAP(R) System im Modul SAP(R) FI-AR Accounts Receivables in den Tabellen des debitorischen Nebenbuches. Die Daten wurden mit den relevanten Feldern extrahiert, in eine Analysesoftware wie ACL(TM) importiert und mit entsprechenden Formeln, berechneten Feldern, Funktionen und Kommandos ausgewertet.
Als Ergebnis im fiktiven Beispiel liegt die durchschnittliche Quote bei 8,34% über alle Kunden. Das bedeutet, wir (bzw. die Firma, für die die Daten analysiert wurden) erstatten Kunden im Schnitt Beträge von knapp unter 10% zurück. Das kann begründet sein durch Rahmenverträge mit Jahresendboni bei Überschreitung eines gewissen Umsatzes, aber auch bedingt durch Rücksendungen und Reklamationen. (Streng genommen gehört schon das Verstehen, wieso es überhaupt zu Gutschriften kommen kann, bereits zum Domänenwissen).
Nun werfen wir noch einen Blick auf die Quote pro Einzelkunde - greifen wir dafür aus einer Gesamtzahl von sagen wir 10539 Kunden vier Einzelbeispiele heraus:
Abbildung 2 – Gutschriftsquote pro Kunde (Auszug aus Gesamtergebnis)
- Die "Demo AG" hat ausschließlich Gutschriften, aber keine einzige Rechnung im System. Die Gutschriften betragen in Summe 10 Millionen Euro. Ist das ein Risiko? Welche Gründe könnte das haben?
- Dagegen scheint die "Test GmbH" ein einfacherer Fall zu sein, die Gutschriften betragen genau 15% des kumulierten Rechnungsbetrages. Allerdings ist der Kunde einer Gruppe zugeordnet, die einen Bonus von 10% auf den Jahresumsatz bekommen - die ermittelte Gutschriftsquote ist somit höher als erwartet.
- Bei der Klein GbR scheint etwas zu fehlen, denn für diese ausschließlich Rechnungen im System, allerdings gar keine Gutschrift - dabei ist sie ebenfalls der 10%-Gruppe laut Stammdaten zugeordnet.
- John Doe, Inc. dagegen ist wieder komplett anders gelagert als die ersten drei Beispiele. Dieser Kunde hat Gutschriften, die exakt der Höhe der Rechnungen entsprechen, nämlich 299.000,00 €.
Natürlich kann es verschiedene Gründe für die eine oder andere Ausprägung geben. Hier die "Auflösung":
- Bei der Demo AG handelt es sich um einen Einkaufsverbund. D.h., die Waren werden von den Kunden bezogen, die dem Einkaufsverbund angehören. Dort findet man auch die zugehörigen Rechnungen. Dies ist auch bei dem Datensatz in Zeile 4 der Fall, der Klein GbR, und genau das ist der Grund warum dort keine Gutschriften zu finden sind. Diese werden - genau wie die Gutschriften aller weiteren dem Einkaufsverbund zugehörigen Firmen - am Ende des Kalenderjahres dem Einkaufsverbund gutgeschrieben, der diese Gutschriften dann zentral verwaltet und verteilt.
- Die Test GmbH ist ein einfacherer Fall. Hier handelt es sich um einen Kunden, der eine Bonusvereinbarung in Höhe von 10% mit uns getroffen hat. Der Jahresumsatz wurde erreicht, der Bonus ausbezahlt. Warum aber 15% Gutschriftsquote? Ein Blick in die Detaildaten (= Einzeltransaktionen) zeigt, dass zusätzlich noch eine Gutschrift erteilt wurde, da eine Warenlieferung auf Grund eines Transportschadens zum Teil beschädigt war. Diese hätte man anhand der Referenz zum Vertriebsbeleg in der Analyse im Vorfeld separieren können.
- Auffällig bei John Doe, Inc. ist der Umstand, dass es genau eine Rechnung ist, gegen die genau eine Gutschrift gebucht wurde. Diese Transaktionen sollten möglicherweise genauer betrachtet werden. Sollten Umsatzzahlen geschönt werden am Ende einer Periode (möglicherweise relevant für Kriterien der Zielerreichung) die dann in der nächsten Periode wieder storniert wurden? Oder Bestand das Risiko eines Zahlungsausfalles, so dass die Rechnung mit einer Gutschrift storniert wurde, da man die Ware zurückgeholt hat? Dafür wären ebenfalls Informationen aus einem anderen SAP(R) Modul, etwa SD Sales & Distribution hilfreich.
Dies sind mögliche Geschichten hinter den einzelnen Ergebnissen. Man sieht, dass es oft mit einer reinen "Liste" als Resultat von Analysen nicht getan ist. Ein Punkt, den ich hier beschreibe, und der bei den hier genannten Artikeln noch nicht so klar genannt wurde, ist auch das Selbstverständnis des Data Scientists / Data Analysts und seiner Einbettung in das Unternehmen. Soll diese Rolle nur darin bestehen, ein Analyseergebnis wie im Beispiel "Ermittlung der durchschnittlichen Gutschriftsquote insgesamt, sowie der Gutschriftsquote pro Kunde" zu liefern, das dann wiederum andere zu bewerten haben? Oder soll die Aufgabe vielmehr sein, Analysen zu erstellen, die Ergebnisse zu sichten, werten zu können, zu differenzieren und differenziert zu kommunizieren, und schließlich die Analysen iterativ zu verfeinern in Hinblick auf den Kontext der jeweiligen Analyse, der Domäne in der man sich bewegt?
In diese Richtung geht auch der Artikel in [HBR], und stellt diese Weichen auch gleich in der Einleitung „More enduring will be the need for data scientists to communicate in language that all their stakeholders understand—and to demonstrate the special skills involved in storytelling with data,…“. [HBR]
Storytelling with data, ein ganz wichtiger Punkt für die Zukunftsfähigkeit dieser Profession, und hier wird die Brücke mittels des Domänenwissens geschlagen.
Aus meiner Sicht, um noch einmal auf den "Sexiest Job of the 21st Century" in [HBR] zurückzukommen, kann nur der ganzheitliche Ansatz eine wirklich erfüllende Tätigkeit darstellen. Natürlich ist das hier aufgeführte Beispiel eines, für das man kein mathematisch/statistisches Methodenwissen benötigt. Das soll übrigens nicht bedeuten, dass in "Data Science = Mathematik + Informatik + Domänenwissen" diese nicht extrem wichtig wären. Aber gute Datenanalyse beginnt im Kleinen, und mit der Bereitschaft, sich fundiert mit den Daten zu beschäftigen, die eigenen Daten und Prozesse zu kennen bzw. kennenzulernen, und die Ergebnisse ständig zu hinterfragen und so dazuzulernen; "Celebrate Data", wie Herr Jansen in [Heise] so schön proklamiert. Ein wichtiger Teil des Gesamtbildes ist das hier am kleinen Beispiel aufgezeigte Know-How die jeweilige Domäne betreffend. Wenn Sie selber im Bereich Datenanalyse tätig sind, oder Data Analysts / Data Scientists suchen - legen Sie Wert auf das Domänenwissen. Unbedingt.
Für Fragen oder Kommentare können Sie sich gerne unter info@dab-gmbh.de an uns wenden.
Um den Autor zu kontaktieren, bieten sich auch LinkedIn oder XING an (möglicherweise müssen Sie sich erst einloggen in das entsprechende Social Network, bevor Sie die folgenden Links nutzen können):
LinkedIn: http://de.linkedin.com/pub/stefan-wenig/54/1b8/b30