Data-Driven Culture oder doch lieber Bauchgefühl?

Data-driven Culture an einem Tag? Vergiss es!

Zack, schmeißen wir mal für im nächsten Meeting drei Mal die genannten Buzzwords in die Runde, dann läuft das schon mit der Data-driven Culture. Falls nicht, hat man ja alles getan, um datengetriebenes Arbeiten auf den Weg zu bringen.  Das kleine Problem an der Sache ist, dass es so nicht funktionieren wird. Ein Unternehmen dazu zu bringen mit Daten ganzheitlich in allen Bereichen zu arbeiten ist ein Prozess der Monate, teilweise sogar Jahre andauern kann. Dabei sind viele Faktoren zu bedenken, wie bspw. das Alter und die Größe eines Unternehmens. Aber auch andere, weichere Einflüsse bedingen das Gelingen dieser Unternehmung.

C-Level steht auch für Culture-Level

"Der Fisch fängt immer am Kopf an zu stinken". Klare Ansage: Kulturwandel müssen von oberster Ebene in die unteren hinein vorgelebt werden. Wenn ich als Chef im Meeting mit meinen Heads noch immer den Daumen hebe und über diesen essenzielle Entscheidungen peile, dann muss ich mich nicht wundern, wenn eine Data-driven Culture im Kein erstickt wird. Ebenso ein blindes Einfordern von Ergebnissen ohne klare Zielvorgabe oder striktes Micromanagement führen zwangsläufig dazu den Erneuerungswillen der Mitarbeiter/innen empfindlich zu stören. Hingegen realistische Meilensteine zu definieren (bspw. Schulungen im Umgang mit Daten, Tracking eingebaut bis XY, etc.), Platz für freies Denken zu schaffen (Was ist State-of-the-Art? Welche Konzepte sind sinnvoll? Etc.) und ein vorgelebtes Vertrauen in die Fähigkeiten der eigenen Mannschaft offen zu demonstrieren (Fail fast and learn ist ok!) fördern auch den Willen aus der eigenen Komfortzone zu kommen und sich aktiv einzubringen. Ebenso die klare Kommunikation über die Funktionalität der Daten und deren Handling im Unternehmen ist von größter Wichtigkeit. Daten dienen der Optimierung und nicht der stumpfen Kontrolle durch den Chef. Gerade hier reagieren Mitarbeitern durchaus immer sehr hellhörig und sensibel.

Fail fast and learn

Der Umgang mit Fehlern erfordert manchmal nicht nur im Datenbereich ein Umdenken der bisherigen Kultur, sondern auch in Bezug auf die restlichen Werte eines Unternehmens. Wer Angst hat Fehler zu begehen bzw. seinen Mitarbeitern dieses nicht zugesteht in einem bestimmten Rahmen, der wird niemals die nächste Stufe erklimmen. Ohne Misserfolg gibt es auch keinen Erfolg. Gerade das sollte man von den großen in jeder Branche gelernt haben. Ich habe mal gelernt:

"Wenn du einen Fehler machst, dann bemerke und behebe ihn schnell, aber lerne daraus und mache es besser"

Ganz einfach! Eine Data-driven Culture zu etablieren, heißt viele Fehler zu machen. Oftmals sind es Kommunikationsfehler, die die Anforderungen bzw. Erwartungen falsch interpretieren lassen. Der Entwickler baut das Tracking falsch ein, weil der Analyst das Ticket nicht genau genug geschrieben hat. Die Analyse gibt nicht das her, was der Marketing-Mensch braucht, da er sich selbst mit den Zahlen vorher nicht beschäftigt hat und nur nach "Trafficzahlen" gefragt hat. Es fehlt oftmals an der richtigen Sprachebene zwischen den Parteien Analysten, Entwickler sowie Produkt- und Marketingmanager. Genau das führt oftmals zu Frustrationen, die sehr schnell zu Misstrauen und irreversiblen Schaden führen. Dies gilt es zu vermeiden. Einfachste Methode dabei ist es diese Player an einen Tisch zu holen und sich auf eine gemeinsame Sprachebene zu bringen und ein glasklares Erwartungsmanagement für alle zu betreiben.

Übergreifende Alpha-Teams aufbauen

Wie im vorherigen Absatz schon erwähnt hilft es aus den verschiedenen Abteilungen ein Team zusammen zu stellen, dass eine gewisse Vorreiterrolle einnimmt und den Rest des Unternehmens durch gelebte Data-driven Culture ein Beispiel ist. Dabei gilt es eine sprachliche Ebene zu finden, die alle verstehen. Jeder sollte am Anfang dabei versuchen so einfach wie möglich zu erklären und die Komplexität langsam zu steigern. Beispiel: Ein "Feature" ist für den Data Scientist nicht das, was ein Entwickler unter "Feature" versteht.

Ebenso Themen, die mehrere Fachbereiche betreffen und darüber hinaus gehen müssen ins große Ganze eingeordnet werden. Ein nettes Beispiel ist das Thema "Event-Tracking". Für den Web Analysten ist es bspw. die Nutzerinteraktion mit Links, Buttons, Teaser und den dazugehörigen Werten, die eindeutig identifizieren, welches Element auf der Seite geklickt wurde, um es dann in Beziehung zum restlichen Nutzerverhalten zu setzen. Der Entwickler hingegen stellt sich erstmal die Fragen: "onClick, onMousedown...? Welchen Separator? Und warum müssen alle Elemente trackbar sein? Das macht doch meine Seite langsam!". Der Marketing-Manager wiederum wird sich fragen, warum nicht nur der eine Button, der zur Landingpage seiner Kampagne gehört, gemessen wird. Hier gilt es sehr klar das langfristige Ziel zu  formulieren und zu kommunizieren, welche positiven Effekte daraus hervorgehen. Ebenso kleinere Vorteile, wie bspw. die verbesserte Customer Journey Analyse, die zur höheren Conversion Rate der Kampagne führt oder die mögliche Verschlankung der Seite, sofern das Element nicht performt, sollten mit eingebracht werden.

Die Quintessenz aus beiden Beispielen ist die Rücksichtnahme am Anfang bei gleichzeitigem gemeinsamen Lernen für die zukünftige Weiterentwicklung des Kulturwandels. Wichtig ist dabei ist die Bereitschaft aller dies zu akzeptieren und als Bereicherung zu sehen. Ergänzt kann dieses "Learning on the job" durch Sessions der einzelnen Projektteilnehmer sofern dies gewünscht ist. Dies beschleunigt durchaus das schnellere Zusammenwachsen sowie Integration der Data-driven Culture. Beispiele:

• Analysten/innen erklären ihre Analytics-Messkonzepte
• Entwickler/innen zeigen wie Daten in den DataLayer kommen
• Produktmanager/innen stellen Arbeitsprozesse wie bspw. Scrum vor
• Marketingmanager/innen führen ihre Tools vor
• Data Engineers erklären, wie Daten "gelagert" werden und welche Verbindungen und Visualisierungen möglich sind

Genau diese Maßnahmen schaffen Vertrauen in die gegenseitigen Fähigkeiten, wie bspw. die Korrektheit von Anaylseergebnissen sowie den sich daraus entwickelnden Handlungsempfehlungen für das Marketing und Produkt oder in den richtigen Einbau von Trackingstrukturen und damit am Ende auch in die gemeinsam gelebte Kultur. Allerdings sollte diese Initialisierung von datengetriebenen Arbeiten konsequent weiter entwickelt werden, da das bisher Vorgestellte keine Einbahnstraße, sondern ein Kreislauf ist, der immer wieder neuen Antrieb braucht.

Was macht die Data-driven Culture aus? Mensch oder Tool?

Ein State-of-the-Art Tool- und Technikportfolio ist sehr wichtig für ein voranschreitendes Unternehmen. Wer mittlerweile keine schnelle und technisch aktuelle Seite, die richtige Ad/Mar-Tech- oder Analyselandschaft hat, wird zwangsläufig irgendwann ein Problem bekommen, da Kunden nicht mehr erreicht und damit monetarisiert werden können. Allerdings kann der Fall auch eintreten, dass Tools und Anforderungen an die hauseigene Seite, die Mitarbeiter/innen überfordert und jeder in seinem Silo (wieder) vor sich hinarbeitet. Gegensteuern lässt sich mit der Schulung von Mitarbeitern oder dem zusätzlichen Einstellen von "Know-How", das noch nicht im Unternehmen vorhanden ist. Wird im Rahmen einer Data-driven Culture das gemeinsame Lernen und Wachsen gefördert, so lassen sich am Ende des Tages auch Tools und Technik effizienter einsetzen und somit Zeit und Kosten sparen, die an anderer Stelle weitaus besser eingesetzt werden können.

Wer die menschliche Komponente stark in den Fokus stellt braucht auch keine Angst vor Stillstand oder der falschen Toolauswahl zu haben. Wer in seinem Feld Experte und durch regelmäßigen Austausch mit anderen ist, kann technische Anforderungen klar formulieren und diese kosteneffizient und effektiv umsetzen, sodass keine Redundanzen oder Löcher in der Infrastruktur entstehen.

Was sollte nie vergessen werden? Dokumentation!

Wahrscheinlich die unbeliebteste Aufgabe im ganzen Prozess: Dokumentation. ABER wohl mit die wichtigste im Verlauf. Wer ordentlich dokumentiert, hat es hinten raus einfacher. Beim Anlernen neuer Leute, die viel Know-How in kurzer Zeit aufbauen müssen, beim eigenen Nachvollziehen, warum bestimmte Sachen so gemacht wurden, wie sie gemacht worden sind oder Entwickler können Prozesse besser umsetzen und reproduzieren. Dabei ist Form der Dokumentation erstmal zweitrangig, wichtig ist dabei eher die Struktur. Ob ich ein Wiki nutze indem ich Code und Fachbegriffe archiviere und kläre oder ob ich eine Mischung aus GitHub und einem Google Spreadsheet nutze. Hauptsache jeder weiß, wo es die Dinge nachzuschlagen gilt.

Checkliste Data-driven Culture

• Das C-Level muss glaubhaft mitgestalten und vorleben
• Fehler müssen gemacht werden (dürfen)
• Übergreifende Teams müssen gemeinsame Kommunikation entwickeln
• Investiert in Menschen, dann in Tools
• Baut eine strukturierte Dokumentation auf und macht sie allen zugänglich

Letzte Anmerkung und dann ist Schluss

Was die ganze Sache deutlich nochmal vereinfacht, ist das Bestimmen einer Person, einer Art Projektmanager oder "Mediator", um einen Anlaufpunkt zu haben. Oftmals eignen sich dafür technisch, affine Analysten oder Marketingleute oder neuerdings auch sogenannte "Manager Digital Operations".