Maak eerst dezelfde scope vergelijkbaar
Twee voorstellen zijn pas eerlijk te vergelijken wanneer ze hetzelfde probleem en dezelfde eerste versie beschrijven. Bepaal eerst per procesonderdeel of standaardsoftware, een hybride koppeling of maatwerk logisch is. Laat daarna per offerte benoemen welke gebruikers, processen, schermen, rollen, rapportages en koppelingen binnen de scope vallen. Controleer ook welke onderdelen expliciet buiten de prijs blijven. Een lage totaalprijs zegt weinig als migratie, testen of belangrijke integraties later apart worden berekend.
Werk bij voorkeur met een korte lijst van gewenste uitkomsten in plaats van alleen functies. Bijvoorbeeld: een verkoper ziet alle open opvolgtaken, een planner voorkomt dubbele afspraken en een manager kan de actuele pipeline controleren. Zo ontdek je sneller of leveranciers hetzelfde resultaat aanbieden of ieder een andere interpretatie hebben gemaakt.
Vraag om concrete acceptatiecriteria
Een planning met fases is nuttig, maar zonder acceptatiecriteria blijft onduidelijk wanneer een onderdeel werkelijk klaar is. Vraag per belangrijke flow welke invoer wordt getest, welk resultaat verwacht wordt en wie de controle uitvoert. Denk ook aan foutmeldingen, rechten per rol, mobiel gebruik en gedrag wanneer een koppeling tijdelijk niet beschikbaar is.
Leg daarnaast vast hoe bevindingen worden afgehandeld. Welke punten zijn fouten binnen de afgesproken scope, welke punten zijn nieuwe wensen en wanneer mag een fase worden goedgekeurd? Dit is geen vervanging voor juridisch advies, maar wel een praktische manier om gesprekken over oplevering en meerwerk veel concreter te maken.
Controleer data, koppelingen en toegang
Datamigratie wordt vaak in een enkele regel genoemd, terwijl de kwaliteit van brondata grote invloed heeft op het werk. Vraag welke bronnen worden overgezet, wie opschoont en mapt, hoeveel proefmigraties zijn inbegrepen en hoe totalen of steekproeven na de migratie worden gecontroleerd. Bij koppelingen wil je weten welke systemen, velden, synchronisatierichting en foutafhandeling zijn voorzien.
Bespreek ook welke toegangen je na oplevering ontvangt. Denk aan beheeraccounts, domeinen, hosting, databases, documentatie, exportmogelijkheden en waar relevant de afspraken rond broncode. De precieze rechten horen in de overeenkomst thuis; de offerte moet in elk geval voorkomen dat essentiële onderdelen pas na ondertekening onderwerp van gesprek worden.
Maak beheer en wijzigingen zichtbaar
Software blijft na livegang bewegen. Nieuwe medewerkers, veranderende processen, updates van gekoppelde systemen en gebruikersvragen zorgen voor beheerwerk. Vergelijk daarom niet alleen de bouwprijs, maar ook wat monitoring, back-ups, beveiligingsupdates, ondersteuning en kleine aanpassingen betekenen. Vraag welke reactieroutes bestaan en welke werkzaamheden buiten een beheerafspraak vallen.
Voor wijzigingswerk is een eenvoudige werkwijze belangrijk: hoe wordt een wens beschreven, wie schat impact en kosten, wanneer beslist de opdrachtgever en hoe wordt de planning aangepast? Een leverancier hoeft niet iedere toekomstige wijziging vooraf te prijzen, maar moet wel duidelijk maken hoe verrassingen worden beheerst.
Beoordeel aanpak en samenwerking, niet alleen uren
Een urenraming vertelt nog niet wie het werk uitvoert en hoe beslissingen worden genomen. Vraag wie productvragen stelt, wie techniek bouwt, wie test en wie tijdens het traject het vaste aanspreekpunt is. Controleer hoeveel tijd van jouw eigen team nodig is voor interviews, feedback, data, acceptatie en training. Die interne inzet bepaalt mede of de planning haalbaar is.
Een sterke offerte maakt onzekerheid zichtbaar. Bij onderdelen die nog onderzocht moeten worden, is een korte discovery, prototype of technische proef vaak eerlijker dan een schijnbaar exact bedrag. Vergelijk voorstellen daarom ook op de manier waarop risico, voortgang en keuzes worden gedeeld.
Gebruik een gewogen beslismatrix
Zet de belangrijkste criteria in een matrix en geef vooraf gewicht aan wat voor jouw bedrijf telt. Een bruikbare verdeling kan bestaan uit begrip van het proces, volledigheid van scope, acceptatie en kwaliteit, migratie en koppelingen, beheer, samenwerking en totale kosten. Laat meerdere betrokkenen eerst afzonderlijk scoren en bespreek daarna vooral de grootste verschillen.
De winnaar hoeft niet de offerte met de meeste functies te zijn. Het beste voorstel is doorgaans het voorstel waarvan je de aannames begrijpt, de eerste versie kunt toetsen en de gevolgen van latere keuzes kunt overzien. Voor een route met een AI-laag helpt het aparte kader om een AI-automatiseringsofferte te vergelijken op gebruikseenheden, menselijke beslisgrenzen en bewijs. Als de voorstellen nog te verschillend zijn, maak de scope eerst scherper voordat je een leverancier kiest.
Maak van je beoordeling een korte terugvraag: benoem per open punt het offerteonderdeel, wat ontbreekt en welk bewijs je vóór akkoord wilt zien. Bijvoorbeeld: “Is één proefmigratie met controle van aantallen en foutregels inbegrepen, en wie keurt de uitkomst goed?” Wil je vervolgens bedrijfssoftware op maat laten uitwerken, neem dan één proces, de gewenste eerste versie en deze open punten mee. Zo begint het gesprek bij een toetsbare scope, niet bij een losse totaalprijs.
