Offentlig upphandling av utvecklingstjänster – det här gäller
Offentlig upphandling av IT-utveckling styrs av LOU och ska ge alla leverantörer lika villkor. Nyckeln är att beskriva vad systemet ska åstadkomma i funktionskrav snarare än att låsa tekniska detaljer, välja rätt avtalsform för behovet och sätta utvärderingskriterier som premierar kvalitet lagligt, inte bara lägsta pris.
Offentlig sektor köper utveckling under lagen om offentlig upphandling, LOU. Regelverket finns för att skydda skattemedel och ge alla leverantörer lika villkor – men fel använt skrämmer det bort just de skickliga leverantörer man vill nå. En kravkatalog med tusen detaljkrav lockar dem som är bäst på att fylla i formulär, inte dem som är bäst på att bygga system. Här är hur du upphandlar utveckling utan att fastna i den fällan.
Välj rätt avtalsform för behovet
Det första vägvalet handlar om hur du köper, inte vad. Tre vägar dominerar, och de passar olika lägen.
- Direktupphandling gäller under en beloppsgräns och kräver ingen annonsering. Den passar avgränsade insatser som en förstudie eller en kortare konsultinsats. Kom ihåg att räkna på hela behovet – du får inte dela upp ett stort köp i småbitar för att slippa annonsera.
- Ramavtal ger en förhandlad uppsättning leverantörer och villkor, ofta i upp till fyra år. Smidigt för återkommande avrop, men marknaden fryser vid avtalstecknandet – ett bekymmer i en bransch där kompetens och pris rör sig snabbt.
- Dynamiskt inköpssystem håller dörren öppen: nya leverantörer kan ansluta under hela systemets livslängd. Det ger en färskare leverantörsbas för IT-kompetens, till priset av mer administration.
Tumregeln: ju mer långsiktigt och föränderligt behovet är, desto mer talar för en öppen form framför ett låst ramavtal.
Funktionskrav i stället för detaljkrav
Det största misstaget i offentlig IT-upphandling är att specificera lösningen i stället för behovet. Skriver du “systemet ska använda ramverk X och lagra data i databas Y” har du redan bestämt arkitekturen – ofta utan att vara den som kan den bäst.
Beskriv i stället vad systemet ska åstadkomma. I stället för “sökfunktion byggd i teknik Z” skriver du “en handläggare ska hitta ett ärende på nummer eller namn inom två sekunder”. Då konkurrerar leverantörerna med sitt kunnande, och du får förslag du inte själv hade tänkt på. Funktionskrav är också lättare att följa upp: antingen klarar lösningen tvåsekundersmålet eller inte, medan ett detaljkrav på teknikval sällan säger något om resultatet.
Blanda inte ihop krav som är obligatoriska med sådant som bara är önskvärt. Varje absolut skall-krav du sätter stänger ute leverantörer – sätt dem bara där de verkligen behövs.
Utvärderingskriterier som premierar kvalitet lagligt
Lägsta pris är enkelt att försvara men farligt för utveckling, där skillnaden mellan ett bra och ett svagt team är enorm. LOU tillåter att du väger in kvalitet – förutsatt att du beskriver hur redan i underlaget.
| Kriterium | Så gör du det lagligt mätbart |
|---|---|
| Teamets kompetens | Poängsätt CV och konkret erfarenhet av liknande system, inte bolagets storlek |
| Kvalitet i lösningen | Låt leverantören lösa en avgränsad provuppgift som bedöms mot förutbestämda kriterier |
| Metod och arbetssätt | Be om en beskriven leveransplan och bedöm den mot definierade framgångsfaktorer |
| Pris | Vikta mot kvaliteten så att billigt men svagt inte vinner per automatik |
Poängen är förutsägbarhet: en leverantör ska kunna räkna ut sin egen poäng av ditt underlag. Godtycke är både olagligt och en inbjudan till överprövning.
Ett scenario: två sätt att fråga
En kommun ska upphandla ett nytt ärendehanteringssystem. I det första underlaget listas 400 detaljkrav på fältnivå. Anbuden kommer från leverantörer som är vana vid offentliga formulär, och den som vinner bygger exakt det som stod – inklusive de tankefel som fanns i kravlistan.
I det andra underlaget beskrivs i stället tjugo verksamhetsflöden som ska fungera, plus en provuppgift. Nu svarar även mindre, vassare leverantörer, och kommunen kan bedöma faktiskt kunnande före avtal. Samma budget, helt olika utfall – skillnaden låg i frågan, inte i pengarna.
En genomtänkt upphandling frigör kvalitet i stället för att stänga ute den. Vill du bolla kravbild eller utvärderingsmodell inför en upphandling tar vi på Weapp gärna det samtalet – hör av dig med en kort beskrivning av vad ni ska köpa.
Vanliga frågor
Måste vi alltid annonsera upphandlingen?
Nej, inte alltid. Under direktupphandlingsgränsen får du köpa utan annonsering, men du behöver ändå agera affärsmässigt och kunna motivera valet. Över gränsen krävs annonsering, antingen som egen upphandling eller genom avrop från ett befintligt ramavtal. Räkna ihop hela avtalets värde, inte bara första året, när du bedömer vilket regelverk som gäller.
Vad är skillnaden mellan ramavtal och dynamiskt inköpssystem?
Ett ramavtal fryser leverantörer och villkor för avtalets löptid, ofta upp till fyra år. Ett dynamiskt inköpssystem är öppet under hela sin livslängd, så nya leverantörer kan ansluta löpande. För snabbrörlig IT-kompetens ger det dynamiska systemet mer aktuell marknad, medan ramavtalet ger enklare avrop.
Får vi prata med leverantörer innan upphandlingen?
Ja. En extern dialog eller RFI innan du publicerar underlaget är tillåten och ofta klok. Den hjälper dig att skriva realistiska krav och förstå vad marknaden kan leverera. Villkoret är att ingen enskild leverantör får ett försprång – det du lär dig ska komma alla till del i det slutliga underlaget.
Hur undviker vi att bara priset avgör?
Använd kvalitet som tilldelningskriterium vid sidan av pris och beskriv i förväg hur du poängsätter det. Konkreta, mätbara kvalitetsfaktorer som teamets erfarenhet av liknande system eller en bedömd provuppgift håller juridiskt, till skillnad från lösa omdömen. Vikta pris och kvalitet så att en billig men svag leverans inte vinner automatiskt.