Manche Anforderungen passen in kein Standardsystem. Diese hier gehörte dazu: ein Produktkonfigurator mit einer Logik, die kein fertiges Werkzeug abbildet. Wie er trotzdem in Business Central gelandet ist, KI-gestützt gebaut und senior gesteuert, erzählen wir hier. Ohne Wunderzahlen.
Ihren Anwendungsfall besprechenEin Industrieunternehmen konfiguriert seine Produkte nach einer Logik, die weit über das hinausgeht, was Standardsoftware abbildet: Varianten, Regeln und Abhängigkeiten, die ineinandergreifen. Dafür gibt es kein fertiges Werkzeug. Auch in Business Central lässt sich diese Logik im Standard nicht abbilden. Das ist keine Schwäche des Systems, es ist die ehrliche Diagnose: Standard ist für das gebaut, was viele brauchen. Diese Anforderung brauchte nur einer.
Die bestehende Lösung war über Jahre gewachsen und technisch nicht mehr zukunftsfähig. Jede Änderung wurde zur Archäologie: erst verstehen, was damals warum gebaut wurde, dann vorsichtig anpassen. So etwas trägt eine Weile. Aber es wird jedes Jahr teurer, und irgendwann steht die Frage im Raum, die wir aus vielen Projekten kennen: weiter flicken oder neu denken?
Der bequeme Weg wäre gewesen, die Speziallogik doch irgendwie ins ERP zu pressen. Wir kennen das Ergebnis solcher Entscheidungen: ein verbogener Standard, der bei jedem Update zittert. Genau das wollten wir nicht.
Statt Business Central zu verbiegen, haben wir den Konfigurator als eigenständige Anwendung neu aufgebaut und sauber an das System angebunden. Die Arbeitsteilung ist klar: Die Datenbasis bleibt in Business Central und behält dort ihre eine, verantwortete Wahrheit. Die Speziallogik lebt daneben, in einer Anwendung, die genau für sie gebaut ist.
Diese Trennung ist mehr als Architektur-Hygiene. Sie hält Business Central updatefähig: Die zwei Release-Wellen pro Jahr laufen weiter automatisch durch, weil kein verbogener Standard im Weg steht. Und sie hält die Speziallösung beweglich, weil sie sich weiterentwickeln kann, ohne das ERP anzufassen.
Senior gesteuert heißt hier konkret: Ein erfahrener Entwickler trifft die fachlichen und die Architektur-Entscheidungen, prüft jeden Stand und gibt frei, was übernommen wird. Eine Person, die Verantwortung trägt. Kein Team, das sich an der Komplexität abarbeitet und die Verantwortung verteilt, bis sie niemand mehr hat.
Die Entwicklung lief test-getrieben, und die Reihenfolge ist der Punkt: Zuerst schreibt der Entwickler die Tests, selbst, von Hand. Erst dann entwickelt die KI gegen diese Tests. Warum diese Reihenfolge? Weil eine KI, die ihre eigenen Prüfkriterien schreibt, sich den Erfolg selbst schönschreiben kann. Gegen fremde Tests kann sie das nicht. Entweder die Logik besteht, oder sie besteht nicht.
Was die Tests besteht, wird trotzdem nicht blind übernommen. Der Entwickler liest, prüft und merged jeden Stand. Die KI beschleunigt die Routinearbeit, das Grundgerüst, die Wiederholung. Die kritischen und fehleranfälligen Teile bleiben in seiner Hand.
Und damit das hier keine Hochglanzgeschichte wird: Ein erheblicher Teil der Arbeit floss in Bug-Fixing. KI-gestützte Entwicklung ist kein Selbstläufer, sie verschiebt die Arbeit vom Tippen zum Prüfen. Wer Ihnen erzählt, KI baue so etwas nebenbei, war bei so einem Projekt noch nicht dabei.
Der Prototyp läuft, und zwar über den ganzen Kernprozess: Artikel aus Business Central holen, verarbeiten, neu anlegen, Stücklisten und Arbeitspläne erzeugen. Über eine Code Unit sauber in Business Central überführt, nicht drangeklebt.
Wichtiger als der Prototyp selbst ist, was er möglich macht: Anforderungen, die im alten System an dessen Grenzen scheiterten, lassen sich jetzt umsetzen. Aus einer Altlast, die jede Änderung bestrafte, ist ein Fundament geworden, auf dem weitere Anforderungen aufsetzen.
Und weil Ehrlichkeit hier die Währung ist: Es ist ein Prototyp, kein fertiges Produkt. Erweiterungen und die Schnittstelle zu einem weiteren System stehen noch aus. Genau so sagen wir es auch dem Kunden.
Solche Geschichten enden sonst mit einer Zahl: fertig in X Tagen, Kosten gezehntelt. Wir lassen das weg, aus einem einfachen Grund: Wir können es nicht seriös belegen. Ein Prototyp ist kein Projektabschluss, und ehrliche Zwischenstände sind uns mehr wert als runde Zahlen. Was wir belegen können, steht oben: eine Speziallösung, die es als Standard nicht gibt, nutzbar in Business Central, gebaut mit einer Methode, die KI-Tempo und Senior-Kontrolle verbindet. Das ist die Geschichte. Sie reicht.
KI beschleunigt die Routine. Die Verantwortung für das Ergebnis bleibt beim erfahrenen Menschen.
Drei Dinge aus diesem Projekt gelten überall. Erstens: Die Datenbasis gehört ins ERP, mit einer verantworteten Wahrheit, sonst hat auch die beste Speziallösung nichts, worauf sie arbeiten kann. Zweitens: KI-Entwicklung braucht einen Menschen, dem die Prüfkriterien gehören. Drittens: Speziallogik gehört neben den Standard, nicht hinein. Wer diese drei Dinge hat, kann sich Anforderungen leisten, die früher als unbezahlbar galten.
Dann sprechen wir darüber, was in Business Central möglich ist.
Anwendungsfall besprechen