Hvordan skrive en tilbudsforespørsel for servicedesk-programvare

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

Sliter du med å finne riktig servicedesk-programvare? Lær hvordan du utarbeider en tilbudsforespørsel som tydelig definerer behovene dine, slik at det blir enklere for teamet ditt å velge leverandør.

Service desk software rfp standard editorial post 46481

Key Takeaways

Skriv en tilbudsforespørsel for å definere behovene dine tydelig, sammenligne leverandører effektivt og sikre at du får den beste servicedesk-programvaren for teamet ditt.

Dropp tilbudsforespørselen hvis organisasjonen din er liten, eller hvis behovene dine er enkle nok til at du kan evaluere leverandører uten en formell prosess.

Oppnå bedre samsvar og priser ved å bruke en tilbudsforespørsel til å forhandle med leverandører, slik at løsningen oppfyller budsjettet og kravene dine.

En RFP, eller en forespørsel om forslag, er et dokument du bruker når du trenger å finne riktig leverandør for en kompleks løsning, for eksempel programvare for servicedesk. Denne veiledningen er for deg som trenger å ta informerte beslutninger uten å kaste bort tid.

Ved å skrive en RFP kan du tydelig beskrive behovene dine, slik at det blir enklere å sammenligne leverandører. Det reduserer risikoen for å velge feil løsning ved å sikre at du og teamet ditt vet nøyaktig hva dere ser etter.

Ved å utforme en gjennomtenkt RFP effektiviserer du prosessen med å evaluere leverandører. Du sparer tid, minimerer forvirring og sørger for at programvaren du velger, er i tråd med organisasjonens mål.

Trenger du faktisk en RFP?

En RFP blir viktig når teamet ditt står overfor komplekse krav, opererer i en regulert bransje eller må evaluere flere leverandører for en implementering i stor skala. Den er også avgjørende når du har spesifikke krav til samsvar, eller når et feil valg kan føre til betydelige driftsforstyrrelser. Hvis disse situasjonene høres kjent ut, bør du vurdere å utarbeide en RFP for å sikre at du tar det riktige valget:

  • Komplekse integrasjonskrav
  • Samsvar med kravene i en regulert bransje
  • Storskalaimplementering på tvers av flere lokasjoner
  • Stramme budsjettrammer med høy risiko
  • Behov for ansvarlighet hos leverandøren

Når en RFP kan være unødvendig omfattende

Hvis behovene dine er enkle, organisasjonen din er liten eller du allerede kjenner til de beste alternativene, er en RFP kanskje ikke nødvendig. I slike tilfeller kan du konsentrere deg om å evaluere førstevalget ditt blant programvareløsninger for servicedesk:

Fremhevet programvare for servicedesk du bør vurdere

\u003cspan style=\u0022font-weight: 400;\u0022\u003eHer er min liste over de 10 beste tilgjengelige programvareløsningene for servicedesk, slik at du kan komme i gang med søket ditt:\u003c/span\u003e

RFI vs. RFP vs. RFQ: Hva er forskjellen?

Når du skal bestemme hvordan du skal kjøpe programvare for servicedesk, kan det spare deg for tid og arbeid å kjenne forskjellene mellom en RFI, RFP og RFQ. En RFI innhenter generell informasjon, en RFP ber om detaljerte forslag, og en RFQ ber om spesifikke priser. Ikke alle kjøp krever en RFP. Velg med omhu for å redusere unødvendige trinn og få det du trenger på en effektiv måte:

DokumenttypeInformasjonsforespørsel (RFI)FormålInnhente generell informasjon om leverandørens muligheterNår det brukesNår du trenger å forstå markedet eller teknologialternativeneHva som skal inkluderesInformasjon om leverandøren, tjenestetilbud, teknologioversiktNødvendig detaljnivåLavt
DokumenttypeForespørsel om forslag (RFP)FormålBe leverandører om detaljerte forslagNår det brukesNår du har et komplekst prosjekt med spesifikke kravHva som skal inkluderesProsjektmål, detaljerte krav, evalueringskriterierNødvendig detaljnivåMiddels til høyt
DokumenttypePrisforespørsel (RFQ)FormålInnhente spesifikke priser for definerte løsningerNår det brukesNår du vet nøyaktig hva du trenger og ønsker å sammenligne priserHva som skal inkluderesSpesifiserte priser, leveringsbetingelser, betalingsvilkårNødvendig detaljnivåMiddels

Vanlige RFP-feil du bør unngå

Hvis du haster gjennom en RFP eller hopper over viktige detaljer, kan det føre til forvirring, bortkastet tid eller at du velger feil leverandør. Ved å unngå noen vanlige feil kan teamet ditt sikre et smidigere valg av programvare for servicedesk. La oss se på noen fallgruver du bør være oppmerksom på:

Mangelfull bakgrunn eller kontekst

Uten riktig bakgrunn eller kontekst kan ikke leverandørene forstå behovene dine fullt ut. Dette kan føre til forslag som bommer på målet. Del bedriftens oppdrag, mål og eventuelle relevante utfordringer. Det hjelper leverandørene med å tilpasse løsningene sine til din unike situasjon.

Manglende eller uklart budsjett

Hvis du ikke spesifiserer et budsjett, kan det føre til forslag som bommer fullstendig. Leverandørene trenger å vite hvilke kostnader for servicedeskprogramvare du er forberedt på å vurdere. Vær åpen om budsjettintervallet ditt for å unngå å kaste bort tid på alternativer du ikke har råd til, og for å sikre realistiske forslag.

Vage krav eller juridisk sjargong

Hvis kravene dine er vage eller fulle av juridisk sjargong, kan leverandørene feiltolke behovene dine. Beskriv tydelig hva du ser etter, med lettfattelige formuleringer. Unngå juridisk språk for å sikre at alle forstår forventningene og leveransene.

Ingen delte evalueringskriterier

Uten evalueringskriterier må leverandørene gjette på hva som er viktigst for deg. Del kriteriene dine på forhånd for å få forslag som samsvarer med prioriteringene dine. Dette hjelper deg med å sammenligne alternativene på en rettferdig måte og velge det som passer best til behovene dine.

Ingen standardformat for leverandørenes svar

Hvis du ikke angir et standardformat, kan leverandørenes svar variere svært mye, noe som gjør sammenligninger vanskelige. Gi dem en mal eller en oversikt for svarene. Dette sikrer konsistens og gjør det enklere å evaluere og sammenligne forslag side om side.

Get Free Access
Get regular tech leadership wisdom for delivering better software and systems.
Get Free Access

Have an account? Log In

Sett sammen RFP-teamet for servicedeskprogramvaren

Å utarbeide en god RFP er ikke en jobb for én person; det krever innspill fra og forståelse av behovene til en tverrfunksjonell gruppe. Ved å involvere de rette personene tidlig kan du redusere risiko og forhindre merarbeid senere. La oss se på hvem som bør være en del av RFP-teamet ditt, og hvorfor:

Prosjekteier

Prosjekteieren gir myndigheten og ressursene som trengs for å drive RFP-prosessen fremover. Vedkommende sikrer samsvar med strategiske mål og har siste ord i viktige beslutninger. Vanligvis er dette en person i toppledelsen, for eksempel en CTO eller avdelingsleder, som kan være en pådriver for prosjektet i hele organisasjonen.

Funksjonseksperter

Funksjonseksperter har detaljert kunnskap om bestemte områder som servicedeskprogramvaren vil påvirke. De sikrer at RFP-en inneholder alle nødvendige tekniske og driftsrelaterte krav. I teamet ditt kan dette være IT-ledere, nettverksadministratorer eller systemarkitekter som forstår det tekniske landskapet.

Innkjøpsansvarlige eller RFP-skribenter

Innkjøpsspesialister eller erfarne RFP-skribenter sikrer at dokumentet er riktig strukturert og inneholder alle nødvendige deler. De bidrar til å håndtere forhandlinger med leverandører og opprettholde samsvar med innkjøpsretningslinjene. Denne gruppen omfatter ofte innkjøpsledere eller erfarne RFP-konsulenter.

Sluttbrukere og interessenter

Sluttbrukere og interessenter gir innsikt i hverdagslige utfordringer og arbeidsflyter som programvaren bør håndtere. Innspillene deres sikrer at løsningen dekker behovene i den virkelige verden og forbedrer brukertilfredsheten. Vurder å involvere kundestøttemedarbeidere, avdelingsledere eller andre teammedlemmer som jevnlig skal bruke programvaren.

Definer nødvendige funksjoner og mål

Før du sender ut en RFP, må teamet ditt tydelig definere hva den nye løsningen må kunne gjøre – og hvorfor. Enighet om utfordringer, mål og ufravikelige krav hjelper leverandørene med å svare nøyaktig og gjør det enklere for deg å evaluere forslagene. Identifiser disse nøkkelelementene før du går videre:

  • Utfordringer med det nåværende systemet: Hvilke problemer opplever dere nå? Kanskje den nåværende servicedeskprogramvaren er treg eller mangler integrasjonsfunksjoner. Ved å identifisere disse utfordringene kan du finne en løsning som løser dem direkte.
  • Nødvendige forbedringer og ønskede resultater: Hvilke forbedringer trenger dere, og hvordan skal suksess måles? Hvis raskere svartider er et mål, må du definere hva «raskere» betyr for teamet ditt.
  • Funksjonelle, tekniske og regulatoriske behov: Hvilke konkrete funksjoner og krav til regelverksetterlevelse må oppfylles? Sørg for at leverandørene vet om du trenger støtte for flere språk eller samsvar med GDPR.
  • Brukerroller, bruksnivåer og arbeidsflyter: Hvem skal bruke programvaren, og hvordan? Kartlegg brukerroller og arbeidsflyter for å sikre at løsningen passer inn i organisasjonens daglige drift.
  • Preferanser for utrulling: Trenger dere en skybasert løsning eller lokal installasjon? Ta hensyn til IT-infrastrukturen og behovet for fremtidig skalerbarhet når du tar beslutningen.

Skriv RFP-en for servicedeskprogramvaren

Nå er det på tide å samle alt i et tydelig og strukturert RFP-dokument. En velorganisert og komplett RFP gjør det enklere for leverandørene å svare nøyaktig og for teamet ditt å evaluere svarene. Her er hva RFP-en bør inneholde:

1. Sammendrag

Sammendraget bør gi en overordnet oversikt over prosjektet. Forklar formålet med RFP-en, organisasjonens mål og problemet dere ønsker å løse. Dette gir leverandørene et grunnlag for raskt å forstå behovene deres. Hold det kortfattet, og gi nok kontekst uten å overvelde med detaljer.

2. Arbeidsomfang

Beskriv i detalj hva dere forventer at leverandøren skal levere. Ta med konkrete oppgaver, leveranser og eventuelle tidsfrister eller milepæler. Dette hjelper leverandørene med å vurdere prosjektets størrelse og kompleksitet. Vær tydelig på hva som omfattes, og hva som ikke omfattes, for å unngå misforståelser.

3. Tekniske krav

List opp de tekniske spesifikasjonene den nye programvaren må oppfylle. Ta med kompatibilitet med eksisterende systemer, nødvendige integrasjoner og eventuelle ytelseskrav. Tydelige tekniske krav hindrer leverandører i å tilby løsninger som ikke vil fungere for dere.

4. Leverandørens kvalifikasjoner

Spesifiser hvilke kvalifikasjoner og hvilken erfaring dere ser etter hos en leverandør. Dette kan omfatte tidligere prosjekter, bransjekompetanse eller sertifiseringer. Når dere vet hvem dere samarbeider med, blir det enklere å sikre at leverandøren er i stand til å oppfylle behovene deres.

5. Krav til sikkerhet og samsvar

Beskriv eventuelle sikkerhetsstandarder eller samsvarskrav programvaren må oppfylle. Enten det gjelder GDPR eller en annen standard, må leverandørene kjenne til disse kravene på forhånd. Dette sikrer at de foreslåtte løsningene er sikre og i samsvar med regulatoriske forpliktelser.

6. Forventninger til implementering og opplæring

Avklar hvordan dere forventer at implementeringen skal gjennomføres, og hvilken opplæring teamet deres trenger. Ta med tidsfrister og forventninger til støtte. Dette hjelper leverandørene med å planlegge hvordan de skal ta løsningen i bruk og forberede teamet deres på bruken av den.

7. Priser og lisensiering

Gi veiledning om hvordan dere ønsker at prisinformasjonen skal presenteres. Avklar om dere trenger en oppdeling etter modul, bruker eller funksjon. Dette gjør det enklere å sammenligne kostnader på en effektiv måte og forstå den økonomiske forpliktelsen som følger med.

8. Avtalevilkår

Oppgi eventuelle foreløpige avtalevilkår eller betingelser leverandørene bør kjenne til. Dette kan omfatte garantiperioder, støtteavtaler eller oppsigelsesklausuler. Tydelige avtalevilkår hjelper leverandørene med å forstå det juridiske rammeverket de skal arbeide innenfor.

9. Instruksjoner for innsending

Gi detaljerte instruksjoner om hvordan leverandørene skal sende inn tilbudene sine. Ta med tidsfrister, formatkrav og kontaktinformasjon for spørsmål. Tydelige instruksjoner for innsending sikrer at dere mottar tilbud i et ensartet format, noe som gjør dem enklere å gjennomgå.

Definer evalueringskriteriene

Tydelig definerte evalueringskriterier bidrar til å holde beslutningsprosessen objektiv, transparent og i tråd med forretningsmålene. Fastsett disse kriteriene før dere går gjennom tilbudene, for å unngå skjevheter og sikre konsekvent vurdering. Slik definerer dere hva som er viktigst ved evaluering av programvare for servicedesk:

Hva er viktigst?

Velg 3–5 vektede kategorier som samsvarer med målene og prioriteringene deres. Dette hjelper dere med å fokusere på det som virkelig er viktig for organisasjonen. Vanlige kategorier for poengsetting av RFP-er for programvare til servicedesk kan omfatte:

  • Funksjonalitet
  • Brukeropplevelse
  • Integrasjonsmuligheter
  • Kostnad
  • Leverandørstøtte

Bruk en poengmatrise

En poengmatrise lar deg bruke vekting på de valgte kategoriene, slik at deres betydning for teamet ditt gjenspeiles. Hvis funksjonalitet for eksempel er avgjørende, kan den ha høyere vekt enn kostnad. Gi hvert kriterium en poengsum på en skala fra 1–5 eller 1–10 for å tallfeste hvor godt hvert forslag oppfyller behovene dine. Juster vektingen basert på interne prioriteringer for å sikre at matrisen samsvarer med målene dine.

Avklar poenggivingsprosessen

Definer hvem som skal gi poeng til forslagene, og hvordan poenggivningen skal gjennomføres. Bruk en standardisert vurderingsskala for å opprettholde konsistens og rettferdighet. Planlegg et møte med alle som skal vurdere forslagene, før poenggivningen starter, slik at dere kan avstemme forventninger og kriterier. Dette sikrer at alle forstår prosessen og vurderer forslagene etter de samme standardene.

Send ut RFP-en for service desk-programvare

Å sende ut RFP-en handler ikke bare om å distribuere den; det handler om å gi leverandørene riktig tilgang, tidsfrister og instruksjoner slik at de kan svare effektivt. En smidig distribusjonsprosess legger grunnlaget for kvaliteten på forslagene du mottar. Slik håndterer du prosessen:

Velg riktig distribusjonsmetode

Vanlige alternativer for distribusjon av en RFP inkluderer e-post, programvareplattformer for RFP-er eller innkjøpsportaler. Et sentralisert system gjør det enklere å følge opp svar og holde orden. Vurder å inkludere en kontaktliste for leverandører eller bruke en rollebasert innboks for å sikre at alle henvendelser sendes til riktig person. Dette holder kommunikasjonen tydelig og effektiv.

Angi tydelige forventninger til tidsplanen

Lag en tydelig tidsplan og inkluder den i selve RFP-en for å holde leverandørene på rett spor. En standard tidsplan for en RFP kan se slik ut:

  • Dato for utsendelse av RFP
  • Periode for spørsmål og svar fra leverandører
  • Frist for endelig innsending
  • Periode for evaluering og valg

Ved å dele denne tidsplanen kan leverandørene planlegge svarene sine, og du sikrer at du mottar forslagene i tide.

Definer kravene til innsending

Leverandørene trenger tydelige instruksjoner for å sende inn forslagene riktig. Angi godkjente filformater, for eksempel PDF-, Word- eller Excel-maler, og oppgi ønsket leveringsmetode, for eksempel en opplastingsportal eller en innboks for svar. Angi om leverandørene må bruke bestemte maler eller skjemaer, og tydeliggjør retningslinjene dine for sene innleveringer. Dette reduserer forvirring og sikrer at du mottar ensartede og fullstendige forslag.

Evaluer leverandørsvar og sett leverandører på kortlisten

Det er her den strukturerte tilnærmingen gir resultater, når teamet ditt med trygghet omgjør leverandørenes svar til en kortliste. Konsistens, objektivitet og samarbeid er avgjørende for alle som deltar i evalueringen. Slik evaluerer og setter du leverandører på kortlisten på en effektiv måte:

  • Organisere og formatere forslag for gjennomgang: Samle alle forslagene i et ensartet format for å gjøre sammenligninger enklere. Bruk en delt mappe eller plattform slik at alle i teamet enkelt får tilgang til dokumentene.
  • Bruke en poengmatrise: Bruk poengmatrisen til å evaluere hvert forslag opp mot kriteriene dine. Dette bidrar til å holde prosessen objektiv og sikrer at dere fokuserer på det som er viktigst for organisasjonen.
  • Planlegge demonstrasjoner og intervjuer: Sett opp demonstrasjoner eller intervjuer med de beste leverandørene for å se løsningene deres i praksis. Hvor godt dekker de de spesifikke behovene dine? Dette trinnet gir innsikt du ikke får fra skriftlige forslag alene.
  • Kontrollere referanser: Kontakt referanser for å få tilbakemeldinger om leverandørens tidligere resultater. Var de pålitelige og støttende? Erfaringer fra virkeligheten kan avdekke om en leverandør passer godt for teamet ditt.
  • Avklare alt som er uklart i forslagene: Ta kontakt med leverandørene hvis deler av forslaget deres er uklare. Ikke anta – still spørsmål for å sikre at du har all informasjonen du trenger for å ta en informert beslutning.

Velg og varsle leverandører

Når teamet har valgt en leverandør, er de siste trinnene like viktige som evalueringsprosessen. Tydelig og profesjonell kommunikasjon med alle leverandører – både de som er valgt, og de som ikke er valgt – er avgjørende. Sørg for at teamet er internt samkjørt før dere går videre til kontraktsinngåelsen. Her er de viktigste trinnene:

Varsle valgte og ikke-valgte leverandører

Rask og respektfull kommunikasjon med alle leverandører opprettholder profesjonaliteten og styrker relasjonene. Send en kort takkemelding eller gi overordnet tilbakemelding der det er hensiktsmessig. Denne tilnærmingen holder døren åpen for fremtidige muligheter og skaper velvilje hos leverandørene.

Forbered deg på de endelige forhandlingene

Før dere går inn i de endelige forhandlingene, bør dere identifisere vanlige punkter som kan kreve diskusjon, for eksempel priser, SLA-er og kontraktsvilkår. Definer på forhånd hvilke punkter teamet ikke kan gå med på, og bruk en sjekkliste eller agenda for å holde fokus. Denne forberedelsen sikrer at forhandlingene blir effektive og produktive.

Sikre intern samordning før signering

Innhent nødvendige godkjenninger, for eksempel godkjenning fra ledelsen eller økonomiavdelingen, og gjennomfør en juridisk gjennomgang eller en gjennomgang av innkjøpsavdelingen. Oppsummer de viktigste beslutningsfaktorene for å hjelpe interne gjennomgåere med å jobbe raskt. Denne samordningen sikrer at alle er enige før kontrakten ferdigstilles.

Hva skjer videre:

Hvis du undersøker programvare for servicedesk, kan du kontakte en rådgiver fra SoftwareSelect for gratis anbefalinger.

Du fyller ut et skjema og har en kort samtale der de går gjennom detaljene i behovene dine. Deretter får du en kortliste over programvare du kan vurdere. De vil til og med hjelpe deg gjennom hele kjøpsprosessen, inkludert prisforhandlinger.

Paulo Gardini Miguel
Paulo is the Director of Technology at the rapidly growing media tech company BWZ. Prior to that, he worked as a Software Engineering Manager and then Head Of Technology at Navegg, Latin America’s largest data marketplace, and as Full Stack Engineer at MapLink, which provides geolocation APIs as a service. Paulo draws insight from years of experience serving as an infrastructure architect, team leader, and product developer in rapidly scaling web environments. He’s driven to share his expertise with other technology leaders to help them build great teams, improve performance, optimize resources, and create foundations for scalability.
Follow the author:

You may also like