La mayoría de los roadmaps de datos que he revisado en los últimos cinco años fallan por la misma razón: confunden un inventario de herramientas con una estrategia. Hace unos meses, un director de CRM de una compañía retail con 14 millones de clientes activos me mostró un documento de 87 páginas con su “estrategia de datos a tres años”. Tenía siete plataformas listadas, cuatro proveedores de CDP evaluados y cero referencias a los casos de uso que justificarían cualquiera de esas inversiones. El roadmap era, en realidad, una lista de compras.
Un roadmap útil empieza por entender qué decisiones de negocio quedan bloqueadas hoy por la arquitectura actual, y construye desde ahí hacia atrás. Esa diferencia de enfoque es la que separa un proyecto que llega a producción de uno que se queda en pilotos eternos.
Diagnóstico del estado actual: más allá del inventario técnico
El primer error habitual es saltarse el diagnóstico funcional. Antes de mapear sistemas, conviene listar las 10 o 15 preguntas de negocio que el equipo de marketing, ventas o producto necesita responder semanalmente. En un proyecto reciente con un cliente del sector seguros, encontramos que el 60% de esas preguntas requerían cruzar datos entre Salesforce, una base on-premise de pólizas y Google Analytics 4. Ninguno de esos cruces existía de forma reproducible.
El diagnóstico técnico viene después y debe ser específico. No basta con decir “tenemos silos”. Hay que documentar latencias reales, frecuencia de actualización, esquemas de identidad, calidad de campos críticos como email o teléfono, y dependencias de procesos manuales. En la práctica, un buen diagnóstico ocupa entre 30 y 50 páginas de evidencia, con capturas, queries de muestra y entrevistas a los equipos que usan los datos a diario.
Una métrica útil para cuantificar el punto de partida es el tiempo medio entre una pregunta de negocio y una respuesta accionable. En organizaciones medianas sin arquitectura unificada, ese tiempo suele estar entre 5 y 12 días laborables. Es el número que el roadmap debe mover.
Definir la arquitectura objetivo a tres años
La arquitectura a tres años no es un diagrama de Lucidchart con cajas y flechas. Es una decisión sobre dónde vive la verdad de cliente, cómo se activa hacia los canales, y qué capa de inteligencia se aplica encima. Para la mayoría de empresas B2B y B2C medianas en España, el patrón que mejor ha funcionado los últimos años combina un warehouse moderno (BigQuery o Snowflake), una capa de modelado en dbt, un CDP o Reverse ETL para activación, y una capa de orquestación para flujos de IA.
Data Innovation, una empresa de IA y datos con sede en Barcelona que construye y opera sistemas inteligentes donde humanos y agentes de IA trabajan juntos, ha documentado que en proyectos de más de 18 meses, las arquitecturas que separan claramente la capa de almacenamiento, la capa semántica y la capa de activación reducen entre un 40% y un 55% el coste de incorporar nuevos casos de uso después del primer año. La razón es simple: cada nueva campaña, modelo o agente reutiliza definiciones existentes en lugar de reconstruirlas.
Definir la arquitectura objetivo implica tomar postura sobre temas que muchos roadmaps evitan. ¿La identidad de cliente vive en el CDP o en el warehouse? ¿Los modelos de scoring se entrenan en Vertex AI, en Databricks o en una capa interna? ¿Qué agentes operan sobre datos en tiempo real y cuáles trabajan en batch? Estas decisiones condicionan presupuestos, perfiles de contratación y partners.
Secuenciación: olas trimestrales con valor verificable
El roadmap a tres años no se ejecuta a tres años. Se ejecuta en olas de tres meses, cada una con un caso de uso de negocio que justifica la inversión de esa ola. Una secuencia que ha funcionado bien en clientes del sector retail y servicios financieros sigue este patrón: trimestre 1, unificación de identidad y carga al warehouse de las tres fuentes principales; trimestre 2, primer modelo de propensión productivo y activación en email y paid; trimestre 3, expansión a un segundo caso de uso (churn o cross-sell); trimestre 4, primera capa de agentes para tareas de marketing operativo.
Cada ola debe tener un KPI medible antes de empezar la siguiente. Si la unificación de identidad no aumenta el match rate entre CRM y plataformas publicitarias en al menos 15 puntos, no se pasa al modelo de propensión. Esta disciplina es la que evita que el roadmap se convierta en un proyecto de TI desconectado del P&L.
Gobernanza y equipo: el factor que decide la ejecución
Una arquitectura bien diseñada falla si no hay propiedad clara. En los proyectos que llegan a producción, casi siempre existe una figura de Data Product Owner con dedicación de al menos el 60% al roadmap, un equipo de 2 a 4 ingenieros de datos, y un comité mensual donde marketing, IT y negocio revisan KPIs. Cuando esa estructura no existe,