Tabelarvutus näib olema lihtne allikas. Lahter numbriga, vahekaart nimega, teisest süsteemist eksporditud ja sisse kleebitud andmed. Kuid selle lahtri ja numbri vahele, mis lõpuks aruandes on kirjas, jääb rida töötlusetappe, mida enamasti kusagil ei dokumenteerita. Source-to-report mapping tähendab selle rea kaardistamist: iga etappi, mille number läbib alates hetkest, mil see tabelarvutusse jõuab, kuni hetkeni, mil see aruande reale jõuab.
Fikseeritud väljade ja fikseeritud struktuuriga süsteemi puhul on tihtipeale võimalik jälile saada, kust mingi väli pärineb. Tabelarvutusel sellist struktuuri iseenesest ei ole. Keegi lisab vahekaardi, et koondada andmeid. Keegi teine kopeerib veeru teise faili, et teha ümberarvutus. Kolmas kleebib tulemuse väärtusena aruandluslehele, mistõttu valem ja seega jälg kaob. Sellest ei ole midagi valesti sel hetkel, kui see toimub. Probleem tekib aasta hiljem, kui keegi peab selgitama, kust number pärineb, ja vastust ei õnnestu enam taastada.
Source-to-report mapping tabelarvutuse allika puhul koosneb mitmest äratuntavast etapist, millest igaüks vajab eraldi tähelepanu.
Esimene etapp on toorandmete päritolu: milline fail, milline vahekaart, milline lahter või lahtrivahemik, ja kes need sisestab või tarnib. Selle kinnituspunktita ei ole allikat, kuhu tagasi viidata.
Teine etapp on millised töötlused jäävad allika ja aruande vahele, kui allikaks on tabelarvutus. Mõelge ühikute teisendamisele, filtritele, mis välistavad teatud read, valemitele, mis liidavad või skaleerivad väärtusi. Iga töötlus muudab numbrit, ja iga dokumenteerimata töötlus on etapp, mida hiljem ei saa enam kontrollida.
Kolmas etapp on agregeerimine: mitu rida, vahekaarti või faili, mis koondatakse üheks numbriks. Tabelarvutuses toimub see tihti käsitsi, summafunktsiooni vajutades vahemiku peale, mille kellegi enda kätega on piiritletud. Kuidas see vahemik on valitud ja mis selles sisaldub, määrab numbri sama palju kui aluseks olevad andmed. Just seepärast peab olema dokumenteeritud kuidas dokumenteerite agregeerimist, kui allikaks on tabelarvutus: mitte formaalsuse pärast, vaid kuna agregeerimise etapp on iseenesest veaallikas, mida keegi teine ei näe.
Neljas etapp on normaliseerimine: erinevad ühikud, erinevad aruandlusperioodid või erinevad asukohad, mis viiakse ühisele alusele enne, kui need muutuvad võrreldavaks. Ka siin kehtib, et teisendusfaktori või võrdlusväärtuse valik suunab tulemust ja see valik peab olema jälgitav. Kuidas see toimib, on lahti kirjutatud kuidas dokumenteerite normaliseerimist, kui allikaks on tabelarvutus.
Viimane etapp on koht, kuhu number jõuab: aruande rida, indikaator, aasta koondsumma. Ka sellel üleminekul peab olema jälg, mitte ainult viide lähtedokumendile.
On ahvatlev arvata, et piisab nimekirjast selle kohta, kes mida muutis. See on logi, ja logi registreerib muudatused, näitamata selle taga olevat loogikat. Audit trail, mis midagi tähendab, näitab mitte üksnes seda, et lahtrit on muudetud, vaid ka miks, millise reegli alusel ja millise tulemusega, mis on jälgitav tagasi algallikani. Seda vahet käsitletakse täpsemalt selgituses miks audit trail on rohkem kui logi, kui allikaks on tabelarvutus.
Enamikul tabelarvutustega töötavatel organisatsioonidel puudub süsteem, mis peab automaatselt arvet päritoluahela üle. See ei tähenda, et kaardistamine on võimatu, see tähendab, et see peab toimuma käsitsi, distsipliiniga tarkvara asemel. Millised etapid selleks vajalikud on ja kuidas tabelarvutusepõhine protsess ikkagi jälgitavaks muutub, on kirjeldatud kuidas loote päritoluahela ilma tööriistata, kui allikaks on tabelarvutus. Sellega seotud küsimus, mis tihti kõrvale jäetakse, on kellele kuulub andmepunkti definitsioon: kui definitsioonile ei ole määratud omanikku, muutub andmepunkti tähendus koos sellega, kes seda mingil hetkel vaatab, ja siis on kõige ilusamal kaardistuselgi vähe väärtust.
Tööriist, mis muudab aruanded ilusamaks, ei muuda midagi nende numbrite usaldusväärsuses, mis sinna sisenevad. Kui lahtrist aruandeni kulgev tee ei ole dokumenteeritud, toodab tööriist korrastatumaid aruandeid samade ebakindlate numbrite kohta. Allikast aruandeni ulatuv kaardistamine ei ole seetõttu etapp, mis tuleb tööriista järel, vaid etapp, mis läheb sellele eelnevalt.
Niipea kui allika ja aruande vahelised etapid on kirja pandud, saab nähtavaks ka see, millised nendest etappidest on inimtöö ja millised järgivad fikseeritud, korratavat töötlust. See vahe on aluseks FTE TO AI töskannile, mis arvutab iga ülesande puhul välja, kui suure osa tööst saab AI üle võtta, tuginedes sellele, mis on juba dokumenteeritud töötluse, reeglite ja andmete päritolu kohta.
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.