Toda empresa que planifica algo planifica el negocio a tres y cinco años. Dónde quiere estar, cuánto quiere facturar, qué mercados quiere abrir, cuánta gente va a contratar. Eso está escrito, se revisa todos los años y alguien responde por ello.

Pregunte por la TI en el mismo horizonte y la conversación cambia de temperatura. Hay presupuesto del año que viene — a veces del trimestre. Hay una lista de proyectos aprobados. Pero un plan de tres a cinco años, con la misma disciplina del plan de negocio, casi nunca existe.

Es una asimetría extraña, porque hoy la TI es lo que ejecuta el plan de negocio. Y es esa asimetría la que convierte al área en reacción permanente.

El síntoma que todos reconocen

El síntoma no es falta de trabajo. Es el tipo de trabajo.

El área vive de demanda que llega ya cerrada: comercial cerró con un cliente que exige integración; legales necesita responder a una norma nueva; la dirección compró una empresa y ahora hay dos ERP. Cada una de esas es legítima. El problema es que todas llegan como hecho consumado, con un plazo definido por terceros.

Cuando eso es la rutina, pasan tres cosas en secuencia. El área pierde la capacidad de decir que no, porque no tiene un plan contra el cual comparar el pedido. Pasa a elegir siempre la solución más rápida, que casi nunca es la más barata en el total. Y acumula una deuda que nadie contrató, pero que todos pagan después.

El nombre de esa deuda varía — un sistema que nadie sabe mantener, una integración hecha a las apuradas que se volvió dependencia, un servidor que no se puede apagar porque nadie sabe qué corre ahí. El origen es el mismo: una decisión tomada bajo el plazo de otro, sin lugar en un plan.

Por qué la TI no se planifica al mismo plazo

No es descuido. Hay razones, y vale entenderlas antes de proponer nada.

La tecnología parece cambiar demasiado rápido para planificar. Es el argumento más común, y es media verdad. La herramienta cambia rápido; la capacidad cambia despacio. «Cerrar la exposición en plazo corto» y «tener dato confiable para decidir» van a seguir valiendo dentro de cinco años, sea cual sea el producto de moda.

El presupuesto es anual, entonces el pensamiento se vuelve anual. El ciclo financiero moldea el horizonte mental. Solo que el plan de negocio también convive con presupuesto anual y no por eso deja de ser plurianual.

Falta lenguaje común. El plan de negocio habla de mercado, ingresos y margen. El plan de TI suele venir en nombres de producto y versiones. Una dirección no puede priorizar entre dos cosas que no entiende, y lo que no se prioriza se vuelve fila por orden de llegada.

Nadie lo pide. No hay un directorio pidiendo el plan de TI a cinco años. Mientras no falte, no aparece.

La pregunta que ordena todo

Antes de la metodología, una pregunta. Cuando alguien pide un sistema, la respuesta útil no es cuál sistema — es para qué.

«Necesito un CRM.» ¿Para qué? «Para mejorar las ventas.» ¿Mejorarlas cómo — vender a más gente, vender más a quien ya es cliente, o perder menos en el medio del embudo? Cada una de esas respuestas lleva a una decisión técnica distinta, y dos de ellas tal vez no necesiten CRM alguno.

Parece obvio y casi nunca se hace, porque exige admitir que el pedido llegó sin objetivo declarado. Pero es esa pregunta la que une lo técnico con el negocio — y sin esa unión no hay plan, hay lista de compras.

El plan en cuatro preguntas

Un plan de TI plurianual no necesita ser un documento de cien páginas. Necesita responder cuatro cosas, y revisarse cuando el negocio cambie.

1. ¿Qué va a exigir el negocio? Sale del plan de negocio, no de la TI. ¿Va a abrir filial en otro país? Entonces habrá exigencia fiscal y de latencia. ¿Va a comprar empresas? Entonces habrá integración y consolidación, más de una vez. ¿Va a vender a un sector regulado? Entonces habrá auditoría y evidencia. Cada movimiento de negocio tiene una consecuencia técnica previsible — y previsible significa planificable.

2. ¿Qué ya existe, y en qué estado? Inventario honesto: qué corre, quién lo mantiene, qué está fuera de soporte, qué nadie sabe explicar. Esa es la parte que suele doler, porque expone lo acumulado. Es también la que más ahorra después — buena parte de lo que se planifica construir ya existe, mal hecho u olvidado.

3. ¿Qué tiene que nacer, y qué tiene que morir? Los planes de TI adoran la primera mitad e ignoran la segunda. Dar de baja tiene costo, tiene riesgo y tiene dueño — y si no está en el plan, no pasa. El ambiente que nunca muere es el que hace subir el costo sin que nadie entienda por qué.

4. ¿En qué orden, y por qué? El orden no es técnico: es de dependencia y de riesgo. Lo que traba otras cosas va primero. Lo que tiene riesgo regulatorio con fecha va primero. Lo deseable pero aislado puede esperar — y tiene que estar escrito que va a esperar, si no vuelve como urgencia.

Cómo escribirlo para que la dirección lo entienda

La regla es simple: el plan se escribe en capacidades, no en productos.

«Migrar a la versión X» no es objetivo — es medio. «Poder cerrar el mes en tres días en vez de diez» es objetivo, y sobrevive al cambio de proveedor. «Implantar la herramienta Y» no le dice nada a quien decide; «reducir a 48 horas el tiempo entre descubrir una vulnerabilidad explotable y corregirla» sí, y se puede medir.

Esa traducción tiene un efecto colateral valioso: obliga a la TI a saber por qué hace lo que hace. Un proyecto que no sobrevive a la traducción al lenguaje de negocio en general no debería estar en la lista.

Qué cambia cuando el plan existe

Cambian tres cosas, y ninguna de ellas es la velocidad de entrega.

La conversación cambia de lugar. Cuando llega un pedido nuevo, la pregunta deja de ser «¿se puede hacer?» y pasa a ser «¿esto entra en lugar de qué?». Priorizar deja de ser una opinión de la TI y se vuelve una decisión de negocio, con el costo a la vista.

La deuda pasa a ser elección. Seguirá habiendo urgencia, y seguirá siendo correcto atender algunas de ellas mal y rápido. La diferencia es que eso se vuelve decisión registrada, con plazo para corregir — y no accidente que nadie recuerda haber causado.

El presupuesto se vuelve defendible. Pedir plata para «actualizar la infraestructura» es difícil. Pedirla para «sostener la apertura de tres filiales previstas en el plan de negocio» es otra conversación — y es la misma plata.

El límite honesto: ningún plan elimina el imprevisto, y la TI va a seguir apagando incendios. Lo que cambia es la proporción — de un área que solo reacciona a una que reacciona y construye. Y esa diferencia aparece justamente en el horizonte de tres a cinco años, que es donde hoy no mira.

Por dónde empezar, si no hay nada

No empiece por el documento. Empiece por el inventario de lo que existe y por una lectura del plan de negocio — los dos insumos que el plan de TI necesita y que suelen estar en cajones distintos. Es el mismo relevamiento que hacemos en un diagnóstico de TI, y responde las dos primeras preguntas antes de cualquier decisión de compra.

Después de eso, una página. Cuatro preguntas respondidas, un orden justificado, un dueño en la dirección y una fecha de revisión. Si no entra en una página, todavía no está lo bastante claro para ser plan.

Y vale registrar de dónde viene esta observación: no nació de una metodología, nació de la repetición. En años visitando empresas, la pregunta «¿cuál es su plan de TI para los próximos tres años?» casi siempre encuentra el mismo silencio — y es el mismo silencio, seis meses después, cuando alguien pregunta por qué nadie lo previó.

Preguntas frecuentes