Bij aanschaf van nieuwe ict is een programma van eisen (het pve) een belangrijk document. Het beschrijft waar de gevraagde levering of dienst aan moet voldoen en is het handvat bij een eventueel meningsverschil. Hoe stel je een pve op, ofwel een lijst waarin alle relevante onderwerpen behandeld worden?
Behalve dat het pve beschrijft waar de gevraagde levering of dienst aan moet voldoen en bij eventuele latere discussies met een leverancier een belangrijke rol heeft, maakt het opstellen van een pve ook dat je vooraf gedwongen wordt goed over de gewenste dienst of levering na te denken. Daarmee wordt de kans op een naar tevredenheid uitgevoerde opdracht sterk vergroot. De opdrachtgever heeft beter vooraf over zijn wensen nagedacht en de opdrachtnemer weet beter wat van hem verwacht wordt en kan zijn diensten of leveringen hier op inrichten.
In de afgelopen jaren heb ik een checklist opgesteld (en vaak aangevuld) die is te gebruiken om te controleren of een pve volledig is. Let wel dat niet altijd alle onderwerpen van toepassing zullen zijn. ‘Ict’ is immers een breed begrip en kan bestaan uit hardware, software, (cloud)diensten, inhuur, et cetera. Ook maakt uit wie de leveranciers zijn; bij een monopolist stel je andere eisen dan bij startups. Ook de omvang van een verwerving is van belang; gaat het om tien laptops of een nieuwe applicatie voor de Belastingdienst?
De lijst is zo bedoeld om bij het opstellen ervan na te lopen of een op de lijst opgenomen onderwerp gezien het ict-onderwerp relevant is en zo ja, of er afdoende is beschreven wat dan de eisen zijn.
Checklist
- Algemene beschrijving van de gewenste situatie die ook leesbaar is voor een buitenstaander/leek.
- Beschrijving van de doelstellingen van de verwerving. Welke (hogere) doelen moeten behaald worden?
- Gerelateerde documenten die van toepassing zijn zoals userstories, procesbeschrijvingen, de huidige situatie, casebeschrijvingen, projectplannen, gerelateerde projecten)
- Objectspecifieke functionele en technische eisen:
- Wat moet het gevraagde functioneel leveren, wat is (functioneel) de gewenste levering of dienst?
- Alle objectspecifieke eisen. Welke actieradius moet de auto hebben, welke kleur baksteen moet gebruikt worden, welke processor moet de laptop hebben, welke schoonmaakactiviteiten moeten (hoe vaak) worden gedaan?
Algemene overige eisen
Algemene overige eisen. Bepaal of er in het pve wel of niet aandacht besteed moet worden aan:
- Planning van de levering / diensten (en per locatie).
- Looptijd en verlengingen. En waar zijn verlengingen van afhankelijk.
- Eisen omtrent levensduur van het product.
- Aantallen. Ook per locatie, gelijktijdig, wanneer in de tijd.
- Eisen ten gevolge van de omgeving waar het gewenste in moet functioneren (koppelingen / randvoorwaarden / gerelateerde projecten / andere dienstverleners).
- Eigendom (bv bij clouddiensten, lease, huur, terugkopen).
- Hergebruik (bestaand van opdrachtgever of vanuit leverancier).
- Wet en regelgeving.
- Normeringen en standaarden.
- Beveiliging / privacy / persoonsgegevens / geheimhouding.
- Eisen omtrent duurzaamheid(s aspecten)
- Performance / beschikbaarheid / continuïteit / redundancy.
- Schaalbaarheid / flexibiliteit, groei en krimp.
- Welke kpi’s en hoe en wat met rapportage daarover.
- Welke rol heeft de opdrachtgever tijdens de uitvoering van de opdracht.
- Gebruiksvriendelijkheid.
- Te hanteren taal (mondeling en/of schriftelijk).
- Look & feel; van een product.
- Mee te leveren documentatie / handleidingen.
- Zaken die in de toekomst worden voorzien (opties op korte en lange termijn).
- Kwaliteitsborging.
- Verwachte kwaliteitsniveau in het algemeen (welke eisen opnemen om te zorgen dat het geen Dacia wordt als je een Mercedes wil).
- Eisen omtrent het beëindigen van het gevraagde (exitdiensten).
Diensten
Eenmalige diensten (projectdiensten) voor het operationeel krijgen van de levering of dienst.
- Zaken ten aanzien van een plan van aanpak / migratieplan.
- Wijze van ontwikkelen / bouwen / testen.
- Rol van een demo / proof of concept.
- (Manier van) migratie / opleveren / testen.
- Benodigde opleidingen / instructies.
- Eisen aan de (door leverancier) in te zetten medewerkers.
Ongoing-diensten (beheerdiensten).
- Beheerdiensten.
- Onderhoudsdiensten (preventief, correctief).
- Doorontwikkeling.
- Eisen omtrent een sla/dap.
- Governance.
Contractuele eisen.
- Te hanteren (raam)overeenkomst (incl. exitclausule), wachtkamerovereenkomst, bewerkersovereenkomst.
- Rol proof of concept (of test) rondom contractering; voor of na het zetten van de handtekening.
Joost,
Ik heb aan alle kanten van de (onderhandelings)tafel gezeten en moet daarom enigszins lachen om je naïviteit, want hele PVE gaat al mis als je eisen onredelijk zijn. Welke eisen opnemen om te zorgen dat het geen Dacia wordt als je een Mercedes wil geeft dan ook al de vooringenomenheid aan om een rechtszaak van een gelijk speelveld op basis van de functionele vereisten te beginnen want auto is auto en imago van een merk is niet objectief.
Dank OUDLID voor je reactie en leuk dat je wat steekwoorden in ChatGPT hebt ingevoerd om een reactie te maken. Ook goed om te zien dat deze reactie inhoudelijk kant nog wal raakt dus dat er nog wel wat verbetering mogelijk is.
Dat ‘migratieplan’ als onderdeel van de PVE intrigeert wel. Ik zou eerder denken aan een integratieplan. Migratieplan doet vermoeden dat de projectbehoefte is ontstaan uit een voorafgaande mislukking, iets met in zijn totaliteit een end-of-life status (maar dat is volstrekt niet meer van deze tijd en zijn er dus waarschijnlijk eerder fouten gemaakt en ook of juist dan blijven er allerlei aspecten ervan nog van belang bij een volgende investering).
Ook wenselijkheid beschrijving algemenere aspecten ontbreekt of krijgt onvoldoende accent. Wat zijn de verschillen/overeenkomsten tussen de organisaties die ermee gaan werken? Indien één organisatie, wat is de IT-cultuur? Overige applicaties op Oracle? SQL-Server? Progress? Mogen we alles zelf kiezen en gaan jullie dingen dan dubbel of zelfs meervoudig waarborgen? Zijn er DBA’s? Wat voor Applicatiebeheerders? API’s nodig of GUI’s? Zo ja, Rest? Soap? Is anticipatie dan op API’s eventueel wel van belang of mogen we gewoon oud spul van de plank inzetten en de rest later apart in een nieuwe aanbesteding? Wordt er ook niets op dat soort vlakken verlangd van overige aanbieders? Waarop ga je dan eventueel selecteren? Op dit soort dingen krijgen je altijd ‘weet ik niet’, ‘geen flauw idee, maar ik mag ook buiten het bestek helemaal niet met u praten’, enz. Daarom hebben we al sinds 2004 afgezien van iedere aanbesteding waar we naar gekeken hebben. Niets van wat van belang is mag rekening mee worden gehouden of zelfs maar duidelijkheid over komen.
Ik gebruik ChatGPT voor NvI ronden omdat deze terugkerende vragen kennen door de checklijsten. Denk aan vragen over een gemis aan objectiviteit waardoor het gelijke speelveld verstoord wordt. Ik snap dat voldoening van de gebruiker groter is bij een Mercedes maar als we kijken naar ‘geschikt voor gebruik’ of ‘conform de vereisten’ dan is het ook niet zo dat de Dacia ongeschikt is voor een ambtelijke dienst die niet harder mag rijden dan 100 kilometer per uur.
Fenomeen ‘gouden kranen’ waarmee aanbestedende diensten de krant halen gaat erom dat de aanbestedingsplichtige diensten het doel van deze vorm van verwerving niet uit het oog moeten verliezen. Naar aanleiding van vragen vanuit de potentiële aanbieders in NvI ronde vervallen dan ook nog weleens eisen of worden ze veranderd. Want één fabrikant en zes leveranciers betekent dat eerste de broek niet hoeft te laten zakken. En dan ben je niet meer aan het aanbesteden maar aan het inkopen want een monopolist bepaalt de prijs.