Agent de master data: registres nets a l'ERP i al CRM

Gairebé totes les empreses mid-market amb qui treballem han fet alguna neteja de dades. Algú va dedicar sis setmanes a fusionar clients duplicats, normalitzar descripcions d'articles i corregir dades bancàries de proveïdors. Va funcionar. I al cap de dos o tres trimestres el conjunt de dades s'havia tornat a degradar, perquè no havia canviat res en la manera com es creen i es mantenen els registres.

Aquesta és la característica que defineix el master data —les dades mestres de l'empresa—: no és un projecte amb un estat final, és una condició contínua. Els registres els creen cada dia persones amb pressió de temps que estan intentant fer una altra cosa: registrar una comanda, llançar una compra, anotar un lead. Cadascun d'aquests moments és una oportunitat per a un duplicat, un identificador fiscal mal format, una unitat de mesura inconsistent. El ritme de creació és constant, de manera que qualsevol solució que no sigui també constant perd.

I això és precisament el que fa que la custòdia de dades encaixi bé amb un agent. No perquè detectar duplicats sigui tècnicament difícil, sinó perquè la feina és interminable, poc lluïda i sempre la primera que es desplaça quan una persona té alguna cosa més urgent a fer.

Aquest article tracta de l'agent i del model de custòdia contínua. La qüestió prèvia —què és realment un client i quin sistema és propietari de quin camp— es tracta a part a Un client, dos sistemes, i l'agent que es descriu aquí depèn que aquestes decisions ja estiguin preses.

Per què això importa

La qualitat del master data és el substrat sobre el qual funciona tota la resta, i per això les seves errades apareixen com a problemes d'altres. La previsió de l'equip comercial no és fiable. Compres no pot veure la despesa consolidada per proveïdor. El magatzem prepara l'article equivocat perquè dos registres descriuen el mateix de manera diferent. Finances no pot calcular la rendibilitat per client. Cadascun d'aquests casos s'investiga com un problema independent i tots remeten a la mateixa causa.

Els costos més fàcils de quantificar solen ser els menys importants. Els registres de proveïdor duplicats són un vector real de frau en pagaments: un canvi fraudulent de dades bancàries és materialment més difícil de detectar quan existeixen tres registres del mateix proveïdor. Les dades d'article inconsistents provoquen imprecisió d'inventari, que provoca tant ruptures d'estoc com sanejaments. I sota el RGPD, una sol·licitud de supressió o d'accés no es pot atendre de manera fiable si no pot afirmar amb seguretat quins registres es refereixen a la mateixa persona.

Hi ha també un efecte acumulatiu. Cada integració, cada informe, cada automatització construïda sobre un master data deficient hereta el problema i hi afegeix la seva pròpia lògica per esquivar-lo. Dos anys d'això produeixen un parc de sistemes en què ningú pot explicar per què dos informes no coincideixen, i la resposta sempre és la mateixa.

D'un cop d'ull: què vigila l'agent i què pot decidir

La fila de les dades bancàries de proveïdor és la que cal interioritzar. Un agent que pot actualitzar les dades de pagament d'un proveïdor és un agent que es pot manipular per redirigir els seus pagaments. Aquesta autoritat no hauria d'existir, per convenient que fos.

Què funciona i sobre què cal ser honest

Què funciona:

Prevenció en el moment de la creació, abans que detecció posterior. Un agent que avisa un comercial mentre tecleja que ja existeix un compte semblant evita un duplicat a un cost gairebé nul. Detectar aquest mateix duplicat una setmana més tard costa uns minuts a un responsable de dades i una decisió de fusió. Reparteixi l'esforç en conseqüència — la majoria de les implantacions ho fan a l'inrevés.

Una banda de confiança amb tres zones. Per damunt del llindar superior, fusionar automàticament amb pista d'auditoria. Per sota del llindar inferior, ignorar. Entre tots dos, derivar a un responsable de dades. La banda intermèdia és on ha de concentrar-se l'esforç de disseny, i la seva amplada hauria d'estrènyer-se a mesura que l'agent acumuli històric de resolucions.

Reversibilitat en cada acció automatitzada. Cada fusió, normalització i sobreescriptura ha de ser reversible individualment i conservar l'estat anterior. Això és el que fa acceptable la fusió automatitzada per als auditors i per a les persones els registres de les quals s'estan modificant, i és el que permet anar estrenyent llindars conservadors amb el temps.

Un responsable de dades amb nom per domini. Les dades de client, article i proveïdor necessiten un propietari — una persona, no un comitè. L'agent fa la feina; el responsable decideix els casos ambigus i respon de la mètrica de qualitat. Els desplegaments sense un responsable amb nom acumulen una cua desatesa i fracassen en silenci.

La divergència com a mètrica visible. Nombre de registres divergents, duplicats detectats, temps fins a la resolució, registres creats sense validació. Quan això és en un dashboard del qual algú respon, el comportament canvia aigües amunt — i això fa més per la qualitat de les dades que qualsevol quantitat de neteja aigües avall.

Sobre què cal ser honest:

L'agent no pot arreglar un model de dades indefinit. Si no hi ha una resposta acordada sobre si un grup i les seves filials són un client o cinc, l'agent aplicarà aquesta ambigüitat de manera consistent i a escala. La feina de definició va primer i no es pot automatitzar.

La coincidència difusa produeix falsos positius i falsos negatius, de manera permanent. No hi ha cap llindar que elimini tots dos. Està triant quin error prefereix, i en master data la preferència correcta és gairebé sempre tolerar duplicats abans que arriscar-se a fusions errònies — un duplicat és una molèstia, una fusió errònia pot posar les transaccions d'un client al compte d'un altre.

Un backlog s'ha de netejar a part, i és la part cara. L'agent manté net un conjunt de dades net. No neteja amb eficiència un de brut, perquè un backlog històric gran està format sobretot per casos ambigus que requereixen criteri humà. Pressuposti la neteja del backlog com una línia de treball pròpia.

Les dades d'article són molt més difícils que les de client. Els clients tenen identificador fiscal — una clau de coincidència forta i gairebé única. Els articles normalment no en tenen. Aparellar articles depèn de descripcions, especificacions i codis interns aplicats de manera inconsistent, i la desduplicació automatitzada d'articles és, en conseqüència, menys fiable i necessita una banda de revisió humana més ampla.

Part de la divergència és legítima. Que l'adreça de facturació d'un client sigui diferent de la seva adreça de lliurament no és un error. Que un proveïdor consti amb el nom comercial al CRM i amb la denominació legal a l'ERP pot ser del tot correcte. Les regles que tracten tota diferència com a error generen una cua de no problemes i entrenen els responsables de dades a descartar la cua.

Marc de decisió: per on començar

Recorri'l en ordre. Aturi's a la primera coincidència.

1. Té un model de dades acordat i una matriu de propietat a nivell de camp?
Si no, comenci per aquí — vegi l'article complementari. Tots els passos següents en depenen, i un agent desplegat sense això sistematitzarà la seva ambigüitat actual.

2. Hi ha un responsable de dades amb nom per a cada domini de master data?
Si no, nomeni'ls abans de construir res. L'agent crea una cua de decisions; una cua sense propietari és pitjor que cap cua, perquè produeix l'aparença de governança sense la substància.

3. Encara es creen duplicats i registres mal formats cada dia?
Si és així, arregli primer la creació: avisos de duplicat durant l'entrada, validació de l'identificador fiscal per país, obligatorietat de camps, vocabularis controlats per als atributs d'article. Això és més barat que tota la resta d'aquesta llista i té l'efecte més gran.

4. Té un backlog històric significatiu?
Netegi'l com una línia de treball definida, amb un llindar de confiança, una pista d'auditoria i una quarantena per al romanent ambigu. Accepti que hi quedarà un residu permanent. No ho intenti abans del pas 3, o estarà netejant un conjunt de dades que continua deteriorant-se.

5. Pot mesurar la divergència i la duplicació?
Instrumenti-ho abans de desplegar l'agent, per tenir una línia base. Sense una línia base no podrà demostrar que l'agent funciona, i aquests desplegaments es qüestionen sovint al quart mes.

6. Tot l'anterior ja hi és?
Desplegui, començant només amb monitoratge i detecció — sense fusió automatitzada — durant el primer mes. Revisi què hauria fusionat. Després activi l'acció automatitzada a la banda d'alta confiança i vagi ampliant a mesura que s'acumulin evidències.

7. Desplegat i els registres continuen degradant-se?
El problema és el comportament aigües amunt més que la custòdia. Miri si les persones estan creant registres al sistema equivocat, si el procés d'entrada del sistema propietari és tan feixuc que s'està evitant, i si la matriu de propietat s'imposa realment amb permisos i no només està documentada.

Cost i esforç indicatius

Assumeix una instància de CRM i una d'ERP amb volums de registres propis del mid-market. Diverses instàncies de CRM després d'adquisicions, o mestres d'articles de centenars de milers de referències, allarguen això de manera material. Sol·liciti un pressupost per a una estimació delimitada.

Preguntes freqüents

Pot l'agent fusionar registres sense revisió humana?
A la banda d'alta confiança, sí — mateix identificador fiscal, mateixa denominació legal, sense històric transaccional en conflicte — sempre que cada fusió quedi registrada i sigui reversible. A la banda ambigua no hauria de fusionar mai de manera autònoma, perquè l'asimetria de cost és severa: un duplicat sense fusionar és desendreç, una parella mal fusionada barreja l'històric financer de dues empreses.

Com tractem el problema del grup i les seves filials?
Com una decisió de modelatge, no com un problema de coincidència. Decideixi si el grup és un registre amb jerarquia o diversos registres vinculats, codifiqui aquesta estructura en tots dos sistemes i aleshores l'agent tindrà una cosa inequívoca per aplicar. Tractat com a problema de coincidència, produeix o falsos positius constants o duplicats reals que passen desapercebuts.

I les dades bancàries de proveïdor?
L'agent detecta i marca un canvi, i no l'ha d'aplicar mai. Els canvis de dades bancàries exigeixen verificació per canal alternatiu amb el proveïdor a través d'un contacte conegut — una trucada a un número que ja tenia, no una resposta al correu que demana el canvi. Aquest és un dels fraus més comuns i més costosos contra les empreses mid-market, i automatitzar-lo seria activament perillós.

Això requereix una plataforma MDM separada?
Normalment no a escala mid-market. Un agent que opera sobre el seu CRM i el seu ERP actuals amb una matriu de propietat definida i una cua per al responsable de dades aconsegueix la major part del benefici sense introduir un altre sistema per mantenir. Les plataformes MDM dedicades justifiquen el seu cost a més escala, amb molts sistemes d'origen o jerarquies genuïnament complexes.

Quant trigarem a poder confiar en les dades?
La prevenció en la creació millora les coses en setmanes. Confiar en una xifra entre sistemes — pipeline conciliat amb els ingressos, despesa consolidada per proveïdor — sol trigar de dos a tres trimestres, perquè exigeix el backlog net més un període d'operació neta abans que les xifres siguin defensables.

Amb quina rapidesa es pot connectar l'agent als dos sistemes?
La connexió en si és ràpida — un partner d'implementació certificat com Stacksync pot tenir la sincronització CRM-ERP bidireccional en temps real funcionant en setmanes, que és exactament la capa de dades que necessita aquest tipus d'agent. El que triga més és la feina de governança d'amunt: acordar la propietat dels camps i les regles de fusió. Connecta l'agent a definicions netes, no només a canonades netes.

Tancament — Propers passos

El master data és una funció de manteniment que la majoria de les empreses financen com un projecte, i per això s'encarrega la mateixa neteja cada pocs anys. L'agent canvia l'economia del manteniment prou per fer-lo continu en lloc de periòdic — però només sobre un model definit, una matriu de propietat imposada i una persona amb nom que respongui de les decisions ambigües.

Un diagnòstic útil que dura una tarda: compti els seus registres de client a cada sistema, intenti aparellar-los per identificador fiscal i compti quants registres es van crear el darrer trimestre sense un identificador vàlid. La primera xifra li diu la mida del seu backlog. La segona li diu si continua creixent — i això determina en quin pas del marc comença realment.

Sobre l'autor

Bruno Galo és el fundador d'Atypical Tech, una consultora NetSuite que dona servei a clients mid-market de tota la península Ibèrica. Està especialitzat a connectar sistemes CRM i ERP per a fluxos order-to-cash sense friccions, construint pipelines automatitzats de gestió de comandes que eliminen l'entrada manual de dades entre els equips comercial i financer. Com a partner oficial d'implementació de Stacksync, Bruno dissenya i desplega agents d'IA sobre plataformes d'integració per gestionar l'encaminament d'excepcions, el processament de documents i la conciliació — convertint fluxos de comandes fragmentats en sistemes fiables que es monitoren a si mateixos.

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

Fonts

Els URL són a nivell d'editor i s'han de verificar abans de la publicació.

• Oracle NetSuite, documentació de registres d'entitat i d'article — https://docs.oracle.com/en/cloud/saas/netsuite/
• DAMA International, Data Management Body of Knowledge (DMBOK) — master data i dimensions de la qualitat de les dades — https://www.dama.org
• Comissió Europea, Reglament General de Protecció de Dades de la UE — drets de l'interessat entre sistemes — https://commission.europa.eu/law/law-topic/data-protection_en
• Agencia Tributaria (Espanya), format i validació del NIF — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), informació sobre NIF/NIPC — https://info.portaldasfinancas.gov.pt
• Experiència de projectes d'Atypical Tech, programes de dades de CRM i ERP al mid-market a la península Ibèrica
• Stacksync, blog de la plataforma d'integració i sincronització en temps real — https://www.stacksync.com/blog