13Wirtschaftlichkeitsbetrachtung bei der Auswahl & Entwicklung von Data Science

Eine Fallstudie im Online-Lebensmitteleinzelhandel

Nicolas March

Die Abteilungen für Business Intelligence & Analytics der heutigen Unternehmen unterstützen unterschiedliche Geschäftseinheiten wie Marketing, Logistik oder das Personalwesen mit Data-Science-Lösungen. Dabei werden die gesammelten Datenbestände der Unternehmen nach Mustern und Zusammenhängen durchleuchtet, um effiziente Prozesse und wirkungsvolle Softwareprodukte mit Smart und Big Data zu entwickeln. Fast alle Unternehmen stehen dabei vor einer großen Herausforderung: Analytics-Know-how und -Ressourcen sind knapp und stehen den vielen Anwendungs- und Analyseideen der eigenen Data Scientists, Fachabteilungen, CDOs und CEOs gegenüber. Die Leiter der Analytics-Abteilungen müssen dadurch ihrer Pflicht nachkommen, die Projekte und Initiativen mit den größten Erfolgsaussichten auszuwählen und insbesondere der Wirtschaftlichkeitsbetrachtung und der Erfolgsmessung ausreichend Platz im Prozess einzuräumen. Anhand einer praktischen Fallstudie im noch jungen Online-Lebensmitteleinzelhandel (kurz: Online-LEH) zeigen wir das methodische Vorgehen bei Auswahl, Entwicklung und Erfolgsmessung einer Data-Science-Anwendung zur Verringerung des Risikos von Fehlinvestitionen in der Praxis.

13.1Herausforderungen in der Praxis

13.1.1Data-Science-Anwendungen im Online-LEH

Der professionelle Online-Lebensmitteleinzelhandel ist gemessen am stationären LEH-Geschäft ein sehr junger Vertriebskanal. Das Geschäftsmodell klingt relativ einfach: die Bestellung von Lebensmitteln über einen Webshop per Desktop-PC, Smartphone oder Tablet und die Lieferung der Produkte an die Haustür des Kunden.

Den Analytics-Abteilungen der Online Retailer stehen aufgrund dieses Vertriebskonzepts eine Vielzahl sehr detaillierter Datenquellen gegenüber: Durch die Registrierung des Kunden und bei entsprechender Einwilligung zur Speicherung seiner Daten im Rahmen der gesetzlichen Vorgaben können schon zu Beginn der Customer Journey auf den Webseiten völlig neue Erkenntnisse über das Einkaufsverhalten der Kundschaft ermittelt und nutzbar gemacht werden. So sieht man beispielsweise, ob der Kunde Produkte in seinen Warenkorb gelegt und später wieder gelöscht hat oder welche Webseiten er vor dem Shop besucht hat. Diese Daten ergänzen die auch schon im stationären Handel seit jeher betrachteten Transaktionsdaten bzw. die tatsächlich gekauften Warenkörbe der Kunden, die einen Einblick in die Zusammenstellung der unterschiedlichen Produkte geben. Aber auch für die Distribution und Logistik steht ein für Lebensmittelhändler neuer Datenstrom zur Verfügung – die »letzte Meile« zum Kunden. Hieraus ergeben sich für die Online-Lebensmittelhändler neue Anwendungsfälle und Herausforderungen, wie optimale Routenführung der Zusteller oder die Prognose von Stand- und Fahrtzeiten der Lieferfahrzeuge für eine kosteneffiziente Verteilung der Bestellungen an die Endkunden. Schließlich möchte man möglichst viele Kunden in einer Betriebsstunde beliefern und dabei auch das vom Kunden gebuchte Lieferfenster einhalten.

Einig ist man sich, dass die Nutzung dieser Daten elementar für eine effiziente Produkt- und Prozessentwicklung ist, da auf Dauer nur so ein für den Kunden attraktiver und für den Händler wirtschaftlicher Service sichergestellt werden kann.

13.1.2Auswahl und Umsetzung wirtschaftlicher Anwendungsfälle

Die Vielzahl der unterschiedlichen Datenquellen wie Web-, Abverkaufs-, Kunden- und Logistikdaten sowie die damit einhergehenden Anwendungsfälle für Methoden der Data Science lassen ein Auswahlproblem entstehen. Üblicherweise stehen diesen Anwendungsfällen nur eine begrenzte Anzahl analytischer Ressourcen mit entsprechender Zeitrestriktion gegenüber. Wichtig ist hier die Konzentration auf Probleme, die den maximalen ROI (Return on Investment) versprechen. Üblicherweise wird man sich zunächst auf die Anwendungsfälle beschränken, für die sich das günstigste Kosten-Nutzen-Verhältnis berechnet. Der explorative Charakter von Data-Science-Anwendungen macht jedoch eine gesicherte Abschätzung des Erfolgs und damit die Berechnung des ROI schwierig. So ist selten voraussehbar, ob die Hypothese oder der Use Case durch die bereits vorhandenen Daten abbildbar ist.

Beispielsweise könnte der Stockmanager ein Scoring-Modell wünschen, bei dem er seinem Lieferanten einen Wert für die Ausfallwahrscheinlichkeit einer anstehenden Warenbelieferung zuweist. Je nach Scoring-Wert könnte dann der Warenbestand entsprechend angepasst und für den Kunden nachteilige Engpässe in der Warenverfügbarkeit verringert werden. Für ein solches Scoring-Modell zur »Lieferantenausfallwahrscheinlichkeit« kann man sich bekannte Attribute der vergangenen Belieferungen ansehen, wie »Menge«, »Bestellzeitpunkt«, »Bestellvorlauf«, »Warentyp«, »Spedition« etc., und anhand dieser ein entsprechendes Modell trainieren. Fehlen in einem solchen Modell jedoch stark erklärende Variablen, wie beispielsweise »Anfahrtsstrecke« oder »Verkehrssituation zum Zeitpunkt X«, liefert das Modell keine ausreichende Genauigkeit für eine Ausfallprognose.

Data Scientists müssen dann neue Datenintegrationsprojekte initiieren, um den Use Case doch noch zu realisieren – ohne häufig zu wissen, ob nun tatsächlich alle relevanten Datenpunkte integriert sind, die eine theoretische Prognose ermöglichen. Neben der Datenverfügbarkeit ist auch die Datenqualität ein Showstopper, der die Güte von Modellen stark beeinflusst bzw. schwer operationalisierbar macht.

Ebenso müssen technische Limitierungen früh abgeschätzt werden, damit selbst im Zeitalter von Cloud-basierten Data-Management-Plattformen (DMP) keine Laufzeiten in den Modellen entstehen, die eine Nutzung durch den Anwender nicht mehr praktikabel machen. Unkorrekte Schätzungen über die seitens der analytischen DMP verarbeitbaren Datenmenge führen dazu, dass Rückgabewerte von Modellen oder deren Visualisierung erst so verzögert angezeigt werden können, dass eine nachträgliche Verdichtung der Daten mit entsprechendem Informationsverlust nötig wird.

Um uns von Beginn an auf die Wirtschaftlichkeit von Data-Science-Lösungen zu konzentrieren, setzen wir daher auf einen mehrstufigen, iterativen Prozess, der mit unterstützenden Analysen zur Auswahl von Anwendungsfällen beginnt (vgl. Abb. 13–1).

image

Abb. 13–1Iterativer Prozess zur kontinuierlichen Sicherstellung der Wirtschaftlichkeit von Data-Science-Anwendungen

Vorauswahl

Die oben genannten Probleme wie Datenverfügbarkeit und Datenqualität sind nicht unbekannt – müssen aber bei jeder Initiative erneut geprüft und analysiert werden. Vorabanalysen durch Business und Data Analysts in Zusammenarbeit mit dem Fachbereich helfen frühzeitig, die entsprechenden Anwendungsfälle zu schärfen und den Blick auf die Fälle mit der höchsten Erfolgswahrscheinlichkeit und dem höchsten ROI zu richten. Bereits bei der Auswahl der Anwendungsfälle kann erfahrungsgemäß die Wirtschaftlichkeit leiden, wenn wichtige Rahmenbedingungen nicht beachtet werden.

Entwicklung von Prototypen

Nach Auswahl des priorisierten Use Case müssen während dessen Entwicklung notwendige Entscheidungsunterstützungen erfolgen, damit das Projekt aus wirtschaftlicher Sicht erfolgreich wird.

Über viele Fragestellungen liegen häufig noch wenige Erkenntnisse hinsichtlich des Lösungsraums vor. Beispielsweise gibt es unterschiedliche methodische Herangehensweisen oder es ist generell noch fraglich, ob mittels eines Modells mit den Daten verwertbare Ergebnisse erzeugbar sind. Um den Lösungsraum einzugrenzen und vor allem zu prüfen, ob der Output – wie z.B. ein Wahrscheinlichkeitswert für den Lieferantenausfall – überhaupt eine gewisse Vorhersagekraft hat, sind prototypische Ansätze in der Praxis eher die Regel als die Ausnahme. Hierbei werden beispielsweise auf Produktivdaten in Sandbox-Umgebungen Expost-Analysen und vorläufige Modelle entwickelt und validiert (vgl. [Trahasch & Zimmer 2015]). Auch identifizierte Muster oder Zusammenhänge, die über Data-Mining-Ansätze erkannt wurden, können zunächst in prototypischen Prozessen auf ihre Nutzbarmachung überprüft werden. Letztlich ermöglicht diese Vorgehensweise die Prüfung eines Modells oder analytischen Prozesses, ohne dass z.B. ein Entwicklungsteam mit anderweitigen Modulen, wie dem User Interface, wertvolle Ressourcen bindet.

Agile testgetriebene Produkt- und Prozessentwicklung

Aus den Prototypen können sich konkrete Softwareprodukte oder analytisch unterstützte Produktivprozesse entwickeln, wenn beispielsweise die Modellgüte bereits auf Teilmengen der vorhandenen Daten valide Ergebnisse verspricht und der Fachbereich von der Anwendbarkeit überzeugt ist. Dennoch muss der analytische Kern solcher Prototypen häufig in eine Software integriert werden, um Anwendbarkeit, Stabilität und Skalierbarkeit der Lösung sicherzustellen. Beispielsweise kann ein Lieferantenausfallmodell vorkonzipiert werden und auf einem Teil der Supply-Chain-Daten valide Ergebnisse liefern. Dennoch könnte eine Überführung beispielsweise des Modells auf eine Produktivplattform oder die Integration in ein Bestellmengenmodul notwendig werden, um die Ausfallwahrscheinlichkeitswerte direkt in automatisierte Bestellmengenanpassungen zu überführen. Auch die Konzeption eines Modells auf Datenstichproben birgt Risiken, wenn die Stichprobe die Grundgesamtheit nicht korrekt widerspiegelt (z.B. durch zufällige saisonale Verzerrungen oder die falsche Methode zur Extraktion von Sample-Daten). Hat man auf der Grundlage verzerrter Zufallsstichproben modelliert, ist das Ergebnis in der Regel wertlos.

Im nächsten Abschnitt des Entwicklungsprozesses fließen in der Gesamtbetrachtung die meisten Aufwände und damit Kosten ein. Auch wenn Prototypen bereits den analytischen Kern recht gut evaluieren können, so besteht häufig noch ein großer Unterschied zwischen dem Output des Prototyps und dem Endprodukt im Feld, z.B. dem Launch einer Recommendation Engine oder der Implementierung eines Lieferanten-Scorings in den Warenbestellsystemen. Zur Risikominimierung in der Produktentwicklung wurden agile Modelle entwickelt, die den Ansatz verfolgen, mittels eines iterativen Ansatzes unter stetigem Einbezug der Stakeholder zunächst MVPs (Minimum Viable Products) zu entwickeln, die mit jeder Entwicklungsschleife einen höheren Reifegrad erhalten (vgl. [Rubin 2014]). Der Vorteil kleiner Iterationen liegt darin, frühzeitig Fehlentwicklungen zu erkennen und nicht am Bedarf des Kunden bzw. Auftraggebers vorbei zu entwickeln.

Durch den fortschreitenden Erkenntnisgewinn kann jederzeit überprüft werden, ob das übergreifende Ziel der Initiative weiterhin erreichbar ist oder ob man zusätzliche Investitionen in das Produkt oder den Prozess möglicherweise zurückstellen sollte. Das iterative Vorgehen in einem agilen Framework kommt dabei dem typischen Arbeitsmodell der Data Scientists entgegen, die seit jeher durch den explorativen Charakter in iterativen Arbeitsmodellen, wie beispielsweise CRISP-DM, arbeiten und eine ständige Überprüfung ihrer Modelle vor Inbetriebnahme anstreben (vgl. [Nisbet et al. 2018]).

Um aber die Wirtschaftlichkeit der Maßnahmen unumstößlich zu belegen und damit den ROI wirksam zu messen, ist die Messung der Maßnahme durch Feldtests erforderlich. Für die Unternehmen ist es nutzlos, wenn das Lieferanten-Scoring-Modell im Entwicklungsprozess eine gute Prognose des Ausfalls liefert, aber nach Go-live kaum besser als der Zufall eine Vorhersage trifft. Hier müssen frühzeitig multivariate oder einfache Split-Tests durchgeführt werden, die prüfen, ob auch wirklich ein statistisch signifikanter Effekt nachgewiesen werden kann und der modellgestützte Prozess gewinnbringend ist. In der Produktentwicklung, die analytische Modelle enthält, versucht man zunehmend, die Feldtests in den Entwicklungsprozess zu integrieren und damit von Beginn an den gezielten Nachweis der Wirtschaftlichkeit zu erbringen und weitere Iterationen in der Produktentwicklung zu rechtfertigen. Diese datengetriebene agile Entwicklung hilft den Unternehmen, Fehlinvestitionen zu vermeiden und die analytische Anwendung zu einem Erfolg zu führen.

13.2Fallstudie: Kaufempfehlungssysteme im Online-Lebensmitteleinzelhandel

Wie die konkrete Umsetzung des oben genannten Frameworks aussieht, zeigen wir anhand der Entwicklung eines Empfehlungssystems auf der Onlineplattform von REWE digital. Das Prinzip von entscheidungsunterstützenden Empfehlungssystemen im E-Commerce ist dem Großteil der heutigen Internetnutzer aus diversen Onlineshops bekannt. Dem Kunden werden auf Basis seiner im Verlauf des Einkaufsakts ausgewählten Produkte weitere dazu passende Empfehlungen genannt bzw. angezeigt. Grundlage der Empfehlungen sind dabei das Verhalten anderer Käufer, die beispielsweise das gewählte Produkt in Kombination mit anderen Produkten bereits in der Vergangenheit erworben oder angesehen haben. Die gängigen Algorithmen empfehlen dann beispielsweise zu den Nudeln eine passende Sauce.

Große Onlineplattformen für Elektronik- und Modeprodukte nutzen diese »Recommendation Engines« seit Mitte der 90er-Jahre, um dem Kunden inspirierende, für ihn neue und unbekannte Produkte aus dem zumeist breiten Sortiment näherzubringen. Im Prinzip erhoffen sich die Händler dadurch Cross- oder Upselling-Effekte und ein verbessertes Kauferlebnis des Kunden. Umsatzsteigerungen im zweistelligen Prozentbereich gegenüber einem Shop ohne entsprechende Empfehlungssysteme in diesen Sparten versprechen ein hohes Potenzial solcher Anwendungen (vgl. [Dias et al. 2008]).

Den großen Erfolg der Empfehlungssysteme im E-Commerce nutzt auch der Online-LEH für sich, indem die bekannten Methoden auf den Lebensmitteleinkauf übertragen werden. Doch ein simpler Transfer der Methodenansätze führt nicht zwingend zum Erfolg, da beispielsweise der sporadische Einkauf von Elektronikartikeln völlig unterschiedlich zum wöchentlichen Pflichteinkauf von Lebensmitteln ist. Demzufolge ist nicht jeder Empfehlungsansatz zwingend 1:1 auf den E-Commerce mit Lebensmitteln übertragbar, sondern sollte an die Situation und die Umstände des Kunden und seine Customer Journey angepasst werden.

Die Produktentwicklung für Empfehlungssysteme auf einer Onlineplattform muss mehrere Faktoren berücksichtigen:

Während die Darstellung der Produktempfehlung größtenteils durch die UX/UI Designer beeinflusst wird – möglichst anhand von qualitativen UX-Studien –, ist die Ausspielung der vorgeschlagenen Produkte stark von den algorithmischen Methoden abhängig, die durch die Data Scientists im Entwicklungsprozess beigesteuert werden. Welche Methode angewendet wird, hängt wiederum von Ort und Zeitpunkt innerhalb der Customer Journey ab. Beispielsweise kann ein Algorithmus am Ende der Bestellstrecke bereits alle bisherigen im virtuellen Warenkorb angesammelten Items berücksichtigen, während ein Algorithmus zu Beginn des Einkaufsvorgangs – z.B. auf Basis von getätigten Suchergebnissen oder besuchten Inhalten – völlig andere Verfahren nach sich ziehen kann. Hier entsteht also bereits frühzeitig ein weiteres Auswahlproblem, da man vor der Entscheidung steht, mehrere Methoden mit unterschiedlichen Zeitpunkten und Orten der Customer Journey zu kombinieren.

13.2.1Vorabanalysen zur Platzierung von Empfehlungen

Um über Ort und Zeitpunkt der Ausspielung ein klares Bild zu erhalten, besteht die Möglichkeit, durch Digital Analysts das Einkaufsverhalten auf der Website zu analysieren. Digital Analysts nutzen dabei gängige Webanalysetools, um beispielsweise zu prüfen, an welchen Stellen im Shopsystem der durchschnittliche Kunde den Wareneinkauf abbricht oder in welcher Warenkategorie die Verweildauer am höchsten ist und aus welcher dem virtuellen Warenkorb am häufigsten Produkte hinzugefügt werden. Diese Analysen liefern erste Erkenntnisse über Ort und Zeitpunkt zur Ausspielung von Empfehlungen und verhindern, dass ein gegebenenfalls suboptimaler Ansatz gewählt wird. Beispielsweise wäre es denkbar, schon auf der Startseite einen ausgefeilten Empfehlungsalgorithmus zu implementieren. Wenn jedoch ein Großteil der Kunden über entsprechende Werbekanalzuführung nie die Startseite zu Gesicht bekommt und direkt über Produktdetailseiten in das Shopsystem einsteigt (z.B. über einen Suchmaschinen-Link), macht die Platzierung eines Empfehlungssystems auf der Startseite gegebenenfalls wenig Sinn. Erfolgversprechender ist dann ein System, das auf Seiten liegt, die der Kunde betreten muss – wie der Check-out eines Onlineshops. Hier ist die Kaufentscheidung größtenteils getroffen und der Kunde eher bereit, noch weitere Produkte hinzuzufügen, anstatt Produkte zu substituieren.

Die Analysts im Online-LEH stellen mit hoher Wahrscheinlichkeit in jedem Shopsystem fest, dass der Kunde mit zunehmender Dauer nur noch wenige Produkte im Warenkorb anhäuft (vgl. Abb. 13–2):

image

Abb. 13–2Abhängigkeit zwischen Einkaufsdauer und Anzahl ausgewählter Produkte

Während zu Beginn des Einkaufsakts sehr zügig die wichtigsten und präsentesten Produkte erworben werden, verlangsamt sich die Frequenz der Produktauswahl zum Ende hin deutlich. Diesen Umstand kann man berücksichtigen, indem man den Kunden gerade zum Ende seines Einkaufsakts mit Empfehlungen unterstützt, die für ihn inspirierend sein können. Wenn der Kunde im Check-out-Warenkorb beispielsweise Mehl, Hefe und Käse liegen hat, wäre die Einblendung eines Pizzarezepts mit Olivenöl und Tomatenmark sinnvoll.

Es zeigt sich, dass die Analysts durch diese Informationen die systematische Priorisierung unterstützen. Dadurch tragen sie wesentlich zur Sicherstellung der Wirtschaftlichkeit bei.

13.2.2Prototypische Entwicklung eines Empfehlungsalgorithmus

Fraglich bleibt allerdings, wie der Inhalt der Empfehlungen ausgestaltet sein soll. Hier kommen die Data Scientists zum Einsatz, die sich vorab – gegebenenfalls schon in frühzeitiger Abstimmung mit den Produktentwicklern – aus einer Vielzahl von Methoden bedienen können. Die Standardalgorithmen wie Association Rule Mining, Collaborative Filtering und Clustering sind seit vielen Jahren bekannt und gehören zum Standard vieler statistischer Programmierumgebungen oder Big-Data-Frameworks. Bezogen auf den Anwendungsfall liegt jedoch die Schwierigkeit in der Adaption auf den Online-LEH. Hier sind unterschiedliche Gegebenheiten zu beachten, wie z.B. extreme schiefe Häufigkeitsverteilungen (z.B. ist Milch in beinahe jedem zweiten Warenkorb zu finden, Zahnstocher hingegen nur sehr selten).

Es empfiehlt sich, frühzeitig explorativ auf Basis der vorhergehenden Analysen und mit den vorhandenen Datentöpfen modelltechnische Prototypen zu entwickeln. Hier können beispielsweise anhand der bereits gesammelten Transaktionsdaten verschiedene Methoden ausprobiert und evaluiert werden.

Im Fall von Recommender-Systemen besteht das Problem, dass es sich häufig um unüberwachte Lernmodelle handelt (z.B. Item-based Collaborative Filtering oder Clustering, vgl. [Gorakala 2016]). Der Algorithmus des maschinellen Lernens bildet dabei Empfehlungen anhand von Übereinstimmungen zu anderen Nutzern bzw. Warenkörben heraus. Dagegen hat man im Fall der Methoden des überwachten Lernens eine ex post bewertete Zielvariable wie »Ausfall der Lieferung zum Zeitpunkt X« im Datensatz. Die Wirksamkeit überwachter Modelle kann man an Test- und Validierungsdatensätzen vorab gut überprüfen. Dies entfällt für Methoden des unüberwachten Lernens. Folglich muss anderweitig die Sinnhaftigkeit und Verwendbarkeit der generierten Empfehlungen getestet werden. Es bleibt die Option, den Output des Prototyps mit dem Fachbereich in User-Tests überprüfen zu lassen. Hierdurch kann der Data Scientist und Fachbereich bereits sehen, ob Empfehlungen wie »wer Hamburgerbrötchen kauft, hat Interesse an Röstzwiebeln« hinreichend nachvollziehbar sind. Ob diese Art der Empfehlungen wirklich zu positiven Cross-Selling-Effekten führen und vom Kunden akzeptiert werden, ist dagegen nicht sichergestellt.

13.2.3MVP und testgetriebene Entwicklung der Recommendation Engine

In der agilen Produktentwicklung wird die Initiative erneut bewertet und der analytische Prototyp hinterfragt. Im Fall von Empfehlungssystemen fließt ein Teil des Aufwands in die Prüfung zur technischen Umsetzbarkeit des Prototyps. Beispielsweise können verwendete Algorithmen im Sandbox-Umfeld nicht immer zwingend 1:1 in den Produktivbetrieb übernommen werden, da z.B. die Livesysteme anderen Restriktionen hinsichtlich der Laufzeiten unterliegen. Für den Kunden im Shop wäre es unzumutbar, die Empfehlungen nur verzögert auf der Website anzuzeigen.

Wesentlich für den weiteren Entwicklungsprozess ist jedoch die Frage, ob die Empfehlungen überhaupt einen spürbaren Effekt wie Umsatzsteigerungen erbringen. Bei Entwicklung des MVP können beispielsweise die ersten erfolgversprechenden Empfehlungsalgorithmen integriert werden, ohne dass eine detaillierte Parameteroptimierung durchgeführt werden muss. Gerade im Fall von Empfehlungssystemen gibt es auch nach Eingrenzung des Algorithmus noch eine Vielzahl von Einstellungsmöglichkeiten, die einen deutlichen Einfluss auf den Output nehmen können. Bevor es dazu kommt und man entsprechende Aufwände in den Teams generiert, sollte man schon während des MVP den Grundstein für eine testgetriebene Entwicklung legen. Dabei geht es darum, durch multivariate oder einfache Split-Tests den Einfluss des MVP auf die Kern-KPIs (Key Performance Indicators) des Unternehmens zu prüfen. Im Fall einer Recommendation Engine können beispielsweise zwei unterschiedlichen Kundengruppen unterschiedliche Varianten des Empfehlungssystems ausgespielt werden und die Ergebnisse anschließend mittels statistischer Testverfahren ausgewertet werden. Mögliche KPIs sind beispielsweise die Anzahl unterschiedlicher Artikel im Warenkorb oder eine verkürzte Einkaufsdauer. Geht man davon aus, dass Recommendation Engines auch die Kundenzufriedenheit erhöhen, sind auch Kennzahlen wie »Kauffrequenz« oder »Kundenloyalität« als Indikatoren für ein gelungenes Empfehlungssystem denkbar. Generell sollte man eine Vielzahl unterschiedlicher KPIs in die Auswertung des Testszenarios aufnehmen, da durchaus nicht voraussehbare – gegebenenfalls positive oder negative – Effekte entstehen können. So könnten im Fall von Empfehlungssystemen Varianten unbeabsichtigt entstehen, die zwar die Anzahl der gekauften Produkte oder den Gesamtumsatz nicht signifikant beeinflussen, aber die Warenspanne erhöhen. Unabhängig von den KPIs ist es für die weiteren Iterationen im Entwicklungsprozess notwendig, den Einfluss der maschinell generierten Empfehlungen gegenüber der Null-Variante (= Deaktivierung des Empfehlungssystems) oder gegenüber einer Alternativ-Variante (z.B. Zufallsauswahl von Produkten) zu testen und die Ergebnisse direkt wieder in die Folgeiterationen einfließen zu lassen. Sind schon im MVP nur geringe, signifikante Einflüsse erkennbar, kann man spätere Iterationsschleifen hinsichtlich des Kosten-Nutzen-Effekts besser abschätzen oder gar ganz von der weiteren Produktentwicklung absehen. Für eine Beschleunigung der Entwicklungsiterationen sind teilautomatisierte Teststrecken hilfreich, die beispielsweise die Testgruppen einteilen, die Auswertung begleiten oder den Stichprobenumfang kontrollieren. Die Kontrolle der Wirksamkeit gehört dabei auch zum Standardrepertoire der Data Scientists, da sowohl für die Entwicklung der Teststrategien und Testszenarien als auch für die Interpretation der Ergebnisse die nötige fachliche Expertise erforderlich ist.

13.3Fazit

Die Wirtschaftlichkeit von Data-Science-Modellen und -Anwendungen obliegt von Beginn an einer notwendigen Überprüfung. Bereits bei der Auswahl der Initiativen können Business und Data Analysts durch datengetriebene Auswertungen wichtige Informationen für die erforderliche Priorisierung von Maßnahmen liefern.

Die Entwicklung von vorläufigen Modellen und Prototypen jenseits der produktiven Systeme auf Basis von Stichprobendatensätzen ist eine Möglichkeit, den methodischen Lösungsraum einzugrenzen und die Durchführbarkeit auf ein sicheres Fundament zu setzen.

Der MVP als Aufsatz für die testgetriebene Produktentwicklung von Data-Science-Anwendungen ist dann ein hilfreiches Vehikel, die Wirtschaftlichkeit der Maßnahmen schon während des Entwicklungsprozesses zu kontrollieren und Fehlinvestitionen vorzubeugen.

Subjektiv ist festzustellen, dass viele Unternehmen vermehrt noch genauer auf den ROI ihrer Data-Science-Lösungen schauen. Nicht mehr jede Methodik oder jedes große Datenintegrationsprojekt im Rahmen von Big-Data- oder Data-Science-Anwendungen wird angegangen, wenn sich die Wirtschaftlichkeit nur sehr schwierig abschätzen lässt. Der große Druck zur Digitalisierung der Unternehmen erfordert eine zielführende Ausrichtung der kostenintensiven Ressourcen und fordert einen möglichst sparsamen Einsatz von vielen explorativen Entwicklungsschleifen im Rahmen des R&D-Prozesses. »Fail-Fast«-Ansätze sind daher in der Data Science genauso etabliert wie in der agilen Produktentwicklung.