Jak středně velký výrobce opustil SAP — a rozdíl ve funkcionalitě doplnil vibe codingem s Claude Code

Český výrobce autodílů s 200 zaměstnanci platil za SAP ECC 380 tis. € ročně. S blížícím se koncem podpory v roce 2027 a nabídkami na přechod na S/4HANA přesahujícími 1,2 mil. € firma přešla na Odoo za 14 týdnů. 23 zákaznických SAP transakcí bez ekvivalentu v Odoo bylo vyvinuto vibe codingem pomocí Claude Code na Odoo.sh — navigováno znalostním grafem v Neo4j, který zmapoval všechny závislosti dříve, než byl napsán jediný řádek kódu. Roční náklady na ERP klesly o 84 %.

Klient

Středně velký výrobce autodílů se sídlem poblíž Mladé Boleslavi — tři výrobní závody, dva sklady, 200 zaměstnanců. Firma vyrábí lisované a obráběné kovové komponenty pro dodavatele Tier 1 v automobilovém průmyslu po celé střední Evropě. Roční tržby přibližně 45 mil. €.

Společnost provozovala SAP ECC 6.0 od roku 2012, implementovaný regionálním SAP partnerem za 14 měsíců. V průběhu let interní IT tým (dva lidé) a externí konzultanti vytvořili 23 zákaznických ABAP transakcí pokrývajících workflow kontroly kvality, hodnotící karty dodavatelů, mezizávodní fakturaci mezi třemi závody a zakázkové rozšíření MRP pro plánování povrchových úprav.

Finance, prodej, nákup, výroba, sklad i personalistika — vše běželo v SAP. Každý podnikový proces se ho dotýkal. Myšlenka na odchod se zdála nemožná — dokud faktury neudělaly setrvání nemožným.

Problém: Propast roku 2027

SAP oznámil konec podpory pro ECC 6.0 v prosinci 2027. Rozšířená údržba je dostupná — za příplatek 22 % — ale s omezeným rozsahem: pouze bezpečnostní záplaty, žádné funkční aktualizace, žádná podpora nových integrací. Zpráva od SAP byla jasná: přejděte na S/4HANA, nebo si poraďte sami.

Klient si vyžádal nabídky na přechod na S/4HANA od dvou SAP partnerů. Čísla:

• 1,2 mil. € náklady na migraci (doporučena reimplementace na zelené louce kvůli objemu zákaznického kódu)
• 18 měsíců odhadovaný harmonogram — přičemž průmyslová data ukazují, že 60 % projektů S/4HANA překročí svůj plán
• 420 tis. €/rok odhadované celkové náklady na vlastnictví po migraci (předplatné RISE with SAP + partnerská podpora)
• Všech 23 zákaznických ABAP transakcí by muselo být přepsáno pro nový datový model S/4HANA — při sazbách ABAP vývojářů 800–1 200 €/den

Současný účet za SAP byl přitom už tak bolestivý: 380 tis. € ročně napříč licencemi (3 400 €/uživatel pro 120 jmenovaných uživatelů), roční údržbou (22 % z licenčních poplatků), jedním Basis administrátorem na částečný úvazek a dvěma ABAP vývojáři na retaineru pro údržbu zákaznických transakcí.

Existovalo i skryté riziko. Firemní WMS a CRM na bázi Salesforce přistupovaly k datům SAP přes RFC rozhraní. Podle pravidel nepřímého přístupu SAP mohla tato expozice vyvolat další licenční nároky. Diageo se s tímto poučilo tvrdě — 54,5 mil. £ — a AB InBev čelil sporu o 600 mil. $ za podobné integrace.

Shrnutí finančního ředitele: “Platíme skoro půl milionu ročně za systém, kterému brzy skončí podpora, a upgrade stojí víc, než jsme zaplatili za původní implementaci.”

Krok 1: Zmapování všech závislostí před napsáním jediného řádku kódu

Nejnebezpečnější částí jakékoli migrace ERP nejsou data — je to neviditelná síť zákaznické logiky, které nikdo plně nerozumí. Vlastní interní znalostní graf SAP zahrnuje 452 000 ABAP tabulek a 7,3 milionu polí jen pro S/4HANA. 23 zákaznických transakcí našeho klienta bylo do této struktury vpleteno způsoby, které žádný člověk nedokázal zmapovat z paměti.

Před jakýmkoli zásahem do Odoo jsme vytvořili podnikový znalostní graf v Neo4j. Z každého zákaznického ABAP programu jsme extrahovali metadata: které SAP tabulky čte, do kterých zapisuje, jaká RFC rozhraní vystavuje, které další zákaznické transakce ho volají a které uživatelské role na něm závisejí.

Výsledek: 452 uzlů (tabulky, transakce, rozhraní, role) propojených 1 800 hranami (čte, zapisuje, volá, závisí na). Graf okamžitě odhalil tři kategorie:

• Mrtvý kód (7 transakcí) — žádní volající, žádné nedávné záznamy o spuštění. Zastaralé programy, které byly nahrazeny, ale nikdy nebyly smazány. Bezpečné k odstranění.
• Nativní ekvivalent v Odoo (4 transakce) — workflow nabídek, výpočet objednacích bodů, správa dovolených, bankovní odsouhlasení. Standardní moduly Odoo je pokrývají 1:1. Žádný zákaznický kód není potřeba.
• Vyžaduje vibe coding (12 transakcí) — workflow kontroly kvality, hodnotící karty dodavatelů, mezizávodní fakturace, rozšíření MRP pro povrchové úpravy, EDI import, optimalizace vychystávacích tras. Tyto neměly v Odoo ekvivalent a vyžadovaly zakázkové moduly.

Graf také odhalil řetězce závislostí, které diktovaly pořadí vývoje. Modul mezizávodní fakturace (ZFI_INTER) závisel na modulu mezizávodních přesunů (ZPP_INTER), který závisel na rozšíření MRP pro povrchové úpravy (ZPP_SURF). Sestavte je v nesprávném pořadí a nemůžete nic otestovat. Graf nám dal přesné topologické řazení.

Krok 2: Základní migrace — týdny 1 až 8

Se znalostním grafem ukazujícím přesně, co standardní Odoo zvládne, migrace jádra následovala ověřený postup. Nasadili jsme Odoo 18 Enterprise na Odoo.sh a konfigurovali moduly podle obchodní kritičnosti:

1. Týdny 1–2: Finance — účtový rozvrh namapovaný ze SAP FI/CO, počáteční zůstatky nahrány, bankovní napojení připojeno. Česká lokalizace (DPH, Intrastat, kontrolní hlášení) nakonfigurována přes modul l10n_cz v Odoo.
2. Týdny 3–4: Nákup + Sklad — 4 200 materiálových kmenových záznamů migrováno ze SAP MARA/MARC. Záznamy dodavatelů z LFA1. Historie nákupních objednávek (3 roky) nahrána pro analytiku dodavatelů. Multi-skladová struktura odpovídající třem závodům.
3. Týdny 5–6: Výroba (MRP) — kusovníky ze SAP CS, technologické postupy z PP. Pracoviště namapována na pracoviště v Odoo. Historie výrobních příkazů pro kalkulační základny.
4. Týdny 7–8: Prodej + CRM + HR — kmenová data odběratelů z KNA1, otevřené prodejní objednávky migrovány. Záznamy zaměstnanců a zůstatky dovolených převedeny. Staré CRM na Salesforce bylo ukončeno — jeho data sloučena do Odoo CRM, čímž se zcela eliminovalo riziko nepřímého přístupu.

Extrakce dat využila SAP IDocs a RFC, transformaci zajistily Python ETL skripty, nahrání proběhlo přes modul base_import v Odoo. Migrovali jsme 5 let transakční historie — dostatečně pro analýzu trendů bez přenášení 14 let zbytečné zátěže.

V celé této fázi byly klíčové staging větve na Odoo.sh. Každé nahrání dat bylo nejprve otestováno na staging prostředí naklonovaném z produkční databáze. Když české mapování DPH mělo okrajové případy s přenesenou daňovou povinností, zachytili jsme to na stagingu — ne po spuštění do ostrého provozu.

Krok 3: Vibe coding chybějící funkcionality — týdny 9 až 14

Zde se projekt odchýlil od tradiční implementace Odoo. Měli jsme 12 zákaznických SAP transakcí bez ekvivalentu v Odoo. V konvenčním projektu by každá vyžadovala funkční specifikaci, nabídku vývojáře, code review a týdny ladění. Při sazbách 150–200 €/hodinu za seniorní Odoo vývojáře by klient čelil dalším 200 tis. € a 4–6 měsícům práce.

Místo toho jsme je vytvořili vibe codingem pomocí Claude Code na platformě Odoo.sh.

Pracovní postup pro každý zakázkový modul:

1. Dotaz do znalostního grafu — extrakce přesných vstupů, výstupů, obchodních pravidel a navazujících závislostí pro nahrazovanou SAP transakci
2. Sestavení promptu pro Claude Code — včetně kontextu závislostí, konvencí Odoo modelů a očekávaného chování popsaného v obchodních termínech
3. Claude Code vygeneruje modul — modely, pohledy, bezpečnostní pravidla a manifest v jednom průchodu. Protože je Odoo open source, Claude již “prostudoval” 40 000+ komunitních modulů a nativně rozumí vzorům dědičnosti frameworku
4. Push do feature větve na Odoo.sh — automatické nasazení vytvoří živé vývojové prostředí během minut
5. Testování s reálnými daty na stagingu — staging větve na Odoo.sh klonují produkční databázi, takže testování probíhá proti skutečným nákupním objednávkám, kusovníkům a účetním zápisům
6. Iterace nebo nasazení — většina modulů potřebovala 2–3 upřesnění promptu před úspěšným akceptačním testováním

Příklad: Modul hodnotící karty dodavatelů

SAP verze (ZQM_SCORE) byla 1 800řádkový ABAP program čtoucí z EKKO, EKPO, QALS a MARA pro výpočet váženého skóre ve čtyřech dimenzích: spolehlivost dodávek, míra kvality, cenová odchylka a reaktivita. Generoval měsíční PDF report a označoval dodavatele pod prahem pro přehodnocení.

Znalostní graf nám řekl: ZQM_SCORE čte z nákupních objednávek a kontrolních šarží kvality, je volán modulem ZQM_CERT (sledování certifikátů) a vstupuje do čtvrtletního workflow přehodnocení dodavatelů. Žádná další zákaznická transakce nezávisí na jeho výstupním formátu — což znamenalo volnost vylepšit uživatelské rozhraní.

Claude Code vytvořil kompletní modul Odoo v jedné relaci: supplier_scorecard s počítanými poli na res.partner, hodnotícím enginem spouštěným při validaci příchozí zásilky, dashboardem s drill-downem podle dodavatele a dimenze a automatickými e-mailovými upozorněními nahrazujícími statické PDF.

Čas: 4 hodiny od prvního promptu po nasazení na staging — oproti 3týdennímu odhadu od tradičního Odoo partnera.

Kontrast v rychlosti vývoje byl markantní. Systém transportních požadavků SAP — SE80, SE09, STMS, schválení change boardem, víkendová okna pro nasazení — znamenal 3–6týdenní cyklus pro jakoukoli zákaznickou změnu. S Odoo.sh git push spustí nasazení během minut. Claude Code spolu s Odoo.sh zkomprimovaly celou fázi zákaznického vývoje z odhadovaných 6 měsíců na 6 týdnů.

Krok 4: Znalostní graf jako testovací orákulum

Graf závislostí nejen řídil vývoj — stal se frameworkem pro akceptační testování. Pro každý uzel v grafu označený “vyžaduje vibe coding” jsme definovali testovací kontrakt: při stejných vstupech, které spotřebovávala SAP transakce, produkuje náhrada v Odoo ekvivalentní výstupy?

Vzorové páry vstupů a výstupů jsme exportovali ze SAP pro každou zákaznickou transakci během fáze extrakce. Ty se staly referenčními testovacími daty. Hrany znalostního grafu nám řekly pořadí testování: nelze testovat mezizávodní fakturaci (ZFI_INTER), dokud mezizávodní přesuny (ZPP_INTER) neprojdou, a to vyžaduje, aby MRP pro povrchové úpravy (ZPP_SURF) byl zelený.

Traverzování grafu v obráceném topologickém pořadí nám dalo systematický akceptační checklist:

1. Nejprve testovat koncové uzly (bez navazujících závislostí) — tisk paletových štítků, EDI import, optimalizace vychystávacích tras
2. Testovat moduly uprostřed řetězce jakmile jsou jejich závislosti zelené — hodnotící karty dodavatelů, výpočet provizí
3. Naposledy testovat silně provázaný řetězec — povrchové úpravy → mezizávodní přesuny → mezizávodní fakturace → kalkulace výrobků

Čtyři z 12 modulů neprošly prvním akceptačním testem. V každém případě šlo o okrajový případ obchodního pravidla — ne o strukturální problém. Hodnotící karta dodavatelů neřešila částečné dodávky stejně jako SAP. Modul mezizávodní fakturace potřeboval zaokrouhlovací pravidlo specifické pro českou daňovou legislativu. Claude Code opravil každý během jedné iterace promptu a Odoo.sh nasadilo opravu za méně než tři minuty.

Na konci 14. týdne všech 12 zakázkových modulů prošlo akceptačním testováním proti testovacím kontraktům odvozeným ze SAP. Znalostní graf měl nula červených uzlů.

Výsledky

Za pět let by setrvání na SAP ECC s rozšířenou údržbou stálo 1,9 mil. €. Cesta přechodu na S/4HANA činí celkem 3,3 mil. €. Cesta přes Odoo — včetně kompletní migrace, všech zakázkových modulů vytvořených vibe codingem a pěti let předplatného Odoo Enterprise — vychází na 312 tis. €. To je úspora 84 % oproti stávajícímu stavu a 91 % oproti S/4HANA.

Klient využil úspory prvního roku (318 tis. €) na financování projektu predikce poptávky nad rámec Odoo — něco, co nikdy nebylo ekonomicky životaschopné, dokud SAP spotřebovával celý rozpočet na IT.