Software Frankensteinisierung in supply chain

00:00:04 Einführung in die Software Frankensteinisierung.
00:00:35 Auswirkungen der Software Frankensteinisierung auf B2B-Software.
00:01:31 Wie Kundenanforderungen die Software Frankensteinisierung beeinflussen.
00:02:32 ‘Narben’ in der Software und ihre Implikationen.
00:05:33 Wartungskosten der Software Frankensteinisierung.
00:08:00 Herausforderungen und Kosten neuer Softwarefunktionen.
00:08:57 Funktionen ohne Komplexität: B2C-Einblicke.
00:10:36 Probleme mit dem B2B-Ansatz bei Softwarelösungen.
00:13:18 Lokads Erfahrung: richtig vs. schnell & technische Schulden.
00:15:14 Envision: Lokads Lösung für Komplexität.
00:16:30 Domänenspezifisches Scripting: Begrenzungen & Konflikte vermeiden.
00:17:43 Das Angehen von Software-Bloatware in supply chains.
00:18:01 Strategien zur Vereinfachung komplexer Software.
00:20:54 Umgang mit der ’technologischen Masse’ in Softwaresystemen.
00:22:00 IT-, supply chain- und Marketing-Synergien bei Systemänderungen.
00:22:43 Probleme durch übermäßige Softwareanpassung.
00:23:48 Prüfung der Integrität des Softwareanbieters durch Anpassung.
00:24:00 Einfluss auf die Produktentwicklungsstrategie gewinnen.
00:26:08 Auswahl schlanker, fokussierter Software, um Anpassungen zu vermeiden.

Summary

Im Lokad TV stellt Joannes Vermorel das Konzept der Software Frankensteinisierung vor, das sich darauf bezieht, wie B2B-Software durch willkürliche Modifikationen, die nicht ihrem ursprünglichen Design entsprechen, weiterentwickelt wird. Er vergleicht diese Veränderungen mit “Narben”, die zur Entstehung eines zusammengesetzten, evolvierten Softwaresystems beitragen. ERPs werden als Beispiel angeführt, wobei das Dilemma zwischen der Beibehaltung der Softwarearchitektur und der Erfüllung neuer Anforderungen hervorgehoben wird. Vermorel warnt vor vorschnellen Entscheidungen, die oft zu Software-Narben und steigenden Wartungskosten führen. Während er die unvermeidliche Komplexität im Softwaremanagement anerkennt, betont Vermorel die Bedeutung, von B2C-Modellen zu lernen, um die Wechselwirkungen von Funktionen zu kontrollieren. Lokads Reaktion auf dieses Problem ist “Envision”, eine domänenspezifische Programmiersprache, die infrastrukturelle von domänenspezifischen Problemen trennt.

Extended Summary

In der neuesten Episode von Lokad TV dreht sich das Gespräch um das Konzept der Software Frankensteinisierung, ein Begriff, den Joannes Vermorel, der Gründer von Lokad, geprägt hat. Er verwendet diesen Begriff, um die Transformation von B2B-Software im Laufe der Zeit darzustellen, insbesondere langlebiger und supply chain software, die sich durch kontinuierliche Verhandlungen und große Geschäfte zwischen Softwareanbietern und ihren Kunden entwickeln.

Vermorel erklärt, dass Software Frankensteinisierung eintritt, wenn Anpassungen an der Software als Reaktion auf Kundenanforderungen vorgenommen werden. Diese Änderungen stehen häufig im Widerspruch zur ursprünglichen Architektur, Philosophie und dem Design der Software. Infolgedessen sammelt die Software diese Modifikationen oder “Narben” im Laufe der Zeit an, wodurch sie zu dem wird, was Vermorel als ein “Frankenstein-Monster” beschreibt – ein zusammengesetztes und auf merkwürdige Weise entwickeltes Softwaresystem.

Er weist weiter darauf hin, dass dieses Phänomen besonders in supply chain software ausgeprägt ist, aber auch bei vielen B2B-Softwaretypen häufig vorkommt. Dennoch stellt er klar, dass der Begriff “Narbe” nicht von vornherein negativ zu verstehen ist. Diese Modifikationen können die Software verbessern, indem sie neue Funktionen hinzufügen und so ihre Leistungsfähigkeit steigern.

Vermorel führt das Beispiel von Enterprise Resource Planning (ERP)-Software an, die davon ausgeht, dass Saisonalität mithilfe fester 52-Wochen-Profile erfasst werden kann. Dieses Design funktioniert gut, bis eine Anforderung auftritt, die nicht in dieses Schema passt, wie etwa die Modellierung des chinesischen Neujahrs, des Ramadan oder von Ostern, die unterschiedliche Kalender nutzen und deren Termine jährlich variieren.

In solchen Fällen steht der Softwareanbieter vor einem Trade-off. Er kann der neuen Anforderung gerecht werden, indem er eine “hackhafte” Lösung integriert, die sich nicht nahtlos in die Architektur der Software einfügt, aber die benötigte Funktionalität bietet. Dieser Ansatz führt jedoch häufig zu weiteren “Narben”, die zur Software Frankensteinisierung beitragen.

Hervorhebend, wie schnell die Verhandlungen mit wichtigen Kunden im Softwaregeschäft verlaufen, warnt Vermorel davor, dass die Dringlichkeit unbeabsichtigt zu “Software-Narben” führen kann. Er definiert dies als einen Prozess, bei dem hastig implementierte Funktionen im Laufe der Zeit die Komplexität und die Wartungskosten der Software erhöhen.

Er erläutert die Feinheiten der Softwarearchitektur und weist darauf hin, dass jede Codezeile oder Funktion gewartet werden muss. Mit der Hinzufügung weiterer Funktionen werden die Verknüpfungen immer komplexer, was zu einem “quadratischen Komplexitätsproblem” führt. Im Wesentlichen nehmen die potenziellen Wechselwirkungen exponentiell zu, je mehr Teile vorhanden sind, was eine Vielzahl möglicher Probleme wie Bugs, Systemabstürze und Sicherheitsrisiken mit sich bringt.

Vermorel betont die Bedeutung einer sorgfältigen Softwarearchitektur, um die Anzahl der Wechselwirkungen zwischen den Funktionen zu kontrollieren. Er stellt dar, dass das Ziel darin bestehen sollte, den Wartungsaufwand bei einer Verdopplung der Funktionen nur zu verdoppeln, statt wie häufig bei übereilter Entwicklung zu vervierfachen oder noch mehr anzusteigen.

Auf die Frage, wie Softwareunternehmen neue Funktionen einführen können, ohne übermäßige Komplexität zu verursachen, schlägt Vermorel vor, von B2C-Softwareunternehmen wie Google und Netflix zu lernen. Diese nehmen sich Zeit, die spezifischen Probleme, die sie lösen möchten, zu verstehen und entwerfen Lösungen, die eine breite Kategorie ähnlicher Probleme abdecken. Er stellt diesen Ansatz der B2B-Welt gegenüber, in der die Kunden oft nicht nur mit Problemen, sondern auch mit eigenen Lösungsvorschlägen auftreten.

Bezüglich des Umgangs mit diesen Problemen gibt Vermorel zu verstehen, dass Lokad anfangs Schwierigkeiten hatte, das richtige Vorgehen und die schnelle Erfüllung von Kundenwünschen auszubalancieren. In den frühen Jahren stellten sie eine zunehmende technische Verschuldung fest, die Vermorel als nachteilig bezeichnet. Man erkannte, dass das Hinzufügen von Funktionen, um einzelnen Kunden entgegenzukommen, kurzfristig zwar vorteilhaft erscheinen mag, langfristig jedoch zu einem komplexen, inkonsistenten und schwer zu wartenden Produkt führt.

Als Reaktion auf diese Erkenntnis entwickelte Lokad eine einzigartige Lösung: eine domänenspezifische Programmiersprache namens “Envision”. Das Ziel von Envision ist es, infrastrukturelle Probleme von domänenspezifischen Problemen zu trennen, sodass Lokad das Hinzufügen und Warten neuer Funktionen effektiver steuern kann, ohne übermäßige Komplexität zu verursachen.

Vermorel führt weiter aus, dass Softwareprodukte, insbesondere in der supply chain industry, häufig mit einem Aufblähungsproblem zu kämpfen haben, das durch umfangreiche Anpassungen für jeden Kunden entsteht. Während die Anpassung darauf abzielt, maßgeschneiderte Lösungen zu liefern, führt sie oft zu einem komplexen, schwer handhabbaren System, das erhebliche Anstrengungen für Wartung und Upgrade erfordert. Um dem entgegenzuwirken, erläutert Vermorel, wie Lokad ein domänenspezifisches Skript, Envision, einsetzt, um hochgradig angepasste, aber dennoch handhabbare Lösungen für seine Kunden zu schaffen.

Im Zusammenhang mit der Softwarekomplexität fragt Chandler, was Softwareunternehmen tun können, um Bloatware zu vermeiden. Vermorel antwortet, dass das Szenario davon abhängt, ob ein Unternehmen Zugang zu seiner Software hat. Falls nicht, muss das Unternehmen mit der Komplexität der erworbenen Software zurechtkommen. Ist jedoch ein Zugang vorhanden, kann die Software vereinfacht werden, indem ungenutzte Elemente identifiziert und entfernt werden, was die Komplexität erheblich reduziert.

Mit dem Wechsel des Fokus auf die Verantwortlichkeiten von IT und supply chain executives stellt Vermorel fest, dass IT-Fachleute zwar über das technische Know-how verfügen, ihnen jedoch oft das Verständnis für den geschäftlichen Mehrwert bestimmter Funktionen fehlt. Dies führt zu einer Kluft zwischen notwendigen und unnötigen Funktionen. Daher müssen die wirtschaftlichen Entscheidungsträger eng mit der IT zusammenarbeiten, um Priorisierungen voranzutreiben und das System zu vereinfachen.

Vermorel gibt Ratschläge für supply chain executives, die in neue Software investieren möchten. Er warnt davor, übermäßige Anpassungen zu fordern, da dies zu weiteren Problemen führen kann. Statt bestimmte Funktionen in einen Vertrag zu pressen, sollten die Führungskräfte regelmäßig den Kontakt zu den Produktmanagern oder CTOs des Anbieters halten, um ihre Bedürfnisse direkt zu kommunizieren. Ziel sollte es sein, Probleme denjenigen zu präsentieren, die in der Lage sind, Lösungen zu entwickeln.

Schließlich rät Vermorel Unternehmen, sich für Software zu entscheiden, die in einem Punkt excels anstatt auf umfassende Lösungen setzt. Dieser fokussierte Ansatz erleichtert Verbesserungen und reduziert die Komplexität, die durch eine Vielzahl miteinander verbundener Funktionen entsteht. Indem Unternehmen nahe bei denjenigen bleiben, die die Roadmap steuern, und sich für scharf fokussierte Software entscheiden, können sie die Komplexität besser handhaben und die Produktivität steigern.

Full Transcript

Kieran Chandler: Heute werden wir das Thema Software Frankensteinisierung angehen. Also, Joannes, das ist ein Thema, das ziemlich schwer auszusprechen ist, also überlasse ich es wohl dir. Ich nehme an, wir sprechen heute nicht von einem großen grünen Monster. Wovon genau reden wir?

Joannes Vermorel: Wir sprechen über einen Prozess, der die Entwicklung von Software vorantreibt, insbesondere von B2B-Software und sogar noch spezifischer von supply chain software. Er gilt vor allem für langlebige B2B-Software. Dieser Prozess, den ich als “Frankensteination” bezeichne, entwickelt die Software über die Jahre hinweg weiter, begleitet von einem konstanten Strom großer Geschäfte, die zwischen den Softwareanbietern und ihren Kunden verhandelt werden. Das Interessante daran, woher der Begriff “Frankensteination” stammt, ist, dass jedes große Geschäft, das zwischen dem Anbieter und einem seiner Großkunden ausgehandelt wird, mit hoher Wahrscheinlichkeit eine Narbe in der Software hinterlässt.

Es ist ein allmählicher Prozess, bei dem ein Anbieter mit einem großen Unternehmen verhandelt. Das große Unternehmen hat Forderungen, und um diesen gerecht zu werden, werden Anpassungen an der Software vorgenommen, die nicht zur Gesamtarchitektur, Philosophie oder dem ursprünglichen Design passen. Die Funktion wird hinzugefügt, allerdings auf eine etwas hackhafte Weise. Das ist eine Narbe. Das Problem ist, wenn dieser Prozess über Jahre hinweg immer wieder wiederholt wird, landet man letztlich mit einer Art Frankenstein-Monster in der Software. Es ist ein Gebilde aus vielen Narben, das etwas Unansehnliches und hochgradig zusammengesetzt wirkt. Es entwickelt sich auf merkwürdige Weise, und so entstehen diese Frankenstein-Softwaremonster. Das passiert in den meisten Datenbanken, aber in supply chain software ist es, als ob sie auf Steroiden wäre.

Kieran Chandler: Lass uns über diese Narben sprechen, wie du sie nennst. Wie sehen sie aus? Ich meine, sie verbessern die Software, oder? Sie fügen zusätzliche Funktionen hinzu. Ist das wirklich so etwas Schlechtes?

Joannes Vermorel: Ja, offensichtlich ist das der Kompromiss. Man will die Software verbessern, aber ein Stück Software ist ein sehr kompliziertes Objekt. Es ist nicht wie ein Gebäude, dem man einfach einen Stock hinzufügen oder das sich schön erweitern lässt. Software kommt mit zahlreichen unverrückbaren Designannahmen, die sehr früh getroffen werden und der Software eine gewisse Integrität – architektonische Integrität – verleihen.

Nehmen wir als Beispiel viele ERPs, die um die Idee herum entwickelt wurden, Saisonalität mit Profilen zu erfassen, die genau 52 Wochen umfassen und ein bestimmtes Jahr repräsentieren. Man hat also buchstäblich eine Tabelle mit 52 Spalten, eine Spalte pro Woche, und diese Saisonalitätsprofile, die man auf jedes produzierte oder verkaufte Produkt anwenden kann. Aber was, wenn man etwas wie das chinesische Neujahr modellieren möchte? Es passt nicht in dieses 52-Wochen-Raster, da es sich gemäß dem traditionellen chinesischen Kalender von einem Jahr ins nächste verschiebt und nicht dem gregorianischen Kalender folgt. Ähnliche Probleme treten auch bei Ramadan oder sogar Ostern auf.

Man hat diese sehr schöne Annahme, die auseinanderfallen kann, wenn eine Anforderung auftritt, die nicht in das eigene Rahmenwerk passt. Und das kann viele Formen annehmen. Das Problem ist, dass ein Softwareanbieter eigentlich nicht die Zeit hat, seinen gesamten Software-Stack neu zu schreiben, damit diese neuen Funktionen sich völlig nahtlos in die eigene Architektur integrieren. Letztlich ist es also etwas hackhaft.

Kieran Chandler: Man verhandelt mit einem wichtigen Kunden, also hat man keine Jahre Zeit, um den Deal abzuschließen. Und ebenso wenig hat man Jahre, um die Zukunft zu liefern. Daher müssen bei jeder Verhandlung Dinge in einer relativen Notfallsituation erledigt werden, einfach aufgrund der Tatsache, dass es sich tatsächlich um eine größere als gewöhnlich Verhandlung handelt, um einen Verkauf abzuschließen. Die Dinge werden fast absichtlich übereilt umgesetzt. Aber wann wird etwas zu einer Narbe und wann zu einer guten Funktion? Denn all diese Software muss sich weiterentwickeln, sie muss sich ändern, sie muss für ihre Kunden funktionieren. Was unterscheidet also das eine vom anderen? Wie erkennt man, dass etwas, das man entwickelt, nicht zu einer Narbe wird?

Joannes Vermorel: Die Frage ist, wie viel das in Bezug auf Wartung kosten wird. Jede einzelne Codezeile, die in Ihrer großen Unternehmenssoftware existiert, muss irgendwann gewartet werden. Eine Sache, die selbst Softwareprofis nicht immer realisieren, ist, dass Software wie ein komplexes Getriebe ist, in dem jedes einzelne Teil in irgendeiner Weise mit allen anderen Teilen interagieren muss. Man hat ein quadratisches Komplexitätsproblem.

Was bedeutet das? Es heißt, wenn ich zehn Teile habe, dann gibt es im Grunde etwa 100 potenzielle Wechselwirkungen, also 10 x 10. Wenn ich tausend Teile habe und diese alle interagieren, dann habe ich 1.000 mal 1.000 Wechselwirkungen. Jede potenzielle Interaktion ist eine Einladung zu allerlei Problemen: Sicherheitslücken, Bugs, Abstürze, fehlerhafte Ergebnisse oder einfach massive Verlangsamungen der Software.

Wenn man weitere Teile hinzufügt, steigt die Anzahl der potenziellen Wechselwirkungen zwischen den Teilen der Software, und diese nimmt viel schneller zu als die Anzahl der Teile. Und wenn ich von Teilen spreche, können dies Funktionen, Möglichkeiten, Bildschirme, Datenoptionen oder Einträge sein.

Wenn Sie in Ihrer Softwarearchitektur sehr sorgfältig vorgehen, können Sie die Anzahl der Interaktionen zwischen Ihren Funktionen bewahren, um sie unter Kontrolle zu halten. Wenn Sie die Anzahl der Funktionen in Ihrer Software verdoppeln, möchten Sie nicht, dass sich die Anzahl der Interaktionen vervierfacht, denn das bedeutet, dass sich bei einer Verdopplung der Funktionen tatsächlich auch der Wartungsaufwand vervierfacht.

Doch das ist sehr schwierig. Wenn man unter Zeitdruck steht, vervielfacht man bei einer Verdopplung der Funktionen tatsächlich den erforderlichen Wartungsaufwand um das Vierfache oder sogar noch mehr. Mit der Zeit schießen die Wartungskosten in die Höhe, und Ihre Fähigkeit, neue Dinge auszurollen, wird immer geringer. Jedes Mal, wenn Sie eine neue Funktion einführen, löst das eine Welle von Inkompatibilitäten und bizarren, unbeabsichtigten Interaktionen zwischen den verschiedenen Teilen aus, weil sie nicht vollständig durchdacht wurde. Der Aufwand wächst mit der Zeit.

Kieran Chandler: Also, betrachten wir die Dinge aus der Perspektive dieses Softwareunternehmens. Wie können sie diese neuen Funktionen einführen? Wie können sie diese Funktionen implementieren, um ihre Kunden zufrieden zu stellen, ohne diese zusätzliche Komplexitätsebene zu schaffen? Was können sie tun?

Joannes Vermorel: Ich denke, die Lehre kommt aus der Welt der B2C-Software. Google führt keine neuen Funktionen für Google Search ein, und Netflix rollt keine neuen Funktionen für Netflix aus, nur weil sie einen neuen Kunden gewinnen. Sie akquirieren keine neuen Kunden und beginnen dann mit ihnen zu diskutieren und zu sagen: “Oh, wenn wir diese Funktionen nicht haben, melden Sie sich nicht bei uns an, also müssen wir es jetzt umsetzen.”

So funktioniert es nicht. Sie denken darüber nach, was die Domäne ist, welches spezifische Problem sie zu lösen versuchen. Sie versuchen, eine sehr hohe Perspektive auf dieses Problem zu entwickeln und dann zu überlegen.

Kieran Chandler: Sie sprechen einen Ansatz an, der darauf abzielt, Lösungen für eine ganze Kategorie von Problemen zu generieren, anstatt für ein einzelnes Mikroproblem. Das erfordert eine Neuarchitektur der Software, um ein breites Spektrum ähnlicher Probleme zu adressieren. Und das passiert ständig. Im Umgang mit Kunden hören Sie sich deren Probleme an, nicht deren vorgeschlagene Lösungen. Im Vergleich dazu neigen Kunden in der B2B-Welt dazu, nicht nur ihr Problem, sondern auch gleich eine Lösung zu präsentieren. Diese Lösung passt möglicherweise in Ihren bestehenden Software-Stack oder in die Entwicklung dieses Problems, muss es aber nicht. Geht es also darum, eigentlich gar nicht wirklich zuzuhören?

Joannes Vermorel: Genau, es geht vielmehr darum, das Kernproblem wirklich zu verstehen, anstatt sich auf eine bestimmte Lösung zu fixieren. Große Unternehmen wie Google und Netflix sind hervorragende Beispiele dafür.

Kieran Chandler: Also sagen Sie, dass Unternehmen eigentlich nicht zuhören. Aber was ist mit diesen nervigen Pop-ups, die um Feedback bitten? Schaut tatsächlich jemand darauf?

Joannes Vermorel: Die Pop-ups, auf die Sie anspielen, sind in der Regel unerwünschte Funktionen. Aber man muss Unternehmen wie Google Anerkennung zollen. Diese Pop-ups, bei denen man den Bedingungen zustimmen muss, waren nicht ihre Wahl. Sie wurden aufgrund regulatorischer Auflagen implementiert. Auch wenn es wie eine bizarre Funktion erscheint, war es nicht ihre Idee. Und wenn man sich anschaut, wer das Web gewonnen hat, waren es nicht die Unternehmen mit super nervigen Anzeigen. Es waren solche wie Google, die saubere, unaufdringliche Anzeigen hatten. Sie dachten an ihre Kunden, anstatt ihr Produkt mit etwas so Nervigem abzuwerten. Sie nehmen sich die Zeit, ihre Funktionen gründlich zu durchdenken.

Kieran Chandler: In B2B-Softwareunternehmen, insbesondere im supply chain, gibt es eine große Vielfalt. Es kann Hunderte von Szenarien geben, und oft wird in letzter Minute über viele Funktionen verhandelt, die sich fast immer als schlechte Ideen herausstellen – sechs Monate später. Würden Sie also zustimmen, dass die Software-Frankensteinisierung etwas Schlechtes ist? Und wenn ja, was haben Sie bei Lokad anders gemacht, um dieses Problem zu vermeiden?

Joannes Vermorel: Absolut, die Software-Frankensteinisierung ist ein Problem. In den ersten Jahren bei Lokad standen wir vor genau diesem Problem. Es war ein harter Kompromiss. Wenn man es richtig machen will, kann es ein oder zwei Jahre dauern, was zu langsam ist. Wenn man es nicht richtig macht, kann man in wenigen Wochen oder Monaten fertig werden, aber dann bleibt einer großen Narbe, einem hässlichen Hack, der als technischem Schuldenberg zurückbleibt. In den ersten Jahren bei Lokad hatten wir zwar keine Lösung, aber wir wurden uns des Problems immer mehr bewusst. Selbst als Startup häuften sich die technologischen Schulden, was eine besorgniserregende Situation darstellte. In diesem Moment wurde mir klar, dass der Trend ungünstig war. Mit Blick auf ein paar Jahrzehnte konnte ich erkennen, wie Konkurrenten mit ihrer aufgeblähten Software für supply chain-Optimierung immer mehr Funktionen hinzufügten, ohne jegliche Konsistenz.

Kieran Chandler: Es scheint, als würden Softwareunternehmen ständig neue Funktionen hinzufügen, und im Endeffekt kann daraus ein verwirrendes, aufgeblähtes Produkt entstehen. Können Sie über Ihren Ansatz bei Lokad sprechen, wie Sie mit diesem Problem umgehen?

Joannes Vermorel: Absolut. Die Art und Weise, wie Software aufgebläht wird, besteht darin, dass man immer eine schlechte Funktion nach der anderen hinzufügt. Wenn man diesen Weg 20 Jahre lang fortsetzt, landet man mit einem monströsen Produkt. Es liegt nicht daran, dass die Entwickler inkompetent oder töricht sind – sie arbeiten einfach schrittweise ordentlich, um einen Kunden nach dem anderen zu gewinnen. Dennoch führt dieser Ansatz dazu, dass die Software kundenweise überladen wird, und das Endergebnis ist typischerweise sehr, sehr schlecht.

Also haben wir uns bei Lokad entschieden, einen völlig anderen Ansatz zu verfolgen, was zur Entstehung von Envision führte, unserer domänenspezifischen Programmiersprache. Mit Envision haben wir die Probleme effektiv aufgeteilt. Wir haben die Infrastruktur, die Dateninfrastruktur und die machine learning-Infrastruktur getrennt. Dies sind langlebige Produkte, die wir warten und aktualisieren möchten, und jedes Mal, wenn wir uns entscheiden, sie zu ändern und zu verbessern, ist es ein mehrjähriger Aufwand.

Dann erstellen wir separat für jeden einzelnen Kunden eine völlig maßgeschneiderte Implementierung, die in Scripts in Envision geschrieben ist. Da Envision speziell für die supply chain-Optimierung entwickelt wurde, konnten wir etwas völlig Individuelles für jeden einzelnen Kunden programmieren – mit hoher Produktivität und gleichzeitig vollständig maßgeschneidert.

Also beginnen wir mit einem leeren Blatt, passen es vollständig an, und dann müssen wir uns nicht mit der Situation auseinandersetzen, dass der Kunde von uns etwas verlangt, das wir nicht unterstützen. Dank der programmatischen Fähigkeiten von Envision, falls wir etwas Besonderes für einen Kunden tun müssen, ist im schlimmsten Fall das von uns geschriebene Script nicht so kompakt wie üblich. Dennoch können wir von einer Infrastruktur profitieren, die darauf ausgelegt ist, bestimmte Arten von Problemen einfach zu lösen.

Wenn Sie fortschrittliche, programmatische, domänenspezifische Fähigkeiten in Ihre Plattform integrieren, müssen Sie nicht mehr übereilt Verhandlungen führen, die Ihrem Produkt eine Narbe zufügen. Sie können die Anpassung in Ihrer programmatischen Umgebung vornehmen, die für jeden einzelnen Kunden maßgeschneidert ist, und dann Upgrades für Ihre Plattform nach Ihrem eigenen Zeitplan ausrollen – ein Zeitplan, der höchstwahrscheinlich nicht mit dem Zeitplan Ihrer Kunden übereinstimmt.

Kieran Chandler: Sie haben dieses Problem schon sehr früh erkannt. Welchen Rat würden Sie anderen Softwareunternehmen geben, die mit solch aufgeblähter Software zu kämpfen haben? Können sie etwas dagegen tun? Sollten sie anfangen, einige dieser Funktionen zu entfernen, um die Dinge zu vereinfachen?

Joannes Vermorel: Die Situation hängt von mehreren Faktoren ab. Wenn Sie ein großes Unternehmen sind, das die Software besitzt – wie ein WMS, ERP, MRP etc. – haben Sie möglicherweise nicht einmal Zugriff auf die Software selbst, da es sich schlicht um ein Anbieterprodukt handeln kann. Wenn Sie keinen Zugriff auf das Produkt haben, sind Sie mit der Komplexität der erworbenen Software gestraft.

Wenn Sie jedoch Zugriff auf die Software haben und diese vereinfachen möchten, dann sollten Sie zunächst einmal all die Dinge in den Blick nehmen, die Sie nicht nutzen, und diese konsequent entfernen. Viele Menschen fürchten, Teile einer bestehenden Software zu entfernen, weil sie befürchten, bestimmte Fähigkeiten zu verlieren. Es stimmt zwar, dass das Entfernen von Funktionen auch bedeutet, dass diese Funktionen verloren gehen. Wenn Sie jedoch etwas entfernen, das fast nie genutzt wird, können Sie auch ganze Problemklassen beseitigen, die allein durch die bloße Existenz dieser winzigen Funktion entstanden sind.

Bei Lokad sehen wir oft ERP-Implementierungen mit buchstäblich Tausenden von Tabellen. Man kann sich ein ERP vorstellen, das sagen wir fünftausend Tabellen umfasst. Jede Tabelle kann zwischen 10 und 200 Feldern haben, was zu enormer Komplexität führt. Sogar die Sicherung des ERPs kann unglaublich kompliziert sein.

Kieran Chandler: Weil es so viele Tabellen gibt, braucht man eine Tabelle, um die Liste der Tabellen und Ähnliches zu speichern. Das ist genau die Art von Situation, in der, wenn Sie zahlreiche Tabellen identifizieren können, die nicht mehr verwendet werden – oder Bildschirme, die nicht mehr genutzt werden –, durch deren Entfernung alles deutlich vereinfacht wird.

Joannes Vermorel: Genau, zum Beispiel wenn Sie von einer Version Ihrer Datenbank auf eine andere upgraden müssen, kann eines der Probleme darin bestehen, dass Sie Logikbausteine aktualisieren müssen, die überhaupt niemand mehr nutzt. Jede einzelne Codezeile – sei es in Java, C Sharp, SQL oder was auch immer – muss so lange gewartet werden, wie sie existiert. Entfernen Sie diese, dann entfällt bei der nächsten Integration oder Migration die Frage, wie wir dieses Element auf die nächste Version des Systems oder in ein völlig neues System überführen.

Und das ist etwas, worüber supply chain-Führungskräfte nachdenken müssen. Beim Kauf von Software sollten sie sich wirklich an das Prinzip der Sparsamkeit halten – wenn Sie etwas nicht wirklich benötigen, ist es besser, diesen Teil des Systems nicht zu haben. Es wird nur zur Belastung. Es ist entscheidend, stets auf die technologische Masse der Lösung zu achten, die Sie erwerben und betreiben.

Diese technologische Masse kommt nicht kostenlos. Wenn Sie mehr Bildschirme haben, benötigen Sie mehr Personal, um diese zu schulen. Entfernen Sie ein paar Bildschirme, bedeutet das weniger Schulungsaufwand, weniger gemeldete Fehler, weniger Auseinandersetzungen mit der IT und so weiter. Es geht darum, die Komplexität der IT zu managen, doch das Schwierige ist, dass die IT in der Regel keinen Durchblick hat, weil ihr der Zugang zum geschäftlichen Mehrwert fehlt. Sie können nicht zwischen wirklich notwendigen Funktionen und Funktionen, die absolut nicht notwendig sind, unterscheiden. Sie können Tabellen, Felder, Bildschirme oder Funktionen nicht in Euro oder Dollar umrechnen. Das ist etwas, das nur Leute im supply chain oder im Marketing – je nachdem, welches System man betrachtet – leisten können. Deshalb braucht die IT die Unterstützung dieser Entscheidungsträger, um die Priorisierung und Veränderung bei der Vereinfachung des Systems voranzutreiben.

Kieran Chandler: Und um es zusammenzufassen: Sie erwähnten, dass wenn ich als supply chain-Führungskraft in neue Software für mein Unternehmen investieren möchte, es so klingt, als sollte ich nicht allzu viel Anpassung verlangen, weil das Probleme verursacht. Also, wonach sollte ich suchen?

Joannes Vermorel: Ja, die Forderung nach Anpassungen oder speziellen Funktionen ist wie ein Rezept zur Erzeugung von Problemen. Wenn Ihr Softwareanbieter nicht bereits genug eigene Probleme hätte, schaffen Sie gerade neue, die die Situation nur verschlimmern. Deshalb sollten Sie das wirklich nicht tun. Wenn Sie überhaupt nach Anpassungen fragen können – nur als Test –, denn wenn der Anbieter bereitwillig mit Ihnen über Anpassungen diskutiert, bedeutet das, dass der Anbieter keine Integrität besitzt. Das heißt, der Anbieter macht das bei jedem einzelnen anderen Kunden, was wiederum bedeutet, dass selbst wenn das Produkt heute gut ist, es in fünf Jahren ein Albtraum sein wird.

Zunächst einmal, wenn Sie nach Anpassungen fragen, ist es gut, das zu tun – aber Sie sollten wirklich erwarten, dass diese Anfrage abgelehnt wird. Wenn nicht, ist das ein Problem.

Kieran Chandler: Eine Sache, nach der die Leute fragen sollten, sind spezielle Funktionen, richtig? Ich meine, wenn es um eine einzige Forderung geht, könnte das der Zugang zum CTO oder Produktmanager auf der Anbieterseite sein. Vielleicht als Teil des Vertrags einbezogen? So etwas wie, dass man einmal im Monat zwei Stunden ein Treffen mit dieser Person abhalten darf. Warum?

Joannes Vermorel: Wenn Sie aushandeln, direkten Zugang zu denjenigen zu erhalten, die die Roadmap des Anbieters erarbeiten, können Sie einfach Ihre Änderungen präsentieren. Sie müssen ihnen Ihre Lösung nicht aufzwingen – präsentieren Sie einfach Ihr Problem. Denn als Ingenieure, was tun sie, wenn ihnen ein Problem vorgelegt wird? Sie machen sich sofort daran, eine Lösung zu entwickeln. Wenn Sie regelmäßige Treffen haben, in denen Sie Ihre Probleme präsentieren, müssen Sie im Vertrag nicht explizit um bestimmte Funktionen verhandeln. In ein paar Jahren werden dann Funktionen im Produkt erscheinen, die genau zu dem Problem passen, das Sie offengelegt haben.

Kieran Chandler: Können Sie das etwas näher erläutern?

Joannes Vermorel: Wenn Sie es durchrechnen, bedenken Sie den CTO eines Softwareunternehmens. Wie viele Meetings kann diese Person in einem Monat mit Kunden haben? Sagen wir, maximal 20. Wenn Sie ein Meeting pro Monat haben, erhalten Sie im Wesentlichen etwa fünf Prozent der mentalen Kapazität des CTO, der die technologische Entwicklung des Anbieters, mit dem Sie zusammenarbeiten, vorantreibt. Das bedeutet, dass Ihren Problemen eine beträchtliche Aufmerksamkeit geschenkt wird.

Kieran Chandler: Also, was ist Ihr Vorschlag?

Joannes Vermorel: Mein Vorschlag, wenn Sie klug vorgehen wollen, ist, sich den Personen anzunähern, die die Kontrolle über die Roadmap haben. Das ist schlauer, als überstürzt um fehlerhafte Funktionen zu verhandeln, die Sie in sechs Monaten wahrscheinlich wieder verwerfen, weil Ihre Lösung nicht gelungen ist oder sich Ihr Problem geändert hat. Ein weiterer Rat wäre, Software zu vermeiden, die zu viel macht. Sie sollten an ein Stück Software denken, das eine einzige Sache tut und diese sehr gut, anstatt an eine Software mit umfangreichen Fähigkeiten, die letztlich alles schlecht erledigt.

Kieran Chandler: Können Sie diesen Punkt noch weiter ausführen?

Joannes Vermorel: Es ist einfacher, ein eng fokussiertes Stück Software zu verbessern, als ein gigantisches Framework, das alles macht, zu optimieren. Wann immer Sie etwas anpassen, denken Sie an die quadratische Anzahl der Interaktionen. Wenn Sie tausend Funktionen haben und eine hinzufügen, müssen Sie an alle Interaktionen mit den bereits vorhandenen tausend Funktionen denken. Fügen Sie also eine Funktion hinzu, und Sie haben tausend Interaktionen zu betrachten. Bei nur zehn Funktionen und der Hinzufügung einer elften, sind es dagegen nur zehn Interaktionen, die überprüft werden müssen. Konzentrieren Sie sich also wieder auf etwas Schlankes, das sich präzise auf das spezifische Problem fokussiert, das Sie lösen wollen.

Kieran Chandler: Super! Ich fürchte, wir müssen es für heute hierbei belassen, aber ich vermute, da draußen gibt es ein paar CEOs, die dafür nicht allzu dankbar sein werden und wahrscheinlich jetzt noch ein paar weitere Telefonate führen. Nun, das war alles für diese Woche. Nächste Woche sind wir mit einer weiteren Episode zurück. Bis dahin, passt auf euch auf.

Joannes Vermorel: Danke.