Si vuestro almacén empieza a quedarse corto para el volumen que fabricáis o distribuís, es lógico que el primer paso que nos planteemos sea comparar soluciones SGA por sus funcionalidades: picking, trazabilidad, integración, automatización, gestión de ubicaciones, etc.
Este artículo parte de un momento posterior. Ya habéis decidido que necesitáis un SGA y ahora la cuestión no es qué software ofrece más funciones, sino cómo se va a implantar.
La cuestión es que un SGA puede resolver muchos de los problemas actuales del almacén, pero una implantación mal planteada también puede introducir nuevos riesgos: interrupciones operativas, retrasos en expediciones, dificultades de integración o una transición más compleja de lo previsto.
Por eso, antes de comprar el software, conviene hacerle cinco preguntas al proyecto de implantación. No al software SGA.
Tabla de contenidos:
El software rara vez es el problema. El proyecto, sí
Una consultora especializada en operaciones logísticas lo resume así en su análisis sobre implantación de SGA (1): el éxito del proyecto depende tanto de la herramienta elegida como de la metodología utilizada. Y señala tres errores que se repiten:
- empezar sin haber analizado en profundidad la operación de implantación,
- subestimar que el cambio afecta a procesos y organización, no solo a sistemas,
- y centrar toda la decisión en elegir software en vez de en cómo se va a implantar.
Esto no es una opinión aislada. Una consultora de referencia en gestión del cambio para proyectos ERP ha consolidado datos de cientos de proyectos (2): solo el 49,7 % cumple el plazo original, con una duración mediana de 15,5 meses, y los factores humanos pesan seis veces más que los técnicos a la hora de que el proyecto acabe dando los resultados esperados. Un informe anual sobre proyectos ERP correspondiente a 2026 (3) encuentra que más de una cuarta parte de los proyectos supera el presupuesto y casi otra cuarta parte se retrasa, y que menos de una cuarta parte de las organizaciones da a la gestión del cambio la prioridad que le correspondería.
|
Dato |
Fuente |
|
49,7 % de los proyectos cumple el plazo original; duración mediana de 15,5 meses |
(2) |
|
Los factores humanos pesan 6 veces más que los técnicos en el resultado del proyecto |
(2) |
|
Más de 1/4 de los proyectos supera el presupuesto; casi 1/4 se retrasa |
(3) |
|
Los proyectos con metodología formal de gestión del cambio tienen un 33 % más de probabilidad de un resultado bueno o excelente |
(2) |
|
La implicación humana temprana amplifica el éxito de la transformación en un 73 % |
(7) |
|
Incrementos de productividad de entre el 10 % y el 30 %; mejoras de entregas puntuales de entre el 5 % y el 10 % |
(7) |
Otro consultor especializado en convertir informes de analistas en decisiones de compra de WMS (10) lo dice de forma más directa: el software puede ser excelente y el proyecto puede fracasar igual. Esa es la idea que sostiene las cinco preguntas siguientes: más que el producto, evalúan si el proyecto que tienes delante está diseñado para “no romper lo que ya funciona mientras arregla lo que no funciona”.
Las 5 preguntas que hay que hacer antes de comprar un SGA
Cada una de estas preguntas aborda uno de los puntos críticos en los que, según la evidencia disponible, suelen surgir problemas durante la implantación de un SGA. Y, con frecuencia, la causa no está en el software elegido, sino en cómo se ha planteado y gestionado su implantación
1. ¿Cómo funciona hoy el proceso y qué datos lo demuestran?
Antes de pedir una propuesta, alguien tiene que poder responder con datos (no con sensaciones) a cuánto tarda hoy un pedido en salir, cuántas líneas se preparan por hora y con qué margen de error, y cuánto tiempo pasa entre que un palet entra por el muelle y queda disponible para servir. Sin esa tarea base, es imposible demostrar después qué mejora es atribuible al SGA y cuál se habría producido de todas formas.
Esa misma consultora (1) lo señala como el primer error del proyecto: arrancar sin haber analizado en profundidad el proceso. Otra consultora especializada en implantaciones de WMS (4) añade un matiz importante: el alcance real casi siempre resulta mayor de lo previsto, porque el diseño de un SGA es iterativo y muchas incógnitas solo aparecen durante el proceso de implantación, ya que los requisitos que nadie documenta porque "son obvios" son los que después generan la brecha entre lo que el cliente esperaba y lo que el proveedor entendió.
Para un director de operaciones, esta pregunta tiene una traducción muy concreta: si hoy no sabéis con precisión cuánto tarda el material en pasar de producción a almacén y de ahí a expedición, tampoco vais a saber si el SGA lo ha mejorado o si simplemente habéis cambiado de sistema para seguir igual.
2. ¿Cómo se conecta con vuestro ERP, y quién lo ha probado ya?
Un SGA sin integración de calidad con el ERP no sustituye el problema que tenías: lo traslada. Si el conector no funciona en tiempo real, la alternativa es doble tecleo, ficheros puente o, en el peor de los casos, volver al Excel que el proyecto debía eliminar.
Una consultora estratégica de primer nivel (5) sitúa la armonización de datos entre ERP, WMS y el resto de sistemas de la cadena de suministro como una capacidad estructural de cualquier operación digital avanzada. Y la pregunta que de verdad distingue un conector maduro de uno recién montado es si ya está probado en producción con un cliente de vuestro mismo ERP: pedid una referencia con integración activa, no solo una demo del conector en un entorno controlado.
Esta es también la pregunta donde el comité de compra suele descubrir que la decisión no depende tanto del catálogo de funciones del SGA como de si ese proveedor ya ha resuelto la conexión con vuestro ERP concreto — Sage X3, Dynamics 365 Business Central, SAP u otro — con un cliente real, no solo en la ficha de producto.
3. ¿Quién gestiona el cambio, y qué pasa con producción mientras tanto?
El cambio debe liderarlo Operaciones, no solo TI. Esta es la pregunta que más veces se salta el comité de compra, y la que más veces explica después por qué un proyecto con buen software da mal resultado. Una firma especializada en rescatar implantaciones de WMS que han fracasado (6) lo resume con una frase que vale la pena tomarse en serio: cuando las implementaciones fracasan, la causa raramente es el software mismo. El factor más crítico que identifican, tras años de proyectos de recuperación, es tratar el proyecto como uno de TI en lugar de uno de Operaciones. Sin liderazgo operativo, el sistema termina reflejando cómo alguien de sistemas cree que funciona el almacén, no cómo funciona de verdad, y el equipo lo rechaza.
Los números respaldan la intuición: según esa misma consultora de gestión del cambio (2), los proyectos con una metodología formal de gestión del cambio tienen un 33 % más de probabilidades de lograr un resultado bueno o excelente, y una consultora internacional, en una investigación conjunta con una reconocida escuela de negocios (7), ha medido que la implicación humana temprana amplifica el éxito de una transformación de almacén en un 73 %.
|
Dato |
Fuente |
|
Los proyectos con metodología formal de gestión del cambio tienen un 33 % más de probabilidad de un resultado bueno o excelente |
(2) |
|
La implicación humana temprana amplifica el éxito de la transformación en un 73 % |
(7) |
Pero la pregunta concreta que debería hacerse cualquier director de operaciones no es abstracta: ¿qué pasa con el suministro a línea de producción el día que arranca el nuevo sistema? Un proyecto de SGA bien planteado tiene respuesta a eso desde el principio, un plan de arranque por fases, no un salto en frío a producción completa el mismo día en toda la operación.
4. ¿Qué KPI define que el proyecto ha funcionado?
"Mejorar la eficiencia del almacén" no es un KPI: es una intención. Sin un indicador concreto pactado antes de empezar, no hay forma de decir, seis meses después de la puesta en marcha, si el proyecto ha cumplido o no — y el CFO tampoco va a poder justificar la inversión con nada más que percepción.
El marco de transformación de esa misma consultora internacional (7) se construye sobre tres pilares:
- preparar una línea base con beneficios definidos por adelantado,
- medir con visibilidad continua sobre esos indicadores,
- y sostener el resultado en el tiempo.
Con ese enfoque, reporta en su experiencia como consultora incrementos de productividad de entre el 10 % y el 30 %, y mejoras de entre el 5 % y el 10 % en entregas puntuales, cifras de su propia cartera de proyectos, no una garantía universal, pero un rango de referencia razonable para fijar expectativas.
El KPI concreto depende del tramo que más os duela: si el problema es que producción para porque no encuentra el material que sí está en el almacén, mide el tiempo entre que se solicita una referencia y queda disponible en línea. Si el problema es el cuello de botella en expedición, mide el ciclo entre que un pedido se lanza a preparación y sale del muelle. Elegid uno o dos indicadores, no quince, y aseguraros de que alguien los mida hoy (antes de empezar), para tener con qué comparar después.
5. ¿Qué pasa el día después del arranque, y dentro de cinco años?
El día después del arranque hace falta un equipo de soporte dedicado a corto plazo; a cinco o diez años, garantías de continuidad del proveedor a largo plazo. Son dos preguntas distintas que conviene no mezclar.
- La primera: quién da soporte en las semanas posteriores a la puesta en marcha, cuando la productividad cae de forma predecible mientras el equipo gana experiencia con el sistema. Una de las grandes consultoras internacionales (8), que ha estudiado en detalle esta fase de estabilización, advierte de un riesgo concreto: si se presiona a los operarios para que mantengan el ritmo de pedidos desde el primer día, "podría llevarles a eludir el sistema o a usarlo incorrectamente", exactamente el resultado contrario al que se buscaba con el proyecto. Un proveedor de WMS (9) añade que sin un equipo de soporte dedicado tras el arranque, el rendimiento del sistema y la satisfacción del usuario se degradan con el tiempo.
- La segunda pregunta es de largo plazo, y suele quedar fuera del comité de compra porque no parece urgente: ¿qué pasa si este proveedor desaparece dentro de cinco o diez años? No es una hipótesis exagerada: es precisamente uno de los criterios que recomienda evaluar quien ha estudiado cómo convertir estos informes de analistas en decisiones de compra reales (10): si la plataforma seguirá recibiendo inversión seria dentro de diez años, más allá del soporte técnico inmediato, y si el proveedor desarrolla el software que implanta o depende de un tercero para cualquier adaptación relevante.
Cómo se traduce esto en el comité de compra del SGA
Estas cinco preguntas complementan la evaluación funcional del SGA, no la sustituyen. Un proveedor puede tener el mejor catálogo de funciones y perder igualmente el proyecto si no puede responder con solvencia a estas cinco cuestiones, y un proveedor con un catálogo más ajustado, pero con un proyecto bien planteado, puede acabar dando mejor resultado que el que parecía técnicamente superior en la demo.
Para el responsable de operaciones y producción, la pregunta que de verdad importa no es "¿qué hace este SGA?", sino "¿qué garantiza este proyecto sobre el tramo de producción mientras se implanta?". Cada vez que se introduce un sistema nuevo existe el riesgo real de arreglar un tramo y romper el siguiente, y la única forma de reducir ese riesgo es exigir, antes de firmar, respuestas concretas a estas cinco preguntas, con nombres, plazos y responsables, no con generalidades sobre "acompañamiento" o "metodología propia".
Preguntas frecuentes (FAQs)
¿Estas preguntas sirven también si el SGA se implanta como módulo de un ERP ya elegido, no como producto independiente?
Sí. La complejidad de gestión de proyecto (línea base, integración, gestión del cambio, KPI y soporte) no depende de si el SGA es un módulo del ERP o un producto conectado a él. Cambia el peso relativo de la pregunta de integración (menor si es nativo del mismo ERP, mayor si conecta con un ERP de terceros), pero las otras cuatro preguntas se mantienen igual.
¿Cuánto debería durar un proyecto de implantación de un SGA?
No hay una cifra única válida para cualquier operación: depende de la complejidad del almacén, del número de procesos que se digitalizan a la vez y de si hay integración con automatización física. Como referencia, la duración mediana de este tipo de proyectos ronda los 15,5 meses (2), aunque varía mucho según el alcance. Lo importante es que el plazo esté acotado por fases con hitos verificables, no que sea un único arranque en bloque.
¿Quién debería liderar el proyecto dentro de la empresa, TI u operaciones?
La evidencia de proyectos de recuperación de esa misma firma especializada (6) señala tratar el proyecto exclusivamente como uno de TI como uno de los errores más determinantes. El liderazgo operativo no sustituye a TI —la integración con el ERP sigue siendo una cuestión técnica que necesita a IT/Sistemas— pero sin un responsable de operaciones con autoridad real sobre el proyecto, el sistema tiende a construirse sobre una imagen incompleta de cómo funciona el almacén.
¿Es razonable exigir a un proveedor que arranque el SGA por fases en vez de todo a la vez?
Sí, y es una de las señales más claras de un proyecto bien planteado. La evidencia recomienda estabilizar primero los procesos que maduran antes —recepción y ubicación— para sumar después los más exigentes, como la expedición (8), en vez de un arranque único en bloque en toda la operación. Un arranque por fases reduce el riesgo de que una incidencia en un módulo pare toda la operación, y da al equipo tiempo real de adaptación antes de sumar el siguiente proceso.
¿Qué pasa si el proveedor no puede responder con precisión a alguna de estas cinco preguntas?
No es necesariamente motivo de descarte automático, pero sí una señal que conviene explorar más antes de firmar. Un proveedor que no tiene una línea base metodológica clara para el análisis previo, que no puede dar una referencia de integración activa con vuestro ERP, o que no tiene un plan explícito de soporte tras el arranque, traslada ese riesgo directamente al proyecto — y, por lo visto en la evidencia disponible, es precisamente ahí donde suelen fallar.
Si quieres ver cómo se resuelven estas cinco preguntas en un caso concreto, con el tramo de producción incluido, puedes solicitar una demo del flujo completo entre producción, almacén y expedición con el equipo de DATADEC.
También te pueden interesar...
Fuentes citadas
- G3M Operational Consulting — "Implantación de SGA: fases y errores comunes" (g3m.es/blog)
- Prosci — "ERP Change Management" (prosci.com)
- Panorama Consulting Group — 2026 ERP Report (panorama-consulting.com)
- Tompkins Solutions — "Warehouse Management: Navigating the Pitfalls of a WMS Implementation" (tompkinsinc.com)
- Boston Consulting Group (BCG) — Building the Supply Chain of the Future (bcg.com)
- Socius24 — "WMS Implementation Failure: The Real Causes" (socius24.com)
- EY, en investigación conjunta con la Oxford Saïd Business School — "Distribution Transformation at Speed and Scale" (ey.com)
- Deloitte Consulting LLP — "WMS Implementation: Ramp-up Planning Best Practices" (deloitte.com)
- Cadre Technologies — "10 Common WMS Implementation Mistakes" (cadretech.com)
- itorizon — "From Quadrant to Shortlist: How to Turn Gartner's WMS Report Into a Buying Decision" (itorizon.com)