00:00:00 Einfuehrung
00:03:17 Warum gibt es Forward Deployed Engineers?
00:09:48 Warum KI-Projekte in grossen Unternehmen scheitern
00:13:35 Untergraebt Expertenunterstuetzung Plug-and-play-Software?
00:18:33 Bestaetigt der FDE-Trend Lokads Ansatz?
00:22:55 Automatisierung versus folgenreiche Entscheidungen
00:28:07 Wie ein Supply Chain Scientist einen neuen Kunden angeht
00:32:26 Experten ueber lange Zeithorizonte bewerten
00:36:12 Ist Produktakzeptanz die richtige Erfolgskennzahl?
00:40:06 Warum Automatisierung ein Null-zu-eins-Problem ist
00:43:09 Finanzieller Effekt versus wirtschaftlicher Effekt
00:48:05 Warum Entscheidungsfindung Domaenenexpertise erfordert
00:52:32 Wie Lokad starke Supply Chain Scientists erkennt
00:55:22 Krankenhausautomatisierung versus medizinische Entscheidungen
00:57:09 Widerlegen FDEs Plug-in-Optimierungsmodule?
00:58:43 Das Kostenproblem von FDE-Diensten
01:01:04 Fazit
Zusammenfassung
Conor Doherty und Joannes Vermorel untersuchen, warum Forward Deployed Engineers zu einem der neuesten Trends in Unternehmenssoftware geworden sind. Sie besprechen den Fachkraeftemangel und gescheiterte KI-Initiativen, die diesen Aufstieg antreiben, und unterscheiden gewoehnliche Automatisierung von finanziell folgenreichen Entscheidungen. Joannes argumentiert, dass Automatisierung Arbeit vollstaendig beseitigen sollte, waehrend Entscheidungssysteme kontinuierliche Wartung, wirtschaftliches Urteilsvermoegen und tiefe Domaenenexpertise erfordern. Das Gespraech vergleicht FDEs mit Lokads Supply Chain Scientists, hinterfragt Akzeptanz als Erfolgskennzahl und untersucht, ob teure menschliche Unterstuetzung die Grenzen angeblich plug-and-play-faehiger Unternehmenssoftware offenlegt.
Vollstaendige Transkription
Conor Doherty: Also, es ist fast 18 Uhr, was in Paris im Grunde schon Nacht ist. Ja, wir arbeiten hier in Frankreich wirklich hart, nach franzoesischen Massstaeben. Es ist also fast 18 Uhr hier in Paris, und Joannes und ich haben gerade den Podcast ueber Forward Deployed Engineers beendet. Er ist ganz anders geworden, als ich erwartet hatte.
Ich hatte natuerlich meine Fragen vorbereitet, aber dann hat sich das Gespraech einfach weiterentwickelt. Ich dachte, wir wuerden hauptsaechlich darueber sprechen, was ein Forward Deployed Engineer ist und ob das Hype ist oder nicht. Das haben wir zwar behandelt, aber wir sind auch auf Fragen eingegangen wie: Wie bewertet man ein FDE-Angebot in Unternehmenssoftware? Wofuer sollte diese Rolle wirklich eingesetzt werden? Und wie unterscheidet sie sich von der Rolle des Supply Chain Scientist bei Lokad? Ich habe es jedenfalls sehr genossen. Ich hoffe, Ihnen geht es genauso, und schreiben Sie uns gern auf LinkedIn.
Sie koennen sich mit Joannes und mir vernetzen, falls Sie weitere Fragen haben. Ich gehe jetzt aber nach Hause. Viel Spass mit dem Gespraech. Joannes, danke, dass du dabei bist.
Ich habe dich heute eingeladen, um ueber den Aufstieg der Forward Deployed Engineers zu sprechen. Ich habe meine Hausaufgaben gemacht. Das ist keine neue Position. Tatsachlich liegen ihre Wurzeln im Militaer, aber in Softwarekreisen, und besonders in der Unternehmenssoftware, ist das eine sehr neue Position.
Um die Groessenordnung kurz einzuordnen: Ich habe heute Morgen gelesen, dass AWS rund eine Milliarde, eigentlich etwas mehr als eine Milliarde Dollar, in den Aufbau seiner Forward-Deployed-Engineer- oder FDE-Abteilung investiert. Y Combinator, der sehr bekannte Accelerator, hat derzeit, also Stand 27. August, mehr als 100 Startups, die genau solche Rollen ausschreiben. Nicht einfach Ingenieure, sondern Forward Deployed Engineers. Was ist das nun in einfachen Worten? Ich habe ein paar Definitionen zusammengefasst, denn natuerlich variieren sie, aber im Kern ist ein Forward Deployed Engineer oder FDE ein kundenorientierter Software Engineer, der direkt innerhalb eines Kundenteams oder mit diesem Team arbeitet, physisch oder remote, um komplexe Software zu bauen, anzupassen und auszuliefern, die komplexe reale Probleme loest. Nun, wie dir sicher sofort aufgefallen ist, und mir in dem Moment, als ich das gelesen habe, und wie es sicher jedem aufgefallen ist, der Lokad kennt: Das klingt sehr aehnlich wie ein Supply Chain Scientist. Es gibt Unterschiede, auf die wir spaeter kommen, aber meine erste Frage auf hoher Ebene lautet:
Wir sind vier Jahre im KI-Boom. ChatGPT erschien also im Herbst 2022, jetzt sind wir fast im Herbst 2026. Es fuehlt sich kuerzer an, aber es sind vier Jahre. Wir haben KI, die in vielen Kontexten ihren eigenen Code schreibt, und trotzdem sind wir nun wieder da angekommen, als waere die Zeit ein flacher Kreis.
Wir sind wieder bei: “Wenn Sie wollen, dass dieses Ding funktioniert, muessen Sie meinen Experten einstellen, der kommt und es fuer Sie zum Laufen bringt.” Joannes, warum existiert diese Rolle heute ueberhaupt?
Joannes Vermorel: Ja, ich meine, wir kommen wieder genau zu der Art Setup zurueck, die historisch den Erfolg von IBM ausgemacht hat. Die Idee des Forward Deployed Engineer war im Grunde das Standardmodell von IBM in den 70er- und 80er-Jahren: Man schickte sehr viele Ingenieure, wuerde ich sagen, vor Ort zum Kunden, um den Mainframe einzurichten. Das war sozusagen der Standard.
Tatsachlich haben wir uns in den letzten zwei Jahrzehnten davon eher entfernt, und jetzt kommt es mit Macht zurueck. Meine allgemeine Sicht darauf, warum es zurueckkommt, ist: Es gibt viele Kraefte, aber eine davon ist einfach der soziologische Effekt des Recruitings. Manche Unternehmen sind im Vergleich zu anderen unglaublich erfolgreich darin, Talente anzuziehen. Ich glaube, ich habe vor einigen Jahren gelesen, dass sich etwa vier Millionen Menschen pro Jahr bei Google bewerben.
Diese Information ist ungefaehr ein Jahrzehnt alt. Die Groessenordnung duerfte aber wahrscheinlich immer noch stimmen. Das Interessante ist: Einige Unternehmen sind erfolgreich, andere nicht. Und als kleine, vollkommen anekdotische Zahl: Wenn wir bei Lokad eine Stelle auf LinkedIn ausschreiben, sehe ich sehr haeufig, dass wir viel mehr Bewerber bekommen als sehr grosse Unternehmen mit ueber 100.000 Mitarbeitern, wenn sie eine vergleichbare Stelle ausschreiben.
Conor Doherty: Du sprichst da konkret von der Rolle des Supply Chain Scientist?
Joannes Vermorel: Ja, auf LinkedIn rahmen wir sie als Business Analyst.
Conor Doherty: Ach ja, stimmt.
Joannes Vermorel: Denn sonst wissen die Leute vor dem Computer nicht einmal wirklich, wovon wir sprechen. Wenn wir also auf LinkedIn posten, nennen wir es Business Analyst, und wir bekommen normalerweise viel mehr Bewerber als extrem grosse Unternehmen. Was ich allgemein sehe, ist, dass einige Unternehmen jeder Groesse extrem erfolgreich darin sind, sehr viele Talente anzuziehen, waehrend viele andere, typischerweise aeltere und groessere Unternehmen, das nicht sind. Dadurch entsteht eine sehr natuerliche Neigung zu sagen: Wenn wir all diese Leute einstellen koennen, oder mehr von diesen Leuten, die sich bei uns bewerben, dann verkaufen wir ihre guten Dienste einfach an diese Kunden weiter. Und wenn man das mit einer Softwareplattform kombinieren kann, verkauft man also die Zeit dieser klugen Leute, die man einstellen kann, und obendrein bindet man das Kundenunternehmen an die zugrunde liegenden Technologien, die man verkauft. Dann kann das ueber einen sehr langen Zeitraum ein sehr profitabler Schachzug werden. Wenn wir ueber AWS sprechen, sprechen wir ueber Leute, die Kunden helfen, die Cloud-Angebote von Amazon zu uebernehmen. Und genauso ist es, wenn man Forward Deployed Engineers von Palantir bekommt: Diese Leute bauen auf der Palantir-Plattform. In gewissem Masse ist es bei Lokad aehnlich: Die Supply Chain Scientists bauen auf der Lokad-Plattform. Aber grundsaetzlich denke ich, dass die eigentliche Kraft, die groesser ist als die Technologie, dieser soziologische Effekt ist: Es scheint, dass Talente zu einigen wenigen Unternehmen stroemen, die eine enorme Zahl von Bewerbern bekommen, waehrend viele andere Unternehmen sehr wenig bekommen. Deshalb landen wir gewissermassen bei Unternehmen, die Talente horten, und daraus entsteht die natuerliche Neigung zu sagen: Ich kann nur einstellen, was ich brauche, oder ich kann expandieren und die Tatsache nutzen, dass ich ueberhaupt so gut darin bin, Talente anzuziehen, um diese Engineering-Talente anschliessend an Kunden weiterzuverkaufen.
Conor Doherty: Das stimmt. Es ist natuerlich vielschichtig.
Joannes Vermorel: Ja.
Conor Doherty: Ein weiterer Strang, auf den man sich konzentrieren sollte, fuehrt wieder zur Idee zurueck, dass die Zeit ein flacher Kreis ist. Ich glaube, vor 18 Monaten hatten wir ein Live-Event ueber die Wertluecke generativer KI. Ein paar Monate davor hatten wir eine voraufgezeichnete Folge dazu. Wir sprachen darueber, dass es sehr viel Forschung gibt, sogar von grossen Beratungsunternehmen, die sagt: Viele Projekte, in die Menschen hunderte Millionen Dollar stecken, werden erstens nicht angenommen und erzeugen zweitens keinen Wert. Zur Vorbereitung darauf habe ich nachgesehen, wie viele meiner damaligen Notizen heute noch relevant sind. Ueberraschung: alle. Es gab im vergangenen Jahr sogar eine MIT-Studie mit 400 Unternehmen, und das waren grosse US-Unternehmen. 95 Prozent gaben an, dass das Geld, das sie fuer KI-Projekte ausgegeben hatten, nichts eingebracht hat.
Die Formulierung war: kein messbarer Effekt. Viele dieser Forward-Deployed-Positionen sind sehr eng damit verbunden, KI-Projekte zum Funktionieren zu bringen. Ich bin sicher, es gibt Nischenanwendungen, bei denen es heisst: Nein, ich will nur mein System of Record in Gang bringen, und ich schicke jemanden, der das erledigt. Aber sehr haeufig verkaufen OpenAI, Anthropic und auch Leute in unserem Umfeld KI-Projekte mit dem FDE: Der FDE wird das KI-Projekt in Ihrem Kontext zum Laufen bringen.
Du hast also ueber das Horten von Talenten gesprochen, natuerlich, und es ist fast wie eine Investition in kuenftigen Bedarf. Gleichzeitig gibt es aber, zumindest laut vielen Institutionen, einen sehr gegenwaertigen Bedarf, weil viele KI-Projekte, fuer die Unternehmen ziemlich blind Millionen ausgeben, nichts beitragen. Und der Markt hat gesagt: Wissen Sie was, ich habe einen Experten, der Ihnen hilft, das zu beheben. Klingt das fuer dich plausibel?
Joannes Vermorel: Ja, aber ich wuerde die Grundursache vielleicht etwas anders verorten.
Conor Doherty: Okay.
Joannes Vermorel: Grosse Unternehmen, alle Unternehmen, haben normalerweise die exakte Menge an Kompetenz und Faehigkeiten, die man fuer jede einzelne Position braucht, vollstaendig gemeistert und kalibriert. Dadurch entsteht im Unternehmen eine Pyramide, in der der groesste Teil mit Menschen besetzt ist, die genau auf ihrem Kompetenzmaximum sind. Das ist das Peter-Prinzip: Man wird befoerdert, bis man den Punkt der Inkompetenz erreicht.
Stellen Sie sich nun ein Unternehmen mit 50.000 Menschen vor, in dem fast jeder exakt an der Grenze zur Inkompetenz ist. Nicht inkompetent, nur knapp darunter. Jetzt fuehren Sie eine Technologie ein, die selbst nicht unbedingt extrem kompliziert ist, aber eindeutig eine zusaetzliche Komplikation darstellt. Dann merken Sie, dass praktisch die ganze Pyramide ueberfordert ist, weil diese neue Sache die Menschen aus ihrer Faehigkeitszone herausbringt. Das klingt etwas hart, aber denken Sie an ein Unternehmen, das seit Jahrzehnten existiert und normalerweise jeden Prozentpunkt Profitabilitaet aus seiner Kostenstruktur herausgepresst hat. Das bedeutet: Wenn man Menschen beschaeftigt hat, die kompetenter waren als wirklich noetig, dann war das Geld, das auf dem Tisch liegen blieb. Viele Unternehmen landen ueber Jahrzehnte durch die natuerlichen Marktkruefte dabei, jede Art von Kompetenzueberschuss zu eliminieren. Das ist meine typische Sicht auf den Fall. Deshalb brauchen sie Unterstuetzung, sobald disruptive Softwaretechnologien auftreten. Wenn sie versuchen, diese intern auszurollen, stossen sie auf Schwierigkeiten, weil praktisch jeder in der Pyramide bereits am Limit dessen ist, was er bewaeltigen kann. Wenn man noch etwas hinzufuegt, ist es nicht mehr beherrschbar, und sie scheitern. Deshalb scheitern meiner Meinung nach viele dieser KI-Initiativen: Man braucht Menschen, die sehr viel Spielraum haben, was Intelligenz, Kompetenz und Faehigkeiten zusaetzlich zu ihrer aktuellen Aufgabe betrifft, damit sie ueber die Zukunft ihrer Arbeit nachdenken koennen, wenn KI ins Bild kommt. Denn bei KI-Technologien laeuft es meist darauf hinaus, dass man die Arbeit neu denken muss. Dann kann man vielleicht eine zehnfache Produktivitaet erreichen, aber diese Arbeit erfordert ein sehr sorgfaeltiges Neudenken, weit jenseits dessen, was historisch noetig war, um den Status quo am Laufen zu halten.
Conor Doherty: Waehrend du das gesagt hast, hat sich bei mir ein Gedanke herauskristallisiert. Ich hatte ihn nicht aufgeschrieben, aber ich versuche ihn jetzt auszusprechen. Die ganze Idee von KI, zumindest so, wie sie verkauft wurde, lautet: Wir automatisieren so viel wie moeglich, und ausserdem koennen wir weit ueber das hinaus skalieren, was mit einer menschlichen Belegschaft noetig oder moeglich war, oder zumindest ueber das hinaus, was eine Person leisten konnte. Und jetzt sind wir an dem Punkt, an dem gilt: Wenn KI funktionieren soll, braucht man jemanden mit sehr viel Kompetenzreserve, der das zum Funktionieren bringt.
Joannes Vermorel: Ja.
Conor Doherty: Untergraebt das dann nicht das ganze Konzept von: einfach bezahlen und einstecken, oder neue Software anschliessen, von der Stange kaufen und sie ist sofort einsatzbereit? Denn jetzt muss man jemanden zusaetzlich kaufen, damit sie fuer einen funktioniert.
Joannes Vermorel: Ja. Ich gebe ein aktuelles Beispiel. Ich habe kuerzlich meinen Mobilfunkanbieter ueber die Hotline kontaktiert. Eine wunderbare Erfahrung. Historisch hatten sie die ersten zwei Minuten mit einem unglaublich langsamen rechtlichen Hinweis, der mich nicht interessiert, und dann “Druecken Sie eins fuer dies, zwei fuer das” und so weiter.
Sie hatten dieses Labyrinth aus Nummern, um zu dem zu gelangen, was man erreichen wollte, und am Ende zu einem Mitarbeiter, weil keiner der Wege irgendwohin fuehrte. Sogar das war schon ein wenig kaputt. Was man sich vorstellen muss: Die Ingenieure, die in diesem Unternehmen ihr Bestes gaben, waren kaum in der Lage, etwas zu pflegen, das im Grunde ein Entscheidungsbaum mit Nummern war, um Menschen weiterzuleiten. Das war bereits ihr Engineering-Maximum, und selbst daran scheiterten sie teilweise. Nun haben sie ihr System kuerzlich mit KI erneuert. Diese KI hat die schlechteste Spracherkennung ueberhaupt. Sie versteht nichts.
Ich habe etwa 20 Minuten mit dieser verdammten KI gestritten, bis ich endlich einen Mitarbeiter erreichen konnte, weil das, was ich tun wollte, mit diesem System nicht moeglich war. Es war episches Fehl-Engineering. Aber in Wirklichkeit war es sehr vorhersehbar. Wenn Menschen bereits an ihrer Grenze sind, wenn es darum geht, einen Entscheidungsbaum zu bauen, und das fuer sie schon eine Herausforderung ist, dann wird es sehr schlecht, wenn man sie bittet, eine fluessige KI-basierte Triage fuer eingehende Anrufe zu entwickeln. Interessant war, dass alles schlecht war: Die Spracherkennung war furchtbar, man konnte spueren, dass das Skript und die Wissensbasis, mit denen sie die Situation behandeln sollten, schlecht waren.
Es war also ein mehrschichtiges Problem, bei dem jedes einzelne Stueck Software extrem schlecht war. Die gewaehlte Spracherkennung war schlecht. Die Sprachsynthese war schlecht. Das LLM war schlecht.
Die Wissensbasis, mit der sie das LLM gefuettert hatten, war schlecht. Es war wieder eine mehrschichtige schlechte Software. Und wenn wir dazu zurueckkommen, warum es scheitert: Stellen Sie sich vor, Ihre IT kaempft bereits damit, sehr einfache Dinge zum Laufen zu bringen. Und ich kenne die Leute, die in genau diesem Unternehmen in der IT arbeiten. Sie sind nicht die Schaerfsten.
Es ist die Art Unternehmen, die enorme Schwierigkeiten hat, auch nur halbwegs brauchbare Leute aus franzoesischen Ingenieurhochschulen zu bekommen. Deshalb ist es keine Ueberraschung, dass alles, was sie mit KI versuchen, eine Katastrophe wird. Dass man Hilfe von aussen braucht, ist also einfach die Konsequenz daraus, dass Ihre Teams, sobald Neuheit ins Spiel kommt, damit nicht zurechtkommen, weil sie schon mit dem Status quo kaum zurechtkommen.
Conor Doherty: Ja.
Joannes Vermorel: Und selbst der Status quo ist schon sehr ueberdehnt.
Conor Doherty: Ich hatte vorher das Wort Flux aufgeschrieben, aber Neuheit ist besser, weil es den Geist eines der groessten Unterscheidungsmerkmale hier besser einfängt. Lokad hat historisch immer die Idee verbunden: Man hat die Software, aber man hat auch den Experten. Und der Grund fuer den Experten ist, dass Ihre Supply Chain voller Nuancen und Randfaelle ist, die auftreten werden. Natuerlich gibt es taegliche Entscheidungen, die banal sind, aber sie werden von viel Flux bestimmt. Es war nie: Kaufen Sie das einfach von der Stange.
Das gesamte Marketing und in Wirklichkeit auch die tatsaechliche Funktion des Dienstes lautete: Das muss um Ihre Probleme, um Ihre Realitaet herum gebaut werden. Unser Supply Chain Scientist muss mit Ihnen interagieren, um die Entscheidungsebene aufzubauen.
Joannes Vermorel: Ja.
Conor Doherty: Siehst du das Aufkommen der FDE-Rolle bei aehnlichen Unternehmen, also bei Peers, Wettbewerbern, was auch immer, als Bestaetigung der Tatsache, dass du immer gesagt hast: Alles muss von Grund auf gebaut werden. Man kann nicht einfach fuer alles Copy-Paste-Code haben.
Joannes Vermorel: Ja und nein. Zunaechst ist die Realitaet: Fast alle Probleme, die man betritt, sobald man in den Bereich der Unternehmenssoftware kommt, bestehen darin, Software miteinander zu verkleben. Das ist fast das ganze Problem. Ja, man kann dort drueben ein LLM von der Stange haben.
Man kann dort drueben einen Webserver von der Stange haben. Man kann dort drueben eine transaktionale Datenbank von der Stange haben. Aber man muss diese Dinge zusammenkleben. Und weil Ihr Unternehmen seit 50 Jahren existiert, haben Sie Jahrzehnte an bereits vorhandenen Dingen. Sie haben also nicht den Luxus zu sagen: “Ich schliesse dieses Produkt einfach an, und es funktioniert.”
Das ist eine Greenfield-Situation, die in einem KMU funktioniert. Im Enterprise-Bereich funktioniert sie nicht. Um dem Markt gegenueber fair zu sein: Die Idee, viele Berater und Integratoren fuer diese kundenspezifische Klempnerei einzusetzen, gibt es schon lange. Die Leute waren da sehr realistisch.
Der Hauptunterschied liegt meiner Meinung nach bei der Automatisierung. Das ist der entscheidende Unterschied. Denn wenn es nur darum geht, ein System of Record einzurichten und Ihre System-of-Record-Daten zu sammeln, konnte man das mit Integratoren tun, die typischerweise gut mit Systemen of Record waren. Diese Dinge sind wirklich nicht intelligent. In Bezug auf Softwaredesign sind es im Grunde CRUD-Anwendungen: Create, Read, Update, Delete. Das ist so vanilla, wie es nur sein kann.
Sie haben eine einfache Funktion: Datensaetze pflegen. Aber Automatisierung ist etwas anderes. Wir bei Lokad konzentrieren uns auf Entscheidungen, aber sogar vor den Entscheidungen gibt es sehr viele Dinge, die einfach grundlegende Automatisierungen sind. Und hier sehe ich viele Hindernisse fuer Automatisierung, vor allem weil man, sobald es einen Freitexteintrag, ein unstrukturiertes Datenelement, ein Bild oder irgendetwas dergleichen gab, feststeckte und einen Menschen in die Schleife setzen musste. Mit diesen KI-Technologien kann praktisch die Gesamtheit der banalen Automatisierung umgesetzt werden. Ich spreche noch nicht einmal von der eigentlichen Entscheidungsebene wie bei Lokad.
Ich meine Dinge wie: Ein Kunde soll eine Kopie seines Ausweises schicken. Man bekommt ein Bild. Ist es ein Bild eines Ausweises? Ja.
Nein. Wenn man kein System hat, das sagen kann, ob es ein Bild eines Ausweises ist, ja oder nein, dann braucht man einen Menschen, der hinschaut und dazwischen sitzt. Deshalb ist Automatisierung meiner Meinung nach viel breiter als Entscheidungen. Es sind buchstaeblich all die supergranularen Schritte Ihrer Prozesse, und die meisten davon sind sehr folgenarm. Sie muessen einfach erledigt werden, und man will nur, dass sie ohne Menschen in der Schleife erledigt werden, obwohl es unglaublich banale Dinge sind. Die Einsaetze sind nicht besonders hoch, es ist sehr geradlinig. Aber wenn man sich nur das CRUD-Paradigma ansieht, also Create, Read, Update, Delete, gibt dieses Paradigma einem keinen Weg, das zu automatisieren. Man braucht also ein bisschen mehr. Und dort koennen Forward Deployed Engineers meiner Meinung nach viel Wert liefern: indem sie im Wesentlichen die Intelligenz bereitstellen, die noetig ist, um Automatisierung jenseits von CRUD zu liefern, denn die meisten Integratoren sind nicht in der Lage, ueber CRUD hinauszugehen.
Conor Doherty: Absolut. Das ist ein Punkt, der eine Klarstellung verdient. Der Kontext der Diskussion hier, zumindest groesstenteils, und besonders soweit es den Vergleich mit der Lokad-Ebene betrifft, also der System-of-Intelligence-Ebene: Der groesste Teil meiner Recherchen und der Stellen, die ich mir angesehen habe, dreht sich im Grunde darum, KI-Code zu bauen, der Menschen hilft, Entscheidungen zu treffen. Um das Beispiel eines ERP als System of Record zu nehmen: Das ist ein System of Record.
Man hat seine Transaktionsdaten. Wie kommt man von dort zu den Entscheidungen, die man heute, morgen und so weiter treffen sollte? Genau dort setzen viele Leute Forward Deployed Engineers ein, oder zumindest im Bereich Unternehmenssoftware. Dort werden sie platziert.
Und das ist in ihrer Sprache im Grunde eine Mission. Man geht hinein, es kann sechs Monate dauern, ein Jahr, vielleicht zwei Wochen. Im Gegensatz dazu ist der Supply Chain Scientist, wenn du darueber sprichst, keine kurzfristige Sache. Es ist aus sehr konkreten Gruenden eine laufende Beziehung.
Joannes Vermorel: Ja. Ich meine, vor allem deshalb, weil fast alles, was der Markt unter Forward Deployed Engineers versteht, keine Entscheidungen sind. Es ist einfach die Automatisierung des Banalen. Die Entscheidung wurde bereits getroffen.
Die Frage ist buchstaeblich nur: Automatisiere. Und wenn ich automatisieren sage, denken Sie an Dinge, die sehr einfach sein koennen. Zum Beispiel erscheint ein Datensatz auf einem Bildschirm und muss in manchen Situationen per Copy-and-Paste in Software A und in anderen Situationen in Software B uebertragen werden, und die Grenze zwischen diesen beiden Faellen ist ein bisschen unscharf. Das ist die Art Situation, in der man boom, einen Forward Deployed Engineer einsetzen kann. Wenn man eine hyper-einfache Regel hat, die man in Excel codieren kann, braucht man diese Leute nicht. Wenn es aber nuancierter ist, dann ja, vielleicht braucht man sie. Meine Ansicht ist, dass Profitabilitaet nur erreicht wird, wenn sie Menschen aus dem Bild entfernen. Wenn es keinen erheblichen Netto-Produktivitaetsgewinn gibt, gibt es keine Kapitalrendite. Und noch einmal: Wenn Sie sagen, dass Ihre Mission zeitlich begrenzt ist, dann beschaeftigen Sie sich per Definition nicht mit Entscheidungen.
Conor Doherty: Das ist ein fairer Punkt.
Joannes Vermorel: Ja, das ist ein fairer Punkt. Eine Entscheidung, also etwas, an dem finanzielle Einsaetze haengen, muss ueberwacht und ueberarbeitet werden. Deshalb verschwinden die Supply Chain Scientists nicht.
Deshalb bleiben sie, wenn wir eine Initiative mit einem Kunden starten. Wenn man eine numerische Rezeptur schreibt, die buchstaeblich Millionen von Dollar pro Tag ausgeben kann, dann tut sie das, denn wenn man empfiehlt, was nachbestellt werden soll, gibt diese numerische Rezeptur die Nachbestellliste aus. Das ist buchstaeblich Ihre Ausgabenliste. Es sind Dollars, die aufgrund dieser numerischen Rezeptur ausgegeben werden. Sie muss gewartet werden, denn sie nicht zu warten, waere Wahnsinn.
Irgendwann gibt es eine Marktveraenderung. Sie wird die Annahmen Ihrer numerischen Rezeptur entkraeften, und es wird eine Katastrophe. Wartung ist also offensichtlich noetig, und man braucht jemanden Klugen fuer diese Wartung. Wenn wir aber ueber grundlegende Automatisierungen sprechen, dann nein. Man kann etwas haben, bei dem man jemanden Klugen braucht, um die Automatisierung zu bauen, aber danach kann diese Automatisierung im Grunde bis ans Ende der Zeit laufen.
Nehmen wir zum Beispiel die Erkennung von Schecks mit Handschrift. Sobald man ein Setup hat, das diese Handschrifterkennung leisten kann, kann es ziemlich unbegrenzt laufen. Aber im Kern ist es nichts mit hohen Einsaetzen. Es ist einfach Handschrifterkennung: Man bewahrt das Bild auf, hat die Erkennung und kann automatisieren.
Das ist in Ordnung. Man muss nicht unbedingt den Ingenieur behalten, der den Handschrifterkennungsalgorithmus entworfen hat.
Conor Doherty: Mir faellt auf, dass eine Kerndimension, die es hier wirklich zu untersuchen lohnt, die Frage ist, ob man einen FDE ueber ein anderes Unternehmen engagiert oder mit Lokad arbeitet und einen Supply Chain Scientist hat. Der entscheidende Punkt ist: Man holt einen Experten herein, der zu diesem Zeitpunkt das Unternehmen noch nicht kennt, den Code noch nicht geschrieben hat oder ihn nicht geschrieben haben sollte, weil er Interviews fuehren muss, die Supply Chain verstehen muss, um diese Informationen zu extrahieren und vermutlich Domaenenexpertise anzuwenden. Ja, ich glaube nicht, dass wir in der Lage sind, zu kommentieren, wie ein FDE das macht. Wir haben keine FDEs.
Wie geht ein Supply Chain Scientist daran heran? Also Tag eins, er spricht mit Kunden. Auf dem Papier klingt es sehr einfach: mit Leuten reden, Informationen sammeln. Aber welche Art von Information ist im Supply-Chain-Kontext relevant, damit ein FDE oder ein SCS anfangen kann, Code zu bauen? Du kannst dir ein beliebiges Spielzeugproblem aussuchen.
Joannes Vermorel: In unserem Fall bei Lokad muss der Supply Chain Scientist im Wesentlichen die Applikationslandschaft sondieren. Das wird eine technische Diskussion mit der IT, um zu verstehen, welche Daten verfuegbar sind. Die Regel lautet: Die Daten sind, was sie sind. Also nicht beschweren. Das Unternehmen schafft es, mit diesen Daten zu arbeiten. Daher ist die Standardannahme: Es reicht.
Es ist nie perfekt, aber es reicht. Das ist also die Landschaft sondieren. Das ist wirklich ein grosser Teil. Der andere Teil besteht darin, zu verstehen, was das Unternehmen eigentlich fuer den Markt, mit seinen Partnern, tut und wie all das quantifiziert werden sollte, um ein oekonomisches Modell des Unternehmens zu haben.
Das muss Sinn ergeben, denn der Supply Chain Scientist wird dafuer verantwortlich sein, eine numerische Rezeptur zu gestalten. Diese neue numerische Rezeptur wird die Daten konsumieren. Das ist Punkt eins. Aber am Ende wird sie alle verschiedenen Optionen, die wir haben, in Euro oder Dollar bewerten.
Und damit diese Bewertung nicht unsinnig ist, braucht man ein tiefes Verstaendnis des Geschaefts. Man muss verstehen, was die Kunden tatsaechlich schaetzen. Welche Einschraenkungen fuer die Lieferanten wirklich schmerzhaft sind. Wo die Engpaesse in der Supply Chain liegen.
Was als knappe Ressource zaehlt. Alles ist knapp, ja, aber manche Dinge in der Supply Chain koennen viel knapper sein. Man kann an sehr spezifischen Stellen blockiert sein. Das muss man wissen.
Und dann muss man im Wesentlichen auch alle Kraefte modellieren, die dauerhafte Effekte haben, aber unmittelbar schwer zu bewerten sind. Ein Beispiel waere: Wenn man teurer verkauft als die Wettbewerber, bei ansonsten gleichen Bedingungen, dann gibt es ueber die Zeit Abwanderung. Man verliert allmaehlich Marktanteile. Wenn alles andere gleich ist und man nur ein wenig teurer ist als die Wettbewerber, werden die Kunden im Laufe der Zeit zu den Wettbewerbern gehen, es sei denn, der Markt ist reguliert oder aehnliches.
Das bleibt aber ueber Wochen unsichtbar, weil es viele Gewohnheiten gibt und so weiter. Der Supply Chain Scientist ist also da, um eine kluge langfristige Perspektive auf die Oekonomie des Unternehmens zu haben, gestuetzt auf die Daten, aber nicht blind gegenueber langfristigen Effekten, die nur verstanden und, ich wuerde sagen, abgeschaetzt werden koennen. Sie koennen nie wirklich gemessen werden, denn wir werden keine Experimente ueber ein Jahrzehnt laufen lassen. Es gibt viele Dinge, die nur aus einem Verstaendnis auf hoher Ebene kommen koennen. Ein Beispiel: Wenn man im harten Luxus taetig ist, will man keinem Kunden jemals Rabatte geben. Wenn man eine teure Uhr verkauft, will man dem Kunden sagen: Sie geben kein Geld aus, das ist eine Investition. Diese Uhr wird in zehn Jahren sogar noch mehr wert sein. Ob das wahr sein wird oder nicht, ist eine andere Frage. Aber wenn man mit Rabatten anfaengt, kann es sicher nicht wahr sein. Deshalb muessen viele Dinge nur aus einem Verstaendnis auf hoher Ebene kommen, und man wird keine Experimente mit Kunden machen, um diese Dinge zu bewerten.
Conor Doherty: Ach, also du…
Joannes Vermorel: Nein.
Conor Doherty: Ach, weil ich “Zeithorizonte” notiert hatte. Ich moechte ueber Bewertung sprechen, wieder ueber die Bewertung der Wirkung des Experten. Ob es ein FDE ist oder ein SCS, ist fuer die Diskussion egal. Aber du hast gerade ein sehr gutes Beispiel genannt, und das hat bei mir eine Idee angestossen, die ich vor ein paar Tagen im Buero gehoert habe. Ich werde nicht sagen, von wem, aber es ging um Luft- und Raumfahrt, um Bestellungen fuer Triebwerke.
Der springende Punkt bei diesem Kunden ist: Es ist per Definition eine mehrjaehrige Verpflichtung. Ich gehe nicht ins Detail, weil es vielleicht oeffentlich bekannt ist, aber jedenfalls kaufen sie, sagen wir, zehn Triebwerke. Und der Zeithorizont fuer dieses Projekt, an dem sie arbeiten, liegt bei ungefaehr fuenf Jahren. Also werden sie realistisch erst in fuenf Jahren wissen: War es am 27. August eine gute Idee, all diese Triebwerke zu kaufen?
Wenn man einen FDE hat, ist diese Person laengst weg. Wenn man aber weiterhin mit Lokad arbeitet, gibt es zumindest Kontinuitaet in der Bewertung.
Joannes Vermorel: Ja. Und es geht in beide Richtungen. Meine Ansicht ist, dass FDEs Produktivitaetsgewinne liefern sollten, die buchstaeblich vollstaendig am Tag des Missionsendes bewertet werden koennen.
Conor Doherty: Okay.
Joannes Vermorel: Man hat also einen Prozess, der automatisiert werden soll. Man geht potenziell von 100 Menschen, die die Arbeit tun, auf null, vielleicht einen zur Ueberwachung. Das ist das Lieferobjekt. Der FDE, noch einmal, weil wir nicht auf der Entscheidungsebene sind, hat keine solchen Einsaetze.
Man automatisiert Dinge vollstaendig. Man entfernt die Menschen, und das ist die Gewinnbedingung. Es gibt keine andere. Kann ich diese Arbeit, die von 100 Menschen erledigt wurde, im Wesentlichen von null Menschen mit etwas IT-Ueberwachung erledigen lassen, damit alles reibungslos weiterlaeuft? Das ist es. Ein Beispiel, das wir bei Lokad gemacht haben, ist die Uebersetzung unserer Website in viele Sprachen. Sie ist jetzt vollstaendig automatisiert. Die Frage ist also nur, die Automatisierung zu ueberwachen, nicht Uebersetzer zu spielen.
Conor Doherty: Wir haben aber Entscheidungen.
Joannes Vermorel: Ich verstehe. Genau das sage ich: FDEs werden sich nicht mit Entscheidungen befassen. Stellen Sie es sich eher wie Uebersetzung vor. Das ist eine viel bessere Art Aufgabe. Ja, sie erfordert Intelligenz. Ja, man kann nichts mit einem primitiven Setup uebersetzen. Create, Read, Update, Delete in Ihrer SQL-Datenbank kann keine Uebersetzung leisten. Das ist, worin FDEs gut sind. Man nimmt einen Prozess, der sehr klar definiert ist. Man weiss, was am Ende der Pipeline herauskommen soll. Und was man neu konstruiert, ist: Man entfernt die Menschen aus dem kritischen Pfad. Man robotisiert dieses Stueck.
Und der Grund, warum die Mission enden kann, ist wiederum, dass keine Entscheidung beteiligt ist. Keine echte Entscheidung, nicht in dem Sinn, wie ich sie in diesem Buch definiere, naemlich als Allokation von Ressourcen. Es gibt keine Allokation von Ressourcen.
Es ist einfach ein Prozess, bei dem etwas getan werden musste und nun im Grunde unbeaufsichtigt getan wird. Es gab keine spezifischen Einsaetze. Es musste getan werden, und jetzt wird es automatisch getan, waehrend es mit dem jeweiligen Qualitaetsziel konform bleibt. Das ist alles.
Conor Doherty: Apropos Qualitaetsziele: Mein naechster Punkt war, und ich nenne wieder keine Namen, aber ich empfehle jedem, der zuhoert, einfach nach Deployed Engineers und Ihrer Stadt und dann dem Wort Jobs zu suchen. Dann wissen Sie, wovon ich spreche. Ich gebe also eine repraesentative Beschreibung der Bewertungskriterien fuer einen FDE nach vielen Unternehmen, die solche Stellen ausschreiben. Es ist Produktakzeptanz. Das ist natuerlich nicht trivial, denn wenn man etwas baut und buchstaeblich niemand es nutzt, ist das ein Problem.
Es koennte die beste Entscheidungssoftware der Welt sein, aber wenn niemand sie nutzt, ist das ein Problem. Das verstehen wir alle. Reicht das aber an und fuer sich, um zu sagen: Das war eine lohnende Ausgabe von Geld, Zeit, Aufwand und Gelegenheit? Fuer den Softwareanbieter ist Adoption im Sinne von: Viele Menschen verbringen viel Zeit damit, superwichtig, denn so schafft man Bindung.
Joannes Vermorel: Ja.
Conor Doherty: Aber fuer das empfangende Kundenunternehmen ist es eine massive Falle.
Joannes Vermorel: Ja. Man will nichts, das adoptiert wird. Man will etwas, das einfach laeuft.
Conor Doherty: Entfalte das bitte, denn ich habe es dort nicht verstanden.
Joannes Vermorel: Wie hoch ist die Adoptionsrate Ihres Anti-Spam-Filters?
Conor Doherty: Ah, okay. Ich verstehe.
Joannes Vermorel: Haben die Leute den Anti-Spam adoptiert? Nein. Der Anti-Spam ist da. Er erledigt seine Arbeit, und man bemerkt nicht einmal mehr, dass man einen Anti-Spam hat.
Er ist einfach da. Er macht die Arbeit, und er macht sie ausserordentlich gut. 99 Prozent Ihrer Muell-E-Mails werden gefiltert. Sie merken nie, dass er da war. Es wurde erledigt.
So sieht Automatisierung aus. Ja, so sieht Automatisierung aus. Sie fuegt sich ein, und dann ist es erledigt. Das Problem ist, wenn Menschen bei Automatisierung von Adoption sprechen: Worueber reden wir eigentlich?
Gibt es wirklich eine Adoptionsherausforderung fuer Anti-Spam? Historisch gab es eine, weil Anti-Spam-Filter Ende der 90er Jahre sehr schlecht waren. Deshalb mussten Menschen Regeln anpassen und viel tun, damit es halbwegs funktionierte, damit die Dinge fuer ihr Postfach zumindest halbwegs vernuenftig waren. Heute ist es im Allgemeinen exzellent, und normalerweise haben Unternehmen, die als Spam markiert werden, es sich selbst zuzuschreiben, weil sie Millionen E-Mails geschickt haben und von Millionen Menschen als “Das ist Spam” markiert wurden. Deshalb sind ihre E-Mails nun eben Spam.
Das Problem, das ich habe, ist: Wenn Menschen erfolgreiche Technologie mit Adoption gleichsetzen, uebernehmen sie sehr stark die Metriken des Softwareanbieters, des Technologieanbieters. Und was ich sage: Im B2B-Geschaeft will man keine Software, die Ihre Mitarbeiter taeglich viele Minuten beschaeftigt. Jede Minute, die Ihr Mitarbeiter mit Software verbringt, kostet Ihr Unternehmen Geld. Sie wollen, dass die Sache das Problem so vollstaendig adressiert, dass diese Probleme unsichtbar werden. Es wird zum Grundrauschen Ihres Unternehmens, und niemand denkt ueberhaupt daran.
Es ist einfach da. Es erledigt die Dinge.
Conor Doherty: Aber um dorthin zu kommen, und ich stimme zu, und mir gefaellt die Analogie, geht man nicht einfach von null… Es ist nicht realistisch null auf eins, das wissen wir. Es gibt Automatisierung.
Joannes Vermorel: Nein. Bei Automatisierung ist es immer strikt null zu eins. Ich habe es nie anders gesehen. Denken Sie an Dinge mit niedrigen Einsaetzen. Vor etwa 15 Jahren habe ich Menschen in Versicherungsunternehmen gesehen, deren Job einfach war: Knopf druecken, bestaetigen, ob es ein Ausweis ist, ja, nein, Knopf druecken, naechstes Bild, bestaetigen, ob es ein Ausweis ist. Da war es immer null zu eins.
Das Problem ist der komplette Trugschluss von Crawl-Walk-Run. Nein. Bei Automatisierung funktioniert es nicht so. Wenn es um Millionen Dollar geht, ist das etwas anderes. Deshalb sage ich, wir reden nicht ueber dasselbe. Lokad operiert im Bereich der Entscheidungen, finanzieller Entscheidungen. Das sind hochgradig finanziell folgenreiche Entscheidungen. Dort liegt der Unterschied. Und wir sprechen ueber Entscheidungen, fuer die es keine obere Grenze gibt, wie gut sie getroffen werden koennen. Gehen wir zurueck zu einer Software, die ein Bild klassifiziert: Ist es ein Ausweis?
Ja oder nein? Wenn man etwas hat, das nach einer Bewertung bereits weit ueber der Genauigkeit eines Menschen liegt, dann ist man fertig. Es gibt keinen Punkt, weiterzugehen. Und wenn es keine gegnerischen Spielchen gibt, bei denen Menschen betruegen koennen oder dergleichen, und es gibt viele Situationen, in denen es keine gibt, dann ist die Aufgabe geloest. Man hat das Problem vollstaendig geloest, und das war’s. Man muss zu etwas anderem uebergehen.
Das ist die Art von Problemen, von denen ich spreche. Eine KI-Version waere zum Beispiel: Ihr Lieferant schickt Ihnen ein PDF, eine Rechnung, und Sie wollen aus diesem PDF die Rechnungsnummer in der Kodierung Ihres Lieferanten extrahieren. Das kann automatisch gemacht werden. Sobald man das hat, ist es erledigt.
Ja, jemand koennte das PDF oeffnen und per Copy-and-Paste arbeiten, aber wenn man eine Automatisierung hat, die das tut, dann ist es erledigt. Wenn Ihre Bewertung sagt, dass Sie nahezu perfekt sind, dann gibt es keinen Sinn in gradueller Adoption. Das ergibt keinen Sinn. Deshalb sage ich: Bei Automatisierung gibt es nur null und eins, niemals graduelle Adoption.
Conor Doherty: Wenn wir Aepfel mit Aepfeln vergleichen, also fuer Unternehmen, die FDEs als Dienstleistung anbieten oder verkaufen, um die Art Entscheidungssoftware zu bauen, die wir vielleicht ebenfalls bauen, dann sprechen wir ueber andere Bewertungsmetriken. Fuer dich, du hast es vorhin erwaehnt, nicht explizit, eher angedeutet, ging es um finanzielle Entscheidungen, finanzielle Wirkung. Die klare Linie fuer dich ist: Die einzige Art, einen Experten zu bewerten, den man hereinholt, um Entscheidungen zu treffen, also: Nimm dieses Geld und kaufe das, allokiere diesen Bestand dort, plane diese Leute fuer diese Dinge ein, muss der finanzielle Effekt sein. Das ist zumindest der Nordstern.
Joannes Vermorel: Ja. Ich wuerde sagen: oekonomisch. Der Unterschied ist, dass es bei oekonomischem Denken Dinge gibt, die nicht in Ihrer Finanzrechnung auftauchen, zum Beispiel alle langfristigen Effekte.
Conor Doherty: Richtig.
Joannes Vermorel: Etwa Goodwill. Man will seine Kunden nicht veraergern und Dinge tun, die direkte und indirekte Kosten zerstoeren.
Conor Doherty: Genau.
Joannes Vermorel: Alle indirekten Kosten, all die Dinge, bei denen man langfristig denken muss. Ihre oekonomische Perspektive ist also viel vorausschauender als die finanzielle, die eher die kurzfristige Version der oekonomischen Perspektive ist.
Conor Doherty: Koenntest du fuer alle, die zuhoeren, kurz auspacken, was du mit Goodwill meinst? Das ist vielleicht nicht sofort klar, und auch wie man diesen oekonomischen Treiber oder diese oekonomische Perspektive etwas auspacken kann. Das ist ein sehr interessanter Punkt.
Joannes Vermorel: Wenn Sie zum Beispiel Kunden in einem E-Commerce-Shop Waren kaufen lassen und ihnen sagen, dieser Artikel werde in weniger als sieben Tagen geliefert, Sie aber in, sagen wir, 30 Prozent der Faelle Ihr Ziel verfehlen. Kurzfristig kann ein Versprechen mit kurzer Lieferzeit Ihre Verkaeufe steigern. Aber wenn ein erheblicher Prozentsatz fehlschlaegt und Sie die Liefertermine verpassen, die Sie Ihren eigenen Kunden genannt haben, dann bauen Sie sich einen schrecklichen Ruf auf. Und Sie werden mit der Zeit Marktanteile verlieren. Es zeigt sich vielleicht nicht sofort, aber es wird sich mit der Zeit zeigen.
Deshalb haben zum Beispiel vor einigen Jahren, heute geschieht es nicht mehr so haeufig, manche E-Commerce-Plattformen gesagt: “Wir haben es auf Lager”, obwohl das nicht wahr war. Wenn man einen Artikel online anzeigt und sagt: “Ich habe ihn auf Lager”, dann verdoppelt man wahrscheinlich die Verkaeufe im Vergleich zu demselben Produkt mit dem Hinweis: “Ich habe ihn nicht auf Lager, aber ich bestelle ihn, wenn Sie bestellen.” Aber wenn man gegenueber Kunden nicht ehrlich ist, ruiniert man einfach seinen Ruf, und in ein paar Jahren hat man alle Marktanteile verloren, wenn man solche Dinge spielt. Das ist der Goodwill, von dem ich spreche: im Wesentlichen das gesamte Vertrauen, das Ihre Kunden in Sie haben, um in Zukunft weiter mit Ihnen Geschaefte zu machen.
Conor Doherty: Ja, die oekonomische Perspektive, und ich bevorzuge den Begriff oekonomische Perspektive.
Joannes Vermorel: Das ist korrekt.
Conor Doherty: Es ist gut, das von der finanziellen Perspektive zu klaeren. Aber Menschen dazu zu bringen, das zu schaetzen, ist meiner Meinung nach ein Kernbestandteil der Perspektive des SCS oder FDE, jedenfalls bei uns der Perspektive des SCS. Zum Beispiel Strafkosten bei Fehlbestand: Die Kosten, etwas nicht zu haben, erscheinen nicht unbedingt direkt, aber sie existieren natuerlich. Wenn man etwas nicht hat, verkauft man es nicht.
Joannes Vermorel: Und wenn man in FDE-Begriffen denkt: Sobald man sagt, diese FDEs sind nicht nur fuer banale Automatisierung da, sondern sollen die Entscheidungsebene beruehren, dann braucht man meiner Meinung nach Vertikalisierung. Man braucht Menschen, die Experten der Domaene sind. Wenn man nur banale Automatisierung betreibt, ist es in Ordnung. Man nimmt kluge Software Engineers, sie koennen FDEs sein, sie werden es loesen. Wenn man aber die Entscheidungsebene beruehren will, kann man nicht einfach Menschen haben, die angeblich universell in allem kompetent sind. Das wird nicht funktionieren. Man braucht vertikale Expertise, um dieses korrekte oekonomische Verstaendnis zu haben.
Conor Doherty: Aber kann ich das nicht einfach erheben? Zum Beispiel: Tag eins, ich bin ein FDE. Ich komme an. Okay.
Wie stark variieren Ihre Lieferzeiten im Durchschnitt? Kann ich diese Information nicht einfach erfragen? Warum muss ich Domaenenexperte sein? Warum kann ich nicht einfach technisch brillant sein und Fragen stellen?
Joannes Vermorel: Wenn wir annehmen, dass Sie Leonardo da Vinci sind, ein polymathisches Genie.
Conor Doherty: Ja.
Joannes Vermorel: Okay. Aber wenn Sie frisch von der Uni kommen, sind Sie das vielleicht nicht. Meine Erfahrung bei Lokad war: Wenn wir kluge Leute von einer sehr guten Top-Schule, Ivy League, nehmen, dauert es etwa zwei Jahre, bis sehr brillante Menschen eine, sagen wir, korrekte High-Level-Einschaetzung dessen haben, was in der Supply Chain eines grossen Unternehmens vor sich geht. Dieses Urteilsvermoegen zu kultivieren, braucht Zeit. Unser Ziel bei Lokad ist typischerweise: Innerhalb von sechs Monaten kann aus einer sehr klugen Person jemand werden, der ein Konto betreuen kann. Viele der superkritischen architektonischen Entscheidungen ueber das Design der numerischen Rezeptur wurden dann zum Beispiel bereits getroffen.
Es geht also darum, ein System zu warten. Das kann in sechs Monaten erreicht werden. Aber um diese Entscheidungen akkurat und weise selbst zu treffen, dauert es eher zwei Jahre, selbst wenn man mit sehr klugen Menschen beginnt und sich exklusiv auf eine Vertikale konzentriert.
Conor Doherty: Ja. Das stimmt.
Joannes Vermorel: Das Problem ist: Wenn Menschen eine Mission nach der anderen machen und es kurze Missionen von nur wenigen Monaten sein sollen, gibt es keine Magie. Sie werden nicht in der Lage sein, diese oekonomische Perspektive richtig zu entwickeln. Wenn solche Menschen also anfangen, auf der Entscheidungsebene zu arbeiten, wird das meiste, was daraus entsteht, unsinnig sein. So ist es einfach. Und bei Lokad war es selbst fuer uns in den ersten fuenf Jahren extrem schwierig. Die fruehen Jahre von Lokad waren grauenhaft.
Ich hatte nicht begriffen, was ich haette begreifen muessen. Zu meiner Verteidigung: Fast alle Buecher ueber Supply Chain sind voellig unsinnig, und sie sind es immer noch.
Conor Doherty: Das haben wir, glaube ich, schon behandelt.
Joannes Vermorel: Trotzdem habe ich mich effektiv genau wie ein FDE ohne echte vertikale Expertise verhalten, und ja, das hat zu viel Schmerz und Elend gefuehrt. Meine Empfehlung ist also: Wenn Unternehmen FDEs einsetzen, sollten sie sicherstellen, dass diese sich auf strikte und absolute Automatisierung konzentrieren, bei der das Kriterium sehr einfach Headcount ist. Und fuer die Entscheidungsebene sollte man absolut sicherstellen, dass man Menschen hat, die wirklich vertikalisiert sind. Wenn man darueber nachdenkt, ist es gesunder Menschenverstand. Lokad befasst sich mit Supply-Chain-Problemen. Aber stellen Sie sich vor, Sie wollen jemanden einstellen, der mit Finanzbetrug in Banksystemen umgeht. Das ist ein unglaublich spezialisiertes Gebiet. Ich wuerde nicht behaupten, genau zu wissen, wie Betrueger und Scams funktionieren, wenn sie buchstaeblich versuchen, Banken zu betruegen und transnationale Konstrukte mit falschen Identitaeten, falschen Papieren und so weiter aufzubauen. Das ist nicht meine Expertise. Wenn man glaubt, man koenne einfach einen klugen Ingenieur frisch von der Ingenieurhochschule holen und Probleme loesen, die sehr tiefgehende vertikale Spezialisierung erfordern, wird es nicht funktionieren. Diese Menschen brauchen Zeit, moeglicherweise Jahre, um echte Domaenenexperten zu werden. Und das untergraebt das Versprechen des FDE-Modells: Man stellt diese Leute ein, sie machen ihre dreimonatige Mission, zack, Amortisation, sie gehen nach Hause, und man hat einen profitablen Return on Investment.
Conor Doherty: Fuer alle, die zuhoeren, und das baut auf der Idee auf: Man hat die technischen Faehigkeiten, aber noch nicht die Domaenenexpertise. Woher weisst du, und ich frage nach deiner anekdotischen Erfahrung, ob jemand ein guter SCS waere? Wenn sie frisch von einer Grande ecole kommen, wissen sie offensichtlich noch nichts ueber Supply Chain oder sehr wahrscheinlich nichts ueber die Besonderheiten und Eigenheiten.
Also: Woher weisst du, Joannes, dass diese Person eine gute Investition ist, dass sie ausreichende Faehigkeiten hat und so weiter?
Joannes Vermorel: Wir bewerten im Allgemeinen einfach die rohe Lernfaehigkeit, das ist alles. Und ich glaube, die meisten Unternehmen, die FDEs verkaufen, machen genau dasselbe. Sie sagen: Wir nehmen kluge Menschen, die sehr schnell lernen koennen, und wir horten dieses Talent. Das funktioniert. Ich sage nicht, dass es nicht funktioniert. Ich sage nur: Wenn man auf der Automatisierungsebene arbeitet, muss man Menschen in der Kunst des Softwaremachens trainieren, und dann ist alles in Ordnung. Das ist sehr agnostisch. Man kann eine vollstaendig horizontale Perspektive haben, in der sie jede Vertikale angehen koennen, und es wird funktionieren, wenn es nur um strikte Automatisierung geht.
Wenn man sich aber mit der Entscheidungsebene befassen will, dann nimmt man kluge Menschen, und diese Menschen muessen fuer diese Vertikale ausgebildet werden. Die Frage lautet also: Sie kaufen einen FDE, einen Forward Deployed Engineer, fuer Ihre Vertikale. Wurde dieser FDE explizit fuer diese Vertikale ausgebildet, ja oder nein? Wenn das Unternehmen sagt: “Nein, wir stellen einfach die Besten ein.
Vertrauen Sie uns, es wird gut gehen.” Es wird nicht gut gehen. Was ich sage: Wenn man jemanden haben will, der sich mit einer Entscheidungsebene befasst, die bei fortgeschrittenen Betrugssituationen im Bankensystem entscheidet, dann sollte diese Person besser ein echtes Verstaendnis dessen haben, was im Bankensystem passiert. Wenn man jemanden haben will, der fuer ein fortgeschrittenes medizinisches Diagnosesystem entscheidet, bei dem es um das Leben von Patienten geht, dann moechte ich, dass diese Person in den medizinischen Wissenschaften sehr kompetent ist und zugleich Software Engineer.
Wenn man darueber nachdenkt, ist es wirklich offensichtlich.
Conor Doherty: Gut, okay. Ja. Ja.
Ich stimme zu.
Joannes Vermorel: Um aber darauf zurueckzukommen und noch einmal das Krankenhaus zu nehmen, um zwei FDE-Missionen zu kontrastieren: Mission eins, und ich habe beide gesehen, ist, dass Menschen in mehreren Abteilungen des Krankenhauses mehrfach registriert werden und man deshalb abgleichen muss, dass es tatsaechlich derselbe Patient ist.
Conor Doherty: Ja.
Joannes Vermorel: Sonst endet man mit vielen Duplikaten, weil sich viele Menschen hier und dort registrieren, es Probleme gibt, und dann gibt es viele doppelte Datensaetze. Man wird dieses Problem des Abgleichs all dieser Duplikate nicht mit einem primitiven Setup loesen koennen. Also holt man einen FDE, und diese Leute bauen die Automatisierung, um diese Duplikate abzugleichen.
Conor Doherty: Perfekt.
Joannes Vermorel: Nun, das ist ein Problem, das keine echte medizinische Expertise erfordert. Es geschieht in einem Krankenhaus, aber am Ende des Tages geht es um den Abgleich identischer Menschen mit moeglichen Tippfehlern in Vorname, Nachname, Adresse, Telefonnummer und so weiter. Wenn man aber etwas haben will, das bei irgendetwas Medizinischem Entscheidungen trifft, die folgenreich sind, fuer das Leben des Patienten und finanziell fuer das Krankenhaus, dann will man jemanden, der in den medizinischen Wissenschaften bewandert ist. Diese Linie ist in der Praxis nicht so subtil. Ich glaube, viele Unternehmen neigen dazu zu verwechseln, ob sie es mit intelligenter Automatisierung oder intelligenten Entscheidungen zu tun haben. Beides hat in der Praxis sehr unterschiedliche Dynamiken und sehr unterschiedliche Anforderungen.
Conor Doherty: Als abschliessender Gedanke: Wenn ich mindestens ein paar Schlussfolgerungen ziehen sollte, kannst du mir sagen, ob du dieser Einschaetzung zustimmst oder nicht. Ist es fair zu sagen, dass, basierend auf dem, was wir heute besprochen haben, und sicher auch auf dem Aufkommen und der Popularisierung dieser Rolle, die Behauptung, die wir seit ein paar Jahren, eigentlich seit mehreren Jahren, gehoert haben: Wenn man seine Entscheidungen optimieren will, kauft man einfach ein Zusatzmodul, steckt es ein, und schon ist man startklar, tot ist? Wuerdest du dem zustimmen?
Joannes Vermorel: Ja. Ja.
Conor Doherty: Ich meine, wir haben das immer gedacht. Aber glaubst du, dass es nie funktioniert? Glaubst du, dass der Mainstream jetzt stillschweigend sagt: “Ja, ja, das funktioniert nicht”? Das haette ich sagen sollen.
Joannes Vermorel: Ich weiss nicht. Klar sagen das die Anbieter, die FDEs verkaufen.
Conor Doherty: Ja. Nun, das stimmt.
Joannes Vermorel: Aber die anderen Anbieter, die keine FDEs verkaufen, sehen weiterhin das Gegenteil. Und ich wuerde sagen: Die Zeit wird es zeigen. Die Zeit wird es zeigen. Ich sehe aber immer noch, dass der Markt absolut voll ist mit ERP-Anbietern, die ein Modul zur Bestandsoptimierung verkaufen.
Es gibt immer noch etwa tausend Unternehmen, die das tun. Also wird die Zeit es zeigen. Vielleicht ja, mit der Zeit. Es ist klar ein interessanter Trend, aber ich bin nicht sicher, ob er bereits dominant ist. Ein Teil des Problems ist, dass die Unternehmen, die FDEs verkaufen, auch extrem teuer sind. Das ist auch eine der Schwaechen dieser sehr profilierten Unternehmen wie OpenAI, Anthropic oder Amazon: Es sind Unternehmen, die Gehaelter zahlen, die im Vergleich zu Marktnormen etwas extravagant sind. OpenAI hat zum Beispiel regelmaessig Menschen mit jaehrlichen Paketen im Millionenbereich eingestellt.
Das Problem ist wiederum: Ich bewerte nicht, ob diese Menschen es wert sind oder nicht. Ich sage nur: Wenn Ihre gesamte Kostenstruktur aus Sicht des Anbieters solche Menschen beruecksichtigen muss…
Conor Doherty: Ja.
Joannes Vermorel: Dann wird der Preis, den Sie fuer Ihren FDE verlangen, wahrscheinlich unangemessen hoch sein. Wenn man sich die Geschichte von Palantir ansieht, war das eine Geschichte von Hin und Her: Sie machen Fortschritte in der Domaene, dann wachsen sie wie verrueckt, dann skalieren sie zurueck, einfach weil sie extrem teuer sind und viele ihrer Kunden nach anfaenglicher Begeisterung sagen: Oh, das ist einfach zu teuer, wir muessen zurueckfahren.
Conor Doherty: Um diese Idee noch etwas auseinanderzunehmen: Wenn ich dich richtig verstanden habe, hast du mir im Kern zugestimmt. Dein Punkt ist, dass es, um es gut zu machen, was auch immer “es” ist, also ein KI-Projekt gut zu machen, unerschwinglich teuer sein kann. Und deshalb wird es weiterhin Leute geben, weiterhin Anbieter, die im Grunde, ich will nicht Schlangenöl sagen, aber verkaufen: “Ja, ja, kaufen Sie dieses Modul. Es wird alles optimieren.” Das ist eine billigere Alternative. Sie ist unvollkommen, aber eine billigere Alternative dazu, einen FDE zu kaufen.
Ich glaube also nicht, dass es da wirklich einen Widerspruch gibt. Es kann weiterhin als Produkt existieren, auch wenn die Existenz eines FDE das Optimierungsversprechen eines Optimierungsmoduls irgendwie untergraebt. Etwas philosophisch, aber ich glaube, das war der Punkt, auf den wir hinauswollten.
Joannes Vermorel: Ja. Ja. Genau.
Conor Doherty: Joannes, es hat mir sehr viel Freude gemacht, aber ich habe keine weiteren Fragen. Vielen Dank fuer deine Zeit. Und allen, die zugehoert haben, moechte ich sagen, dass bei Lokad Stellen fuer Supply Chain Scientists offen sind. Wenn Sie interessiert sind, schauen Sie auf LinkedIn vorbei oder schreiben Sie uns eine E-Mail an contact@lokad.com.
Und nachdem das gesagt ist, bleibt nichts anderes zu sagen als: Zurueck an die Arbeit.
