Casi todas las empresas medianas tienen algo que llaman "plan de TI". En la práctica suele ser una de dos cosas: una lista de compras pendientes, o un documento aspiracional que se escribió una vez y nadie ha vuelto a abrir. Ninguna de las dos sobrevive al primer trimestre, porque ninguna resuelve el problema real: decidir qué se hace primero, con qué dinero y a costa de qué.
Un roadmap de 12-24 meses no es burocracia. Es el mecanismo que convierte intenciones en presupuesto comprometido y secuencia ejecutable. Sin él, TI opera en modo reactivo permanente: cada urgencia desplaza al proyecto anterior y al final del año se gastó el presupuesto sin haber avanzado en nada estructural.
Lo que un plan sin roadmap no puede resolver
Los proyectos de infraestructura tienen dependencias duras. No se puede migrar el correo antes de sanear el directorio; no conviene renovar servidores antes de decidir qué se queda en sitio y qué se va a nube; no tiene sentido invertir en monitoreo avanzado sobre una red sin segmentar. Un plan sin secuencia explícita hace estos proyectos en el orden en que aparecen las urgencias — que casi nunca es el orden correcto — y se paga dos veces: una por hacer el trabajo y otra por rehacerlo (retrabajarlo).
Qué contiene un roadmap que sí funciona
- Secuencia con dependencias: qué proyecto habilita a cuál, y qué no puede empezar antes de que otro termine.
- Presupuesto por trimestre, no por año: un monto anual global permite que las urgencias se lo coman; asignarlo por trimestre y por iniciativa lo protege.
- Ciclos de vida explícitos: fechas de fin de soporte de sistemas operativos, garantías de hardware y vencimientos de licenciamiento, puestos en el calendario antes de que se vuelvan emergencias.
- Criterios de entrada y salida: qué justifica meter un proyecto nuevo al roadmap y qué proyecto sale para hacerle espacio. Sin esta regla, el roadmap crece hasta volverse ficción.
El error más común: confundir roadmap con lista de deseos
Un roadmap con 25 iniciativas para 12 meses no es un plan, es una negación. En general, una empresa mediana puede ejecutar bien entre 4 y 8 iniciativas de infraestructura al año, dependiendo de si las opera con equipo interno o con un proveedor administrado. Lo demás es mantenimiento y operación diaria, que también consume capacidad y casi nunca se contabiliza.
Por eso el roadmap debe construirse desde la capacidad real de ejecución, no desde la lista de todo lo deseable. Es preferible un roadmap corto que se cumple a uno ambicioso que se abandona en marzo.
El roadmap como herramienta de conversación con dirección
El beneficio menos visible es político: un roadmap vigente cambia la conversación con dirección. En lugar de pedir dinero cada vez que algo truena — la peor posición negociadora posible — TI presenta un plan con fechas, y cada gasto llega anunciado con meses de anticipación. Suele ocurrir que la resistencia de dirección a invertir en TI no es al monto, sino a la sorpresa.
Un roadmap no elimina las urgencias; les da contexto. Cuando aparece un imprevisto, la decisión deja de ser "¿gastamos en esto?" y pasa a ser "¿qué movemos del plan para atender esto?" — una decisión informada en vez de una reacción.
Si mañana le preguntaran qué proyectos de TI va a ejecutar tu empresa en los próximos 18 meses y en qué orden, ¿podrías responder con fechas, o solo con intenciones?