Change Management: Wie künstliche Intelligenz den kulturellen Wandel in Unternehmen vorantreibt

Artificial Intelligence drives Change Management

2012 veröffentlichten Thomas Davenport und DJ Patil, der unter Präsident Obama der erste Chief Data Scientist der Abteilung für Wissenschafts- und Technologiepolitik der Vereinigten Staaten im Weißen Haus wurde, einen Aufsatz im Harvard Business Review mit dem Titel “Data Science is the Sexiest Job of the 21st Century”. Darin definieren sie die Rolle des Data Scientists als „hochrangigen Experten mit einer Ausbildung und Neugier, die ihn befähigen, neue Entdeckungen in der Welt von Big Data zu machen“. 

Zweifelsohne sind das Schlüsselkomponenten der Arbeit eines Data Scientists: sich in die Daten zu vertiefen, sie zu erkunden und zu verstehen – und dann aus den Daten unter Nutzung von Machine Learning und künstlicher Intelligenz (KI) künftige Ereignisse vorherzusagen.

Tatsächlich kratzt diese Definition aber nur an der Oberfläche. Woher kommen all die benötigten Daten? In der Praxis sind in den meisten Unternehmen die IT-Systeme über die Jahre zu ganzen Ökosystemen angewachsen. Die wenigsten davon wurden so konzipiert, dass sie jederzeit fast in Echtzeit und in feinster Granularität auf alle Daten zugreifen können. Der Zugriff auf diese Systeme und das Zusammenführen der Datenströme sind alles andere als trivial, ganz abgesehen von der Frage der Datenqualität. Allein diese Aspekte können bis zu 80 % sämtlicher Projektarbeiten ausmachen. Auch die Ausgangsdaten müssen bearbeitet werden: Prognosen über zukünftige Ereignisse sind nicht einfach so operativ nutzbar. Um aus den Prognosen Wert zu schöpfen, müssen sie in Entscheidungen umgewandelt werden, die idealerweise viele Bedingungen berücksichtigen. Diese Entscheidungen sollten darüber hinaus optimiert sein. Dafür werden Zielfunktionen oder Kennzahlen benötigt, die minimiert oder maximiert werden können. Sind die Entscheidungen einmal getroffen, sollten sie auch ausgeführt werden, was wiederum sehr viel „Data Plumbing“ braucht, um sie in die operative Geschäftsebene einfließen zu lassen. Doch damit nicht genug: Ein System, das Daten aufnimmt, künftige Ereignisse vorhersagt, Prognosen in nutzbare optimale Entscheidungen umwandelt und diese dann wieder in die operative Geschäftsebene rückführt, ein solches System muss zuverlässig, fehlertolerant und hochverfügbar laufen.

Die Einbindung von Data Scientists in Unternehmen

Data Science stellt sicherlich den wesentlichen Teil beim Einsatz von künstlicher Intelligenz in einem geschäftlichen Umfeld dar. Es wäre allerdings unfair gegenüber den anderen, ebenso maßgeblichen Akteuren, den gesamten Erfolg allein den Data Scientists zuzuschreiben. Manche Unternehmen haben mit einem mehrstufigen Ansatz experimentiert, um den Mangel an Data-Science-Kompetenz auf dem Markt wettzumachen und jeden Data Scientist mit einer Gruppe von Data Engineers umgeben. Diese sind primär darauf konzentriert, die Daten für die Data Scientists vorzubereiten und von diesen Prognosemodelle zu erhalten, die dann implementiert werden und mit der IT und den Betriebsabläufen interagieren müssen, um zu funktionieren. Abgesehen von der sozialen Problematik, Data Scientists einen Starstatus zu verleihen, hat dieser Ansatz noch weitere Nachteile: Die Data Scientists sind weit weg von den Herausforderungen der Datenerfassung und -bereinigung sowie der Sicherstellung eines reibungslosen und zuverlässigen 24/7-Betriebs des Prognose- und Entscheidungsmodells. Diese kreieren letztlich aber den Mehrwert für den Anwender oder Kunden. Der Ansatz kann zwar – häufig aus der Not heraus – funktionieren, weil es einfach zu wenige Data Scientists am Markt gibt, er ist jedoch nicht ideal. Denn bei dieser Aufstellung sind verschiedene Funktionen an verschiedenen Dingen interessiert: Data Engineers geht es um „Data Plumbing“, Data Scientists um Modelle, IT und Betrieb um ein laufendes System. Während Data Scientists beispielsweise die Modelle schnell ändern wollen, um mehr Daten integrieren oder mehr Modellvariablen nutzen zu können, will der IT-Betrieb das System nicht mehr anfassen, sobald es läuft, und ist höchstens mit ein paar sorgfältig geplanten neuen Versionen pro Jahr einverstanden. Niemand interessiert sich so richtig für die Kunden oder die Anwender – solange sie nur an Bord bleiben.

Vergleich mit anderen Bereichen: Softwareentwicklung

 

DevOps Devops.png by Rajiv.Pant ( Wikipedia.org CC BY-SA 3.0, modified by adapting the colours of the original graph)

Unternehmen, die künstliche Intelligenz nutzen und mit diesen Problemen konfrontiert werden, sind nicht die ersten, die merken, dass Silodenken keine optimalen Ergebnisse liefert. Im schlimmsten Fall wissen die Kollegen nicht, was die anderen tun oder arbeiten sogar gegeneinander an nicht abgestimmten Zielen, wobei jeder unabhängig voneinander nur die eigenen Leistungen optimiert. Vor ungefähr zehn Jahren stand die Softwarebranche vor ähnlichen Herausforderungen: Softwareentwicklung und Betrieb arbeiteten zu separat, um optimal zu funktionieren. Als Rechner billiger und leistungsfähiger wurden, lösten Server die Großrechner zum größten Teil ab. Rechenzentren vergrößerten sich auf Hunderte, später Tausende und sogar Hunderttausende von Computern. Die physische Hardware-Wartung ist immer noch ein wichtiger Aspekt, um die Funktionsfähigkeit der Rechner sicherzustellen, aber die Rechenzentren mussten die Verwaltung, die Einrichtung und das Monitoring automatisieren, um zuverlässige und reproduzierbare Services bereitzustellen. Die nächste Innovationswelle brachte die Virtualisierung der Server in der Cloud – die heutigen Betriebsteams haben nur noch wenig mit tatsächlicher Hardware zu tun: Infrastruktur ist reiner Code. Oder wie James Urquhart es beschreibt: Es gibt immer noch alle Aspekte des Betriebs wie Monitoring, Fehlertoleranz, zuverlässiger Service etc., aber sie sind jetzt Teil der Anwendung. Betrieb wird zur Entwicklung und umgekehrt. Dadurch entstand der DevOps-Ansatz.

Was ist DevOps?

DevOps ist ein Ansatz, der alle Rollen zusammenbringt und ihre Anstrengungen auf ein gemeinsames Ziel fokussiert. Der Grundgedanke ist, alle Ziele (und Leistungsanreize) der verschiedenen Gruppen aufeinander abzustimmen: Softwareentwickler entwickeln immer noch neue Software und fügen weitere Funktionen hinzu, Tester und Qualitätsmanager vermindern immer noch Risiken und der Betrieb strebt immer noch nach Stabilität – allerdings ist das gemeinsame Ziel jetzt, dem Kunden einen guten Service zu bieten und ihn zufriedenzustellen. Was hilft Kunden am meisten? Neue Funktionalitäten der Software, deren gründliche Prüfung und die Bereitstellung zuverlässiger und reibungsloser Services. Jeder Aspekt ist wichtig und Leistungsanreize werden aufeinander abgestimmt, um ein Gesamtpaket liefern zu können.

DevOps in einem KI-Unternehmen

Der gleiche Ansatz bringt beträchtlichen Nutzen für KI-Unternehmen: Den Kunden an erste Stelle zu setzen, klingt zunächst wie eine triviale Devise – welches Unternehmen behauptet das schließlich nicht von sich, da der Kunde doch derjenige ist, der am Ende alles bezahlt? Diesen Leitgedanken in einer Organisation zu verankern stellt jedoch eine große Herausforderung dar.
Die zentrale Frage, um die sich alles dreht, lautet: Was bringt dem Kunden den größten Mehrwert? Der Kunde legt Wert auf optimale Entscheidungen, die sowohl an seinen Hauptzielen ausgerichtet sind als auch zuverlässig und reibungslos ausgeführt werden. Um das zu erreichen, müssen Daten zugänglich sein und bereinigt sowie vorbereitet werden. Darüber hinaus werden Prognosen von hoher Qualität mithilfe exzellenter Modelle benötigt. Diese Prognosen gilt es dann in optimale Entscheidungen umzusetzen, die wiederum in die Betriebsebene des Kundensystems übertragen werden müssen – und das gesamte Setup muss rund um die Uhr und das ganze Jahr über störungsfrei laufen.
Ein Produkt in einer technischen Abteilung zu entwickeln und Data Scientists mit dem Gesamtprojekt zu betrauen – von der „Dateninstallation“ über die Modellentwicklung bis zur Fertigstellung und Anpassung des Produkts für einen bestimmten Kunden durch die Data Engineers, bevor es dann an das Betriebsteam weitergegeben wird –, dieser Vorgang wird all die Reibungen und operativen Schmerzen hervorrufen, welche die Softwarebranche vor der „Entdeckung“ des DevOps-Ansatzes aushalten musste. Ähnliches gilt für Künstliche-Intelligenz-Projekte: Alle Gruppen zusammenzubringen und deren unterschiedliche Ziele und Motivationen abzugleichen, hat das Potenzial, Kunden den meisten Mehrwert zu bringen – und damit auch dem Unternehmen, das die Services anbietet.

Organisationen entwerfen Systeme

Obwohl das Gesetz von Conway bereits 1968 entwickelt wurde, ist es heute noch relevant: „Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations.“ Das bedeutet, dass die organisatorische Struktur eines Unternehmens sich in den Produkten und Services widerspiegeln, die es entwickelt. Große Abteilungen, welche die Aufgabe erhalten, komplexe Produkte oder Services zu entwickeln, neigen dazu, große und monolithische Anwendungen mit vielen komplexen Abhängigkeiten zu kreieren. Dadurch wird es schwierig, die unterschiedlichen Teile zu entwirren, einzelne Aspekte zu ändern oder individuelle Komponenten auszutauschen. Wenn beispielsweise Data Scientists sich nicht eng mit den anderen Mitarbeitern der Organisation abstimmen, dürften automatisierte Entscheidungen nur schwer in die IT- und Geschäftssystemlandschaft des Unternehmens zu integrieren sein.

Deloitte veröffentlichte kürzlich eine Studie, die darlegt, wie sehr sich Organisationsstrukturen verändert haben – und dies immer noch tun. Ursprünglich waren Unternehmen in strengen Hierarchien mit festen Berichtslinien und Verantwortlichkeiten organisiert. 

Change Management and AI (Quelle: Deloitte)

 

Der Informationsfluss fand in erster Linie von oben nach unten statt. Informationen, die von unterschiedlichen Einheiten geteilt werden sollten, mussten normalerweise erst wieder ein paar Ebenen nach oben wandern, um dann woanders wieder „herunter zu sickern“. In der heutigen Geschäftswelt bemerkt Deloitte jedoch, dass viele Unternehmen eine neue Art der Vernetzung haben. Die unterschiedlichen Abteilungen sind nicht mehr in strengen Hierarchien organisiert, sondern direkt miteinander verbunden und in unterschiedlichen Graden voneinander abhängig. Während diese Organisationsstrukturen mehr Flexibilität ermöglichen als die hierarchischen Modelle, tragen sie nicht unbedingt zur Erreichung gemeinsamer Ziele bei. Jeder ist zwar mit jedem verbunden, aber oft indirekt und ohne klare Struktur. Ein vielversprechenderer Ansatz ist, das Unternehmen in kleinen Teams entsprechend ihren Aufgaben zu organisieren. Jedes Team besitzt die gleichen Kompetenzen und Ressourcen, fokussiert aber jeweils auf einen anderen Aspekt. Dadurch werden die Abhängigkeiten von anderen Teams minimiert. Im Agile-Vokabular werden sie oftmals als Squads, Tribes, Chapters oder Guilds bezeichnet – oder mit irgendeinem anderem Namen für Gruppen, die ein einheitliches Interesse verfolgen. Sie sind in der Lage, mehr oder weniger unabhängig von anderen Gruppen zu arbeiten. In der Welt der Softwareentwicklung wird diese Idee beispielsweise in den sogenannten „Microservices“ umgesetzt.
Das Grundprinzip bleibt das gleiche: der Aufbau eines Teams mit allen benötigten Kompetenzen und Ressourcen und dessen Ausrichtung an einem gemeinsamen Ziel mit Fokus auf der Wertschöpfung für das Unternehmen und seine Kunden.

 

Dr. Ulrich Kerzel ist Principal Data Scientist bei Blue Yonder. Er verfügt über mehrjährige Erfahrung an weltweit führenden Forschungseinrichtungen und hat internationale Arbeitsgruppen geleitet. Er ist Experte für statistische Datenanalyse und Big Data.

 

 

Sebastian wurde als Data Scientist bei Blue Yonder schnell bewusst, dass mehr nötig ist als Software und Algorithmen, um den Kunden einen echten Mehrwert zu liefern. Aus diesem Grund legte er einen Schwerpunkt seiner Arbeit auf Konfigurationsmanagement und Application-Lifecycle-Management sowie die Konzeption, die Entwicklung und den Betrieb dezentraler Systeme.
Sebastian wurde als Data Scientist bei Blue Yonder schnell bewusst, dass mehr nötig ist als Software und Algorithmen, um den Kunden einen echten Mehrwert zu liefern. Aus diesem Grund legte er einen Schwerpunkt seiner Arbeit auf Konfigurations-management und Application-Lifecycle-Management sowie die Konzeption, die Entwicklung und den Betrieb dezentraler Systeme.

 

Dr. Ulrich Kerzel & Dr. Sebastian Neubauer Dr. Ulrich Kerzel & Dr. Sebastian Neubauer