IBP rollout, mes 18: lo que hicimos mal
El sistema salió en vivo. Los forecasts mejoraron marginalmente. La organización peleó contra el proceso durante dieciocho meses. Un post-mortem sobre lo que realmente cuesta una transformación de IBP.
El go-live ocurrió un martes de octubre. El director del programa envió un correo al comité directivo. Dashboard verde. Todos los hitos cumplidos. El sistema estaba en vivo en seis mercados, cubriendo el 78% de los ingresos, con 14 meses de datos históricos cargados y el motor de forecast estadístico corriendo cada noche.
Para el marzo siguiente, tres de los seis mercados habían vuelto a mantener archivos de Excel en paralelo con el sistema. La planificadora de demanda del mercado más grande había reconstruido en silencio todo su libro de planeación y exportaba del sistema hacia él cada mañana. El proceso de S&OP que la herramienta de IBP debía habilitar estaba corriendo aproximadamente al mismo nivel de madurez que tenía antes de la implementación de $4.2 millones.
Esto es un post-mortem. Los nombres están cambiados. El patrón no es inusual.
Lo que IBP se supone que entrega
Integrated Business Planning es la forma evolucionada de S&OP: la misma lógica de alineación interfuncional, extendida para cubrir todo el horizonte de planeación (típicamente 24–36 meses), totalmente integrada con la planeación financiera, y habilitada por una única plataforma de planeación en lugar del mosaico de Excel-y-ERP que la mayoría de las empresas maneja.
Los proveedores, SAP IBP, o9 Solutions, Kinaxis, OMP, Anaplan, prometen versiones del mismo resultado: una versión única de la verdad, capacidad de planeación de escenarios, reconciliación oferta-demanda en tiempo real, y la eliminación de la sobrecarga de reconciliación manual que mata la productividad en la mayoría de los equipos de planeación.
El Gartner Market Guide for Supply Chain Planning Solutions (2023) estima que las empresas con capacidad de IBP madura logran reducciones de inventario de 15–20%, mejora de 10–15% en precisión del forecast, y reducción de 20–30% en el ciclo de planeación. Son números reales de implementaciones reales. También son los números del cuartil superior de implementaciones. La historia mediana es distinta.
Lo que dice la investigación sobre el fracaso de la implementación de IBP
El 2023 ERP/Planning Report de Panorama Consulting, que cubre 271 implementaciones, encontró que el 58% de las implementaciones de planeación de supply chain superó su presupuesto original, con un sobrecosto promedio del 24%. El retraso promedio en el cronograma fue del 33%. De forma más significativa, solo el 41% de los encuestados dijo que su implementación entregó los beneficios de negocio esperados dentro de los tres años posteriores al go-live.
Un estudio de Gartner de 2022 encontró que la causa número uno de fracaso en implementaciones de planeación de supply chain fue la gestión del cambio organizacional, citada por el 67% de los encuestados, por delante de problemas tecnológicos (31%), calidad de datos (48%) y brechas en el diseño de procesos (44%). Nótese que la calidad de datos fue citada por casi la mitad de los encuestados pero aun así quedó por debajo de la gestión del cambio.
El análisis de 2023 de Boston Consulting Group sobre transformaciones digitales de supply chain encontró que el 70% de las transformaciones digitales de supply chain no logró sus objetivos declarados, un número consistente con la tasa de fracaso de transformación digital más amplia, que McKinsey ha estimado en 70% a través de industrias.
Lo que las estadísticas agregadas no capturan es la textura específica de cómo fracasan las implementaciones de IBP. El sistema funciona. Los datos cargan. Los modelos estadísticos corren. El fracaso está en la adopción, y el fracaso de adopción sigue un patrón consistente.
Meses 1–3: la luna de miel
Los primeros tres meses después del go-live son genuinamente productivos. El equipo de planeación recibió capacitación intensiva. Los consultores siguen en sitio. El comité directivo está atento. Los problemas de calidad de datos que se conocían pero se toleraban en el sistema anterior se están atendiendo activamente porque el nuevo sistema los hace visibles.
La precisión del forecast mejora modestamente, típicamente de 3 a 5 puntos porcentuales, porque los nuevos modelos estadísticos son mejores que los basados en Excel que reemplazaron, y porque la limpieza de datos que ocurrió durante la implementación eliminó parte del ruido en el historial.
El equipo está aprendiendo la herramienta. Cada ciclo de planeación es más lento que antes porque el proceso es desconocido. Esto se espera y se comunica. Los consultores explican que hay una caída de productividad antes de que la curva se recupere. El comité directivo lo acepta. El director del programa reporta que las métricas de adopción van según lo previsto.
Meses 4–6: la primera crisis
Algo sale mal con los datos. Siempre es algo con los datos.
En el caso que describo, fue el historial promocional. La empresa manejaba promociones comerciales significativas (ofertas BOGOF, descuentos por volumen, promociones de precio coordinadas con cuentas clave) y los datos históricos cargados en el sistema no marcaban sistemáticamente estos periodos. El forecast estadístico estaba, por lo tanto, extrapolando a partir de un historial que incluía uplifts promocionales sin saber que eran uplifts promocionales. El resultado fue un forecast baseline estructuralmente sesgado al alza para ciertos SKUs.
Los planificadores de demanda lo sabían. Lo habían sabido durante años. En el sistema anterior, lo corregían manualmente, usando conocimiento institucional sobre qué periodos eran promocionales y aproximadamente cuánto descontar del historial. El nuevo sistema no tenía ese conocimiento. La lógica de corrección se suponía que se construiría durante la implementación. Se construyó parcialmente, lo suficiente para pasar el UAT, pero no lo bastante robusta para manejar toda la gama de mecánicas promocionales que usaba la empresa.
La planificadora de demanda del mercado tres, que llevaba nueve años en su rol, lo señaló en la semana seis. La respuesta del equipo de implementación fue que se estaba definiendo el alcance de una corrección. La corrección tomó once semanas en implementarse completamente. Durante esas once semanas, ella mantuvo su archivo de Excel.
Nunca dejó de usarlo del todo.
Meses 7–12: la salida de los consultores
El equipo consultor se retiró en el mes ocho. Esto es estándar. El contrato de implementación cubre el go-live y un periodo de estabilización. Para el mes ocho, se declara la estabilización. Los consultores transfieren conocimiento al equipo interno, documentan el proceso, y se van.
Lo que se va con ellos: el conocimiento institucional de por qué se tomaron ciertas decisiones de diseño, la capacidad de escalar problemas de datos rápidamente dentro de la estructura de soporte del proveedor, y la energía de cambio que mantenía comprometido al comité directivo.
Lo que queda: un equipo interno que entiende la herramienta a nivel de usuario pero no a nivel de configuración, un conjunto de documentos de proceso que describen cómo se supone que se ve el proceso más que cómo se ve realmente, y un contrato de soporte del proveedor que atiende bugs pero no adopción.
El primer ciclo de S&OP después de que se fueran los consultores tomó tres días más que el ciclo anterior. La reunión de revisión de demanda se extendió dos horas más de lo programado porque un problema de datos en el sistema no se pudo diagnosticar en la sala. El equipo comercial, que había tolerado los tiempos de ciclo más lentos en deferencia al programa, comenzó a preguntarse abiertamente si el nuevo sistema era realmente mejor que el anterior.
Meses 13–18: el problema de los archivos paralelos
Para el mes trece, los archivos de Excel en paralelo eran visibles si sabías dónde buscar.
No eran secretos. Los planificadores no los escondían. Eran adaptaciones prácticas a brechas específicas del sistema. La planificadora de demanda del mercado uno tenía un archivo para gestionar lanzamientos de nuevos productos: el proceso de NPI del sistema era demasiado lento para la velocidad a la que comercial lanzaba productos. El planificador del mercado cuatro tenía un archivo para gestionar forecasts específicos por cliente: tres cuentas clave requerían envíos semanales de forecast que no encajaban en los buckets de planeación del sistema. La planificadora del mercado tres tenía su archivo de corrección de historial promocional, que nunca se había reemplazado del todo.
Cada archivo era una respuesta razonable a una brecha real. Cada archivo era también una fractura en la "versión única de la verdad" con la que se vendió la implementación de IBP.
El problema se agrava porque los archivos no se quedan contenidos. Una vez que una planificadora tiene un archivo paralelo en el que confía más que en el sistema para un propósito, el límite de esa confianza se expande. Empieza a verificar el número del sistema contra su archivo antes de comprometerse con él. Cuando divergen, usa su número. El sistema se convierte en el insumo de su proceso en lugar de en el resultado.
Para el mes dieciocho, el director de planeación no podía decirle al comité directivo con confianza que los números en el sistema de IBP eran los números con los que los mercados realmente estaban planeando.
Lo que realmente falló
No la tecnología. SAP IBP es un sistema capaz. El motor de forecast funciona. Las herramientas de planeación de escenarios funcionan. La integración financiera funciona.
No los datos. La calidad de datos mejoró genuinamente con la implementación: los datos maestros estaban más limpios, los datos históricos estaban más completos, y el problema del historial promocional, aunque tomó tres meses, se corrigió.
Lo que falló fueron tres cosas que la metodología de implementación no atendió adecuadamente:
El proceso fue diseñado para la organización que se aspiraba a tener, no para la organización que existía. El proceso de estado futuro asumía que comercial entregaría insumos de volumen promocional estructurados con cadencia mensual. En la práctica, comercial entregaba información promocional deal-by-deal, a menudo dos semanas antes de la ejecución, en formatos que variaban por mercado y por gerente de cuenta clave. La brecha de diseño de proceso entre "comercial entrega volumen mensualmente" y "comercial llama a planeación el jueves antes de que una promoción salga en vivo" nunca se cerró.
Los incentivos no cambiaron. A los planificadores de demanda se les medía por precisión del forecast. El forecast estadístico del sistema de IBP era su baseline, pero su bono se calculaba sobre la precisión del forecast de consenso, que ellos eran responsables de ajustar a partir del baseline estadístico. Cuando el baseline estadístico del sistema estaba mal (como en el caso del historial promocional), ajustarlo correctamente mejoraba la precisión. Pero el ajuste tomaba tiempo y requería defender la anulación frente al equipo comercial. El camino de menor resistencia era mantener el archivo de Excel, usarlo para producir el número correcto, y meter ese número en el sistema. El sistema registraba el resultado. El archivo de Excel contenía el razonamiento.
El programa de gestión del cambio terminó en el go-live. El workstream de gestión del cambio dentro de la implementación (comunicaciones, capacitación, gestión de stakeholders) estaba estructurado en torno a la adopción de la herramienta, no la adopción del proceso. Medía si los usuarios podían operar el sistema, no si confiaban en él lo suficiente como para dejar de usar alternativas. Después del go-live, el presupuesto de gestión del cambio estaba agotado y la atención se movió a otra parte. La resistencia de la organización al proceso, que había sido suprimida durante la implementación por la energía del programa, resurgió una vez que esa energía se retiró.
Lo que requiere una transformación real de IBP que nadie presupuesta
Con base en el post-mortem, y en lo que he visto en otras implementaciones:
El Año 2 es la implementación real. El primer año es despliegue del sistema. El segundo año es cuando el proceso realmente arraiga, lo cual requiere recurso interno dedicado, atención ejecutiva continua, y un presupuesto para las correcciones que surgen del uso en el mundo real. La mayoría de los contratos de implementación presupuestan el Año 1. El Año 2 es una idea de último momento.
Un arquitecto de procesos que no sea empleado del proveedor. Los consultores de implementación de los proveedores son expertos en desplegar la herramienta dentro de la arquitectura de referencia del proveedor. No tienen incentivo para decirte que el proceso comercial de tu organización es estructuralmente incompatible con ciclos de planeación mensuales. Ese juicio requiere a alguien que responda ante los resultados de tu negocio, no ante el proyecto de implementación.
Alineación de incentivos antes del rediseño de procesos. Si la estructura de bonos del equipo comercial premia el ingreso dentro del año sin considerar la precisión del forecast, ningún proceso de IBP producirá señales de demanda honestas. El proceso está aguas abajo del incentivo. Corregir el proceso sin corregir el incentivo produce números que parecen precisos pero no reflejan la realidad comercial.
Una evaluación honesta de los archivos paralelos. En el mes dieciocho, la respuesta correcta al problema de los archivos paralelos no era exigir que los planificadores dejaran de usarlos. Era entender por qué existía cada archivo, corregir las brechas que los crearon, y ganarse la confianza que haría que los planificadores estuvieran dispuestos a dejarlos ir. No lo hicimos lo suficientemente rápido.
El número que importa
En los dieciocho meses desde el go-live hasta el punto en que se encargó este post-mortem, la implementación de IBP había costado la cuota de implementación original de $4.2 millones, más aproximadamente $1.1 millones en estabilización y correcciones, más un estimado de 2,400 horas-persona de tiempo interno de planeación gastadas gestionando la brecha entre el sistema y los archivos paralelos.
La precisión del forecast, la métrica principal, había mejorado 4 puntos porcentuales desde el baseline. El inventario se había reducido 8% en dos mercados y aumentado 3% en un mercado donde el problema del historial promocional había causado sobrecompra antes de que se desplegara la corrección. La integración financiera funcionaba de forma limpia en cuatro de seis mercados.
El director del programa llamó a esto un éxito parcial. Probablemente tenía razón. Tampoco era lo que se prometió, ni lo que se compró, ni lo que justificaba el costo total de $5.3 millones.
La lección no es que IBP no funcione. La lección es que el contrato de implementación cobra la tecnología y el go-live. La transformación se cobra por separado, en tiempo ejecutivo, recurso interno, rediseño de procesos y ajuste de incentivos, y ese precio casi nunca se cotiza por adelantado.
Fuentes
- Panorama Consulting Group. (2023). 2023 ERP Report. Panorama Consulting.
- Gartner. (2023). Market Guide for Supply Chain Planning Solutions. Gartner Research.
- Gartner. (2022). "Top Reasons Supply Chain Planning Implementations Fail." Gartner Research Note.
- Boston Consulting Group. (2023). "Digital Supply Chain Transformation: Why Most Fail and How to Succeed." BCG.
- McKinsey & Company. (2018). "Unlocking success in digital transformations." McKinsey Digital.
- Oliver Wight International. (2023). IBP Maturity Assessment Framework. Oliver Wight.
- ASCM. (2022). Supply Chain Resilience and Digital Readiness Report. ASCM.
- Wallace, T. F. (2004). Sales & Operations Planning: The Executive's Guide. T.F. Wallace & Company.
- Cecere, L. (2022). Supply Chain Metrics That Matter. Supply Chain Insights LLC.
- Lapide, L. (2011). "IBP: Not your father's S&OP." The Journal of Business Forecasting. 30(3).