Cómo crear un comité directivo eficaz para un proyecto SAP

Un comité directivo de proyecto SAP es el pequeño grupo de directivos que toma las decisiones que el equipo del proyecto no puede tomar: presupuesto, cambios de alcance, conflictos entre departamentos y el go/no-go final. Funciona cuando sus miembros tienen autoridad real, se reúnen con la frecuencia suficiente para decidir en la propia reunión y juzgan la preparación con evidencias y no con el calendario. Esta guía es para patrocinadores y directores de programa que están montando un comité o arreglando uno que se ha convertido en un público de informes de estado. Cubre lo que el comité debe decidir, los miembros según el tamaño del proyecto, cómo deben funcionar las decisiones, una lista de comprobación go/no-go y lo que cambian RISE with SAP y las herramientas de IA.

Nunca he visto triunfar un proyecto SAP con un comité directivo débil. El comité es donde se toman las decisiones difíciles. O se toman en tiempo real, o se acumulan hasta que explotan en el cutover.

En un despliegue de SAP, el comité se reunía una vez al mes. El equipo del proyecto señaló flujos de aprobación rotos, pruebas incompletas y formación pendiente. La dirección dijo que lo «revisaría». Nunca lo hizo. El proyecto entró en producción y finanzas pasó los seis meses siguientes limpiando.

En otra empresa, el comité se reunía cada semana y tomaba decisiones de verdad. Cuando las pruebas revelaron brechas, reasignó recursos. Cuando un proceso no funcionaba, lo corrigió. Ese proyecto entró en producción sin sobresaltos.

Un comité lideró. El otro se quedó en las reuniones.

Si el comité solo recibe informes de estado, ya está fallando. La tabla muestra la diferencia en la práctica.

Función	Cómo se ve cuando es bueno	Cómo se ve cuando es débil
Decisiones importantes	Revisa el caso y decide en el acto	«Lo hablamos aparte»; el asunto vuelve el mes siguiente
Obstáculos	¿Recursos humanos retrasa las pruebas? Quien preside llama directamente al jefe del departamento	Reconoce el problema y lo registra
Alcance	Sopesa cada solicitud de cambio frente al plan	Da el visto bueno a lo que se escale con más ruido
Riesgo	Ve que un proveedor tiene dificultades y prepara un respaldo antes de que lleguen los retrasos	Espera a ver si se resuelve solo
Presupuesto	Aprueba 2 millones de dólares adicionales para ampliar tres meses porque la interrupción costaría más	Lo aplaza al mes siguiente
Go/no-go	Retrasa el go-live seis semanas porque las pruebas no están completas, y mantiene su postura	Aprueba el go-live porque la fecha está en el calendario

La última fila es la que más importa. He visto a comités aplazar go-lives aunque los equipos querían seguir adelante a toda costa. El comité de un cliente farmacéutico retrasó el go-live seis semanas porque las pruebas no estaban completas. Una decisión dura, pero le evitó un desastre.

Con demasiados miembros, el comité no puede decidir. Con muy pocos, faltan voces críticas.

Tamaño del proyecto	Presupuesto y alcance	Miembros	Quién debe estar en la sala
Pequeño	Menos de 0,5 millones de dólares, un departamento, menos de 6 meses	3 a 5	Jefe de departamento, responsable de TI, representante de finanzas
Mediana empresa	De 0,5 a 5 millones de dólares, varios departamentos, de 6 a 18 meses	5 a 8	Responsables de negocio de los departamentos afectados, dirección de TI, finanzas
Gran empresa	Más de 5 millones de dólares, toda la empresa, 18 meses o más	8 a 12	Directivos de nivel C de finanzas, RR. HH., operaciones y TI; director del programa; responsable del cambio

La regla que aplico: incluya a personas con autoridad real para decidir. He visto fracasar comités porque los cargos altos no podían aprobar nada sin consultarlo con otra persona. Si el CFO no puede asistir, envíe a alguien con un mandato genuino para decidir, no para volver a informar.

Quien presida el comité debería ser el patrocinador del proyecto, normalmente un directivo de nivel C capaz de exigir cuentas a otros directivos. Un mando intermedio al frente del comité no puede imponerse a un CFO, y esa autoridad importa cuando surgen conflictos de alcance o de presupuesto.

Con evidencias. Trabajé con un cliente de fabricación cuyo equipo de TI dijo que un cambio de proceso añadiría tres meses. El negocio insistía en que era «simple». El comité se negó a decidir hasta ver estimaciones de esfuerzo, análisis de dependencias y planificación de capacidad. TI tenía razón. El comité acertó porque exigió evidencias en lugar de ponerse del lado de la voz más fuerte.

Rápido. He visto a un cliente cuyo comité se reunía cada dos semanas, pero siempre terminaba con «lo hablaremos aparte». Los asuntos se acumularon hasta que el proyecto llevaba seis meses de retraso. El comité de otro cliente tomaba las decisiones en la sala, y su proyecto terminó antes de plazo y por debajo del presupuesto. Los comités lentos producen proyectos tardíos.

Con autoridad explícita. Los comités eficaces pueden imponerse a los jefes de departamento, aprobar presupuesto no previsto y rechazar adiciones de alcance a mitad del proyecto. Si esas facultades no están por escrito y entendidas, el comité se convierte en consultivo, y los comités consultivos no sacan adelante proyectos SAP.

Sobre el alcance, de forma selectiva. En uno de mis clientes, un departamento exigió de pronto 20 informes adicionales. El comité preguntó si cada uno hacía falta ahora y si rompería el calendario. Aprobó cinco informes críticos y trasladó el resto a después del go-live. Esa decisión probablemente salvó la fecha del go-live.

Mantenga las reuniones en 60 a 90 minutos. Los principales riesgos, las decisiones concretas que hacen falta y las acciones con responsables y fechas. Sin actualizaciones técnicas que se puedan leer de antemano. Si el mismo asunto aparece tres reuniones seguidas sin resolverse, tiene un problema de gobierno, no de complejidad.

Use datos, no presentaciones. Trabajé con un cliente del sector energético que construyó un panel con la ejecución de pruebas, la resolución de defectos, la finalización de la formación y el consumo de presupuesto. Las reuniones dejaron de tratar de entender en qué punto estaban las cosas y pasaron a tratar de resolver problemas.

Muestre el sistema al comité. El comité de un cliente farmacéutico recorrió un escenario de «un día en la vida». Se dio cuenta de que el diseño aprobado obligaría al personal a usar cinco pantallas distintas para un proceso habitual. Ordenó un rediseño de inmediato.

Cuente con la política. El fallo más habitual no es la incompetencia. Son los departamentos que protegen su territorio y los equipos que retrasan las pruebas por el trabajo de cierre de año. En un proyecto, RR. HH. seguía retrasando las pruebas de nómina porque estaba ocupado con las tareas del cierre de año. El comité repriorizó el trabajo y asignó probadores de respaldo, y el proyecto se mantuvo en el camino en lugar de deslizarse durante meses.

Use comprobaciones independientes en los hitos principales. Un cliente de fabricación hizo que revisores externos evaluaran su preparación antes de aprobar el go-live. La revisión encontró varios problemas graves que el equipo del proyecto había pasado por alto o minimizado. Mi guía sobre los quality gates de SAP muestra cómo estructurar esos puntos de control.

La presión del calendario es una mala base para aprobar un go-live. Antes de la votación, el comité debería ver evidencias de cada uno de estos puntos:

1. Pruebas de integración y de aceptación de usuario completas, sin defectos críticos abiertos
2. Última migración de datos de prueba conciliada y firmada por finanzas
3. Ensayo del cutover completado dentro de la ventana prevista
4. Usuarios clave formados, con soporte en planta y ayudas de trabajo listas
5. Preparación del negocio confirmada por escrito por cada responsable de proceso
6. Plan de rollback probado y acordado
7. Equipo de hypercare, ruta de escalamiento y soporte del primer cierre listos

Si algún punto está en rojo, un comité sólido dice que no. Un retraso de seis semanas se puede recuperar. Un go-live fallido que perturba las operaciones o el cierre financiero puede tardar meses en estabilizarse. He limpiado demasiados go-lives que se aprobaron porque la fecha parecía inamovible. Alimente la agenda del comité desde un registro de riesgos vivo para que estos puntos afloren pronto.

RISE incorpora a SAP al modelo de gobierno. En RISE with SAP, SAP gestiona la infraestructura y las operaciones técnicas. El documento de roles y responsabilidades de RISE de SAP hace que los clientes trabajen con un SAP Cloud Architect Advisor, un Client Delivery Manager o el centro de clientes de la nube privada de SAP. Para los problemas de plataforma, como el rendimiento, la disponibilidad o los niveles de servicio, el comité necesita una vía hacia esos contactos que no pase por el socio de implementación. Invítelos para los puntos de la agenda que correspondan y no como miembros permanentes.

Un foro de clean core debe existir por debajo del comité. En los programas RISE, cree una autoridad de diseño que apruebe o rechace las solicitudes de personalización según los principios de clean core. Solo escala al comité cuando se bloquea una solicitud crítica para el negocio. Sin esa capa, cada personalización se convierte en una pelea del comité. En on-premise sigue aplicándose el modelo tradicional y SAP es un proveedor, no un participante.

1. Comité directivoLo preside el patrocinador. Presupuesto, alcance, conflictos, go/no-go
   Contactos de entrega de SAPSe invitan para los puntos de plataforma, sin pasar por el socio

• Oficina de gestión de programas (PMO)Ejecución diaria, registro de riesgos, coordinación
• Autoridad de diseño de clean coreResuelve sobre las personalizaciones, escala solo las solicitudes críticas bloqueadas

La IA ahorra tiempo en el papeleo. Microsoft 365 Copilot redacta las actas a partir de la reunión grabada. El trabajo pasa a ser revisar un borrador en lugar de escribir desde cero, y las decisiones salen de la transcripción. Rovo de Atlassian puede convertir las notas de reunión en entradas estructuradas del registro de decisiones una vez construida la plantilla. Los asistentes basados en Joule de SAP Cloud ALM pueden redactar una primera evaluación de impacto de una solicitud de alcance, de modo que el comité puede decidir en la reunión en lugar de aplazar.

Por ahora, descarte el análisis de sentimiento. Algunos proveedores ofrecen el análisis de sentimiento de las comunicaciones del programa como una fuente de información para el comité. En la mayoría de los programas es teatro: la señal es débil, los falsos positivos son frecuentes y que se vea que se vigila el sentimiento tiene un costo político. Solo en programas muy grandes puede señalar pronto a los grupos que se desentienden. Para la mayoría de los comités no es donde conviene gastar el presupuesto de IA.

¿Cuál es el papel de un comité directivo en un proyecto SAP?

Toma las decisiones que el equipo del proyecto no puede tomar: aprobaciones de presupuesto, cambios de alcance, escalamiento de recursos y el go/no-go final. Resuelve los conflictos entre departamentos y exige a los jefes de departamento que cumplan sus compromisos de pruebas y formación. Si solo recibe actualizaciones de estado, no cumple su función. El valor está en las decisiones que se toman, no en las reuniones a las que se asiste.

¿Cuántas personas debería tener un comité directivo de SAP?

De tres a cinco para un proyecto pequeño de un solo departamento; de cinco a ocho para una mediana empresa; de ocho a doce para un programa de gran empresa. El fallo habitual es tener demasiada gente: un comité de 20 se convierte en un público de presentaciones. Cada miembro debería tener autoridad real de decisión sobre algo. En RISE, incorpore a los contactos de entrega de SAP para los puntos de plataforma y no como miembros permanentes.

¿Cómo cambia RISE with SAP el comité directivo?

SAP pasa a ser un participante en la entrega de la infraestructura y de las operaciones técnicas, de modo que el comité necesita una vía directa hacia los contactos asignados de SAP que no pase por el socio de implementación. También necesita por debajo una autoridad de diseño de clean core que gestione las solicitudes de personalización, y solo se escalan las solicitudes críticas para el negocio que queden bloqueadas. En on-premise, SAP sigue siendo un proveedor.

¿Qué diferencia hay entre un comité directivo y una PMO?

La oficina de gestión de proyectos ejecuta el trabajo diario: tareas, registros de riesgos y coordinación entre los flujos de trabajo. El comité directivo toma las decisiones que la PMO no puede tomar: cambios de presupuesto, cambios de alcance y go/no-go. En las organizaciones más grandes, un comité a nivel de cartera se sitúa por encima de varios proyectos y asigna recursos entre ellos.

¿Qué debería figurar en la agenda de un comité directivo?

Decisiones, no actualizaciones. Empiece con los tres a cinco riesgos principales, después las decisiones concretas que necesitan aprobación, después los asuntos entre departamentos por resolver y, por último, las acciones de la reunión anterior con responsables y fechas. Si un punto aparece tres veces sin resolverse, escale la forma en que se está gestionando en lugar de volver a discutirlo.

¿Cuándo debe retrasar el comité directivo el go-live?

Cuando las pruebas no están completas, los usuarios clave no están formados, la migración de datos no está conciliada, una integración crítica es inestable o el plan de rollback no se ha probado. Un retraso casi siempre cuesta menos que la limpieza posterior al go-live. Un retraso de seis semanas se puede recuperar; un go-live fallido que perturba la cadena de suministro o el cierre financiero puede tardar meses en estabilizarse.