At lægge datasoftware oven på en ødelagt proces giver kun pænere rapporter, mens de underliggende tal forbliver upålidelige

Byg først et datapunktregister, design derefter en kilde-til-rapport-proces per datapunkt med konsekvente definitioner mellem enheder, i stedet for at lade hver enhed udvikle sin egen indsamlingsmetode uafhængigt. Inkonsekvente definitioner mellem enheder er ofte usynlige, indtil nogen forsøger at lægge tallene sammen på koncernniveau, hvor den resulterende total tavst kombinerer tal, der aldrig reelt målte det samme.

Fiks først processen, ejerskab, definitioner, kontroller, før nogen værktøj indføres; et værktøj ovenpå en ødelagt proces producerer kun renere upålidelige rapporter, der virker mere troværdige, end de er. Regneark er egentlig ikke problemet; manglen på klart ejerskab, konsekvente definitioner, og enhver kontrol over, hvad der tæller som et gyldigt tal, er problemet, og intet softwarekøb løser det alene.

Design hver indsamlingsproces med kontroller, aggregering, normalisering, beregning og standardisering, så hvert tal er sporbart til en kilde, i stedet for at komme ind i den endelige rapport som et uforklaret tal, ingen kan forsvare, hvis det efterspørges. En verificerbar proces ligner meget den måde, økonomifunktionen allerede håndterer finansielle data på, den samme disciplin er bare traditionelt ikke blevet anvendt på bæredygtighedstal, netop det hul denne tilgang udfylder.

At dokumentere, per datapunkt, hvor det kommer fra, hvilken behandling det gennemgår, og hvor det ender i den endelige rapport, så hele vejen fra rå kilde til publiceret tal er eksplicit og verificerbar, i stedet for noget kun én person i organisationen reelt forstår. Uden denne kortlægning er et tal i den endelige rapport i praksis en sort boks, ingen kan verificere uafhængigt eller rekonstruere, hvis det efterspørges.

Tildel en RACI per datapunkt og proces, definitionsejerskab i bæredygtighedsfunktionen, proces- og kontrolejerskab i økonomifunktionen, i stedet for at lade ejerskab være underforstået og antage, at nogen naturligt tager ansvar. Bæredygtighedsdata har en specifik tendens til at ende uden ejer, fordi de falder mellem afdelinger, der hver antager, den anden er ansvarlig, netop hvad en eksplicit RACI skal forhindre.

Fastlæg hvilke datapunkter jeres væsentlige temaer og rapporteringsstandarden reelt kræver, og registrer, hvad der allerede findes mod, hvad der skal bygges, i stedet for at forsøge at indsamle hver tænkelig datapunkt, standarden teoretisk tillader. Et register begrænset til reelt behov, baseret på jeres specifikke væsentlige temaer, er en brøkdel af størrelsen af et bygget til at dække hver mulig oplysning uden at overveje dens relevans.

Standardiser definitionen i datapunktregisterfasen, før nogen indsamlingsproces designes, fordi det at forsøge at forene inkonsekvente definitioner, efter hver enhed allerede har bygget sin egen proces, er langt mere forstyrrende. At blive enige om en fælles definition tidligt, selvom det tager mere tid i starten, undgår den langt højere omkostning ved at afmontere uforenelige processer senere.

Definer, hvordan en gyldig værdi ser ud per datapunkt, og hvilken afvigelse der udløser en advarsel, den samme disciplin, finansielle data allerede har, udvidet til bæredygtighedstal, historisk indsamlet med langt mindre stringens. En kontrolramme behøver ikke være udførlig for at være effektiv; den skal specificere, for hver datapunkt, hvordan et sandsynligt interval ser ud, og hvad der sker, når et tal falder udenfor.

Sørg for, at hvert tal har en sporbar kilde og en navngiven ejer fra dag ét, at rekonstruere det bagefter er langt dyrere, især efter den person, der oprindeligt samlede et tal, har skiftet rolle eller helt forladt organisationen. Revisionsudbydere leder specifikt efter denne type sporbarhed, og fraværet af det er en af de mest almindelige grunde til, at en bæredygtighedsrapport ikke opnår en ren revisionserklæring.

Fiks processen først. Et værktøjs funktionelle krav bør komme fra den designede proces, ikke omvendt, fordi det at vælge software, før processen findes, betyder at gætte krav i stedet for at definere dem ud fra en reel, testet arbejdsmåde. Værktøjer valgt sådan viser sig ofte at mangle kapaciteter, processen reelt har brug for, eller inkludere en lang liste af funktioner, processen aldrig bruger.

Definer funktionelle krav baseret på jeres designede indsamlingsproces, gennemfør derefter udvælgelsen, aldrig før processen findes, fordi en leverandørdemo er langt mere overbevisende end en klar vurdering af, hvad jeres specifikke dataindsamling reelt har brug for. Krav defineret ud fra en reel proces er typisk mere specifikke og nyttige under leverandørevaluering end en generisk funktionsliste kopieret fra en branchereport.

Definitionsejerskabet tilhører bæredygtighedsfunktionen; proces- og kontrolejerskabet tilhører økonomifunktionen, der allerede har systemerne og disciplinen til det, fordi økonomifunktionen har brugt årtier på at opbygge den stringens, bæredygtighedsrapportering nu skal opnå. Denne opdeling undgår den almindelige fejl, hvor bæredygtighedsfunktionen ejer både definitioner og proces, uden de systemer, økonomifunktionen allerede har til at køre den proces pålideligt i stor skala.

Brug det samme datapunktregister og den samme procesdesign som skabelon, tilpasset per enhed, men aldrig omdefineret per enhed, så koncernniveauaggregeringen fortsat giver mening, i stedet for at blive en mosaik af lokalt genopfundne tilgange. Tilpasning til lokal kontekst er okay og ofte nødvendig; at omdefinere selve datapunktet eller dets definition lokalt er det, der ødelægger sammenligneligheden på koncernniveau.

Uger for ét enkelt tema; et fuldt udrullet koncernniveauprogram med governance måles i kvartaler, primært drevet af antallet af involverede enheder og parter mere end datas tekniske kompleksitet. Tidslinjen skalerer meget mere med organisatorisk koordinering end med sværhedsgraden af selve målingen, så et pilotprojekt på ét tema kan gå meget hurtigere end en fuld udrulning.

Behold kilde-til-rapport-kortlægningen og kontrolrammen som selve dokumentationen, bygget klar til revision fra design, i stedet for at behandle dokumentation som en separat opgave, der skal gennemføres, når processen allerede er i gang. At tilføje dokumentation bagefter til en allerede eksisterende proces er typisk både langsommere og mindre præcis end at bygge dokumentationen som et naturligt biprodukt af god procesdesign fra starten.