Middleware mezi ERP a e‑commerce / uživatelským softwarem

Když nadnárodní skupina nasazuje nové ERP a centralizuje klíčové procesy, lokální potřeby jednotlivých zemí často mizí z radaru.

Rozdílné obchodní zvyklosti, legislativa, cenotvorba i provozní realita dceřiných společností se těžko vtěsnávají do jednoho rigidního systému. Výsledkem bývají výpadky digitálního prodeje při migracích ERP, omezení lokální autonomie a pomalé reakce na specifika trhu – právě v době, kdy e-commerce potřebuje pružnost a kontinuitu. Tato case study ukazuje, jak může middleware mezi ERP a e-commerce vrátit dceřiným společnostem kontrolu, zajistit nepřerušený provoz a umožnit rychlé úpravy bez zásahů do centrálního ERP.

Proč to firmy řeší

Když nadnárodní skupina nasazuje nové ERP a centralizuje procesy, pohled centrály se logicky upírá na sdílené pravidlo, nikoli na výjimky. Lokální potřeby dceřiných společností – jiné země, odlišné obchodní zvyklosti, vlastní zákazníci – tak často zůstávají mimo zorné pole. To přináší tři typická rizika:

  • výpadky digitálního prodeje/dostupnosti během migrací/odstávek ERP, stejně jako při samotném rolování ERP do produkce
  • ztráta lokální autonomie (smluvní podmínky, sledované ukazatele, lokální právní specifika, cenotvorba, dostupnost, doručování)
  • pomalá schopnost přizpůsobit e‑commerce (nebo jiné části, například CMS nebo účetní manažerské výkaznictví) specifikům jednotlivých trhů.

Cíl řešení

Klíčem je oddělit specifický software – typicky rychle se měnící kanál e‑commerce – od rigidního ERP, zachovat lokální obchodní pravidla a zajistit kontinuitu businessu i při dlouhých odstávkách. Jinými slovy: dát centrále stabilitu, kterou potřebuje, a dceřiným společnostem volnost, kterou potřebují ony.

Architektonický vzor

Řešením je middleware, který sedí mezi ERP a lokálním softwarem. Navenek poskytuje stabilní API kontrakty, dovnitř pak nabízí lokálním týmům sadu nástrojů, kterými si můžou pravidla, obsah i integrace ovládat sami – bez čekání na centrálu.

Schéma toku mezi klientem/partnerem/uživatelem, e-commerce řešením, middleware a ERP. Middleware zajišťuje obousměrnou komunikaci mezi e-shopem a ERP a zároveň v něm jsou implementovány lokální funkce.

Klíčové schopnosti middleware

Náš příklad z velkoobchodního e-commerce je přenositelný na jakékoliv jiné odvětví. Výsledné řešení má totiž tyto klíčové vlastnosti.

Prodejní platforma pro partnery (distributory / velkoobchodníky)

Partneři potřebují svůj vlastní prostor, kde si nastaví obchodní podmínky pro koncové zákazníky, aniž by museli sahat do centrálního ERP. Middleware jim k tomu dává konkrétní nástroje:

  • Přepisy cen a marží nad katalogem (řízení obchodních podmínek bez zásahu do ERP).
  • Správa přístupů pro koncové zákazníky partnerů (kteří nezapadají do standardní struktury oprávnění), včetně zakládání účtů a delegovaného řízení oprávnění.
  • Dostupnost zboží: možnost nahrávat/integrovat vlastní skladové stavy (CSV/API) a řídit, komu se zobrazí; fallback na dostupnost z centrálního skladu.
  • Doručení/rozvoz: více poboček partnera, pravidla dopravy a směrování objednávek spravovaná v middleware.
  • Governance sortimentu: volitelná restrikce na schválený katalog (partneři nepřidávají „cizí“ zboží)

Identity & Access jako služba

  • Onboarding externích účtů (partneři, jejich zákazníci), reset hesel, registrace, role/permission sety, audit.
  • Parametrizace chování katalogu pro různé role, notifikace, last login.

Download centrum (faktury a dokumenty)

  • Zpřístupnění faktur a interních dokumentů přímo z e‑commerce.
  • Automatizace (management commandy, skripty) – např. přesuny souborů do Download centra.

CMS pro e‑commerce

  • Bannery, obsahové bloky, promo akce i „top‑sale“ produkty editujete přímo, bez zásahu do ERP – marketing tak může pracovat svým vlastním tempem.

Offline mód (business continuity)

Plánovaná odstávka nebo výpadek ERP nesmí znamenat zastavení prodeje. V takových situacích přebírá řízení middleware a uživatel rozdíl ideálně vůbec nepozná.

  • Při výpadku/plánované odstávce ERP: nepřerušované objednávky, transakce se frontují a po obnovení se dosynchronizují.
  • Dočasně se může skrýt realtime dostupnost; uživatelé výpadek fakticky nepoznají.

Integrace referenčních dat

  • Napojení na poskytovatele referenčních dat (např. identifikace zboží/stroje/vozidla dle různých identifikátorů).
  • Inteligentní vyhledávání: rozpoznání typu vstupu z volného textu a dotaz na správný zdroj; přesnější objednávky, méně vratek.

Moduly (rozšiřitelnost & entitlementy)

  • Volitelné moduly e‑commerce (např. rozšířené vyhledávání, specifické platební či dopravní integrace).
  • Aktivace modulů pro konkrétní trhy/partnery bez dopadu na ostatní.

Obchodní data mimo ERP

  • Lost sale reasons, opuštěné košíky, chování uživatelů – cenné podklady pro obchod a marketing, které ERP obvykle vůbec nesbírá.

Přenositelnost napříč zeměmi a dceřinými společnostmi

Problém není raritní – opakuje se v nadnárodních skupinách, kde centrální ERP nezohledňuje lokální specifika. Přenositelnost stojí na:

  • Oddělení vrstev: ERP (stabilita) vs. e‑commerce (rychlé změny) s middlewarem mezi nimi.
  • Konfigurovatelnosti: ceny, dostupnost, pravidla dopravy, role a obsah spravovatelné lokálně
  • Šablonách: znovupoužitelná datová schémata, API kontrakty, standardní konektory a runbooky.
  • Rozšiřitelnosti: ModuleStore a entitlementy umožní odlišné funkce pro různé trhy bez forkování kódu.

Co je fixní a co variabilní

V tomto modelu jsou některé prvky pevně dané – obvykle je definuje mateřská společnost nebo přímo ERP – a jiné jsou variabilní: o těch rozhodujete sami na lokálním trhu, nebo je diktuje místní legislativa. Rozdělení vypadá typicky takto:

  • Fixní: integrační principy (API, fronty, idempotence), datové kontrakty (katalog, ceny, objednávky, identity), observabilita a audit.
  • Variabilní: lokální daně/DPH, jazyky a měny, dopravci a SLA, pravidla cenotvorby, modulové rozšíření, reference datové zdroje.

Implementační playbook pro novou dceru

Připojení nové dceřiné společnosti není improvizace – postupujeme podle ověřené sekvence kroků. Každý má jasný výstup a navazuje na další, takže klient přesně ví, co se právě řeší a co přijde:

  • Discovery & fit‑gap: role a toky (B2B partner, jejich zákazník), cenotvorba, logistika, compliance.
  • Datové kontrakty: katalog, ceny, dostupnost, objednávky, faktury, identity; definice „offline“ datové sady.
  • Adapter layer k ERP: konektory, message bus, retry, idempotence, audit trail.
  • E‑commerce: modulární rollout, CMS, promo, řízení oprávnění a chování katalogu.
  • IAM: registrace/SSO (je‑li potřeba), správa hesel, role, audit.
  • Reference data: napojení na lokální/oborové poskytovatele, validace a fallbacky.
  • Moduly: výběr modulů pro konkrétní trhy/partnery.
  • Offline scénáře: DR plány, testy dlouhých odstávek, metriky re‑sync.
  • Go‑live & hypercare: monitoring, notifikace, runbooky, školení lokálních adminů.

Co potřebujeme od klienta na start

Abychom mohli middleware navrhnout přesně na míru vašemu prostředí, potřebujeme od vás na začátku několik zásadních vstupů. Bez nich nelze správně postavit datové kontrakty ani obchodní logiku:

  • Zdroj pravdy pro ceny a slevy, definice partnerů a segmentů.
  • Pravidla logistiky a doručení (dopravci, cut‑off, SLA), platební metody.
  • Požadavky na jazyk, měny, DPH a lokální compliance.
  • Cílové KPI a očekávané NFR.

Shrnutí

Vzor ERP ↔ middleware ↔ e‑commerce je obecně přenositelný napříč dceřinými společnostmi a trhy. Přináší kontinuitu prodeje, lokální autonomii bez forkování ERP a rychlejší iterace v digitálním kanálu – s jasnou správou oprávnění, modulární rozšiřitelností a měřitelnými KPI.

Máte zájem o spolupráci?

Kontaktujte nás

Adresa

Pláničkova 445/13
162 00 Praha 6

Telefon

+420 777 646 771

E-mail

info@eluvia.com
Případová studie: Middleware mezi ERP a e‑commerce/uživatelským softwarem | eluvia.com