Ocean PMP BLOG

同樣地賣方寫的建議書買方不見得完全瞭解，單憑書面資料也未必能證明賣方的能力，所以買方在收到建議書後就會請各賣方前來說明(Presentation)。召開說明會後，買方即可運用先前制定的評選標準評定賣方建議書，最後選擇一個或多個合格的賣方(Short list)開始進行磋商(Negotiation)，磋商的範圍包括建議書中技術(Specification)、商業(Price)、合約條件(Contract Term&Condition) 及專案管理部分。最後專案團隊及採購部門會將磋商的結論呈報管理階層召開經營會議(Executive Committee)做最後決定，將該合約給那一家賣方(Contract Award)，最後完成簽約。

通常在英文合約條約裡是用 Clause #：Security Deposits (擔保保證金)來表示，賣方得標後一定期間內需質押總價款一定比例的金額給甲方，做為履行合約(交付產品或服務)的保證金，這對買方是一種保障，也是賣方對甲方的承諾(Commitment)，賣方可以以定存單設定質押、銀行開立之保證金保證書(買方需注意有效期限，到期專案如尚未結束，需要求賣方重新開立展延)或其他型式來作為履約保證金，合約執行期完成如無爭議甲方需解除設定抵押退還乙方，屆時乙方即可以動用開筆資金。

當買方寄出RFP給賣方後接下來該做什麼，等賣方的建議書(Proposal)嗎？這樣來看你(買方)認為你寫的採購文件(RFP)裡面的需求、專案範疇、合約條款、特訂條款、投標需知、答標方式、及各種附件，這些收到RFP的潛在賣方都充分瞭解嗎？如果答案是否定的，就會影響賣方的投標意願、解決方案及價格，為了要縮小買賣雙方對於專案範疇內容的認知差距，所以買方都會發起一個會議邀請賣方到場針對RFP不清楚部分發問，這個會議叫做投標商會議(Bidder conference)，即是讓潛在賣方準備建議書前的會議，會議進行時買方應公平的讓賣方逐一提問及回覆(不一定當場回覆)，最後回覆澄清的內容需作為採購文件(RFP)的修改文件

在完成了外購的範疇(Statement of work), 我們也選擇了最適合的合約類型後, 接下來就是準備要讓潛在的供應商(系統整合商)提出解決方案(Proposal)來滿足你專案外購的需求, 因為我們要Proposal所以我們要提出一個RFP(Request For Proposal)告訴潛在的供應商(系統整合商)提出解決方案(Proposal), 所以在RFP裡除了外購的範疇(Statement of work)外我們還要加上各種合約條文來限制甲乙雙方的權力及義務, 例如交期, 付款條件, 罰則, 合約爭議處理, 合約中止, 違約, 不可抗力...這些合約條文一般在大公司的法律部門都有標準版本的中英文合約(Standard provisions), 我們稱這些合約條文為 clause, 總稱為 Term&Condition, 除了這標準版本的條文外每個專案都有其差異性, 這些差異需要供應商(系統整合商)或甲方(buyer)特別遵守的稱為特訂條款(Special provisions), 例如系統或產品規格, 專案特別需求(標準條款沒有), 這些條文會影響供應商的投標意願及報價, 專案經理也要確認透過合約條文將風險轉移給供應商, 所以專案經理要參考自己的主約條文然後back to back 將風險(例如交期,罰則,品質...)透過合約條文轉移出去, 所以專案經理必須要參與採購流程

採購流程大部人都是部分參與難得窺得全貌，一來說需求人員通常會先準備三家報價，然後上個採購單(Purchase Order), 複雜的系統就加些系統規格要求，然後就看採購了，有進一步消息或活動採購會通知，大概時間快來不及時才會摧一下進度，事實上PMBOK講得採購與一般實際運作基本上幾乎一致，下面就讓我們來順一便，採購是流程導向的(process driven)，每個流程間是有清楚邏輯關係，少了一步驟就不完整。

許多老闆都知道風險管理很重要, 可是說到要如何做, 大家確都是嘴巴說說沒人知道該怎麼做, 另外一種就是把問題point out出來然後沒有任何solution, 問題我點出來了發生不要說我沒提醒, 其實我們要的不祇是發現潛在問題, 怎麼解決及是否有效才更重要, 下面列出方法步驟照著做即可

Scope verification 會發生在專案每個 Phase 結束時, 要將 deliverable 交到客戶手上, 並得到客戶的簽收(acceptance, sign-off)所以是與客戶相關, 當然交給客戶時也會確認交付的數量及品質是否經過QC(Quality Control) 檢驗完成可出廠.