Een fabriek telt afvalgewicht op de weegbrug. Een andere fabriek schat het op basis van containervolume. Beide leveren een cijfer aan voor dezelfde regel in het rapport. Niemand heeft gelogen, niemand heeft een fout gemaakt. Er is alleen nooit vastgelegd wat de definitie van dat datapunt precies is, en dus heeft elk onderdeel de meest logische invulling gekozen die daar voorhanden was.
Dit is geen uitzondering. Het is de normale staat van een organisatie waarin dezelfde metric door verschillende teams, met verschillende bronsystemen en verschillende historie, wordt aangeleverd. De vraag is niet hoe u dit verschil wegkrijgt voordat het ontstaat. De vraag is wat u ermee doet zodra u het ziet.
De stap die meestal wordt overgeslagen, is dat de definitie zelf ergens staat. Niet in het hoofd van de controller die het al jaren zo doet, maar in een register: dit datapunt betekent dit, wordt zo gemeten, en telt deze eenheden wel of niet mee. Wat een geldige waarde daarbinnen is en wie het opvalt als een aanlevering daarbuiten valt, staat beschreven op de pagina over wat een geldige waarde is en wie het merkt als een waarde daarbuiten valt. Zonder die vastlegging is elke optelsom over onderdelen heen een optelsom van dingen die net niet hetzelfde zijn, verpakt in één getal dat net wel eenduidig oogt.
Dit vastleggen is precies het werk van de Data Readiness Scan: niet het rapport opnieuw schrijven, maar het datapuntregister opbouwen waarin voor elk datapunt staat wat het is, waar het vandaan komt en wie ervoor tekent. Dat register is de plek waar het verschil tussen onderdelen zichtbaar wordt, in plaats van pas zichtbaar te worden nadat het cijfer al is opgeteld.
Als u eenmaal ziet dat onderdeel A en onderdeel B iets anders verstaan onder hetzelfde datapunt, zijn er grofweg drie routes.
De eerste is harmoniseren: één definitie afdwingen voor de hele organisatie, met alle systeemaanpassingen die daarbij horen. Dat is vaak de juiste route op de langere termijn, maar niet iets wat van vandaag op morgen klaar is.
De tweede is documenteren en corrigeren: de afwijking laten staan waar die zit, maar vastleggen hoe groot ze is en met een vaste omrekening zorgen dat het totaal wel klopt. Dit werkt als het verschil stabiel en bekend is — bijvoorbeeld wanneer één vestiging structureel een andere meetmethode gebruikt die zich laat herleiden.
De derde is signaleren: niet corrigeren, maar een vlag zetten zodra een aanlevering afwijkt van het patroon dat u van dat onderdeel gewend bent. Hoe u zo'n afwijking instelt en wie daarvan een melding krijgt, staat uitgewerkt op de pagina over hoe u een signaalafwijking instelt en wie het merkt als het gebeurt. Deze route is er niet om het probleem op te lossen, maar om te voorkomen dat het onopgemerkt blijft terwijl u naar een structurele oplossing toewerkt.
Welke route passend is, hangt af van hoeveel onderdelen afwijken, hoe stabiel die afwijking is, en hoeveel tijd er is voordat het cijfer een rapportageperiode ingaat. Dat is een afweging die per organisatie verschilt en die dit register niet voor u maakt — het maakt wel zichtbaar dat de afweging gemaakt moet worden.
Definitieverschil is een van de stilste fouten die er zijn, omdat elk onderdeel apart gelijk heeft. De vestiging die op containervolume schat, doet niets fout binnen haar eigen proces. Het probleem ontstaat pas op het niveau waar de cijfers samenkomen, en juist daar is vaak niemand aangewezen om te controleren of de onderliggende definities überhaupt vergelijkbaar zijn.
Dat is de reden dat eigenaarschap per datapunt net zo belangrijk is als de definitie zelf. Welke controles bij een datapunt horen en wie het merkt als een van die controles wordt overgeslagen, staat beschreven op de pagina over welke controles bij een datapunt horen en wie het merkt als er een ontbreekt. Zonder een aangewezen eigenaar blijft de vraag 'maar wie ziet dit eigenlijk' onbeantwoord, ook als de definitie op papier staat.
Het is verleidelijk om dit probleem te willen oplossen met een systeem dat automatisch aanleveringen normaliseert. Maar een tool die boven een verzameling ongedefinieerde datapunten wordt gezet, normaliseert niets — hij verpakt dezelfde verschillen in een nettere interface. De volgorde die standhoudt, is eerst de definitie en het eigenaarschap vastleggen, en pas daarna kijken welk systeem daarbij past. Waarom die volgorde er niet toevallig is, staat uitgewerkt op de pagina over eerst een tool kopen of eerst het proces inrichten.
Zodra per datapunt vastligt wat de definitie is, wie eigenaar is en welke afwijkingen worden gesignaleerd, ontstaat een ander soort vraag: wie voert straks het werk uit dat bij die controles hoort — het narekenen, het navragen bij het onderdeel dat afwijkt, het bijhouden van het register zelf. Een deel van dat werk is herhaalbaar genoeg om over te dragen aan een automatische stap, een deel vraagt beoordeling die bij een mens blijft. De werkscan van FTE TO AI rekent per taak uit welk deel daarvan door AI is over te nemen, op basis van hetzelfde soort concreetheid als dit register: niet de vraag of automatisering mogelijk is, maar welk deel van welke taak eronder valt.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Antwoorden komen uit de kennisbank van deze site. Geen advies op maat, en geen scan van uw bedrijf.