Het probleem achter de oplossing

download deze column als pdf

	Ik vind deze column een aanrader
	1203 personen hebben deze column positief beoordeeld

Zoals we wel eens eerder betoogd hebben bestaat een groot deel van het werk van een asset manager uit het verzinnen van oplossingen voor toekomstige problemen. Je zou er bijna van gaan denken dat asset managers notoire zwartkijkers zijn, maar dat is gelukkig niet zo. Het denken in problemen is uiteindelijk slechts een hulpmiddel om te zorgen dat je de beste oplossing vindt voor het probleem dat er speelt. Nu is dit altijd een gevaarlijk statement. Waar ook ter wereld je dit zegt, er staat altijd wel één of andere techneut op die beweert dat ze dit allang doen, al van ver voor de tijd van de uitvinding van het begrip asset management. In zekere zin hebben ze natuurlijk wel een punt[1]. Probleemoplossing en mensheid zijn zeer na aan elkaar verbonden.

Wat we in de praktijk echter nog al eens tegenkomen is dat het probleem niet expliciet gemaakt wordt, maar dat alleen over de oplossing gesproken wordt. Ook dit hebben we wel eens eerder betoogd[2]. Als argument wordt hier dan voor gehanteerd dat iedereen toch weet wat het probleem is en dat het niet nodig is dit te specificeren. Bij doorvragen blijkt het dan te gaan om een asset die een technisch criterium niet haalt, maar waarom dat criterium geldt weet niemand. Hierbij wordt aangenomen dat het probleem voor iedereen duidelijk is. En dat is precies het probleem waar we het vandaag over willen hebben: het documenteren van oplossingen zonder dat het probleem dat ermee opgelost wordt vastgelegd is.

Een simpele test om deze stelling te onderbouwen is de volgende: loop naar een willekeurige onderhoudsmanager en vraag naar de onderhoudsschema’s of onderhoudscontracten die hij onder beheer heeft. In een professionele organisatie kunnen die zo boven water getoverd worden. Als dat niet zo is heb je meteen een aanknopingspunt om asset management te verbeteren. Blader de schema’s en contracten door en stel dan terloops de vraag wat er mis gaat indien de helft van het onderhoud geschrapt wordt of de intervallen verdubbeld worden. Grote kans dat men zelfs in een professionele organisatie hier niet direct antwoord op kan geven. Met een beetje geluk kan men nog vinden met welke tool het schema is geoptimaliseerd of wie er bij betrokken was, maar men moet dan daar verder gaan zoeken om het antwoord te geven. Zolang het tool met optimalisatiebestand of medewerker nog aanwezig is, zul je dat vinden. Maar hoe lang kan je daar vanuit gaan? Tools gaan maar een jaar of vijf mee. Het tool wordt dan misschien wel langer geleverd, maar de downward compatibility houdt een keer op. Het bestand is dus op een gegeven moment niet meer leesbaar. En voor medewerkers geldt ook dat die niet eeuwig meegaan. Zeker in de technische vakken is sprake van een dreigende pensioengolf. Als er dan ook nog eens sprake van is dat de assets die langer meegaan dan medewerkers, zoals in de infrastructuur (denk aan weg, water, elektriciteit en gas), dan is er dus een grote kans dat op een gegeven moment niemand meer weet waarom bepaalde dingen gedaan worden.

Dit doet in alle eerlijkheid een beetje denken aan een experiment dat ooit met apen is uitgevoerd[3]. Hierbij werd midden in een kooi met een aantal apen een ladder geplaatst met daarop een aantal bananen. Elke keer dat een aap de ladder beklom om een banaan te pakken, werden de anderen natgespoten. Apen houden er niet van om nat te worden. Dus toen ze na een tijdje doorkregen dat het kwam omdat een andere aap de ladder beklom, pakten ze de brutale aap die de ladder wilde beklimmen hardhandig aan. Na een tijdje haalde geen aap het meer in zijn hoofd om de ladder te beklimmen. De wetenschappers vervingen toen een aap in de groep. Het eerste wat die nieuwe aap deed was op de ladder af gaan waar de bananen op lagen, om daar onmiddellijk een ongenadig pak slaag van de anderen te krijgen. Na enige tijd kreeg de nieuwe aap door dat het geen goed idee was de ladder te beklimmen. Een tweede aap werd vervangen, enzovoort, tot geen van de originele apen (die het natsproeien had meegemaakt) nog aanwezig was. Maar zelfs als in die compleet nieuwe groep een nieuwe aap werd geplaatst, dan kreeg die toch een pak slaag bij het benaderen van de ladder, ook al wist niemand meer waarom. Het was gewoon de manier waarop dingen gedaan werden.

Willen we hier nu mee zeggen dat je een aap asset management kan leren zolang je maar genoeg bananen hebt? Natuurlijk niet, het gaat er juist om dat een asset manager moet beseffen dat hij geen aap is. Elke handeling, of het nu om operatie, onderhoud of investering gaat, is een keuze. Dit geldt ook als het slechts om de uitvoering van voorschriften draait. Die voorschriften zijn ooit namelijk opgesteld als beste oplossing voor een probleem, maar dat wil niet zeggen dat ze nu nog steeds de beste oplossing zijn. Het idee van wat het beste is kan veranderd zijn, maar er kunnen ook betere oplossingen ontwikkeld zijn. Elke handeling moet dus continu kritisch beoordeeld worden en daarbij helpt het enorm als ook is vastgelegd waarom die handeling is gekozen. Met andere woorden, leg dus altijd vast wat het probleem achter de oplossing is. Doe dit niet in een apart document, maar in de oplossing zelf. Maar om dat de asset managers wijs te maken kan het handig zijn wat bananen en een waterspuit mee te nemen.

John de Croon en Ype Wijnia zijn partner bij  AssetResolutions B.V., een bedrijf dat ze samen hebben opgericht. Periodiek geven ze in deze column hun visie op een aspect van asset management. De columns staan gepubliceerd op de website van AssetResolutions; www.assetresolutions.nl/nl/column

<< terug naar overzicht