Wie ein mittelständischer Hersteller SAP ablöste — und die Funktionslücke mit Claude Code per Vibe Coding schloss

Ein tschechischer Automobilzulieferer mit 200 Mitarbeitenden zahlte 380.000 € pro Jahr für SAP ECC. Angesichts des nahenden Wartungsendes 2027 und S/4HANA-Angeboten von über 1,2 Mio. € migrierte das Unternehmen in 14 Wochen zu Odoo. Die 23 kundenspezifischen SAP-Transaktionen ohne Odoo-Äquivalent wurden per Vibe Coding mit Claude Code auf Odoo.sh entwickelt — gesteuert durch einen Neo4j-Wissensgraphen, der jede Abhängigkeit erfasste, bevor eine einzige Codezeile geschrieben wurde. Die jährlichen ERP-Kosten sanken um 84 %.

Der Kunde

Ein mittelständischer Automobilzulieferer mit Sitz bei Mladá Boleslav, Tschechien — drei Produktionswerke, zwei Lager, 200 Beschäftigte. Das Unternehmen fertigt Stanz- und Frästeile aus Metall für Tier-1-Zulieferer der Automobilindustrie in ganz Mitteleuropa. Jahresumsatz rund 45 Mio. €.

Das Unternehmen betrieb SAP ECC 6.0 seit 2012, eingeführt von einem regionalen SAP-Partner in 14 Monaten. Im Laufe der Jahre hatten das interne IT-Team (zwei Personen) und externe Berater 23 kundenspezifische ABAP-Transaktionen entwickelt: Qualitäts-Gate-Workflows, Lieferantenbewertungen, Intercompany-Abrechnung zwischen den drei Werken und eine MRP-Erweiterung für die Oberflächenbehandlungsplanung.

Finanzen, Vertrieb, Einkauf, Fertigung, Lager und Personalwesen — alles lief in SAP. Jeder Geschäftsprozess war davon betroffen. Der Gedanke an einen Wechsel schien unmöglich — bis die Rechnungen das Bleiben unmöglich machten.

Das Problem: Die Klippe 2027

SAP kündigte das Ende der regulären Wartung für ECC 6.0 im Dezember 2027 an. Erweiterte Wartung ist verfügbar — gegen einen Aufpreis von 22 % — jedoch mit eingeschränktem Umfang: nur Sicherheitspatches, keine funktionalen Updates, keine Unterstützung neuer Integrationen. Die Botschaft von SAP war klar: Migrieren Sie zu S/4HANA oder finden Sie Ihren eigenen Weg.

Der Kunde holte S/4HANA-Migrationsangebote von zwei SAP-Partnern ein. Die Zahlen:

• 1,2 Mio. € Migrationskosten (Greenfield-Reimplementierung empfohlen aufgrund des Umfangs der Eigenentwicklungen)
• 18 Monate geschätzter Zeitrahmen — wobei Branchendaten zeigen, dass 60 % der S/4HANA-Projekte ihren Zeitplan überschreiten
• 420.000 €/Jahr prognostizierte Gesamtbetriebskosten nach der Migration (RISE with SAP-Abonnement + Partnerunterstützung)
• Alle 23 kundenspezifischen ABAP-Transaktionen müssten für das neue Datenmodell von S/4HANA umgeschrieben werden — bei ABAP-Entwicklerkosten von 800–1.200 €/Tag

Gleichzeitig war die aktuelle SAP-Rechnung bereits schmerzhaft: 380.000 € pro Jahr verteilt auf Lizenzen (3.400 €/Benutzer für 120 benannte Benutzer), jährliche Wartung (22 % der Lizenzgebühren), einen Teilzeit-Basis-Administrator und zwei ABAP-Entwickler auf Retainer für die Pflege der Eigenentwicklungen.

Es gab auch ein verborgenes Risiko. Das WMS des Unternehmens und ein Salesforce-basiertes CRM griffen über RFC-Schnittstellen auf SAP-Daten zu. Nach den Regeln für indirekten Zugriff von SAP könnte diese Exposition zusätzliche Lizenzforderungen auslösen. Diageo lernte diese Lektion auf die harte Tour — 54,5 Mio. £ — und AB InBev stand vor einem Streit über 600 Mio. $ wegen ähnlicher Integrationen.

Die Zusammenfassung des CFO: „Wir zahlen fast eine halbe Million pro Jahr für ein System, dessen Support bald ausläuft, und das Upgrade kostet mehr als die ursprüngliche Implementierung.“

Schritt 1: Jede Abhängigkeit erfassen, bevor eine Zeile Code geschrieben wird

Der gefährlichste Teil jeder ERP-Migration sind nicht die Daten — es ist das unsichtbare Netz kundenspezifischer Logik, das niemand vollständig überblickt. SAPs eigener interner Wissensgraph umfasst 452.000 ABAP-Tabellen und 7,3 Millionen Felder allein für S/4HANA. Die 23 Eigenentwicklungen unseres Kunden waren auf eine Weise in dieses Geflecht eingewoben, die kein Einzelner aus dem Gedächtnis rekonstruieren konnte.

Bevor wir Odoo überhaupt berührten, erstellten wir einen Unternehmens-Wissensgraphen in Neo4j. Wir extrahierten Metadaten aus jedem kundenspezifischen ABAP-Programm: welche SAP-Tabellen es liest, in welche es schreibt, welche RFC-Schnittstellen es bereitstellt, welche anderen Eigenentwicklungen es aufrufen und welche Benutzerrollen davon abhängen.

Das Ergebnis: 452 Knoten (Tabellen, Transaktionen, Schnittstellen, Rollen) verbunden durch 1.800 Beziehungen (liest, schreibt, ruft auf, hängt ab von). Der Graph offenbarte sofort drei Kategorien:

• Toter Code (7 Transaktionen) — keine aufrufenden Programme, keine aktuellen Ausführungsprotokolle. Veraltete Programme, die abgelöst, aber nie gelöscht wurden. Können sicher entfernt werden.
• Natives Odoo-Äquivalent (4 Transaktionen) — Angebots-Workflows, Bestellpunktberechnung, Urlaubsverwaltung, Bankabstimmung. Standard-Odoo-Module decken diese 1:1 ab. Kein kundenspezifischer Code nötig.
• Erfordert Vibe Coding (12 Transaktionen) — Qualitäts-Gate-Workflows, Lieferantenbewertungen, Intercompany-Abrechnung, MRP-Erweiterung für Oberflächenbehandlung, EDI-Import, Kommissionierrouten-Optimierung. Diese hatten kein Odoo-Äquivalent und erforderten kundenspezifische Module.

Der Graph deckte auch Abhängigkeitsketten auf, die die Reihenfolge der Entwicklung diktierten. Das Intercompany-Abrechnungsmodul (ZFI_INTER) hing vom Modul für Werksübergreifende Umlagerungen (ZPP_INTER) ab, welches wiederum von der MRP-Erweiterung für Oberflächenbehandlung (ZPP_SURF) abhing. Entwickelt man sie in der falschen Reihenfolge, lässt sich nichts testen. Der Graph lieferte die exakte topologische Sortierung.

Schritt 2: Kernmigration — Wochen 1 bis 8

Mit dem Wissensgraphen, der präzise zeigte, was Standard-Odoo abdecken kann, folgte die Kernmigration einem bewährten Pfad. Wir setzten Odoo 18 Enterprise auf Odoo.sh ein und konfigurierten die Module nach Geschäftskritikalität:

1. Wochen 1–2: Finanzen — Kontenplan aus SAP FI/CO übertragen, Eröffnungssalden geladen, Bankanbindungen eingerichtet. Tschechische Lokalisierung (MwSt., Intrastat, Kontrollmeldungen) über das l10n_cz-Modul in Odoo konfiguriert.
2. Wochen 3–4: Einkauf + Lager — 4.200 Materialstammsätze aus SAP MARA/MARC migriert. Lieferantenstammdaten aus LFA1. Bestellhistorie (3 Jahre) für Lieferantenanalysen geladen. Multi-Lager-Struktur entsprechend den drei Werken.
3. Wochen 5–6: Fertigung (MRP) — Stücklisten aus SAP CS, Arbeitspläne aus PP. Arbeitsplätze auf Odoo-Arbeitsplätze gemappt. Fertigungsauftragshistorie für Kalkulationsgrundlagen.
4. Wochen 7–8: Vertrieb + CRM + HR — Kundenstammdaten aus KNA1, offene Kundenaufträge migriert. Personalstammdaten und Urlaubssalden übertragen. Das alte Salesforce-CRM wurde abgeschaltet — seine Daten in Odoo CRM zusammengeführt, wodurch das Risiko des indirekten Zugriffs vollständig eliminiert wurde.

Die Datenextraktion nutzte SAP IDocs und RFC-Aufrufe, die Transformation erfolgte über Python-ETL-Skripte, das Laden über Odoos base_import-Modul. Wir migrierten 5 Jahre Transaktionshistorie — ausreichend für Trendanalysen, ohne 14 Jahre toten Ballast mitzuschleppen.

In dieser gesamten Phase waren die Staging-Branches von Odoo.sh entscheidend. Jeder Datenimport wurde zunächst in einer Staging-Umgebung getestet, die von der Produktionsdatenbank geklont wurde. Als das tschechische MwSt.-Mapping Sonderfälle bei der Umkehr der Steuerschuldnerschaft aufwies, fiel das im Staging auf — nicht nach dem Go-Live.

Schritt 3: Vibe Coding der Funktionslücke — Wochen 9 bis 14

Hier wich das Projekt von einer traditionellen Odoo-Implementierung ab. Wir hatten 12 kundenspezifische SAP-Transaktionen ohne Odoo-Äquivalent. In einem konventionellen Projekt hätte jede eine Fachspezifikation, ein Entwicklerangebot, ein Code-Review und wochenlange Abstimmung erfordert. Bei Stundensätzen von 150–200 € für Senior-Odoo-Entwickler blickte der Kunde auf weitere 200.000 €+ und 4–6 Monate.

Stattdessen entwickelten wir sie per Vibe Coding mit Claude Code auf Odoo.sh.

Der Workflow für jedes kundenspezifische Modul:

1. Wissensgraph abfragen — exakte Eingaben, Ausgaben, Geschäftsregeln und nachgelagerte Abhängigkeiten der zu ersetzenden SAP-Transaktion extrahieren
2. Prompt für Claude Code formulieren — einschließlich Abhängigkeitskontext, Odoo-Modellkonventionen und erwartetem Verhalten in Geschäftsbegriffen
3. Claude Code generiert das Modul — Modelle, Views, Sicherheitsregeln und Manifest in einem Durchlauf. Da Odoo Open Source ist, hat Claude bereits 40.000+ Community-Module „studiert“ und versteht die Vererbungsmuster des Frameworks nativ
4. Push in einen Feature-Branch auf Odoo.sh — automatisches Deployment erstellt eine Live-Entwicklungsumgebung in Minuten
5. Test mit Echtdaten im Staging — Staging-Branches auf Odoo.sh klonen die Produktionsdatenbank, sodass Tests gegen echte Bestellungen, Stücklisten und Buchungssätze laufen
6. Iterieren oder ausliefern — die meisten Module benötigten 2–3 Prompt-Verfeinerungen bis zur Akzeptanz

Beispiel: Modul Lieferantenbewertung

Die SAP-Version (ZQM_SCORE) war ein 1.800-zeiliges ABAP-Programm, das aus EKKO, EKPO, QALS und MARA las, um eine gewichtete Bewertung über vier Dimensionen zu berechnen: Lieferzuverlässigkeit, Qualitätsquote, Preisabweichung und Reaktionszeit. Es erzeugte einen monatlichen PDF-Bericht und kennzeichnete Lieferanten unterhalb des Schwellenwerts zur Neubewertung.

Der Wissensgraph verriet uns: ZQM_SCORE liest aus Bestellungen und Qualitätsprüflosen, wird von ZQM_CERT (Zertifikatsverfolgung) aufgerufen und fließt in den vierteljährlichen Lieferantenbewertungs-Workflow ein. Keine andere Eigenentwicklung hängt von seinem Ausgabeformat ab — was Freiheit für UX-Verbesserungen bedeutete.

Claude Code erzeugte ein vollständiges Odoo-Modul in einer Sitzung: supplier_scorecard mit berechneten Feldern auf res.partner, einer Bewertungslogik, die bei Wareneingangsvalidierung ausgelöst wird, einem Dashboard mit Drill-Down nach Lieferant und Dimension sowie automatischen E-Mail-Benachrichtigungen anstelle des statischen PDF.

Zeitaufwand: 4 Stunden vom ersten Prompt bis zum bereitgestellten Staging — gegenüber dem 3-Wochen-Angebot eines traditionellen Odoo-Partners.

Der Kontrast in der Entwicklungsgeschwindigkeit war deutlich. SAPs Transportauftragssystem — SE80, SE09, STMS, Change-Board-Freigabe, Wochenend-Deployment-Fenster — bedeutete einen 3- bis 6-wöchigen Zyklus für jede kundenspezifische Änderung. Mit Odoo.sh löst ein git push das Deployment in Minuten aus. Claude Code plus Odoo.sh komprimierten die gesamte kundenspezifische Entwicklungsphase von geschätzten 6 Monaten auf 6 Wochen.

Schritt 4: Der Wissensgraph als Test-Orakel

Der Abhängigkeitsgraph leitete nicht nur die Entwicklung — er wurde zum Abnahmetest-Framework. Für jeden Knoten im Graphen, der als „erfordert Vibe Coding“ markiert war, definierten wir einen Testvertrag: Produziert der Odoo-Ersatz bei denselben Eingaben, die die SAP-Transaktion verarbeitete, äquivalente Ausgaben?

Wir exportierten Beispiel-Ein-/Ausgabepaare aus SAP für jede Eigenentwicklung während der Extraktionsphase. Diese wurden zu referenziellen Testdaten. Die Beziehungen des Wissensgraphen gaben die Testreihenfolge vor: Die Intercompany-Abrechnung (ZFI_INTER) kann nicht getestet werden, bevor die werksübergreifende Umlagerung (ZPP_INTER) bestanden hat, und diese erfordert, dass die MRP-Erweiterung für Oberflächenbehandlung (ZPP_SURF) grün ist.

Das Traversieren des Graphen in umgekehrter topologischer Reihenfolge ergab eine systematische Abnahme-Checkliste:

1. Zuerst Blattknoten testen (keine nachgelagerten Abhängigkeiten) — Palettenetikettendruck, EDI-Import, Kommissionierrouten-Optimierung
2. Module in der Mitte der Kette testen, sobald ihre Abhängigkeiten grün sind — Lieferantenbewertungen, Provisionsberechnung
3. Zuletzt die eng verkettete Kette testen — Oberflächenbehandlung → werksübergreifende Umlagerung → Intercompany-Abrechnung → Produktkalkulation

Vier der 12 Module fielen beim ersten Abnahmetest durch. In jedem Fall handelte es sich um einen Randfall einer Geschäftsregel — kein strukturelles Problem. Die Lieferantenbewertung behandelte Teillieferungen nicht wie SAP. Das Intercompany-Abrechnungsmodul benötigte eine Rundungsregel speziell für das tschechische Steuerrecht. Claude Code korrigierte jeden Fehler innerhalb einer Prompt-Iteration, und Odoo.sh stellte die Korrektur in unter drei Minuten bereit.

Am Ende der 14. Woche bestanden alle 12 kundenspezifischen Module die Abnahmetests gegen ihre aus SAP abgeleiteten Testverträge. Der Wissensgraph hatte null rote Knoten.

Ergebnisse

Über fünf Jahre würde das Verbleiben auf SAP ECC mit erweiterter Wartung 1,9 Mio. € kosten. Der S/4HANA-Migrationspfad summiert sich auf 3,3 Mio. €. Der Odoo-Weg — einschließlich der vollständigen Migration, aller per Vibe Coding erstellten kundenspezifischen Module und fünf Jahre Odoo-Enterprise-Abonnement — kommt auf 312.000 €. Das entspricht einer Reduktion von 84 % gegenüber dem Status quo und 91 % gegenüber S/4HANA.

Der Kunde nutzte die Einsparungen des ersten Jahres (318.000 €) zur Finanzierung eines Bedarfsprognose-Projekts auf Basis von Odoo — etwas, das nie wirtschaftlich tragfähig war, solange SAP das gesamte IT-Budget verschlang.