I samband med att en investering i nytt affärssystem diskuteras är det inte ovanligt att någon för fram kravet/synpunkten att projektet skall ske till ett fastpris. Det kan låta klokt och är lätt att besluta utan att man riktigt förstår konsekvenserna. Inte sällan kan man få en jämförelse att ingen vettig person låter bygga ett hus på löpande räkning, det vore som att be om ett projekt som kommer att bli dyrare än planerat.

Fastpriskrav ett förfarande som är vardag för de organisationer som verkar under LOU vilket i princip kräver ett bindande fastpris (om man inte väljer förhandlad upphandling, vilket få organisationer gör) som baserats på de handlingar som en leverantör fått ta del av, möjligen kompletterat med en systemdemo.

Problemet med husjämförelsen är ritningarna. Skall man bygga ett hus har en seriös beställare alltid ett antal ritningar som i detalj beskriver hur stort huset skall vara konstruerat, hur väggar och bärande konstruktioner skall vara placerade samt var installationer av el, VA, data skall vara placerade. Motsvarande dokument i ett affärssystemsprojekt är anbudsförfrågan med kravspecifikationen och övriga bilagor.

I fallet med husbygget är det också så att det inom i princip alla delar av husets konstruktioner finns olika standarder för både konstruktioner och ingående material.  Det innebär att både byggare och beställare har en relativt klar bild av hur leveranser kommer att se ut och kunden har en god möjlighet att bedöma sin byggnation baserat på vad ritningen beskriver.

Samma tydliga förhållande råder inte när det gäller programvaror som ett affärssystem. För att åstadkomma ett lika klart och tydligt specificerat projekt som husbygget skulle man få skriva en mycket detaljerad och omfattande kravspecifikation som i detalj redogör för alla funktioner och varianter av arbetsmoment som skall vara möjliga i det nya systemet och det är inte rimligt. I princip skulle ingen kund/beställare orka med en så pass omfattande insats för att specificera alla arbetsmoment och systemfunktioner och kombinationer av dessa. Det innebär att man som köpare av ett affärssystem normalt sett har en mycket större grad av osäkerhet när det gäller leveransen.

Som kund kan man satsa på att försöka klarlägga de delar av systemet som är affärskritiska via systemvisningar med användarfall och en detaljerad agenda men även där får man acceptera att man inte har hela bilden klar för sig. Först när man nyttjat systemet en tid kan man avgöra hur väl leveransen lever upp till alla delar av den befintliga kravspecen. Inte sällan kommer man fram till att många av kraven baserades på de processer som var möjliga i det gamla systemet och att man först efter att ha lärt sig det nya systemet kan förstå och dra nytta av det nya systemet och effektivisera sina processer.

Om man fortsätter med liknelsen med husbygget och fastprisprojektet måste den offererande leverantören nyttja delar av det gamla huset och de skall dessutom bygga ihop det med andras hus. Dvs. i ett systemprojekt är det normalt sett den nya leverantören som förväntas konvertera befintlig data och integrera med andra system. För att kunna uppskatta sin insats och bedöma priset behöver leverantören naturligtvis ha tillgång till en specifikation på de data som skall konverteras samt en detaljerad beskrivning på format som skall hanteras i samband med integrationsbyggande, något som inte brukar finns med i en anbudsförfrågan, i alla fall inte på en tillräckligt detaljerad nivå.

När man betänker detta kan man snabbt konstatera att det är mycket svårare att få ihop ritningen för ett systemprojekt och att det därmed inte är rimligt att begära ett fastpris för hela projektet när så pass mycket är oklart när det gäller ingående delar och leverans.

Man kan ändå begära ett fastpris, det är i princip vad som sker under LOU inom den offentliga sektorn varje dag, men man skall ha klart för sig att det normalt sett sker med mycket bristfälliga underlag och att risken att man som kund blir besviken. Leverantören å sin sida måste ta höjd för alla oklarheter och baka in en riskpremie i priset, alternativ blunda och hoppas att man klarar sig igenom projektet trots alla oklarheter och problem som brukar dyka upp.

I samband med en upphandling av ett affärssystem kan man i slutskedet av processen, dvs. när leverantören har besvarat kravspecen och demonstrerat systemet efter en tydlig agenda och genomfört en förstudie och satt sig in i verksamheten och förutsättningarna, begära fastpris för valda delar av leveranser. Alltså sådant som går att specificera på ett tydligt vis, ex. vis x antal utbildningsdagar, x antal integrationer (efter specifikation av format på data, frekvens och riktning) och liknande.

Trots att affärssystemen idag ofta går under benämningen standardsystem, vilket den oinvigde ofta tolkar allt för bokstavligt, är det faktiska förhållandet att det i hög grad är en verktygslåda som kan te sig tämligen olikartad beroende på hur man sätter upp systemet. Lägger man sen till problemet med tolkningen av en kravspecifikation, dvs. vem avgör hur kravet ”systemet skall kunna hantera x valutor” skall tolkas, det kan innebära mycket olikartade funktioner, samt alla projektrelaterade problem som till exempel behovet av att interna resurser bör medverka med ca 3x leverantörens tid inser man att begäran om fastpris i ett tidigt skede av upphandlingen är ett skott i mörkret för både beställare och leverantör.