Resposta curta: una bona integració entre ERP, PIM i ecommerce B2B comença definint qui és propietari de cada dada. Després es decideix com se sincronitza, amb quina freqüència, què passa quan falla i quin nivell de consistència necessita el client. Connectar APIs sense aquestes decisions només trasllada el desordre d’un sistema a un altre.
En projectes B2B, la integració acostuma a convertir-se en el centre tècnic de l’ecommerce. El front-end pot estar ben dissenyat, però si mostra un preu incorrecte, un estoc obsolet o una fitxa inconsistent, la confiança cau. I si una comanda entra dues vegades o es perd abans de l’ERP, el problema ja no és d’experiència: afecta operació, facturació i servei.
Primer: dibuixa el mapa de sistemes
Abans d’especificar endpoints convé llistar els sistemes que participen i per a què s’utilitzen avui. ERP, PIM, CRM, WMS, DAM, ecommerce, eina de màrqueting, transportistes, BI o sistemes d’identitat poden intervenir. No tots necessiten connectar-se directament amb tots.
L’objectiu és evitar una arquitectura de connexions punt a punt difícil de mantenir. En molts casos, l’ecommerce ha de consumir dades de fonts definides i publicar esdeveniments o transaccions seguint un flux controlat.
Defineix una font de veritat per a cada domini
La font de veritat no ha de ser un únic sistema. Ha de ser inequívoca per tipus de dada. L’ERP pot governar comptes, condicions comercials, crèdit i comandes. El PIM pot governar títol, atributs, taxonomia, traduccions i relacions de producte. El DAM pot governar arxius. L’ecommerce pot governar llistes desades, comportament d’usuari i contingut específic d’experiència.
El més important és que una modificació tingui un lloc oficial. Si una descripció es pot editar en PIM i ecommerce sense regles, tard o d’hora les versions divergeixen.
Producte: separa dada comercial, tècnica i editorial
Un producte B2B acumula molts tipus d’informació. SKU, unitat de venda, família fiscal i estat de venda poden venir de l’ERP. Especificacions i atributs enriquits poden venir del PIM. Casos d’aplicació i contingut SEO es poden gestionar al CMS.
No cal forçar-ho tot dins d’un únic sistema. Cal saber quin camp ve d’on i quin equip el manté. Aquesta separació permet que el catàleg sigui ric sense convertir l’ERP en un gestor editorial.
Preu: evita replicar tota la lògica si no és necessari
Els preus B2B poden dependre de client, grup, mercat, moneda, volum, contracte i data. Copiar totes aquestes regles a l’ecommerce crea risc de divergència. En alguns projectes el portal consulta o rep un preu calculat per l’ERP; en d’altres se sincronitzen taules de condicions.
L’elecció depèn de volum, rendiment i necessitat de temps real. L’essencial és poder explicar per què el preu mostrat és correcte i què passa si la font no respon.
Estoc: temps real no sempre significa millor
Consultar l’ERP en cada visualització pot generar latència i dependència. Sincronitzar cada cert temps pot ser suficient si el negoci tolera petites diferències. Algunes empreses mostren rangs o estats de disponibilitat en lloc d’unitats exactes.
La decisió ha de partir de la promesa al client. Si el web diu «disponible ara», el sistema necessita una garantia diferent que si mostra «habitualment disponible en 48–72 h».
Clients i comptes: sincronitza identitat i condicions
En B2B, el client digital s’ha de relacionar amb el compte comercial existent. És freqüent necessitar validació abans d’activar preus privats, vincular diversos usuaris a una mateixa empresa i heretar adreces o condicions.
Defineix quin és l’identificador estable del compte. El correu d’una persona no acostuma a ser suficient. També convé definir quins canvis pot fer l’usuari online i quins han de tornar a l’ERP després d’una validació.
Comandes: dissenya idempotència des del principi
Una comanda no s’hauria de duplicar perquè una petició es repeteixi. APIs, webhooks i cues poden reintentar. La integració ha de reconèixer una transacció ja processada i retornar una resposta coherent.
La idempotència és especialment important en pagaments i creació de comandes. Un identificador extern estable i un registre d’estats permeten reintentar sense generar duplicats.
Utilitza cues per desacoblar operacions que no han de ser síncrones
No tot ha de passar durant l’espera de l’usuari. Una comanda pot confirmar-se al portal i enviar-se a l’ERP mitjançant una cua, sempre que l’experiència expliqui l’estat i hi hagi monitorització. El mateix passa amb actualitzacions massives de catàleg o documents.
Les cues permeten absorbir pics i reintentar errors temporals. Però requereixen visibilitat: no n’hi ha prou amb emmagatzemar treballs; cal saber quins fallen, des de quan i per què.
Dissenya explícitament l’estat degradat
La pregunta «què passa si l’ERP cau?» s’ha de respondre abans del llançament. Potser el catàleg continua visible però es desactiva la compra. Potser es mostra l’última disponibilitat coneguda amb un avís. Potser determinats clients poden preparar una comanda que queda pendent.
L’estat degradat evita que una dependència interna converteixi tot el web en indisponible.
Errors: diferencia temporal, dada invàlida i conflicte
No tots els errors es reintenten igual. Un timeout pot ser temporal. Un SKU inexistent requereix revisió de dades. Un preu impossible pot indicar un conflicte de regles. Classificar errors ajuda a automatitzar reintents i escalar només allò que necessita intervenció humana.
Un dashboard operatiu senzill acostuma a ser més útil que revisar logs tècnics quan atenció al client necessita saber què està passant amb una ordre concreta.
Observabilitat: registra el viatge de cada entitat
Per depurar una integració necessites seguir producte, client o comanda a través de sistemes. Identificadors de correlació, timestamps, estat de sincronització i origen del canvi permeten respondre preguntes com «per què aquesta comanda no va arribar?» sense reconstruir manualment diversos logs.
Seguretat: integra amb el mínim privilegi
Una credencial d’ecommerce no hauria de tenir accés a tot l’ERP. Limita permisos per funció, protegeix secrets fora del codi, rota credencials i registra operacions sensibles. En integracions B2B també convé revisar exposició de dades comercials de clients.
Com decidir entre sincronització batch, esdeveniments i consulta directa
Batch funciona bé per a grans volums que no necessiten immediatesa, com una actualització nocturna de determinades dades. Els esdeveniments són útils quan un canvi s’ha de propagar ràpidament. La consulta directa serveix quan la resposta necessita la font actual en aquell moment.
L’arquitectura real acostuma a combinar els tres models. Triar-ne un per a tot crea extrems innecessaris.
La integració també té impacte SEO i GEO
Els cercadors i motors d’IA necessiten contingut estable i accessible. Si els atributs de producte només apareixen després de crides privades o JavaScript que falla, la visibilitat se’n ressent. El PIM pot alimentar pàgines públiques estructurades mentre preus i condicions privades es resolen per compte.
Aquesta separació permet que una empresa sigui trobable per producte, aplicació i especificació sense exposar informació comercial sensible. L’article sobre capacitats d’un dealer portal B2B mostra com aquestes dades es converteixen en funcions per al client.
Checklist abans de connectar ERP, PIM i ecommerce
- Inventari de sistemes i propietaris.
- Font de veritat per domini de dades.
- Identificadors estables de producte, compte i comanda.
- Freqüència i direcció de cada sincronització.
- Política de reintents i idempotència.
- Estat degradat quan una dependència falla.
- Monitorització operativa i alertes.
- Pla de seguretat i rotació de credencials.
- Proves amb volums i casos reals.
- Procediment de reconciliació de dades.
A CODE B2B Commerce tractem la integració com a part del producte, no com una fase tècnica posterior. El portal només pot oferir una experiència fiable si l’arquitectura de dades ho permet.
Preguntes freqüents sobre ERP, PIM i ecommerce B2B
L’ecommerce ha de consultar sempre l’ERP en temps real?
No. Depèn de la dada i de la promesa al client. Preus o crèdit poden requerir molta actualitat; altres atributs poden sincronitzar-se de manera periòdica.
Quines dades hauria de governar el PIM?
Habitualment atributs enriquits, taxonomia, relacions, traduccions i documentació de producte. La distribució exacta depèn del stack i dels equips responsables.
Què és la idempotència en una integració ecommerce?
És la capacitat de processar una operació repetida sense duplicar l’efecte. Si una comanda s’envia dues vegades per un reintent, l’ERP hauria de crear una sola ordre.
Com s’evita que una caiguda de l’ERP tombi el portal?
Desacoblant operacions quan sigui possible, utilitzant memòries cau o cues i definint un estat degradat. La interfície ha de saber quines funcions pot mantenir de manera segura.
Reconciliació: comprova que els sistemes continuen explicant la mateixa història
A més de monitoritzar errors individuals, programa reconciliacions periòdiques. Compara comandes creades al portal amb comandes rebudes a l’ERP, productes actius al PIM amb productes publicats i comptes habilitats amb les seves condicions comercials. Una integració pot “funcionar” tècnicament i, tot i això, acumular diferències silencioses. La reconciliació detecta aquestes desviacions abans que les trobi un client.