Llevamos más de 15 años acompañando implementaciones SAP en distintos países e industrias. Y hay un patrón que se repite con una consistencia que ya no sorprende: los proyectos no fracasan por la tecnología. Fracasan por cómo las organizaciones se preparan para recibirla.
SAP S/4HANA, TM, EWM, IBP son plataformas maduras y probadas. Lo que varía entre un proyecto exitoso y uno que termina en un go live traumático o en un sistema subutilizado, casi siempre tiene que ver con decisiones tomadas (o no tomadas) mucho antes de que el primer consultor entre a una sala de diseño.
El alcance como espejo de madurez
Uno de los errores más costosos que vemos es el del alcance sobredimensionado en proyectos de una sola fase. La ambición no es un defecto. El problema es cuando la ambición supera la capacidad real de absorción del cambio de una organización.
Hay empresas que quieren migrar a S/4HANA, integrar gestión de transporte, almacenes y planeación, en doce meses, con el mismo equipo que opera el negocio de lunes a domingo. El resultado casi siempre es el mismo: el proyecto se extiende, los costos suben, y en el camino se pierde el foco en lo que realmente importa.
Un proyecto bien acotado, con objetivos claros y medibles, entrega más valor que uno ambicioso con resultados difusos. El marco metodológico que utilizamos como referencia, está diseñado precisamente para eso: estructurar el trabajo por etapas, con validaciones frecuentes que permiten ajustar antes de que los problemas escalen.
El rol del sponsor en el éxito del proyecto
Hay un factor crítico que PROSCI (la metodología de gestión del cambio organizacional más adoptada a nivel global) identifica como el predictor más confiable del éxito de cualquier proyecto de transformación: el patrocinio ejecutivo activo. No el nombre en la presentación de kickoff. El involucramiento real, semana a semana, en las decisiones que importan.
Cuando el sponsor del proyecto no tiene capacidad de dedicar tiempo o no tiene autoridad para tomar decisiones ágiles, los problemas de diseño migran. Van de la fase de exploración a la de realización. De la de realización a las pruebas. Y si llegan a las pruebas sin resolverse, llegan al go live.
Hemos visto situaciones en las que decisiones que debieron tomarse en semanas de diseño se resuelven (o se descubren) en la fase de pruebas integrales, cuando el costo de corregirlas es significativamente mayor. El defecto no es del sistema. Es de la gobernanza del proyecto.
La calidad del diseño depende de quién está en la sala
Los key users son los que conocen los procesos reales de la empresa. Son quienes saben que hay excepciones en ciertos clientes, que hay un flujo especial para determinadas rutas, que la lógica de ciertos almacenes no sigue el proceso estándar. Cuando esos perfiles no están disponibles durante el diseño, o cuando participan de forma parcial porque siguen operando el 100% de su rol, o cuando, simplemente, hay omisiones de aspectos relevantes, el diseño se hace sobre supuestos.
Esos supuestos se prueban en las fases de pruebas integrales. Y lo que «resultaba que no era como se necesitaba» aparece tarde, con poco margen para corregirse bien. En proyectos como TM o EWM, donde las pruebas integrales son el momento de verdad de todo el diseño logístico, llegar a esa etapa con definiciones incompletas es especialmente costoso.
La adopción por parte del usuario no comienza en la capacitación. Comienza en el momento en que esos usuarios participan activamente en definir cómo va a operar el sistema. Cuando son co-diseñadores, no solo receptores de un sistema que alguien más construyó para ellos.
Datos maestros: una responsabilidad que no se puede delegar
Este punto merece su propio artículo, pero no puede faltar aquí. La calidad de los datos maestros es responsabilidad del cliente. Siempre. El consultor puede definir la estructura, proporcionar las plantillas, validar la lógica. Pero los datos del negocio los conoce y los cuida el cliente.
Cuando el sistema no entrega los resultados esperados después del go live, la primera pregunta que hay que hacerse no es qué falló en la configuración. La primera pregunta es si el proceso se ejecutó conforme a lo definido, y si los datos con los que opera el sistema son los correctos.
Esto no es una crítica. Es una delimitación de responsabilidades que, cuando se clarifica desde el inicio del proyecto, ahorra semanas de diagnóstico en las etapas más críticas.
Gestión del cambio: no es un lujo, es una variable del resultado
PROSCI define tres condiciones para que una transformación sea exitosa en el plano humano: que las personas entiendan por qué cambia su forma de trabajar, que tengan las habilidades para operar en el nuevo esquema y que cuenten con el refuerzo sostenido después del go live. Cuando alguna de las tres falla, el sistema puede estar perfectamente configurado y aun así no entregar los resultados esperados.
En la práctica, la gestión del cambio es uno de los primeros componentes que los clientes consideran reducir o asumir internamente para ajustar presupuesto. Es una decisión válida, y hay organizaciones con la madurez para gestionarlo bien por su cuenta. Pero en nuestra experiencia, los proyectos donde este componente se trabaja de forma estructurada, con indicadores de adopción, plan de comunicación y acompañamiento a líderes, tienen una curva de estabilización post go live notablemente más corta.
No en todos los proyectos que acompañamos incluimos consultoría formal de gestión del cambio. Pero siempre lo consideramos un factor crítico, y siempre lo ponemos sobre la mesa.
La transformación la hace la organización, no el software
SAP es una herramienta poderosa. Pero una herramienta solo funciona bien cuando quien la usa sabe cómo usarla, cuándo usarla y por qué.
Los proyectos más exitosos que hemos acompañado tienen algo en común: el cliente y el equipo consultor trabajaron como uno solo, con un objetivo común. Participaron juntos en el diseño, garantizaron la calidad de los datos, asignaron perfiles con capacidad de decisión y mantuvieron el foco en el objetivo del negocio, no solo en la fecha de go live.
Eso no sucede por inercia. Sucede cuando hay claridad de roles desde el inicio, gobernanza activa durante el proyecto y una organización que entiende que el sistema es el medio, no el fin.
¿Tu próximo proyecto SAP ya contempla esto desde el inicio?
En GoSCM llevamos más de 15 años acompañando proyectos SAP de supply chain y ERP en empresas líderes de manufactura, consumo masivo, farmacéutica, entre otras. Si estás en proceso de evaluación de un proyecto o en etapas tempranas de una implementación SAP, con gusto podemos conversar.
Francisco Flores
Gerente Regional Mexico, Centroamerica y Caribe.
