Yksi tehdas mittaa jätepainon vaa'alla. Toinen tehdas arvioi sen kontin tilavuuden perusteella. Molemmat toimittavat luvun samalle rivillä raportissa. Kukaan ei ole valehdellut, kukaan ei ole tehnyt virhettä. Vain sitä ei ole koskaan kirjattu, mikä tarkalleen on kyseisen datapisteen määritelmä, ja niin jokainen yksikkö on valinnut sen tulkinnan, joka omassa tilanteessa on ollut looginen.
Tämä ei ole poikkeus. Se on organisaation normaali tila, jossa samaa mittaria toimittavat eri tiimit, eri lähdejärjestelmillä ja eri historialla. Kysymys ei ole siitä, miten estätte tämän eron syntymisen etukäteen. Kysymys on siitä, mitä teette, kun huomaatte sen.
Askel, joka useimmiten jää väliin, on se, että itse määritelmä on kirjattuna jonnekin. Ei sen kontrollerin päässä, joka on tehnyt niin vuosia, vaan rekisterissä: tämä datapiste tarkoittaa tätä, mitataan näin, ja näitä yksiköitä lasketaan mukaan tai ei lasketa. Se, mikä on kelvollinen arvo tämän sisällä ja kuka huomaa, jos toimitus jää sen ulkopuolelle, on kuvattu sivulla mikä on kelvollinen arvo ja kuka huomaa, jos arvo jää sen ulkopuolelle. Ilman tätä kirjaamista jokainen yksiköiden yli tehty yhteenlasku on yhteenlasku asioista, jotka eivät ole aivan samoja, pakattuna yhteen lukuun, joka näyttää vain yksiselitteiseltä.
Tämä kirjaaminen on juuri Data Readiness Scanin työtä: ei raportin uudelleen kirjoittaminen, vaan datapisterekisterin rakentaminen, jossa jokaisen datapisteen kohdalla kerrotaan, mikä se on, mistä se tulee ja kuka siitä vastaa. Tämä rekisteri on paikka, jossa yksiköiden välinen ero tulee näkyväksi, sen sijaan että se tulisi näkyväksi vasta sen jälkeen, kun luku on jo laskettu yhteen.
Kun huomaatte, että yksikkö A ja yksikkö B ymmärtävät samalla datapisteellä eri asian, on karkeasti kolme reittiä.
Ensimmäinen on yhtenäistäminen: yhden määritelmän pakottaminen koko organisaatioon, kaikkine siihen kuuluvine järjestelmämuutoksineen. Se on usein oikea reitti pitkällä aikavälillä, mutta ei asia, joka on valmis päivässä.
Toinen on dokumentointi ja korjaus: poikkeaman antaminen olla siellä missä se on, mutta sen suuruuden kirjaaminen ja vakiomuunnoksella varmistaminen, että kokonaissumma täsmää. Tämä toimii, kun ero on vakaa ja tunnettu — esimerkiksi kun yksi toimipiste käyttää järjestelmällisesti eri mittausmenetelmää, joka on jäljitettävissä.
Kolmas on hälyttäminen: ei korjata, vaan asetetaan lippu, kun toimitus poikkeaa kuviosta, jota tuolta yksiköltä olette tottuneet odottamaan. Se, miten tällainen poikkeamahälytys asetetaan ja kuka siitä saa ilmoituksen, on kuvattu sivulla miten asetatte poikkeamahälytyksen ja kuka huomaa, kun se tapahtuu. Tämä reitti ei ole olemassa ratkaisemaan ongelmaa, vaan estämään sen jäämisen huomaamatta sillä aikaa, kun työskentelette rakenteellisen ratkaisun eteen.
Mikä reitti on sopiva, riippuu siitä, montako yksikköä poikkeaa, kuinka vakaa poikkeama on, ja kuinka paljon aikaa on jäljellä ennen kuin luku siirtyy raportointikauteen. Se on organisaatiokohtainen harkinta, jota tämä rekisteri ei tee puolestanne — se tekee kuitenkin näkyväksi, että harkinta on tehtävä.
Määritelmäero on yksi hiljaisimmista virheistä, koska jokainen yksikkö on erikseen oikeassa. Toimipiste, joka arvioi kontin tilavuuden perusteella, ei tee mitään väärin omassa prosessissaan. Ongelma syntyy vasta tasolla, jossa luvut kohtaavat, ja juuri siellä usein kenellekään ei ole osoitettu tehtäväksi tarkistaa, ovatko taustalla olevat määritelmät ylipäätään vertailukelpoisia.
Siksi omistajuus datapisteittäin on yhtä tärkeää kuin itse määritelmä. Mitkä tarkastukset kuuluvat datapisteeseen ja kuka huomaa, jos yksi niistä jää tekemättä, on kuvattu sivulla mitkä tarkastukset kuuluvat datapisteeseen ja kuka huomaa, jos yksi puuttuu. Ilman nimettyä omistajaa kysymys 'kuka tätä oikeastaan seuraa' jää vastaamatta, vaikka määritelmä olisikin paperilla.
On houkuttelevaa haluta ratkaista tämä ongelma järjestelmällä, joka normalisoi toimitukset automaattisesti. Mutta työkalu, joka asetetaan määrittelemättömien datapisteiden joukon päälle, ei normalisoi mitään — se pakkaa samat erot siistimpään käyttöliittymään. Järjestys, joka kestää, on ensin määritelmän ja omistajuuden kirjaaminen, ja vasta sen jälkeen sen katsominen, mikä järjestelmä sopii siihen. Se, miksi tämä järjestys ei ole sattumaa, on kuvattu sivulla ostetaanko työkalu ensin vai järjestetäänkö prosessi ensin.
Kun jokaisen datapisteen kohdalla on kirjattuna, mikä on määritelmä, kuka on omistaja ja mitkä poikkeamat hälytetään, syntyy toisenlainen kysymys: kuka tekee jatkossa työn, joka kuuluu näihin tarkastuksiin — uudelleenlaskemisen, kysymisen poikkeavalta yksiköltä, itse rekisterin ylläpidon. Osa tästä työstä on tarpeeksi toistettavaa siirrettäväksi automaattiselle vaiheelle, osa vaatii arviointia, joka pysyy ihmisellä. FTE TO AI:n työskannaus laskee tehtäväkohtaisesti, kuinka suuren osan siitä voi siirtää tekoälylle, samanlaisen konkreettisuuden perusteella kuin tämä rekisteri: ei kysymystä siitä, onko automatisointi mahdollista, vaan sitä, mikä osa mistä tehtävästä sen alle kuuluu.
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.