Das System of Record sollte lokal sein
Ich bin zu der Auffassung gelangt, dass die meisten Unternehmen für supply chain damit aufhören sollten, breit angelegte Systeme der Aufzeichnung zu kaufen, und stattdessen beginnen sollten, sie lokal zu entwickeln. Ich spreche von der Software, die Bestellungen, Eingänge, Lagerbewegungen, Rechnungen, Freigaben und das administrative Nachspiel gewöhnlicher Abläufe aufzeichnet. Diese Systeme sind kritisch, aber ihr Wert ist begrenzt. Sie sind Hauptbücher mit Arbeitsabläufen. Der Markt bewertet, präsentiert und regelt sie immer noch, als wären sie die Kronjuwelen des Unternehmens. Dieser Fehler ist sehr teuer geworden.
In Einführung in supply chain, insbesondere Kapitel 5 und 6, zog ich eine Grenze zwischen Software, die den Papiernachweis führt, und Software, die Entscheidungen trifft. Dieser Unterschied ist hier von Bedeutung. Sobald man ein Aufzeichnungssystem ohne das übliche Theater betrachtet, verschwindet ein Großteil des Mysteriums. Ein System der Aufzeichnung sollte zuverlässig, prüfbar und ziemlich langweilig sein. Es sollte nicht so tun, als könnte es denken. Es sollte sich Fakten merken, einige Arbeitsabläufe erzwingen und sich zurückhalten.
Die versteckte Steuer vorgefertigter Hauptbücher
Ein Aufzeichnungssystem erreicht schnell die kommerzielle Reife. Sobald es in der Lage ist, Einkauf, Verkauf, Lagerbestand, Rechnungsstellung und einige angrenzende Arbeitsabläufe zuverlässig zu bewältigen, ist der zusätzliche Nutzen einer Erweiterung gering. Anbieter wissen das nur zu gut. Ihre Antwort ist über Jahrzehnte hinweg immer dieselbe gewesen: Fügen Sie eine weitere Entität, einen weiteren Bildschirm, ein weiteres Modul, eine weitere Konfigurationsseite hinzu. Verkaufen Sie das nächste Inkrement an die bestehende Basis. Mit der Zeit wird das Produkt zum Sediment unzähliger Kundenanfragen, von denen viele für sich genommen sinnvoll, in der Gesamtheit absurd sind. Das Ergebnis ist ein Funktions-Mastodon, dessen Komplexität weiter steigt, obwohl die zugrunde liegende Aufgabe sich kaum verändert hat.
Die wissenschaftliche Literatur beschreibt dasselbe Problem seit Jahren in ruhigerer Sprache. Strong und Volkoff beobachteten, dass vorgefertigte Unternehmenssysteme für generische statt spezifische Anforderungen konzipiert sind und daher in jeder konkreten Organisation tendenziell nicht optimal passen. Eine neuere Studie zur ERP-Anpassung macht den Kompromiss explizit: Individuelle Anpassungen können die Funktionalität und die Benutzerzufriedenheit verbessern, führen jedoch auch zu höheren Implementierungskosten, mehr Komplexität und höheren Kosten für spätere Upgrades. Ein Review zu ERP-Missfits aus dem Jahr 2025 kommt zu einer ebenso ernüchternden Schlussfolgerung: Die Implementierungsfehlerquoten bleiben hoch, die Fehlanpassung zwischen standardisierten Prozessen und lokalen Arbeitsabläufen besteht fort, und es ist keine weithin anerkannte Branchenpraxis entstanden, die diese Diskrepanzen sauber behebt.
Diese Steuer beschränkt sich nicht auf Lizenzgebühren. Panoramas ERP-Benchmark 2025 berichtet von einem mittleren Projektkostenaufwand von 450.000 USD und einer mittleren Projektdauer von neun Monaten. Bei Projekten, die das Budget überschritten, war der häufigste Grund der unerwartete Bedarf an zusätzlicher Technologie. Bei verspäteten Projekten waren Datenprobleme der Hauptverursacher. Derselbe Bericht stellt fest, dass viele ERP-Implementierungen es immer noch nicht schaffen, organisatorische Silos aufzulösen. Dies ist das Muster, das ich immer wieder beobachte: Die Suite beseitigt die Komplexität nicht, sondern verteilt sie auf Integration, Migration, Steuerung und umständliche Umgehungslösungen.
Die zugrunde liegenden Datenmodelle erzählen dieselbe Geschichte. Die Dokumentation von Microsoft für Dynamics erklärt, dass ein einfaches Geschäftskonzept wie ein Kunde über mehrere normalisierte Tabellen verteilt sein kann, weshalb Dateneinheiten als denormalisierte Abstraktionen existieren. Die Dokumentation von Oracle JD Edwards zeigt lange Kataloge von Tabellen nach Typ und Modul. ERPRef, ein Schema-Katalog von Drittanbietern, listet 1.687 Tabellen für SAP Business One 9.0 und 5.097 für JD Edwards 9.20 auf; in demselben Katalog wird die Debitoren-Rechnungstabelle in SAP Business One 9.3 mit 424 Spalten dargestellt. Ein bestimmtes Unternehmen wird nur einen Bruchteil dieser Breite nutzen, zahlt jedoch weiterhin für diese Breite in Form von Berechtigungen, Zuordnungen, Integrationen, Schulungen und Upgrades.
Es gibt eine zweite Steuer, und sie ist oft die schädlichere. William Ocasios aufmerksamkeitsbasierte Sichtweise eines Unternehmens beginnt mit einer einfachen Beobachtung: Was Unternehmen tun, hängt davon ab, wie die Aufmerksamkeit der Entscheidungsträger kanalisiert wird. Ein weit verzweigtes Aufzeichnungssystem beansprucht diese Aufmerksamkeit ebenso wie es Geld verschlingt. Die Jahre, die für Implementierungen, Bereinigungen, Migrationen, Neugestaltungen, Zusatzmodule und Upgrades aufgewendet werden, sind Jahre, in denen das obere Management von der Mechanik der administrativen Infrastruktur absorbiert wird. Ich habe an anderer Stelle argumentiert, dass, wenn Aufzeichnungen und Berichte den größten Teil des Softwarebudgets verbrauchen, sie auch den Großteil der Exekutivkapazität in Anspruch nehmen, sodass wenig Raum für die Software bleibt, die tatsächlich Entscheidungen verbessern könnte.
Warum maßgeschneiderte Lösungen nicht mehr schwierig sind
Bemerkenswert ist, dass der technische Fall für maßgeschneiderte Aufzeichnungssysteme schon vor geraumer Zeit aufhörte, exotisch zu sein. PostgreSQL kann auf fast vier Jahrzehnte aktive Entwicklung zurückblicken und ist seit 2001 ACID-konform. ASP.NET Core ist kostenlos, Open Source und plattformübergreifend. Entity Framework Core unterstützt Änderungsverfolgung, Updates und Schema-Migrationen über mehrere Datenbanken hinweg. Django wird mit eingebauten Schutzmaßnahmen gegen gängige Webangriffe ausgeliefert. Wenn die Infrastruktur für transaktionale Software so ausgereift geworden ist, ist der Bau eines schmalen internen Hauptbuchs nicht mehr ein Akt der Dreistigkeit.
Es gibt sogar ein aufschlussreiches Detail in der Django-Dokumentation. Die automatische Admin-Oberfläche wird als internes Verwaltungstool einer Organisation empfohlen, nicht als öffentliche Frontend-Lösung. Dieser kleine Hinweis fasst das Ganze zusammen. Die Branche hat das Backoffice-Skelett von CRUD-Software so gründlich standardisiert, dass große Frameworks es nun bereits out-of-the-box mitliefern. Was weiterhin schwierig ist, ist nicht die Infrastruktur. Was weiterhin schwierig ist, ist die Entscheidung, welche Entitäten, Zustände und Arbeitsabläufe für Ihr Unternehmen wirklich von Bedeutung sind und welche nur deshalb vorhanden sind, weil ein Anbieter zwanzig Jahre damit verbracht hat, Eigenheiten eines Marktsegments zu sammeln.
Hier gewinnt die maßgeschneiderte Lösung entscheidend. Der Vorteil liegt nicht in der virtuosen Codierung. Der Vorteil liegt in semantischer Präzision. Die Entitäten können dem Unternehmen so entsprechen, wie es tatsächlich arbeitet: seiner Produkthierarchie, seinen Einkaufsausnahmen, seinen Eingangszuständen, seinen Freigaberegeln, seinen Rücksendegründen, seinen Qualitätszurückhaltungen, seinen eigenartigen, aber nützlichen Unterscheidungen, die keine generische Suite verstehen sollte. Ein kleiner lokaler Codebestand kann verständlich bleiben. Noch wichtiger ist, dass das Unternehmen das operative Wissen, das in diesem Code verkörpert ist, behält. Die Software spiegelt das Geschäft wider; das Geschäft muss nicht länger die akkumulierten Kompromisse der gesamten Kundenbasis eines Anbieters erben.
Was Coding Agents verändert haben
Was sich im Jahr 2025 änderte, war nicht die Datenbank, nicht der Browser und nicht der Web-Stack. Was sich änderte, waren die Kosten für die Code-Produktion. Im Januar 2025 berichtete Anthropic von 49 Prozent bei SWE-bench Verified für einen aufgerüsteten Claude 3.5 Sonnet Agent. Im August erreichte Claude Opus 4.1 74,5 Prozent. Das SWE-bench-Team merkte später an, dass der mini-SWE-agent denselben verifizierten Teil in einer spartanischen Konfiguration mit 65 Prozent erreichte. OpenAI seinerseits brachte Codex als Cloud-Software-Agent heraus, der parallel an vielen Aufgaben arbeiten, Tests und Linter in isolierten Umgebungen ausführen und Änderungen zur Überprüfung vorschlagen kann; in einem separaten internen Produkteexperiment gibt OpenAI an, dass Codex den gesamten millionenzeiligen Codebestand geschrieben hat, der in etwa einem Zehntel der Zeit gebaut wurde, die für handcodierte Lösungen erforderlich gewesen wäre.
Das bedeutet nicht, dass Agenten jeden Entwickler bei jedem Codebestand schneller machen. METR’s randomisierter Versuch mit erfahrenen Open-Source-Entwicklern ergab, dass KI-Tools aus dem frühen Jahr 2025 sie um 19 Prozent verlangsamten, als sie an ihren eigenen Repositories arbeiteten. Ich nehme dieses Ergebnis ernst. Dennoch beschreibt es nicht dasselbe Problem. Die Pflege eines ausgereiften öffentlichen Codebestands mit strengen Standards und jahrelang implizitem Kontext ist nicht dieselbe Aufgabe wie das Entwerfen eines Empfangs-Workflows, eines Lieferantenportals, einer Backoffice-Lösung für Bestandsanpassungen oder eines Rücksende-Bildschirms für ein internes Team. Für Letzteres sind die Anforderungen lokal, die Akzeptanzkriterien konkret und die Architektur gewöhnlich. METR’s separate Arbeiten zum Zeithorizont berichten außerdem, dass sich die Länge von Softwareaufgaben, die Frontier Agents mit 50 Prozent Zuverlässigkeit erledigen können, etwa alle sieben Monate verdoppelt hat. Genau diese Art von Trend ist entscheidend, wenn die Arbeit eng gefasst und gut definiert ist.
Deshalb kann nun selbst ein gewöhnlicher Hersteller, Großhändler oder Einzelhändler sinnvollerweise weitaus mehr seiner transaktionalen Software selbst besitzen als bisher. Ein solches Unternehmen muss kein Softwareanbieter werden. Es benötigt einen Prozessverantwortlichen, der das Geschäft versteht, einen technisch versierten Leiter, einen kleinen Codebestand, eine Test-Suite und die Disziplin, den Umfang eng zu halten. Coding Agents reduzieren den manuellen Implementierungsaufwand für die langweiligen Teile, von denen in Aufzeichnungssystemen die meisten genau diese sind. Inzwischen übernimmt der ausgereifte Open-Source-Stack den Rest. Die Kombination ist genau deshalb leistungsstark, weil Aufzeichnungssysteme so unprunkvoll sind. Es handelt sich größtenteils um Formulare, Tabellen, Validierungen, Berechtigungen, Arbeitsabläufe und Integrationen. Dort liegt die Stärke der Tools.
Ich würde immer noch die Bereiche ausnehmen, in denen der Hauptnutzen des Anbieters darin besteht, mit gesetzlichen Änderungen Schritt zu halten. Das sind echte Ausnahmen. Abgesehen von diesen, insbesondere im supply chain, sollte der Standard umgekehrt werden. Für Einkaufsabläufe, Eingänge, Rücksendungen, Qualitätsunterbrechungen, Lieferantenkooperation, Stammdatenpflege und ähnliche transaktionale Bereiche hat sich breit angelegte, vorgefertigte Software zu einem teuren Weg entwickelt, um eine mittelmäßige Passform zu erzielen. Die maßgeschneiderte Alternative ist nicht mehr ausschließlich Technologieunternehmen vorbehalten. Sie ist nun auch für normale Firmen in Reichweite, vorausgesetzt, sie sind bereit, einen bescheidenen Codebestand zu besitzen und der Versuchung zu widerstehen, diesen Codebestand in eine umfassende Plattform zu verwandeln.
Der Fall ist nicht mehr sentimental und auch nicht mehr futuristisch. Breit angelegte, vorgefertigte Hauptbücher sind von Natur aus generisch, aus Gewohnheit unpassend und inflationsanfällig in Bezug auf Kosten und Aufmerksamkeit. Die Werkzeuge zum Bau schmaler Alternativen sind seit Jahren ausgereift. Coding Agents haben nun den letzten Teil, der viele Unternehmen bisher vom Handeln abgehalten hat, nämlich die schiere Menge an routinemäßigem Coding, komprimiert. Bei supply chain-Systemen der Aufzeichnung hat sich die Beweislast umgekehrt. Ein Unternehmen sollte damit beginnen, zu fragen, warum dieses System überhaupt gekauft werden sollte.
