Aufbau einer Data-Analytics- und Data-Science-Organisation

Die Branchen Energie, Mobilität und Smart City sind enorm datengetrieben. Für einen reibungslosen Betrieb rund um die Uhr benötigen die Unternehmen der Wiener Stadtwerke geeignete Entscheidungshilfen – Data Analytics und Data Science unterstützen sie dabei. Für den Aufbau einer geeigneten Konzern­organisation wurden ein vierstufiges Prozessmodell, vier Rollenprofile und eine virtuelle Aufbau­organisation entwickelt.


1. Ausgangssituation

Wir schreiben das Jahr 2016: Big Data, Advanced Analytics, Machine Learning und weitere Kombinationen dieser Begriffe wurden von Gartner mehrfach als die topstrategischen Technologien für das kommende Jahr prognostiziert. Die Wiener Stadtwerke als moderner Infrastruktur­dienstleister und einer der größten Mischkonzerne Österreichs beginnt sich ebenfalls umfassend mit dem Thema auseinanderzusetzen. Mit seinen Unternehmen Wien Energie, Wiener Netze, Wiener Linien, Wiener Lokalbahnen, Bestattung Friedhöfe, WiPARK, Facility Comfort, Upstream Mobility und WienIT agiert der Konzern in besonders datenintensiven Branchen. In einigen Abteilungen, zB in der Energiewirtschaft, sind Methoden aus dem relativ neuen Bereich Data Science schon längst im Einsatz. Für einen effizienten und wirtschaftlichen Betrieb der Anlagen setzen die Abteilungen auf statistische Methoden, um ein genaueres Bild der Zukunft zu erhalten. Auf Konzernebene existiert jedoch keine Struktur zur Koordination und Verknüpfung dieser einzelnen Expertengruppen.

Im Büro des Chief Information Officers wird daher im Frühjahr 2017 eine Stelle freige­geben, die diese konzernübergreifende Organisation aufbauen und erste Leuchtturmprojekte umsetzen soll. Damit beginnt die konzernweite Arbeit am Thema Data Analytics. Initial liegt der Fokus stark auf Anwendungsfällen und es werden vier konkrete Projekte ausgewählt sowie erfolgreich umgesetzt:

  • Small Scale Big Data: Analyse des Mobilitätsverhaltens von Kunden gemeinsam mit dem Konzern-Start-up Upstream Mobility;
  • Rail Shock Recording: Erkennung von Gleisbeschaffenheit und -schäden auf Basis von Vibrationssensordaten herkömmlicher Mobiltelefone;
  • Churn-Analyse von Energie-Kunden: Verbesserung der Modelle zur Vorhersage von Kundenabwanderung;
  • Predictive Maintenance bei Straßenbahnen: Vorhersagen von Fehlern wichtiger Baugruppen in Straßenbahnen auf Basis von Sensordaten.

Nachdem erste Erfahrungen gesammelt wurden, wird der Bedarf, diese neue Form von Aufgaben zu organisieren, zunehmend sichtbar. Ende 2017 wird daher ein konzernweites Organisationsprojekt gest­artet. Mit externer Unterstützung von EY wird eine Governance für das Analytics Competence Center (ACC) ausgearbeitet. Dazu wird ein dreistufiges Vorgehen angewandt:

  • Mission definieren,
  • Prozess und Aufgaben beschreiben sowie
  • Rollen und Aufbau­organisationsform ausarbeiten.

Für die Ausarbeitung einer geeigneten Mission werden strukturierte Interviews mit wesentlichen Stakeholdern in allen Bereichen des Konzerns durchgeführt. Daraus ergeben sich die folgenden fünf Anforderungen als Mission des ACC :

  • zentrale Anlaufstelle rund um Analytics, Data Science und Big Data;
  • Pflege der internen und externen Experten-Community;
  • Verwaltung eines übergreifenden Portfolios aller Analytics-Initiativen;
  • Unterstützung ausgewählter Analytics Use Cases;
  • Bereit­stellung von Schulungen und Best Practices zur Befähigung der Fachbereiche.

Auf Basis dieser Mission wird die weitere Governance entwickelt, die in der Folge näher beschrieben wird.

2. Der Analytics-Lebenszyklus

Wie läuft ein typisches Analytics-Projekt ab? Mit dieser Frage startete die Ausarbeitung des später „Analytics-Lebenszyklus“ benannten Prozesses. Dieser besteht aus vier Phasen:

  • Initiierung,
  • Datenanalyse,
  • Entwicklung und
  • Operationalisierung (siehe Abb 1).

Der Prozess dient als Leitfaden und Basis für Rollenprofile und folglich auch für die Aufbau­organisation. Der Analytics-Lebenszyklus orientiert sich stark an allgemeinen Innovationsprozessen mit einigen Besonderheiten. Wichtig ist die deutliche Reduktion der Menge an Ideen oder Projekten je Phase. Dafür sind geeignete Auswahlkriterien für strategisch und wirtschaftlich sinnvolle Anwendungsfälle notwendig. Ein Spezifikum für den Analytics-Lebenszyklus sind auch reine Proofof-Concept-Projekte. Darunter sind Ideen oder Projekte zu verstehen, deren Ziel nur ein Machbarkeits­nachweis oder eine einmalige Auswertung ist. Die Ergebnisse werden präsentiert, danach nehmen die Projekte den „Power-Point-Exit“ aus dem Lebenszyklus.

Abb 1: Der Analytics-Lebenszyklus der Wiener Stadtwerke.

Abb 1: Der Analytics-Lebenszyklus der Wiener Stadtwerke.

2.1. Initiierung

In der Initiierungsphase liegt das Augenmerk auf der Ideengenerierung und Ausgestaltung von Projektideen. Das ACC hat dabei innerhalb der Wiener Stadtwerke die Aufgabe, den Ideentrichter zu erweitern und für eine rasche Weiterentwicklung der Ideen zu sorgen. Genutzt werden dabei diverse Kreativ­methoden. Insgesamt soll diese Phase eine Durchlaufzeit von wenigen Wochen nicht überschreiten, weil die Menge an Ideen sonst zu groß wird, ohne dabei Mehrwert zu generieren.

Um neue Analytics-Ideen in der Initiierungsphase erfolgreich auf den Weg zu bringen, sind drei Barrieren zu überwinden. Die erste und zentrale Barriere für das ACC ist Vertrauen. Dabei gilt es, diverse Ängste zu überwinden. Dies kann nur durch kompetente Beratung und transparente Umsetzung von Projekten geschehen. Eine weitere Barriere bilden die verfügbaren Daten. Zunächst titulierte das ACC noch unter „Big-Data-Organisation“. Dadurch wurde aber häufig die Frage getriggert: „Habe ich denn genug Daten?“ Diese Frage ist für Analytics-Projekte meist nur sekundär von Relevanz. Daher wurde das „Big“ bei den Wiener Stadtwerken in diesem Kontext gestrichen. Die dritte Barriere stellen rechtliche Rahmenbedingungen und Informationssicherheit dar, insb die Datenschutzgrund­verordnung (DSGVO). In diesem Zusammenhang führt fehlendes Wissen oft zur Übererfüllung der Regeln oder zu Angst im Fachbereich, dadurch kann die Initiierung gehemmt werden. Hier setzen die Wiener Stadtwerke auf konsequente und regelmäßige interne Trainings zu den Themen Datenschutz und Informationssicherheit.

In der Initiierungsphase ist es zudem wichtig, die Projektidee aus dem Blickwinkel der jeweiligen Fachabteilung zu betrachten. Analytics und Machine Learning sollen kein Selbstzweck sein, sondern der Generierung konkreter Mehrwerte dienen.

2.2. Datenanalyse

In der Phase der Datenanalyse werden die Daten bereitgestellt und ein erster Proof-of-Concept entwickelt. Dabei werden vier wesentliche Schritte durchlaufen:

  • physische Datenbereit­stellung,
  • Sichtung der Daten inklusive Ausdetaillierung der Frage­stellung,
  • Methodenauswahl inklusive Datenaufbereitung und
  • Validierung des Modells.

Für eine optimale Umsetzung empfiehlt sich ein agiles Projektsetup, weil seitens der Analytics-Experten regelmäßig Wissen oder Entscheidungen vonseiten des Fachbereichs benötigt werden.

Bei der physischen Datenbereit­stellung besteht die Herausforderung im ersten echten „Austausch“ von Daten. Dh, im Hintergrund müssen dafür alle (rechtlichen) Rahmenbedingungen geklärt sein, sonst können keine Daten übermittelt werden. Bei den Wiener Stadtwerken werden daher ua Datenschutzverantwortliche frühzeitig in die Ideenausgestaltung miteinbezogen. Weiters müssen die für die Datenbereit­stellung notwendigen IT-Ressourcen verfügbar sein. Da es sich hierbei meist um Schlüsselkräfte handelt, gilt es, diese ebenfalls rechtzeitig einzuplanen.

In diesem zweiten Schritt werden die Daten gesichtet und die Informationen des Fachbereichs geprüft. Oft werden dabei Sonderfälle identifiziert, die dem Fachbereich zwar bekannt, aber nicht an das ACC kommuniziert wurden. Diese Sonderfälle und die genaue Zielgröße sind in diesem Schritt zu detaillieren. Gerade das Bestimmen der eigentlich zu berechnenden Zielgröße erfordert oft ein iteratives Vorgehen, weil hierfür viele Detailfragen geklärt werden müssen.

In einem weiteren Schritt wird eine geeignete Machine-Learning-Methode für die vorliegende Problem­stellung ausgewählt. Neben der Methodenauswahl müssen dabei oft auch die Trainingsdaten in eine geeignete Repräsentation gebracht werden. Danach kann nun das analytische Modell trainiert werden.

Nachdem ein Modell erfolgreich trainiert wurde, muss dieses in einem letzten Schritt der Datenanalyse validiert werden. Im Analytics-Kontext können Modelle korrekte Vorhersagen nur mit einer bestimmten Quote treffen, in der Praxis jedoch selten mit 100 %. Daher muss das Modell auf eine Sammlung von Testdaten angewendet werden, wobei für jedes Beispiel die richtige Antwort bekannt ist. Die Testdaten sind für den späteren Feinschliff des Modells wichtig und bilden den Ausgangspunkt zur Bewertung der Modellqualität. Ist die Qualität des trainierten Modells ausreichend, ist der erste Proof-of-Concept erbracht.

2.3. Entwicklung

In der Entwicklungsphase wird das trainierte Modell verbessert und die organisatorische Verankerung geplant. Ist der Proof-of-Concept geschafft, kann das analytische Modell weiter verbessert werden. Dabei ist ein Abgleich zwischen Fachbereich und ACC von zentraler Bedeutung, weil Verbesserungen an einer Stelle zu Verschlechterungen an anderen Stellen führen können. Oft werden in diesem Schritt auch weitere Trainingsdaten aufgenommen bzw sogar Live-Daten angebunden. Neben der technischen Weiterentwicklung muss in der Entwicklungsphase häufig auch eine Organisations- oder Prozess­änderung im Fachbereich ausgearbeitet werden. Analytics-Anwendungen führen oft zu Änderungen in fachlichen Prozessschritten. Diese gilt es zu planen und die notwendigen Schnittstellen bzw Anpassungen in bestehenden IT-Systemen zu identifizieren.

2.4. Operationalisierung

In der Operationalisierungsphase muss der operative Betrieb vorbereitet werden. Hierfür sind die Produktivsetzung des analytischen Modells, der Abschluss von Anpassungen in IT-Systemen und die Änderung der organisatorischen Abläufe notwendig. Für die Produktivsetzung analytischer Modelle bauen die Wiener Stadtwerke aktuell eine standardisierte IT-Architektur auf. Dieses Vorgehen empfiehlt sich, weil viele Methoden ähnliche Anforderungen an die darunterliegende IT-Infrastruktur haben und die Rechen­leistung besser geteilt werden kann. Die Anpassung an Business-IT-Systeme kann frühzeitig in der Entwicklungsphase starten. Dabei werden in der Operationalisierung die meisten Ressourcen gebunden. Abschließend müssen die Mitarbeiter im Fachbereich auf die neuen Abläufe trainiert werden. Ist diese Phase abgeschlossen, kann ein Analytics-Anwendungsfall den operativen Betrieb aufnehmen.

3. Rollen in der virtuellen Organisation

Mit dem Analytics-Lebenszyklus und den enthaltenen Aufgaben konnte nun auch die für die meisten Stakeholder spannende Frage der Rollen und der Aufbau­organisation beantwortet werden.

Das Rollenmodell der Analytics-Organisation der Wiener Stadtwerke kennt vier wesentliche Profile:

  • Analytics Consultant,
  • Data Scientist,
  • Data Engineer und
  • Analytics Developer.

Die Rollen wurden durch Zusammenfassen der abzuarbeitenden Aufgaben im Analytics-Lebenszyklus definiert und im Konzern eingesetzt. Durch diese Vorgehensweise konnte der Zeitbedarf der einzelnen Rollen in den Prozessphasen geschätzt werden (siehe Abb 2). Die Erfahrungen im Konzern bestätigen diese initiale Schätzung.

Abb 2: Zeitbedarf je Rolle im Analytics-Lebenszyklus.

Abb 2: Zeitbedarf je Rolle im Analytics-Lebenszyklus.

3.1. Analytics Consultant

Der Analytics Consultant agiert ähnlich einem Projektleiter und übernimmt alle administrativen Aufgaben innerhalb von Analytics-Projekten. Er erhebt, versteht und schärft die Anforderungen der Fachbereiche und unterstützt sie bei der Beurteilung von Analytics-Anwendungsfällen. Der Consultant benötigt dafür ein grundlegendes Verständnis aller Tätigkeitsfelder des ACC. Er ist insb in die ersten beiden Phasen von Analytics-Projekten stark eingebunden.

3.2. Data Scientist

Der Data Scientist verfügt über das Methodenwissen für den Aufbau analytischer Modelle. Er übersetzt die fachliche Problem­stellung zu mathematisch lösbaren Problemen und setzt für deren Lösung statistische Modelle und selbstlernende Algorithmen ein. Der Data Scientist verfügt oft über eine Mathematik- oder Informatik­ausbildung mit notwendigem Schwerpunkt.

3.3. Data Engineer

Der Data Engineer bereitet Daten für deren Verwendung in Analytics-Projekten auf. Er versteht, modelliert und optimiert Datenflüsse und Datenintegration und verfügt über ein umfassendes Verständnis der betrieblichen Daten- und Systemlandschaft. Als Data Engineer eigenen sich meist bestehende IT-Ressourcen im Datenbankumfeld. Sie sind besonders für die Datenbereit­stellung wichtig. Die Datenbereit­stellung unterscheidet sich in Bezug auf den Zeitbedarf je Rolle stark von der Datenanalyse und wurde daher eigenständig ausgewiesen.

3.4. Analytics Developer

Der Analytics Developer integriert die Quelldaten mit dem produktiven analytischen Modell und den Business-IT-Systemen. Er verfügt über Wissen zu Analytics, zur zugehörigen Systemlandschaft und zu IT-Systemen im Geschäftsprozess. Diese Rolle kann durch bestehende Entwickler in der IT-Organisation abgedeckt werden.

3.4. Weitere Rollen

Beim Aufbau einer Analytics-Organisation empfiehlt es sich, nicht nur einen Data Scientist, sondern zumindest auch einen Analytics Consultant einzustellen. Eine zentrale Schwierigkeit in Bezug auf Data Scientists ist das Halten dieser Mitarbeiter. Sie wollen meist fortlaufend an herausfordernden Problemen arbeiten und können durch starre Konzernstrukturen schnell demotiviert werden. Aus diesem Grund ist auch der Analytics Consultant wichtig für die Organisation. Er treibt die meist zeitaufwändigere Initiierung und Datenbereit­stellung im Analytics-Lebenszyklus stark voran.

Neben den vier Rollenprofilen wurden auch weitere Spezialisierungen ausgearbeitet, die sowohl methodische als auch administrative Schwerpunkte innerhalb der Rollen abbilden. Diese werden allerdings erst bei einem weiteren Ausbau der Analytics-Organisation eingesetzt.

4. Aufbau­organisation

Abschließend wurde eine für die Wiener Stadtwerke geeignete Aufbau­organisation ausgearbeitet. Dafür wurden verschiedene Varianten – von einem komplett dezentralen Aufbau bis hin zu einem zentralen Center of Excellence – bewertet. Schlussendlich aufgebaut wurde ein gemischtes Modell mit einer virtuellen Organisation. Dabei werden in allen Konzern­unternehmen Analytics Consultants und in einigen auch Data Scientists aufgebaut. Eine zentrale Einheit im Büro des Chief Information Officers (das ACC), bestehend aus Analytics Consultant und Data Scientist, koordiniert zusätzlich konzernübergreifend. Aus dem ACC werden die folgenden Themen konzernweit angeboten: fachliches Know-how zu Data Science, Schulungen, eine technische Plattform sowie Community Events zum regelmäßigen Austausch innerhalb des Konzerns. Durch diese Organisationsform besteht einerseits eine Nähe zum Fachbereich, andererseits werden durch das zentrale ACC Synergien genutzt.

Auf den Punkt gebracht

Die Bilanz nach einem Jahr Bestehen des ACC ist sehr positiv. Die Breite an Analytics-Projekten bei den Wiener Stadtwerken nahm deutlich zu und die Aus- und Weiter­bildung von Mitarbeitern stieg erfolgreich an. Das ACC wird von den Fachbereichen des Konzerns positiv angenommen. Der Aufwand für den Aufbau einer Analytics-Organisation hat sich somit gelohnt.


Der Artikel ist in CFO aktuell (Heft 2/2019) erschienen. Mehr Infos unter: www.cfoaktuell.at


Weiterbildungstipp

Certified Business Data Scientist | Wettbewerbsvorteile mit Big Data, Advanced Analytics und Machine Learning
Wann? Start am 14. Oktober 2019 | Wo? Munich Business School, 80687 München, Elsenheimerstr. 61 | Anmeldung

0 Antworten

Hinterlassen Sie einen Kommentar

Wollen Sie an der Diskussion teilnehmen?
Wir freuen uns über Ihren Beitrag!

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.