Skaičius tvarumo ataskaitoje beveik visada turi nueitą kelią. Jis pradeda kaip eilutė energijos sąskaitoje, skaitiklio rodmuo gamybos sistemoje, įvedimo laukas HR įrankyje. Kol skaičius atsiduria ataskaitoje, jis yra suskaičiuotas, perskaičiuotas, sujungtas ir kartais pataisytas. Tie tarpiniai žingsniai galutiniame rezultate retai yra matomi. Kas žiūri tik į ataskaitą, mato skaičių. Kas žiūri į kelią tarp jų, mato eilę sprendimų.
Tarp šaltinio ir ataskaitos paprastai yra nusistovėjusi apdorojimų eiga, net jei niekas jos niekada nėra užrašęs.
Pirmiausia duomenys yra surenkami: eksportuojami iš sistemos, perrašomi iš sąskaitos, kopijuojami iš skaičiuoklės. Tada jie yra normalizuojami: litrai tampa kubiniais metrais, kilovatvalandės tampa gigadžauliais, vietinė valiuta tampa fiksuotu skaičiavimo vienetu. Toliau jie priskiriami kategorijai ar apimčiai (scope), o tai yra sprendimas, ne automatinis veiksmas. Po to seka agregacija: padalinių, mėnesių ar skyrių skaičiai sujungiami į metinę sumą. Kelyje pasitaiko pataisymai – dėl dvigubo skaičiavimo, dėl trūkstamų mėnesių, dėl klaidingo vieneto, kurį kažkas prieš metus pastebėjo ir pataisė rankiniu būdu.
Kiekvienas žingsnis yra vieta, kur priimama prielaida. Pasirenkamas emisijos koeficientas. Įvertis pakeičia trūkstamą matavimą. Pritaikomas apvalinimas. Pati savaime nė viena iš šių dalykų nėra problema. Problema kyla tada, kai niekas nebežino, kokia prielaida buvo priimta, kas ją priėmė ir kodėl.
Ataskaitos skaičius, kurio negalima susekti iki jo šaltinio, yra tik pareiškimas. Kai kontrolierius, auditorius ar priežiūros institucija paklausia, kaip skaičius buvo sudarytas, atsakymas turi būti daugiau nei „taip yra sistemoje“. Atsakymas turi galėti parodyti kelią: šis šaltinis, šis perskaičiavimas, šis agregavimas, šis pataisymas.
To kelio užfiksavimas turi tris tiesioginius padarinius. Pirma, klaidų paieška tampa kelių minučių, o ne kelių dienų darbu, nes aišku, kur perskaičiavimas buvo pritaikytas, o kur ne. Antra, tampa galimas perdavimas: kai skaičiuoklę tvarkantis asmuo išeina, žinios apie apdorojimus nedingsta su juo. Trečia, atsiranda pagrindas tikrinimui, nes išorinė šalis gali sekti žingsnius, jų iš anksto neatkurdama.
Be šio fiksavimo, kiekvienas ataskaitų teikimo ciklas yra pakartotinis tyrimo darbas. Kažkas skambina ankstesniam tvarkytojui, ieško senuose laiškuose, spėlioja apvalinimo priežastį. Tas darbas ataskaitoje pačioje yra nematomas, bet jis nulemia, kiek pasitikėjimo ta ataskaita verta.
Ne kiekvienas apdorojimas reikalauja to pačio metodo. Agregacija, kurios metu keleto šaltinių skaičiai sujungiami į vieną sumą, reikalauja kitokio fiksavimo nei normalizacija, kurios metu suvienodinami vienetai ir apibrėžimai. Kas norėtų sužinoti, kaip tiksliai dokumentuoti agregaciją, tai ras paaiškinime apie agregacijos žingsnių fiksavimą, o kas svarsto, kaip elgtis su normalizacija, tai perskaitys normalizacijos fiksavimo aprašyme. Abu yra tos pačios grandinės dalis, bet klausimai, kuriuos jie kelia, yra skirtingi: agregacija kelia klausimus apie išsamumą, normalizacija – apie nuoseklumą.
Situacija taip pat pasikeičia, kai šaltinis pats yra ne sistema, o skaičiuoklė. Tada nėra automatinio eksporto, sistemos žurnalo, fiksuotos struktūros, ir fiksavimą reikia sukurti kitaip. Kas susiduria su tokia situacija, ras atramos taškų paaiškinime apie source-to-report susiejimą, kai šaltinis yra skaičiuoklė ir apžvalgoje apie apdorojimus tarp šaltinio ir ataskaitos konkrečiai skaičiuoklės šaltinių atveju. Tiems, kas neturi biudžeto įrankiui ir turi kilmės grandinę (lineage) sukurti su tuo, kas jau yra, yra darbo metodas, kaip sukurti kilmės grandinę be specializuotos programinės įrangos.
Apdorojimų fiksavimas dažnai painiojamas su žurnalu: sąrašu, kas, ką ir kada pakeitė. Tai yra dalis istorijos, bet ne visa istorija. Audito seka (audit trail), kuri registruoja tik pakeitimus, nepaaiškina, kodėl sprendimas buvo priimtas ar kokia taisyklė buvo pritaikyta. Skirtumas tarp žurnalo ir tikros atskaitomybės struktūros yra išnagrinėtas aprašyme apie tai, kodėl audito seka turi būti daugiau nei žurnalas.
Data Readiness Scan atvaizduoja šį kelią: kuris šaltinis maitina kurį duomenų tašką, kokie apdorojimai yra tarp jų, kas yra kiekvieno žingsnio savininkas ir kokia kokybės taisyklė su tuo siejasi. Tai nėra ataskaita ir ne klausimynas, o pagrindinė struktūra, kuri abu daro patikimais.
Kai apdorojimai tarp šaltinio ir ataskaitos yra aprašyti, tampa aišku, kurie žingsniai yra nuolatinis rankinis darbas: sąskaitos perrašymas, fiksuoto perskaičiavimo koeficiento pritaikymas, mėnesio skaičių sujungimas pagal fiksuotą taisyklę. Tai tiksliai tas darbo tipas, kurio dalį galima apskaičiuoti, kiek gali perimti AI, neprarandant fiksavimo funkcijos nuo šaltinio iki ataskaitos. FTE TO AI apskaičiuoja kiekvienai užduočiai, kokia jos dalis yra perkeliama, remiantis darbo skenavimu (werkscan), kuris tą skirtumą kiekvienai užduočiai padaro aiškiai matomą.
Data Readiness Scan yra kūrimo stadijoje. Kas norėtų, kad apdorojimai tarp šaltinio ir ataskaitos būtų užfiksuoti, kai tik skenavimas bus prieinamas, gali užsiregistruoti laukiančiųjų sąraše.
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.