El error de personalizar Dynamics sin arquitectura de datos previa

La personalización del CRM comenzó antes de que existiera una arquitectura de datos. Era la consecuencia predecible de un proceso de implementación donde la presión de llegar a una fecha de lanzamiento había comprimido la fase de diseño. Los primeros módulos se configuraron con la información disponible en el momento: los campos que el equipo de ventas pedía, la lógica de procesos que el manager de ventas describía en reuniones, y las integraciones que el equipo de IT consideraba prioritarias. Cada decisión era razonable de forma individual. Sin una arquitectura que las conectara, el resultado fue un sistema que crecía en complejidad sin crecer en coherencia.

El primer síntoma de la ausencia de arquitectura de datos apareció en el mes 6, cuando intentamos construir el primer reporte cruzado entre el módulo de marketing y el módulo de ventas. Los datos que necesitábamos cruzar usaban identificadores diferentes en cada módulo porque habían sido configurados de forma independiente sin un estándar de identificación compartido. Un contacto tenía un ID en marketing, otro en ventas, y no existía ningún campo que actuara como clave de unión entre ambos módulos. El reporte que debería haber tardado 2 horas en construir tardó 3 semanas y requirió trabajo de ingeniería de datos que no estaba en ningún plan de proyecto.

El segundo síntoma fue la inconsistencia de nomenclatura entre módulos. Los sectores industriales estaban clasificados con 12 categorías en el módulo de marketing y con 8 categorías diferentes en el módulo de ventas. Una empresa de "manufactura de alimentos" podía estar clasificada como "Manufactura" en ventas y como "Alimentos y Bebidas" en marketing, lo que hacía imposible cualquier análisis que cruzara datos de los dos módulos sin una tabla de equivalencias construida manualmente.

La solución retrospectiva fue construir la arquitectura que debería haber existido desde el principio. El proceso tomó 4 meses porque implicaba revisar y estandarizar todos los campos de clasificación en todos los módulos, establecer un modelo de datos compartido con identificadores únicos para cada entidad y migrar los datos existentes al nuevo esquema sin interrumpir la operación del sistema. Era el tipo de trabajo técnico que no genera resultados visibles de negocio a corto plazo y que es difícil de priorizar frente a solicitudes de funcionalidades nuevas.

La lección más costosa de esa experiencia fue sobre el costo de omitir la arquitectura de datos en la fase de diseño de un sistema de CRM. Los primeros 4 meses de una implementación son el momento donde las decisiones de arquitectura tienen menor costo porque el sistema todavía no tiene datos reales que migrar ni procesos operativos que interrumpir. Las mismas decisiones tomadas 12 meses después, con datos reales y procesos activos, cuestan entre 5 y 10 veces más en tiempo, recursos y riesgo operativo. La arquitectura de datos no es un lujo del diseño. Es la infraestructura que determina qué puede hacer el sistema en todos los años de su vida útil.