In mijn boek ‘Anders Kijken en Organiseren’ beschrijf ik waarom het uitwisselen van (impliciete) kennis een zo belangrijke rol speelt in een creatief proces zoals bijvoorbeeld softwareontwikkeling. In dit blog leg ik uit wat impliciete kennis is en ga ik via een casus in op een probleem dat we vaak tegenkomen: het expertprobleem. Een persoon in de organisatie die alles weet van een bepaald onderwerp of systeem en schijnbaar onmisbaar is. Maar die persoon klaagt dat ‘alles op zijn of zijn schouders rust’ of erger nog; hij of zij lijkt zijn omgeving wel te chanteren en het overdragen van kennis wil maar niet lukken.

Impliciete en expliciete kennis

Allereerst: wat is kennis? Er zijn veel definities te vinden. Ik houd me hier bij mijn versie van de definitie van Mathieu Weggeman in zijn boek Kennismanagement (1997). Niet in de laatste plaats omdat mijn compagnon Dirk Dekker destijds betrokken is geweest bij de totstandkoming van dit boek als reflective practitioner van de kennismanagementgroep van Twynstra Gudde. Dan is de cirkel weer rond. Maar vooral ook omdat deze definitie rekening houdt met de ervaringen en vaardigheden die nodig zijn om kennis te vergaren en om met kennis ook daadwerkelijk wat te doen. En daar gaat het uiteindelijk om, zeker in de context van voorspelbaarheid van digitaliseringsprojecten.

Kennis is het persoonlijk vermogen dat iemand in staat stelt een bepaalde taak uit te voeren door gegevens te verbinden met eigen informatie, ervaringen, vaardigheden en attitude.

Kennis is dus persoonlijk, kan niet zomaar worden overgedragen en kan niet worden vastgelegd in systemen. Dat gegeven maakt alleen al dat we met een andere bril kunnen gaan kijken naar bijvoorbeeld het documenteren van software. Maar daarover later meer.

Weggeman illustreert zijn definitie van Kennis met een functie: K = f (I.EVA), waarbij I staat voor Informatie: expliciete kennis. Het product van Ervaring, Vaardigheden en Attitude vormt impliciete kennis.

Expliciete kennis is kennis die is vastgelegd in documentatie, leerboeken, theorieën, handleidingen, werkinstructies, schema’s, enzovoort. Expliciete kennis is daarmee persoonsonafhankelijk en kan worden overgedragen door te lezen en te bestuderen.

Impliciete kennis bestaat uit ervaringen, vaardigheden en attitude (kunnen en willen) en kan worden uitgewisseld door interactie tussen mensen: demonstratie, imiteren en kopiëren in socialisatieprocessen. Van ervaringen en vaardigheden ligt dat misschien wat meer voor de hand dan van attitude. Met attitude wordt hier bedoeld de (impliciete) selectie die je maakt bij het verkrijgen van informatie. Je selecteert voortdurend de informatie die op je afkomt om er wel of niet iets mee te doen. Het gaat hier over vakmanschap en jaren ervaring, gekoppeld aan een persoonlijk beeld van de realiteit én het vermogen tot verbeelding van de toekomst.

In dit boek gebruik ik bovenstaande simplistische weergave van impliciete kennis. Die is oneindig en dat is weergegeven door het infinity-symbool.

Het Expert Probleem

Kennis is macht wordt vaak gezegd. En voor een belangrijk deel is dat zo, zeker waar het gaat om impliciete kennis. Expliciete kennis is tenslotte relatief snel tot je te nemen. Het hebben van veel impliciete kennis in een bepaalde context, kan leiden tot het expertprobleem. Het probleem dat iemand onmisbaar lijkt te zijn omdat hij of zij relevante impliciete kennis heeft die bij niemand anders aanwezig is. Met alle gevolgen van dien.

Ik heb er in vrijwel elke organisatie waar ik heb mogen werken wel voorbeelden van gezien. Vooral in de context van softwareontwikkeling en -beheer, want het belang van impliciete kennis is daar relatief groot vanwege de complexiteit en omvang van bestaande applicatielandschappen. Er is in die context ook een term voor, te weten Single Point of Knowledge. Dit is een verbastering van Single Point of Failure.

Het expertprobleem kenmerkt zich door een ingesleten patroon:

De ander, een collega of manager, zit vaak met een dubbel gevoel. Hij voelt zich wat gechanteerd, maar je kan of wil de expert ook niet missen want dan worden de resultaten niet behaald.

Casus

Een voorbeeld. Ik was in 1999 net verantwoordelijk geworden voor een softwareafdeling die onder meer systemen voor autoverzekeringen bouwde en onderhield. Het was racen tegen de klok om het zogeheten jaar 2000-probleem op te lossen. Veel oudere systemen waren geprogrammeerd zonder rekening te houden met het feit dat JJJJ naast 1JJJ ook wel eens 2JJJ kon worden. Meestal om geheugenruimte te besparen.

Het ‘oude’ autoverzekeringssysteem onder de passende naam OTO, zou niet meer worden aangepast. Het was slecht gedocumenteerd en er was nog maar één medewerker die alle ins en outs van dat enorme grote systeem kende (veel impliciete kennis). Een jaar geleden was men al gestart met een volledig nieuw informatiesysteem genaamd AUTO. Vier maanden voor D-day, kwam men tot de conclusie dat het project AUTO het niet ging halen en werd de stekker eruit getrokken. Er werd besloten om alsnog het OTO-systeem te gaan aanpassen. En o ja, er moest dan ook maar direct een koppeling met RDW worden gebouwd want dat werd ook verplicht vanaf 1 januari 2000.

Precies op het moment dat ik die ene externe medewerker daarover wilde gaan informeren, komt de bewaking naar me toe. Ze vertelden me dat ze daarnet die ene externe medewerker uit het gebouw hadden gezet en overgedragen aan de politie. Wat nu te doen? In die tijd was er (net als nu) een schreeuwend tekort aan getrainde programmeurs. Wij hadden daarom ingetekend op een omscholingsprogramma van de overheid dat als doel had langdurig werkloze WO’ers om te scholen tot programmeur.

Een van het conservatorium omgeschoolde programmeur en een omgeschoolde programmeur die geschiedenis had gestudeerd stapten vrijwillig naar voren toen ik het probleem aan het team voorlegde en naar twee vrijwilligers vroeg. Ze waren een maand binnen. In het team zaten ook programmeurs met heel veel ervaring maar zij durfden hun vingers er niet aan te branden. Ik heb de gok genomen en een paar maanden later was het OTO-systeem klaar voor het jaar 2000 én voor de RDW.

Als ik dit voorbeeld naast de formule K = f (I.EVA) leg, dan was de I(nformatie) voor iedereen gelijk (het was slecht gedocumenteerd, maar de opdracht was simpel). De programmeurs hadden vrijwel geen E(rvaring), de V(aardigheden) hadden ze net getraind in de opleiding, maar vooral de Attitude maakte het in dit geval tot een succes. Het willen en kunnen en het mede daardoor scherp selecteren van de informatie die nodig was om de klus te klaren (welke softwarecoderegels uit de honderdduizenden regels die het systeem groot was), waren doorslaggevend. Ze vlogen het probleem onbevangen aan en wisten dat, wanneer ze erin zouden slagen, ze de organisatie en de verzekerden enorm mee zouden helpen.

De enig manier om weg te komen van het expertprobleem is om het ingesleten patroon te doorbreken. Met desnoods onorthodoxe of contra-intuïtieve maatregelen (het direct vervangen van de expert bijvoorbeeld).

Over het boek

Waarom is het opleveren van een software / IT project zoveel onvoorspelbaarder dan bijvoorbeeld het opleveren van een huis?

Je kan er een boek over schrijven. En dat heb ik dan ook maar eens gedaan. Over hoe gek en ineffectief het eigenlijk is als we een Tayloriaanse benadering (mens/machine metafoor) blijven gebruiken in de besturing van IT zonder dat we het beseffen. Welke rol impliciete kennis, creativiteit, serendepity en leren speelt in softwareontwikkeling. Over irrationaliteit in organisaties en waarom het belangrijk is dat te onderkennen. Hoe andere metaforen je kunnen helpen bij Anders Organiseren door Anders te Kijken. En nog veel meer.

Bestellen of meer informatie >

Meer weten over anders kijken en organiseren? Neem gerust contact met ons op.