Proračunska tablica izgleda kao jednostavan izvor. Ćelija s brojem, kartica s nazivom, izvoz iz drugog sustava koji je zalijepljen. Ali između te ćelije i broja koji se konačno pojavi u izvještaju, postoji niz obrada koje najčešće nigdje nisu zabilježene. Source-to-report mapping je mapiranje toga niza: svaki korak kroz koji broj prolazi od trenutka kada uđe u proračunsku tablicu do trenutka kada se pojavi u redu izvještaja.
Kod sustava s fiksnim poljima i fiksnom strukturom obično je još moguće utvrditi odakle koje polje dolazi. Proračunska tablica sama po sebi nema tu strukturu. Neko dodaje pomoćnu karticu za agregiranje. Netko drugi kopira stupac u drugu datoteku da bi izvršio preračun. Treća osoba zalijepi rezultat kao vrijednost u izvještajni list, čime formula, a time i trag, nestaje. Ništa od toga nije pogrešno u trenutku kada se dogodi. Problem nastaje godinu dana kasnije, kada neko treba objasniti odakle broj dolazi, a odgovor se više ne može rekonstruirati.
Source-to-report mapping za izvor u obliku proračunske tablice sastoji se od nekoliko prepoznatljivih koraka, od kojih svaki zahtijeva posebnu pažnju.
Prvi korak je podrijetlo sirovih podataka: koja datoteka, koja kartica, koja ćelija ili raspon ćelija, i tko to unosi ili dostavlja. Bez te referentne točke nema izvora na koji se može uputiti.
Drugi korak je koje se obrade nalaze između izvora i izvještaja kada je izvor proračunska tablica. Riječ je o preračunima jedinica, filterima koji isključuju određene redove, formulama koje zbrajaju ili preskaliraju vrijednosti. Svaka obrada mijenja broj, a svaka obrada koja nije zabilježena je korak koji se kasnije ne može provjeriti.
Treći korak je agregacija: više redova, kartica ili datoteka koje se spajaju u jedan broj. Kod proračunske tablice to se često radi ručno, pritiskom na funkciju zbroja preko raspona koji je netko sam odredio. Način na koji je taj raspon odabran i što se u njemu nalazi određuje broj u istoj mjeri kao i temeljni podaci. Zato je potrebno zabilježiti kako utvrđujete agregaciju kada je izvor proračunska tablica: ne kao formalnost, već zato što je sam korak agregacije izvor pogrešaka koji nitko drugi ne vidi.
Četvrti korak je normalizacija: različite jedinice, različita razdoblja izvještavanja ili različite lokacije koje se dovode na zajedničku osnovu prije nego što se mogu usporediti. I ovdje vrijedi da izbor faktora preračuna ili referentne vrijednosti određuje rezultat, i da taj izbor mora biti sljediv. Kako to funkcionira objašnjeno je u kako utvrđujete normalizaciju kada je izvor proračunska tablica.
Zadnji korak je mjesto gdje broj završava: red izvještaja, indikator, godišnji zbroj. I taj prijelaz mora imati trag, a ne samo referencu na izvorni dokument.
Privlačno je pomisliti da je popis toga tko je što promijenio dovoljan. To je dnevnik, a dnevnik bilježi promjene bez prikazivanja logike koja stoji iza njih. Audit trail koji ima smisla ne pokazuje samo da je ćelija promijenjena, već i zašto, na temelju kojeg pravila i s kojim rezultatom koji se može svesti na izvorni izvor. Ta razlika dodatno je objašnjena u tekstu o zašto je audit trail više od dnevnika kada je izvor proračunska tablica.
Većina organizacija koje rade s proračunskim tablicama nema sustav koji automatski prati lineage. To ne znači da je mapiranje nemoguće, znači da se mora provoditi ručno, disciplinom umjesto softverom. Koji su koraci za to potrebni i kako proces koji se temelji na proračunskoj tablici ipak postaje sljediv, opisano je u kako izraditi lineage bez alata kada je izvor proračunska tablica. Srodno pitanje koje se često izostavlja je tko posjeduje definiciju podatkovne točke: bez određenog vlasnika definicije, značenje podatkovne točke mijenja se ovisno o tome tko u danom trenutku u nju gleda, a tada i najbolje mapiranje ima malu vrijednost.
Alat koji izvještaje čini ljepšima ne mijenja ništa u pogledu pouzdanosti brojeva koji u njih ulaze. Ako put od ćelije do izvještaja nije zabilježen, alat proizvodi urednije izvještaje o istim nesigurnim brojevima. Mapiranje od izvora do izvještaja zato nije korak koji dolazi nakon alata, već korak koji mu prethodi.
Čim se koraci između izvora i izvještaja ispišu, postaje vidljivo i koji su od tih koraka ljudski rad, a koji slijede fiksnu, ponovljivu obradu. Ta razlika temelj je za radnu skenu (werkscan) tvrtke FTE TO AI, koja po zadatku izračunava koji dio posla može preuzeti AI, na temelju onoga što je već utvrđeno o obradi, pravilima i podrijetlu podataka.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.