Kysykää viideltä osastolta samaa suuretta — esimerkiksi henkilötyövuosien määrää, ajoneuvokannan polttoaineenkulutusta tai poistettua materiaalia — ja saatte viisi päättelyä, jotka kulkevat kukin hieman eri tavalla. Yksi toimipiste laskee vuokratyövoiman mukaan, toinen ei. Yksi tehdas laskee litroissa, toinen on jo muuntanut sen litroiksi ajoneuvoa kohden vuodessa ja toimittaa siis erityyppisen luvun kuin pyydettiin. Paperilla se kaikki on samaa mittaria. Todellisuudessa kyse on eri määritelmistä, jotka sattuvat olemaan samassa sarakkeessa.
Kyse ei ole syöttövirheestä. Kukaan ei ole kirjoittanut mitään väärin. Ongelma piilee tasoa aiemmin: koskaan ei ole kiinnitetty, mikä tämän datapisteen pätevä arvo täsmälleen on, ja niin kukin osasto täyttää tyhjiön omalla logiikallaan. Mikä on pätevä arvo ja mikä ei, on käsitelty sivulla mikä on pätevä arvo — kysymys, jonka pitäisi edeltää jokaista osastojen välistä vertailua.
Keskeinen kysymys ei ole, esiintyykö poikkeamia — niitä esiintyy aina — vaan kuka näkee ne ennen kuin luku päätyy raporttiin. Monessa organisaatiossa vastaus on: ei kukaan, kunnes ulkoinen osapuoli tai tilintarkastaja huomaa luvun, joka ei täsmää viime vuoteen. Silloin kysymys on esitetty liian myöhään.
Datapisteellä, jolla ei ole signaalipoikkeamaa, ei ole tapaa herättää epäluuloa itsestään. Luku, joka on kolme kertaa suurempi kuin viime vuonna, ei automaattisesti erotu, jos ei ole kiinnitetty vaihteluväliä, jonka sisällä arvo on uskottava. Miten tämä vaihteluväli määritetään — kiinteä prosenttiosuus, historiallinen hajonta, yksikkökohtainen kynnysarvo — on käsitelty sivulla miten asetatte signaalipoikkeaman. Kysymys ei ole monimutkainen, mutta se on esitettävä, datapisteittäin, ennen kuin datapiste täytetään.
Signaalipoikkeama havaitsee äärimmäisen tapauksen: luvun, joka selvästi ei täsmää. Mutta useimmat osastojen väliset määritelmäerot ovat sitä hienovaraisempia. Toimipiste, joka laskee vuokratyövoiman mukaan, ei tuota absurdia lukua — se tuottaa luvun, joka näyttää hyvin normaalilta, ja juuri sen takia se ei erotu.
Sen takia jokaiseen datapisteeseen kuuluu useampi kuin yksi tarkistus: vaihteluväli, jonka sisällä arvon on oltava, kiinnitetty yksikkö, lähdevaatimus, joka määrittää minkälainen asiakirjatyyppi kelpaa perusteeksi, ja kuvaus siitä, mikä kuuluu laskentaan ja mikä ei. Mikä tarkistusyhdistelmä tarvitaan, vaihtelee datapisteen ja organisaation mukaan — t&k-menoerä vaatii erilaiset varmistukset kuin päästökerroin. Yleiskuva siitä, mitkä tarkistukset kuuluvat minkä tyyppiseen datapisteeseen, on sivulla mitkä tarkistukset kuuluvat datapisteeseen. Ilman tätä yhdistelmää syntyy näennäistarkkuutta: luku, jossa on kaksi desimaalia, mutta joka on koottu viidestä toisiinsa sopimattomasta määritelmästä. Mistä tämä näennäistarkkuus syntyy ja miten sen tunnistaa, on käsitelty sivulla miten estätte näennäistarkkuuden.
Määritelmä, joka on kiinnitetty paperilla, ei automaattisesti ole määritelmä, jota sovelletaan. Jonkun on vastattava kysymykseen, kun osasto tuo esiin rajatapauksen: lasketaanko tämä yhteistyömuoto henkilötyövuodeksi vai ei, kuuluuko tämä toimittaja scope 3:een vai ei. Ilman nimettyä omistajaa kysymys jää sen varaan, kuka sattuu istumaan lähimpänä lomaketta, ja niin määritelmä siirtyy jälleen, äänettömästi, osastoittain.
Data Readiness Scan kiinnittää datapisteittäin, mikä on pätevä arvo, mikä signaalipoikkeama pätee, mitkä tarkistukset kuuluvat kyseiseen datapisteeseen, ja kuka on määritelmän omistaja. Se ei ole raportointityökalu eikä kyselylomake — se on rekisteri, joka kiinnittää sen, mikä raportin alla on, jotta osastojen välinen ero näkyy ennen kuin luku lasketaan yhteen.
On olemassa järjestelmiä, jotka voivat suorittaa näitä tarkistuksia. Mutta järjestelmä, joka toimii viiden erilaisen, koskaan kiinnittämättömän määritelmän päällä, suorittaa nämä tarkistukset säännöillä, joista kukaan ei ole sopinut. Tuloksena on siisti käyttöliittymä, jossa on epäluotettavia lukuja. Miksi järjestys — ensin määritelmä, sitten työkalu — on tärkeä, on käsitelty sivulla ostetaanko ensin työkalu vai järjestetäänkö ensin prosessi. Ja mitä vaatimuksia työkalun oikeastaan tulee täyttää, ei seuraa toimittajalistasta vaan omasta prosessistanne — katso mitkä toiminnalliset vaatimukset seuraavat omasta prosessistanne.
Data Readiness Scan on rakenteilla. Ne, jotka jo nyt taistelevat osastoittain vaihtelevien määritelmien kanssa, voivat ilmoittautua jonotuslistalle ja saavat tiedon, kun työkalu on saatavilla.
Kun on kerran kiinnitetty, mikä on pätevä arvo, kuka valvoo määritelmää ja mikä tarkistus kuuluu mihin datapisteeseen, näkyy myös, mikä osa tästä työstä on toistoa: samojen lähdeasiakirjojen tarkistaminen samaa sääntöä vasten, samaan vaihteluväliin vertaaminen jokaisen uuden syötteen kohdalla. Se on työtä, joka voidaan laskea, kun se on kerran tehty näkyväksi. FTE TO AI:n työscan laskee tehtävittäin, mikä osa työstä on siirrettävissä AI:n tehtäväksi — ei korvaamaan omistajaa, joka päättää määritelmästä, vaan tapana nähdä, missä valvonta ja toisto erottuvat toisistaan.
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.