La selección de un software de SGA suele seguir un patrón de errores predecible. Incluso los equipos con experiencia se equivocan. La cuestión no es la experiencia, sino la secuenciación.
Para lo que antes se tardaba de 6 a 12 meses, ahora se alarga hasta 18 meses o más. Las partes implicadas se multiplican. Las dependencias salen a la luz demasiado tarde. Las listas de candidatos preseleccionados se reabren tras las demos que se suponía que tenían que cerrarlas.
Este documento ofrece un método para romper ese patrón. Cinco pasos para tomar las decisiones correctas antes de que los proveedores entren en escena. Una hoja de ruta con plazos realistas. Y las trampas que pueden descarrilar incluso a los equipos más experimentados para que puedas verlas venir.
Hoja de ruta para la selección de un SGA
La mayor parte de los retrasos se producen antes de que se contrate formalmente a los proveedores. El alcance, las limitaciones y la responsabilidad están sin resolver. El método que se describe a continuación las aborda desde el principio.
| Fase | Plazo | Prioridad | Resultado clave |
|
Fase 1: Definición del marco de decisión |
Semanas 1-6 | Fijar los fundamentos |
|
| Fase 2:
Criterios y preparación |
Semanas 7-10 | Convertir las decisiones en filtros |
|
| Fase 3:
Evaluación de proveedores |
Semanas 11-20 | Comprobar las hipótesis, no las promesas |
|
| Fase 4:
Compromiso |
Semanas 21-26 | Confirmar la decisión |
|
Pasos para tomar la decisión sobre un SGA
Qué decidir y en qué orden.
Paso 1: Decidir qué no debe fallar en los próximos 3 años
Las operaciones actuales parecen el punto de partida obvio, pero no lo son.
La presión por obtener resultados inmediatos empuja a los equipos a resolver las dificultades actuales: solucionar el cuello de botella, acelerar el picking, reducir los errores en el muelle X. Sin embargo, optimizar para el presente a menudo genera deuda estructural para el futuro.
Empieza por otro lado. ¿Qué falla en la plataforma cuando cambian las condiciones?
Cuatro limitaciones que hay que poner a prueba antes de cualquier pliego de condiciones:
- El volumen se duplica: ¿puede la arquitectura asumirlo sin cambiar de plataforma?
- Se abre un nuevo canal: ¿pueden adaptarse los flujos de trabajo sin necesidad de un proyecto?
- Llega la automatización: ¿puede el SGA coordinar equipamiento que no controla actualmente?
- Se añade un centro: ¿es replicable el despliegue o hay que empezar de cero?
Los resultados rápidos importan, pero no marcan el mínimo. Las limitaciones sí lo hacen.
Paso 2: Decidir el alcance de la decisión
La selección del SGA a menudo pasa a ser una transformación de la cadena de suministro. El TMS entra en juego. El OMS se pone en tela de juicio. Resurge la estrategia de automatización. El proyecto se estanca.
Antes de contratar a nadie externo, hay que marcar una línea roja. ¿Qué se decide en este proceso y qué es lo que explícitamente no se decide?
| Se decide en este proceso | No se decide en este proceso |
| Plataforma de SGA | Sustitución del TMS |
| Modelo de integración esencial (ERP, OMS) | Estrategia de transportistas |
| Enfoque de despliegue en varios centros | Proveedor de automatización |
| Calendario y fases de go-live | Hoja de ruta de TI más amplia |
«No decidido por ahora» no significa ignorarlo. Puede que la automatización no se implemente hasta dentro de dos años, pero el grado de preparación para la automatización es una limitación actualmente. Las decisiones adyacentes definen lo que el SGA debe admitir, pero no forman parte del proceso de selección en sí.
Paso 3: Poner de acuerdo a los responsables de la toma de decisiones antes de buscar fuera
Los proveedores no son los que crean la falta de convergencia interna. La ponen de manifiesto.
Una demo sale bien. Entonces, el departamento de TI plantea preocupaciones sobre la integración que no se habían comentado. El departamento financiero cuestiona el modelo de costes. El departamento de operaciones quiere revisar el alcance. Se reabre la lista de candidatos preseleccionados.
Las decisiones sobre el SGA ya no son elecciones operativas con una revisión del departamento TI al final. La arquitectura, la estrategia de nube, los límites de integración, la seguridad y la responsabilidad de los datos convierten al departamento de TI en corresponsable de la decisión, no en una parte implicada a la que consultar más adelante.
Antes de mantener cualquier conversación externa, tres preguntas exigen respuestas claras:
- ¿Quién es el responsable de la decisión final? No quién participa en esta. ¿Quién decide?
- ¿Qué concesiones se han aceptado ya? Coste o velocidad. Estándar o personalizado. Nube o local.
- ¿Dónde radican los desacuerdos conocidos? Sácalos a la luz ahora o los proveedores lo harán por ti.
Paso 4: Identificar las decisiones que son difíciles de revertir
No todas las decisiones en cuanto al SGA tienen la misma importancia. Algunas pueden ajustarse tras el go-live. Otras te obligan a mantenerlas durante años.
Dedicar meses a evaluar los algoritmos de picking mientras se subestiman las decisiones estructurales implica una asignación errónea del riesgo. Céntrate en las decisiones que son difíciles o costosas de revertir:
- Modelo de arquitectura: nativo en la nube, híbrido, local. Cambiarlo más adelante supone un proyecto de migración, no un simple ajuste de configuración. Conocer tus opciones de arquitectura de TI y escalabilidad del SGA antes de este paso evita quedarse atado a un modelo inadecuado.
- Dependencia del proveedor: una vinculación profunda a un único ecosistema (ERP, middleware, herramientas) genera costes de salida que se acumulan con el tiempo.
- Modelo de gobernanza: configuración centralizada frente a descentralizada. Esto determina cómo se desplegará y controlará cada futuro centro.
- Deuda de personalización: una gran cantidad de características específicas incorporadas en una fase temprana ralentiza las actualizaciones más adelante. Cada solución provisional se convierte en una limitación permanente.
Paso 5: Traducir las necesidades en criterios de evaluación.
Las listas de comprobación de funciones crean una falsa equivalencia. Todo SGA maduro gestiona la recepción, el almacenamiento, el picking, el embalaje y el envío. Lo hemos dicho ya varias veces.
Comparar a los proveedores según las funcionalidades esenciales rara vez permite diferenciarlos.
Los criterios funcionan de otro modo. Eliminan opciones.
Una pregunta sobre una característica: «¿admite el SGA la planificación con oleadas?» Una pregunta basada en criterios: »¿podemos pasar de una ejecución basada en oleadas a una sin oleadas en pleno periodo de máxima actividad sin necesidad de modificar el código?»
A la primera pregunta todos responden «sí». La segunda pone de manifiesto las diferencias reales.
Establece criterios a partir de tus limitaciones (paso 1) y tus decisiones irreversibles (paso 4):
- Si el grado de preparación para la automatización es una limitación, el criterio es la coordinación en situaciones de perturbación, y no «se integra con el SCA».
- Si el aspecto multicentro es una limitación, el criterio es la velocidad de despliegue para el centro n.º 4, y no «admite varios almacenes».
Los criterios funcionan cuando se aplican como pruebas de eliminación excluyentes. El mejor software de SGA muestra cómo se aplican esas pruebas a proveedores reales.
Lo que descarta a los proveedores son los criterios. En cambio, lo que descarta a las justificaciones comerciales es la diferencia entre el presupuesto de un proveedor y el coste total de propiedad. Entender cuánto cuesta realmente un SGA convierte los criterios de evaluación en decisiones presupuestables.
Las trampas más comunes en la selección de un SGA
Existen cinco patrones que se repiten una y otra vez, incluso en equipos con experiencia.
- En primer lugar, las demos: las demos tempranas ayudan a interpretar una interfaz. Si se utilizan antes de tomar decisiones y aplicar los criterios, sesgan el proceso. El departamento de TI debería estar presente para detectar las asunciones en cuanto a arquitectura, no para validar funciones
- Confundir la cobertura con la adecuación: un proveedor cumple todos los requisitos. Eso no significa que la plataforma se adapte a tu modelo operativo. Las prestaciones esenciales del SGA han alcanzado la paridad. La adecuación depende de la arquitectura, el modelo de implementación y la autonomía postimplementación.
- Dejar que la lista de candidatos preseleccionados decida: tres proveedores pasan el corte. La tentación es elegir al «mejor» de los tres. Si ninguno cumple tus criterios, amplía la búsqueda. No bajes el listón.
- Presuponer una adaptación futura: «Lo ajustaremos tras el go-live». Esto funciona para la configuración. No lo hace en el caso de la arquitectura y la gobernanza
- Alargar el calendario: la selección se amplía. Las personas cambian de funciones. Las prioridades cambian. Para cuando te decides, ya estás resolviendo un problema distinto.
El marco de pliego de condiciones del SGA
Los pasos anteriores definen qué hay que decidir. El pliego de condiciones convierte esas decisiones en criterios de evaluación a los que los proveedores deben responder.
Un pliego de condiciones solo funciona si refleja lo que ya has fijado: las limitaciones, el alcance, la responsabilidad y los filtros de descarte. Sin eso, se convierte en un ejercicio de comparación de funciones dirigido por los proveedores.
El contexto del pliego de condiciones del SGA te aporta la estructura para formalizar las decisiones y evaluar una evaluación controlada.
Qué esperar de las demos de un SGA
Las demos son pasos de validación. Se realizan una vez que se han definido las limitaciones, el alcance y los criterios.
Una demo bien diseñada pone a prueba las excepciones, la autonomía de configuración y los límites de integración. Una demo mal diseñada se limita a mostrar los casos más favorables y te deja impresionado, pero mal informado.
Saber qué esperar de una demo de SGA ayuda a diseñar casos prácticos que ponen de manifiesto los límites reales, y no un rendimiento pulido.
Preguntas frecuentes
¿Cuánto tiempo debe durar la selección de un SGA?
De seis a nueve meses desde el inicio hasta la toma de la decisión es una plazo realista para empresas de tamaño mediano a grande. Los plazos más cortos omiten pasos y generan trabajo adicional. Con plazos más largos se pierde el impulso. Fija una fecha límite y respétala.
¿Quién es el responsable de la decisión final sobre el SGA?
Una sola persona. Normalmente, el ejecutivo de cadena de suministro u operaciones con autoridad sobre el presupuesto y el proceso. El departamento de TI participa en la evaluación, pero no en la decisión. Los comités asesoran. Asumir la responsabilidad significa que hay una persona con nombres y apellidos desde inicio de la implementación.
¿Cuándo deben incorporarse los proveedores al proceso?
Una vez definidas las limitaciones, fijado el alcance y confirmada la coordinación interna. Involucrar a los proveedores antes puede parecer productivo, pero pone de manifiesto las deficiencias que aún no se han resuelto. Detectarán las descoordinaciones por ti.