Ett register för en affärsenhet får ni vid ett tillfälle klart. Datapunkterna finns med, var och en med en källa och en ägare, och definitionerna är testade. Vid flera affärsenheter ändras frågan. Det handlar inte längre om att en lista är komplett, utan om att listorna tillsammans summerar till en samlad bild av organisationen.
Det är ett annat slags arbete än att bara lägga till fler rader. Fallgropen är att tro att ett register är klart så snart varje enhet har fyllt i sin egen tabell. Fyra fullständiga tabeller med fyra olika definitioner av samma datapunkt ger inte ett register, utan fyra register som råkar ligga bredvid varandra.
Per enhet upprepas samma grundarbete: vilka datapunkter behövs, varifrån kommer de, och vem är ansvarig för dem. Det börjar med frågan vilka datapunkter behöver ni egentligen, eftersom en enhet som registrerar för många datapunkter främst samlar på sig underhållsbörda utan att rapporteringen blir bättre.
För varje datapunkt som blir kvar måste samma fråga ställas: finns detta redan i ett system, eller måste det fortfarande efterfrågas. Sidan om var finns en datapunkt redan beskriver den utredningen. Vid flera affärsenheter varierar svaret ofta: enhet A har redan energiförbrukningen i ett fastighetssystem, enhet B för fortfarande in det i ett kalkylblad som en enda controller hanterar. Den skillnaden måste synas i registret, och inte försvinna bakom en enhetlig kolumn som överallt säger 'finns'.
Den största risken vid flera enheter är inte att datapunkter saknas, utan att de finns under samma namn medan de mäter något annat. 'Vattenförbrukning' kan hos en enhet enbart avse huvudkontoret och hos en annan även produktionshallen. 'Antal heltidsanställda' kan vara räknat med eller utan inhyrd personal. Så länge den skillnaden inte är namngiven summerar ingen problemet förrän siffrorna måste sammanställas för den konsoliderade rapporten.
Ett register som löser detta fastställer per datapunkt definitionen på organisationsnivå, och visar därefter per enhet om den definitionen också har tillämpats så. Där det inte är fallet står det som en öppen punkt i registret, inte som ett tyst antagande. Uppbyggnaden av den strukturen beskrivs i hur upprättar ni ett dataregister, och den ordningen ändras inte när det finns flera enheter: först fastställa datapunkterna och deras definitioner på organisationsnivå, sedan fylla i per enhet vad som redan finns och vad som saknas.
Antagandet att bara de mindre eller mindre mogna enheterna har luckor i sina källor stämmer sällan. En stor enhet med ett omfattande ERP-system kan för viss miljödata lika gärna förlita sig på en manuell räkning som en liten filial. Andelen datapunkter utan säker källa beror på ämnet och på hur länge en enhet redan har arbetat med dessa siffror, inte på enhetens storlek. Hur många av era datapunkter har en källa är därför en fråga som måste besvaras separat per enhet, se hur många av era datapunkter har en källa. Först när det är kartlagt per enhet kan något sägas om helheten.
Datapunkter utan källa försvinner inte från registret bara för att de är obekväma. De får en status och ett nästa steg, beskrivet under vad gör ni med en datapunkt utan källa. Vid flera affärsenheter är det klokt att jämföra denna status mellan enheterna: om tre av fyra enheter har en källa för en datapunkt och den fjärde inte har det, ligger lösningen ofta inom räckhåll hos dessa tre enheter, i stället för att den fjärde enheten måste uppfinna hjulet på nytt.
Ett register över flera affärsenheter stämmer inte för att det ser komplett ut, utan för att tre saker är sanna samtidigt. För det första: varje datapunkt har på organisationsnivå en definition, och den definitionen har tillämpats likadant hos varje enhet, eller skillnaden är uttryckligen dokumenterad. För det andra: för varje datapunkt är det per enhet tydligt om det finns en källa, och om inte, vad statusen är. För det tredje: ägarskap är tilldelat på den nivå där kunskapen verkligen finns, inte automatiskt hos enhetens högsta chef.
Hur lång tid detta arbete tar beror på antalet enheter, antalet ämnen och skicket hos de underliggande systemen; en uppskattning av det beskrivs i hur lång tid tar det att få ett ämne i ordning. Det är ingen fast genomloppstid, utan en summering av det arbete som fortfarande återstår per enhet och per datapunkt.
Att sammanföra dessa register, härleda definitioner och lägga källor bredvid varandra per enhet är till stor del repeterbart arbete: samma frågor, tillämpade om och om igen på en annan avdelning eller en annan datapunkt. Vilken del av det som kan tas över av AI och vilken del som förblir mänskligt arbete är precis vad arbetsskanningen från FTE TO AI är gjord för: den beräknar per uppgift hur mycket utrymme det finns att snabba upp den här typen av registerarbete, utan att resultatet blir beroende av antaganden som ingen har kontrollerat.
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.