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.
Publicado 12 de marzo de 2026 ·Empresa · Estrategia y Dirección.
Este caso de estudio de transformación digital en retail muestra cómo se decide un reset completo, cómo se diseña un RFP por bloques, cómo se negocia con proveedores e integradores y qué gobernanza debe quedar firmada antes de implantar. Pero el fondo del caso no es tecnológico: es una decisión de dirección en un contexto de riesgo y venta.
- Compañía: retailer líder no-food con ~30 M€ de e-commerce (≈10% del total).
- Complejidad: operación en dos países y dos unidades fiscales extras.
- Problema visible: cancelaciones por stock del 10–15%, retrasos, herramientas desconectadas y conflicto tienda vs online.
- Problema real: una operativa demasiado frágil para un negocio que estaba en proceso de venta.
- Lectura correcta: la decisión no era tecnológica; era de dirección, continuidad y reducción de riesgo estructural.
Un reset del stack solo se justifica si reduce tres cosas a la vez: herramientas, dependencia y trabajo duplicado. En este caso debía reducir también una cuarta: riesgo estructural. Si tu “nuevo stack” añade capas para hacer lo mismo, no es transformación: es deuda más cara y una operación más difícil de transferir.
- Contexto: cuando el online deja de ser un canal y pasa a ser riesgo de empresa y de valoración
- Síntomas “de CEO” y el conflicto tienda vs online (lo que el software no arregla solo)
- Marco de decisión: reset completo vs parches (test rápido y errores típicos)
- RFP: checklist por bloques (e-commerce, CRM/MA, OMS, CS, datos)
- Negociación con caja crítica: condiciones, hitos y cómo evitar el “proyecto infinito”
- Gobernanza: ownership, reglas y KPIs de sistema (antes/después)
- Plan 90 días: discovery → RFP → negociación → plan de implantación + CTA
- FAQs (AIO/AEO)
1. Contexto: cuando el stack operativo y online deja de ser un canal y pasa a ser riesgo de empresa y de valoración
- El online ya no era un canal táctico: afectaba catálogo, pricing, stock, pagos, devoluciones y atención al cliente.
- La compañía operaba con complejidad fiscal y geográfica, lo que amplificaba cualquier error.
- La empresa estaba en proceso de venta, así que la fragilidad operativa podía penalizar la valoración.
- Las campañas de pico concentraban riesgo reputacional, comercial y de caja en muy pocos momentos del año.
El caso ocurre en un retailer no-food con una particularidad habitual en grupos grandes: operación en dos países y una tercera unidad fiscal. En ese entorno, “el online” no es una web.
Es catálogo, pricing, stock, pagos, devoluciones, atención al cliente y coordinación interna… multiplicado por complejidad fiscal y operativa. Cuando todo eso funciona con demasiadas piezas desconectadas, el problema ya no se queda en el canal digital: sube a nivel de dirección.
1.1. El factor que cambia la lectura del caso
La empresa estaba en proceso de venta. Eso cambia completamente la lógica del proyecto. Ya no se trataba solo de modernizar un stack o mejorar la experiencia de cliente.
Había que responder a otra pregunta: ¿podía la compañía seguir operando con una arquitectura frágil, dependiente de parches, conocimiento disperso y trabajo duplicado sin deteriorar valor?
En un contexto de M&A, un comprador no adquiere solo ventas actuales. Compra la capacidad futura de sostenerlas con un nivel razonable de riesgo. Si el canal digital depende de demasiadas excepciones, demasiadas personas clave y demasiados apaños manuales, el problema no es solo operativo: es estructural.
1.2. El entorno de mercado no ayudaba
El momento de mercado tampoco ayudaba: caída de demanda post-COVID, inflación y presión de costes, y competidores más digitales. El efecto real no es solo “baja el tráfico”.
Lo que ocurre es algo más exigente: los clientes comparan con estándares distintos. Esperan disponibilidad fiable, plazos creíbles y atención al cliente que resuelva sin marear. Cuando la operación no puede sostener eso de forma consistente, la consecuencia no es solo comercial: aumenta el riesgo percibido sobre la calidad del negocio.
1.3. La estacionalidad concentraba el riesgo
Las campañas clave eran rebajas (dos grandes), Semana Santa y Black Friday. Si fallas en una de esas ventanas, no solo pierdes ventas.
Dañas reputación, disparas incidencias, tensionas tiendas y atención al cliente, y generas una bola operativa que consume semanas. En una empresa en venta, esa lectura es todavía más dura: cada pico mal ejecutado amplifica la percepción de fragilidad.
En picos de campaña, un error de pricing o de disponibilidad se convierte en: devoluciones, tickets, llamadas, reclamaciones, tensión con tiendas, pérdidas de productividad y, en casos, sanciones o conflictos regulatorios. El coste real no está en “un bug”, está en el efecto dominó en caja y reputación. En este caso había además una derivada adicional: ese efecto dominó también afectaba a la transferibilidad estructural del negocio.
- Creer que “la tecnología” arregla el conflicto tienda vs online sin tocar incentivos y SLAs internos.
- Confundir inventario de herramientas con “stack”: si nadie es owner, no existe gobierno.
- Entrar en un reset sin líneas rojas (no parar ventas, datos exportables, control de cambios, etc.).
- Leer el problema como un proyecto digital aislado, cuando en realidad afecta operación, caja y valoración.
2. Síntomas “de CEO” y el conflicto tienda vs online (lo que el software no arregla solo)
- Campañas que no se ejecutaban con la fiabilidad esperada.
- Disponibilidad difícil de explicar y peor aún de sostener.
- Atención al cliente saturada por incidencias evitables.
- Equipos trabajando duplicado para contener errores.
- Dependencia excesiva de desarrollo para cambios operativos normales.
Los síntomas que disparan una decisión de reset no suelen presentarse como un problema técnico. Llegan a comité con otro lenguaje: “no se puede ejecutar”, “esto vuelve a fallar”, “no tenemos visibilidad”, “cada campaña genera incidencias”. En este caso, el stack anterior obligaba a depender de programadores incluso para cambios operativos habituales. Eso no solo ralentizaba al negocio. También lo hacía más dependiente, más frágil y más difícil de gobernar.
En un contexto de venta, ese matiz importa mucho. Una empresa que necesita demasiada intervención para operar tareas corrientes transmite una señal incómoda: el negocio funciona, pero no está suficientemente ordenado para escalar o transferirse con tranquilidad. El síntoma visible era operativo. El problema de fondo era estructural.
2.1. Síntomas visibles sin ser técnico
- Imposibilidad de modernizar: herramientas actuales no se conectan bien con la web y su middleware.
- Campañas complejas = errores: promociones y pricing con dependencias cruzadas.
- Base de datos “sucia”: sin CRM real, sin segmentación fiable, sin automatización.
- Customer Service tradicional: mail/teléfono, sin plataforma de casos ni vista 360.
- Cancelaciones por stock y frustración del cliente por disponibilidad tardía (se descubre en checkout).
- Analítica inútil: eventos mal medidos, tags sin gobierno, trazabilidad rota.
Ninguno de estos síntomas es “solo digital”. Todos apuntan a lo mismo: demasiada dependencia, demasiada excepción manual y demasiado riesgo operativo para un negocio que necesitaba ser más defendible. Cuando el canal online exige tanta intervención para sostener lo básico, la compañía pierde capacidad de decisión y continuidad futura.
El “momento gatillo” fue una campaña fuerte de verano con combinación letal: problemas de comunicación, stock y errores de pricing que obligaron a devolver importes y a gestionar incidencias masivas. Ese episodio no crea el problema; lo hace visible, medible e innegable.
Eso es precisamente lo que suelen hacer los picos de campaña en negocios tensos: no inventan la fragilidad, la exponen. Y cuando esa exposición coincide con un proceso de venta, el daño no está solo en la operativa del momento. Está en que la dirección ya no puede seguir defendiendo que se trata de incidencias aisladas.
2.2. El conflicto tienda vs online: si no lo atacas, el OMS solo automatiza el caos
- Disponibilidad “fantasma”: el sistema promete más de lo que la operación puede cumplir.
- Incentivos desalineados: la tienda soporta trabajo extra sin percibir retorno claro.
- Preparación inconsistente: cada excepción se resuelve de forma distinta.
En este caso no había política de stock centralizado. La disponibilidad dependía de la tienda más cercana, por zonas. Eso, bien diseñado, puede funcionar. Mal diseñado, te rompe el canal online por tres frentes: disponibilidad “fantasma”, incentivos desalineados y preparación inconsistente.
Este punto es clave porque muchas compañías leen el problema como si fuera de herramienta, cuando en realidad es de modelo operativo. Un OMS puede ordenar flujos, estados y excepciones. Lo que no puede hacer por sí solo es corregir un sistema en el que cada área interpreta el canal online según su propio interés.
El conflicto era real: una venta online podía percibirse en tienda como “stock que yo no vendo” + “trabajo extra” + “cero retorno en variable”. Resultado: retrasos, rechazos tácitos y operativa errática. Un CEO debe asumir esto: la fricción interna compite contra tu conversión.
En clave de M&A, esto también tiene lectura propia. Un comprador puede aceptar complejidad. Lo que penaliza de verdad es encontrar una operación donde demasiadas cosas dependen de la buena voluntad, acuerdos informales o compensaciones no resueltas entre áreas. Eso no es solo ineficiencia: es fragilidad de gobierno.
1) KPI compartido (cumplimiento de pedidos online asignados).
2) SLAs internos por tienda/zona (preparación, incidencias, rechazo).
3) Trazabilidad: cada excepción tiene motivo, responsable y consecuencia operativa.
Si esto no existe, tu canal online depende de la buena voluntad.
- Intentar “convencer” a tienda con comunicación, sin tocar incentivos, SLAs y ownership.
- Asumir que el stock por zonas es el problema. El problema suele ser la gobernanza del modelo.
- No diseñar el Customer Service como parte del stack: sin vista 360, cada incidencia se multiplica.
- Creer que implantar un OMS resuelve el conflicto por sí solo, cuando en realidad puede escalar más rápido el mismo caos.
3. Marco de decisión: reset completo vs parches (test rápido y errores típicos)
- No era elegir “tecnología nueva” frente a “tecnología vieja”.
- Era decidir si convenía seguir conviviendo con una operación frágil o reducir deuda estructural.
- En un contexto de venta, el criterio incluía transferibilidad, riesgo operativo, caja y capacidad de continuidad futura.
El error más caro es decidir por fatiga (“estamos hartos”) o por moda (“todo el mundo replataforma”). La decisión correcta se basa en otra cosa: coste total de propiedad, capacidad real de iteración, riesgos operativos en picos y dependencia interna. Si el parche añade capas para “conectar” lo viejo, normalmente no estás comprando flexibilidad: estás comprando deuda más sofisticada.
En este caso, además, la decisión tenía una exigencia extra. La empresa no solo necesitaba operar mejor. Necesitaba hacerlo de una forma más explicable, menos dependiente y más gobernable en un contexto de M&A. Eso obligaba a mirar el stack no como un problema aislado de IT, sino como una pieza de la calidad estructural del negocio.
3.1. Cuándo un parche tiene sentido (y cuándo no)
Parchar para ganar tiempo
Parchar puede ser lo correcto si el core es extensible y tienes ownership: APIs reales, integraciones mantenibles, equipos que conocen el stack y un problema acotado. En ese caso, el parche actúa como palanca táctica sin comprometer la base.
Parchar para sostener una base frágil
Parchar deja de tener sentido cuando dependes de horas de programación para operar lo básico y cuando cada nueva herramienta obliga a inventar conectores que nadie documenta. Ahí el parche ya no reduce riesgo: lo desplaza y lo acumula.
La diferencia es crítica. Un parche razonable compra tiempo. Un parche mal planteado compra dependencia. En un negocio que se prepara para una posible transmisión, esa diferencia pesa porque un comprador puede aceptar complejidad, pero difícilmente aceptará una estructura que solo funciona gracias a conocimiento tácito, integración artesanal y trabajo duplicado.
La pregunta no es “¿podemos seguir así unos meses más?”. La pregunta útil es otra: ¿cada mes adicional con esta arquitectura mejora o empeora la capacidad futura del negocio para operar con menos riesgo y menos dependencia? Si la respuesta es que la deuda crece, el reset deja de ser una opción estética y pasa a ser una decisión de gobierno.
3.2. Test CEO en 5 preguntas (si contestas “sí” a 3, el reset es probable)
- ¿Dependemos de programadores para operar promociones, pricing, envíos o checkout sin romper cosas?
- ¿Tenemos 15–20+ herramientas sin inventario, sin owner y sin reglas de alta/baja?
- ¿Cancelamos por stock o indisponibilidad por encima de ~5% de forma sostenida (aquí era 10–15%)?
- ¿Duplicamos trabajo entre ERP y web (y eso provoca errores humanos recurrentes)?
- ¿Seremos competitivos en 12–18 meses con el stack actual, sin deuda creciente?
Este test no pretende simplificar una decisión compleja, pero sí ordenar la conversación. Si varias respuestas son afirmativas, el problema rara vez está en una funcionalidad concreta. Suele estar en la combinación de dependencia, baja gobernanza, opacidad operativa y coste oculto de mantener lo existente.
3.3. Matriz simple: parches vs reset (lo que estás comprando)
Ganar tiempo
Reducir dolor puntual sin tocar la arquitectura. Sirve si el core es sólido y el equipo tiene ownership.
Eliminar deuda
Reducir herramientas, dependencia y duplicidad. Justifica el esfuerzo si la base actual es inflexible y frágil.
Deuda acumulada
Más conectores, más fricción, más “trabajo duplicado”, y cada campaña se convierte en un proyecto.
Bloqueo interno
La tecnología avanza más rápido que la organización. Si no hay ownership y comités, el integrador se queda solo.
Activo más difícil de defender
La compañía sigue dependiendo de excepciones, parches y conocimiento disperso, lo que reduce claridad y transferibilidad.
Estructura más gobernable
Permite ordenar ownership, reglas y datos maestros para reducir fragilidad operativa y sostener continuidad futura.
Arquitectura extensible
APIs, QA, analítica gobernada y documentación. Si no existen, el parche añade fragilidad.
Gobernanza firmada
RACI, reglas de datos, control de cambios y KPIs de sistema. Sin eso, el reset repite el caos con herramientas nuevas.
La matriz ayuda a evitar una trampa habitual: pensar que “reset” equivale a valentía y “parche” equivale a prudencia. No siempre es así. A veces el parche es la decisión más sensata. Y otras veces es simplemente una forma de retrasar una decisión incómoda. En este caso, seguir acumulando capas sobre un stack frágil aumentaba el riesgo operativo y mantenía abierta una fuente de deterioro justo cuando la empresa necesitaba ser más sólida y más defendible.
- Decidir “suite única” sin validar killers (multi-almacén real, integraciones y coste total).
- No fijar líneas rojas: no parar ventas, exportabilidad de datos, independencia operativa, hitos de MVP.
- Subestimar la duplicidad ERP/web: es el origen de errores más caros en pricing y promociones.
- Confundir urgencia operativa con criterio estratégico: no todo dolor exige reset, pero tampoco todo parche protege valor.
4. Mini-RFP: checklist por bloques (e-commerce, CRM/MA, OMS, CS, datos)
- No se buscaba un RFP de 200 páginas, sino uno que permitiera decidir.
- Primero se definen MUST y killers; el backlog completo viene después.
- El objetivo es separar rápido opciones viables de demostraciones bonitas.
- Condición estructural del caso: no habría stock centralizado; el OMS debía respetar el modelo por zonas.
Un RFP infinito no ayuda a decidir: ayuda a perder control. La experiencia muestra que cuanto más largo es el documento, más fácil es esconder los puntos realmente críticos. Por eso aquí el enfoque fue un mini-RFP ejecutivo: un checklist corto, enfocado a procesos reales y a los requisitos que podían romper el proyecto si no se validaban desde el principio.
El principio era simple: primero se decide si una solución es viable; después se amplía backlog para delivery. En este caso, además, el diseño debía respetar una restricción importante del negocio: el stock no se centralizaría. La arquitectura tenía que funcionar con un modelo por zonas y tiendas.
E-commerce
MUST
Operación diaria por configuración (menos dependencia de desarrollo), estabilidad en picos, promociones gobernadas,
multi-país / unidad fiscal y conexión limpia con OMS y ERP.
KILLER
Independencia real de programadores para la operativa habitual.
OMS / Logística
MUST
Reglas por zona, almacén o tienda; estados de pedido end-to-end; excepciones trazables;
integración obligatoria con ERP y capacidad multi-almacén demostrable.
KILLER
Multi-almacén real (no “se puede hacer con desarrollo”).
Customer Service
MUST
Gestión de casos, colas, SLAs, vista 360 de pedido/cliente y reporting operativo.
El CS debía poder responder “qué pasa con este pedido” sin depender de tres departamentos.
KILLER
Vista 360 del cliente y trazabilidad completa del pedido.
CRM + Marketing Automation
MUST
Gobierno de consentimientos, segmentación accionable y journeys con reglas anti-errores:
evitar impactos irrelevantes, no mostrar precios inferiores tras una compra reciente
y excluir clientes con incidencias abiertas.
KILLER
Dato utilizable. Si la base está sucia, automatizar solo escala el error.
4.1. Datos e integración: el requisito que evita el trabajo duplicado
Este fue uno de los requisitos más importantes porque conecta directamente negocio con calidad operativa: cualquier cambio en el ERP debía reflejarse automáticamente en la web.
Si dos equipos distintos gestionan precios o catálogo en sistemas diferentes, el error humano deja de ser una posibilidad y pasa a ser una certeza. La integración debía eliminar duplicidad manual y asegurar una única fuente de verdad.
1) Definir datos maestros: quién manda en precio, stock, pedido y catálogo.
2) Integración API-led (evitar integraciones point-to-point no documentadas).
3) Monitorización visible: errores de integración accesibles para negocio e IT.
4) GA4 desde cero con eventos y conversiones definidos con negocio y QA de tagging.
- Confundir “demo bonita” con “proceso cubierto”. Las demos deben reproducir procesos críticos y excepciones.
- No validar killers (multi-almacén, coste real de licencias, integración con ERP) antes de hacer shortlist.
- Dejar analítica y tagging para el final: luego nadie confía en los datos y las decisiones vuelven a intuición.
5. Negociación con caja crítica: condiciones, hitos y cómo evitar el “proyecto infinito”
- No había financiación externa para el proyecto.
- La empresa operaba con tensión de caja habitual.
- El riesgo real de dirección era simple: llegar a fin de mes con nóminas y seguridad social.
- Por tanto, la negociación no podía centrarse solo en precio: debía proteger flujo de caja.
La restricción más dura del caso no era técnica: era financiera. Sin financiación externa, con recortes habituales al final de mes, el proyecto debía encajar dentro de la realidad operativa de la compañía.
En ese contexto, negociar “precio” es insuficiente. La variable crítica pasa a ser otra: cómo se distribuye el coste en el tiempo y en qué momento aparece el valor.
Por eso la negociación no se planteó como una discusión de tarifas, sino como un diseño de condiciones que protegieran caja y acercaran el gasto al momento en el que el sistema empezara a generar valor operativo (MVP).
5.1. Palancas reales de negociación (sin fantasía)
Competencia explícita
Competencia real entre proveedores por bloques y por suite completa. Sin transmitir nunca que la decisión estuviera tomada.
Shortlist reducida
Pocos proveedores en la fase final para aumentar presión negociadora y permitir comparativas claras entre propuestas.
Pagos por hitos
Pagos ligados a entregables concretos y validables, no a calendario ni a fases abstractas.
Licencias diferidas
Acercar el inicio de pago de licencias al momento de MVP para evitar meses pagando sin retorno operativo.
Compromiso plurianual
A cambio de compromisos de permanencia, se negociaron precios por tramos, ramp-up gradual y módulos bonificados.
Además se utilizó una palanca que sí existe en el mundo real pero rara vez se menciona: el valor comercial de un caso de éxito.
Para ciertos proveedores, implantar su tecnología en un retailer tradicional de cierto tamaño no es solo un proyecto. Es también una referencia comercial relevante. Cuando existe competencia real y buen timing, ese incentivo puede convertirse en concesiones económicas o condiciones más favorables.
5.2. Riesgos típicos en un reset (y cómo mitigarlos)
| Riesgo típico | Cómo te golpea | Señal temprana | Mitigación práctica |
|---|---|---|---|
| Vendor lock-in | Coste futuro y poca salida | Export de datos / APIs no claras | Cláusulas de datos, documentación y APIs; plan de salida definido |
| Dependencia del integrador | Cada cambio = horas | “Pregúntales a ellos” para todo | Handover, formación, repositorio y ownership interno por dominio |
| Falta de ownership | Nadie prioriza | Reuniones sin decisión | RACI, weekly de priorización y steering mensual |
| Scope creep | Proyecto interminable | “Ya que estamos…” constante | MVP real + control de cambios + backlog priorizado |
| Integración frágil | Errores recurrentes | Arreglos manuales y duplicidad | API-led, monitorización y QA; ERP como maestro definido |
| Conflicto tienda vs online | Sabotaje pasivo | Retrasos y rechazos | SLAs internos + KPI compartido + trazabilidad de excepciones |
| Caja insuficiente | Parones y recortes | “Se para hasta nuevo aviso” | Pagos por hitos + licencias diferidas + plan de cash del proyecto |
- Negociar solo descuento y no negociar pagos por hitos, ramp-up y licencias diferidas.
- Dejar que el integrador “diseñe” la solución sin killers definidos y sin comparativa real.
- Comprar módulos que el negocio no puede absorber (capacidad interna) y luego culpar a la tecnología.
6. Gobernanza: ownership, reglas y KPIs de sistema (antes/después)
- El software importa menos que las reglas de gobierno que lo acompañan.
- Sin ownership, cualquier stack termina degradándose.
- Sin control de cambios, la complejidad vuelve aunque la tecnología sea nueva.
- Sin KPIs de sistema, dirección pierde visibilidad y el proyecto se convierte en opinión.
La parte que más autoridad da a un caso de replataforma no es “qué software eliges”. Es lo que dejas definido para evitar repetir el mismo caos con herramientas nuevas.
Eso implica fijar desde el inicio ownership, reglas de herramientas, datos maestros, control de cambios y rituales de decisión. Si estos elementos no quedan definidos, el nuevo stack tiende a degradarse con el tiempo.
En este caso se definieron responsables con nombre y apellidos por dominio. Negocio y tecnología tenían responsabilidades distintas y explícitas. Esa separación evita uno de los problemas más habituales en este tipo de proyectos: que nadie sepa realmente quién decide.
6.1. Rituales y estructura mínima (sin burocracia)
Daily
Revisión de bloqueos reales, incidencias críticas y decisiones operativas rápidas.
Weekly de priorización
Revisión de backlog, cambios y riesgos con responsables definidos.
Steering mensual
Revisión de KPIs de sistema y decisiones estratégicas. No es una reunión de estado: es un foro de decisión.
Control de cambios
Pricing, promociones, checkout y reglas de OMS pasan por QA y ventanas de despliegue definidas.
6.2. KPIs de sistema (para dirección, no solo para IT)
- Permiten a dirección ver la salud real del sistema.
- Separan problemas de tecnología de problemas de operación.
- Evitan que el proyecto se evalúe por percepciones.
6.3. Qué cambia realmente en la operación (antes vs después)
| Área | Antes | Después |
|---|---|---|
| Inventario | Disponibilidad tardía y dependiente de middleware | OMS multi-almacén por zonas + estados y excepciones trazables |
| Pricing/Promos | Duplicidad y errores entre sistemas | ERP maestro + replicación + QA + control de cambios |
| Customer Service | Mail/teléfono, sin trazabilidad | Casos + colas + SLAs + vista 360 |
| Marketing | Sin automation real y base de datos sucia | CRM/MA con reglas anti-errores y segmentación accionable |
| Herramientas | 20+ satélites sin owner | Catálogo + owner + reglas de alta/baja e integraciones |
| Analítica | Tags sin gobierno y trazabilidad rota | GA4 desde cero + eventos + QA + naming estándar |
| Decisión | Dependencia de “quien sabe” | RACI + comités + decisiones con responsables |
1) No entra herramienta nueva sin owner, coste, dato que toca y plan de baja.
2) No hay cambios críticos sin QA y ventana de despliegue (pricing/promos/checkout).
3) ERP como maestro definido y replicación sin duplicidad manual (menos error humano).
- Firmar sin dejar atado el modelo de soporte, handover y documentación mínima.
- Dejar el ownership “para luego”: luego no llega, y el integrador decide por ti.
- No medir KPIs de sistema: dirección pierde visibilidad y el proyecto se convierte en opinión.
7. Plan 90 días: discovery → RFP → negociación → plan de implantación + CTA
- No implantar todo, sino decidir bien.
- Pasar de opiniones a un inventario real de problemas, restricciones y killers.
- Dejar condiciones, hitos y gobernanza atados antes de construir.
- Reducir incertidumbre operativa y financiera antes de comprometer más caja.
Un reset completo no se implanta en 90 días. Pero sí puedes hacer en 90 días lo que separa a los proyectos serios de los que se encallan: inventario real, killers, decisión, condiciones y gobernanza atada.
Ese era el objetivo aquí. No se trataba de “transformar” la compañía en tres meses, sino de dejar resuelto lo más importante: qué se iba a hacer, con qué criterios, bajo qué condiciones y con qué protecciones para no repetir los mismos errores con herramientas nuevas.
En un contexto de venta y caja crítica, eso tiene una lógica clara. La compañía no podía permitirse un proyecto infinito, una decisión sentimental ni una implantación que consumiera meses antes de demostrar valor. El objetivo en 90 días era salir de “opiniones” y entrar en decisiones ejecutables.
7.1. Quick wins realistas (sin vender humo)
- Inventario de herramientas y costes: eliminar duplicidades evidentes y riesgos de seguridad/accesos.
- Redefinir reglas de pricing/promos y control de cambios para reducir “errores de campaña”.
- GA4 desde cero con eventos mínimos de negocio y naming estándar (para recuperar trazabilidad).
- Diseñar SLAs internos tienda/online y trazabilidad de excepciones (para que el OMS no nazca en guerra).
Estos quick wins no “resuelven” el proyecto, pero sí cumplen una función importante: empiezan a reducir ruido, devuelven algo de visibilidad a dirección y rebajan errores evitables antes de entrar en la fase más costosa.
Eso es especialmente útil cuando la organización llega cansada. Si todo se deja para la gran implantación, el proyecto arranca con demasiada presión y muy pocas señales tempranas de control.
7.2. Riesgos asumidos conscientemente (y cómo se mitigaron)
En este caso existía un riesgo operativo claro: un OMS nuevo, especialmente si es reciente, puede traer incertidumbre en interacciones e integraciones. Eso no se soluciona con fe. Se mitiga con fases, QA end-to-end, readiness antes de cutover y KPIs de sistema visibles para dirección.
- Fases claras y no un big bang opaco.
- QA end-to-end antes de cualquier paso sensible.
- Readiness real antes de cutover, no “optimismo de proyecto”.
- KPIs de sistema visibles para dirección desde el inicio.
La lógica de fondo era simple: si el proyecto iba a introducir una capa nueva de complejidad temporal, esa complejidad debía estar compensada por un modelo mejor de decisión, control y seguimiento. De lo contrario, el remedio podía amplificar el problema original.
Con cancelaciones por stock en doble dígito, campañas frágiles y analítica rota, la dirección pierde capacidad de decisión. Sube el coste de atención al cliente, sube el trabajo manual, baja la conversión y se deteriora la reputación. El “parcheo” se convierte en un coste fijo sin retorno, justo cuando más necesitas caja. En este caso, además, no hacer nada implicaba otra derivada: sostener una fragilidad que podía seguir penalizando la percepción de continuidad y transferibilidad del negocio.
Recurso: Plantilla RFP + checklist de gobernanza digital
Si estás valorando un reset, o no tienes claro si seguir parcheando o replantear la base, lo que más acelera no es una demo comercial: es un artefacto serio de decisión. Killers, ownership, reglas de datos, control de cambios y estructura de negociación por hitos.
FAQs (AIO/AEO): replataforma, OMS, gobernanza y conflicto tienda vs online
Respuestas directas a las preguntas que un CEO se hace antes de autorizar un reset del stack.
¿Cuál es la señal nº1 de que debo replantear el stack completo?
Cuando dependes de parches y horas de programador para operar lo básico (promos, pricing, envíos, checkout) y aun así fallas en picos. A partir de ahí, el problema deja de ser “IT” y pasa a ser riesgo de empresa: ventas, reputación, tickets y caja. En un contexto de M&A, además, suele convertirse en señal de fragilidad estructural.
¿Qué nivel de cancelaciones por stock debería preocupar a un CEO?
Por encima de ~5% sostenido ya es serio. En doble dígito (10–15%) el canal se vuelve frágil: cae conversión, aumenta atención al cliente y el equipo trabaja en modo bomberos. En ese punto, el coste de “no hacer nada” suele ser mayor que el coste de decidir bien.
¿Qué es “killer” en un RFP de retail omnicanal?
La promesa: disponibilidad y entrega. Si tu realidad es stock por zonas, el OMS multi-almacén no es negociable. Si el sistema no cubre excepciones y no deja trazabilidad, automatiza el caos: solo irás más rápido hacia el problema.
¿Cómo gestiono el conflicto tienda vs online sin guerras internas?
Con dirección: incentivos compartidos, SLAs internos por tienda/zona y trazabilidad de excepciones. Si la tienda “pierde” con el online, el canal se rompe desde dentro. El software ayuda, pero no sustituye reglas e incentivos.
¿Qué es no negociable si tengo un ERP corporativo como maestro?
Que no haya duplicidad manual. Cualquier cambio relevante en ERP (precio, stock, catálogo, condiciones) debe reflejarse en web/OMS/CS sin “hacerlo dos veces”. Esa duplicidad es la fábrica de errores más rentable del retail.
¿Cómo se negocia cuando la caja es crítica?
Negocia condiciones, no solo precio: pagos por hitos, ramp-up, licencias diferidas hacia el MVP y compromiso plurianual con precios por tramos. Si pagas licencias meses antes de generar valor, el riesgo financiero se dispara.
¿Qué debo dejar firmado antes de implantar para no repetir el caos?
RACI, modelo de soporte, documentación obligatoria, handover y control de cambios (pricing/promos/checkout). Además, KPIs de sistema visibles para dirección (cancelación por stock, errores, SLAs de CS, exactitud de disponibilidad).
¿Qué se puede hacer de verdad en 90 días?
Decidir bien y dejar gobernanza atada: inventario real, killers, shortlist, condiciones de pago/licencias y plan de implantación con MVP. No es “implantar todo”, es evitar el proyecto infinito y proteger caja y operación.
👉 Si estás valorando un cambio importante (equipo, canal, stack o modelo comercial), podemos devolverte un marco claro:
Qué conviene fichar, qué conviene externalizar y qué conviene ejecutar por proyecto, con coste estimado y pasos de implementación.
¿Te avisamos cuando publiquemos nuevos contenidos?
Nos tomamos en serio tu tiempo. Solo te enviaremos artículos, guías o herramientas que te ayuden a mejorar, decidir o actuar mejor.
