Agente de master data: registros limpios en ERP y CRM

Casi todas las empresas mid-market con las que trabajamos han hecho alguna limpieza de datos. Alguien dedicó seis semanas a fusionar clientes duplicados, normalizar descripciones de artículos y corregir datos bancarios de proveedores. Funcionó. Y en dos o tres trimestres el conjunto de datos había vuelto a degradarse, porque nada había cambiado en la forma en que se crean y mantienen los registros.

Ésta es la característica definitoria del master data —los datos maestros de la empresa—: no es un proyecto con un estado final, es una condición continua. Los registros los crean cada día personas presionadas por el tiempo que están intentando hacer otra cosa: registrar un pedido, lanzar una compra, anotar un lead. Cada uno de esos momentos es una oportunidad para un duplicado, un identificador fiscal mal formado, una unidad de medida inconsistente. El ritmo de creación es constante, así que cualquier solución que no sea también constante pierde.

Y eso es precisamente lo que hace que la custodia de datos encaje bien con un agente. No porque detectar duplicados sea técnicamente difícil, sino porque el trabajo es interminable, poco lucido y siempre lo primero que se desplaza cuando una persona tiene algo más urgente que hacer.

Este artículo trata del agente y del modelo de custodia continua. La cuestión previa —qué es realmente un cliente y qué sistema es propietario de qué campo— se aborda por separado en Un cliente, dos sistemas, y el agente que se describe aquí depende de que esas decisiones ya estén tomadas.

Por qué esto importa

La calidad del master data es el sustrato sobre el que funciona todo lo demás, así que sus fallos aparecen como problemas de otros. La previsión del equipo comercial no es fiable. Compras no puede ver el gasto consolidado por proveedor. El almacén prepara el artículo equivocado porque dos registros describen lo mismo de forma distinta. Finanzas no puede calcular la rentabilidad por cliente. Cada uno de estos casos se investiga como un problema independiente y todos se remontan a la misma causa.

Los costes más fáciles de cuantificar suelen ser los menos importantes. Los registros de proveedor duplicados son un vector real de fraude en pagos: un cambio fraudulento de datos bancarios es materialmente más difícil de detectar cuando existen tres registros del mismo proveedor. Los datos de artículo inconsistentes provocan inexactitud de inventario, que provoca tanto roturas de stock como saneamientos. Y bajo el RGPD, una solicitud de supresión o de acceso no puede atenderse de forma fiable si no puede afirmar con seguridad qué registros se refieren a la misma persona.

Hay además un efecto acumulativo. Cada integración, cada informe, cada automatización construida sobre un master data deficiente hereda el problema y añade su propia lógica para sortearlo. Dos años de eso producen un parque de sistemas en el que nadie puede explicar por qué dos informes no coinciden, y la respuesta siempre es la misma.

De un vistazo: qué vigila el agente y qué puede decidir

La fila de los datos bancarios de proveedor es la que hay que interiorizar. Un agente que puede actualizar los datos de pago de un proveedor es un agente al que se puede manipular para redirigir sus pagos. Esa autoridad no debería existir, por conveniente que resultara.

Qué funciona y sobre qué hay que ser honesto

Qué funciona:

Prevención en el momento de la creación, antes que detección posterior. Un agente que avisa a un comercial mientras teclea de que ya existe una cuenta similar evita un duplicado a coste casi nulo. Detectar ese mismo duplicado una semana más tarde cuesta varios minutos a un responsable de datos y una decisión de fusión. Reparta su esfuerzo en consecuencia: la mayoría de las implantaciones lo hacen al revés.

Una banda de confianza con tres zonas. Por encima del umbral superior, fusionar automáticamente con pista de auditoría. Por debajo del umbral inferior, ignorar. Entre ambos, derivar a un responsable de datos. La banda intermedia es donde debe concentrarse el esfuerzo de diseño, y su anchura debería reducirse a medida que el agente acumule histórico de resoluciones.

Reversibilidad en cada acción automatizada. Cada fusión, normalización y sobrescritura debe ser reversible individualmente y conservar el estado anterior. Esto es lo que hace aceptable la fusión automatizada para los auditores y para las personas cuyos registros se están modificando, y es lo que permite ir estrechando umbrales conservadores con el tiempo.

Un responsable de datos con nombre por dominio. Los datos de cliente, artículo y proveedor necesitan un propietario: una persona, no un comité. El agente hace el trabajo; el responsable decide los casos ambiguos y responde por la métrica de calidad. Los despliegues sin un responsable con nombre acumulan una cola desatendida y fracasan en silencio.

La divergencia como métrica visible. Número de registros divergentes, duplicados detectados, tiempo hasta la resolución, registros creados sin validación. Cuando esto está en un dashboard del que alguien responde, el comportamiento cambia aguas arriba, y eso hace más por la calidad del dato que cualquier cantidad de limpieza aguas abajo.

Sobre qué hay que ser honesto:

El agente no puede arreglar un modelo de datos indefinido. Si no hay una respuesta acordada a si un grupo y sus filiales son un cliente o cinco, el agente aplicará esa ambigüedad de forma consistente y a escala. El trabajo de definición va primero y no se puede automatizar.

La coincidencia difusa produce falsos positivos y falsos negativos, de forma permanente. No hay umbral que elimine ambos. Está eligiendo qué error prefiere, y en master data la preferencia correcta es casi siempre tolerar duplicados antes que arriesgarse a fusiones erróneas: un duplicado es una molestia, una fusión errónea puede poner las transacciones de un cliente en la cuenta de otro.

Un backlog hay que limpiarlo aparte, y es la parte cara. El agente mantiene limpio un conjunto de datos limpio. No limpia con eficiencia uno sucio, porque un gran backlog histórico está formado sobre todo por casos ambiguos que requieren juicio humano. Presupueste la limpieza del backlog como una línea de trabajo propia.

Los datos de artículo son mucho más difíciles que los de cliente. Los clientes tienen identificador fiscal: una clave de coincidencia fuerte y casi única. Los artículos normalmente no. Emparejar artículos depende de descripciones, especificaciones y códigos internos aplicados de forma inconsistente, y la deduplicación automatizada de artículos es proporcionalmente menos fiable y necesita una banda de revisión humana más amplia.

Parte de la divergencia es legítima. Que la dirección de facturación de un cliente sea distinta de su dirección de entrega no es un error. Que un proveedor figure con su nombre comercial en el CRM y con su razón social en el ERP puede ser perfectamente correcto. Las reglas que tratan toda diferencia como error generan una cola de no problemas y entrenan a los responsables de datos para ignorar la cola.

Marco de decisión: por dónde empezar

Recórralo en orden. Deténgase en la primera coincidencia.

1. ¿Tiene un modelo de datos acordado y una matriz de propiedad a nivel de campo?
Si no, empiece por ahí: vea el artículo complementario. Todos los pasos siguientes dependen de ello, y un agente desplegado sin eso sistematizará su ambigüedad actual.

2. ¿Hay un responsable de datos con nombre para cada dominio de master data?
Si no, nómbrelos antes de construir nada. El agente crea una cola de decisiones; una cola sin propietario es peor que ninguna cola, porque produce la apariencia de gobierno sin el fondo.

3. ¿Se siguen creando duplicados y registros mal formados a diario?
Si es así, arregle primero la creación: avisos de duplicado durante la introducción, validación del identificador fiscal por país, obligatoriedad de campos, vocabularios controlados para los atributos de artículo. Esto es más barato que todo lo demás de esta lista y tiene el mayor efecto.

4. ¿Tiene un backlog histórico significativo?
Límpielo como una línea de trabajo definida, con un umbral de confianza, una pista de auditoría y una cuarentena para el resto ambiguo. Acepte que quedará un residuo permanente. No lo intente antes del paso 3, o estará limpiando un conjunto de datos que sigue deteriorándose.

5. ¿Puede medir la divergencia y la duplicación?
Instruméntelo antes de desplegar el agente, para tener una línea base. Sin ella no podrá demostrar que el agente funciona, y estos despliegues se cuestionan con frecuencia en el cuarto mes.

6. ¿Todo lo anterior está en su sitio?
Despliegue, empezando solo con monitorización y detección —sin fusión automatizada— durante el primer mes. Revise qué habría fusionado. Después active la acción automatizada en la banda de alta confianza y amplíe desde ahí a medida que se acumulen evidencias.

7. ¿Desplegado y los registros siguen degradándose?
El problema está en el comportamiento aguas arriba, no en la custodia. Mire si las personas están creando registros en el sistema equivocado, si el proceso de entrada del sistema propietario es tan engorroso que se está esquivando, y si la matriz de propiedad se impone realmente mediante permisos y no solo está documentada.

Coste y esfuerzo indicativos

Asume una instancia de CRM y una de ERP con volúmenes de registros propios del mid-market. Varias instancias de CRM tras adquisiciones, o maestros de artículos de cientos de miles de referencias, alargan esto de forma material. Solicite un presupuesto para una estimación acotada.

Preguntas frecuentes

¿Puede el agente fusionar registros sin revisión humana?
En la banda de alta confianza, sí —mismo identificador fiscal, misma razón social, sin histórico transaccional en conflicto— siempre que cada fusión quede registrada y sea reversible. En la banda ambigua nunca debería fusionar de forma autónoma, porque la asimetría de coste es severa: un duplicado sin fusionar es desaliño, un par mal fusionado mezcla el histórico financiero de dos empresas.

¿Cómo tratamos el problema del grupo y sus filiales?
Como una decisión de modelado, no como un problema de coincidencia. Decida si el grupo es un registro con jerarquía o varios registros vinculados, codifique esa estructura en ambos sistemas y entonces el agente tendrá algo inequívoco que aplicar. Tratado como problema de coincidencia produce o falsos positivos constantes o duplicados reales que pasan desapercibidos.

¿Y los datos bancarios de proveedor?
El agente detecta y señala un cambio, y nunca debe aplicarlo. Los cambios de datos bancarios exigen verificación por canal alternativo con el proveedor a través de un contacto conocido: una llamada a un número que ya tenía, no una respuesta al correo que solicita el cambio. Éste es uno de los fraudes más comunes y más costosos contra las empresas mid-market, y automatizarlo sería activamente peligroso.

¿Requiere esto una plataforma MDM separada?
Normalmente no a escala mid-market. Un agente que opera sobre su CRM y su ERP actuales con una matriz de propiedad definida y una cola para el responsable de datos consigue la mayor parte del beneficio sin introducir otro sistema que mantener. Las plataformas MDM dedicadas justifican su coste a mayor escala, con muchos sistemas de origen o jerarquías genuinamente complejas.

¿Cuánto tardaremos en poder fiarnos de los datos?
La prevención en la creación mejora las cosas en semanas. Fiarse de una cifra entre sistemas —pipeline conciliado con los ingresos, gasto consolidado por proveedor— suele llevar de dos a tres trimestres, porque exige el backlog limpio más un periodo de operación limpia antes de que las cifras sean defendibles.

¿Con qué rapidez se puede conectar el agente a ambos sistemas?
La conexión en sí es rápida — un partner de implementación certificado como Stacksync puede tener la sincronización CRM-ERP bidireccional en tiempo real funcionando en semanas, que es exactamente la capa de datos que necesita este tipo de agente. Lo que lleva más tiempo es el trabajo de gobierno de arriba: acordar la propiedad de los campos y las reglas de fusión. Conecta el agente a definiciones limpias, no solo a tuberías limpias.

Cierre — Próximos pasos

El master data es una función de mantenimiento que la mayoría de las empresas financia como un proyecto, y por eso la misma limpieza se encarga cada pocos años. El agente cambia la economía del mantenimiento lo suficiente para hacerlo continuo en lugar de periódico, pero solo sobre un modelo definido, una matriz de propiedad impuesta y una persona con nombre que responda por las decisiones ambiguas.

Un diagnóstico útil que lleva una tarde: cuente sus registros de cliente en cada sistema, intente emparejarlos por identificador fiscal y cuente cuántos registros se crearon el último trimestre sin uno válido. La primera cifra le dice el tamaño de su backlog. La segunda le dice si sigue creciendo, y eso determina en qué paso del marco empieza realmente.

Sobre el autor

Bruno Galo es el fundador de Atypical Tech, una consultora NetSuite que presta servicio a clientes mid-market en toda Iberia. Está especializado en conectar sistemas CRM y ERP para flujos order-to-cash sin fricciones, construyendo pipelines automatizados de gestión de pedidos que eliminan la introducción manual de datos entre los equipos comercial y financiero. Como partner oficial de implementación de Stacksync, Bruno diseña y despliega agentes de IA sobre plataformas de integración para gestionar el enrutado de excepciones, el procesamiento documental y la conciliación, convirtiendo flujos de pedidos fragmentados en sistemas fiables que se supervisan a sí mismos.

LinkedIn: https://www.linkedin.com/in/brunogd

Fuentes

Las URL son a nivel de editor y deben verificarse antes de la publicación.

• Oracle NetSuite, documentación de registros de entidad y de artículo — https://docs.oracle.com/en/cloud/saas/netsuite/
• DAMA International, Data Management Body of Knowledge (DMBOK) — master data y dimensiones de calidad del dato — https://www.dama.org
• Comisión Europea, Reglamento General de Protección de Datos de la UE — derechos del interesado entre sistemas — https://commission.europa.eu/law/law-topic/data-protection_en
• Agencia Tributaria (España), formato y validación del NIF — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), información sobre NIF/NIPC — https://info.portaldasfinancas.gov.pt
• Experiencia de proyectos de Atypical Tech, programas de datos de CRM y ERP en el mid-market en Iberia
• Stacksync, blog de la plataforma de integración y sincronización en tiempo real — https://www.stacksync.com/blog