Kolik stojí napojení webu na ERP

Napojení e-shopu na ERP je nejčastěji podceněná položka celého projektu. Rozdíl mezi jednosměrným stahováním skladu za 9 900 a plnou obousměrnou synchronizací za 60 000 je přitom v datech, ne v marketingovém názvu.

Co přesně znamená napojení na ERP a proč se cena tolik liší

Napojení není jedna služba. Je to škála od stažení skladových zásob jednou za hodinu až po systém, kde objednávka vzniklá na webu doputuje do skladu, vygeneruje fakturu, vrátí zpět číslo zásilky a upraví dostupnost všech variant. Každá další datová věta znamená více práce, více testování a více míst, kde se to může rozbít.

Cena se odvíjí od tří věcí: kolik entit se přenáší, jakým směrem tečou data a jestli má ERP použitelné API. Pohoda přes mServer se chová jinak než Money S3 přes XML soubory a úplně jinak než Helios nebo Abra s vlastním REST rozhraním. U starších systémů se často doplácí za obcházení limitů, ne za samotnou logiku.

Praktický dopad: klient s tisícem položek a jedním skladem se dostane na jiné číslo než velkoobchod s variantami, rezervacemi a třemi expedičními místy. Proto nikdy neposílám paušál bez toho, abych viděl strukturu dat a jeden reálný export.

Jednosměrná synchronizace: nejlevnější cesta, která často stačí

Jednosměrná synchronizace znamená, že ERP je jediný pán dat a web je jen výkladní skříň. Stahují se produkty, ceny, dostupnost, případně kategorie. Web nic nezapisuje zpět, objednávky se řeší mailem nebo ručním přepisem. U firem, které mají pět až patnáct objednávek denně, tohle drží roky bez problému.

Nasazení trvá typicky tři až pět dní práce, cena se pohybuje od 9 900 do 24 000 podle počtu polí a stavu API. Synchronizace běží po cronu, obvykle každých patnáct až šedesát minut. Kritické je nastavit chování při výpadku: co se stane, když ERP nedopoví, jestli web ukáže poslední známý stav nebo produkty schová.

Nejčastější chyba je stahovat celý katalog při každém běhu. U dvou tisíc položek to znamená zbytečnou zátěž. Řeším to inkrementálně přes časovou značku poslední změny, takže se přenáší jen to, co se opravdu hnulo.

Obousměrná synchronizace: kdy se vyplatí platit trojnásobek

Obousměrná synchronizace posílá objednávky z webu do ERP a vrací zpět stavy, čísla dokladů a tracking. Zní to jako drobnost navíc, ale přidává celou vrstvu spolehlivosti. Objednávka nesmí zmizet, nesmí se založit dvakrát a musí se dát ručně přehrát, když integrace v noci spadne.

Proto do každé obousměrné integrace stavím frontu s opakováním, log každého volání a stránku, kde je vidět, co prošlo a co selhalo. Tohle je zhruba polovina rozpočtu. Bez toho se první reklamace řeší dvě hodiny hledáním v e-mailech, což je dražší než ta vrstva stála.

Vyplatí se od okamžiku, kdy ruční přepis zabere víc než hodinu denně. Při dvaceti objednávkách denně a třech minutách na přepis je to hodina práce, tedy zhruba 6 000 měsíčně. Integrace za 45 000 se vrátí za sedm měsíců a dál už jen šetří.

• Objednávka se zakládá v ERP do jedné minuty od odeslání
• Stav objednávky a číslo zásilky se vrací zpět na web
• Fronta s opakováním pokrývá výpadky ERP i internetu
• Log volání s možností ručně přehrát konkrétní objednávku
• Ochrana proti duplicitám přes idempotenční klíč
• Notifikace na mail, když selže víc než tři pokusy po sobě

Orientační ceník integrací podle rozsahu

Čísla níž vychází z projektů, které jsem stavěl pro české e-shopy s katalogem od dvou set do zhruba osmi tisíc položek. Jde o jednorázovou implementaci včetně testování na kopii dat a týdne dohledu po spuštění.

K jednorázové ceně počítejte provoz. Serverová část synchronizace stojí 990 měsíčně v rámci Provozu, u větších objemů s hlídáním chybovosti a rychlou reakcí dává smysl Péče za 2 990 měsíčně. To není licence za software, ale za to, že když se v úterý ve tři ráno rozbije API, ráno už je to opravené.

Co cenu zvedne nejrychleji a jak se tomu vyhnout

Největší násobič ceny nejsou objednávky, ale varianty a párování. Když má produkt tři velikosti a čtyři barvy, je to dvanáct skladových karet, které se musí spárovat s webem. Pokud v ERP nemají stabilní identifikátor, začíná párování podle názvu a to je zdroj chyb na roky dopředu.

Druhý násobič jsou ceníky. Velkoobchod s individuálními cenami na zákazníka znamená, že se cena nedá stáhnout jednou pro všechny. Buď se táhnou celé cenové hladiny, nebo se cena dotahuje živě při přihlášení. Živý dotaz je pohodlnější, ale klade nároky na rychlost odpovědi ERP.

Třetí věc je stav dat. Duplicitní karty, prázdné EAN kódy, produkty bez kategorie. Čištění dat před integrací zabere den až tři a účtuje se zvlášť. Vyplatí se to udělat před startem, protože po spuštění už se čistí za provozu a to je vždycky dráž.

• Stabilní kód nebo EAN u každé varianty, nikdy párování podle názvu
• Rozhodnout dopředu, kdo je pán ceny: web nebo ERP
• Vyjasnit chování rezervací, aby se sklad nepodtekl
• Připravit testovací kopii dat, ne ostrý sklad
• Určit jednu osobu, která rozhoduje o struktuře katalogu

Jak probíhá nasazení krok za krokem

Začínám auditem dat. Dostanu export z ERP a dokumentaci API, projdu strukturu a napíšu mapu polí. Z toho vzniká pevná nabídka, ne odhad. Tenhle krok trvá jeden až dva dny a u větších projektů ho účtuji zvlášť, protože výstupem je použitelný dokument i v případě, že si klient integraci nechá udělat jinde.

Pak stavím synchronizaci proti testovací kopii. Nikdy proti ostrému skladu. Následuje týden souběhu, kdy běží integrace i ruční proces vedle sebe a porovnávají se výsledky. Rozdíly se ladí, dokud nejsou tři dny po sobě čisté.

Po ostrém spuštění nechávám sedm dní zvýšeného dohledu. Kontroluji log každé ráno a hlásím, co se dělo. Většina problémů se ukáže právě v prvním týdnu, typicky na produktu, který se nikomu nezdál jako výjimka, ale byl.

Kdy integraci nedělat a co udělat místo ní

Pod deset objednávek denně se plná obousměrná integrace většinou nevyplatí. Ruční přepis zabere pár minut a peníze jsou lépe utracené za měření a kampaně. Doporučuji jednosměrný sklad, aby web neprodával neexistující zboží, a zbytek nechat na člověku.

Nedělat ji také ve chvíli, kdy firma zrovna mění ERP. Integrace na systém, který za čtvrt roku odejde, je vyhozených padesát tisíc. Lepší je počkat a mezitím vyřešit rychlost webu a konverzní cestu.

A neinvestovat do ní, když je problém jinde. Pokud web nemá návštěvnost, sebedokonalejší sklad ji nevyrobí. V takovém případě dává větší smysl začít měřením za 6 900 a zjistit, kde se objednávky ztrácí, než automatizovat proces, kterým skoro nic neteče.

Časté otázky

Zvládne integraci můj současný ERP systém?

Pohoda, Money S3 a S5, Abra, Helios i Vario mají použitelnou cestu ven, jen každý jinou. Pohoda přes mServer, Money přes XML, Abra a Helios přes REST. U starších verzí bez API se dá číst databáze přímo nebo si vyměňovat soubory. Vždycky si nejdřív vyžádám ukázkový export a podle něj řeknu, jestli to jde a za kolik.

Jak často se sklad synchronizuje?

Standardně každých patnáct minut, u zboží s rychlým obratem každých pět. Kratší interval než minuta nemá smysl, protože ERP většinou neodpoví dost rychle a jen se zvyšuje zátěž. Pokud je potřeba přesný stav v okamžiku objednávky, řeším to živou kontrolou dostupnosti až v košíku, ne častějším stahováním celého katalogu.

Co se stane, když ERP vypadne?

Web běží dál na posledních známých datech a objednávky se ukládají do fronty. Jakmile se ERP vrátí, fronta se automaticky přehraje ve správném pořadí. Když selže víc než tři pokusy po sobě, přijde mi upozornění na mail. Zákazník nic nepozná, jen se doklad v ERP objeví s pár minutami zpoždění.