En signalavvikelse är en regel som säger: om detta värde faller utanför detta intervall, är det något som någon måste granska. Det låter enkelt, men frågan består av tre delar som var för sig måste besvaras. Vad är ett giltigt värde. Vad är en avvikelse från det värdet. Och vem får syn på det. Utan dessa tre är en signal inget mer än ett tal som står någonstans.
Du kan inte definiera en avvikelse utan först att veta vad som är normalt. För en energiförbrukning per filial är det ett intervall som beror på ytstorlek, öppettider och säsong. För ett personalantal är det ett intervall som beror på enhetens storlek. Denna bandbredd måste fastställas per datapunkt innan en signal har någon betydelse. Hur du bestämmer och fastställer den bandbredden beskrivs på vad är ett giltigt värde och vem märker det när det går fel. Utan detta steg ställer du in en signal på ett värde som självt aldrig har prövats, och då signalerar du egentligen ingenting.
En signal kan reagera på olika saker. Det finns den hårda gränsen: ett värde som faller utanför ett fysiskt eller logiskt möjligt intervall, som ett negativt antal medarbetare. Det finns den mjuka gränsen: ett värde som ligger inom det möjliga men avviker starkt från tidigare perioder, som en fördubbling av vattenförbrukningen utan tydlig anledning. Och det finns den jämförande avvikelsen: ett värde som avviker från en jämförbar enhet, som en filial som rapporterar tre gånger så mycket avfall som en filial av samma storlek. Var och en av dessa tre kräver en annan regel och en annan typ av källdata att jämföra med. En mellanhand som bara ser det senaste värdet ser ofta bara den första typen. Den andra och tredje kräver att du har historisk eller jämförbar data inom räckhåll, vilket är en anledning att ta med det redan vid uppsättningen av datapunktregistret.
En avvikelse som inte landar någonstans är inte en signal utan en loggrad. För varje signal måste det fastställas vem den första mottagaren är: det är oftast den som levererar datapunkten, inte den som sammanställer rapporten. Den levererande avdelningen kan kontrollera en orsak vid det tillfälle då minnet ännu är färskt. Vid rapporteringsdeadline har den kontexten ofta försvunnit. Dessutom måste det fastställas vad som händer om den första mottagaren inte reagerar: går signalen vidare till en andra person efter en viss period, eller blir den liggande. Denna fråga hänger direkt samman med det ägarskap du tidigare fastställt per datapunkt, och med de kontroller som gäller för den datapunkten — se vilka kontroller hör till en datapunkt och vem märker det när för hur signalering och kontroll ansluter till varandra.
En avvikelse kan vara ett fel, men kan också vara en verklig förändring: en fusion, en ny filial, ett ändrat rapporteringsår. En signalregel som inte tillåter den distinktionen leder till två problem. Användare som får för många falska signaler ignorerar till slut alla signaler. Användare som får för få signaler missar just den avvikelse som verkligen spelar roll. Båda är en form av skenprecision: det ser ut som att systemet vakar, medan det i praktiken inte längre filtrerar något. Hur du förhindrar det när du ställer in tröskelvärden beskrivs på hur förhindrar ni skenprecision. En del av lösningen är att kräva en anledning när en signal klickas bort: inte för att kontrollera vem som gjorde något fel, utan för att se om tröskelvärdet självt behöver justeras.
En signalregel som är identisk för hela organisationen bortser från att delar av organisationen ibland arbetar med olika definitioner av vad de mäter, även om datapunkten heter samma sak överallt. En filial som avgränsar scope 3-utsläpp bredare än en annan kommer att visa andra värden utan att något är fel. En signalregel som inte tar hänsyn till detta ger falska avvikelser vid varje jämförelse mellan enheter. På vad gör ni med definitioner som skiljer sig per enhet beskrivs hur du fastställer den skillnaden så att signalregeln kan ta hänsyn till den i stället för att förväxla den med ett fel.
Att ställa in en signalavvikelse kräver ingen programvara; det kräver att du per datapunkt vet vad som är giltigt, vad som är en avvikelse, och vem som ser det. Det är precis det slags arbete som Data Readiness Scan kartlägger: datapunktregistret, de tillhörande kvalitetsreglerna och ägarskapet, så att en signal har något att stödja sig på i stället för en lös formel i ett kalkylblad. Själva skanningen är under utveckling; den som redan nu vill börja med detta kan anmäla sig till väntelistan.
När den strukturen finns på plats uppstår en följdfråga: vem ska granska dessa signaler dagligen, och vilken del av det kontrollarbetet är repetitivt nog att lämnas till en maskin. Den frågan hör inte till denna sida, utan till FTE TO AI:s arbetsskanning, som per uppgift beräknar vilken del av arbetet som kan tas över av AI. För granskning av rutinmässiga avvikelser, att fråga efter en orsak hos en fast grupp av dataleverantörer och att föra en signalloggbok är det ofta en relevant fråga.
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.