Der Anthropic-Artikel über Self-Service-Datenanalyse (opens in new tab) macht eine Beobachtung, die sich fast eins zu eins auf die Einführung einer hochkonfigurierbaren Low-Code-ERP-Plattform übertragen lässt: Die generativen Fähigkeiten eines LLM sind ein zweischneidiges Schwert — dieselben Mechanismen, die kreative Lösungen ermöglichen, erzeugen auch fehlerhafte Ausgaben.

Eine konfigurationsfreudige Low-Code-Plattform hat genau dieselbe Eigenschaft. Die Flexibilität, die schnelle und maßgeschneiderte Lösungen erlaubt, ist auch die Quelle der meisten gescheiterten Einführungen. „Die Plattform auf den Kunden loslassen und konfigurieren lassen” erzeugt dieselbe falsche Präzision, vor der der Artikel warnt: Anfangs herrscht Euphorie über die Befreiung von starrer Standardsoftware, die in Ernüchterung umschlägt, sobald klar wird, dass niemand mehr weiß, welche Konfiguration die kanonische ist, warum sie so gebaut wurde und ob sie noch stimmt.

Der zentrale Satz des Artikels, übersetzt auf unsere Welt: Die Komplexität liegt nicht im Bauen einer Konfiguration — das wird trivial, sobald man es richtig versteht. Sie liegt in der Mehrdeutigkeit: der Fähigkeit, eine fachliche Anforderung auf die eine richtige Stelle in der Plattform abzubilden und zu wissen, wie man dort korrekt arbeitet.

Deshalb folgt dieser Leitfaden derselben Logik wie der Artikel. Er identifiziert drei Fehlermodi, die für die überwältigende Mehrheit gescheiterter Low-Code-Einführungen verantwortlich sind, und baut für jeden eine Verteidigungsschicht.

Die drei Fehlermodi der Low-Code-Einführung

1. Konzept-zu-Konfiguration-Mehrdeutigkeit. Eine fachliche Anforderung („Wann gilt ein Auftrag als abgeschlossen?”) lässt sich auf einer flexiblen Plattform auf Dutzende plausible Arten umsetzen: ein Statusfeld, ein berechnetes Feld, ein Workflow-Schritt, eine eigene Entität. Verschiedene Beratende und verschiedene Key User entscheiden sich für verschiedene Wege, oft mit subtil unterschiedlicher Semantik. Genau wie beim Datenmodell mit vierzig plausiblen Umsatz-Definitionen entstehen so überlappende, inkonsistente Konfigurationen.

2. Veralterung. Geschäftsprozesse, Rollen und Anforderungen ändern sich während und nach dem Projekt ständig. Konfigurationen, die zum Zeitpunkt des Workshops korrekt waren, beginnen subtil falsche Ergebnisse zu liefern. Auf einer Low-Code-Plattform ist das gefährlicher als bei Standardsoftware, weil jede Konfiguration potenziell ein Einzelfall ohne Hersteller-Wartung ist.

3. Auffindbarkeitsfehler (Retrieval). Die richtige Konfiguration, der richtige Baustein, das wiederverwendbare Muster existiert bereits — aber angesichts der Weite des Konfigurationsraums findet es niemand wieder. Das Team baut neu, was schon da war, oder schlimmer: eine leicht abweichende Variante daneben.

Alles Weitere in diesem Leitfaden ist darauf ausgelegt, diese drei Fehlermodi anzugreifen.

Vorgehensmodell: die vier Phasen

Das Vorgehen spiegelt den agentischen Stack des Artikels (Fundamente → Sources of Truth → Skills → Validierung), nur auf ein Einführungsprojekt übertragen.

Phase 1 — Fundamente schaffen (Discovery & Konfigurationsleitplanken)

Bevor die erste Konfiguration entsteht, wird der Lösungsraum verkleinert. Das ist die wichtigste Phase, und die, die unter Termindruck am häufigsten übersprungen wird.

Konkret in dieser Phase:

  • Kanonische Bausteine definieren. Lege pro Domäne (Vertrieb, Einkauf, Lager, Finanzen, …) einen kleinen Satz kanonischer Entitäten, Felder und Statusmodelle fest, die als einzige gültige Quelle gelten. Der häufigste Fehler ist, dass dasselbe Konzept später drei leicht verschiedene Umsetzungen hat. Die Lösung sind weniger, stärker geregelte Bausteine mit klarer Eigentümerschaft statt vieler Beinahe-Duplikate.
  • Glossar und Disambiguierung. Ein Begriff wie „Kunde” oder „aktiver Vertrag” bedeutet in verschiedenen Abteilungen oft Verschiedenes. Halte diese Mehrdeutigkeiten früh schriftlich fest — das ist später dein wichtigster Schutz gegen Fehlkonfiguration.
  • Konfigurationsstandards festlegen. Namenskonventionen, wann ein eigenes Feld erlaubt ist versus ein Standardfeld zu nutzen ist, wann ein Workflow versus ein berechnetes Feld, wann eine Erweiterung versus eine Konfiguration. Diese Standards verhindern, dass alle ihren eigenen Stil bauen.
  • Governance vereinbaren. Wer darf was konfigurieren? Welche Änderungen brauchen ein Review? Der Artikel betont: Governance ohne Durchsetzung zerfällt rasch zurück zum Problem der vielen Kandidaten. Die Durchsetzung muss durch das Werkzeug selbst (Berechtigungen, Vorlagen), durch Review-Prozesse und durch ein klares Mandat erfolgen.

Ergebnis dieser Phase: nicht eine fertige Konfiguration, sondern ein Rahmen, in dem es zu jeder fachlichen Frage möglichst nur eine geregelte Antwort gibt.

Phase 2 — Sources of Truth aufbauen (Solution Design & Referenzen)

Hier entsteht die Referenzschicht, auf die sich das ganze Projektteam beim Konfigurieren bezieht. In absteigender Verbindlichkeit:

  • Standardfunktionen zuerst (analog zum Semantic Layer). Die wichtigste Regel der gesamten Einführung: Eine Anforderung wird zuerst gegen die Standardfunktionen der Plattform geprüft. Custom-Konfiguration ist der Fallback, der erst greift, wenn nachweislich keine Standardabdeckung existiert. Genau wie der Semantic Layer im Artikel der verpflichtende Standardpfad ist und rohes SQL nur der Fallback. Diese Reihenfolge strukturell zu verankern, ist der größte Hebel gegen Wildwuchs.
  • Lösungsmuster-Katalog. Wiederkehrende Anforderungen (Genehmigungsworkflows, Nummernkreise, Mehrwährung, Berechtigungsschnitte) werden einmal sauber gelöst und als wiederverwendbares Muster dokumentiert, statt in jedem Modul neu erfunden zu werden.
  • Konfigurationsdokumentation als erstklassiges Produkt. Jede nicht-triviale Konfigurationsentscheidung wird mit ihrem fachlichen Grund dokumentiert — nicht nur das Was, sondern das Warum. Der Artikel rät, die Dokumentation generieren zu lassen, die Definition aber von einem Menschen verantworten zu lassen. Übertragen: Routinedokumentation darfst du beschleunigen, die fachliche Definition gehört der benannten verantwortlichen Person.
  • Geschäftskontext einbeziehen. Die Schicht, die die meisten Teams überspringen. Wer den Geschäftshintergrund nicht versteht, baut, was die Key User gesagt haben, nicht, was sie gemeint haben. Roadmap, Entscheidungsprotokolle und die Frage „warum wird das gerade jetzt gebraucht” gehören ins Projektwissen.

Phase 3 — Konfigurieren mit Leitplanken (Build)

Erst jetzt wird gebaut — innerhalb des in Phase 1 und 2 geschaffenen Rahmens.

  • Iterativ in kurzen Schleifen. Konfigurieren, mit Key Usern gegenprüfen, anpassen. Jede Schleife endet mit einer Beobachtung, nicht mit einer Annahme.
  • Adversariales Review. Der Artikel beschreibt einen Review, der alle zugrunde liegenden Annahmen aggressiv hinterfragt, und beziffert den Effekt (etwa 6 % mehr Genauigkeit, zum Preis von mehr Aufwand). Übertragen: Jede nicht-triviale Konfiguration sollte von einer zweiten Person mit der Haltung „warum ist das falsch?” geprüft werden, bevor sie als fertig gilt. Keine Selbstzertifizierung.
  • Provenienz sichtbar machen. Im Artikel trägt jede Antwort einen Footer mit Quelle, Frische und Eigentümer. Übertragen: Jede Konfiguration trägt nachvollziehbar, auf welcher Anforderung sie beruht, wer sie verantwortet und wann sie zuletzt geprüft wurde. Das macht die Lösung nicht automatisch korrekter, aber es macht Vertrauen überprüfbar.

Phase 4 — Validierung & Go-Live

  • Testfälle gegen einen fixen Stand verankern. Der Artikel warnt, dass ein Test gegen Live-Daten in dem Moment veraltet, in dem sich die Zahl bewegt. Übertragen: Akzeptanztests gegen einen definierten Datenstand und definierte Szenarien schreiben, nicht gegen flüchtige Produktivdaten.
  • Pro Domäne freigeben. Eine Domäne geht erst live, wenn ihre Testfälle einen vereinbarten Schwellenwert erreichen. Das erzwingt Korrekturen, bevor die Anwender die Fehler sehen.
  • Den stillen Fehler fürchten. Der gefährlichste Fehlermodus ist der, bei dem ein Ergebnis falsch ist, aber plausibel aussieht und ohne Einwand verwendet wird. Gegenmaßnahmen: Provenienz, ausdrückliche Freigabe bei allem, was Entscheidungen auf Leitungsebene beeinflusst, und tägliche Plausibilisierung der wichtigsten Kennzahlen gegen eine abgesegnete Referenz.

Wartung nach Go-Live: der Teil, den fast alle unterschätzen

Der eindrücklichste Befund des Artikels: Die Offline-Genauigkeit driftete innerhalb eines Monats von etwa 95 % auf etwa 65 %, weil die Dokumentation nicht mit dem sich täglich ändernden Modell mitgepflegt wurde. Erst als Modelländerung und Doku-Änderung im selben Schritt erzwungen wurden, stabilisierte sich das.

Übertragen auf die ERP-Einführung ist das die wichtigste Botschaft für die Zeit nach Go-Live: Eine Low-Code-Konfiguration ist kein abgeschlossenes Bauwerk, sondern ein lebendes System, das verrottet, wenn niemand es pflegt. Konkret bedeutet das, Konfigurationsänderung und Dokumentationsänderung organisatorisch zu koppeln — wer eine Konfiguration ändert, aktualisiert im selben Vorgang ihre Beschreibung. Und es bedeutet, ein „das war die falsche Einstellung”-Feedback aus dem Betrieb systematisch einzusammeln und in die Referenzdokumentation zurückzuspeisen, statt es im Support-Ticket versanden zu lassen.

Was nicht funktioniert — die negativen Erkenntnisse

Der Artikel dokumentiert bewusst, was nicht geklappt hat, weil negative Ergebnisse billig zu protokollieren sind und verhindern, dass die nächste Person denselben Fehler macht. Drei davon übertragen sich direkt:

Erstens: Mehr Zugriff löst kein Strukturproblem. Im Artikel veränderte voller Lesezugriff auf Tausende früherer Queries die Genauigkeit um weniger als einen Prozentpunkt — die Information war da, wurde gesehen und trotzdem nicht genutzt. Der Engpass war Struktur, nicht Zugang. Übertragen: Dem Team Zugriff auf hundert frühere Projektkonfigurationen zu geben, hilft wenig, wenn es keine Struktur gibt, die eine Anforderung auf das richtige Muster abbildet. Kuratierte, durchsuchbare Muster schlagen rohen Zugriff.

Zweitens: Automatisch generierte Definitionen kodieren genau die Mehrdeutigkeit, die man beseitigen wollte. Übertragen: Konfiguration aus Altsystem-Mustern automatisch ableiten zu lassen erzeugt plausibel aussehende, aber semantisch verwaschene Lösungen. Die fachliche Definition gehört in menschliche Hand.

Drittens: Dokumentationsverfeinerung hat einen Punkt der negativen Erträge — irgendwann werden die Dokumente länger, nicht besser. Übertragen: Ein Konfigurationskonzept totzudokumentieren bindet Aufwand, ohne die Einführung sicherer zu machen.

Erste Schritte (wenn du bei null anfängst)

Analog zum Schluss des Artikels: Du brauchst nicht den ganzen Apparat von Tag eins. Eine Handvoll kanonischer Bausteine pro Kerndomäne, ein knapper Satz Akzeptanz-Testfälle und ein schlankes „Standard zuerst, Custom nur als begründeter Fallback”-Prinzip erfassen den größten Teil des Nutzens. Alles andere baust du auf, sobald dieses Fundament steht.

Und richte das Vorgehen an einigen Leitfragen aus, die der Artikel ebenfalls stellt: Wie wichtig ist Korrektheit heute versus später (die Plattform entwickelt sich weiter)? Wie technisch ist die Zielgruppe der Konfiguration — Key User, die einen Fehler erkennen, oder Endanwender ohne Modellverständnis? Wie viel zusätzlicher Aufwand für Review und Validierung rechtfertigt sich angesichts des Risikos? Und wie weit reicht der Zugriff, den du dem Kundenteam auf die Konfiguration gibst — ein zentral verantworteter Stand oder viele eingegrenzte?

Der größte Hebel bleibt, wie im Artikel, das Angehen aller drei Fehlermodi: Mehrdeutigkeit zu einer geregelten Antwort zusammenführen, diese Antwort leicht auffindbar machen, und kennzeichnen, wenn sie veraltet ist.

Apparat: Gastbeitrag von Philipp Schrimpf. Der Text überträgt die Beobachtungen aus How Anthropic enables self-service data analytics with Claude (claude.com (opens in new tab), 2026) auf die Einführung einer hochkonfigurierbaren Low-Code-ERP-Plattform. Der agentische Vier-Schichten-Stack (Data Foundations → Sources of Truth → Skills → Validation), die drei Fehlermodi (Entitäts-Mehrdeutigkeit, Veralterung, Retrieval-Fehler), der Semantic-Layer-first-Grundsatz und der Befund, dass automatisch generierte Definitionen den kuratierten unterlegen sind, stammen aus diesem Artikel. Die beiden zitierten Kennzahlen — der Drift von rund 95 % auf rund 65 % Genauigkeit binnen eines Monats und der Genauigkeitsgewinn von etwa 6 % durch adversariales Review — sind ebenfalls dort berichtet. Die Übertragung auf das ERP-Einführungsprojekt ist die eigene Arbeit des Autors.