Hindi sinusuportahan ng iyong browser ang JavaScript!

Kabanata 24 - Mga Kahilingan para sa mga Proposal at mga Kompetisyong Negosasyon

Appendix D: Mga Nilalaman ng isang De-kalidad na IT RFP

Seksyon Seksyon Paglalarawan ng nilalaman

1

Panimula

Nagbibigay ng pahayag ng problema at dapat ay sapat na detalyado para sa mga supplier upang maunawaan ang mga isyu sa negosyo na nagtutulak sa RFP at ang mga teknikal na isyu na maaaring nagpasimula ng problema.

2

Mga tagubilin sa panukala at pangangasiwa

Naglalaman ng lahat ng mga kinakailangan sa pangangasiwa at impormasyon kung saan dapat sumunod ang isang supplier upang makapagsumite ng isang katanggap-tanggap na panukala. Kasama sa seksyong ito ang mga pangunahing panuntunan para sa pagkuha, mula sa pagsusumite ng RFP hanggang sa pagbibigay ng kontrata at dapat maglaman ng mga sumusunod na uri ng impormasyon:

  • kung at kailan gaganapin ang isang pre-proposal conference
  • kaugnay na mga petsa para sa ikot ng pagkuha
  • mga kinakailangan para sa paghahanda at pagsusumite ng mga panukala (ibig sabihin, mga kinakailangan sa Code of Virginia , pati na rin ang protocol ng panukala)
  • kung paano susuriin ang mga panukala
  • RFP Single Point of Contact pangalan at impormasyon ng contact
  • kailan, saan at kanino dapat ang mga panukala
  • iba pang impormasyon na kinakailangan para maging ganap na tumutugon ang isang supplier

Kung ang mga tagubilin ay hindi kumpleto o hindi malinaw, maaaring makaligtaan ng mga supplier ang mga kritikal na pagpupulong o milestone. Maaaring tingnan ng ilang mga supplier ang kakulangan ng mga tagubilin sa kalidad bilang isang senyales ng isang mahinang pangkat ng proyekto o magkasalungat na proyekto na maaaring makaimpluwensya sa mga pangunahing tagapagtustos ng industriya na hindi magsumite ng mga panukala. Ang pagkabigo ng isang supplier na sumunod sa mga pangangailangang pang-administratibo ng RFP ay maaaring maging sanhi ng pagtanggi sa panukala. Ang seksyong ito ay dapat magpakita ng malinaw na mga panuntunan para sa pagtugon sa RFP at upang ipaalam sa mga supplier ang mga parusa sa hindi pagsunod sa kanila.

3

Format ng panukala

Nagbibigay ng mga detalye kung paano ipo-format at itali ang mga panukala at ang kinakailangang media (ibig sabihin, hardcopy, CD, atbp.). Makatutulong na magsama ng isang talahanayan upang ipakita kung ang iba't ibang mga seksyon ng panukala ay dapat isumite nang hiwalay; ibig sabihin, teknikal mula sa gastos, na-redact, atbp.). Ang seksyong ito ay hindi dapat duplicate o sumasalungat sa mga tagubilin sa panukala sa seksyon 2.

4

Kasalukuyang sitwasyon

Tumpak na ilarawan ang background ng organisasyon ng ahensya at ang kasalukuyang negosyo at teknikal na kapaligiran ng proyekto upang epektibo at tumpak na makapagmungkahi ang mga supplier ng mga solusyon para iakma o baguhin ang kapaligirang iyon upang matugunan ang mga bagong kinakailangan. Ang paglalarawan ng kasalukuyang kapaligiran ng negosyo ay dapat isama ang lahat ng mga gumagamit at mga benefactor ng kasalukuyang mga serbisyo at proseso ng negosyo na apektado. Ang paglalarawan ng kasalukuyang teknikal na kapaligiran ay dapat na isang malinaw na kahulugan kabilang ang lahat ng kasalukuyang hardware at software na ginagamit, kung ano ang maaaring gamitin o dapat gamitin upang matugunan ang mga kinakailangan ng proyekto, pati na rin ang mga kasalukuyang interface sa iba pang umiiral na mga system/platform at/o application. Maaaring ipakita ang daloy ng trabaho at mga interface ng application gamit ang mga visual.

5

Mga kinakailangan sa pag-andar at teknikal

Nagbibigay ng functional at teknikal na mga kinakailangan at sapat na impormasyon upang bigyang-daan ang mga supplier na maunawaan ang mga isyu at maghanda ng isang kumpleto at matatag na panukala. Dapat matugunan ng pangkalahatang-ideya na ito ang kasalukuyang aplikasyon sa negosyo at ang teknikal na kapaligiran (hardware, software, mga komunikasyon). Inirerekomenda na ang mga ahensya ay hindi gumamit ng "dapat" at "dapat" na mga teknikal na kinakailangan, ngunit payagan ang mga supplier na magmungkahi kung paano nila lulutasin ang problema bilang bahagi ng isang panukalang nakabatay sa solusyon. Kasama sa seksyon ng teknikal at functional na mga kinakailangan ang mga tanong kung saan dapat tumugon ang mga supplier, gaya ng:

  • kritikal na mga kadahilanan ng tagumpay
  • functional na mga pagtutukoy para sa kasalukuyang sistema
  • functional na mga pagtutukoy para sa inaasahang sistema
  • mga pagtutukoy ng pagganap
  • mga inaasahan sa antas ng serbisyo
  • mga kinakailangan sa hardware (kung sapilitan)
  • mga kinakailangan sa software
  • mga kinakailangan sa seguridad at proteksyon ng data
  • mga kinakailangan sa komunikasyon (kung sapilitan)
  • mga kinakailangan sa pagsubok
  • kung ang kanilang solusyon ay sumusunod (o maaaring sumunod) sa VITA Security, Data Standards at Enterprise Architecture at IT Accessibility/508 Compliance ITRMSGs

Ang mga kinakailangan sa pamamahala ng proyekto ay nagsasaad ng mga kondisyon para sa pamamahala at pagpapatupad ng proyekto. Ang seksyong ito ay dapat magbigay sa mga supplier ng impormasyon na kailangan nila upang bumuo ng isang plano ng proyekto, plano sa pagpapagaan ng panganib o iba pang plano sa pamamahala, gaya ng kinakailangan para sa pagiging kumplikado at kritikal na misyon ng proyekto at na sumasaklaw sa kahulugan ng mga kinakailangan, pagpapatupad, pag-install, pagsubok, pagsasanay, pagpapanatili, at iba pang mga yugto ng proyekto. Ang iminungkahing plano ng proyekto ay nagbibigay ng katiyakan na ang tagapagtustos ay may mga mapagkukunang kinakailangan upang matagumpay na maisagawa ang kontrata. Ang plano sa pamamahala ng proyekto ay karaniwang naglalaman ng mga sumusunod:

  • mga kinakailangan sa tauhan
  • mga responsibilidad sa paghahanda ng site
  • iskedyul at plano ng paghahatid at pag-install
  • mga kinakailangan sa pagsubok sa pagtanggap ng system
  • mga kinakailangan sa pagpapanatili ng system
  • mga kinakailangan sa pagsasanay ng system
  • mga kinakailangan sa dokumentasyon

Dapat tandaan ng mga ahensya na posibleng matugunan ng isang tagapagtustos ang mga teknikal na kinakailangan, ngunit hindi matugunan ang mga kinakailangan sa pamamahala bilang ebidensya sa kanilang mahihirap o hindi sapat na mga tugon sa seksyong ito. Ang seksyon ng pamamahala ay makakatulong sa pagkakaiba sa pagitan ng mga tagapagtustos na may mature o hindi pa gulang na mga kakayahan sa pamamahala.

Maaari mong hilingin sa mga supplier na tukuyin ang lahat ng mga pagpapalagay at anumang potensyal na panganib na nauugnay sa RFP at ninanais na mga layunin ng proyekto; at/o hilingin sa kanila na ilarawan nang detalyado ang isang katulad na proyekto at kung paano nila niresolba ang mga problema o isyu na naganap sa panahon ng kanilang pagganap sa kasiyahan ng kanilang customer.

6

Malinaw at natatanging Mga Panukala sa Pagganap at Mga Probisyon sa Pagpapatupad

Ang mga pangangalap ng IT at mga kontrata na nakakatugon sa kahulugan ng "mataas na panganib," gaya ng tinukoy sa § 2.2-4303.01 ng Code of Virginia, ay dapat magsama ng malinaw at natatanging mga hakbang sa pagganap at mga probisyon sa pagpapatupad, kabilang ang mga remedyo sa kaso ng hindi pagganap ng Supplier.

Gamitin ang mga tool sa ibaba upang matuto nang higit pa tungkol sa malinaw at natatanging mga hakbang sa pagganap at mga probisyon sa pagpapatupad, kabilang ang mga remedyo:

         Minimum Requirements Matrix para sa Major IT Procurements, High Risk IT Procurements, at

         1. Mga Delegadong Pagkuha 

         2. Tool sa Pagsusukat ng Pagganap

 

7

Profile ng supplier

Hinihiling sa mga supplier na ilarawan ang kanilang negosyo at mga propesyonal na kwalipikasyon at magbigay ng mga sanggunian. Dapat silang hilingin na magpakita ng detalye tungkol sa kanilang katayuan sa korporasyon at pananalapi at ang mga customer na magsisilbing mga sanggunian para sa kanilang propesyonal na pagganap at integridad. Ang mga sumusunod na halimbawa ay kung ano ang karaniwang kinakailangan sa seksyong ito:

  • Ang kasaysayan ng kumpanya, istraktura ng organisasyon, mga lokasyon at katayuan ng laki ng negosyo ng supplier (ibig sabihin, status ng sertipikasyon ng DSBSD, kung naaangkop).
  • Pangkalahatang karanasan sa background ng supplier at kakayahan para sa pagbibigay ng uri ng solusyon o pagiging produkto
  • Isang paglalarawan ng relasyon sa pagitan ng supplier at sinumang iminungkahing kasosyo/subkontraktor/manufacturer, kung mayroon man, at kung gaano katagal ang relasyong ito.
  • Katibayan na ang tagapagtustos ay may kinakailangang teknikal, pagpapatakbo at mga kasanayan sa pamamahala, kawani at mga mapagkukunang pinansyal at posibilidad na maisagawa ang
  • Isang listahan ng pareho/katulad na kasalukuyang naka-install na produkto, system o
  • Mga pangalan ng mga customer na may mga katulad na proyekto, configuration at/o application na maaaring magbigay ng mga sanggunian, kabilang ang mga pangalan ng contact at numero ng telepono.
  • Mga kwalipikasyon ng supplier, kabilang ang mga resume, profile ng kumpanya at negosyo
  • Karaniwang paraan ng supplier ng pagbibigay ng mga serbisyo kabilang ang isang paglalarawan ng plano ng trabaho, mga pamamaraan na gagamitin at isang sample na iskedyul ng mga maihahatid/timeline para sa proyekto

8

Seksyon ng SWaM

Ang mga supplier ay hinihiling na magbigay ng isang "Supplier Procurement and Subcontracting Plan" na nagsasaad ng kabuuang porsyento ng pangako na inaasahan ng Supplier na direktang gumastos kasama ng mga subcontractor sa pagsasagawa ng mga kinakailangan ng kontrata. Dagdag pa rito, hinihiling sa Mga Supplier na magbigay ng listahan ng lahat ng mga subcontractor na inaasahan nitong gamitin sa pagganap ng kontrata ng Supplier. Dapat italaga ng listahan ng mga subcontractor ang mga subcontractor na mga negosyong SWaM, gayundin ang mga hindi negosyong SWaM. Kung sakaling ang isang Supplier DOE ay hindi inaasahang gumamit ng mga subcontractor sa pagganap ng isang kontrata, ang Supplier ay hinihiling na sabihin ang katotohanang ito sa kanilang tugon.

9

Impormasyon sa pagpepresyo

Tinutukoy kung paano magbibigay ang mga supplier ng impormasyon sa pagpepresyo at nagbibigay ng detalyadong format para sundin nila sa pagbuo ng kanilang mga panukala sa presyo. Ang mga tagubilin ay dapat sapat na malinaw upang matiyak na ang mga panukala sa presyo ay maihahambing sa pantay na batayan. Upang mapadali ang paghahambing na ito, isaalang-alang ang pagbibigay ng sample na spreadsheet na naghahati sa iminungkahing system sa mga bahagi tulad ng sumusunod:

  • software ng system
  • software sa pagbuo ng application
  • pag-install
  • pagpapanatili
  • pagsasanay
  • dokumentasyon
  • pamamahala ng proyekto
  • pagsasama ng natatanging hardware o software
  • mga bayarin sa lisensya (patuloy)

Magsama ng iskedyul/scenario sa pagpepresyo bilang isang halimbawa kung paano dapat isumite ang mga presyo ng panukala. Kung ang lump sum na pagpepresyo ay hindi kapaki-pakinabang, gumamit ng senaryo ng pagpepresyo upang makakuha ng mga presyo para sa hindi kilalang dami o oras. Humingi ng breakout ng umuulit kumpara sa hindi umuulit na mga gastos. Ang iskedyul ng pagpepresyo ay dapat na nakatali sa mga maihahatid at dapat na tumutugma sa paraan ng pagbabayad na itinakda sa solicitation.

Kapag tumitingin sa mga iskedyul ng pagpepresyo, bigyang-pansin ang pagpepresyo na nagsasangkot ng isang beses na gastos kumpara sa mga umuulit na gastos. Ang paunang presyo ng isang software package ay isang beses na gastos; Ang taunang bayad sa pagpapanatili at paglilisensya ng software ay mga umuulit na gastos na dapat matukoy upang mabuo ang kabuuang halaga ng life-cycle ng proyekto. Ang pagpepresyo ay hindi karaniwang ang tanging determinant para sa award, ngunit dapat gamitin upang maputol ang ugnayan sa pagitan ng dalawang supplier na may parehong mahusay na teknikal at mga panukala sa pamamahala.

Para sa mga kumplikadong proyekto maaari mo ring hilingin sa mga supplier na magsumite ng isang milestone na iskedyul ng pagpepresyo kung saan maaaring ilapat ang mga porsyento ng holdback upang mabayaran pagkatapos ng huling pagtanggap sa huling invoice. Ito ay nag-uudyok sa mga supplier at nagdaragdag ng proteksyon para sa ahensya kung ang huling pagtanggap ay naantala o may problema. Nagbibigay din ito ng mas madaling pagkahiwalay ng kontrata sa anumang milestone kung hindi gumaganap ang supplier.

10

Karaniwang kasunduan ng ahensya (ibig sabihin, template ng kontrata)

Naglalaman ng iminungkahing template ng kontrata na may mga kasunduan sa hindi pagsisiwalat, pagiging kompidensiyal, proteksyon ng data at mga kinakailangan sa seguridad, mga warranty, mga kinakailangan sa kasunduan sa paglilisensya at iba pang mga tuntunin at kundisyon na ayon sa batas, legal at partikular sa IT, o anumang mga tuntunin ng federal flow-down na maaaring kailanganin. Dapat hilingin sa mga supplier na i-redline ang iminungkahing template ng kontrata upang i-highlight ang lahat ng mga pagbubukod na hindi nila sinasang-ayunan. Hindi dapat i-redline ng mga supplier ang sugnay ng pananagutan sa oras na ito.

Maaari silang maglabas ng mga isyu o komento sa unang pagkakataon sa panahon ng negosasyon mamaya. Tukuyin ang mga isyu sa showstopper sa panahon ng pagsusuri ng panukala dahil posibleng pumili ng supplier na hindi tatanggap sa kontrata ng ahensya.

11

Seksyon ng Supplier (opsyonal)

Nagbibigay-daan sa mga supplier na isama ang impormasyon na sa tingin nila ay may kaugnayan kahit na hindi kinakailangan o hiniling sa RFP. Maaari din nilang talakayin ang mga potensyal na isyu na may kaugnayan sa RFP at sa kanilang panukala. Halimbawa, maaaring may mga karagdagang feature ng produkto ang isang supplier upang ipakita na nasa labas ng saklaw ng RFP, magpakita ng natatanging solusyon na hindi inaasahan ng mamimili, o maaaring magbigay ng solusyon sa isang problemang nakikita sa RFP na hindi isinasaalang-alang ng ibang mga supplier. Kahit na ang partikular na supplier na ito DOE hindi nanalo, ang paliwanag ng problema at ang potensyal na solusyon ay maaari pa ring isaalang-alang.

12

Mga Appendice

Naglalaman ng napakalaki ngunit may-katuturang impormasyon tulad ng mga diagram ng network, pag-aaral ng mga kinakailangan sa teknikal, mga balangkas ng plano ng proyekto at iba pang detalyadong impormasyon. Kasama sa mga halimbawa ang sumusunod:

  • Mga spreadsheet na may istatistika
  • Mga drawing ng network ng komunikasyon at
  • Listahan ng kasalukuyang
  • Mga pamantayang ginamit sa loob ng
  • Pansamantalang plano ng proyekto na may
  • Template ng kontrata
  • Pormularyo ng plano sa subcontracting ng maliit na negosyo
  • Form ng Komisyon ng State Corporation na kinumpleto ng supplier bilang nakarehistro upang makipagtransaksyon ng negosyo sa

Ang impormasyon ay makukuha sa tagapagtustos ngunit DOE ay hindi nakakaabala mula sa salaysay na bahagi ng RFP. Tandaan: Sabihin sa mga supplier kung dapat nilang gamitin ang impormasyong ito kapag binubuo ang kanilang mga panukala.


Hanapin sa manwal sa pamamagitan ng mga susing salita o mga karaniwang termino.