Cómo evitar el scope creep en una implementación de SAP

El scope creep, la ampliación descontrolada del alcance, se evita en una implementación de SAP haciendo que cada cambio sea visible y costoso de aprobar. Escriba lo que queda fuera del alcance con el mismo cuidado que lo que entra. Canalice cada petición por el control de cambios, con una evaluación de impacto en plazo, costo y calidad. Exija una contrapartida por cada añadido. Fije una fecha de congelación del alcance con respaldo directivo y ponga la misma disciplina en el contrato con el integrador de sistemas (SI). Esta guía es para directores de programa, sponsors y PMO de programas de S/4HANA. Use la tabla de costo del cambio y las cláusulas contractuales que aparecen más abajo en su próximo informe para el comité directivo.

La mayoría de los proyectos SAP se pasan de presupuesto y de plazo, y el scope creep es la razón más habitual. He trabajado con decenas de empresas cuyos proyectos SAP se descontrolaron, y hay tres señales que aparecen antes de que el desvío llegue al informe del comité directivo. Los cambios pequeños se acumulan sin evaluación de impacto. El control de cambios se apoya en relaciones personales en lugar de en una autoridad documentada. Y el sponsor aprueba tomando un café cosas de las que el equipo del proyecto se entera una semana después.

Un cliente farmacéutico empezó con un calendario claro de 18 meses. Tres años después seguía implementando y los costos se habían duplicado. El CIO de una empresa industrial me contó que su equipo había descartado módulos enteros que había tardado meses en configurar, porque los requisitos no dejaban de cambiar. El alcance había crecido tanto que nadie reconocía el plan original.

No son casos extremos. Es la forma más habitual en que fracasan los programas SAP.

Empieza de forma inocente. Un responsable de negocio pide «un pequeño cambio nada más». Luego otro. La frase «ya que estamos con esto, solo...» ha descarrilado más implementaciones de SAP que cualquier reto técnico.

Trabajé con un cliente de retail con el que empezamos limpio: el núcleo de Finanzas y la Gestión de materiales básica. A los seis meses, el CMO quiso analítica de clientes. Después, el COO necesitó funciones avanzadas de almacén. El calendario original de nueve meses peligraba. Me planté y rechacé ambas peticiones. Esa disciplina es el trabajo.

No todo cambio es scope creep. A veces se descubren en el diseño carencias críticas que nadie había previsto. A veces cambia la normativa a mitad de proyecto. Esos cambios son legítimos y siguen un proceso con ajustes de calendario y presupuesto. El scope creep simplemente aparece, normalmente tras una conversación de pasillo.

Un cliente industrial empezó con 10 informes a medida y terminó con 47, y cada uno sumaba tiempo de diseño, construcción y pruebas. Solo el frente de reporting superó el presupuesto en un 200 %.

200 %

de sobrecosto en el presupuesto del frente de reporting tras pasar de 10 a 47 informes a medida por la deriva del alcance

Fuente: Programa de un cliente industrial

Señales de alerta

Estas son las señales que vigilo y la respuesta a cada una:

Señal de alerta	Causa de fondo	Respuesta
«Una cosa más» se vuelve el lenguaje diario	Límites del alcance poco claros	Redefinir la línea base con los responsables de negocio; imponer un control de cambios formal
Los responsables de negocio añaden funciones de manera informal	No se entiende el impacto en cascada	Canalizar cada petición por una evaluación de impacto; mostrar el costo
El calendario se alarga sin una replanificación formal	Ampliación silenciosa del alcance	Celebrar revisiones de alcance; replanificar con la aprobación del comité de control de cambios
La documentación ya no coincide con lo construido	Gestión informal del alcance, sin control de versiones	Actualizar especificaciones y planes con cada cambio aprobado
El consumo de presupuesto va por delante del avance	Esfuerzo oculto de cambios no documentados	Seguir el esfuerzo por paquete de trabajo; investigar las desviaciones
El equipo trabaja noches y fines de semana para ponerse al día	El alcance supera la capacidad	Escalar al comité de control de cambios; forzar una decisión sobre el alcance
Reproches entre negocio, TI y el socio	El alcance ya se ha descontrolado	Congelar el alcance, hacer un análisis de causa raíz y restablecer la línea base

Todo está conectado

SAP lo conecta todo. Finanzas afecta a la cadena de suministro. RR. HH. toca la nómina. Ventas se conecta con el inventario. Un solo cambio puede romper diez cosas.

Un cliente añadió un único campo a su proceso de pedidos de compra. Parecía trivial. Rompió tres interfaces y obligó a reescribir informes en varios departamentos. Otro cliente pidió un «cambio minúsculo» en su esquema de cálculo de precios, que resultó exigir reconfigurar toda la estructura de precios: tres semanas de trabajo y 40.000 dólares en honorarios de consultoría, por un cambio minúsculo.

La presión de una vez por década

La mayoría de las empresas implementan SAP una vez cada 10 a 15 años. Cada departamento sabe que no tendrá otra oportunidad en una década. Nadie quiere oír hablar de una «fase 2», que en la mayoría de las organizaciones significa nunca. Así que todo se empuja al proyecto actual y la lista de alcance se convierte en una lista de deseos.

Qué cambia el clean core

El clean core pone un freno técnico a la personalización. En S/4HANA Cloud Public Edition no es posible modificar el núcleo: las extensiones pasan por API publicadas (released APIs), on-stack o side-by-side en SAP BTP. En Private Edition y on-premise la modificación sigue siendo posible, pero la guía de SAP la considera un último recurso, porque cada una añade trabajo en las actualizaciones.

El efecto secundario útil es la disciplina de alcance. Una petición de «añadir solo este paso de aprobación al order-to-cash estándar» deja de ser una charla informal de configuración y se convierte en una extensión con su propio costo de diseño, construcción y pruebas. Si se sitúa un foro de revisión de extensiones por debajo del comité directivo, con un arquitecto que pueda aprobar o rechazar, muchas de estas peticiones se detienen antes de entrar en la línea base. Los programas on-premise sin ese foro recaen en los viejos hábitos. Mi guía de clean core explica cómo montar uno.

1. Defina el alcance con exclusiones explícitas. Documente lo que queda fuera del alcance con el mismo cuidado que lo que entra y consiga la aprobación de ambos. La ambigüedad es donde empiezan las discusiones.
2. Aplique un control de cambios formal, con consecuencias. Todo cambio necesita una evaluación de impacto en costo, plazo y calidad, visible para quien lo apruebe.
3. Comunique los límites del alcance en cada reunión del comité directivo. Muestre el estado del alcance con una vista sencilla en rojo, ámbar y verde. Buena parte de la deriva es un malentendido.
4. Redacte un plan de gestión del alcance. Establezca cómo se evalúan, aprueban, escalan y siguen los cambios, para que todos los frentes de trabajo los traten igual. Mi plantilla de alcance de proyecto SAP ofrece una estructura de partida.
5. Priorice con MoSCoW. Imprescindible (Must have), importante (Should have), deseable (Could have) y descartado por esta vez (Won't have). Presione con firmeza para que la lista de imprescindibles se mantenga corta.
6. Controle las versiones de cada decisión. Cada cambio aprobado actualiza la línea base. Cada cambio rechazado se registra con su motivo.
7. Exija contrapartidas. Si entra un requisito nuevo, sale otra cosa. Los imprescindibles se vuelven opcionales enseguida cuando cuestan algo.

Tres técnicas que he utilizado hacen que todo esto se sostenga.

Disciplina de firma. Haga que los responsables de negocio firmen los requisitos aprobados. En un programa, un responsable de negocio juró que nunca había aprobado un determinado flujo de proceso. Presentamos el documento con su firma y la discusión terminó. La firma no es burocracia. Evita que la misma discusión vuelva a empezar seis meses después.

Muestre el efecto dominó. Preparé para un cliente una demostración de cómo cambiar un campo de un pedido de venta afectaría a 14 áreas, desde el reporting hasta las interfaces y los roles de seguridad. El comportamiento cambió. Educar cuesta horas. No entender el efecto dominó cuesta meses.

Muestre el costo del cambio. Un cambio durante el diseño puede costar 5000 dólares. El mismo cambio durante las pruebas puede costar 50.000 dólares. Ponga delante de la gente un gráfico sencillo con eso y las peticiones a la ligera se frenan.

Estos son rangos indicativos del costo de un cambio en programas de S/4HANA en el mercado estadounidense. Varían con la complejidad y el socio. Úselos como referencias, no como presupuestos.

Fase	Costo típico de un cambio pequeño	Costo típico de un cambio mediano
Explore (diseño)	De 2 mil a 10 mil USD	De 10 mil a 30 mil USD
Inicio de Realize	De 5 mil a 20 mil USD	De 20 mil a 80 mil USD
Mitad de Realize (construcción)	De 15 mil a 50 mil USD	De 50 mil a 200 mil USD
Final de Realize (pruebas)	De 30 mil a 100 mil USD	De 100 mil a 400 mil USD
Deploy y cutover	De 80 mil a 300 mil USD	De 300 mil a 1 millón de USD o más
Hypercare (después del go-live)	De 150 mil a 500 mil USD	De 500 mil a 2 millones de USD o más

El patrón coincide con lo que la investigación lleva décadas constatando. Un estudio de la NASA sobre la escalada del costo de los errores halló que un error de requisitos detectado en integración y pruebas costaba entre 21 y 78 veces más de corregir que uno detectado durante los requisitos, y mucho más una vez que el sistema estaba en operación. La gobernanza del alcance existe para mantener los cambios en el lado barato de esa curva.

Cláusulas contractuales que importan

Los contratos vagos crean problemas caros. He visto a un cliente firmar un contrato que decía solamente «implementar S/4HANA». Más tarde el socio sostuvo que ciertos procesos eran extras con honorarios adicionales, y el cliente acabó pagando el doble. Estas cláusulas lo evitan:

Cláusula	Finalidad
Alcance con exclusiones explícitas	Limita lo que cubre el precio fijo y elimina la ambigüedad sobre los extras
Tarifas pactadas de antemano para cambios habituales	Fija los precios de informes, interfaces y cambios de configuración antes de que llegue la presión
Continuidad de los consultores	Evita que consultores nuevos reabran decisiones ya cerradas y amplíen el alcance
Autoridad de aprobación en ambas partes	Evita que consultores júnior prometan funciones que nadie autorizó
Facturación por hitos	Vincula el pago a entregables aprobados, no al tiempo transcurrido
Criterios de aceptación por entregable	Define qué significa «terminado» antes de que nadie discuta
Cláusula de extensiones clean core	Exige que las extensiones usen API publicadas o SAP BTP; ahorra retrabajo en la primera actualización importante

Mis notas sobre la negociación de contratos ERP explican cómo lograr que se acepten estas cláusulas.

Comité de control de cambios

Un comité de cambios funciona cuando tiene a las personas adecuadas. Yo monto el mío con tres roles: un decisor de negocio al que le importa la funcionalidad, un jefe de proyecto al que le importa el calendario y un responsable de finanzas al que le importa el presupuesto. Ese equilibrio impide que una sola prioridad domine.

1. 01Se plantea la peticiónPor escrito, no tomando un café
2. 02Evaluación de impactoPlazo, costo y calidad, antes de que nadie apruebe
3. 03Se fija la contrapartidaSale otra cosa para hacer sitio
4. 04Decide el comité de cambiosNegocio, proyecto y finanzas en la mesa
5. 05Se actualiza la línea baseLos cambios rechazados se registran con su motivo

El alcance solo se mueve a través del comité

El comité necesita autoridad real. En un programa, ningún cambio de alcance se produjo sin su aprobación. Ni uno. Los acuerdos de pasillo se acabaron. Cuando el vicepresidente de ventas intentó colar nuevos requisitos, el equipo tenía una matriz de aprobación documentada a la que remitirse.

La mayoría de las decisiones deberían quedarse a nivel del comité. Solo las discrepancias reales llegan al sponsor, lo que lo mantiene implicado sin ahogarlo. Celebre una revisión de alcance con los responsables de cada frente cada dos semanas e informe de las peticiones presentadas, aprobadas y rechazadas. Cuando la gente ve «un 15 % de crecimiento del alcance este mes» en un informe de estado, el comportamiento cambia.

Algunos cambios son necesarios. A un cliente farmacéutico mío le cayó encima una nueva normativa de la FDA a mitad de la implementación. Había que incorporarla. Eso no es scope creep. Es la realidad.

Cuando llega un cambio legítimo, haga dos preguntas. ¿Cuál es la corrección más pequeña que funcionará? Y, a quien lo pide: ¿qué está dispuesto a quitar para hacer sitio? La urgencia baja rápido cuando una petición cuesta algo.

Las opciones son ampliar el calendario, añadir presupuesto, recortar otros requisitos, sumar personas o una combinación. Elija lo que elija, documéntelo y actualice todos los documentos de la línea base a la vez. Los documentos desactualizados generan la siguiente ronda de problemas de alcance.

La IA ya ayuda con el papeleo. Asistentes como Microsoft Copilot resumen largos hilos de peticiones de cambio en una nota lista para que decida el comité, y SAP Cloud ALM mantiene vinculados requisitos, cambios y pruebas, de modo que el impacto de un cambio es más fácil de rastrear. La IA puede mostrar que un cambio toca 14 áreas. No puede decirle a la COO que su petición implica que la petición del CFO no se hará. Esa conversación sigue siendo suya.

Una empresa industrial con la que trabajé terminó su proyecto SAP a tiempo, algo más raro de lo que debería. Fijó pronto una fecha de congelación del alcance, y cualquier cambio posterior necesitaba la aprobación personal del CEO. El proyecto cerró con presupuesto sobrante y nadie trabajaba en fin de semana en el go-live.

Otro cliente usó un sistema de fichas: cada departamento recibió tres fichas de cambio para todo el proyecto. ¿Quiere un cambio? Gaste una ficha. La gente pensó muy bien qué era lo importante, y los «imprescindibles» se reconsideraron en cuanto costaban una moneda limitada.

Ninguno de los dos enfoques es complicado. Ambos requieren disciplina y respaldo de la dirección. La prueba de cualquier proceso de alcance es el día en que el COO entra en la sala del proyecto con «un pequeño cambio nada más». Constrúyalo para ese día.

¿Qué es el scope creep en un proyecto SAP?

El crecimiento gradual y descontrolado de los requisitos sin los cambios correspondientes en calendario, presupuesto o recursos. En SAP suele empezar con pequeños añadidos: informes extra, campos extra, «solo un cambio rápido en un workflow». Cada uno parece inofensivo. Juntos suman meses.

Los cambios de alcance legítimos siguen un proceso y vienen acompañados de ajustes de calendario y presupuesto. El scope creep llega de manera informal y se salta el control de cambios.

¿Cuáles son las causas más comunes del scope creep en los proyectos SAP?

Tres aparecen de forma constante: requisitos iniciales vagos, de modo que cualquier cosa se puede defender como incluida en el alcance; ausencia de control de cambios formal, de modo que los cambios se cuelan en todos los niveles; y la mentalidad de una vez por década, en la que cada departamento intenta resolver años de problemas en este proyecto.

La interconexión de SAP amplifica las tres. Un cambio puede romper diez procesos conectados, y si los responsables de negocio no ven esas conexiones, el impacto aparece en las pruebas, cuando cuesta muchas veces más.

¿Cómo cambia el clean core el riesgo de scope creep?

Añade un freno técnico. En S/4HANA Cloud Public Edition el núcleo no se puede modificar, así que cada brecha se convierte en una extensión con su propio costo de diseño, construcción y pruebas. En Private Edition y on-premise la modificación es posible, pero añade trabajo en las actualizaciones, por lo que la guía de SAP la desaconseja.

Un foro de revisión de extensiones, con un arquitecto con autoridad para decidir, detiene muchas peticiones antes de que entren en la línea base. Sin ese foro, los programas on-premise vuelven a los viejos hábitos.

¿Qué diferencia hay entre el scope creep y el gold-plating?

El scope creep viene del negocio: peticiones que van más allá de lo acordado. El gold-plating viene del equipo de entrega: una complejidad que nadie pidió.

En términos de SAP, el gold-plating es un consultor que construye una lógica de workflow elaborada donde bastaría un enrutamiento sencillo. El scope creep es el COO pidiendo funciones avanzadas de almacén seis meses después de empezar un proyecto con alcance de MM básico. Ambos inflan el costo y el plazo, y ambos requieren la misma disciplina.

¿Cómo se estructura un proceso de control de cambios que funcione de verdad?

Tres elementos. Cada petición lleva una evaluación de impacto en calendario, presupuesto y recursos. El comité de aprobación incluye a alguien a quien le importa cada uno de esos tres aspectos, no solo a responsables de negocio, que lo aprobarán todo. Y cada añadido exige una contrapartida: sale otra cosa.

Solo esa última regla ya filtra las peticiones que no son realmente críticas.

¿Se puede evitar el scope creep por completo?

No. En cualquier programa que dure más de unos pocos meses, las condiciones del negocio cambian, la normativa cambia y el diseño destapa carencias.

El objetivo es el control, no la eliminación. El cambio controlado sigue un proceso documentado, se evalúa en su impacto y actualiza la línea base. El cambio descontrolado se salta el proceso y aflora en las pruebas o después del go-live como un costo que nadie había planificado.

¿Cuál es la mejor manera de gestionar la congelación del alcance en un programa SAP largo?

Dándole una consecuencia y un respaldo directivo visible. La versión más eficaz que he usado: la fecha de congelación figura en el acta de constitución del proyecto desde el primer día, el proceso de cambios define qué significa «congelación» en la práctica y el sponsor la refuerza en público en el comité directivo antes de que llegue la fecha.

Cuando el CEO tiene que aprobar personalmente cada cambio posterior a la congelación, la lista se mantiene muy corta.