Optimierter Einkauf in der Luft- und Raumfahrt: gefuehrte Demo der Lokad-Loesungen

Back to Lokad TV

00:00:00 Einkauf in der Luft- und Raumfahrt: Unsicherheit und wirtschaftliche Prioritaeten
00:05:58 Flottentransparenz, Servicegradziele und Investitionskosten
00:11:47 Rotables, Verbrauchsteile und wirtschaftlich gereihte Investitionen
00:17:23 Prioritaeten unter Budget- und Betriebseinschraenkungen
00:23:56 Investitionen nach Servicegradgewinn pro Dollar reihen
00:29:43 Daten validieren und unsichere Nachfrage modellieren
00:35:48 Nachfrageunsicherheit und Durchlaufzeitunsicherheit kombinieren
00:41:42 Systemintegration und Desinvestitionsmoeglichkeiten
00:47:15 Austausch, Reparaturprioritaeten und Lieferantenintegration
00:53:29 Datenvorbereitung und Implementierungsanforderungen
00:58:44 Historische Simulationen und Nachvollziehbarkeit von Entscheidungen
01:04:10 Wirtschaftliche Prioritaeten, Verbrauchsteile und Lieferantenverzoegerungen
01:09:14 Wartungsprognosen und Nachverfolgung der Empfehlungstreue
01:14:05 Einkaufsautomatisierung, Beschaffungsplattformen und Reparaturprioritaeten
01:19:52 Wichtigste Erkenntnisse und Schlussbemerkungen

Zusammenfassung

Conor Doherty und Fabian Hoehner zeigen, wie Lokad unsichere Nachfrage, Reparaturzeiten und begrenzte Budgets in priorisierte Einkaufsentscheidungen fuer die Luft- und Raumfahrt uebersetzt. Der Ansatz bewertet jede zusaetzliche Einheit nach ihrem erwarteten Beitrag zum Servicegrad oder zur Vermeidung eines Aircraft-on-Ground im Verhaeltnis zu den Kosten. Dieselbe Logik unterstuetzt Desinvestitionen, Reparaturpriorisierung und Bestandstransfers. Lokad arbeitet neben bestehenden Systemen, wobei Supply Chain Scientists und operative Experten die Berechnungen verfeinern. Historische Simulationen helfen, vergangene Entscheidungen zu erklaeren, waehrend Automatisierung vom Wert und von der Komplexitaet der betroffenen Einkaeufe abhaengt.

Erweiterte Zusammenfassung

Der Einkauf in der Luft- und Raumfahrt bedeutet, zwischen konkurrierenden Verwendungen knapper Ressourcen zu entscheiden. Ein weiteres Ersatzteil kann das Risiko senken, ein Flugzeug am Boden zu halten, bindet aber zugleich Geld, das eine andere, wichtigere Operation schuetzen koennte. In dieser Live-Demonstration erklaeren Conor Doherty und Fabian Hoehner, wie Lokad solche Entscheidungen bewertet. Die zentrale Frage lautet, wie viel zusaetzlicher Servicegrad oder vermiedener AOG mit jedem Dollar realistisch erkauft werden kann. Daraus ergeben sich die Bestandsmengen, zusammen mit den Einschraenkungen, unter denen das Unternehmen arbeitet.

Die Demonstration beginnt mit einer beispielhaften Airline-Flotte und einem Pool von Rotables: Teilen, die repariert und wieder in Betrieb genommen werden koennen. Ihre Verfuegbarkeit haengt sowohl von der Nachfrage als auch von der Zeit ab, die sie in Reparatur- und Logistikprozessen verbringen. Fuenf eigene Einheiten schuetzen nicht genauso wie fuenf sofort verfuegbare, einsatzfaehige Einheiten. Lokad nutzt Transaktionsdaten aus bestehenden Systemen, um dieses operative Bild zu erstellen, und berechnet anschliessend Investitionsempfehlungen. Im Beispiel liefern rund 68 Millionen Dollar Bestand einen erwarteten Servicegrad von 95,7 %; eine zusaetzliche Investition von etwa 1,2 Millionen Dollar bringt es nahe an 98 %. Weitere Verbesserungen werden zunehmend teuer.

Die Empfehlungen werden Einheit fuer Einheit gereiht. Eine zusaetzliche Einheit eines bestimmten PNs konkurriert mit zusaetzlichen Einheiten anderer PNs, darunter Teile mit sehr unterschiedlichen Preisen und Nachfrageprofilen. Die erste Einheit deckt in der Regel mehr Unsicherheit ab als die zweite oder dritte. Dieser abnehmende Nutzen ist wichtig: Mehrere Einheiten desselben Teils zu kaufen kann weniger wertvoll sein, als die Investition zu verteilen. Auch die Kritikalitaet zaehlt. Ein relativ guenstiges No-Go-Teil kann eine hoehere Verfuegbarkeit rechtfertigen als ein teures Teil, dessen Fehlen weniger gravierende Folgen hat. Eine gereihte Liste erleichtert ausserdem die Anwendung von Budgetgrenzen, Einkaufskapazitaeten und Wareneingangsbeschraenkungen.

Solche Vergleiche erfordern einen realistischen Umgang mit Unsicherheit. Die Nachfrage in der Luft- und Raumfahrt ist oft sporadisch und unregelmaessig, waehrend Durchlaufzeiten stark schwanken koennen. Durchschnittswerte verbergen genau die Ausnahmesituationen, gegen die sich eine Airline absichern moechte. Lokad modelliert daher Verteilungen von Nachfrage und Wiederbeschaffungszeiten und kombiniert sie, um die Nachfrage ueber moegliche kuenftige Horizonte zu schaetzen. Hoehner zeigt, wie Reparaturen sich um eine kuerzere Dauer gruppieren koennen, wenn alles glatt laeuft, und um eine deutlich laengere Dauer, wenn Komplikationen auftreten. Dieses Muster durch einen einzigen Durchschnitt zu ersetzen, kann den erforderlichen Bestand falsch darstellen. Bekannte Wartungsereignisse, probabilistische Stuecklisten und Trends bei Durchlaufzeiten koennen die Berechnungen ebenfalls informieren.

Finanzielle Schaetzungen machen die entstehenden Zielkonflikte diskutierbar. Die Kosten eines AOG-Ereignisses koennen schwer zu bestimmen sein, aber eine ungefaehre Schaetzung gibt Teams eine Grundlage, um Entscheidungen zu vergleichen und Annahmen zu ueberarbeiten. Operatives Wissen bleibt wesentlich: Ein Sitzbezug oder eine Kaffeemaschine kann Folgen haben, die technische Lufttuechtigkeitsklassifikationen allein nicht erfassen. Nutzer pruefen Empfehlungen ueber Item Inspectors und unterstuetzende Dashboards, hinterfragen ueberraschende Ergebnisse und helfen, das Modell zu verfeinern. Teure Rotable-Einkaeufe erfordern meist weiterhin Expertenvalidierung und Lieferantenangebote; geringwertigere Verbrauchs- und Verschleissteile bieten mehr Spielraum fuer automatische Ausfuehrung.

Dieselbe Logik gilt fuer Desinvestitionen, Reparaturen und Allokation. Desinvestition vergleicht freigesetzte Liquiditaet mit aufgegebener Servicegradabsicherung. Reparaturpriorisierung identifiziert, welche nicht einsatzfaehigen Einheiten Ausgaben oder Beschleunigung am dringendsten rechtfertigen. Transfers vergleichen Transportkosten und erhoehtes Risiko am abgebenden Standort mit dem Nutzen anderswo und der Alternative, mehr Bestand zu kaufen. Diese wirtschaftlichen Entscheidungen sind verwandt, auch wenn jede eigene operative Details verlangt. Eine theoretische Desinvestitionsmoeglichkeit haengt zum Beispiel weiterhin davon ab, einen Kaeufer zu finden und einen realistischen Marktwert festzulegen.

Lokad arbeitet als System der Intelligenz neben Transaktionssoftware. Die Supply Chain Scientists passen die Loesung an die Daten und Prozesse des Kunden an; Lieferanten muessen keine neue Plattform einfuehren. Nuetzliche Entscheidungen zeigen auch, welche Datenmaengel Aufmerksamkeit verdienen, statt endlos zuerst alles bereinigen zu wollen. Hoehner nennt etwa sechs Monate als typische Implementierungsdauer, mit erheblicher Streuung. Historische Ausfuehrungen bleiben zur Untersuchung verfuegbar, sodass Teams eine Budgeteinschraenkung von einer schlechten Annahme oder einem akzeptierten Risiko unterscheiden koennen. Die uebergeordnete Disziplin ist fortlaufend: Unsicherheit quantifizieren, Folgen vergleichen und Entscheidungen verbessern, waehrend neue Evidenz entsteht.

Full Transcript

Conor Doherty: Willkommen zur allerersten Live-Demo von Lokad. Heute zeigen wir Ihnen, wie Lokad Investitions- und Desinvestitionsentscheidungen in der Luft- und Raumfahrt erzeugt. Heute zeigen wir Ihnen, welche PN Prioritaet haben sollte.

Heute zeigen wir Ihnen, wie ein begrenztes Budget aufgeteilt werden sollte, und wie Ihre Einschraenkungen, ob Lieferzeiten der Lieferanten, Turnaround Times, Kosten oder das Budget selbst, die Entscheidungen beeinflussen, die wir fuer Sie erzeugen. Dies ist eine Live-Veranstaltung, also stellen Sie bitte Ihre Fragen. Wir werden sie wahrscheinlich in etwa 30 Minuten beantworten. Haengt davon ab, wie lange wir scherzen.

Aber wer sind wir? Ich bin Conor, Marketing Director hier bei Lokad. Und bei mir im Studio ist mein sehr guter Freund und Director of Strategic Accounts, Fabian Hoehner. Guten Tag, Herr Hoehner, wie geht’s?

Fabian Hoehner: Hallo, Conor.

Conor Doherty: Das ist wunderbar. Also, Fabi, wie man in der Ecke des Bildschirms sehen kann, oder schon sehen koennen sollte, werden wir uns gleich ein Einkaufs-, ein Aerospace-Demo-Konto ansehen. Wir konzentrieren uns auf Einkauf, aber einige der Anwesenden und spaeteren Zuschauer kennen Lokad tatsaechlich noch nicht so gut. Einige schon, aber viele nicht.

Nehmen wir uns also eine Minute, bevor wir einsteigen. Koenntest du zwei kurze Fragen beantworten? Erstens: Wie genau sieht Lokad das Einkaufsproblem in der Luft- und Raumfahrt? Und zweitens: Wenn die Leute nur die ersten Minuten sehen, welche zwei, drei Kernkonzepte sollten sie mitnehmen?

Fabian Hoehner: Das hast du mich in der Vorbereitung nicht gefragt, also ist das…

Conor Doherty: Nein, habe ich nicht. Ich wollte Improvisation.

Fabian Hoehner: Ja. Okay. Es wird also eine Mischung aus Leuten geben, die vertraut sind, und solchen, die es nicht sind. Wir versuchen, auf hoher Ebene zu bleiben, aber in einigen Bereichen etwas tiefer zu gehen. Die zwei Dinge, die die Leute mitnehmen sollen, sind einerseits, wie wir mit Unsicherheit umgehen.

Unsicherheit bedeutet bei den Themen, ueber die wir sprechen, hauptsaechlich Lieferantenunsicherheit, also Turnaround Times und Lieferzeiten, und andererseits Nachfrageunsicherheit. Der zweite Aspekt ist wirtschaftliche Optimierung, wirtschaftliche Priorisierung. Wenn ich eine begrenzte verfuegbare Ressource habe, wie mache ich im Grunde das Beste daraus? Wie kaufe ich in diesem Fall effizient ein? Das sind die zwei Hauptbereiche, die die Leute heute mitnehmen sollen.

Conor Doherty: Also in einem Satz: Fuer jeden einzelnen Euro oder Dollar oder welche Waehrung auch immer man verwendet, fuer jeden, sagen wir Euro, den man in den Bestand investiert, was ist im Wesentlichen der erwartete Servicegradgewinn?

Fabian Hoehner: Ja. Genauer gesagt: Was man tun moechte, und darauf gehen wir gleich im Detail ein, ist den Servicegradgewinn pro Dollar zu maximieren oder AOG, also Aircraft on Ground, pro ausgegebenem Dollar zu reduzieren. Also der effizienteste Weg zum Ziel. Und wir hoffen, dass das fuer die Zuhoerer heute eine zentrale Erkenntnis wird.

Conor Doherty: Cool. Gut. Nachdem wir den Rahmen gesetzt haben, wollen wir nicht laenger um den heissen Brei herumreden. Gehen wir direkt zum Demo-Konto.

Max, unser Produzent, schalte gern um und stell sicher, dass alles in Ordnung ist. Subcto. Gut. Fabi, ich schaue auf meinen eigenen Bildschirm, weil meine Augen schrecklich sind, aber was genau sehen wir hier?

Bitte erklaere den Leuten den Kontext: Ist das Aviation? Ist es MRO? Ist das KI? Machen wir KI?

Fabian Hoehner: Ja, natuerlich machen wir immer KI. Wir gehen spaeter darauf ein, was wir in Sachen KI tun, aber wir sind tatsaechlich in einem Demo-Konto. Lokad in 20 Sekunden: Wir entwickeln kundenspezifische Bestandsoptimierungsloesungen fuer Kunden aus verschiedenen Bereichen, und heute konzentrieren wir uns auf die Luftfahrt. Das koennte MRO sein, also Maintenance, Repair and Overhaul, aber wir konzentrieren uns auf ein Beispiel, im Grunde von einer Airline.

Die Hauptfrage, die wir uns stellen, lautet: Wie bekomme ich fuer eine gegebene Flotte den effizientesten Investitions- und eventuell Desinvestitionspfad fuer meinen Bestand? Das ist die uebergeordnete Frage. Ganz kurz, wo wir hier sind: Man sieht, wir sind auf go.lokad.com.

Dies ist ein Demo-Konto. Alle unsere Kunden sind auf derselben Plattform. Es ist also eine Multi-Tenant-Anwendung, aber wir schreiben fuer jeden Kunden eine individuelle Loesung. Das macht Demos in gewisser Weise schwierig, weil jeder Kunde sehr anders ist.

Conor Doherty: Anders. Ja, natuerlich.

Fabian Hoehner: Das ist, wuerde ich sagen, unser USP: Wir passen an, was wir tun. Der Fokus heute ist, die zwei Prinzipien zu zeigen, die ich am Anfang erwaehnt habe. Einerseits: Wie sehen wir Unsicherheit?

Das Stichwort wird probabilistische Prognose sein. Die Leute, die uns ein wenig folgen, haben das schon sehr, sehr oft gehoert, aber heute machen wir es sehr praktisch. Und zweitens: wirtschaftliche Optimierung an einem konkreten Beispiel. Wenn es Fragen gibt, stellen Sie sie natuerlich gern zwischendurch.

Oft wird meine Antwort lauten: “Ja, wenn es logisch ist, koennen wir es bauen, oder wir haben es in der Vergangenheit gebaut.” Aber heute sehen wir uns nur ein konkretes Beispiel an. Das schlage ich vor. Noch Fragen? Sonst legen wir einfach los.

Conor Doherty: Ich wuerde sagen, wir legen einfach los, denn es gibt tatsaechlich schon viele Fragen. Wie die Leute wissen, habe ich im Vorfeld mit vielen Menschen gesprochen. Es gibt also einige sehr konkrete Fragen fuer spaeter, aber wie gesagt, wenn jemandem beim Zuschauen etwas auffaellt, gern unten kommentieren, und wir werden das zu gegebener Zeit aufgreifen.

Fabian Hoehner: Ja. Und du kennst mich, also unterbrich mich. Sonst…

Conor Doherty: Das werde ich, keine Sorge.

Fabian Hoehner: …komme ich in einen kleinen Redefluss. Gut. Das ist also wieder ein Demo-Konto, und wir sehen hier nur eine Uebersicht. Ich koennte auf alles klicken, was ich moechte, aber wir werden heute in zwei, drei Bildschirme eintauchen.

In diesem Fall betrachten wir ein Uebersichts-Dashboard. Wir gehen nach dem Prinzip der umgekehrten Pyramide vor. Wir beginnen mit der Uebersicht und bohren uns dann bis auf die niedrigste Ebene hinunter. Dies waere also eine Management-Uebersicht, in der wir die Pool-Performance sehen.

In diesem Fall sieht man, dass es ein Pool ist. Er koennte von mehreren Airlines stammen. Entscheidend ist: Wir betrachten eine Flotte, naemlich Triple 7. Ob sie von einer oder mehreren Airlines stammt, spielt keine Rolle, und dazu die Teile, die ich brauche, um diese Flotte zu betreuen.

Das ist hier das uebergeordnete Konzept. In diesem Fall sieht man eine historische Verbrauchsanzeige, und natuerlich geht sie nach oben, weil Lokad optimiert, also wird alles immer besser. Dazu einige zusaetzliche Ansichten zur aktuellen operativen Situation. Also: Wo ist mein Bestand?

In der Luftfahrt sprechen wir immer ueber Schleifen. Das wird ein sehr wichtiges Konzept sein. Offensichtlich sind die meisten Zuschauer heute damit sehr vertraut. Aber Bestand ist in der Luftfahrt nicht gleich Bestand.

Es geht darum, einsatzfaehigen und nicht einsatzfaehigen Bestand zu haben und zu wissen, wo er sich im Prozess befindet. Fuenf Einheiten zu haben, fuenf einsatzfaehige Einheiten zu haben, vier Einheiten im Reparaturzyklus und eine einsatzfaehige Einheit zu haben, das sind sehr unterschiedliche Interpretationen der Realitaet. Dies hier ist also im Grunde nur ein Uebersichts-Dashboard. Wie waeren wir dorthin gekommen? Durch Integration…

Conor Doherty: Ich wollte dir buchstaeblich genau diese Frage stellen, ich hatte schon den Mund offen.

Fabian Hoehner: Ja. Typischerweise: Woher kommen in diesem Fall die Daten? Aus verschiedenen ERP-Systemen, MRP-Systemen, aber im Kern sind es Transaktionsdaten, die wir auf die Plattform holen, wobei Lokad eine Intelligenzplattform ist. Das Transaktionssystem, ERP, MRP, sagt nur: “Wo sind meine Sachen?”, also die transaktionale Ebene. Wir nehmen das taeglich auf und machen dann, ich wuerde sagen, die Big-Data-Manipulation, um die Erkenntnis zu gewinnen: “Ich habe 186 Einheiten, die gerade in einem Rueckgabeprozess sind.” Gut, oder wolltest du…

Conor Doherty: Nein, das war gut.

Fabian Hoehner: Perfekt. Also, Uebersicht auf hoher Ebene, und jetzt steigen wir direkt in das Ergebnis ein. Wir beginnen damit, wie das Ergebnis einer Optimierung aussehen kann. In diesem Fall betrachten wir die Investitionsoptimierung.

Wir betrachten also eine Investition, die wir fuer einen Ziel-Servicegrad von 98 % erreichen wollen. Man sieht hier einen kleinen Simulator mit Dropdown, sodass ich verschiedene Szenarien simulieren kann, die ich bereits vorberechnet habe, hier, um es schnell zu machen. Wir koennten das auch anders gestalten, mit einem Eingabefeld, in dem man selbst herumprobiert, aber hier haben wir es vorberechnet, um schneller zu sein. Was wir hier sehen, ist fuer eine gegebene Situation: Wir sehen noch unseren aktuellen Bestand, in diesem Fall 68 Millionen, und diese 68 Millionen sollen mir einen Servicegrad von 95,7 % geben.

Conor Doherty: Mhm.

Fabian Hoehner: 95,7 % Verfuegbarkeit relativ zu den individuellen Lieferzeiten aller verschiedenen Teile und gewichtet nach ihrem Verbrauch.

Conor Doherty: Okay.

Fabian Hoehner: Als Naechstes waehlen wir, in diesem Fall gehen wir hier auf unsere 98. Wir waehlen: “Okay, wir wollen 98 % durchschnittliche Verfuegbarkeit, gewichtet nach Verbrauch und so weiter.” In diesem Fall sagt mir der Simulator: “Okay, ich muss 1,2 bis 2 Millionen investieren”, und ich erreiche mein Ziel, in diesem Fall 97,99. Das waere das Ergebnis.

Das ist die oberste Ebene. Ich koennte damit herumspielen, und wenn wir das tun, sehen wir etwas sehr Typisches in der Luftfahrt, womit die Mehrheit des Publikums sicher sehr vertraut ist: Die Long Tail ist dort, wo die Kosten liegen. Wenn wir also sehen, ich bin von 98 oder 98,5 auf 99,5 gegangen.

Gehen wir auf 99. Wir haben also dieses 1 %. Was wir sehen: Der erste Prozentpunkt, den wir gewinnen wollten, oder die ersten zwei Punkte, kosten uns eine Million Dollar Investition, und der naechste kostet 2,5. Dieser exponentielle Anstieg, um diese Servicegradpunkte zu gewinnen, ist extrem wichtig, wenn wir am Anfang ueber die Technologie sprechen.

Warum ist sie wichtig? Was machen wir anders? Die grosse Passung fuer Lokad in dieser Branche ist das Verstaendnis, wie man mit spaerlicher und erratischer Nachfrage umgeht, was die Mehrzahl der Luftfahrtprobleme ausmacht. Das heisst: Wie verstehe ich die Wahrscheinlichkeit der Extreme besser, also diese 90-plus-Perzentile, denn dort spielt sich die Luftfahrt im Grunde ab. Luftfahrt ist ein extrem risikoaverser Sektor; nicht vorratig zu sein kostet sehr viel Geld.

Conor Doherty: Ja. In vielen Faellen viel mehr als das einzelne Teil.

Fabian Hoehner: Traditionell ist in der Luftfahrt also jeder ueberbestueckt. “Im Zweifel einfach noch eins kaufen.” Das ist der typische Ansatz.

Zu verstehen, wie wahrscheinlich ein 99- oder 99,5-Szenario fuer das einzelne Teil ist, ist daher extrem wichtig. Dazu kommen wir auf einer detaillierteren Ebene. Erst einmal auf hoher Ebene: Warum betrachten wir hier all diese Extreme?

Weil wir in der Luftfahrt genau dort spielen. Niemand will wissen, was der Durchschnitt ist. Das wuerde bedeuten, dass man in 50 % der Faelle genug Bestand hat. Das ist egal.

Man will wissen, wie wahrscheinlich es ist, Extreme abzudecken. Wenn wir das betrachten, gehen wir wieder von hoher Ebene auf niedrigere Ebene. Hier haben wir die Investition, und jetzt ist das meine Gesamtinvestition. Wir wollen wissen: Was sind typischerweise die Mengen fuer den Kunden? In diesem Fall haben wir sehr einfach eine Liste: “Das sind meine Artikel, und das sind die Mengen, in die wir investieren.”

Conor Doherty: Nur zur Klaerung: Betrachten wir an dieser Stelle Rotables oder Consumables? Das sind nur Rotables.

Fabian Hoehner: Ja, Rotables.

Conor Doherty: Ja, absolut. Aber wir schauen spaeter auf Consumables, oder beruehren zumindest die Logik dort.

Fabian Hoehner: Ja, wir beruehren die Logik, aber…

Conor Doherty: Aber das sind im Grunde die teuersten Teile. Deshalb betrachten wir sie.

Fabian Hoehner: Man hat gesehen, die Werte, die wir hier sehen, sind ziemlich wichtig, denn ja, wir betrachten tatsaechlich Rotables. Die meisten Konzepte sind auf Consumables uebertragbar. Der Hauptunterschied: Ein rotable Teil hat per Definition eine Rotation, also eine Schleife, statt mehrerer Reparaturschleifen.

Theoretisch kann man das intern machen, oder man hat Ausschuss. Ein Consumable kauft man einfach, und es geht raus. Es gibt also einige mathematische Unterschiede, aber die zugrunde liegenden Prinzipien, die ich am Anfang genannt habe, naemlich Unsicherheit beziehungsweise Quantifizierung von Unsicherheit und Priorisierung auf Basis der Wirtschaftlichkeit, bleiben gleich.

Conor Doherty: Okay.

Fabian Hoehner: Die Frage ist nun: Warum empfehlen wir vier, drei, fuenf und so weiter? Dafuer gehen wir etwas mehr ins Detail, bleiben aber zunaechst noch auf relativ hoher Ebene. Was wir hier sehen, ist wieder dieselbe Liste wie zuvor, nur mit zusaetzlichen Informationen. Das Erste, was wir intuitiv sehen wollen, und ich werde euch einige Bildschirme mit vielen Zahlen zeigen…

Ich werde dir und dem Publikum sagen, worauf man achten sollte. In diesem Fall ist das meine Liste, und das sind die Teile, deren Kauf ich empfehle. Man sieht hier vier Einheiten, dort drei, fuenf und so weiter. Wichtig ist nun, was die Optimierung intuitiv tun sollte.

Ich erklaere gleich, wie wir dorthin kommen. Wir gehen immer tiefer. Aber zuerst: Ergibt es intuitiv Sinn? Was sollte eine Optimierung, die auf Effizienz abzielt, intuitiv tun?

Wenn Effizienz AOG-Reduktion pro ausgegebenem Dollar oder Servicegradsteigerung pro ausgegebenem Dollar ist, sollten wir sehen, dass Teile, die A, relativ billig und B, sehr wichtig sind, bei der Verfuegbarkeit gegenueber teuren und weniger wichtigen Teilen uebergewichtet werden. Wenn wir diese Liste betrachten, nehmen wir die ersten zwei Teile, weil sie einen ziemlich aehnlichen Stueckpreis haben. Wir sehen, dass ein Teil deutlich hoeher liegt. Der finale Servicegrad, der aktuelle Servicegrad, ist das, was ich mit dem aktuellen Bestand abdecke, den ich besitze.

Der finale Servicegrad ist dort, wo ich nach der Optimierung lande. In diesem Fall bringen wir dieses auf 94 % und dieses auf 80 %. Warum? Wenn wir hinschauen, hat dieses die Essentiality “no-go”. Und dieses ist “go-if”.

Im Kern ist die Konsequenz einer Fehlmenge hier also viel teurer. Deshalb ist es relativ ueberbestueckt, und das sollte die Intuition sein. Wenn wir die Liste hinuntergehen, sollten wir wieder sehen: Ein Teil, hier sehen wir 99. Sag mir uebrigens, wenn es zu klein ist.

Conor Doherty: Das ist besser. Danke. Zumindest fuer mich, weil ich fast blind bin.

Fabian Hoehner: Ja. Hier sehen wir 99,5. Das Teil ist mit 8.000 Dollar relativ guenstig und ein no-go-Teil. Diese Intuition sollte durchgehend gelten: Teile, die wir im Vergleich zu anderen aggressiv bevorraten, sollten no-go und relativ guenstig sein, waehrend die weniger aggressiv bevorrateten Teile eher… hier sehen wir, es ist ein go-Teil, nicht wirklich teuer, aber nur go.

Das ist zunaechst die zugrunde liegende Logik, die haengen bleiben sollte. Nun ist die Frage: Wie kommen wir genau auf vier, drei, fuenf und so weiter? Intuitiv ergibt es Sinn. Grossartig.

Der zweite Schritt ist nun: Wie kommen wir genau dorthin? Hier sehen wir zum ersten Mal, auf hoher Ebene, dass darin ein Konzept der wirtschaftlichen Priorisierung steckt. Wie kommen wir detaillierter dorthin? Das nennen wir eine gerankte Priorisierung, in diesem Fall eine gerankte Investitionsliste.

Was wir hier tun: Wir betrachten jeden einzelnen Kauf, beziehungsweise in diesem Fall jede Investitionsmoeglichkeit, die wir haben, und simulieren, welche wirtschaftliche Konsequenz eine Investition in dieses Teil haette. Wenn man die ersten zwei, drei Zeilen betrachtet, sieht man, dass es dieselbe PN ist, aber nicht dieselbe Stock-Keeping Unit, weil wir erst das erste Teil kaufen, dann das zweite, dann das dritte, und genau das machen wir durchgehend. Wir simulieren den Kauf jedes einzelnen Teils, das wir kaufen koennten. Diese Liste hier ist im Grunde endlos. Ich koennte endlos nach unten scrollen, und genau das tun wir.

Conor Doherty: Sie ist vermutlich durch das Budget begrenzt, weil ich sehe, dass sie wieder gerankt ist. Die Gesamtinvestition steigt beim Herunterscrollen. Vermutlich koennte man also eine harte Grenze setzen, etwa: “Ich habe nur X Budget. Es ist nicht unendlich. Optimiere also bis zu diesem Punkt und nicht weiter.”

Fabian Hoehner: Ja. In diesem Fall ist sie nicht durch das Budget begrenzt, sondern durch mein Ziel, naemlich 98 %. Aber du hast absolut recht. Die 98 % fuehren im Grunde zu einem Budget von 1,2 oder 1,25 Millionen. Was wir tun werden, ist tatsaechlich genau das.

Wir scrollen hier einfach nach unten, bis wir eine Gesamtinvestition von 1,25 erreichen. In diesem Fall haben wir es anders herum gemacht: Wir versuchen 98 zu erreichen, und 1,2 war das Ergebnis. Aber ich haette es auch umgekehrt machen koennen. Ich haette sagen koennen…

Conor Doherty: Ja, natuerlich.

Fabian Hoehner: Es ist eigentlich dasselbe, nur aus einer anderen Perspektive betrachtet. Okay, gut. Gehen wir jetzt durch ein paar Beispiele, um zu zeigen, wie diese Logik der wirtschaftlichen Priorisierung funktioniert. Ein guter Lackmustest, auch fuer Mitglieder des Publikums, die ihre eigene Optimierung betreiben, lautet immer: Kann man sagen, wenn ich euch sage: “Ihr habt 100.000 Dollar, welches waere heute der wichtigste einzelne Artikel, den ihr kaufen solltet?”

Das ist ein sehr wichtiges Konzept. Es wird nicht fuer dieses erste Teil gelten, aber allgemein fuer die Priorisierung jeder Aktion, die man unternimmt. Denn mit dieser Logik kann man beliebige Einschraenkungen einfuehren, ob “mein Einkaufsteam kann nur fuenf Teile pro Tag bearbeiten”, “mein Lager kann nur zehn pro Tag annehmen”, was auch immer die Einschraenkung ist, oder “ich habe eine Million Budget”. Wenn man keine priorisierte Sicht hat, ist es sehr schwierig, wenn man nur ein Ja/Nein hat. Sagen wir, “mein Ziel ist, Teil A bei 99 %, Teil B bei 95 und Teil C bei 91 zu haben.”

Extrem, aber okay. In diesem Fall ist es nur Ja oder Nein, und man hat kein Ranking-System. Genau dieses Konzept ist hier unglaublich wichtig, weil wir tatsaechlich priorisieren koennen. Und man muss immer priorisieren: begrenzte Zeit, Budget, was auch immer. Die Frage an das Publikum waere also: “Koennen Sie genau benennen, welches der einzelne wichtigste Artikel ist, den ich heute brauche?” Und wieder: Es geht nicht um den einen, sondern um die 50 wichtigsten.

Genau das koennen wir hier tun, und wir tun es, indem wir die erste Zeile betrachten. Was wir sehen: Wir betrachten die 1338. Wir werden uns die 1338 ziemlich lange ansehen. Also bitte dranbleiben.

Wir sehen, dass wir derzeit keine auf Lager haben. Wir ueberlegen, eine zu kaufen. Wir sehen, wie viele im letzten Jahr angefragt wurden. Dann kaufen wir eine Einheit, die uns 1.200 Dollar kostet, und aktuell haben wir null Servicegrad oder erwarteten Servicegrad.

Warum? Wir haben null auf Lager. Wenn man null hat, deckt man keine Unsicherheit ab. Das bedeutet es im Grunde.

Mein erwarteter Servicegrad bedeutet: Wie viel Unsicherheit ueber die Zukunft decke ich ab? Was das genau bedeutet, sehen wir im naechsten Schritt. Wie gesagt, wir gehen von hoher Ebene nach unten. Man koennte bei “das sind die Artikel, die Sie kaufen sollten” aufhoeren, und das waere es. Aber natuerlich wollen wir etwas tiefer gehen und verstehen, woher das kommt.

Conor Doherty: Darf ich kurz einhaken, denn das ist ein guter Punkt. Eine Frage habe ich in mehreren Varianten bekommen. Trink ruhig etwas. Ich habe mehrere Varianten derselben Frage bekommen: “Interessiert an der Idee, klingt grossartig”, weil einige Leute Lokad bereits kennen, “aber wie sieht das fuer mein Planungsteam aus?” Du hast gerade gesagt: “Schaut euch diese Dashboards an, hier sind die gerankten Entscheidungen.”

Dann hast du gesagt: “Wir gehen in eine viel tiefere Analyse”, und du hast gesagt, man koennte hier aufhoeren. Im Wesentlichen koennte das Planungsteam also an diesem Punkt aufhoeren. Die Entscheidungen liegen bereits vor. Wenn man dem System vertraut, kann man ausfuehren. Wenn man mehr lernen will, kann man untersuchen, warum diese Einheit, diese PN, ueber jener steht, usw.

Fabian Hoehner: Ja.

Conor Doherty: Okay.

Fabian Hoehner: In der Tat. Wenn wir hoffen, dass das System eingerichtet ist. Wir koennen darueber sprechen, wie lange das dauert, aber sagen wir nach sechs Monaten hat man ein System, das funktioniert und laeuft. Dann koennte man einfach sagen: “Ich vertraue dem System”, und die Empfehlungen werden exportiert und von den operativen Systemen ausgefuehrt.

Noch einmal: Wir sind kein Transaktionssystem. Wir sind ein System der Intelligenz. Wir sind dazu da, komplexe Simulationen auszufuehren und die Intelligenz dann an das operative System zurueckzuspielen.

Conor Doherty: Oh, bitte fahr fort.

Fabian Hoehner: Ich habe es gerade gesagt. Allerdings…

Conor Doherty: Ja.

Fabian Hoehner: Es gibt nur sehr wenige Leute, die, wenn wir uns an die Teile von vorhin erinnern, ein Teil fuer 46.000 Dollar einfach automatisch laufen lassen wuerden. Und so funktioniert es nicht.

Conor Doherty: Ja.

Fabian Hoehner: Das sind Teile, fuer die man tatsaechlich ein Angebot einholen muss. In der Luftfahrt ist das nicht wie Amazon E-Commerce.

Nein, man wuerde den Preis fuer das Teil anfragen, und der Preis, den wir hier haben, ist eine Annahme, bis er validiert ist. Das ist ein manueller Prozess, oder er kann automatisiert werden, aber mein Punkt ist: Die rotable Teile, die wir hier betrachten, sind wahrscheinlich nicht etwas, das man vollstaendig automatisieren wuerde. Man koennte natuerlich, aber in der Tat…

Conor Doherty: Die Ausfuehrung der Entscheidung nicht unbedingt, aber die Analyse und die eigentliche Erzeugung der Entscheidung ist automatisiert.

Fabian Hoehner: Deine Frage ist im Grunde: “Worauf schauen die Leute?” Ich wuerde sagen, typischerweise, wenn es die Zeit nicht wert ist, also wenn die Teile unter, ich weiss nicht, 2.000 Dollar liegen oder so, wenn wir C&E betrachten, dann kann man, und wir tun das tatsaechlich, alles automatisieren. Das operative System wird taeglich aktualisiert, und eine Bestellung wird automatisch angestossen. Wenn wir ueber rotable Investitionen sprechen, schauen typischerweise Experten darauf, um viele Dinge zu validieren.

In diesem Fall machen wir tatsaechlich etwas sehr Aehnliches wie hier. Wir haben die Empfehlung, die sagt: “Kaufe fuenf Einheiten davon.” Dann gibt es einen Experten, der das seit Jahren macht, der das Ergebnis hinterfragt, am Anfang, um das System mit uns aufzubauen, zu gestalten und zu verbessern, und dann auch, um zu untersuchen. Der Untersuchungsprozess, die Begruendung, wie ich zu “kaufe fuenf Einheiten” komme, ist genau das, was ich hier zeige. Wie bin ich dorthin gekommen? Wenn du mich nicht unterbrochen haettest, waeren wir schon fertig, aber ja.

Conor Doherty: Meine Entschuldigung.

Fabian Hoehner: Wir schauen also auf die 1338 und haben gesagt: “Eine Einheit zu kaufen bringt uns auf 47 %.” Sie deckt also 47 % der Unsicherheit ab. Das Delta von 0 auf 47 ist 47.

Dann setzen wir das ins Verhaeltnis zum gesamten Katalog. Was ist mein Delta auf dem Katalog? Das haengt davon ab, wie der Verbrauch dieses Teils ist. Offensichtlich hat ein Teil mit hoeherem Verbrauch hier einen hoeheren Einfluss und so weiter.

Dann mein Gewinn auf den gesamten Servicegrad, die AOG-Reduktion in Dollar. Wie kommen wir dorthin? Wieder: Wir bauen das kundenspezifisch, und ich erwarte nicht, dass viele Leute im Publikum oder auch unsere Kunden zu Beginn eine feste Zahl haben und sagen: “Ich weiss, was ein AOG kostet.” Unser Ansatz ist immer zu sagen: “Es ist besser, ungefaehr richtig zu liegen als exakt falsch.” In diesem Fall heisst das: Ja, es ist sehr schwer genau zu bestimmen, was uns ein AOG kostet.

Typischerweise moechte man hier sehen: Wie viele AOGs hatte ich, die ereignisbezogen waren und bei denen ein Bestandsereignis die Ursache war, und was ist meine grobe Kostenschaetzung? Zum Beispiel kann ich auch sehen, dass ich einen Notkauf taetigen musste. Welchen Wert hat das? Auf diese Weise kann ich versuchen, einen ungefaehr richtigen Wert abzuleiten.

Noch einmal das Argument: Besser eine Zahl in Dollar zu haben als gar keine. Denn wenn man keine hat, fliegt man bei Servicegraden immer etwas blind und kann nicht wirklich diskutieren: “Sollten wir bei 99 oder 99,5 sein?” Ich weiss es nicht. Aber sobald man etwas mit Dollar bewertet, kann man diskutieren, auch abteilungsuebergreifend.

Conor Doherty: Ja.

Fabian Hoehner: Und man kann das im Laufe der Zeit aendern. Das ist in Ordnung. Wenn man ein Jahr spaeter sagt: “Okay, ich glaube, unsere Schaetzungen sind hier falsch, oder fuer diesen Flottentyp stimmt es, aber fuer diesen Flottentyp sollte es teurer sein”, spielt das keine Rolle. Aber sobald man Dinge quantifiziert, kann man tatsaechlich…

Conor Doherty: Man gibt den Leuten eine gemeinsame Sprache, um Meinungsverschiedenheiten zu diskutieren.

Fabian Hoehner: Genau. Perfekt. Und das bringt uns am Ende zur AOG-Reduktion pro ausgegebenem Dollar, oder man kann sagen zum Servicegradgewinn pro ausgegebenem Dollar. Beides fuehrt zu einem Score, der im Wesentlichen zeigt, wo mein effizientester Investitionspfad liegt. Jetzt fuehre ich dich nur zur zweiten und dritten Zeile, und dann machen wir weiter.

Die zweite Zeile ist, wie wir sehen, tatsaechlich dasselbe Teil. Es ist dieselbe ID, aber wir kaufen nicht dasselbe Teil. Diesmal kaufen wir die zweite Einheit. Die erste haben wir bereits gekauft, also koennen wir jetzt nur noch in eine zweite Einheit investieren. Und wir werden sehen, dass diese uns auf… du kannst mir immer sagen, wenn ich hineinzoomen soll.

Conor Doherty: Nein, es ist okay. Es ist okay.

Fabian Hoehner: Ich hocke mich hier hin. Das bringt uns in diesem Fall auf 72 %, was bedeutet, dass wir 25 % zusaetzlichen Servicegrad bekommen. Die erste deckt natuerlich die meiste Unsicherheit ab. Was, 50 %, und die zweite nur 25.

Was ist also die logische Konsequenz? Das zweite Teil, und das ist ziemlich offensichtlich, hat weniger Wert fuer unseren Betrieb. Deshalb werden alle Werte sinken. Mein Servicegradzuwachs ist niedriger, meine AOG-Kosten sind niedriger, und daher ist mein Ranking-Score niedriger.

Okay, es ist keine Revolution zu sagen: “Das zweite Teil ist weniger wertvoll als das erste.” Ich kann natuerlich das zweite nicht vor dem ersten kaufen. Aber jetzt schauen wir auf die dritte Zeile. Dieselbe Logik, alles ist gleich.

Ich gewinne nur 14 % fuer dieses Teil. Ich zahle immer noch 1.200. Also wird mein Ranking-Score niedriger. Interessant ist jetzt die vierte Zeile, wo wir eine andere Teilenummer sehen.

Bei diesem Teil ist einfach alles anders. Ich habe eine andere Lieferzeitanforderung. Hier sieht man einen anderen zugrunde liegenden TAT. Potenziell gibt es eine andere zugrunde liegende Lieferzeit.

Der Preis ist anders. Alles ist anders bei diesem Teil. Was jedoch gleich bleibt, ist meine Ranking-Logik: Was ist meine AOG-Reduktion? Wir koennen das auch ueber meine Investition diskutieren.

Das ist das Kernkonzept, das wir hier anwenden. Ich mache eine kleine Klammer auf. Natuerlich wird es in der Realitaet komplizierter, und auch in diesen Berechnungen fuegen wir Faktoren fuer no-go, if und so weiter hinzu. In diesem Fall ist es in den AOG-Kosten enthalten.

Um es einfach zu machen: Die AOG-Kosten sind hoeher, wenn man ein no-go-Teil hat. Das kann extrem kompliziert sein. Und das liegt nicht daran, dass wir Genies sind, sondern an dem Feedback, das wir von unseren Kunden bekommen. Im Grunde schaut man sich einen Output an, wir nennen das experimentelle Optimierung, zeigt jemandem eine Liste und sagt: “Hey, das wuerde ich an deiner Stelle tun”, und dann spricht man mit den Experten, und die Experten sagen: “Ja, okay, fuenf klingt vernuenftig, aber ich waere auf 20 gekommen.”

In diesem Fall fehlt mir etwas, denn die operativen Experten wissen typischerweise, was sie tun. Das koennte zum Beispiel ein Sitzbezug sein. Man koennte sagen: “Technisch ist es kein no-go-Teil. Man kann damit fliegen.”

Aber der Betrieb wird sagen: “Ja, aber es sieht furchtbar aus”, und die Kosten, wenn jemand in ein schoenes Flugzeug einsteigt und sieht, dass wir da ein rotes Band anbringen muessen, das geht nicht. Ja. Das ist ein no-go. Das ist also extrem teuer.

Fun Fact: Kaffeemaschinen, no-go. Man kann also nicht keine Kaffeemaschinen haben. Technisch fliegt das Flugzeug ohne sie, aber… Das sind die Dinge, bei denen wir gemeinsam lernen und dann das Rezept anpassen. Und es kann von Airline zu Airline unterschiedlich sein. Was sind Prioritaeten?

Was nicht? Was wir hier tun: Wir ranken alles nach dem Ranking-Score, also: Was ist der Servicegradgewinn pro ausgegebenem Dollar, die AOG-Vermeidung pro ausgegebenem Dollar, und gehen diese Liste hinunter. Man sieht, es nimmt stetig ab. So werden ein Teil fuer 46.000 Dollar und ein Teil fuer 5.000 Dollar vergleichbar, weil die Frage einfach lautet: Ab welchem Punkt ist es sinnvoll, das sechste Exemplar eines billigen Teils oder das zweite Exemplar eines teuren Teils zu kaufen?

Genau das tun wir hier. Die naechste Frage lautet: Wie kommen wir zu diesen Werten, oder auf operativer Ebene betrachtet? Du hast vorhin gefragt, worauf Operations schauen wuerde. Sie wuerden auf eine solche Liste schauen.

Das waere absolut vernuenftig. Aber dann wuerden sie auch in das springen, was wir hier Item Inspector nennen. In diesem Fall, und auch fuer uns, ist das am Ende ein KPI-Dashboard, das erklaert, wie wir zu den Werten gekommen sind, die wir vorher betrachtet haben.

Typischerweise koennen das wieder die Kunden sein, die das untersuchen, aber auch Supply Chain Scientists auf unserer Seite. Also die Leute, die programmieren und Sparringspartner sind. Ich vermute, die meisten kennen das Konzept der Supply Chain Scientists, wenn sie an dieser Vorlesung teilnehmen, dann haben sie schon etwas von Lokad gesehen. Im Kern sind es die Leute, die implementieren und mit dem Kunden hin und her challengen.

Wir verwenden dieselben Auswertungsbildschirme wie der Kunde potenziell, um zu beurteilen oder zu bewerten: Ist das eine vernuenftige Entscheidung, die wir geben? Also immer von oben herunterbohren: “Kaufe fuenf”, bis zum Warum. Zuerst haben wir ein wirtschaftliches Ranking gesehen, und zweitens schauen wir jetzt auf alle Details. Wenn wir nicht einverstanden sind, wuerden wir typischerweise hierher gehen und sehen: Haben wir dieselbe Sicht auf die Realitaet? Denn besonders zu Beginn eines Projekts ist die Mehrheit der Faelle, in denen wir nicht ausgerichtet sind… Hast du eine Idee?

Conor Doherty: Der wirtschaftliche Wert der Entscheidungen?

Fabian Hoehner: Nein, Daten. Es sind immer Daten. Im Grunde ist man nicht auf dieselbe Realitaet ausgerichtet, die man betrachtet. Unsere komplexen Kunden und Luftfahrtunternehmen haben typischerweise viele Anschaffungen getaetigt. Sechs verschiedene ERP-Systeme mit Legacy zu sehen, ist ziemlich ueblich, plus drei Excels links und rechts.

Schon die richtige oder gleiche Interpretation derselben Realitaet zu bekommen, ist nicht einfach. Also der erste Schritt: Haben wir denselben Blick auf die Realitaet? Sehen wir dieselben Einheiten, die in diesem Fall alle… Schauen wir ein anderes Teil an, ob wir eines sehen. Ja, haben wir dieselbe Anzahl von Einheiten, die sich gerade in einem Rueckgabeprozess, Reparaturprozess, Logistikprozess befinden?

Ja, nein, vielleicht? Das ist ziemlich wichtig zu sehen. Und dann, sagen wir, die Daten sind tatsaechlich kohärent. Dann schauen wir: Was ist unsere Nachfrageprojektion?

Wie kommen wir dorthin? Hier… Wir haben ueber wirtschaftliche Priorisierung gesprochen. Ganz am Anfang sagte ich, es gibt zwei Hauptkonzepte, die die Leute mitnehmen sollen: wirtschaftliche Priorisierung. Davon haben wir einiges abgedeckt. Und ich sagte Unsicherheit, probabilistische Prognose, und das sehen wir uns jetzt an.

Noch einmal: Fuer manche wird das ziemlich offensichtlich sein, aber ich gehe etwas langsam vor, damit alle mitkommen. Was wir hier sehen, ist eine Verbrauchshistorie, die extrem typisch ist. Uebrigens bleiben wir bei unserer Lieblings-1338. Okay. Also…

Conor Doherty: Dasselbe Teil auf dieser Reise. Okay.

Fabian Hoehner: Wir gehen tatsaechlich durch die Reise dieses Teils. Was wir sehen, ist eine sehr typische Verbrauchshistorie, spaerlich und erratisch. Also nichts, eins, eins, eins, zwei, dann zwei, eins. Das bedeutet, sie ist extrem schwer zu prognostizieren.

Wenn man das betrachten wuerde, und ich weiss, in der Luftfahrt wuerden das nur sehr wenige tun, aber wenn man das aus einer Durchschnittsverbrauchsperspektive betrachtet, also einfach einen gleitenden Durchschnitt nimmt, saehe es so aus. Hilft dir das ueberhaupt? In diesem Fall sagt es 0,17 Einheiten. Okay, grossartig.

Was gibt mir das? Praktisch nichts. Die Sicht, die man haben will, und was wir tun werden, ist eine probabilistische Sicht, die uns sagt: Wie wahrscheinlich ist ein Verbrauch ueber einen gegebenen Horizont? Wenn ich sage ueber einen gegebenen Horizont, fangen wir einfach an. Also, fuer alle, die Statistik hatten…

Conor Doherty: Geh davon aus, dass ich ein Idiot bin. Du darfst mit mir von oben herab reden. Das ist okay.

Fabian Hoehner: Das wird eine schwierige Annahme. Dieses Histogramm hier ist… Fangen wir einfach an und sagen, es waere oder war eine Darstellung der Realitaet. Also nur Vergangenheit, nur rueckblickend. In Wirklichkeit schauen wir natuerlich nach vorne, wir prognostizieren, wir machen superintelligente Dinge, aber der Einfachheit halber sagen wir, wir betrachten die Vergangenheit.

Was macht ein Histogramm hier? Wir sagen einfach, ich weiss nicht, ob man es sieht, ja, ich denke, man sieht hier kleine Balken. Nehmen wir an, ein Zeitraum, den wir betrachten, liegt zwischen diesen Balken. Sagen wir 30 Tage, und ich sage jetzt zufaellig: Wenn die Vergangenheit die Zukunft repraesentiert und wir zufaellig eine Stelle herausgreifen…

In diesem Fall wuerde das bedeuten: Wie oft treffe ich eine Nachfrage von eins in einem 30-Tage-Fenster? Wie oft treffe ich null? Wie oft zwei, drei und so weiter? Genau das sagt dies.

Es sagt also: Zufaellig treffen wir in 25 % der Faelle null. In 34 % der Faelle treffen wir eins, zwei, drei, vier, fuenf und so weiter. Das ist der theoretische Fall. Hier sehen wir: Wenn ich dieses Intervall haette, waere das eine Nachfrage von drei. Wenn das Intervall groesser waere, waeren es all diese.

Das ist die einfache Theorie. Die Praxis ist, und hier kommen wir zu dem, was ich am Anfang sagte, Unsicherheit anerkennen und annehmen: Welcher Horizont ist zu prognostizieren? Denn es sind nicht 30 Tage. 30 Tage waeren eine feste Zahl, und wir betonen stark: Unsicherheit existiert, und man kann sie nicht aus dem Bild herausplanen. Es ist schoen anzunehmen, dass es immer 30 Tage sind, um einen deterministischen Wert zu haben, der die Planung einfach macht, aber dadurch wird es nicht realer. Die Realitaet ist: Manchmal dauert es 30 Tage, manchmal 50, manchmal 60, manchmal 180, oder…

Conor Doherty: es kommt gar nicht zurueck.

Fabian Hoehner: Genau, Ausschuss. Was wir hier betrachten, sind rotable Teile. Rotable Teile werden normalerweise repariert. Wir betrachten also nicht Lieferzeiten, sondern typischerweise Turnaround Times.

Wie lange dauert es, bis mein Teil wieder einsatzfaehig ist? Ich bekomme mein Teil, das Flugzeug kommt rein, das nicht einsatzfaehige Teil geht raus. Ich ersetze es durch ein einsatzfaehiges Teil, das ich auf Lager hatte, und das nicht einsatzfaehige Teil geht nun durch eine lange, ewige Schleife. Idealerweise habe ich die Daten, um jede Station darin zu identifizieren und viele kleine Verteilungen zu haben. Aber fuer mich ist entscheidend: Ich will verstehen, welche moeglichen Verzoegerungen auf mich zukommen koennen.

Und das ist der Horizont, ueber den ich prognostizieren will, weil ich die Extreme verstehen will. Wenn ein Teil innerhalb eines Tages repariert werden koennte, braeuchte man ueberhaupt keinen Bestand, oder keinen zusaetzlichen Bestand. Eine Einheit waere ausreichend. Jedes Mal, wenn das Flugzeug kommt, nicht einsatzfaehig raus, einsatzfaehig rein, nicht einsatzfaehig repariert, ein Bestand von eins waere genug. Die Realitaet ist offensichtlich nicht so, aber wir sehen, dass die Bestimmung dieses Zeitraums absolut wesentlich ist, und genau das tun wir hier.

Dies ist in diesem Fall unsere Wiederbeschaffungszeit, kann eine Turnaround Time sein, spielt keine Rolle. Doch, es spielt eine Rolle, aber aus Prinzipiensicht wollen wir verstehen: Was ist der Horizont, ueber den wir prognostizieren? Man sieht, dass dies geglaettet ist, und dass es eine bimodale Verteilung ist. Was koennte eine Erklaerung sein? Typischerweise waere in der Luftfahrt dieser Peak um 80: Alles laeuft glatt.

Man hat ein Teil, schickt es in die Werkstatt, es wird repariert, alles ist schoen. Und dies hier repraesentiert den Fall, dass etwas kaputt ist, das behoben werden muss, was Zeit kostet. Das ergibt eine schoene bimodale Verteilung. Die wichtige Botschaft ist: Es ist eine ganz andere Interpretation zu sagen, dass in der Mehrheit der Faelle, sagen wir in 80 % der Faelle, es um 80 liegt und in 20 % der Faelle bei 150, als zu sagen, es sei immer der Durchschnitt, also 110 Einheiten.

Conor Doherty: was in dieser Verteilung sehr selten passiert.

Fabian Hoehner: Ja. Offensichtlich ist das hier geglaettet und Demo-Daten und so weiter. Aber tatsaechlich koennte das ein sehr realer Fall sein, den man ziemlich haeufig sieht. Entweder alles laeuft glatt, dann sind es 80 Tage, oder es laeuft nicht glatt, dann sind es 120.

Ich ziehe hier keine Schlussfolgerung. Ich sage nicht: “Waehle eines der Szenarien.” Nein, ich sage nur: Man will verstehen, dass Unsicherheit existiert, und tatsaechlich ueber alle moeglichen Zukuenfte prognostizieren, die existieren. In diesem Fall sagte ich am Anfang: “Okay, wir nehmen einfach ein 30-Tage-Fenster.”

30 Tage. In diesem Fall ist das eine sehr kleine Wahrscheinlichkeit von unter einem Prozent. Aber im Kern werden wir eine Nachfrageverteilung ueber jeden moeglichen Nachfragehorizont erstellen. Stellen Sie sich also einfach vor, egal ob es exakt so gemacht wird oder nicht, nur fuer den visuellen Teil, Sie haben jetzt hundert verschiedene Verteilungen ueber alle verschiedenen Horizonte, die existieren.

Diese nehmen wir und verdichten sie zu einer Verteilung, naemlich dieser. Was bewirkt das? Es gibt uns die Nachfrage ueber alle moeglichen Zukuenfte. Warum diese letzten zehn Minuten?

Weil uns das die genaueste Darstellung der Nachfrage ueber eine unsichere Zukunft gibt, und das ist unglaublich wichtig. Wenn wir in der Luftfahrt sprechen, sagten wir ganz am Anfang, das Einzige, was mich interessiert, sind die Extreme. Also meine 90-plus-Szenarien. In diesem Fall ist es extrem wichtig zu verstehen, wo ich in dieser Verteilung bin. Und wenn wir ein paar ansehen, klicken wir einfach durch.

Hier. Wir sehen, dass es sehr typisch ist, dass wir diese null-inflationierten, rechtsschiefen Verteilungen haben. Das bedeutet, man hat eine Long Tail, die man die ganze Zeit sieht, und gleichzeitig ist keine Nachfrage ueber den Horizont oft das wahrscheinlichste Szenario. Aber noch einmal: Genau zu verstehen, wie wahrscheinlich die Ausreisser sind, dort liegt die Bedeutung. Wenn dieses Teil hier 20.000 Dollar kostet, lautet die Frage: Wollen wir fuer diese zusaetzlichen, ich weiss nicht, fuer diese zusaetzlichen 7 %, nicht ganz die richtige Berechnung, noch einmal 40.000 Dollar investieren, oder wollen wir nur die ersten paar nehmen? Genau das haben wir vorher gemacht.

Deshalb ist es absolut kritisch zu verstehen, welche Form die Verteilung hat. Das ist der erste Schritt. Wenn wir dann mehr ins Detail gehen oder zu unserem Teil zurueckkehren wollen, erinnern wir uns, vielleicht hier: Wenn wir ein Teil einsetzen, erhalten wir einen erwarteten Servicegrad von 47 %. Das zweite bringt uns auf 72 und dann auf 87, und wenn wir…

Conor Doherty: das war in der Liste.

Fabian Hoehner: Sehr gut. Du…

Conor Doherty: Ich habe aufgepasst.

Fabian Hoehner: Grossartig. Wenn wir hierher gehen und zurueckschauen, dann sehen wir: ja, wir waren beim ersten bei 47, dann 72 und so weiter. Das ist im Grunde der Rueckweg zu: Wie sind wir dorthin gekommen? Und das erklaert, wie wir genau zu dieser Zahl kamen. Kurz Luft holen, also wenn du…

Conor Doherty: Ich denke, an diesem Punkt habe ich schon ein paar eingereichte Fragen, und es ist ein guter Zeitpunkt, dazu ueberzugehen. Denn eines der Dinge, nach denen ich im Vorfeld immer wieder gefragt wurde, war: Wie passt das alles, was die Leute gerade gesehen haben, in einen bestehenden Workflow? Denn offensichtlich haben jedes Unternehmen, unsere Kunden oder potenzielle zukuenftige Kunden, ihre eigene Software und ihre bestehenden Workflows. Muss man also alles herausreissen, um Lokad einzusetzen? Sitzt es daneben? Wie funktioniert das?

Fabian Hoehner: Ja, das waere eine ziemlich schlechte Frage, wenn das die Wahrheit waere.

Conor Doherty: Ja, genau, offensichtlich.

Fabian Hoehner: Nein, wir sitzen oben drauf. Ich zeige dir einfach ganz kurz, buchstaeblich nur fuer ein paar Sekunden, was im Hintergrund davon ist. Das ist…

Conor Doherty: Das ist KI, richtig?

Fabian Hoehner: Ja, das ist alles Magie. Offensichtlich ist das alles schwarze Magie. Nein, das ist unsere Programmiersprache Envision.

Am Ende ist Lokad mehrere Dinge. Einerseits ist es eine sehr leistungsfaehige Big-Data-Plattform, die fuer Bestandsoptimierung entwickelt wurde, und es gibt tatsaechlich viele KI-Funktionen. Zum Beispiel koennen wir diese Sprache mit internen Agenten schreiben und so weiter. Was ich hier zeigen wollte, ist: Du hast nach den Daten gefragt.

Wir passen es an jeden an. Wir erwarten nicht, dass jemand etwas vorab designt. Wir wollen nur die Rohextrakte. Ein grosser Teil der Arbeit ist dann, die Daten auf unserer Seite zu manipulieren, sie richtig zu bekommen, oder die Datenmanipulation richtig hinzubekommen, damit sie Sinn ergibt. Also Datenkohaerenz.

Ein Beispiel: der Fair Value eines Teils. Das ist ziemlich komplex zu erreichen, weil man in der Luftfahrt viele Teile hat, die schon lange da sind. Man schreibt ein Teil vielleicht ueber acht Jahre ab, und dann hat dieses Teil in der Buchhaltung einen Buchwert von 1 Dollar. Aber das Teil kann immer noch ersetzt werden, und ein Neukauf kostet, ich weiss nicht, 50.000 Dollar. Welchen Wert sollte man also annehmen? Was ist der faire Wert des Teils?

Darauf gibt es keine einfache Antwort. Man hat zwei verschiedene Systeme. Das Buchhaltungssystem sagt, es ist 1 Dollar, weil man einen Buchhaltungsdollar darin stehen laesst. Und wenn man es neu kaufen will, sind es 50.000.

Wie bekommt man diese Daten richtig? Das braucht Zeit, Diskussion, und aus unserer Sicht vor allem Flexibilitaet. Deshalb haben wir, aus vielen Gruenden, aber im Kern deshalb, eine Programmiersprache, um uns daran anzupassen. Alle unsere Kunden haben sehr unterschiedliche Setups, und wir sitzen einfach oben drauf.

Ob sie AMOS haben, TRAX, SAP, meistens eine Mischung aus allem. Ja, das ist einfach Teil des Systems der Intelligenz. Wir bauen es aus. Beantwortet das die Frage?

Conor Doherty: Ja, mehr oder weniger, denn ich habe die Frage paraphrasiert. Die Sorge war eher, doppelte Transaktionen zu vermeiden. Wenn man mehrere Systeme hat, muss ich dann zwischen System A und Lokad und umgekehrt abgleichen? Das war im Grunde die zugrunde liegende Bedeutung der Frage.

Fabian Hoehner: Ja. Wenn du fragst, ob es eine Verdoppelung der Funktion gibt: Wenn wir einen Schritt zurueckgehen, hat man die Transaktionssysteme, die fuer Transaktionen da sind.

Conor Doherty: ERP.

Fabian Hoehner: Ja. ERP, M… Im Grunde nehme ich eine Einheit aus dem Bestand und installiere sie. Das will man in Millisekunden sehen. Ueberall muss es aktualisiert werden.

Das ist nicht Lokad. Wir fuehren komplexe Simulationen aus, die 20 Minuten dauern koennen. Das ist in Ordnung. Hier sieht man, es ist vorberechnet.

Deshalb dauert es hier keine Zeit, weil wir es vorberechnet haben. Dieses hier wuerde wahrscheinlich in ein paar Sekunden durchlaufen, aber die kompliziertesten Dinge koennten laenger dauern, und das ist in Ordnung, weil das nicht unsere Aufgabe ist. Unsere Aufgabe ist Intelligenz und im Grunde die besten Einsichten, die beste Entscheidungsunterstuetzung, die besten automatisierten Entscheidungen bereitzustellen und sie dann an die automatisierten Systeme zurueckzuspielen. Um dorthin zu kommen, haben wir ziemlich viele Dashboards, Insight-Dashboards.

Also ein Berichtssystem. System of Records, dann darueber typischerweise ein Berichtssystem, Tableau, was ist das andere? Egal. Power BI, solche Dinge. Und dann ist System of Intelligence die Klasse, in der wir arbeiten.

Um das zu tun, ja, natuerlich. Sobald ich die Daten habe, bauen wir viele Dashboards, die uns eine Erklaerung geben. Zum Beispiel diese Untersuchungs-Dashboards, die wir hier betrachten. Offensichtlich ist auch das ein Berichtssystem. Dieses Dashboard ist nur ein Bericht.

Ich meine, die Berechnung passiert woanders. Aber zu deiner Frage, verdoppeln wir Dinge? Ja, man kann manche Dinge verdoppeln, aber global ist unser Anspruch nicht, ein Berichtssystem zu werden. Das ist nur fuer uns intern und dann auch fuer die Kunden, damit sie validieren koennen, was wir tun, denn wir wollen nicht nur Code anschauen. Man will sehen, was er tut.

Conor Doherty: Okay. Apropos was es tut: Als wir ganz am Anfang gesprochen haben, sagte ich, dass wir uns Investitions- und Desinvestitionsentscheidungen ansehen wuerden. Mir ist aufgefallen, dass wir uns sehr stark auf Investitionsentscheidungen konzentriert haben.

Koenntest du uns etwas zeigen in Richtung: “Ich habe zu viel”? Noch einmal, wir sprachen ueber Rotables. “Ich habe zu viel Bestand. Wie kann ich Einheiten identifizieren, die ich wahrscheinlich abgeben sollte, um Kapital freizusetzen?”

Fabian Hoehner: Ja. Als haettest du gewusst, dass ich das irgendwo habe. Brillant.

Ja. Grundsaetzlich ist das Dashboard auch in diesem Fall so gestaltet, wie wir es wollen. Es ist ein Demo-Dashboard. Es ist einfach eine Wahl, die wir hier getroffen haben.

In diesem Fall haben wir Desinvestitions- und Investitionsmoeglichkeiten im selben uebergeordneten Dashboard. Was wir hier betrachten, sind tatsaechlich Desinvestitionsmoeglichkeiten. Am Ende ist Desinvestition fast dasselbe wie Investition. Bei einer Investition nehmen wir den aktuellen Bestand und fragen uns: Was waere, wenn ich eine weitere Einheit hinzufuege, und noch eine, eine dritte, eine vierte und so weiter, fuer jede Bestandsmoeglichkeit, die ich habe? Dann bauen wir unseren Ranking-Score.

Bei einer Desinvestitionsmoeglichkeit betrachten wir hier den gesamten Bestand, den wir besitzen, und machen dasselbe. Wir fragen uns: Wenn ich eine Einheit Bestand, die ich besitze, desinvestiere, wie viel Servicegrad verliere ich und wie viel Cash setze ich frei? Das ist im Wesentlichen dieselbe Logik. Ich gehe nicht alles durch, aber in einer solchen Liste will man Teile mit hohem Stueckpreis und einem geringen Servicegradverlust sehen. In diesem Fall sieht man, ja, wir verlieren weniger als ein Prozent bei diesem Teil.

Wenn wir auf den Gesamtverlust schauen, ist er gerundet. Wir koennen ihn nicht einmal sehen. Offensichtlich gibt es einige Teile, von denen man einfach zu viele hat. Dann sieht man den AOG-Anstieg daraus und dann das Ranking.

Wir sollten wahrscheinlich ein paar Nullen hinzufuegen, dann koennte man es sehen. Aber wenn wir nach unten scrollen, sieht man, dass es steigen wird. Entscheidend ist: Das Gefuehl, das man hier sehen sollte, ist hoher Stueckpreis, geringer Servicegradverlust, und das ist die umgekehrte Logik. In der Theorie kann man sogar einen idealen Punkt zwischen beiden finden und sagen: “Okay, ich moechte in all diese investieren und desinvestieren, bis ich einen Sweet Spot erreicht habe.”

Das ist eher theoretisch, weil die Realitaet komplexer ist, was faire Marktwerte betrifft. Noch einmal: Das ist nicht Amazon, wo man sagt: “Oh, ich habe 10 zu viel von einem Teil, das 85.000 Dollar kostet, weg damit.” Nein, man muss sie verkaufen. Man muss jemanden finden, Standorttransfer und so weiter.

Aber das sind tatsaechlich Dashboards, die fuer Kunden sehr wertvoll sind, um Assets zu desinvestieren und dann zu sagen: “Okay, ja, das ergibt Sinn. Wir haben hier mindestens fuenf, die im Grunde nur fuer ein sehr, sehr Long-Tail-Ereignis dienen.” Also wirklich, wenn unsere gesamte Flotte am selben Tag ein Problem hat, dann waere dies noetig. Das ist die Grundidee der Desinvestition.

Conor Doherty: Ja. Fuer mich, wenn wir unterscheiden, wie wir Budget zuteilen wuerden, je nachdem, sorry, wie wir Entscheidungen auf Basis von Investitions- oder Desinvestitionsentscheidungen erzeugen und wie diese sich leicht unterscheiden. Eine Anschlussfrage wurde im Vorfeld eingereicht. Eine Person aus dem operativen Einkauf wollte wissen: “Wie sollte oder wie aendert sich eine Einkaufsempfehlung, je nachdem, ob die Einheit fuer einen Austausch oder fuer einen direkten Kauf erworben wird?”

Fabian Hoehner: Kommt darauf an. Die Antwort ist immer…

Conor Doherty: Diese Fragen brauchen tatsaechlich ziemlich viel Zeit, deshalb bitte ich dich um knappe Antworten. Ich weiss, wenn wir nicht in alle Details gehen, koennen wir nachfassen, das ist kein Problem.

Fabian Hoehner: Ja, natuerlich.

Conor Doherty: Aber eine allgemeine Antwort.

Fabian Hoehner: Ja. Die Frage waere hier: In diesem Fall schauen wir typischerweise auf den Pool, den man besitzt. Wie hoch ist mein Gesamtbestand? Das sind also alle Investitionen, die meinen gesamten Pool-Level erhoehen.

Wenn es nur fuer einen Austausch ist, dann aendert sich die Pool-Zahl normalerweise nicht, weil man es austauscht und zu einem bestimmten Zeitpunkt zurueckgibt. Dort waere die Frage eher in der Bewertung. Man koennte das tun, weil man theoretisch genug Teile hat, aber sie alle in einer Reparaturschleife feststecken. Man braucht also nicht wirklich mehr Bestand, aber man muss eine Zeit ueberbruecken, bis sie zurueckkommen. Das waere im Wesentlichen eine andere Optimierung.

Was wir hier betrachten, sind Investitionen, die in den Pool gehen. Das wuerde auch in Richtung Reparaturpriorisierung gehen. Am Ende lautet die zugrunde liegende Frage: Wenn ich eine gegebene Menge an Teilen in meinem Reparaturprozess habe, welche dieser Teile sollte ich priorisiert reparieren lassen? Manchmal kann man das aendern, aber jedes Unternehmen hat, wenn wir zur Uebersicht gehen, haben wir gesehen, dass aktuell 500 Einheiten durch einen Reparaturprozess laufen. Nicht alle sind gleich wichtig.

Was wir hier tun koennten, und das tun wir im Grunde wieder mit einer priorisierten Liste, ist zu sagen: Okay, diese sollten… Dann haben wir Expedite-Aktionen, bei denen man sehen kann, welche Prioritaeten bestehen und ob man die Lieferzeiten verkuerzen koennte. Denn fuer den Lieferanten spielt es keine Rolle. Er hat 20 Ihrer Teile und repariert sie alle, und er weiss nicht, welche fuer Sie wichtig sind. Aber wir sagen: “Wir haben noch fuenf einsatzfaehige Teile herumliegen, und nur weil wir es frueher rausgeschickt haben, brauchen wir es nicht frueher zurueck.” Das waere sehr typisch, wenn ich ueber Priorisierung spreche. Wieder: Welches hat den wichtigsten Einfluss fuer uns? Es sind am Ende einfach Listen: Was tun wir, um den groessten Einfluss zu erzielen?

Conor Doherty: Okay. Ich kann weitermachen? Alles gut? Perfekt.

Weil du Lieferanten erwaehnt hast, fuehrt das zu einer weiteren wichtigen konkreten Frage, die gestellt wurde. Ich habe sie hier notiert. Im Wesentlichen kam sie von jemandem, der schon gesehen hat, dass Lieferanten sich weigern, einer neuen Plattform beizutreten, wegen Onboarding-Kosten oder Abogebuehren. Also: “Muessen Lieferanten ihre Arbeitsweise mit dem Kunden aendern, damit Lokad all dies tun oder Wert erzeugen kann?”

Fabian Hoehner: Lieferanten in welchem Sinne, die Lieferanten der Kunden?

Conor Doherty: Ja. Ja. Also…

Fabian Hoehner: Nein. Typischerweise… Brauchen wir die Daten der Lieferanten? Die kurze Antwort: nein. Wir brauchen nur die Daten des Kunden, weil er alle Daten hat.

Koennen wir? Ja, wir integrieren tatsaechlich zusaetzlich einige Lieferanten, typischerweise fuer Timestamps. Also: Du bist der MRO, du reparierst. Ich bin die Airline.

Ich sende meine Daten an Lokad, und das Einzige, was ich weiss, ist: Ich schicke das Teil raus und weiss, wann es zurueckkommt. Wenn ich deine Daten habe, etwa “es ist gerade im Reparaturprozess, es ist gerade an der Grenze, oder was auch immer, es wurde geprueft”, und wenn ich diese Daten habe, und wir haben einige Kunden mit guten Beziehungen zu ihren Lieferanten, dann kann das so einfach sein wie eine Excel-Datei, die regelmaessig zu Lokad hochgeladen wird. Dann koennen wir diese Datenpunkte besser aktualisieren.

Um deine Frage zu beantworten: Wenn ich mit meinem Lieferanten integriert bin und die Daten in meinem ERP-System habe, dann ziehe ich die Daten einfach aus dem ERP-System. Das ist in Ordnung. Fertig. Aber wir sind sehr flexibel, und das ist wahrscheinlich unser Vorteil bei der Integration mit einem Drittanbieter. Noch einmal: Wir sind ein IT-Unternehmen.

Fuer uns ist es wahrscheinlich viel einfacher, uns mit einem Dritten, mit irgendeinem Datenfluss, zu integrieren, als fuer eine grosse Organisation, Drittanbieterdaten in ein ERP-System zu bekommen. Das ist ein Transformationsprojekt. Fuer uns sind das ein paar Tage. Das ist wahrscheinlich der grosse Unterschied.

Conor Doherty: Okay. Aber als Fazit gibt es mindestens zwei Datenkategorien. Es gibt Nice-to-have und Must-haves.

Und die Lieferantendaten, die du gerade beschrieben hast, sind nice-to-have. Im Wesentlichen schoen zu haben. Sie helfen, sind aber kein Dealbreaker.

Fabian Hoehner: Ja, absolut. Nur um klar zu sein, guter Punkt.

Conor Doherty: Ich will konkret sein, richtig?

Fabian Hoehner: Ja. Die Datenfrage ist immer gut. Welche Art von Daten brauchen wir?

Im Grunde muss man in der Luftfahrt alles verfolgen. Es gibt also genug Daten. Die Frage ist: “Haben wir genug?” Ja, hat man.

Die Frage ist: Sind sie schoen? Sind sie sauber? Nein, nie. Aber es gibt ausreichend Daten, und dann beginnt die Arbeit, dieselbe Interpretation der Daten zu bekommen.

Daten sind nur Daten, aber wie interpretiert man sie? Das ist die Frage. Ja, Verbrauchshistorie ist offensichtlich wichtig. Bestandslevel, Katalog, ja, alles, aber auch die Standards.

Und dann gibt es viele Nice-to-have-Daten. Historische Bestandslevel pro Standort, solche Dinge. Und natuerlich Lieferanten-Timestamps, das ist super schwierig. Typischerweise sieht man das nicht.

Man sieht nur die Turnaround Time als zwei Werte: raus und rein, und das war’s. Wenn man die Zwischen-Timestamps hat, ist das wirklich stark, aber wenn nicht, hat man nur eine breite Verteilung davon. Sonst hat man mehrere Verteilungen.

Conor Doherty: Du hast vorhin in Bezug auf potenziell chaotische Daten gesagt: “Dann beginnt die Arbeit.” Nur zur Klaerung, und das wurde auch in Bezug auf Datenvorbereitung gefragt: Was wird von Kunden verlangt? Und das knuepft wohl an das an, was du vorhin ueber Supply Chain Scientists gesagt hast.

Fabian Hoehner: Ja. Normalerweise ist unsere Haltung, dass wir es gemeinsam tun, denn genau dafuer sind wir gebaut. Wir sind eine Big-Data-Plattform.

Wir sind darin schnell. Wir sind typischerweise viel schneller als unsere Kunden, sogar bei der Vorbereitung der Daten. Wir brauchen nur Rohextrakte. Abgesehen davon ist es natuerlich wichtig und wertvoll, Leute zu haben, die mit den Daten vertraut sind, wissen, wo die Daten sind, und das beschleunigt ein Projekt.

Ich werde also nicht sagen, dass es nicht grossartig ist, Leute zu haben, die sich die Daten schon angesehen haben und wissen, was sie bedeuten. Aber sonst ist unser Ansatz: Man geht auf die Entscheidungsebene. Das ist das Schoene. Wenn ich sage: “Kaufe vier Teile, tu das”, werden die zugrunde liegenden Probleme ziemlich offensichtlich. Eine Datenbereinigungsmission…

Ich habe viele Unternehmen gesehen, die sagen: “Wir sind nicht bereit. Wir wollen erst unsere Daten bereinigen.” Dann spricht man zwei Jahre spaeter mit ihnen, und die Antwort lautet: “Wir bereinigen immer noch unsere Daten”, weil es unglaublich schwierig ist zu wissen, wo man anfangen soll. Es gibt immer chaotische Daten, falsche Kategorisierung, Produkthierarchien. Ja.

Okay. Fuer uns waere eine bessere Kategorisierung schoen. Interchangeability Mapping, offensichtlich, Interchangeabilities in der Luftfahrt, einseitig, zweiseitig, super wichtig.

Also ja, es ist nicht sauber. Waere es viel besser, wenn es sauber waere? Ja, absolut. Aber wird man, indem man zur Entscheidung geht, auch sehr deutlich sehen, welche Daten wertvoll sind?

Ja, denn nehmen wir Interchangeability: Ein neues Teil, kann ich es in einer alten Ausruestung verwenden oder nicht? Ja oder… Das wird ziemlich offensichtlich, wenn ich eine falsche Empfehlung gebe. Wenn ich also ein Teil habe, das in beide Richtungen kompatibel ist, will ich es aggressiver haben. Das ist interessant.

Wenn meine Empfehlung fuer einen Benutzer sehr falsch ist, ich sage “fuenf”, und der Benutzer sagt: “Hey, warum? Wir brauchen das alte Teil nicht mehr. Das neue kann das alte und das neue reparieren, also wollen wir 20.” Dann kommen wir sehr schnell, wenn wir den Inspector anschauen und so weiter, zu dem Schluss: “Ah, ja, wir wussten nicht, dass dieses Teil fuer diese zwei Nachfrageszenarien funktioniert.”

Warum? Weil wir die Daten nicht richtig hatten. Dann weiss man: “Ja, diese Daten sind es wert, korrigiert zu werden”, weil wir tatsaechlich Datenpunkte betrachten, die uns helfen. Wenn man nur um des Bereinigens willen bereinigt, kommt man nie irgendwo an und hoert nie auf zu bereinigen.

Conor Doherty: Gut.

Fabian Hoehner: Warum grinst du?

Conor Doherty: Jemand gratuliert uns… Alex hat sich gerade selbst als klug bezeichnet. Er ist ziemlich klug. Er ist ein kluger Junge. Ja.

Eine der Fragen, und ich habe verschiedene Versionen dieser Frage zu einer allgemeinen Version zusammengefuehrt, betrifft im Wesentlichen die Implementierung. Konkret: Integrationsaufwand, Datenanforderungen, du hast Datenanforderungen schon angesprochen, aber Integrationsaufwand, Datenanforderungen, Sicherheit, Support, Skalierbarkeit ueber eine grosse Lieferantenbasis, Engineering, eine Einschaetzung dazu, Zeitplananforderungen usw. Ich verstehe, wie lang ist ein Stueck Schnur? Es haengt jeweils ab. Ich verstehe das, aber eine grobe Antwort fuer Leute, die zuschauen und interessiert sein koennten.

Fabian Hoehner: Sechs Monate.

Conor Doherty: Okay. Ungefaehr, kann schneller sein, kann laenger sein.

Fabian Hoehner: Ja. Und ja. Okay.

Typischerweise, es haengt von allem ab, aber zwei Monate, um Daten zu bekommen und ein ungefaehres gemeinsames Verstaendnis dessen zu bekommen, was man betrachtet, also Datenqualitaet auf hoher und niedriger Ebene, bei der man einfach dieselbe Interpretation der Daten hat. Zwei Monate fuer eine grobe Optimierung. Wir sind darin eigentlich ziemlich schnell, und dann noch zwei Monate zum Feinabstimmen, aber auch parallel laufen lassen, denn die Art, wie wir arbeiten, ist: Jeder macht bereits das, was wir hier tun.

Die Unternehmen, mit denen wir arbeiten, treffen bereits taeglich Entscheidungen: “Was soll ich kaufen? Worin soll ich investieren?” Im Grunde laesst man es also parallel zu ihren Prozessen laufen, und dort kommt die Verbesserung. Das bringt mich zu einer kleinen Funktion in Bezug auf Historie: Wie vergleicht man mit der Vergangenheit, oder wie bewertet man?

Eine Funktion, die ich gern hervorhebe: Auf der Plattform sind wir vollstaendig kompatibel damit, die Vergangenheit zu bewerten. Was meine ich damit? Wenn wir uns die Historie ansehen, kann ich alle frueheren Ausfuehrungen sehen, die ich habe. Zum Beispiel kann ich buchstaeblich sehen, was ich heute getan habe.

Ich kann das Dashboard ansehen, das ich vor ein paar Stunden ausgefuehrt habe. Und was ich hier tun kann, und was man tatsaechlich sieht, ist, dass ich angenommen habe, du wuerdest mich nach Budget fragen. In diesem Fall habe ich das Budget auf, sorry, 1 Million statt 10 Millionen gesetzt. Und wenn wir jetzt zu unseren 98 % zurueckgehen, was war vorher die Investition, erinnerst du dich?

Conor Doherty: 1,2… 2 Millionen.

Fabian Hoehner: Sehr gut. Was wir hier jetzt tun: Wir kommen nur noch auf 900.000, weil ich eine Begrenzung von 1 Million eingegeben habe. Man sieht tatsaechlich, ich kann mit diesem Dashboard spielen. Ich kann es ausfuehren.

Ich kann das mit jedem Dashboard tun, das ich in der Vergangenheit hatte. Ich kann sagen, die meisten Leute halten das nicht fuer eine sehr wichtige Funktion, aber sie ist unglaublich wertvoll, besonders wenn man zu jedem Zeitpunkt in die Vergangenheit zurueckgehen und sehen will, was wir getan haben. Oft, wenn es eine AOG-Situation gibt, geraten Unternehmen, ich will nicht sagen in Panik, aber sie gehen in einen Untersuchungsmodus: “Wie ist es passiert? Was haben wir falsch gemacht?”

In diesem Fall wird es unglaublich schwierig, ich meine, wir sprechen von Lieferzeiten von sechs Monaten fuer ein Teil, das System und das eigene Handeln zu hinterfragen, wenn man sich nicht an die Stelle versetzen kann, an der man im Januar 2026 war. In diesem Fall kann ich einfach in meine Simulation 2026 gehen und werde potenziell sehen: “Ja, wir wollten eine dritte Einheit davon bekommen. Es war interessant zu kaufen. Allerdings waren wir eingeschraenkt und hatten nur ein Budget von, ich weiss nicht, 10 Millionen, und deshalb haben wir es nicht gekauft.”

Dann wissen wir es. Die Konsequenz koennte sein: “Ja, wir sollten unsere Budgets erhoehen und mehr Geld verfuegbar haben.” Oder die Konsequenz koennte auch sein: “Tatsaechlich haben wir das nicht richtig priorisiert.” Wir haetten der Fehlmenge eine hoehere Strafe geben sollen, und die Konsequenz ist, dass wir den Algorithmus aendern. Das ist absolut entscheidend. Man geht von einer, ich wuerde sagen, eher sinnlosen Untersuchung zum Hinterfragen des zugrunde liegenden Systems, und die Konsequenz ist dann entweder: “Der Algorithmus hat getan, was er tun sollte, und das ist in Ordnung.”

Ja. Manchmal hat man extreme Ereignisse und Fehlmengen. Wir sagen hier, wir gehen auf 98. Das bedeutet, in 2 % werden wir Fehlmengen haben.

Das ist einfach Statistik. Aber man koennte auch sagen: “Schaut darueber hinaus. Wir sollten den Algorithmus aendern, damit er in Zukunft besser ist.” Aber das ist ein kontinuierlicher Prozess. Optimierung ist ein kontinuierlicher Prozess.

Es ist ein kontinuierlicher Fluss: Man versucht, nach Perfektion zu streben, die man per Definition nie erreicht. Deshalb ist es wichtig, etwas zu haben, womit man in die Historie schauen und neue Daten auf altem Code ausfuehren kann. Ich kann die Berechnungen, die Gewichtung, die Strafe, die wir fuer ein kundensichtbares Teil geben, und so weiter nehmen.

Ich kann Daten von heute mit einem Code oder Algorithmus ausfuehren, der sechs Monate alt ist, oder umgekehrt alte Daten nehmen und sagen: “Okay, was wuerde passieren, wenn ich sie in den heutigen Optimierer stecke?” Wieder werden nur sehr wenige Leute danach fragen, aber es ist eine extrem starke Funktion, die urspruenglich geschaffen wurde, um Bugs zu beheben, denn das ist wichtig. Wenn Daten sich von einem Tag auf den anderen aendern, kann es sein, dass der Bug nicht mehr da ist, und das ist schlecht, weil man weiss, dass da etwas ist, es aber nicht lokalisieren kann. Aber ich schweife ab.

Conor Doherty: Okay, schweif nicht ab. Es ist gut, die konkreten Informationen festzuhalten. Wir haben noch ein paar Fragen.

Du bist bereit? Weiter. Perfekt.

Fabian Hoehner: Nein, sorry.

Conor Doherty: Gut. Diese Frage ist wieder nicht explizit ueber Einkauf. Sie geht eher um andere Optionen.

Im Wesentlichen: “Kann Lokad entscheiden, ob wir eine weitere Einheit kaufen oder eine bestehende Einheit zwischen Standorten verschieben sollten?” Wir entfernen uns etwas vom heutigen Thema. Wir oeffnen kein weiteres Dashboard, aber eine Antwort auf hoher Ebene?

Fabian Hoehner: Ja. Also…

Conor Doherty: Ja. Naechste Frage.

Fabian Hoehner: Okay. Erledigt. Nein.

Hier kommt wirtschaftliche Priorisierung ins Spiel. Am Ende, und das wird wahrscheinlich sehr langweilig, wird meine Antwort immer sein: “Wenn es logisch ist, koennen wir es tun.” Welche Logik sollten wir hier anwenden? Die Frage ist einfach: Zuerst will man simulieren, wie hoch die Bedarfswahrscheinlichkeit ist.

In diesem Fall, fuer ein Allokationsproblem, muss man zuerst die Nachfrage pro Standort simulieren. Zum Beispiel hat man MBKs an 100 Aussenstationen. Das ist offensichtlich schwierig. Es ist schwieriger zu prognostizieren, wenn es noch spaerlicher ist, aber man muss es tun. Wir sagen immer: “Nicht die Einfachheit der Berechnung entscheidet ueber die Simulationsebene, sondern die Entscheidung, die man treffen will.”

Wenn ich also den Bedarf fuer ein Teil nach Standort simulieren will, muss ich auf Standortebene prognostizieren. Um nun die Frage zu beantworten: Was muessen wir tun? Muessen wir mehr fuer den zentralen Bestand kaufen oder muessen wir umverteilen? Am Ende ist es eine wirtschaftliche Frage.

Es ist einfach die Frage, was die Kosten des Verschiebens des Teils sind relativ zu… Man verschiebt das Teil. Das bedeutet, man erhoeht das Risiko an der Station, von der man das Teil wegbewegt. Erhoehtes Risiko plus Logistikkosten gegen externe Investitionskosten. Das ist der Kapitalkostenaspekt. Ja, am Ende ist das ziemlich logisch und berechenbar.

Fuer uns ist die Quintessenz immer: Wir koennen das auf den Euro, Dollar, Pfund, was auch immer, berechnen. Aber die Frage ist immer: Wie gross ist das Problem, und wie oft haben wir diese Frage? Man kann das auch mit einer einfachen Dreisatzregel loesen. Aber wenn es eine relevante und hochwertige Frage ist, dann koennen wir genau auf diese Ebene gehen.

Conor Doherty: Okay. Einige…

Fabian Hoehner: Sag mir, wenn es nicht klar ist.

Conor Doherty: Nein, nein, nein. Vollkommen klar. Mir ist auch bewusst, dass es noch andere Fragen gibt, und ich will nicht bremsen. Alles, was unklar ist, dazu habe ich schon ein paar Nachrichten von Leuten bekommen, die sagen, sie wollen nachfassen, weil das zu lange dauern wuerde: “Okay, was ist mit dieser Situation? Und jener Situation?”

Fabian Hoehner: Nur um klar zu sein: Mein Punkt ist, ich wollte sicherstellen, dass wir diese zwei Prinzipien haben: Unsicherheit, also im Grunde verschiedene Unsicherheiten, Turnaround Time und Nachfrage gemischt, geben uns eine Sicht auf die Unsicherheit, und wirtschaftliche Priorisierung. Damit koennen wir ziemlich sicher 95 % aller zugrunde liegenden Fragen beantworten. Sei es, was du am Anfang gefragt hast, Consumables und Expendables. Jetzt haben wir ueber die Schleife gesprochen.

Okay, die Schleife ist komplizierter, aber am Ende sind C&E dasselbe. Es ist einfach Bestand rein und raus, also 100 % Ausschuss, wenn man so will. Das zugrunde liegende Prinzip ist etwas dasselbe. Man kann exakt dieselbe wirtschaftliche Optimierung machen.

Man kann, muss aber nicht. Wenn das zugrunde liegende Problem einfach ist, kann man es auch einfacher loesen. Wir muessen es nicht mit dieser Art Optimierung tun. Aber das waere normalerweise die starke Empfehlung. Wenn wir schnell und pragmatisch starten muessen, koennen wir immer quick and dirty anfangen, um etwas zu haben, das besser als das Bestehende und automatisiert ist, denn automatisiert schlaegt den Menschen fast immer.

Und dann in die zweite Stufe gehen. Ich habe Tonnen anderer Dashboards, aber da will ich nicht hineingehen. Nur grundsaetzlich: Allokation, ja, natuerlich kann man ein Dashboard haben, das sagt: “Du musst von einem Standort zu einem anderen allokieren.” Okay, grossartig. Ich will hier nicht in die Mathematik gehen.

Conor Doherty: Ja, das wird Thema eines Follow-ups. Das wuerde die Sache vernebeln.

Fabian Hoehner: Die Dinge auf hoher Ebene, die ich hervorheben wollte. Aber ja, wir haben, ich wuerde sagen, es haengt immer davon ab, was man als Modul definiert. Sind unterschiedliche Lieferzeiten auf Turnaround Times, die skalieren, ein Modul? Es haengt davon ab. Oder ist nur Einkauf im Modul? Man kann sagen, wir haben 20 verschiedene Module, also sieht man hier einige Ideen.

Conor Doherty: Ja. Daran anschliessend, vielleicht hat jemand einen frueheren Abschnitt verpasst, aber es ist eine Live-Frage, also stellen wir sie. Sie ist von Saddaf, hoffentlich spreche ich das richtig aus. “Koennen Sie etwas genauer erklaeren, wie Lokad Lieferantenverzoegerungen bei der Berechnung der optimalen Einkaufsmenge behandelt?”

Fabian Hoehner: Ja. Also…

Conor Doherty: Du kannst es noch einmal zeigen, wenn du fuer alle, die es vorhin verpasst haben, ins Dashboard zurueckspringen willst.

Fabian Hoehner: Ja, sicher. Die Frage ist: Was ist eine Verzoegerung im Vergleich zu etwas, das man einfach beruecksichtigen muss? Eine Verzoegerung bedeutet, dass man einen erwarteten Wert hat und es jetzt laenger dauert. Darauf gibt es zwei Antworten.

Die eine waere die Expedite-Aktion. Man hat angenommen, es wuerde 30 Tage dauern, und jetzt ist man bei Tag 40. In diesem Fall liefern wir typischerweise eine gerankte Prioritaetenliste: Wen ruft man zuerst an? Denn wenn ich ein Teil habe, das 10 Tage verspaetet ist, aber fuenf einsatzfaehige Teile herumliegen, ist mir egal, ob es verspaetet ist.

Es ist fuer mich wirklich nicht wichtig. Andererseits, wenn ich eines habe, das nicht einmal verspaetet ist, wir sind bei Tag 25, aber ich bin out of stock und weiss, dass es super dringend ist, will ich wahrscheinlich zum Telefon greifen und sagen: “Hey, koennt ihr wirklich alles tun, um das Teil hereinzubekommen?” Das ist die eine Haelfte der Antwort darauf, wie wir mit Verzoegerungen umgehen. Die Frage ist: Kann man etwas tun?

Und dann den Nutzern die Moeglichkeit geben zu priorisieren. Es geht immer darum: Was ist die Auswirkung, wenn etwas falsch laeuft? Das ist die erste Haelfte der Antwort. Die zweite Haelfte ist das, was wir hier betrachtet haben…

Conor Doherty: Was ist die Definition von verspaetet?

Fabian Hoehner: Ja. Am Ende wuerden wir eher sagen: Es gibt verschiedene Lieferzeiten. Ja, schoen, wenn in einem Vertrag “60 Tage” steht. Wenn es in der Realitaet immer 120 dauert, will man das in der Einkaufsempfehlung beruecksichtigen.

Genau das haben wir hier getan. Man sagt nicht: “Es sind immer 80” oder “es sind immer 120”, egal welche Zahlen. Man sagt: “Es gibt all diese Moeglichkeiten”, und dann ist die Nachfrageverteilung, die wir hier sehen, eine Nachfrageverteilung ueber alle moeglichen Lieferzeiten. Genau deshalb machen wir das alles.

Um die unkontrollierbare Unsicherheit anzunehmen, und Turnaround Times sowie Lieferantenlieferzeiten sind ein grosser Teil davon. Und um ganz klar zu sein: Wir sind nicht darauf eingegangen, aber auch das wird prognostiziert. Ich habe es immer einfach dargestellt: Wir schauen auf die Vergangenheit, und die Vergangenheit repraesentiert die Zukunft.

Wir wissen natuerlich, dass die Vergangenheit nicht immer die Zukunft repraesentiert. Wir waren mit unseren Kunden waehrend COVID und danach dabei, also Rueckgang und dann Hochlauf und unglaubliche Anstiege der Turnaround Times. Wenn eine Turnaround Time so verlaufen wuerde, wuerden wir nicht sagen: “Die Vergangenheit repraesentiert die Zukunft.” Nein.

Dann prognostizieren wir natuerlich Turnaround Times und prognostizieren Nachfrage ueber prognostizierte Turnaround-Time-Verteilungen. Und ich nehme noch eine Frage vorweg. Ich sagte, wir schauen auf das letzte Jahr. Natuerlich koennen wir kommende Checks betrachten. Wenn ich also ein… Ja, wenn du eine Frage hast.

Conor Doherty: Nein, nein, das wird tatsaechlich Teil einer spaeteren Frage. Bitte fahr fort.

Fabian Hoehner: Okay, die typische Frage waere: Wie prognostiziert man zukuenftige Nachfrage? Schaut man nur auf die Vergangenheit? Es haengt davon ab. Wenn man einen Betrieb mit tausend Flugzeugen hat, also ein grosses MRO, und viel statistische Masse, dann ist die Vergangenheit tatsaechlich eine ziemlich gute Darstellung der Zukunft.

Wenn man jedoch mehr Informationen hat, und das ist immer die Frage, welches Informationsniveau hat man? Zum Beispiel weiss man, dass eine Reihe von D-Checks ansteht. Dann nehmen wir natuerlich die probabilistische BOM, die Bill of Materials, die selbst unsicher ist. Manche Teile weiss man, dass man sie ersetzen wird, dann hat man eine 100-%-Wahrscheinlichkeit, ein Consumable zu ersetzen. Bei anderen weiss man nur: Ich oeffne es…

Conor Doherty: und dann sieht man Korrosion, mit der man nicht gerechnet hatte.

Fabian Hoehner: Ja. Oder man weiss, dass man auf Basis frueherer C-Checks das Teil in 30 % der Faelle ersetzt. Das ist eine probabilistische Bill of Materials, bei der man sagt: “Das sind die 100 Teile, die ich brauchen werde, mit ihren Wahrscheinlichkeiten.” Wenn ich weiss, dass dieses Ereignis in zwei Monaten stattfinden wird, kann ich das einplanen.

Genau das tun wir. Die Realitaet ist natuerlich komplizierter, denn wenn man sagt: “Wir haben in zwei Monaten einen C-Check”, wie oft ist er wirklich in zwei Monaten? Auch dort gibt es Unsicherheit. Wenn ich also sage, ich habe zwei Hauptunsicherheiten eingefuehrt, koennen wir in der Realitaet noch mehr haben, und das erhoeht einfach immer meine Unsicherheit, verbreitert die Verteilungen, aber am Ende laeuft es auf dieselbe Frage hinaus: Wie viel Abdeckung bekomme ich, wenn ich in ein weiteres Teil investiere, und ist es das wert? Bin ich bereit, ich weiss nicht, was dieses kostet, 10.000 Dollar auszugeben, um noch, was ist es, 0 Punkt oder weitere 4 % oder was auch immer zu bekommen?

Conor Doherty: Fuer mich klar. Und es ist auch gut, darauf hinzuweisen, warum die Dashboards hier so kritisch sind. Eine Anschlussfrage, sie ist von Metan, verzeihung, wenn ich es falsch ausspreche. Sie betrifft einen sehr wichtigen Punkt, der zuvor aufkam: Das beste Set an Investitions-, Desinvestitions- oder Allokationsentscheidungen zu erzeugen ist grossartig, aber wenn es mangelnde Adhaerenz gibt, das heisst, wenn die Leute einfach nicht ausfuehren, ist das ein Problem.

Die Frage lautet also: Wie wisst ihr tatsaechlich, das ist eine oeffentliche Frage, “wie wisst ihr tatsaechlich, ob das Unternehmen, sagen wir ein Kunde, das vorgeschlagene Teil wirklich gekauft hat?” Du hast vorhin ueber Rueckverfolgbarkeit gesprochen. Koennen wir verfolgen: “In X Prozent der Faelle wurden diese Entscheidungen befolgt?”

Fabian Hoehner: Ah, okay. Ja. Also…

Conor Doherty: Einfache Pruefung, Auditierbarkeit, Entschuldigung.

Fabian Hoehner: Wie wuerdest du das verfolgen, Conor?

Conor Doherty: Mit einem Computer.

Fabian Hoehner: Ja. Okay. Grossartig. Im Kern sehen wir die Ausfuehrung, wenn ich taeglich die Transaktionshistorien von allem bekomme.

Das beinhaltet den Einkauf. Ich sehe buchstaeblich, ob jemand meiner Empfehlung gefolgt ist. Offensichtlich vereinfache ich hier stark, aber sagen wir einfach: Am Montag habe ich fuenf empfohlen. Der Run lief Sonntagabend. Montagmorgen sieht der Operator: “Okay, fuenf empfohlen.”

Und dann sehe ich im Dienstag-Run fuenf. Dann kann ich sagen: “Ich habe 100 % Adhaerenz.” Ich vereinfache stark, und in der Realitaet ist es komplizierter, weil es bei solchen Fragen lange Verzoegerungen geben kann, bevor man ein Angebot macht und so weiter. Aber im Kern: Ja, wir verfolgen das, und fuer etwas Automatisiertes, wenn wir ueber Consumables sprechen, kann man das sehr gut verfolgen.

Dort ist es viel einfacher. Man hat einfach Masse. Das ist einfacher. Hier, auf der gesamten Rotable-Seite, ueber die wir gesprochen haben, wuerde ich sagen, dass menschliches Feedback wahrscheinlich am wichtigsten ist. Diese Listen schauen wir uns buchstaeblich mit unseren Kunden an, und noch einmal, wir sind sehr gut in Mathematik und Statistik, aber wenn ich wir sage, meine ich…

Conor Doherty: Ja, du bist ein absolutes Genie.

Fabian Hoehner: Nein, ich meine, es ist eine sehr starke Plattform, und wir haben kluge Ingenieure, und das ist unsere Expertise. Wir sind seit etwa 13 Jahren im Luftfahrtsektor. Wir haben einiges an Expertise aufgebaut, aber wir behaupten nie, Luftfahrt besser zu kennen als unsere Kunden. Wann kommt ein Retrofit? Wenn wir mit Luftfahrtunternehmen zusammen sind, sind das sehr leidenschaftliche Menschen. Wenn sie ein Flugzeug sehen, wissen sie sofort, welches Flugzeug es ist, welche Teile darin sind und so weiter. Wir sind eher die Statistikseite.

Was bedeutet das? Wir stuetzen uns immer stark auf die Expertise und das Feedback der Nutzer, und dann gestalten wir die Dashboards zu 100 % fuer sie. Wenn sie uns sagen: “Ja, ich will, dass das anders aussieht. Ich will andere Farben. Ich will was auch immer.”

Ja, wir hoeren zu und gestalten es fuer diesen Zweck. Das neu zu bauen, es neu zu designen, das ist fuer uns ein halber Tag. Nicht einmal. Wenn du willst, kann ich ueber KI sprechen, aber das ist ein anderes Thema.

Conor Doherty: Nein, ich mache weiter. Das ist eher ein Kommentar. Entschuldigung, Moment. Ja.

Es geht im Grunde darum, wie viel des manuellen Einkaufsprozesses tatsaechlich entfernt werden kann, wenn man mit Lokad arbeitet, denn ich will das nicht falsch darstellen. Du hast das vorhin angesprochen, als du ueber Rotables gesprochen hast. Je nach Preis wird man natuerlich immer noch einen Experten in der Schleife haben, um einen Kauf von 90.000 Dollar zu validieren. Aber wie viel dieses Prozesses kann tatsaechlich, wie viel der darin investierten Zeit kann freigesetzt werden? Und dieselbe Frage, wenn wir ueber C&E sprechen.

Fabian Hoehner: Ja, ich werde meine Antwort von vorhin wieder aufnehmen.

Conor Doherty: Ja, ich lese nur vor.

Fabian Hoehner: Ja. Natuerlich. Es haengt von der Komplexitaet dessen ab, was man tut. Und ich wuerde sagen, C&E kann man wirklich zu einem sehr grossen Teil automatisieren.

Wenn ich das sage, meine ich ueber… Ja, ich weiss, vieles ist bereits mit Reorder Points automatisiert. Wir haben Min-Max. Das kann man automatisieren, aber mit einem viel intelligenteren System. So etwas kann potenziell zum Beispiel Reorder Points, wenn wir wollen, taeglich zuruecksetzen, damit es die Entscheidung ausfuehrt, die wir wollen.

Das tun wir fuer einige Kunden. Und ich wuerde sagen, darin liegen auch enorme Zeiteinsparungen. Aber wenn man wieder Teile fuer Millionen von Dollar kauft, dann geht es an diesem Punkt weniger um Zeiteinsparungen, die definitiv vorhanden und recht gross sind, sondern darum, besser zu sein. Das ist wirklich der Kern des Spiels. Man vermeidet ein paar AOGs, und dann werden Kosten bis zu einem gewissen Grad irrelevant.

Conor Doherty: Ich glaube, ich habe alles abgedeckt, denn es ist jetzt 17:45. Wir sind seit etwa 75 Minuten dabei. Ich weiss, es gab einen harten Schluss gegen sechs, also denke ich… ach nein, es gibt noch eine letzte Frage, Entschuldigung. Ich denke, jeder, der die Demo gesehen hat, wird sie verstehen, aber um konkret zu sein: Wie unterscheidet sich Lokad von anderen Procurement-Plattformen in diesem Bereich, zum Beispiel Aeroxchange? Eine Person vergleicht aktiv zwei Kategorien und will den Unterschied zwischen Entscheidungsoptimierung und Dingen wie RFQ-Verarbeitung, Angebotsvergleich, PO-Verarbeitung usw. verstehen.

Fabian Hoehner: Es gibt verschiedene Aspekte, die… Nein, ich sage nur, es gibt verschiedene Aspekte, die Aeroxchange macht. Aber auf hoher Ebene moechte ich sagen: Wir sind nicht per se eine Procurement-Plattform. Noch einmal, ein System der Intelligenz. Der Unterschied…

Conor Doherty: Entscheidungsfindung.

Fabian Hoehner: Ja. Man hat seine Transaktionssysteme. Wir sitzen darueber. Wir sind das Gehirn, und wir spielen die bestmoeglichen Entscheidungen zurueck, die Statistik und Business Intelligence liefern koennen und die dann ausgefuehrt werden sollten. Aeroxchange hat auch mehr Procurement-Funktionen zur Automatisierung der Einkaufsfunktion selbst, der Kommunikation.

Das ist nicht, was wir tun. Wieder: Wir koennen uns mit verschiedenen Lieferanten integrieren, Dinge abgleichen und Kommunikation darin haben, aber wir listen keine Preise oder so etwas. Das ist nicht unser Geschaeftsmodell. Ich wuerde uns also nicht Procurement-Plattform nennen. Ich wuerde sagen: Entscheidungsautomatisierung, Entscheidungsunterstuetzung und System der Intelligenz, als Zusammenfassung.

Conor Doherty: Gut. Eine letzte, wieder eher ein Kommentar. Die Leute scheinen verstaendlicherweise komfortabler damit zu sein, DMs zu schicken, als oeffentlich zu kommentieren. Ich lese wortwoertlich: “Schoen, aber ich interessiere mich mehr fuer Reparaturen. Kann dieser Ansatz angewendet werden, um Reparaturen und Expediting zu priorisieren?”

Fabian Hoehner: Ja. Das war einfach, oder? Ja.

Conor Doherty: Goehn dem Publikum ein bisschen mehr bei der Antwort.

Fabian Hoehner: Nein, ernsthafter gesagt, es ist wieder dieselbe Logik. Jetzt frage ich, statt ein Teil zu kaufen, ob ich mein nicht einsatzfaehiges Teil reparieren sollte. Sagen wir, man hat 10 nicht einsatzfaehige Teile und null auf Lager. Statt zu kaufen, macht man es einfach einsatzfaehig.

Es einsatzfaehig zu machen, ist in diesem Fall eine Reparatur mit einer Reparaturschleife, also einer Turnaround Time, und es kostet etwas. Ob intern oder extern, beides hat Kosten, aber nehmen wir externe Reparatur, weil es einfacher ist. Sagen wir, es kostet 50.000, das Teil einsatzfaehig zu machen. Die erste Frage ist: Wie priorisiere ich?

Denn ich habe ein Reparaturbudget, das ich ausgeben will, oder sogar nur physische Kapazitaet. Ich kann 50 Teile pro Tag verarbeiten. Welche sind die dringendsten? Und sogar: Welche sind wirtschaftlich ueberhaupt sinnvoll zu reparieren?

Zum Beispiel nach COVID, das war ein grosses Thema. Fuer einige unserer Kunden wurde Cash natuerlich ein echtes Problem. Es gab schlicht kein Cash. Also lautet die Frage: Was tut man?

Denn man hat weiterhin alle Leasingverpflichtungen und so weiter, aber keine Cash-Zufluesse mehr. Das Erste, was man tun konnte, war genau das: Reparaturen einfach anhalten, denn es gibt einen grossen Cash-Abfluss allein durch das Reparieren nicht einsatzfaehiger Teile. Man kann den bestehenden Bestand kannibalisieren und sie nicht einsatzfaehig lassen, was zu dieser Zeit sehr vernuenftig war, Dinge unrepariert zu lassen. Denn wenn man keine Nachfrage hat, wenn waehrend COVID 20 % der Flotte fliegt, reduziert das die Nachfrage nach einsatzfaehigen Teilen erheblich. Man stoppt einfach, aber man kann nicht, und das ist wieder das Problem, einfach sagen: “Ich repariere nicht mehr.”

Man braucht eine priorisierte Liste. Man muss also zwischen Teilen priorisieren, die kritisch sind und die man trotzdem reparieren muss, weil es einem wirklich das Genick brechen wuerde, wenn man sie nicht hat, und anderen, bei denen man 10 auf Lager und fuenf nicht einsatzfaehig hat. Weisst du was? Man wird in Ordnung sein, wenn man etwas mehr Risiko nimmt und ein paar mehr nicht einsatzfaehig laesst oder nur eines repariert.

Also dieselbe Logik. Ja. Und Turnaround Times werden dann noch wichtiger. Wenn man dann zusaetzliche Timestamps hat, Ausschusswahrscheinlichkeit, sehr wichtig dabei. Ja, aber dieselbe zugrunde liegende Logik, und ja, wir zeigen auch Dashboards dafuer, aber das fuehrt in eine andere Richtung.

Conor Doherty: Gut. Mein Schlussgedanke ist: Wenn du, wieder zum Kreis schliessend, die wichtigsten Punkte zusammenfassen muesstest, die die Leute mitnehmen sollen, wenn sie erst jetzt einschalten oder direkt zum Q&A-Teil springen, wie wuerdest du den Ansatz fuer Einkaufs-, Investitions- und Desinvestitionsentscheidungen in Aerospace zusammenfassen? Und was sind die wichtigsten Takeaways?

Fabian Hoehner: Erstens sollten sie sich schaemen, nicht alles gehoert zu haben. Zweitens…

Conor Doherty: Ziemlich gut. Der dritte fuer…

Fabian Hoehner: Ich wiederhole: Unsicherheit anerkennen. Das bedeutet, Unsicherheit existiert in vielen Formen, sei es Turnaround Times, sei es Nachfrage, sei es probabilistische Bill of Materials. Sie existiert ueberall, und man sollte sie nicht durch Vereinfachung aus dem Bild herausplanen. Also anerkennen, und es gibt Technologie, um das besser zu tun.

Und zweitens: mit wirtschaftlichen Konsequenzen priorisieren. In der Luftfahrt ist die Konsequenz typischerweise Servicegradgewinn oder AOG-Vermeidung pro ausgegebenem Dollar. Das sind zentrale Konzepte, die man mitnehmen sollte. Und was tun wir bei Lokad? Wir haben eine leistungsfaehige Plattform dafuer, und wir haben brillante Supply Chain Scientists, die dies gemeinsam mit unseren Kunden gestalten. Das ist Lokad in der Luftfahrt auf den Punkt gebracht.

Conor Doherty: Gut. Fabi, ich habe keine weiteren Fragen. Vielen Dank, dass du heute bei mir warst. Es ist ein Vergnuegen, dich im Studio zu haben, und ich hoffe, alle anderen haben deine Stimme genauso gern gehoert wie ich.

Fabian Hoehner: Zu freundlich.

Conor Doherty: Sie sind eine Ehre fuer die Menschheit, mein Herr.

Fabian Hoehner: Danke.

Conor Doherty: Kein Problem. Und danke an alle fuers Zuschauen. Danke fuer eure Kommentare und Fragen.

Ein besonderer Dank an all die Leute, mit denen ich im letzten Monat oder so gesprochen habe. Wir haben diese Veranstaltung etwa einen Monat lang beworben. Ich habe mit vielen Leuten gesprochen, viele gefragt: “Was wollt ihr sehen?” Und wie man sehen kann, habe ich das Feedback aufgenommen und versucht, das, was wir heute gesehen oder gezeigt haben, an die Wuensche des Publikums anzupassen.

Wenn es Dinge gibt, die wir nicht behandelt haben und die euch wirklich interessieren, koennt ihr euch gern direkt mit Fab und mir auf LinkedIn verbinden. Ihr koennt uns klar sehen. Wir reden gern. Wir sind reizend.

Klickt auf das Profil, schickt uns eine Nachricht. Oder wenn ihr bereits ueberzeugt seid und einen Call buchen und etwas mehr erfahren wollt, sollte es einen Link im Chat geben. Falls nicht, koennt ihr uns direkt eine E-Mail an contact@lokad.com schicken. Wie Fabi vorhin kurz gezeigt hat, gibt es weitere Module, ueber die wir in Aerospace sprechen koennen.

Wir haben sie heute nicht behandelt, aber wir werden zu einem spaeteren Zeitpunkt zurueckkommen, um sie zu behandeln. Bis dahin bleibt nichts mehr zu sagen ausser: Ja, zurueck an die Arbeit. Oh, okay. Bitte.