Mange organisasjoner kan identifisere sine behov, men har en hard tid å kartlegge disse inn krav. Dette kan være en oppskrift på fiasko når man skal vurdere en leverandørs svar på en RFP. Jeg har allerede diskutert dos and don'ts om hvordan å oppfordre leverandørene med riktig informasjon. Riktignok er det mange kontraktsmessige problemer som oppstår når du utvikler en RFP, men de er noe unikt for hver enkelt organisasjon, så jeg har ikke rørt på disse elementene.

Nøkkelen til evalueringen er å forstå hva kravene er mest kritiske til organisasjonen. For noen organisasjoner vil dette koste, for andre vil det være de tekniske aspektene. Uavhengig av de områdene av fokus, er det nødvendig å rangere disse områdene for betydning og for å tildele en vekt til hvert av områdene. Dette bør gjøres ved pengeinnsamling innspill fra beslutningstakere i organisasjonen og som et minimum bør inkludere nettverksinfrastruktur gruppen, driftsgruppe og sikkerhetsgruppen. Disse gruppene bør sette seg ned og ha en diskusjon om de viktigste fokusområder og deres betydning for organisasjonen for å levere de tjenestene du ønsker. Utviklerne av RFP skal presentere de viktigste fokusområder som er utviklet for evalueringsformål og gruppen som helhet bør tildele vektede verdier til områdene. Disse vektede verdier blir brukt til å skille mellom fokusområder når oppnå en leverandør respons. Du kan bruke en hvilken som helst skala du vil, 1-50, 1-100 etc, men det viktigste punktet er at du får konsensus fra alle grupper. Nedenfor er et eksempel på vektede prioriteringer.
Koste 45Technical Funksjoner 35Operational Support 20

RFP bør oppfordre innspill til hver av de viktigste fokusområder. Inngangen for hvert fokusområde kan tildeles score for å skille mellom hver leverandører 'offer for den aktuelle funksjonen som blir vurdert. I det siste har jeg brukt en enkel poengsystem for å evaluere leverandørens svar på hver tast funksjonen eller krav. Poengsystemet jeg har brukt er som følger:
Støtter ikke funksjonen 0Supports funksjonen 1Supports verre 2Supports bedre 3

Dette er for en to leverandør eksempel, dersom antall leverandører øker støttene verre og bedre tall har som skal endres.

for eksempel, la oss si at du er ute etter multicast støtte fra en leverandør. Hvis en leverandør støtter funksjonen, og den andre har du ikke tildele en leverandør en 0 (støtter ikke) og andre leverandører en 1 (støtter). Hvis de begge støtter denne funksjonen, men man har en fordel over andre tildele en leverandør et tre (støtter bedre) og den andre en 2 (støtter verre). Hvis de begge støtter det like de begge får en 1. Dette gjør det mulig å skille mellom de 2 leverandørers svar. Nå som du har scoret alle områder av fokus, kan du bruke vekter for å finne ut hvilken leverandør er det riktige valget. Når du total score for hver del, kan du multiplisere med vekter for å få en samlet poengsum. Multicast er en teknisk funksjon slik resultatet for de tekniske funksjonene vil bli multiplisert med vektingen av tekniske funksjoner. Dette gjør det mulig å differensiere basert på betydningen av hver av de fokusområder. Hvis en leverandør er bedre på den tekniske siden, men verre på kostnadssiden, vil dette bli reflektert i den totale poengsummen.

Nøkkelen til denne tilnærmingen er at det tillater deg å vurdere viktige funksjoner, funksjonalitet og muligheter uavhengige av dine krav. Vekten tildelt hver fokusområde differensierer basert på dine individuelle behov. Det er en veldig vitenskapelig tilnærming til å vurdere leverandørens svar.

Robbie Harrell (CCIE # 3873) er den nasjonale anbefalingen Lead for avanserte infrastrukturløsninger for SBC Communications. Han har over 10 års erfaring gir strategiske, næringsliv og tekniske konsulenttjenester til kunder. Robbie bor i Atlanta, og er utdannet ved Clemson University. Han har bakgrunn fra stillinger som Principal Architect hos International Network Services, Lucent, Frontway og Callisma.