IT van je dromen aanbesteden

Stel je wilt het huis van je dromen laten bouwen.
Hoe gaat dat in zijn werk?  Al naar gelang de
portomonee orienteer je je op een huis dat daarbij
in de buurt komt dat je dan besteld en kan laten
mofidiceren binnen de gestelde archtecturale
kaders.   Of je neemt een architect in de hand die
je dromen duidt en daar een maatwerk oplossing
voor ontwerpt.  Je vraagt op basis van het ontwerp
een bouwvergunning aan bij de Gemeente, en die
valideert het ontwerp op allerlei punten.  Na deze
fase zorgt een aannemer voor de realisatie.  Bij
oplevering laat je een bouwkundige de zaak keuren
en na het oplossen van de restpunten ga je over
tot acceptatie.  Wat je in feite doet is het
vertalen van de wensen in de ene hand geven en het
uitvoeren van het bestek in de andere hand,
waarbij verificatie en validatie door
specialistische partijen wordt verzorgt.

Een aannemer laat je geen huis ontwerpen en
een architect laat je het niet bouwen.  Het duo
kan je echter je dromen verwezenlijken; met het
juiste contractbeheer en de onafhankelijke
verificatie en validatie die daarbij hoort.

Stel je wilt het IT systeem van je dromen laten
bouwen.  Hoe gaat dat in zijn werk?  Er wordt een
eisen en wensen pakket opgesteld en daarmee ga je
de boer op.  Bij wat grotere systemen kom je dan
al vaak terecht bij volumespelers.  Die laveren
moeiteloos om alle boterzachte kwaliteitseisen
heen om vervolgens de zaak op laagste prijs te
beslechten.  Het resultaat is dat een IT-aannemer
je huis gaat ontwerpen en bouwen.  Die aannemer
vertaalt je eisen en wensen pakket in een ontwerp
dat het goedkoopst te bouwen is, niet in een
ontwerp dat de eisen en wensen het best gestand
doet.  Dat is namelijk het belang van de
IT-aannemer helemaal niet.  Goede ontwerpers zijn
heel schaars men heeft vooral bouwers, en die
bouwen.

Dat moet dus anders, en dat kan ook anders.  Je
kunt beter je gezond verstand gebruiken en je
realiseren dat dit systeem niets anders is als het
IT-huis van je dromen waar je de komende tijd je
bedrijfsvoering sterk mee gaat ondersteunen.
Ergo, je hebt een ontwerp nodig dat de eisen het
beste uitwerkt.  Dat bestek moet gevalideerd
worden.  Die vertaling van eisen naar een
uitvoeringsontwerp besteed je aan, louter op
kwaliteit.  De prijs doet er nauwelijks toe.  Een
gevalideerd uitvoeringsontwerp is namelijk goud
waard: het is gewoon te bouwen!

Je moet knalharde eisen stellen aan de kwaliteit
van de ontwerpers die het werk gaan doen.  Je laat
ook geen amateurs de balkenlaag van je huis
doorrekenen, dat doet een heus ingenieursbureau.
Een simpele eis in de aanbesteding is dan ook dat
je uitsluitend gebruik wilt maken van mensen met
een echte IT-opleiding.  Daar kun je een
limitatief lijstje van maken, zodat je niet met
lui opgescheept komt te zitten die het
bloemschikpracticum met goed gevolg hebben
afgelegd.  Je moet harde eisen stellen aan het
ervaringsniveau.  Sterker je kunt eisen stellen
aan de methode van ontwerpen.  Ik zou bijvoorbeeld
Systems engineering eisen dat al sinds jaar en dag
is neergelegd in standaards (bijvoorbeeld de
J-STD-016 en aanpalende documenten).  Je kunt
eisen dat de software requirements worden
opgesteld volgens en voldoen aan de eisen gesteld
in de IEEE 830: de hoofdstukindeling is er al,
hoeft niemand meer te bedenken.  Er is een hele
batterij aan dit soort ISO, IEC en IEEE
normen voor IT.  Ik zie het vrijwel nooit in IT
aanbestedingen.  Terwijl het ervan wemelt 
aanbestedingen voor civiele techniek.

Echt goed kunnen ontwerpen is heel lastig en vergt
kennis, kunde en creativiteit en daarnaast
realisme wat betreft uitvoering op de werkvloer.
Het eindproduct van deze fase van de aanbesteding
is een gevalideerd en geverifieerd ontwerp op
uitvoeringsniveau.  Dat is in de civiele wereld
het uitwerkingsniveau waarop je pas een
bouwvergunning kunt krijgen.

Dat bestek kun je gemakkelijker op prijs
aanbesteden: je weet dan immers precies dat de
kwaliteit die nodig is reeds in het ontwerp
verdisconteerd is.  Alle functionele eisen zijn
traceerbaar tot op bestekniveau uitgewerkt.
Uiteraard zijn de zeer belangrijke aspecteisen
(RAMS SHEEP) in balans afgewogen en meegenomen
door het IT-ingenieursbureau.  De aannemer die het
werk mag uitvoeren heeft niet langer de vrijheid
om voor het level van security dat het systeem
nodig heeft, zomaar een oplossing te bedenken.
Die is er al.  De aannemer voert uit, basta.
Wel controleren dus: gedegen contractbeheer.

De IT-aannemer kan op basis van het bestek
veel beter inschatten wat het gaat kosten, en
daarmee kun je realistisch scherpe prijsstellingen
krijgen---gegeven de reeds vaststaande kwaliteit.
De IT-materiaalkeuze is namelijk reeds gemaakt en
is onderbouwd gegeven de eisen en wensen.

Deze aanpak druist in tegen de idee dat je via
publiek-private samenwerkingen tot goede
resultaten komt bij de juiste prikkels en dat je
als opdrachtgever op afstand kunt blijven.  Bij
werken waar IT een significante rol speelt gaat
die vlieger niet op: de praktijk wijst dat keer op
keer uit.  Het klinkt op de tekentafel leuk: een
DBFMO contract en je bent van al het gedoe af.
Het werkt niet zodra IT er onderdeel van wordt en
niet in de laatste plaats omdat je als
opdrachtgever je dromen werkelijk moet laten
omzetten in het bestek dat die dromen ook echt
waarmaakt.

X

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.