Toimittaja kysyy ennemmin tai myöhemmin: mitä järjestelmän on pystyttävä tekemään? Vastaus ei löydy toimittajalta eikä listalta ominaisuuksia, jotka muutkin yritykset ovat rastittaneet. Vastaus löytyy omasta prosessistanne: mitä datapisteitä keräätte, kuka toimittaa ne, mistä ne tulevat, ja mitä menee pieleen, jos kukaan ei valvo.
Yleinen tapa on: valita työkalu, ottaa työkalu käyttöön ja vasta sitten selvittää, mistä minkä datan on tultava. Tämä järjestys toimii nurinkurisesti, koska työkalulla ei ole mielipidettä prosessistanne. Se pyytää syötettä, ja tuon syötteen on tultava jostakin. Jos se jokin — datapisterekisteri, omistajuus, lähteet — ei ole vielä olemassa, työkalun käyttöönotosta tulee etsintäretki, jota kukaan ei ollut suunnitellut.
Toinen järjestys alkaa prosessista. Ensin kartoitetaan, mitä datapisteitä tarvitaan, kuka toimittaa ne, mistä järjestelmästä tai laskentataulukosta ne tulevat, ja mitkä laatusäännöt niihin liittyvät. Vasta sen jälkeen selviää, mitä vaatimuksia työkalun on todella täytettävä. Ei abstrakteja vaatimuksia kuten "käyttäjäystävällinen" tai "skaalautuva", vaan konkreettisia vaatimuksia kuten: on liityttävä tähän tiettyyn lähdejärjestelmään, on pystyttävä erottamaan kolme omistajaa yhden datapisteen sisällä, on pystyttävä havaitsemaan poikkeama, kun luku ylittää ennalta määritetyn marginaalin.
Järjestys ei ole menetelmän mieltymys; se seuraa siitä, mikä toiminnallisesti loogisesti edeltää työkalua. Työkalulle voidaan asettaa vaatimuksia vasta, kun on olemassa jotain, mistä vaatimukset johdetaan. Tuo jokin on prosessi: datan kulku lähteestä raporttiin, kaikkine manuaalisine vaiheineen, siirtoineen ja oletuksineen. Ilman tätä yleiskuvaa organisaatio asettaa vaatimukset sen mukaan, mihin työkalu pystyy, ei sen mukaan, mitä prosessi tarvitsee. Tämä kuulostaa hienovaraiselta erolta, mutta se ratkaisee, vastaako työkalu sitten todellisuutta vai jää siitä sivuun.
Tämä liittyy kysymykseen siitä, miten työkalu valitaan niin, ettei sitä joudu katumaan jälkikäteen: katumus syntyy usein ei huonosta työkalusta, vaan työkalusta, jonka oli arvattava vaatimukset, koska kukaan ei ollut kirjannut niitä ylös.
Jos työkalu tulee ensin ja prosessi vasta myöhemmin, syntyy kahdenlaisia kustannuksia. Ensimmäinen on suora uudelleenjärjestely: toiminnallisuus, joka ei sovi, liitännät, jotka on rakennettava jälkikäteen, kentät, jotka jäävät tyhjiksi, koska kukaan ei tiedä, kenen tehtävä on täyttää ne. Toinen kustannus on näkymättömämpi mutta raskaampi: työkalu alkaa tuottaa raportteja, jotka näyttävät siistimmiltä, vaikka luvut niiden takana eivät edelleenkään ole jäljitettävissä lähteeseen tai omistajaan. Tätä riskiä kuvataan laajemmin sivulla siitä, mitä maksaa työkalun asettaminen järjestämättömän prosessin päälle: työkalu piilottaa ongelman sen ratkaisemisen sijaan.
Kysymys siitä, kumpi järjestys tulee edullisemmaksi, riippuu siitä, kuinka monta datapistettä, järjestelmää ja omistajaa on jo olemassa ja kuinka moni niistä on vielä kirjaamatta. Pienessä prosessissa, jossa lähteitä on vähän, käänteisen järjestyksen aiheuttama vahinko on rajallinen. Prosessissa, joka on levittäytynyt useille osastoille, järjestelmiin ja laskentataulukoihin, tämä vahinko kasvaa jokaisen datapisteen myötä, jota ei ole selvitetty ennen kuin työkalu sitä kysyy. Tämä vertailu on avattu tarkemmin sivulla ostetaanko ensin työkalu vai järjestetäänkö ensin prosessi: mitä ero maksaa.
Ennen kuin työkalulle voidaan asettaa vaatimuksia, on oltava yleiskuva siitä, mitä datapisteitä raportointi vaatii, mistä kukin datapiste tulee, kuka vastaa oikeellisuudesta, ja mikä sääntö määrittää, onko arvo uskottava. Tämä yleiskuva ei ole tekninen asiakirja eikä työkalu itse; se on rekisteri, joka muodostaa perustan kaikille jatkotoimille, olipa jatkotoimi työkalu, manuaalinen prosessi tai näiden yhdistelmä.
Kysymys siitä, mitä toiminnallisia vaatimuksia siitä seuraa, on siis oikeastaan kysymys: mitä rekisterissä on, ja mitä siitä puuttuu vielä? Kunnes tähän kysymykseen on vastattu, jokainen työkalulle asetettu vaatimus on arvaus. Tätä vaatimusten ja taustalla olevan prosessin yhteyttä käsitellään tarkemmin sivulla siitä, mitkä toiminnalliset vaatimukset seuraavat omasta prosessistanne ja mitä väärä järjestys siinä maksaa.
Kun datapisterekisteri ja omistajuus ovat kunnossa, kysymys siirtyy siitä, mitä työkalun on pystyttävä tekemään, siihen, mitä tapahtuu ihmisille, jotka tekevät tätä työtä nyt: lukujen keräämiseen, tarkistamiseen ja kopioimiseen laskentataulukoista ja järjestelmistä. Osa näistä tehtävistä on toistuvaa ja noudattaa kiinteitä sääntöjä, ja juuri tällaista työtä voidaan osittain siirtää AI:n tehtäväksi. [FTE TO AI:n työskannaus](https://ftetoai.nl) laskee tehtäväkohtaisesti, mikä osa siitä voidaan automatisoida, jolloin selviää, missä ihmisiä tarvitaan edelleen ja missä työ voidaan siirtää järjestelmälle, joka tarkistaa ja toimittaa tiedot kiinteiden sääntöjen mukaisesti.
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.