Praxisfall: Der Händler gestaltet sein eigenes ERP
Ein Shopware-Händler entwickelt mit Codex ein neues, webbasiertes ERP für seine Nische. Er baut es als Nachfolger eines mehr als zwanzig Jahre alten Systems. Die Idee kommt aus dem eigenen Betrieb: Der Händler kennt die Abläufe und baut die neue Anwendung um diese Erfahrung herum. [S144]
Mich interessiert daran vor allem die neue Rolle des Händlers. Er muss seine Vorstellung nicht mehr vollständig an eine fremde Entwicklungsabteilung übergeben und auf den fertigen Entwurf warten. Mit einem Coding-Agenten kann er selbst einen Ablauf in Software übersetzen und ausprobieren. An der Anwendung wird sichtbar, ob seine Regel verständlich beschrieben ist und im Arbeitsalltag funktioniert.
Weil ein ERP Einkauf, Artikel, Warenbewegungen und Abrechnung verbindet, ist die Nischenkenntnis des Händlers besonders wertvoll. Er weiß, welche Ausnahme regelmäßig vorkommt und welcher vermeintliche Sonderfall längst zum normalen Geschäft gehört. Dieses Wissen kann nun unmittelbar zum Ausgangspunkt der Software werden.
Zur Ablösung gehört auch die Geschichte des Geschäfts. Die GoBD verlangen bei der Überführung steuerlich relevanter Daten eine gleichwertige Übernahme einschließlich notwendiger Verknüpfungen; die Verfahrensdokumentation gehört ebenfalls dazu. Migration und steuerliche Abstimmung bleiben deshalb eigene Aufgaben des Projekts. [S148, S149]
Für die Zukunft zeigt der Fall eine veränderte Arbeitsteilung: Der Händler kann selbst gestalten und früher entscheiden, welche Hilfe er benötigt. Entwickler, Agenturen und Fachleute bringen ihre Erfahrung dort ein, wo sie den Entwurf verlässlich in den Betrieb trägt. Unternehmerische Eigenständigkeit wächst, weil der Weg vom eigenen Fachwissen zur nutzbaren Anwendung kürzer wird.
Praxisfall: Ein lange blockierter Wechsel bekommt einen Weg
Ein neuer Shopware-Kunde hatte jahrelang keine wirtschaftlich tragbare Lösung für den Wechsel seines Shopsystems gefunden. Sein Geschäftsmodell brauchte Funktionen, die ein Standardshop nicht mitbrachte. Mit der Community Edition fand er eine Grundlage, auf der er diese Besonderheiten mit Claude in eigenen Erweiterungen umsetzt. [S144]
Der Bedarf war schon da. Der Händler musste keine neue Geschäftsidee finden; er wollte sein bestehendes Geschäft besser abbilden. Jetzt kann er eine Anforderung beschreiben, einen Entwurf ausprobieren und ihn an den eigenen Abläufen weiterentwickeln. Der Systemwechsel wird dadurch zu einem Vorhaben, das er selbst mitgestalten kann.
Die Erweiterungen bauen auf den vorhandenen Shop auf. Produktverwaltung und Bestellungen müssen nicht für jede Besonderheit neu erfunden werden. Der Händler konzentriert sich auf die Regeln, die sein Unternehmen ausmachen. Offener Code und ein Coding-Agent geben ihm dafür einen direkten Zugang zum System.
Solche Vorhaben verändern auch die Zusammenarbeit mit einer Agentur. Auf dem Tisch liegt bereits eine Anwendung, an der der Händler zeigen kann, was er meint. Beratung, Architektur, Prüfung und Pflege setzen an einer konkreten Lösung an. Fachwissen und technische Erfahrung finden früher zueinander.
Beide anonymisierten Fälle stammen aus meinem Händlerumfeld und zeigen, was Händler heute mit Coding-Agenten selbst in Angriff nehmen: ein betriebliches Kernsystem oder die Besonderheiten eines komplexen Shops. Mich fasziniert daran, dass die eigene Erfahrung unmittelbar Arbeitsmaterial für die Software wird. Mehr Unternehmen können so ihre Arbeitsweise gestalten, statt sie an das anzupassen, was bisher bezahlbar zu bekommen war.
Das Briefing wird zum Prototyp
Bei Werkpunkt beginnt die Idee mit einer Tabelle. Ein Instandhalter kopiert eine Liste von Ersatzteilen aus seinem System, der Vertrieb sucht Artikelnummern, Varianten und Kundenpreise zusammen. Die gewünschte Schnellbestellung ist seit Langem klar: Liste hinein, erkannte Positionen prüfen, Unklarheiten klären, Angebot vorbereiten.
Lassen wir einen Coding-Agenten diesen ersten Entwurf auf einer Kopie des Shops bauen. Er nutzt vorhandene Produkt- und Preisfunktionen. Die erste Ansicht kann schon zeigen, wo die eigentliche Arbeit steckt: Eine abgekürzte Bezeichnung passt zu zwei Revisionen derselben Maschine. Der Kunde muss diese eine Frage beantworten, bevor aus der Liste ein Angebot wird. Ein schöner Upload-Button allein hätte das Problem nur schneller weitergereicht.
Weil das Briefing bereits als Prototyp vorliegt, kann die Agentur den Geschäftsweg prüfen und mit dem Händler vereinbaren, wie daraus eine gepflegte Erweiterung wird. Für mich ist das eine der größten Chancen der agentischen Entwicklung: Ideen werden früh besprechbar, auch bevor ein großes Projektbudget gebunden ist.
Offener Code als Arbeitsmaterial
Coding-Agenten wie Codex und Claude Code können einen vorhandenen Codebestand lesen, Abhängigkeiten verfolgen und Änderungen vorschlagen. Auf einem offenen Kern können sie bis zur Handelslogik schauen. Menschen sehen denselben Zusammenhang und können eine Änderung prüfen. Geschlossene Plattformen erlauben über Schnittstellen ebenfalls Anpassungen; die Eingriffstiefe und die Kontrolle darüber unterscheiden sich.
Ein Kundenpreis kann von einer Vertragsregel abhängen, die eine andere Erweiterung ergänzt. Ein Agent mit Zugriff auf den Code kann diesen Zusammenhang verfolgen und den vorgesehenen Erweiterungspunkt finden. Dokumentation und Testdaten helfen anschließend, die Änderung an einer Bestellung nachzuvollziehen.
Was sich für Agenturen ändert
Wenn Umsetzung schneller wird, gewinnt das Urteil darüber an Wert, welche Besonderheit das Geschäft verbessert. Eine Agentur hilft bei dieser Auswahl, entwirft die passende Architektur und vereinbart den Betrieb nach dem nächsten Update. Ihre Verantwortung beginnt deshalb deutlich vor der Endabnahme.
| Aufgabe | Mit Coding-Agenten | Wertbeitrag der Agentur |
|---|---|---|
| Idee konkretisieren | Händler und Agent bauen einen ersten Entwurf | Geschäftslogik und UX schärfen |
| Umsetzung | Viele Änderungen entstehen schnell | Erweiterungspunkte und Architektur festlegen |
| Qualität | Mehr Varianten werden möglich | Sicherheit, Leistung und echte Grenzfälle prüfen |
| Betrieb | Mehr eigene Erweiterungen bleiben im Umlauf | Updates, Beobachtung und Fehlerbehebung tragen |
| Vergütung | Reine Umsetzungszeit verliert Knappheit | Prototyp-Sprints, Coaching und Betriebspakete anbieten |
Ein Betriebspaket nennt die betreuten Erweiterungen, Reaktionszeiten und enthaltenen Updates. Bei einer Vergütung nach Ergebnis legen Händler und Agentur den gemessenen Nutzen und den Umgang mit fremden Einflüssen fest. So wird aus einer neuen Preisidee ein Angebot, auf das sich beide Seiten verlassen können.
Nordstern (fiktiv): die Beratung, die bisher zu aufwendig war
Nordstern möchte die persönliche Tourenberatung auch Kunden anbieten, die außerhalb der Ladenzeiten planen. Bisher lohnt sich diese Tiefe nur bei wenigen Aufträgen. Der Händler entwickelt mit einem Coding-Agenten einen Tourenberater: Reiseziel, Jahreszeit, vorhandene Ausrüstung und persönliche Wünsche führen zu einer passenden Auswahl.
Für eine begrenzte Produktgruppe liest der erste Prototyp bestätigte Eigenschaften und Lagerdaten und verwendet die Preisberechnung der Storefront. Fehlende Angaben führen zu Rückfragen, während erfahrene Berater typische Touren ausprobieren und falsche Schlussfolgerungen korrigieren. So fließt das Wissen aus der Beratung direkt in die nächste Fassung.
Vor der Einführung prüft Nordstern, ob Beratung, Warenkorb und Service dieselbe Auswahl wiederfinden. Danach kann der Händler den Berater um sein eigenes Erfahrungswissen erweitern. Seine Besonderheit liegt in einer Beratung, deren Tiefe bisher zu teuer gewesen wäre.
Werkpunkt (fiktiv): aus der Teileliste wird eine Schnellbestellung
Werkpunkt setzt den bereits beschriebenen Entwurf als Erweiterung um. Kunden können eine Ersatzteilliste einfügen. Der Agent ordnet Positionen dem Katalog zu; der Shop liefert Kundenpreise und Lieferinformationen. Unklare Revisionen gehen an die Fachberatung, bevor ein Angebot entsteht.
Ein Coding-Agent unterstützt den Bau der Eingabemaske, der Zuordnung und der Verbindung zu den vorhandenen Shopfunktionen. Händler und Agentur prüfen den Ablauf mit vertrauten Listen und typischen Fehlern. Ein Kunde mit Leserechten erhält ein Ergebnis zur Prüfung, aber keine Möglichkeit, selbst eine Bestellung auszulösen.
Der Händler entwickelt damit eine Fähigkeit, die genau zu seiner Nische passt. Später kann daraus ein betreuter Beschaffungsdienst werden: mit bekannten Maschinen, freigegebenen Ersatzteilen und den Einkaufsregeln des Kunden. Das erste Bauvorhaben schafft dafür eine konkrete Grundlage.
Lichtfeld (fiktiv): eine Kollektionswelt mit verbindlichem Warenkorb
Lichtfeld will die Zusammenstellung von Leuchten als gestaltete Raumgeschichte anbieten. Ein Coding-Agent baut dafür eine erste Kollektionswelt aus den Bildern, Produktinformationen und Gestaltungsregeln des Händlers. Das Team entscheidet über Atmosphäre und Auswahl und probiert Varianten direkt am Entwurf aus.
Jedes gezeigte Produkt bleibt mit einem tatsächlichen Artikel verbunden. Wählt der Kunde Farbe oder Ausführung, fragt die Oberfläche die gültige Variante, den Preis und die Lieferbarkeit im Shop ab. Der Warenkorb verwendet diese bestätigte Auswahl. So kann die Gestaltung frei werden, während der Kauf auf derselben verlässlichen Grundlage bleibt.
Der erste Einsatz kann eine einzelne Kollektion betreffen. Lichtfeld lernt daran, welche Darstellung Kunden bei der Auswahl hilft und wie die Inhalte gepflegt werden. Danach lässt sich die eigene Handschrift auf weitere Räume und Sortimente übertragen.
Drei Abkürzungen, die später teuer werden
Die erste ist die Änderung direkt im Kern, obwohl ein Erweiterungspunkt existiert. Beim nächsten Update treffen zwei Entwicklungen aufeinander, die nichts voneinander wissen. Die zweite ist unkontrollierter Datenzugriff: Ein Agent braucht für eine Vorschau selten die vollständige Kundendatenbank. Die dritte ist der private Fork ohne Pflegeplan. Die erste Version ist schnell gebaut, aber für spätere Updates fühlt sich niemand verantwortlich.
Ein einfacher Arbeitsablauf hilft: Aufgabe und Grenzen festhalten, auf einer Kopie entwickeln, Änderung prüfen, mit einem normalen Fall und einem Gegenfall abnehmen, dann ein begrenztes Release. Halten Sie fest, wie Sie zurückgehen und wer den Betrieb übernimmt. Das lässt sich klein anfangen, ohne für jede Idee einen neuen Verwaltungsapparat aufzubauen.
Rechenvorlage für eigene Bauvorhaben
Was Plattformen jetzt liefern müssen
Plattformen werden für zwei Arten von Entwicklern gebaut: Menschen und ihre Agenten. Stabile Erweiterungspunkte, klare Fehlermeldungen und nachvollziehbare Geschäftsoperationen helfen beiden. Anleitungen als AGENTS.md oder Skills erklären dem Coding-Agenten, welche Konventionen gelten und welche Prüfungen nötig sind. Testdaten und eine private Vorschau verkürzen den Weg zum brauchbaren Ergebnis.
Agent in a Box aus dem Lab schafft diesen Arbeitsraum pro Projekt; Kapitel 13 erklärt die Sicherheitsgrenze. [S109]
Welche Versuche lohnen die nächste Investition? Das nächste Kapitel zeigt, wie wir diese Frage im Lab bearbeiten.