Data & AI Teamstruktur: Wie gestalten Sie Ihre Daten- und KI-Organisation?

Vor einigen Jahren war das sicherlich nicht die dringendste Frage für Unternehmen. Aber im Laufe der Zeit haben sich einige der frühen Big Data- und Data Science-Initiativen zu maschinellen Lernmodellen in der Produktion und kundenorientierten KI-Lösungen entwickelt. Die Einführung von Daten- und KI-Lösungen in großem Maßstab steht noch aus. So geben z.B. nur 20 % der Befragten der Data & AI Survey 2020 an, dass sie aus vielen Gründen tatsächlich einen geschäftlichen Nutzen aus Daten und KI ziehen.

Aus unserer Erfahrung bei vielen Kunden haben wir gelernt, dass ein Grund für die mangelnde Effektivität von KI-Initiativen die Herausforderung ist, wie man (Teams von) Datenexperten organisiert. Diese Herausforderung wird noch relevanter, wenn es tatsächlich gelingt, KI-Modelle in die Produktion zu bringen. Gleichzeitig wächst die Zahl der Daten- und KI-Experten in den Unternehmen. Daher stellt sich heute für viele Unternehmen die folgende Frage ganz dringend: Wie sollten wir unsere KI-Organisation strukturieren?

In diesem Blog werde ich versuchen, diese Frage zu beantworten. Zunächst werde ich die organisatorischen Gestaltungsprinzipien aus dem Buch Team Topologies zusammenfassen, die sich auf einen ähnlichen, aber anderen Bereich beziehen: die Softwareentwicklung. Der nächste Schritt besteht darin, zu beurteilen, wie diese Prinzipien auf den Bereich Daten & KI angewendet werden können, und zu einer Schlussfolgerung zu kommen, welche Prinzipien das Design von Daten- & KI-Organisationen bestimmen.

Business oder IT?

Initiativen, die sich mit Daten und künstlicher Intelligenz befassen, kommen oft entweder aus datenintensiven Geschäftsbereichen wie Marketing und Vertrieb oder aus dem Bereich, in dem die meisten Daten gespeichert sind, der IT-Abteilung. Erstere konzentriert sich auf den potenziellen Geschäftswert, letztere auf die Möglichkeiten, die neue Technologien und die Verfügbarkeit von Daten bieten.

Im Zuge der Digitalisierung von Geschäftsprozessen, Kundendiensten und Produkten haben die Geschäfts- und IT-Abteilungen viel Erfahrung in der Zusammenarbeit gesammelt. Die reiferen Unternehmen haben ihre Organisationsstruktur für die IT-Entwicklung und den Betrieb in funktionsübergreifende Produktteams mit einem langfristigen Auftrag umgewandelt, die auch als Squads bezeichnet werden, z.B. nach dem Spotify-Modell.

Aber sind Daten und KI wie Business oder IT? Funktioniert die Übernahme von Datenexperten in Produktteams so, wie wir es uns wünschen? Oftmals nicht, und zwar aus dem einfachen Grund, dass ein Unternehmen nicht über genügend Budget und/oder Datenwissenschaftler verfügt, um in jedem Produktteam, das einen solchen benötigt, einen Datenwissenschaftler einzusetzen. Aber selbst wenn Sie viele Datenwissenschaftler hätten, benötigt nicht jedes Produktteam einen Datenwissenschaftler, der das ganze Jahr über in Vollzeit für das Team arbeitet.

Manche Unternehmen entscheiden sich für ein oder mehrere Teams, die nur aus Datenexperten bestehen, und lassen diese als Produktteam arbeiten. In der Praxis fühlt sich die Topologie eines Produktteams für ein solches Team meist seltsam an. Produktteams funktionieren gut, solange sie eine einzige gemeinsame End-to-End-Mission haben, z.B. eine Customer Journey für eine bestimmte Reihe von Online-Diensten. Daten- und KI-Produktteams arbeiten in der Regel für viele verschiedene Geschäftsbereiche und für viele verschiedene Anwendungsfälle. Dies führt zu vielen Kontextwechseln und Prioritätskonflikten, von denen nicht erwartet werden kann, dass sie vom PO dieses Teams gelöst werden. Sicherlich kann und sollte der PO den Prozess erleichtern, aber Entscheidungen über Prioritäten sollten auf einer eher strategischen Ebene getroffen werden.

Bestehende Theorie zur Organisationsstruktur

Es gibt viele Bücher, Blogs und andere Veröffentlichungen zum Thema der Gestaltung von Organisationsstrukturen für die Softwareentwicklung. Ob diese Theorie direkt auf die Daten- und KI-Funktion Ihres Unternehmens anwendbar ist, ist, wie oben erwähnt, fraglich; Daten und KI sind nicht ganz dasselbe wie Softwareentwicklung. Aber wie wäre es, wenn wir die Theorie ein wenig verallgemeinern und versuchen, sie auf unsere Hauptfrage anzuwenden?

Ein Buch zu diesem Thema, das ich sehr schätze, ist "Team Topologies" von Matthew Skelton und Manuel Pais(Link). Ein Ratschlag, der mir besonders gut gefällt, lautet, dass man sich bei der Gestaltung von Organisationsstrukturen auf die Festlegung der Gestaltungsprinzipien konzentrieren sollte, nicht auf das Organisationsdesign selbst.

Team-Topologien, eine Zusammenfassung

Zunächst einmal beginnt das Buch mit einer Disqualifizierung von Organigrammen und Matrizen, indem es erwähnt, dass Organisationen, die sich zu sehr auf sie verlassen, oft nicht die notwendigen Voraussetzungen schaffen, um Innovationen zuzulassen und gleichzeitig in hohem Tempo zu liefern. Die Organigramme und Matrizen stellen einfach nicht dar, wie die Arbeit erledigt wird und wie die Teams miteinander interagieren. In der Praxis sind es die informellen Kommunikationswege, die die Wertschöpfung ermöglichen, nicht die theoretischen und formalen Befehlswege.

Bereits 1968 stellte Mel Conway fest, dass Organisationen, die Systeme entwerfen, gezwungen sind, Entwürfe zu erstellen, die Kopien der Kommunikationsstrukturen dieser Organisationen sind. Ein Ergebnis dieses Gesetzes ist, dass, wenn die gewünschte theoretische Systemarchitektur nicht mit dem Organisationsmodell übereinstimmt, eines der beiden Modelle geändert werden muss. Wir können dies zu unserem strategischen Vorteil nutzen. Wir können die Organisation (d.h. die Kommunikationsstruktur) so umgestalten, dass sie das gewünschte Systemdesign widerspiegelt.

Damit Teams effektiv arbeiten können, sollten wir uns um die kognitive Belastung und die Motivation des Teams kümmern. Nach Dan Pink sind die drei Elemente der intrinsischen Motivation Autonomie, Beherrschung und Zielsetzung. Die Überlastung eines Teams mit vielen Anfragen aus verschiedenen Geschäftsbereichen, die Verantwortung für viele Komponenten von Softwaresystemen und die Forderung, ein Tausendsassa zu sein (aber kein Meister), wirken sich negativ auf alle Elemente der intrinsischen Motivation aus. Damit Teams autonom arbeiten können, sollte die Notwendigkeit, mit anderen Teams zu kommunizieren, begrenzt sein. In der Regel dauert es 3 Monate, bis ein Team zu einer kohäsiven Einheit wird. Häufige Änderungen in der Teamzusammensetzung verzögern diesen Prozess. Die Belohnung von Teams anstelle von Einzelpersonen trägt zum Teamgeist bei.

Verhaltensstudien legen nahe, dass Menschen am besten mit anderen zusammenarbeiten, wenn wir ihr Verhalten vorhersagen können. Wir können Vertrauen aufbauen, indem wir anderen in der Organisation einheitliche Erfahrungen bieten. Klare Rollen und Verantwortlichkeiten helfen dabei, das erwartete Verhalten zu definieren und damit die Interaktion zwischen Teams effektiver zu gestalten.

Bei sorgfältiger Anwendung gibt es nur vier Teamtopologien, die zum Aufbau und Betrieb moderner Softwaresysteme erforderlich sind. Diese vier Typen dienen als leistungsfähige Vorlage für die Gestaltung von Organisationen. Alle Teams sollten sich auf einen dieser "magnetischen Pole" zubewegen.

Team-Topologien
Stream-aligned Team		Ist ein Team, das auf einen einzigen, wertvollen Arbeitsstrom ausgerichtet ist. Das kann ein einzelnes Produkt oder eine Dienstleistung, eine Reihe von Funktionen, eine User Journey, eine User Persona usw. sein. Keine Übergaben an andere Teams
Kompliziert-Subsystem Team		Verantwortlich für den Aufbau und die Pflege eines Teils des Systems, der stark von Fachwissen abhängt Ziel ist es, die kognitive Belastung eines auf einen einzelnen Stream ausgerichteten Teams zu reduzieren
Ermöglichungsteam		Besteht aus Spezialisten in einem bestimmten technischen Bereich, die keine direkte Verantwortung für die Produktentwicklung haben. Verantwortlich für die zeitaufwendige Aneignung von Wissen auf dem neuesten Stand der Technik und die Unterstützung von Teams bei dessen Anwendung Unterstützen Sie mehrere auf den Strom ausgerichtete Teams dabei, sich fehlende Fähigkeiten anzueignen, zu recherchieren, zu lesen, neue fortgeschrittene Fähigkeiten zu erlernen und zu üben.
Plattform-Team		Bereitstellung interner Dienste, die es den auf die einzelnen Abläufe ausgerichteten Teams ermöglichen, ihre Arbeit mit weitgehender Autonomie zu erledigen Eine Plattform ist eine Grundlage von Self-Service-APIs, Tools, Diensten, Wissen und Support, die als internes Produkt angeordnet sind, das die auf den Strom ausgerichteten Teams einfach nutzen können.

Ein wichtiger Bestandteil des Ansatzes der Teamtopologien ist die sorgfältige Gestaltung der Teamgrenzen. Dabei sollte vermieden werden, dass alle Teams mit allen anderen Teams kommunizieren müssen, um ihre Ziele zu erreichen. Wo immer Teams kommunizieren müssen, kann ein Interaktionsmodus definiert werden. Es gibt drei wesentliche Interaktionsmodi.

Modi der Interaktion
Zusammenarbeit		Eng mit einem anderen Team zusammenarbeiten Das Conway'sche Gesetz besagt, dass mit zunehmender Zusammenarbeit auch die Verantwortlichkeiten und die Architektur der Lösung immer mehr vermischt werden. Vorteile: schnelle Innovation und Entdeckung, weniger Übergaben Nachteile: umfangreiche, geteilte Verantwortlichkeiten für jedes Team, mehr Details/Kontext zwischen den Teams erforderlich, was zu einer höheren kognitiven Belastung führt. Ein Team sollte nicht mit mehr als einem Team gleichzeitig zusammenarbeiten
X-as-a-Service		Etwas mit minimaler Zusammenarbeit konsumieren oder bereitstellen Geeignet für Teams, die eine Code-Bibliothek, Komponente, API oder Plattform benötigen, die ohne großen Aufwand "einfach funktioniert". Vorteile: klare Eigentumsverhältnisse mit eindeutigen Verantwortungsgrenzen Nachteile: Gefahr eines verminderten Flusses, wenn die Begrenzung nicht wirksam ist Ein Team sollte davon ausgehen, dass es diese Interaktion mit vielen anderen Teams gleichzeitig nutzen wird, egal ob es einen Dienst in Anspruch nimmt oder anbietet
Erleichtern Sie		Einem anderen Team helfen (oder von ihm geholfen werden), Hindernisse zu beseitigen Vorteile: Aufhebung der Blockade von Teams, die auf den Strom ausgerichtet sind, um den Fluss zu erhöhen Nachteile: erfordert erfahrene Mitarbeiter, die nicht am "Aufbau" oder "Betrieb" arbeiten Ein Team sollte davon ausgehen, dass es diese Interaktion mit einer kleinen Anzahl von Teams gleichzeitig nutzen wird, unabhängig davon, ob es sie konsumiert oder die Moderation übernimmt.

Unternehmen sollten bereit sein, sich regelmäßig anzupassen, indem sie sich organisatorisch abtasten: Die Identifizierung von Kommunikationslinien, die für die Wertschöpfung erforderlich sind, außerhalb des aktuellen Organisationsdesigns wird als ein Signal dafür angesehen, dass das aktuelle Design nicht mehr optimal ist.

Mehr zu diesem Buch finden Sie auf seiner Website: Team Topologies Website

Team-Topologien für Daten- und KI-Teams

Die Theorie von Team Topologies konzentriert sich auf die Entwicklung von Softwaresystemen. Obwohl es sicherlich Ähnlichkeiten zwischen der Softwareentwicklung und der Entwicklung von Daten und KI-Produkten gibt, ist letztere aufgrund des explorativen und forschenden Charakters dieser Projekte viel weniger vorhersehbar. Diese unterschiedliche Dynamik und die begrenzte Verfügbarkeit von Datenexperten erfordern unterschiedliche Teamzusammenstellungen. Lassen Sie uns einige Aspekte der Daten- und KI-Organisationsstruktur anhand der Prinzipien und der Theorie von Team Topologies diskutieren.

Der Lebenszyklus einer KI-Lösung

Von der Ideenfindung bis zur Produktion durchläuft eine KI-Lösung verschiedene Phasen. Insbesondere KI-Anwendungsfälle, die auf noch nie zuvor genutzten Datenquellen basieren, erfordern einen beträchtlichen Aufwand an Datenexploration, -interpretation und -vorbereitung, bevor Experimente auf der Suche nach der Vorhersagekraft der Daten durchgeführt werden können. Zu jedem Zeitpunkt dieses F&E-Prozesses kann das gesamte gesammelte Wissen zu dem Schluss führen, dass es einfach nicht funktionieren wird oder dass wir die Ziele des Projekts an realistischere Ziele anpassen sollten.

Der KI-Anwendungsfall kann z.B. ein kleines einzelnes Feature innerhalb eines größeren Softwareprojekts sein, das von Millionen von Kunden genutzt wird, oder eine einmalige, auf vielen Datenquellen basierende Entscheidungshilfe für ein kleines Managementteam.

Diese Aspekte (d.h. Lebenszyklusphasen und Anwendungsfalltypen) haben großen Einfluss auf die Art und den Umfang der Kommunikation, die während des gesamten Lebenszyklus der KI-Lösung erforderlich ist. Und da sie die Kommunikation beeinflussen, bestimmen sie auch die optimale Organisationsstruktur gemäß der Team Topologies' Theory.

Forschungsphase		In der anfänglichen Forschungsphase des Projekts wird viel Kommunikation mit Fachleuten aus der Wirtschaft erforderlich sein. Um zu verhindern, dass das Team den Interaktionsmodus für die Zusammenarbeit (möglicherweise mit vielen Teams) aufrechterhalten muss, ist es sinnvoll, ein funktionsübergreifendes (KI & Wirtschaft) Team zu bilden, das auf den Strom ausgerichtet ist.
Entwicklungsphase		In dem Maße, in dem sich gangbare Wege zur Erreichung der Ziele abzeichnen, nimmt der Kommunikationsbedarf mit den Fachleuten des Geschäftsbereichs ab und der KI-Teil des Teams könnte sich zu einem komplizierten Subsystemteam entwickeln.
Produktionsphase		Noch weiter unten im Lebenszyklus, wenn die KI-Lösung in Produktion ist, kann das Produkt an ein Plattformteam übergeben und von diesem verwaltet werden, das die Interaktion mit den Stakeholdern im As-a-Service-Modus nutzt.

Welche Topologie am besten geeignet ist, hängt von der Art des KI-Anwendungsfalls ab. Wenn weniger Sondierungsarbeit erforderlich ist, weil bekannte Datensätze verwendet werden und die Ziele fest und klar sind, können die KI-Experten von Anfang an als kompliziertes Subsystemteam starten und den Interaktionsmodus der Zusammenarbeit mit den Geschäftsanwendern nutzen.

Daten-as-a-Service

Bevor Daten in BI- oder KI-Anwendungen verwendet werden können, müssen die meisten Daten bereinigt, umgewandelt, angereichert, dokumentiert, auf ihre Qualität hin überprüft werden usw. Dies ist ein sehr zeitaufwändiger Prozess, der nur durchgeführt werden sollte, wenn mindestens eine Anwendung die Datenquelle tatsächlich benötigt.

Eine neu aufbereitete Datenquelle kann in einer einzigen Anwendung verwendet werden, aber vorzugsweise dient dieser Datensatz später vielen Anwendungen. Dies erfordert eine gut durchdachte Datenarchitektur, d.h. ein angemessenes Design des Datensystems, das der Organisationsstruktur nach dem Conway'schen Gesetz entsprechen sollte.

Neue Daten	Vorhandene Daten

Wenn neue Daten verwendet werden, ist der Lebenszyklus dieser Datenquelle dem Lebenszyklus von KI-Lösungen recht ähnlich, nur dass die Planung und das Ergebnis ein wenig vorhersehbarer sind. Für die Dateningenieure ist es sinnvoll, sich für den Zeitraum, der notwendig ist, um die Analysten und Wissenschaftler bei der Erkundung und Aufbereitung der Daten zu unterstützen, einem auf den Datenstrom ausgerichteten Team anzuschließen, was viel Kommunikation erfordert.

Nach der Vorbereitungsphase kann ein Plattformteam, das Daten-as-a-Service für mehrere andere Teams bereitstellt, besser geeignet sein.

Daten & KI Reifegrad

Ein Aspekt, der sich stark auf den Umfang der erforderlichen Kommunikation auswirkt, ist der Reifegrad der Mitarbeiter im Unternehmen, wenn es um Daten und KI geht. Wenn die Daten- und KI-Kenntnisse in den Geschäftsbereichen begrenzt sind, werden Datenexperten viel Zeit damit verbringen, den Geschäftsleuten die grundlegenden Konzepte zu erklären. Umgekehrt gilt das Gleiche: Datenexperten, die nur über begrenzte Kenntnisse des Geschäftsbereichs verfügen, benötigen eine gründliche Einführung, um mit den vorliegenden Daten etwas anfangen zu können.

Wenn die Seniorität in der Gruppe der Datenwissenschaftler oder Dateningenieure begrenzt ist, wird außerdem viel Zeit auf Pionierarbeit, die Neuerfindung des Rades, das Ausprobieren von Methoden, die Förderung effektiver Arbeitsweisen und dokumentierter Best Practices usw. verwendet, was durch die gemeinsame Kommunikation und Interaktion bei der Arbeit beschleunigt wird. Selbst wenn Sie in der Lage sind, Mitarbeiter nach ihrem Dienstalter einzustellen, muss der Rest des Teams noch geschult werden, was wiederum Zeit und Kommunikation erfordert. Der Reifegrad wirkt sich also sehr stark auf den Umfang der erforderlichen Kommunikation aus, was sich wiederum auf das Organisationsdesign auswirkt, wie in Team Topologies beschrieben.

Ein Gestaltungsprinzip zielt auf die Autonomie der Teams ab, oder anders gesagt, auf eine begrenzte Kommunikation zwischen den Teams. Dies fördert funktionsübergreifende Teams, in denen sich Daten-/AI- und Geschäftsexperten zusammentun und sich gegenseitig in ihren Domänen ausbilden. Gleichzeitig fördert dieses Prinzip die Bildung von Teams aus (angehenden) Datenexperten, da die Entwicklung und der Austausch von Wissen und Fähigkeiten auch viel Kommunikation und gemeinsame Zeit erfordert, insbesondere wenn die Autonomie der Datenjunioren noch zu begrenzt ist, um allein in einem auf den Strom ausgerichteten Team zu arbeiten.

Das Autonomieprinzip führt zu widersprüchlichen Argumenten bezüglich der optimalen Topologie. Einzelne Datenexperten sollten ihre Zeit sowohl im funktionsübergreifenden Team als auch im Enabling Team verbringen, da beide Lernmöglichkeiten bieten, die für ihre berufliche Entwicklung wichtig sind. Die beste Wahl bei der Teamgestaltung in der Praxis hängt von den spezifischen Reifegraden und der Größe des Unternehmens ab.

Begrenzte Anzahl von Datenexperten

Wie bereits erwähnt, geht man davon aus, dass jedes Unternehmen an die Grenzen seines Budgets stößt, wenn es darum geht, jedem Produktteam und jedem Geschäftsbereich, der dies benötigt, Vollzeitkapazitäten für Data Engineering und Data Science zur Verfügung zu stellen. Gleichzeitig benötigen andere Produktteams und Geschäftsbereiche die Vollzeitkapazitäten vielleicht nur für ein paar Monate, so dass sie keine eigenen Datenexperten einstellen können. Eine statische Organisationsstruktur wird also nicht den Bedürfnissen aller Teams und Bereiche im Unternehmen gerecht.

Fazit

Meiner Meinung nach liegt der große Vorteil der Verwendung der Theorie der Teamtopologien für die organisatorische Gestaltung von Daten- und KI-Teams darin, dass sie uns die (sowohl verbale als auch visuelle) Sprache und die Definitionen an die Hand gibt, um sie effektiver und spezifischer zu diskutieren. Bei der Gestaltung der Organisationsstruktur erleichtert es uns, uns zunächst auf eine Reihe von Ausgangspunkten und Gestaltungsprinzipien zu einigen, bevor wir zu Lösungen kommen.

Unter Berücksichtigung aller oben genannten Überlegungen wird es nicht nur ein einziges festes Organisationsdesign geben. Wahrscheinlich ist ein dynamischeres, hybrides Design vorzuziehen, wobei dynamisch bedeutet, dass die Datenexperten von Zeit zu Zeit zwischen Teams (Topologien) wechseln werden. Wie das spezifische Organisationsdesign aussehen wird, hängt unter anderem von der Reife und Größe des Unternehmens, der Anzahl der Datenexperten und der Komplexität der Anwendungsfälle ab.

Das sich daraus ergebende Design muss sich nicht vollständig in einem Organigramm widerspiegeln. Um die Team-Topologie für Datenwissenschaftler zu erleichtern, wie sie für die Weiterentwicklung von Expertenwissen und -fähigkeiten erforderlich ist, könnte eine Community of Practice anstelle eines "physischen Teams" für eine Organisation sehr gut funktionieren. Für ein Unternehmen, das in Bezug auf Daten und KI weniger ausgereift ist, könnte ein physisches Team von Datenexperten die bessere Option sein, das in den frühen Phasen des KI-Lebenszyklus in Teilzeit an Produktteams für die Entwicklung von Daten und KI-Produkten verteilt wird.

In einem Folgeblog werde ich drei Fälle von Unternehmen unterschiedlicher Größe und Reife erörtern und die Gestaltungsprinzipien von Team Topologies nutzen, um mögliche Organisationsformen für Data & AI zu untersuchen.

Möchten Sie das organisatorische Design für Daten- und KI-Teams speziell für Ihr Unternehmen besprechen? Bitte kontaktieren Sie uns! Unser KI-Reifegrad-Scan kann zur Bewertung bestimmter Aspekte Ihres Unternehmens verwendet werden. Sie erhalten Empfehlungen, um Ihr Unternehmen auf die nächste Stufe der KI-Reife zu bringen und können diese als Input für die KI-Strategie Ihres Unternehmens nutzen.