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.
