En fabrik väger avfall på vågbryggan. En annan fabrik uppskattar det baserat på containervolym. Båda levererar en siffra för samma rad i rapporten. Ingen har ljugit, ingen har gjort ett fel. Det har bara aldrig fastställts exakt vad definitionen av den datapunkten är, och därför har varje enhet valt den mest logiska tolkningen som fanns tillgänglig där.
Detta är inget undantag. Det är det normala tillståndet i en organisation där samma mätvärde levereras av olika team, med olika källsystem och olika historik. Frågan är inte hur ni får bort denna skillnad innan den uppstår. Frågan är vad ni gör med den när ni upptäcker den.
Steget som oftast hoppas över är att definitionen själv finns dokumenterad någonstans. Inte i huvudet på controllern som har gjort det så i flera år, utan i ett register: denna datapunkt betyder detta, mäts på detta sätt, och dessa enheter räknas med eller inte. Vad som är ett giltigt värde inom detta och vem som märker det när en leverans hamnar utanför det beskrivs på sidan om vad ett giltigt värde är och vem som märker det när ett värde hamnar utanför. Utan denna dokumentation blir varje summering över enheter en summering av saker som nästan men inte helt är samma, förpackat i en siffra som nästan verkar entydig.
Denna dokumentation är precis det arbete som Data Readiness Scan gör: inte att skriva om rapporten, utan att bygga upp datapunktsregistret där det för varje datapunkt anges vad det är, var det kommer från och vem som ansvarar för det. Det registret är platsen där skillnaden mellan enheter blir synlig, istället för att bli synlig först efter att siffran redan har summerats.
När ni väl ser att enhet A och enhet B förstår samma datapunkt på olika sätt finns det i stort sett tre vägar.
Den första är att harmonisera: driva igenom en definition för hela organisationen, med alla systemanpassningar det innebär. Det är ofta den rätta vägen på längre sikt, men inte något som är klart från en dag till en annan.
Den andra är att dokumentera och korrigera: låta avvikelsen ligga kvar där den finns, men fastställa hur stor den är och med en fast omräkning säkerställa att totalen blir korrekt. Detta fungerar när skillnaden är stabil och känd — till exempel när en anläggning strukturellt använder en annan mätmetod som kan spåras.
Den tredje är att signalera: inte korrigera, utan sätta en flagga när en leverans avviker från det mönster ni är vana vid från den enheten. Hur ni ställer in en sådan avvikelse och vem som får en anmälan om den beskrivs på sidan om hur ni ställer in en signalavvikelse och vem som märker det när det sker. Denna väg är inte till för att lösa problemet, utan för att förhindra att det förblir oupptäckt medan ni arbetar mot en strukturell lösning.
Vilken väg som är lämplig beror på hur många enheter som avviker, hur stabil avvikelsen är, och hur mycket tid det finns innan siffran går in i en rapporteringsperiod. Det är en avvägning som skiljer sig från organisation till organisation och som detta register inte gör för er — men det gör synligt att avvägningen måste göras.
Definitionsskillnad är ett av de tystaste felen som finns, eftersom varje enhet har rätt för sig. Anläggningen som uppskattar baserat på containervolym gör inget fel inom sin egen process. Problemet uppstår först på den nivå där siffrorna kommer samman, och just där finns ofta ingen utsedd person för att kontrollera om de underliggande definitionerna överhuvudtaget är jämförbara.
Det är anledningen till att ägarskap per datapunkt är lika viktigt som definitionen själv. Vilka kontroller som hör till en datapunkt och vem som märker det när en av dessa kontroller hoppas över beskrivs på sidan om vilka kontroller som hör till en datapunkt och vem som märker det när en saknas. Utan en utsedd ägare förblir frågan 'men vem ser egentligen detta' obesvarad, även om definitionen finns på papper.
Det är frestande att vilja lösa detta problem med ett system som automatiskt normaliserar leveranser. Men ett verktyg som placeras ovanpå en samling odefinierade datapunkter normaliserar ingenting — det förpackar samma skillnader i ett snyggare gränssnitt. Ordningen som håller är att först fastställa definitionen och ägarskapet, och först därefter se vilket system som passar till det. Varför denna ordning inte är slumpmässig beskrivs på sidan om att först köpa ett verktyg eller först bygga upp processen.
När det för varje datapunkt är fastställt vad definitionen är, vem som är ägare och vilka avvikelser som signaleras, uppstår en annan typ av fråga: vem ska framöver utföra det arbete som hör till dessa kontroller — omräkningen, återfrågan hos den enhet som avviker, underhållet av registret självt. En del av det arbetet är repetitivt nog för att överföras till ett automatiskt steg, en del kräver bedömning som förblir hos en människa. Arbetsscanen från FTE TO AI räknar per uppgift ut vilken del av den som kan tas över av AI, baserat på samma typ av konkretisering som detta register: inte frågan om automatisering är möjlig, utan vilken del av vilken uppgift den omfattar.
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.