En fabrik tæller affaldsvægt på vejebroen. En anden fabrik estimerer det baseret på containervolumen. Begge leverer et tal til samme linje i rapporten. Ingen har lyet, ingen har begået en fejl. Der er blot aldrig blevet fastlagt, hvad definitionen af dette datapunkt præcis er, og derfor har hver enhed valgt den mest logiske tolkning, der var tilgængelig.
Dette er ikke en undtagelse. Det er den normale tilstand i en organisation, hvor samme metrik leveres af forskellige teams, med forskellige kildesystemer og forskellig historie. Spørgsmålet er ikke, hvordan De fjerner denne forskel, før den opstår. Spørgsmålet er, hvad De gør med den, når De først ser den.
Det skridt, der oftest springes over, er, at definitionen selv står skrevet et sted. Ikke i hovedet på den controller, der har gjort det på samme måde i årevis, men i et register: dette datapunkt betyder dette, måles på denne måde, og disse enheder tæller med eller ikke. Hvad en gyldig værdi er inden for det, og hvem der bemærker det, hvis en indberetning falder uden for det, er beskrevet på siden om hvad en gyldig værdi er og hvem der bemærker det, hvis det går skævt. Uden denne fastlæggelse er hver sammentælling hen over enheder en sammentælling af ting, der lige akkurat ikke er ens, pakket ind i et tal, der lige akkurat ser entydigt ud.
Denne fastlæggelse er præcis det arbejde, Data Readiness Scan udfører: ikke at skrive rapporten om, men at opbygge det datapunktregister, hvor det for hvert datapunkt fremgår, hvad det er, hvor det kommer fra, og hvem der står bag det. Dette register er stedet, hvor forskellen mellem enheder bliver synlig, i stedet for først at blive synlig, efter tallet allerede er lagt sammen.
Når De først ser, at enhed A og enhed B forstår noget forskelligt ved samme datapunkt, er der groft sagt tre veje.
Den første er at harmonisere: gennemtvinge én definition for hele organisationen, med alle de systemændringer, det medfører. Det er ofte den rigtige vej på længere sigt, men ikke noget, der er klaret fra den ene dag til den anden.
Den anden er at dokumentere og korrigere: lade afvigelsen stå, hvor den er, men fastlægge, hvor stor den er, og med en fast omregning sikre, at totalen alligevel stemmer. Dette virker, når forskellen er stabil og kendt — for eksempel når én lokation strukturelt bruger en anden målemetode, som kan spores tilbage.
Den tredje er at signalere: ikke korrigere, men sætte et flag, når en indberetning afviger fra det mønster, De er vant til fra den enhed. Hvordan De opsætter en sådan afvigelse, og hvem der får en notifikation om det, er udfoldet på siden om hvordan De opsætter en signalafvigelse og hvem der bemærker det, når det sker. Denne vej findes ikke for at løse problemet, men for at forhindre, at det forbliver ubemærket, mens De arbejder hen mod en strukturel løsning.
Hvilken vej der er passende, afhænger af, hvor mange enheder der afviger, hvor stabil den afvigelse er, og hvor meget tid der er, før tallet indgår i en rapporteringsperiode. Det er en afvejning, der varierer fra organisation til organisation, og som dette register ikke træffer for Dem — men det gør synligt, at afvejningen skal træffes.
Definitionsforskel er en af de mest lydløse fejl, der findes, fordi hver enhed for sig har ret. Den lokation, der estimerer på containervolumen, gør intet forkert inden for sin egen proces. Problemet opstår først på det niveau, hvor tallene mødes, og netop dér er der ofte ingen udpeget til at kontrollere, om de underliggende definitioner overhovedet er sammenlignelige.
Det er grunden til, at ejerskab pr. datapunkt er lige så vigtigt som definitionen selv. Hvilke kontroller der hører til et datapunkt, og hvem der bemærker det, hvis en af disse kontroller springes over, er beskrevet på siden om hvilke kontroller der hører til et datapunkt og hvem der bemærker det, hvis en mangler. Uden en udpeget ejer forbliver spørgsmålet 'men hvem ser egentlig dette' ubesvaret, selv når definitionen står på papir.
Det er fristende at ville løse dette problem med et system, der automatisk normaliserer indberetninger. Men et værktøj, der sættes oven på en samling udefinerede datapunkter, normaliserer ingenting — det pakker de samme forskelle ind i en pænere brugerflade. Den rækkefølge, der holder, er først at fastlægge definition og ejerskab, og først derefter se, hvilket system der passer til det. Hvorfor denne rækkefølge ikke er tilfældig, er udfoldet på siden om først et værktøj kob eller først processen på plads.
Når det for hvert datapunkt er fastlagt, hvad definitionen er, hvem der er ejer, og hvilke afvigelser der signaleres, opstår en anden slags spørgsmål: hvem udfører fremover det arbejde, der hører til disse kontroller — genberegningen, forespørgslen til den enhed, der afviger, opdateringen af registret selv. En del af dette arbejde er tilstrækkeligt gentageligt til at overdrage til et automatisk trin, en del kræver en vurdering, der forbliver hos et menneske. FTE TO AI's arbejdsscan beregner for hver opgave, hvor stor en del af den, der kan overtages af AI, baseret på samme slags konkrethed som dette register: ikke spørgsmålet om automatisering er muligt, men hvilken del af hvilken opgave det gælder for.
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.