Wie man Data-Science-Projekte nicht in die PoC-Sackgasse manövriert

Warum gelingt es Data-Science-Initiativen häufig nicht, einen echten Mehrwert zu schaffen? Wir haben einige Ursachen dafür ausgemacht. In diesem Blogpost stellen wir vier typische Fallen für Data-Science-Projekte vor und geben Tipps, wie Du sie umschiffen kannst.

Hinweis: Dieser Artikel erschien ursprünglich im Softwerker-Magazin Vol. 14. Das gesamte Heft kann hier als PDF heruntergeladen werden .

Seien wir ehrlich: Obwohl der Künstliche-Intelligenz -Hype aktuell überall zu spüren ist, gelingt es den meisten Unternehmen derzeit noch nicht, mit ihren Data-Science-Initiativen einen Mehrwert für sich oder ihre Kunden zu schaffen. Im Gegenteil: Wir erleben oft, dass sehr viel Budget in Data-Science-Projekte investiert wird, aber nach dem x-ten Proof of Concept (PoC) noch kein Geld verdient wurde.

In vielen Fällen beobachten wir sogar, dass Data-Science-Projekte nicht fortgeführt werden und stattdessen abrupt enden, obwohl es eigentlich erfolgreiche Proofs of Concept gab. Bevor der erste Euro verdient wurde, wird stattdessen häufig schon ein weiterer Proof of Concept gestartet. So hangeln sich die Data Scientists von PoC zu PoC und werden irgendwann mit der unangenehmen Wahrheit konfrontiert, dass trotz aller Bemühungen kein Business Value geschaffen wurde. Da auch wir und unsere Data Scientists regelmäßig an solchen Projekten beteiligt sind, sind wir diesem Problem auf den Grund gegangen und möchten im Folgenden einige Erkenntnisse teilen.

Abgrenzung

Der Artikel fokussiert sich auf die Verprobung einer Idee im Data-Science-Kontext, mit dem Ziel, daraus ein Produkt zu entwickeln und damit Geld zu verdienen. Neben diesem Fokus kann es für Data-Science-Projekte auch das Ziel geben, neue Technologien kennenzulernen und deren Potenzial abzuschätzen. Dabei steht eventuell zunächst nicht die kommerzielle Nutzung dieser Technologie im Vordergrund. Solche Projekte benötigen in der Regel eine andere Steuerung, etwa über die Begrenzung des Budgets oder der Zeit für das Projekt.

Quellen

Während wir die nachfolgend beschriebenen Situationen in unserem Projektalltag regelmäßig antreffen, basieren die empfohlenen Lösungsansätze auf Ideen und Konzepten verschiedenster Quellen im Kontext von „Lean Product Development“. Maßgeblich inspiriert wurde der Artikel insbesondere durch die Arbeiten, die in den Referenzen [1] [2] [3] [4] [5] aufgeführt sind (s. Artikelende).

Fokus auf den Business Case

Viele Data-Science-Projekte starten ohne ausreichend geschärften Business Case. Das ist zunächst einmal nicht unbedingt schlimm. Problematisch kann es jedoch werden, wenn der Business Case in der Anfangsphase des Projekts nicht weiter verfeinert und geschärft wird. Idealerweise unterstützt bereits der PoC dabei, den eigentlichen Business Case zu validieren.

Ein Beispiel: Die Churn Rate beschreibt den Anteil der Bestandskunden eines Unternehmens, die innerhalb eines Zeitfensters das Unternehmen verlassen. Eine Churn Rate von 2 % pro Monat bedeutet zum Beispiel, dass das Unternehmen jeden Monat 2 % seiner Bestandskunden verliert. Um gesund zu bleiben, ist es für das Unternehmen sehr wichtig, diese Churn Rate zu kompensieren – etwa durch Neukundengewinnung. Typischerweise ist das Gewinnen neuer Kunden jedoch deutlich teurer, als Bestandskunden zu halten. Um gezielt diejenigen Kunden anzusprechen, die für das Unternehmen interessant sind, aber potentiell abwandern, ist daher Churn Prediction ein weit verbreiteter Anwendungsfall.

Nehmen wir an, wir möchten validieren, ob es sinnvoll ist, Churn Prediction zu betreiben. Einem ersten Impuls folgend, wird ein PoC mit der Frage  „Können wir Churn vorhersagen?” oder „Wie gut können wir Churn vorhersagen?“ gestartet. Zur Beantwortung der ersten Frage benötigt man streng genommen keinen PoC, denn die Antwort ist schlicht: „Ja!“. Die zweite Frage ist schon besser, führt aber immer noch etwas an der eigentlichen Kernfrage „Kann ich mit Churn-Prediction einen Mehrwert für das Unternehmen schaffen?“ vorbei.

In einem PoC herauszufinden, dass man für 40 % aller Kunden Churn korrekt vorhersagen kann, ist nur ein Teilaspekt, denn eine Genauigkeit von 40 % kann je nach Kontext gut oder schlecht sein. Um wirklich eine Vorstellung davon zu entwickeln, wie die 40 % einzuschätzen sind, muss man den zugrundeliegenden Business Case genauer untersuchen. Dazu gehört es einerseits, konkrete Maßnahmen zu finden, mit denen man potentiellen Churn möglicherweise verhindern kann. Andererseits müssen konkrete Annahmen zu Kosten und Nutzen dieser Maßnahmen getroffen und validiert werden.

Ein Ziel des PoCs wäre es dann, konkrete Annahmen darüber zu treffen, was eigentlich passieren muss, dass mit der zugrundeliegenden Idee – z. B. Churn Prediction  –  ein Mehrwert geschaffen werden kann. Ein Schritt, der in diese Richtung führt, ist es, statt lediglich die Genauigkeit des Modells zu betrachten, eine konkrete Business-Metrik zu entwickeln. Die Genauigkeit des Modells oder andere Modelleigenschaften spielen hierbei natürlich eine Rolle, sind aber nur Faktoren neben Größen wie „Kosten für Neukundengewinnung“ oder „Kosten für Gutscheine, um die Kunden zu behalten“, um den Business Case zu beurteilen.

In der Anfangsphase ist es dazu häufig notwendig, pragmatische Annahmen für verschiedene Faktoren zu treffen. Im Beispiel Churn Prediction ist es etwa sehr schwer vorherzusagen, wie viele Kunden aufgrund eines Gutscheins letztlich nicht kündigen werden. Dennoch spielt dieser Anteil eine große Rolle für den Erfolg der Idee und es ist wichtig, diese Größe in einer Business-Metrik transparent zu machen. Das Ziel ist es, eine initiale Metrik zu entwickeln, die auf konkreten Annahmen beruht. Basierend auf neuen Erkenntnissen und im Projektverlauf kann die Metrik dann stets iterativ verfeinert und die Annahmen können validiert werden.

Ohne Fokussierung auf den Business Case wird häufig zu spät oder gar nicht in Betracht gezogen, was überhaupt alles passieren muss, um tatsächlich Geld mit der Ausgangs-Idee zu verdienen. Oft beobachten wir, dass diese Fragen bewusst zum Projektstart ausgeklammert werden. In vielen Fällen führt diese Unklarheit aber letztlich dazu, dass die Data-Science-Initiative nach dem PoC nicht fortgeführt wird. Es fehlt eine Vision für das Produkt, um der Data-Science-Initiative den nötigen Vorschub zu leisten.

Mindset zum Projektbeginn

Es macht sehr viel Spaß, sich mit KI und neuronalen Netzen zu beschäftigen. Fast täglich werden wir mit neuen Möglichkeiten konfrontiert, die uns KI eröffnet. Darum ist es sehr wichtig, sich ständig daran zu erinnern, dass KI und andere Technologien im Kontext von Data-Science-Projekten lediglich ein Hilfsmittel dafür sind, einen Mehrwert für Kunden zu schaffen.

Startet ein Data-Science-Projekt mit einem Proof of Concept und der oben beschriebenen Fragestellung:  „Wie gut können wir Kündigungen vorhersagen?“ – oder allgemeiner: „Wie gut ist es möglich, mit KI XYZ zu erreichen?“ – ist diese sehr interessant und es ist äußerst spannend, sich mit der Frage zu beschäftigen. Ein solcher Projektstart führt jedoch regelmäßig dazu, dass im PoC exzessive Modelloptimierung betrieben wird.

In der Anfangsphase des Projekts ist es meistens nicht nötig, das vermeintlich beste Modell zu entwickeln. Dennoch werden häufig direkt am Anfang sehr viele Ressourcen in die Modelloptimierung investiert. Die folgenden Gründe sprechen gegen dieses Vorgehen:

• Ein Modell kann beliebig lange weiteroptimiert werden und es gibt oft einen unerschöpflichen Ideenpool, wie das Modell weiter verbessert werden könnte.
• Der Aufwand zur Verbesserung des Modells wächst typischerweise exponentiell und es ist oft noch nicht klar, ob eine Verbesserung der Genauigkeit von 84 auf 87 % wirtschaftlich und überhaupt notwendig ist.
• Neben einem Modell benötigt man noch eine Vielzahl weiterer Software-Komponenten, etwa zum Deployen des Modells und zur Auslieferung der Vorhersageergebnisse, um tatsächlich einen Mehrwert zu generieren.

Pragmatisch gesehen benötigt man, um weiter zu kommen, im ersten Schritt lediglich ein Modell, das schlicht gut genug ist. Die Beurteilung von „gut genug“ kann anhand der oben beschriebenen Business-Metrik erfolgen. Modell-Metriken sind dabei nur ein Faktor in der eigentlichen Business-Metrik und oft entscheiden letztlich ganz andere Faktoren darüber, ob sich mit der Idee überhaupt Geld verdienen lässt.

Eine Empfehlung ist es daher, bereits vom ersten Projekttag an das Gesamtbild nicht aus dem Blick zu verlieren und sich regelmäßig die Frage zu stellen:  „Ist das, was ich gerade vorhabe, notwendig, um herauszufinden, ob ich mit der Idee einen Mehrwert schaffen kann?”

Schnell Erfahrung sammeln

Zu einem gewissen Zeitpunkt befindet sich das Projekt hoffentlich in der Situation, dass ein erstes Modell vorliegt und die Business-Metrik einen relevanten Mehrwert erwarten lässt. Hier basiert die Business-Metrik häufig zwar nicht auf validierten Annahmen, dennoch ist an dieser Stelle ein entscheidender Punkt im Projekt erreicht: Spätestens jetzt geht es darum, damit zu beginnen, die Annahmen hinter dem Business Case zu validieren.

Eine mögliche Falle, in die das Projekt in dieser Situation geraten kann, sind offene Diskussionen über Vermutungen, wie das Modell noch weiter verbessert werden kann oder Hypothesen über den zugrundeliegenden Business Case. Der Grund dafür ist, dass die Diskussionen in vielen Fällen schlicht zu keinem Ziel führen können. Das liegt daran, dass die relevantesten Erkenntnisse nur noch mit Feedback von echten Nutzern und Daten erlangt werden können.

Um möglichst schnell von hypothetischen „Was wäre, wenn“-Diskussionen zu „Was ist, wenn“-Erkenntnissen zu gelangen, gilt es daher, die gesamte Energie darauf zu konzentrieren, einen ersten Prototyp zu bauen und diesen unter realen Bedingungen zu testen. Hierbei geht es darum herauszufinden, ob sich der erwartete Mehrwert tatsächlich realisieren lässt. Also unter anderem die Annahmen der Business-Metrik zu validieren und zu testen, ob das Modell auf echten Daten ebenso zuverlässig und genau funktioniert wie auf den Beispieldaten.

Ein entscheidender Aspekt hierbei ist, so schnell wie möglich ein tragfähiges Fundament für den Business Case zu schaffen. Je länger die Validierung der Annahmen verzögert wird, desto länger basieren Entscheidungen und Weiterentwicklungen auf nicht validierten Annahmen. Dies führt in der Regel dazu, dass die Geschwindigkeit, mit der Anpassungen vorgenommen werden können, immer weiter sinkt und Letztere zusätzlich immer teurer und damit schmerzhafter werden.

Außerdem treten – sobald es darum geht, einen Prototyp zu bauen, diesen in eine IT-Infrastruktur zu integrieren und ihn mit Kunden zu testen – regelmäßig technische Herausforderungen auf, die bis dahin oft nicht absehbar waren. Manchmal verändern diese Herausforderungen den gesamten Business Case und in seltenen Fällen scheitert die gesamte Idee etwa daran, dass etwa Aspekte des Datenschutzes nicht erfüllt werden können.

Gelingt die Integration des Prototyps, stellt sich bei der Validierung typischerweise schnell heraus, dass der Business Case nicht von ein paar Prozent Modellgenauigkeit abhängt, sondern andere Faktoren einen viel größeren Einfluss haben. Umso schmerzlicher ist es, wenn diese Lernerfahrungen erst viel später gemacht werden und stattdessen zunächst viele Ressourcen in die Modelloptimierung investiert wurden.

Unsere Empfehlung ist es daher, möglichst schnell nicht mehr „discussion-driven“, sondern „experiment-driven“ zu arbeiten und validierte Erkenntnisse über den Business Case zu sammeln.

Zusammenstellung des Projektteams

Wenn man die bisher genannten Punkte im Projekt berücksichtigen möchte, zeigt sich schnell, dass hierfür eine Vielzahl unterschiedlicher Fähigkeiten, Kenntnisse und Erfahrungen nötig ist.

Data-Science-Projekte werden allerdings häufig mit einem Team gestartet, in dem ein stark akademisch geprägtes Mindset überwiegt. Dies führt regelmäßig dazu, dass nicht der Kundennutzen oder der Business Case im Vordergrund steht, sondern die Begeisterung für KI und neuronale Netze und damit die Technologie. Das wiederum fördert einen Fokus auf Modelloptimierung und eine große Bereitschaft im Team, den zugrundeliegenden Business Case nicht zu hinterfragen.

Oft haben Data Scientists keinen Hintergrund in Softwareentwicklung. Das allein ist zunächst kein Problem, da Data-Science-Expertise als solche wichtig für das Projekt ist. Besteht das Team jedoch überwiegend aus Data Scientists ohne Software-Engineering-Hintergrund, stellt die Entwicklung eines Prototyps das Team in vielen Fällen vor eine schwer lösbare Aufgabe und es ist schlicht nicht zu erwarten, dass ein solches Team einen schlanken Prototyp entwickelt, der schnell iterativ angepasst werden kann.

Fehlt die Expertise für Produktentwicklung im Team, gelingt es in vielen Fällen nicht, eine belastbare Produktvision zu erarbeiten. Dadurch verschiebt sich häufig der Fokus im Laufe des Projekts und verlagert sich vom Ziel, Kundennutzen schaffen, hin zu anderen technischen Zielen wie Modelloptimierung. Dies führt regelmäßig dazu, dass die Idee nach dem Nachweis der technischen Machbarkeit nicht weiterverfolgt wird und nach einem Abschlussvortrag in der Schublade verschwindet.

Nach unserer Erfahrung benötigt das Team bereits von Anfang an Expertise im Bereich Data/Software Engineering und Produktentwicklung. So kann es einerseits gelingen, den Übergang von der Validierung des Business Case zur Entwicklung eines Prototyps ohne unüberwindbare Reibungseffekte zu gestalten, da Themen wie Data Pipelines, Deployment des Modells und Auslieferung der Ergebnisse an die Nutzer direkt mitgedacht werden können. Andererseits kann aktiv an der Produktvision gearbeitet werden und der fachliche Input zur Erstellung einer Business-Metrik ist im Team vorhanden. Letztlich geht es darum, das Team so aufzustellen, dass der Fokus auf dem eigentlichen Ziel liegt: mit einem neuen Produkt Geld zu verdienen.

Wir empfehlen daher, das Team so zu gestalten, dass es alle notwendigen Fähigkeiten besitzt, um dieses primäre Ziel zu erreichen. Als zugrundeliegendes Paradigma gilt hierbei, alle Rahmenbedingungen so zu setzen, dass möglichst schnelle Feedback-Zyklen möglich sind. Dafür ist es insbesondere notwendig, dass das Team alle Entscheidungen im Projektkontext selbst treffen kann. Dazu gehören einerseits technische Entscheidungen, aber auch Entscheidungen zur Produktvision und die Möglichkeit, direkten Kontakt zu Kunden herzustellen, um Feedback einholen zu können.

Fazit

Typischerweise entsteht der größte Mehrwert für Kunden beim ersten Schritt von keiner Lösung zu einer Lösung. Um den Schritt mit dem Kunden zu gehen, muss die Lösung nicht optimal, sondern lediglich gut genug sein. In diesem Artikel haben wir aufgezeigt, welche Rahmenbedingungen in Data-Science-Projekten regelmäßig dazu führen, dass der Schritt zum Kunden sehr spät oder gar nicht gegangen wird. Da fehlendes Kundenfeedback häufig zu vorschnellen und kostenintensiven Optimierungen führt und nicht validierte Annahmen schlicht bedeuten, zu lange und aufwändig am Kunden vorbei zu entwickeln, ist es hilfreich, sich regelmäßig auf das primäre Ziel des Projekts zu fokussieren.

Der Artikel liefert keine Blaupause für Data-Science-Projekte; er zeigt lediglich auf, welche Bedingungen problematisch sein können, wenn es darum geht, das Ziel – ein erfolgreiches Data-Science-Produkt – zu erreichen. Bei der Umsetzung konkreter Projekte sind unterschiedlichste Rahmenbedingungen vorhanden, die verschiedenste Anpassungen der Vorgehensweise verlangen. Oft ist es nur sehr schwer oder gar nicht möglich, diese Rahmenbedingungen zu verändern. Das Ziel dieses Artikels war es daher, eine generelle Sensibilität zu schaffen, um im nächsten Projekt ein paar hinderliche Rahmenbedingungen gezielt hinterfragen zu können.

Unsere Herangehensweise an Data-Science-Projekte präsentieren wir in unserem kostenlosen On-Demand-Webinar (Deutsch) . Außerdem zeigen wir in unserem Deep-Learning Tutorial: DISH-O-TRON (Englisch) (mit einem Augenzwinkern) wie man von einer Data-Science-Idee bis zum Ende-zu-Ende Prototypen kommt.

Jetzt einen unverbindlichen Austausch anfordern über ki@codecentic.de .

Referenzen & Link-Tipps

[1] https://developers.google.com/machine-learning/guides/rules-of-ml/
[2] https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf
[3] http://theleanstartup.com/book
[4] https://multithreaded.stitchfix.com/blog/2019/03/11/FullStackDS-Generalists/
[5] http://lpd2.com/
[6] codecentric.AI Bootcamp
[7] Data Science zum Mittagessen