⚠️ Dieser Text wurde aus dem Englischen Original maschinell übersetzt.
Ein erster Kundenvertrag für ein Data Science-Projekt kann beide Vertragsparteien ein wenig überfordern - solche Projekte sind oft explorativ und daher weder zeitlich noch inhaltlich a priori gut abzugrenzen. Im Folgenden sollen einige Dinge festgehalten werden, die es sich lohnt in einer Projektvereinbarung oder einem Vertrag festzuhalten - und einige, die man nicht festhalten sollte.
Form und Inhalt des Ergebnisses Link to heading
Um die Erwartungen auf Seiten des Kunden zu verwalten, sollten die Liefergegenstände genau definiert werden, wie zum Beispiel:
- das Ziel, z.B.
- Identifizierung von Faktoren auf der Website, die das durchschnittliche Warenkorbvolumen beeinflussen
- Entscheidung, ob eine der 5 Marketingkampagnen des letzten Jahres einen messbaren Einfluss auf die Einnahmen hatte und wenn ja, wie viel
- Analyse, ob die Kundenbindungsmaßnahmen im Callcenter positive Renditen generieren
- …
- das Format
- Powerpoint
- Word
- Notizbuch (Notebook)
- Airflow-Workflow
- schlüsselfertige Anwendung
- tägliche E-Mail-Berichte
- …
- den Inhalt
- einmalige Analyse
- Modell zur kontinuierlichen Auswertung
- Tabelle oder Visualisierung
- …
- den Zeitraum der zu analysierenden Daten und - falls zutreffend - die Zeiträume für Vorhersagen
- den Zeitpunkt der Lieferung, auch bekannt als die “Deadline”
Daten und wie man sie beherrschen kann Link to heading
Dies ist eine der kniffligsten Aufgaben, da ein Grund dafür, dass gerade über jetzt ein Data Science-Projekt verhandelt wird, möglicherweise darin besteht, dass der Kunde keinen sehr guten Überblick über seine eigene Datenlandschaft hat. Aber soweit es dem Kunden bekannt ist, empfiehlt es sich, die grobe Größe und Struktur der bereitgestellten Daten und deren Zugänglichkeit festzuhalten:
- Millionen von Zeilen
- Größe in GB
- Fernzugriff oder nur Vor-Ort-Zugriff
- Datenbank-/Daten-Warehouse-Ausfallzeiten
- ETL-Prozesse, die den Zugriff blockieren (mein letztes Projekt-DWH war eine Stunde lang nach der Mittagspause für ETL nicht verfügbar)
- …
Ziel ist es, eine realistische Sicht auf den entstehenden administrativen Aufwand zu schaffen, der erledigt werden muss, bevor überhaupt ein Wert geschaffen wird, der einen Impact auf das Geschäft des Kunden hat. Für den Fall, dass die Komplexität der Vorverarbeitung der Daten den Umfang, auf den Sich beide Parteien geeinigt haben, übersteigt, sollte eine Vertragspassage aufgenommen werden, die es ermöglicht, den Vertrag nach einer gründlichen Prüfung der Daten neu zu verhandeln oder vorzeitig zu beenden. Manchmal stellt sich auch heraus, dass die Daten nicht die erwartete Qualität und/oder Größe haben, wodurch Ihr Projekt möglicherweise vollständig undurchführbar wird.
Bezahlung nach Aufwand, nicht für die Auswirkungen die Ergebnisse Link to heading
Es gibt keine Garantie, dass sich in einem explorativen Data-Science-Projekt Ergebnisse von Substanz und wirtschaftlicher Bedeutung finden lassen. Wenn man beispielsweise erkunden möchte, welche Faktoren den Warenkorbwert eines Kunden beeinflussen, ist es durchaus möglich, dass der Datensatz keine Antworten auf diese Frage enthält. Jegliche bedeutsamen Faktoren, die identifiziert werden sollen, könnten bereits ihr Optimum erreicht haben oder aus externen Gründen nicht verändert werden können. Ein Vertrag sollte festhalen, dass Sie kein bestimmtes Ergebnis garantiert wird (im Sinne von z.B. einer Umsatzsteigerung oder der Steigerung des Warenkorbwertes) und dass die Vergütung für die investierte Zeit und Mühe des Prozesses erfolgt, nicht für die Wirksamkeit der Ergebnisse.
Noch besser: Ein erfahrener Data Scientists bespricht vor Beginn des Projekts, welche möglichen Handlungsoptionen der Kunde verfolgen kann. Zeigt eine Analyse zum klischeehaften Beispiel dass ältere Kunden mehr Geld ausgeben, ist vielleicht sinnvoll und notwendig, dass der Kunde TV- und Printanzeigen schalten. Wenn hingegen jüngere Kunden mehr ausgeben, kann das Unternehmen des Kunden Instagram-Marketing betreiben oder entsprechende Expertise erwerben. Sind einige oder mehrere dieser Handlungsoptionen von vornherein ausgeschlossen, sollte diskutiert werden, ob sich eine Durchführung des Analyseprojektes überhaupt lohnt.
Zwischenergebnisse nicht vorstellen, Endergebnisse nur einmal vorstellen Link to heading
Vereinbaren Sie keine Meetings zur Präsentation von Zwischenergebnissen, ohne gründlich darüber nachzudenken. Durch die Vorbereitung einer glänzenden Präsentation, um einen skeptischen Kunden nach ein oder zwei Wochen Arbeit zu beruhigen, wird der Fokus vom Endergebnis abgezogen.
Die Vorbereitung der Präsentation des Ergebnisses kann zwischen 30 - 50 % der gesamten Arbeitsstunden eines Projekts in Anspruch nehmen, sodass, wenn Ergebnisse nach z.B. zwei Wochen präsentiert werden sollen, möglicherweise kaum eine Woche Zeit für die eigentliche Arbeit übrig bleibt. Oftmals möchte der Kunde einfach auf dem Laufenden gehalten werden, um das investierte Geld nicht zu verschwenden. Es können daher regelmäßige Statusaktualisierungen per E-Mail oder Chat angeboten werden, und diese Memos sollten in Bezug auf die Ergebnisse neutral gehalten werden, um später keine Worte zurücknehmen zu müssen. Zum Beispiel könnte Folgendes kommuniziert werden: “Untersuchte - unter Anderem - das Alter der Kunden im Verhältnis zu den Einnahmen” anstatt “Es sieht so aus, als ob ältere Kunden mehr Geld in Ihrem Geschäft ausgeben”. Sobald interessante Ergebnisse gefunden und kommuniziert werden, könnte es eine Kaskade von “Oh, der Leiter des Marketings muss das sehen”, “Oh, der COO muss das sehen”, “Oh, der CEO muss das sehen” geben. Dies führt natürlich dazu, dass mehr Zeit als erwartet für das Projekt aufgewendet wird, da die Ergebnisse nicht nur einmal, sondern 3 oder 4 Mal präsentiert werden und zusätzlich vielleicht noch eine politische “Feedbackrunde” gehalten wird.
Wenn im Projektvertrag jedoch festgehalten wird, dass die Ergebnisse nur einmal präsentiert werden, verleiht Ihnen das Handlungsspielraum, falls der Kunde Sie um mehr als eine Präsentation bittet.
Kontakt mit den Fachexperten Link to heading
Während die Führungsebene des Kunden nur über das “Notwendigste” informiert werden sollte, sollte im Gegensatz dazu ein enger Kontakt mit den fachkundigen Ansprechpartnern auf der Seite des Kunden gehalten werden. Fast jeder braucht jedoch hin und wieder einmal Urlaub, daher ist es äußerst ungünstig, wenn Ansprechpartner innerhalb der Organisation des Kunden genau dann nicht verfügbar sind, wenn sich mitten im Projekt schwierige Fragen auftun. Zugang zu Fachexperten sollte daher vertraglich sichergestellt werden, und Verzögerung durch Urlaub, Krankheit oder Überlastung durch Meetings der Fachexperten zu Lasten des Kunden gehen.
Bereitgestellte Hardware oder BYOD (Bring Your Own Device) Link to heading
Falls der Kunde Hardware zur Verfügung stellt und eine eigene Maschine nicht mitgebracht wird oder werden darf, muss sichergestellt werden, dass die bereitgestellte Hardware schnell ist und ausreichend RAM hat. Das Minimum sollte heutzutage 32 GB RAM für die Stapelverarbeitung einer signifikanten Datenmenge sein. Natürlich ist der Preis von RAM im Vergleich zum Gesamtbudget eines durchschnittlichen Projekts vernachlässigbar, und ausreichend RAM, um das Auslagern auf die Festplatte zu vermeiden, kann Ihnen Stunden, wenn nicht sogar Tage, bei einem größeren Projekt ersparen. Findet das Projekt in der Cloud statt, so ist immer noch eine gut motorisierte Maschine empfehlenswert um schnelle Ladezeiten für Browser, Workbenches, Prototyping und IDEs zu gewährleisten.
Drittanbieter-Tools Link to heading
Wenn Drittanbieter-Tools verwendet werden - insbesondere wenn Daten auf deren Server hochgeladen werden - muss vertraglich sichergestellt werden, dass der Auftragnehmer dazu berechtigt ist und dass Form und Umfang der hochgeladenen Daten den Informationssicherheitsrichtlinien des Kunden entsprechen.
Minimierung von persönlich identifizierbaren Informationen Link to heading
Wenn irgendwie möglich, sollten keine persönlich identifizierbaren Informationen in die Hände des Auftragnehmers gelangen. Zur Vermeidung von Verstrickungen in Datenlecks sollten alle schützenswerten Informationen nur in gehashter oder pseudonymisierter Form für den Auftragnehmer zugänglich gemacht werden. Am allerbesten ist natürlich wenn es sich vermeiden lässt, diese Daten überhaupt im Empfang zu nehmen, sofern diese nicht für die Durchführung des Projektes unabdingbar sind.
Checkliste
- Erklärung zur explorativen Natur eines Data-Science-Projekts
- Definition eines möglichen Abbruchpunktes nach der ersten Untersuchung der Daten
- Keine Vereinbarung für Meetings für vorläufige Ergebnisse
- Form und Inhalt des endgültigen Ergebnisses sind festgelegt
- Die Anzahl der Präsentationen der Ergebnisse ist festgelegt
- Mögliche Analyseergebnisse und darauf zu ergreifende Maßnahmen wurden besprochen
- Die Vergütung für die investierte Zeit ist festgelegt
- Es ist festgelegt, dass kein bestimmter Erfolg in Hinblick auf die Unternehmenskennzahlen des Kunden gewährleistet wird
- Die bereitgestellte Hardware wird definiert (falls zutreffend)
- Drittanbieter-Tools die verwendet werden sollen sind vom Kunden explizit genehmigt
- Die Verantwortung persönlich identifizierbare Informationen zu minimieren liegt beim Kunden. Der Umfang der bereitgestellten Datensätze ist definiert
- Dokumentation der Größe, Struktur und des Umfangs der bereitgestellten Daten.
- Der Zugang zu fachkundigen Ansprechpartnern ist definiert und geplante Abwesenheiten wurden mitgeteilt