Den vanliga ordningen är: välja ett verktyg, konfigurera verktyget, och sedan hoppas att processen anpassar sig till det. Det fungerar inte i praktiken, eftersom ett verktyg inte medför en process. Ett verktyg medför fält, kopplingar, dashboards — men inte frågan om vem i er organisation som ansvarar för energiförbrukningen i byggnad tre, eller om facilitetschefen som levererar den siffran vet att den hamnar i scope 2-rapporteringen.
Den rätta ordningen är omvänd: först beskriva processen, sedan välja ett verktyg utifrån vad den processen behöver. Det låter som en omväg, men det är den kortaste vägen, eftersom varje funktionellt krav ni ställer på ett verktyg måste komma från er egen dataorganisation. Utan den utgångspunkten väljer ni utifrån funktioner som en leverantör tycker är viktiga, inte funktioner som löser er flaskhals.
Kostnaderna för den felaktiga ordningen syns inte omedelbart, eftersom ett verktyg som inte passar till en början fungerar utmärkt — för den del av processen som råkar stämma med det verktyget förväntar sig. Resten byggs manuellt runt omkring: en Excel-bilaga här, en e-postväxling där, en medarbetare som exakt vet vilket steg som ligger precis utanför systemet. Det fungerar, tills den medarbetaren slutar eller datamängden växer.
Vad det kostar beror på hur många datapunkter som ligger utanför verktyget och hur ofta de måste samlas in manuellt igen per rapporteringscykel. Vid ett litet antal punkter är det en acceptabel omväg. Vid ett växande antal — fler platser, fler scope 3-kategorier, mer lagstiftning som ansluter — blir omvägen huvudvägen, och ni betalar strukturellt för missmatchningen mellan verktyg och process. Det är ett annat sätt att säga vad som också står på den här sidan: ett verktyg ovanpå en oorganiserad process producerar snyggare rapporter om samma opålitliga siffror.
Ett funktionellt krav är först ett krav när det härstammar från något. "Verktyget måste kunna visa lineage" är inte ett krav förrän ni vet att er controller tre gånger om året manuellt måste ta reda på var en siffra kommer ifrån. "Verktyget måste kunna registrera ägarskap" är inte ett krav förrän ni har sett att en datapunkt utan ägare inte finns på någons åtgärdslista.
Detta är exakt varför datapunktregistret, source-to-report-lineage per datapunkt, och tilldelningen av ägarskap måste finnas först, oavsett vilket verktyg ni slutligen väljer. Så snart de tre sakerna finns på papper — vilken datapunkt, varifrån den kommer, vem som ansvarar för den — har ni en lista med krav som inte kommer från en leverantör utan från er egen organisation. Den listan använder ni för att jämföra verktyg, inte för att blint välja ett. Hur ni hanterar den jämförelsen utan att ångra er beskrivs på den här sidan om verktygsval.
Var datan finns skiljer sig starkt mellan olika sektorer, och det avgör också vilka funktionella krav som är relevanta. I ett byggföretag ligger en stor del av hållbarhetsdatan hos underentreprenörer och på byggplatsen själv, som beskrivs på den här sidan om databronnen i bygg; där är ett krav kring flera externa källor per projekt förmodligen viktigare än i andra sektorer. I installationsbranschen ligger datan oftare utspridd över servicekvitton och materialregistreringar på projektnivå, som man kan läsa om på den här sidan om installationsbranschen; där handlar det främst om huruvida ett verktyg kan sammanföra separata inmatningspunkter utan att någon gör det manuellt.
Den allmänna frågan — först inrätta processen eller först köpa ett verktyg — utvecklas vidare på den här sidan, och kärnfrågan på denna sida, vilka krav exakt som härstammar från er egen process, sammanfattas på den här sidan. Båda sidorna utgår från samma punkt: ordningen avgör om ett krav är ett krav, eller en gissning.
Data Readiness Scan fastställer datapunktregistret, lineagen och ägarskapet innan man pratar om ett verktyg. Det är inget rapporteringsverktyg och ingen frågeformulärslösning — det är steget som avgör vad ett verktyg egentligen behöver kunna för er organisation. Utan det steget köper ni funktioner; med det steget köper ni en lösning på ett problem ni kan peka ut.
Scanen är under uppbyggnad. Den som vill kartlägga sin process på detta sätt innan ett verktygsval görs kan anmäla sig till väntelistan och blir informerad så snart scanen är tillgänglig.
Så snart datapunktregistret finns och det är klart vilken datapunkt som kommer från vilken källa och vem som ansvarar för den, uppstår en andra, naturlig fråga: vilken del av arbetet runt omkring — insamling, kontroll och överföring av siffror — är fortfarande människoarbete, och vilken del kan ett system ta över utan att tillförlitligheten sjunker. Den frågan besvarar arbetsscanen från FTE TO AI, som per uppgift beräknar vilken del av arbetet som kan tas över av AI. Det är en annan scan än Data Readiness Scan, och en logisk fortsättning på den: först veta vad datan är och varifrån den kommer, sedan titta på vilken del av det manuella arbetet runt omkring som kan bli överflö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.