Estrategia de datos: el plan que va antes de comprar la herramienta

Casi todas las empresas que nos piden una estrategia de datos ya han comprado la herramienta. Tienen licencias de una plataforma de BI, un almacén en la nube a medio llenar y tres cuadros de mando que nadie abre desde la demo. Lo que falta no es software: falta acuerdo sobre qué número es el bueno, quién responde de él y en qué orden se va a arreglar el desorden. Eso es una estrategia de datos, y es un documento de negocio, no un diagrama de arquitectura.

Esta guía va de cómo se construye ese acuerdo en una empresa mediana normal, con un ERP viejo, un CRM a medias y mucho Excel. Qué es exactamente una estrategia de datos y qué no lo es, por qué fracasan las que empiezan por la tecnología, cómo se fija la fuente de verdad, cómo se prioriza qué ordenar primero, cómo es un plan de 90 días realista y qué se mide para saber si está funcionando.

¿Qué es una estrategia de datos y qué no es?

Una estrategia de datos es la respuesta escrita a cuatro preguntas: qué decisiones queremos tomar mejor, qué datos hacen falta para tomarlas, en qué estado están hoy y en qué orden vamos a arreglarlos. Cabe en cinco o seis páginas. Si ocupa cuarenta, casi siempre es un catálogo de deseos disfrazado.

Lo que no es:

• No es un diagrama de arquitectura. El dibujo de cajas con flechas es una consecuencia, no un punto de partida. Elegir el almacén antes de saber qué preguntas hay que responder es escoger la carretera antes que el destino.
• No es un inventario de todos tus sistemas. Un inventario exhaustivo tarda meses y envejece en semanas. Basta con mapear los sistemas que tocan las tres o cuatro decisiones que importan.
• No es un plan a tres años. A tres años nadie sabe qué herramientas habrá. Lo útil es un horizonte de un año con un primer trimestre detallado al día.
• No es un proyecto de IA. La IA es un consumidor de datos más, exigente y ruidoso. Si la estrategia no aguanta sin IA, tampoco aguantará con ella. Es la idea que desarrollamos en primero los datos, después la IA.

La prueba del algodón es sencilla: pon el documento delante del director financiero. Si no puede señalar tres decisiones concretas que se van a tomar con menos discusión dentro de seis meses, todavía no es una estrategia. Es un presupuesto de infraestructura buscando justificación.

Una estrategia de datos no se juzga por la elegancia de su arquitectura, sino por cuántas reuniones deja de empezar con «pero ese dato a mí no me sale así».

¿Por qué fracasan las estrategias de datos que empiezan por la herramienta?

Porque resuelven el problema de almacenamiento y dejan intacto el problema de acuerdo. Hemos visto el mismo patrón lo suficiente como para describirlo por fases.

Primero llega la plataforma. Alguien monta el almacén, conecta el ERP y publica un cuadro de mando de ventas. Al mes, comercial dice que la cifra de facturación no coincide con la suya. Se investiga: comercial cuenta el pedido cuando se firma, finanzas cuando se factura, y operaciones cuando se sirve. Ninguno está equivocado. Simplemente nadie decidió cuál de las tres definiciones es la oficial.

A partir de ahí el desenlace es previsible. Cada área vuelve a su Excel «porque el mío sí cuadra», el cuadro de mando queda como decoración y el proyecto se archiva como fracaso tecnológico cuando en realidad fue un fracaso de gobierno. El coste no es solo la licencia: es que la próxima vez que alguien proponga ordenar los datos, la dirección ya tiene un mal recuerdo asociado.

Los cuatro errores que más veces hemos visto repetirse:

• Empezar por el dato más difícil. Márgenes por producto con costes indirectos repartidos suele ser el peor primer proyecto posible. Muchísimo trabajo, resultado discutible y meses sin nada que enseñar.
• Modelarlo todo antes de entregar nada. Seis meses de modelo de datos perfecto sin un solo informe en producción garantiza que el patrocinador pierda interés antes del estreno.
• No nombrar dueños. Un dato sin responsable no se corrige: se comenta. Y los comentarios no cambian el sistema origen.
• Confundir informe con decisión. Publicar el número no cambia nada si nadie tiene la autoridad ni la costumbre de actuar sobre él. Es el mismo mecanismo que explica por qué fracasan los pilotos de IA.

¿Cómo se decide cuál es la fuente de verdad?

La fuente de verdad no es un sistema, es una decisión por cada dato relevante: para el dato X, manda el sistema Y, con esta definición y este responsable. Se documenta en una tabla aburrida que vale más que cualquier diagrama.

| Dato | Sistema que manda | Definición acordada | Responsable | Frecuencia | |---|---|---|---|---| | Cliente | CRM | Entidad con NIF único; las sedes son ubicaciones, no clientes | Dirección comercial | Diaria | | Pedido | ERP | Confirmado cuando existe número de pedido en firme | Operaciones | Diaria | | Ingreso | ERP (facturación) | Fecha de factura emitida, sin IVA | Finanzas | Diaria | | Producto | Maestro de artículos | Código de artículo activo; las variantes cuelgan del padre | Producto | Semanal | | Coste unitario | ERP + costes | Coste estándar del periodo, no el real de cada lote | Control de gestión | Mensual |

Tres reglas prácticas para rellenarla sin bloquearse.

Una sola discusión por dato, con decisor presente. El error clásico es abrir un hilo de correo para acordar qué es un cliente. Convoca cuarenta minutos, con la persona que puede decidir, y sal con la definición escrita aunque no guste a todos. Una definición imperfecta y publicada rinde más que la perfecta y pendiente.

Documenta lo que la definición deja fuera. «Ingreso no incluye pedidos pendientes de servir» evita la mitad de las reclamaciones futuras. Los límites explícitos son el verdadero producto.

Acepta convivir con dos cifras si son legítimas. Ventas firmadas y ventas facturadas son ambas útiles. Lo que no se puede es llamarlas igual. Nombres distintos, definiciones distintas, y en el mismo panel para que nadie sospeche.

Cuando esta tabla existe y se mantiene, ya estás haciendo gobierno del dato sin haber montado un comité. Y si tienes que montarlo, al menos tendrá algo concreto sobre lo que decidir.

¿Cómo priorizar qué datos ordenar primero?

Con dos ejes: valor de la decisión que desbloquea y esfuerzo real de dejarlo limpio. Ordena los candidatos y ataca los de valor alto y esfuerzo medio o bajo. Suena obvio; casi nadie lo hace, porque la conversación suele derivar a qué dato está más sucio, que es una pregunta distinta.

Preguntas que sirven para puntuar cada candidato:

• ¿Qué decisión concreta cambia? Si la respuesta es «tendríamos visibilidad», no puntúa. Si es «dejaríamos de reponer a ojo esta familia de producto», sí.
• ¿Cada cuánto se toma esa decisión? Un dato que informa una decisión semanal vale mucho más que uno para el comité anual.
• ¿Cuánta gente lo recalcula hoy a mano? Ese número es tu ahorro más defendible y el más fácil de medir.
• ¿Está el dato origen o hay que crearlo? Limpiar es caro; capturar algo que nadie registra hoy es mucho más caro y afecta a la operativa.
• ¿Quién se opone? Si el dueño del sistema origen no quiere tocarlo, súmalo al esfuerzo. La resistencia organizativa es una partida de coste, no un detalle.

Un ejemplo típico del orden que sale de este ejercicio en una empresa con distribución: primero clientes y pedidos, porque casi todo cuelga de ahí; después stock, porque desbloquea decisiones semanales de reposición; después márgenes, que es lo que dirección pidió el primer día y es lo que más depende de los dos anteriores. Explicar ese orden con esta lógica evita la sensación de que el equipo de datos hace lo que le apetece.

Si tu ambición a medio plazo incluye previsión o análisis predictivo, añade un criterio más: histórico disponible. Un modelo necesita dos o tres años de datos con la misma definición. Si has cambiado de ERP hace ocho meses, ese caso baja de prioridad por mucho que ilusione.

¿Cómo es un plan de datos de 90 días que se sostiene?

Noventa días dan para dejar una decisión bien resuelta de punta a punta. No para tres. Este es el reparto que usamos y dónde se va el esfuerzo de verdad.

| Fase | Qué se hace | Resultado tangible | |---|---|---| | Semanas 1-2 | Entrevistas con negocio; elegir 1 decisión y 2 métricas | Documento de una página con dueño y línea base | | Semanas 3-4 | Tabla de fuente de verdad de los datos implicados | Definiciones firmadas por sus responsables | | Semanas 4-7 | Ingesta y modelo mínimo; solo lo que alimenta esas métricas | Datos actualizados a diario, sin intervención manual | | Semanas 7-10 | Panel con las 2 métricas y sus cortes; validación con negocio | Cifras que cuadran con la realidad conocida | | Semanas 10-12 | Rutina de uso: quién lo mira, cuándo y qué hace | La decisión se toma con el panel delante | | Semana 13 | Revisión: qué escalar, qué corregir, qué descartar | Siguiente trimestre priorizado con evidencia |

Dos advertencias sobre este calendario. La primera: las semanas 10-12 son las que más se saltan y las únicas imprescindibles. Un panel correcto que nadie ha incorporado a una reunión periódica se muere solo, y morirá con la etiqueta de «el proyecto de datos no sirvió».

La segunda: reserva capacidad para lo que aparezca. En la ingesta siempre sale algo —un campo que se usa para dos cosas, clientes duplicados con distinto NIF, fechas en tres formatos—. Si el plan va al 100 % de ocupación, el primer hallazgo se lo lleva por delante. Un 70 % planificado es más honesto y termina antes.

Sobre el gasto: en este primer trimestre la infraestructura suele ser la partida menor. El coste dominante son las horas de tu gente en definir, validar y adoptar. Presupuestar solo licencias y horas técnicas es la forma más habitual de que el proyecto se quede sin combustible en la semana ocho.

¿Qué roles mínimos necesita una estrategia de datos?

Menos de los que dice el manual, pero ninguno puede quedar vacío. En empresa mediana esto son sombreros, no personas a jornada completa.

• Patrocinador. Alguien de dirección que responda del resultado y desbloquee discusiones entre áreas. Sin este rol, cualquier desacuerdo dura semanas.
• Dueño de dato. Por cada dato crítico, la persona de negocio que decide su definición y responde de su calidad. No es informática: es quien conoce la operativa.
• Perfil técnico de datos. Quien monta la ingesta, el modelo y las validaciones. Puede ser interno o externo, pero debe ser estable: rotar aquí borra el contexto acumulado.
• Analista o traductor. Quien convierte la pregunta de negocio en métrica y explica el resultado sin jerga. Es el rol más infravalorado y el que más determina la adopción.

Con esos cuatro sombreros y una revisión mensual de treinta minutos tienes gobierno suficiente para empezar. Comités, catálogos y políticas formales llegan después, cuando hay algo que gobernar. Montar la burocracia antes que el primer dato limpio es la forma más rápida de agotar la paciencia de la organización.

¿Cómo se mide que la estrategia de datos funciona?

Con indicadores que no dependen de la opinión de nadie. Cuatro sirven para casi todo:

• Tiempo hasta el número. Cuánto se tarda desde que alguien pregunta hasta que hay una cifra fiable. Si pasa de tres días a una hora, la estrategia está funcionando.
• Discrepancias abiertas. Cuántas veces al mes dos áreas presentan cifras distintas del mismo concepto. Debe bajar y acercarse a cero en los datos ya acordados.
• Horas de recálculo manual. Las que tu gente dedica a rehacer informes en Excel. Es el ahorro más tangible y el que mejor se defiende ante dirección.
• Uso real. Usuarios distintos que abren el panel en la semana en que se toma la decisión. Sin uso, todo lo demás es decorado.

Fija la línea base antes de empezar, aunque sea a ojo y por encuesta. Sin ese punto de partida, cualquier mejora parecerá discutible y no podrás justificar el siguiente trimestre. Cuando estos números existen, la conversación sobre qué es business intelligence y qué herramienta comprar se vuelve fácil, porque ya sabes qué tiene que resolver.

Preguntas frecuentes

¿Cuánto tarda una estrategia de datos en dar resultados?

El documento se escribe en dos o tres semanas con entrevistas incluidas. El primer resultado tangible —una decisión que se toma con un dato fiable en vez de con una hoja de cálculo— cabe en un trimestre si se acota a una sola decisión. Los planes que prometen transformar todo el reporting en tres meses no terminan bien.

¿Necesito un almacén de datos para tener una estrategia de datos?

No para tenerla; sí, con frecuencia, para ejecutarla más allá del primer caso. Muchas empresas resuelven su primer trimestre con extracciones ordenadas y un modelo sencillo. El almacén se justifica cuando aparecen varias fuentes que hay que cruzar a diario o histórico que el sistema origen no guarda.

¿Quién debe liderar la estrategia de datos, negocio o tecnología?

Negocio marca las decisiones y las definiciones; tecnología responde de que el dato llegue limpio y a tiempo. Si lidera solo tecnología, salen sistemas correctos que nadie usa; si lidera solo negocio, salen exigencias sin base. El patrocinador debe estar en dirección, no en el departamento de sistemas.

¿Sirve una estrategia de datos si mi empresa es pequeña?

Sí, y ocupa menos. En una empresa de veinte personas puede ser una tabla de fuente de verdad de seis filas y dos métricas acordadas. El valor no está en el tamaño del documento, sino en que exista una definición única para los tres o cuatro números con los que se dirige la empresa.

Si estás a punto de comprar una plataforma de datos y no tienes escrito qué decisiones tiene que mejorar, ese es exactamente el hueco que cubre la auditoría: mirar tus sistemas, tus definiciones y tus reuniones para salir con una tabla de fuente de verdad, un caso priorizado y un plan de 90 días que puedas defender ante dirección. Si prefieres contrastarlo antes en media hora, hablemos.