Welke controle hoort bij dit datapunt, en wie ziet het als de waarde afwijkt

Een datapunt zonder controle is een getal dat niemand tegenspreekt. Het staat in het rapport, het komt uit een systeem of een spreadsheet, en het wordt geaccepteerd omdat er geen aanleiding is om het te bevragen. Pas als een externe partij een vraag stelt, of als een cijfer plotseling met een factor tien verschuift ten opzichte van vorig jaar, valt op dat er nooit iemand naar heeft gekeken. Dan is het te laat om nog te reconstrueren waar het misging.

De vraag die dit voorkomt is simpel te stellen en lastig te beantwoorden zonder structuur: welke controle horen bij dit datapunt, en wie merkt het als het misgaat. Dat zijn twee vragen, en ze horen allebei een antwoord te hebben voordat een cijfer een rapport in gaat.

Wat een geldige waarde is, en wat niet

Elk datapunt heeft grenzen. Een energieverbruik kan niet negatief zijn. Een fte-aantal is geen decimaal. Een percentage komt niet boven honderd. Dit lijkt vanzelfsprekend, maar in de praktijk staan dit soort grenzen nergens vastgelegd — ze zitten in het hoofd van degene die de data al jaren verwerkt, en verdwijnen zodra die persoon van functie wisselt.

Een geldige waarde vastleggen betekent niet alleen een ondergrens en een bovengrens noteren. Het betekent ook vastleggen in welke eenheid een datapunt wordt aangeleverd, welke datumformaten toegestaan zijn, en of een leeg veld een geldige uitkomst is of een teken dat er iets ontbreekt. Zonder die afspraak wordt elke uitzondering opnieuw beoordeeld, door wie er op dat moment toevallig naar kijkt. Wat daarbij precies telt als geldig, en wanneer een grenswaarde eerder een aanname is dan een regel, staat uitgewerkt op de pagina over wat een geldige waarde is.

Het verschil tussen een fout en een signaal

Niet elke afwijking is een fout. Een datapunt kan volledig binnen de geldige grenzen liggen en toch een signaal zijn — een verbruik dat plotseling daalt, een aantal dat drie keer zo hoog is als vorig kwartaal, een leverancier die voor het eerst in twee jaar geen data aanlevert. Dat zijn geen ongeldige waarden. Het zijn waarden die vragen om een blik van iemand die de context kent.

Een signaalregel is dus iets anders dan een validatieregel. Validatie bepaalt of een waarde kan bestaan. Een signaal bepaalt of een waarde, ook al is die geldig, alsnog een reden is om te kijken. Hoe die drempel wordt ingesteld — vast percentage afwijking, vergelijking met een historische reeks, of een combinatie — hangt af van het datapunt en van hoe stabiel de onderliggende activiteit normaal is. De opzet van zo'n regel, inclusief de afweging tussen te veel en te weinig signalen, staat beschreven op de pagina over het instellen van een signaalafwijking.

Wie het merkt, is geen technische vraag

Een regel die niemand ziet, is geen regel. Als een validatie- of signaalcheck ergens in een systeem afgaat, moet vaststaan wie de melding krijgt en wat die persoon ermee doet. Is het de invoerder van de data, de eigenaar van het datapunt, of iemand die het geheel overziet voordat het rapport wordt samengesteld? Zonder een aangewezen ontvanger verdwijnt een signaal in een log dat niemand raadpleegt.

Dit raakt aan eigenaarschap, en eigenaarschap raakt aan een probleem dat in veel organisaties onopgelost blijft: verschillende onderdelen gebruiken andere definities voor wat op papier hetzelfde datapunt is. De ene vestiging telt fte's inclusief inhuur, de andere niet. Wanneer een signaal afgaat dat een waarde afwijkt, is de eerste vraag vaak niet of de waarde klopt, maar of iedereen het over dezelfde definitie heeft. Hoe u daarmee omgaat, staat op de pagina over verschillende definities tussen onderdelen.

Waarom dit niet begint met een tool

Het is verleidelijk om deze controles te zoeken in een softwarepakket: iets dat automatisch waarschuwt, valideert, en rapporteert. Maar een tool die controles uitvoert op data waarvan niemand heeft vastgelegd wat een geldige waarde is, voert geen controle uit — die geeft alleen een net ogende uitkomst over een proces dat nog steeds niet is doordacht. De regels moeten er eerst zijn, los van welk systeem ze uiteindelijk toepast. Deze volgorde, en waarom hem omdraaien meestal tot teleurstelling leidt, staat toegelicht op de pagina over eerst een tool kopen of eerst het proces inrichten.

Wat dit oplevert voordat er iets wordt gebouwd

Als voor elk datapunt vastligt wat een geldige waarde is, wanneer een signaal afgaat, en wie dat signaal ontvangt, ontstaat een register dat niet alleen documenteert maar ook bruikbaar is als eisenpakket. Dat register is precies wat nodig is om te bepalen wat een systeem — intern gebouwd of ingekocht — straks moet kunnen. Zonder dat eisenpakket wordt elke aanschaf een gok. Hoe u dat vertaalt naar functionele eisen die uit uw eigen proces komen, in plaats van uit een leverancier, staat op de pagina over functionele eisen uit uw eigen proces.