Intro
Las propuestas de grandes integradores suelen llegar como documentos muy pulidos: plazos seguros, metodologías reconocidas, workstreams bien definidos y un coste total que encaja con el presupuesto que la dirección esperaba aprobar. El riesgo real suele estar en los supuestos, exclusiones, dependencias y anexos.
Firmar sin una revisión independiente de esos supuestos es una forma habitual de heredar planes demasiado optimistas que luego son difíciles de renegociar, especialmente cuando los equipos internos ya están comprometidos, el gobierno del programa ha dado su aprobación y el capital político ya se ha invertido. Antes de aprobar un statement of work relevante, CEOs y CFOs deberían entender dónde la propuesta transfiere riesgo de nuevo al negocio.
Resumen ejecutivo
Una propuesta de un integrador no es solo un plan de entrega. Es un documento de asignación de riesgos. La organización compra una historia de certeza, mientras que el integrador valora la incertidumbre que puede gestionar, excluir o devolver más adelante mediante control de cambios.
Las señales de alerta no son necesariamente motivos para rechazar a un proveedor. Son preguntas que protegen el presupuesto, la credibilidad de la entrega y la reputación ejecutiva. Una brecha relevante puede ser suficiente para pausar la aprobación hasta que el statement of work se aclare, se reformule o se contraste competitivamente.
Las siete señales de alerta
1. Plazos que ignoran la realidad de las dependencias
Los programas de una sola fase con workstreams en paralelo pueden parecer eficientes sobre el papel. A menudo asumen que terceros, responsables de datos, entornos de prueba, equipos de seguridad y expertos de negocio estarán disponibles al mismo tiempo. Pregunta qué partes externas están en el camino crítico y qué ocurre con la fecha objetivo si se retrasan.
2. Hitos que suenan precisos pero demuestran poco
“Diseño completado” o “construcción completada” no es suficiente. Los hitos deberían nombrar entregables que el negocio pueda reconocer: qué procesos, qué sedes, qué integraciones, qué informes, qué controles y qué criterios de aceptación están incluidos en cada puerta de decisión.
3. Detalle de integración aplazado para más adelante
Expresiones como “interfaces por definir”, “middleware asumido” o “integración a confirmar durante el diseño” son señales de alerta. El trabajo caro rara vez es solo la conexión. Es definir propiedad, payloads, gestión de errores, reconciliación, monitorización, soporte y gestión de excepciones.
4. Migración de datos valorada solo por número de objetos
Una línea de coste basada en el número de objetos de datos no dice a la dirección si los datos serán utilizables. Si la limpieza, enriquecimiento, resolución de duplicados o propiedad del dato se describe como “responsabilidad del cliente”, el coste interno debería estimarse antes de aprobar.
5. Pruebas comprimidas al final del plan
Cuando la construcción domina la estructura del plan y las pruebas aparecen como una franja estrecha cerca del go-live, es probable que los problemas de proceso, integración y preparación del negocio aparezcan demasiado tarde. Las pruebas deberían estar visibles a lo largo del plan, no tratarse como una inspección final.
6. Gestión del cambio reducida a formación
Formación no es adopción. Una propuesta creíble debería explicar cómo se gestionarán el cambio de procesos, el impacto en roles, la implicación del negocio, la preparación para cutover y las métricas de adopción. Si la gestión del cambio se resume en unas diapositivas y un calendario de formación, el negocio está asumiendo más riesgo del que la propuesta sugiere.
7. Criterios de éxito que no pueden medirse en el go-live
“Implementación exitosa” no es un resultado medible. La dirección debería esperar criterios de aceptación claros vinculados a preparación operativa, rendimiento de procesos, controles de negocio, calidad de datos, estabilidad de integraciones y traspaso a soporte.
Conclusión práctica para la dirección
Antes de firmar una propuesta importante de un integrador, no preguntes solo si el precio es asumible. Pregunta si los supuestos son sostenibles.
Los equipos directivos deberían cuestionar cinco puntos antes de aprobar:
1. ¿Qué riesgos están explícitamente incluidos, excluidos o devueltos al cliente?
2. ¿Qué dependencias podrían retrasar el programa y quién es responsable de cada una?
3. ¿Dónde están poco especificadas la integración, los datos, las pruebas y la gestión del cambio?
4. ¿Qué activaría un control de cambios y qué probabilidad tiene ese escenario?
5. ¿Qué evidencia demostrará que el programa está preparado para salir en producción?
Una revisión independiente de un statement of work suele pagarse por sí sola al identificar una o dos brechas estructurales antes de la firma del contrato. Es mucho más barato cuestionar supuestos ambiguos en la sala de negociación que descubrirlos durante la entrega.