Best Practices für Data Science Projekte

Immer wieder machen Umfragen Schlagzeilen, in welchen die Mehrheit der befragten Unternehmen angibt, kaum Mehrwert aus ihren Data Science Projekten / KI Initiativen zu ziehen. Gleichzeitig machen alleine fünf Unternehmen, die Data Science / KI zum Kern ihres Geschäfts gemacht haben, 20% des Gesamtwertes des US Aktienmarktes aus. Wie kann es sein, dass manche Unternehmen einen enormen Nutzen aus Data Science ziehen und andere wiederum nicht?

Kultur und Erfahrung sind ausschlaggebend

Ein Grund dafür liegt sicher darin, dass die Transformation eines traditionellen zu einem datengetrieben Unternehmen eine grundlegende Veränderung beinhaltet, in der traditionelle Denkweisen angepasst und umgelernt werden müssen. Diese Transformation bedeutet mehr als die Gründung eines neuen, hippen Geschäftsbereichs.

Doch neben diesem “kulturellen” Aspekt gibt es noch viel banalere Gründe: viele Unternehmen haben keine Erfahrung damit, wie Data Science am besten im Unternehmen eingeordnet, bzw. eingebettet werden kann. Noch, welche Methoden für typische Data Science (nicht Software Engineering!) Projekte geeignet sind oder mit welchen Werkzeugen die Wartbarkeit von Data Science Projekten verbessert werden kann. Kurz gesagt: Es besteht ein Mangel an Best Practices.

In diesem Beitrag stellen wir drei praxiserprobte Best Practices vor, mit welchen Unternehmen Nutzen und Qualität ihrer Data Science Projekte sicherstellen können – oder, falls das geplante Projekt nicht realisierbar ist, schnell scheitern können. Denn auch das ist Teil der Transformation: Zu lernen, was mit vorhandenen Daten möglich ist und was nicht; und dieses Wissen in Entscheidung zu Produkt- oder Systementwicklung einfließen zu lassen.

Das (richtige) Vorgehen für Data Science Projekte

Um bezüglich eines geplanten Use Cases eine möglichst schnelle und umfängliche Rückmeldung zu erhalten, ist es meist ratsam, den Use Case als MVP (minimum viable product, “minimal überlebensfähiges Produkt”) anzugehen. Das bedeutet insbesondere, von Anfang an die späteren Nutzer (z.B. Fachbereich) ins Boot zu holen und in die Entwicklung einzubeziehen. Denn nicht selten scheitern gut gemeinte Initiativen daran, dass sie an den Adressaten vorbei entwickelt werden. Das kann aus den unterschiedlichsten Gründen passieren: Vielleicht wurde der Schmerz des Fachbereichs missverstanden (oder falsch kommuniziert), die operative Randbedingungen (Komplexität im Betrieb etc.) unterschätzt oder der Fachbereich fühlt sich übergangen und blockiert.

Das Business-Ziel im Blick haben

Durch die Konzentration auf das “Produkt”, d.h. das Resultat des Use Cases, wird der (wirtschaftliche) Mehrwert in den Vordergrund gerückt und die mathematisch-technische Fragestellung, der Data Scientists leidenschaftlich gern nachgehen, in die Business-Fragestellung eingebettet. Dies erweitert den Problemlösungshorizont – denn nicht selten kann auch mit pragmatischen Mitteln Mehrwert geschaffen werden, wenn Problemverständnis mit Kreativität und technischer und fachlicher Expertise zusammentreffen.

Wissen, was Erfolg bedeutet

Der Fokus auf das gewünschte Resultat beinhaltet zusätzlich die Definition der Zielerreichung: Wann ist das Ziel erreicht? Beinhaltet die Erfüllung eines definierten Kriteriums den Erfolg des fachlichen Use Cases? Ohne realistische Zielvorstellungen ist es fast unmöglich, zu entscheiden (und zu begründen), wann es an der Zeit ist, eine Initiative einzustellen oder doch weiter voranzutreiben.

Geschwindigkeit als Erfolgsfaktor

Die klare Beschränkung des Umfangs des MVPs führt zudem zu besserem Fokus, schnelleren Iterationen, und schlussendlich schnellerem “Scheitern” oder Erfolg. Vereinfacht gesprochen, denn natürlich zeichnen sich Data Science Probleme oft durch einen großen Problemraum aus und ein Data Scientist würde gerne alle Möglichkeiten überprüfen. Doch eine hohe Use Case Komplexität zu Beginn der datengetriebenen Transformation ist ein Warnsignal. Denn die Wahrscheinlichkeit ist hoch, dass es noch nicht berücksichtigte “low hanging fruits” gibt, d.h. Use Cases, bei denen ein hoher Mehrwert durch geringen Aufwand geschaffen werden kann. Gerade am Anfang der datengetriebenen Transformation sind schnelle Erfolge wichtig, um das Engagement der Zielgruppe für die nächsten Schritte zu sichern.

Bei der Diskussion des MVP-Vorgehens dürfen jedoch zwei Dinge nicht vergessen werden: Ein MVP ist kein produktives System und “Scheitern” bedeutet Lernen. Wie in der Softwareentwicklung gilt auch hier, dass sich eine vernünftige Infrastruktur- oder Software-Architektur nicht von selbst im Zug iterativer Weiterentwicklung ergibt. Und wie in der Wissenschaft bedeuten auch hier “negative” Experimente Wissensgewinn. Vielleicht ist es die Erkenntnis, dass die zeitliche Auflösung der Sensordaten für diesen Use Case nicht ausreicht; vielleicht das Verständnis, wie Kunden wirklich mit der Unternehmenswebsite interagieren. In den allermeisten Fällen wird es jedoch ein sowohl…als auch sein: Sowohl Erfolg in Bezug auf den Business Use Cases als auch ein besseres Verständnis dessen, welche Faktoren diesen Use Case auf welche Art beeinflussen.

Die Rolle des Data Scientists

Doch nicht nur beim Vorgehen, sondern auch bei der Rollendefinition eines Data Scientists gibt es zum Teil immer noch verhängnisvolle Missverständnisse. So haben sich aus den verschiedenen Facetten des hochkomplexen “Data Science / KI” Umfelds verschiedene Spezialisierungen herausgebildet – Data Engineer, Data Scientist und Machine Learning Engineer (um nur drei zu nennen). Zurecht – jede einzelne Facette (Datenökosystem, Entwicklung, Kommunikation und Betrieb von Analysen & Machine Learning Modellen) besitzt eine hinreichende fachliche Breite und Tiefe, um die Herausbildung unterschiedlicher Rollen zu rechtfertigen.

Was im Rahmen dieser Entwicklung jedoch nicht unter die Räder kommen darf ist die ganzheitliche Betrachtung eines Data Science Use Cases. Zu viel relevantes Wissen geht verloren, wenn der Data Engineer die Merkmale (Features) für ein Machine Learning Modell baut, der Data Scientist dieses Modell entwickelt und der Machine Learning Engineer das Modell produktiv setzt. Im besten Fall bedeutet solch eine Arbeitsteilung ein langsames Vorankommen mit viel Reibung, im schlimmsten Fall ein völliger Verlust von Verantwortungsgefühl (Ownership).

End-To-End statt Silodenken

Aus eben den oben genannten Gründen hat sich ein sogenannter „End-To-End“ Ansatz bewährt: Ein Data Scientist verantwortet die Umsetzung des Use Cases von der Merkmal-Erstellung aus den Daten bis zur Diskussion mit den Interessengruppen (Stakeholdern). Die genaue Struktur hängt dabei von Unternehmensgröße und -reife sowie Use Case Umfang, bzw. Komplexität ab, nicht aber das grundlegende Prinzip: Nur wer das gesamte Bild im Blick hat, kann Abhängigkeiten, Probleme und implizite Anforderungen frühzeitig erkennen und so effektiv Geschäftsprobleme lösen.

Wohlgemerkt: End-To-End bedeutet nicht, dass Spezialisierung hinfällig geworden ist. Doch tiefe Spezialisierung, die sich ausschließlich mit einem Teil der End-To-End Strecke befasst, kommt besonders dort zum Tragen, wo kleine Verbesserungen großen Mehrwert liefern können, wie z.B. die Verbesserung des Empfehlungssystems eines globalen e-commerce Unternehmens. Die Mehrheit der Unternehmen befindet sich nicht an diesem Punkt.

Das Rad nicht neu erfinden

Als letzte Empfehlung sei hier noch eine Lanze für die Professionalisierung des technischen Data Science Workflows gebrochen. Zu viele Data Scientists mühen sich täglich mit mangelhaft automatisierten SQL-Abfragen ab oder erfinden das Rad neu, in dem sie eigene Hilfsroutinen für Probleme schreiben, für welche gute Open Source Lösungen existieren. Es hat sich viel getan in den letzten Jahren im Bereich der (Open Source) Werkzeuge, die Data Scientists – und allen, die mit ihnen zusammenarbeiten – das Leben erleichtern können, und diese Entwicklung ist noch längst nicht abgeschlossen.

Natürlich lassen sich fundamentale Probleme in Prozessen nicht durch die Einführung neuer Werkzeuge lösen. Und natürlich lässt sich ein historisch gewachsenes Datenökosystem nicht in das Schema eines generischen neuen Wunderwerkzeugs pressen. Doch die wunden Punkte (pain points) eines Teams werden mit einer wachsenden Anzahl von Use Cases und Teammitgliedern nicht geringer, sondern größer. Vielleicht ist es das Fehlen einer standardisierten Projektstruktur, die es mit jedem neuen Projekt immer schwieriger macht, alte Projekte zu warten. Vielleicht ist es die händische Erstellung von Views in der Datenbank, die Zusammenarbeit an komplexen Fragestellungen im Team plötzlich zu einer Herausforderung macht. Oder die Datenqualität, die nicht überwacht wird und das Vertrauen in die Vorhersage von Machine Learning Modelle untergräbt.

Wachsende Komplexität durch gute Werkzeuge meistern

Doch gerade für diese Herausforderungen der Skalierung und Produktivsetzung gibt es mittlerweile Open Source Werkzeuge, in welche nicht nur Praxiserfahrung, sondern auch Best Practices aus der Software Engineering eingeflossen sind. Die folgende Auflistung zeigt beispielhaft, für welche unterschiedlichen Herausforderungen mittlerweile nützliche Werkzeuge existieren:

• Projektvorlagen für Data Science Projekte: Cookiecutter Data Science, PyScaffold, kedro
• Machine Learning / Data Pipeline Framework: kedro
• Machine Learning Experiment Tracking: mlflow
• Daten-Versionierung: dvc
• Validierung und Testen von (relationalen) Daten: great expectations
• Framework für die Erstellung komplexer Transformationen in einem SQL DWH: dbt
• Workflow Orchestrierung: airflow, dagster, prefect, argo
• Error Monitoring & Alerting: sentry
• …

Schon heute profitieren zahlreiche Unternehmen von der Nutzung von Open Source Werkzeugen wie dbt, kedro, great-expectations und anderen, um Daten-, Code- und Modellqualität sicherzustellen und die Zusammenarbeit in Daten-Teams zu verbessern. Dies führt nicht nur zu effektivem Arbeiten, sondern auch zu zufriedenen Data Scientists, die dadurch mehr Zeit für das haben, was sie antreibt – praktisch umsetzbare Erkenntnisse aus Daten zu generieren. Falls Sie Fragen haben – sprechen Sie uns an!