De opdracht is een middel, niet het vertrekpunt

Een interne vraag komt vaak binnen als een oplossing: “we hebben een nieuw platform nodig”, “het huidige contract moet worden vervangen” of “we willen naar de cloud”. Zo’n formulering kan begrijpelijk zijn, maar ze legt de oplossingsrichting al vast voordat het onderliggende probleem voldoende is onderzocht.

FOD BOSA benadrukt dat de voorbereiding cruciaal is om behoeften voldoende nauwkeurig te bepalen en te omschrijven. Een duidelijke behoefte helpt de markt om relevante en geldige offertes te maken. Ze geeft het projectteam bovendien een toetssteen voor latere keuzes over scope, eisen, prijsmodel en gunning.

KernideeFormuleer eerst welke verandering of publieke waarde nodig is. Bepaal pas daarna welke oplossing, procedure en contractvorm daarbij passen.

Zeven stappen naar een bruikbare behoefte

1. Beschrijf het probleem in de huidige situatie

Leg vast wat vandaag niet goed werkt, voor wie dit een probleem is en wat de gevolgen zijn. Gebruik waar mogelijk feiten: doorlooptijden, incidenten, manuele handelingen, kosten, beveiligingsrisico’s of ontbrekende functionaliteit. Vermijd dat een productnaam als probleembeschrijving wordt gebruikt.

2. Definieer de gewenste resultaten

Maak duidelijk wat na de opdracht aantoonbaar beter moet zijn. Denk aan snellere dienstverlening, hogere beschikbaarheid, betere informatiekwaliteit, minder operationeel risico of eenvoudiger beheer. Resultaten helpen later om functionele eisen, gunningscriteria en KPI’s op elkaar af te stemmen.

3. Breng gebruikers en belanghebbenden samen

Een ICT-opdracht raakt zelden alleen de IT-afdeling. Betrek eindgebruikers, proceseigenaars, security, privacy, architectuur, financiën, juridische ondersteuning, procurement en contractbeheer. Benoem wie beslist, wie adviseert en wie gevolgen ondervindt. Tegenstrijdige verwachtingen worden beter vóór de publicatie opgelost dan tijdens de uitvoering.

4. Bepaal scope én expliciete grenzen

Beschrijf processen, locaties, gebruikersgroepen, gegevens, koppelingen en diensten die binnen de opdracht vallen. Noteer ook wat buiten scope blijft. Controleer afhankelijkheden met bestaande contracten, interne teams en andere projecten. Een onduidelijke grens veroorzaakt vaak wijzigingen, vertraging en discussies over verantwoordelijkheid.

5. Scheid behoeften van oplossingen

Een behoefte beschrijft een noodzakelijk resultaat of vermogen. Een eis vertaalt dat naar een toetsbare verwachting. Een oplossing beschrijft hoe een leverancier dit realiseert. Door die niveaus te scheiden, blijft er ruimte voor marktkennis en innovatie zonder dat essentiële randvoorwaarden verdwijnen.

6. Maak randvoorwaarden en risico’s zichtbaar

Denk onder meer aan budget, timing, continuïteit, informatiebeveiliging, gegevensbescherming, toegankelijkheid, interoperabiliteit, migratie, interne capaciteit en exit. Rangschik risico’s volgens waarschijnlijkheid en impact. Bepaal vervolgens welke risico’s door de opdrachtgever worden beheerst, welke bij de leverancier liggen en welke gezamenlijk moeten worden opgevolgd.

7. Toets de behoefte aan markt en haalbaarheid

Onderzoek of de markt de behoefte kan invullen, welke leveringsmodellen bestaan en welke informatie leveranciers nodig hebben om een degelijke offerte te maken. Een marktconsultatie kan daarvoor nuttig zijn, mits ze zorgvuldig, proportioneel en transparant wordt georganiseerd. Gebruik de uitkomst om de behoefte scherper te maken, niet om één vooraf gekozen oplossing te bevestigen.

Vertaal de analyse naar een compact behoeftedossier

Het resultaat hoeft geen omvangrijk document te zijn. Een bruikbaar behoeftedossier bevat minimaal:

  • de aanleiding en het vastgestelde probleem;
  • de gewenste resultaten en succesindicatoren;
  • de betrokken gebruikers en governance;
  • de scope, volumes en belangrijkste afhankelijkheden;
  • de essentiële randvoorwaarden;
  • de grootste risico’s en aannames;
  • een eerste raming van kosten, timing en interne inspanning;
  • de vragen die nog via marktverkenning moeten worden beantwoord.

Controlelijst vóór u het bestek opstelt

  • Is het probleem beschreven zonder meteen één product of technologie voor te schrijven?
  • Zijn de gewenste resultaten concreet genoeg om later te beoordelen?
  • Zijn eindgebruikers en alle relevante interne disciplines betrokken?
  • Zijn scope, volumes, interfaces en afhankelijkheden bekend?
  • Is onderscheid gemaakt tussen must-haves, voorkeuren en mogelijke oplossingen?
  • Zijn budget, timing, capaciteit, continuïteit en exit meegenomen?
  • Zijn belangrijke aannames en risico’s expliciet vastgelegd?
  • Is bepaald welke vragen nog aan de markt moeten worden gesteld?
Praktische conclusieEen scherpe behoefte voorkomt niet alle wijzigingen. Ze zorgt er wel voor dat wijzigingen bewust kunnen worden beoordeeld tegen de oorspronkelijke doelstellingen, in plaats van het project ongemerkt van richting te laten veranderen.

Officiële achtergrond

Dit artikel biedt algemene informatie en vervangt geen juridisch of professioneel advies voor een concrete plaatsingsprocedure, offerte of overeenkomst.