Presupuestos IT 2026: como presentar el business case tecnologico

El presupuesto se decide en octubre

La mayoria de las empresas espanolas cierran sus presupuestos para el ano siguiente entre octubre y diciembre. Para los responsables de tecnologia, esto significa que el business case de IT para 2026 se esta presentando ahora. Y la calidad de ese documento determina si los proyectos criticos reciben financiacion o se aplazan otro ano.

El problema no suele ser la falta de necesidades. Es la forma en que se presentan. Un CTO que llega al comite de direccion con una lista de proyectos tecnologicos y sus costes, sin conectar cada linea con impacto de negocio, pierde antes de empezar.

Benchmarks que dan contexto

Antes de presentar numeros, necesitas contexto sectorial. Las preguntas que hara el CFO son predecibles: gastamos mucho o poco en IT? Estamos alineados con el sector?

Datos de referencia para 2025-2026 (fuentes: Gartner IT Key Metrics, IDC, Forrester):

• Gasto IT como % de ingresos: media global 5.5%. Logistica: 3.5-4.5%. Banca: 7-10%. Retail: 2.5-4%. Construccion: 1.5-3%. Servicios profesionales: 5-8%.
• Crecimiento interanual del gasto IT: media estimada +8% para 2026. La IA generativa esta inflando la cifra; sin ella, el crecimiento base es del 4-5%.
• Distribucion tipica: 65-70% run (mantener lo existente), 20-25% grow (mejorar), 10-15% transform (innovar). Las empresas que invierten menos del 10% en transformacion estan, en la practica, acumulando deuda tecnologica.

Estos benchmarks no son prescripciones. Una empresa de logistica al 3% de gasto IT no necesariamente esta mal posicionada; depende de su nivel de automatizacion y sus objetivos. Pero proporcionan un marco de referencia que el comite de direccion entiende.

El framework de priorizacion

No todos los proyectos IT compiten en la misma liga. Un framework util para organizar la propuesta presupuestaria es clasificar las inversiones en cuatro categorias:

Obligatorio (compliance/riesgo). Proyectos que no son opcionales: actualizaciones de seguridad, cumplimiento regulatorio (NIS2, DORA, CSRD digital), renovacion de infraestructura end-of-life. No necesitan ROI porque el coste de no hacerlos es cuantificable y mayor. Presentalos como gestion de riesgo, no como inversion.

Mantenimiento (keep the lights on). Licencias, soporte, actualizaciones de version, renovacion de hardware. Es el 65-70% del presupuesto que todos quisieran reducir pero que sostiene la operacion. El argumento no es ROI; es continuidad operativa. El coste de una interrupcion de servicio (calcula horas de parada * coste/hora) justifica estas partidas.

Mejora (eficiencia operativa). Automatizacion de procesos manuales, migracion a cloud, integracion de sistemas, mejora de herramientas de trabajo. Aqui si hay ROI medible. El truco esta en cuantificarlo correctamente.

Transformacion (ventaja competitiva). Nuevas capacidades que cambian como la empresa compite: IA aplicada, productos digitales, nuevos canales. El ROI es mas incierto pero el coste de oportunidad de no invertir puede ser existencial a medio plazo.

La propuesta presupuestaria debe presentar las cuatro categorias por separado, con argumentos distintos para cada una. Mezclar una partida de compliance de ciberseguridad con un proyecto de IA experimental en el mismo documento es garantizar que ambos se cuestionen.

Construir el business case que aprueba el comite

Habla el idioma del CFO

El comite de direccion no aprueba “modernizaciones de stack” ni “reducciones de deuda tecnica”. Aprueba inversiones que reducen costes, aumentan ingresos, mitigan riesgos o cumplen obligaciones legales.

Traduccion practica:

• “Migrar a Kubernetes” -> “Reducir costes de infraestructura un 30% (120K EUR/ano) y eliminar 14 horas mensuales de tareas manuales de despliegue.”
• “Implementar observabilidad” -> “Reducir el tiempo medio de resolucion de incidentes de 4.2 horas a menos de 1 hora, evitando X horas de inactividad anuales valoradas en Y EUR.”
• “Automatizar procesamiento de facturas” -> “Eliminar 160 horas/mes de trabajo manual y reducir errores de clasificacion del 8% al 0.5%.”

Cada proyecto necesita tres numeros: coste total de propiedad (3 anos), beneficio cuantificado (en euros, en horas, en riesgo mitigado), y payback period.

Payback period realista

Los comites desconfian de los ROI inflados, y tienen razon para hacerlo. Un proyecto IT que promete un ROI del 400% en el primer ano probablemente esta ocultando costes o inflando beneficios.

Rangos realistas por tipo de proyecto:

• Automatizacion de procesos: payback 6-18 meses.
• Migracion a cloud: payback 18-36 meses (el primer ano suele ser mas caro por costes de migracion).
• Plataformas de datos/analytics: payback 12-24 meses para use cases definidos, mas largo para capacidades genericas.
• IA aplicada: payback 9-24 meses para use cases concretos (clasificacion, extraccion, routing). Mucho mas largo (o incierto) para proyectos exploratorios.

La honestidad en el payback genera credibilidad. Presentar un rango (“estimamos un payback de 12 a 18 meses bajo estos supuestos”) es mas convincente que un numero magico.

El coste de no hacer nada

Para proyectos de infraestructura y compliance, el argumento mas potente no es el ROI de la inversion sino el coste de la inaccion. Ejemplos concretos:

• Un servidor en end-of-life sin soporte del fabricante: el coste de un incidente de seguridad medio en una pyme europea es de 50.000-200.000 EUR segun ENISA.
• Procesos manuales que consumen 200 horas/mes de personal cualificado: 200h * 35 EUR/h = 84.000 EUR/ano en coste directo, sin contar errores.
• No cumplir NIS2 o DORA antes de la fecha limite: sanciones de hasta 10 millones EUR o 2% de facturacion global.

El coste de no hacer nada casi siempre es mayor que el coste de hacer algo. Pero hay que calcularlo explicitamente para que el comite lo vea.

Errores que hunden propuestas validas

Hemos visto docenas de propuestas presupuestarias de IT rechazadas que eran tecnicamente solidas. Los errores comunes:

Presentar una lista de la compra. “Necesitamos: nueva plataforma cloud (180K), herramienta de BI (60K), renovacion de red (90K), licencias de seguridad (45K).” Sin narrativa, sin priorizacion, sin conexion con los objetivos de la empresa. Esto no es un business case; es un catalogo.

Subestimar el coste total. Incluir las licencias pero olvidar la implementacion, la formacion, la migracion de datos, y el soporte continuo. Un ERP que cuesta 150K en licencias puede costar 400K en total en el primer ano. El comite que descubre costes ocultos despues de aprobar el proyecto pierde confianza para el presupuesto siguiente.

No priorizar. Si todo es prioridad 1, nada es prioridad 1. El comite necesita saber que se pierde si el presupuesto se reduce un 20%. Presentar tres escenarios (minimo, recomendado, optimo) con impacto explicito de cada recorte permite una decision informada.

Ignorar el track record. Si el ano pasado se aprobaron 500K para “transformacion digital” y los resultados fueron difusos, este ano el comite sera esceptico. Antes de pedir mas, demuestra que lo anterior funciono: metricas de adopcion, ahorro validado, satisfaccion de usuarios. No hay mejor argumento para inversion futura que un historial de ejecucion solida.

La propuesta que funciona

Una propuesta presupuestaria IT efectiva tiene una estructura clara:

1. Contexto y alineacion. Objetivos de negocio para 2026 y como la tecnologia los soporta. No mas de media pagina.
2. Estado actual. Donde estamos: indicadores clave de la operacion IT actual (uptime, incidentes, costes, satisfaccion interna). Una pagina.
3. Propuesta por categorias. Obligatorio, mantenimiento, mejora, transformacion. Cada proyecto con coste, beneficio y payback. Dos o tres paginas.
4. Escenarios. Minimo (solo obligatorio + mantenimiento), recomendado, y optimo. Que se pierde en cada recorte.
5. Roadmap de ejecucion. Calendario trimestral. Que se entrega y cuando.
6. Metricas de seguimiento. Como se medira el exito. KPIs concretos, no genéricos.

El documento completo no deberia superar 8-10 paginas. Si necesita mas, es que no esta suficientemente priorizado.

La diferencia entre un presupuesto IT que se aprueba y uno que se recorta rara vez esta en la solidez tecnica. Esta en la claridad con que conecta tecnologia con resultados de negocio, y en la confianza que genera el equipo que lo presenta. Nuestro equipo de consultoria puede ayudarte a construir el business case o a realizar el diagnostico tecnologico que lo sustenta.