...que nadie está reportando al directorio 

¿Puede un proyecto estar en verde y, al mismo tiempo, representar un riesgo importante para el negocio?

Imaginemos una reunión de directorio en la que se presenta el avance de una migración a SAP S/4HANA. El cronograma se encuentra dentro de lo planificado. El presupuesto está controlado. Los entregables avanzan según las fechas comprometidas y el tablero muestra indicadores mayoritariamente en verde.

Todo parece indicar que el proyecto está bajo control. Sin embargo, detrás de esos resultados pueden existir procesos críticos sin pruebas completas, interfaces pendientes de validación, defectos abiertos o escenarios de alta demanda que nunca se han ejecutado.

El problema aparece cuando los indicadores de avance se interpretan como evidencia de que el negocio está preparado para operar. Un proyecto puede avanzar según lo planificado y mantener riesgos capaces de comprometer su continuidad operacional.

1. Medir el avance no es lo mismo que medir el riesgo

Los indicadores tradicionales responden preguntas necesarias: ¿estamos cumpliendo el cronograma?, ¿el presupuesto se mantiene dentro de lo aprobado?, ¿los entregables están terminados? Estas métricas controlan la ejecución, pero no necesariamente muestran qué podría fallar al entrar en producción.

Los indicadores de riesgo preguntan algo distinto: ¿los procesos críticos fueron validados de extremo a extremo?, ¿las integraciones funcionan?, ¿existen defectos capaces de detener la facturación?, ¿el sistema soporta los volúmenes reales de operación?

Los indicadores de avance muestran cuánto hemos construido. Los indicadores de riesgo permiten evaluar qué tan preparados estamos para operar con lo construido. Ambas perspectivas son necesarias.

2. Cuando un riesgo tecnológico se convierte en un problema financiero

Consideremos una empresa que migra sus procesos comerciales y financieros a SAP S/4HANA. Durante las pruebas, los usuarios ingresan pedidos y generan documentos correctamente, pero no se valida completamente la integración entre pedidos, entregas y facturación.

Después del Go Live, algunos pedidos presentan errores que impiden completar el proceso comercial. La facturación se retrasa, los equipos deben reprocesar transacciones y aumenta la carga operacional. Determinados clientes podrían recibir sus productos o documentos fuera de plazo. Si el problema persiste, también puede afectar la cobranza y el flujo de caja.

Facturación retrasada no equivale necesariamente a ingresos perdidos. Incluso cuando las transacciones se recuperan, la interrupción puede generar costos adicionales y afectar compromisos comerciales. El impacto de un defecto debe evaluarse por sus consecuencias para el negocio, no solo por su complejidad técnica.

3. Los riesgos que pueden quedar ocultos detrás de un tablero verde

Procesos críticos sin validación completa. Un proceso puede funcionar en pruebas individuales y fallar cuando intervienen distintos módulos o áreas. Crear un pedido no demuestra que el ciclo de venta, despacho, facturación y contabilización funcione de extremo a extremo.

Interfaces pendientes o insuficientemente probadas. SAP suele conectarse con plataformas logísticas, sistemas bancarios y aplicaciones comerciales. Una integración sin validar puede interrumpir procesos dependientes de información compartida.

Defectos críticos abiertos. La cantidad total de defectos no siempre refleja su impacto: diez errores menores pueden representar menos riesgo que uno capaz de impedir la emisión de facturas o la conciliación financiera.

Pruebas poco representativas. Que una transacción funcione con pocos usuarios no demuestra que mantendrá su rendimiento durante la demanda máxima. Las pruebas de Performance deben representar cargas, concurrencia y volúmenes esperados.

4. ¿Qué información debería conocer el directorio?

El directorio no necesita revisar cada caso de prueba. Necesita comprender la exposición del negocio y las consecuencias de las decisiones que aprueba. Un reporte ejecutivo debería complementar los indicadores tradicionales con:

Esta información permite distinguir entre progreso de implementación y preparación real, y facilita decisiones Go/No-Go basadas en el impacto de los riesgos pendientes.

5. El riesgo residual: lo que permanece después de probar

Ninguna implementación tecnológica está completamente libre de riesgos. Incluso después de pruebas funcionales, automatización, Performance y validaciones de integración, pueden quedar situaciones pendientes. El riesgo residual es el que permanece después de aplicar medidas de control y mitigación.

Su evaluación considera probabilidad, impacto sobre el negocio, contingencias y capacidad de recuperación. No es lo mismo avanzar con un defecto de impacto limitado y una alternativa probada que hacerlo con un defecto capaz de detener un proceso financiero crítico sin contingencia efectiva.

La decisión ejecutiva consiste en comprender qué riesgos permanecen, qué consecuencias pueden generar y bajo qué condiciones resulta aceptable asumirlos.

6. La responsabilidad de la Calidad también es ejecutiva

Las actividades de Testing suelen asociarse a equipos técnicos y funcionales, pero las consecuencias de una falla pueden alcanzar a toda la organización. Una interrupción en facturación afecta a Finanzas; una falla de inventarios compromete a Operaciones; una integración defectuosa puede impactar a clientes.

Por ello, el Gobierno de Calidad requiere participación de los responsables del negocio y mecanismos claros para informar riesgos, evaluar evidencias y respaldar decisiones. El porcentaje de casos aprobados no basta si las pruebas no representan los procesos que sostienen la operación.

Reflexión final: ¿qué significa realmente tener un proyecto bajo control?

Un tablero en verde puede ser una buena noticia: refleja disciplina de ejecución y cumplimiento de compromisos. Pero esos resultados no garantizan, por sí solos, que la organización esté preparada para operar con SAP S/4HANA.

El verdadero desafío es conectar información tecnológica con consecuencias empresariales. Un proceso no probado representa exposición operacional; una interfaz pendiente puede comprometer una actividad crítica; un defecto sin resolver puede convertirse en costo financiero.

El riesgo más peligroso no siempre es el de mayor complejidad técnica. Puede ser aquel que nunca fue traducido a su impacto en el negocio y, por lo tanto, nunca llegó a quienes debían conocerlo.

La pregunta que debería acompañar cada reporte ejecutivo no es únicamente cuánto hemos avanzado, sino también: ¿qué podría impedir que nuestro negocio opere correctamente y qué evidencia tenemos de que estamos preparados para enfrentarlo?