La mayoría de los proyectos de datos no muere por fallos técnicos. Muere mucho antes, en una reunión de presupuesto donde alguien pregunta "¿y esto qué retorno trae?" y nadie alrededor de la mesa sabe responder con claridad. El modelo era correcto, el pipeline funcionaba y el informe se veía bien — pero nunca quedó claro qué problema de negocio resolvía, ni cuánto valía resolverlo.
Un business case es el puente entre una buena idea técnica y una decisión de negocio. Es el documento — a menudo una hoja de cálculo y dos o tres diapositivas — que traduce "queremos montar un data warehouse" en algo como "queremos liberar 300 horas al mes del equipo financiero y reducir la rotura de stock en un 8%, con una inversión de X y un retorno esperado en Y meses". Sin esa traducción, un proyecto de datos compite por presupuesto en clara desventaja frente a todo lo demás.
Esta guía muestra cómo construir un business case sólido para un proyecto de datos: partir del problema correcto, cuantificar valor y coste sin inventar números, gestionar la incertidumbre con honestidad y presentarlo todo a quien decide. No es un ejercicio de marketing interno. Bien hecho, es una disciplina que mejora el propio proyecto, porque obliga a aclarar qué se quiere cambiar y cómo se sabrá que funcionó.
Qué es, y qué no es, un business case
Un business case responde a tres preguntas simples: qué problema vamos a resolver, qué cuesta resolverlo y qué ganamos con ello. Todo lo demás es accesorio. No es un plan de proyecto detallado, no es una arquitectura técnica y no es un documento de requisitos — esos vienen después y para otra audiencia.
El error más común es confundir el business case con la descripción de la solución. Quien aprueba el presupuesto rara vez quiere saber si vas a usar Snowflake o BigQuery, si el modelo es en estrella o en copo de nieve, o qué herramienta de ETL va en medio. Quiere saber si el dinero invertido vuelve, en qué plazo y con qué grado de confianza. El business case habla el idioma de quien firma el cheque, no el de quien escribe el código.
Un buen business case también es honesto sobre lo que no sabe. Asume supuestos explícitos, muestra el rango probable de resultados y no promete una precisión que los datos de partida no permiten. Esa honestidad es lo que lo hace creíble la segunda y la tercera vez que lo presentas.
Empieza por el problema, no por la tecnología
Muchos proyectos de datos nacen al revés: alguien vio la demostración de una herramienta, se entusiasmó y solo después buscó un problema donde encajarla. Un business case fuerte invierte ese orden. Parte de un dolor concreto del negocio — un informe que tarda tres días en cerrarse, una decisión de compra tomada a ciegas, clientes que se van sin que nadie lo note a tiempo — y solo después pregunta qué datos y qué capacidades resuelven ese dolor.
Una buena forma de comprobar si estás empezando por el lado correcto es escribir el problema en una frase que no contenga ninguna palabra técnica. "El equipo comercial no sabe qué clientes están en riesgo de irse hasta que ya es tarde." Si puedes describirlo así, tienes un problema de negocio. Si solo puedes describir la solución ("queremos un modelo de churn"), sigues pensando como técnico y no como quien va a pagar la factura.
Cuantificar el valor en tres frentes
El valor de un proyecto de datos casi siempre cae en una de tres categorías. Vale la pena separarlas porque cada una se estima de forma distinta y convence a públicos distintos:
- Aumento de ingresos: más ventas, mejor conversión, menos clientes perdidos, precios más afinados. Suele ser el número más entusiasmante y también el más incierto, por depender del comportamiento del mercado.
- Reducción de costes: horas de trabajo manual liberadas, menos errores que corregir, procesos más rápidos, infraestructura consolidada. Es el valor más fácil de defender, porque depende sobre todo de nosotros.
- Reducción de riesgo: menos roturas de stock, detección de fraude, cumplimiento regulatorio, decisiones menos expuestas al azar. Es el más difícil de poner en euros, pero a menudo el más importante.
Para cada frente, busca un número ancla que ya exista en la organización. Si el equipo financiero pasa tres días al mes consolidando informes a mano, esas son horas con un coste conocido. Si la rotura de stock media es del 5% y cada punto porcentual vale una cantidad conocida en ventas perdidas, tienes la base para una estimación defendible. El objetivo no es la precisión al céntimo; es un orden de magnitud que resista preguntas.
Estimar el coste total, no solo las licencias
El lado de los costes es donde los business cases más pecan de optimismo. Es tentador sumar solo el precio de las licencias de software y presentarlo como la inversión. En realidad, el coste total de propiedad incluye mucho más: el tiempo de las personas que construyen y mantienen la solución, la migración y limpieza de datos, la formación de quien la va a usar, la integración con los sistemas existentes y el coste de mantenimiento en los años siguientes.
Una regla prudente es que la construcción inicial es solo una fracción del coste a lo largo de la vida del proyecto. Un pipeline o un informe no es un activo que se compra y se olvida; es algo que necesita mantenerse, corregirse y adaptarse a medida que los datos y el negocio cambian. Incluir ese coste recurrente desde el principio evita la conversación incómoda, un año después, sobre por qué "el proyecto que ya estaba hecho" sigue consumiendo recursos.
El escenario base: el coste de no hacer nada
Todo business case necesita un punto de comparación, y el más honesto es el escenario en el que no se hace el proyecto. ¿Qué pasa si seguimos como estamos? Muchas veces la respuesta no es "todo sigue igual" — es una degradación lenta: más horas gastadas, más errores, más decisiones malas, una desventaja competitiva que se acumula.
Hacer visible ese coste es la mitad de la persuasión. Cuando quien decide se da cuenta de que la inacción también tiene un precio — uno que ya está pagando, de forma difusa, todos los meses — la pregunta deja de ser "¿vale la pena gastar esto?" y pasa a ser "¿vale la pena seguir perdiendo aquello?". Es un cambio de enfoque que cambia decisiones.
Supuestos, incertidumbre y sensibilidad
Ninguna estimación de valor futuro es segura, y fingir que lo es destruye credibilidad. En lugar de presentar un número único, presenta un rango y haz explícitos los supuestos que lo sostienen. "Si conseguimos reducir la rotura entre 3 y 6 puntos porcentuales, el retorno anual se sitúa entre A y B." Esto muestra madurez y te protege cuando la realidad caiga en cualquier punto de ese rango.
El análisis de sensibilidad lleva esto un paso más allá: identifica cuáles son los dos o tres supuestos que más mueven el resultado. Si el retorno depende sobre todo de la tasa de adopción de la herramienta por parte del equipo, entonces ese es el verdadero riesgo del proyecto — y el business case debe decirlo y proponer cómo mitigarlo, por ejemplo con formación y acompañamiento. Discutir el riesgo abiertamente es señal de fuerza, no de debilidad.
Fasear: probar valor antes de escalar
Un business case es más fácil de aprobar cuando no pide todo de una vez. Dividir la iniciativa en fases — una prueba de concepto enfocada, luego un piloto con usuarios reales, solo después la expansión — reduce el riesgo percibido y crea puntos de decisión. Cada fase produce aprendizaje y resultados que financian la confianza para la siguiente.
Este faseado también protege a la organización. Si la primera fase no entrega lo que prometía, se para con una pérdida pequeña en lugar de descubrir el problema al final de una inversión grande. Quien decide agradece saber que hay una salida en cada punto. Un plan con hitos claros y criterios de "continuar o parar" es casi siempre más convincente que una única petición del presupuesto total.
Cómo presentarlo a quien decide
El mejor análisis del mundo no convence si se comunica mal. Empieza por la conclusión — el problema, el valor esperado, la inversión y el plazo — en una página. Quien decide debe poder captar la esencia en dos minutos y solo después bajar al detalle si quiere. Enterrar el resultado al final de veinte diapositivas es el camino más rápido hacia un "vamos a pensarlo".
Adapta el lenguaje a la audiencia. Un director financiero quiere ver retorno, plazo de recuperación y supuestos. Un responsable de operaciones quiere entender el impacto en el día a día del equipo. Un miembro del consejo quiere el encuadre estratégico y el riesgo. El mismo business case puede tener que contarse de tres formas — los números no cambian, el ángulo sí.
Errores comunes que hunden un business case
Hay un puñado de errores que se repiten. El primero es prometer de más: cifras de retorno que nadie cree minan la confianza en todo lo demás. El segundo es vender tecnología en lugar de resultados, dejando a quien decide sin entender qué problema suyo se resuelve. El tercero es ignorar los costes de mantenimiento y adopción, creando una sorpresa desagradable más adelante.
Un cuarto error, más sutil, es no definir de entrada cómo se va a medir el éxito. Si el business case promete reducir horas de trabajo o aumentar la conversión, tiene que haber forma de comprobar, meses después, si eso ocurrió. Sin esa métrica acordada de antemano, el siguiente business case parte de una posición más débil, porque no hay prueba de que el anterior cumpliera.
Mini-caso: de la intuición a la decisión
Considera una empresa de retail de tamaño medio que convivía con roturas de stock frecuentes en sus productos más vendidos. La percepción interna era que "esto nos cuesta ventas", pero nadie había puesto un número al problema. El equipo de datos propuso un proyecto de previsión de demanda, pero la primera versión de la petición — centrada en la tecnología — no pasó el comité de presupuesto.
Reformularon el business case alrededor del problema. Estimaron que la rotura media rondaba el 6% en las referencias de cabecera y que cada punto porcentual valía una cantidad conocida en ventas perdidas al mes. Del lado de los costes, incluyeron no solo la herramienta, sino el tiempo de dos personas durante tres meses y el mantenimiento anual. Propusieron una primera fase limitada a una categoría de productos, con un criterio claro: si la rotura no bajaba al menos dos puntos en tres meses, el proyecto se paraba.
La fase piloto redujo la rotura en esa categoría de cerca del 6% a alrededor del 3,5%, un resultado dentro del rango prometido. Con ese número real en la mano, la expansión al resto de categorías se aprobó casi sin discusión. Lo que cambió no fue la tecnología — fue el encuadre y la prueba de valor a pequeña escala.
En la práctica
Un business case para datos no está para adornar un proyecto; está para obligarlo a ser honesto consigo mismo antes de pedir dinero. Empieza por el problema de negocio, cuantifica valor y coste con números ancla reales, muestra el coste de no hacer nada, sé transparente sobre la incertidumbre y propón un camino faseado con puntos de decisión. Acuerda de entrada cómo vas a medir el éxito, para que la siguiente petición parta de terreno sólido.
Hecho así, el business case deja de ser una formalidad y pasa a ser una herramienta de gestión. Alinea al equipo técnico y al negocio en torno al mismo objetivo, filtra las ideas que no se sostienen y da a los buenos proyectos el lenguaje que necesitan para competir por presupuesto. En un contexto en el que casi todas las áreas piden inversión en datos, es esa claridad — y no la sofisticación técnica — la que suele separar los proyectos que avanzan de los que se quedan para siempre "en análisis".
