Plantilla de alcance de un proyecto SAP: qué definir y qué excluir

Una plantilla de alcance de un proyecto SAP define lo que el programa entregará, lo que deliberadamente no entregará, quién es responsable de cada parte y cómo puede cambiar el alcance. Las nueve secciones siguientes lo cubren. Las dos que más importan son las que los equipos se saltan: las exclusiones explícitas y el alcance de la migración de datos. Rellene la plantilla antes de que empiece la configuración y consiga que la firmen el patrocinador y los responsables de proceso.

A veces los equipos rellenan una plantilla de alcance y siguen adelante. Esa parte parece fácil. Semanas después, durante el diseño o la construcción, alguien señala un proceso que «se daba por incluido en el alcance». La conversación se vuelve incómoda. Nadie lo dejó por escrito. Nadie quiso omitirlo. Lo he visto pasar demasiadas veces. Unos pocos supuestos sin comprobar al principio desvían el proyecto de rumbo, en silencio, durante semanas.

La función del documento de alcance no es registrar lo que se dijo en la sala. Es forzar la claridad antes de que la configuración consolide supuestos que cuesta mucho revertir.

Estas son las nueve secciones, con lo que cada una debe responder.

1. Objetivos

¿Por qué se hace este trabajo y qué verá el negocio cuando termine? Vincule cada objetivo a un resultado medible: reducir el cierre mensual en tres días, eliminar las conciliaciones manuales en tres entidades, una sola vista del inventario en todas las plantas. Los objetivos vagos producen criterios de éxito vagos, y el desacuerdo aflora en las pruebas de aceptación de usuario (UAT).

2. Definición del alcance

Módulos, entidades jurídicas, plantas, países, idiomas, integraciones y el modelo de despliegue. Sea específico. «Finanzas» no es alcance. «Contabilidad financiera y controlling (FI/CO), que cubre cuentas por pagar, cuentas por cobrar, libro mayor y contabilidad de centros de costos para la entidad jurídica de los Emiratos Árabes Unidos en S/4HANA Cloud Private Edition» es alcance.

3. Exclusiones

Aquí es donde fallan la mayoría de las plantillas de alcance. Si algo no figura como excluido, alguien dará por hecho que está incluido. Exclusiones que conviene dejar por escrito, por su nombre:

1. Países o entidades aplazados a una fase posterior.
2. Integraciones heredadas que se mantienen como están por ahora.
3. Datos históricos anteriores a una fecha de corte definida.
4. Informes trasladados a una lista de mejoras posteriores al go-live.
5. Requisitos regulatorios aplazados a la espera de confirmación legal.

Indique para cada exclusión la fase a la que pasa, si corresponde. Una exclusión firmada convierte una discusión de dos semanas en una conversación breve.

4. Alcance de la migración de datos

Un punto ciego constante. Responda por escrito a tres preguntas:

1. ¿Qué se migra? ¿Solo las partidas abiertas o también el historial? ¿Todos los clientes y proveedores o solo los activos? ¿Materiales de todas las plantas o solo de las entidades del go-live?
2. ¿Cuáles son las reglas de corte? La fecha de corte de los pedidos de compra, de venta y de trabajo abiertos, y qué ocurre con lo que está en curso en el cutover.
3. ¿Qué se archiva en su lugar? Las normas legales de conservación del historial y durante cuánto tiempo seguirá siendo legible el sistema heredado.

Los supuestos que queden sin documentar aquí se convierten en disputas durante la construcción. Mi artículo sobre por qué fracasa la migración de datos en SAP explica la planificación en detalle.

5. Alcance no funcional

Estos puntos se caen durante la planificación y afloran como bloqueos tarde en las pruebas. Inclúyalos en el alcance:

1. Disponibilidad y ventana de mantenimiento. En RISE, remita a los términos de disponibilidad de su contrato.
2. Rendimiento con carga máxima, como el cierre mensual.
3. Registro de auditoría: qué transacciones y durante cuánto tiempo se conservan los registros.
4. Seguridad y control de acceso por rol.
5. Latencia de los informes: en tiempo real, casi en tiempo real o diaria.

No son funcionalidades. Son restricciones que el sistema debe cumplir. Si no están en el alcance, nadie diseña para ellas.

6. Roles y responsabilidades

Cada flujo de trabajo necesita un consultor líder y una contraparte de negocio con autoridad de decisión, ambos con nombre. La carencia que más veo es la propiedad de la UAT: ¿quién puede firmar que un proceso está probado y aceptado? Decídalo antes de que empiece la construcción, no dos semanas antes del go-live.

7. Control de cambios

No «los cambios requieren aprobación formal». Un proceso concreto: qué desencadena una solicitud de cambio, quién evalúa el impacto en plazo y presupuesto, quién aprueba y qué se registra. Sin él, «¿podemos añadir esto?» se convierte en «pensábamos que eso estaba incluido» y después en una prórroga de tres semanas que nadie había planificado.

8. Reglas de extensión

Cómo se aprobará el desarrollo a medida. SAP clasifica ahora las extensiones desde el nivel A, solo API publicadas, hasta el nivel D, modificaciones del core (SAP News, agosto de 2025). En Public Edition con GROW, el sistema solo permite interfaces publicadas. En Private Edition con RISE y on-premise todavía se puede modificar el core, por lo que el alcance debe indicar el nivel objetivo y quién aprueba las excepciones. Mi guía de clean core explica los niveles.

9. Supuestos y restricciones

Enumere los supuestos que sustentan el alcance para que alguien tenga que comprobarlos. Después, las restricciones: plazos regulatorios que fijan una fecha de go-live, techos presupuestarios, personas que solo dedican parte de su tiempo y fechas de desmantelamiento de sistemas heredados.

La personalización es la forma de desviación del alcance que más tarda en notarse. Un informe a medida aprobado se convierte en cinco. Una excepción de flujo de trabajo se convierte en el precedente de cada solicitud posterior.

Clasifique cada solicitud antes de aprobar nada:

Categoría	Criterio	Qué hacer
Esencial	El proceso no puede funcionar legal u operativamente sin ello	Aprobar, con la extensión más barata que sea segura para las actualizaciones
Importante, no crítica	Mejora la eficiencia pero no impide continuar	Aprobar solo con un caso claro de costo-beneficio
Innecesaria	Una preferencia, o una copia de cómo funcionaba el sistema heredado	Cuestionarla y luego rechazarla o aplazarla

La mayoría de las personalizaciones innecesarias existen porque alguien no quería cambiar su forma de trabajar, no porque SAP no pudiera dar soporte al proceso. Y el costo de construcción es solo el principio. Cada objeto personalizado añade pruebas, formación, documentación y trabajo de actualización mientras exista.

Fije una congelación de cambios. Elija una fecha, normalmente de cuatro a seis semanas antes del go-live, a partir de la cual no se acepten nuevas solicitudes para esta entrega. Todo lo posterior pasa al backlog posterior al go-live. La congelación necesita detrás la firma del comité directivo. Una fecha anunciada solo por el director del proyecto será anulada la primera vez que un jefe de departamento presione.

1. 01Solicitud registradaQué cuenta como cambio se define desde el principio
2. 02ClasificadaEsencial, importante o innecesaria
3. 03Impacto evaluadoPlazo y presupuesto, por un evaluador con nombre
4. 04DecisiónUn aprobador con nombre aprueba, rechaza o aplaza
5. 05Alcance versionadoNuevo número de versión y lista de lo que cambió

Tras la congelación de cambios, las nuevas solicitudes pasan al backlog posterior al go-live

La analítica es donde las conversaciones de alcance se calientan. Todos quieren informes y nadie dice cuántos.

Acuerde una lista fija de informes durante el diseño. Pregunte a las personas qué necesitan, no qué podrían querer. Marque cada informe como salida estándar de SAP o desarrollo a medida y consiga que la lista se firme junto con el resto del alcance. Los informes estándar cuestan una fracción de los personalizados. Identifique a la vez las fuentes de datos de cada informe; un informe que se alimenta de tres sistemas es un requisito de integración. Si los paneles y la planificación están en el alcance, mi guía de SAP Analytics Cloud explica qué resolver primero.

Error	Qué provoca	Cómo evitarlo
Objetivos no medibles	Disputas en la UAT sobre qué significa «funciona»	Fije resultados medibles desde el principio
Exclusiones sin escribir	Trabajo absorbido sin aprobación	Enumere por su nombre lo que queda fuera del alcance
Alcance de migración de datos vago	Volúmenes erróneos, cutover retrasado, retrabajo	Defina qué se migra, los cortes y el archivado
Faltan requisitos no funcionales	Problemas de auditoría y rendimiento en el go-live	Incluya en el alcance disponibilidad, rendimiento, registro y seguridad
Sin responsables de UAT con nombre	Las pruebas se arrastran, nadie puede firmar	Nombre a personas con autoridad
Sin control de cambios	Añadidos informales, pruebas comprimidas	Escriba el proceso de cambios en el alcance
Sin firma	Se cuestiona el alcance más tarde sin responsabilidad	Firman el patrocinador y los responsables de proceso
Analítica dejada para después	Solicitudes de informes dos semanas antes del go-live	Acuerde la lista de informes durante el diseño
Modelo de despliegue o reglas de extensión abiertos	El debate se alarga hasta la fase de construcción	Decida ambos antes de firmar el alcance

Revise el alcance en cada hito de fase de SAP Activate y después de cada cambio aprobado, con un número de versión y una lista de lo que cambió. El alcance pertenece al acta de constitución del proyecto por referencia, de modo que ambos documentos cuenten la misma historia.

¿Qué debe incluir una plantilla de alcance de un proyecto SAP?

Nueve secciones: objetivos con resultados medibles, definición del alcance (módulos, entidades, países, integraciones, modelo de despliegue), exclusiones explícitas, alcance de la migración de datos, requisitos no funcionales, roles con nombre, control de cambios, reglas de extensión y supuestos con restricciones. Las exclusiones son la sección que más a menudo falta.

¿Cómo se evita la desviación del alcance en los proyectos SAP?

Escriba las exclusiones de forma explícita, pase cada cambio por una solicitud formal con evaluación de impacto y un aprobador con nombre, clasifique las personalizaciones antes de aprobarlas y fije una congelación de cambios firmada de cuatro a seis semanas antes del go-live. El objetivo no es rechazar todo cambio. Es que el cambio sea visible, evaluado y autorizado.

¿Qué es el alcance de la migración de datos en un proyecto SAP?

La definición de qué datos pasan a SAP y con qué reglas: qué objetos (clientes, proveedores, materiales, pedidos abiertos, historial), las fechas de corte y qué se archiva en lugar de migrarse. Determina el esfuerzo y el calendario, y decide cuánto tiempo deben seguir accesibles los sistemas heredados.

¿Qué es el alcance no funcional en los proyectos SAP?

Las restricciones que el sistema debe cumplir, a diferencia de los procesos que soporta: disponibilidad, rendimiento con carga máxima, registro de auditoría, seguridad y control de acceso, y latencia de los informes. A menudo se dejan fuera del alcance y se descubren en las pruebas. En los sectores regulados, el registro de auditoría es una obligación legal.

¿Cómo deben tratarse las personalizaciones en el alcance?

Clasifique cada solicitud como esencial, importante o innecesaria. Para cada una aprobada, registre el requisito, por qué el SAP estándar no lo cubre, el esfuerzo, el impacto en las pruebas, el costo de mantenimiento y el enfoque de extensión. En Private Edition y on-premise, indique el nivel objetivo de clean core y quién aprueba las excepciones.

¿Cuándo debe revisarse el alcance de un proyecto SAP?

En cada hito de fase de SAP Activate, después de cada solicitud de cambio aprobada y siempre que cambien el presupuesto, los recursos o el calendario. Conserve cada versión con una fecha, un número de versión y un resumen de lo que cambió. Ese historial protege al equipo cuando se cuestiona el alcance más adelante.