將風險量化 回歸財務流程管控

出處：商業週刊1059期
作者：曠文琪
節錄：
機會與風險，像是銅板的一體兩面，不冒險，就沒機會，如果要冒險，又要如何將傷害降至最低？
IBM大中華區財務管理諮詢服務負責人周繼昌提出的解決方案是IBM今天能建立起管理164個國家員工風險體制的基礎建設－一套全球化的財務流程系統。為何從財務切入？『財務就是所有風險呈現後的結果。』控管好財務，即便子公司做出錯誤決策，也不至於對母公司造成致命打擊。有趣的是，IBM的第一步，卻是很多人忽略的基本功－建立共同的語言。
風險控管第一步：統一業務員對數據的認定。(統一語言)
『風險本來就是很不確定的因素，所以我們要盡可能把不確定的因素消除。』周繼昌說。不同的業務對成本的定義可能不同，這其實可以解釋，為何很多業務人員認為自己接到賺錢訂單，但不自知，這已讓企業面臨虧損的風險。
風險控管第二步：建立決策流程，讓權責分明。(統一流程)
對數據的認定有共識後，才可能讓後續財務流程與重大決策的決策步驟標準化，這都是循序漸進的。每個決策必須經過幾個步驟？每個步驟該誰負責？被檢驗的標準是什麼？都必須一目了然。唯有如此，之後搭配的專案生命週期管理(Project Life Cycle) 制度與風險檔案 (Risk Profile) 才可能落實。
在專案生命週期管理上，業務不只負責接訂單，還是專案的負責人。他的績效評估模式，將會包含專案的獲利率、客戶滿意度、客戶重複購買率與專案達成度等。他也需要協調每個環節。這就很自然的讓業務對風險擁有Ownership，會更重視整體的達成度。
風險控管第三步：依風險等級讓不同層級決策。
業務承接訂單的同時，要釐清所有資訊，並在系統內填入包含訂單規模、利潤、內部可行性與客戶信用背景等訊息，製作出風險檔案，風險分數從0到10，分數越高，越需要得到更高層級的主管同意。
IBM一開始先從系統建置下手，但並不代表執行長可以期待一套完美的系統，能讓企業處在0風險的環境中。系統不能自己跑出商業決策，它最大的意義在讓企業決策是否冒險時，把風險代價給量化。重點是，當所有訊息都不明確時，決策反而更慢。若企業希望可以快速打開知名度，而願意接下不賺錢的訂單，那麼系統只能算出成本為何，但主管仍需自行判斷，那樣值不值得。

瓦肯錢觀點：
新公司 (明天on board，往後所有文章中一律稱C公司，前公司則稱P公司。) 過去一年在接系統整合專案部分初步看起來是賠錢生意，因為並沒有對專案進行成本分析，所以實際虧損的金額並不清楚。
因為沒有在接單前作風險評估及成本計算，在專案執行過程中也沒有確實地monitor執行成本和費用，再加上大部分工程師結案能力不足 (其實也是風險的一部分)，更甚者，結案後也沒有確實檢討成本及利潤，才會導致一整年末才驚覺整體虧損的狀況。
技術能力不足，不一定容易解決，但至少單純，而且是獨立的問題，可以切割開來。至於其他方面，需要先確定會計人員是否有準確計算成本的能力及標準，如果有最好，稍加檢視修改即可。如果沒有，那就要重新仿照損益表的模式，建立專案損益預估表，這個專案損益預估表必須非常仔細，不單單是營收、成本、毛利、費用及稅前純益等，還必須把成本細項及費用細項仔細列出。
接下來，讓採購成本及人力成本資訊通透。業務頂多只要靠資深技術人員協助評估軟硬體零組件及所需工時，就可以完成專案損益預估表。另外還要建立專案可行性及風險評估表，風險項目以表列方式呈現讓業務勾選，業務也是靠資深技術人員協助評估可行性及技術風險，就可以完成專案可行性及風險評估表，重點是，所有風險都必須換算成工時或其他形式的成本。
之後是執行時的monitor。工程師必須每天回報執行狀況，包含時間、進度、發生問題與解決方式，並與專案損益預估表比對，看與預期目標的差距有多少，另外也要與專案可行性及風險評估表比對，看是否有未預估到的風險發生。專案損益預估表與專案可行性及風險評估表在初期一定與執行狀況有落差，最可能發生的情形有三種，第一，預估工時不準，第二，風險與成本之間的換算關係有不準，第三，執行時發生未估算到的風險。這些落差都必須靠執行時不斷地monitor及feedback來調整，當然，這些都是需要時間及經驗的工作，不可能一蹴而及。
最重要的是，上述流程與表單必須以SOP的形式建立，並不斷地討論溝通，藉以達成整個公司的共識後再開始逐步執行。