La auditoría de conformidad metodológica como herramienta de control para clientes, integradores y comités de dirección
Luis Vilanova Blanco · Auditor CISA (ISACA), auditor jefe ISO 27001 e ISO 42001, perito judicial informático · Legal & Digital Auditors
La mayor parte de los litigios SAP que acaban en nuestra mesa como peritos podrían haberse evitado con una auditoría a tiempo. No porque el proyecto fuera fácil, sino porque las señales de que se estaba desviando de la metodología contratada estaban en el repositorio desde los primeros meses: un Quality Gate que no se celebró, una estrategia de pruebas que nadie aprobó, una lista de GAP que seguía vacía cuando la configuración ya había empezado. Nadie las leyó porque nadie tenía el encargo de leerlas. Este artículo explica en qué consiste la auditoría de conformidad con SAP Activate que realizamos en Legal & Digital Auditors, qué comprueba en cada fase y qué resultados produce, con un caso ilustrativo cuyos datos han sido modificados.
Qué es y qué no es esta auditoría
La auditoría de conformidad metodológica no es una revisión técnica de la configuración ni una auditoría de seguridad del sistema. Es una verificación independiente de que el proyecto se está ejecutando según la metodología que el integrador ofertó y el contrato recogió: que las fases se cierran con sus Quality Gates, que los entregables obligatorios existen y están aprobados en el momento en que la metodología los exige, que los comités funcionan y deciden, que el reporting refleja la realidad y que los riesgos, los cambios y los retrasos se gestionan con los instrumentos previstos. Se apoya en las mismas técnicas que la auditoría de sistemas de información conforme al marco de ISACA: entrevistas, inspección documental, reejecución y observación directa en el sistema.
Puede contratarla el cliente, que es lo habitual, pero también el integrador que quiere acreditar su diligencia ante un cliente exigente, o ambos de común acuerdo como mecanismo de gobierno del proyecto. En los tres casos el auditor es independiente de las dos partes y su informe se redacta de modo que pueda utilizarse después, si fuera necesario, como evidencia.
Cuándo hacerla: tres momentos
La auditoría puede plantearse en tres momentos con objetivos distintos. La auditoría previa al cierre de Explore es la más rentable: comprueba que el diseño está aprobado, los GAP decididos, las estrategias de pruebas y de migración firmadas y el plan recalculado antes de que empiece la construcción, que es donde se consume la mayor parte del presupuesto. La auditoría de readiness antes del go-live verifica que los criterios de salida de las pruebas se cumplen, que el ensayo de cutover se ha ejecutado y que el plan de hypercare existe, y da al comité de dirección una base objetiva para la decisión go/no-go. La auditoría de cierre o de proyecto en dificultades se realiza cuando el proyecto se ha retrasado o paralizado y las partes necesitan saber, antes de negociar o litigar, qué parte del desvío es imputable a cada una.
Qué comprobamos en cada Quality Gate
La matriz de auditoría se construye a partir de la metodología pactada y se organiza por Quality Gate. La tabla siguiente resume, para cada uno, qué entregables pedimos y qué aceptamos como evidencia válida. La lista completa de la matriz tiene en torno a ochenta criterios, cada uno con su gravedad.
| Quality Gate | Qué comprobamos | Evidencia que aceptamos |
| QG1 · Cierre de Prepare | Charter firmado, alcance cerrado contra los scope items activados, plan con línea base, equipo completo, estructura de comités, plan de gestión del cambio, acceso al sistema inicial. | Documentos firmados por ambas partes, plan en herramienta con línea base guardada, acta de kick-off, checklist de gate cumplimentada. |
| QG2 · Cierre de Explore | Talleres Fit-to-Standard por scope item con demostración en sistema, deltas clasificados y aprobados, backlog priorizado, lista de GAP decidida, decisiones clave aprobadas por el comité de diseño, estrategias de pruebas y migración, concepto de autorizaciones, plan recalculado. | Actas con aprobación del responsable de proceso, backlog en Cloud ALM o equivalente, actas del comité de diseño, estrategias con firma y fecha anterior al inicio de la construcción. |
| QG3 · Cierre de Realize | Registro de configuración con prueba unitaria por ítem, sprints o ciclos con demostración al cliente, especificaciones aprobadas antes de construir, Change Requests formalizados, ciclos de pruebas integradas y de aceptación con registro de defectos, ciclos de migración reconciliados, formación impartida, runbook de cutover. | Tracker de configuración, actas de demostración, registro de defectos con estados, informes de reconciliación firmados por negocio, hojas de asistencia a formación, runbook con responsables. |
| QG4 · Go-live y hypercare | Criterios de salida de UAT verificados, ensayo de cutover ejecutado, decisión go/no-go formal, migración productiva verificada, modelo de soporte y SLA de hypercare, criterios de cierre de hypercare. | Acta de go/no-go firmada con el estado de los defectos, informe del ensayo de cutover, informe de verificación de la carga productiva, plan de hypercare aprobado. |
Además de los gates, la matriz incluye un bloque transversal de gobierno y reporting: la periodicidad y veracidad de los informes de estado, el funcionamiento de los comités de dirección y de diseño, el registro de riesgos con planes de respuesta, la gestión de cambios y el cálculo de los KPI que el Charter definió. Es el bloque que con más frecuencia explica el resto de los problemas.
Cómo valoramos y qué devuelve la auditoría
Cada criterio se califica en cuatro estados, conforme, conforme con reservas, deficiente o ausente, y se pondera por su gravedad. Con ello calculamos un índice de conformidad por fase y uno global, que situamos en una escala de cuatro niveles: conforme a partir del 80 %, conforme con observaciones entre el 60 % y el 79 %, deficiente entre el 40 % y el 59 % y no conforme por debajo del 40 %. El informe entrega, además del índice, la lista de hallazgos con su gravedad, su evidencia y su recomendación, un plan de acción priorizado y, cuando se solicita, una opinión sobre la atribución de cada desvío a una u otra parte.
Un caso ilustrativo: auditoría al cierre de Realize
Una empresa de distribución contrató una auditoría de readiness cuando su integrador anunció que la construcción estaba terminada y propuso una fecha de go-live a ocho semanas vista. El proyecto, una implantación de S/4HANA Cloud Private Edition con SAP Activate, llevaba trece semanas de retraso sobre el plan original. La dirección quería saber si el sistema estaba en condiciones de arrancar y, si no lo estaba, por qué. Los resultados que siguen son una recomposición con datos modificados.
Gráfica 1. Índice ponderado de conformidad con SAP Activate por fase en el momento de la auditoría.
El índice global fue del 57 %, en el nivel deficiente. La Gráfica 1 muestra que el proyecto había estado razonablemente bien gobernado en Prepare, con un 71,4 %, y que el reporting se mantenía en el nivel de conformidad con observaciones. El deterioro se concentraba en Explore, Realize y Deploy. Esa distribución es muy frecuente y tiene una lectura clara: el integrador había desplegado correctamente sus plantillas de gobierno, pero no estaba ejecutando los procesos de la metodología que dependen del trabajo diario de los consultores.
Gráfica 2. Distribución de los 84 criterios auditados por estado de cumplimiento y fase.
La Gráfica 2 descompone el índice en los 84 criterios auditados. Veintiséis eran conformes y doce estaban ausentes. Entre los ausentes figuraban los que más pesan en una decisión de go-live: el registro de configuración con pruebas unitarias, el informe de reconciliación del segundo ciclo de migración, el ensayo de cutover y el plan de hypercare con sus acuerdos de nivel de servicio.
Gráfica 3. Quality Gates: fecha pactada frente a fecha real de cierre, en semanas desde el kick-off. QG4 corresponde a la fecha de go-live propuesta por el integrador.
La Gráfica 3 sitúa el retraso en su contexto. Prepare cerró con dos semanas de retraso, Explore con seis y Realize con once. Ninguno de los tres gates se había celebrado formalmente: la auditoría reconstruyó las fechas a partir de los informes de estado y del correo. El dato que más preocupó al comité de dirección no fue el retraso, sino que el integrador proponía un go-live trece semanas después de la fecha pactada sin haber cerrado ninguno de los gates previos.
Gráfica 4. Defectos abiertos en el momento de la auditoría frente al máximo admitido por el criterio de salida de UAT definido en la estrategia de pruebas.
La Gráfica 4 compara el registro de defectos con el criterio de salida que la propia estrategia de pruebas del integrador había fijado. Con tres defectos bloqueantes y once de severidad alta abiertos, frente a cero y dos admitidos, el sistema no cumplía las condiciones para arrancar. La auditoría comprobó además que 61 de los 268 casos de prueba del ciclo integrado no tenían resultado informado, de modo que el número real de defectos era necesariamente superior al registrado.
Gráfica 5. Objetos a medida previstos en la lista de GAP aprobada frente a los encontrados en el sistema de desarrollo, clasificados según el principio Clean Core.
La Gráfica 5 recoge un hallazgo que la dirección desconocía por completo. La lista de GAP aprobada al cierre de Explore preveía 33 objetos a medida, casi todos extensiones in-app y side-by-side. En el sistema de desarrollo había 37, pero con una composición muy distinta: dieciséis desarrollos ABAP clásicos en el núcleo y dos modificaciones del estándar, ninguno amparado por un Change Request. El integrador había resuelto varios GAP con desarrollo tradicional en lugar de con las extensiones ofertadas, comprometiendo el principio Clean Core y, con él, la capacidad de la empresa para absorber las actualizaciones futuras.
Gráfica 6. Número de hallazgos de la auditoría por gravedad y fase del proyecto.
La Gráfica 6 resume los 64 hallazgos del informe por gravedad y fase. Los dieciocho de gravedad alta se concentraban en Realize y Deploy, y eran los que condicionaban la decisión: ausencia de registro de configuración, segundo ciclo de pruebas integradas sin ejecutar, criterio de salida de UAT incumplido, migración sin reconciliar, cutover sin ensayar y desarrollos en el núcleo sin autorización.
Qué pasó después
El comité de dirección aplazó el go-live diez semanas sobre la base del informe y exigió al integrador un plan de cierre con cinco condiciones: completar el registro de configuración, ejecutar el segundo ciclo de pruebas integradas con registro de defectos, reconciliar la migración con firma de negocio, ensayar el cutover de principio a fin y regularizar mediante Change Request los desarrollos en el núcleo o sustituirlos por extensiones. Se acordó además que la auditoría se repetiría dos semanas antes de la nueva fecha. El proyecto arrancó con dos defectos de severidad alta abiertos y documentados, un plan de hypercare aprobado y sin reclamación de ninguna de las partes.
El coste de la auditoría fue inferior al 1 % del presupuesto del proyecto. El coste de un arranque fallido, medido en nuestra experiencia pericial en términos de sobrecoste, paralización de la operación y honorarios de un procedimiento judicial que suele durar más de dos años, es de otro orden de magnitud.
Diez señales de que su proyecto necesita una auditoría
Hay síntomas que, en nuestra experiencia, anticipan con bastante fiabilidad un proyecto en dificultades. El informe de estado lleva meses en verde mientras las fechas se mueven. Ningún Quality Gate se ha celebrado con checklist y acta. La lista de GAP sigue vacía o sin estimar cuando la configuración ya ha empezado. El comité de autoridad de diseño existe en el Charter pero no se ha reunido. Las estrategias de pruebas y de migración no están aprobadas o se han redactado después de empezar a construir. Los Change Requests se discuten en diapositivas y no se formalizan. Los porcentajes de avance no se apoyan en ningún registro de configuración. El cliente no ha visto funcionar nada en sistema desde los talleres de Explore. El plan de cutover y el de hypercare no existen a ocho semanas del arranque. Y el integrador atribuye todos los retrasos al cliente sin haberlos escalado en su momento. Dos de estas señales bastan para justificar la auditoría; cinco indican que llega tarde.
Conclusión
SAP Activate es una metodología excelente cuando se ejecuta, y un argumento de venta vacío cuando solo se cita. La diferencia entre lo uno y lo otro no la decide el integrador ni el cliente, sino la evidencia que el proyecto va dejando en su repositorio. Una auditoría de conformidad independiente lee esa evidencia a tiempo, la convierte en un índice y en una lista de hallazgos que el comité de dirección puede entender, y permite tomar decisiones de alcance, plazo y go-live con conocimiento de causa. Cuando se hace en el momento adecuado, evita el litigio; cuando el litigio ya es inevitable, es la base del peritaje.
En Legal & Digital Auditors realizamos auditorías de conformidad con SAP Activate en implantaciones y conversiones a S/4HANA, con auditores certificados CISA y perito judicial informático, y somos socios de AUSAPE. Si su proyecto muestra alguna de las señales descritas, o si simplemente quiere llegar al go-live con la seguridad de que la metodología contratada se ha cumplido, estaremos encantados de ayudarle.
