Objednávky chodia, sklad zatiaľ drží krok a niekto ich po večeroch prepisuje do účtovníctva. Potom príde sezóna. E-shop predá tovar, ktorý fyzicky už nie je, doklady meškajú tri dni a pri reklamácii sa dohadujete, ktorý systém má pravdu. Chýbajúca e-shop ERP integrácia nič nestojí vo faktúre za softvér, zaplatíte ju hodinami, ktoré tím strávi opravovaním dát, a objednávkami, ktoré musíte stornovať zákazníkovi, ktorý už zaplatil.
Keď takýto projekt otvoríme, vidíme skoro vždy tie isté tri veci. Sklad sa prenáša raz za noc, takže e-shop celý deň predáva zo včerajších čísel. Produkty sa medzi systémami párujú podľa názvu namiesto kódu, takže variant „modrá, XL“ má v podnikovom systéme tri podoby a v jednej z nich sedí cena. A keď prenos zlyhá, nedozvie sa to nikto — chýba záznam aj upozornenie, takže chyba vypláva na povrch až na konci mesiaca pri uzávierke.
E-shop ERP integrácia je trvalé prepojenie e-shopu s podnikovým systémom (ERP, teda softvér, v ktorom firma vedie sklad, financie, doklady a objednávky), pri ktorom si obe strany podľa vopred dohodnutých pravidiel vymieňajú produkty, ceny, stavy zásob, objednávky a doklady. Súčasťou dohody je aj to, ktorý systém je pri každom údaji zdrojom pravdy, ktorým smerom údaj tečie, ako často sa prenáša a čo sa stane, keď sa hodnoty na oboch stranách rozídu.
Práve kvôli poslednej časti definície padajú integrácie až v prevádzke. Kým objednávok pribúda pomaly, nezhody niekto ručne vyrovná a nikomu neprekážajú. Pri náraste objemu sa ich vyrovnávanie stane dennou rutinou. V článku si prejdeme, ktoré dáta medzi systémami reálne putujú a akým smerom, ako často ich synchronizovať, čo robiť pri konflikte hodnôt, kde sa integrácie lámu najčastejšie a ako pripraviť projekt tak, aby sa to nezistilo až po spustení. Samotnú automatizáciu faktúr a exportov aj veľkoobchodné ceny a zákaznícke skupiny na WooCommerce sme rozobrali v samostatných článkoch — tu ideme o úroveň nižšie, do samotného toku dát.
Väčšina ponúk na integráciu opisuje výsledok: „prepojíme e-shop s vaším systémom“. Ako keby ste sľúbili, že dom bude mať strechu. Podstatné je, z čoho sa prepojenie skladá, lebo práve niektoré časti sa dajú vynechať — a na cene to vidno.
Prvá vrstva je dátový model — zoznam entít, ktoré si systémy vymieňajú, a mapovanie polí medzi nimi. Druhá je párovací kľúč, teda jednoznačný identifikátor, podľa ktorého sa produkt v e-shope spáruje s položkou v podnikovom systéme. Tretia je pravidlo, ktoré pre každé pole určuje smer a zdroj pravdy. Štvrtá je spôsob prenosu — či pôjde o hotový konektor, API alebo výmena súborov, a ako často sa dáta prenášajú. A piata, ktorá chýba najčastejšie, je ošetrenie chýb: čo sa má stať pri výpadku, pri neplatnom údaji, pri duplicite a pri opakovanom doručení tej istej správy.
Práve piata vrstva rozhoduje, či integrácia prežije prvý zlý týždeň. Bez nej vyzerá výpadok takto: v piatok večer sa preruší spojenie, cez víkend padne štyridsať objednávok, v pondelok ich je v podnikovom systéme sedemnásť a nikto vo firme nevie povedať, ktorých dvadsaťtri chýba. V ponuke sa táto vrstva škrtá najľahšie, lebo pri preberaní ju nevidno — testuje ju až prevádzka.
Toto rozhodnutie padne skôr ako ktorékoľvek iné a rozhoduje o cene projektu. Na bežné dvojice — WooCommerce alebo Shoptet na jednej strane, Pohoda, Omega, Money S3, iKros či SuperFaktúra na druhej — existujú hotové konektory a doplnky s ročnou licenciou. Nasadia sa za pár dní a stoja zlomok vývoja.
Cena za to je pevný rozsah. Konektor prenáša to, čo má v sebe zabudované, a nič viac. Ak máte vlastnú cenotvorbu pre veľkoobchod, viac skladov alebo netypický postup pri vratkách, narazíte naň v druhom mesiaci a dorobenie bude drahšia než integrácia na mieru od začiatku. Správne poradie je opačné, než sa zvyčajne robí: najprv si spíšte, čo má prepojenie vedieť, a až potom sa pýtajte, či to hotový konektor pokryje. Nie naopak.
Ak sa produkty párujú podľa názvu, integrácia funguje dovtedy, kým niekto neopraví preklep. Potom sa položka v podnikovom systéme nenájde, e-shop ju vyhodnotí ako novú a založí duplicitu. Preto sa páruje podľa kódu položky (SKU), ktorý sa nemení, a ak taký kód v katalógu neexistuje, zaviesť ho je prvá úloha projektu — nie posledná.
Osobitná kapitola sú varianty. Tričko v piatich veľkostiach a troch farbách je pre e-shop jeden produkt s pätnástimi variantmi, pre podnikový systém pätnásť samostatných skladových kariet. Ak sa táto hierarchia nezmapuje na začiatku, dorába sa neskôr ručne a pri každej novej kolekcii znova.
Toto je jediná tabuľka, ktorú by ste si mali vypýtať skôr, než podpíšete objednávku. Ak ju dodávateľ nemá pripravenú, znamená to, že rozsah ešte nie je premyslený a bude sa dopĺňať počas vývoja — teda za príplatok.
| Údaj | Smer | Zdroj pravdy | Typická frekvencia | Čo sa stane, keď to nesedí |
|---|---|---|---|---|
| Katalóg položiek a parametre | ERP → e-shop | podnikový systém | pri zmene, inak raz denne | e-shop predáva položky, ktoré ste už vyradili |
| Predajné ceny a akcie | ERP → e-shop | tam, kde sa tvorí cenotvorba | pri zmene | zákazník vidí inú cenu, než mu vyfakturujete |
| Disponibilné množstvo | sklad → e-shop | skladový systém | minúty, v sezóne kratšie | predaj do mínusu a stornované objednávky |
| Rezervácia tovaru | e-shop → ERP | e-shop v momente objednávky | okamžite | posledný kus kúpia dvaja zákazníci |
| Objednávka a platba | e-shop → ERP | e-shop | okamžite | ručné prepisovanie a chyby v sumách |
| Stav objednávky a číslo zásielky | ERP → e-shop | podnikový systém | pri zmene stavu | zákazník sa pýta e-mailom, kde má balík |
| Faktúra a dodací list | ERP → e-shop | podnikový systém | pri vystavení | doklady v dvoch systémoch sa rozchádzajú |
| Zákazník a fakturačné údaje | obojsmerne | e-shop pri novom, ERP pri existujúcom | pri zmene | duplicitné karty a nespárované platby |
| Vratky a dobropisy | e-shop → ERP → e-shop | podnikový systém | pri zmene stavu | vrátený tovar sa nevráti na sklad |
Všimnite si, že smer nie je pri všetkých údajoch rovnaký a pri zákazníkovi dokonca závisí od toho, či ide o nový alebo existujúci záznam. Väčšina neskorších problémov vzniká z toho, že sa jeden údaj zapisuje z oboch strán bez pravidla, ktoré rozhodne spor.
Z tabuľky sa dá vyčítať ešte jedna vec. Každý riadok, ktorý do nej pridáte, je ďalšie mapovanie, ďalší testovací scenár a ďalšie miesto, kde sa dá pokaziť. Preto sa oplatí začať tromi riadkami, ktoré prinesú najviac ušetreného času — zásoby, objednávky a doklady — a zvyšok pridávať až vtedy, keď tieto tri bežia mesiac bez zásahu.
Marketingové a obsahové polia nechajte v e-shope. Rovnako sem nepatrí ani odovzdávanie zásielok dopravcom — Packete, GLS, DPD či Slovenskej pošte. To je samostatné prepojenie, ktoré rieši štítky a sledovanie zásielky, a nemá zmysel viesť ho cez podnikový systém len preto, že tam už jedno rozhranie máte. Popisy produktov, obrázky, štruktúru kategórií, meta tagy či texty pre produktový feed, teda export do porovnávačov a reklamných systémov, typicky nemá zmysel spravovať v podnikovom systéme — ten je stavaný na účtovné a skladové údaje, nie na predajný text. Keď sa to zmieša, redakčná práca sa presunie do rozhrania, ktoré na ňu nie je stavané, a obsah tým trpí.
Frekvencia synchronizácie nie je technická drobnosť, ale obchodné rozhodnutie. Určuje, ako dlho môže e-shop predávať zo starých čísel. Pri sortimente s pomalou obrátkou je hodinové oneskorenie neviditeľné. Pri poslednom kuse v sezóne rozhoduje minúta.
| Režim prenosu | Ako funguje | Kedy dáva zmysel | Na čo si dať pozor |
|---|---|---|---|
| Udalosť (webhook) | systém sám ohlási zmenu druhej strane | objednávky, platby, zmeny stavu | zmeškanú správu treba doručiť znova |
| Sťahovanie v intervale (cron) | jedna strana sa v pevnom intervale pýta na zmeny | ceny, katalóg, disponibilné množstvo | obmedzenia počtu volaní rozhrania |
| Fronta správ | zmeny sa zaradia a spracujú postupne | nárazové objemy a sezóna | vyžaduje monitoring dĺžky fronty |
| Dávkový prenos súborov (XML, CSV) | export a import v pevných časoch | historické dáta, prechodné obdobie | ako trvalé riešenie prináša oneskorenie |
V praxi sa režimy kombinujú. Objednávka ide okamžite ako udalosť, katalóg sa ťahá v intervaloch a v sezóne sa pred zápis vloží fronta, aby špička nezhodila podnikový systém. Rozhrania mávajú limit na počet volaní za minútu a integrácia, ktorá ho nerešpektuje, začne pri väčšom nápore vracať chyby práve vtedy, keď to najviac bolí.
Za rýchlosťou je vždy cena. Synchronizácia zásob každú minútu znamená vyššiu záťaž na podnikový systém, drahšiu prevádzku a viac miest, kde sa dá pokaziť. Ak sa jeden kus vášho sortimentu predá raz za dva týždne, nočný prenos je úplne dostatočný a rozdiel v cene projektu je citeľný. Rýchlosť si kupujte tam, kde vám predaj do mínusu reálne spôsobuje storná — typicky pri niekoľkých desiatkach položiek s najrýchlejšou obrátkou, nie plošne pre celý katalóg.
Fyzický stav zásob a predajná dostupnosť nie sú to isté. Časť tovaru je rezervovaná pre otvorené objednávky, časť je pripravená na expedíciu, časť visí v reklamačnom procese. Ak e-shop zobrazuje fyzické číslo zo skladovej karty, predá aj to, čo je už niekomu prisľúbené. Prenáša sa preto disponibilné množstvo — fyzický stav znížený o rezervácie a rozpracované výdaje. Tak to pomenúvajú aj konektory na Pohodu či Kros a v tomto tvare ho očakávajú.
Nad rámec toho sa nastavuje poistná zásoba: pár kusov, ktoré e-shop nikdy neponúkne, aby pokryli bežné nepresnosti evidencie. Má svoju cenu — každý schovaný kus je kus, ktorý ste mohli predať. Pri drahom sortimente s pomalou obrátkou sa to rýchlo nazbiera, preto sa poistná zásoba nastavuje po kategóriách, nie plošne jedným číslom pre celý sklad. A pri sortimente s expiráciou alebo so sériovými číslami nestačí ani jedno číslo: e-shop musí vedieť aspoň to, či sa predáva zo šarže, ktorej sa blíži koniec doby použiteľnosti.
Otázka neznie, či sa hodnoty niekedy rozídu. Rozídu sa. Otázka je, či na ten moment existuje pravidlo, alebo sa bude improvizovať.
Pravidlo, ktoré konfliktu predchádza, je jedno: pri každom poli určte jediný systém, ktorý ho smie meniť. Cena sa tvorí na jednom mieste a druhá strana ju len prijíma. Stav zásob počíta sklad. Objednávku zakladá e-shop. Keď sa toto dodrží, konflikt nemá kde vzniknúť — a ak vznikne, vždy vyhráva zdroj pravdy a druhá hodnota sa prepíše, nezlučuje sa.
Pri výpadku spojenia odosielateľ často pošle správu druhýkrát, lebo nedostal potvrdenie. Ak integrácia nevie rozlíšiť, že ide o tú istú objednávku, založí ju znova. Riešením je jednoznačný identifikátor operácie, ktorý si prijímajúca strana pamätá a druhé spracovanie ticho zahodí. Bez toho sa každý dlhší výpadok prejaví duplicitnými dokladmi a rozhádzaným skladom.
Objednávka môže obsahovať položku, ktorá bola medzitým vyradená, alebo zákazníka s neplatnými fakturačnými údajmi. Slabá integrácia ju v tichosti zahodí a nikto o nej nevie. Poriadne riešenie ju ponechá v čakajúcom stave, oznámi to zodpovednej osobe a umožní opakovaný pokus po oprave. Pri návrhu si preto vždy vypýtajte odpoveď na jednu vetu: kde skončí objednávka, ktorú sa nepodarilo zapísať?
Integrácie zriedka zlyhajú na hlavnom scenári. Objednávka za bežných okolností prejde. Padá to na okrajových prípadoch, ktoré počas vývoja nikto netestoval, lebo v testovacích dátach neboli.
Zaokrúhľovanie a daň. E-shop počíta ceny s daňou a zaokrúhľuje položku po položke, kým účtovné systémy rozšírené na slovenskom trhu — Pohoda, Omega od Krosu, Money S3 či MRP — počítajú bez dane a zaokrúhľujú celý doklad. Rozdiel býva pár centov na objednávku. Nikto ho nenahlási, a preto vypláva až pri uzávierke ako nespárovaná platba — a s ňou hodiny strávené nad bankovým výpisom.
Doprava, dobierka a poplatky. Doprava je v e-shope často samostatná položka košíka, v účtovníctve služba s vlastnou sadzbou. Ak sa nezmapuje, buď chýba na doklade, alebo sa objaví dvakrát.
Viac skladov a viac predajných kanálov. Keď predávate cez e-shop, kamennú predajňu aj porovnávače naraz, dostupnosť sa musí počítať z jedného miesta. Inak kanály predajú tie isté kusy dvakrát a sklad to zistí až pri balení. To isté platí aj pre cenové porovnávače: produkt spárovaný na Heureke sa predáva z rovnakého disponibilného množstva ako produkt v e-shope.
Čiastočné expedície a vratky. Objednávka odíde na dvakrát, zákazník vráti jednu položku z troch. Tieto zmeny musia zachytiť obe strany, inak sa evidencia rozíde presne v prípadoch, ktoré najviac zaťažujú zákaznícku podporu.
Párovanie úhrad. Peniaze chodia z platobnej brány v hromadných výplatách znížených o províziu, z banky po jednotlivých prevodoch a od dopravcu za dobierky s vlastným rozpisom. Ak sa úhrada nespáruje s objednávkou automaticky, robí to niekto ručne a pri prvých stovkách objednávok mesačne je to samostatná pracovná náplň. Do rozsahu projektu preto patrí aj kľúč párovania — variabilný symbol, číslo objednávky alebo referencia z brány.
Chýbajúci dohľad. Bez záznamu o prenosoch a bez upozornenia pri opakovanej chybe sa výpadok zistí až podľa dôsledku. Prevádzkový dohľad patrí do rozsahu projektu rovnako ako samotné prepojenie — s meraním a reportingom je vidieť nielen chyby integrácie, ale aj to, čo sa deje s objednávkami pred ňou.
Najviac hodín z toho zožerie zaokrúhľovanie. Ostatné položky bolia hneď a niekto ich nahlási ešte v prvom týždni. Rozdiel dvoch centov na doklade nenahlási nikto — ten sa len ticho kopí, kým sa raz za mesiac neposadí účtovníčka nad výpis a nezačne párovať ručne.
Na projekte pre Dr. Valuch sme riešili práve tú náročnejšiu časť: jeden katalóg, rozdielne pravidlá pre koncových a veľkoobchodných odberateľov a dostupnosť, ktorá musí sedieť pre oba režimy naraz.
Najdrahšia časť integračného projektu nie je programovanie. Je to upratovanie dát, ktoré sa roky nikto neodvážil otvoriť. Čím skôr sa doň pustíte, tým menej prekvapení príde v momente, keď už bežia ostré objednávky.
Treba s tým počítať aj v rozpočte. Pri katalógu bez stabilných kódov položiek pohltí upratovanie dát podstatnú časť projektu a väčšinu tej práce musí urobiť váš skladník alebo účtovníčka, nie dodávateľ — oni jediní vedia, ktorá z troch kariet toho istého tovaru je tá platná. Dá sa to celé zveriť agentúre, ale platíte hodinovou sadzbou vývojára za prácu, ktorú sklad urobí rýchlejšie a lacnejšie.
| Fáza | Čo sa v nej rozhodne | Výstup, ktorý si vypýtajte |
|---|---|---|
| Dátový audit | v akom stave sú kódy položiek, varianty a karty zákazníkov | zoznam nezrovnalostí na vyčistenie |
| Mapovanie polí | ktoré pole zodpovedá ktorému a ako sa prevádza | tabuľka entít, polí a párovacieho kľúča |
| Pravidlá a zdroj pravdy | kto smie údaj meniť a čo pri konflikte | písomné pravidlá pre každú entitu |
| Testovacie prostredie | kde sa skúša bez dopadu na prevádzku | oddelené prostredie s kópiou dát |
| Testovacie scenáre | okrajové prípady, nie iba hlavný scenár | zoznam scenárov vrátane výpadku a vratky |
| Pilot na časti sortimentu | či pravidlá obstoja na reálnych dátach | vyhodnotenie nezrovnalostí za pilotné obdobie |
| Ostrý prechod | kedy a v akom poradí sa systémy prepnú | plán prechodu vrátane rollbacku |
| Prevádzka a dohľad | kto reaguje na chyby a v akom čase | dohodnuté reakčné doby a prístup k záznamom |
Pilot na užšej časti sortimentu je krok, ktorý sa vypúšťa najčastejšie — a jeho absencia sa potom najviac vypomstí. Stačí jedna kategória a niekoľko desiatok objednávok, aby sa ukázalo, či sedia dane, dostupnosť aj doklady. Oprava v tejto fáze stojí zlomok toho, čo tá istá chyba po prepnutí celého katalógu.
Prineste zoznam systémov, ktoré sú v hre, a mená ľudí, ktorí ich spravujú. K tomu vzorku katalógu vrátane variantov, jednu objednávku so všetkými poplatkami a jeden zložitý prípad — čiastočnú expedíciu alebo vratku. A odpoveď na otázku, kde sa dnes tvoria ceny a kto ich mení. Z týchto štyroch vecí sa dá určiť rozsah aj poradie prác a projekt naceniť na mieru. Bez nich vznikne odhad, ktorý sa v polovici projektu prekročí.
Referencie na peknom e-shope o integrácii nepovedia nič. Prepojenie nie je vidno zvonku, takže sa treba pýtať na veci, ktoré sa dajú ukázať iba zvnútra.
Vypýtajte si mapovaciu tabuľku z predchádzajúceho projektu, aj keď bude anonymizovaná. Chcete vidieť, či existuje. Ďalej sa pýtajte, ako riešia opakované doručenie správy, kam odkladajú neúspešné zápisy, ako sa dozvedia o výpadku a či bude integrácia bežať v oddelenom testovacom prostredí ešte pred spustením. Odpoveď „to doladíme počas prevádzky“ je varovný signál — znamená, že testovanie zaplatíte objednávkami zákazníkov.
Druhá otázka sa kladie ťažšie, ale rozhoduje o tom, či zostanete nezávislí. Kto má prístup k prihlasovacím údajom rozhraní, kde je uložený zdrojový kód a čo sa stane, keď spoluprácu ukončíte. Integrácia je infraštruktúra vášho predaja a nemala by byť čiernou skrinkou. Ako vyzerá naša práca na projektoch tohto typu, si viete pozrieť v referenciách.
Rozhoduje stav dát, nie počet entít. Ak má katalóg čisté kódy položiek a varianty sú zavedené jednotne, ide o kratší projekt zameraný na mapovanie a testovanie. Ak sa kódy dopĺňajú počas projektu, časť rozpočtu ide na upratovanie a termín sa posúva. Realistický odhad vzniká až po dátovom audite.
Vo väčšine prípadov nie. Integrácia pracuje s existujúcimi systémami cez ich rozhranie alebo cez hotový konektor. Výmena prichádza do úvahy, keď jeden zo systémov nemá rozhranie vôbec a jediná cesta by viedla priamo do databázy — to je krehké riešenie, ktoré sa rozbije pri prvej aktualizácii.
Pri správne navrhnutej integrácii sa objednávky zaraďujú do fronty a spracujú sa po obnovení spojenia, pričom identifikátor operácie zabráni dvojitému zápisu. Zákazník výpadok nezaznamená. Bez fronty a bez opakovaného pokusu sa objednávky z tohto okna jednoducho stratia.
Dostupnosť musí počítať jeden systém, ktorý vidí všetky sklady aj otvorené rezervácie, a ostatné kanály z neho iba čítajú. K tomu sa nastavuje pravidlo, z ktorého skladu sa objednávka expeduje. Ak si kanály držia vlastné čísla, predaju do mínusu sa nevyhnete.
Tam, kde ich reálne spravujú ľudia, ktorí za ne zodpovedajú. Ak cenotvorbu robí obchodné oddelenie v podnikovom systéme, e-shop ceny iba preberá. Ak vznikajú akcie na strane marketingu, definujte, ktoré cenové pole je akciové a ktoré základné, aby prenos jedno neprepisoval druhým.
Podľa troch vecí: počet objednávok v e-shope za obdobie sa rovná počtu v podnikovom systéme, počet neúspešných prenosov je viditeľný a klesá, a nikto v tíme neopravuje dáta ručne. Ak si niekto vedie pomocnú tabuľku, integrácia niečo nepokrýva.
Začnite jednou tabuľkou. Napíšte si entity, ktoré majú systémy vymieňať, a ku každej doplňte smer, zdroj pravdy a frekvenciu. Pri poliach, kde si nebudete istí, kto ich smie meniť, ste práve našli miesta, kde vám dnes vznikajú nezrovnalosti. Ak chcete jednu kontrolu na dnes: vezmite tri objednávky z minulého týždňa a porovnajte ich sumy v e-shope a v podnikovom systéme položku po položke. Ak sa niektorá líši čo i len o cent, máte problém so zaokrúhľovaním a ten rastie s počtom objednávok.
Druhý krok je katalóg. Bez stabilných kódov položiek a jednotne zavedených variantov je akékoľvek prepojenie postavené na piesku, a to platí rovnako pre e-shop na mieru aj pre hotovú platformu. Tretí krok je rozhodnutie, či sa ide integrovať existujúce riešenie, alebo či má zmysel dať do poriadku aj samotný predaj — vtedy sa oplatí riešiť návrh UX a UI spolu s dátovou vrstvou, nie oddelene.
Ak riešite prepojenie e-shopu s účtovníctvom a skladom, ozvite sa nám. Prejdeme si vaše systémy, dáta aj procesy, navrhneme rozsah integrácie a naceníme ho na mieru vášmu projektu.
