Machen Sie aus Ihren Experimenten Produkte.
Wie Sie in unserem Artikel zum ersten Tag der Veranstaltung lesen können, ist die Zeit der Prototypen vorbei, wenn es um Datenanalyse mit messbarem Mehrwert geht. In diesem Kontext tauchte im Rahmen der Vorträge des zweiten Tages in Berlin immer wieder der Begriff Produkt bzw. Datenprodukt auf.
Ein Produkt ist das Ergebnis eines Prozesses. Dieser reicht von der Idee über den Rohstoff und schlussendlich zum Endprodukt. Im Gegensatz zu einem Projekt ist es kein einmaliges Ereignis. Vielmehr muss ein Produkt kontinuierlich weiterentwickelt und betreut werden.
Bei einem Datenprodukt entsprechen Idee, Rohstoff und Produkt grob gesprochen dem Anwendungsfall, den Daten und der Applikation, welche schlussendlich dem Endanwender zur Verfügung gestellt wird. Diese Applikation soll mit Hilfe von Daten die durch den Anwendungsfall definierte Problemstellung lösen.
Dr. Frank Block von Roche Diagnostics skizzierte dazu in der Keynote des zweiten Tages „Data Science at Roche Diagnostics – From Exploration to Productionisation“ den Weg von „data to insights“ und von „insights to production“ in seinem Unternehmen. Spannend war dabei, wie sich seiner Meinung nach die Rollen und die Anforderungen an diese im Rahmen der „Productionisation“ von Data Science verändern:
Ein Prozess von Anfang an: auch die Generierung von Ideen zu Anwendungsfällen, welche mit Datenanalyse gelöst werden sollen, findet bei Roche Diagnostics im Rahmen von strukturierten Workshops statt. In diesen bedient man sich konzeptioneller Werkzeuge wie beispielsweise Design Thinking.
Wichtig ist die strukturierte und schrittweise Zerlegung der Komplexität. Etwas das auch bei der Anwendung des Datenstrategie-Designkits bzw. in den Datenstrategie-Workshops von Datentreiber vermittelt wird.
Betten Sie Ihre Produkte in einen Entwicklungszyklus ein.
Ein Produkt muss also weiterentwickelt werden. Weiterentwicklung und Verwendung des Produkts müssen aber Hand in Hand gehen. Also möglichst ohne Reibungsverlust. René Traue und Christian Lindenlaub von der GfK teilten ihre Erfahrungen dazu in ihrem Vortrag „Data Science Development Lifecycle – Everyone talks about. Nobody really knows how to do it and everyone thinks everyone else is doing it“.
Auch hier war gut zu sehen, welchen Einfluss die erwähnte Produktcharakteristik auf den gesamten Prozess der Entwicklung nimmt. Dabei war es den beiden Vortragenden wichtig, zwischen folgenden zwei Phasen bei der Entwicklung eines Datenprodukts zu unterschieden:
- Research-Entwicklung: die frühe Phase in der außer der Problemstellung fast keine weiteren Details der Aufgabe bzw. der Lösung klar sind.
- Production-Entwicklung: die Problemstallung wurde gelöst. Das Datenprodukt muss nun darauf vorbereitet werden im laufenden Betrieb eingesetzt werden zu können.
Aus eben genannter Trennung ergaben sich bei der GfK wiederum zahlreiche Maßnahmen, wie zum Beispiel:
- Im Bereich der Research-Entwicklung wurde schrittweise die Vorgehensweise nach Scrum durch eine leichtgewichtigere mittels Kanban ersetzt. Beispielsweise können bereits angefangene Aufgaben jederzeit zurückgestuft werden und in ein zusätzliches Refinement gehen. Die sture Abarbeitung von Sprints entfällt.
- Der Technical Review wurde durch sogenannte Storytelling Sessions ersetzt. In diesen sehr fachlich abgehaltenen Sessions, die in erster Linie auf Stakeholder aus dem Fachbereich zugeschnitten sind, geht es vor allem darum herauszufinden, ob auch tatsächlich die richtigen Probleme gelöst werden. Etwas das trivial klingt, es aber keinesfalls ist, wenn Sie das Plädoyer von Dean Abbot zum Customer Lifetime Value in unserem ersten Artikel gelesen haben.
- Um Konflikte zwischen Research und Production zu minimieren, wurde die neue Rolle des Machine Learning Engineers definiert. Eingebettet in das Data Science Team nimmt diese Rolle bereits zu einem frühen Zeitpunkt Rücksicht auf sogenannte Production Principles. Diese umfassen beispielsweise das Code Refactoring oder die konsequente Verwendung von Git zur Versionsverwaltung des Codes.
Zu guter Letzt erläuterten Traue und Lindenlaub, wie es selbst entwickelte QPIs (Quality Performance Indicators) der GfK erlauben, die Wartung im Rahmen des Live-Betriebes eines Datenprodukts von Incident-basiert auf einen mehr vorausschauenden Ansatz zu ändern. Echtes „data science development at scale“ wie Moderator Norbert Wirth nicht müde wurde zu betonen.
Balancieren Sie Preis, Risiko und gewinnen Sie das Anwendervertrauen in Ihre Produkte.
Ausgehend von der These, dass ein Datenprodukt grundsätzlich drei große Herausforderungen meistern muss, startete Nikita Matveev von S7 Airlines in seinen Vortrag „Bricks and Mortar of a Data Science Product“. Seiner Meinung nach sind die Herausforderungen:
- Kosten
- Risiko
- Vertrauen
Die von Matveev präsentierten Maßnahmen zur Begegnung dieser Herausforderungen sind unter anderem:
- Eine solide fachliche Analyse, um die Anforderungen bzw. die Zielsetzung des Product Owner auch wirklich zu verstehen.
- Konsequenter Fokus auf User Experience, da das Produkt erst Mehrwert bietet, wenn es vom Anwender verwendet wird bzw. in seinen Arbeitsablauf integriert ist.
- Agile, cross-funktionale Teams, welche die Problemstellung gesamtheitlich greifen bzw. bearbeiten können.
Jeder dieser Bausteine trägt bei S7 Airlines maßgeblich zum Erfolg eines Datenprodukts bei.
Matveev nannte als ein Beispiel die Entwicklung eines Modells zur Optimierung der Auslastung. Diese nahm nur ca. drei Monate in Anspruch. Die Integration des Modells in das System der Endanwender wiederum dauerte ungefähr viermal so lang. Also erst nach einem weiteren Jahr konnte das Produkt erfolgreich in der Produktion eingesetzt werden.
Verpassen Sie keine Neuigkeiten.
Hat Ihnen dieser Artikel gefallen? Dann registrieren Sie sich doch gleich für den Datentreiber-Newsletter. Somit erhalten Sie Informationen zu zukünftigen Konferenzen inklusive Rabattcodes sowie monatlich weitere Beiträge und Neuigkeiten rund um Datenstrategie-Design und Analytics.
Anmerkung: Dieser Beitrag wurde von unserem Gastautor Martin Raffeiner, Geschäftsführer von datenbotschafter consulting, verfasst.
