Aufbau eines schlagkräftigen Data-Science-Teams

Data Science erlebt in den letzten Jahren eine zunehmende Professionalisierung und Standardisierung. Der oft intrinsisch motivierte Datenbastler und Frickler, der die Nische "Analyse" in seinem Unternehmen mit sehr hohem unternehmensinternen Daten- und Prozesswissen besetzt, kommt an seine Grenzen.

Zunehmende Anforderungen, gerade im Zuge der stärkeren Kundenfokussierung über alle Branchen hinweg, zwingen Unternehmen dazu, die Strukturen im Bereich Data Science zu professionalisieren: Dies reicht vom Wissen über zur Verfügung stehende Datenquellen und deren Aufbereitung bis zu schon im Unternehmen genutzten Data-Science-Produkte.

Professionalisierung von Data Science

So erleben wir in unserem Beratungsalltag immer häufiger die Anfrage nach Beratungsbedarf beim Aufbau eines schlagkräftigen Data-Science-Teams. Schnell stellt sich nun beim Aufbau einer Organisation die Frage, wie man die oben beschriebene "One-Man-Show" institutionalisiert und damit in das Netzwerk eines Unternehmens bzw. dessen Organigramm einpasst.

Entscheidend ist hier die Frage, ob man die Data-Science-Kompetenz in einem Team bündeln sollte oder dezentral über verschiedene Abteilungen verteilt. Hierum soll es in diesem Blogartikel gehen.

Dies ist sicher nur eine der Fragen von Relevanz, sollte aber früh geklärt werden. Am Ende des Artikels folgen weitere in diesem Kontext relevante Fragestellungen, wie z. B. die Verortung auf dem Organigramm: Soll es sich bei einem möglichen Team um eine Stabsstelle handeln oder sollte es Teil  einer Fachabteilung sein?

Die Anwendungsfälle

Welches Ziel wird mit dem Aufbau eines Data-Science-Teams verfolgt? Die Antwort auf diese Frage ist kritisch für deren spätere Ausrichtung: Wird das Data-Science-Team in einer Fachabteilung zentralisiert oder installiert man einzelne Data Scientists in den jeweiligen Abteilungen.

Bei der Definition des Ziels bzw. des Data-Science-Produkts ist die Unterscheidung zwischen Ad-hoc-Analyse und analytischer Applikation entscheidend:

Ad-hoc-Analyse: Eine Analyse ist statisch und wird nicht produktiv genutzt bzw. ist nicht in den Kontext einer Anwendung eingebunden. Ein klassisches Beispiel wäre hier eine Kundensegmentierung, die auf einem Snapshot der Kundenbasis zu einem gewissen Zeitpunkt entstanden ist. Es werden Handlungsempfehlungen abgeleitet, umgesetzt und zu einem späteren Zeitpunkt evaluiert. Dies geschieht aber nicht fortlaufend.

Am anderen Ende des Kontinuums die analytische Applikation: Die Segmentierung wird genutzt, um Kunden, die auf die Webseite kommen, zu kategorisieren und die Nutzererfahrung so zu individualisieren. Die Verarbeitung der dafür nötigen Information kann zur Laufzeit geschehen. Der Kunde einer Data-Science-Abteilung muss jedoch nicht immer der Endkunde sein; so gibt es die Möglichkeit, interaktive Applikationen für einen kleinen Kreis, z. B. nur im Intranet zur Verfügung zu stellen. Eine interaktive Visualisierung einer Szenariorechnung ist ein Beispiel.

(De-)Zentralisierung

Die zwei extremen Ausprägungen sind also auf der einen Seite ein Data Science Competence Center sowie auf der anderen Seite fachabteilungsinterne Data Scientists mit jeweiligen Vor- und Nachteilen.

Zentralisierung in einem Data Science Competence Center

Dezentralisierung der Data-Science-Ressourcen in den entsprechenden Abteilungen

Fazit

Sobald sich das analytische Zielbild einer Organisation auf der Achse Applikation vs. Data Product weiter in Richtung Applikation entwickelt, wird eine Zentralisierung in ein Data Science Competence Center notwendig. Da ist zum einen eine verstärkte Spezialisierung, die bei der Entwicklung einer Applikation notwendig ist: Es sollten im Team neben der Kompetenz, das Geschäftsmodell zu verstehen, Daten aufzubereiten und Modelle zu entwerfen und zu implementieren, auch die Fähigkeiten der Software-Entwicklung vorhanden sein. Hierzu bedarf es komplett eigener Kenntnisse, nicht nur in entsprechenden Frontend-Sprachen, sondern unter Umständen auch in technischer Architektur und dem Verständnis für einen Software-Entwicklungs-Lifecycle. Dieses umfangreiche Aufgabenportfolio und damit Anforderungsprofil an entsprechende Skills lässt sich schwer von einem Mitarbeiter alleine bewältigen.

Der größte Kritikpunkt an einer zentralen Einheit ist das vermeintlich fehlende Verständnis für die Geschäftsprozesse in einer spezifischen Abteilung, z. B. Marketing: "Wie kann jemand, der sonst Logistikoptimierung macht, nun plötzlich Bid-Management übernehmen", ist dann ein häufig genannter Einwand. Um dem Fachbereich einen kompetenten Ansprechpartner an die Hand zu geben, der auch als Sparringspartner dienen kann, ist wiederum eine Spezialisierung innerhalb der Data-Science-Teams nötig.

So wird nicht nur für eine kontinuierliche Weiterentwicklung der Data Scientists Sorge getragen, sondern durch die Teamstruktur auch der für die Modellierung benötigte Freiraum erwirkt. Wir erleben sehr häufig, dass in der Praxis gute Data Scientists nicht zu ihrer eigentlichen Aufgabe kommen, sondern primär kurzfristige Analyse- und Reporting-Aufgaben erfüllen.

Wie man aus den Zeilen erkennt, ist der erfolgreiche Aufbau eines Data-Science-Teams keine leichte, aber doch sehr kritische Entscheidung für das Business. Die Entscheidung für die richtige Organisationsform, die im Idealfall das Zielbild meiner Organisation widerspiegelt, ist nur eine der relevanten Angelegenheiten: Früher oder später tauchen dann Fragen auf wie: "Welche Prozesse und Methodiken bzw. Standards bieten sich an?" oder "Wie funktioniert Projektmanagement im Kontext des 'Working with Uncertainty'?" - dazu aber mehr in späteren Blogbeiträgen.