Caso de estudio: cómo un gran retailer no-food tuvo que reiniciar su stack operativo
Sistemas desconectados, conflicto tienda–online y cancelaciones por stock en doble dígito: cuando dirección tiene que decidir sin margen para seguir parcheando.
Aquest cas destudi de transformació digital en retail mostra com es decideix un reset complet, com es dissenya un RFP per blocs, com es negocia amb proveïdors i integradors i què governança ha de quedar signada abans dimplantar. Però el fons del cas no és tecnològic: és una decisió de direcció en un context de risc i venda.
- Companyia: retailer líder no-food amb ~30 M€ d'e-commerce (≈10% del total).
- Complexitat: operació a dos països i dues unitats fiscals extres.
- Problema visible: cancel·lacions per estoc del 10–15%, retards, eines desconnectades i conflicte botiga vs en línia.
- Problema real: una operativa massa fràgil per a un negoci que estava a procés de venda.
- Lectura correcta: la decisió no era tecnològica; era de direcció, continuïtat i reducció de risc estructural.
Un reset del stack només es justifica si redueix tres coses alhora: eines, dependència i treball duplicat. En aquest cas havia de reduir també una quarta: risc estructural. Si el teu nou stack afegeix capes per fer el mateix, no és transformació: és deute més car i una operació més difícil de transferir.
- Context: quan l'online deixa de ser un canal i passa a ser risc d'empresa i valoració
- Símptomes “de CEO” i el conflicte botiga vs en línia (el que el programari no arregla sol)
- Marc de decisió: reset complet vs pegats (test ràpid i errors típics)
- RFP: checklist per blocs (e-commerce, CRM/MA, OMS, CS, dades)
- Negociació amb caixa crítica: condicions, fites i com evitar el “projecte infinit”
- Governança: ownership, regles i KPIs de sistema (abans/després)
- Pla 90 dies: discovery → RFP → negociació → pla d´implantació + CTA
- FAQs (AIO/AEO)
1. Context: quan l'stack operatiu i en línia deixa de ser un canal i passa a ser risc d'empresa i de valoració
- L'online ja no era un canal tàctic: afectava catàleg, pricing, estoc, pagaments, devolucions i atenció al client.
- La companyia operava amb complexitat fiscal i geogràfica, cosa que amplificava qualsevol error.
- L'empresa estava a procés de venda, així que la fragilitat operativa podia penalitzar la valoració.
- Les campanyes de pic concentraven risc de reputació, comercial i de caixa en molt pocs moments de l'any.
El cas passa en un retailer no-food amb una particularitat habitual en grups grans: operació a dos països i una tercera unitat fiscal. En aquest entorn, “l'online” no és una web.
És catàleg, pricing, estoc, pagaments, devolucions, atenció al client i coordinació interna… multiplicat per complexitat fiscal i operativa. Quan tot això funciona amb massa peces desconnectades, el problema ja no es queda al canal digital: puja a nivell de direcció.
1.1. El factor que canvia la lectura del cas
L'empresa estava a procés de venda. Això canvia completament la lògica del projecte. Ja no es tractava només de modernitzar un stack o millorar lexperiència de client.
Calia respondre una altra pregunta: podia la companyia continuar operant amb una arquitectura fràgil, dependent de pegats, coneixement dispers i treball duplicat sense deteriorar valor?
En un context de M&A, un comprador no adquireix només vendes actuals. Compra la futura capacitat de sostenir-les amb un nivell raonable de risc. Si el canal digital depèn de massa excepcions, massa persones clau i massa arranjaments manuals, el problema no és només operatiu: és estructural.
1.2. L'entorn de mercat no ajudava
El moment de mercat tampoc no ajudava: caiguda de demanda post-COVID, inflació i pressió de costos, i competidors més digitals. L'efecte real no és només “abaixa el trànsit”.
El que passa és una mica més exigent: els clients comparen amb estàndards diferents. Esperen disponibilitat fiable, terminis creïbles i atenció al client que resolgui sense marejar. Quan l'operació no pot sostenir això de manera consistent, la conseqüència no és només comercial: augmenta el risc percebut sobre la qualitat del negoci.
1.3. L'estacionalitat concentrava el risc
Les campanyes clau eren rebaixes (dos grans), Setmana Santa i Black Friday. Si falles en una d'aquestes finestres, no només perds vendes.
Danyes reputació, dispares incidències, tensions botigues i atenció al client, i generes una bola operativa que consumeix setmanes. En una empresa en venda, aquesta lectura encara és més dura: cada bec mal executat amplifica la percepció de fragilitat.
En pics de campanya, un error de pricing o de disponibilitat es converteix en: devolucions, tiquets, trucades, reclamacions, tensió amb botigues, pèrdues de productivitat i, en casos, sancions o conflictes reguladors. El cost real no està en “un bug”, és a l'efecte dòmino en caixa i reputació. En aquest cas hi havia a més una derivada addicional: aquest efecte dòmino també afectava la transferibilitat estructural del negoci.
- Creure que “la tecnologia” arregla el conflicte botiga vs en línia sense tocar incentius i SLAs interns.
- Confondre inventari d'eines amb “stack”: si ningú no és owner, no hi ha govern.
- Entrar a un reset sense línies vermelles (no parar vendes, dades exportables, control de canvis, etc.).
- Llegir el problema com un projecte digital aïllat, quan en realitat afecta operació, caixa i valoració.
2. Símptomes “de CEO” i el conflicte botiga vs online (cosa que el programari no arregla sol)
- Campanyes que no s'executaven amb la fiabilitat esperada.
- Disponibilitat difícil d'explicar i encara pitjor de sostenir.
- Atenció al client saturada per incidències evitables.
- Equips treballant duplicat per contenir errors.
- Dependència excessiva de desenvolupament per a canvis operatius normals.
Els símptomes que disparen una decisió de reset no solen presentar-se com a problema tècnic. Arriben a comitè amb un altre llenguatge: “no es pot executar”, “això torna a fallar”, “no tenim visibilitat”, “cada campanya genera incidències”. En aquest cas, l'stack anterior obligava a dependre de programadors fins i tot per a canvis operatius habituals. Això no només alentia el negoci. També ho feia més dependent, més fràgil i més difícil de governar.
En un context de venda, aquest matís importa molt. Una empresa que necessita massa intervenció per operar tasques corrents transmet un senyal incòmode: el negoci funciona, però no està prou ordenat per escalar o transferir-se amb tranquil·litat. El símptoma visible era operatiu. El problema de fons era estructural.
2.1. Símptomes visibles sense ser tècnic
- Impossibilitat de modernitzar: eines actuals no es connecten bé amb la web i el seu middleware.
- Campanyes complexes = errors: promocions i pricing amb dependències creuades.
- Base de dades “bruta”: sense CRM real, sense segmentació fiable, sense automatització.
- Customer Service tradicional: mail/telèfon, sense plataforma de casos ni vista 360.
- Cancel·lacions per estoc i frustració del client per disponibilitat tardana (es descobreix a checkout).
- Analítica inútil: esdeveniments mal mesurats, tags sense govern, traçabilitat trencada.
Cap d'aquests símptomes és “només digital”. Tots apunten al mateix: massa dependència, massa excepció manual i massa risc operatiu per a un negoci que necessitava ser més defensable. Quan el canal en línia exigeix tanta intervenció per sostenir el que és bàsic, la companyia perd capacitat de decisió i continuïtat futura.
El moment gallet va ser una campanya forta d'estiu amb combinació letal: problemes de comunicació, estoc i errors de pricing que van obligar a tornar imports ia gestionar incidències massives. Aquest episodi no crea el problema; ho fa visible, mesurable i innegable.
Això és precisament el que solen fer els pics de campanya en negocis tensos: no inventen la fragilitat, l'exposen. I quan aquesta exposició coincideix amb un procés de venda, el dany no és només a l'operativa del moment. És que la direcció ja no pot continuar defensant que es tracta d'incidències aïllades.
2.2. El conflicte botiga vs online: si no l'ataques, l'OMS només automatitza el caos
- Disponibilitat “fantasma”: el sistema promet més del que loperació pot complir.
- Incentius desalineats: la botiga suporta treball extra sense percebre retorn clar.
- Preparació inconsistent: cada excepció es resol de manera diferent.
En aquest cas, no hi havia política d'estoc centralitzat. La disponibilitat depenia de la botiga més propera, per zones. Això, ben dissenyat, pot funcionar. Mal dissenyat, et trenca el canal online per tres fronts: disponibilitat “fantasma”, incentius desalineats i preparació inconsistent.
Aquest punt és clau perquè moltes companyies llegeixen el problema com si fos una eina, quan en realitat és de model operatiu. Un OMS pot ordenar fluxos, estats i excepcions. El que no pot fer per si mateix és corregir un sistema en què cada àrea interpreta el canal en línia segons el seu propi interès.
El conflicte era real: una venda en línia podia percebre's a la botiga com “stock que jo no venc” + “treball extra” + “zero retorn en variable”. Resultat: retards, rebutjos tàcits i operativa erràtica. Un CEO ha d'assumir això: la fricció interna competeix contra la teva conversió.
En clau de M&A, això també té una lectura pròpia. Un comprador pot acceptar complexitat. El que penalitza de debò és trobar una operació on massa coses depenen de la bona voluntat, acords informals o compensacions no resoltes entre àrees. Això no és només ineficiència: és fragilitat de govern.
1) KPI compartit (compliment de comandes en línia assignades).
2) SLAs interns per botiga/zona (preparació, incidències, rebuig).
3) Traçabilitat: cada excepció té motiu, responsable i conseqüència operativa.
Si això no existeix, el teu canal en línia depèn de la bona voluntat.
- Intentar “convèncer” a botiga amb comunicació, sense tocar incentius, SLAs i ownership.
- Assumir que el stock per zones és el problema. El problema sol ser la governança del model.
- No dissenyeu el Customer Service com a part de l'stack: sense vista 360, cada incidència es multiplica.
- Creure que implantar un OMS resol el conflicte per si mateix, quan en realitat pot escalar més ràpidament el mateix caos.
3. Marc de decisió: reset complet vs pegats (test ràpid i errors típics)
- No era triar “tecnologia nova” davant de “tecnologia vella”.
- Era decidir si convenia continuar convivint amb una operació fràgil o reduir deute estructural.
- En un context de venda, el criteri incloïa transferibilitat, risc operatiu, caixa i capacitat de continuïtat futura.
L'error més car és decidir per fatiga (“estem farts”) o per moda (“tothom replataforma”). La decisió correcta es basa en una altra cosa: cost total de propietat, capacitat real d¿iteració, riscos operatius en pics i dependència interna. Si el pegat afegeix capes per “connectar” allò vell, normalment no estàs comprant flexibilitat: estàs comprant deute més sofisticat.
En aquest cas, a més a més, la decisió tenia una exigència extra. L'empresa no només necessitava operar millor. Necessitava fer-ho de manera més explicable, menys dependent i més governable en un context de M&A. Això obligava a mirar l'stack no com un problema aïllat d'IT, sinó com una peça de la qualitat estructural del negoci.
3.1. Quan un pegat té sentit (i quan no)
Pegar per guanyar temps
Pegar pot ser el correcte si el core és extensible i tens ownership: APIs reals, integracions mantenibles, equips que coneixen el stack i un problema acotat. En aquest cas, el pegat actua com a palanca tàctica sense comprometre la base.
Pegar per sostenir una base fràgil
Petar deixa de tenir sentit quan depens d'hores de programació per operar el que és bàsic i quan cada nova eina obliga a inventar connectors que ningú documenta. Aquí el pegat ja no redueix risc: el desplaça i ho acumula.
La diferència és crítica. Un pegat raonable compra temps. Un pegat mal plantejat compra dependència. En un negoci que es prepara per a una possible transmissió, aquesta diferència pesa perquè un comprador pot acceptar complexitat, però difícilment acceptarà una estructura que només funciona gràcies a coneixement tàcit, integració artesanal i treball duplicat.
La pregunta no és “podem seguir així uns mesos més?”. La pregunta útil és una altra: Cada mes addicional amb aquesta arquitectura millora o empitjora la capacitat futura del negoci per operar amb menys risc i menys dependència? Si la resposta és que el deute creix, el reset deixa de ser una opció estètica i passa a ser una decisió de govern.
3.2. Test CEO en 5 preguntes (si contestes “sí” a 3, el reset és probable)
- Depenem de programadors per operar promocions, pricing, enviaments o checkout sense trencar coses?
- Tenim 15–20+ eines sense inventari, sense owner i sense regles d'alta/baixa?
- Cancel·lem per estoc o indisponibilitat per sobre de ~5% de forma sostinguda (aquí era 10–15%)?
- Dupliquem feina entre ERP i web (i això provoca errors humans recurrents)?
- Serem competitius en 12–18 mesos amb l'stack actual, sense deute creixent?
Aquest test no pretén simplificar una decisió complexa, però sí que ordenar la conversa. Si diverses respostes són afirmatives, el problema poques vegades està en una funcionalitat concreta. Sol estar en la combinació de dependència, baixa governança, opacitat operativa i cost ocult de mantenir allò existent.
3.3. Matriu simple: pegats vs reset (el que estàs comprant)
Guanyar temps
Reduir dolor puntual sense tocar larquitectura. Serveix si el core és sòlid i l'equip té ownership.
Eliminar deute
Reduir eines, dependència i duplicitat. Justifiqueu l'esforç si la base actual és inflexible i fràgil.
Deute acumulat
Més connectors, més fricció, més “treball duplicat”, i cada campanya es converteix en un projecte.
Bloqueig intern
La tecnologia avança més ràpidament que l'organització. Si no hi ha ownership i comitès, l?integrador es queda sol.
Actiu més difícil de defensar
La companyia continua depenent d'excepcions, pegats i coneixement dispers, cosa que redueix claredat i transferibilitat.
Estructura més governable
Permet ordenar ownership, regles i dades mestres per reduir fragilitat operativa i sostenir continuïtat futura.
Arquitectura extensible
APIs, QA, analítica governada i documentació. Si no n'hi ha, el pegat afegeix fragilitat.
Governança signada
RACI, regles de dades, control de canvis i KPIs de sistema. Sense això, el reset repeteix el caos amb eines noves.
La matriu ajuda a evitar un parany habitual: pensar que “reset” equival a valentia i “pegat” equival a prudència. No sempre és així. De vegades el pegat és la decisió més assenyada. I altres vegades és simplement una manera de retardar una decisió incòmoda. En aquest cas, continuar acumulant capes sobre un stack fràgil augmentava el risc operatiu i mantenia oberta una font de deteriorament just quan l?empresa necessitava ser més sòlida i més defensable.
- Decidir “suite única” sense validar killers (multi-magatzem real, integracions i cost total).
- No fixar línies vermelles: no aturar vendes, exportabilitat de dades, independència operativa, fites de MVP.
- Subestimar la duplicitat ERP/web: és lorigen derrors més cars en pricing i promocions.
- Confondre urgència operativa amb criteri estratègic: no tot dolor exigeix reset, però tampoc qualsevol pegat protegeix valor.
4. Mini-RFP: checklist per blocs (e-commerce, CRM/MA, OMS, CS, dades)
- No es buscava un RFP de 200 pàgines, sinó un que permetés decidir.
- Primer es defineixen MUST i killers; el backlog complet ve després.
- L'objectiu és separar ràpid opcions viables de demostracions boniques.
- Condició estructural del cas: no hi hauria estoc centralitzat; l'OMS havia de respectar el model per zones.
Un RFP infinit no ajuda a decidir: ajuda a perdre control. L'experiència mostra que com més llarg és el document més fàcil és amagar els punts realment crítics. Per això aquí l'enfocament va ser un mini-RFP executiu: un checklist curt, enfocat a processos reals i als requisits que podien trencar el projecte si no es validaven des del principi.
El principi era simple: primer es decideix si una solució és viable; després s'amplia backlog per a delivery. En aquest cas, a més, el disseny havia de respectar una restricció important del negoci: l'estoc no se centralitzaria. L'arquitectura havia de funcionar amb un model per zones i botigues.
E-commerce
MUST
Operació diària per configuració (menys dependència de desenvolupament), estabilitat en pics, promocions governades, multipaís/unitat fiscal i connexió neta amb OMS i ERP.
KILLER
Independència real de programadors per a loperativa habitual.
OMS / Logística
MUST
Regles per zona, magatzem o botiga; estats de comanda end-to-end; excepcions traçables; integració obligatòria amb ERP i capacitat multi-magatzem demostrable.
KILLER
Multi-magatzem real (no “es pot fer amb desenvolupament”).
Customer Service
MUST
Gestió de casos, cues, SLAs, vista 360 de comanda/client i reporting operatiu. El CS havia de poder respondre “què passa amb aquesta comanda” sense dependre de tres departaments.
KILLER
Vista 360 del client i traçabilitat completa de la comanda.
CRM + Màrqueting Automation
MUST
Govern de consentiments, segmentació accionable i journeys amb regles antierrors: evitar impactes irrellevants, no mostrar preus inferiors després d'una compra recent i excloure clients amb incidències obertes.
KILLER
Dada utilitzable. Si la base està bruta, automatitzar només escala lerror.
4.1. Dades i integració: el requisit que evita el treball duplicat
Aquest va ser un dels requisits més importants perquè connecta directament negoci amb qualitat operativa: qualsevol canvi a l'ERP havia de reflectir-se automàticament a la web.
Si dos equips diferents gestionen preus o catàleg en sistemes diferents, lerror humà deixa de ser una possibilitat i passa a ser una certesa. La integració havia d'eliminar duplicitat manual i assegurar una única font de debò.
1) Definir dades mestres: qui mana en preu, estoc, comanda i catàleg.
2) Integració API-led (evitar integracions point-to-point no documentades).
3) Monitorització visible: errors dintegració accessibles per a negoci i IT.
4) GA4 des de zero amb esdeveniments i conversions definits amb negoci i QA de tagging.
- Confondre “demo bonica” amb “procés cobert”. Les demos han de reproduir processos crítics i excepcions.
- No validar killers (multimagatzem, cost real de llicències, integració amb ERP) abans de fer shortlist.
- Deixar analítica i tagging per al final: després ningú no confia en les dades i les decisions tornen a intuïció.
5. Negociació amb caixa crítica: condicions, fites i com evitar el “projecte infinit”
- No hi havia finançament extern per al projecte.
- L'empresa operava amb tensió de caixa habitual.
- El risc real de direcció era simple: arribar a final de mes amb nòmines i seguretat social.
- Per tant, la negociació no podia centrar-se només en preu: havia de protegir flux de caixa.
La restricció més dura del cas no era tècnica: era financera. Sense finançament extern, amb retallades habituals al final de mes, el projecte havia d'encaixar dins la realitat operativa de la companyia.
En aquest context, negociar “preu” és insuficient. La variable crítica passa a ser una altra: com es distribueix el cost en el temps i en quin moment apareix el valor.
Per això la negociació no es va plantejar com una discussió de tarifes, sinó com un disseny de condicions que protegissin caixa i apropessin la despesa al moment en què el sistema comencés a generar valor operatiu (MVP).
5.1. Palanques reals de negociació (sense fantasia)
Competència explícita
Competència real entre proveïdors per blocs i suite completa. Sense transmetre mai que la decisió estigués presa.
Shortlist reduïda
Pocs proveïdors a la fase final per augmentar pressió negociadora i permetre comparatives clares entre propostes.
Pagaments per fites
Pagaments lligats a lliurables concrets i validables, no a calendari ni a fases abstractes.
Llicències diferides
Apropar l'inici de pagament de llicències al moment de MVP per evitar mesos pagant sense retorn operatiu.
Compromís pluriennal
A canvi de compromisos de permanència, es van negociar preus per trams, ramp-up gradual i mòduls bonificats.
A més es va utilitzar una palanca que sí que existeix al món real però poques vegades s'esmenta: el valor comercial d'un cas d'èxit.
Per a certs proveïdors, implantar la seva tecnologia en un retailer tradicional de certa mida no és només un projecte. És també una referència comercial rellevant. Quan hi ha competència real i bon timing, aquest incentiu es pot convertir en concessions econòmiques o condicions més favorables.
5.2. Riscos típics en un reset (i com mitigar-los)
| Risc típic | Com et colpeja | Senyal primerenc | Mitigació pràctica |
|---|---|---|---|
| Vendor lock-in | Cost futur i poca sortida | Export de dades / APIs no clares | Clàusules de dades, documentació i APIs; pla de sortida definit |
| Dependència de l'integrador | Cada canvi = hores | “Pregunta'ls a ells” per a tot | Handover, formació, repositori i ownership intern per domini |
| Manca d'ownership | Ningú prioritza | Reunions sense decisió | RACI, weekly de priorització i steering mensual |
| Scope creep | Projecte interminable | “Ja que estem…” constant | MVP real + control de canvis + backlog prioritzat |
| Integració fràgil | Errors recurrents | Arranjaments manuals i duplicitat | API-led, monitorització i QA; ERP com a mestre definit |
| Conflicte botiga vs online | Sabotatge passiu | Retards i rebutjos | SLAs interns + KPI compartit + traçabilitat d'excepcions |
| Caixa insuficient | Aturs i retallades | “Es para fins a nou avís” | Pagaments per fites + llicències diferides + pla de cash del projecte |
- Negociar només descompte i no negociar pagaments per fites, ramp-up i llicències diferides.
- Deixar que l'integrador “dissenyi” la solució sense killers definits i sense comparativa real.
- Comprar mòduls que el negoci no pot absorbir (capacitat interna) i després culpar la tecnologia.
6. Governança: ownership, regles i KPIs de sistema (abans/després)
- El programari importa menys que les regles de govern que l'acompanyen.
- Sense ownership, qualsevol stack s'acaba degradant.
- Sense control de canvis, la complexitat torna encara que la tecnologia sigui nova.
- Sense KPIs de sistema, adreça perd visibilitat i el projecte es converteix en opinió.
La part que més autoritat dóna a un cas de replataforma no és “quin programari tries”. És el que deixes definit per evitar repetir el mateix caos amb eines noves.
Això implica fixar des del començament ownership, regles d'eines, dades mestres, control de canvis i rituals de decisió. Si aquests elements no queden definits, el nou stack tendeix a degradar-se amb el temps.
En aquest cas, es van definir responsables amb nom i cognoms per domini. Negoci i tecnologia tenien responsabilitats diferents i explícites. Aquesta separació evita un dels problemes més habituals en aquest tipus de projectes: que ningú no sàpiga realment qui decideix.
6.1. Rituals i estructura mínima (sense burocràcia)
Daily
Revisió de bloquejos reals, incidències crítiques i decisions operatives ràpides.
Weekly de priorització
Revisió de backlog, canvis i riscos amb responsables definits.
Steering mensual
Revisió de KPIs de sistema i decisions estratègiques. No és cap reunió d'estat: és un fòrum de decisió.
Control de canvis
Pricing, promocions, checkout i regles de OMS passen per QA i finestres de desplegament definides.
6.2. KPIs de sistema (per a adreça, no només per a IT)
- Permeten a adreça veure la salut real del sistema.
- Separen problemes de tecnologia de problemes doperació.
- Eviten que el projecte s'avaluï per percepcions.
6.3. Què canvia realment a l'operació (abans vs després)
| Àrea | Abans | Després |
|---|---|---|
| Inventari | Disponibilitat tardana i dependent de middleware | OMS multi-magatzem per zones + estats i excepcions traçables |
| Pricing/Promos | Duplicitat i errors entre sistemes | ERP mestre + replicació + QA + control de canvis |
| Customer Service | Mail/telèfon, sense traçabilitat | Casos + cues + SLAs + vista 360 |
| Màrqueting | Sense automation real i base de dades bruta | CRM/MA amb regles anti-errors i segmentació accionable |
| Eines | 20+ satèl·lits sense owner | Catàleg + owner + regles d'alta/baixa i integracions |
| Analítica | Tags sense govern i traçabilitat trencada | GA4 des de zero + esdeveniments + QA + naming estàndard |
| Decisió | Dependència de “qui sap” | RACI + comitès + decisions amb responsables |
1) No entra eina nova sense owner, cost, dada que toca i pla de baixa.
2) No hi ha canvis crítics sense QA i finestra de desplegament (pricing/promos/checkout).
3) ERP com a mestre definit i replicació sense duplicitat manual (menys error humà).
- Signar sense deixar lligat el model de suport, handover i documentació mínima.
- Deixar l'ownership per després: després no arriba, i l'integrador decideix per tu.
- No mesurar KPIs de sistema: adreça perd visibilitat i el projecte es converteix en opinió.
7. Pla 90 dies: discovery → RFP → negociació → pla d´implantació + CTA
- No implantar-ho tot, sinó decidir bé.
- Passar d'opinions a un inventari real de problemes, restriccions i killers.
- Deixar condicions, fites i governança lligats abans de construir.
- Reduir incertesa operativa i financera abans de comprometre més caixa.
Un reset complet no s'implanta al cap de 90 dies. Però sí que pots fer en 90 dies el que separa els projectes seriosos dels que s'encallen: inventari real, killers, decisió, condicions i governança lligada.
Aquest era lobjectiu aquí. No es tractava de “transformar” la companyia en tres mesos, sinó de deixar resolt el més important: què es faria, amb quins criteris, sota quines condicions i amb quines proteccions per no repetir els mateixos errors amb eines noves.
En un context de venda i caixa crítica això té una lògica clara. La companyia no es podia permetre un projecte infinit, una decisió sentimental ni una implantació que consumís mesos abans de demostrar valor. L'objectiu en 90 dies era sortir d'“opinions” i entrar a decisions executables.
7.1. Quick wins realistes (sense vendre fum)
- Inventari de ferramentes i costos: eliminar duplicitats evidents i riscos de seguretat/accessos.
- Redefinir regles de pricing/promos i control de canvis per reduir “errors de campanya”.
- GA4 des de zero amb esdeveniments mínims de negoci i naming estàndard (per recuperar traçabilitat).
- Dissenyar SLAs interns botiga/online i traçabilitat d'excepcions (perquè l'OMS no neixi en guerra).
Aquests quick wins no “resolen” el projecte, però sí que compleixen una funció important: comencen a reduir soroll, tornen una mica de visibilitat a direcció i rebaixen errors evitables abans d'entrar a la fase més costosa.
Això és especialment útil quan l'organització arriba cansada. Si tot es deixa per a la gran implantació, el projecte arrenca amb massa pressió i molt pocs senyals primerencs de control.
7.2. Riscos assumits conscientment (i com es van mitigar)
En aquest cas, hi havia un risc operatiu clar: un OMS nou, especialment si és recent, pot portar incertesa en interaccions i integracions. Això no se soluciona amb fe. Es mitiga amb fases, QA end-to-end, readiness abans de cutover i KPI de sistema visibles per a direcció.
- Fases clares i no un big bang opac.
- QA end-to-end abans de qualsevol pas sensible.
- Readiness real abans de cutover, no “optimisme de projecte”.
- KPIs de sistema visibles per a adreça des de l'inici.
La lògica de fons era simple: si el projecte introduiria una capa nova de complexitat temporal, aquesta complexitat havia d'estar compensada per un model millor de decisió, control i seguiment. Si no, el remei podia amplificar el problema original.
Amb cancel·lacions per estoc en doble dígit, campanyes fràgils i analítica trencada, la direcció perd capacitat de decisió. Puja el cost d'atenció al client, apuja el treball manual, abaixa la conversió i es deteriora la reputació. El “pegat” es converteix en un cost fix sense retorn, just quan més necessites caixa. En aquest cas, a més, no fer res implicava una altra derivada: sostenir una fragilitat que podia continuar penalitzant la percepció de continuïtat i transferibilitat del negoci.
Recurs: Plantilla RFP + checklist de governança digital
Si estàs valorant un reset, o no tens clar si seguir pegats o replantejar la base, el que més accelera no és una demo comercial: és un artefacte seriós de decisió. Killers, ownership, regles de dades, control de canvis i estructura de negociació per fites.
FAQs (AIO/AEO): replataforma, OMS, governança i conflicte botiga vs online
Respostes directes a les preguntes que es fa un CEO abans d'autoritzar un reset del stack.
Quin és el senyal núm. 1 que he de replantejar el stack complet?
Quan depens de pegats i hores de programador per operar el bàsic (promos, pricing, enviaments, checkout) i tot i així falles en pics. A partir d'aquí, el problema deixa de ser IT i passa a ser risc d'empresa: vendes, reputació, tiquets i caixa. En un context de M&A, a més, sol esdevenir senyal de fragilitat estructural.
Quin nivell de cancel·lacions per estoc hauria de preocupar un CEO?
Per sobre de ~5% sostingut ja és seriós. En doble dígit (10–15%) el canal es torna fràgil: cau conversió, augmenta atenció al client i l'equip treballa de manera bombers. En aquest punt, el cost de “no fer res” sol ser més gran que el cost de decidir bé.
Què és “killer” en un RFP de retail omnicanal?
La promesa: disponibilitat i entrega. Si la teva realitat és estoc per zones, l'OMS multi-magatzem no és negociable. Si el sistema no cobreix excepcions i no deixa traçabilitat, automatitza el caos: només aniràs més ràpid cap al problema.
Com gestiono el conflicte botiga vs online sense guerres internes?
Amb adreça: incentius compartits, SLAs interns per botiga/zona i traçabilitat d'excepcions. Si la botiga “perd” amb l'online, el canal es trenca des de dins. El programari ajuda, però no substitueix regles i incentius.
Què és no negociable si tinc un ERP corporatiu com a mestre?
Que no hi hagi duplicitat manual. Qualsevol canvi rellevant en ERP (preu, estoc, catàleg, condicions) s'ha de reflectir a web/OMS/CS sense “fer-ho dues vegades”. Aquesta duplicitat és la fàbrica derrors més rendible del retail.
Com es negocia quan la caixa és crítica?
Negocia condicions, no només preu: pagaments per fites, ramp-up, llicències diferides cap al MVP i compromís pluriennal amb preus per trams. Si pagues llicències mesos abans de generar valor, el risc financer es dispara.
Què he de deixar signat abans d'implantar per no repetir el caos?
RACI, model de suport, documentació obligatòria, handover i control de canvis (pricing/promos/checkout). A més, KPIs de sistema visibles per a adreça (cancel·lació per estoc, errors, SLAs de CS, exactitud de disponibilitat).
Què es pot fer de debò en 90 dies?
Decidiu bé i deixeu governança lligada: inventari real, killers, shortlist, condicions de pagament/licències i pla d'implantació amb MVP. No és “implantar-ho tot”, és evitar el projecte infinit i protegir caixa i operació.
👉 Si estàs valorant un canvi important (equip, canal, stack o model comercial), podem tornar-te un marc clar:
Què convé fitxar, què convé externalitzar i què convé executar per projecte, amb cost estimat i passos d'implementació.
T'avisem quan publiquem nous continguts?
Ens prenem seriosament el teu temps. Només us enviarem articles, guies o eines que us ajudin a millorar, decidir o actuar millor.
