en
de

Gebrauchsanweisung für (Big) Data Projekte: drei Kernfragen

26 Mai 2016
| |
Lesezeit: 3 Minutes

Robo-Advisors für finanzielle Entscheidungen, Algorithmen, welche Betrug erkennen, Predictive Maintenance bei technischen Anlagen: Data Analytics-Lösungen halten Einzug in alle Branchen und alle Firmenbereiche. Viele Unternehmen sind gerade daran zu erkennen, dass Data Analytics nicht nur für die Googles, Facebooks und Amazons dieser Welt wirtschaftlich interessant sind, sondern auch für ihr Geschäft Wert zu generieren vermag. Dabei rückt – glücklicherweise! – die Frage, ob die Daten, die man nutzen will, nun wirklich «Big Data» sind, immer mehr in den Hintergrund – Hauptsache, verfügbare Daten werden gewinnbringend genutzt. Natürlich muss die Frage nach Umfang, Art und Dynamik der Daten geklärt werden – spätestens dann, wenn es darum geht, eine Dateninfrastruktur und –plattform aufzubauen bzw. zukunftsfähig zu machen. Zuvor gibt es allerdings noch eine Reihe von nicht-technischen Themen, über welche man sich Klarheit verschaffen sollte, bevor man eine Daten-Initiative startet. Wir haben für Entscheider, welche datenbasierte Projekte ins Auge fassen, drei wichtige Kernfragen zusammengestellt:

Welchem strategischen Ziel soll das Data Analytics-Projekt dienen?

Data Analytics-Lösungen unterstützen drei grundsätzliche geschäftliche Ziele:

  • Bessere Entscheidungen treffen
    Beispiel: ein Tool, welches die Meinungen von weltweiten Nutzern eines Produktes systematisch abbildet (Sentiment Analysis) und somit hilft, bei der Konzeption eines neuen Produkts die richtigen Schwerpunkte betreffend Funktionalitäten zu setzen. Sentiment Analysis wird auch von friedensfördernden Organisationen zur Analyse und zur Überwachung von Konfliktregionen eingesetzt.
  • Kosten reduzieren durch die Optimierung von Prozessen
    Beispiel: Ein System, welches Email-Anfragen an den Kundendienst sortiert und Standard-Anfragen automatisiert beantwortet
  • Erschliessen neuer Umsatzquellen durch Daten-Innovationen.
    Beispiel: Eine App, welche auf Basis einer Vielzahl von aktuellen Daten (persönliche Fitness, Arbeitsbelastung, Kühlschrankinventar etc.) eine persönliche Menüempfehlung für eine ausgewogene Ernährung macht

Bei datenbasierten Projekten ist es besonders wichtig, dass die übergeordneten geschäftlichen Ziele, welche mit der anvisierten Lösung unterstützt werden sollen, reflektiert und klar definiert sind. Dies aus mehreren Gründen: Zum einen werden manche datenbasierten Lösungen geschäftlich erst wirksam, wenn sie mit bestimmten Geschäftsmodellen vermarktet werden. Ein Beispiel: Predictive Maintenance ist eine Optimierung des Wartungsprozesses für technische Systeme. Sie ist für einen Anbieter dann wirtschaftlich interessant, wenn er seinen Kunden eine Wartungspauschale verrechnet oder sein System mit einem «Pay per use»-Ansatz anbietet (ein berühmtes Beispiel zu letzterem ist Rolls Royces «Power by the Hour»-Modell). Bei der Abrechnung der Servicedienstleistung nach Aufwand kann der Anbieter den Nutzen (keine ungeplanten Wartungsstillstände mehr, reduzierte Serviceaufwände) kaum voll abschöpfen. Deshalb sollte man sich zu Beginn von datenbasierten Initiativen fragen, ob strategische Ziele, Nutzen der Lösung und das Geschäftsmodell im Einklang stehen.

Ein weiterer Grund für die Wichtigkeit dieses Punktes ist die Rentabilitätsbetrachtung des Projekts. Ist beispielsweise das Lieferobjekt eines geplanten Projekts ein Modell, welches aufgrund von aktuellen Daten Vorhersagen macht, so wird die Genauigkeit dieser Vorhersagen einen direkten Einfluss auf die Rentabilität des Business Case haben. Ist ein Modell, welches zu 68% richtige Vorhersagen liefert, nun gut oder unbrauchbar? Diese Frage kann nur der Auftraggeber aus dem Business beantworten – nachdem er sich über die Ziele und den Business Case seines Projekts Klarheit verschafft hat.

Wo stehen Sie im Prozess?

Die Möglichkeiten, für ein Unternehmen Daten gewinnbringend zu nutzen, sind mannigfaltig. Haben die Projekt-Stakeholder nach einem «Data Visioning» einen bestimmten Anwendungsfall im Visier, werden sie feststellen, dass auch die Wege zu dessen Umsetzung zahlreich sind und nicht immer geradlinig verlaufen; gewählte Ansätze zur Datenmodellierung erweisen sich beispielsweise als Sackgassen, dafür gewinnen die Datenanalysten unverhofft neue Erkenntnisse, die einen komplett anderen Anwendungsfall plötzlich sehr attraktiv erscheinen lassen… kurzum: es besteht die Gefahr, sich zu verzetteln. Umso wichtiger ist es, Data-Projekte nach einem adäquaten Prozess abzuwickeln.

Wir empfehlen ein Vorgehen, in welchem für einen gewählten Anwendungsfall möglichst schnell dessen Machbarkeit geklärt wird – und zwar in datenmodellierungstechnischer und wirtschaftlicher Hinsicht. Im Zühlke Data Analytics-Prozess nennt sich die entsprechende Phase «Evaluate & Prototype»; sie ist darauf ausgelegt, dem Management in wenigen Wochen quantitative Grundlagen für einen Entscheid zur Lösungsumsetzung zu liefern.

Ist die Machbarkeit gegeben, kann die eigentliche Lösungsentwicklung starten. In dieser Phase werden die Datenmodelle bzw. Algorithmen entwickelt und validiert sowie die Datenplattformen, welche die Algorithmen mit Daten versorgen, realisiert. Ebenso geht es in dieser Phase darum, die entwickelten Datenmodelle durch geeignete Applikationen nutzbar zu machen; hierzu sind also nebst den Datenanalysten und –Plattformspezialisten auch daten-affine Software-Entwickler erforderlich. Angesichts dieser verschiedenen Disziplinen, die in der Lösungsentwicklung Hand in Hand arbeiten müssen, sind wir bei unserer letzten Frage angelangt:

Wie gehen Sie mit Interdisziplinarität um?

Data Analytics-Projekte sind stark interdisziplinäre Projekte. Sie werden erfolgreich, wenn die erforderlichen Disziplinen bzw. Unternehmensebenen im Projekt effektiv zusammenspielen.

Aus den oben genannten Gründen (s. erste Kernfrage) ist insbesondere der regelmässige Austausch zwischen dem Auftraggeber aus dem Business und den Datenanalysten essentiell. Gute Erfahrungen haben wir mit einer agilen Projektorganisation gemacht, in welcher ein Vertreter des Business die Rolle des «Product Owner» übernommen hat. Wir empfehlen während der Klärung der Machbarkeit eher kurze Entwicklungsintervalle zu fahren; ein- oder zweiwöchige Sprints stellen den erforderlichen intensiven Austausch zwischen den verschiedenen Disziplinen sicher.

Welche Erfahrungen haben Sie zu unseren drei Kernfragen gemacht? Wir freuen uns über Ihre Kommentare und über Ihre persönlichen Fragen zum Thema!

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »