Ett kalkylblad med energiförbrukning per anläggning är i sig inget problem. Problemet uppstår i nästa steg: hur dessa rader sammanförs till det tal som anges i rapporten. Det steget sker ofta i en formel, en pivottabell eller, värre, i huvudet hos den person som årligen uppdaterar kalkylbladet. Ingen annan vet exakt vilka rader som har tagits med, vilka som har exkluderats och varför.
Att aggregera låter som att räkna, men det är en rad val. Räknar ni med anläggningar som var stängda under delar av året? Tar ni med hyrda lokaler eller bara ägda? Räknar ni med kalenderår eller räkenskapsår? Varje val förändrar slutsiffran, och i ett kalkylblad är dessa val vanligtvis inte separat dokumenterade. De är inbyggda i en formel som hänvisar till celler, utan att det finns en läsbar rad som säger: detta är aggregeringsregeln, och det är därför.
Så snart någon tar över kalkylbladet, eller så snart en controller ett år senare vill reproducera en jämförbar siffra, saknas den förklaringen. Formeln fungerar fortfarande, men ingen kan längre bedöma om den fortfarande är korrekt för årets situation.
Mellan den råa raden i kalkylbladet och talet i rapporten finns vanligtvis flera steg: urval av relevanta rader, omräkning till en enhet, summering eller viktat genomsnitt, och ibland en korrigering för saknade månader eller platser. Varje steg kan ha en egen regel, och varje regel kan ändras utan att det noteras någonstans.
Den fråga som då räknas: om en controller frågar hur denna siffra är uppbyggd, kan ni peka ut stegen ett för ett? Inte härleda resultatet genom att arbeta bakåt genom formeln, utan visa själva reglerna.
En aggregeringsregel som bara existerar i en formel är inte kontrollerbar och inte överförbar. Att fastställa den innebär: separat från kalkylbladet notera vilken aggregering som har tillämpats, på vilket urval, med vilka undantag, och vem som har fastställt den regeln. Det är inte ett extra dokument bredvid kalkylbladet, det är förklaringen som gör kalkylbladet användbart som källa för en rapportpunkt.
Utan den förklaringen förändras en aggregeringsregel obemärkt. Någon lägger till en anläggning i listan, justerar formeln, och årets siffra går inte längre att jämföra med förra året. Inte eftersom underliggande data har förändrats, utan eftersom sättet att summera tyst har justerats.
Aggregering är en av de platser där kalkylblad döljer aggregeringsfel, men inte den enda. Liknande frågor gäller för enheter och definitioner: se hur ni fastställer normalisering när källan är ett kalkylblad för steget som ofta kommer före aggregering. Och för att kartlägga hela vägen från rå rad till rapportsiffra, även utan specialiserad programvara, finns hur ni skapar lineage utan verktyg när källan är ett kalkylblad. Båda ansluter till den bredare frågan vad source-to-report mapping egentligen innebär, där aggregering är ett av de steg som dokumenteras.
En aggregeringsregel behöver, precis som en datapunkt, någon som är ansvarig för valet bakom den. Inte den som råkade skriva formeln, utan den som kan förklara varför just detta urval och denna beräkningsmetod har valts, och som godkänner en ändring innan den genomförs. Denna fråga hänger samman med vem som äger definitionen av en datapunkt: definitionen bestämmer vad som mäts, aggregeringsregeln bestämmer hur mätningar sammanförs till en rapportsiffra. Båda hör till någon med namn, inte till ett kalkylblad som går från hand till hand.
Att fastställa aggregeringsregler är ingen engångsövning. Det är en fråga som återkommer varje gång organisationen förändras: en ny anläggning, en ny enhet, en fusion. Därför räcker det inte att dokumentera denna gång; det måste finnas en process som upprepar fastställandet vid varje förändring. Vem som bevakar den processen och när en aggregeringsregel ska revideras är en fråga som anknyter till vem som äger processen därunder, oavsett vem som levererar de enskilda siffrorna.
Denna sida beskriver vad som krävs för att göra aggregering transparent. Data Readiness Scan är verktyget som hjälper till att fastställa detta för era datapunkter: registret, käll-till-rapport-lineage per punkt och ägarskapsreglerna. Det verktyget är under uppbyggnad. Den som redan nu vill börja med detta kan anmäla sig till väntelistan.
Så snart aggregeringsregler är fastställda, med en ägare och en anledning, uppstår en annan typ av arbete: att utföra och kontrollera samma steg, år efter år. Mycket av det utförande arbetet, från att välja rader till att summera tal enligt en fast regel, är den typ av uppgift där en arbetsscan från FTE TO AI kan beräkna vilken del som kan tas över av AI, per uppgift, utifrån vad arbetet exakt innebär.
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.