Vaste prijs of uurtarief voor aanpassingen?

Wanneer u een aanpassing voor Business Central laat bouwen, kan de prijs als vast bedrag zijn afgesproken of naar verbruik worden afgerekend. Beide kunnen verstandig zijn, maar ze passen bij verschillende opdrachten. Dit artikel legt uit wanneer elk model het best werkt, wat een vaste prijs vraagt van de beschrijving en welke vragen u moet stellen, wie de offerte ook geeft. Het geldt ongeacht de leverancier.

Vaste prijs

Met een vaste prijs kent u de prijs vooraf, als de opdracht duidelijk is afgebakend. Dat past bij opdrachten waarbij u weet wat u wilt hebben: een rapport, een nieuw veld met een regel, een afgebakende koppeling.

Het risico ligt bij de leverancier, maar alleen zolang de beschrijving standhoudt. Veranderen de eisen onderweg, dan volgt meestal een meerwerkofferte. Daarom is de beschrijving het belangrijkste.

Vraag ook wat een vaste prijs aan projectleiding en testen omvat. Moet u zelf testen, schrijf dan op hoeveel uur dat naar verwachting bij u kost en wie het doet.

Is de beschrijving vaag, dan zal een offerte tegen vaste prijs ofwel duur zijn, doordat de leverancier de onzekerheid meeprijst, ofwel onderweg uitmonden in wijzigingswensen. De beschrijving is daarom uw beste onderhandelingsinstrument. Hoe preciezer ze is, hoe beter de offertes vergelijkbaar worden.

Uurtarief

Met een uurtarief betaalt u voor het verbruik dat er is. Dat past bij opdrachten waarvan de omvang onduidelijk is: analyse, foutopsporing, het verkennen van mogelijke oplossingen of aanpassingen die zich onderweg ontwikkelen.

Het risico ligt bij u. Vraag om een schatting, een plafond en doorlopende rapportage van het urenverbruik, zodat u op tijd kunt stoppen.

Vraag om een weekrapport en een afgesproken moment waarop u beoordeelt of het werk doorgaat. Dat geeft controle zonder dat u eerst een volledige beschrijving nodig heeft.

Vraag ook of het uurtarief voor alle rollen gelijk is. Adviseurs, ontwikkelaars en projectleiders kunnen verschillende tarieven hebben, en de mix bepaalt de gemiddelde prijs.

Wat een goede beschrijving moet bevatten

Laat iemand die de beschrijving niet heeft geschreven haar lezen en vragen stellen. Twijfelen zij, dan zal de leverancier ook twijfelen.

Welk model u ook kiest, een aanpassing moet schriftelijk worden beschreven voordat het werk begint. Controleer of de beschrijving het volgende bevat:

Doel: welk probleem wordt opgelost en voor wie
Wat erbij hoort en wat niet
Hoe het moet werken, bij voorkeur met voorbeelden en schermafbeeldingen
Welke gegevens en koppelingen het raakt
Acceptatiecriteria: hoe u bepaalt dat het is geleverd
Wie test en wanneer
Wat wijzigingen onderweg kosten

Vragen die verschillen blootleggen

Vraag of het werk tegen vaste prijs ook testen, documentatie en het herstellen van fouten na oplevering dekt, en hoe lang. Vraag ook wie de code bezit en hoe updates worden afgehandeld. Microsoft werkt Business Central twee keer per jaar bij, en een aanpassing moet na de updates blijven werken. Zie het artikel over aanpassing of standaard.

Vraag wat er gebeurt als de opdracht groter blijkt. Wie betaalt en hoe wordt dat afgesproken?

Vraag ook of de prijs opleiding van de gebruikers en een doorloop na oplevering van de aanpassing omvat. Een aanpassing waarvan niemand weet hoe ze moet worden gebruikt, schept geen waarde.

Een tussenweg

Veel mensen kiezen een vaste prijs voor een afgebakende analyse of een eerste stap, en daarna een vaste prijs of uurtarief voor de rest. Dan is de beschrijving preciezer geworden voordat de grote beslissing wordt genomen.

Het kan ook helpen de opdracht in fasen te verdelen met goedkeuring ertussen. De betaling kan de fasen volgen, zodat u niet alles vooraf betaalt.

Bij Addverk

Wilt u weten wat wij aanbieden en wat het kost, schrijf ons dan. Gebruik de checklist hierboven om te vergelijken.