Quality gates en SAP: cómo configurarlos y dónde fallan

Un quality gate es un punto de control formal entre las fases de un proyecto. Antes de avanzar, el equipo tiene que demostrar que se cumplen los criterios acordados. Si se supera, se avanza. Si no, primero se corrigen los problemas. En un programa SAP, los gates se sitúan en las transiciones de fase de SAP Activate, cada uno con un responsable designado que tiene autoridad para decir «no está listo».

Una gran empresa de bienes de consumo de Singapur estaba desplegando SAP a escala global. El equipo aceleró las pruebas para cumplir los plazos. Vi cómo se desarrollaba el desastre. Las pruebas de usuario apenas se hicieron, pero la dirección presionó para lanzar de todos modos. A los pocos días aparecieron los problemas: configuraciones que faltaban, flujos de trabajo rotos, datos completamente erróneos. Las semanas de caos posteriores al lanzamiento se debieron a problemas que eran visibles antes del go-live. Nadie se detuvo a comprobarlo.

Yo nunca me salto las revisiones de los quality gates. Sin atajos, sin aprobaciones de trámite. Cuesta más tiempo al principio y ahorra meses de limpieza después.

Un gate es un punto de decisión con un estándar escrito, una aprobación documentada y autoridad real para retrasar el proyecto. No es una revisión de avance ni una actualización de estado del comité directivo.

Sin esa autoridad, las revisiones se convierten en meros trámites. Y los gates de mero trámite son peores que ninguno, porque crean una falsa confianza. Un cliente del sector retail hacía «revisiones» que eran básicamente un sello de goma. A los seis meses iba desesperadamente retrasado, porque nadie había abordado los problemas que esas revisiones deberían haber detectado.

SAP Activate tiene seis fases: Discover, Prepare, Explore, Realize, Deploy y Run. Cada transición es un gate natural. Esto es lo que espero que compruebe cada gate.

Gate de fase	Foco de calidad	Evidencia a revisar	Se supera cuando
Discover	Caso de negocio, alineación de la dirección	Caso de negocio, hoja de ruta de alto nivel	Caso de negocio firmado, patrocinador comprometido
Prepare	Gobernanza, equipo, riesgos	Acta de constitución, modelo de gobernanza, registro de riesgos	Acta aprobada, responsables de riesgos designados, equipo incorporado
Explore	Fit-to-standard, diseño, enfoque de integración	Decisiones de fit-gap, diseños de procesos, arquitectura de integración	Responsables de proceso con aprobación firmada; cada brecha tiene una decisión
Realize	Configuración, pruebas de integración	Informes de ejecución de pruebas, registro de defectos	Umbrales de prueba alcanzados, defectos críticos cerrados
Deploy	Datos, formación, preparación del cutover	Conciliación de la migración, registros de formación, plan de cutover	Ensayo general realizado, plan de reversión acordado
Run	Estabilización y traspaso	Registro de incidencias, informes de rendimiento	Incidencias dentro de los límites acordados, traspaso a soporte firmado

En la práctica, Explore, Realize y Deploy concentran más riesgo. Un problema que pasa sin detectar por una de esas tres fases es el que más cuesta cuando aflora después del go-live.

1. 01DiscoverCaso de negocio firmado, patrocinador comprometido
2. 02PrepareActa aprobada, responsables de riesgos designados
3. 03ExploreCada brecha tiene una decisión
4. 04RealizeUmbrales de prueba alcanzados, defectos críticos cerrados
5. 05DeployEnsayo general hecho, reversión acordada
6. 06RunIncidencias dentro de los límites, traspaso firmado

Cada gate lo firma un responsable con autoridad para decir que no está listo

Escriba los criterios de entrada y de salida de cada gate en el acta de constitución del proyecto antes de que empiece la configuración. Los criterios escritos bajo presión de plazos describen lo que el equipo puede mostrar en ese momento, no lo que el proyecto necesita. Tuve un cliente que intentó combinar fases para «ahorrar tiempo». Acabó rehaciendo semanas de trabajo.

Criterios que dan una respuesta de sí o no

«Pruebas completadas» no es un criterio. Genera discusiones. Trabajé con un cliente de retail cuyo gate decía simplemente «UAT completadas». La mitad del equipo lo leía como todas las pruebas ejecutadas; la otra mitad, como todos los defectos corregidos.

«95 % de los casos de prueba ejecutados, todos los defectos de prioridad 1 resueltos, ningún defecto de prioridad 2 abierto con más de cinco días» es un criterio. Produce una respuesta.

Los gates de un cliente del sector manufacturero fallaron porque los criterios eran demasiado vagos. Nadie sabía si realmente los habían superado. Cuando los criterios pasaron a ser umbrales medibles, las discusiones en las transiciones de fase se acabaron.

Un responsable con autoridad para retrasar

Cada gate necesita un responsable designado que pueda retrasar el proyecto. Una persona, no un comité. Vi cómo un proyecto se estrellaba porque nadie tenía el poder de retrasar la siguiente fase, aunque el equipo no estaba preparado.

Lo contrario funciona. Un cliente de retail nombró a un director senior como responsable del gate. Cuando él decía «no está listo», todos escuchaban. Ponga esa autoridad en el acta de constitución.

Respaldo de la dirección antes de que llegue la presión

A los directivos les encantan los quality gates hasta que un gate amenaza un plazo. Un CIO anuló un gate fallido para cumplir un objetivo trimestral. Los problemas resultantes costaron el doble que el retraso. He visto repetirse este patrón muchas veces, así que ahora pido la aprobación de la dirección sobre el marco de gates antes de que empiece el proyecto.

Evidencia del sistema de registro

Las decisiones de un gate necesitan evidencia: informes de ejecución de pruebas, registros de defectos, aprobaciones de proceso, conciliaciones de migración. Extráigala de la herramienta, no de lo que la gente dice que está hecho. Uno de mis clientes descubrió, a través de los informes de Solution Manager, que el 40 % de sus casos de prueba «completados» nunca se habían ejecutado. Lo detectaron antes del gate, no después.

1. Asigne los gates a las transiciones de fase. Para SAP Activate, como mínimo después de Prepare, Explore, Realize y Deploy. Un cliente del sector energético creó puntos de control aleatorios entre medias y acabó con un desorden.
2. Defina los criterios de entrada y de salida antes de que empiece la configuración. Acuerde la cobertura de pruebas, los umbrales de defectos y los responsables de proceso que deben firmar. Inclúyalos en el acta de constitución y obtenga la firma del patrocinador.
3. Programe los gates con margen. Ponga cada gate en el calendario como una actividad, no solo como un hito. Uno de mis clientes de retail reservaba una semana entera antes de cada gate solo para la limpieza.
4. Elija revisores que puedan decidir. Los responsables de negocio aprueban los procesos. Los responsables técnicos aprueban la configuración y la integración. Los consultores nunca firman en nombre del negocio.
5. Guarde la evidencia en un solo lugar. Seis meses después, un auditor preguntará quién aprobó la migración de datos. La respuesta debería encontrarse en minutos.
6. Haga visibles los resultados. Un cliente colgó su panel de gates en la pared de la sala del proyecto. Era imposible ignorarlo.

Ejemplo de criterios de salida para los dos gates que más importan

Gate de Realize:

1. Ejecución de pruebas igual o superior al umbral acordado, con los resultados guardados en la herramienta de pruebas.
2. Ningún defecto de prioridad 1 abierto; defectos de prioridad 2 dentro del límite de antigüedad acordado.
3. Cada proceso crítico aprobado por su responsable de proceso designado.
4. Pruebas de integración ejecutadas sobre cadenas de proceso completas, con resultados documentados.
5. Cada desarrollo a medida aprobado conforme a las reglas de clean core del programa.

Gate de Deploy:

1. Ensayo general de la migración de datos completado y conciliación firmada por el responsable de datos.
2. Formación completada por rol, igual o superior al umbral acordado.
3. Plan de cutover ensayado, con tiempos y puntos de decisión go/no-go.
4. Plan de reversión documentado y probado.
5. Equipo de hypercare designado, con vías de escalado y definiciones de severidad acordadas.

Si el gate de Deploy muestra excepciones de conciliación sin resolver o usuarios sin formar y el negocio aun así quiere seguir adelante, conviértalo en una decisión documentada con un firmante identificado. No en una decisión por defecto porque nadie quiso decir que no.

Dos cosas han cambiado cómo diseño los gates en los programas actuales.

Clean core es ahora un criterio de gate. SAP clasifica las extensiones desde el nivel A (solo interfaces publicadas) hasta el nivel D (modificaciones y escrituras directas en tablas). En el gate de Explore, cada brecha debería tener una decisión: configurarla, construirla como una extensión sobre API publicadas o rechazarla. En el gate de Realize, compruebe que no se hayan colado objetos nuevos de nivel D. Public Edition lo impone técnicamente. Private Edition y on-premise no, así que es el gate quien lo impone.

SAP Cloud ALM es la herramienta por defecto. Está incluida en las suscripciones cloud de SAP con Enterprise Support, edición cloud, y en SAP Enterprise Support para los clientes on-premise (SAP Support). Cubre fit-to-standard, asignación de tareas, orquestación de pruebas y trazabilidad. El mantenimiento estándar de SAP Solution Manager 7.2 termina a finales de 2027, y SAP recomienda pasar a Cloud ALM antes de esa fecha (SAP Support). Si está a mitad de un programa sobre Solution Manager, termínelo allí. Planifique los programas nuevos en torno a Cloud ALM.

Herramientas para gestionar los gates

La herramienta importa menos que la disciplina. Un cliente de retail montó un proceso de gates limpio en SharePoint que funcionó de maravilla en una implementación de tamaño medio. También he visto fallar gates sobre una configuración completa de Solution Manager porque el equipo mantenía hojas de cálculo paralelas.

Herramienta	Función en la gestión de gates	Ideal para
SAP Cloud ALM	Fit-to-standard, tareas, pruebas, trazabilidad	Programas nuevos de S/4HANA, cloud u on-premise
SAP Solution Manager 7.2	Seguimiento de proyectos, gestión de pruebas y de defectos	Programas que ya funcionan sobre él
Jira y Confluence	Tareas, defectos, criterios de gate y evidencia	Equipos que ya usan herramientas de Atlassian
Tricentis Tosca	Automatización de pruebas e informes de cobertura	Programas con mucha automatización de pruebas
ServiceNow	Flujos de aprobación y pista de auditoría	Empresas que ya usan ServiceNow

Sea cual sea la que elija, tiene que ser la única fuente de verdad. Una hoja de cálculo paralela siempre muestra la versión que el equipo quiere mostrar. Mi comparativa de herramientas de pruebas y validación de SAP profundiza en la parte de pruebas.

Se saltan bajo presión de plazos. Cuando los proyectos se retrasan, los gates son lo primero que se recorta. En un proyecto las revisiones se volvieron un mero trámite, y el go-live fue una pesadilla: los sistemas se cayeron, los pedidos se atascaron e hicieron un rollback completo. Las tres semanas que «ahorraron» les costaron tres meses de recuperación.

Criterios vagos. Ya lo vimos arriba. Si un criterio necesita interpretación, solo sirve para abrir una conversación.

Revisores sin tiempo. Cuando los revisores clave se reparten entre varios proyectos, las revisiones se reducen a marcar casillas. La revisión del gate de Realize en un programa de tamaño medio debería llevar al menos media jornada, con la evidencia leída de antemano.

Cultura. Los equipos acostumbrados a precipitar los hitos buscan la manera de eludir los gates. Eso cambia cuando un directivo dice en el kickoff que los gates son obligatorios y luego lo demuestra negándose a anular el primero que cause un retraso.

Tres cifras que muestran si los gates funcionan

Siga estas cifras para saber si los gates protegen el proyecto o solo lo aparentan.

1. Fuga de defectos: la proporción de defectos hallados después de un gate que el gate debería haber detectado.
2. Tasa de aprobación al primer intento: si todos los gates se superan a la primera, es probable que los criterios no tengan peso real.
3. Incidencias tras el go-live: las incidencias de alta prioridad en los primeros 30 días son un veredicto directo sobre el gate de Deploy.

Los gates pertenecen al acta de constitución desde el primer día. Mi guía del acta de constitución del proyecto muestra dónde encajan, y la guía del comité directivo explica quién debería tener la autoridad para hacerlos cumplir.

¿Qué es un quality gate en los proyectos SAP?

Un punto de control formal entre fases del proyecto. El equipo tiene que demostrar que se cumplen criterios concretos y medibles antes de avanzar. Cada gate tiene un responsable designado con autoridad para retrasar el proyecto. En SAP Activate, los gates se sitúan en las transiciones de fase, sobre todo después de Explore, Realize y Deploy.

¿Cuáles son los quality gates de SAP Activate?

SAP Activate tiene seis fases (Discover, Prepare, Explore, Realize, Deploy y Run), y cada transición es un gate. Discover comprueba el caso de negocio. Prepare comprueba la gobernanza y el acta de constitución. Explore comprueba la aprobación del diseño y las decisiones sobre brechas. Realize comprueba los resultados de las pruebas y los defectos. Deploy comprueba los datos, la formación y la preparación del cutover. Run comprueba la estabilización y el traspaso.

¿Qué deben incluir los criterios de un quality gate de SAP?

Criterios que den una respuesta de sí o no. Para Realize: umbrales de ejecución de pruebas, defectos abiertos por prioridad, aprobaciones de los responsables de proceso y resultados de las pruebas de integración. Para Deploy: conciliación de la migración, formación completada por rol, un plan de cutover ensayado, un plan de reversión probado y un equipo de hypercare con personal asignado. Cada criterio necesita un responsable que aporte la evidencia.

¿Por qué fallan los quality gates en las implementaciones de SAP?

Se saltan bajo presión de plazos, los criterios son vagos, los revisores no tienen tiempo para prepararse o un directivo anula un gate fallido. La causa de fondo es tratar los gates como una carga y no como una protección.

¿Qué herramienta debería usar para gestionar los quality gates de SAP?

Para programas nuevos, SAP Cloud ALM. Está incluida en las suscripciones cloud de SAP y en Enterprise Support, y admite fit-to-standard, pruebas y trazabilidad. SAP Solution Manager 7.2 sale del mantenimiento estándar a finales de 2027. Jira, Tricentis Tosca y ServiceNow funcionan bien donde la empresa ya los usa. La regla es una única fuente de verdad.

¿Cómo se evalúa la preparación para el go-live en el último quality gate?

Compruebe cinco cosas con evidencia: migración de datos ensayada y conciliada, formación completada para cada rol, plan de cutover ensayado con puntos de go/no-go, plan de reversión probado e hypercare con personal asignado y vías de escalado. Si alguna falla y el negocio aun así quiere seguir adelante, regístrelo como una decisión de negocio firmada.