Millorar la qualitat de les dades: comprovacions pràctiques que en 30 dies lliuren informes amb millora mesurable

Moltes empreses intenten obtenir millors informes mitjançant nous dashboards, KPIs addicionals o una altra eina de BI. A la pràctica, el problema sovint es troba abans: qui vol millorar la qualitat de les dades ha d’estabilitzar les dades als punts en què es generen, es transmeten, es consoliden i s’interpreten. La mala qualitat de les dades no només es manifesta en «xifres equivocades», sinó en el dia a dia: les àrees de negoci discuteixen sobre la font en lloc de sobre la decisió, l’equip de IT rep tiquets de «l’informe no és correcte» i cada anàlisi requereix correccions manuals a Excel.

La bona notícia: per a millores perceptibles no cal un gran projecte. Amb un procediment clar de 30 dies —focalitzat en pocs, però efectius checks— es poden estabilitzar els informes de manera mesurable. El decisiu és que els checks no s’entenguin com una neteja puntual, sinó com un sistema de control operatiu: amb llindars, responsables, documentació i vies d’escalat.

Aquest article descriu checks de qualitat de dades aplicables en la pràctica, que podeu implantar en quatre setmanes sense «re-inventar» el paisatge de sistemes. El focus està en les repercussions pel funcionament, l’administració, les interfícies, els fluxos de dades i la col·laboració entre IT i àrees de negoci.

Per què fallen els informes malgrat eines modernes: causes típiques en paisatges empresarials

En entorns evolucionats les dades es generen a través de moltes estacions: ERP, CRM, magatzem, portals, software empresarial a mida, processos d’importació/exportació, interfícies amb proveïdors. Cada estació pot canviar el significat d’un camp. Un exemple clàssic és «client»: en el sistema A és el destinatari de la factura, en el sistema B l’adreça d’entrega, en el sistema C l’emplaçament. Quan aquests conceptes es consoliden en una anàlisi, apareixen mètriques aparentment «errònies» —encara que tècnicament s’hagin carregat correctament.

Causes típiques que fan que els informes siguin poc fiables:

• Semàntica poc clara: els camps es diuen igual però signifiquen coses diferents segons el sistema. Per semàntica entenem aquí el significat funcional —no el format de dades.
• Ruptures silencioses d’interfícies: un camp es modifica a la font (p. ex. nous valors d’estat) i la ruta de destí l’accepta «com abans» fins que les anàlisis fallen.
• Dades mestres febles: duplicats, adreces obsoletes, catàlegs de productes inconsistents —i a partir d’això assignacions errònies.
• ETL/ELT sense portes de qualitat: ETL (Extract, Transform, Load) defineix les rutes de càrrega i transformació cap a un DWH. Sense comprovacions, el que és erroni s’acarrega igualment.
• Correccions manuals: les solucions a Excel generen lògica paral·lela. L’informe sembla «correcte», però no és reproduïble.

La conseqüència és sempre similar: manca un mecanisme fiable que detecti les desviacions de forma primerenca i les faci rastrejables abans que arribin als informes de gestió.

Mesurable en 30 dies: què significa «millor qualitat de dades» de manera concreta

«Millor» ha de ser mesurable, si no queda en una percepció. Per a un pla de 30 dies és útil acordar-se en pocs indicadors que tant IT com l’àrea de negoci acceptin. Han demostrat ser pràctics tres nivells:

• Qualitat d’entrada: percentatge de registres vàlids a la font (p. ex. comandes amb adreça d’entrega completa).
• Qualitat de la canonada: percentatge de treballs de càrrega verificats amb èxit sense violacions de qualitat (p. ex. sense valors atípics, sense valors nuls inesperats).
• Qualitat de l’informe: nombre de reclamacions sobre informes, temps fins a la resolució, nombre de correccions manuals.

Opteu per un abast d’inici petit: dos a tres informes crítics que s’utilitzen regularment (p. ex., facturació/marge de contribució, puntualitat en lliuraments, indicadors d’estoc). Per a aquests informes definiu „camps crítics“ i implementeu comprovacions exactament allà. Això evita que la qualitat de les dades es converteixi en una obra sense fi.

Millorar la qualitat de les dades amb 5 categories de comprovacions que funcionen en qualsevol entorn

Les categories de comprovacions següents s’han triat perquè funcionin independentment de l’eina BI emprada. Es poden implementar a la base de dades, a la canalització ETL o com a treballs de control separats. L’important no és l’eina, sinó l’aplicació conseqüent.

1) Comprovacions de completitud: els camps obligatoris estan realment omplerts

La completitud és la palanca més ràpida perquè sovint es pot comprovar sense lògica complexa. Exemples típics: ID de client, número d’article, data de registre, centre de cost, estat, moneda. La trampa a la pràctica: que no sigui NULL no n’hi ha prou. Un camp pot estar tècnicament omplert, però funcionalment buit (p. ex., „0“, „–“, „desconegut“).

Regles pràctiques:

• Definiu per a cada informe 10–20 camps obligatoris que siguin realment rellevants per als indicadors.
• Distingeu entre estricte (l’informe no s’actualitza) i suau (l’informe s’actualitza, però amb advertència i ticket).
• Feu el seguiment de la quota: „X% dels registres compleixen tots els camps obligatoris“ – això és mesurable en 30 dies.

2) Comprovacions de validesa: rang de valors, format i convencions de negoci

La validesa vol dir que un valor no només existeix, sinó que és plausible dins del rang permès. Pot ser tècnic (data en format ISO) o de negoci (l’estat és un dels valors permesos). Precisament a les interfícies sovint apareixen nous valors „inesperats“. Una comprovació de validesa actua com un sistema d’alerta primerenca per a aquests canvis.

Exemples de comprovacions de validesa robustes:

• Enumeracions (llistes de valors): valors d’estat, tipus de document, tipus de registre.
• Rangs de valors: quantitats >= 0, descomptes entre 0 i 100, data de registre no en el futur (amb excepció definida).
• Regles de format: longitud del codi postal segons el país, format IBAN, regles d’e-mail (amb tolerància per no bloquejar casos especials legítims).

És important gestionar conscienciosament les excepcions: un control massa estricte condueix a processos d’elusió („llavors posarem 999“). Per tant, definiu una classe d’excepció amb motiu documentat i data de caducitat.

3) Comprovacions de consistència: la mateixa entitat ha d’aparèixer igual a totes les taules

La consistència és la causa més freqüent d’informes contradictoris. Casos típics: una comanda està „tancada“, però encara hi ha línies obertes. Un client està „inactiu“, però té nous registres. Un article està „bloquejat“, però continua sent disposat. Les comprovacions de consistència verifiquen relacions entre camps i taules.

Comprovacions de consistència pràctiques que mostren efectes ràpidament:

• Lògica d’estat: un estat final requereix una data de finalització; una anul·lació requereix un motiu d’anul·lació.
• Integritat referencial: cada registre comptable té una àrea de cost vàlida; cada línia té una fitxa d’article vàlida. (Fins i tot si la base de dades no imposa claus foranes, la comprovació pot supervisar-ho.)
• Concordança de totals: suma de les línies = total del document (amb tolerància per arrodoniment).

Aquests controls són especialment valuosos perquè fan visibles ruptures semàntiques que d’altra manera només es detecten en reunions. Per a l’operació TI i la direcció de projecte, les comprovacions de consistència són un bon indicador de si els canvis al sistema origen «fan efecte».

4) Controls de duplicats i d’identitat: „Un client“ realment és un client

Els duplicats s’originen gairebé sempre en límits de procés i de sistema: nous canals de venda, portals, creació manual, migracions. L’àrea funcional ho detecta com a vendes duplicades, segmentació incorrecta o responsabilitat poc clara. TI normalment només veu claus diferents.

Inici pragmàtic sense un gran projecte de Master-Data-Management:

• Definiu una o dues regles de correspondència per a les dominis mestres més importants (p. ex. client: nom + codi postal + carrer; proveïdor: ID d’IVA o IBAN).
• Implanteu un informe de „sospita de duplicats“: no com a eliminació automàtica, sinó com a llista de treball amb owner.
• Establiu un conjunt de regles d’adopció: quina font de dades és la principal (System of Record) per a l’adreça, condicions de pagament, classificació?

L’efecte mesurable després de 30 dies no és „ja no hi ha duplicats“, sinó: els duplicats es detecten més ràpidament, els responsables els resolen, i els informes més importants es veuen menys afectats per comptatges duplicats.

5) Controls de valors atípics i de deriva: quan les xifres es tornen „estranyes“ abans que s’escalin

Molts errors de dades no són „NULL“, sinó graduals: una interfície subministra sobtadament un 20% menys de registres, un estat s’utilitza de manera diferent, una ubicació registra en moneda equivocada. Els controls de deriva analitzen tendències i distribucions. Són especialment útils per a indicadors operatius que s’executen diàriament o setmanalment.

Mecanismes fàcils d’implantar:

• Control de volum: nombre de registres per dia/setmana dins d’un corredor (p. ex. mínim/màxim, mitjana mòbil).
• Control de distribució: la proporció de certs valors d’estat o categories es manté dins del rang esperat (p. ex. „anul·lat“ no augmenta sobtadament 10 vegades).
• Control de latència: temps entre l’esdeveniment al sistema origen i la disponibilitat al DWH/informe (important per a la gestió diària).

Perquè els controls de deriva siguin acceptats, necessiten regles d’alarma clares. Altrament apareix la „fatiga d’alarma“: moltes alertes, poca acció. Definiu, per tant, quina desviació només es registra i quina genera un ticket.

El pla de 30 dies: així implementen TI i l’àrea funcional comprovacions sense un projecte mastodòntic

Les quatre setmanes següents són un ritme pràcticament aplicable. S’adapta tant a configuracions DWH/ETL clàssiques com a plataformes modernes de dades. L’objectiu no és la perfecció, sinó un cicle de qualitat que funcioni.

Setmana 1: Establir el focus – abast, fonts de dades, responsabilitat

Comenceu amb una reunió conjunta d’IT i l’àrea de negoci (60–90 minuts). El resultat no és un plec de càrrega, sinó una ordre de treball amb límits clars.

• Trieu 2–3 informes que siguin crítics per al negoci i que s’utilitzin de manera regular.
• Definiu les fonts de dades i el recorregut fins a l’informe: sistema origen → interfície → staging/ODS → DWH → BI. (ODS significa Operational Data Store, és a dir, una àrea intermèdia per a dades operatives.)
• Assigneu responsables: per informe un responsable funcional (significat/regles) i un responsable tècnic (pipeline/operació).
• Mesureu línies de base: quotes d’errors actuals, nombre de reclamacions, causes típiques.

Ja en aquesta fase val la pena una petita „llista de termes de dades“: quina mètrica significa què i quins camps hi ha darrere? Això redueix debats posteriors.

Setmana 2: Construir comprovacions – primer completitud i validesa

La setmana 2 es creen les primeres comprovacions automatitzades. L’objectiu és obtenir ràpidament un senyal sense bloquejar l’activitat diària.

• Implementeu comprovacions de completitud per als camps obligatoris dels informes seleccionats.
• Afegiu comprovacions de validesa per a valors d’estat, rangs de dates, formats bàsics.
• Definiu els resultats de les comprovacions com a Events: „OK“, „Advertència“, „Error“. Aquesta classificació és operativament més rellevant que el text tècnic detallat.

Important: emmagatzemeu històricament els resultats de les comprovacions. Altrament, després de dues setmanes no podreu dir si ha millorat. Un registre d’auditoria simple per comprovació (moment, font afectada, nombre d’infraccions) és suficient per començar.

Setmana 3: Consistència i deriva – estabilitzar els fluxos de dades en lloc de només netejar

Ara s’actua sobre les causes que fan que els informes siguin „inestables“. Les comprovacions de consistència detecten ruptures entre taules/sistemes; les comprovacions de deriva detecten canvis graduals.

• Implementeu 3–5 comprovacions de consistència que impactin directament les mètriques dels informes (p. ex. conciliació de sumes, lògica d’estats).
• Configureu 1–2 comprovacions de deriva per cada font de dades (volum i latència solen ser el millor inici).
• Acordeu una revisió setmanal breu (30 minuts): quines infraccions es repeteixen? Quines són „errors“ reals i quines són ajustos de regla?

Aquest és el punt on la col·laboració dona resultat: molts „problemes de dades“ són problemes de procés (p. ex. manteniment d’estats, camps obligatoris en venda). Quan l’àrea de negoci és responsable, apareixen mesures concretes en lloc d’incidències sense efecte.

Setmana 4: Posar-ho en operació – escalada, tickets, aprovacions, higiene de reporting

Sense ancoratge operatiu, les comprovacions es dilueixen després del pilot. La setmana 4 aporta rutina i camins clars.

• Regles d’alarma i tickets: quina classe de comprovació genera automàticament un ticket? Qui en és el destinatari? Quin termini de resposta és realista?
• Protecció de llançament: en canvis d’interfícies o models de dades, es verifica un conjunt mínim de comprovacions abans d’anar a producció (control de qualitat).
• Llistes de treball dels responsables de dades: sospites de duplicats, classificacions faltants, excepcions amb data de caducitat.

Al cap dels 30 dies hauríeu de tenir un full de resultats curt: línia de base vs. estat actual (percentatges d’errors, reclamacions, temps fins a la resolució). Això genera confiança – i facilita planificar la següent ampliació.

On és tècnicament més adient ubicar les comprovacions: origen, interfície, DWH o BI?

Una pregunta habitual en projectes és: „On incorporem les comprovacions?“ La resposta depèn de l’abast i de l’operació. Regla empírica: comproveu tan aviat com sigui possible, però tan a prop de l’informe com calgui.

• Al sistema origen: Ideal per a camps obligatoris i regles de procés (p. ex. lògica d’estats). Avantatge: els errors no arriben a produir-se. Inconvenient: els canvis requereixen aprovació del departament funcional i poden afectar processos.
• A la interfície: Adequat per a comprovacions de format i de mapping. Avantatge: protegeix els sistemes aval. Inconvenient: amb fallades severes poden generar-se embussos de dades.
• Al DWH/Staging: Adequat per a comprovacions de consistència, conciliacions de sumes, controls de volum i de deriva. Avantatge: central i fàcil de monitoritzar. Inconvenient: els errors ja s’han «registrat» i cal tractar-los retrospectivament.
• Al BI: Més aviat com a capa de protecció final (p. ex. avisos). Avantatge: ràpidament visible per als usuaris. Inconvenient: massa tard per abordar les causes de manera neta.

Per a un inici de 30 dies, el DWH/Staging sovint és el lloc pragmàtic, ja que IT en té el control sense intervenir en els processos operatius. A mitjà i llarg termini val la pena traslladar comprovacions seleccionades cap endavant al sistema origen.

Data Governance light: rols que realment sostenen la qualitat de les dades al dia a dia

„Data Governance“ sona a comitès i directrius. Per a millores ràpides n’hi ha prou amb un model lleuger que clarifiqui responsabilitats. Tres rols han demostrat la seva eficàcia en projectes:

• Data Owner (departament funcional): Responsable del significat, les regles i les excepcions. Decideix si un valor és acceptable des del punt de vista funcional.
• Data Steward (operatiu): Gestiona llistes de treball (p. ex. duplicats, classificacions faltants) i garanteix la cura contínua.
• Technical Owner (IT): Opera les comprovacions, el monitoratge, les interfícies i les escalades; assegura la traçabilitat (Logs, Història, Reproduïbilitat).

És important que les escalades no acabin en el no-res: si una comprovació es viola repetidament, cal o bé canviar el procés, ajustar la UI del programari empresarial o modificar explícitament la regla. „Ignorar“ no és una opció, si no el sistema de control perd credibilitat.

Esculls típics – i com evitar-los

Massa comprovacions alhora

Si els equips defineixen 100 regles però no n’apliquen cap de manera coherent, no s’aconsegueix res. Comenceu amb pocs checks que impactin directament els informes seleccionats. Amplieu-los només quan l’operació rutlli amb estabilitat.

Comprovacions sense camí d’actuació

Una comprovació que només mostra „vermell“ genera frustració. Cada regla necessita un responsable, una forma de tractament (ticket, llista de tasques, procés) i una decisió sobre si l’informe s’ha de bloquejar o simplement advertir.

«Netegem una vegada» en comptes d’arreglar les causes

Una neteja puntual pot ajudar a millorar les línies de base. Serà sostenible només quan s’adreci la causa: camps obligatoris, màscares d’entrada, contractes d’interfície, lògica d’estats, migracions. Si no, el problema tornarà.

Absència de traçabilitat de l’origen de les dades

Per a ambigüitats recurrents val la pena una vista senzilla de la traçabilitat de dades: d’on prové un camp, quines transformacions s’apliquen, qui va fer l’última modificació? La traçabilitat de dades descriu exactament aquesta cadena d’origen. No cal una gran eina per això: sovint n’és suficient un resum mantingut per a cada informe.

Com la millor qualitat de dades millora la presa de decisions — més enllà dels „dashboards més bonics“

El benefici no es limita a menys errors, sinó a decisions més ràpides i més fiables:

• Menys esforç de coordinació: Les reunions tornen a centrar-se en les mesures a prendre en lloc de la font de les xifres.
• Anàlisi de causes més ràpida: Els històrics de les comprovacions mostren quan va començar un error (p. ex. després d’un release o d’un canvi d’interfície).
• Planificació més estable: Les previsions i les decisions d’inventari són menys distorsionades per artefactes de dades.
• Menys Shadow-IT: Si els informes oficials són fiables, disminueix la pressió de crear entorns propis en Excel.

Per a la direcció d’IT i els responsables de projecte és fonamental: la qualitat de les dades és una qüestió d’operacions. Conjuga arquitectura (fluxos de dades), operació (monitorització, tickets), processos (obligacions de manteniment) i modernització (interfícies, models de dades).

Conclusió: En 30 dies, del conflicte sobre les xifres a un procés de qualitat controlable

Millorar la qualitat de les dades és menys una qüestió d’eina que de disciplina: termes clars, pocs checks efectius, valors mesurats historitzats i un camí d’acció que funcioni en el dia a dia. Si comenceu amb 2–3 informes crítics, automatitzeu ràpidament la completitud i la validesa i després afegiu consistència i deriva, obtindreu dins d’un mes una estabilitat mesurable als informes — i una base per fer créixer la governança de dades sense sobrecàrrega.

Si voleu avaluar quines comprovacions en el vostre entorn de sistemes aporten l’efecte més ràpid i com es poden ancorar de manera operativa, podeu tractar-ho estructuradament en el següent pas:

Per a aquest tema també són importants la millora del reporting i la qualitat de dades mestres. L’article situa aquests aspectes de manera comprensible i mostra què importa en el dia a dia.

Parli del projecte o de la iniciativa de modernització amb Net-Base.