Programvareutvikling og erp system: RFP-sjekkliste for B2B-kjøpere

En RFP for programvareutvikling bør beskrive problemet, de funksjonelle og ikke-funksjonelle kravene, behovene for sikkerhet og data, de kommersielle vilkårene og poengmetoden før noen leverandør svarer. Poengsett de vektede kriteriene i stedet for å diskutere dem i etterkant, kontroller referansene i stedet for å stole på casestudiene, og gjennomfør en kort betalt pilot før dere signerer noe som binder et budsjett til prosjektet. Et erp system bør vurderes etter de samme kriteriene når det inngår i leveransen.

Hva bør en RFP for programvareutvikling inneholde?

Dokumentet skal gjøre svarene sammenlignbare. En leverandør kan bare svare på det som står skrevet; en RFP som beskriver en visjon og ber om en pris, inviterer til tilbud som alle høres fremragende ut, men som ikke kan vurderes opp mot hverandre. Det funksjonelle innholdet, begrensningene og poengreglene må være fastlagt før det første svaret kommer, ellers blir evalueringen en forhandling om kriteriene.

Det finnes også en rekkefølge som kan spare måneder: RFP-en er ikke stedet der dere oppdager hva dere trenger. Kravene må komme fra internt arbeid – prosesseierne beskriver hvordan virksomheten faktisk drives, økonomiavdelingen sier hva som må avstemmes, og de som skal bruke systemet hver dag, forteller hvor dagens problemer ligger. Dette arbeidet er langsomt og politisk, og det skjer før noen leverandør involveres. Team som setter det bort til den første leverandøren som dukker opp, ender med krav formulert i leverandørens produktspråk. Da ser alle andre tilbud ut som dårlige treff – ikke fordi de er det, men fordi målestokken ble skrevet rundt én av tilbyderne.

Det er også viktig å skille mellom tre dokumenter som ofte blandes sammen. En RFI spør markedet hva som finnes; den er kort, kommer før kravene og binder ingen. En RFP ber om et tilbud basert på definerte krav og en oppgitt evalueringsmetode. En RFQ ber om en pris basert på et definert omfang. Å gjennomføre en RFQ før omfanget finnes, er den vanligste måten å ende med tre tall som betyr tre forskjellige ting.

Fem ting en komplett RFP gjør, som en ufullstendig RFP ikke gjør:

• Definerer problemet, ikke løsningen. «Reduser tiden det tar å lage den månedlige konsoliderte rapporten fra dager til et definert antall timer» er en problembeskrivelse; «bygg et datavarehus for oss» er et løsningsgjetning som kanskje ikke løser problemet.


• Skiller krav fra preferanser. Må-krav som avgjør om tilbudet består, bør-krav som avgjør rangeringen, og kjekt-å-ha-krav som ikke avgjør noe. Leverandører svarer seriøst først når skillet er synlig.


• Nevner begrensningene. Eksisterende systemer som må integreres, data som må migreres, krav til revisjon og oppbevaring, tidsvinduet for produksjonssetting og hvem som godkjenner.


• Beskriver evalueringsmetoden på forhånd. Vektede kriterier, hvem som evaluerer, hvilken dokumentasjon som kreves, og når leverandører som ikke vinner, får et sammendrag av poengene sine.


• Fastsetter datoene for prosessen. Frist for spørsmål, avklaringsperiode, innleveringsfrist, evalueringsperiode og beslutningsdato. En prosess uten datoer tiltrekker leverandører som allerede har for mye å gjøre.

RFP-struktur

Funksjonelle og ikke-funksjonelle krav

Funksjonelle krav beskriver hva systemet gjør: hvilke prosesser, for hvilke roller og med hvilke resultater. Ikke-funksjonelle krav beskriver hvor godt det gjør dette, og det er disse som oftest mangler – før de senere håndheves dyrt, eller ikke håndheves i det hele tatt.

Dette bør vanligvis beskrives uttrykkelig i B2B-prosjekter:

• Ytelse. Svartider under en oppgitt belastning, for de viktige operasjonene – registrering av bestillinger, rapportgenerering og månedsavslutning.


• Tilgjengelighet. Hvilken oppetid virksomheten trenger, vedlikeholdsvinduer og hva som skjer når systemet er nede – et mål uten en beskrivelse av akseptabel nedetid er ikke et krav.


• Gjenoppretting. RTO og RPO i klare ord: hvor raskt driften gjenopptas etter en hendelse, og hvor mye arbeid som kan gå tapt. Begge tallene hører hjemme i evalueringen, ikke bare i kontrakten.


• Revisjonsspor. Hvem endret hva og når, hvor lenge det oppbevares og hvem som kan hente det frem – særlig der penger, lagerbeholdning eller personopplysninger flyttes.


• Tilgjengelighet og brukervennlighet. Hvem bruker systemet, på hvilke enheter og på hvilke språk; et system lageret ikke kan bruke, er ikke implementert, uansett hvor godt det scorer.


• Integrasjon og data. Hvilke systemer som kobles sammen, hvilken vei dataene går og hvem som eier masteroppføringen for hver enhet.

Sikkerhet og etterlevelse for et erp system

Sikkerhet bør stilles som spørsmål med krav om dokumentasjon, ikke som en ja/nei-linje. Dette er spørsmålene det er verdt å ta med:

• ISO/IEC 27001 – har leverandøren sertifiseringen, og hva omfatter det sertifiserte området? Et sertifikat som dekker salgsorganisasjonen, men ikke leveranseteamene, forteller dere noe konkret.


• Sikker utvikling – hvor sikkerhet inngår i design, kodegjennomgang og testing, og om håndtering av avhengigheter og sårbarheter er en fast rutine.


• OWASP Top 10 – om dette inngår i leverandørens gjennomgang av nettilgjengelige komponenter; et konkret spørsmål som kan besvares.


• Tilgangskontroll – hvem som kan nå miljøene og dataene deres, hvordan tilgang gis og trekkes tilbake, og hvilken logging som finnes.


• Plikter knyttet til databeskyttelse – KVKK og GDPR der det gjelder; hvem som er behandlingsansvarlig, hvem som er databehandler, og hva databehandleravtalen sier om underleverandører og varsling av brudd.

Kommersielle vilkår og SLA-er

Be om priser i en struktur dere kan sammenligne: hva som er inkludert, hva som faktureres separat og hvordan endringer prises. Ett tall uten et definert omfang kan ikke sammenlignes med et annet enkelt tall; siden om kostnads- og prismodeller forklarer de vanlige strukturene og spørsmålene hver av dem reiser.

SLA-er fortjener samme presisjon som kravene. En prosent for tilgjengelighet gir bare mening sammen med målemetode, unntak og kompensasjon; en svartid gir bare mening med alvorlighetsgrader og åpningstider. Be hver leverandør definere begrepene i selve SLA-en i stedet for å godta en side med prosenter uten definisjoner.

Poengmatrise for evaluering

En mal dere kan kopiere. Vektene nedenfor er et eksempel – sett deres egne ut fra prioriteringene deres, og hold totalsummen på 100. Definer hva 1, 3 og 5 betyr før noen begynner å gi poeng, ikke etter at diskusjonene har startet.

To disipliner får dette til å fungere. Gi poeng uavhengig av hverandre før dere diskuterer, slik at den første selvsikre stemmen ikke setter premissene for rommet. Skriv også én begrunnelse per poeng – leverandører som får et poengsammendrag med begrunnelser, aksepterer utfallet langt lettere, og deres eget team kan forsvare det seks måneder senere.

En tredje disiplin gjelder hvem som gir poengene. Panelet bør omfatte personene som skal leve med resultatet – prosesseieren, den som har ansvar for dataene, og noen fra sikkerhet eller økonomi der disse funksjonene finnes – ikke bare innkjøp. Evalueringer mislykkes i det stille når panelet gir poeng for det det kan vurdere (tilbudsstrukturen og salgsteamets profesjonalitet) og utsetter det det ikke kan vurdere (om integrasjonstilnærmingen faktisk passer med dagens systemer). Én teknisk person med myndighet til å si «dette vil ikke fungere med det vi kjører», sparer mer kostnad enn enhver rabatt.

Selve vektene fortjener enda en advarsel: De uttrykker prioriteringer som blir synlige for leverandørene. Hvis sikkerhet vektes med 5 % og pris med 30 %, vil seriøse sikkerhetsorienterte leverandører merke det, og det vil deres eget team også gjøre når kontrakten er signert. En vektfordeling som settes i hast for å fylle ut tabellen, blir lest som sannheten av alle utenfor rommet. Fastsett den én gang sammen med beslutningstakerne, og endre den bare gjennom samme formalitet som da den ble fastsatt.

Referansesjekk og pilot

Casestudier er markedsføring; referansesjekker er dokumentasjon. Den gode samtalen er kort og spør om det som faktisk skjedde, ikke bare om det som ble levert: Ble prosjektet ferdig? Hva endret seg i omfanget? Hvem var faktisk med på teamet? Hva ville kunden gjort annerledes? Ville de startet prosjektet på nytt med denne leverandøren? Svar i fortid og konkrete detaljer er signalet.

Be om en referanse fra et prosjekt som ligner deres i størrelse og kompleksitet, ikke leverandørens stolteste oppdrag – en flaggskipimplementering til dobbelt så stort budsjett sier lite om hvordan teamet arbeider i deres skala. Kontroller også referansen selv: En kontakt leverandøren har briefet på forhånd, er en anbefaling, ikke en referanse. Den nyttige samtalen er den der kunden får vite hva dere spør om der og da.

En kort betalt pilot tester deretter det ingen referanse kan teste: hvordan dette teamet samarbeider med deres folk når kravene er ufullstendige. Reglene for utforming er de samme som for enhver pilot – reelt arbeid, skriftlige godkjenningskriterier, én endring underveis og en beslutningsregel som er avtalt på forhånd. Siden om utkontraktering går nærmere inn på pilotutforming.

Kontraktsklausuler som bør kontrolleres

• Overføring av immaterielle rettigheter – rettigheter til kode, dokumentasjon og avledede verk overføres til dere fra det de skapes, ikke først ved siste betaling.
• Dataeierskap – dataene deres forblir deres; leverandørens rettigheter begrenses til det som trengs for leveransen.
• Godkjenning – hva godkjenning betyr, hvem som erklærer den, og prosessen når noe ikke består.
• Endringsstyring – hvordan endringer i omfanget foreslås, prises og godkjennes; uten dette blir hver endring en tvist.
• Avslutning og overgang – kildekode, tilgang, dokumentasjon og bistand ved avslutning; hvordan kunnskap overføres hvis leverandøren skiftes ut.
• Escrow – når virksomhetens kontinuitet avhenger av komponenter leverandøren holder, hva som skjer hvis leverandøren ikke kan fortsette.
• Ansvar – begrensninger, unntak og det som ikke er forsikret; les dette med samme oppmerksomhet som prisen.
• Oppsigelse – oppsigelsesfrister, plikter etter oppsigelse og prosessen for tilbakelevering eller sletting av data.

Vanlige spørsmål

Bør vi sende en RFI eller en RFP først?

En RFI brukes når markedet eller problemet er uklart – dere spør hva som finnes og hva det koster. En RFP brukes når kravene og evalueringsmetoden er definert. Sender dere en RFP tidligere, flytter dere bare kravarbeidet inn i hver leverandørs tilbud, formulert med leverandørens ord og prioriteringer.

Hvor mange leverandører bør vi invitere?

Få nok til at dere kan lese hvert tilbud ordentlig og ringe alle referansene. De fleste evalueringer mister kvalitet når antallet blir større enn en håndfull. En kortliste bygget på en RFI, en innledende samtale og ett lignende referanseprosjekt er som regel mer nyttig enn en lang liste med kjente navn.

Hvordan bør vektene fastsettes?

Ta utgangspunkt i prioriteringene deres, før dere ser et tilbud, og bli enige med personene som skal leve med resultatet. En vanlig feil er lik vekt på alt, som i praksis betyr at ingenting er viktigere enn noe annet. Hvis pris eller risiko er avgjørende for dere, bør vektene vise det.

Bør pris inngå i poengsettingen?

Ja, men som ett vektet kriterium med fastsatt omfang, ikke som hele evalueringen. En pris uten et definert omfang belønner leverandøren som antok minst arbeid. Pris derfor kravene først, og sammenlign deretter totalsummer for det samme.

Hvordan gir jeg poeng for sikkerhetssvar?

Vurder dokumentasjon, ikke tone. Tre nivåer fungerer: ingen standpunkt (1), retningslinjer beskrevet (3), sertifikatets omfang kontrollert samt sikker utvikling beskrevet og dokumentasjon fremlagt (5). Hvis leverandøren ikke har sertifikat, spør skriftlig hvilke tilsvarende kontroller som finnes. Et ærlig nei med dokumenterte kontroller scorer bedre enn et ja som ikke kan etterprøves.

Kan vi endre kravene etter RFP-en?

Før innleveringene, ja – så lenge endringen kunngjøres for alle. Etter innlevering kan det bare gjøres gjennom en formell avklaring som alle tilbydere mottar. Å endre kravene i stillhet for én leverandør ødelegger sammenlignbarheten hele prosessen er bygget på. Etter kontraktsinngåelse er det endringsstyringen som skal brukes.

Kilder og standarder

• ISO – utgiver av ISO/IEC 27001 (styringssystem for informasjonssikkerhet); bekreft gjeldende utgave og sertifikatets omfang før dere legger det til grunn.
• OWASP – utgiver av sjekklisten over de 10 største sikkerhetsrisikoene i webapplikasjoner som det vises til på denne siden.
• Prinsippene for poengmatriser følger publisert praksis for RFP-maler; vektene som vises, er et eksempel som skal redigeres, ikke en anbefaling. Denne siden er veiledning om innkjøp, ikke juridisk rådgivning, og WorldwideTradeX hevder ingen sertifisering eller revisjon.

Relaterte sider

Programvareutvikling · IT-utkontraktering fra Türkiye · Kostnads- og prismodeller · IT-revisjon og rådgivning · Be om et tilbud