4Konzeption und Entwicklung von Data-driven Products/Datenprodukten

Christoph Tempich

Data Science bietet große Vorteile für Unternehmen, weil man mit ihr aus Daten neue Angebote für Kunden entwickeln kann. Dabei arbeiten verschiedene Disziplinen eng zusammen – vom Produktmanagement über das Datenmanagement bis hin zum Design –, denn die Methoden der Data Science und ihre Ergebnisse sind nicht ohne Weiteres allgemeinverständlich. Die Erkenntnisse der Data Science müssen vielmehr in ein Datenprodukt umformatiert werden, das einen konkreten Kundennutzen formuliert. Datenprodukte helfen ihren Nutzern dann dabei, informiertere Entscheidungen zu treffen, und lassen sich deshalb monetarisieren.

In diesem Beitrag beschreiben wir auf Basis etablierter Vorgehensmodelle für die digitale Produktenwicklung ein Modell für die Entwicklung von datenbasierten Produkten. Dabei werden u. a. die Aspekte Ideenfindung, Value Proposition Design und Zielgrößen näher untersucht. Zur Messung der Qualität eines Datenprodukts sollte eine Feedbackschleife implementiert werden. Die Gestaltung des Datenprodukts, die Integration der Feedbackschleife und die iterative Weiterentwicklung übernimmt ein interdisziplinäres Team. Dieses nutzt verschiedene Big-Data-Technologien, um das Datenprodukt skalierbar zu produzieren.

4.1Einleitung

»Information is costly to produce but cheap to reproduce«, schreiben Carl Shapiro und Hal R. Varian 1999 in ihrem Buch »Information Rules« [Shapiro & Varian 1999]. In diesem Buch haben sie viele Entwicklungen der letzten beiden Jahrzehnte vorweggenommen, indem sie ökonomische Grundprinzipien auf die entstehende Informationsökonomie angewendet haben. Die Tatsache, dass im Jahr 2018 die Geschäftsmodelle der wertvollsten Firmen auf dem Handel von Daten basieren, illustriert das eindrücklich [The Economist 2017]. In diesem Kapitel betrachten wir die Produkte, die in einer Ökonomie der Information gehandelt werden, die Datenprodukte, und deren Entstehung.

In den letzten Jahren haben sich bestimmte Vorgehensweisen für die Entwicklung von digitalen Produkten durchgesetzt. Die agile Entwicklung ist zum Beispiel heute das Standardvorgehensmodell in der Softwareentwicklung. Datenprodukte sind digitale Produkte mit einem spezifischen Kundennutzen, der im Wesentlichen auf der Verarbeitung von Informationen beruht. Die Digitalisierung von Prozessen liefert oft die Datengrundlage, um aus diesen Daten Datenprodukte zu kreieren. Dazu werden Daten häufig mithilfe von Data-Science-Methoden ausgewertet und daraus neue Erkenntnisse gewonnen. Aus Daten werden Informationen und schließlich Wissen [Probst et al. 1998]. Für Datenprodukte müssen einige etablierte Vorgehensweisen allerdings angepasst werden. Die Integration von Machine-Learning-Funktionalität ist nicht einfach ein neues Feature, sondern beeinflusst den gesamten Prozess der Produktentwicklung.

Angefangen von der Identifikation eines Kundenproblems über die Definition einer Value Proposition, die Konzeption des Produkts bis zur Definition eines sinnvollen Team-Setups zeigen wir, wie man ein erfolgreiches Datenprodukt bauen und produktiv betreiben kann. Ein besonderes Augenmerk richten wir dabei auf die Feedbackschleife. Jedes Datenprodukt ist ein kybernetisches System mit einer Regelschleife. Allerdings ist die Erfassung und Auswertung des Feedbacks bei Datenprodukten oft nicht trivial und muss daher konzeptionell betrachtet werden.

Im Folgenden beginnen wir mit einer Definition von Datenprodukten und einer Beschreibung der grundlegenden Monetarisierungsstrategien von Datenprodukten. Datenprodukte entstehen als Teil der digitalen Produktentwicklung, daher verweisen wir auf die gängigen Vorgehensmodelle in diesem Bereich. Unter Berücksichtigung der Erfolgsfaktoren von Datenprodukten leiten wir ein Vorgehensmodell für die Erstellung von Datenprodukten ab. Dieses Vorgehen lässt sich unter bestimmten organisatorischen und technischen Voraussetzungen besonders gut realisieren. Mit der Beschreibung dieser Anforderungen schließen wir das Kapitel und ziehen ein Fazit.

4.2Datenprodukte

4.2.1Definition

Daten treten in vielfältigen Formen auf. Ein elektronisches Thermometer produziert Daten, die die Temperatur repräsentieren, eine Digitalkamera produziert Daten, die ein Bild repräsentieren, in einem E-Commerce-Portal fallen Daten über einen Nutzer an. Die meisten Daten werden aus einem bestimmten Grund erhoben, allerdings werden nicht alle Daten zu einem Produkt weiterverarbeitet. Daten bekommen einen Produktcharakter, wenn aus ihnen ein Produkt erzeugt wird, das

  1. einen bestimmten Kundennutzen erzeugt/ein Kundenbedürfnis befriedigt,
  2. für mehr als einen Nutzer relevant ist,
  3. mit vorhersehbarer Qualität produziert wird/einen Produktionsprozess durchläuft,
  4. innerhalb eines Produktlebenszyklus gemanagt wird und
  5. einen Markt bedient.

Diese Eigenschaften können in unterschiedlichen Geschäftsmodellen realisiert werden und wir unterscheiden daher drei Typen von Datenprodukten [Tempich 2017, Abb. 4–1]:

image

Abb. 4–1Datenprodukttypen und dazugehörige Geschäftsmodelle

4.2.2Beispiele für Datenprodukte

Zur Illustration des Produktcharakters der unterschiedlichen Datenprodukttypen werden im Folgenden einige Beispiele aufgegriffen.

Google Recaptcha

Google Recaptcha1 ist ein Beispiel für Data-enhanced Products. Unter traditionellen Gesichtspunkten ist diese Produktentwicklung nicht sinnvoll. Die Websites, die Recaptcha benutzen, bezahlen kein Geld; die Nutzer bezahlen kein Geld, und es wird auch keine Werbung eingeblendet. Google stellt also ein Produkt zur Verfügung, ohne damit direkt Geld zu verdienen. Das ist natürlich nur die halbe Wahrheit: Recaptcha hat lange Zeit Fotos von Hausnummern durch Menschen verifizieren lassen. Es wurde ein Bild einer Google-Street-View-Aufnahme angezeigt und in den Fällen, in denen der Algorithmus die Hausnummer nur mit einer bestimmten, zu kleinen Wahrscheinlichkeit richtig erkannt hat, wird der Nutzer über Recaptcha zur Eingabe und damit Korrektur der Algorithmus-Einschätzung herangezogen. Wiederholt man diesen Vorgang mit mehreren Menschen, wird die korrekte Nummer mit großer Wahrscheinlichkeit identifiziert. Recaptcha verbessert also den Dienst »Google Maps«, wodurch die Nutzung von Google Maps steigt und damit die Möglichkeit für Google, über Maps Werbung auszuspielen und damit Geld zu verdienen. Recaptcha ist damit nicht nur ein gutes Beispiel für ein Datenprodukt, sondern auch für die Gestaltung eines zweiseitigen Markts (vgl. Abb. 4–2; [Rochet & Tirole 2003]).

Tesla Autopilot

Ein weiteres Beispiel für Data-enhanced Products sind die Fahrzeuge von Tesla und hier insbesondere der Autopilot.2 Zu Beginn wurde dieser »kostenlos« als Feature allen Tesla-Fahrern zur Verfügung gestellt. Durch die Nutzung des Autopiloten konnte Tesla lernen, in welchen Situationen der Mensch in die Entscheidung des Autopiloten eingegriffen hat. Diese Situationen werden zur Verbesserung genutzt, damit der Autopilot mit immer mehr Situationen des Straßenverkehrs umgehen kann. Die Unfälle, die auf Basis einer unsachgemäßen Nutzung des Dienstes passiert sind, deuten allerdings auf besondere Herausforderungen bei der Definition und Ausgestaltung des Wertversprechens hin.

Deutsche Post: AddressFactory

Die AddressFactory3 der Deutschen Post ist ein Beispiel für ein Data-as-a-Service-Datenprodukt. Firmen können ihre Adressdaten mit denen der Deutschen Post abgleichen und dadurch eine höhere Datenqualität in ihren eigenen Adressbeständen erreichen.

Medienagenturen: Allokation der Werbebudgets

Ein Beispiel für die Nutzung von Data as Insight – verbunden mit einem dazugehörigen Geschäftsmodell – ist das Angebot vieler Medienagenturen, das Management der Werbeetats zu übernehmen. Auf Basis von Werbeeffizienzkriterien werden die einzelnen Kanäle, zum Beispiel Online, TV, Zeitschriften, in unterschiedlich starkem Maß bespielt und die Werbebotschaften angepasst. Daten werden hier dazu genutzt, ein bestehendes Werbebudget optimal einzusetzen.

image

Abb. 4–2Datenprodukte werden in zweiseitigen Märkten angeboten.

4.2.3Herausforderungen des Produktmanagements für Datenprodukte

Wenn man sich aus Produktmanagementsicht mit Datenprodukten auseinandersetzt, müssen verschiedene Aspekte des Produktmanagements neu gedacht werden, wie nachfolgende Beispiele zeigen (siehe auch [Davenport & Kudyba 2016]):

  1. Dazu zählt zunächst die Frage: Wer sind die Kunden, für wen wird das Produkt gebaut? Dabei kann der zahlende Kunde ein ganz anderer sein als der Hauptnutzer.
  2. Warum nutzt der Kunde das Produkt und welches Wertversprechen motiviert ihn, es zu nutzen? Nicht alle Wertversprechen von Daten führen auch zu einer Zahlungsbereitschaft.
  3. Für welche Datenprodukte ist ein Kunde bereit, Geld zu bezahlen? Dies steht natürlich in direktem Zusammenhang mit dem Wertversprechen.
  4. Insbesondere für die Fälle, in denen der Kunde nicht bereit ist, für die Nutzung zu bezahlen, gilt es herauszufinden, für welche Datenprodukte der Kunde bereit ist, den Anbieter auf andere Art (z.B. Nutzung) zu entlohnen?
  5. Wie stellt man die Vollständigkeit des Angebots sicher und gewährleistet, dass die Nutzung durch den Kunden tatsächlich zu einer Verbesserung des Angebots führen kann?

4.3Digitale Produktentwicklung

Das hier vorgestellte Vorgehensmodell zur Entwicklung von Datenprodukten bedient sich an verschiedenen Stellen bei etablierten Vorgehensweisen aus der digitalen Produktentwicklung. Im Folgenden geben wir einen Einblick in die wesentlichen Ansätze und begründen, warum die Erstellung von Datenprodukten an einigen Stellen eine besondere und veränderte Methodik erfordert.

4.3.1Produktmanagement

Das Produktmanagement (PM) ist eine etablierte Disziplin, die sich in der Regel um die generelle strategische und technische Ausrichtung und die Prozesse innerhalb des Produktlebenszyklus kümmert [Smith & Reinertsen 1997; Herrmann & Huber 2013]. Klassisch werden im PM physische Produkte betreut. Das Produktmanagement hat dadurch oft eine vermittelnde Rolle zwischen der Produktentwicklung, der Produktion, dem Service und nicht zuletzt der Unternehmensleitung. Die Produktmanagementmethoden für das Management digitaler Produkte sind in letzter Zeit angepasst worden [Cagan 2008; Pichler 2016; Banfield et al. 2017]. Die Möglichkeiten, Produktänderungen quasi kontinuierlich an den Kunden ausliefern, Produktmerkmale in A/B-Tests auf Basis von Daten vergleichen oder Produkteigenschaften personalisieren zu können, stellten neue Herausforderungen an das PM, die in früheren Vorgehensweisen wenig Berücksichtigung fanden. Bei der Definition von Datenprodukten muss zusätzlich bedacht werden, dass Informationen nur bestimmte Value Propositions erfüllen können und dass die Nutzung des Angebots wiederum Daten produziert, die wertstiftend eingesetzt werden sollten.

4.3.2Agile Entwicklung

Innerhalb der Softwareentwicklung hat sich die agile Entwicklung in den letzten Jahren als bevorzugtes Vorgehensmodell etabliert. Kurze Feedbackzyklen innerhalb kleiner Teams und die Möglichkeit, schnell auf sich ändernde Anforderungen zu reagieren, sind wesentliche Vorteile der agilen Entwicklung. Die Abläufe, die durch Scrum [Schwaber & Beedle 2002] oder Kanban definiert werden, finden dabei häufig Anwendung. Nach Scrum werden kurze Feedbackzyklen innerhalb des Teams beispielsweise durch das Daily Scrum und die Retrospektive am Sprint-Ende realisiert. Ein inkrementelles Vorgehen und die Autonomie des Teams sind dabei Voraussetzungen für die effektive Nutzung von Scrum. Für die Entwicklung von Datenprodukten schlagen wir auch die Nutzung agiler Prinzipien vor. Am Beispiel von Google Recaptcha zeigte sich allerdings, dass Datennutzung und Datengenerierung weit auseinanderliegen können. Dies hat Einfluss darauf, wie Autonomie für Datenproduktteams erzeugt werden kann. Weiterhin kann der Erkenntnisgewinn aus Daten sehr viel Zeit in Anspruch nehmen, wodurch die Definition des Inkrements zu neuen Herausforderungen führt.

4.3.3Lean Startup

In der Wissenschaft ist das erkenntnistheoretische Prinzip der Falsifikation von Karl Popper beschrieben worden. Die Anwendung dieses Prinzips auf die Produktdefinition, insbesondere von Start-ups, hat Eric Ries eindrucksvoll umgesetzt [Ries 2011]. Jede Produktdefinition impliziert eine Hypothese bezogen auf ein bestimmtes Kundenproblem. Durch die explizite Formulierung von Hypothesen und deren Validierung mit Kunden können die Erfolgsaussichten für eine erfolgreiche Produkteinführung stark gesteigert werden. Eric Ries beschreibt, wie man schrittweise mit kleinen Kundengruppen ein besseres Verständnis für ein Kundenproblem erlangen kann. Für die Definition von Datenprodukten eignet sich dieses Vorgehen ebenfalls. Gerade weil die Entwicklung ausgefallener Algorithmen oft sehr anspruchsvoll und damit zeitaufwendig ist, lohnt es sich, durch frühes Feedback durch den Kunden den potenziellen Mehrwert eines Datenprodukts einschätzen zu können.

4.3.4Data Science

In den Kapiteln 5 und 7 werden unterschiedliche Methoden der Data Science im Detail vorgestellt. Daher soll hier nur der Bezug zu dem Vorgehensmodell CRISP-DM [Shearer 2000] hergestellt werden. CRISP-DM beschreibt, wie Data Scientists vorgehen können, um zunächst ein Geschäfts- und Datenverständnis zu entwickeln, im Anschluss daran die Daten aufzubereiten und zu modellieren, damit diese dann in der Evaluationsphase – bezogen auf das zu lösende Business-Problem – bewertet werden können. Nach erfolgreicher Lösung des Problems kann dieses dann bereitgestellt werden. Der Prozess ist in ein iteratives Vorgehen eingebettet. Durch die hier vorgeschlagene Einbettung der Data Science in die Produktentwicklung können wir stärker auf den Kundennutzen fokussieren und insbesondere Zielsetzungen für inkrementelle Schritte ableiten. Wie wir später sehen werden, ist dies von entscheidender Bedeutung, wenn das Optimieren eines Algorithmus unvorhersehbar viel Zeit in Anspruch nimmt.

4.3.5Data-centric Business Models

Ein Datenprodukt muss in ein valides Geschäftsmodell integriert sein. Zur Definition von Geschäftsmodellen hat sich der Business Model Canvas (BMC) etabliert [Osterwalder & Pigneur 2010]. Der BMC hilft dem Anwender dabei, ausgehend von einer Value Proposition sowohl die notwendigen Partner, Aktivitäten und Ressourcen zu benennen, die zur Herstellung der Value Proposition erforderlich sind, als auch die notwendigen Kundenbeziehungen, Kanäle und Kundensegmente zu definieren, um Erlöse zu erzielen. Erste Begriffsdefinitionen zu datenzentrischen Geschäftsmodellen finden sich in [Tempich & Rieger 2007]. Eine Übersicht von Geschäftsmodellen auf Basis von Daten hat Laura Dorfer erstellt [Dorfer 2016].

Die Einordnung in Abbildung 4–3 zeigt, dass Datenprodukte in der Regel in ein datenzentrisches Geschäftsmodell eingebettet sind. Innerhalb der Organisation kümmert sich das Produktmanagement um die Definition der Value Propositions. Dazu greift man auf Methoden aus dem Lean Startup, der agilen Entwicklung und der Data Science zurück. Im Folgenden beschreiben wir, wie dies im Detail ablaufen kann.

image

Abb. 4–3Datenprodukte im methodischen Schnittpunkt verschiedener Disziplinen

4.4Datenprodukte definieren

Durch die Verwendung des Produktbegriffs möchten wir hervorheben, dass in dem hier beschriebenen Vorgehen Daten dazu verwendet werden sollen, ein bestimmtes Problem zu lösen. Weiterhin gehen wir davon aus, dass dieses Problem nicht nur einmalig auftritt, das Produkt also mehrfach Verwendung findet. Unser Vorgehensmodell beinhaltet daher Methoden für die Definition des Problems, die Ableitung einer Value Proposition und die iterative Produkterstellung.

4.4.1Ideengenerierung für Datenprodukte entlang der Customer Journey

Zur systematischen Ableitung von Problemen bestimmter Nutzergruppen verwenden wir die Analyse der Wertschöpfungskette des Nutzers, auch Customer-Journey-Analyse genannt. Dabei gehen wir davon aus, dass wir Datenprodukte in einem bestimmten Kontext definieren wollen. Das Datenprodukt soll also nicht im luftleeren Raum entstehen, sondern es gibt Vorgaben zum Beispiel von der Unternehmensstrategie, dem Produkt, für das ein Datenprodukt entwickelt werden soll, oder den zur Verfügung stehenden Datendomänen. Wenn diese Voraussetzungen erfüllt sind, identifizieren wir im ersten Schritt die unterschiedlichen Nutzergruppen, die für unser Datenprodukt infrage kommen. Für diese Nutzergruppen stellen wir eine Abfolge an Schritten auf, die der Nutzer durchführt, um sein Ziel zu erreichen. Ausgangspunkt der Abfolge sollte dabei der Zeitpunkt sein, an dem das Bedürfnis entsteht. Endpunkt der Abfolge ist der Zeitpunkt, an dem das Ziel erreicht wurde.

Zur Illustration nutzen wir die Situation bei einem Marktplatz für Fahrzeuge. Der Kontext für die Identifikation eines Datenprodukts ist also das Fahrzeug und dessen Handel. Nutzergruppen einer solchen Plattform sind unter anderem die Besitzer, Händler und Käufer von Fahrzeugen, aber auch Finanzierungspartner, Versicherungen oder Werkstätten. Die Wertschöpfungskette eines Käufers könnte dann wie folgt modelliert werden: 1. Wunschentstehung, 2. Fahrzeugauswahl, 3. Kauf, 4. Nutzung, 5. Erhaltung und 6. Verkauf.

Für jeden Schritt analysiert man die Entscheidungsoptionen des Nutzers und deren Auswirkungen. Die Vielfalt der Möglichkeiten ist eine Indikation dafür, dass der Nutzer Informationen benötigt, um eine Entscheidung zu seinem Vorteil zu treffen. Je größer der Unterschied zwischen einer guten und schlechten Entscheidung für den Nutzer ist, desto mehr sind Informationen wert, die dem Nutzer dabei helfen, eine gute Entscheidung zu treffen. Aus Anbietersicht kann der Wert einer Information auch dadurch beeinflusst sein, wie häufig eine bestimmte Entscheidung getroffen wird. Entscheidungen, die einen kleinen individuellen Wert haben, dafür aber sehr oft getroffen werden müssen, können aus Anbietersicht interessanter sein als Entscheidungen, die zwar individuell sehr wertvoll sind, aber sehr selten fallen.

Bei der Fahrzeugauswahl möchte der potenzielle Käufer zum Beispiel wissen, ob der Preis für ein Fahrzeug angemessen in Bezug auf den Zustand des Fahrzeugs ist. Objektive Informationen bezüglich des Fahrzeugzustands sind daher wertvoll.

Aus der Analyse der Wertschöpfungskette ergeben sich Informationsbedürfnisse, die durch ein Datenprodukt gelöst werden könnten, und eine initiale Bewertung dieser Informationsbedürfnisse.

4.4.2Value Propositions von Datenprodukten

Im nächsten Schritt gilt es nun, ein Wertversprechen (Value Proposition) für die identifizierten Problemstellungen innerhalb der Wertschöpfungskette zu definieren. Dabei können die Wertversprechen von Datenprodukten in zwei Dimensionen beschrieben werden: als rationale und als soziale Komponente. Ein rational begründetes Wertversprechen unterstützt den Nutzer dabei, die objektiv beste Entscheidung zu treffen. Volkswirtschaftlich interpretiert man den Menschen hierbei als homo oeconomicus. Wir wissen aber aus der Verhaltensökonomie, dass Menschen auch andere Gesichtspunkte wichtig sind. Das Wertversprechen kann also auch sozial ausgelegt sein und Neugierde, soziale Interaktion oder Entertainment-Bedürfnisse ansprechen [Dorfer 2016].

In den meisten Fällen werden die unterschiedlichen Ausrichtungen des Wertversprechens kombiniert und an verschiedene Nutzergruppen angepasst, um ein Datenprodukt zu erstellen. Zum Beispiel kann man soziale Interaktion dazu nutzen, um Feedback zu der Qualität eines Datenprodukts zu bekommen.

Nehmen wir beispielsweise die Möglichkeit, die Verkaufsanzeige eines Fahrzeugs über einen Link an einen Freund weiterzuleiten. Diese soziale Interaktion kann dazu genutzt werden, die Fahrzeugempfehlung zu beeinflussen, wobei das Datenprodukt »Fahrzeugempfehlung« die Entscheidung für oder gegen ein Fahrzeug unterstützt und damit eher ein rational begründetes Wertversprechen hat.

Neben dieser kategorischen Unterscheidung kann zusätzlich die zeitliche Dimension zur Beschreibung des Wertversprechens herangezogen werden. Datenprodukte können ein Bedürfnis nach Informationen

befriedigen.

Preisvergleichsportale bieten zum Beispiel historische Preisinformationen an oder versuchen, einen Preistrend für ein bestimmtes Produkt vorherzusagen, um daraus eine Warte- oder Kaufempfehlung abzuleiten.

Während die Wertschöpfungskettenanalyse Hinweise darauf gibt, welche Wertversprechen einen Mehrwert liefern könnten, unterstützt die Kategorisierung der Wertversprechen die Ideenfindung einer konkreten Problemlösung. Im Zusammenspiel der Wertversprechen und der Wertschöpfungskette kann sich dann auch ergeben, an welcher Stelle der Wertschöpfungskette ein Service beginnen bzw. enden sollte, um gegebenenfalls Daten für darauffolgende Schritte zu sammeln oder Feedback über das Nutzerverhalten einzuholen. Insbesondere auf das Design der Feedbackschleife gehen wir noch in einem späteren Abschnitt detailliert ein.

4.4.3Ziele und Messung

Im nächsten Schritt folgt die Ableitung einer messbaren Zielerreichungsgröße für das angestrebte Wertversprechen. In der Wertschöpfungskette wurden alle Schritte bis zur Erreichung eines bestimmten Ziels aufgeschrieben. Allerdings kann es passieren, dass dieses Endziel nicht messbar ist, wie zum Beispiel Glück oder Zufriedenheit. Daher müssen Messpunkte an den einzelnen Stationen eingebaut werden, um zu bewerten, ob der Nutzer auf einem guten Weg ist, sein Ziel zu erreichen.

Zum Beispiel kann das Ziel eines Autokaufs die räumliche Unabhängigkeit sein. Wie gut dieses Ziel durch den Kauf erreicht wird, ist sehr schwer zu messen. Während die Weiterleitung eines Links an einen Freund nur wenig über diese Zielerreichung aussagt, kann es doch ein Etappenziel darstellen, das vermuten lässt, dass ein bestimmtes Auto in die nähere Auswahl einbezogen wurde.

4.4.4Die Erwartung an die Güte des Modells bestimmen

Maschinelle Lernverfahren machen in der Regel Vorhersagen, die nicht in allen Fällen richtig sind. Da unterscheiden sie sich nicht von Menschen. Im Falle einer Klassifikationsaufgabe kann die Güte eines Modells beispielsweise durch die F-Measure, also die Kombination aus Precision und Recall, angegeben werden [Baeza-Yates & Ribeiro-Neto 1999]. Abhängig vom Einsatzgebiet des Datenprodukts ist es entscheidend, zu verstehen, welche Eigenschaft dem Nutzer besonders wichtig ist. Möchte er z.B. einen höheren Recall, soll also eine Klassifikation für möglichst viele Fälle angeben werden, bei entsprechender Verminderung der Precision oder sollen die Vorhersagen eher richtig sein und im Zweifelsfall nicht angezeigt werden. Damit dies richtig eingeschätzt werden kann, ist es wichtig, zu verstehen, was im schlimmsten Fall bei einem Fehler des Algorithmus passieren kann. Im Zweifelsfall müssen Fehlerquellen auch manuell während der Entwicklung abgefangen werden.

Bei Urlaubsbildern wird man es entschuldigen können, wenn ein Kuchen als Sonnenuntergang klassifiziert wird. Wenn die IBAN auf einer Überweisung erkannt werden soll, hilft eine unscharfe Erkennung nicht, weil dann doch alle erkannten Ziffern überprüft werden müssten.

Aus der Robotik ist das Konzept des Uncanny Valley bekannt [Mori 1970]. Die Sympathie, die einer Maschine entgegengebracht wird, steigt zunächst mit ihrer Ähnlichkeit zu menschlichem Verhalten/Aussehen. Sobald die Ähnlichkeit aber einen bestimmten Grad erreicht hat, fällt sie signifikant, bis eine absolute Übereinstimmung mit menschlichem Verhalten erreicht wurde. Etwas Ähnliches kann man sich bei der Güte von Algorithmen vorstellen. Ein Algorithmus, von dem man weiß, dass er eine gute Vorhersage liefert, ist eine gute Informationsquelle, aber der Nutzer weiß auch, dass er sich nicht zu 100% darauf verlassen kann, und denkt entsprechend selber nach. Bei einer sehr guten Vorhersage geht die Anzahl der Änderungen so stark zurück, dass der Mensch sich zu sehr auf den Algorithmus verlässt. Wie die tragischen Beispiele von Tesla zeigen, auch mit tödlichem Ausgang.

Im Rahmen der Konzeption des Datenprodukts müssen daher die Präferenzen der Nutzer bezüglich der Güte des Modells herausgefunden werden und auch die Konsequenzen aus einer zu guten Vorhersage abgewogen werden.

4.4.5Mit dem Datenprodukt beginnen

Die bisher beschriebenen Schritte dienten dazu, Hypothesen bezüglich relevanter Wertversprechen und Ziele des Nutzers zu formulieren. Diese gilt es nun zu überprüfen. Entsprechend dem Lean-Startup-Vorgehensmodell sollten diese Hypothesen schrittweise validiert werden.

Im ersten Schritt gilt es daher, herauszufinden, wie der Nutzer das definierte Problem aktuell löst, welche Entscheidungsoptionen er hat und welche Unsicherheiten damit verbunden sind. Darauf aufbauend kann ein sehr einfacher Algorithmus verwendet werden, der beispielsweise sehr wenige Datenquellen nutzt, um die aktuelle Vorgehensweise zur Problemlösung leicht zu verbessern. Es ist entscheidend, dass man zu Beginn der Entwicklung nicht die ausgefallensten Algorithmen einsetzt oder gar versucht, alle möglichen Datenquellen einzubeziehen. Dies ist in der Regel sehr aufwendig. Am Anfang muss man mit wenig Aufwand herausfinden, ob ein Kunde von einem Informationsangebot überhaupt profitiert. Außerdem dient der einfache Algorithmus oder eine Heuristik als Basis, um später die Verbesserungen durch andere Algorithmen nachweisen zu können.

Zum Beispiel wurden die ersten Empfehlungen auf bekannten E-Commerce-Portalen zunächst nicht aufwendig berechnet, sondern sie bestanden aus einer zufälligen Auswahl von Produkten aus dem Produktkatalog. Das Ziel dieser Implementierung war einzig und alleine, herauszufinden, ob Kunden überhaupt etwas mit einer Produktempfehlung anfangen können und ob diese zu höheren Verkäufen führt [Linden et al. 2003].

4.4.6Kontinuierliche Verbesserung mit der Datenwertschöpfungskette

Wenn man herausgefunden hat, auf welche Art man ein Datenprodukt dem Nutzer anbieten kann, geht es im nächsten Schritt darum, die Vorhersagegüte kontinuierlich zu verbessern. Dies kann gelingen, indem andere Algorithmen zum Einsatz kommen und/oder mehr Datenquellen benutzt werden. Teilweise wird man auch Situationen/Fälle identifizieren, die auch durch eine Verbesserung des Algorithmus nicht zum richtigen Ergebnis führen. Diese Fälle gilt es zu bewerten und im Zweifelsfall manuell zu behandeln. Weiterhin kann davon ausgegangen werden, dass die Nutzung der ersten Version des Datenprodukts weitere klassifizierte Daten generiert, die für Trainingszwecke zur Algorithmenoptimierung genutzt werden können.

Damit man alle Daten, die innerhalb der Customer Journey anfallen bzw. anfallen könnten, betrachtet, können die Datenflüsse mithilfe der Datenwertschöpfungskette4 analysiert werden (vgl. Abb. 4–4). Diese beschreibt den Fluss der Daten von deren Entstehung bis zur Nutzung. Die Datenwertschöpfungskette sollte für alle Datenobjekte betrachtet werden. Nicht immer werden zum Beispiel alle Schritte für Stamm- und Transaktionsdaten gleichermaßen gut unterstützt. Insbesondere der Rückfluss wird oft vergessen, d.h., es wird nicht protokolliert, wie der Nutzer mit den Daten interagiert. Eine typische Datenwertschöpfungskette enthält die Schritte, die der folgenden Abbildung zu entnehmen sind:

image

Abb. 4–4Abdeckung der Datenwertschöpfung bewerten

4.4.7Skalierung und Alleinstellungsmerkmal

In dieser Phase der Entwicklung eines Datenprodukts ist geklärt, welches Wertversprechen das Datenprodukt erfüllt, wie dies gemessen werden kann und welche Datenquellen zur Verfügung stehen, um den Algorithmus zu verbessern. Oft sind zu diesem Zeitpunkt die Methoden des A/B-Tests bereits implementiert und können genutzt werden. Nun gilt es, das Produkt so zu gestalten, dass die Nutzung des Produkts selbst zur kontinuierlichen Verbesserung des Produkts führt. Das Design der Feedbackschleife wird damit zum kritischen Erfolgsfaktor.

4.5Kritischer Erfolgsfaktor Feedbackschleife

Ein zentrales Element der Kybernetik ist die Rückkopplung oder Feedbackschleife. Gerade wenn Daten im Zentrum des Wertversprechens liegen, kommt der Feedbackschleife aus zwei Gründen eine besondere Bedeutung zu. Einerseits kann die Feedbackschleife dazu genutzt werden, das Produkt zu verbessern. Andererseits ermöglicht die Feedbackschleife, Daten zu generieren, die die Basis des Produkt-Alleinstellungsmerkmals werden.

Die Google-Suchergebnisse sollen als Beispiel verdeutlichen, wie die Feedbackschleife zur Verbesserung des Produkts beiträgt. Google hat einen Algorithmus, der auch ohne Nutzer tolle Ergebnisse auf die vorderen Ränge bringt. Einzigartig wird er aber durch die Integration der Nutzer-Interaktionen. Jeder Klick auf ein Suchergebnis ist wieder ein Feedback für das Ranking des Suchergebnisses. Dadurch kann dem nächsten Nutzer ein minimal besseres Suchergebnis angezeigt werden.

Diese Verbesserung führt gleichzeitig zu einem Alleinstellungsmerkmal. Denn während die Stammdaten (im Falle von Google die Websites und Links) für alle theoretisch zugreifbar sind, sind es die Transaktionsdaten nicht (im Falle von Google die Klicks auf die Links). Die Interaktion des Nutzers mit dem Produkt liefert die notwendige Information, um das Produkterlebnis langfristig besser zu gestalten, als es der Konkurrenz möglich ist.

Bei der Gestaltung der Feedbackschleife sollten die folgenden Aspekte betrachtet werden:

Zieldefinition

Zunächst sollte definiert werden, mit welchem Ziel Feedback eingesammelt werden soll. Die Zielerreichungsgrößen aus der Wertschöpfungskettenanalyse bilden hier einen wertvollen Input. An welchen Stellen werden Informationen über das Nutzerverhalten benötigt, um das Produkt zu verbessern? Man kann den Nutzer eines Dienstes hier durchaus als Leistungsanbieter verstehen, der durch seine Tätigkeit die Dienstleistung verbessert. Die Produktnutzung wird also selbst zum eigentlichen Produkt, nur dass der Anbieter dieses Produkt konsumiert.

Am Beispiel des Fahrzeugmarktplatzes wird das deutlich. Der Anbieter des Marktplatzes weiß zunächst nicht, welches Auto der Nutzer präferiert. Durch sein Such-, Klick- und Weiterleitungsverhalten kann der Anbieter implizit auf die Präferenzen des Nutzers schließen. Das Ziel ist also, ein möglichst gutes Bild über die Präferenzen des Nutzers herauszuarbeiten.

Wert für den Nutzer

Damit der Nutzer das gewünschte Feedback auch gibt, muss dieses auch einen Mehrwert für den Nutzer haben – es ist also fast schon ein eigenes Datenprodukt. Zum Beispiel bietet die Weiterleitung einer Anzeige an einen Bekannten den Mehrwert, die soziale Interaktion zu fördern.

Häufig genutzte Muster, um den Nutzer zu Feedback zu motivieren, sind die Weiterleitung, die Darstellung der persönlichen Auswahl innerhalb einer Grundgesamtheit, die Dokumentation im Sinne eines zeitlichen Verlaufs und Ähnliches.

Flow

Im besten Fall nutzt man das Feedback des Nutzers, um den Nutzer im Flow-Zustand zu halten [Fogg 2002]. Hierbei sind insbesondere die User Experience und Interface Designer gefragt. Die Interaktion erzeugt zum Beispiel Daten, für deren Aggregation über alle Nutzer sich der Einzelne interessiert.

Ein typisches Beispiel findet sich bei YouTube.5 Sobald ein Video beendet ist, wird das nächste geöffnet und abgespielt. Die Beendigung des Streams kann dann als Feedback für die Präferenzen des Nutzers gewertet werden.

Community pflegen

In dem Moment, in dem die soziale Interaktion mit dem Produkt zum Mehrwert für den Nutzer wird, spielen auch andere Kunden eine Rolle. Neugier, Entertainment und Interaktion mit anderen Menschen stehen selten alleine, sondern werden besonders spannend im Vergleich zu anderen Nutzern. Daher sollte man die Gruppe der eigenen Nutzer und Kunden als Community begreifen und diese auch als solche behandeln. Dabei geht es vor allem darum, den Austausch zwischen den Mitgliedern der Community einfach zu gestalten und die Community, gegebenenfalls durch Gamification-Ansätze, zum Austausch zu motivieren.

Als Beispiel seien hier die Rezept-Communitys von Geräten zur Unterstützung des Kochens genannt. Die Community sorgt dafür, interessante Rezepte zu definieren und zu bewerten. Dadurch wird das Kocherlebnis mit dem Gerät kontinuierlich verbessert.

Serendipität

Einen wichtigen Aspekt darf man bei Feedbackschleifen nicht vergessen: die Gefahr des Overfittings. Wenn ein Modell trainiert wird, kann es passieren, dass dieses Modell sehr gut zu den Trainingsdaten passt, aber keine oder wenig Aussagekraft für neue Inputdaten hat. Dies kann zum Beispiel passieren, wenn ein Empfehlungssystem nur mit dem Feedback einer bestimmten Kundengruppe trainiert wird. In dem Fall kann es sein, dass das Modell nicht oder schlecht zu den Bedürfnissen einer anderen Kundengruppe passt. Daher ist es sinnvoll, in Empfehlungen immer wieder etwas Zufall einfließen zu lassen. Ein gängiger Wert für Zufall gegenüber Vorhersagen aus dem Modell liegt zwischen 10 und 20 Prozent. Durch die Zufallsbeimischung wird Serendipität ermöglicht, also die ungeplante Entdeckung von neuen Zusammenhängen.

Klein anfangen

Viele Feedbackprodukte fangen mit sehr einfachen Mitteln an. Zum Beispiel kann man mit simplen Aggregationen starten: Wie viele Menschen waren auf der Seite? Wer hat sich was angesehen? Sobald man den Feedbackmechanismus im Griff hat, kann man sich ausgefalleneren Methoden widmen.

Platform Mindset: Nutzung für verschiedene Produkte

Zum Schluss sei noch auf den Plattform-Gedanken hingewiesen. Transaktionsdaten, die in einem Dienst erzeugt werden, können hilfreich für einen weiteren Dienst sein oder sogar dessen Grundlage bilden. Die unterschiedlichen Produkte können sich damit gegenseitig helfen. Dafür ist ein zentraler Bestandteil, dass sich die Produktmanager der einzelnen Produkte regelmäßig austauschen. Inhaltlich sollten sie dabei über ihre spezifischen Herausforderungen sprechen und nach wechselseitigen Datenlösungen suchen. Technisch sollten sie an einem gemeinsamen Datenmodell arbeiten. Das heißt nicht, dass alle Daten von Anfang an in einem gemeinsamen Datenmodell integriert sein müssen. Datenobjekte, die einen gemeinsamen Wert darstellen, sollten allerdings kontinuierlich in ein gemeinsames Modell überführt werden [Pinto et al. 2004].

Da die Distribution von Daten quasi nichts kostet, hat der Anbieter von Datenprodukten die Freiheit, seinen Markt selbst zu modellieren – beispielsweise indem er wertvolle Daten verschenkt, damit er sich durch noch wertvollere Informationen über die Nutzung dieser Daten »bezahlen« lassen kann (vgl. [Rochet & Tirole 2003]). Wie beim Erfolgsfaktor Community schon angedeutet, ist nicht jeder Nutzer des Datenprodukts gleichzeitig auch ein Käufer. Manche Nutzer bekommen nur deswegen Zugriff auf ein Produkt, damit sie es verbessern und am Ende jemand für das verbesserte Produkt – oder ein Derivat des Produkts – Geld bezahlt. Die Zusammenhänge zwischen den einzelnen Gruppen, Nutzern und Käufern muss man modellieren und gegebenenfalls über den Lebenszyklus hinweg verändern. Manchmal kostet ein Produkt z.B. in der Einführungsphase nichts, wird aber später kostenpflichtig (z.B. der Tesla Autopilot). Oder der Nutzer selbst zahlt nichts, aber das Aggregat ist sehr wertvoll, wie das Beispiel von Foursquare zeigt [Glueck 2017]. Bei der Ausgestaltung dieser Modellierung hilft einem das Konzept der zweiseitigen Märkte aus der Volkswirtschaftslehre (vgl. Abb. 4–2). Eine nähere Betrachtung dieses Aspekts geht über die Zielsetzung dieses Artikels hinaus.

Abbildung 4–5 zeigt die unterschiedlichen Phasen und Schritte der Datenproduktentwicklung noch einmal im Überblick.

image

Abb. 4–5Prozessüberblick für die Konzeption und Entwicklung von Datenprodukten

4.6Organisatorische Anforderungen

Aus den Empfehlungen für die Konzeption und Umsetzung von Datenprodukten ergibt sich eine Reihe an Anforderungen für die Organisation von Teams, die solche Datenprodukte umsetzen. Dazu zählen

In der Regel wird ein Produktmanager dafür verantwortlich sein, das Wertversprechen, die Mess- und Gütekriterien zu definieren und Feedback vom Kunden bezogen auf den Produktnutzen einzuholen.

Der Produktmanager ist auch dafür verantwortlich, den Umfang eines Inkrements zu bestimmen. Ein Inkrement kann zum Beispiel durch das Hinzufügen neuer Datenquellen, einen neuen Algorithmus, eine Verbesserung des Feedbackmechanismus oder die größere Abdeckung der Customer Journey entstehen.

Damit das Team selbstbestimmt und autark das Produkt entwickeln kann, sollten die wesentlichen Fähigkeiten in dem Team vorhanden sein. Dazu zählen

Wichtig ist auch, dass das Team Einfluss auf die komplette Customer Journey nehmen kann. Dies erlaubt dem Team, Daten aus allen Schritten zu erfassen und dem Nutzer zu anderen Zeitpunkten widerzuspiegeln.

In größeren Kontexten wird ein Team oft nicht ausreichen, um alle Anforderungen abzudecken. Typischerweise werden Datenproduktteams mit anderen Teams zusammenarbeiten, um ein Gesamtprodukt zu erstellen oder weiterzuentwickeln. Insbesondere bei der Skalierung ist wichtig zu beachten, dass der Zugriff einzelner Produktteams auf die gesamte Datenlandschaft nicht eingeschränkt wird. Die dedizierte Betrachtung und Regelung der Datenschutzanforderungen bekommt hier ein besonderes Gewicht.

Neben den organisatorischen Anforderungen gibt es auch technische Anforderungen, um Datenprodukte effizient entwickeln zu können.

4.7Technische Anforderungen

Die Auflistung aller technischen Anforderungen an eine Plattform zur Entwicklung von Datenprodukten übersteigt den Rahmen dieses Kapitels. Dennoch ergibt sich aus der Art und Weise, wie Datenprodukte gebaut werden sollten, eine Reihe besonderer Anforderungen, die hier auf einem hohen Abstraktionsniveau explizit genannt werden sollen.

Dazu zählen,

Diese Anforderungen werden in anderer Stelle im Buch zum Teil noch ausführlicher behandelt.

4.8Fazit

Die großen Plattformbetreiber Amazon, Google und Facebook in der westlichen Hemisphäre oder die entsprechenden Pendants Alibaba, Baidu und Tenent in der östlichen Hemisphäre nehmen ihren Ursprung in der erfolgreichen Etablierung eines Datenprodukts. Sie haben Daten als Kernelement des Wertversprechens verstanden und dieses dann sukzessive ausgebaut. Dazu haben sie auf der einen Seite immer mehr Daten integriert, aber auch einen immer größeren Teil der Customer Journey abgedeckt. Dadurch sind bei allen Unternehmen Datensammlungen entstanden, die nun auf vielfältige Art und Weise für weitere Produkte genutzt werden können.

In diesem Kapitel haben wir beschrieben, wie man Ideen für Datenprodukte systematisch ableiten kann. Wir haben gezeigt, wie Methoden aus der agilen Softwareentwicklung und Lean Startup genutzt werden können, um den Weg von der Idee zum validierten Produkt methodisch zu begleiten. Dabei kann die Datenwertschöpfungskette dazu genutzt werden, die Vollständigkeit von der Datengenerierung bis zur Auswertung nachzuvollziehen und sicherzustellen. Weiterhin haben wir herausgearbeitet, welche Rolle die Feedbackschleife für Datenprodukte spielt und worauf bei dem Design einer Feedbackschleife geachtet werden sollte.

Damit gibt dieses Kapitel einen Überblick über die Methoden und Verfahren, die genutzt werden können, um Datenprodukte systematisch zu planen und umzusetzen. Davon unbenommen bleibt die Herausforderung, die richtigen Algorithmen und Tools einzusetzen und dem Datenschutz gerecht zu werden.