RFP za razvoj softvera: kontrolna lista dobavljača

RFP za razvoj softvera treba da navede problem, funkcionalne i nefunkcionalne zahteve, potrebe u vezi sa bezbednošću i podacima, komercijalne uslove i način bodovanja pre nego što bilo koji dobavljač odgovori. Bodujte ponderisane kriterijume umesto da se naknadno raspravljate, proverite reference umesto da verujete studijama slučaja i sprovedite kratak plaćeni pilot pre potpisivanja bilo čega što obavezuje budžet.

Šta treba da sadrži RFP za softver?

Svrha dokumenta je da odgovori budu uporedivi. Dobavljač može da odgovori samo na ono što je napisano; RFP koji opisuje viziju i traži cenu poziva na ponude koje sve zvuče odlično, a nijedna se ne može proceniti u odnosu na druge. Funkcionalni sadržaj, ograničenja i pravilo bodovanja moraju biti utvrđeni pre prvog odgovora, inače procena postaje pregovaranje o kriterijumima.

Postoji i redosled koji štedi mesece: RFP nije mesto na kom otkrivate šta vam je potrebno. Zahtevi nastaju iz internog rada — vlasnici procesa opisuju kako poslovanje zaista funkcioniše, finansije navode šta mora da se uskladi, a ljudi koji će svakodnevno koristiti sistem govore gde je sadašnji problem. Taj rad je spor i politički i odvija se pre uključivanja bilo kog dobavljača. Timovi koji ga prepuste prvom dobavljaču koji se pojavi dobiju zahteve napisane jezikom tog dobavljačevog proizvoda, zbog čega svaka druga ponuda izgleda kao loš izbor — ne zato što to jeste, već zato što je merilo napisano oko jednog ponuđača.

Vredi sačuvati još jednu razliku između tri dokumenta koja se često mešaju. RFI pita tržište šta postoji; kratak je, prethodi zahtevima i ni na koga ne preuzima obavezu. RFP traži ponudu na osnovu definisanih zahteva i unapred navedenog načina procene. RFQ traži cenu za definisan obim. Pokretanje RFQ-a pre nego što je obim utvrđen najčešći je način da uporedite tri broja koji znače tri različite stvari.

Pet stvari koje potpun RFP radi, a nepotpun ne:

• Definiše problem, a ne rešenje. „Smanjiti vreme za sastavljanje mesečnog konsolidovanog izveštaja sa nekoliko dana na definisan broj sati“ jeste opis problema; „napravite nam skladište podataka“ jeste pretpostavljeno rešenje koje možda neće rešiti problem.


• Razdvaja zahteve od preferencija. Obavezne funkcionalnosti odlučuju da li se prolazi, poželjne odlučuju o rangu, a korisne funkcionalnosti koje bi bilo lepo imati ne odlučuju ništa. Dobavljači ozbiljno odgovaraju samo kada je ta razlika vidljiva.


• Navodi ograničenja. Postojeći sistemi koji moraju da se integrišu, podaci koji moraju da se migriraju, obaveze revizije i čuvanja podataka, rok za puštanje u rad i osobe koje odobravaju rezultat.


• Unapred navodi način procene. Ponderisani kriterijumi, osobe koje procenjuju, potrebni dokazi i trenutak kada neuspešni dobavljači dobijaju sažetak svojih rezultata.


• Postavlja datume procesa. Rok za pitanja, period za pojašnjenja, rok za dostavljanje, period procene i datum odluke. Proces bez datuma privlači dobavljače koji su već zauzeti.

Struktura RFP-a

Funkcionalni i nefunkcionalni zahtevi

Funkcionalni zahtevi opisuju šta sistem radi: koje procese podržava, za koje uloge i sa kojim rezultatima. Nefunkcionalni zahtevi opisuju koliko dobro to radi, a oni najčešće nedostaju — pa se kasnije sprovode skupo ili se uopšte ne sprovedu.

U većini B2B projekata vredi izričito navesti:

• Performanse. Vreme odziva pri navedenom opterećenju, za operacije koje su važne — unos porudžbine, generisanje izveštaja i zatvaranje meseca.


• Dostupnost. Potreban nivo neprekidnog rada, prozori za održavanje i postupak kada sistem nije dostupan — cilj bez opisa prihvatljivog prekida rada nije zahtev.


• Oporavak. RTO i RPO objašnjeni jednostavnim jezikom: koliko brzo se poslovanje nastavlja posle incidenta i koliko rada sme da bude izgubljeno. Oba broja pripadaju proceni, ne samo ugovoru.


• Trag revizije. Ko je šta promenio i kada, koliko dugo se čuva i ko može da ga preuzme — posebno tamo gde se kreću novac, zalihe ili lični podaci.


• Pristupačnost i upotrebljivost. Ko koristi sistem, na kojim uređajima i na kojim jezicima; sistem kojim magacin ne može da upravlja nije implementiran, bez obzira na rezultat bodovanja.


• Integracija i podaci. Koji sistemi se povezuju, u kom smeru podaci teku i ko je vlasnik glavnog zapisa za svaki entitet.

Pitanja o bezbednosti i usklađenosti

Bezbednost je bolje postaviti kao pitanja sa obaveznim dokazima nego kao polje sa odgovorom da ili ne. Vredi uključiti sledeće:

• ISO/IEC 27001 — da li ga dobavljač poseduje i šta obuhvata sertifikovani obim? Sertifikat koji pokriva prodajnu organizaciju, ali ne i timove za isporuku, govori vam nešto konkretno.


• Bezbedan razvoj — gde su bezbednost u dizajnu, pregled koda i testiranje; da li se zavisnostima i ranjivostima upravlja rutinski.


• OWASP Top 10 — da li je deo pregleda dobavljača za komponente dostupne preko veba; konkretno pitanje na koje se može odgovoriti.


• Kontrola pristupa — ko može da dođe do vaših okruženja i podataka, kako se pristup odobrava i ukida i kakvo beleženje postoji.


• Obaveze zaštite podataka — KVKK i GDPR gde se primenjuju; ko je rukovalac, ko obrađivač i šta ugovor o obradi podataka kaže o podobrađivačima i obaveštavanju o povredi podataka.

Komercijalni uslovi i SLA

Tražite cenu u strukturi koju možete da uporedite: šta je uključeno, šta se posebno naplaćuje i kako se promene cene. Jedan broj bez obima iza njega ne može da se uporedi sa drugim jednim brojem; stranica o troškovima i modelima cena objašnjava uobičajene strukture i pitanja koja svaka od njih otvara.

SLA zaslužuju istu preciznost kao i zahtevi. Procenat dostupnosti ima smisla samo uz način merenja, izuzetke i pravni lek; vreme odziva ima smisla samo uz definicije ozbiljnosti i radno vreme. Tražite od svakog dobavljača da definiše termine unutar SLA, umesto da prihvatite stranicu procenata bez definicija.

Matrica bodovanja procene

Šablon koji možete direktno kopirati. Ponderi ispod su primer — postavite svoje prema prioritetima i zadržite zbir na 100. Definišite šta znače 1, 3 i 5 pre nego što bilo ko počne da boduje, a ne nakon početka rasprave.

Dve discipline čine da ovo funkcioniše. Bodujte nezavisno pre razgovora, kako prvi samouvereni glas ne bi odredio mišljenje cele prostorije. Zatim zapišite po jednu rečenicu obrazloženja za svaku ocenu — dobavljači koji dobiju sažetak rezultata sa razlozima mnogo lakše prihvataju ishod, a vaš tim može da ga obrazloži i šest meseci kasnije.

Treća disciplina odnosi se na to ko boduje. Panel treba da obuhvati ljude koji će živeti sa rezultatom — vlasnika procesa, osobu odgovornu za podatke i nekoga iz bezbednosti ili finansija tamo gde te funkcije postoje — a ne samo nabavku. Procene tiho propadaju kada panel boduje ono što ume da proceni (strukturu ponude i uglađenost prodajnog tima), a odlaže ono što ne ume (da li pristup integraciji zaista odgovara postojećim sistemima). Jedna tehnička osoba koja ima ovlašćenje da kaže „ovo neće raditi sa onim što koristimo“ sprečava veći trošak nego bilo koji popust.

I sami ponderi zaslužuju još jedno upozorenje: oni su izjava o prioritetima koja postaje vidljiva dobavljačima. Ako bezbednost nosi 5%, a cena 30%, ozbiljni dobavljači kojima je bezbednost važna to će primetiti, kao i vaš tim kada ugovor bude potpisan. Ponderi postavljeni na brzinu, samo da bi se popunila tabela, svima izvan prostorije izgledaju kao istina; postavite ih jednom, uz donosioce odluka u prostoriji, i menjajte ih samo uz istu formalnost sa kojom su postavljeni.

Provera referenci i pilot

Studije slučaja su marketing; provera referenci je dokaz. Dobar poziv je kratak i pita šta se dogodilo, a ne samo šta je isporučeno: da li je projekat završen, šta se promenilo u obimu, ko je zaista bio u timu, šta bi uradili drugačije i da li bi ponovo započeli projekat sa ovim dobavljačem. Odgovori u prošlom vremenu i konkretni odgovori predstavljaju signal.

Tražite referencu sa projekta koji je po veličini i složenosti sličan vašem, a ne najponosniji rad dobavljača — vodeća implementacija čiji je budžet dvostruko veći od vašeg malo govori o tome kako se tim ponaša u vašoj razmeri. I sami proverite referencu: kontakt koji dobavljač unapred pripremi jeste preporuka, a ne referenca; koristan poziv je onaj tokom kog klijent tek na licu mesta saznaje šta pitate.

Kratak plaćeni pilot zatim proverava ono što nijedna referenca ne može: kako ovaj tim radi sa vašim ljudima kada su zahtevi nepotpuni. Pravila dizajna ista su kao kod svakog dobrog pilota — stvaran rad, pisani kriterijumi prihvatanja, jedna promena usred rada i unapred dogovoreno pravilo odluke. Stranica o autsorsingu detaljnije obrađuje dizajn pilota.

Ugovorne klauzule koje treba proveriti

• Prenos intelektualne svojine — prava na kod, dokumentaciju i izvedena dela prenose se na vas od trenutka nastanka, a ne tek pri konačnoj uplati.
• Vlasništvo nad podacima — vaši podaci ostaju vaši; prava dobavljača ograničena su na ono što je potrebno za isporuku.
• Prihvatanje — šta prihvatanje znači, ko ga proglašava i koji je postupak kada rezultat ne prođe prihvatanje.
• Kontrola promena — kako se promene obima traže, cene i odobravaju; bez toga svaka promena postaje spor.
• Izlazak i tranzicija — izvorni kod, pristup, dokumentacija i pomoć na kraju saradnje; kako se znanje prenosi ako dobavljač bude promenjen.
• Escrow — kada kontinuitet poslovanja zavisi od komponenti koje drži dobavljač, šta se dešava ako dobavljač ne može da nastavi.
• Odgovornost — ograničenja, izuzeci i ono što nije osigurano; čitajte ovu klauzulu sa istom pažnjom kao i cenu.
• Raskid — otkazni rokovi, obaveze posle raskida i postupak vraćanja ili brisanja podataka.

Često postavljana pitanja

Da li prvo treba da pošaljemo RFI ili RFP?

RFI pošaljite kada tržište ili problem nisu jasni — pitate šta postoji i koliko košta. RFP pošaljite kada su zahtevi i način procene definisani; ranije slanje samo premešta posao definisanja zahteva u ponudu svakog dobavljača, napisanu njegovim rečima i prema njegovim prioritetima.

Koliko dobavljača treba pozvati?

Dovoljno malo da možete pravilno da pročitate svaku ponudu i pozovete svaku referencu. Većina procena gubi kvalitet kada broj pređe nekoliko; uži izbor sastavljen na osnovu RFI-ja, razgovora za proveru i jednog sličnog referentnog projekta obično je korisniji od duge liste poznatih imena.

Kako treba postaviti pondere?

Na osnovu vaših prioriteta, pre nego što vidite bilo koju ponudu, i uz saglasnost ljudi koji će živeti sa rezultatom. Česta greška je jednako ponderisanje svega, što zapravo znači da ništa nije važnije od bilo čega drugog; ako kod vas dominiraju cena ili rizik, ponderi to treba da pokažu.

Da li cenu treba bodovati?

Da, ali kao jedan ponderisani kriterijum sa utvrđenim obimom, a ne kao celu procenu. Cena bez obima nagrađuje dobavljača koji je pretpostavio najmanje rada; najpre cenite svoje zahteve, a zatim uporedite ukupne iznose za istu stvar.

Kako da bodujem odgovore o bezbednosti?

Na osnovu dokaza, a ne tona odgovora. Tri nivoa su dovoljna: nema stava (1), politike su opisane (3), obim sertifikata je proveren, bezbedan razvoj opisan i dokazi dostavljeni (5). Ako dobavljač nema sertifikat, tražite napismeno koje ekvivalentne kontrole postoje — iskreno „ne“ sa dokumentovanim kontrolama dobija bolju ocenu od neproverljivog „da“.

Možemo li menjati zahteve posle RFP-a?

Pre dostavljanja ponuda, da — uz objavljivanje promene svima. Posle dostavljanja, samo kroz formalno pojašnjenje koje dobijaju svi ponuđači; tajna promena zahteva za jednog dobavljača ukida uporedivost na kojoj je ceo proces zasnovan. Posle ugovora, za to služi kontrola promena.

Izvori i standardi

• ISO — izdavač standarda ISO/IEC 27001 (upravljanje bezbednošću informacija); pre oslanjanja na sertifikat proverite važeće izdanje i njegov obim.
• OWASP — izdavač kontrolne liste Top 10 rizika po bezbednost veb-aplikacija koja je navedena na ovoj stranici.
• Načela matrice bodovanja prate objavljenu praksu šablona za RFP; prikazani ponderi su primer za izmenu, a ne preporuka. Ova stranica je smernica za nabavku, ne pravni savet, i za WorldwideTradeX se ne tvrdi da poseduje sertifikat ili obavljenu reviziju.

Povezane stranice

Razvoj softvera · IT autsorsing iz Turske · Troškovi i modeli cena · IT revizija i konsalting · Zatražite ponudu