
Precisió de l'inventari multicanal: font única d'estoc
perBruno Galo · Publicat el 22 de febr. 2026
Actualitzat el 12 d’ag. 2026
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ó.
- Oracle NetSuite, documentació de gestió d'inventari i de compromisos — https://docs.oracle.com/en/cloud/saas/netsuite/
- APICS / ASCM, orientacions sobre precisió dels registres d'inventari i recomptes cíclics — https://www.ascm.org
- IFRS Foundation, IAS 2 Inventories — mesura i valoració — https://www.ifrs.org
- APQC, Open Standards Benchmarking — indicadors de cadena de subministrament i inventari — https://www.apqc.org
- Experiència d'Atypical Tech en projectes d'implantació multicanal al mid-market ibèric

Comentaris
Encara no hi ha comentaris.
Deixa un comentari
El teu comentari es revisarà abans de publicar-se.
Responsable: Atypical Tech S.L. Finalitat: respondre la teva consulta. Base jurídica: el teu consentiment. Drets: accés, rectificació, supressió i els altres descrits a la política, escrivint a hello@atypicaltech.com.