Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Programma van eisen basis voor ict-vernieuwing

Computable Expert

Joost Lucassen
Senior Consultant, Mitopics. Expert van Computable voor de topics Infrastructuur, ICT-branche en Overheid.

Bij het vernieuwen van ict is het wenselijk over een goed 'programma van eisen' (PvE) te beschikken. Het opstellen van een goed PvE is echter niet makkelijk, zeker niet als dit gedaan wordt door mensen die dit niet eerder hebben gedaan. En vaak is dat het geval.

Het opstellen van een programma van eisen (PvE) wordt regelmatig gedaan door de 'inhoudelijk deskundige', degene die het meeste met het onderwerp van doen heeft. En dat is iemand waarvan de dagelijkse werkzaamheden niet bestaan uit het opstellen van PvE's. Onderstaand daarom vijf aandachtspunten én vijf valkuilen bij het opstellen van een goed PvE:

1) Een PvE moet passen bij de markt, bij wat er te koop is. Daarvoor is marktkennis vereist. Als voorbeeld: Het heeft geen zin om te vragen om een nieuwe auto die 250 km/uur kan, die zuinig is, waar een halve schoolklas in mee kan, en die minder dan tienduizend euro kost. Er zal dus eerst marktkennis moeten worden opgedaan, bijvoorbeeld door een zoektocht op internet maar vaak ook door leveranciers te spreken, door documentatie te bestuderen, door na te gaan hoe andere organisaties een vraagstuk hebben ingevuld of door indicatieve offertes op te vragen. Hierbij is met name belangrijk om helder te krijgen wat de onderscheidende factoren zijn tussen de verschillende beschikbare oplossingen, zo heeft iedere auto een stuur en een stoel, daar hoef je dus eigenlijk niet om te vragen, stoelverwarming of navigatie juist wel.

2) Eisen moeten ondubbelzinnig en helder zijn verwoord. Als dit niet zo is kan er later discussie ontstaan over wat er precies is bedoeld; de leverancier heeft de eis anders geïnterpreteerd als dat deze is bedoeld (en levert bijvoorbeeld een auto die alleen bergaf en met wind mee de 250 km/uur haalt). Daarnaast speelt dat een PVE (en de beantwoording daarvan) in de regel onderdeel worden van het af te sluiten contract waardoor het gewenst is dat teksten eenduidig en helder zijn, ook bij eventuele toekomstige (contractuele) discussies.

3) Een goed PvE bevat eisen maar daarnaast ook wensen. Aan alle eisen moet worden voldaan, aan wensen hoeft niet te worden voldaan. Voldoen aan een wens is van toegevoegde waarde en juist door de wensen kan een leverancier zich onderscheiden, aan de eisen moet iedere leverancier immers voldoen. Bij het beoordelen van offertes zal zo met name de discussie worden gevoerd in welke mate het aanbod voldoet aan de wensen en of de invulling van de wensen een eventueel hogere prijs rechtvaardigt.

4) In een PvE zijn de eisen bij voorkeur zo functioneel mogelijk beschreven. Functioneel beschrijven maakt dat teksten beter begrijpbaar zijn maar maakt vooral ook dat een leverancier enige vrijheid krijgt bij het invullen van het gevraagde. Een (functionele) eis zoals 'ik wil van A naar B' kan door een leverancier worden ingevuld met een auto, trein, fiets, etc, afhankelijk van waar hij goed in is en waarvan de leverancier inschat dat het het beste past bij andere eisen die gesteld worden (zoals bijvoorbeeld 'onderweg kunnen werken'). 

5) Een PvE dient compleet te zijn. Zo dient er aandacht besteed te worden aan functionele zaken, technische zaken, eisen die worden bepaald door de 'omgeving' die van invloed is, eisen aan ontwerp en constructie (en hoe lang moet iets meegaan), logistieke zaken, documentatie, (gebruikers) trainingen, milieu of arbo aspecten, eisen aan verpakkingen, eisen aan bedrijfszekerheid en onderhoud, contractuele eisen, eisen aan het project van de invoering van een nieuwe dienst of product, en eisen omtrent het betalingsproces.

Valkuilen

Bovenstaande maakt duidelijk dat het opstellen van een goed PvE niet even snel gedaan kan worden. De 'inhoudelijk deskundige' van een organisatie zal hier echt even goed de tijd voor moeten vrij maken en ook regelmatig moeten afstemmen met de achterban. Toch kan het dan nog mis gaan. Daarom vijf bekende valkuilen bij het opstellen van een PVE.

De eerste valkuil is dat voorafgaand aan het opstellen van het PvE onvoldoende is nagedacht over de strategische keuzes. Denk hierbij bijvoorbeeld aan het zelf aanschaffen van (ICT) producten versus het afnemen van een dienst uit de markt. Met name bij het afnemen van een dienst kan het zijn dat degene die het PvE opstelt in zijn toekomstige werkzaamheden geraakt wordt doordat zijn taken overgaan naar de (nieuwe) leverancier. In dit geval moet uiteraard goed doordacht worden of het PvE wel door de juiste persoon wordt opgesteld en op basis van welke uitgangspunten. 

Als tweede; Voor een PvE wordt regelmatig als basis een bestaand programma gebruikt van een andere organisatie of van een eerdere eigen aanbesteding. Vaak met tientallen of honderden eisen. In dit geval is het een valkuil dat men geen eisen durft te schrappen, vaak omdat er onvoldoende overzicht en (markt)kennis is of alle (oude) eisen echt wel nodig zijn. Dit leidt er toe dat er ongeveer hetzelfde wordt ingekocht als bij de eerdere (of vergelijkbare) aanbesteding terwijl de markt ondertussen is veranderd en de oude eisen ook niet meer de wensen van de organisatie weerspiegelen. Zeker als organisaties ‘ict als dienst’ willen gaan afnemen gaat dit slecht samen met een PvE dat is opgesteld vanuit het kopen van producten.

Derde valkuil is dat door een gebrek aan marktkennis het PvE wordt opgesteld met een concrete oplossing voor ogen, vaak van een bekende fabrikant of leverancier. De opgestelde technische specificatie passen dan precies bij een productlijn die men voor ogen heeft. Andere fabrikanten of leveranciers (of innovatieve oplossingen) maken zo geen eerlijke kans. Dit komt met name veel voor als medewerkers met een technische achtergrond een PvE gaan opstellen omdat zij vaak denken vanuit de oplossingen die ze kennen.

Vierde valkuil is dat de eisen in het PvE onvoldoende functioneel zijn beschreven waardoor de leveranciers gedwongen worden een oplossing te kiezen die mogelijk niet de best passende oplossing is. Functioneel specificeren is lastig. Veelal komt dit doordat het (zeker bij technisch specialisten) onprettig voelt keuzes open te laten en niet tot in detail voor te schrijven wat men wil. In de praktijk leidt functioneel specificeren echter veelal tot beter passende oplossingen omdat de leverancier zijn kennis kan inzetten om de doelstellingen op de best passende manier te bereiken.

De laatste valkuil is dat het PvE onvoldoende is afgestemd met gerelateerde documenten zoals het af te sluiten contract en de gunningscriteria (of wensen). Ook het contract bevat eisen, bijvoorbeeld over intellectueel eigendom of over boeteclausules. Doordat het contract veelal met het PvE wordt meegestuurd naar de leveranciers is het zaak dat er geen eisen dubbel worden genoemd of dat er tegenstrijdigheden in de verschillende documenten staan. Medewerkers die een PvE opstellen hebben niet altijd voldoende juridische kennis om dit goed te overzien.

Conclusie

Door rekening te houden met bovenstaande valkuilen kan een PvE sterk verbeterd worden. Een alternatief is natuurlijk om een specialist in te zetten, deze heeft verstand van de markt, van vraagstukken die bij vergelijkbare organisaties spelen, van juridische aandachtspunten en natuurlijk van de aanpak. Binnen deze aanpak is het belangrijk dat het PvE een document is dat niet door één iemand wordt opgesteld, het moet een gezamenlijk en gedragen document zijn. Daar zijn interactieve sessies met alle betrokkenen voor nodig. Ook dat is iets wat de eigen medewerkers niet dagelijks doen.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Lees verder


Reacties

Ik heb nogal moeite met het eerste aandachtspunt (Een PvE moet passen bij de markt, bij wat er te koop is.)
Wanneer je eerst gaat kijken naar wat er op de markt is, ga je je eisen al aanpassen naar wat er mogelijk is, en mogelijkerwijs zelfs al toeschrijven naar een specifieke leverancier. Hiermee loop je het risico dat je uitendelijk niet krijgt wat je eigenlijk in gedachten had.

De derde valkuil zou ik aan willen vullen met "zorg dat je weet wat het probleem achter de oplossing is". Dit heeft niet zo zeer te maken met een techneut die de specs opstelt, maar meer met het gebrek aan achtergrondkennis over processen en implementaties. Zeker bij tools die al lange tijd in gebruik zijn zie je dat men de gewoontes en onlogische stappen in de tools als vanzelfsprekend is gaan beschouwen en de "waarom" vraag niet meer weet te beantwoorden.

Eens met PA VA KE dat het eerste aandachtspunt wat onhandig geformuleerd is, maar de strekking dat een PvE zo moet zijn opgesteld dat de markt het kan leveren is wel terecht. In dat licht vind ik het wel jammer dat het hele stuk is geschreven zonder kritische noot dat de inhoudelijk deskundige veelal niet voldoende geëquipeerd is om een PvE zelf op te stellen. Naast het genoemde voorbeeld van het overvragen van de markt zijn er ook voldoende voorbeelden van PvE's die uitgaan van de stand van de techniek van enige jaren geleden.
Als je iets moet doen - zoals het opstellen van een PvE - dat niet tot je dagelijkse werkzaamheden behoort is het in veel gevallen verstandig je te laten bijstaan. Dat staat in de conclusie een beetje als "second best" optie beschreven. Wat mij betreft had het je niet bij laten staan door een expert met stip op 1 gemogen bij de valkuilen.

pve vs requirements, zoiets als afdrukeenheid vs printer, flexibele schijven vs floppy disk ? Dan weet je het wel. Net als op journaal als ze oewebsite zeggen ipv website. Dat wordt nix.
Eerst pve, daarna bduf, dan budget op ? ik dacht dat we daar nu wel uit waren : gewoon beginnen met minimum viable product en dan in stapjes verbeteren, we lezen niet anders :-P Aan het eind van het verhaal komt toch die mislukte schommel met touw aan boom er uit.

@Frank, dat van die inhoudelijke expert en proces deskundige is een beetje kort door de bocht opgeschreven denk ik. Je zegt dat de inhoudelijk deskundige vaak niet goed uitgerust zijn om deze zaken te maken, maar dat ze zich moeten laten bijstaan door een (proces?) expert die dat wel kan? Volgens mij zegt de auteur van het stuk juist dat dit niet een "One Man Show" moet zijn en dus dat die inhoudelijk expert zich moet laten bijstaan door een team vanuit allerlei disciplines. Het is hoe dan ook verkeerd om ergens maar 1 expert op te zetten, want die zal altijd een bevooroordeelde blik hebben (of dat nou de factor techniek, kosten, of de mens is, maakt niet uit), het sleutelwoord is dus: team, maar verlies vooral de techniek niet uit het oog ten faveure van het correct volgen van een proces, daar is niemand bij gebaat...

Jouw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met je persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.