Reinicio sin modelo de control sigue siendo costoso

Muchos programas de digitalización avanzan sin una clara asignación de responsabilidad sobre Capex y Opex. Capex se refiere a los gastos de inversión iniciales, mientras que Opex abarca los costes operativos y de licencias recurrentes. Los CIO y CDO en la región DACH necesitan un modelo de gobernanza sólido antes de aprobar nuevos programas.

RelacionadoAI Act Omnibus pospone los sistemas de alto riesgo: la gobernanza sigue vigente  /  ¿Qué gobernanza permanece tras el despliegue de agentes?

Por qué los programas sin propietario fracasan

Un programa de digitalización sin un responsable global designado se convierte en una colección de iniciativas desconectadas. Presupuesto, plazos y promesas de valor se distribuyen entre varias líneas jerárquicas. Nadie asume la responsabilidad del éxito global. Cuando el área de negocio reclama el beneficio, TI proporciona la plataforma y el CDO mantiene el relato, falta la figura que resuelva conflictos de objetivos y decida sobre cancelaciones.

El Tribunal de Cuentas Federal describe este patrón en su informe de asesoramiento de julio de 2025 sobre la digitalización de la administración, dirigido a la Comisión de Presupuestos del Bundestag. Según este, el Gobierno federal ejerció un control insuficiente. Las estrategias digitales se limitaron a inventarios sin un análisis riguroso de deficiencias. Los objetivos rara vez eran medibles. Las desarrollos paralelos generaron un «caos». Se destinaron fondos sin demostrar rentabilidad, ignorando riesgos o faltando recursos humanos. Como ejemplo, el informe menciona el proyecto Smart-eID: en 2021, el Ministerio del Interior ya calificó el riesgo de fracaso como «casi seguro». A pesar de ello, se invirtieron más de 90 millones de euros. El proyecto fracasó. Para las soluciones EfA (una para todos), la Federación asignó a los Länder unos 500 millones de euros sin verificar previamente la rentabilidad de las soluciones propuestas. Muchas quedaron limitadas a un solo Land o municipio, o directamente no se utilizaron.

En empresas cotizadas, esta misma brecha suele manifestarse como un portfolio sin priorización vinculante. El programa sigue siendo visible, pero la responsabilidad sobre los resultados sigue siendo negociable.

El fracaso rara vez comienza con la tecnología. Comienza cuando nadie quiere asumir la responsabilidad de cancelar un proyecto no productivo porque nadie lo posee formalmente. Entonces, los contratos posteriores, las renovaciones de licencias y los trabajos de integración continúan, aunque ya no se pueda demostrar el beneficio empresarial. Por ello, el modelo de gobernanza TI debe imponer la asignación de ownership antes de aprobar el presupuesto y no después.

Separar Capex, Opex y riesgo operativo

Los equipos suelen tratar la aprobación de Capex como una decisión de inversión puntual. Tras el lanzamiento, el estado del proyecto desaparece, mientras que los costes operativos, las licencias y el riesgo operativo aumentan. Sin cuentas separadas ni responsabilidades diferenciadas, la operación continua se convierte en un epígrafe residual de la decisión de inversión.

Un modelo sólido separa tres niveles de decisión. En primer lugar, la aprobación de la inversión con el caso de negocio, el ajuste arquitectónico y la hipótesis de valor. En segundo lugar, la Übernahme de la operación con nivel de servicio, capacidad y requisitos de seguridad. Y en tercer lugar, la evaluación continua de la rentabilidad, que contrasta el crecimiento de los costes operativos y las posiciones de riesgo con el valor prometido inicialmente. El marco de gobernanza COBIT 2019 de ISACA agrupa precisamente esta separación: EDM02 gestiona la demostración del valor (Benefits Delivery), APO05 la gestión y priorización del portafolio, y la dimensión DSS la operación continua. ITIL 4 complementa este enfoque con la gestión del nivel de servicio y la habilitación del cambio. Allí, los equipos evalúan riesgos antes de la aprobación y gestionan los cambios en el servicio en curso.

El riesgo operativo debe incluirse en la lógica de aprobación. Quien aprueba nuevos canales, flujos de datos o componentes de IA asume los riesgos de fallos, cumplimiento y dependencias en la operación continua. Si Capex y Opex se mezclan en una misma línea, el riesgo permanece invisible hasta que aparece en un incidente o en una auditoría. La separación aporta claridad: quién invierte, quién opera y quién asume el riesgo residual.

Matriz de roles para CIO, CDO y área de negocio

Un modelo de gobernanza se sustenta en una matriz de roles que define derechos de decisión y vías de escalado. El CIO es responsable de la integridad arquitectónica, la capacidad operativa, así como de los estándares de seguridad y adquisiciones. El CDO gestiona las prioridades del portafolio, la lógica de valor y la conexión con los modelos de negocio. El área de negocio posee los requisitos funcionales, la demostración del valor y la gestión del cambio en los procesos.

La matriz debe anticipar conflictos. ¿Quién decide ante roadmaps competidores? ¿Quién detiene un proyecto si el valor no se materializa? ¿Quién asume los costes si el área de negocio amplía el alcance y la plataforma debe mantenerse estable? Sin esta clarificación surge una gobernanza paralela: programas del CDO junto a proyectos de TI, herramientas del área de negocio junto a la arquitectura empresarial. COBIT 2019 aporta para ello matrices RACI (Responsible, Accountable, Consulted, Informed) por cada objetivo de gobernanza y gestión, así como para estructuras organizativas de decisión. ISACA lo deja claro: los diagramas RACI no reemplazan la rendición de cuentas, sino que la clarifican. Múltiples roles «Accountable» para un mismo resultado generan un comité. La responsabilidad de ownership solo surge con un único rol Accountable.

Las dobles funciones son posibles, pero la responsabilidad compartida sobre un mismo resultado no lo es. Si el CIO y el CDO recaen en una misma persona, la separación entre responsabilidad de plataforma y gestión del portafolio debe quedar documentada. El área de negocio puede establecer requisitos, pero no debe generar una TI en la sombra como estado permanente. La matriz solo funciona si está vinculada a derechos presupuestarios y de aprobación.

Lógica de puertas de control para aprobaciones y cancelaciones

La gobernanza de programas de digitalización requiere puertas de control que aprueben o cancelen. En la práctica, son recomendables al menos cuatro puertas: aprobación del concepto y la arquitectura, aprobación de la inversión, Übernahme de la operación, y evaluación periódica de valor y riesgo. Cada puerta necesita criterios de cancelación concretos, no solo semáforos.

Los criterios de cancelación deben definirse antes del primer euro invertido. Ejemplos incluyen la falta de demostración de valor, la ausencia de Übernahme de la operación, deficiencias de seguridad sin plan de remediación o la ruptura arquitectónica respecto al modelo objetivo. Cancelar solo por negociación política protege los gastos en curso y penaliza las decisiones honestas de detención. El modelo Stage-Gate de Robert G. Cooper formaliza esta lógica desde hace décadas: en cada puerta, los responsables evalúan según criterios predefinidos y deciden entre continuar, cancelar, pausar o reciclar. Las puertas son decisiones de inversión con compromiso de recursos. Las reuniones de seguimiento reflejan el progreso, pero las puertas comprometen y liberan fondos. El Tribunal de Cuentas Federal recomienda en su informe de 2025 exactamente lo mismo para los fondos públicos de digitalización: solo se aprueba si los proyectos contribuyen a los objetivos digitales, son económicos, implementan estándares y consideran los riesgos.

La lógica de puertas de control debe formar parte del portafolio, no de la metodología de proyectos individuales. Un proyecto puede ejecutarse metodológicamente bien y ser estratégicamente irrelevante. Por eso, el comité de gobernanza necesita la competencia para finalizar proyectos, incluso con éxitos parciales, si la inversión en Capex, la trayectoria de Opex o el riesgo operativo superan el valor generado. Aprobar sin opción de cancelación se convierte en una automatización de continuidad.

Qué debe ver realmente el Consejo de Supervisión

El Consejo de Supervisión no necesita listas de funciones ni reinicios de presentaciones en PowerPoint. Necesita una visión compacta sobre la vinculación de Capex, la evolución de los Opex, los riesgos operativos críticos y el estado de las pruebas de beneficio por programa. Esto incluye la propiedad, la próxima decisión de puerta (gate) y las opciones explícitas de abandono o reajuste.

Solo es apto para informes lo que sea decisivo. Un semáforo sin propuesta de decisión exime de responsabilidad a la dirección y bloquea al Consejo de Supervisión. Son útiles pocas métricas con una interpretación clara: Capex invertido y aún vinculado, carga actual de Opex por programa, riesgos altos pendientes y porcentaje de proyectos con prueba de beneficio confirmada. El Código Alemán de Gobierno Corporativo (DCGK) establece el marco: el Principio 4 exige un sistema interno de control y gestión de riesgos adecuado y eficaz. La Recomendación A.5 pide en el informe de gestión las características esenciales de estos sistemas, así como una valoración sobre su adecuación y eficacia. El Principio 6 integra al Consejo de Supervisión en decisiones de importancia fundamental y exige reservas de aprobación. Los riesgos de TI y digitales entran en este mandato de supervisión tan pronto como afecten materialmente a la actividad empresarial.

Los relatos políticos sobre programas no sustituyen la gestión empresarial. Las iniciativas públicas de digitalización pueden servir de orientación, pero no reemplazan ni la disciplina en Capex ni la responsabilidad operativa en la propia organización. El Consejo de Supervisión debería preguntar por el modelo de control, no por el marketing del próximo reinicio. La transparencia se logra cuando las decisiones de parada son tan reportables como las de aprobación.

Quien apruebe nuevos programas de digitalización sin fijar la propiedad, la separación de Capex y Opex, la matriz de roles y la lógica de puertas (gates), financia la continuación en lugar del control. El modelo de control de TI es la condición previa para el próximo reinicio, mucho antes de que se supere el presupuesto previsto.

Preguntas frecuentes

Más para leer en Digital Chiefs

Digital ChiefsMade for Germany: Cuanto valen realmente 735 mil millonesDigital ChiefsEl Chief AI Officer ya está aquí. El problema sigue igualDigital ChiefsLa apuesta por miles de millones de los hyperscalers y su factura de la nube

Más de la red MBF Media

cloudmagazin

Cuando las GPU se comen el presupuesto de SaaS

mybusinessfuture

IA en pymes: del piloto a la escalabilidad

securitytoday

El Reglamento de IA es, en realidad, una ley de seguridad

Fuente de la imagen: Generada por IA (julio 2026)