Et værktøj bliver ofte købt som første skridt: der er tidspres, der er en deadline, der er en leverandør med en overbevisende demo. Det spørgsmål, der sjældent stilles i den forbindelse: findes der allerede noget, som dette værktøj kan lægges oven på? Et værktøj organiserer ikke noget af sig selv. Det viser, beregner og strukturerer det, man lægger ind i det. Hvis de underliggende data ikke er fastlagt — intet register over datapunkter, ingen fastlagt oprindelse, ingen udpeget ejer per tal — så får man et værktøj, der pænt viser, hvad der i realiteten stadig er løse spreadsheets og løse antagelser.
Værktøjet selv fungerer for det meste fint. Problemet ligger i, hvad der lægges ind i det. Et dashboard, der viser energiforbrug pr. lokation, er kun så godt som den input, det modtager. Hvis ingen har fastlagt, hvilken afdeling der leverer disse tal, med hvilke kildefiler, efter hvilken beregningsregel, så udfylder værktøjet et hul med et skøn, en forkert kobling eller et tal, som en kollega for tre år siden indtastede én gang, og som aldrig siden er blevet opdateret. Værktøjet signalerer ikke dette selv. Det beregner bare videre.
Omkostningerne ved denne rækkefølge kan ikke fanges i ét tal, og det er netop pointen: de er diffuse og spredte. Tid, der bruges igen på at finde ud af, hvor et tal kommer fra, efter det allerede stod i værktøjet. Diskussioner mellem finance og sustainability om, hvem der har leveret hvilket tal. En controller, der ved den første eksterne kontrol må indrømme, at oprindelsen af en central indikator ikke kan rekonstrueres. En implementering, der skal gøres om, delvist eller helt, fordi datastrukturen ikke var indrettet til det. På denne side er selve kernespørgsmålet uddybet nærmere: hvilken rækkefølge er logisk, og hvorfor netop den.
Et værktøj vælges på baggrund af funktionalitet: kan det håndtere de rette datapunkter, passer det til den rette rapporteringsstandard, er rapporteringsstrukturen flexibel nok til det, der stadig kommer til at ændre sig. Disse krav kan ikke formuleres i det abstrakte. De følger af, hvilke data der allerede findes, hvem der forvalter disse data, og hvilke huller der er. Uden det overblik vælges værktøjet på det, leverandøren viser i en demo, ikke på det, organisationen har brug for. Hvilke funktionelle krav der reelt følger af den enkelte organisations egen situation, er beskrevet på denne side om funktionelle krav fra egen proces.
Den omvendte rækkefølge — værktøj først, proces senere — fører til et andet indkøb, en migrering, eller et værktøj, der permanent skal suppleres med de spreadsheets, det skulle have erstattet. Den, der først er kommet ind i denne spiral, opdager, at værktøjet ikke løser det problem, det skulle løse: upålidelige, uopfindelige eller ustyrede data. Det forskyder blot problemet til en pænere brugergrænseflade.
Organisering på forhånd er ikke en bureaukratisk øvelse. Det er et register: hvilke datapunkter er nødvendige til rapporteringen, hvor kommer de fra, via hvilke systemer eller spreadsheets bevæger de sig frem til det endelige tal, hvem er ansvarlig for deres korrekthed, og hvilken kvalitetsregel gælder for at opdage en fejl i tide. Dette register findes uafhængigt af, hvilket værktøj der senere lægges oven på. Det er grundlaget, som et værktøj fungerer på, uanset hvilken leverandør der vælges.
For at undgå at den anden fejltagelse bliver den samme som den første, er det nyttigt at vide, hvordan et værktøj faktisk kan vælges uden fortrydelse: hvilke skridt der hører til dette, er beskrevet på denne side om værktøjsvalg uden fortrydelse. For organisationer i specifikke brancher er det desuden nyttigt at se, hvor bæredygtighedsdataene konkret kommer fra: i byggebranchen ligger de ofte spredt over projektadministrationer og underentreprenører, som beskrevet på denne side om bæredygtighedsdata i byggebranchen, og i installationsbranchen er de fordelt anderledes, som beskrevet på denne side om bæredygtighedsdata i installationsbranchen.
Data Readiness Scan opbygger dette register, før der overhovedet tales om et værktøj: for hvert datapunkt oprindelsen, ejeren og kvalitetsreglen. Ikke en rapport, ikke et udfyldt spørgeskema, men den struktur, som en rapport eller et spørgeskema senere kan bygge på. Værktøjet er under udvikling; den, der er interesseret i dette, kan tilmelde sig ventelisten.
Så snart det er klart, hvilke datapunkter der findes, hvor de kommer fra, og hvem der forvalter dem, opstår også et mere præcist billede af arbejdet omkring dem: hvem indsamler, hvem kontrollerer, hvem fastlægger. Dette arbejde er ikke lige velegnet til automatisering alle steder. Arbejdsscanningen fra FTE TO AI beregner for hver opgave, hvor stor en del der reelt kan overtages af AI, baseret på hvad opgaven præcist indebærer, og ikke på et generelt skøn over branchen.
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.