Den gængse rækkefølge er: vælge et værktøj, indrette værktøjet, og så håbe at processen nok vil rette sig efter det. Det virker ikke i praksis, fordi et værktøj ikke medbringer en proces. Et værktøj medbringer felter, koblinger, dashboards — men ikke spørgsmålet om hvem i jeres organisation der er ansvarlig for energiforbruget i bygning tre, eller om den facility manager, der leverer det tal, ved at det ender i scope 2-rapporteringen.
Den rigtige rækkefølge er den omvendte: først beskrive processen, derefter først vælge et værktøj baseret på hvad den proces har brug for. Det lyder som en omvej, men det er den korteste vej, fordi hvert funktionelt krav, De stiller til et værktøj, skal komme fra et sted i jeres egen dataorganisation. Uden det udgangspunkt vælger De ud fra funktioner, en leverandør finder vigtige, ikke funktioner der løser jeres flaskehals.
Omkostningerne ved den forkerte rækkefølge er ikke umiddelbart synlige, for et værktøj der ikke passer, virker i første omgang udmærket — for den del af processen, der tilfældigvis matcher det, værktøjet forventer. Resten bygges der manuelt omkring: et Excel-bilag her, en e-mailkorrespondance der, en medarbejder der nøje ved, hvilket trin der lige falder uden for systemet. Det fungerer, indtil den medarbejder forsvinder eller datamængden vokser.
Hvad det koster, afhænger af hvor mange datapunkter der kører uden om værktøjet, og hvor ofte de skal indsamles manuelt igen pr. rapporteringscyklus. Ved et lille antal punkter er det en acceptabel omvej. Ved et stigende antal — flere lokationer, flere scope 3-kategorier, mere lovgivning der kommer til — bliver omvejen hovedvejen, og De betaler strukturelt for mismatchet mellem værktøj og proces. Det er en anden måde at sige det, der også står på denne side: et værktøj oven på en uorganiseret proces producerer pænere rapporter om de samme upålidelige tal.
Et funktionelt krav er først et krav, når det udspringer af noget. "Værktøjet skal kunne vise lineage" er ikke et krav, før De ved, at jeres controller tre gange om året manuelt skal finde ud af, hvor et tal kommer fra. "Værktøjet skal kunne registrere ejerskab" er ikke et krav, før De har set, at et datapunkt uden ejer ikke står på nogens handlingsliste.
Det er netop derfor, at datapunktregistret, source-to-report-lineage'en pr. datapunkt og ejerskabstildelingen skal eksistere først, uafhængigt af hvilket værktøj De til sidst vælger. Så snart de tre ting står på papir — hvilket datapunkt, hvor det kommer fra, hvem der tegner for det — har De en liste med krav, der ikke kommer fra en leverandør, men fra jeres egen organisation. Den liste bruger De til at sammenligne værktøjer, ikke til blindt at vælge et af dem. Hvordan De gennemfører den sammenligning uden bagslag, er beskrevet på denne side om værktøjsvalg.
Stedet hvor dataene ligger, varierer stærkt fra branche til branche, og det bestemmer også hvilke funktionelle krav der er relevante. I en byggevirksomhed ligger en stor del af bæredygtighedsdataene hos underentreprenører og på selve byggepladsen, som beskrevet på denne side om datakilder i byggeriet; der er et krav om flere eksterne kilder pr. projekt sandsynligvis vigtigere end i andre brancher. I installationsbranchen ligger dataene oftere spredt over servicesedler og materialeregistreringer på projektniveau, som beskrevet på denne side om installationsbranchen; der tæller det især, om et værktøj kan samle enkeltstående indtastningspunkter uden at nogen skal gøre det manuelt.
Det generelle spørgsmål — først indrette processen eller først købe et værktøj — bliver videreudviklet på denne side, og kernespørgsmålet på denne side, nemlig hvilke krav der præcist udspringer af jeres egen proces, er opsummeret på denne side. Begge sider tager udgangspunkt i samme punkt: rækkefølgen bestemmer, om et krav er et krav eller et gæt.
Data Readiness Scan fastlægger datapunktregistret, lineage'en og ejerskabet, før der bliver talt om et værktøj. Det er ikke et rapporteringsværktøj og ikke en spørgeskema-løsning — det er det skridt, der bestemmer hvad et værktøj egentlig skal kunne for jeres organisation. Uden det skridt køber De funktioner; med det skridt køber De en løsning på et problem, De kan påvise.
Scanningen er under opbygning. Den, der på denne måde vil have sin proces kortlagt, før der træffes et valg af værktøj, kan tilmelde sig ventelisten og bliver informeret, så snart scanningen er tilgængelig.
Så snart datapunktregistret står klart, og det er tydeligt hvilket datapunkt der kommer fra hvilken kilde og hvem der er ansvarlig for det, opstår et andet, naturligt spørgsmål: hvilken del af arbejdet omkring det — indsamling, kontrol og overførsel af tal — er stadig menneskearbejde, og hvilken del kan et system tage over uden at pålideligheden falder. Det spørgsmål besvarer arbejdsscanningen fra FTE TO AI, der pr. opgave beregner hvilken del af arbejdet der kan overtages af AI. Det er en anden scanning end Data Readiness Scan, og et logisk næste skridt derfra: først vide hvad dataene er og hvor de kommer fra, derefter først se på hvilken del af det manuelle arbejde omkring dem der kan blive overflødigt.
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.