Het ramschaap geeft antwoord

De Meneer-van-Dalen-wacht-op-antwoord van het
systeem denken heet RAMS SHEEP.  Alleen ik merk
keer op keer dat mensen dit massaal niet schijnen
te weten.  Dit beestje vat de belangrijkste
aspecteisen samen die je vaak bij te ontwerpen
systemen tegen zult komen en die je ook in de juiste
mate moet meenemen om een ontwerp te maken dat die
aspecteisen gestand doet.

Die belangrijke aspecteisen kun je zomaar vergeten
zo blijkt uit al het geblunder.  Vandaar het
ezelsbruggetje dat Reliability, Availability,
Maintainability, Safety, Security, Health,
Environment, Economics en Politics betekent.  Je
kunt er vast nog meer bedenken maar als ontwerp,
bouw en exploitatie standaard van goed uitgevoerde
RAMS SHEEP analyses per fase zouden worden
voorzien zouden systemen een stuk beter
functioneren.

Een heel simpel voorbeeld: als je IT maakt en je
moet snel opleveren dan vallen zaken als onderhoud
en beheer al snel af als aandachtspunten die
tijdens de ontwikkeling eigenlijk meegenomen
hadden moeten worden.  De kater komt later nadat
de rommelige spullen operationeeel worden en de
onderhoudskosten zich opstapelen.

Nog een voorbeeld maar dan buiten de IT.  Bij het
ontwerp van een zwembad moet de vloer rond het
bassin glad zijn vanwege hygienerisico's (de H
van Health).  Een gladde vloer maakt gemakkelijk
schoon (M van Maintainability) en er kunnen zich
geen bacterie- en schimmelhaarden in oneffenheden
van de vloer gaan vormen.  Optimaliseren naar de H
kan echter niet.

De bassinvloer moet namelijk juist stroef zijn
vanwege de veiligheid voor personeel en bezoekers
(de S van Safety).  Maar een stroeve vloer maakt
lastiger schoon, en het duurt langer (de A van
Availiability).

En er is natuurlijk stroef en stroef: het moet
niet te stroef zijn als de vloer droog is (dan
verdraai je je knie) en niet te glad als die nat
is (dan breek je je knie).  Het weerstandsverschil
tussen nat en droog mag niet te groot zijn
omdat je dan alsnog uitglijdt door het verschil.
Kortom hier bijten de H en de S elkaar en de S
bijt zichzelf ook nog eens in de staart.

Aspecteisen bijten elkaar bijna per definitie,
daarom zijn ze zo belangrijk om in samenhang te
analyseren.  Mensen zijn echter geneigd om van het
ramschaap slechts 1 aspect mee te nemen: de E van
Economics.  Het moet zo min mogelijk geld kosten.
De zwembadvloer wordt dus de goedkoopste.  Het
gevolg is: geen veilig exploitaarbaar zwembad en
direkt na opening kun je weer sluiten en mag het
nog eens over (de A van Availability).

Het oplossen van dit soort problemen heet:
ontwerpen.  Daar is kennis en kunde voor nodig.
Daar is een gedegen opleiding voor nodig.  Daar is
ervaring voor nodig.  Daar is creativiteit voor
nodig.   Kort en goed: ontwerpen is lastig.  Bent
u al uit de zwembadvloer?  Laat staan dat u uit
een complex ICT project komt als niet alle
condities optimaal zijn om een goed ontwerp te
kunnen realiseren.

Net zoals optimaliseren naar een gladde vloer niet
werkt in het grotere geheel, werkt optimaliseren
naar de laagste prijs evenmin.  Toch is dat
precies wat in Europese aanbestedingen gebeurt:
het gunningscriterium is of laagste prijs, of het
chique economisch meest voordelige inschrijving
(EMVI).

Bij EMVI zou dan de afweging tussen prijs en
prestatie duidelijker naar voren komen.  In
theorie is dat leuk bedacht, maar in de praktijk
lijkt het zelden te werken getuige het falen van
allerlei projecten bij de overheid, en dat loopt
van A(utomatisering) tot Z(wembaden).

Wat veel en vaak gebeurt is klagen: de
leveranciers klagen over de amateuristische klant.
De klanten klagen over de slechte dienstverlening.
Mijn stelling is dat de leverancier niet verweten
kan worden dat deze inspeelt op de makke van de
klant.  Simpelweg omdat als de ene leverancier dat
wel doet, de andere er met de poet vandoor gaat.
Je kunt niet uit principe je mensen op de bank
laten zitten omdat anders je bedrijf kapot gaat.
Daarom is het voor 100% aan de klant om zich
goed te realiseren dat voor de juiste afwegingen
eisen gesteld moeten worden aan de
manier van ontwerpen.

Iedereen snapt dat als meneer van Dalen niet op
antwoord wacht, berekeningen onbetrouwbaar worden
en uitkomsten onbruikbaar.  Evenzo worden
ontwerpen onbetrouwbaar en systemen onbruikbaar
zonder een antwoord van het ramschaap.

X

Meer weten over de wondere wereld van ICT
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Prof. dr Chris Verhoef is hoogleraar informatica
aan de Vrije Universiteit in Amsterdam en
wetenschappelijk adviseur voor overheid en
bedrijfsleven.  Hij schrijft regelmatig een
column in AG II.  Hij is te bereiken via email:
x@cs.vu.nl.  Deze tekst is copyright SDU.  Niets
van deze uitgave mag zonder schriftelijke
toestemming van de uitgever worden overgenomen of
worden gepubliceerd.