ERP-ul știe. Webshop-ul nu știe. Clientul e supărat.

Scenariul e mai comun decât credem: un client plasează o comandă online pentru un produs care apare ca "în stoc". ERP-ul știa de 4 ore că acel produs nu mai există în depozit — fusese vândut unui client B2B prin agentul de vânzări. Webshop-ul nu a primit informația. Clientul online primește un email a doua zi: "Ne pare rău, produsul nu mai este disponibil."

Un client pierdut. O recenzie negativă posibilă. Un om din echipa de suport care gestionează situația manual.

De unde vine decalajul

ERP-ul actualizează stocul în timp real. Webshop-ul îl citește la fiecare oră printr-un import programat. Acesta e decalajul. Pare mic. Nu e.

Într-o oră, un depozit mediu poate procesa zeci de mișcări de stoc: intrări, ieșiri B2B, rezervări, retururi, ajustări de inventar. Dacă toate acestea nu se propagă instant spre toate canalele de vânzare, operezi cu date false — și iei decizii (sau lași clienții să ia decizii) bazate pe realitate inexactă.

Nu e o problemă de sincronizare. E o problemă de arhitectură.

Soluția reflexă e să micșorezi intervalul de sincronizare: de la o oră la 15 minute, de la 15 minute la 5. La un punct, această abordare devine nesustenabilă — servere suprasolicitate, API-uri cu rate limiting, import-uri care se suprapun și produc date corupte.

Abordarea corectă e orientată pe eveniment, nu pe polling. Când ERP-ul confirmă o mișcare de stoc, declanșează un eveniment. Orchestratorul preia evenimentul și îl propagă simultan spre webshop, marketplace-uri și orice alt canal activ. Nu la interval fix — instant, când evenimentul are loc.

Sincronizarea periodică e un compromis. Arhitectura event-driven e soluția.

Unde se complică lucrurile

Problema nu e doar stocul. E orice informație care există în ERP și trebuie să ajungă pe canal: prețuri, disponibilitate, termeni de livrare, status comandă, factură. Fiecare dintre acestea are propriul ritm de schimbare și propriul impact dacă ajunge cu întârziere.

Un preț greșit pe un marketplace poate genera pierderi directe dacă platforma penalizează erorile de preț. Un status de comandă neactualizat generează apeluri la suport. O factură emisă cu întârziere blochează procesele contabile ale clientului B2B.

Cum arată integrarea corectă

Într-un ecosistem bine orchestrat, ERP-ul e sursa de adevăr, dar nu e responsabil să "împingă" informația nicăieri. Orchestratorul ascultă ERP-ul, înțelege ce s-a schimbat și decide ce canal trebuie actualizat, în ce format și cu ce prioritate.

Webshop-ul nu mai "trage" date periodic. Primește actualizări când există ceva de actualizat. Marketplace-urile primesc fiecare stoc și preț în formatul lor specific, instantaneu. ERP-ul continuă să facă ce știe cel mai bine: gestiunea internă a businessului.

Concluzie

Dacă ai vreodată situația în care un client a comandat ceva ce nu mai aveai, sau a primit un preț pe care nu îl mai practicai — nu e o eroare umană. E o eroare de arhitectură. Și se rezolvă o singură dată, structural, nu prin procese manuale repetate.