Een softwareofferte lezen: wat er staat en wat ontbreekt

Een offerte is een tekst die is geschreven om ondertekend te worden, niet om elk risico voor u uit te leggen. Dat is geen verwijt aan de opsteller — het is inherent aan het genre. Wat een offerte wél doet, is een reeks regels presenteren die stuk voor stuk om een eigen check vragen. Onderstaand voorbeeld is volledig fictief: geen bestaande leverancier, geen bestaand bedrijf. De structuur — 15 regels, van licentie tot opzegtermijn — is wel representatief voor wat er in de praktijk op uw bureau kan belanden.

De reden dat offertes op deze manier zijn opgebouwd, is niet per se onwelwillend. Een leverancier die een concreet, afgebakend traject aanbiedt, moet ergens de grens trekken tussen wat met zekerheid te begroten is en wat afhangt van factoren die pas tijdens het traject duidelijk worden — de staat van uw data, de complexiteit van een koppeling, de snelheid waarmee uw organisatie besluiten neemt. Die grens wordt zichtbaar in woorden als "indicatief", "standaard" en "circa". Het is aan u om, voordat u tekent, elk van die woorden te vertalen naar een concreet antwoord: hoeveel kán dit bedrag maximaal worden, en wie draagt het risico als dat gebeurt?

De voorbeeldofferte

Offerte van "Voorbeeld Software B.V." aan "Fictief Bedrijf B.V.", 25 gebruikers, ter illustratie — niet gebaseerd op een bestaande leverancier of een bestaand traject.

Vijf regels uitgelicht

Niet elke regel weegt even zwaar. Vijf regels uit de tabel verdienen extra aandacht, omdat ze in de praktijk het vaakst tot een naderhand-verrassing leiden.

Regel 5 — Datamigratie "indicatief"

Het woord "indicatief" is geen juridische term met een vaste betekenis; het is een signaal dat de leverancier de omvang van het werk nog niet volledig kan inschatten. Dat is op zichzelf begrijpelijk — de kwaliteit van uw brondata is voor een buitenstaander vooraf lastig te beoordelen. Het probleem ontstaat wanneer "indicatief" wordt gelezen als "waarschijnlijk het uiteindelijke bedrag", terwijl het eigenlijk betekent "dit kan hoger uitvallen, en de leverancier heeft zich daar contractueel niet aan gebonden".

Regel 6 — Standaardkoppeling zonder specificatie

"Standaard" zegt iets over de manier van bouwen (een kant-en-klare connector in plaats van maatwerk), maar niets over de functionele diepte. Een koppeling die eenmalig een adressenbestand importeert bij livegang, is een heel ander product dan een koppeling die continu facturen tussen twee systemen synchroniseert en foutmeldingen afhandelt. Beide passen onder de noemer "standaardkoppeling".

Regel 8 — Projectmanagement op geschatte uren

Een schatting van 20 uur is een verwachting, geen belofte. Zonder een plafond of een afspraak over wat er gebeurt bij overschrijding, is dit in feite een open post: de 20 uur is het startpunt van de rekening, niet het maximum.

Regel 12 — Hosting optioneel

Optionele hosting klinkt als flexibiliteit, en dat is het ook — mits u weet wat de exit-route is. Als hosting nu bij de leverancier wordt afgenomen, is de vraag niet alleen wat het per maand kost, maar ook: kunt u over twee jaar zelf gaan hosten zonder een nieuw implementatietraject, en wat kost die overstap dan aan tijd en geld?

Regel 15 — Stilzwijgende verlenging

Een contractduur van 12 maanden met stilzwijgende verlenging van weer 12 maanden betekent dat u een moment in de agenda moet zetten om op te zeggen, meestal enkele maanden voor het einde van de looptijd. Mist u dat moment, dan zit u vast aan een nieuw jaar, ongeacht of het traject naar wens verloopt.

De overige tien regels, kort

De overige regels uit de tabel zijn minder risicovol, maar niet risicoloos. Regels 1 tot en met 3 (licentie en modules) verdienen vooral een check op wat er gebeurt bij groei — zie ook de pijler over prijsmodellen. Regel 4 (implementatie) is de plek waar u concreet wilt weten wat "inrichting" omvat: is dat het instellen van standaardvelden, of ook het bouwen van rapportages en workflows op maat? Regels 9, 10, 11 en 14 (testomgeving, support en onderhoud) lijken onschuldig omdat ze "inbegrepen" zijn, maar "inbegrepen" zegt niets over de omvang — een reactietijd van "binnen 2 werkdagen" is iets anders dan "binnen 4 uur", ook al vallen beide onder dezelfde regel "support inbegrepen". Regel 7 (training) is vooral een schaalvraag: twee dagdelen voor 25 gebruikers is een andere verhouding dan twee dagdelen voor 5 gebruikers. Regel 13 (meerwerk) is in feite een blanco cheque totdat u heeft vastgelegd wat wél in de oorspronkelijke scope zit.

De 12 vragen die u schriftelijk stelt

Onderstaande vragen zijn generiek genoeg om bij vrijwel elke softwareofferte te stellen. Vraag ze schriftelijk (e-mail volstaat) zodat het antwoord meetbaar en herleidbaar is — een mondelinge toezegging tijdens een verkoopgesprek telt niet mee als er een geschil ontstaat.

1. Wat gebeurt er met de prijs per gebruiker als ons aantal gebruikers groeit? Vraag naar een staffel of een plafond, niet alleen naar het huidige tarief.
2. Welke posten zijn een richtprijs en welke een vaste prijs? Vraag dit expliciet per regel, niet voor de offerte als geheel.
3. Wat gebeurt er als een richtprijs wordt overschreden — is er een plafond, en wie betaalt het verschil?
4. Wat omvat de datamigratie precies, en wat niet? Vraag om een lijst van bronnen die wel en niet zijn inbegrepen.
5. Wat doet elke koppeling functioneel — eenmalig of doorlopend, welke richting, wie onderhoudt hem na livegang?
6. Is er een maximum aantal uren voor projectmanagement en implementatie, en wat gebeurt er bij overschrijding?
7. Wat is het onderhoudspercentage of updatebeleid, en geldt dat ook voor majeure versie-upgrades?
8. Wat is de opzegtermijn, en wat kost een tussentijdse beëindiging van het contract?
9. Is er prijsindexering, op basis van welke index, en met welke frequentie?
10. Wat kost het om onze eigen data te exporteren als wij besluiten te stoppen? Zie ook het artikel over exitkosten.
11. Welke reactietijd hoort bij de standaard support, en geldt die ook in de eerste weken na livegang?
12. Kunt u twee referenties geven van een klant met een vergelijkbaar aantal gebruikers en een vergelijkbare implementatie?

Deze twaalf vragen zijn met opzet generiek: ze zijn zo geformuleerd dat ze op vrijwel elke offerte voor bedrijfssoftware van toepassing zijn, van een CRM-pakket tot een ERP-systeem. Stel ze niet allemaal tegelijk in één lange e-mail — dat werkt averechts en levert vaak een half beantwoorde lijst op. Stel ze gegroepeerd: eerst de vragen over prijs en schaal (1 tot en met 3), dan de vragen over scope en uren (4 tot en met 8), dan de vragen over contract en exit (9, 10, 12). Bewaar de antwoorden bij de offerte zelf; bij een geschil na livegang is een schriftelijk antwoord op een schriftelijke vraag het enige dat telt, een mondelinge toezegging tijdens een demo of verkoopgesprek meestal niet.

Richtprijs versus vaste prijs

Dit onderscheid bepaalt wie het financiële risico draagt als de werkelijkheid afwijkt van de inschatting. Bij een vaste prijs ligt het risico bij de leverancier: valt het werk tegen, dan is dat voor hun rekening, tenzij er expliciete uitsluitingen in de offerte staan (denk aan "exclusief meerwerk buiten scope"). Bij een richtprijs ligt het risico bij u: de leverancier geeft een inschatting op basis van de op dat moment beschikbare informatie, en heeft zich niet gebonden aan dat bedrag als de werkelijkheid afwijkt.

Geen van beide vormen is per definitie beter. Een vaste prijs is voorspelbaarder, maar leveranciers verwerken doorgaans een risico-opslag in een vaste prijs om hun eigen onzekerheid af te dekken — u betaalt voor de zekerheid. Een richtprijs kan voordeliger uitpakken als het werk meevalt, maar biedt geen garantie als het tegenvalt. De vraag die ertoe doet is niet "welke vorm is beter", maar: staat er bij elke post in de offerte duidelijk welke van de twee het is? In de praktijk laten offertes dit vaak in het midden — een bedrag zonder "vast" of "richt" ervoor, wat bij een geschil tot interpretatieverschil leidt.

Een rekenvoorbeeld maakt het verschil concreet. Stel, de datamigratie uit regel 5 van de voorbeeldofferte (EUR 3.000, indicatief) blijkt in de praktijk 25% meer werk te vergen omdat een van de bronsystemen ongestructureerde exports oplevert. Bij een vaste prijs betaalt u nog altijd EUR 3.000 — de overschrijding is voor rekening van de leverancier, tenzij vooraf een uitsluiting was opgenomen voor "onvoorziene datakwaliteitsproblemen". Bij een richtprijs betaalt u ongeveer EUR 3.750, bovenop het bedrag waarmee u in uw eigen begroting had gerekend. Op één regel van EUR 3.000 is dat verschil van EUR 750 misschien behapbaar; op een offerte waarin meerdere posten als richtprijs zijn genoteerd, telt dat soort afwijkingen op tot een bedrag dat de moeite van vooraf navragen ruimschoots waard is.

Wat "indicatief" echt betekent

Bij uurtarief-maatwerk (zie ook prijsmodellen) wordt vaak een geschat aantal uren genoemd: "circa 140 uur", "indicatief 20 uur", "verwachting 8 tot 12 dagen". Dat woord "indicatief" vertelt u drie dingen tegelijk: er is een inschatting gemaakt op basis van vergelijkbare trajecten, die inschatting is geen belofte, en de uiteindelijke factuur volgt de werkelijk bestede tijd. Dat is op zichzelf een redelijke afspraak — maatwerk laat zich nu eenmaal niet altijd millimeter vooraf begroten — maar het is wel een afspraak die om een aanvullende vraag vraagt: bij welke afwijking van de inschatting wordt u geïnformeerd, en is er een moment waarop u kunt bijsturen voordat de uren doorlopen?

Een bruikbare vraag hierbij is niet "wordt de inschatting gehaald", want dat weet niemand vooraf zeker. Een bruikbare vraag is: "bij welk percentage overschrijding van de inschatting neemt u contact met ons op voordat u verder werkt?" Leg dat percentage schriftelijk vast, bijvoorbeeld 15%, zodat u niet pas bij de eindfactuur ontdekt dat de oorspronkelijke schatting is losgelaten.

"Standaardkoppeling" zonder specificatie

Van alle terugkerende problemen in offertes is dit misschien de meest onderschatte: de term "standaardkoppeling" (of "standaard API-koppeling") suggereert een kant-en-klaar, beproefd onderdeel, terwijl de functionele reikwijdte volledig openligt. Vraag bij elke koppeling naar vier dingen:

• Richting. Leest de koppeling alleen gegevens uit, schrijft hij ze ook terug, of is het een tweerichtingssynchronisatie?
• Frequentie. Gebeurt dit realtime, meerdere keren per dag, of eenmalig bij livegang?
• Foutafhandeling. Wat gebeurt er als een record niet kan worden verwerkt — krijgt iemand een melding, of verdwijnt het stilzwijgend?
• Onderhoud. Wie is verantwoordelijk als het gekoppelde systeem een update krijgt waardoor de koppeling breekt, en wat kost het herstel?

Dit is ook precies de reden dat het TCO-model op deze site met een richtprijs per koppeling rekent in plaats van een vast bedrag: de spreiding in wat een koppeling feitelijk kost, hangt sterk af van de antwoorden op deze vier vragen.

Voordat u tekent

Een offerte doorlezen kost twintig minuten. De vragen uit deze pijler schriftelijk stellen en beantwoord krijgen kost een paar dagen heen en weer mailen. Die paar dagen zijn goedkoper dan een van de acht posten uit dit artikel die achteraf alsnog op de rekening verschijnt. Gebruik de tabel en de 12 vragen hierboven als checklist, en vul bij twijfel over de langetermijnkosten het TCO-model in — dat laat in enkele minuten zien wat een offerte betekent over vijf jaar in plaats van alleen in het eerste jaar.

Een laatste punt over toon: niets van bovenstaande veronderstelt kwade trouw bij de leverancier. De meeste offertes zijn onvolledig omdat volledigheid vooraf simpelweg niet mogelijk is bij een deel van het werk, niet omdat er iets wordt verzwegen. Het verschil tussen een goede en een moeizame samenwerking zit zelden in de offerte zelf, maar in hoe helder beide partijen zijn over wat er gebeurt zodra de werkelijkheid van de inschatting afwijkt. Een leverancier die op de 12 vragen hierboven duidelijke, schriftelijke antwoorden geeft, laat daarmee zien dat die duidelijkheid ook na livegang te verwachten is. Een leverancier die de vragen ontwijkt of alleen mondeling beantwoordt, geeft daarmee evengoed informatie — alleen dan over wat u ná ondertekening kunt verwachten.