En este artículo
Una empresa de distribución con 80 empleados invirtió 40.000€ en un proyecto de Business Intelligence. Nueve meses después, los dashboards estaban construidos, el proveedor había entregado todo lo acordado en el contrato, y nadie en la empresa los usaba. El director general seguía pidiendo el informe de ventas en Excel al controller los lunes. El proyecto se consideró un fracaso.
¿Qué salió mal? No la tecnología — Power BI funcionaba perfectamente. No el proveedor — había entregado exactamente lo que le pidieron. Lo que falló fue lo que nadie había preguntado antes de empezar: ¿qué problema estamos resolviendo exactamente? ¿quién va a usar esto en el día a día? ¿quién dentro de la empresa es el responsable de que esto funcione? ¿cuánto tiempo va a dedicar el equipo a validar los datos y a formarse?
Esas preguntas no son técnicas. Son organizativas. Y son las que determinan si un proyecto de datos genera valor o se convierte en un gasto sin retorno.
Hay un dato que se repite en todos los estudios sobre adopción de datos en empresas: el 70% de los proyectos de datos no generan el valor esperado. Setenta por ciento. Más de dos de cada tres.
En nuestra experiencia trabajando con PYMEs, la causa principal rara vez es técnica. Las herramientas de BI y analítica actuales son maduras, bien documentadas y razonablemente fáciles de implementar si sabes lo que haces. El problema es casi siempre organizativo: falta de preparación antes de empezar.
La herramienta perfecta implementada en el entorno equivocado produce resultados mediocres. Un Ferrari no sirve de nada si no sabes conducir y la carretera no está asfaltada. En datos, el "saber conducir" es tener las preguntas de negocio claras, y el "asfalto" es tener los datos ordenados y a las personas organizadas. Sin eso, la herramienta es irrelevante.
Lo que hace que un proyecto de datos funcione no se decide durante el proyecto — se decide antes de que empiece.
No el responsable de IT que le interesa el tema. No el analista que quiere aprender Power BI. El sponsor tiene que ser alguien de C-level o gerencia general con tres características concretas: puede priorizar recursos cuando hay conflicto de agenda, puede resolver bloqueos entre departamentos cuando el de operaciones no quiere compartir datos con el de finanzas, y puede comunicar al resto de la organización por qué el proyecto importa.
Sin este sponsor, el proyecto muere en el primer conflicto de prioridades. Y habrá conflictos: siempre los hay. "El ERP está en proceso de migración, mejor esperamos." "El controller está con el cierre del año, que te llame en enero." "IT tiene prioridades más urgentes este mes." Cada uno de esos bloqueos, sin un sponsor con autoridad para desatascarlo, se convierte en un proyecto pausado indefinidamente.
El sponsor no necesita saber nada de datos. Necesita creer que el proyecto vale la pena y tener la autoridad para protegerlo.
"Quiero tener todos mis datos en un dashboard" no es una pregunta de negocio. Es una aspiración vaga que puede significar cualquier cosa. "Necesito saber, actualizado cada semana, qué clientes han reducido su volumen de compra más de un 20% respecto al mismo período del año anterior, para que el equipo comercial pueda llamarles antes de que se vayan" — eso sí es una pregunta de negocio. Tiene un destinatario claro, una frecuencia, un umbral y una acción asociada.
Antes de empezar cualquier proyecto de datos, identifica 3-5 preguntas que tu empresa no puede responder hoy, que si pudieras responder cambiarían decisiones reales. El ejercicio parece sencillo pero normalmente tarda un par de sesiones: hay que separar lo que la gente dice que necesita de lo que realmente necesita para tomar mejores decisiones.
Estas preguntas son el norte del proyecto. Todo lo que se construya — arquitectura, modelos, dashboards — se mide contra ellas. Si al final del proyecto puedes responderlas con datos fiables y actualizados, el proyecto fue un éxito. Si no, no lo fue.
¿Qué sistemas tiene tu empresa? ¿ERP? ¿CRM? ¿Gestión de almacén separada? ¿Facturación en la nube? ¿El Excel del controller que nadie toca porque "solo él sabe cómo funciona"? No necesitas documentarlo todo con pelos y señales — necesitas saber qué existe y dónde está.
Este inventario, que parece una trivialidad, evita la sorpresa que hemos visto en múltiples proyectos: descubrir a mitad de la implementación que el ERP tiene las tablas de clientes y pedidos en un formato que nadie documentó jamás, que el CRM tiene registros duplicados porque hubo una migración hace tres años que nadie validó, o que los datos de logística están en un sistema legado al que el proveedor ya no da soporte y del que nadie tiene las credenciales de acceso.
Cada una de esas sorpresas añade semanas al proyecto y frustración a todas las partes. Con un inventario básico hecho antes de empezar, el proveedor puede evaluar la complejidad real de las integraciones y el cliente puede tener expectativas de plazo realistas.
Un proyecto de datos no es instalar una aplicación. No es un proceso en el que el proveedor llega, hace su trabajo y se va mientras la empresa sigue con sus cosas. Requiere tiempo y dedicación de personas de tu empresa, especialmente en las primeras semanas.
¿Cuánto? Típicamente 2-4 horas semanales de un interlocutor durante los primeros 3 meses. Reuniones para definir requisitos ("¿el 'cliente activo' incluye los que compraron con un distribuidor o solo los directos?"), sesiones de validación de datos ("estos números del marzo del año pasado no cuadran con lo que recuerdo — ¿hay algún problema en el pipeline?"), revisiones de prototipos, formación para los usuarios finales.
Las empresas que no planifican esto — que piensan que el proyecto de datos es "cosa del proveedor" — acaban en el cuello de botella más común: el proveedor construido y esperando respuesta durante semanas porque la persona que tiene que validar los datos está con otras prioridades. Ese tiempo de espera es tiempo de proyecto facturado o perdido, según el modelo, y siempre alarga los plazos y tensiona la relación.
No necesita ser un técnico. No necesita saber qué es un modelo semántico ni escribir DAX. Necesita tres cosas: conocer bien el negocio (saber si los números que ve en el prototipo tienen sentido), tener acceso a los stakeholders clave de cada departamento, y tiempo parcialmente dedicado al proyecto durante la fase de implementación.
Este interlocutor es el puente entre el proveedor y el negocio. Valida si los datos tienen sentido ("este 12% de margen en esta línea de producto me parece bajo, tenemos que revisar cómo está calculado"), conecta al proveedor con las personas que necesita entrevistar para entender los procesos, y es la persona que lidera la adopción interna cuando el proyecto entra en producción.
Sin interlocutor, el proveedor trabaja en el vacío. Los dashboards pueden ser técnicamente correctos pero completamente desalineados con cómo el negocio interpreta la realidad. La adopción falla porque nadie dentro ha estado implicado y nadie se siente dueño de la solución.
Antes de firmar con cualquier proveedor, hazte estas preguntas. Si llegas al final sin ningún STOP, estás listo.
Si llegas a algún STOP, no es una señal de que el proyecto no va a funcionar nunca. Es una señal de que hay trabajo previo que hacer. Ese trabajo previo es, literalmente, la diferencia entre el 30% de proyectos que generan valor y el 70% que no lo generan.
Hay frases que, cuando las escuchamos en una primera reunión con un cliente potencial, nos indican que hay trabajo previo por hacer antes de empezar:
"Yo no sé de datos, que se encargue IT." Esta frase significa que no hay sponsor directivo. IT puede gestionar la infraestructura, pero no puede liderar un proyecto que necesita implicación de negocio. Solución: involucrar a dirección en la definición de los casos de uso antes de arrancar.
"El ERP es la fuente de verdad, pero el controller tiene su propia Excel con los datos reales." Señal de que no hay fuente única de verdad definida y de que hay desconfianza en los sistemas. Solución: como parte de la preparación, decidir qué sistema es la fuente oficial de cada tipo de dato — aunque esa decisión sea incómoda.
"Primero espera que terminemos el año, en enero empezamos." Enero llega y aparece otra razón para esperar. Este patrón indica falta de priorización real. Solución: si el proyecto no puede competir con las prioridades actuales, es mejor ser honesto sobre eso antes de firmar que comprometerse y no cumplir.
"Vosotros hacéis todo, nosotros solo usamos el resultado." Expectativa de que el proveedor hace el 100% del trabajo sin implicación interna. No es un modelo que funcione en datos: la validación de negocio, la definición de requisitos y la adopción requieren implicación interna sí o sí. Solución: alinear expectativas de esfuerzo antes de firmar el contrato.
El Data Discovery es una auditoría de 2 semanas que hace precisamente el trabajo previo que hemos descrito. No es un proyecto de datos — es la preparación para un proyecto de datos.
En esas 2 semanas inventariamos tus fuentes de datos (Ingrediente 3), trabajamos contigo para formular las 3-5 preguntas de negocio que el proyecto debe responder (Ingrediente 2), definimos los roles y responsabilidades internas (Ingrediente 5) y evaluamos la calidad y disponibilidad de los datos para los casos de uso identificados.
Al final de las 2 semanas tienes: un inventario de datos documentado, las preguntas de negocio formuladas con precisión, una evaluación de la brecha entre el estado actual de los datos y lo que necesitas, y una propuesta de proyecto con plazos, hitos y entregables concretos.
Lo que a muchas empresas les lleva 3-4 meses preparar por su cuenta — porque nadie tiene el tiempo ni el método para hacerlo — queda hecho en 2 semanas. Y el proyecto que viene después tiene una probabilidad de éxito radicalmente mayor porque arranca con el fundamento correcto.
¿No sabes si tu empresa está lista para un proyecto de datos? Nuestro Data Discovery te lo dice en 2 semanas — y si no estás listo, te dice exactamente qué falta.
// escrito por
Director de 480 Analytics
En 480 Analytics, la unidad de datos de Cuatroochenta, ayuda a empresas a ordenar y explotar sus datos con Power BI, Microsoft Fabric e IA. Escribe sobre lo que aprende por el camino.
Una estrategia de datos no son 200 páginas: es traducir el objetivo de negocio al dashboard, definiendo qué preguntas responder antes de elegir herramienta.
Cuando tres áreas tienen tres versiones del mismo dato, tienes un problema de gobernanza. Qué es, qué pasa si la ignoras y cómo implementarla sin liarte.
No va de cifras grandes: es responder con evidencia preguntas que hoy respondes con intuición. La definición corta y cómo saber si ya puedes arrancar.
Te lo cuantificamos. Empezamos por descubrir y ordenar tus datos, y los convertimos en decisiones — empezando por el reporting financiero (FP&A).