No es extraño encontrar problemas en IT, incluso suele ser habitual. Lo grave es cuando, con esos problemas delante, alguien quiere hablar ya de transformación.
Porque ahí suele empezar el autoengaño.
No es grave solo tener infraestructura vieja, procesos incompletos o proyectos mal priorizados. Lo grave es intentar construir encima de eso como si la base aguantara. Cuando transformas una operación que todavía no controlas, no modernizas nada: haces más cara, más frágil y más difícil de gobernar la misma inestabilidad.
La pregunta no es si tu IT necesita cambiar. Eso ya lo sabes. La pregunta es: ¿estás llamando «transformación» a una huida hacia delante?
Por qué transformar antes de estabilizar
En casi todas las organizaciones este error entra con una frase razonable. «Hay que aprovechar el cambio para impulsar la transformación». Dicho así, parece visión. En la práctica, muchas veces significa meter nuevas iniciativas sobre una operación que todavía vive al límite.
Ahí está el riesgo.
Si intentas transformar sin haber estabilizado antes, cada proyecto nuevo añade complejidad, consumo de capacidad, más puntos de fallo y más dependencia de personas concretas. El problema no es que falte ambición, falta suelo.
Las señales suelen estar a la vista en la primera semana.
Incidentes que se repiten sin corrección real. Cambios que entran por urgencia y no por criterio. Proyectos abiertos que nadie se atreve a cerrar, aunque ya compitan entre sí. Infraestructura y aplicaciones sin inventario fiable. Riesgos de seguridad conocidos, pero sin dueño ni fecha. Equipo saturado, siempre ocupado y sin capacidad de explicar qué deja de hacer cada vez que se le pide algo nuevo. Reuniones donde se habla mucho de cloud, automatización o IA, mientras lo básico sigue dependiendo de la memoria, buena voluntad y personas que ya van al límite.
La mecánica del fallo es bastante simple. No suele faltar trabajo. Falta autoridad. Nadie toma la decisión incómoda de decir que la prioridad inmediata no es transformar, sino recuperar control operativo. Y cuando esa decisión no aparece, cada uno empuja desde su necesidad: negocio pide velocidad, proveedores venden futuro, IT intenta sostenerlo todo, los mandos intermedios amortiguan como pueden y el equipo técnico acaba funcionando como una unidad de contención, no como una función gobernada.
En ese punto, la organización empieza a confundir movimiento con avance. Se celebra que hay iniciativas nuevas, aunque el servicio siga siendo inestable. Se presume de roadmap, aunque no exista control mínimo del presente. Se habla de modernización, mientras la continuidad real depende de que dos personas no se cansen, no fallen y no se vayan.
Eso tiene consecuencias directas de negocio. La primera es la pérdida de fiabilidad: si la base ya falla, cualquier capa nueva amplifica el problema. La segunda es la dependencia: cuanto más frágil es la operación, más poder real concentran quienes sostienen conocimiento crítico sin estructura alrededor. La tercera es la pérdida de credibilidad: cuando IT promete cambio sin haber recuperado control, el negocio deja de ver dirección y empieza a ver ruido.
Prueba este checklist con respuesta binaria – si-no – y si reconoces al menos tres de estas señales, no estás en fase de transformación:
- no existe un inventario mínimo validado de infraestructura, aplicaciones y responsables;
- una parte relevante de los incidentes críticos se repite sin acción correctiva cerrada;
- los cambios relevantes no siguen un mecanismo mínimo de evaluación, aprobación y reversión;
- hay proyectos estratégicos activos que el equipo no puede sostener sin degradar la operación;
- la continuidad de procesos o servicios clave depende de una sola persona o de conocimiento no documentado.
Si eso pasa, la intervención no debería empezar con una iniciativa nueva. Debería empezar con una decisión de secuencia.
- Reconocer el estado real: operación inestable, prioridades mezcladas y capacidad consumida por reacción.
- Asumir la causa: no falta trabajo ni buena intención; falta un mínimo gobierno operativo y falta alguien que ordene el tiempo.
A partir de ahí, las opciones suelen ser tres.
- Seguir igual y confiar en que aguante.
- Intentar una gran reorganización y añadir aún más ruido.
- O hacer una pausa selectiva, breve y seria, para recuperar control.
Yo tengo muy claro que eligiría la tercera opción y lo haría de la siguiente manera.
Durante 30 días, congelaría cualquier iniciativa de transformación que no reduzca riesgo operativo de forma directa. En paralelo, obligaría a producir un único entregable: una página con riesgos críticos, proyectos que deben pausarse, inventario mínimo, dependencias peligrosas y mecanismo provisional de incidentes y cambios. Esa página tiene que tener dueño, fecha y uso real en la priorización semanal. Si no existe, todavía no hay dirección. Solo hay preocupación bien redactada.
A partir de ahí sí tiene sentido dejar tres mecanismos en marcha.
- Una revisión semanal de prioridades con decisiones explícitas.
- Un runbook mínimo de incidentes y cambios que quite excusas.
- Una revisión quincenal de dependencias críticas por personas y servicios.
Aquí no eliges entre innovación y conservadurismo. Eliges entre tolerar una IT frágil con discurso moderno o cortar el ruido suficiente para poder gobernarla.
La pregunta que te hago: ¿qué estás llamando transformación para no admitir que tu IT todavía no está bajo control?
