Yleinen järjestys on: valita työkalu, ottaa se käyttöön, ja toivoa että prosessi mukautuu siihen. Se ei toimi käytännössä, koska työkalu ei tuo mukanaan prosessia. Työkalu tuo mukanaan kenttiä, liittymiä, kojetauluja — mutta ei vastausta siihen, kuka organisaatiossanne vastaa kolmannen kiinteistön energiankulutuksesta, tai tietääkö kiinteistöpäällikkö, joka toimittaa luvun, että se päätyy scope 2 -raportointiin.
Oikea järjestys on käänteinen: ensin kuvataan prosessi, vasta sitten valitaan työkalu sen perusteella, mitä prosessi tarvitsee. Se kuulostaa kiertotieltä, mutta se on lyhin reitti, koska jokaisen työkalulle asetettavan toiminnallisen vaatimuksen on tultava jostain oman data-organisaationne sisältä. Ilman tätä lähtökohtaa valitsette ominaisuuksien perusteella, joita toimittaja pitää tärkeinä, ei ominaisuuksien perusteella, jotka ratkaisevat oman pullonkaulanne.
Väärän järjestyksen kustannukset eivät näy heti, sillä työkalu, joka ei sovi yhteen, toimii alkuun ihan hyvin — sen prosessin osan verran, joka sattuu vastaamaan sitä, mitä työkalu odottaa. Loput rakennetaan käsin sen ympärille: Excel-liite tänne, sähköpostikeskustelu tuonne, työntekijä, joka tietää tarkalleen mikä vaihe jää juuri järjestelmän ulkopuolelle. Se toimii, kunnes kyseinen työntekijä lähtee tai datamäärä kasvaa.
Mitä se maksaa, riippuu siitä, kuinka monta datapistettä kulkee työkalun ulkopuolella ja kuinka usein ne on kerättävä käsin uudelleen joka raportointikierroksella. Pienellä pistemäärällä se on hyväksyttävä kiertotie. Kasvavalla määrällä — useampia toimipaikkoja, useampia scope 3 -kategorioita, uutta lainsäädäntöä joka liittyy mukaan — kiertotiestä tulee pääreitti, ja maksatte jatkuvasti työkalun ja prosessin epäsuhdasta. Se on toinen tapa sanoa se, mikä lukee myös tällä sivulla: työkalu järjestäytymättömän prosessin päällä tuottaa siistimpiä raporteja samoista epäluotettavista luvuista.
Toiminnallinen vaatimus on vaatimus vasta, kun se nousee jostain. "Työkalun on pystyttävä näyttämään lineage" ei ole vaatimus ennen kuin tiedätte, että controllerinne joutuu kolme kertaa vuodessa käsin selvittämään, mistä luku on peräisin. "Työkalun on pystyttävä kirjaamaan omistajuus" ei ole vaatimus ennen kuin olette havainneet, että datapiste, jolla ei ole omistajaa, ei ole kenenkään toimenpidelistalla.
Juuri tästä syystä datapisterekisterin, kunkin datapisteen source-to-report-lineagen ja omistajuuden osoittamisen on oltava olemassa ensin, riippumatta siitä, mihin työkaluun päädytte. Kun nämä kolme asiaa on kirjattu — mikä datapiste, mistä se tulee, kuka siitä vastaa — teillä on lista vaatimuksia, jotka eivät tule toimittajalta vaan omasta organisaatiostanne. Tätä listaa käytetään työkalujen vertailuun, ei sokeasti yhden valitsemiseen. Miten tämä vertailu tehdään katumatta, kuvataan tällä toolselectiota käsittelevällä sivulla.
Se, missä data sijaitsee, vaihtelee suuresti toimialan mukaan, ja se määrittää myös, mitkä toiminnalliset vaatimukset ovat olennaisia. Rakennusalan yrityksessä suuri osa kestävyysdatasta on aliurakoitsijoilla ja itse työmaalla, kuten kuvataan tällä rakennusalan datalähteitä käsittelevällä sivulla; siellä vaatimus useista projektikohtaisista ulkoisista lähteistä on todennäköisesti tärkeämpi kuin muilla toimialoilla. Talotekniikka-alalla data on useammin hajallaan huoltolapuissa ja materiaalikirjauksissa projektitasolla, kuten kuvataan tällä talotekniikka-alaa käsittelevällä sivulla; siellä ratkaisevaa on ennen kaikkea se, pystyykö työkalu yhdistämään erilliset syöttöpisteet ilman, että kukaan tekee sen käsin.
Yleistä kysymystä — järjestetäänkö prosessi ensin vai ostetaanko työkalu ensin — käsitellään laajemmin tällä sivulla, ja tämän sivun keskeinen kysymys, mitkä vaatimukset tarkalleen nousevat omasta prosessistanne, on tiivistetty tälle sivulle. Molemmat sivut lähtevät samasta pisteestä: järjestys ratkaisee, onko vaatimus vaatimus vai arvaus.
Data Readiness Scan kirjaa datapisterekisterin, lineagen ja omistajuuden ennen kuin työkalusta puhutaan lainkaan. Se ei ole raportointityökalu eikä kyselylomakeratkaisu — se on vaihe, joka määrittää, mitä työkalun pitäisi organisaatiollenne oikeasti osata. Ilman tätä vaihetta ostatte ominaisuuksia; tämän vaiheen kanssa ostatte ratkaisun ongelmaan, jonka pystytte osoittamaan.
Skanneri on rakenteilla. Se, joka haluaa prosessinsa kartoitettavan tällä tavalla ennen työkaluvalinnan tekemistä, voi ilmoittautua jonotuslistalle ja saa tiedon, kun skanneri on käytettävissä.
Kun datapisterekisteri on olemassa ja on selvää, mikä datapiste tulee mistä lähteestä ja kuka siitä vastaa, syntyy toinen, luonnollinen kysymys: mikä osa sen ympärillä olevasta työstä — lukujen kerääminen, tarkistaminen ja siirtäminen — on yhä ihmistyötä, ja mikä osa voidaan siirtää järjestelmälle luotettavuuden heikkenemättä. Tähän kysymykseen vastaa FTE TO AI:n työskanneri, joka laskee tehtäväkohtaisesti, kuinka suuri osa työstä voidaan siirtää AI:lle. Se on eri skanneri kuin Data Readiness Scan, ja looginen jatko sille: ensin selvitetään, mitä data on ja mistä se tulee, vasta sitten katsotaan, mikä osa sen ympärillä olevasta käsityöstä voi käydä tarpeettomaksi.
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.