← Torna al blog
Precisió de l'inventari multicanal: font única d'estoc
Ecommerce i Order-to-Cash

Precisió de l'inventari multicanal: font única d'estoc

perBruno Galo · Publicat el 22 de febr. 2026

Actualitzat el 12 d’ag. 2026

Disponible enCatalàEnglishEspañolPortuguês

Una empresa que ven a través d'una botiga en línia, dos marketplaces i un equip comercial té quatre sistemes que creuen saber, cadascun, quantes unitats hi ha disponibles. Cap no s'equivoca en el moment en què se li pregunta. Tots s'equivoquen uns segons després.

L'instint és resoldre-ho amb una sincronització més ràpida: enviar els nivells d'estoc a cada canal amb més freqüència, reduir l'interval, acostar-se al temps real. Això ajuda amb volums baixos i falla exactament en el moment en què importa, perquè el problema no és la latència. Dos canals poden vendre l'última unitat dins del mateix segon, i cap freqüència de sincronització no ho evita. El que sí que ho evita és decidir, en un sol lloc, qui està autoritzat a prometre una unitat.

La majoria dels incidents de sobrevenda que investiguem al mid-market es remunten a una arquitectura en què la disponibilitat es publica als canals però mai no és reservada per ells. Als canals se'ls diu què existeix en lloc d'assignar-los què poden vendre.

Per què això importa

La sobrevenda té un cost asimètric. Una ruptura d'estoc que impedeix una venda costa el marge d'aquella venda. Una sobrevenda que cobra els diners d'un client i després no pot servir costa el marge, la gestió de la devolució, la confiança del client i —als marketplaces— una mètrica de rendiment que afecta el seu posicionament i, si es deteriora prou, la seva capacitat de vendre-hi. Els dos errors no són comparables, i per això la lògica de disponibilitat hauria de ser deliberadament conservadora en lloc d'estar optimitzada per a l'exposició màxima.

Subestimar la disponibilitat té el seu propi cost acumulatiu, i és el que les empreses toleren en silenci. Un buffer mantingut a tots els canals per evitar la sobrevenda és estoc que no es pot vendre enlloc. Aplicat a un catàleg ampli representa una quantitat material de capital circulant que no produeix res i, com que mai no es manifesta com una fallada, ningú no el revisa.

I després hi ha la dimensió comptable. Un inventari sobre el qual els sistemes no es posen d'acord és un inventari amb una valoració incerta, cosa que apareix al tancament de l'exercici quan l'auditor pregunta per què difereixen els registres permanents i el recompte físic. La precisió de l'inventari per canal és un control financer, no només una comoditat operativa.

D'un cop d'ull: els quatre estats en què pot ser l'estoc

Estat Significat Qui el pot modificar Fallada habitual
Existències físiques Presents físicament i comptades Només el magatzem Es tracten com a disponibles i es publiquen als canals
Reservat Compromès amb una comanda concreta o amb una assignació de canal El motor de reserves, a petició No es modela en absolut: la causa arrel de la majoria de les sobrevendes
Disponible per prometre Existències físiques menys reservat, menys buffer Només derivat, mai editat Cada canal el calcula de manera diferent
En trànsit En una ordre de compra amb data prevista Compres Es publica com a disponible abans d'existir

La segona fila és la que ometen la majoria dels sistemes del mid-market. Sense un estat de reserva, «disponible» és un número calculat a partir de l'històric i no una promesa que algú estigui sostenint, i cada canal és lliure de vendre la mateixa unitat.

Què funciona i sobre què cal ser honest

Què funciona:

Un sol sistema és propietari de la disponibilitat, i és l'ERP. No la botiga en línia, no el connector del marketplace, no un full de càlcul que manté el responsable d'assortiment. La disponibilitat es deriva en un únic lloc a partir d'existències físiques, reservat i buffer, i cada canal consumeix aquesta derivació en lloc de calcular la pròpia.

Reserva en el moment del compromís, no en el de la preparació i enviament. Quan un canal rep una comanda, sol·licita una reserva i obté un sí o un no. Aquest és el mecanisme que fa segura la venda concurrent, i és la diferència entre publicar informació i assignar estoc.

Un enviament gairebé en temps real amb la reserva com a xarxa de seguretat. Actualitzi els canals amb prou freqüència perquè la disponibilitat mostrada sigui raonablement correcta, i confiï en la reserva per evitar el cas límit. Això és més robust que perseguir el temps real pur i considerablement més econòmic d'operar.

Buffers deliberats, diferenciats i revisats. Un buffer sobre un article d'alta rotació amb reposició setmanal és una decisió diferent d'un buffer sobre un article de baixa rotació amb dotze setmanes de termini de lliurament. Aplicar un únic percentatge a tot el catàleg és la manera més habitual com les empreses immobilitzen capital circulant sense adonar-se'n.

Recomptes cíclics en lloc de recomptes anuals. El recompte continu ponderat per valor i moviment manté fiable la xifra d'existències físiques sense tancar el magatzem. Un agent que assenyali les desviacions que superin determinats llindars —i que detecti patrons que apuntin a un problema sistemàtic en lloc d'un error puntual de recompte— fa que això sigui sostenible amb la plantilla d'una empresa mid-market.

Sobre què cal ser honest:

Els marketplaces no sempre respectaran el seu model. Alguns mantenen la seva pròpia disponibilitat, apliquen la seva pròpia lògica o imposen una latència que vostè no controla. Està gestionant l'exposició, no eliminant-la, i la mitigació pràctica és un buffer més gran específicament en aquests canals: acceptar un cost de capital circulant a canvi de protegir una mètrica de rendiment.

La precisió física és el terra, i cap arquitectura no l'apuja. Si les existències físiques són errònies per errors de picking, danys no registrats o entrades comptabilitzades amb retard, tots els números derivats són erronis. Les empreses intenten sovint resoldre un problema de disponibilitat que en realitat és un problema de disciplina de magatzem.

El multimagatzem ho complica de manera substancial. Quan l'estoc és en diverses ubicacions, la disponibilitat depèn de quina ubicació pot servir quin canal dins del termini de lliurament promès. Això és una política d'assignació, no una estructura de dades, i cal decidir-la explícitament.

Els kits, els paquets i els conjunts trenquen la lògica ingènua. La disponibilitat d'un paquet és una funció dels seus components, i els components normalment també es venen individualment. Això cal modelar-ho deliberadament o el paquet sobrevendrà el seu component més escàs.

Una certa sobrevenda és comercialment acceptable. En un article de reposició ràpida en què un dia de retard és tolerable, una taxa petita de sobrevenda pot ser més econòmica que el buffer necessari per eliminar-la. Això hauria de ser una decisió valorada, no un accident.

Marc de decisió: dissenyar la disponibilitat

Recorri'l en ordre. Aturi's a la primera coincidència.

1. És fiable la seva xifra d'existències físiques?
Si no ho és, comenci pel magatzem: disciplina en la confirmació d'entrades i de picking, recomptes cíclics, investigació de desviacions. Cap disseny de disponibilitat no sobreviu a una xifra d'existències físiques poc fiable.

2. Modela vostè ni tan sols un estat de reserva?
Si no, aquesta és la solució. Reserva en el compromís, alliberada en cas de cancel·lació o de caducitat, visible en el càlcul de la disponibilitat. És l'únic canvi que resol la major part de la sobrevenda.

3. Hi ha un sol sistema propietari del càlcul de la disponibilitat?
Si els canals calculen el seu propi, consolidi. Una única derivació, consumida per tots els canals, sense que cap canal la pugui editar.

4. Són els seus buffers deliberats i diferenciats?
Si s'aplica un únic percentatge generalitzat, revisi'l per rotació de l'article, termini de lliurament i risc del canal. Això normalment allibera capital circulant de manera immediata i és una de les poques intervencions d'aquesta llista amb un efecte directe en el balanç.

5. Ven paquets, kits o conjunts?
Modeli explícitament la disponibilitat derivada dels components abans d'estendre qualsevol altra cosa, o la resta del disseny quedarà minada pels productes amb més probabilitat de decebre un client.

6. Manté estoc en més d'una ubicació que serveixi el mateix canal?
Defineixi la política d'assignació —quina ubicació serveix quin canal i sota quines condicions— abans d'optimitzar res més. L'ambigüitat aquí produeix simultàniament sobrevendes i buffers innecessaris.

7. Tot l'anterior i encara hi ha sobrevenda?
El residu és gairebé segurament latència del marketplace que vostè no controla. Gestioni-la amb buffers específics per canal i monitoritzi l'exposició, en lloc d'esperar eliminar-la pel disseny.

Cost i esforç indicatius

Línia de treball Termini habitual Perfil d'esforç
Programa de precisió de magatzem i recomptes cíclics 6–14 setmanes Mitjà: disciplina operativa
Disseny i implantació del model de reserves 5–10 setmanes Mitjà: canvi estructural
Consolidació del càlcul de disponibilitat a l'ERP 4–8 setmanes Mitjà
Revisió i diferenciació de la política de buffers 2–4 setmanes Lleuger, retorn directe en capital circulant
Modelatge de la disponibilitat de paquets i kits 3–6 setmanes Mitjà
Política i configuració d'assignació multimagatzem 4–8 setmanes Mitjà
Publicació als canals i monitoratge 3–6 setmanes Mitjà
Agent de detecció de desviacions 3–6 setmanes Mitjà

Pressuposa una única instància d'ERP i fins a quatre canals de venda. Ubicacions addicionals, logística de tercers o un ús intensiu de paquets allarguen aquests terminis. Sol·liciti un pressupost per a una estimació delimitada.

Preguntes freqüents

La disponibilitat s'ha d'enviar als canals o l'han de consultar ells?
Enviï-la per a la visualització, de manera que el client vegi alguna cosa raonablement exacta sense penalització de latència a cada càrrega de pàgina. Consulti-la —una sol·licitud de reserva en directe— en el moment del compromís, on la correcció importa. Combinar-les d'aquesta manera és més robust que qualsevol de les dues per separat.

Quina mida ha de tenir un buffer?
Derivi-la del termini de reposició, la variabilitat de la demanda i el cost d'una ruptura d'estoc davant el d'una sobrevenda per a aquell article i aquell canal. Una xifra generalitzada per a tot el catàleg sempre és errònia en les dues direccions alhora: massa gran en els articles d'alta rotació, massa petita en els volàtils.

Necessitem un sistema dedicat de gestió de comandes?
Normalment no a escala mid-market, si l'ERP pot mantenir reserves i derivar la disponibilitat. Una capa independent de gestió de comandes justifica el seu cost amb molts canals, diverses ubicacions de preparació i enviament i regles d'assignació complexes, però també es converteix en un altre sistema amb la seva pròpia visió de l'estoc, que és el problema del qual va partir.

Com gestionem les prevendes i l'estoc en trànsit?
Com un tipus de promesa diferent, amb la seva pròpia data, mai integrat en el disponible per prometre. Vendre estoc en trànsit és una decisió comercial legítima; publicar-lo com si fossin existències físiques és la manera d'incomplir compromisos de lliurament.

Quin és un objectiu de precisió realista?
Mesuri dues coses per separat —la precisió física davant els recomptes cíclics i la taxa de sobrevenda per canal— i fixi objectius a partir de la seva pròpia línia de base. Una única xifra de «precisió de l'inventari» confon un problema de disciplina de magatzem amb un problema d'arquitectura de disponibilitat, i tenen responsables diferents i solucions diferents.

Tancament — Propers passos

Els problemes d'inventari per canal es presenten com a fallades de sincronització i gairebé sempre són fallades de reserva. La pregunta que val la pena fer-se no és amb quina freqüència es publiquen els nivells d'estoc, sinó si alguna cosa en el sistema sosté una promesa quan un client es compromet —i, si és el cas, quin sistema, i si tots els canals la respecten.

Un diagnòstic que es fa en una tarda: durant una setmana, registri cada sobrevenda i cada comanda cancel·lada per manca d'estoc, amb el canal i l'article. Després comprovi quin buffer té aquell article. El patró li dirà si té un problema de reserves, un problema de precisió física o una política de buffers que li costa més que les sobrevendes que evita.

Sobre l'autor

Bruno Galo és el fundador d'Atypical Tech, una consultora NetSuite que treballa amb clients mid-market a tota la península Ibèrica. Està especialitzat a connectar sistemes CRM i ERP per aconseguir fluxos d'order-to-cash sense friccions, i a construir processos automatitzats de gestió de comandes que eliminen la introducció manual de dades entre els equips comercials i financers. Com a partner oficial d'implementació de Stacksync, Bruno dissenya i desplega agents d'IA sobre plataformes d'integració per gestionar l'encaminament d'excepcions, el processament de documents i la conciliació, convertint fluxos de comandes fragmentats en sistemes fiables i capaços de supervisar-se ells mateixos.

LinkedIn: https://www.linkedin.com/in/brunogd

Fonts

Els URL són a nivell d'editor i s'han de verificar abans de la publicació.

Comentaris

Encara no hi ha comentaris.

Deixa un comentari

El teu comentari es revisarà abans de publicar-se.

An unhandled error has occurred. Reload 🗙