Att lägga datamjukvara ovanpå en trasig process ger bara snyggare rapporter, medan de underliggande siffrorna förblir opålitliga

Bygg först ett datapunktsregister, designa sedan en källa-till-rapport-process per datapunkt med konsekventa definitioner mellan enheter, istället för att låta varje enhet utveckla sin egen insamlingsmetod oberoende. Inkonsekventa definitioner mellan enheter är ofta osynliga tills någon försöker summera siffrorna på koncernnivå, då den resulterande summan tyst kombinerar siffror som aldrig egentligen mätt samma sak.

Fixa processen först, ägarskap, definitioner, kontroller, innan något verktyg införs; ett verktyg ovanpå en trasig process producerar bara renare opålitliga rapporter som verkar mer trovärdiga än de är. Kalkylark är egentligen inte problemet; avsaknaden av tydligt ägarskap, konsekventa definitioner, och någon kontroll över vad som räknas som en giltig siffra är problemet, och inget mjukvaruköp löser det ensamt.

Designa varje insamlingsprocess med kontroller, aggregering, normalisering, beräkning och standardisering, så att varje siffra är spårbar till en källa istället för att komma in i den slutliga rapporten som ett oförklarat tal ingen kan försvara om det efterfrågas. En verifierbar process liknar mycket hur ekonomifunktionen redan hanterar finansiella data, samma disciplin har bara traditionellt inte tillämpats på hållbarhetssiffror, precis den klyfta detta tillvägagångssätt fyller.

Att dokumentera, per datapunkt, varifrån den kommer, vilken bearbetning den genomgår, och var den hamnar i den slutliga rapporten, så att hela vägen från rå källa till publicerad siffra är explicit och verifierbar istället för något bara en person i organisationen egentligen förstår. Utan denna kartläggning är en siffra i den slutliga rapporten i praktiken en svart låda ingen kan verifiera oberoende eller rekonstruera om det efterfrågas.

Tilldela en RACI per datapunkt och process, definitionsägarskap i hållbarhetsfunktionen, process- och kontrollägarskap i ekonomifunktionen, istället för att lämna ägarskap underförstått och anta att någon naturligt tar ansvar. Hållbarhetsdata har en specifik tendens att bli ägarlösa, eftersom de faller mellan avdelningar som var och en antar att den andra är ansvarig, precis vad en explicit RACI ska förhindra.

Fastställ vilka datapunkter era väsentliga teman och rapporteringsstandarden verkligen kräver, och registrera vad som redan finns mot vad som behöver byggas, istället för att försöka samla in varje tänkbar datapunkt standarden teoretiskt tillåter. Ett register begränsat till verkligt behov, baserat på era specifika väsentliga teman, är en bråkdel av storleken jämfört med ett byggt för att täcka varje möjlig upplysning utan att överväga dess relevans.

Standardisera definitionen i datapunktsregisterfasen, innan någon insamlingsprocess designas, eftersom att försöka förena inkonsekventa definitioner efter att varje enhet redan byggt sin egen process är betydligt mer störande. Att komma överens om en delad definition tidigt, även om det tar mer tid i början, undviker den mycket högre kostnaden att montera ner inkompatibla processer senare.

Definiera hur ett giltigt värde ser ut per datapunkt och vilken avvikelse som utlöser en varning, samma disciplin finansiell data redan har, utökad till hållbarhetssiffror som historiskt samlats in med mycket mindre stringens. Ett kontrollramverk behöver inte vara utarbetat för att vara effektivt; det behöver specificera, för varje datapunkt, hur ett troligt intervall ser ut och vad som händer när en siffra hamnar utanför det.

Säkerställ att varje siffra har en spårbar källa och en namngiven ägare från dag ett, att rekonstruera det i efterhand är mycket dyrare, särskilt när personen som ursprungligen sammanställde en siffra bytt roll eller helt lämnat organisationen. Granskningsleverantörer letar specifikt efter denna typ av spårbarhet, och dess frånvaro är en av de vanligaste anledningarna till att en hållbarhetsrapport inte får ett rent granskningsuttalande.

Fixa processen först. Ett verktygs funktionella krav bör komma från den designade processen, inte tvärtom, eftersom att välja mjukvara innan processen finns betyder att gissa krav istället för att definiera dem från ett verkligt, testat arbetssätt. Verktyg valda så visar sig ofta sakna kapaciteter processen verkligen behöver, eller inkludera en lång lista funktioner processen aldrig använder.

Definiera funktionella krav baserat på er designade insamlingsprocess, genomför sedan valet, aldrig innan processen finns, eftersom en leverantörsdemo är mycket mer övertygande än en tydlig bedömning av vad er specifika datainsamling verkligen behöver. Krav definierade från en verklig process är vanligtvis mer specifika och användbara under leverantörsutvärdering än en generisk funktionschecklista kopierad från en branschrapport.

Definitionsägarskap tillhör hållbarhetsfunktionen; process- och kontrollägarskap tillhör ekonomifunktionen, som redan har systemen och disciplinen för det, eftersom ekonomifunktionen tillbringat decennier med att bygga den stringens hållbarhetsrapportering nu måste uppnå. Denna uppdelning undviker det vanliga misstaget där hållbarhetsfunktionen äger både definitioner och process, utan de system ekonomifunktionen redan har för att köra den processen tillförlitligt i stor skala.

Använd samma datapunktsregister och processdesign som mall, anpassad per enhet men aldrig omdefinierad per enhet, så att koncernnivåaggregeringen fortsätter vara meningsfull istället för att bli en mosaik av lokalt återuppfunna tillvägagångssätt. Anpassning till lokal kontext är okej och ofta nödvändig; att omdefiniera datapunkten eller dess definition lokalt är det som förstör jämförbarheten på koncernnivå.

Veckor för ett enskilt tema; ett fullständigt utrullat koncernnivåprogram med styrning mäts i kvartal, drivet huvudsakligen av antalet inblandade enheter och parter mer än av datans tekniska komplexitet. Tidsramen skalar mycket mer med organisatorisk samordning än med svårighetsgraden av den underliggande mätningen, så ett pilotprojekt på ett enda tema kan gå mycket snabbare än en fullständig utrullning.

Håll källa-till-rapport-kartläggningen och kontrollramverket som dokumentationen själv, byggd redo för granskning från grunden istället för att behandla dokumentation som en separat uppgift att slutföra när processen redan är igång. Att lägga till dokumentation i efterhand på en redan befintlig process är vanligtvis både långsammare och mindre exakt än att bygga dokumentationen som en naturlig biprodukt av god processdesign från början.