Asset management voor dummies

download deze column als pdf

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

Iedereen met een beetje verstand weet dat er makkelijke en moeilijke problemen zijn. Als een computer het niet doet omdat de stekker niet in het stopcontact zit, dan is dat een relatief eenvoudig probleem. Je stopt de stekker in het stopcontact en het ding doet het weer. Het voordeel van eenvoudige problemen is dat heel veel mensen ze kunnen oplossen. Je zou het bij wijze van spreke een chimpansee kunnen leren als je genoeg bananen hebt. Lastiger wordt het als de computer eens in de zoveel tijd een blauw scherm vertoont (voor de Apple gebruikers onder ons: heel lang geleden waren  computers nog veredelde typemachines en gaf het scherm alleen maar letters weer. Een blue screen ziet er ook zo uit). Een Blue screen of Death geeft aan dat er een kritieke fout is opgetreden die niet hersteld kan worden, soms met opgave van de geheugenplaats waar de fout is opgetreden. Voor de meeste gebruikers dus volkomen onbegrijpelijk. Het vinden van de precieze oorzaak en de daarbij behorende oplossing is vrijwel ondoenlijk. In de tientallen jaren  ontwikkeling van chip plus besturingssysteem is telkens voortgebouwd op de vorige generatie, met alle historische fouten er nog in en met allerlei mogelijkheden voor conflicten tussen verschillende generaties code. Om het probleem voor die ene crash op te lossen zou je grote stukken van de code moeten nalopen en eventueel herzien, waarbij je natuurlijk weer nieuwe problemen kunt introduceren. Een echte hersenkraker dus.

Het vreemde van computers is dat er voor dit ogenschijnlijk onoplosbare probleem toch een simpele oplossing bestaat: zet de computer uit, wacht een paar seconden en zet hem weer aan. De kans is groot dat je dan weer normaal aan de slag kunt, omdat de fout waarschijnlijk is veroorzaakt door een of andere exotische combinatie van handelingen. Deze simpele procedure kan de gebruiker zelf uitvoeren. Het is ook het eerste dat in het script van een helpdeskmedewerker staat: heeft u de computer al uit en aan gezet? Als dat niet helpt dan worden vaak een aantal standaardconfiguraties bekeken, op basis van de kenmerken van de fout. Soms kan dat zelfs op afstand worden gedaan. Mocht de helpdeskmedewerker er niet uitkomen, dan is de oplossing al snel een herinstallatie van de computer, of zelfs een compleet nieuwe computer.  Geen helpdeskmedewerker zal ooit de code van de programma’s induiken, dat doen de ontwikkelafdelingen van de softwarebedrijven wel. Met hoge frequentie brengen ze patches en updates uit (zeg maar gewoon reparaties van fouten). Eens in de zoveel tijd brengen ze zelfs een compleet nieuwe versie uit, waarbij ook nieuwe functionaliteiten zijn toegevoegd, wat ook weer een groot potentieel van nieuwe fouten met zich meebrengt.

In de aanpak van de computerproblemen is heel duidelijk een gelaagdheid te zien. Het eerste niveau is dat van de individuele computer die niet doet wat die moet doen. Zo’n lokaal probleem is een knelpunt. Met simpele regels (helpdeskmedewerkers volgen daadwerkelijk een script) wordt daar naar een oplossing gezocht, met als laatste redmiddel vervanging van de computer, wat gezien de kosten van een computer en de kosten van de foutoplossing al snel de beste keuze is. Als een bepaald type knelpunt vaker voorkomt, dan zal de ontwikkelafdeling aan de slag gaan om een meer structurele oplossing te bedenken. Hierbij wordt daadwerkelijk fouten uit de code gehaald, of extra voorwaarden toegevoegd, al blijft het vrijwel altijd binnen de bestaande functionaliteit. Het doel is te voorkomen dat het probleem  in de toekomst nog meer optreedt. Het knelpunt is als het ware gegeneraliseerd tot een risico, een probleem dat mogelijk ergens op gaat treden. Het derde en laatste niveau is dat van de releasewissel. Hierbij wordt de gehele  de software nog eens overwogen, prestatie-eisen herijkt, en mogelijk nieuwe functionaliteiten toegevoegd of verouderde functionaliteiten verwijderd.

De gelaagdheid van problemen is ook goed te herkennen  binnen asset management. Wij gebruiken het onderstaande schema vaak als vertrekpunt.

Voor knelpunten zoals storingen of assets in een slechte conditie stuur je een ploeg op pad met een set simpele instructies die via een beslisboom uitkomen bij 1 technische oplossing. Dat wordt gebudgetteerd in eenheidsprijzen, en daar wordt in de uitvoering ook op gestuurd. Als er een nieuw soort probleem opduikt dan moet je een nieuw standaard recept voor dat probleem verzinnen, en dat vraagt dus een analytische benadering. In de kern is dat het risk based asset management proces, met risicoanalyse, meerdere soorten oplossingen, ook in de vorm hoe je de oplossing laat uitvoeren (andere contracten of specifieke voorwaarden in de SLA). Op het hoogste niveau wordt het echt ingewikkeld, want dan moet je gaan bepalen hoe je de beschikbare resources gaat verdelen tussen de verschillende risico’s die bij elkaar de totale prestatie van het bedrijf gaan bepalen. Als die prestatie onder de maat is noemen we dat een overtreding (je komt gemaakte afspraken niet na), al heeft dit uitdrukkelijk niets te maken met  het al dan niet voldoen aan de wet. Voor die overtredingen zul je in overleg moeten met de stakeholders (lekker ouderwets polderen), want om de prestaties aan de afspraak te laten voldoen kan je immers ook de afspraak aanpassen. Dat samenwerken komt overal in het proces voor overtredingen terug.

Volgens deze logica zijn knelpunten dus simpele problemen. Maar in de praktijk zie je toch vaak dat de slimste mensen ingezet worden op (weliswaar ingewikkelde) knelpunten. Aangezien sommige knelpunten heel dure oplossingen kennen loont het absoluut om daar na te denken in plaats van blind de regels te volgen. Alleen, mensen die zich met knelpunten bezig houden komen vaak aan niets anders meer toe. De knelpunten duiken te pas en te onpas op en schreeuwen om aandacht. Hierdoor blijft er geen tijd over om aan verbetering van de regels bij de simpele knelpunten te werken. Per knelpunt zal het niet zoveel schelen, dus niemand trekt aan de bel. Maar als je bedenkt dat er veel meer eenvoudige knelpunten zijn dan ingewikkelde kom je al snel tot de conclusie dat daar veel meer te verdienen is dan op die paar hersenkrakers van knelpunten. Waarschijnlijk verdien je er zelfs genoeg mee om die incidentele veel te dure oplossing voor een bepaald knelpunt mee te bekostigen. Je hebt er meer aan om in alle gevallen een score van 90 te halen dan in 10% van de gevallen een score van 100 en de rest middelmatig.

Dit is wat we asset management voor dummies noemen. Hou het simpel en zorg voor makkelijk toepasbare regels. Hierdoor kan de gehele organisatie meedoen en wordt veel meer waarde gecreëerd dan wanneer een paar Einsteins in de dop een aantal projecten grondig herzien. Je moet die knappe koppen juist gebruiken om te zorgen dat die simpele regels toch over het geheel gezien het juiste resultaat opleveren. En als je daar appels in plaats van bananen voor nodig hebt, dan is dat een aanvaardbare prijs.

Ype Wijnia is partner bij AssetResolutions B.V., een bedrijf dat hij samen met John de Croon heeft opgericht. Beurtelings geven ze in deze wekelijkse column hun visie op een aspect van asset management. De columns staan gepubliceerd op de website van AssetResolutions, http://www.assetresolutions.nl/nl/column.

<< terug naar overzicht