Business case de IT: opciones, costes, beneficios medibles, TCO a cinco años y la decisión que pides al comité

Qué vas a conseguir

Un documento de cuatro o cinco páginas con el que un comité de inversiones o de dirección puede decir sí, no o "vuelve con esto" en una sola reunión. No es un argumento a favor de lo que IT ya ha decidido: es la comparación honesta de varias opciones, con cifras que finanzas puede comprobar y beneficios que alguien va a medir después.

El ejemplo de toda la guía: los cinco servidores físicos de la sede llegan al fin de soporte del fabricante en marzo y alojan el ERP, los ficheros y la impresión.

Antes de empezar

• Quién decide y con qué umbral: muchas organizaciones tienen un importe a partir del cual la inversión va a comité, y un formato propio. Si existe plantilla, úsala.
• Un patrocinador de negocio que defienda el caso contigo. Un business case que solo firma IT se lee como una petición de presupuesto.
• Los datos de partida: inventario y contratos (fechas de fin de soporte, renovaciones), incidencias de los últimos 12 meses, horas del equipo y el coste por hora interno que usa finanzas.
• Una conversación previa con control de gestión: qué tasa de descuento usan, a cuántos años amortizan el hardware y qué consideran CAPEX.

1. El problema, en una página

El primer apartado se escribe para quien solo va a leer ese: qué pasa, desde cuándo, a quién afecta y qué ocurre si no se hace nada.

• Hecho: "Los cinco servidores de la sede quedan sin soporte del fabricante el 31 de marzo. Alojan el ERP, los ficheros y la impresión de 180 personas."
• Consecuencia: sin parches de firmware ni repuestos garantizados; una avería de placa puede dejar el ERP parado días, no horas.
• Evidencia: 14 incidencias de hardware en 12 meses, 300 horas del equipo dedicadas a ellas.
• Urgencia: el plazo de entrega del hardware es de 8 a 10 semanas. Decidir en diciembre o en febrero no es lo mismo.

Si el problema no se entiende sin saber qué es un hipervisor, reescríbelo. El comité decide sobre riesgo y dinero, no sobre tecnología.

2. Las opciones, siempre con "no hacer nada"

Entre dos y cuatro opciones, y una de ellas es no hacer nada (o el mínimo imprescindible). Es la referencia contra la que se mide todo lo demás: sin ella no hay ahorro ni beneficio que calcular.

Cada opción con el mismo nivel de detalle. Una opción "de relleno" descrita en dos líneas resta credibilidad a la buena.

3. Los costes: lo que se paga una vez y lo que se paga cada año

Separa siempre dos ejes: CAPEX u OPEX (cómo lo trata contabilidad) y único o recurrente (cuándo sale el dinero). No coinciden: la implantación de un servicio en la nube es un coste único que suele ir a OPEX.

Para la opción B:

• Las licencias con su modelo exacto (por núcleo, por usuario, suscripción anual) y la subida prevista en la renovación. Es la partida que más se equivoca.
• Las personas: horas internas aunque no generen factura, y si hace falta contratar o externalizar algo. Si el equipo no tiene tiempo, dilo y cuéntalo como coste.
• Un margen de contingencia explícito (10-15 % sobre lo único) mejor que unas cifras infladas en silencio.
• El CAPEX se amortiza: 160.000 € a cinco años son 32.000 € al año en la cuenta de resultados. El plazo lo fija finanzas, no IT.

4. Beneficios que se pueden medir

Un beneficio entra en el cálculo si tiene línea base, métrica, dueño y fecha. Lo que no cumple eso va en una lista aparte de beneficios cualitativos, sin euros.

Las horas ahorradas del equipo no son dinero que se ahorra si nadie sale de la plantilla: son capacidad que se libera. Escríbelo así ("300 horas para el proyecto de Windows 11") y el comité te creerá el resto.

5. ROI, periodo de recuperación y VAN

Con "no hacer nada" costando 99.500 € al año (52.000 de soporte, 20.000 de licencias, 14.000 de energía y 13.500 de horas de incidencias) y la opción B costando 43.600 € al año, el ahorro anual es de 55.900 € frente a una inversión inicial de 208.000 €.

• Periodo de recuperación (payback): inversión ÷ ahorro anual = 208.000 ÷ 55.900 ≈ 3,7 años.
• ROI a cinco años: (ahorro acumulado − inversión) ÷ inversión = (279.500 − 208.000) ÷ 208.000 ≈ 34 %.
• VAN (valor actual neto) al 8 %: cada ahorro anual se descuenta, ahorro ÷ (1 + 0,08)^año, y se resta la inversión. Cinco años de 55.900 € valen hoy unos 223.200 €; el VAN es de unos +15.200 €. Positivo, pero ajustado.

Un VAN pequeño no es un mal caso: dice que la opción B se paga sola y que el argumento principal es el riesgo que elimina. Escríbelo así en vez de estirar los beneficios hasta que salga un número bonito. Si el comité usa la TIR, la calcula finanzas con los mismos flujos.

6. TCO a cinco años

El coste total de propiedad compara las opciones en el mismo horizonte, sumando lo único y lo recurrente:

• El horizonte de tres a cinco años coincide con la vida útil del hardware; más allá, las cifras son adivinanzas.
• Indica las hipótesis: precios sin IVA, sin subida de licencias, soporte extendido disponible los cinco años (no siempre lo está).
• La opción C sale más cara en este horizonte, pero puede ganar si la sede se va a cerrar o cambiar en dos años. Eso es una pregunta para el comité, no una conclusión de IT.

7. Riesgos, calendario y la decisión

Riesgos, de cada opción y del proyecto, con probabilidad, impacto y mitigación:

• A: avería sin repuesto del servidor del ERP. Probabilidad media, impacto alto. Sin mitigación real.
• B: retraso de entrega del hardware. Mitigación: pedido antes del 15 de diciembre, soporte extendido de tres meses como puente.
• B: migración del ERP con corte. Mitigación: ventana de fin de semana, prueba previa, plan de vuelta atrás aprobado en el CAB.

Calendario: aprobación en diciembre, pedido en la misma semana, entrega en febrero, migración por servicios en dos fines de semana de marzo, retirada del hardware viejo en abril.

La decisión que pides, en una frase al principio y al final del documento:

"Se solicita aprobar la opción B: 208.000 € de inversión con cargo al presupuesto de este año y 43.600 € anuales de gasto recurrente a partir del año próximo, con decisión antes del 15 de diciembre para cumplir el plazo de soporte."

8. Después de la aprobación: seguir los beneficios

Aprobar el caso es el principio. Sin seguimiento, el siguiente business case se leerá con más desconfianza.

• Un registro de beneficios con las líneas del apartado 4, el dueño de cada una y la fecha de medición.
• Revisión trimestral del coste real frente al aprobado: desviaciones de más del 10 % se explican.
• Revisión posterior a la implantación a los 6 y 12 meses: qué beneficios se han conseguido, cuáles no y por qué.
• Si un beneficio no llega, se dice. Si cambia el contexto (la sede se amplía, cambian las licencias), se actualiza el caso, no se esconde.

Siguientes pasos

• La guía de Presupuesto de IT del Sector 4 explica cómo entra esta inversión en el presupuesto anual y cómo se explica una desviación.
• La guía de Backup y recuperación ante desastres (DR/BCP) ayuda a cuantificar el riesgo de "no hacer nada" con RTO y RPO reales.
• Los costes recurrentes viven en contratos: el repositorio 23-it-vendor-contract-tracker de mi GitHub sigue renovaciones, plazos de preaviso y ahorros, y el 01-finops-cloud-cost-dashboard vigila el gasto de nube si eliges la opción C.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.