Cómo crear el acta de constitución de un proyecto de implementación de SAP

El acta de constitución de un proyecto de implementación de SAP es el documento breve que autoriza formalmente el programa. Fija por escrito qué entregará el programa, qué no entregará, quién decide, cómo se mide el éxito y para cuándo. Escríbala antes de firmar las declaraciones de trabajo (SOW) de los proveedores, haga que el patrocinador del cliente sea su dueño y que sea lo bastante concreta como para zanjar una discusión. Más abajo hay un esquema por secciones.

Los equipos entran con confianza en las reuniones de arranque de SAP. Luego descubren que los roles se definieron de forma vaga, que nunca se acordaron los límites del alcance y que nadie sabe decir cómo se ve el éxito. El acta debería evitarlo. La mayoría no lo hace, porque se escribe para cumplir un requisito de gobernanza y no para anclar el trabajo.

He visto actas de constitución que lucen limpias pero no se conectan con los planes reales. La versión que funciona es la que la gente discute mientras se redacta. Así se sabe que es honesta.

Tres documentos se confunden en todo programa grande de SAP. Cumplen funciones distintas.

Documento	Finalidad	Elaborado por	Momento
Propuesta de proyecto	Justificar por qué debe hacerse el proyecto	Patrocinador del negocio	Antes de la aprobación
Acta de constitución del proyecto	Autorizar el proyecto; fijar alcance, objetivos, responsables con nombre y gobernanza	El patrocinador junto con el director del programa	En el inicio
Plan del proyecto	Definir cómo se hace el trabajo: tareas, recursos, dependencias	Director del programa	Después de aprobada el acta

El acta es el documento de gobernanza. Traza líneas. Si su programa de S/4HANA abarca varios módulos, países y proveedores, el acta es donde se decide qué se incluye antes de que cada persona empiece a hacer sus propias suposiciones.

Objetivos ligados a un resultado de negocio

No «modernización del sistema». Cada objetivo necesita una cifra. La prueba: ¿puede explicar la visión a un miembro del consejo en 30 segundos y sin diapositivas?

He trabajado en programas de SAP en los que todos celebraron el go-live, y dos meses después nadie podía decir si había aportado el valor prometido. Un cliente del sector manufacturero gastó más de 4 millones de USD y no pudo demostrar ningún retorno. El CFO pidió métricas. Nadie las tenía, y eso retrasó su siguiente ronda de financiación.

Compárelo con un cliente de retail al que apoyé. Su acta tenía KPI definidos desde el primer día. Mostraron una caída del 32 % en los costos de procesamiento de pedidos, y la fase 2 se aprobó de inmediato.

Alcance con exclusiones explícitas

Esta es la sección que más se pasa por alto. Los equipos redactan listas detalladas de lo que entra en el alcance y omiten las exclusiones, que es justo donde surgen las discusiones.

Trabajé con una empresa del sector sanitario que mantuvo enfocado su despliegue de SAP de esta manera. El responsable de marketing quiso añadir analítica para el seguimiento de campañas durante las pruebas de aceptación de usuario (UAT). El acta no tenía espacio para eso, y el comité directivo lo señaló de inmediato. Esa única decisión ahorró 850 000 USD y evitó un retraso de seis semanas.

Personas con nombre, no departamentos

«Equipo de finanzas: aporta información para los informes» no hace responsable a nadie. «Responsable de finanzas, [nombre]: define los requisitos de informes, da su conformidad a la configuración de FI/CO y aprueba la preparación para la migración de datos» sí.

Hitos como compromisos

Un cliente de retail retrasó su go-live cuatro meses. El retraso inicial fue un desliz de tres semanas en la recopilación de requisitos que nadie añadió al cronograma. Asumieron que podrían recuperarlo más adelante. En cambio, gastaron 1,8 millones de USD en sobrecostos.

También funciona a la inversa. En un proyecto de manufactura, el equipo se ciñó al plan publicado. Cuando el equipo de migración de datos señaló un retraso, el comité directivo autorizó de inmediato un refuerzo de personal, porque el acta hacía visible el hito. Esa decisión ahorró tiempo y 600 000 USD.

Presupuesto, riesgos y dependencias

Un presupuesto de alto nivel, los tres o cuatro riesgos que podrían descarrilar el programa y los otros programas que compiten por las mismas personas y el mismo dinero. Un cliente de retail gastó 3,2 millones de USD en una implementación que nunca llegó al go-live. Su rediseño de finanzas y el proyecto SAP se ejecutaron en paralelo con los mismos recursos y la misma ventana presupuestaria, y ninguna de las dos actas mencionaba a la otra. La dirección se dio cuenta demasiado tarde.

Esta es la estructura desde la que yo empezaría. Cada sección debería caber en una página o menos.

1. Finalidad y contexto: por qué ahora, qué está roto, qué ocurre si no se hace nada.
2. Objetivos y medidas de éxito: cada objetivo con una línea base, una meta y una fecha.
3. Alcance: módulos, procesos, entidades jurídicas, países, sedes, integraciones y datos incluidos.
4. Fuera del alcance: redactado con el mismo cuidado que el alcance, con la fase a la que se difiere cada elemento excluido.
5. Modelo de despliegue y reglas de extensión: S/4HANA Cloud Public Edition, Private Edition bajo RISE u on-premise, y cómo se aprobará el desarrollo a medida.
6. Gobernanza: patrocinador, comité directivo, autoridad de diseño, control de cambios, vía de escalamiento, con personas con nombre.
7. Roles y responsabilidades: personas con nombre para cada área de proceso, datos, pruebas, cambio y cutover.
8. Hitos: puertas de fase con fechas y los criterios para superarlas. Mi guía de puertas de calidad tiene ejemplos.
9. Presupuesto y contingencia: el monto, la contingencia y quién puede liberarla.
10. Riesgos, supuestos y dependencias: incluidos los programas paralelos y los plazos regulatorios.
11. Requisitos de cumplimiento: por ejemplo HIPAA en el sector sanitario de EE. UU., GxP en farmacia, SOX para las empresas que cotizan en EE. UU.
12. Aprobación: patrocinador y responsables de negocio, con número de versión y fecha.

1. 01Pregunte a quienes conocen el trabajoPatrocinadores, responsables de negocio y usuarios finales
2. 02Separe lo imprescindible de lo deseableGo-live, fase 2 o fuera de este proyecto
3. 03Parta de una plantillaLuego añada integración, datos y cumplimiento
4. 04Sea lo bastante concreto como para zanjar discusiones¿Puede demostrar que se cumplió cada objetivo?
5. 05Consiga una aprobación realLeída, cuestionada y aceptada, sección por sección

Un acta a la que recurrir cuando el alcance se discuta en el tercer mes

1. Pregunte a quienes conocen el trabajo

Antes de escribir nada, siéntese con patrocinadores, responsables de negocio y usuarios finales. Pregunte qué está roto y qué se intentó antes. Una vez trabajé con un cliente del sector manufacturero que desperdició 1,8 millones de USD en una implementación de SAP porque daba por hecho que sabía lo que necesitaba la planta. A los seis meses descubrió que no se estaban abordando los problemas reales del flujo de trabajo.

En una transformación de finanzas en la que trabajé, TI planeaba desplegar SAP para resolver problemas de eficiencia. Las conversaciones con finanzas mostraron que el problema real era la mala calidad de los datos. Si no hubiéramos preguntado, habríamos gastado millones en arreglar el problema equivocado.

2. Separe lo imprescindible de lo deseable antes de redactar el alcance

Clasifique cada aporte como necesario para el go-live, para la fase 2 o fuera de este proyecto. Un cliente mío de servicios profesionales superó el presupuesto en un 40 % porque los requisitos estaban en tres sitios distintos y se «redescubrían» meses después de empezar el proyecto. Mi guía de plantilla de alcance ayuda con este paso.

3. Parta de una plantilla y luego añada lo específico de SAP

Una plantilla genérica no recoge lo que encarece los programas SAP: los puntos de integración, la responsabilidad de la migración y la depuración de datos, los supuestos por módulo, los requisitos de cumplimiento y las reglas para el desarrollo a medida. Supe de un proyecto SAP que empezó con un acta genérica que nunca mencionaba la depuración de datos. A los seis meses, los datos heredados resultaron ser un desastre, lo que sumó 750 000 USD y tres meses.

4. Sea lo bastante concreto como para zanjar discusiones

Dirigí la implementación de un cliente de retail en Singapur cuya acta decía «modernizar la gestión de inventario». La mitad del equipo pensó que eso significaba un procesamiento más rápido. La otra mitad se centró en las previsiones. El resultado fueron 1,8 millones de USD gastados y ningún acuerdo sobre cómo se veía el éxito. Para cada objetivo, pregúntese: ¿puedo demostrar que esto se completó?

5. Consiga una aprobación real

El acta está terminada cuando quienes la firman la han leído, la han cuestionado y han aceptado sus compromisos. Recorra con el patrocinador y los responsables de negocio cada sección, una por una. He visto clientes de retail dedicar tres días completos a alinearse sobre el acta. Les ahorró meses de discusiones y de cambios de alcance más adelante.

Error	Qué provoca	Qué hacer en su lugar
Objetivos vagos («mejorar la eficiencia»)	Los equipos tiran en direcciones distintas	Ponga una cifra a cada objetivo
Sin exclusiones	El alcance crece en silencio	Redacte la lista de lo que queda fuera con el mismo cuidado que el alcance
Responsables nombrados solo por cargo o departamento	Las decisiones se aplazan	Nombre a personas concretas
Sin medidas de éxito	Se celebra el go-live y nunca se demuestra el valor	Defina los KPI antes del arranque
Programas paralelos sin mapear	Choques de recursos y de presupuesto	Registre las dependencias en ambas actas
Acta redactada por el socio de implementación	El alcance refleja lo que el socio quiere entregar	El cliente es su dueño; el socio aporta el detalle

En el último punto soy tajante. Su socio de implementación no debería escribir su acta. Su incentivo es empezar el proyecto. El suyo es acotarlo.

En RISE with SAP (Private Edition), añada dos cosas a la sección de gobernanza. Primero, un foro de aprobación del Clean Core. SAP clasifica ahora las extensiones desde el nivel A, solo APIs publicadas, hasta el nivel D, modificaciones (SAP News, agosto de 2025). Private Edition todavía permite modificar el núcleo, así que el foro es lo que impide que se acumule deuda técnica. Segundo, una vía de escalamiento hacia SAP. Bajo RISE, SAP gestiona la infraestructura y las operaciones técnicas. El CIO necesita saber a quién llamar en SAP cuando algo falla a nivel de plataforma, y no solo en el socio.

En GROW with SAP (Public Edition), el acta se vuelve más pequeña. Las extensiones se limitan a las interfaces publicadas, de modo que la plataforma impone el Clean Core por usted, y las opciones de integración son más estrechas. La visión, las medidas de éxito, los responsables con nombre y las exclusiones importan igual.

Las herramientas de IA pueden convertir las notas de las entrevistas en un primer borrador más rápido. No pueden hacer el trabajo político del acta, que consiste en lograr que los patrocinadores acuerden qué les corresponde.

¿Qué es un acta de constitución del proyecto en una implementación de SAP?

El documento que autoriza formalmente el programa SAP. Fija el alcance y las exclusiones, nombra al patrocinador y a las personas responsables, define las medidas de éxito, establece los hitos y la gobernanza, y enumera los principales riesgos. Un acta útil es lo bastante concreta como para zanjar un desacuerdo sobre el alcance o la responsabilidad.

¿Qué debe incluir el acta de constitución de un proyecto SAP?

Finalidad, objetivos con metas medibles, alcance, exclusiones explícitas, modelo de despliegue y reglas de extensión, gobernanza con personas con nombre, roles, hitos con criterios de paso, presupuesto y contingencia, riesgos y dependencias, requisitos de cumplimiento y aprobación. El esquema anterior muestra cada sección.

¿Cuál es la diferencia entre el acta de constitución y el plan del proyecto?

El acta autoriza y define: alcance, patrocinador, gobernanza e hitos de alto nivel. El plan ejecuta: tareas, dependencias, recursos y secuencia. Un plan sin acta se desvía porque nunca se acordó el alcance. Cada compromiso del plan debería poder rastrearse hasta el acta.

¿Quién debe redactar el acta de constitución de un proyecto SAP?

El patrocinador del cliente es su dueño y el director del programa la redacta, con los responsables de finanzas, TI y operaciones aportando el detalle. Recomiendo no dejar que la redacte el socio de implementación. Su incentivo es empezar el proyecto, no protegerle de un alcance que usted no necesita.

¿Cómo cambia RISE with SAP el acta de constitución?

Añada un foro de aprobación del Clean Core que decida qué extensiones se permiten y en qué nivel. Añada una vía de escalamiento hacia SAP para los problemas de plataforma, ya que bajo RISE SAP gestiona la infraestructura. En GROW with SAP el acta es más ligera, porque Public Edition impone el Clean Core de forma técnica.

¿Puede cambiar el acta de constitución durante la implementación?

Sí, mediante el control de cambios. Trate el acta como una línea base. Cuando cambien el alcance, el patrocinador, el presupuesto o un hito importante, actualícela con un número de versión, una nota de qué cambió y por qué, y una nueva aprobación. No deje que se revise en silencio cada vez que el proyecto se desvíe.