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’ an der Software und ihre Auswirkungen.
00:05:33 Wartungskosten der Software-Frankensteinisierung.
00:08:00 Herausforderungen und Kosten neuer Softwarefunktionen.
00:08:57 Funktionen ohne Komplexität: Erkenntnisse aus dem B2C-Bereich.
00:10:36 Probleme mit dem B2B-Ansatz für Softwarelösungen.
00:13:18 Erfahrungen von Lokad: Richtig vs. schnell & technischer Schuldenberg.
00:15:14 Envision: Lokads Lösung für Komplexität.
00:16:30 Domänenspezifisches Skripting: Vermeidung von Einschränkungen und Konflikten.
00:17:43 Umgang mit aufgeblähter Software in Lieferketten.
00:18:01 Strategien zur Vereinfachung komplexer Software.
00:20:54 Verwaltung der ’technologischen Masse’ in Softwaresystemen.
00:22:00 IT-, Lieferketten- und Marketing-Synergie bei Systemänderungen.
00:22:43 Probleme mit übermäßiger Softwareanpassung.
00:23:48 Überprüfung der Integrität von Softwareanbietern durch Anpassung.
00:24:00 Einflussnahme auf die Produktentwicklungsstrategie.
00:26:08 Auswahl schlanker, fokussierter Software zur Vermeidung von Anpassungen.
Zusammenfassung
Auf Lokad TV stellt Joannes Vermorel das Konzept der Software-Frankensteinisierung vor, das sich auf die Art und Weise bezieht, wie B2B-Software durch willkürliche Modifikationen entwickelt wird, die nicht mit ihrem ursprünglichen Design übereinstimmen. Er vergleicht diese Veränderungen mit ‘Narben’, die zur Schaffung eines zusammengesetzten, weiterentwickelten Softwaresystems beitragen. ERPs werden als Beispiel präsentiert und betonen das Dilemma zwischen der Aufrechterhaltung der Softwarearchitektur und der Erfüllung neuer Anforderungen. Vermorel warnt vor voreiligen Entscheidungen, die seiner Meinung nach oft zu Softwarenarben und steigenden Wartungskosten führen. Obwohl er die unvermeidliche Komplexität im Softwaremanagement anerkennt, betont Vermorel die Bedeutung des Lernens von B2C-Modellen, um Funktionsinteraktionen zu kontrollieren. Lokads Antwort auf dieses Problem ist “Envision”, eine domänenspezifische Programmiersprache, die infrastrukturelle und domänenspezifische Probleme trennt.
Ausführliche Zusammenfassung
In der neuesten Folge von Lokad TV dreht sich das Gespräch um das Konzept der Software-Frankensteinisierung, ein Begriff, der von Joannes Vermorel, dem Gründer von Lokad, geprägt wurde. Er verwendet diesen Begriff, um die Transformation von B2B-Software im Laufe der Zeit darzustellen, insbesondere langjährige und Supply-Chain-Software, da sie sich durch kontinuierliche Verhandlungen und große Deals zwischen Softwareanbietern und ihren Kunden entwickeln.
Vermorel erklärt, dass die Software-Frankensteinisierung stattfindet, wenn Anpassungen an der Software als Reaktion auf Kundenanforderungen vorgenommen werden. Diese Änderungen stehen oft im Widerspruch zur ursprünglichen Architektur, Philosophie und Gestaltung der Software. Als Folge davon sammelt die Software im Laufe der Zeit diese Veränderungen oder “Narben” an, wodurch sie zu dem wird, was Vermorel als “Frankenstein-Monster” beschreibt - ein zusammengesetztes und eigenartig weiterentwickeltes Softwaresystem.
Er weist außerdem darauf hin, dass dieses Phänomen besonders bei Supply-Chain-Software ausgeprägt ist, aber auch bei vielen anderen Arten von B2B-Software häufig vorkommt. Dennoch stellt er klar, dass der Begriff “Narbe” nicht grundsätzlich negativ verstanden werden sollte. Diese Modifikationen können die Software verbessern, indem sie neue Funktionen hinzufügen und so ihre Funktionalität verbessern.
Vermorel gibt ein Beispiel für Enterprise Resource Planning (ERP)-Software, die davon ausgeht, dass Saisonalität mithilfe von festen 52-Wochen-Profilen erfasst werden kann. Dieses Design funktioniert gut, bis eine Nachfrage entsteht, die nicht in dieses Rahmenwerk passt, wie zum Beispiel die Modellierung des chinesischen Neujahrs, des Ramadan oder des Osterfestes, die unterschiedlichen Kalendern folgen und sich jährlich ändern.
In solchen Fällen steht der Softwareanbieter vor einem Abwägungsproblem. Sie können auf die neue Nachfrage eingehen, indem sie eine “hackische” Lösung integrieren, die nicht nahtlos in die Architektur der Software passt, aber die gewünschte Funktion bietet. Diese Vorgehensweise führt jedoch oft zu weiteren “Narben”, die zur Frankensteinisierung der Software beitragen.
Vermorel betont das schnelle Tempo der Verhandlungen mit Schlüsselkunden im Softwaregeschäft und warnt 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 Wartungskosten der Software erhöhen.
Bei der Erklärung der Feinheiten der Softwarearchitektur stellt Vermorel fest, dass jede Codezeile oder Funktion gewartet werden muss. Mit zunehmender Anzahl von Funktionen werden die Verbindungen komplexer, was zu einem “quadratischen Komplexitätsproblem” führt. Im Wesentlichen nehmen potenzielle Interaktionen exponentiell zu, wenn die Anzahl der Teile zunimmt, was zu verschiedenen potenziellen Problemen wie Fehlern, Abstürzen und Sicherheitsbedrohungen führt.
Vermorel betont die Bedeutung einer sorgfältigen Softwarearchitektur, um die Anzahl der Interaktionen zwischen Funktionen zu kontrollieren. Er stellt fest, dass das Ziel darin bestehen sollte, den Wartungsaufwand nur zu verdoppeln, wenn die Anzahl der Funktionen verdoppelt wird, anstatt dass er sich vervierfacht oder mehr erhöht, wie es oft geschieht, wenn die Entwicklung überstürzt wird.
Auf die Frage, wie Softwareunternehmen neue Funktionen einführen können, ohne übermäßige Komplexität hinzuzufügen, schlägt Vermorel vor, von B2C-Softwareunternehmen wie Google und Netflix zu lernen. Sie nehmen sich Zeit, um die spezifischen Probleme zu verstehen, die sie lösen möchten, und entwerfen Lösungen, die eine breite Kategorie ähnlicher Probleme ansprechen. Er stellt diesen Ansatz dem B2B-Bereich gegenüber, in dem Kunden oft nicht nur Probleme, sondern auch ihre eigenen vorgeschlagenen Lösungen mitbringen.
In Bezug auf die Art und Weise, wie Lokad mit diesen Problemen umgeht, enthüllt Vermorel ihre anfänglichen Schwierigkeiten, das richtige Gleichgewicht zwischen der korrekten Durchführung und der schnellen Anpassung an Kundenanfragen zu finden. Sie bemerkten in den ersten Jahren eine zunehmende technologische Verschuldung, die Vermorel als nachteilig anerkennt. Sie erkannten, dass das Hinzufügen von Funktionen, um individuelle Kunden zufriedenzustellen, zwar kurzfristig vorteilhaft erscheinen mag, langfristig jedoch zu einem komplexen, inkonsistenten und schwer zu verwaltenden 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 die Hinzufügung und Wartung neuer Funktionen effektiver verwalten kann, ohne übermäßige Komplexität hinzuzufügen.
Vermorel erläutert weiter, wie Softwareprodukte, insbesondere in der Supply-Chain-Branche, häufig mit einem Aufblähungsproblem aufgrund umfangreicher Anpassungen für jeden Kunden konfrontiert sind. Während Anpassungen maßgeschneiderte Lösungen liefern sollen, führen sie oft zu einem komplexen und schwer zu handhabenden System, das erheblichen Aufwand für Wartung und Upgrades erfordert. Um dies zu vermeiden, zeigt Vermorel auf, wie Lokad ein domänenspezifisches Skript namens Envision verwendet, um hochgradig angepasste, aber dennoch handhabbare Lösungen für ihre Kunden zu erstellen.
Auf die Frage, was Softwareunternehmen tun können, um Bloatware zu verhindern, erwidert Vermorel, dass das Szenario davon abhängt, ob ein Unternehmen Zugriff auf seine Software hat. Wenn nicht, muss das Unternehmen mit der Komplexität der erworbenen Software umgehen. Wenn jedoch Zugriff möglich ist, kann die Software vereinfacht werden, indem ungenutzte Elemente identifiziert und entfernt werden, was die Komplexität erheblich reduziert.
Den Fokus auf die Verantwortlichkeiten von IT- und Supply-Chain-Executives lenkend, stellt Vermorel fest, dass IT-Personal in der Regel über das technische Know-how verfügt, jedoch oft das Geschäftswert bestimmter Funktionen nicht versteht. Dies führt zu einer Kluft zwischen notwendigen und unnötigen Funktionen. Daher müssen Geschäftsentscheidungsträger eng mit der IT zusammenarbeiten, um Priorisierung und Systemvereinfachung voranzutreiben.
Vermorel gibt Supply-Chain-Executives Ratschläge, die in neue Software investieren möchten. Er warnt davor, übermäßige Anpassungen zu verlangen, da dies weitere Probleme mit sich bringen kann. Stattdessen sollten Führungskräfte regelmäßigen Kontakt zu den Produktmanagern oder CTOs des Anbieters halten, um ihre Bedürfnisse direkt zu kommunizieren. Anstatt spezifische Funktionen in einen Vertrag zu zwingen, sollte das Ziel darin bestehen, Probleme denen vorzulegen, die in der Lage sind, Lösungen zu entwickeln.
Schließlich rät Vermorel Unternehmen, Software zu wählen, die sich auf eine Sache spezialisiert, anstatt umfassende Lösungen zu wählen. Dieser fokussierte Ansatz erleichtert Verbesserungen und reduziert die Komplexität, die durch eine Vielzahl von miteinander verbundenen Funktionen verursacht wird. Indem sie eng mit denen zusammenarbeiten, die die Roadmap kontrollieren, und sich für scharf fokussierte Software entscheiden, können Unternehmen Komplexität besser bewältigen und die Produktivität steigern.
Vollständiges Transkript
Kieran Chandler: Heute werden wir uns mit dem Thema Software-Frankensteinisierung befassen. Joannes, das ist ein Thema, das ziemlich schwer auszusprechen ist, also überlasse ich das wahrscheinlich dir. Ich nehme an, wir sprechen heute nicht über ein großes grünes Monster. Wovon genau sprechen wir?
Joannes Vermorel: Wir sprechen über einen Prozess, der die Entwicklung von Software vorantreibt, speziell B2B-Software und noch spezieller Supply-Chain-Software. Es gilt hauptsächlich für langjährige B2B-Software. Dieser Prozess, den ich als “Frankensteinisierung” bezeichne, entwickelt die Software im Laufe der Jahre mit einem fortlaufenden Strom großer Deals, die zwischen den Softwareanbietern und ihren Kunden ausgehandelt werden. Das Interessante, woher der Teil “Frankensteinisierung” kommt, ist, dass jeder große Deal, der zwischen dem Anbieter und einem seiner großen Kunden ausgehandelt wird, wahrscheinlich eine Narbe in der Software hinterlässt.
Es handelt sich um einen schrittweisen Prozess, bei dem ein Anbieter mit einem großen Unternehmen verhandelt. Das große Unternehmen hat Forderungen, und um diesen Forderungen nachzukommen, werden Anpassungen an der Software vorgenommen, die nicht zur Gesamtarchitektur, Philosophie oder zum ursprünglichen Design passen. Die Funktion wird hinzugefügt, aber auf eine etwas hackische Weise. Das ist eine Narbe. Das Problem ist, wenn Sie diesen Prozess über Jahre hinweg immer wiederholen, dann haben Sie am Ende in Bezug auf die Software sozusagen ein Frankenstein-Monster. Es ist ein Ungeheuer, das aus vielen Narben besteht und ziemlich abscheulich und super zusammengesetzt aussieht. Es entwickelt sich auf seltsame Weise, und so entstehen diese Frankenstein-Softwaremonster. Das passiert in den meisten Datenbanken, aber in der Supply-Chain-Software ist es wie auf Steroiden.
Kieran Chandler: Sprechen wir über diese Narben, wie Sie sie nennen. Wie sehen sie aus? Ich meine, sie verbessern die Software, oder? Sie fügen zusätzliche Funktionen hinzu. Ist das so schlimm?
Joannes Vermorel: Ja, offensichtlich ist das der Kompromiss. Sie möchten Ihre Software verbessern, aber ein Softwarestück ist ein sehr kompliziertes Objekt. Es ist nicht wie ein Gebäude, in dem Sie einfach ein Stockwerk hinzufügen oder es schön erweitern können. Software kommt mit vielen unverletzlichen Designannahmen, die sehr früh getroffen wurden und der Software eine gewisse Integrität - architektonische Integrität - verleihen.
Nehmen wir viele ERP-Systeme als Beispiel, die um die Idee der Erfassung von Saisonalität mit Profilen gebaut wurden, die genau 52 Wochen repräsentieren, was einem Jahr entspricht. Sie haben also buchstäblich eine Tabelle mit 52 Spalten, eine Spalte pro Woche, und Sie haben all diese Saisonalitätsprofile, die Sie auf jedes Produkt anwenden können, das Sie herstellen oder verkaufen. Aber was ist, wenn Sie etwas wie das chinesische Neujahr modellieren möchten? Es passt nicht in dieses 52-Wochen-Raster, weil es sich gemäß dem traditionellen chinesischen Kalender von einem Jahr zum nächsten verschiebt, nicht dem gregorianischen Kalender. Sie werden ähnliche Probleme mit dem Ramadan oder sogar Ostern haben.
Sie haben diese sehr schöne Annahme, die auseinanderfallen kann, wenn Sie mit einer Nachfrage konfrontiert werden, die nicht in Ihr Framework passt. Und das kann viele Formen annehmen. Das Problem ist, dass Sie als Softwareanbieter tatsächlich nicht die Zeit haben, Ihre gesamte Software-Stack neu zu schreiben, damit diese neuen Funktionen auf natürliche Weise in Ihre Architektur integriert werden. Am Ende ist es ein bisschen hackisch.
Kieran Chandler: Sie verhandeln mit einem wichtigen Kunden, also haben Sie nicht Jahre, um den Deal abzuschließen. Und dann haben Sie auch nicht Jahre, um die Zukunft zu liefern. Also müssen die Dinge jedes Mal in einer relativen Notlage erledigt werden, einfach aufgrund der Tatsache, dass es sich tatsächlich um eine größere als übliche Verhandlung handelt, um einen Verkauf abzuschließen. Die Dinge werden fast schon von Design aus gehetzt. Aber wann wird etwas zu einer Narbe und wann wird etwas zu einer guten Funktion? Denn all diese Software muss sich weiterentwickeln, sie muss sich ändern, sie muss für ihre Kunden funktionieren. Was unterscheidet die beiden? Wie wissen Sie, dass etwas, an dem Sie arbeiten, nicht zu einer Narbe wird?
Joannes Vermorel: Die Frage ist, wie viel wird es in Bezug auf Wartung kosten? Jede einzelne Codezeile, die in Ihrer großen Unternehmenssoftware existiert, ist etwas, das Sie warten müssen. Eine Sache, die Menschen, selbst Softwareprofis, nicht immer erkennen, ist, dass die Software wie eine komplexe Maschine ist, bei der jedes einzelne Teil irgendwie mit allen anderen Teilen interagieren muss. Sie haben ein quadratisches Komplexitätsproblem.
Was bedeutet das? Das bedeutet, dass ich bei zehn Teilen ungefähr 100 potenzielle Interaktionen habe, wissen Sie, 10 x 10. Wenn ich tausend Teile habe und sie alle interagieren, dann habe ich 1.000 mal 1.000 Interaktionen. Jede potenzielle Interaktion ist eine Quelle für allerlei Probleme: Sicherheitsprobleme, Fehler, Abstürze, falsche Ergebnisse oder einfach massive Verlangsamungen in der Software.
Wenn Sie mehr Teile hinzufügen, erhöhen Sie die Anzahl der potenziellen Interaktionen zwischen den Teilen in Ihrer Software, und sie nimmt viel schneller zu als die Anzahl der Teile. Und wenn ich von Teilen spreche, können Sie an Funktionen, Fähigkeiten, Bildschirme, Datenoptionen oder Einträge denken.
Wenn Sie sehr sorgfältig mit Ihrer Softwarearchitektur umgehen, können Sie die Anzahl der Interaktionen zwischen Ihren Funktionen kontrollieren. Wenn Sie die Anzahl der Funktionen in Ihrer Software verdoppeln, möchten Sie nicht die Anzahl der Interaktionen vervierfachen, denn das bedeutet, dass Sie, wenn Sie die Anzahl der Funktionen verdoppeln, tatsächlich die Menge an Wartung vervierfachen müssen.
Aber es ist sehr schwierig. Wenn Sie in Eile sind, wenn Sie die Anzahl der Funktionen verdoppeln, multiplizieren Sie tatsächlich den Aufwand, den Sie in die Wartung investieren müssen, um das Vierfache oder sogar mehr. Im Laufe der Zeit steigen die Wartungskosten in die Höhe, Ihre Fähigkeit, neue Dinge einzuführen, nimmt immer weiter ab. Immer wenn Sie eine neue Funktion einführen, löst sie eine ganze Welle von Inkompatibilitäten und seltsamen unbeabsichtigten Interaktionen zwischen verschiedenen Teilen aus, weil sie nicht vollständig durchdacht wurde. Der Schmerz nimmt im Laufe der Zeit zu.
Kieran Chandler: Okay, lassen Sie uns das aus der Perspektive des Softwareunternehmens betrachten. Wie können sie diese neuen Funktionen einführen? Wie können sie diese Funktionen implementieren, um ihre Kunden zufriedenzustellen, ohne diese zusätzliche Komplexität einzuführen? 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 die Google-Suche ein, und Netflix führt keine neuen Funktionen für Netflix ein, nur weil sie einen neuen Kunden gewinnen. Sie nehmen keine neuen Kunden an und beginnen mit ihnen zu diskutieren und zu sagen: “Oh, wenn wir diese Funktionen nicht haben, werden Sie sich nicht bei uns anmelden, also müssen wir es jetzt tun.”
Sie arbeiten nicht so. Sie denken darüber nach, was das Thema ist, welches spezifische Problem sie lösen wollen. Sie versuchen, einen sehr hohen Blickwinkel auf dieses Problem zu haben und dann nachzudenken.
Kieran Chandler: Sie diskutieren einen Ansatz, der darauf abzielt, Lösungen für eine ganze Kategorie von Problemen zu generieren, anstatt nur ein einzelnes Mikroproblem. Dies erfordert eine Neugestaltung der Software, um eine breite Palette ähnlicher Probleme anzugehen. Und das passiert die ganze Zeit. Wenn Sie mit Kunden interagieren, hören Sie sich ihre Probleme an, nicht ihre vorgeschlagenen Lösungen. Im Vergleich dazu neigen Kunden in der B2B-Welt dazu, nicht nur ihr Problem, sondern auch eine Lösung vorzustellen. Diese Lösung passt möglicherweise nicht in Ihren vorhandenen Software-Stack oder in die Entwicklung dieses Problems. Geht es also darum, nicht wirklich zuzuhören?
Joannes Vermorel: Genau, es geht eher darum, das Kernproblem wirklich zu verstehen, anstatt sich auf eine bestimmte Lösung zu fixieren. Große Unternehmen wie Google und Netflix sind ausgezeichnete Beispiele dafür.
Kieran Chandler: Also sagen Sie, dass Unternehmen nicht wirklich zuhören. Aber was ist mit diesen nervigen Pop-ups, die nach Feedback fragen? Schaut sich das überhaupt jemand an?
Joannes Vermorel: Die von Ihnen erwähnten Pop-ups sind in der Regel unerwünschte Funktionen. Aber Unternehmen wie Google verdienen Anerkennung. Diese Pop-ups, bei denen Sie den Bedingungen zustimmen müssen, waren nicht ihre Wahl. Sie wurden gezwungen, sie aufgrund von regulatorischen Einschränkungen zu implementieren. Daher war es zwar eine seltsame Funktion, aber nicht ihre Entscheidung. Wenn Sie sich auch ansehen, wer das Web gewonnen hat, waren es nicht die Unternehmen mit super nervigen Anzeigen. Es waren diejenigen wie Google, die saubere, unauffällige Anzeigen hatten. Sie dachten an ihre Kunden, anstatt ihr Produkt mit etwas so Ärgerlichem zu entwerten. Sie nehmen sich die Zeit, um ihre Funktionen durchzudenken.
Kieran Chandler: In B2B-Softwareunternehmen, insbesondere in der Lieferkette, gibt es eine Vielzahl von Szenarien, und oft verhandeln die Menschen in letzter Minute viele Funktionen aus, die sich fast immer als schlechte Ideen herausstellen. Würden Sie also zustimmen, dass die Frankensteinisierung von Software eine schlechte Sache ist? Und wenn ja, was haben Sie bei Lokad anders gemacht, um dieses Problem zu vermeiden?
Joannes Vermorel: Absolut, die Frankensteinisierung von Software ist ein Problem. In den ersten Jahren bei Lokad standen wir genau vor diesem Problem. Es war ein schwieriger Kompromiss. Wenn Sie es richtig machen wollen, kann es ein oder zwei Jahre dauern, was zu langsam ist. Wenn Sie es nicht richtig machen, können Sie es in ein paar Wochen oder Monaten erledigen, aber dann bleiben Sie mit einer großen Narbe, einem hässlichen Hack, zurück. Sie häufen technische Schulden an. In den ersten Jahren von Lokad hatten wir also keine Lösung, aber wir wurden uns des Problems immer mehr bewusst. Selbst als Startup wuchs die technische Schuldenlast, was eine besorgniserregende Situation war. An diesem Punkt wurde mir klar, dass der Trend ungünstig war. Wenn man ein paar Jahrzehnte vorausschaut, kann man sehen, wie Konkurrenten mit ihrer aufgeblähten Software für die Optimierung der Lieferkette immer mehr Funktionen hinzufügen, ohne jegliche Konsistenz.
Kieran Chandler: Es scheint, dass Softwareunternehmen immer neue Funktionen hinzufügen, und das Endergebnis kann ein verwirrendes, aufgeblähtes Produkt sein. Können Sie über Ihren Ansatz zu diesem Problem bei Lokad sprechen?
Joannes Vermorel: Absolut. Die Art und Weise, wie Software aufgebläht wird, besteht darin, eine schlechte Funktion nach der anderen hinzuzufügen. Wenn Sie diesen Weg 20 Jahre lang fortsetzen, haben Sie am Ende ein monströses Produkt. Es liegt nicht daran, dass die Entwickler inkompetent oder töricht sind, sie machen einfach einen anständigen Job inkrementell und versuchen, einen Kunden nach dem anderen zu gewinnen. Diese Vorgehensweise durchsucht jedoch die Software einen Kunden nach dem anderen, und das Endergebnis ist in der Regel sehr, sehr schlecht.
Also haben wir uns bei Lokad entschieden, einen völlig anderen Ansatz zu wählen, und das führte zur Entwicklung von Envision, unserer domänenspezifischen Programmiersprache. Mit Envision haben wir effektiv alle Probleme aufgeteilt. Wir haben die Infrastruktur, die Dateninfrastruktur und die Machine Learning-Infrastruktur getrennt. Dies sind langfristige Produkte, die wir pflegen und aktualisieren möchten, und es ist jedes Mal ein mehrjähriger Aufwand, wenn wir uns entscheiden, sie zu ändern und zu aktualisieren.
Dann erstellen wir für jeden einzelnen Kunden eine völlig maßgeschneiderte Implementierung, die in Skripten in Envision geschrieben ist. Da Envision speziell für die Optimierung der Lieferkette entwickelt wurde, konnten wir für jeden einzelnen Kunden etwas vollständig individuelles schreiben, mit hoher Produktivität und gleichzeitig vollständig maßgeschneidert.
Also beginnen wir mit einem leeren Blatt, passen es vollständig an und müssen uns dann nicht mit einer Situation konfrontieren, in der der Kunde uns um etwas bittet, das wir nicht unterstützen. Aufgrund der programmatischen Fähigkeiten von Envision ist der schlimmste Fall, wenn wir etwas Besonderes für einen Kunden tun müssen, dass das von uns geschriebene Skript nicht so kompakt ist wie üblich. Wir können jedoch immer noch von einer Infrastruktur profitieren, die entwickelt wurde, um bestimmte Arten von Problemen leicht zu lösen.
Wenn Sie erweiterte programmatische domänenspezifische Fähigkeiten in Ihre Plattform integrieren, müssen Sie plötzlich keine Verhandlung mehr überstürzen, die Ihr Produkt beeinträchtigen würde. Sie können die Anpassung in Ihrer programmatischen Umgebung durchführen, die für jeden einzelnen Kunden maßgeschneidert ist, und dann Upgrades für Ihre Plattform nach Ihrem eigenen Zeitplan bereitstellen, der höchstwahrscheinlich nicht mit dem Zeitplan Ihrer Kunden übereinstimmt.
Kieran Chandler: Sie haben dieses Problem frühzeitig erkannt. Welchen Rat würden Sie anderen Softwareunternehmen geben, die mit dieser Art von aufgeblähter Software zu kämpfen haben? Können sie etwas dagegen tun? Sollten sie damit beginnen, 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 z.B. ein WMS, ERP, MRP usw., haben Sie möglicherweise nicht einmal Zugriff auf die Software selbst, es könnte sich nur um ein Produkt eines Anbieters handeln. Wenn Sie keinen Zugriff auf das Produkt haben, sind Sie also mit der Komplexität der von Ihnen erworbenen Software konfrontiert.
Wenn Sie Zugriff auf die Software haben und sie vereinfachen möchten, sollten Sie zunächst alle Dinge betrachten, die Sie nicht verwenden, und sie konsequent verwerfen. Viele Menschen sind in der Regel besorgt darüber, Teile einer vorhandenen Software zu entfernen, weil sie befürchten, bestimmte Funktionen zu verlieren. Es stimmt, dass Sie bei der Entfernung von Funktionen diese Funktionen verlieren. Wenn Sie jedoch etwas entfernen, das fast nie verwendet wird, können Sie auch ganze Klassen von Problemen entfernen, die durch die bloße Existenz dieser winzigen Funktion verursacht wurden.
Bei Lokad sehen wir oft ERP-Implementierungen mit buchstäblich Tausenden von Tabellen. Sie können ein ERP mit, sagen wir, fünftausend Tabellen haben. Jede Tabelle kann zwischen 10 und 200 Felder haben, was zu massiver Komplexität führt. Selbst das Sichern des ERPs kann unglaublich kompliziert sein.
Kieran Chandler: Weil Sie so viele Tabellen haben, benötigen Sie eine Tabelle, um die Liste der Tabellen und dergleichen zu speichern. Das ist die Art von Situation, in der Sie, wenn Sie viele Tabellen identifizieren können, die nicht mehr verwendet werden, oder Bildschirme, die nicht mehr verwendet werden, indem Sie sie einfach entfernen, alles vereinfachen.
Joannes Vermorel: Genau, zum Beispiel, wenn Sie von einer Version Ihrer Datenbank auf eine andere aktualisieren müssen, ist eines der Probleme, mit denen Sie konfrontiert werden können, dass Sie Teile der Logik aktualisieren müssen, die von niemandem mehr verwendet werden. Jede einzelne Zeile Code, sei es Java, C Sharp, SQL oder sonst etwas, ist etwas, das Sie so lange wie die Codezeile selbst warten müssen. Wenn Sie das entfernen, bedeutet das, dass Sie während Ihrer nächsten Integration oder Migration nicht die Frage stellen müssen, wie wir diese Sache zur nächsten Version des Systems oder zum nächsten System übertragen.
Und das ist etwas, worüber Supply-Chain-Manager nachdenken sollten. Beim Kauf von Software sollten sie sich wirklich an das Prinzip der Sparsamkeit halten - wenn Sie es wirklich nicht brauchen, ist es besser, diesen Teil des Systems nicht zu haben. Es wird nur eine Belastung sein. Es ist wichtig, ständig auf die technologische Masse der Lösung zu achten, die Sie erwerben und betreiben.
Diese technologische Masse ist nicht kostenlos. Wenn Sie mehr Bildschirme haben, benötigen Sie mehr Personen, um sie zu schulen. Wenn Sie ein paar Bildschirme entfernen können, bedeutet das weniger Schulungen, weniger gemeldete Fehler, weniger Kämpfe mit der IT und so weiter. Es geht darum, die Komplexität der IT zu managen, aber der schwierige Teil besteht darin, dass die IT in der Regel keine Ahnung davon hat, weil sie keinen Zugang zum Geschäftswert hat. Sie können nicht zwischen Funktionen unterscheiden, die wirklich notwendig sind, und Funktionen, die nicht unbedingt notwendig sind. Sie können Tabellen, Felder, Bildschirme oder Funktionen nicht in Euro oder Dollar umrechnen. Das können nur die Leute in der Supply Chain oder im Marketing, wenn Sie sich ein anderes System ansehen. Deshalb braucht die IT die Unterstützung dieser Personen, der Entscheidungsträger im Unternehmen, um die Priorisierung und Vereinfachung des Systems voranzutreiben.
Kieran Chandler: Um das Ganze abzurunden, haben Sie erwähnt, dass ich als Supply-Chain-Manager, der in eine neue Software für mein Unternehmen investieren möchte, anscheinend nicht nach so viel Anpassung fragen sollte, weil das Probleme mit sich bringt. Also, wonach sollte ich suchen?
Joannes Vermorel: Ja, nach Anpassung oder speziellen Funktionen zu fragen, ist wie ein Rezept, um Probleme zu generieren. Wenn Ihr Softwareanbieter nicht genug Probleme hat, schaffen Sie gerade neue, die die Dinge nur noch schlimmer machen werden. Also sollten Sie das wirklich nicht tun. Wenn Sie tatsächlich nach Anpassung fragen können, nur als Test, denn wenn der Anbieter bereitwillig in die Diskussion über Anpassung einsteigt, bedeutet das, dass der Anbieter keine Integrität hat. Das bedeutet, dass der Anbieter das bei jedem anderen Kunden genauso macht, was bedeutet, dass selbst wenn das Produkt heute gut ist, es in fünf Jahren ein Albtraum sein wird.
Zunächst einmal ist es gut, nach Anpassung zu fragen, und Sie sollten wirklich erwarten, dass diese Anfrage abgelehnt wird. Wenn nicht, dann ist das ein Problem.
Kieran Chandler: Eine Sache, die die Leute verlangen sollten, sind spezielle Funktionen, oder? Ich meine, wenn es etwas gibt, nach dem man fragen sollte, könnte es der Zugang zum CTO oder zum Produktmanager auf der Anbieterseite sein. Nehmen Sie es als Teil des Vertrags auf, vielleicht? Wie zum Beispiel die Forderung, einmal im Monat zwei Stunden mit dieser Person zu sprechen. Warum?
Joannes Vermorel: Wenn Sie verhandeln, um direkten Zugang zu den Personen zu haben, die die Roadmap des Anbieters entwickeln, können Sie einfach Ihre Änderungen präsentieren. Sie müssen Ihre Lösung nicht aufzwingen; präsentieren Sie einfach Ihr Problem. Denn was machen Ingenieure, wenn ihnen ein Problem präsentiert wird? Sie beginnen an einer Lösung zu arbeiten. Wenn Sie regelmäßige Meetings haben, in denen Sie Ihre Probleme präsentieren, müssen Sie nicht für bestimmte Funktionen im Vertrag verhandeln. In ein paar Jahren werden Funktionen im Produkt auftauchen, die genau zu dem Problem passen, das Sie aufgedeckt haben.
Kieran Chandler: Können Sie das etwas genauer erklären?
Joannes Vermorel: Wenn Sie rechnen, betrachten Sie den CTO eines Softwareunternehmens. Wie viele Meetings kann diese Person in einem Monat mit Kunden haben? Nehmen wir an, sie hat maximal 20. Wenn Sie einmal im Monat ein Meeting haben, erhalten Sie im Wesentlichen etwa fünf Prozent der geistigen Bandbreite des CTO, der die technologische Entwicklung des Anbieters, mit dem Sie zusammenarbeiten, vorantreibt. Das bedeutet, dass Ihre Probleme eine erhebliche Aufmerksamkeit erhalten.
Kieran Chandler: Was ist also Ihr Vorschlag?
Joannes Vermorel: Mein Vorschlag, wenn Sie klug vorgehen wollen, ist es, sich den Personen anzunähern, die die Roadmap kontrollieren. Es ist klüger, als überstürzt für fehlerhafte Funktionen zu verhandeln, die Sie wahrscheinlich in sechs Monaten verwerfen werden, weil Ihre Lösung nicht gut war oder sich Ihr Problem geändert hat. Eine andere Art von Ratschlag wäre auch, Software zu vermeiden, die zu viel kann. Sie sollten an eine Software denken, die eine Sache tut und sie gut macht, anstatt an eine Software mit umfangreichen Funktionen, die letztendlich alles schlecht macht.
Kieran Chandler: Können Sie das genauer erläutern?
Joannes Vermorel: Es ist einfacher, eine eng fokussierte Software zu verbessern als ein riesiges Framework, das alles macht. Immer wenn Sie etwas anpassen, denken Sie an die quadratische Anzahl von Interaktionen. Wenn Sie tausend Funktionen haben und eine hinzufügen, müssen Sie an alle Interaktionen mit den bereits vorhandenen tausend Funktionen denken. Wenn Sie also eine Funktion einführen, betrachten Sie alle tausend Interaktionen. Wenn Sie jedoch nur zehn Funktionen haben und eine elfte hinzufügen, müssen Sie nur zehn Interaktionen überprüfen. Konzentrieren Sie sich also auf etwas, das schlank ist und sich auf das spezifische Problem konzentriert, das Sie lösen möchten.
Kieran Chandler: Großartig! Ich fürchte, wir müssen es hier für heute belassen, aber ich vermute, es gibt ein paar CEOs da draußen, die Ihnen dafür nicht allzu dankbar sein werden und wahrscheinlich ein paar mehr Telefonanrufe erhalten werden. Nun, das war alles für diese Woche. Wir sind nächste Woche wieder mit einer neuen Folge zurück. Bis dahin, passen Sie auf sich auf.
Joannes Vermorel: Danke.
