Poboljšanje kvalitete podataka: praktične provjere koje u roku od 30 dana rezultiraju mjerljivo boljim izvješćima

Mnoge tvrtke pokušavaju dobiti bolje izvještaje putem novih nadzornih ploča, dodatnih KPI-jeva ili drugog BI-alata. U praksi je problem često prije toga: tko želi poboljšati kvalitetu podataka, mora stabilizirati podatke na mjestima gdje nastaju, prenose se, agregiraju i interpretiraju. Loša kvaliteta podataka ne očituje se samo u „pogrešnim brojkama“, nego u svakodnevici: poslovni odjeli raspravljaju o izvoru umjesto o odluci, IT dobiva tikete „izvještaj nije točan“, i svaka analiza zahtijeva ručne korekcije u Excelu.

Dobra vijest: za opipljiva poboljšanja nije potreban veliki program. Jasnim 30-dnevnim pristupom – fokusiranim na nekoliko, ali učinkovitih provjera – moguće je izvještaje mjerljivo stabilizirati. Ključno je da se provjere ne razumiju kao jednokratno čišćenje, već kao operativni kontrolni sustav: s graničnim vrijednostima, odgovornima, dokumentacijom i putevima eskalacije.

Ovaj članak opisuje praktične provjere kvalitete podataka koje možete uvesti u četiri tjedna, bez „ponaovnog izumljavanja“ sustavnog krajolika. Fokus je na utjecajima za operacije, administraciju, sučelja, tokove podataka i suradnju između IT-a i poslovnog odjela.

Zašto izvještaji ne uspijevaju unatoč modernim alatima: tipični uzroci u korporativnim okruženjima

U razvijenim okruženjima podaci nastaju kroz mnoge stanice: ERP, CRM, skladište, portali, prilagođeni poslovni softver, import/export procesi, sučelja dobavljača usluga. Svaka stanica može promijeniti značenje polja. Klasičan primjer je „kupac“: u Sustavu A to je primatelj računa, u Sustavu B adresa isporuke, u Sustavu C lokacija. Čim se ti pojmovi ujedine u jednoj analizi, nastaju naizgled „pogrešne“ metrike – iako je tehnički sve ispravno učitano.

Tipični uzroci koji čine izvještaje nepouzdanima:

• Nejasna semantika: polja se zovu jednako, ali u svakom sustavu znače nešto drugo. Semantika se ovdje odnosi na poslovno značenje – ne na format podataka.
• Tihi prekidi sučelja: polje se u izvoru promijeni (npr. novi statusni vrijednosti), ciljni tok ga preuzme „kao i dosad“, sve dok se rezultati izvještavanja ne izobliče.
• Slabi osnovni podaci: duplikati, zastarjele adrese, nekonzistentni stabla proizvoda – i pogrešne dodjele koje iz toga proizlaze.
• ETL/ELT bez gates za kvalitetu: ETL (Extract, Transform, Load) označava tokove učitavanja i transformacije u DWH. Bez provjera, pogreške se jednostavno učitavaju.
• Ručne korekcije: Excel-popravci stvaraju sjenkovitu logiku. Izvještaj izgleda „ispravno“, ali nije reproducibilan.

Posljedica je uvijek slična: nedostaje pouzdan mehanizam koji rano uočava i čini odstupanja razumljivima prije nego što dospiju u upravljačke izvještaje.

Mjerljivo u 30 dana: što „bolja kvaliteta podataka“ konkretno znači

„Bolje“ mora biti mjerljivo, inače ostaje dojam. Za 30-dnevni plan korisno je dogovoriti se na nekoliko indikatora koje prihvaćaju i IT i poslovni odjel. Pokazale su se tri razine:

• Ulazna kvaliteta: udio valjanih zapisa na izvoru (npr. narudžbe s potpunom adresom za dostavu).
• Kvaliteta pipeline: udio uspješno provjerenih učitavanja bez kršenja kvalitete (npr. bez odstupanja, bez neočekivanih null-vrijednosti).
• Kvaliteta izvještaja: broj prigovora na izvještaje, vrijeme do rješavanja, broj ručnih ispravaka.

Počnite s malim opsegom: dva do tri kritična izvještaja koji se redovito koriste (npr. prihod/doprinos pokriću, poštivanje rokova isporuke, pokazatelji zaliha). Za te izvještaje definirajte „kritična polja“ i postavite provjere upravo na tim mjestima. To sprječava da kvaliteta podataka postane beskonačni problem.

Poboljšanje kvalitete podataka s 5 kategorija provjera koje funkcioniraju u svakoj okolini

Sljedeće kategorije provjera odabrane su tako da rade neovisno o korištenom BI-Toolu. Mogu se provesti u bazi podataka, u ETL-pipelinu ili kao zasebni kontrolni poslovi. Važno nije sredstvo, nego dosljedna primjena.

1) Provjere potpunosti: obvezna polja su zaista popunjena

Potpunost je najbrži poluga jer se obično može provjeriti bez složene logike. Tipični primjeri: ID kupca, broj artikla, datum knjiženja, troškovno mjesto, status, valuta. Praktična zamka: „Ne NULL“ nije dovoljna. Polje može biti tehnički popunjeno, ali semantički prazno (npr. „0″, „–“, „nepoznato“).

Praktična pravila:

• Definirajte za svaki izvještaj 10–20 obveznih polja koja su zaista relevantna za metrike.
• Razlikujte strogo (izvještaj se ne smije ažurirati) i meko (izvještaj se ažurira, ali s upozorenjem i tiketom).
• Pratite udio: „X% zapisa ispunjava sva obvezna polja“ – to je u 30 dana dobro mjerljivo.

2) Provjere valjanosti: raspon vrijednosti, format i stručne konvencije

Valjanost znači: vrijednost nije samo prisutna, nego je i plauzibilna u dozvoljenom okviru. To može biti tehnički (datum u ISO-formatu) ili stručno (status pripada skupu dopuštenih vrijednosti). Posebno kod sučelja često neočekivano dolaze nove vrijednosti. Provjera valjanosti djeluje kao rani sustav upozorenja za takve promjene.

Primjeri robusnih provjera valjanosti:

• Enumeracije (ljestvice vrijednosti): statusne vrijednosti, tipovi dokumenata, vrste knjiženja.
• Rasponi vrijednosti: Mengen >= 0, popusti između 0 i 100, datum knjiženja ne u budućnosti (s definiranim izuzetkom).
• Pravila formata: duljina poštanskog broja po državi, IBAN-format, pravila za e-poštu (s tolerancijom kako se legitimni iznimni slučajevi ne blokiraju).

Važno je svjesno upravljati iznimkama: presna provjera inače vodi do procesa zaobilaženja („onda ćemo jednostavno unijeti 999“). Definirajte stoga klasu iznimke s dokumentiranim razlogom i datumom isteka.

3) Provjere konzistentnosti: ista stavka mora biti u svim tablicama jednaka

Konzistentnost je najčešći razlog proturječnih izvještaja. Tipični slučajevi: narudžba je „zaključena“, ali i dalje postoje otvorene stavke. Kupac je „neaktivan“, ali ima nova knjiženja. Artikl je „blokiran“, a ipak se raspoređuje. Provjere konzistentnosti ispituju odnose između polja i tablica.

Praktične provjere konzistentnosti koje brzo pokazuju učinak:

• Status-logika: krajnji status zahtijeva datum završetka; storno zahtijeva razlog storna.
• Referencijalna integritet: svako knjiženje ima važeće troškovno mjesto; svaka stavka ima važeću artikl-karticu. (Čak i ako baza podataka ne prisiljava strane ključeve, provjera to može nadgledati.)
• Usklađivanje zbrojeva: zbroj stavki = iznos dokumenta (s tolerancijom zbog zaokruživanja).

Te provjere su posebno vrijedne jer otkrivaju semantičke prekide koji bi se inače pojavili tek na sastancima. Za IT-operacije i vođenje projekta provjere konzistentnosti predstavljaju dobar indikator jesu li promjene u izvornom sustavu ostvarile učinak.

4) Provjere duplikata i identiteta: „Jedan kupac“ je zaista jedan kupac

Duplikati nastaju gotovo uvijek na granicama procesa i sustava: novi prodajni kanali, portali, ručno unošenje, migracije. Struka to primijeti kao dvostruke prihode, pogrešnu segmentaciju ili nejasnu odgovornost. IT obično vidi samo različite ključeve.

Pragmatičan početak bez velikog projekta upravljanja master podacima:

• Definirajte jedno do dvije pravila podudaranja za najvažnije matične domene (npr. kupac: ime+poštanski broj+ulica; dobavljač: PDV-ID ili IBAN).
• Uvedite izvještaj „sumnja na duplikat“: ne za automatsko brisanje, nego kao radni popis s vlasnikom.
• Usvojite jedno pravilo preuzimanja: koji izvor podataka je vodeći (System of Record) za adresu, uvjete plaćanja, klasifikaciju?

Mjerljivi učinak nakon 30 dana nije „nema više duplikata“, nego: duplikati se brže pronađu, odgovorne osobe ih razjasne i ključni izvještaji budu manje iskrivljeni zbog dvostrukog brojanja.

5) Provjere odudaranja i drifta: kada brojevi „čudno“ izgledaju prije nego što eskalira

Mnoge pogreške u podacima nisu „NULL“, nego postepene: sučelje iznenada isporuči 20% manje zapisa, status se počne drugačije koristiti, lokacija knjiži u pogrešnoj valuti. Provjere drifta promatraju trendove i raspodjele. Posebno su korisne za operativne pokazatelje koji se prate dnevno ili tjedno.

Jednostavno provedivi mehanizmi:

• Provjera volumena: broj zapisa po danu/tjednu unutar zadanog koridora (npr. minimum/maksimum, pokretni prosjek).
• Provjera raspodjele: udio određenih statusa ili kategorija ostaje u očekivanom okviru (npr. „stornirano“ ne postane iznenada 10x veće).
• Provjera latencije: vrijeme između događaja u izvornom sustavu i dostupnosti u DWH/izvještaju (važno za dnevno upravljanje).

Da bi provjere drifta bile prihvaćene, trebaju im se postaviti jasna pravila alarma. Inače nastaje „zamor od alarma“: puno upozorenja, malo akcije. Definirajte stoga koja odstupanja se samo evidentiraju, a koja otvaraju ticket.

30-dnevni plan: kako IT i poslovna jedinica implementiraju provjere bez ogromnog projekta

Sljedeća četiri tjedna predstavljaju praktičan ritam. Prikladan je i za klasična DWH/ETL rješenja i za moderne podatkovne platforme. Cilj nije perfekcija, već funkcionalan krug kvalitete.

Tjedan 1: Uspostaviti fokus – opseg, izvori podataka, vlasništvo

Započnite zajedničkim sastankom IT-a i poslovne jedinice (60–90 minuta). Rezultat nije dokument s detaljnim zahtjevima, već radni nalog s jasno definiranim granicama.

• Odaberite 2–3 izvještaja koji su poslovno kritični i redovito se koriste.
• Definirajte izvore podataka i put do izvještaja: Quellsystem → Schnittstelle → Staging/ODS → DWH → BI. (ODS označava Operational Data Store, tj. međuspremnik za operativne podatke.)
• Imenujte vlasnike: za svaki izvještaj jedan poslovni vlasnik (značenje/pravila) i jedan tehnički vlasnik (pipeline/operacije).
• Izmjerite referentne vrijednosti: trenutne stope pogrešaka, broj reklamacija, tipični uzroci.

Već ovdje vrijedi napraviti malu „listu pojmova podataka“: koja metrika što označava i koja su polja iza nje? To smanjuje kasnije rasprave.

Tjedan 2: Izrada provjera – prvo potpuna pokrivenost i valjanost

U tjednu 2 nastaju prve automatizirane provjere. Cilj je brzo dobiti signal, a da se pritom ne blokira svakodnevni rad.

• Implementirajte provjere potpunosti za obvezna polja odabranih izvještaja.
• Dodajte provjere valjanosti za statusne vrijednosti, raspon datuma i osnovne formate.
• Definirajte rezultate provjera kao događaje: „OK“, „Upozorenje“, „Pogreška“. Ta klasifikacija je operativno važnija od tehničkog detaljnog opisa.

Važno: pohranjujte rezultate provjera povijesno. Inače nakon dva tjedna nećete moći reći poboljšava li se. Jednostavan revizijski zapis po provjeri (vrijeme, zahvaćeni izvor, broj prekršaja) dovoljan je za početak.

Tjedan 3: Konzistentnost i drift – stabilizirati podatkovne tokove umjesto samo čišćenja

Sada se bavite uzrocima zbog kojih su izvještaji „nestabilni“. Konzistentnostne provjere otkrivaju prekide između tablica/sustava, a drift-provjere postupne izmjene.

• Uvedite 3–5 provjera konzistentnosti koje izravno utječu na metrike izvještaja (npr. usklađivanje zbrojeva, logika statusa).
• Postavite 1–2 drift-provjere po izvoru podataka (obujam i latencija su najčešće najbolji početak).
• Dogovorite kratak tjedni pregled (30 minuta): koji se prekršaji ponavljaju? Koji su „pravi“ pogreške, a koji prilagodbe pravila?

Ovo je točka u kojoj suradnja donosi rezultat: mnogi „problemi s podacima“ zapravo su problemi procesa (npr. održavanje statusa, obvezna polja u prodaji). Ako poslovna jedinica ima vlasništvo, nastaju konkretne mjere umjesto neefikasnih ticket-a.

Tjedan 4: Uvesti u operativu – eskalacije, ticketi, odobrenja, higijena izvještavanja

Bez operativne ukorijenjenosti provjere će nakon pilot-faze izblijediti. Tjedan 4 donosi rutinu i jasne putove.

• Pravila za alarme i tickete: koja klasa provjera automatski stvara ticket? Tko je primatelj? Koje je realno vrijeme reakcije?
• Zaštita pri puštanju u produkciju: pri promjenama sučelja ili modela podataka provjerava se minimalni skup provjera prije puštanja u produkciju (quality gate).
• Radne liste vlasnika podataka: sumnja na duplikate, nedostajuće klasifikacije, iznimke s datumom isteka.

Na kraju 30 dana trebali biste imati kratki izvještaj: početna vrijednost (Baseline) nasuprot trenutačnom stanju (stope pogrešaka, reklamacije, vrijeme do rješavanja). To stvara povjerenje – i omogućuje planiranje daljnjeg proširenja.

Gdje su provjere tehnički najsmislenije: izvor, sučelje, DWH ili BI?

Često pitanje u projektima je: „Gdje ugrađujemo provjere?“ Odgovor ovisi o učinku i operacijama. Pravilo: provjeravajte što je prije moguće, ali onoliko blizu izvještaju koliko je potrebno.

• U izvornom sustavu: Idealno za obavezna polja i pravila procesa (npr. logika statusa). Prednost: pogreške se uopće ne pojavljuju. Nedostatak: promjene zahtijevaju odobrenje poslovnog odjela i mogu utjecati na procese.
• Na sučelju: Dobro za provjere formata i mapiranja. Prednost: štiti sustave nizvodno. Nedostatak: kod tvrdih prekida prijeti zagušenje podataka.
• U DWH/Staging: Dobro za provjere konzistentnosti, usporedbe zbrojeva, provjere volumena i provjere drifta. Prednost: centralno, dobro za nadzor. Nedostatak: pogreške su već „ušle“ u sustav i moraju se obrađivati retroaktivno.
• U BI: Prije svega kao posljednji zaštitni sloj (npr. upozorenja). Prednost: brzo vidljivo korisnicima. Nedostatak: prekasno za temeljito otklanjanje uzroka.

Za početak od 30 dana DWH/Staging je često pragmatično mjesto, jer IT tamo ima kontrolu bez miješanja u operativne procese. Srednjoročno do dugoročno isplati se premjestiti odabrane provjere prema izvoru.

Data Governance light: uloge koje u praksi doista održavaju kvalitetu podataka

„Data Governance“ zvuči kao odbori i smjernice. Za brza poboljšanja dovoljan je jednostavan model koji razjašnjava odgovornosti. Tri su uloge u projektima pokazale vrijednost:

• Data Owner (poslovni odjel): Odgovoran za značenje, pravila i iznimke. Donosi odluku je li vrijednost stručno prihvatljiva.
• Data Steward (operativ): Obrađuje radne liste (npr. duplikati, nedostajuće klasifikacije) i osigurava kontinuiranu njegu.
• Technical Owner (IT): Upravlj a provjerama, nadzorom, sučeljima i eskalacijama; osigurava sljedivost (Logs, Historie, Reproduzierbarkeit).

Važno je da eskalacije ne završavaju u nirvani: ako se provjera ponavljano krši, potrebno je ili promijeniti proces, prilagoditi UI u poslovnom softveru ili svjesno promijeniti pravilo. „Ignoriranje“ nije opcija, inače kontrolni sustav gubi vjerodostojnost.

Tipične poteškoće – i kako ih izbjeći

Previše provjera odjednom

Ako timovi definiraju 100 pravila, ali nijedno od njih ne provode dosljedno, ništa nije postignuto. Započnite s nekoliko provjera koje izravno utječu na odabrane izvještaje. Proširite tek kad je rad stabilan.

Provjere bez akcijskog puta

Provjera koja pokazuje samo „crveno“ stvara frustraciju. Svako pravilo treba vlasnika, način obrade (Ticket, radni popis, proces) i odluku hoće li izvještaj biti blokiran ili samo upozoravati.

„Jednom očistimo“ umjesto rješavanja uzroka

Jednokratno čišćenje može pomoći poboljšanju baseline-a. Održivost dolazi tek kad je uzrok adresiran: obavezna polja, obrasci za unos, ugovori o sučeljima, logika statusa, migracije. Inače se problem vraća.

Nema praćenja podrijetla podataka

Za ponavljajuće nejasnoće isplati se jednostavan pogled na Data Lineage: odakle potječe polje, koje se transformacije događaju, tko je zadnji nešto promijenio? Data Lineage odnosi se upravo na taj lanac podrijetla. Ne mora doći kao veliki alat – često je dovoljna uredna pregledna shema po izvještaju.

Kako bolja kvaliteta podataka poboljšava odluke – izvan „ljepših nadzornih ploča“

Koristi se ne vide samo u manjku grešaka, već u bržim, pouzdanijim odlukama:

• Manje usklađivanja: sastanci se ponovno usmjeravaju na mjere umjesto na izvore podataka.
• Brža analiza uzroka: povijesti provjera pokazuju kada je pogreška započela (npr. nakon releasa ili promjene sučelja).
• Stabilnije planiranje: prognoze i odluke o zalihama manje su iskrivljene artefaktima u podacima.
• Manje Shadow IT: kad su službeni izvještaji pouzdani, smanjuje se pritisak za izgradnjom vlastitih Excel-svjetova.

Za IT-upravljanje i odgovorne za projekte posebno je važno: kvaliteta podataka je pitanje operativnog sustava. Povezuje arhitekturu (tokovi podataka), operativu (monitoring, Tickets), procese (obveze održavanja) i modernizaciju (sučelja, modeli podataka).

Zaključak: U 30 dana od sukoba oko brojeva do upravljivog procesa kvalitete

Poboljšanje kvalitete podataka manje je pitanje alata nego discipline: jasni pojmovi, nekoliko djelotvornih provjera, historizirane mjere i akcijski put koji u svakodnevici funkcionira. Ako započnete s 2–3 kritična izvještaja, brzo automatizirate potpunost i valjanost, a zatim dopunite konzistentnost i drift, unutar mjesec dana dobit ćete mjerljivu stabilnost u izvještajima – i temelj za rast upravljanja podacima bez prekomjernog opterećenja.

Ako želite provjeriti koje provjere u vašoj sustavnoj arhitekturi daju najbrži učinak i kako se to operativno uredno ukorijeniti, to možete strukturirano razmotriti u sljedećem koraku:

Za ovu temu važni su i Poboljšanje izvještavanja i Kvaliteta matičnih podataka. Članak te aspekte jasno kategorizira i pokazuje na što se u svakodnevnom radu treba usredotočiti.

Razgovarajte o projektu ili modernizacijskom pothvatu s Net-Base.