2014年5月20日 星期二

SQL指令-By towns

2014年5月6日 星期二

RFP

如何提出RFP找到適合的系統廠商(一)

想要找到好的系統委外廠商,製作RFP是一項很重要的工作。何謂RFP(Request For Proposal),簡單來講就是需求的一方根據自己的需求要求提供服務的一方提案的「提案要求書」。讀者當中應該有人有撰寫或者看過RFP的經驗,應該了解到提出明確的RFP,找到好的而且適當的廠商,不是一件很容易的事。有些企業已經有固定格式的RFP,尤其是建築、工程業已相當成熟的標準格式和程序。不過在IT業界,應該尚未有標準的RFP。
提出RFP之後,最後會針對廠商提出的提案內容進行評選。不過常常會發生買方寫了一大堆需求,賣方也針對需求提案了一大堆,卻很難評選的情形。難以評選的原因,除了RFP的內容有問題之外,RFP的作業流程也有問題。為了避免此種情形發生,基本上必須明確傳達①想要做甚麼②有多少預算③時程有多久,以及④廠商需要提出哪些資料。必要時撥些經費給提案的廠商,讓廠商能夠針對RFP的內容製作提案書,不是拿現有的資料充數。

「系統委外」步驟之一

製作RFP為「系統委外」的步驟之一,「系統委外」的作業流程主要分①前置作業,②製作RFP,③提案書的評選和決定,④訂立契約等4個步驟。
①前置作業
較複雜的系統可以參考本網站的IT策略擬定的流程。通常掌握經營、業務、系統相關課題,使用者的需求,同業先進的事例以及技術動向等。
②製作RFP
根據前置作業所取得的相關資訊,明確的將①想要做甚麼、②有多少預算、③時程有多久,以及④廠商需要提出哪些資料等資訊放進RFP內。之後會針對此部分做較詳細的解說。
③提案書的評選
針對廠商的提案書的內容進行評選。除了評斷是否符合RFP的需求外,廠商的對應態度、體制、提案書的品質、技術能力、風險管理等也應列入評選的項目。還有考量成本時,系統導入後的維護以及系統營運成本等也必須一併檢討。
④訂立契約
將採用廠商提案的內容,反映到實際的契約上。通常在此階段會出現彼此認知的差異發生,必須注意,否則有可能功虧一匱。

接下來的章節,針對②製作RFP、③提案書的評選等加以詳細說明。

PM RFP RFI RFQ As-is, To-be 與 Gap

寫的時侯大概的原則是「由大到小,由大方向到小細項」,以「建置人力銀行網站專案」為例,要定義範疇的方向可以參考下列簡例:
目標:公司拓展業務方向,提高獲利
範圍:在2008年第四季導入人力銀行網站
工作事項:
1. 決定預算及時程
2. 擬定專案計劃
3. 專案執行
4. 成果驗收
5. 上線運作
交付項目:
1. 專案計劃書
2. 專案會議記錄
3. 驗收報告

以下是與範疇有關的一些名詞以及原則,這裡做個說明

RFP:Request for Proposal,較大型標案中,甲方會提供RFP給所有有意願承包的乙方當參考資料,RFP的內容主要是針對甲方所欲外包的工作,做更詳細的說明,乙方可以更清楚地評估自身承接標案的能力,並據以評估時程、成本之後,做出報價。
RFI:Request for Information,有些標案,甲方只知道要做什麼,但是細節不是很清楚,於是就會發出Rrequst for Information,向其他有相關專業知識的廠商詢問資料,將資料彙整之後,再寫成RFP。
RFQ:Request for Quotation,在各項先期溝通完成之後,甲方詢問乙方報價的動作

As-is, To-be 與 Gap
這是定義範疇時一種常用的方法,因為很簡單明瞭,As-is指的就是「現況」,To-be指的就是「未來」(即專案完成後的結果),而Gap就是其中的差異。
以頂樓加蓋一間小工作室為例,As-is就是目前三層樓透天的房子,To-be就是三層樓的房子,頂樓有一間小工作室,Gap就是要蓋的那間小工作室。
IT界的專案中的As-is和To-be或許沒有這麼單純而簡單的定義,但是基本上這個方法可以讓許多人在短時間內了解到這個專案要做的是什麼,更甚至可以評估「值不值得這個錢」。

需要(need)與想要(want)
我本身的經驗多半是乙方,在專案前期過程,與甲方在談需求與定義範疇時,常常會用到這個方法,就是「需要」和「想要」,有時客戶講得天花亂墜、口沬橫飛,你就要適時的將他拉回現實世界,或者讓他做完夢之後,清楚地(一定要明確地)跟他溝通,他想要的是什麼,他需要的是什麼,以及你在這個專案打算承做的是什麼。每個人都想要一輛法拉利,但每個人只是需要一輛代步工具的自小客而已。

規模大小
專案規模大小是個吊詭的東西,要靠經驗去拿捏。規模太小賺不了什麼錢,規模太大又怕結不了案;規模太小客戶可能會看不上眼,規模太大客戶又可能不願意出那個錢。
對於IT界的專案,我的建議是,每個專案的時間最好不要超過三個月,以免夜長夢多。或許你會覺得:笑死人了,三個月的案子太小了吧。沒錯,我的經驗是,如果有大案子,就把他切成好幾個三個月的小案子去進行,最好連合約都能分開簽,例如:發射太空梭之第一階段(基地建設)、發射太空梭之第二階段(人員訓練)、發射太空梭之第三階段(太空梭建造)…等等。

模糊與明確
這個與專案規模一樣,同樣是變化萬千的東西,也要靠實戰去累積經驗。以乙方的角度出發,Sales與客戶談案子的時侯,範疇定得越模糊,越容易接到案子;而乙方後援部隊(技術團隊)卻希望範疇越明確越好,因為越明確越容易結案。

技術人最愛說的一句不該說的話
「只要定義清楚,我就做得出來」,我小時侯自恃甚高,也很愛講這句話,不知道天高地厚,人情世故,如今看遍浪花淘盡英雄淚。在此奉勸各位,這句話少說為妙。


有關於您提出的這些問題呢, 我們會帶回去會同相關部門與廠商做研究, 設法做出詳細及徹底的測試, 並討論各種後續各種可能衍生的問題及解決方案, 相信能提出讓您滿意的答覆.

謝謝您提出這個很重要的議題,由於您的意見我公司非常重視,公司要求我先做好詳細記錄,回去後再召集相關單位開會討論,務必找出讓您能滿意的做法,後續進行過程中,只要有 status update,會立刻跟您 update status,謝謝。