Lista e kontrollit për RFP-në e furnizuesit të softuerit për blerësit B2B

Një RFP për softuer duhet të përcaktojë problemin, kërkesat funksionale dhe jofunksionale, nevojat për siguri dhe të dhëna, kushtet tregtare dhe metodën e pikëzimit përpara se të përgjigjet ndonjë furnizues. Pikëzoni kriteret sipas peshës në vend që të debatoni më pas, verifikoni referencat në vend që të besoni studimet e rasteve dhe zhvilloni një pilot të shkurtër me pagesë përpara se të nënshkruani diçka që angazhon buxhet.

Çfarë duhet të përmbajë një RFP për softuer?

Dokumenti shërben që përgjigjet të jenë të krahasueshme. Furnizuesi mund t'u përgjigjet vetëm gjërave të shkruara; një RFP që përshkruan një vizion dhe kërkon çmim nxit propozime që tingëllojnë të gjitha shkëlqyeshëm, por asnjëri nuk mund të vlerësohet kundrejt të tjerëve. Përmbajtja funksionale, kufizimet dhe rregulli i pikëzimit duhet të përcaktohen përpara se të mbërrijë përgjigjja e parë, përndryshe vlerësimi kthehet në negocim të kritereve.

Ekziston edhe një çështje renditjeje që ju kursen muaj: RFP-ja nuk është vendi ku zbuloni çfarë ju nevojitet. Kërkesat dalin nga puna e brendshme — pronarët e proceseve përshkruajnë si funksionon realisht biznesi, financa përcakton çfarë duhet të rakordohet dhe njerëzit që do ta përdorin sistemin çdo ditë tregojnë ku i kanë problemet aktuale. Kjo punë është e ngadaltë dhe politike dhe kryhet përpara se të përfshihet ndonjë furnizues. Ekipet që ia delegojnë furnizuesit të parë që paraqitet, përfundojnë me kërkesa të shkruara në gjuhën e produktit të atij furnizuesi; kështu çdo propozim tjetër duket i papërshtatshëm, jo sepse është i tillë, por sepse standardi u hartua sipas njërit prej ofertuesve.

Vlen të ruhet edhe një dallim mes tre dokumenteve që ngatërrohen shpesh. Një RFI pyet tregun se çfarë ekziston; është e shkurtër, vjen përpara kërkesave dhe nuk angazhon askënd. Një RFP kërkon propozim kundrejt kërkesave të përcaktuara dhe një metode të deklaruar vlerësimi. Një RFQ kërkon çmim për një fushëveprim të përcaktuar. Zhvillimi i një RFQ-je përpara se të ekzistojë fushëveprimi është mënyra më e zakonshme për të krahasuar tre shifra që nënkuptojnë tre gjëra të ndryshme.

Pesë gjërat që bën një RFP e plotë dhe nuk i bën një e paplotë:

• Përcakton problemin, jo zgjidhjen. "Të zvogëlohet koha e përpilimit të raportit të konsoliduar mujor nga ditë në një numër të përcaktuar orësh" është përshkrim i problemit; "na ndërtoni një magazinë të dhënash" është hamendësim për zgjidhjen që mund të mos e zgjidhë problemin.


• Dallon kërkesat nga preferencat. Kushtet e domosdoshme që përcaktojnë kalimin, ato të dëshirueshme që përcaktojnë renditjen dhe gjërat e këndshme për t'u pasur që nuk përcaktojnë asgjë. Furnizuesit përgjigjen seriozisht vetëm kur ky dallim është i qartë.


• Emërton kufizimet. Sistemet ekzistuese që duhen integruar, të dhënat që duhen migruar, detyrimet e auditimit dhe ruajtjes, afati i hedhjes në përdorim dhe personat që japin miratimin.


• Deklaron paraprakisht metodën e vlerësimit. Kriteret me peshë, vlerësuesit, provat e kërkuara dhe koha kur furnizuesit e pasuksesshëm marrin përmbledhjen e pikëve.


• Përcakton datat e procesit. Afati i pyetjeve, periudha e sqarimeve, afati i dorëzimit, periudha e vlerësimit dhe data e vendimit. Një proces pa data tërheq furnizues që janë tashmë të zënë.

Struktura e RFP-së

Kërkesat funksionale dhe jofunksionale

Kërkesat funksionale përshkruajnë çfarë bën sistemi: cilat procese, për cilat role dhe me cilat rezultate. Kërkesat jofunksionale përshkruajnë sa mirë i kryen dhe janë ato që mungojnë më shpesh — e më pas zbatohen me kosto të lartë ose nuk zbatohen fare.

Në shumicën e projekteve B2B ia vlen të përcaktohen shprehimisht:

• Performanca. Kohët e përgjigjes nën një ngarkesë të deklaruar, për operacionet e rëndësishme — regjistrimi i porosive, krijimi i raporteve, mbyllja mujore.


• Disponueshmëria. Koha e punës që i nevojitet biznesit, dritaret e mirëmbajtjes dhe çfarë ndodh kur sistemi nuk funksionon — një objektiv pa përshkrim të ndërprerjes së pranueshme nuk është kërkesë.


• Rikuperimi. RTO dhe RPO me fjalë të qarta: sa shpejt rifillojnë operacionet pas një incidenti dhe sa punë mund të humbet. Të dy numrat i përkasin vlerësimit, jo vetëm kontratës.


• Gjurmët e auditimit. Kush ndryshoi çfarë dhe kur, për sa kohë ruhet, kush mund ta gjejë — veçanërisht kur lëvizin para, stoqe ose të dhëna personale.


• Aksesueshmëria dhe përdorshmëria. Kush e përdor sistemin, në cilat pajisje dhe gjuhë; një sistem që magazina nuk mund ta përdorë nuk është i zbatuar, sado mirë të pikëzohet.


• Integrimi dhe të dhënat. Cilat sisteme lidhen, në cilin drejtim rrjedhin të dhënat dhe kush zotëron regjistrimin kryesor për secilin entitet.

Pyetje për sigurinë dhe pajtueshmërinë

Siguria trajtohet më mirë përmes pyetjeve që kërkojnë prova sesa si një kuti po/jo. Pyetjet që ia vlen të përfshihen:

• ISO/IEC 27001 — a e ka furnizuesi dhe çfarë mbulon fushëveprimi i certifikuar? Një certifikatë që mbulon organizatën e shitjeve, por jo ekipet e dorëzimit, ju tregon diçka konkrete.


• Zhvillimi i sigurt — ku përfshihet siguria në projektim, rishikim kodi dhe testim; nëse trajtimi i varësive dhe cenueshmërive është rutinë.


• OWASP Top 10 — nëse është pjesë e rishikimit të furnizuesit për komponentët e ekspozuar në ueb; pyetje konkrete dhe e përgjigjshme.


• Kontrolli i qasjes — kush mund të hyjë në mjediset dhe të dhënat tuaja, si jepet dhe hiqet qasja dhe çfarë regjistrimesh ekzistojnë.


• Detyrimet për mbrojtjen e të dhënave — KVKK dhe GDPR aty ku zbatohen; kush është kontrolluesi, kush përpunuesi dhe çfarë thotë marrëveshja e përpunimit të të dhënave për nënpërpunuesit dhe njoftimin e shkeljeve.

Kushtet tregtare dhe SLA-të

Kërkoni çmime në një strukturë që mund ta krahasoni: çfarë përfshihet, çfarë faturohet veçmas dhe si çmohen ndryshimet. Një shifër e vetme pa fushëveprim nuk krahasohet me një shifër tjetër; faqja për modelet e kostos dhe çmimeve shpjegon strukturat e zakonshme dhe pyetjet që ngre secila.

SLA-të meritojnë të njëjtin saktësim si kërkesat. Një përqindje disponueshmërie ka kuptim vetëm me metodën e matjes, përjashtimet dhe mjetin korrigjues; një kohë përgjigjeje ka kuptim vetëm me përkufizimet e niveleve të rëndësisë dhe orarin e punës. Kërkojini secilit furnizues t'i përkufizojë termat brenda SLA-së, në vend që të pranoni një faqe me përqindje pa përkufizime.

Matrica e pikëzimit të vlerësimit

Një model që mund të kopjohet. Peshët më poshtë janë shembull — caktoni tuajat sipas prioriteteve dhe mbajeni totalin 100. Përcaktoni çfarë nënkuptojnë 1, 3 dhe 5 përpara se dikush të pikëzojë, jo pasi të nisin debatet.

Dy praktika e bëjnë këtë të funksionojë. Pikëzoni në mënyrë të pavarur përpara diskutimit, që zëri i parë i sigurt të mos përcaktojë mendimin e grupit. Dhe shënoni nga një rresht arsyetimi për secilën pikë — furnizuesit që marrin përmbledhje pikësh me arsye e pranojnë shumë më lehtë rezultatin, ndërsa ekipi juaj mund ta mbrojë gjashtë muaj më vonë.

Një praktikë e tretë lidhet me vlerësuesit. Paneli duhet të përfshijë njerëzit që do të jetojnë me rezultatin — pronarin e procesit, përgjegjësin për të dhënat dhe dikë nga siguria ose financa kur këto funksione ekzistojnë — jo vetëm prokurimin. Vlerësimet dështojnë pa u vënë re kur paneli pikëzon atë që mund të gjykojë (strukturën e propozimit, paraqitjen e ekipit të shitjeve) dhe shtyn atë që nuk mundet (nëse qasja e integrimit i përshtatet realisht sistemeve aktuale). Një person teknik me autoritetin për të thënë "kjo nuk do të funksionojë me sistemet tona" kursen më shumë se çdo zbritje.

Peshët meritojnë edhe një paralajmërim: ato janë deklaratë prioritetesh që bëhet e dukshme për furnizuesit. Nëse siguria peshon 5% dhe çmimi 30%, furnizuesit seriozë për sigurinë do ta vënë re, siç do ta vërë re edhe ekipi juaj kur të nënshkruhet kontrata. Peshëzimi i caktuar me nxitim për të plotësuar tabelën lexohet si e vërteta nga të gjithë jashtë dhomës; caktojeni një herë me vendimmarrësit të pranishëm dhe ndryshojeni vetëm me të njëjtin formalitet që përdorët për ta caktuar.

Verifikimi i referencave dhe piloti

Studimet e rasteve janë marketing; verifikimi i referencave është provë. Telefonata e dobishme është e shkurtër dhe pyet çfarë ndodhi, jo çfarë u dorëzua: a përfundoi projekti, çfarë ndryshoi në fushëveprim, kush ishte realisht në ekip, çfarë do të bënin ndryshe dhe a do ta nisnin sërish projektin me këtë furnizues. Përgjigjet specifike në kohën e shkuar janë sinjali.

Kërkoni referencë nga një projekt që i ngjan tuajit për nga madhësia dhe kompleksiteti, jo nga puna me të cilën furnizuesi krenohet më shumë — një zbatim kryesor me dyfishin e buxhetit tuaj ju mëson pak për sjelljen e ekipit në shkallën tuaj. Dhe verifikojeni vetë referencën: një kontakt që furnizuesi e informon paraprakisht është dëshmi marketingu, jo referencë; telefonata e dobishme është ajo ku klienti mëson aty për aty çfarë po pyesni.

Një pilot i shkurtër me pagesë provon atë që nuk mund ta provojë asnjë referencë: si punon ekipi me njerëzit tuaj kur kërkesat janë të paplota. Rregullat e projektimit janë të njëjtat që vlejnë për çdo pilot — punë reale, kritere pranimi me shkrim, një ndryshim në mes të pilotit dhe rregull vendimi i dakordësuar paraprakisht. Faqja për outsourcing trajton më hollësisht projektimin e pilotit.

Klauzolat e kontratës për t'u kontrolluar

• Kalimi i IP-së — të drejtat mbi kodin, dokumentacionin dhe derivatet ju kalojnë juve që në krijim, jo vetëm pas pagesës përfundimtare.
• Pronësia e të dhënave — të dhënat mbeten tuajat; të drejtat e furnizuesit kufizohen në atë që nevojitet për dorëzimin.
• Pranimi — çfarë nënkupton pranimi, kush e deklaron dhe si veprohet kur një dorëzim nuk e përmbush.
• Kontrolli i ndryshimeve — si kërkohen, çmohen dhe miratohen ndryshimet e fushëveprimit; pa këtë, çdo ndryshim kthehet në mosmarrëveshje.
• Dalja dhe kalimi — kodi burimor, qasja, dokumentacioni dhe ndihma në përfundim; si transferohen njohuritë nëse ndryshon furnizuesi.
• Ruajtja në escrow — kur vazhdimësia e biznesit varet nga komponentët që zotëron furnizuesi, çfarë ndodh nëse ai nuk mund të vazhdojë.
• Përgjegjësia — kufijtë, përjashtimet dhe pjesa e pasiguruar; lexojeni me të njëjtin kujdes si çmimin.
• Përfundimi — afatet e njoftimit, detyrimet pas përfundimit dhe procesi i kthimit ose fshirjes së të dhënave.

Pyetje të bëra shpesh

A duhet të dërgojmë fillimisht RFI apo RFP?

RFI kur tregu ose problemi nuk është i qartë — po pyesni çfarë ekziston dhe sa kushton. RFP kur kërkesat dhe metoda e vlerësimit janë përcaktuar; dërgimi më herët thjesht e zhvendos punën e kërkesave te propozimi i secilit furnizues, me fjalët dhe prioritetet e tyre.

Sa furnizues duhet të ftojmë?

Mjaftueshëm pak që të mund ta lexoni siç duhet çdo propozim dhe të telefononi çdo referencë. Cilësia e shumicës së vlerësimeve bie kur kalohet një numër i vogël; një listë e shkurtër e krijuar nga RFI-ja, telefonata paraprake dhe një projekt referues i ngjashëm zakonisht është më e dobishme se një listë e gjatë emrash të famshëm.

Si duhen caktuar peshët?

Sipas prioriteteve tuaja, përpara se të shihni ndonjë propozim dhe me marrëveshjen e njerëzve që do të jetojnë me rezultatin. Një dështim i zakonshëm është peshimi i barabartë i gjithçkaje, që do të thotë se asgjë nuk ka më shumë rëndësi se diçka tjetër; nëse çmimi ose rreziku dominon për ju, peshët duhet ta tregojnë këtë.

A duhet të pikëzohet çmimi?

Po, por si një kriter i vetëm me peshë dhe fushëveprim të përcaktuar, jo si i gjithë vlerësimi. Një çmim i pikëzuar pa fushëveprim shpërblen furnizuesin që ka supozuar më pak punë; çmojini fillimisht kërkesat tuaja, pastaj krahasoni totalet për të njëjtën punë.

Si t'i pikëzoj përgjigjet për sigurinë?

Sipas provave, jo tonit. Funksionojnë tre nivele: nuk ka qëndrim (1), përshkruhen politikat (3), verifikohet fusha e certifikatës, përshkruhet zhvillimi i sigurt dhe paraqiten prova (5). Nëse furnizuesi nuk ka certifikatë, kërkoni me shkrim kontrollet ekuivalente — një përgjigje e sinqertë "jo" me kontrolle të dokumentuara vlerësohet më mirë se një "po" e paverifikueshme.

A mund t'i ndryshojmë kërkesat pas RFP-së?

Përpara dorëzimeve, po — duke ua njoftuar ndryshimin të gjithëve. Pas dorëzimeve, vetëm përmes një sqarimi formal që u dërgohet të gjithë ofertuesve; ndryshimi i heshtur i kërkesave për një furnizues shkatërron krahasueshmërinë mbi të cilën u ndërtua i gjithë procesi. Pas kontratës, për këtë shërben kontrolli i ndryshimeve.

Burimet dhe standardet

• ISO — botuesi i ISO/IEC 27001 (menaxhimi i sigurisë së informacionit); konfirmoni botimin aktual dhe fushën e certifikatës përpara se të mbështeteni në të.
• OWASP — botuesi i listës Top 10 të rreziqeve të sigurisë së aplikacioneve ueb, të cilës i referohet kjo faqe.
• Parimet e matricës së pikëzimit ndjekin praktikat e publikuara për modelet RFP; peshët e paraqitura janë shembull për t'u përshtatur, jo rekomandim. Kjo faqe është udhëzim për prokurimin, jo këshillë ligjore, dhe nuk pretendohet asnjë certifikim ose auditim për WorldwideTradeX.

Faqe të lidhura

Zhvillimi i softuerit · Outsourcing i IT-së nga Türkiye · Modelet e kostos dhe çmimeve · Auditimi dhe konsulenca e IT-së · Kërkoni ofertë