Wie man Data & Analytics Projekte komplett an die Wand fährt – und wie man es verhindert

Kennen Sie das? Es kommt ein neues Projekt auf den Tisch – es geht um Reporting, Big Data Analytics, Machine Learning, eine Data Platform für das Unternehmen? Das Controlling möchte die Finanz-Daten des ERP-System analysieren, das Sales & Marketing Team muss die CRM-Daten auswerten, in der Produktion gibt es IoT-Geräte als erste Prototypen. Es wird immer viel in „moderne“ Technologien investiert, doch wie erfolgreich sind diese Invests?

Exkurs: Data & Analytics Projekte scheitern
In der Öffentlichkeit sind kaum Informationen zu gescheiterten Data & Analytics Projekte bekannt – warum eigentlich? Es gibt zwar jede Menge Artikel wie und warum Business Intelligence oder Big Data Projekte scheitern – aber konkrete Anwendungsfälle und Lessons Learned sind kaum zu finden. Im Gegensatz dazu sind Berichte über gescheiterte Einführungen von ERP (Enterprise Resource Planning) in Konzernen vorhanden – wie beispielsweise bei LIDL, Haribo, Otto, Deutsche Bank, Deutsche Post (Link). Ohne konkrete öffentliche Berichte – nehmen wir einfach an: Data & Analytics Projekte scheitern.

Data & Analytics Projekte unterscheiden sich von ERP-Projekten
Bleiben wir am Beispiel und konkretisieren: Data & Analytics Projekte unterscheiden sich von ERP-Projekten: eine ERP-Einführung dient dazu die primäre Prozesskette von rückwärts effektiv und effizient abzuwickeln (Kunde bestellt, Versand liefert, Produktion produziert, Einkauf beschafft) und sekundäre Prozesse in den Bereichen HR, Finanzen, Controlling oder auch IT zu unterstützen. Data & Analytics Projekte basierend auf einer ERP-Einführung dienen meist der Analyse und dem Berichten dieser Daten. Ein weiterer, wichtiger Unterschied ist, dass ein Data & Analytics Projekt meist eher ein „hartes“ Enddatum hat (ja, es gibt Ausnahmen!), wohin gegen alle Projektbeteiligten einer ERP-Einführung auf ein fixes Enddatum für die Einführung hinarbeiten. Wird dieser Termin nicht gehalten, ist ein Aufschrei vorprogrammiert.

Welche Möglichkeiten gibt es, dass Data & Analytics Projekte nicht scheitern?
Diese Unterschiede sollten Verantwortliche von und Mitarbeiter in Data & Analytics Projekten kennen. Denn sie ermöglichen unterschiedliche Planungs- und Implementierungs-Konzepte. Doch wie gelingt es, dass man relativ schnell, einfach und kostengünstig zu einem guten Ergebnis kommt? Also ein qualitativ hochwertiges Ergebnis mit absoluter Sicherheit abliefert?

„Hochwertige Ergebnisse“ sind immer sehr positive Nutzer-Erfahrungen mit IT-Systemen gestützten, datengetriebenen Prozessen (kurz: Nutzung analytischer Applikation). Um eine hochwertige Applikation schließlich auszuliefern bedarf es einer Design Phase – in der der Analyst versteht welchen Bedarf der Kunde hat, das konzeptionelle Design entwirft und im Anschluss das finale Produkt erstellt. Das ist das Vorgehen des „Design Thinking Ansatzes“ – und ich liebe ihn.

Design Thinking bedeutet Entwicklung im Kopf des Kunden
Warum? Design Thinking bedeutet die Entwicklung von Software für einen Kunden – aus Kundensicht – das klingt einfach. Im Alltag dominieren dennoch weiterhin Interviews mit Lasten- und Pflichtenheft. Für Data & Analytics Projekte in der Design Phase ist dieses Vorgehen kein Best Practice (mehr) – diese Methodik ist alt und wurde durch neue Techniken überholt.

Design Thinking gibt einen Rahmen vor, um herauszufinden, wer der Nutzer ist, was ihn antreibt und in der täglichen Arbeit frustriert. Diese Nutzer werden Personengruppen (Persona) mit gemeinsamen Eigenschaften zusammengeführt und festgehalten, wie deren Sicht auf die analytische Applikation ist und was sie wirklich benötigen um Ihre Performance zu verbessern. Ein praktisches Beispiel und eine meiner größten persönlichen Erlebnisse – ein Vertriebsleiter wollte die Kundenumsätze basierend auf den Geschäftsjahren der jeweiligen Kunden sehen und analysieren. Diese Information brachte ihn in Verhandlungen in eine bessere Position. Folglich mussten die Stammdaten erweitert werden. Ohne das Interview und das Verständnis für seine tägliche Arbeit wäre diese Funktion niemals entwickelt worden.

Nachdem der Bedarf des Nutzer verstanden wurde, beginnt die Phase des konzeptuellen Entwurfs mit Storyboards, Wireframes, visuellem Design und die Darstellung des Anwendungsfalls. Direkte Rücksprachen mit offenen Fragen an den Nutzer sind erlaubt und explizit gewünscht – er soll verstehen was er bekommt. Meistens justieren die Nutzer ihren wahren Bedarf sogar noch einmal.

Im Anschluss werden die Ergebnisse der konzeptionellen Phase genutzt um das finale produktive Design zu entwerfen. Dazu zählen die Interaktionen mit der analytischen Applikation über das Endgerät, visuelle Spezifikationen und die formelle Erfassung als User Story für die Entwickler.

Und richtig gelesen – bisher wurde noch keine Zeile Code geschrieben, noch kein Data & Analytics Tool in die Hand genommen oder der Data Lake, das Lake Haus oder das Data Warehouse umfassend realisiert. Denn erst wenn dem Kunden klar ist was er bekommt und der Analyst die Anforderungen so dokumentiert, dass es die Entwickler aus Kundensicht verstehen, erst dann fängt die Entwicklung an.

Implementierung? Geben Sie die organisatorischen und technischen Rahmenbedingungen
vor
Liegen User Stories zur Umsetzung vor können diese auch umgesetzt werden. Voraussetzung dafür ist die Schaffung organisatorischer und technischer Leitlinien. Am besten ist es bereits im Anhang der User Story die architektonische Lösung und technischen Komponenten zu beschreiben – denn nichts ist schlimmer als streitende Entwickler über die „beste“ Lösung. Wichtig ist in diesem Zusammenhang, dass die architektonische Lösung als Standard innerhalb der Organisation definiert wurde. Denn sonst wird die Lösung früher oder später entweder zum „Schatten-IT-Projekt“ oder als „Individual-Lösung“erklärt, die irgendwann eine hohe technische Schuld fordert.

Parallel zur Standard-Architektur und den technischen Komponenten sollte auch definiert sein, wer die entsprechenden Arbeitspakte mit den jeweiligen Werkzeugen umsetzt. Wer im Team welche Rolle besetzt, diese auch ausführt und welche Kapazitäten einbringt sind die absoluten Basics in jedem Projekt – egal ob modern oder klassisch – und dennoch kommt es häufiger vor, dass dies nicht der Fall ist.

Ist die User Story laut Team umgesetzt, erfolgt anschließend der User Acceptance Test, in dem der Kunde das Produkt/ den Service akzeptiert oder ablehnt. Dieser Test erfolgt gemeinsam zwischen dem Business Analysten des Teams sowie dem Kunden und evtl. Dem Key User des Bereichs. Erst wenn der Kunde bestätigt, dass das Produkt live genutzt werden kann, ist die User Story fertig. Lehnt er ab, geht die User Story zurück ins Team. Es zählt der Grundgedanke: „wer bestellt, der bezahlt und wer bezahlt, hat Recht“.

Wie treiben Sie BI und Data Analytics-Entwicklungen voran?
Wenn Sie Fragen haben oder Rückmeldung geben wollen – ich bin immer an einem Austausch interessiert. Bitte wählen Sie die Kommentarfunktion unten, um eine öffentliche Diskussion zu führen. Für private Anschreiben kontaktieren Sie mich bitte über mein Xing– oder LinkedIn-Profil.

* Der Beitrag spiegelt die Meinung des Autors wider und ist keine allgemeingültige Meinung des TDWI. Als TDWI bieten wir die Plattform, alle Themen und Sichtweisen zu diskutieren. *