Best practices

Als je in Nederland leert autorijden, leer je een simpele regel: je rijdt rechts. Dat is niet zomaar een gewoonte, het is een goede afspraak. Iedereen rijdt rechts, dus je weet wat je aan elkaar hebt, en dat voorkomt een hoop ongelukken. Je zou het een best practice kunnen noemen. De beste manier om het te doen.

Maar stel je voor dat je met de boot naar Engeland gaat, de klep gaat open, en jij rijdt netjes de kade op aan de rechterkant van de weg. Dan heb je een probleem. Want daar is precies dezelfde regel, die goed doordachte en volstrekt logische regel, ineens levensgevaarlijk.

Daar wil ik het vandaag over hebben. Over best practices, dus over die adviezen waarvan we hebben afgesproken dat het de goede manier is om iets te doen. Want ik merk dat bij het inzetten van een best practice niet altijd genoeg wordt nagedacht over het “waarom”.

Welkom bij Data met impact. De podcast over de zin en onzin van data, mensen en techniek. Ik ben Jeroen Buisman, en met InfoReports help ik organisaties in het maatschappelijk domein om grip te krijgen op hun informatie.

Laat ik vooraf even dit zeggen: ik wil niet de indruk wekken dat best practices onzin zijn. Dat is niet zo. Integendeel.

Een best practice is het tegenovergestelde van een domme regel. Het is vaak het resultaat van slimme mensen die ergens goed over hebben nagedacht. Die een probleem tegenkwamen, het van alle kanten bekeken, verschillende oplossingen probeerden, en uiteindelijk tot een aanpak kwamen die goed werkte. En die aanpak schreven ze op, zodat de mensen na hen niet opnieuw het wiel hoefden uit te vinden. Dat is waardevol. Daar moeten we zuinig op zijn.

Dus als ik straks kritisch word, begrijp me goed: ik heb niks tegen best practices. Ze zijn het resultaat van goed nadenken over een probleem, en wat daar de oplossing voor is.

Alleen, die goede aanpak is bedacht in een bepaalde situatie, voor een bepaald probleem, onder bepaalde omstandigheden. Net zoals rechts rijden fantastisch werkt, zolang je in het land bent waar het voor bedacht is.

De vraag die we te vaak overslaan is dus simpel: is de situatie waarin deze best practice is ontstaan, ook de situatie waarin ik ‘m wil toepassen?

Voordat ik naar een concreet voorbeeld ga, wil ik twee manieren beschrijven waarop het misgaat. Want een best practice verkeerd gebruiken kan op twee verschillende manieren.

De eerste noem ik het schild.

Dat werkt zo. Er wordt iets gebouwd, of iets ingericht, en achteraf blijkt het niet goed te werken. En dan komt de zin: ja, maar we hebben wel de best practice toegepast. Alsof daarmee de kous af is. Alsof het feit dat je een erkende aanpak hebt gevolgd, je ontslaat van de verantwoordelijkheid voor het resultaat.

Maar zo werkt het natuurlijk niet. De best practice is geen doel op zich. Het doel is dat wat je bouwt, of inricht, werkt. En als je keurig de regel hebt gevolgd en het werkt alsnog niet, dan is dat geen excuus, dan is dat juist het signaal dat je had moeten opletten. Dat je misschien in Engeland reed, met een regel die voor Nederland was bedoeld.

Het schild is verraderlijk, want het klinkt professioneel. Je hebt je aan de standaard gehouden, wie kan daar iets van zeggen? Maar het is een manier om je te verstoppen achter de regel, in plaats van je verantwoordelijk te voelen voor de uitkomst.

De tweede manier is de automatische piloot.

Dan pas je een best practice toe zonder je ooit af te vragen of hij hier wel geldt. Gewoon “omdat het zo hoort”. Omdat het de best practice is, en dat is toch per definitie de goede manier?

Het denken wordt daar uitgeschakeld. Je volgt de regel omdat het de regel is, en je stelt de vraag naar de context niet meer. Je rijdt rechts, want zo doe je dat, en je kijkt niet meer op naar het bord waarop staat dat je net de grens over bent.

Dit gebeurt vaker dan je zou denken, en het gebeurt juist bij goede, ervaren mensen. Want die kennen hun best practices, die hebben ze honderd keer toegepast, en dat gaat op een gegeven moment vanzelf, zonder dat er nog een vraag bij komt kijken. Terwijl de wereld verandert, en de context verandert, en een aanpak die tien jaar geleden de beste was, dat vandaag misschien niet meer is. Of dat de best practice nog steeds heel actueel is, maar gewoon niet voor de situatie die zich voordoet.

Ik wil dit concreet maken met één voorbeeld, en ik kies er eentje uit mijn vakgebied dat laat zien hoe een best practice zelf ook meebeweegt met de tijd. Het wordt heel even wat technischer, maar ik leg het onderweg uit, dus blijf vooral hangen.

Het gaat over iets wat normaliseren heet. Ik leg het simpel uit. Als je gegevens opslaat in een database, wil je voorkomen dat je dezelfde informatie op tien plekken tegelijk hebt staan. Want als je het dan ergens wijzigt en op de andere negen plekken vergeet, klopt het niet meer. Normaliseren is het netjes opsplitsen van je gegevens zodat elk feit maar op één plek staat. Eén keer opslaan, en overal ernaar verwijzen. Denk aan het specialisme van een zorgverlener, of de naam van een verzekeraar. In de meest simpele vorm van een database heb je gewoon één grote bak met gegevens waar alles in staat, en om in een ziekenhuis-voorbeeld te blijven: voor elke uitgevoerde verrichting sla je ook de naam van de patiënt op, en de naam van de zorgverlener, en de naam van de verrichting, en noem maar op. Is makkelijk, alles bij elkaar, maar zo kan je dus wel meerdere velden hebben met de naam van een zorgverlener: aanvrager en uitvoerder. En wat doe je dan als er iets wijzigt in de gegevens van de zorgverlener? Dan moet je al die velden langs, en op iedere regel in de bak met gegevens dat aan gaan passen. Niet handig. Foutgevoelig. Onoverzichtelijk.

De oplossing is normaliseren: je maakt in plaats van die ene grote bak met gegevens aparte bakjes per soort gegevens. Een bakje, of tabel, voor de patiëntgegevens, en een tabel voor de verrichtingen, en een tabel voor de zorgverleners. En vanuit de tabel met uitgevoerde verrichtingen heb je alleen een verwijzing naar die tabellen: een patiëntnummer, een zorgverlenercode, een verrichtingcode. Veel eenvoudiger in het onderhoud.

Dat is al decennialang een keiharde best practice, en terecht. Want in de systemen waar het voor bedacht is, de systemen waarin je de dagelijkse administratie bijhoudt, waarin je voortdurend dingen toevoegt en wijzigt, is dat precies wat je wilt. Daar voorkomt het fouten, en daar is normaliseren gewoon goed vakmanschap.

Maar toen kwam er een ander soort gebruik op. Niet het bijhouden van de administratie, maar het analyseren ervan. Rapportages maken, trends bekijken, grote hoeveelheden gegevens doorrekenen. Een andere wereld, met een ander doel. En de mensen die dat gingen bouwen, namen in eerste instantie hun vertrouwde best practice gewoon mee. Normaliseren, want zo hoort het. De automatische piloot.

En toen liep men tegen iets aan. Want voor analyse en rapportage is al dat opsplitsen juist onhandig. Je moet de gegevens telkens weer met veel moeite aan elkaar knopen om een vraag beantwoord te krijgen, en het wordt traag en ingewikkeld. Om te weten te komen hoeveel verrichtingen door een specialisme in een jaar zijn uitgevoerd moet je twee koppelingen leggen: van uitgevoerde verrichtingen naar zorgverlener om te weten te komen om welk specialisme het gaat, en daarna naar specialisme om te weten wat de naam van het specialisme is. En elke keer zo’n koppeling leggen is “duur”, in termen van computercapaciteit. Hoe minder je dat hoeft te doen, hoe beter het is, tenminste, als het je gaat om zo snel mogelijk veel gegevens bij elkaar te harken. De best practice die in de ene wereld goed was, werkte in de andere wereld averechts.

Maar men bleef daar niet in hangen. Slimme mensen keken naar dat probleem en bedachten een andere aanpak, eentje die juist wél paste bij analyse en rapportage. Een aanpak waarin je gegevens niet maximaal opsplitst, maar juist slim samenbrengt rondom de vraag die je wilt beantwoorden. En dat werd een nieuwe best practice, voor die nieuwe context.

Dus wat je hier ziet, is de hele levensloop. Een goede best practice, bedacht voor een bepaalde situatie. Die klakkeloos wordt meegenomen naar een nieuwe situatie waar hij niet past. Dat het daar problemen oplevert. En dat er, door goed na te denken, een nieuwe best practice ontstaat die wél klopt. De regel was niet dom. Hij was alleen niet voor die plek gemaakt.

Ik zou nog een reeks voorbeelden kunnen bespreken. Het advies om alles te documenteren, dat prachtig klinkt, tot je een berg documentatie hebt die niemand bijhoudt en die dus niet meer klopt, wat erger is dan geen documentatie. Of het streven naar één centrale bron van waarheid, een mooi principe, tot je er dingen mee samenperst die eigenlijk niet bij elkaar horen. Maar ik ga ze niet allemaal uitdiepen, want het gaat me niet om de voorbeelden. Het gaat me om wat eronder zit, en dat is nadenken.

Alleen, als ik het daarbij laat, dan zeg ik iets wat lekker klinkt en waar je niks aan hebt. Denk zelf na. Ja, dank je wel. Dus laat ik daar even wat verder op ingaan, want zo eenvoudig ligt het niet.

Om te beginnen dit: er is een goede reden waarom we niet bij elke best practice stilstaan. Een best practice is er juist om je dat denkwerk te besparen. Dat is nou net de bedoeling ervan.

Stel je voor dat je elke keer als je iets inricht, opnieuw vanaf nul moet beredeneren hoe je dat het beste aanpakt. Dan kom je nergens. Je bent maanden bezig voordat er iets staat, en de kans is groot dat je onderweg fouten maakt die anderen allang hebben opgelost. Dat je kunt terugvallen op wat anderen hebben uitgezocht, is pure winst.

Dus als iemand zegt dat je gewoon altijd zelf moet nadenken, dan klopt dat niet helemaal. Je kunt niet óveral over nadenken. Je aandacht is beperkt, en verreweg de meeste dingen doe je op de automatische piloot omdat dat prima werkt. Dat is gewoon hoe je door je dag komt.

De echte vraag is dus wanneer je stopt om na te denken. En vooral: hoe je merkt dat dat moment er is.

Volgens mij zit het antwoord in het waarom.

Een best practice is een oplossing. En bij elke oplossing hoort een probleem. Iemand liep ergens tegenaan, zocht uit hoe dat beter kon, en schreef de aanpak op. Maar in de overdracht raakt dat probleem vaak zoek. Wat overblijft is de regel: zo doen we dat hier. Het waarom verdwijnt, en de wat blijft staan.

Zodra dat gebeurt, kun je niet meer beoordelen of de regel van toepassing is. Want om dat te kunnen beoordelen moet je weten welk probleem hij oplost. Ken je dat probleem, dan kun je jezelf de vraag stellen of het hier ook speelt. Ken je alleen de regel, dan kun je twee dingen doen: gehoorzamen, of gokken. Allebei niet ideaal.

Dat maakt het waarom achter een regel geen wetenswaardigheid, maar cruciale informatie. Het is het enige waarmee je kunt oordelen.

En er zijn een paar momenten waarop het de moeite waard is om even op te kijken. Als je niet kunt uitleggen waarom een regel bestaat, bijvoorbeeld. Als iemand die net binnen is vraagt waarom jullie het zo doen, en niemand weet het antwoord, of het antwoord is een dooddoener. Als de situatie duidelijk anders is dan die waar de aanpak voor bedacht is. Of als het resultaat niet is wat je verwacht, terwijl je alles volgens het boekje hebt gedaan.

Dat laatste is misschien wel het duidelijkste signaal. Als je de regels netjes hebt gevolgd en het werkt toch niet, dan moet je je afvragen of de regels wel bij de situatie passen.

Maar je moet er zelf even voor stoppen, net op het moment dat het eigenlijk het makkelijkst is om gewoon door te gaan. Even opkijken, en controleren of je nog in Nederland bent, of dat je net van de boot bent gereden.

Nou, dan is er nog een kant die ik niet wil overslaan.

Een best practice negeren omdat je het zelf beter denkt te weten, zonder dat je kunt uitleggen waarom, is net zo gemakzuchtig als hem klakkeloos toepassen. Het is dezelfde denkfout, alleen dan de andere kant op. En het is nog risicovoller ook, want nu heb je de ervaring van anderen niet eens achter je staan.

Wie afwijkt van een gangbare aanpak, neemt daarmee de verantwoordelijkheid om uit te leggen waarom. Welk probleem lost die best practice op? Waarom speelt dat hier niet, of waarom lost onze aanpak het beter op? Kun je die vragen beantwoorden, dan is afwijken vakwerk. Kun je dat niet, dan is het gokken met een goed gevoel.

Dat is de spiegel van het schild. Bij het schild verstop je je achter de regel om geen verantwoordelijkheid te hoeven nemen voor de uitkomst. Bij een onderbouwde afwijking neem je die verantwoordelijkheid juist wel. Het gaat in beide gevallen om dezelfde vraag: sta je achter de keuze die je maakt, en kun je uitleggen waarom je hem gemaakt hebt?

Best practices zijn waardevol. Ze zijn het resultaat van ervaring en van slim nadenken, en het zou dom zijn om ze te negeren. Maar ze zijn een hulpmiddel, geen vervanging voor je eigen oordeel.

Dus de volgende keer dat iemand zegt: we doen het zo, want het is de best practice, is dat geen slecht begin. Maar het is ook niet het einde van het gesprek. De echte vraag komt daarna. Welk probleem loste die best practice ook alweer op? En hebben wij dat probleem, hier, vandaag? En als het antwoord ja is, dan pas je die best practice toe omdat je weet waarom, en niet omdat het nu eenmaal zo hoort.

Want onthoud: een goed antwoord begint altijd met een betere vraag.

Bedankt voor het luisteren. Vond je deze aflevering iets om over door te denken? Deel hem dan met iemand die ook wel eens een best practice toepast. En wil je weten hoe wij bij InfoReports naar dit soort vraagstukken kijken? Kijk dan op inforeports.nl. Tot de volgende keer.