Hoe schrijf je een goede RFP voor maatwerk software?

Wat een RFP is, en wat niet.

Een RFP (Request for Proposal) is een offerteaanvraag. Je beschrijft je situatie, je doelen en je eisen, en nodigt meerdere leveranciers uit om een voorstel in te dienen: aanpak, planning en prijs. Bij maatwerk software is dat precies het punt. Je koopt geen kant-en-klaar product met een vaste prijskaart, dus de RFP is het instrument waarmee je de voorstellen van verschillende partijen vergelijkbaar maakt.

Wat een RFP níét is: een technisch ontwerp. Je schrijft op wát je nodig hebt en waarom, niet hoe de leverancier het moet bouwen. Dat "hoe" is juist waar je de partijen op wilt beoordelen.

RFP versus RFI versus RFQ.

Deze drie worden door elkaar gebruikt, maar ze doen iets anders. Een RFI (Request for Information) verkent de markt: wie zijn de spelers, wat is er mogelijk? Een RFP vraagt om een volledig voorstel met aanpak, planning en prijs. Een RFQ (Request for Quotation) vraagt alleen om een prijs voor iets wat al helemaal vastligt. In een softwaretraject gebruik je ze vaak in die volgorde: eerst oriënteren, dan voorstellen opvragen, en pas een RFQ als de oplossing echt tot in detail bekend is.

RFP versus programma van eisen.

Een programma van eisen (PvE) is de gestructureerde lijst met eisen en wensen aan de software. De RFP is het bredere document: het bevat dat PvE, plus je context, de selectiecriteria en het gunningsproces. Kort door de bocht is het PvE dus een onderdeel van je RFP, niet een synoniem ervan.

Wanneer je een RFP inzet voor maatwerk software.

Een RFP is geen doel op zich. Hij is nuttig als je meerdere partijen serieus met elkaar wilt vergelijken, als het traject groot of complex genoeg is om die moeite te rechtvaardigen, en als je eisen redelijk stabiel zijn. Als je een klein of middelgroot traject hebt met twee of drie partijen op je shortlist, is een goed gesprek soms sneller en scherper dan een formeel RFP-proces. Een RFP kost jou tijd om te schrijven en de leveranciers tijd om te beantwoorden. Weeg die investering af tegen wat je eruit haalt.

Wat er in een sterke software-RFP hoort.

Dit is de kern. Een RFP hoeft niet dik te zijn, maar wel compleet op de onderdelen die ertoe doen. De volgende blokken horen er in ieder geval in.

Bedrijfscontext, aanleiding en doelstellingen.

Begin met waar je vandaan komt. Wat doet je organisatie, hoe ziet je huidige situatie eruit en waarom start je dit traject nu? Vertaal dat naar concrete doelen. Niet "we willen efficiënter werken", maar bijvoorbeeld "we willen de doorlooptijd van een offerte terugbrengen van drie dagen naar één". Doelen die je achteraf kunt toetsen, geven leveranciers iets om hun voorstel op te richten.

Scope en afbakening.

Wat valt binnen dit project, en minstens zo belangrijk: wat niet? Een expliciete afbakening voorkomt dat het traject onderweg twee keer zo groot wordt. Benoem ook de raakvlakken met bestaande systemen en processen.

Functionele en niet-functionele eisen.

Functionele eisen beschrijven wat het systeem moet doen: welke acties, welke gebruikersrollen, welke schermen. Niet-functionele eisen gaan over hoe goed het dat moet doen: prestaties, schaalbaarheid, beschikbaarheid, gebruiksvriendelijkheid. Maak die laatste toetsbaar. "De software moet snel zijn" kun je niet nakijken. "De API reageert binnen 200 milliseconden voor 95 procent van de requests" wel. Precies daar zit vaak het verschil tussen een RFP die goede voorstellen oplevert en een die dat niet doet.

Technische eisen en integraties.

Met welke systemen moet de software praten? Denk aan je CRM, ERP, HR-systeem of boekhouding. Beschrijf de koppelingen die kritiek zijn, welke data er heen en weer moet, en of dat realtime moet of periodiek. Koppelingen zijn vaak het onderschatte deel van een maatwerkproject, dus wees hier concreet.

Security en compliance (AVG, NIS2, ISO 27001).

Als de software persoonsgegevens verwerkt, horen AVG-eisen in je RFP. Val je onder NIS2, of lever je aan een organisatie die daaronder valt, dan wordt het serieuzer. De NIS2-richtlijn (formeel Richtlijn (EU) 2022/2555, aangenomen op 14 december 2022) verplicht een reeks basismaatregelen, waaronder afspraken over de beveiliging van je toeleveringsketen, encryptie en incidentafhandeling.

De uiterste datum voor lidstaten om NIS2 om te zetten in nationale wetgeving was 17 oktober 2024. Nederland haalde die niet; de Nederlandse Cyberbeveiligingswet volgde later. Neem in je RFP dus eisen op over ketenveiligheid, incidentmelding en encryptie, en vraag leveranciers expliciet naar certificeringen als ISO 27001. Let op: een ISO 27001-certificaat is waardevol, maar staat niet gelijk aan NIS2-compliance. NIS2 voegt onder meer bestuurdersaansprakelijkheid en een wettelijke meldplicht toe. Wil je hier scherp in staan, dan helpt het om je eisen rond security en privacy vroeg in het proces vast te leggen.

Budget, tijdlijn en mijlpalen.

Veel organisaties laten het budget bewust weg, uit angst overvraagd te worden. Dat werkt averechts. Zonder budgetindicatie krijg je voorstellen die alle kanten op schieten en die je niet kunt vergelijken. Geef een bandbreedte. Zet daarnaast je gewenste tijdlijn en de belangrijkste mijlpalen op papier, zodat leveranciers hun aanpak daarop kunnen afstemmen.

Selectie- en gunningscriteria.

Op welke punten beoordeel je de voorstellen, en hoe zwaar weegt elk punt? Prijs, aanpak, ervaring, technische fit, cultuur. Door de wegingen vooraf vast te leggen, houd je de vergelijking eerlijk en voorkom je een keuze op onderbuikgevoel.

Onderhoud, SLA, doorontwikkeling en exit.

Software is nooit "af". Vraag naar het onderhoud na livegang, naar de SLA (Service Level Agreement) voor reactietijden bij incidenten, en naar hoe doorontwikkeling georganiseerd wordt. En denk aan het einde: hoe voorkom je vendor lock-in, en hoe ziet een exit eruit als je ooit afscheid neemt van de partij? Bij maatwerk is eigenaarschap van de code een belangrijk punt om vast te leggen.

Prioriteer je eisen met de MoSCoW-methode.

Niet elke eis is even belangrijk, en dat mag je gerust laten zien. De MoSCoW-methode verdeelt je eisen in vier categorieën: Must-have (zonder dit werkt het niet), Should-have (belangrijk, maar niet fataal), Could-have (mooi meegenomen) en Won't-have (nu bewust niet). De Must-haves zijn je knock-outcriteria.

De methode is in 1994 bedacht door softwareontwikkelaar Dai Clegg, destijds bij Oracle, en later verankerd in het DSDM-raamwerk voor agile projecten. Een handige vuistregel uit dat raamwerk: laat je Must-haves niet meer dan zestig procent van de totale scope beslaan. Zit je daarboven, dan heb je in feite geen prioriteiten gesteld, en verlies je de flexibiliteit die je bij maatwerk juist nodig hebt.

Veelgemaakte fouten in een software-RFP.

De meeste RFP's stranden op een handvol dezelfde fouten. Overspecificeren staat bovenaan: je schrijft de oplossing zó dicht dat een goede leverancier niet meer kan meedenken. Daarna komen vage, niet-toetsbare eisen, waardoor je voorstellen krijgt die je niet kunt beoordelen. Het weglaten van een budgetindicatie is de derde klassieker. Ook populair: eisen kopiëren uit de RFP van een andere organisatie, waardoor je vraagt om functionaliteit die je helemaal niet nodig hebt.

De vervelendste tegenstrijdigheid komt vaak als laatste: agile willen werken, maar tegelijk een vaste prijs voor een vaste scope eisen. Dat kan niet allebei. Agile betekent dat de scope meebeweegt met wat je onderweg leert. Een fixed-price offerte betekent dat de scope juist vastligt. Vraag je om beide, dan dwing je leveranciers om lucht in hun prijs te stoppen, of je krijgt onvergelijkbare voorstellen. Kies bewust.

Wanneer een RFP niet de beste route is.

Soms is een RFP simpelweg het verkeerde instrument. Bij sterk iteratieve of innovatieve trajecten liggen de eisen vooraf nog niet vast; je weet nog niet precies wat je nodig hebt, want dat ontdek je gaandeweg. Als je die onzekerheid in een dichtgetimmerde RFP propt, dwing je iedereen om te doen alsof het traject voorspelbaar is. Dat is het niet.

In dat geval werkt een andere aanpak beter. Een RFI om eerst de markt te verkennen. Een marktconsultatie. Of een gezamenlijke Kickoff: een korte, intensieve fase waarin je samen met een partij de scope, de eisen en een realistische schatting scherp krijgt, voordat er ook maar een regel code wordt geschreven. Voor veel maatwerktrajecten is dat een eerlijker startpunt dan een formeel RFP-proces, omdat je de eisen samen aanscherpt in plaats van ze vooraf alleen te moeten raden.

Van RFP naar de juiste softwarepartner.

Een goede RFP is het halve werk. De andere helft is het beoordelen van de partijen die reageren: hun ervaring, hun aanpak, hun betrouwbaarheid, en of het klikt. Waar de RFP draait om welke eisen je stelt, draait de selectie om hoe je een partij op die eisen toetst. Dat is een apart vak, met eigen aandachtspunten en red flags. Hoe je dat aanpakt lees je in ons artikel over [softwarepartner kiezen]. Twijfel je of maatwerk sowieso de juiste weg is, dan is dat precies het soort vraag dat thuishoort aan het begin van je digitale transformatie.

Even kort samengevat.

Een RFP voor maatwerk software legt je probleem, je doelen en je eisen vast, niet een kant-en-klare oplossing, zodat je vergelijkbare en realistische voorstellen krijgt. Neem minimaal op: bedrijfscontext, doelen, scope, functionele en niet-functionele eisen, technische eisen en integraties, security en compliance (AVG, NIS2, ISO 27001), een budgetindicatie, tijdlijn, selectiecriteria en afspraken over onderhoud, SLA en vendor lock-in. Prioriteer met MoSCoW en houd je Must-haves onder de zestig procent van de scope. En weet wanneer je moet stoppen: bij sterk iteratieve trajecten is een RFI, een marktconsultatie of een gezamenlijke Sprint 0 vaak effectiever dan een fixed-scope RFP.