Behovsbeskrivelse i offentlige anskaffelser
Behovsbeskrivelsen oversetter analysen til et tydelig oppdrag uten unødvendig detaljstyring av løsningen.
En behovsbeskrivelse gir markedet et presist bilde av problemet, brukerne, ønsket effekt og rammene. Den skal være konkret nok til at leverandørene kan prise og planlegge, men åpen nok til at relevante løsninger kan konkurrere.
En nyttig struktur
1. Bakgrunn
Beskriv hvorfor behovet har oppstått, dagens prosess og dokumenterte utfordringer. Skill fakta fra antakelser.
2. Brukere og situasjoner
Vis hvem som skal bruke eller påvirkes av leveransen, volum, steder og de viktigste arbeidsforløpene. Bruk konkrete scenarioer fremfor generelle målgrupper.
3. Ønsket effekt
Definer hva som skal bli bedre og hvordan det måles. Koble effekten til baseline fra behovsanalysen .
4. Omfang og grensesnitt
Avklar hva som inngår, hva som ikke inngår, avhengigheter, integrasjoner og ansvar mellom partene.
5. Rammer
Beskriv bindende føringer som sikkerhet, personvern, tilgjengelighet, språk, tidsplan og budsjettmodell. Unngå å gjøre preferanser til absolutte krav uten begrunnelse.
Behov, krav og kriterium er ikke det samme
| Element | Eksempel |
|---|---|
| Behov | Brukeren må kunne fullføre oppgaven uten spesialiststøtte |
| Krav | Løsningen skal støtte de angitte arbeidsstegene og rollene |
| Kriterium | Tilbudt løsnings dokumenterte brukervennlighet vurderes gjennom prøveoppgave |
| Kontraktsmål | 85 prosent fullfører prøveoppgaven uten hjelp etter opplæring |
Hvis samme setning kopieres ukritisk mellom alle fire, blir det uklart hva som er obligatorisk, hva som gir poeng og hva som følges opp.
Unngå skjult produktspesifikasjon
Et krav om bestemt skjermoppsett, teknologi eller funksjonsnavn kan utelukke gode løsninger uten å gi bedre måloppnåelse. Spør hvilken risiko detaljkravet kontrollerer. Hvis risikoen kan uttrykkes som ytelse, grensesnitt eller testresultat, får markedet større handlingsrom.
Samtidig skal ikke «funksjonsbasert» bli vagt. Oppgi relevante volum, responstid, brukergrupper, datakilder og godkjenningskriterier.
Leverandørens lesemåte
Når behovsbeskrivelsen kommer i et konkurransegrunnlag, bør leverandøren markere:
- eksplisitte problemer og effekter
- brukergrupper og kritiske scenarioer
- rammer som påvirker løsning og pris
- manglende data som krever spørsmål
- forhold som bør bli forutsetning eller risiko i tilbudet
Koble deretter hvert løsningselement til et uttalt behov. Det gir en mer relevant metodebeskrivelse enn en generell produktpresentasjon.
Kvalitetssjekk
La en person utenfor prosjektet lese beskrivelsen og svare på: Hvem har problemet? Hva skal endres? Hva er innenfor? Hvilke rammer er bindende? Hvordan vet vi at leveransen virker? Uklare svar viser hvor teksten må forbedres.
Les videre om anskaffelsesstrategi .
Offisiell kilde
Se DFØs veiledning om behovsbeskrivelse . Kontroller gjeldende prosessveiledning før konkurransen.