IT-sektorn avviker från sektorer med fabriker, fordonsflottor eller byggnader. Ett mjukvarubolag har inga masugnar och har oftast inte heller någon egen fastighet av betydelse. Det gör att sektorn vid första anblick verkar utsläppslätt, men hållbarhetsdatan är inte försvunnen — den har flyttat. Den finns inte i egna tillgångar, utan i leverantörskedjan, i avtal med molntjänstleverantörer, och i den utrustning som medarbetarna använder. Den som inom IT bara tittar på det egna kontoret missar den största delen av berättelsen.
För många IT-bolag har tyngdpunkten i klimatpåverkan förskjutits till den beräkningskapacitet de köper in. Den som använder AWS, Azure, Google Cloud eller en lokal hostingleverantör köper i praktiken in energiförbrukning som genereras och redovisas någon annanstans. Denna data finns oftast inte i ett internt system, utan i fakturor, tjänsteavtal och de hållbarhetsrapporter som molnleverantörerna själva publicerar. Vissa leverantörer levererar utsläppssiffror per kund eller per arbetsbelastning, andra bara ett allmänt genomsnitt. Skillnaden mellan dessa två avgör hur exakt ett företag kan underbygga sina egna molnrelaterade utsläpp — och den skillnaden är ofta okänd för den som sammanställer rapporten.
Den andra platsen där hållbarhetsdata samlas är utrustning: laptoppar, servrar, nätverksutrustning, telefoner. Denna data uppstår vid flera tillfällen i livscykeln. Vid inköp finns information om materialanvändning och tillverkningsutsläpp hos leverantören, ofta i en produktdeklaration eller miljödeklaration som inte begärs in som standard. Under användning genererar IT-förvaltningen uppgifter om energiförbrukning i datacenter och serverrum, ibland i fastighetssystem, ibland i IT-tillgångshanteringsverktyg som inte kommunicerar med ekonomifunktionen. Vid avfallshantering uppstår ny data igen: återanvändningsgrader, återvinningscertifikat, avtal med hanterare av elektroniskt avfall. Tre faser, tre typer av källor, och sällan en enda plats där de sammanförs.
Företag som primärt levererar mjukvara eller digitala tjänster har en ytterligare komplikation: själva produkten har inget fysiskt fotavtryck, men den körs ändå på en infrastruktur som har det. Frågan om vilken andel av molnutsläppen som ska tillskrivas vilken produkt eller vilken kund kräver allokeringsmetoder som ofta ännu inte har fastställts. Den som rapporterar om detta måste först bestämma vilken datapunkt som utgör grunden — beräkningskraft, lagring, datatrafik — innan något kan mätas. Det är ett metodologiskt val som ligger utanför själva rapporten, men som föregår den.
Eftersom sektorn är arbetsintensiv och har relativt få fysiska tillgångar väger personalrelaterade poster ofta tyngre än inom industriella sektorer: arbetsresor, distansarbete, tjänsteresor, energin i kontorsbyggnader som ibland delas med andra hyresgäster. Denna data finns spridd över HR-system, resebokningsplattformar, fastighetstjänsteleverantörer och ibland i kalkylblad som förs av en enskild medarbetare. Volymen per post är liten, men antalet källor är stort, och det gör konsolideringen mer tidskrävande än omfattningen antyder.
Inom sektorer som byggsektorn eller fastighetssektorn är datan ofta koncentrerad kring ett begränsat antal fysiska platser eller projekt. Inom IT-sektorn är det omvända sant: datan är tunt utspridd över många små, digitala och avtalsbaserade källor. Det kräver ett annat angreppssätt vid uppbyggnaden av ett datapunktsregister — att inte börja med byggnader eller maskiner, utan med avtal, system och frågan om vem inom organisationen som förvaltar vilken del av kedjan.
Även inom ett IT-bolag med flera affärsenheter — till exempel en separat moln-, konsult- och mjukvarugren — återkommer samma fråga: vilka datapunkter behöver ni egentligen vid flera affärsenheter och var i organisationen den datapunkten redan finns. Innan man återigen frågar efter molnförbrukning eller hårdvaruinventering är det värt att undersöka om den uppgiften redan förs någonstans, till exempel via var en datapunkt redan finns vid flera affärsenheter. Det förhindrar att varje enhet bygger upp sin egen, lätt avvikande version av samma siffra.
Frestelsen vid splittrad data är att först skaffa ett verktyg som gör allt överskådligt. Ett verktyg som läggs ovanpå en oorganiserad process ger dock framför allt en snyggare rapport om siffror som underliggande ännu inte stämmer. Att först klargöra varifrån varje datapunkt kommer, vem som ansvarar för den och vilka kvalitetsregler som gäller, är steget som föregår systemval, inte det som följer på det.
Så snart det är klart vilka datapunkter som finns, varifrån de kommer och vem som förvaltar dem, uppstår också insikt i hur mycket manuellt arbete som fortfarande finns runt omkring: omskrivning, kontroll, efterforskning hos en kollega. Det är precis den typ av arbete som FTE TO AI med en arbetsanalys per uppgift räknar ut hur stor andel av som kan tas över av AI, som ett komplement till den insikt ett datapunktsregister redan ger.
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.