Presupuestos IT 2026: cómo presentar el business case tecnológico
El presupuesto se decide en octubre
La mayoría de las empresas españolas cierran sus presupuestos para el año siguiente entre octubre y diciembre. Para los responsables de tecnología, esto significa que el business case de IT para 2026 se está presentando ahora. Y la calidad de ese documento determina si los proyectos críticos reciben financiación o se aplazan otro año.
El problema no suele ser la falta de necesidades. Es la forma en que se presentan. Un CTO que llega al comité de dirección con una lista de proyectos tecnológicos y sus costes, sin conectar cada línea con impacto de negocio, pierde antes de empezar.
Benchmarks que dan contexto
Antes de presentar números, necesitas contexto sectorial. Las preguntas que hará 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%. Logística: 3.5-4.5%. Banca: 7-10%. Retail: 2.5-4%. Construcción: 1.5-3%. Servicios profesionales: 5-8%.
- Crecimiento interanual del gasto IT: media estimada +8% para 2026. La IA generativa está inflando la cifra; sin ella, el crecimiento base es del 4-5%.
- Distribución típica: 65-70% run (mantener lo existente), 20-25% grow (mejorar), 10-15% transform (innovar). Las empresas que invierten menos del 10% en transformación están, en la práctica, acumulando deuda tecnológica.
Estos benchmarks no son prescripciones. Una empresa de logística al 3% de gasto IT no necesariamente está mal posicionada; depende de su nivel de automatización y sus objetivos. Pero proporcionan un marco de referencia que el comité de dirección entiende.
El framework de priorización
No todos los proyectos IT compiten en la misma liga. Un framework útil para organizar la propuesta presupuestaria es clasificar las inversiones en cuatro categorías:
Obligatorio (compliance/riesgo). Proyectos que no son opcionales: actualizaciones de seguridad, cumplimiento regulatorio (NIS2, DORA, CSRD digital), renovación de infraestructura end-of-life. No necesitan ROI porque el coste de no hacerlos es cuantificable y mayor. Preséntalos como gestión de riesgo, no como inversión.
Mantenimiento (keep the lights on). Licencias, soporte, actualizaciones de versión, renovación de hardware. Es el 65-70% del presupuesto que todos quisieran reducir pero que sostiene la operación. El argumento no es ROI; es continuidad operativa. El coste de una interrupción de servicio (calcula horas de parada * coste/hora) justifica estas partidas.
Mejora (eficiencia operativa). Automatización de procesos manuales, migración a cloud, integración de sistemas, mejora de herramientas de trabajo. Aquí si hay ROI medible. El truco está en cuantificarlo correctamente.
Transformación (ventaja competitiva). Nuevas capacidades que cambian como la empresa compite: IA aplicada, productos digitales, nuevos canales. El ROI es más incierto pero el coste de oportunidad de no invertir puede ser existencial a medio plazo.
La propuesta presupuestaria debe presentar las cuatro categorías 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 comité
Habla el idioma del CFO
El comité de dirección no aprueba “modernizaciones de stack” ni “reducciones de deuda técnica”. Aprueba inversiones que reducen costes, aumentan ingresos, mitigan riesgos o cumplen obligaciones legales.
Traducción práctica:
- “Migrar a Kubernetes” -> “Reducir costes de infraestructura un 30% (120K EUR/año) y eliminar 14 horas mensuales de tareas manuales de despliegue.”
- “Implementar observabilidad” -> “Reducir el tiempo medio de resolución 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 clasificación del 8% al 0.5%.”
Cada proyecto necesita tres números: coste total de propiedad (3 años), beneficio cuantificado (en euros, en horas, en riesgo mitigado), y payback period.
Payback period realista
Los comités desconfían de los ROI inflados, y tienen razón para hacerlo. Un proyecto IT que promete un ROI del 400% en el primer año probablemente está ocultando costes o inflando beneficios.
Rangos realistas por tipo de proyecto:
- Automatización de procesos: payback 6-18 meses.
- Migración a cloud: payback 18-36 meses (el primer año suele ser más caro por costes de migración).
- Plataformas de datos/analytics: payback 12-24 meses para use cases definidos, más largo para capacidades genéricas.
- IA aplicada: payback 9-24 meses para use cases concretos (clasificación, extracción, routing). Mucho más 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 más convincente que un número mágico.
El coste de no hacer nada
Para proyectos de infraestructura y compliance, el argumento más potente no es el ROI de la inversión sino el coste de la inacción. 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 según ENISA.
- Procesos manuales que consumen 200 horas/mes de personal cualificado: 200h * 35 EUR/h = 84.000 EUR/año en coste directo, sin contar errores.
- No cumplir NIS2 o DORA antes de la fecha límite: sanciones de hasta 10 millones EUR o 2% de facturación global.
El coste de no hacer nada casi siempre es mayor que el coste de hacer algo. Pero hay que calcularlo explícitamente para que el comité lo vea.
Errores que hunden propuestas válidas
Hemos visto docenas de propuestas presupuestarias de IT rechazadas que eran técnicamente sólidas. Los errores comunes:
Presentar una lista de la compra. “Necesitamos: nueva plataforma cloud (180K), herramienta de BI (60K), renovación de red (90K), licencias de seguridad (45K).” Sin narrativa, sin priorización, sin conexión con los objetivos de la empresa. Esto no es un business case; es un catálogo.
Subestimar el coste total. Incluir las licencias pero olvidar la implementación, la formación, la migración de datos, y el soporte continuo. Un ERP que cuesta 150K en licencias puede costar 400K en total en el primer año. El comité que descubre costes ocultos después de aprobar el proyecto pierde confianza para el presupuesto siguiente.
No priorizar. Si todo es prioridad 1, nada es prioridad 1. El comité necesita saber qué se pierde si el presupuesto se reduce un 20%. Presentar tres escenarios (mínimo, recomendado, óptimo) con impacto explícito de cada recorte permite una decisión informada.
Ignorar el track record. Si el año pasado se aprobaron 500K para “transformación digital” y los resultados fueron difusos, este año el comité será escéptico. Antes de pedir más, demuestra que lo anterior funcionó: métricas de adopción, ahorro validado, satisfacción de usuarios. No hay mejor argumento para inversión futura que un historial de ejecución sólida.
La propuesta que funciona
Una propuesta presupuestaria IT efectiva tiene una estructura clara:
- Contexto y alineación. Objetivos de negocio para 2026 y como la tecnología los soporta. No más de media página.
- Estado actual. Dónde estamos: indicadores clave de la operación IT actual (uptime, incidentes, costes, satisfacción interna). Una página.
- Propuesta por categorías. Obligatorio, mantenimiento, mejora, transformación. Cada proyecto con coste, beneficio y payback. Dos o tres páginas.
- Escenarios. Mínimo (solo obligatorio + mantenimiento), recomendado, y óptimo. Qué se pierde en cada recorte.
- Roadmap de ejecución. Calendario trimestral. Qué se entrega y cuándo.
- Métricas de seguimiento. Cómo se medirá el éxito. KPIs concretos, no genéricos.
El documento completo no debería superar 8-10 páginas. Si necesita más, es que no está suficientemente priorizado.
La diferencia entre un presupuesto IT que se aprueba y uno que se recorta rara vez está en la solidez técnica. Está en la claridad con que conecta tecnología con resultados de negocio, y en la confianza que genera el equipo que lo presenta. Nuestro equipo de consultoría puede ayudarte a construir el business case o a realizar el diagnóstico tecnológico que lo sustenta.