csrdready Zet mij op de wachtlijst

Kennisbank

Wat uw proces van een tool eist, weet u pas als u het proces kent

De volgorde die de meeste organisaties omdraaien

De gangbare volgorde is: een tool selecteren, de tool inrichten, en dan hopen dat het proces zich daar wel naar voegt. Dat werkt in de praktijk niet, omdat een tool geen proces meebrengt. Een tool brengt velden mee, koppelingen, dashboards — maar niet de vraag wie in uw organisatie verantwoordelijk is voor het energieverbruik van pand drie, of de facilitair manager die dat cijfer levert weet dat het in de scope 2-rapportage terechtkomt.

De juiste volgorde is omgekeerd: eerst het proces beschrijven, dan pas een tool kiezen op basis van wat dat proces nodig heeft. Dat klinkt als een omweg, maar het is de kortste route, omdat elke functionele eis die u aan een tool stelt, ergens uit uw eigen data-organisatie moet komen. Zonder dat vertrekpunt selecteert u op functies die een leverancier belangrijk vindt, niet op functies die uw knelpunt oplossen.

Wat de verkeerde volgorde kost

De kosten van de verkeerde volgorde zijn niet meteen zichtbaar, want een tool die niet aansluit werkt in eerste instantie prima — voor het deel van het proces dat toevallig overeenkomt met wat de tool verwacht. De rest wordt handmatig omheen gebouwd: een Excel-bijlage hier, een e-mailwisseling daar, een medewerker die precies weet welke stap net buiten het systeem valt. Dat werkt, tot die medewerker vertrekt of de data-omvang groeit.

Wat het kost, hangt af van hoeveel datapunten buiten de tool om lopen en hoe vaak die per rapportagecyclus opnieuw handmatig verzameld moeten worden. Bij een klein aantal punten is dat een acceptabele omweg. Bij een groeiend aantal — meer locaties, meer scope 3-categorieën, meer wetgeving die aanhaakt — wordt de omweg de hoofdroute, en betaalt u structureel voor de mismatch tussen tool en proces. Dat is een andere manier om te zeggen wat er ook op deze pagina staat: een tool boven een ongeorganiseerd proces produceert nettere rapporten over dezelfde onbetrouwbare cijfers.

Functionele eisen komen uit het proces, niet uit een brochure

Een functionele eis is pas een eis als hij ergens uit voortkomt. "De tool moet lineage kunnen tonen" is geen eis totdat u weet dat uw controller drie keer per jaar handmatig moet uitzoeken waar een cijfer vandaan komt. "De tool moet eigenaarschap kunnen vastleggen" is geen eis totdat u heeft gezien dat een datapunt zonder eigenaar bij niemand op de actielijst staat.

Dit is precies waarom het datapuntregister, de source-to-report lineage per datapunt, en de eigenaarschapstoewijzing eerst moeten bestaan, los van welke tool u uiteindelijk kiest. Zodra die drie dingen op papier staan — welk datapunt, waar het vandaan komt, wie ervoor tekent — heeft u een lijst met eisen die niet van een leverancier komt maar van uw eigen organisatie. Die lijst gebruikt u om tools te vergelijken, niet om er blindelings een uit te kiezen. Hoe u dat vergelijken zonder spijt aanpakt, staat beschreven op deze pagina over toolselectie.

Waar deze volgorde in de praktijk vastloopt

De plek waar de data zit, verschilt sterk per sector, en dat bepaalt ook welke functionele eisen relevant zijn. In een bouwbedrijf zit een groot deel van de duurzaamheidsdata bij onderaannemers en op de bouwplaats zelf, zoals beschreven op deze pagina over databronnen in de bouw; daar is een eis rond meerdere externe bronnen per project waarschijnlijk belangrijker dan in andere sectoren. In de installatiebranche ligt de data vaker verspreid over servicebonnen en materiaalregistraties op projectniveau, zoals te lezen is op deze pagina over de installatiebranche; daar telt vooral of een tool losse invoerpunten kan samenvoegen zonder dat iemand dat handmatig doet.

De algemene vraag — eerst het proces inrichten of eerst een tool kopen — wordt op deze pagina verder uitgewerkt, en de kernvraag van deze pagina, welke eisen precies uit uw eigen proces voortkomen, staat samengevat op deze pagina. Beide pagina's vertrekken vanuit hetzelfde punt: de volgorde bepaalt of een eis een eis is, of een gok.

De Data Readiness Scan als vertrekpunt

De Data Readiness Scan legt het datapuntregister, de lineage en het eigenaarschap vast voordat er over een tool wordt gesproken. Dat is geen rapportagetool en geen vragenlijst-oplossing — het is de stap die bepaalt wat een tool voor uw organisatie eigenlijk moet kunnen. Zonder die stap koopt u functies; met die stap koopt u een oplossing voor een probleem dat u kunt aanwijzen.

De scan is in aanbouw. Wie zijn proces op deze manier in kaart wil laten brengen voordat er een toolkeuze wordt gemaakt, kan zich aanmelden voor de wachtlijst en wordt geïnformeerd zodra de scan beschikbaar is.

De volgende vraag: welk werk kan AI overnemen

Zodra het datapuntregister er staat en duidelijk is welk datapunt van welke bron komt en wie ervoor verantwoordelijk is, ontstaat een tweede, natuurlijke vraag: welk deel van het werk daaromheen — het verzamelen, controleren en overzetten van cijfers — is nog mensenwerk, en welk deel kan een systeem overnemen zonder dat de betrouwbaarheid daalt. Die vraag beantwoordt de werkscan van FTE TO AI, die per taak berekent welk deel van het werk over te nemen is door AI. Dat is een andere scan dan de Data Readiness Scan, en een logisch vervolg erop: eerst weten wat de data is en waar die vandaan komt, dan pas kijken welk deel van het handmatige werk daaromheen overbodig kan worden.

Marvinde assistent van de Data Readiness Scan

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.