Las empresas suelen detectar un problema de integración cuando, en realidad, el problema es de modelo de datos. Hay pedidos duplicados, clientes con nombres distintos en cada sistema, estados que no cuadran entre ERP y ecommerce, o informes que requieren una revisión manual antes de poder confiar en ellos. La reacción habitual es añadir otra integración o crear una exportación más. Pero cuando cada sistema define el dato a su manera, el problema se desplaza, no se resuelve.
Si cada sistema interpreta el mismo dato de forma distinta, la empresa no tiene integración: tiene versiones incompatibles de la realidad.
Un modelo de datos compartido no significa centralizar todo en una única base de datos ni imponer un monolito tecnológico. Significa acordar qué entidades son comunes, cuál es su significado y quién es responsable de cada cambio. Para una pyme, esto puede ser tan concreto como definir qué es un cliente, un pedido, una devolución, un producto o una factura. Sin esa definición, cada proyecto nuevo termina creando su propia traducción entre sistemas.
Por qué las integraciones no bastan cuando el negocio crece
Las integraciones resuelven el transporte de información. El modelo de datos resuelve su significado. Esa diferencia parece teórica, pero en operación diaria se nota enseguida. Un ERP puede considerar que un pedido está confirmado cuando se ha reservado stock. Un ecommerce puede dar por vendido un pedido en el momento del pago. Atención al cliente puede querer verlo como pendiente hasta que salga del almacén. Todos los sistemas están “conectados”, pero ninguno habla exactamente el mismo idioma.
Cuando el negocio crece, también crecen las excepciones. Aparecen nuevos canales, nuevas reglas de precios, lotes, suscripciones, devoluciones parciales, pedidos internacionales o flujos manuales para casos especiales. Si la empresa solo piensa en integraciones punto a punto, cada nuevo caso añade una excepción más. El coste no está solo en desarrollar, sino en mantener coherencia cuando cambian procesos, catálogos o responsabilidades.
Un síntoma muy común es el “dato de referencia disputado”. El mismo cliente existe en CRM, ERP y plataforma ecommerce, pero no con la misma estructura ni con el mismo identificador. Lo mismo ocurre con productos, almacenes o tarifas. Entonces los equipos dejan de confiar en el sistema y recurren a hojas de cálculo, correos o validaciones manuales. A corto plazo parece una solución; a medio plazo, crea una operación lenta y frágil.
Qué debe incluir un modelo de datos compartido
El error más habitual es querer modelar absolutamente todo desde el principio. Eso suele retrasar el proyecto y aumentar la resistencia interna. Es mejor empezar por las entidades que condicionan más la operación y los reportes. En la mayoría de empresas, suelen ser cliente, producto, pedido, factura, envío, stock y devolución.
Para cada entidad conviene definir cuatro cosas:
- Nombre y significado de negocio: por ejemplo, qué diferencia un pedido confirmado de uno creado o de uno preparado.
- Identificador único: qué campo o combinación de campos permite reconocer la entidad en todos los sistemas.
- Sistema de referencia: cuál es la fuente principal cuando hay conflicto.
- Eventos o estados permitidos: qué transiciones son válidas y cuáles deben bloquearse o revisarse.
También conviene documentar los datos que no deben duplicarse. Un ejemplo típico es la dirección fiscal del cliente, que a veces se copia en varios sistemas y luego se actualiza en algunos sí y en otros no. Otro caso frecuente es el catálogo de productos: si comercio, ventas y operaciones editan descripciones, unidades o atributos sin una regla común, el resultado es incoherente.
Un modelo compartido no tiene por qué ser rígido. Puede convivir con extensiones locales por canal o por unidad de negocio. La clave es que esas extensiones no rompan el núcleo común. Si un canal necesita campos específicos, se pueden añadir como atributos complementarios, pero sin redefinir la entidad base.
Cómo pasar de sistemas aislados a una base común sin detener la operación
La transición debe hacerse por etapas. Intentar rediseñar todos los sistemas a la vez suele generar riesgo operativo y fatiga en los equipos. Un enfoque más realista empieza por mapear dónde se producen las discrepancias más caras: pedidos, clientes, inventario, facturación o reporting.
Un buen primer paso es construir un inventario de fuentes de datos. No hace falta que sea complejo: basta con listar qué sistema crea cada dato, cuál lo modifica, dónde se consume y qué ocurre si falta o llega tarde. Ese mapa suele revelar que algunos datos se generan en demasiados sitios y otros no tienen propietario claro.
Después se recomienda definir un flujo maestro por entidad. Por ejemplo, el ERP puede ser la referencia para facturas y stock; el ecommerce para estados de checkout; el CRM para segmentos o relaciones comerciales. Lo importante no es que todos los datos nazcan en un mismo sistema, sino que la empresa sepa dónde vive la verdad operativa de cada dato.
A partir de ahí, las integraciones se diseñan para sincronizar, no para reinterpretar. Esto implica validar formatos, estados y reglas antes de enviar datos a otros sistemas. También exige registrar errores de forma utilizable: no basta con que una integración “falle”; hay que saber qué registro falló, por qué y quién debe corregirlo.
En esta fase suele ser útil introducir una capa de normalización, ya sea mediante APIs, colas o un servicio de datos intermedio. Su función no es añadir complejidad, sino aislar cambios. Si mañana cambia la estructura del ecommerce, la empresa no debería tener que rehacer todas las conexiones aguas abajo.
Señales de que ya es momento de invertir en un modelo compartido
Hay indicadores bastante claros. El primero es el tiempo que el equipo dedica a reconciliar datos entre sistemas. Si cada cierre de mes, cada campaña o cada revisión comercial requiere horas de comprobación manual, el coste ya es estructural.
El segundo indicador es la inconsistencia en decisiones. Cuando ventas, operaciones y administración trabajan con cifras distintas, no solo hay un problema de informes; hay un problema de gobierno del dato. En ese escenario, cada área acaba defendiendo su propia versión y la conversación se vuelve política en lugar de operativa.
El tercer indicador es la dependencia de personas concretas. Si solo una o dos personas saben cómo encajan realmente los datos entre sistemas, la empresa está expuesta. El conocimiento crítico no debería vivir en una hoja de cálculo personal ni en la memoria de un técnico.
También conviene mirar el coste de los cambios pequeños. Si añadir un nuevo canal, una nueva tarifa o una nueva regla de negocio obliga a tocar cinco sistemas y revisar diez excepciones, el modelo actual ya está penalizando el crecimiento.
Un modelo de datos compartido no es un proyecto de moda ni una capa abstracta para consultoría. Es una forma de reducir fricción operativa y de hacer que las integraciones sean sostenibles. Para muchas pymes, el momento de abordarlo llega antes de lo que parece: cuando los sistemas ya funcionan, pero la empresa empieza a operar más despacio de lo que necesita. En ese punto, en Codefuente solemos ayudar a ordenar el dato antes de seguir añadiendo conexiones.