Melkein jokaisessa keskustelussa kestävyysdatasta on kiinteä hetki: joku osoittaa taulukkolaskentaohjelmaa. Liikaa välilehtiä, liikaa käsityötä, liikaa virhemahdollisuuksia. Johtopäätös tuntuu ilmeiseltä: korvaa taulukkolaskentaohjelma järjestelmällä ja ongelma on ratkaistu. Tämä johtopäätös on yleensä tehty liian aikaisin.
Taulukkolaskentaohjelma on pintapinta. Se näyttää lukuja, laskee niitä yhteen, yhdistää niitä toisiinsa. Se ei selitä, mistä luku on peräisin, kuka siitä on vastuussa, vai vastaako se enää määrittelyä, joka vahvistettiin kaksi vuotta sitten. Näitä kysymyksiä ei ole esitetty taulukkolaskentaohjelmalle — niitä ei ole koskaan kirjattu mihinkään. Taulukkolaskentaohjelma saa syyt jostakin, mikä on mennyt pieleen jo aiemmin: keräämisen, uudelleenkirjoittamisen, tai sen olettamisen vaiheessa, että kollega tiesi kyllä, mitä lukua tarkoitettiin.
Korvaa taulukkolaskentaohjelma ohjelmistopaketilla, ja nämä kysymykset jäävät vastaamatta. Järjestelmä näyttää sitten siistimmän yleiskuvan samasta epävarmuudesta. Raportointi näyttää ammattimaisemmalta; taustalla oleva data ei ole muuttunut luotettavammaksi. Tämä on sudenkuoppa: työkalun ostaminen ennen kuin on selvää, mitä sen työkalun tulisi järjestää.
Usein kyse on kolmesta asiasta, jotka ovat kasvaneet erillään toisistaan. Ei ole ajantasaista yleiskuvaa siitä, mitä datapisteitä organisaatio tarvitsee — se yleiskuva on joskus laadittu vanhaa raportointistandardia varten ja sitä ei ole päivitetty. Ei ole kirjattua polkua lähteestä raporttilukuun, minkä takia kukaan ei voi varmuudella sanoa, tuleeko luku yhdestä järjestelmästä vai toisesta, tai arviosta, jonka joku joskus täytti, kun todellista dataa ei ollut saatavilla. Ja jokaiselle datapisteelle ei ole nimettyä omistajaa — henkilö, joka toimittaa luvun, ei ole automaattisesti se, joka pystyy selittämään, mistä se on peräisin tai mikä sen laatu on.
Näillä kolmella asialla ei ole mitään tekemistä taulukkolaskentaohjelmien kanssa. Ne aiheuttaisivat saman ongelman missä tahansa järjestelmässä. Taulukkolaskentaohjelma tekee niistä vain näkyvämpiä, koska sen päällä ei ole kerrosta, joka peittäisi sekasotkun.
Datapisterekisteri, jossa on source-to-report-jäljitettävyys (lineage), kirjaa, mistä datapiste on peräisin, kuka siitä vastaa ja mitä laatusääntöjä siihen sovelletaan. Se on hyödyllistä, ja se on myös rajallista. Rekisteri ei näytä sisällöllistä arviota siitä, onko luku oikein — se näyttää, onko polku siihen lukuun jäljitettävissä. Kahdella organisaatiolla, joilla on sama rekisteri, voi silti olla erilainen pisteytys datan laadussa, koska yhdellä organisaatiolla on lähde, joka on itsessään epätarkka, ja toisella ei. Rekisteri tekee tämän eron näkyväksi; se ei ratkaise sitä.
Tärkeää on myös se, että jokainen datapiste ei tarvitse yhtä paljon jäljitettävyyttä. Joillekin luvuille yksinkertainen, hyvin dokumentoitu lähde riittää; toisille tarvitaan enemmän yksityiskohtia, koska lähteen ja raportin välissä on useampia vaiheita. Mitkä datapisteet organisaatio todella tarvitsee, riippuu raportointivelvoitteesta ja toimialasta, ja se on eri asia kuin olettaa, että kaikki ansaitsee yhtä paljon huomiota. Kuinka moni olemassa olevista datapisteistä on jo lähteen kanssa yhdistetty, vaihtelee suuresti organisaatiokohtaisesti — yhdellä se on kirjattu ERP-integraatioon, toisella yhden työntekijän muistiin.
Rekisterin ja jäljitettävyyden luominen ei ole kysymys järjestelmän käynnistämisestä. Se on selvittämistä, aihe aiheelta, mistä luku syntyy, kuka sitä tarkastelee ennen kuin se päätyy raporttiin, ja mitä tapahtuu, kun tämä henkilö ei ole enää käytettävissä. Tämä työ vaihtelee aiheen mukaan: yhdelle aiheelle lähde on jo valmiina, toiselle se on vielä löydettävä tai rakennettava uudelleen. Kuka pohtii, kuinka paljon aikaa tämä vie aihetta kohden, löytää realistisemman vastauksen aiheen läpimenoaika-arviosta kuin työkaludemosta, joka lupaa, että kaikki tapahtuu automaattisesti.
Tämä lähestymistapa ei tuota raporttia — sen tekee toinen työkalu, tämän datan pohjalta. Se, mitä se tuottaa, on rakenne, joka pysyy pystyssä, vaikka taulukkolaskentaohjelma korvattaisiin, vaikka kaiken tietänyt työntekijä lähtisi. Mitä tämä käytännössä tarkoittaa sille, joka joskus tarkastelee rekisteriä, on kuvattu siinä, kuka käyttää datapisterekisteriänne, kun laatija ei ole enää käytettävissä, ja mitä muuttuu, kun jäljitettävyys on kerran vahvistettu, on kerrottu kertaalleen vahvistetun jäljitettävyyden seurauksissa.
Taulukkolaskentaohjelmat eivät ole ongelma, mutta ne ovat ensimmäinen näkyvä oire. Se, joka korvaa taulukkolaskentaohjelman tietämättä ensin, mitkä datapisteet todella ovat merkityksellisiä, mikä lähde niihin kuuluu ja kuka niistä vastaa, siirtää ongelman kalliimpaan järjestelmään. Jäljelle jää sitten kysymys, joka edeltää tätä työtä: mitä datapisteitä todella tarvitaan raportointivelvoitteeseen, ja onko osa niistä mahdollisesti jo olemassa jossakin organisaatiossa kenenkään sitä tietämättä, kuten kuvataan kohdassa missä datapiste mahdollisesti on jo olemassa.
Tämä on työtä, jota ihmiset tekevät nykyään suurelta osin käsin: lähteiden jäljittäminen, määritelmien vertailu, omistajuuden selvittäminen. Osa tästä selvitystyöstä on jäsennettävissä ja nopeutettavissa tekoälyllä, osa ei — juuri tätä eroa FTE TO AI:n työscan tarkastelee. Työscan laskee tehtäväkohtaisesti, kuinka suuri osa työstä on siirrettävissä tekoälylle, ja antaa siten realistisemman kuvan kuin oletus, että työkalu ratkaisee ongelman kokonaisuudessaan.
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.