SAP IBP, o9, Kinaxis: lo que los demos no te muestran

El demo será impecable. Los consultores llegarán con un tenant preconstruido sobre la plantilla de tu industria. Te mostrarán un dashboard que concilia planes financieros y operativos en tiempo real, un módulo de demand sensing que se ajusta con datos de punto de venta, y una pantalla de comparación de escenarios donde puedes estresar tu plan de suministro contra tres opciones de disrupción simultáneamente. Las diapositivas mostrarán los logos de tus competidores con la frase "más de 200 clientes en tu industria." Los números serán impecables.

Nada de esto es deshonesto. La plataforma hace todo eso. Lo que el demo no te muestra son los dieciocho meses de armonización de datos que preceden a todo esto, el headcount interno necesario para mantenerla funcionando, y la brecha entre lo que la plataforma puede hacer y lo que tu organización realmente usará tres años después del go-live.

Esto es cómo se ve esa brecha, y qué preguntar antes de firmar.

Las tres plataformas, sin el marketing

SAP IBP (Integrated Business Planning) es el módulo de S&OP y planeación de suministro dentro del ecosistema S/4HANA de SAP. Corre sobre la base de datos en memoria de HANA, lo que le da ventajas reales de velocidad en datasets grandes. La arquitectura es modular: Supply, Response & Supply, Demand, Inventory, y Sales & Operations son licencias separadas. Puedes empezar acotado. La trampa es que los módulos se cobran por separado y el valor real emerge de la integración entre ellos, así que tu implementación "inicial" tiene un camino de upsell integrado en la arquitectura misma del producto.

El precio para un fabricante de mercado medio (5,000-15,000 SKUs activos, 10-15 planners) cae en el rango de $380,000-$520,000 anuales solo en software. La implementación de un partner Big Four típicamente corre 18-24 meses y 1.5-2.5x el costo del software del primer año. El hogar natural de IBP es una empresa ya profundamente metida en SAP: si tu ERP es S/4 y tus datos maestros viven en SAP, el argumento de integración es real. Si tu ERP es Oracle o un stack a medida, estás agregando una capa de integración cuyo costo de mantenimiento se compondrá año tras año.

El Magic Quadrant 2024 de Gartner para Supply Chain Planning ubicó a IBP como Challenger, no como Leader. La razón: profundidad funcional fuerte, buen encaje con el ecosistema SAP, más débil en facilidad de uso y velocidad de despliegue frente a los competidores puros. Los puntajes de satisfacción de clientes en Gartner Peer Insights son reveladores: no malos, pero consistentemente por debajo de Kinaxis en "tiempo hasta el valor."

Kinaxis Maestro (antes RapidResponse) opera con un principio arquitectónico distinto: planeación concurrente. En vez de correr optimizaciones secuenciales (el plan de demanda alimenta al plan de suministro que alimenta al plan financiero), Maestro mantiene todos los planes en memoria simultáneamente y propaga los cambios entre ellos casi en tiempo real. Cuando un proveedor confirma un faltante de componente, Maestro no encola un batch nocturno para repropagar el impacto en el plan. Lo cascadea inmediatamente, a través de demanda, suministro y finanzas, y muestra las opciones de decisión.

Esta arquitectura es genuinamente diferenciada. También es genuinamente cara: $100,000-$500,000+ anuales según el número de usuarios y el alcance de módulos, con un multiplicador de implementación similar de 1.2-1.8x. Kinaxis es Leader en el MQ 2024 de Gartner, y sus puntajes de peer review son consistentemente los más altos de las tres plataformas en satisfacción del usuario y velocidad del ciclo de planeación. Su debilidad es la opuesta a la de SAP: fuerte en agilidad de planeación, más débil en integración profunda con S/4 para empresas donde el ERP es el sistema de registro para todo lo que ocurre después del plan.

La propuesta de planeación concurrente importa más para empresas con alta volatilidad de suministro, tiempos de entrega cortos al cliente, y ciclos de planeación que hoy corren semanalmente o más largos porque la ventana de batch es el cuello de botella. Si tu ciclo de planeación es diario o más rápido, la arquitectura de Kinaxis saca el reloj de la ecuación como restricción. Si tu ciclo de planeación es mensual y está impulsado por alineación humana más que por tiempo de cómputo, no verás la ventaja arquitectónica en la práctica.

o9 Solutions compite en el segmento alto: Fortune 500, redes globales complejas, planeación multiempresa. Su diferenciador es el Enterprise Knowledge Graph, un modelo de datos unificado que mapea las relaciones entre clientes, SKUs, proveedores, plantas y contratos, y permite a los planners consultar el plan como consultarían una base de datos de grafos: "¿cuáles son las dependencias de proveedores de segundo nivel para este SKU en EMEA?" en vez de "corre este reporte."

o9 fue Visionary en el MQ 2023 de Gartner. Fue degradado a Niche Player en 2024; el reporte citó preocupaciones de ejecución mientras o9 escalaba su base de clientes rápidamente. Las reseñas de clientes están más polarizadas que las de Kinaxis: puntajes altos en amplitud de capacidad, puntajes más bajos en experiencia de implementación y capacidad de respuesta del soporte. El precio es a medida y no público, pero los benchmarks de la industria lo ubican por encima de Kinaxis en el nivel enterprise.

Figure

La pregunta que el demo no puede responder

Toda plataforma produce un plan mejor que tu proceso actual en un entorno de demo controlado. El tenant del demo tiene datos maestros limpios: unidades de medida consistentes, sin números de material duplicados, tiempos de entrega de proveedores que reflejan la realidad y no el valor default del sistema desde 2017. Tu tenant no será así.

La restricción fundamental del software de planeación de supply chain no es algorítmica. Es de datos. El plan es tan bueno como los datos maestros que lo restringen y los reales que lo alimentan. Toda implementación que he visto quedarse corta frente a su caso de negocio tuvo la misma causa raíz: la herramienta de planeación se desplegó antes de que los datos estuvieran listos, y los datos nunca se limpiaron del todo porque el proyecto se quedó sin presupuesto después de que el software estuvo en vivo.

Antes de evaluar la lógica de planeación de cualquier plataforma, audita tus datos maestros contra cuatro preguntas:

1. Precisión de lead time. ¿Tus lead times de sistema reflejan el desempeño actual del proveedor, o el lead time contractual de hace tres años? En la mayoría de las implementaciones, la respuesta es el lead time contractual. La brecha entre el lead time de sistema y el lead time real es la mayor fuente individual de error de planeación, y ninguna plataforma la corrige algorítmicamente.
2. Consistencia de unidad de medida. ¿Todos los insumos (pronósticos de demanda, planes de suministro, posiciones de inventario) están expresados en la misma unidad? Las UoM mixtas son comunes en entornos multi-ERP y producen planners que sobrescriben el sistema porque no confían en las cantidades.
3. Completitud de la lista de materiales (BOM). Para fabricantes discretos, ¿todo producto terminado activo está cubierto por una lista de materiales vigente y precisa? El plan de suministro se construye sobre la explosión del BOM. Un BOM incompleto o desactualizado produce un plan estructuralmente incorrecto antes de que corra cualquier optimización.
4. Datos de capacidad de proveedor. ¿Tienes capacidad de proveedor confirmada por periodo, o planeas contra una salida de proveedor sin restricciones? La mayoría de las empresas planea sin restricciones y descubre las restricciones durante la ejecución. La plataforma no puede modelar restricciones que no están en el sistema.

Qué preguntar antes de firmar

Las preguntas que vale la pena hacer en negociaciones con proveedores no son sobre matrices de funcionalidades. Son sobre modos de falla.

Pide una referencia con tu perfil de datos. No tu industria: tu complejidad de datos. Si tienes 80,000 SKUs activos en 14 plantas de manufactura con 6 ERPs alimentando la capa de planeación, pide hablar con un cliente de perfil similar que lleve tres años o más post-go-live. Los early adopters son los que aparecen en los casos de estudio. Los clientes de tres años te cuentan cómo se ve el estado estable.

Pregunta quién es dueño del modelo post-implementación. La mayoría de las implementaciones las entrega un integrador de sistemas. Cuando el SI se va, el modelo queda con un equipo interno. Pregunta específicamente: ¿cuántos FTEs internos necesita un cliente comparable para operar esta plataforma en estado estable? La respuesta debería ser verificable. "Dos power users y un recurso de TI de medio tiempo" y "cuatro planners dedicados y un arquitecto de TI de tiempo completo" son ambas respuestas legítimas. La primera es optimista para una implementación compleja; la segunda es cara pero honesta. Cualquiera sea el número que te den, duplícalo para los primeros dos años.

Pregunta sobre el alcance de gestión del cambio. Las herramientas de planeación de supply chain cambian cómo trabajan los planners todos los días. La plataforma no es un sistema de fondo: es la interfaz principal de los planners. Si el plan de implementación no incluye un workstream estructurado de gestión del cambio con dueños internos nombrados, la implementación producirá un sistema que los planners rodean en vez de usar. Esto no es hipotético. La mayoría de las implementaciones de planeación "fallidas" que he visto se entregaron técnicamente a tiempo y en presupuesto. Fallaron porque los planners siguieron usando Excel como sistema de registro y usaron la nueva plataforma para generar un reporte para el deck de S&OP.

La secuencia correcta

Las plataformas son reales y el valor está disponible. La secuencia para capturarlo:

1. Establece tu línea base del proceso actual. Mide la precisión del pronóstico en cada nivel, mide el tiempo de ciclo de planeación, identifica los cinco principales workarounds manuales en tu proceso actual. Estos son tus benchmarks. Cualquier proveedor debería poder mostrarte específicamente cómo su plataforma aborda cada uno.
2. Limpia los datos primero. O como mínimo, define y financia el workstream de limpieza de datos antes del go-live, no después. Escálalo como un track paralelo a la implementación, no como una limpieza post-go-live.
3. Haz un piloto en un alcance acotado. Una familia de productos, una región, una planta. Prueba el concepto contra tus datos antes de escalar la licencia. La mayoría de los proveedores aceptará un piloto pagado que se convierte en licencia completa si tiene éxito; si no lo aceptan, eso te dice algo.
4. Define qué vas a dejar de hacer. Toda herramienta de planeación se adopta más rápido cuando el proceso viejo se apaga. Si los planners pueden seguir usando el proceso legacy en paralelo, lo harán, particularmente cuando la nueva plataforma se encuentre con los baches inevitables del rollout inicial. Define la fecha de corte y sostenla.

La plataforma no es el cuello de botella. Eres tú. La pregunta es si tu organización tiene la disciplina para arreglar sus datos, cambiar su proceso, y construir la capacidad interna para operar la herramienta que acabas de comprar. Los proveedores serán útiles en la venta y la implementación. La capacidad que sobrevive después de que se van es enteramente tuya de construir.

---

Fuentes

• Gartner. (2024). Magic Quadrant for Supply Chain Planning Solutions. gartner.com
• Gartner Peer Insights. (2024). Reviews for Supply Chain Planning, 2024. gartner.com
• Lee, H.L. (2004). The Triple-A Supply Chain. Harvard Business Review.
• Lapide, L. (2005). Sales and Operations Planning Part I: The Process. Journal of Business Forecasting.
• SAP. (2024). SAP IBP Product Overview. sap.com
• Kinaxis. (2024). Maestro Platform Overview. kinaxis.com
• o9 Solutions. (2024). Enterprise Knowledge Graph. o9solutions.com