RFP-tjekliste til softwareudvikling for B2B-købere

En RFP for software bør beskrive problemet, funktionelle og ikke-funktionelle krav, sikkerheds- og databehov, kommercielle vilkår samt scoringsmetoden, før leverandørerne svarer. Vægt kriterierne, kontrollér referencerne i stedet for kun at læse cases, og gennemfør en kort betalt pilot før en aftale, der binder budgettet.

Hvad skal en RFP for software indeholde?

Dokumentet skal gøre svar sammenlignelige. En leverandør kan kun svare på det, der står skrevet; en RFP, der beskriver en vision og beder om en pris, giver tilbud, der lyder ensartet gode, men ikke kan vurderes mod hinanden. Funktionelt indhold, begrænsninger og scoringsregel skal ligge fast, før det første svar kommer.

Der er også en rækkefølge, der sparer måneder: RFP'en er ikke stedet, hvor du opdager, hvad du har brug for. Krav kommer fra internt arbejde: procesejere beskriver den faktiske drift, økonomi fortæller hvad der skal stemme, og de daglige brugere peger på den nuværende smerte. Hvis den opgave overlades til den første leverandør, bliver kravene skrevet i leverandørens produktsprog, og andre tilbud ser derefter dårligere ud end de er.

Skeln mellem tre dokumenter, der ofte forveksles. En RFI spørger markedet, hvad der findes; den er kort og binder ingen. En RFP beder om et tilbud på definerede krav og en fast evalueringsmetode. En RFQ beder om en pris på et defineret scope. En RFQ før scope findes sammenligner typisk tre tal, der betyder tre forskellige ting.

Fem ting gør en komplet RFP, som en ufuldstændig ikke gør:

• Definerer problemet, ikke løsningen. “Reducer tiden til den månedlige konsoliderede rapport fra dage til et bestemt antal timer” er et problem; “byg et data warehouse” er et løsningsgæt.


• Adskiller krav fra ønsker. Must-have afgør bestået, should-have afgør rang, og nice-to-have afgør intet.


• Navngiver begrænsningerne. Eksisterende systemer, data der skal migreres, audit- og opbevaringskrav, go-live-vindue og godkendere.


• Angiver evalueringsmetoden på forhånd. Vægtede kriterier, bedømmere, krævet dokumentation og hvornår afviste leverandører får en scoreopsummering.


• Fastlægger datoerne. Spørgefrist, afklaringsvindue, afleveringsfrist, evalueringsperiode og beslutningsdato.

RFP-struktur

Funktionelle og ikke-funktionelle krav

Funktionelle krav beskriver, hvad systemet gør: hvilke processer, for hvilke roller og med hvilke resultater. Ikke-funktionelle krav beskriver, hvor godt det gør det, og de mangler oftest, hvorefter de håndhæves dyrt eller slet ikke.

Det er værd at skrive følgende tydeligt i de fleste B2B-projekter:

• Ydeevne. Svartider under en angivet belastning for ordreindtastning, rapporter og månedsafslutning.


• Tilgængelighed. Krævet oppetid, vedligeholdelsesvinduer og hvad der sker ved nedbrud. Et mål uden acceptabel nedetid er ikke et krav.


• Genopretning. RTO og RPO i almindeligt sprog: hvor hurtigt driften genoptages, og hvor meget arbejde der må gå tabt. Begge tal hører hjemme i evalueringen.


• Auditspor. Hvem ændrede hvad og hvornår, hvor længe det gemmes, og hvem kan hente det.


• Tilgængelighed og brugbarhed. Hvem bruger systemet, på hvilke enheder og sprog; et system lageret ikke kan bruge, er ikke implementeret.


• Integration og data. Hvilke systemer forbindes, hvilken vej data flyder, og hvem ejer stamdata for hver entitet.

Spørgsmål om sikkerhed og compliance

Sikkerhed bør spørges som krav om dokumentation, ikke som et ja/nej-felt:

• ISO/IEC 27001 — har leverandøren certificeringen, og hvad dækker scope? Et certifikat for salgsorganisationen, men ikke leveringsteamet, fortæller noget konkret.


• Sikker udvikling — hvor sikkerhed indgår i design, code review og test, og om afhængigheder og sårbarheder håndteres rutinemæssigt.


• OWASP Top 10 — om den indgår i review af webkomponenter.


• Adgangskontrol — hvem kan nå miljøer og data, hvordan adgang gives og fjernes, og hvad der logges.


• Databeskyttelse — KVKK og GDPR, hvor de gælder; hvem er dataansvarlig og databehandler, og hvad siger databehandleraftalen om underdatabehandlere og brudanmeldelse.

Kommercielle vilkår og SLA'er

Planlæg også en fælles spørgsmålsrunde efter udsendelsen. Alle leverandører skal modtage de samme afklaringer, og svar, der ændrer forståelsen af et krav, skal sendes til alle. En kort, skriftlig log over spørgsmål, svar og versioner gør den senere beslutning efterprøvbar og forhindrer, at en uformel samtale giver én tilbudsgiver en skjult fordel.

Bed om priser i en struktur, der kan sammenlignes: hvad er inkluderet, hvad faktureres separat, og hvordan prissættes ændringer. Ét tal uden scope kan ikke sammenlignes med et andet. Siden om omkostnings- og prismodeller forklarer de almindelige strukturer.

SLA'er kræver samme præcision som kravene. En oppetidsprocent giver kun mening med målemetode, undtagelser og afhjælpning; en svartid kræver alvorlighedsdefinitioner og åbningstider. Bed leverandøren definere ordene i SLA'en i stedet for at acceptere procenter uden forklaring.

Scoringsmatrix til evaluering

En skabelon, der kan kopieres. Vægtene er et eksempel; sæt egne vægte efter prioriteterne og hold totalen på 100. Definér betydningen af 1, 3 og 5, før nogen scorer.

Score først individuelt og diskuter bagefter, så den første sikre stemme ikke bestemmer rummet. Skriv én begrundelse pr. score, så teamet kan forsvare valget seks måneder senere. Panelet bør omfatte procesejeren, den dataansvarlige og sikkerhed eller økonomi, hvor disse funktioner findes, ikke kun indkøb. Én teknisk person med mandat til at sige “det fungerer ikke med vores systemer” forebygger mere omkostning end en rabat.

Vægtene er en synlig prioritering. Hvis sikkerhed vægtes 5 % og pris 30 %, opdager både sikkerhedsorienterede leverandører og dit eget team det. Sæt vægtene med beslutningstagerne til stede, og ændr dem kun gennem samme formelle proces.

Referencekontrol og pilot

Cases er marketing; referenceopkald er dokumentation. Spørg hvad der faktisk skete: blev projektet færdigt, hvad ændrede sig i scope, hvem var reelt på teamet, hvad ville kunden gøre anderledes, og ville kunden starte igen med leverandøren. Bed om en reference fra et projekt, der ligner dit i størrelse og kompleksitet, og ring selv.

En kort betalt pilot tester, hvordan teamet arbejder med dine mennesker, når kravene er ufuldstændige. Brug rigtigt arbejde, skriftlige acceptkriterier, én ændring undervejs og en beslutningsregel aftalt på forhånd. Outsourcingsiden beskriver pilotdesign nærmere.

Kontraktbestemmelser, der skal kontrolleres

• IP-overdragelse — rettigheder til kode, dokumentation og afledte værker overføres ved skabelsen, ikke først ved slutbetaling.
• Dataejerskab — dine data forbliver dine; leverandørens rettigheder begrænses til leverancen.
• Accept — hvad accept betyder, hvem der erklærer den, og hvad der sker ved fejl.
• Ændringsstyring — hvordan scopeændringer foreslås, prissættes og godkendes.
• Exit og overgang — kildekode, adgang, dokumentation og hjælp ved afslutning.
• Escrow — hvad der sker, hvis leverandøren ikke kan fortsætte, når kontinuitet afhænger af leverandørkomponenter.
• Ansvar — begrænsninger, undtagelser og hvad der ikke er forsikret.
• Ophør — varsler, pligter efter ophør samt returnering eller sletning af data.

Ofte stillede spørgsmål

Skal vi sende en RFI eller RFP først?

En RFI, når markedet eller problemet er uklart, og en RFP, når krav og evalueringsmetode er fastlagt. En tidligere RFP flytter blot kravarbejdet ind i hver leverandørs tilbud.

Hvor mange leverandører bør vi invitere?

Få nok til at læse hvert tilbud ordentligt og ringe til hver reference. En shortlist fra RFI, screeningsamtale og ét lignende projekt er ofte mere nyttig end en lang liste kendte navne.

Hvordan skal vægtene fastsættes?

Ud fra prioriteterne, før et tilbud ses, og med enighed blandt dem, der skal leve med resultatet. Hvis pris eller risiko dominerer, skal vægtene vise det.

Skal pris scores?

Ja, som ét vægtet kriterium med fast scope, ikke som hele evalueringen. En pris uden scope belønner leverandøren, der antog mindst arbejde.

Hvordan scorer jeg sikkerhedssvar?

På dokumentation, ikke tone: ingen holdning (1), beskrevne politikker (3), verificeret certifikatscope samt beskrevet sikker udvikling og dokumentation (5). Dokumenterede tilsvarende kontroller kan være bedre end et unverificerbart ja.

Kan vi ændre krav efter RFP'en?

Før tilbud: ja, hvis ændringen offentliggøres for alle. Efter tilbud kun gennem en formel afklaring, som alle tilbudsgivere modtager. Efter kontrakten bruges ændringsstyring.

Kilder og standarder

• ISO — udgiver af ISO/IEC 27001; kontrollér den aktuelle udgave og certifikatets scope.
• OWASP — udgiver af tjeklisten over de 10 vigtigste webapplikationsrisici.
• Scoringsprincipperne følger almindelig RFP-praksis; vægtene er eksempler. Siden er indkøbsvejledning, ikke juridisk rådgivning, og der påstås ingen certificering eller audit for WorldwideTradeX.

Relaterede sider

Softwareudvikling · IT outsourcing fra Türkiye · Omkostnings- og prismodeller · IT-audit og rådgivning · Anmod om tilbud