Justificar proyecto de datos ante dirección

La mayoría de proyectos de datos e IA que no se aprueban no lo son porque dirección no quiera innovar. Lo son porque la propuesta no conecta el problema técnico con el problema de negocio que dirección reconoce como suyo. Este artículo explica cómo construir esa conexión de forma que la conversación sobre el proyecto sea productiva desde el primer minuto.

¿Cuál es el error más común al presentar un proyecto de datos?

Empezar por la solución. 'Queremos implementar un data warehouse con dbt y Power BI' no es un business case. Es una lista de tecnologías. Dirección no puede evaluar si eso merece inversión porque no sabe qué problema resuelve ni qué pasará si no se hace. El business case tiene que empezar por el problema, no por la solución.

Estructura de un business case efectivo para datos e IA

1. 1Bloque 1 — El problema actual: describe la situación con datos propios. No 'el reporting es lento' sino 'el cierre mensual requiere X horas de trabajo manual, produce Y versiones distintas del mismo dato y genera Z discusiones en el comité de dirección'. Cuantifica el coste implícito aunque sea aproximado.
2. 2Bloque 2 — La propuesta concreta: alcance claro (qué incluye y qué no), tecnologías brevemente descritas sin jerga, plazo de ejecución y coste. No un presupuesto vago: un rango realista con qué factores lo hacen subir o bajar.
3. 3Bloque 3 — El impacto esperado: qué cambia cuando el proyecto esté en producción. Usa métricas de negocio, no técnicas. No 'latencia < 100ms' sino 'el equipo financiero tiene los datos del mes cerrados el día 3, no el día 10'. Cuantifica si puedes; si no, da rangos razonables.
4. 4Bloque 4 — El coste de no hacer nada: este bloque lo omiten casi todos y es el que más influye en la decisión. Si en 12 meses seguimos igual, ¿qué nos habrá costado? ¿Qué oportunidades habremos perdido? ¿Qué riesgos acumularemos?
5. 5Bloque 5 — El plan de ejecución: hitos, responsables, decisiones que corresponden al cliente. Sin esto parece un proyecto sin aterrizaje.

Cómo cuantificar el impacto cuando no tienes todos los datos

No necesitas datos perfectos para construir un business case. Necesitas datos suficientemente creíbles para que dirección pueda evaluar el orden de magnitud. Algunas aproximaciones prácticas:

• Coste de tiempo manual: calcula las horas/semana dedicadas al proceso × coste/hora del perfil que las hace × 52 semanas. Es un número rough, pero da perspectiva.
• Coste de errores: si el proceso genera errores con cierta frecuencia, estima cuánto cuesta corregir cada error (tiempo, impacto en cliente, reproceso).
• Oportunidad perdida: si el proceso es lento, ¿qué decisiones se retrasan? ¿Cuánto vale decidir una semana antes?
• Benchmarks del sector: si hay datos del sector (por ejemplo, sobre ahorro en automatización de procesos), cítalos con cautela pero úsalos como referencia.

Objeciones habituales de dirección y cómo responderlas

El tamaño correcto para un primer proyecto

La mayoría de proyectos de datos e IA que se aprueban a la primera son proyectos acotados: un proceso, un departamento, un entregable claro. No la transformación digital completa de la empresa. La estrategia correcta es proponer el mínimo suficiente para demostrar valor real, con la puerta abierta a escalar si funciona. Dirección puede aprobar fácilmente un proyecto de 4–6 semanas con resultado verificable. Le cuesta mucho más aprobar un proyecto de 6 meses con impacto incierto.

Estructura de un business case convincente para direccion

Un business case para un proyecto de datos debe responder a tres preguntas en este orden: que problema de negocio resuelve (no que tecnologia usa), cuanto cuesta no resolverlo (el coste de la inaccion), y cual es la inversion necesaria frente al retorno esperado. Si empiezas hablando de Power BI, data warehouse o n8n, pierdes la atencion de direccion en el primer minuto.

• Problema de negocio: los cierres mensuales tardan 5 dias, hay discrepancias entre areas, las decisiones se toman con datos de hace 3 semanas.
• Coste de la inaccion: horas dedicadas a reconciliar datos manualmente, decisiones incorrectas por datos obsoletos, oportunidades perdidas por falta de visibilidad.
• Inversion vs retorno: coste del proyecto, plazo de amortizacion, beneficios tangibles (ahorro de horas) e intangibles (mejor toma de decisiones, menor riesgo).
• Riesgos y mitigacion: que puede salir mal y como se mitiga. Direccion valora que reconozcas los riesgos, no que los ocultes.

Errores que hacen que direccion rechace el proyecto

El error mas frecuente es presentar el proyecto como una mejora tecnologica en vez de como una solucion a un problema de negocio. A direccion no le importa si usas Snowflake o PostgreSQL; le importa si el cierre mensual bajara de 5 dias a 2, o si el equipo comercial tendra datos actualizados en tiempo real en vez de informes semanales.

Otro error es pedir un presupuesto grande sin ofrecer hitos intermedios. Proponer un proyecto de 60.000 euros a 6 meses sin entregables visibles hasta el final genera desconfianza. Es mejor dividir en fases de 2-3 meses con entregables medibles al final de cada una. La primera fase deberia costar menos de 15.000 euros y demostrar valor tangible.

Si te interesa profundizar, en calcular el roi de un proyecto de datos o ia exploramos este tema en detalle.

Para mas contexto, puedes consultar la informe de Gartner sobre datos listos para IA.

Preguntas frecuentes sobre el business case de datos e IA

¿Hay una plantilla estándar de business case para proyectos de datos?

No hay una plantilla universal, pero sí una estructura que funciona: problema + coste implícito + propuesta concreta + impacto esperado + coste de no hacer + plan. Una página o dos slides son suficientes para la primera conversación con dirección.

¿Cuánto ROI puede esperar un proyecto de datos e IA?

Depende del proceso. Proyectos de automatización de procesos repetitivos (reporting, conciliaciones, onboarding) tienen ROI rápido y cuantificable: las horas ahorradas son fáciles de medir. Proyectos de IA predictiva (forecasting, churn) tienen ROI más difuso pero potencialmente mayor, y requieren 2–3 meses de uso antes de que sea estadísticamente medible.

¿Quién debería presentar el business case internamente?

El sponsor interno del proyecto — habitualmente un director de departamento o el CFO/COO. Un proveedor externo puede ayudar a construir el business case, pero quien lo presenta internamente tiene más credibilidad si es alguien de la organización con acceso a los datos reales del problema.