Fast pris eller timpris på anpassningar?
När ni låter bygga en anpassning till Business Central kan priset vara avtalat som ett fast belopp eller faktureras efter förbrukning. Båda kan vara rimliga, men de passar olika uppgifter. Artikeln förklarar när varje modell fungerar bäst, vad ett fast pris kräver av beskrivningen och vilka frågor ni bör ställa oavsett vem som lämnar offerten. Den gäller oavsett leverantör.
Fast pris
Med ett fast pris känner ni priset i förväg, om uppgiften är tydligt avgränsad. Det passar uppgifter där ni vet vad ni vill ha: en rapport, ett nytt fält med en regel, en avgränsad integration.
Risken ligger hos leverantören, men bara så länge beskrivningen håller. Om kraven ändras under arbetets gång tillkommer det vanligen en extra kostnad. Därför är beskrivningen det viktigaste.
Fråga också vad ett fast pris innehåller av projektledning och test. Om ni själva ska testa, skriv hur många timmar det förväntas ta hos er och vem som gör det.
Om beskrivningen är vag blir en offert med fast pris antingen dyr, eftersom leverantören räknar in osäkerheten, eller leder till ändringsönskemål under arbetets gång. Beskrivningen är därför ert bästa förhandlingsverktyg. Ju mer exakt den är, desto mer jämförbara blir offerterna.
Timpris
Med timpris betalar ni för den förbrukning som blir. Det passar uppgifter där omfattningen är oklar: analys, felsökning, utforskning av möjliga lösningar eller anpassningar som utvecklas under arbetets gång.
Risken ligger hos er. Be om en uppskattning, ett tak och löpande rapportering av timförbrukning så att ni kan stoppa i tid.
Be om en vecka-för-vecka-rapport och en överenskommen punkt där ni bedömer om arbetet ska fortsätta. Det ger kontroll utan att kräva en fullständig beskrivning först.
Fråga också om timpriset är detsamma för alla roller. Konsulter, utvecklare och projektledare kan ha olika taxor, och blandningen avgör det genomsnittliga priset.
Vad en bra beskrivning ska innehålla
Låt någon som inte har skrivit beskrivningen läsa den och ställa frågor. Om de är osäkra kommer leverantören också att vara det.
Oavsett modell bör en anpassning beskrivas skriftligt innan arbetet börjar. Kontrollera att beskrivningen innehåller:
- Syfte: vilket problem som löses och för vem
- Vad som ingår och vad som inte ingår
- Hur det ska fungera, gärna med exempel och skärmbilder
- Vilka data och integrationer det berör
- Acceptanskriterier: hur ni avgör att det är levererat
- Vem som testar och när
- Vad ändringar under arbetets gång kostar
Frågor som avslöjar skillnader
Fråga om det arbete som har fast pris omfattar test, dokumentation och rättelse av fel efter leverans, och hur länge. Fråga också vem som äger koden och hur uppdateringar hanteras. Microsoft uppdaterar Business Central två gånger om året, och en anpassning ska fortsätta fungera efter uppdateringarna. Se artikeln om anpassning eller standard.
Fråga vad som händer om uppgiften visar sig vara större. Vem betalar och hur kommer ni överens om det?
Fråga också om priset inkluderar utbildning av användarna och en genomgång när anpassningen är levererad. En anpassning som ingen vet hur man använder skapar inget värde.
En mellanväg
Många väljer ett fast pris på en avgränsad analys eller ett första steg och därefter fast pris eller timpris på resten. Då har beskrivningen blivit mer exakt innan det stora beslutet tas.
Det kan också hjälpa att dela upp uppgiften i faser med godkännande emellan. Betalningen kan följa faserna så att ni inte betalar för allt i förväg.
Hos Addverk
Använd checklistan ovan för att jämföra offerter. Skriv gärna till oss om ni har frågor.
Korta, konkreta mejl om det kunderna oftast frågar oss om. Vi skriver när vi har något som är värt att läsa.