Data Science zum Erfolg führen – Machine Learning Operations (ML Ops) in Praxis und Forschung

00:00:09: Unbekannt: Zielführung starten - der Management-Podcast von CTcon.

00:00:22: Unbekannt: Herzlich willkommen! Ich bin Christian Bungenstock, Partner bei CTcon in Düsseldorf. Als Gastgeber von "Zielführung starten" nehme ich Sie heute mit auf eine Tour zu den Erfolgsfaktoren tiefgreifender, erfolgreicher und gut integrierter Data-Science-Teams. Im Gespräch erwarten wir Professor Dr. Timo Schirk und Niklas Hartmann. Timo Schirk ist Professor für Data Science und Machine Learning an der Hochschule Darmstadt.

00:00:46: Unbekannt: Timo hat viel Erfahrung im Aufbau von Data-Science-Teams und war vor seiner Hochschulkarriere unter anderem bei der DB Cargo AG und der Schott AG aktiv. Timo kennt Niklas aus gemeinsamer Projektarbeit. Niklas Hartmann ist Principal bei CTcon in Frankfurt. Er berät seit vielen Jahren große Konzerne, vor allem aus Logistik, Transport und Verkehr. Niklas trägt Verantwortung in unserem Kompetenzcenter datengetriebener Steuerung.

00:01:12: Unbekannt: Die Transformation zu einer digitalen Unternehmenssteuerung ist sein Leitstern. Beide besprechen, wie Data-Science-Teams in großen Organisationen mit Erfolg arbeiten. Dabei geht es auch darum, welche Unternehmensfunktionen sie am besten begleiten.

00:01:34: Unbekannt: Hallo Timo, schön, dass du zu Gast bist bei "Zielführung starten". Vielen Dank für die Einladung. Freue mich, hier zu sein. Sehr, sehr gerne. Ich freue mich, mit dir zu reden, denn CTcon, das ist ja ein Mix aus dem Besten von Wissenschaft und Praxis. Ich glaube, beide Stränge können wir sehr, sehr gut aufnehmen. Wir haben uns, wie schon im Intro angekündigt, in der Praxis kennengelernt, im gemeinsamen Klientenprojekt.

00:01:57: Unbekannt: Das ist ehrlicherweise ein paar Jahre her und wir haben auch damals schon rund um AI und Advanced-Analytics-Themen zusammengearbeitet. Heute bist du in der Forschung und vielleicht können wir die Zeit einfach mal ein bisschen Revue passieren lassen. Was ist denn aus deiner Sicht in dem Themenumfeld rund um Advanced Analytics und Co. passiert? Was waren die wesentlichen Trends und wo stehen wir heute?

00:02:21: Unbekannt: Ja, ich glaube, was sich sehr stark verändert hat, ist die Professionalisierung von dem ganzen Thema. Als wir uns kennengelernt haben, als wir die ersten Schritte zusammen gemacht haben, war das noch sehr in den Kinderschuhen. Also ich bin da hingekommen, um so ein Analytics-Team von von der Pike auf mit aufzubauen und da waren wir noch sehr im Forschungsmodus unterwegs, um zu verstehen, wie das Ganze überhaupt funktioniert, welche Technik dazu passt und welche Themen man überhaupt damit angehen sollte.

00:02:50: Unbekannt: Und was ich jetzt gesehen habe in den letzten Jahren ist, dass sich das Thema unglaublich professionalisiert hat, auch immer mehr speziell dafür qualifizierte Mitarbeiter dazugekommen sind. Also Leute, die extra dafür ausgebildet sind und ganz andere Sachen mitbringen. Also Stichwort Data Engineer, Stichwort Data Scientist. Siehst du da auch eine methodische Entwicklung? Also sind die Themen andere geworden oder gilt das eigentlich gleichermaßen für alle Methoden, die in dem Kontext zum Einsatz kommen?

00:03:19: Unbekannt: Ja, also von den Methoden hat sich mit Sicherheit einiges geändert. Das ganze Stichwort neuronale Netze und KI, das hat einen unglaublichen Schub reingebracht und auch ganz andere Kraft von den Algorithmen. Viel komplexere Probleme, die man damit lösen kann. Ja, und das andere Stichwort, das du angesprochen hast, also eine ganz starke Differenzierung von den Rollen. Früher gab es den Data Analyst, das sich so langsam Richtung Data Scientist entwickelt hat.

00:03:43: Unbekannt: Inzwischen hat man ein komplettes Portfolio von Rollen, was man ausfüllen muss in einem Data-Science-Team, also angefangen von einem Data Engineer, der sich hauptsächlich damit beschäftigt, wie man die ganzen Daten aufbereitet, bis zu dem Modellierer, der sich hauptsächlich um die Modelle kümmert. Also ein großes Spektrum an Rollen. Großes Spektrum an Methoden. Das stellt ja durchaus Herausforderungen dar für die Unternehmen, die sich damit auseinandersetzen, diese Kompetenzen zu entwickeln.

00:04:11: Unbekannt: Verantwortung auch für diese Menschen und natürlich auch für die Methoden, Entwicklungen zu verorten. Und ich glaube, das ist ein schöner Übergang zu deiner Forschung und deinem aktuellen Thema. Vielleicht kannst du uns kurz einführen, woran du eigentlich forschst. Genau, jetzt so zwei Babys, die ich versuche voranzutreiben. Das eine ist eine Methode, das ist topologische Datenanalyse. Da geht es darum, wie man Fußabdrücke quasi generiert aus Daten und damit vor allen Dingen Probleme lösen kann, wo man keine Labels an die Daten dranhängt.

00:04:39: Unbekannt: Aber ich glaube, das ist nicht so das Thema für uns heute. Ja, das ist sehr technisch und sehr experimentell. Und das andere Thema, an dem ich super interessiert bin, ist der Bereich MLOps. MLOps steht für Machine Learning Operations. Da geht es vor allen Dingen darum, wie ich, wenn ich durch den ganzen Prozess durch bin, wenn ich ein Modell fertig entwickelt habe, wie ich das danach vernünftig in den Betrieb kriege und auch sicherstelle, dass ich skalieren kann.

00:05:04: Unbekannt: Als Unternehmen, weil wenn ich für jedes neue Modell, was ich entwickelt habe, einen neuen Mitarbeiter einstellen muss, der sich darum kümmert und das regelmäßig schmiert und ölt, ja, dann skaliert das Ganze nicht. Okay, das heißt also, wenn ich das mal übersetze: Üblicherweise, wenn ich das ein bisschen überspitzen darf, kommen die neuen Trendthemen in Form von Leuchttürmen, Schnellbooten, Piloten in die Unternehmen und man sagt: "Mensch, wir müssen uns mit der Methode mal auseinandersetzen.

00:05:34: Unbekannt: Und da findet sich doch bestimmt irgendein Use Case, den man mal machen könnte." Und du beschäftigst dich eigentlich dann hinten raus mit der Frage: Wenn dieses Schnellboot relevant war, wie kriege ich das jetzt in der Organisation verankert und in den laufenden Betrieb, dass die Daten immer wieder bereitgestellt werden, dass die Analysen immer wieder durchgeführt werden und das eben auch sozusagen in einer effizienten Organisation stattfindet?

00:05:59: Unbekannt: Ist das in etwa die Pipeline des Themas oder geht es noch breiter? Ja, ein bisschen breiter wäre besser. Weil wenn man erst dann anfängt zu gucken, dann ist es eigentlich schon zu spät. Vielleicht ist ein ganz klassisches Beispiel, wenn wir so mit der Zeit anfangen, wo wir uns kennengelernt haben, das war so ein Analytics-Team , was wir wirklich von der grünen Wiese aufgebaut haben.

00:06:19: Unbekannt: Wir haben da unser, genau wie du es beschrieben hast, wir haben einen Use Case gesucht, haben das umgesetzt. Danach war eigentlich kein Platz mehr für neue Themen. Damit war ein Thema erfolgreich abgeschlossen und das kam beim Kunden auch gut an, das wollte er weiter benutzen. Ja und dann haben wir als Analytics-Team dieses Thema auch betrieben, haben uns um den ganzen Betrieb von der Lösung gekümmert.

00:06:40: Unbekannt: Den ganzen Service gemacht und da war keinerlei Kapazität mehr frei für neue Themen. Verstehe. Okay. Das heißt, wenn wir das so ein bisschen trennen, vielleicht in diese beiden Phasen, so wie du es jetzt angedeutet hast, da gibt es so eine Art Fokus-Konzept-Phase oder hat man auch schon Pilot gesagt oder Schnellboot und es gibt eine spätere Implementierungs und Betriebsphase?

00:07:03: Unbekannt: Ich würde mal ganz vorne anfangen, wenn jetzt heute ein interner Kunde kommt und sagt, ich habe da eine Idee für ein Projekt. Gibt es eigentlich jemanden aus deiner Sicht, der sicherstellt, dass so ein Thema relevant ist? Was ist eigentlich Relevanz an der Stelle? Ja, das ist ein ganz wichtiger Punkt. Ja, ich glaube, mit eine von den entscheidenden Schnittstellen bei so einem erfolgreichen Projekt ist gerade die Anfangsphase, wenn man die Idee präzisiert. Weil Ideen für Data-Science-Anwendungen gibt es im Unternehmen ganz, ganz viele.

00:07:38: Unbekannt: Und die entscheidende Phase, wo ganz viel über den Erfolg von einem Projekt entschieden wird, ist die erste Phase, wo man versucht, das zu präzisieren. Eine ganz wichtige Sache dabei ist, dass man eigentlich da zwei Größen hat, die man miteinander verbinden muss. Was man als arbeitender Data Scientist im Kopf hat, ist immer die Prognosegüte von dem Modell.

00:07:59: Unbekannt: Wie gut treffe ich denn meine Trainingsdaten? Misst man typischerweise in Prozent. Ich will eine möglichst hohe Prozentzahl erreichen von Genauigkeit. Und umgekehrt für das Unternehmen ist ja eigentlich total egal, wie gut das Modell ist, sondern da ist entscheidend, dass ich irgendeine Steuerungsgröße habe und die treffe. Und ganz entscheidend für den Erfolg von einem Projekt, dass man versucht, diese beiden Sachen zusammenzubringen.

00:08:23: Unbekannt: Also am besten hat man irgendeine Übersetzung, dass ich weiß, wenn ich die Güte in meinem Modell habe, dann hat das auch folgende Auswirkungen auf meinen Unternehmenserfolg. Da bin ich komplett bei dir. Allerdings würde ich auch sagen, tatsächlich in der Praxis so ganz konsistent zu beobachten ist das noch nicht. Oftmals hat man den Eindruck, die Hype-Themen, die kriegen einen ganz einfachen Weg durch die Tür.

00:08:51: Unbekannt: Aber es gibt eigentlich niemanden, der so dreimal "warum?" fragt, wenn so ein Thema kommt. Zu sagen, aus Sicht der Unternehmensstrategie, die ja beschreiben soll, wie das Unternehmen erfolgreich bleibt oder wird, sozusagen konsequent ableitet, dass ein Beitrag in Richtung dieser Strategieumsetzung entstehen kann und dass man sich nicht beliebig irgendein Thema schnappt, sondern tatsächlich einen Plan hat, wie das eben auf die strategischen Ziele des Unternehmens einzahlen kann.

00:09:19: Unbekannt: Hast du andere Erfahrungen gemacht? Nee, das deckt sich hundert Prozent mit meiner Erfahrung. Also da gibt es immer die Hype-Themen, die gerade gepusht werden müssen und da vergisst man oft, was das für einen Impact hat auf das Unternehmen. Und eine andere Sache, die ganz oft vergessen wird, sind auch die Endnutzer hinten dran. Oft werden die relevanten Themen nicht von den Leuten gesetzt, die die Lösung dann benutzen, sondern von jemandem, der einen bisschen größeren Blick drauf hat.

00:09:46: Unbekannt: Und wenn man vergisst, diese Leute miteinzubeziehen, dann entwickelt man manchmal an der Lösung vorbei. Dann gibt es immer das eine lustige Beispiel, da werden Tablets eingeführt für die Leute, die Instandhaltung machen, und die konnten die Tablets gar nicht bedienen, weil sie dicke Handschuhe anhaben. Und das wichtige Stichwort, was man da immer reinbringen muss, ist - viele gute Ideen aus dem Design Thinking, die helfen auch bei Data-Science-Projekten.

00:10:11: Unbekannt: Gerade in der Anfangsphase, wenn es darum geht, die Idee zu präzisieren und den Endnutzer mitzunehmen. Und das sind die Punkte, die schon in der Anfangsphase sicherstellen, dass mein Projekt hinten raus ein Erfolg wird. Weil, die Quote ist immer noch unglaublich schlecht; wenn man so den Zahlen glaubt, die Gartner und Co. veröffentlichen, ist die Quote immer noch so bei 80 Prozent Scheitern, also 80 Prozent aller Data-Science-Projekte schaffen es nicht über den Leuchtturmstatus hinaus.

00:10:39: Unbekannt: Na ja, nicht zu unterschätzen der Ressourcenaufwand, der dann dabei getrieben wird. Wobei man natürlich auch sagen muss: Experimentieren soll ja erlaubt sein. Die Organisation lernt methodisch, die Organisation lernt zumindest: So hat's nicht funktioniert, wir müssen einen anderen Weg gehen. Die Frage ist natürlich immer, wie konsequent verketten sich dann die Cases? Also wenn man eine strategische Zielvorgabe hat und sagt, ich habe da ein bestimmtes Thema, das ich unbedingt umsetzen muss als Unternehmen, und ich probiere es auf dem ersten Weg vielleicht mit einem Data-Science-Projekt und ich schaff's nicht, lege ich es dann zur Seite und mache irgendwas anderes oder versuche ich halt mit einer anderen Methode, das gleiche Ziel zu erreichen?

00:11:15: Unbekannt: Dann ist natürlich die Frage: Wie zähle ich das jetzt in der Statistik? Aber durchaus eine Perspektive, in der Scheitern ja auch erlaubt sein muss, sozusagen. Was ich vorhin noch mal spannend fand, war jetzt der Aspekt: Es gibt eigentlich niemanden, der challenged, wenn so ein Case kommt. Das heißt, deine Erfahrung zeigt auch, da kommt ein Fachbereich und bietet eine Anfrage an ein Analytics-Team.

00:11:38: Unbekannt: Und eigentlich ist nur entscheidend, ob das Analytics-Team gerade Kapazität hat und wenn da Kapazität ist, dann nimmt man sich dem an. Es gibt aber keine neutrale Instanz, die sagt: "So, wir haben viele Anfragen, wir haben viele Ideen, wir challengen die auch gegeneinander und entscheiden halt über das 'Relevanteste', und das wird als allererstes ausprobiert." Ja, aber ich glaube, da gibt's auch Unternehmen, die da ganz gute Ansätze haben.

00:12:02: Unbekannt: Was ich zum Beispiel bei einem Unternehmen mal gesehen habe, ist, dass die wie so eine Art Beauty Contest haben für Data-Science-Projekte und dass dort Entscheider sitzen, die so wie bei "Höhle der Löwen" über Venture Capital verfügen und dann entscheiden, welche von diesen Data-Science-Themen tatsächlich, also mit Geld versorgt wird. Okay, das ist auf jeden Fall eine kreative Idee.

00:12:25: Unbekannt: Klingt unternehmerisch. Weißt du, ob es dafür einen Kriterienkatalog gab? Oder war das dann tatsächlich unternehmerische Entscheidung des Gremiums, das dort vor Ort war? Also ich hab bei dem Unternehmen nicht gearbeitet, deswegen weiß ich nicht genau, wie die das gemacht haben; was man so aus der Literatur kennt, sind eigentlich so drei verschiedene Kriterien, nach denen man das beurteilt. Das eine ist: Bringt mir das als Unternehmen Erfahrung? Kriege ich damit, lerne ich damit irgendwas? Und das andere ist, ob damit neue Geschäftsfelder aufgemacht werden.

00:12:54: Unbekannt: Also: Generiere ich mir damit neues Einkommen? Und dritter Punkt ist immer: "Werde ich dadurch effizienter?" Also kann ich vielleicht damit Prozesse, die im Moment kostenintensiv sind, günstiger machen? Und das sind so drei Eckpunkte, wo man sich dran entlanghangeln kann, um auch wirklich objektiv zu beurteilen: Bringt mir der Case was oder laufe ich da jetzt einem Hype nach?

00:13:19: Unbekannt: Jetzt gibt es da eigentlich eine Rolle im Unternehmen, die traditionell für die Rationalitätssicherung verantwortlich ist, die nennt man Controller. Die ist uns als Unternehmenssteuerer durchaus natürlich nah. Müsste man jetzt nicht den Appell hier senden, zu sagen: "Mensch, in dieses Gremium und an den Tisch gehört der Controller fest mit dran? Als neutraler Sparringspartner, der diese Kriterien immer wieder faktenbasiert in der Runde sozusagen präsentiert und für eine rationale Entscheidung sorgt?"

00:13:49: Unbekannt: Aus meiner Sicht auf jeden Fall. Und wo ich den auch super wichtig finde, ist im Nachhalten von diesen Zahlen. Weil, einen Business Case zu generieren und da Zahlen hinzuschreiben, geht relativ schnell. Also muss man das Commitment einholen von den Leuten, die die Zahlen mitbringen, aber dann wirklich nachzuverfolgen, ob das auch so kommt, zwei Jahre später, ist noch mal eine ganz andere Hausnummer.

00:14:15: Unbekannt: Ja, deswegen, also aus meiner Sicht gehört auf jeden Fall ein Controller mit dazu. Super, dann haben wir schon mal einen Erfolgsfaktor für die erfolgreiche Auswahl von PoCs sozusagen identifiziert. Und jetzt hast du eigentlich auch direkt in dem gleichen Atemzug gesagt: "Na ja, es ist also auch ein Erfolgsfaktor für den nachhaltigen Übergang in die Organisation, auch entsprechend den Erfolg langfristig zu sichern und auch die Relevanz dadurch sozusagen immer wieder zu validieren."

00:14:41: Unbekannt: Welche Erfolgsfaktoren gibt es denn in deinem zweiten Forschungsfeld MLOps an der Stelle aus deiner Sicht noch, um jetzt den Übergang vom PoC in den Betrieb zu sichern und eben auch zu skalieren? Da sind neben dem Controller, der super wichtig ist, natürlich die Leute aus der IT wichtig, weil die haben jahrelange Erfahrung damit, wie man so was genau skaliert.

00:15:02: Unbekannt: Da werden nicht für jedes neue System, was man einführt, ganz viele Mitarbeiter eingestellt, sondern man hat feste Prozesse und versucht, sich anhand dieser Prozesse entlang zu hangeln, um das Ganze auch so hinzukriegen, dass es skaliert. Und an viele von diesen Systemen kann man sich mit einer Data-Science-Lösung dranhängen. Also, um ein ganz einfaches Beispiel dafür zu geben: Eigentlich jedes Unternehmen hat irgendeine Hotline, wo ich anrufen kann, irgendeinen First Level Support, der für einen da ist, wenn was beim Rechner hängt.

00:15:33: Unbekannt: Wenn man ein Machine Learning-Modell an den Kunden bringt, hat man genau dieses gleiche Problem. Irgendwo bei dem hängt das, ein Knopf funktioniert nicht. Und wenn alle diese Anrufe sofort beim Data-Science-Team landen, bindet das viel zu viel Kapazität und auch viel zu viel teure Kapazität. Das ist jetzt also wirklich das erste und einfachste Beispiel, wo es Sinn macht, die beiden Sachen zu verdrahten.

00:15:54: Unbekannt: Also so ein First Level Support auch für Machine Learning-Modelle, wenn die irgendwie Richtung Kunde unterwegs sind, macht super viel Sinn. Und sind denn aus deiner Erfahrung die Fachbereiche bereit dazu, insoweit die Verantwortung auch abzugeben, zumindest in den technischen Teilen der Betriebsführung? Das hängt unglaublich daran, wo man so ein Data-Science-Team aufhängt. Also so wie ich das kenne, gibt es drei verschiedene Positionen, wo man so ein Data-Science-Team hinhängen kann, organisatorisch.

00:16:23: Unbekannt: Das eine ist in den Fachbereich selber, man kann das als Einheit innerhalb des Controllings machen, habe ich auch schon gesehen, und die dritte Möglichkeit ist, das innerhalb von der IT zu hängen. Und je nachdem wo man sich am Anfang entschieden hat, sein Data-Science-Team hinzuhängen, gibt es ganz unterschiedliche Herausforderungen, wie man das nachher integriert. Also eine Möglichkeit ist natürlich, das von vornherein in die IT zu hängen.

00:16:48: Unbekannt: Dann hat man diese Verzahnung in die IT hinten raus eigentlich super sichergestellt. Auf der anderen Seite ist ein Data-Science-Projekt kein IT-Projekt. Birgt ein viel größeres Risiko, viel größeres Potenzial, zu scheitern. Und da ist oft in der IT ein anderer Gedanke dahinter. Wenn ich da ein Projekt starte, dann soll das bitte auch Erfolg haben. Und gerade in der starken, experimentellen Phase am Anfang.

00:17:15: Unbekannt: Von Data-Science-Projekten, passen da oft die Prozesse überhaupt nicht aufeinander. Also das heißt eigentlich der gute Kompromiss, jetzt nicht überparteilich sein, aber tatsächlich könnte ein guter Kompromiss da wieder im Controlling liegen, weil das ist eine neutrale Instanz. Sie ist eigentlich traditionell eben mit der Unterstützung der Entscheidungsfindung betraut. Das umfasst für mich ja eben auch, zu forschen und das Verständnis zu erweitern über die Zusammenhänge im Unternehmen und zu sagen: "Wir sind fachlich in der Lage, sozusagen allen Fachbereichen eine inhaltliche Plattform zu bieten, weil hier die Fäden zusammenlaufen auf einer Informations- und Datenseite.

00:17:52: Unbekannt: Aber wir spielen natürlich den Betrieb technisch gesehen gerne ab." Dann hätte man den Vorteil, technisch zu skalieren in der IT und auf der anderen Seite den Moderationsprozess, über den wir auch eingangs gesprochen haben, zu sagen: "Gibt es auch Abwägungen zwischen Fachbereichen? Es kann nicht hier einfach jetzt jeder 'machen, was er will', sondern wir stellen auch sicher, dass eben relevante Themen als erstes bearbeitet werden.

00:18:14: Unbekannt: Und wir verbinden die mit einem guten Messkonzept und wir verknüpfen die zur Strategie" - im Controlling am besten gewährleistet sein könnte? Ja, man muss halt diese Schnittstelle in die IT gut hinkriegen. Das ist ein Punkt, wo es Potenzial für Reibung gibt. Also ich glaube, so richtig die optimale Lösung gibt's aus meiner Sicht nicht. Es gibt ja auch dieses Lab-Modell, wo ich einfach ein Data-Science-Team komplett auslagere.

00:18:35: Unbekannt: Also am besten in ein komplett eigenes Gebäude, was vielleicht außerhalb ist sogar von meinem Betriebsgelände. Da gibt es auch meistens immer mehr so'n bisschen Cargo-Kult, also viele bunte Möbel und Tischkicker und Obst auf ganz vielen Tischen. Das ist natürlich super für diese Phase, wo man experimentieren will, kreative Lösungen mitbringen will. Aber diese beiden anderen Punkte, "welchen Impact hat das für mein Unternehmen?" und "wie gut ist das verdrahtet mit den Zielen von meinem Unternehmen?" und "wie kriege ich die Integration mit der IT hin?"

00:19:07: Unbekannt: Gerade diese beiden Punkte sind sind da dann oft ein Schwachpunkt. Also ich glaube, so richtig die optimale Lösung gibt es aus meiner Sicht nicht. Jede hat ihre eigenen Nachteile und man muss halt gucken, was zu dem Unternehmen am besten passt. Jetzt hast du eigentlich noch mal eine neue Perspektive aufgemacht auf das Stichwort Erfolg. Und ich glaube, wir haben hier ein ganzes Spektrum in dem Gespräch schon eröffnet in den Fragen von: Wer guckt eigentlich wie auf Erfolg?

00:19:32: Unbekannt: Also du sagtest vorhin mal, na ja, der Data Scientist, der möchte erst mal eine hohe Modellgüte haben, eine hohe Prognosegüte erreichen in dem, was er tut. Der guckt da methodisch drauf. Dann haben wir jetzt drüber gesprochen, dass das Thema erfolgswirksam sein sollte, also irgendwie an relevante erfolgskritische Themen des Unternehmens angelehnt und nicht nur an irgendwie Hype und Trend einer bestimmten Methodik.

00:19:55: Unbekannt: Dann haben wir drüber gesprochen, dass es skalieren sollte in der IT und eben auch kostenoptimal langfristig eingesetzt werden kann. Das führt uns ja zu der Frage: Gibt es in dieser Landschaft, in diesem Spektrum eigentlich schon etablierte Messgrößen und eine klare Definition von dem, was den Erfolg hier ausmacht? Hast du dazu aus deiner auch Beratungs- und Trainingspraxis Impulse? Ja, sogar in der gängigen Literatur, wenn man sich anschaut, was sind so die größten Risikofaktoren für Data-Science-Projekte, taucht eigentlich immer wieder genau dieser Punkt auf.

00:20:30: Unbekannt: Es gibt aktuell keine guten Kennzahlen, wie man Erfolg von einem Data-Science-Team misst. Und welche Incentivierung bietet das, je nachdem, wie ich es messe? Zum Beispiel eine ganz einfache Messgröße für Erfolg von einem Data-Science-Team ist: erfolgreich umgesetzte Projekte pro Jahr. Aber das führt natürlich dazu, dass man viele kleine Projekte macht. Da hat man diese Kennzahl besser erfüllt und lässt vielleicht Sachen, die wirklich viel bringen würden.

00:21:00: Unbekannt: Fürs Unternehmen lässt man eher weg, weil's vielleicht ein größerer Fisch wäre. Also auch hier noch mal ein großes Themenfeld, wo die Unternehmenssteuerer gefragt sind, Guidance reinzubringen, vielleicht ein Stück weit, ohne die Kreativität zu bremsen natürlich und den methodischen Fortschritt, aber eben doch ein Stück weit zu sortieren: Was ist Erfolg für das Unternehmen und wie kriegen wir auch Messkonzepte etabliert für die Projekte, die da gemacht werden?

00:21:24: Unbekannt: Und wie messen wir hier einen Impact? Auch wenn das natürlich immer schwer ist, monokausal aus einem Ergebnis zurückzuleiten, wo jetzt die Impacts herkamen. Auf der anderen Seite - wir machen uns ja mit unserem Ansatz für datengetriebene Steuerung sehr stark dafür, zentral im Controlling Financials und Non-Financials viel, viel stärker zu verdichten, multidimensionale Datenmodelle aufzubauen und so eben auch einfach stärker als in der Vergangenheit, wo man vielleicht etwas finanzorientierter auch in der Datensicht im Controlling unterwegs war, Kausalzusammenhänge datengetrieben analysieren und erkennen zu können.

00:21:59: Unbekannt: Und vielleicht kann man auch damit dann einfach den nächsten Schritt gehen, eben darin, Zusammenhänge zu detektieren, mit Causal Analytics zu sagen: "Hey, Projekt, Wirksamkeit und der Effekt passen doch offensichtlich ganz gut zusammen!", um da auch die Rolle schon wieder zu unterstreichen, auch wenn hier nicht alle Wege immer automatisch ins Controlling führen sollen. Ja, es ist auch ein großes Paradox aus dem Bereich Data Science. Da geht es ja gerade darum, Daten zu analysieren und aus diesen Daten Mehrwert zu bringen.

00:22:31: Unbekannt: Und gerade die Data-Science-Teams selber wehren sich dagegen, dass man in irgendeiner Form objektive Kennzahlen hat, womit man den Erfolg von diesen Teams messen kann. Also viele KI-Projekte, Machine Learning-Projekte, da sehen sich die Entwickler davon, sehen das eher als Manufakturbetrieb und als einen unglaublich kreativen Prozess, ähnlich wie Wissenschaft, und wehren sich in dem Zuge dagegen, dass man irgendwelche Zahlen hat oder Daten, mit denen man Projekterfolg messen kann.

00:23:03: Unbekannt: Also der Data Science geht es darum, dass man andere Sachen analysiert, aber dass das Team an sich auch irgendwie mit Daten gemessen wird - da wehren sich eigentlich alle Teams gegen, und das ist so ein bisschen paradox in der Data Science. Ja, sehr spannend, denn das Thema Incentives, Incentivierung, Anreizgestaltung hattest du eben auch schon mal erwähnt, jetzt hast du eigentlich als Grund angeführt.

00:23:29: Unbekannt: Ja, da ist der freischaffende Künstler, der möchte diesen Blick in die Blackbox nicht zu sehr haben, damit die Kreativität nicht eingeschränkt wird. Glaubst du, dass man, wenn man jetzt Incentive wieder ganz hart versteht, dass man mit einer unternehmerischen finanziellen Incentivierung da dran was ändern könnte? Ja, ich denke schon. Ich glaube, das ist ein wesentlicher Punkt, wo man ansetzen kann. Also zum Beispiel kann man ein Data-Science-Team einfach danach messen, wie viele Business Cases die pro Jahr mitgebracht haben und was da an Wert generiert wurde.

00:24:00: Unbekannt: Die zweite Komponente, die da noch wesentlich mit reinspielt, ist auch die Kultur. Aber man muss auch an die Kultur in einem Data-Science-Team denken und da auch versuchen, das ein bisschen zu ändern, weg von dem freischaffenden Künstler. Was in der Literatur oft erwähnt wird, ist, dass man keine Moonshots machen soll, sondern mehr Laps around the Track. Also ein Data-Science-Projekt zu Ende bringen, sollte eigentlich irgendwann so einfach sein wie eine Runde auf der Tartanbahn laufen.

00:24:29: Unbekannt: Und dann muss man halt weg von dieser Kultur des freischaffenden Künstlers, der sich nicht auf die Tastatur gucken lassen möchte, sondern mehr Templates nutzen, schon vorgefertigte Modelle. Das macht natürlich viel weniger Spaß, weil man nicht diesen ganzen Spaß an dem Training hat. Mehr Routine, mehr Wiederholungen, mehr Industrialisierung der Methoden sozusagen. Verstehe. Ja, und da kommen wir zurück zu dem Punkt, den wir ganz am Anfang vom Gespräch hatten.

00:24:54: Unbekannt: Was sich verändert hat in den letzten zehn Jahren. Also die Pakete, die Tools, die man zur Verfügung hat, um Modelle zu entwickeln, sind unglaublich viel professioneller geworden und stabiler. Also es geht inzwischen viel, viel schneller, dass man ein Modell trainiert, sobald man einmal die Daten sauber gemacht hat. Dann bleibt ja die Frage, wie schaffen wir es, wirksam den Anreiz zu gestalten, der entweder extrinsisch motiviert, sich dem Impact stärker zu öffnen, dann gleichzeitig aber auch sozusagen den Menschen in der Data Science nicht die intrinsische Motivation zu nehmen und zu sagen, so, du hast diesen kreativen, forschenden Teil, in dem du als Pionier neue Methoden erstmals ins Unternehmen bringst, nicht nimmt und nur noch sozusagen Massenbetrieb macht.

00:25:40: Unbekannt: Vielleicht führt uns das auch noch mal zu dem organisatorischen Teil und dem Rollenteil. Du sagtest, die Rollen haben sich deutlich differenziert gegenüber früher. Jetzt könnte man ja auch wieder hier auf die Idee kommen zu sagen: "Vielleicht gibt's da einfach zwei Rollen, also eine Data-Science-Mass-Production und einen Data-Science-Pionier." Je nach Erfahrungen, je nach Ausbildung widmet man sich halt lieber dem einen oder dem anderen Thema.

00:26:06: Unbekannt: Wie guckst du da drauf? Gibt es da Tendenzen? Ich glaube, das hast du genau richtig zusammengefasst. Also da gibt es mehrere Rollen und wenn ich ein erfolgreiches Data-Science-Projekt haben will, also mir jetzt nur mal ein Projekt anschaue, reicht das nicht, da einfach jemanden dran zu setzen, der sehr gut Modelle trainieren kann, sondern ich muss mehrere verschiedene Rollen ausfüllen.

00:26:25: Unbekannt: Also idealerweise habe ich so was wie einen Data Engineer, der sich darum kümmert, wie ich meine Daten-Pipelines baue, wie ich die Daten sauber mache. Ich brauche den Data Scientist, der ein Modell trainieren kann. Aber genauso wichtig ist jemand, der sich um die Kommunikation kümmert, die Ziele im Blick behält, das ganze Stakeholder-Management macht, also jemand, der mehr eine Business-Brille auf hat - und alle diese Rollen zusammen zu vereinen in einer Person ist unmöglich.

00:26:53: Unbekannt: Jeder hat da seine Stärken und Schwächen. Deswegen, für ein erfolgreiches Data-Science-Projekt muss ich mehrere Leute zusammenziehen und also dieses Projekt auch wirklich gut besetzen. Ja, ist ja auch noch mal eine interessante Perspektive darauf, jetzt hast du ja viele solcher Projekte erlebt. Du hast mit unterschiedlichen Teams gearbeitet, hast in so einem Lab-Format, wie du selbst erwähnt hast, gearbeitet, bist jetzt beratend da unterwegs: Gibt es eine gute Größe? Jetzt hast du schon gesagt, na ja, einer allein wird es nicht schaffen, weil das offensichtlich zu klein ist. Gibt es es auch zu groß?

00:27:27: Unbekannt: Ja, aber ich glaube, gerade am Anfang dieser Experimentierphase, wenn da zu viele Leute versuchen zu experimentieren, ich glaube, das klappt nicht so gut. Also ich habe Projekte alleine gemacht, die sind eigentlich alle gescheitert. Also meine Quote an in den Sand gesetzten Projekten ist relativ hoch. Kein kausaler Bezug zur Person. Ich glaube nicht. Ich glaube, das liegt einfach daran, wenn man versucht, das alleine zu machen.

00:27:50: Unbekannt: Das hat wenig Chance auf Erfolg. Also ich glaube, eine gute Größe sind immer so 4 bis 6 Personen. Idealerweise hat man also, was ich eben noch vergessen habe, jemand noch eher mit einer Software-Engineering-Brille auf, der schaut, dass der Code auch eine gewisse Qualität hat, gerade wenn man hinten raus Richtung Betrieb schaut. Also jemand, der von Anfang an guckt, dass der Code, der produziert wird, auch wartbar ist, macht unglaublich viel Sinn.

00:28:15: Unbekannt: Gerade diese Data-Scientist-Rolle wird ja oft ausgefüllt von Leuten, die eher einen Mathematik- oder Physik- oder einen anderen naturwissenschaftlichen Background haben und nicht unbedingt wirklich Informatik studiert haben. Und in so einem Informatikstudium, also man lernt da wirklich richtig, wie man sauber programmiert und wie man von vornherein sicherstellt, dass eine Lösung auch wartbar ist. Und so jemanden von vornherein mit dabei zu haben, macht unglaublich viel Sinn.

00:28:40: Unbekannt: Ja, sicher auch Teil der von dir erwähnten Professionalisierung des gesamten Themenkomplexes in den letzten Jahren. Am Anfang war da doch viel Pioniergeist und man macht erst mal und man merkt dann nach Jahren: Oh, eine Dokumentation hätte uns geholfen. Damit geht es dann los und vielleicht ein bisschen auf die Wartbarkeit zu achten, ist das andere. Und sicherlich gehört Informationssicherheit und auch letztlich Lizenzthemen genauso in das Spektrum, wo man ja auch immer wieder aktiv auf dem Radar behalten muss als Unternehmen.

00:29:09: Unbekannt: Was wird da eigentlich eingesetzt? Dann ist das immer schnell gesagt: Na ja, wir benutzen nur Open Source, aber am Ende steckt dahinter doch ein ganzer Wald an Lizenzen, der möglicherweise am Ende des Tages doch mal Kosten erzeugt, oder wir benutzen halt unterschiedliche, auch das hast du schon erwähnt, Packages, die dahinter stehen, die den Alltag sehr praktisch machen. Auf der anderen Seite muss man aber auch da schauen, dass sie aktuell gehalten werden, dass keine Sicherheitslücken entstehen.

00:29:35: Unbekannt: Und auch all das gehört ja sicherlich in dein Thema mit rein. Zu sagen, wir brauchen eine skalierungsfähige Organisation, die sich auch darum kümmert. Genau das ist das große Stichwort Governance. Das klingt immer super langweilig, aber ist total wichtig für einen langfristigen Erfolg. Das geht bei den Themen los, die du erwähnt hast mit der Data Governance. Also wer sind denn überhaupt die Leute, die verantwortlich sind für bestimmte Daten?

00:29:59: Unbekannt: Töpfe? Was bei ganz vielen Data Science Projekten auftaucht, ist, dass eigentlich im ersten Schritt das ausreichend wäre, wenn die Leute besseren Zugriff hätten auf die Daten. Dass man Daten nicht nur als etwas versteht, was in gewissen Tabellen rumsteht, sondern sich Daten wie Produkte vorstellt und passend Datenprodukte an einen Analysten liefert, damit er sich nicht mehr per Hand aus fünf verschiedenen Quellen das zusammenzieht und dann in Excel S-Verweise baut, sondern ein fertiges Datenprodukt hat.

00:30:28: Unbekannt: Und da ist es ganz wichtig, dass man eine Data Governance hat und sogenannte Data Stewards, die sich um gewisse Datentöpfe kümmern und sich wie ein Produktmanager für ihre Daten verantwortlich fühlen und die so dem Fachbereich zur Verfügung stehen. Und man hat teilweise den Eindruck, dass auch das ein Stück weit ein unterentwickeltes Thema ist, an vielen Stellen aber eines, das unheimlich reich ist an Potenzial. Also sich den Basics noch mal zu widmen und zu sagen: Wir sorgen dafür, dass aus unserem Bereich hochqualitative, vollständige Daten entstehen.

00:31:01: Unbekannt: Wir fragen auch die Nachbarbereiche überhaupt erst mal, ob die an unseren Daten Interesse hätten und ob die vielleicht sich für andere Daten interessieren würden als wir selbst. Aber wir können sie erzeugen und wir können sie bereitstellen, also auch Stichwort Datendemokratie dann wirklich zu leben und zu sagen, wir sitzen nicht drauf auf unseren Daten, sondern wir geben sie auch ins eigene Unternehmen rein, wird natürlich neben, ich sage jetzt mal "fancy" Methoden, oftmals so ein bisschen ins zweite Glied gedrängt und man sagt, na ja, wir machen jetzt mal Leuchtturmprojekt AI, obwohl man vielleicht hinter dem AI-Modell eine ziemlich fragmentierte Datenlandschaft hat.

00:31:36: Unbekannt: Vielleicht kannst du auch da noch mal eine oder zwei Erfahrungen dazu geben, wie gute Ansätze entstehen können, um Datendemokratie zu fördern, um gute, konsistente Datenmodelle in so großen Unternehmen, wie wir sie halt auch gemeinsam kennen, dann voranzutreiben. Also ein ganz typischer Ansatz dafür ist, dass man eine Schicht einzieht zwischen die Datenquellen und den Endkunden, so dass der Datenkonsument nicht immer direkt auf ganz viele einzelne Tabellen zugreifen muss, sondern dass es dazwischen wie eine Datenproduktschicht gibt, wo man fertige Datensets sich ziehen kann.

00:32:16: Unbekannt: Das ist auch die ganze Basisarbeit dafür, dass man nachher Erfolg hat im Bereich KI und maschinellem Lernen, weil alles steht und fällt mit der Qualität von den Daten. Aber das Aufbauen von so einer Schicht, wo verschiedene Quellen schon zusammengeführt sind und wo es auch eine saubere Dokumentation für gibt und wo die Dinge auch korrekt zusammengeführt sind - das ist jahrelange Arbeit und ich kenne auch ein Beispiel von einem Unternehmen, die haben alle Aktivitäten im Bereich KI und maschinelles Lernen erst mal gestoppt für anderthalb Jahre und haben gesagt: So, wir stecken jetzt erst mal ganz viel Zeit da rein, diese Datenschicht ordentlich aufzubauen.

00:32:55: Unbekannt: Und wenn wir noch mal zurückkommen zu dem Thema, wann hat so ein Data-Science-Projekt Erfolg oder woran scheitert es dann? Also typischerweise startet so ein Projekt damit, dass man Excel-Dateien zugeschickt bekommt. Also, erkennst du mit Sicherheit auch. Eigentlich gibt es immer irgendjemanden, der die Datenquellen ganz gut kennt und auch alle Zugriffe hat, der loggt sich dann in ganz viele verschiedene Systeme ein, zieht die Excel-Dateien, die kriegt man dann zugeschickt als Data Scientist.

00:33:20: Unbekannt: Dann fügt man diese Daten zusammen, baut dann ein Modell drauf und hat seinen Leuchtturm eigentlich relativ fix fertig. Und der Hauptpunkt, wo dann solche Projekte nachher scheitern beim in Betrieb gehen ist, dass man natürlich nicht diese Personen jeden Montag damit beauftragen kann, diese Daten zusammenzuziehen und die in einem Ort abzulegen. Oder am besten jeden Morgen. Das heißt, man muss diese Datenladestrecken automatisieren.

00:33:45: Unbekannt: Und das ist so ein ganz wesentlicher Knackpunkt, wo dann Projekte scheitern. Und wenn man vorher schon so eine ordentliche Zwischenschicht hat, wo man Daten sauber zusammenfügen kann aus verschiedenen Systemen, die dann auch einleuchtende Namen haben - das ist ein Faktor, den man mitbringen kann, damit Data-Science-Projekte Erfolg haben. Ja, super, leuchtet auch extrem ein. Also die ETL-Strecke ist halt sehr einfach gebaut.

00:34:09: Unbekannt: Wenn sie auf eine saubere Basis zugreifen kann. Wenn unsere Hörer sich dem Thema jetzt widmen wollen und denken: Ja, das beschäftigt uns doch auch seit Jahren! Wonach sollen sie als erstes suchen? Also ich glaube, da gibt es unheimlich viele Themen und Fachbegriffe, die draußen in der Welt rumgeistern. Vor vielen Jahren war es irgendwann mal der Data Lake, der plötzlich alles heilen sollte.

00:34:30: Unbekannt: Und dann hat man gemerkt, na ja, jeder hat seinen Eimer Wasser reingekippt. Aber bei dem einen war es Salzwasser und bei dem anderen Süßwasser und beim dritten war es irgendwie noch was anderes. Und das, was da zusammengelaufen ist, hat sich nicht gut verstanden. Und eigentlich konnte man auch nichts mehr damit anfangen. Jetzt deutlich überspitzt: Welches Konzept überzeugt dich heute am meisten, um die Schicht zu erzeugen, von der du gesprochen hast?

00:34:51: Unbekannt: Also was man am besten benutzt, um danach zu suchen, ist das Stichwort Data Fabric. Das ist, worunter das heute im Marketing drin ist und wo es auch viele Produkte dazu gibt. Und die unterscheiden sich wirklich als Konzept zu dem alten Data-Lake-Konzept, wo man einfach gesagt hat, da kippt man alles rein und die Leute werden sich schon zurechtfinden.

00:35:11: Unbekannt: Und zu dem anderen Stichwort, also wie bringe ich mein Data-Science-Projekt tatsächlich in Betrieb? Da ist das Stichwort MLOps. Gibt es inzwischen auch viel Literatur dazu und ist auch so, wie wir das eben angesprochen haben, auch bei vielen Stellen eine Governance-Frage. Also wenn es zum Beispiel darum geht, welche Tools sind denn erlaubt.

00:35:30: Unbekannt: In meinem Unternehmen? Da gibt es auch zwei verschiedene Philosophien. Ich lass einfach jeden Data Scientist damit arbeiten, womit er möchte, aber das wird dann hinten raus sehr, sehr kompliziert, wenn ich versuche, das zu betreiben. Und umgekehrt, also das andere Extrem ist, dass ich halt ganz klar vorgebe: Nur folgende Tools und folgende Pakete sind erlaubt. Damit habe ich hinten raus die Sicherheit, dass alle meine Produkte zusammenpassen, was man sich beim Auto gar nicht anders vorstellen könnte.

00:35:59: Unbekannt: Bei der Autoherstellung. Auf der anderen Seite, wo das die Leute beschränkt, ist gerade bei dieser Anfangsphase, wenn man versucht, kreativ zu sein und ein Problem auf eine neue Art zu lösen und man es beschränkt mit den Tools, die man benutzen darf, ist das ein ganz großer Hemmschuh. Irgendwo da in der Mitte liegt die Wahrheit, wie es gut gehen könnte. Da kommt kurz der Bahner noch mal raus.

00:36:22: Unbekannt: Bei der mit dem Hemmschuh.

00:36:26: Unbekannt: Kann man den Lebenslauf nicht verbergen? Also du meinst, es gibt einen Sweet Spot irgendwo zwischen Standardisierung von Dokumentation, Wartung und auch Lizenzkosten und einer ganz klaren Vorgabe der Werkzeuge gegenüber der Lösungsfreiheit und der technologischen Offenheit? Ja, schwierige Frage am Ende des Tages war natürlich, dass mit Blick auf die Skalierbarkeit immer schwierig wird, wenn man die Auswahl dann zulässt und auch Fragen der Informationssicherheit sicherlich nicht einfacher werden.

00:36:55: Unbekannt: Ich würde gerne noch einen Bogen machen an der Stelle, denn wir haben jetzt viel über die Skalierung der Themen gesprochen und wie man sie gut in Betrieb kriegt und welche Kontextfaktoren zum Erfolg beitragen können. Wir sind etwas abgekommen von Methoden, aber an einer Methode kommen wir natürlich aktuell nicht vorbei: Künstliche Intelligenz. Alle sprechen von GenAI. Ich glaube, es ist das größte Thema, das man gerade generell sieht.

00:37:22: Unbekannt: Auch vom Umfang her deutlich größer als so die Methoden, über die man sich dann früher mal unterhalten hat. Siehst du, dass es tatsächlich anders ist? Also glaubst du, es ist jetzt gerade ein großer Hype und der wird sich irgendwann wie viele andere Schlagworte wieder beruhigen? Oder stehen wir hier methodisch vor der großen Revolution, die sich eigentlich gerade viele erhoffen?

00:37:44: Unbekannt: Ich würde sagen, irgendwo da in der Mitte. Also das ist, glaube ich, nicht einfach nur ein Hype, der sich in zwei Jahren legen wird. Also mit Modellen, also mit diesen Large Language Models wie ChatGPT, da ist wirklich eine neue Tür mit aufgegangen und da sind ganz neue Sachen mit möglich, die vor zehn Jahren undenkbar waren. Auf der anderen Seite glaube ich auch nicht, dass das die große Revolution ist. Also ein Test, den ich immer mache, wenn ein neues Modell rauskommt, ist, dass ich irgendein offenes Problem aus der Mathematik nehme, was jetzt nicht so gut dokumentiert ist.

00:38:14: Unbekannt: Also die Riemannsche Vermutung, da gibt es ganz viel drüber im Internet. Wenn ich ChatGPT nach der Riemannschen Vermutung frage, wie man die löst, wird es sagen: "Das geht nicht." Aber bei allen offenen mathematischen Problemen, die nicht gut dokumentiert sind, wenn ich da ChatGPT frage "Wie geht das denn?", guckt mir das eine Lösung aus. Das musst du so und so machen und dann hast du das Problem gelöst.

00:38:37: Unbekannt: Also da fehlt irgendwie noch eine komplette Schicht mit dem Wissen, dass man etwas nicht weiß. Gut, als junges Thema ist das ja okay, dass noch Entwicklungspotenzial auf der Strecke liegt. Die schiere Größe und der Hype unterscheidet sich aus meiner Sicht halt schon, wie stark es in die Unternehmen reingedrängt wird. Jeder fragt sich: Was kann ich jetzt eigentlich damit machen?

00:38:59: Unbekannt: Können wir die Menschen und unsere Zuhörer denn an der Stelle beruhigen, dass es sich nicht unterscheidet von anderen Themen? Müssen wir in Sachen MLOps, in Sachen Betriebsführung anders denken, wenn wir auf AI gucken? Oder bleiben die Herausforderungen dahingehend die gleichen? Nein, das sind wirklich ganz neue Herausforderungen. Einfach die schiere Größe von den Modellen macht eine komplett neue Tür auf.

00:39:19: Unbekannt: Also wenn ich ein klassisches Machine Learning-Modell habe, das kann ich als Unternehmen, auch ziemlich egal von welcher Größe, kann ich das betreiben. Das kann ich trainieren, das kann ich betreiben, das kriege ich hin. Dasselbe für neuronale Netze, so wie wir sie vor ChatGPT kannten, also alles, wo es um Bildklassifikation geht, Objekte in Bildern. Das war auch alles in einer Größenordnung, das kann ich als Unternehmen sowohl trainieren, also die Kosten dafür werde ich mir leisten können.

00:39:51: Unbekannt: Und von der Komplexität kriege ich auch den Betrieb hin. Aber ein Modell von der schieren Größe, so wie das ChatGPT ist, werde ich als Unternehmen weder trainieren noch betreiben können. Also ich glaube, da kriegt man eine ganz neue Herausforderung, weil man damit dann Abhängigkeiten bekommt zu den großen Unternehmen, die solche Sachen trainieren können. Und ich glaube, das neue Thema, was da aufkommt, läuft also so im Stichwort Prompt Engineering.

00:40:18: Unbekannt: Also wie kann ich denn zum Beispiel automatisch meine Prompts so verändern, dass das genau passt zu dem, was ich als Unternehmen brauche? Also da auf der einen Seite noch mal eine neue Anforderung an die Kompetenzen im Data-Science-Team zur Bedienung? Denn sicherlich wirkt es sich ja auch auf die Arbeitsweisen des Teams selbst aus und eben die Nutzung des Werkzeugs an sich für die Aufgaben des Data-Science-Teams.

00:40:41: Unbekannt: Auf der anderen Seite höre ich bei dir auch ein Stück weit raus, dass der Kontext, den wir etwas früher erläutert haben, dass es wichtig ist, noch mehr Wert auf Messbarkeit und Definition von Erfolg zu legen und zu sagen, wir müssen das enger an den Impact im Unternehmen knüpfen, noch mal unterstrichen wird, wenn du sagst, da steigt die Abhängigkeit gegenüber externen Dienstleistern, da steigen möglicherweise auch langfristig entsprechend Kosten.

00:41:07: Unbekannt: Der Dienstleister möchte auch gern was daran verdienen, dass er das bereitstellt und das in einem längeren Maße, als das in der Vergangenheit war, als wir in einer eher fragmentierten Methodenwelt unterwegs waren, wenn sich das heute so stark auf diese Lösungen, die du genannt hast, konzentriert. Ja, auch die Messbarkeit von dem Erfolg wird also aus meiner Sicht viel, viel komplexer, weil bei klassischem Machine Learning sind die Anwendungsgebiete oft Sachen, die ich sehr gut messen kann.

00:41:34: Unbekannt: Also wenn ich zum Beispiel in meiner Produktion einen Prozess um 10 Prozent verbessere oder meinen Ausstoß um 5 Prozent reduziere, das sind so die typischen Use Cases für klassisches Machine Learning oder auch für Bildklassifikation. Da kann ich ganz gut rechnen und weiß, was mir das bringt. Und wo gerade diese neuen Large Language Models viel bringen, ist beim Coding, also wenn ich Code schreiben möchte, das geht jetzt einfach viel schneller.

00:42:00: Unbekannt: Ich kriege eigentlich schon vorgefertigte große Bausteine und muss die nur noch zusammenstöpseln. Also typische Umfragen sagen, dass Coding um die 50 Prozent schneller geworden ist. Und das andere, wo das viel bringt, ist in der Textproduktion oder im Texte zusammenfassen. Aber all diese Bereiche sind super schwer zu messen. Also was bringt mir das in wirklichen Zahlen für mein Business Case, wenn ich 50 Prozent schneller coden kann?

00:42:30: Unbekannt: Das ist sehr schwer zu quantifizieren und viel schwerer zu quantifizieren als: Ich produziere 3 Prozent weniger Ausschuss. In der Tat. Also wir sind doppelt gefordert als Unternehmenssteuerer, die Messbarkeit wird schwieriger, sagst du, und eigentlich gab es sie vorher auch schon nicht. Da müssen wir uns erst mal sehr anstrengen, in den Unternehmen hier noch unseren Beitrag zu leisten und zu sagen: Wir stellen sicher, dass Erfolg erzeugt wird und dass wir verstehen, wie er erzeugt wird, und eben die entsprechenden Informationen als Unternehmenssteuerer bereitstellen.

00:43:02: Unbekannt: Vielen Dank dafür, Timo. Vielleicht, bevor wir abschließen, jetzt haben wir viel über die Vergangenheit gesprochen, viel über die aktuelle Situation rund um die Herausforderung der Skalierung von MLOps-Themen. Und lass uns den Blick noch mal nach vorne strecken. Wenn du jetzt einen Termin machst, um die anschließende Folge für diesen Podcast aufzunehmen in ein oder zwei Jahren, was hat sich bis dahin aus deiner Sicht getan in den Themen?

00:43:33: Unbekannt: Gibt es Sachen, die du dir explizit wünschen würdest? Und gibt es eine Empfehlung, die du unseren Klienten ans Herz legen würdest, worum sie sich führend kümmern sollten? Ja, was ich mir wünschen würde oder wo ich denke, was passieren wird in den nächsten Jahren, ist, dass der Grad der Professionalisierung im Bereich Data Science und Machine Learning immer weiter zunimmt.

00:43:54: Unbekannt: Also gerade wenn wir uns den Bereich MLOps, den wir angeschnitten haben, anschauen, alle großen Softwareanbieter bieten da inzwischen Produkte an und die werden immer ausgereifter und ich glaube, dann wird auch immer leichter, Machine Learning-Modelle zu betreiben und ich glaube, das wird in zwei Jahren noch zugenommen haben. Ja, und was ich so als Empfehlung geben kann, ist zum einen das Thema von dieser Datenschicht, die wir angesprochen haben, da Energie reinzustecken, weil damit legt man die Grundlage für alle weiteren Use Cases und hat mit dem Thema Datenprodukte eigentlich schon an sich einen Benefit, den das bringt.

00:44:31: Unbekannt: Also es ist nicht nur etwas, was auf zukünftige Sachen einzahlt, sondern liefert glaube ich einen direkten Mehrwert. Ja, und das andere Thema, sich einfach viel Gedanken darüber zu machen, wie ich mein Data-Science-Team so strukturiere, dass es Erfolg hat. Also wo häng ich es am besten hin und wie messe ich das denn? Okay, dann gehen wir die Wette ein.

00:44:51: Unbekannt: Gucken wir in zwölf Monaten einfach wieder drauf. Was ist passiert? Welche neuen Cases sind entstanden? Wo hängen die Data-Science-Teams? Welche Rolle spielt das Controlling und der CFO in dem Spiel? Hat man zur Rationalitätssicherung bei der Erfolgsmessung von Data-Science-Projekten beitragen können? Und ja, haben wir generell vielleicht mit GenAI 50 Prozent Produktivität nicht nur beim Coden geholt, sondern auch in den Unternehmen?

00:45:17: Unbekannt: Wir werden sehen. Es hat mir großen Spaß gemacht, mit dir zu sprechen und besten Dank dafür. Ja, auch besten Dank! Hat mir auch super viel Spaß gemacht. Ciao, Timo. Tschüss.

00:45:29: Unbekannt: Wenn Ihnen unsere Etappen gefallen und wir Sie durch interessante Management-Themen navigieren, haben wir gute Nachrichten. Im Juli sind wir mit einem neuen Ziel am Start. Sie wollen keine Folge von "Zielführung starten" verpassen? Dann abonnieren Sie kostenlos unseren Podcast im Verzeichnis Ihrer Wahl. Bis bald.

00:46:02: Unbekannt: Das war "Zielführung starten - der Management-Podcast von CTcon".