Kérdezzen meg öt egységet ugyanarról a mennyiségről — például az fte-létszámról, egy gépjárműpark üzemanyag-fogyasztásáról, vagy leírt eszközökről — és öt olyan gondolatmenetet kap, amelyek kissé eltérően futnak. Az egyik telephely a kölcsönzött munkaerőt is beleszámítja, a másik nem. Az egyik gyár literben számol, a másik ezt már átszámította literre/gépjárműre/évre, és így egy másfajta számot ad meg, mint amit kértek. Papíron mindez ugyanazt a mutatót jelenti. A valóságban különböző definíciókról van szó, amelyek véletlenül ugyanabban az oszlopban szerepelnek.
Ez nem egy adatbeviteli hiba. Senki nem gépelt el semmit. A probléma egy szinttel korábban keletkezik: soha nem rögzítették, hogy pontosan mi az érvényes érték ehhez az adatponthoz, és így minden egység a saját logikájával tölti ki az űrt. Az, hogy mi érvényes érték és mi nem, ki van fejtve itt: mi az érvényes érték — ez az a kérdés, amelynek minden egységek közötti összehasonlítást meg kellene előznie.
A kulcskérdés nem az, hogy előfordulnak-e eltérések — ezek mindig előfordulnak —, hanem az, hogy ki látja meg őket, mielőtt a szám bekerül egy jelentésbe. Sok szervezetben a válasz: senki, amíg egy külső fél vagy egy könyvvizsgáló nem vesz észre egy olyan számot, amely nem illik a tavalyihoz. Ekkor már túl későn merül fel a kérdés.
Egy jelzőeltérés nélküli adatpontnak nincs módja arra, hogy saját magát gyanúsnak tüntesse fel. Egy szám, amely háromszor magasabb, mint tavaly, nem tűnik fel automatikusan, ha nincs rögzítve egy sávszélesség, amelyen belül egy érték elfogadhatónak számít. Az, hogy hogyan határozza meg ezt a sávszélességet — fix százalék, historikus szórás, egységenkénti küszöbérték —, ki van fejtve itt: hogyan állít be jelzőeltérést. A kérdés nem bonyolult, de fel kell tenni, adatpontonként, mielőtt az adatpontot kitöltik.
Egy jelzőeltérés az extrém esetet fogja meg: azt a számot, amely egyértelműen nem stimmel. De az egységek közötti definíciós eltérések többsége ennél sokkal finomabb. Egy telephely, amely a kölcsönzött munkaerőt is beleszámítja, nem eredményez abszurd számot — olyan számot eredményez, amely egészen normálisnak tűnik, és éppen ezért nem tűnik fel.
Ezért minden adatponthoz több ellenőrzés is kell: egy tartomány, amelyen belül az értéknek lennie kell, egy rögzített mértékegység, egy forráskövetelmény, amely megadja, milyen dokumentumtípus számít alátámasztásnak, és egy leírás arról, hogy mi tartozik bele a számításba és mi nem. Az, hogy milyen ellenőrzés-kombináció szükséges, adatpontonként és szervezetenként eltér — egy k+f-kiadás más biztosítékokat igényel, mint egy kibocsátási tényező. Az, hogy milyen ellenőrzések tartoznak milyen típusú adatponthoz, itt van összefoglalva: milyen ellenőrzések tartoznak egy adatponthoz. Ezek kombinációja nélkül látszatpontosság keletkezik: egy szám két tizedesjegyig, amely öt olyan definícióból áll össze, amelyek nem illenek egymáshoz. Az, hogy honnan ered ez a látszatpontosság és hogyan ismerhető fel, itt olvasható: hogyan kerülhető el a látszatpontosság.
Egy papíron rögzített definíció nem automatikusan olyan definíció, amelyet is alkalmaznak. Valakinek meg kell válaszolnia a kérdést, ha egy egység egy határesetet hoz fel: ez az együttműködési forma beleszámít-e fte-ként vagy nem, ez a beszállító a scope 3-ba tartozik-e vagy nem. Kijelölt tulajdonos nélkül ez a kérdés visszaesik arra, aki éppen a legközelebb ül az űrlaphoz, és ekkor a definíció ismét eltolódik, csendben, egységenként.
A Data Readiness Scan adatpontonként rögzíti, mi az érvényes érték, milyen jelzőeltérés érvényes, milyen ellenőrzések tartoznak az adott adatponthoz, és ki a definíció tulajdonosa. Ez nem jelentéskészítő eszköz és nem kérdőív — ez a nyilvántartás, amely rögzíti, mi rejlik a jelentés alatt, hogy az egységek közötti eltérés láthatóvá váljon, mielőtt a számot összeadják.
Léteznek rendszerek, amelyek el tudják végezni ezeket az ellenőrzéseket. De egy rendszer, amely öt különböző, soha nem rögzített definíció fölött működik, olyan szabályok alapján végzi ezeket az ellenőrzéseket, amelyekben senki nem állapodott meg. Az eredmény egy szép felhasználói felület, amelyben megbízhatatlan számok vannak. Az, hogy miért fontos a sorrend — először a definíció, aztán az eszköz —, itt olvasható: először eszközt vásároljon vagy először a folyamatot alakítsa ki. És az, hogy milyen követelményeknek kell egy eszköznek megfelelnie, nem egy beszállítói listából következik, hanem a saját folyamatából — lásd: milyen funkcionális követelmények következnek a saját folyamatából.
A Data Readiness Scan fejlesztés alatt áll. Aki már most is küzd az egységenként eltérő definíciókkal, feliratkozhat a várólistára, és értesítést kap, amint az eszköz elérhetővé válik.
Ha egyszer rögzítve van, mi az érvényes érték, ki őrzi a definíciót, és milyen ellenőrzés melyik adatponthoz tartozik, akkor az is láthatóvá válik, hogy a munka mely része ismétlődő: ugyanazon forrásdokumentumok ellenőrzése ugyanazon szabály szerint, ugyanazon sávszélesség tesztelése minden új bevitelnél. Ez olyan munka, amely — egyszer explicitté téve — kiszámítható. Az FTE TO AI munkaszkennere feladatonként kiszámítja, mely munkarész vehető át MI által — nem a definícióról döntő tulajdonos helyettesítésére, hanem arra, hogy láthatóvá tegye, hol különböztethető meg az ellenőrzés az ismétléstől.
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.