資訊完整度與決策有效性

資訊完整度太低，一直是過去在 P 公司不斷發生的問題。由於資訊不足，導致大部分的決策都像是在瞎子摸象的情況下作出來的。剛好有某人說問題的發生原因可能是 A，大家就朝 A 方向解決，過了一陣子發現沒什麼用，就再猜一個原因 B，所有人就再朝 B 方向努力。通常最後的結果是，所有能猜的原因都猜得差不多了，但問題還是沒解決，大家也師老兵疲，連再繼續猜的力氣都沒了。這個現象恐怖的地方在於：解決問題通常不是一個人解決，而是一組人解決，要凝聚一組人的力量本來就不容易，但要破壞一組人的信心卻是簡單的不得了，只要當中一有人信心動搖，就會像病毒擴散一樣，一發不可收拾。所以，不作決策則已，一但作了決策，就要一舉中的。春秋時代曹劌論戰所說，一鼓作氣，再而衰，三而竭，就是這個道理。
在前幾篇文章中 (這一篇和這一篇) 有提到 C 公司現在遇到的最大問題或是最需要解決的問題是技術部門的結案速度大幅下降，我也已把解決這個問題當成是目前最重要的工作項目。但問題是，該如何解決？或者問，造成這個問題的原因是什麼？我們總得先知道問題的本質，才好找解決方法。經過三天的訪談，聽到的原因很多，例如，客戶會要求工程變更、客戶會對工程師作不合理的要求、硬體採購會延遲交貨、外包商的進度延遲、以及工程師的技術能力不足等等，但如果仔細問，那到底哪一種原因發生的頻率最頻繁？或是哪一種影響對交期的衝擊最大？麻煩了，沒人有把握。因為小公司的資源有限，不可能同時對每個可能原因都投入資源，因此，回答上述兩個問題，就變成一個很重要的工作。
為了回答這兩個問題，例行性的資訊蒐集就變得是必要的工作，唯有在資訊被完整蒐集的情況之下，我們才有可能進行統計與分析，找出問題的本質，並加以解決之。那要如何讓技術專案部門的夥伴們能夠做到例行性的資訊蒐集工作呢？答案就是專案日報及定期的專案日報檢討會議。專案負責人填寫日報，再由一專案管理者統一將各式問題通報給各相關負責負責解決的夥伴們知道，另外，專案管理者亦須負責整理並分析數據，找出導致專案結案速度不夠快的原因，並協助技術夥伴們解決。然後，在專案日報檢討會議上，專案管理的負責人可提出各式統計數據，讓專案負責人了解問題所在，並集思廣益共同找出解決方案。
由於最初的發想是為了要找出結案速度不夠快的原因，因此這份日報的設計最好就只要能夠讓夥伴們提出每天遇到的問題即可，其他的資訊蒐集就不用急著作，而且在設計上必須讓夥伴們容易填寫，不會增加太多的工作負擔，等到大家都習慣了填寫日報，再考慮置入其他資訊蒐集項目。
當然，請專案工程師寫日報不單單只為了蒐集資訊、找出問題，還會有一些其他衍伸出來的好處。例如，所有問題的解決者分派都可以在最短的時間內處理完，這個時間就是一天。另外，某些問題或許會造成交期上的延誤，公司有責任在最短時間內告知客戶，這個時間也是一天。另外，如果某些問題不是專案執行者本身可以掌控的，而且有可能會讓後續的專案工作無法執行，專案管理者也可以立即決定是不是要安排其他的專案工作來填補這段空下來的時間。
執行了專案日報是不是就可以保證結案速度可以提升，答案是不確定。但有一點可以確定的是，如果這件事不作，要讓結案速度提升，要嘛很難，要嘛就是要投入大規模資源才有可能做到。

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

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

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