Integrace nejsou doplněk — jsou provozní rozhodnutí

Problém, který vypadá jako „technický detail“

Firmy koupí ERP, e-shop a CRM. Každý systém funguje „sám o sobě“. Data se přenášejí exportem, e-mailem — nebo vůbec. Management pak slyší: „Potřebujeme jen malou integraci.“

Integrace ale není doplněk. Je to provozní rozhodnutí: kdo vlastní pravdu o skladu, objednávce a zákazníkovi — a co se stane, když se synchronizace zasekne v pátek odpoledne.

Proč „malá integrace“ bolí

Bez spolehlivé vrstvy mezi systémy typicky vzniká:

• nesoulad dostupnosti — online prodáte, co ve skladu už není,
• zpoždění expedice a reklamace,
• reporty, kterým nikdo nevěří,
• tišší dvojí práce lidí, kteří data „jen rychle přepíšou“.

Technicky nejtěžší obvykle není „udělat API“. Těžší je domluvit vlastnictví dat, pořadí synchronizace, retry politiku a chování při chybách.

Signály, že integrace je strategická

• Denně nebo týdně běží export/import mezi systémy.
• Stejné číslo (sklad, cena, stav objednávky) žije na více místech.
• Incidenty se řeší „zavolejte kolegovi“, ne podle logu.
• Každá změna procesu vyžaduje zásah vývojáře a účetní a skladu najednou.
• Plánujete výměnu jednoho systému, ale nevíte, co se rozbije v druhém.

Přístup GEREQ

Integrační vrstva s jasnými pravidly:

1. Kritické toky první — ne big bang „propojíme vše“.
2. Asynchronní fronty (retry, dead-letter, monitoring) místo křehkých synchronních volání všude.
3. Jednoznačný vlastník každého toku na straně klienta i dodavatele.
4. Alerty dřív, než to objeví zákazník nebo sklad.
5. Dokumentace rozhraní a předání provozu — ne „černá skříňka u dodavatele“.

Typický obraz: obchodní systém a ERP komunikují přes API a fronty. Chyby se logují. Synchronizace má majitele.

Související případová studie: ERP integrace skladu a obchodu.

Příklad (anonymizováno)

Klient měl obchod a ERP vedle sebe. Dostupnost se přepisovala ručně. Po nasazení integrační vrstvy:

• sklad a obchod začaly pracovat se stejnými daty prakticky v reálném čase,
• denní ruční exporty/importy u sledovaných toků klesly o odhadovaných 70 %+,
• incidenty se řeší podle alertů, ne podle „někde to nesedí“.

Relativní čísla uvádíme záměrně: klient je pod NDA. Důležité je ověření — srovnání před/po na konkrétních tocích a provozních incidentech.

Náklady špatné integrace

Riziko	Co to stojí
Ruční přepis	Hodiny týdně × sazba lidí × chyby
Špatná dostupnost	Reklamace, storno, ztráta důvěry
Big bang migrace	Měsíce výpadků nebo paralelního chaosu
Bez monitoringu	Problém se pozná u zákazníka

Levná „jednorázová synchronizace skriptem“ často vyjde dráž než pořádná vrstva s frontami — jen náklady přijdou později a rozptýleně.

Rozhodovací rámec: integrovat, nebo sloučit?

Integrovat, když:

• systémy plní odlišnou roli a oba zůstanou,
• potřebujete řízené toky a auditovatelnost,
• nemůžete (nebo nechcete) migrovat vše najednou.

Sloučit / vyměnit, když:

• jeden systém je mrtvý a drží se jen zvykem,
• data nemají smysluplného vlastníka a nikdo nechce vlastnit integraci,
• náklad na údržbu dvou světů dlouhodobě převyšuje migraci.

Nestavět nic nového, když:

• stačí lepší provozní dohoda a disciplína v jednom nástroji,
• problém je organizační, ne datový.

Kontrolní seznam před poptávkou integrace

• Máme seznam toků (objednávka, sklad, faktura…) a jejich prioritu?
• Víme, který systém je zdroj pravdy pro každou entitu?
• Máme vlastníka procesu na straně klienta?
• Víme, co se má stát při chybě (retry, manuál, stop prodeje)?
• Máme přístup k logům a prostředí pro monitoring?

FAQ

Nestačí Zapier / Make?
Pro jednoduché B2C scénáře někdy ano. Pro ERP, sklady a SLA v B2B provozu obvykle potřebujete vlastnictví, fronty a dohled — ne jen „propojte dva konektory“.

Jak dlouho trvá typická integrační vrstva?
U GEREQ často řádově týdny až nízké měsíce u kritických toků, ne „rok na všechno“. Záleží na čistotě dat a dostupnosti lidí u procesu.

Musíme vyměnit ERP?
Často ne. Častěji chybí vrstva mezi systémy a provozní pravidla.

Anti-patterny, které vidím opakovaně

1. Noční CSV mezi systémy — „funguje, dokud někdo nezmění sloupec“.
2. Synchronní volání ERP při každém requestu e-shopu — výpadek ERP = výpadek prodeje.
3. Integrace bez dead-letter fronty — chyby zmizí v logu, který nikdo nečte.
4. Jeden „integrační člověk“ bez dokumentace — nemoc = výpadek provozu.
5. Mapování „jak to cítíme“ místo smluvených identifikátorů a verzí API.

Každý z těchto vzorů vypadá levně na začátku. Po roce je to provozní daň.

Jak měřit úspěch integrace

Bez metriky skončíte u pocitu. Dohodněte si předem:

• počet ručních zásahů týdně na sledovaných tocích,
• dobu do detekce chyby synchronizace,
• počet reklamací / storno z důvodu dostupnosti,
• shodu reportů managementu s provozní realitou (spot check).

Relativní zlepšení (např. −70 % ručních exportů) je často jediné, co lze publikovat u anonymizovaných klientů — a stačí, pokud je metoda ověření jasná.

Kdy volat dodavatele a kdy řešit interně

Interně, když máte silný IT tým, vlastnictví dat a kapacitu držet fronty a monitoring. S dodavatelem (GEREQ), když potřebujete rychle stabilní vrstvu, milníky a předání — a nechcete, aby integrace zůstala „projekt na věky“ bez dokumentace.

Hybrid funguje: dodavatel postaví jádro, interní tým přebírá provoz podle runbooku.

Minimální slovník, který musíte sladit

Než napíšete první endpoint, sladíte významy:

• produkt / SKU / varianta — co je jedna entita ve skladu vs. v obchodě,
• stav objednávky — které stavy smí která strana měnit,
• dostupnost — rezervace, příslib, fyzický sklad,
• identifikátory — co je immutable a co se smí přemapovat.

Bez tohoto slovníku integrace jen automatizuje nedorozumění. S ním můžete stavět fronty a SLA.

Závěr a CTA

Integrace je provozní rozhodnutí s technickým výstupem — ne naopak. Když ERP, e-shop a sklad nemluví stejným jazykem, platíte dvakrát: za licence i za ruční práci mezi nimi.

Chcete ověřit, jestli dává smysl integrační vrstva, nebo jiný postup? Probrat integraci.