Ispraviti podatak nije isto što i rešiti problem

• 

U izveštaju se pojavi pogrešan broj.

Neko ga pronađe.

Vrednost se ispravi.

Dashboard ponovo izgleda kako treba.

I problem se zatvara.

Na prvi pogled, deluje kao uspešno rešenje.

U stvarnosti, možda smo samo uklonili simptom koji je bio vidljiv.

Pravi problem može i dalje da postoji.

Ako se ista greška ponovo pojavi na istom setu podataka, to više nije običan problem sa jednim podatkom. To je alarm da nešto dublje nije pravilno razumeno.

Možda je pogrešna poslovna logika.

Možda se izvorni podatak unosi na pogrešan način.

Možda transformacija daje neočekivan rezultat.

A možda je problem u samom procesu.

Ne postoji jedno univerzalno rešenje.

Zato prvi zadatak nije da ponovo ispravimo pogrešnu vrednost.

Prvo moramo da razumemo zašto je ona uopšte postala pogrešna.

Tu Data Lineage postaje izuzetno važan.

Jedan pogrešan broj na dashboardu mogao je da prođe kroz nekoliko sistema, tabela i transformacija pre nego što ga je bilo ko primetio.

Ispravka konačnog rezultata gotovo ništa nam ne govori o tome gde je problem stvarno nastao.

Praćenje podatka unazad omogućava da pronađemo mesto na kojem su logika, proces ili izvor prvi put zakazali.

A ta razlika je ključna.

Ispraviti jednu vrednost znači rešiti incident.

Ispraviti logiku koja ju je proizvela znači rešiti problem.

Čak ni kada pronađemo i ispravimo root cause, posao nije završen.

Tehnička korekcija sama po sebi nije dokaz da je problem nestao.

Novi proces mora da pokaže da je stabilan.

Jedan praktičan pristup jeste pažljivo praćenje naredna četiri reporting ciklusa.

Ako se podatak objavljuje svakodnevno, to su četiri uzastopna dana.

Ako se prati nedeljno, četiri nedelje.

Ako je mesečni reporting, četiri meseca.

Tek nakon četiri uzastopne tačne objave možemo da počnemo da vraćamo poverenje u podatke.

Ako se ista greška ponovo pojavi u tom periodu, brojanje se ne nastavlja.

Kreće od početka.

Ponovo se otvara i sama analiza, jer je očigledno da prethodno utvrđeni uzrok problema nije bio potpun ili nije bio ispravno identifikovan.

Tada se postavlja još jedno pitanje.

Šta radimo sa istorijskim podacima koji su možda već obrađeni po pogrešnoj logici?

Odgovor nije uvek isti.

Ako je podatak važan za buduće odluke, trendove ili istorijska poređenja, potrebno je vratiti se unazad i ispraviti period koji je problem zahvatio.

Ako podatak nema značajan budući poslovni uticaj, racionalnije može biti da se napravi jasan presek i od tog trenutka nastavi sa ispravnom logikom.

Odluku o tome treba da donesu biznis ili Data Owner, uz procenu rizika i uticaja koju daje Data Governance.

Ako istorija neće biti korigovana, promena ne sme ostati nevidljiva.

Tokom nekoliko narednih reporting ciklusa u samom izveštaju treba jasno naglasiti da podaci pre određenog datuma mogu biti rezultat prethodne logike.

Posle određenog perioda taj disclaimer može da se ukloni iz dashboarda.

Ali ne i iz dokumentacije.

U dokumentaciji trajno mora da ostane zapis o tome šta se dogodilo, šta je promenjeno i od kog datuma se primenjuje ispravna logika.

I čak ni tada incident ne bi trebalo zatvoriti samo zato što tehnički tim kaže da sve funkcioniše.

Biznis korisnici moraju da potvrde da rezultati sada imaju smisla i sa njihove strane.

Tek tada je ceo ciklus završen.

Root cause je ispravljen.

Kontrola je uvedena ili unapređena.

Četiri naredne objave prošle su bez iste greške.

Promena je dokumentovana.

Korisnici su obavešteni.

A biznis je potvrdio da su rezultati ispravni.

Jer ispraviti podatak nije isto što i rešiti problem.

Jedno samo ponovo učini izveštaj tačnim.

Drugo sprečava da sutra ponovo popravljamo istu stvar.