Las demos de SGA suelen considerarse momentos decisivos.
Una demo de SGA revela cómo se comporta una plataforma en tus circunstancias. No en las circunstancias del proveedor. En las tuyas. La mayoría de las demos presentan escenarios pulidos. Flujos estándar, las rutas óptimas, paneles de control impresionantes. Te convencen, pero mal informado. Una demo útil hace lo contrario: prueba las excepciones, pone a prueba los límites de configuración y muestra qué sucede cuando se incumplen las hipótesis.
Existen tres formatos principales de demo que deben tenerse en cuenta. Cada una responde a preguntas diferentes en distintas fases del proceso de selección. Saber cuál ejecutar y qué probar en cada una de ellas es lo que distingue la validación de las simples estrategias de venta. Retoma el proceso donde lo deja la selección del SGA: los criterios están definidos, se ha contactado con los proveedores y ahora hay que validar la adecuación.
¿En qué consiste una demo de SGA?
Una demo de SGA valida las hipótesis. No te ayuda a optar por un proveedor.
Una demo analiza cómo se comporta una plataforma dadas tus limitaciones. ¿Cómo gestiona el sistema un muelle bloqueado? ¿Puede un supervisor cambiar la prioridad de picking sin necesidad de recurrir al departamento de TI? ¿Qué ocurre cuando el inventario no coincide con la ubicación prevista? Estas son preguntas de demo.
Una demo no genera coordinación interna. Si el departamento de TI u operaciones es responsable de la gestión de excepciones, si es aceptable dar prioridad a la nube, si se tolera la personalización. Estas decisiones deben tomarse antes de la demo, y no descubrirlas durante esta.
Nunca se debe tomar una decisión basándose únicamente en una demo ergonómica.
Los tres formatos de demo del SGA
Demo ergonómica
Cuándo: normalmente el primer contacto.
Finalidad: evaluar la usabilidad y la navegación. ¿Los usuarios clave comprenden la interfaz? ¿Se puede acceder a la información sin dificultades?
Qué revela: claridad de la interfaz, curva de aprendizaje, facilidad de uso en el día a día.
No revela: la escalabilidad, profundidad de configuración, el comportamiento bajo presión.
Demo basada en casos concretos
Cuándo: una vez fijados los criterios. Aquí es donde comienza la validación.
Finalidad: probar tus propios casos prácticos, no los valores predeterminados del proveedor. Días de máxima actividad, excepciones, flujos mixtos, puntos de contacto de integración. El objetivo es ver qué falla.
Qué revela: cómo gestiona la plataforma la variabilidad, cómo se gestionan las reglas y las excepciones, si el sistema se adapta sin necesidad de una personalización excesiva.
No revela: la mantenibilidad a largo plazo, la autonomía tras el go-live.
Demo de análisis en profundidad o validación
Cuándo: fase avanzada, una vez que las hipótesis están mayoritariamente confirmadas.
Finalidad: centrarse en limitaciones específicas. Mecánica de configuración, patrones de integración, coordinación de la automatización, lógica de despliegue en varios centros. El departamento de TI y los usuarios clave participan activamente.
Qué revela: la autonomía de configuración, límites técnicos, cómo se gestionan los cambios tras el go-live.
No revela: el éxito del proyecto, la preparación organizativa.
A continuación se ofrece una sencilla tabla para tener una visión clara:
| Formato de demo | Qué revela | Finalidad principal | No revela |
| Demo ergonómica | Evaluar la usabilidad y las primeras señales de adopción | Claridad de la interfaz, lógica de navegación, curva de aprendizaje | Escalabilidad, configurabilidad, comportamiento bajo presión |
| Demo basada en casos concretos | Validar la adecuación operativa en condiciones de limitación | Gestión de las excepciones, flexibilidad de las reglas, respuesta a la variabilidad | Mantenibilidad a largo plazo, ejecución de la entrega |
| Demo de análisis en profundidad/validación | Reducir el riesgo técnico y de gobernanza residual | Autonomía de configuración, madurez de la integración, gestión del cambio | Éxito del proyecto, preparación organizativa |
¿Cómo es una demo seria de un SGA?
Hay cuatro indicadores que distinguen una demo útil de una presentación comercial.
- Casos prácticos reales, no flujos genéricos: picos de actividad, excepciones, automatización mixta, dependencias de integración. Si la demo que solo recorre los casos favorables, no prueba nada.
- Operaciones y TI en la misma sala: se debaten conjuntamente la configuración, las excepciones y los límites de integración. Si surgen limitaciones técnicas después de establecer las expectativas operativas, la demo ha fracasado.
- Configuración en acción: no diapositivas. No promesas. Cambios reales en las reglas, cambios de prioridad, ajustes en los flujos de trabajo. Si todo requiere a un consultor, la dependencia ya está implícita.
- Límites explícitos: qué no gestiona la plataforma de forma nativa. Dónde existen concesiones. Dónde se requiere gobernanza. Las demostraciones fluidas que ocultan las limitaciones crean problemas más adelante.
¿Cómo preparar la demo de un SGA?
Las demos más eficaces siguen una regla sencilla: 80 % estándar, 20 % contextualización.
Los proveedores realizan demos en gran medida estándar a partir del trabajo de descubrimiento. Eso permite a los equipos proyectarse sin convertir la demo en un ejercicio de desarrollo personalizado. Normalmente basta para evaluar la usabilidad, la lógica y la adecuación general.
El 20 % restante es lo que realmente importa. Casos prácticos concretos, limitaciones específicas, comparaciones con el sistema actual. Estos momentos requieren una mayor preparación y deben utilizarse de forma selectiva.
Una demo bien preparada se centra en tres aspectos:
- Datos reales: aunque sean parciales, para poner de manifiesto la complejidad desde el principio.
- Configuración en tiempo real: para evaluar la autonomía. ¿Puede un usuario clave cambiar una regla sin ayuda?
- Manejo claro de las especificidades: mostrar la senda, no necesariamente la solución final.
Cuando a los equipos les cuesta definir los casos prácticos o delimitar las expectativas, el problema suele estar en el origen. Unpliego de condiciones de SGA ayuda a fijar las limitaciones y los criterios de evaluación antes de que comiencen las demos.
Preguntas que hay que plantear durante cualquier demo de un SGA
¿Qué ocurre cuando hay un conflicto de prioridades?
No en teoría. Pide que le muestren cómo arbitra el sistema cuando se producen picos de volumen, falta inventario o los pedidos urgentes alteran el plan.
¿Quién puede modificar esto y cómo?
Pide que te muestren cómo se ajusta en tiempo real una regla, un umbral o un KPI. Si cada cambio requiere derivación, la dependencia ya es evidente.
¿A qué sistema se traslada la responsabilidad?
Aclara qué pertenece al SGA, qué al ERP u otras capas, y cómo se gestionan los fallos en el límite.
¿Qué es lo que la plataforma no gestiona de forma nativa?
Las demos serias explican los límites y las concesiones. Las respuestas vagas son una señal más clara que la ausencia de determinadas funciones.
¿Qué suele fallar tras el go-live?
No en las presentaciones de ventas. En los proyectos reales. La respuesta revela la madurez de ejecución entrega más que cualquier hoja de ruta.