Offertes vergelijken

De verleiding is om de eindbedragen naast elkaar te zetten en de middelste te kiezen. Dat werkt niet, omdat de goedkoopste offerte vaak goedkoop is doordat er iets niet in zit: het beheer, de koppeling, de migratie of het testen met uw eigen mensen.

Een verschil in prijs zegt pas iets als u weet of het over hetzelfde gaat. Meestal is dat niet zo, en dat is geen kwade opzet maar een verschil in interpretatie van wat u heeft gevraagd.

Er zit nog een systematisch verschil onder dat u niet uit de bedragen kunt afleiden: hoeveel risico elke partij in de prijs heeft verwerkt. Een leverancier die uw vraag goed begrepen heeft, ziet de lastige onderdelen en calculeert die. Een leverancier die het niet doorziet, offreert lager en komt later met meerwerk. Het lage bedrag is dan geen scherpe prijs maar een gemiste inschatting, en dat verschil ziet u alleen aan de aannames.

Een tweede reden dat optellen misleidt: offertes knippen het werk verschillend op. De ene partij zet de invoering als aparte post, de andere verwerkt hem in het uurtarief. De ene rekent hosting apart, de andere niet. Dat maakt het onderste bedrag onvergelijkbaar zonder dat er iets verzwegen wordt.

Het enige wat helpt, is de offertes vertalen naar uw eigen indeling voordat u ze naast elkaar legt. Dat kost een uur en het is het enige moment in het hele traject waarop u de verschillen echt ziet.

Schrijf op wat er moet gebeuren voordat u offertes opvraagt, en stuur die lijst mee. Niet als functionele specificatie van veertig pagina's, maar als opsomming van wat er af moet zijn voordat u het in gebruik neemt.

Vraag leveranciers om per punt aan te geven of het in de prijs zit, apart wordt begroot of buiten scope valt. Dan vergelijkt u antwoorden op dezelfde vragen in plaats van drie verschillende verhalen.

Schrijf op wat het systeem moet kunnen in termen van wat er in uw organisatie gebeurt, niet in termen van functies. 'Een planner maakt op vrijdag het rooster voor de week erna en moet zien wie er beschikbaar is' zegt meer dan 'roostermodule'. Het eerste kunnen leveranciers beprijzen; het tweede kunnen ze alleen aanvinken.

Maak daarbij onderscheid tussen wat het systeem moet kunnen en wat prettig zou zijn. Zonder dat onderscheid krijgt u offertes waarin alles zit, en dat is de duurste variant van iets waar u de helft van gebruikt.

Noem ook wat u nú doet en wat daaraan misgaat. Dat is de informatie waaruit een goede leverancier zijn vragen haalt, en de kwaliteit van die vragen is het beste signaal dat u krijgt over met wie u te maken heeft.

• Migratie van uw bestaande gegevens, inclusief het opschonen dat daarbij hoort.
• Koppelingen met systemen die u al heeft, en het testen daarvan.
• Inrichting: rollen, rechten, formulieren en werkwijzen die per organisatie verschillen.
• Opleiding van uw eigen mensen en de tijd die zij zelf kwijt zijn.
• Beheer en onderhoud na oplevering, en wat daar wel en niet onder valt.

Vraag naar de kosten over vijf jaar, niet over het eerste jaar. Licentie of abonnement, onderhoud, ondersteuning, hosting, en de indexering die daarop wordt toegepast. Dat laatste is een post die in het eerste jaar nul is en over vijf jaar aanzienlijk.

Vraag daarnaast wat er gebeurt als u groeit. Prijsmodellen per gebruiker, per vestiging of per transactie pakken heel verschillend uit als uw organisatie verandert. Reken uw eigen groeiscenario door met het model dat elke partij hanteert.

En vraag naar de kosten van weggaan: dataexport, ondersteuning bij overgang, en de opzegtermijn. Dat is geen wantrouwen maar een normale vraag, en het antwoord zegt veel over hoe de partij naar de relatie kijkt.

De nuttigste vraag bij een offerte is: waar bent u van uitgegaan? Een leverancier die daar concreet op antwoordt, heeft nagedacht. Een leverancier die zegt dat het allemaal wel meevalt, verplaatst het risico naar u.

Vraag ook wat er gebeurt als een aanname niet klopt. Het antwoord daarop verschilt sterk per partij en zegt meer over de samenwerking dan het bedrag onderaan.

De vragen die een leverancier stelt voordat hij offreert, voorspellen meer over de samenwerking dan de offerte zelf. Een partij die doorvraagt naar uw huidige werkwijze, naar wat er nu misgaat en naar wie het systeem gaat gebruiken, bouwt een beeld op. Een partij die alleen vraagt hoeveel gebruikers u heeft, vult een prijslijst in.

Let ook op wat er gebeurt als u iets vraagt dat niet kan. Een leverancier die dat gewoon zegt en een alternatief voorstelt, is over twee jaar prettiger om mee te werken dan een die overal ja op zegt. Dat is het beste voorspellende signaal dat u tijdens een offertetraject krijgt.

En let op wie er aan tafel zit. Als de mensen die het gaan bouwen of begeleiden er niet bij zijn, weet u niet met wie u straks te maken heeft. Vraag daar expliciet naar; het is een normale vraag en het antwoord is informatief.

• Stelt de leverancier vragen over uw proces, of alleen over uw wensenlijst?
• Benoemt hij iets dat volgens hem níét moet worden gebouwd? Dat is een goed teken.
• Wie schuift er aan bij het gesprek, en zijn dat ook de mensen die het werk doen?
• Kunt u een referentie bellen die u zelf uitkiest, in plaats van één die wordt aangedragen?

Maak één tabel waarin elke offerte langs uw eigen lijst wordt gelegd, niet langs de indeling van de leverancier. Per punt: zit het erin, zit het in meerwerk, of zit het er niet in. Dat dwingt u om de offertes te vertalen naar uw eigen taal en het maakt de verschillen zichtbaar die in de bedragen verstopt zitten.

Zet er per partij ook de aannames bij die zij hebben opgeschreven. Als een leverancier ervan uitgaat dat u de gegevens uit uw oude systeem zelf aanlevert, is dat een post die bij u terechtkomt en die in geen enkel bedrag staat.

Bewaar die tabel. Bij de eerste meerwerkdiscussie is dit het document waarmee u terugverwijst naar wat er is afgesproken, en het scheelt u een gesprek dat anders op herinneringen berust.

• Vaste prijs of nacalculatie
• Een programma van eisen schrijven
• Een softwareleverancier kiezen

Wilt u eerst weten of het idee werkt voordat u groot investeert? Bij OneDayBuild laat u in één dag een werkend prototype bouwen.