向茶米致敬：產品模組化，提高公司獲利的關鍵點

最近不知道怎麼搞的，突然覺得聽HipHop可以帶給自己一種很High的感覺，尤其是在身體疲勞的狀況下，聽到MC HotDog、大支、茶米在用很快很有節奏感的方式唱歌，就會讓大腦亢奮起來，彷彿又可以把最後一滴力氣給榨出來。

英明的老闆，這篇不是在向你訴苦我工作太認真。親愛的老婆，這篇也不是在抱怨帶小璞太辛苦 (小璞大部分時間都是老婆在照顧。) 我想要說的是，請各位去YouTube聽聽這些人Battle，像這裡、這裡、和這裡。啥? 蝦咪是Battle? battle就是兩個HipHop歌手互相用念歌的方式，虧來虧去，你虧一段完換我，我虧完再換你。你會問，我虧你的時候會虧甚麼? 嘿嘿，你永遠不知道我會虧你甚麼，直到你聽我虧完，所以等你要虧我時，你必須很快速地在大腦中串出一堆有意義的歌詞，再用很快的速度唱出來反駁我，如果做不到，就會變成2100全民開講，藍綠沒有交集，然後你就紅不了。

講到這邊，歌也聽了，大家會問，對耶對耶，你講得東西都很好玩，歌裡面的一些髒話也讓我聽到很爽，茶米也的確很厲害很厲害。可是，這跟「產品模組化」有甚麼關係? Ok，關係就在於，我不相信茶米真的有這麼厲害，或者說，我不相信這個世界上有這麼厲害的人。拜託，騙笑耶，連急智歌王張帝我都覺得是唬爛的，還怎麼可能要我相信茶米沒有作弊帶小抄或是套招? 曹操的兒子寫一首詩都要走七步才想得出來 (而且還是作弊先寫好，七步是裝的)，你要我相信這些人比曹植聰明? 可是可是可是，如果這一切都是真的，而且今天我是茶米，你是大支，預計一年後要被丟到上海和大陸同胞 battle，我們要怎麼辦?

難道我們會背個100條完整的5分鐘的Rap去跟人家拼，然後賭自己會運氣好到遇到對手的歌詞和我們背的有關? 而且要整段有關喔! 我想應該沒人會這樣幹。但，反正我們是要背500分鐘嘛，如果我把它拆成1000條30秒的piece呢? 中獎的機會就大多了吧? 每個歌手能想的事情也不會差到多遠，你想得到的我也想得到，1000條理面中8條我就發了，剩下的一分鐘我再真的臨場硬湊吧，真湊不出來就用一堆yoyo、come on man、do that shit硬塞也沒人說不行阿。

茶米因為太厲害了，我猜他大概背了有一萬條吧，所以可能我們一輩子都練不到那種功力，可是不知道大家有沒有發現? 大支看起來似乎就沒那麼聰明了吧? 怎麼聽起來好像就真的有一些重複的地方，那Mc HotDog呢? 耶? 轉來轉去好像就那麼幾招嘛。說到這裡，大家有沒有一種自己也可以背個10句8句去battle一下的感覺?

這就是我要講的重點，如果把聽眾當成客戶，把公司當成歌手，當我們在跟別的公司競爭客戶時，如果只是要賭運氣，贏到少數幾個非常focus的客戶，那當然可以開發一套很大很完整的產品，然後跟客戶說，黑，就用這個吧，保證不用客製化。可是現實上這種客戶應該是不多，當我們要像HipHop歌手一樣在短時間內兜出一個產品，告訴一個客戶說，黑，這個是你要的，然後再變一下，再兜出另外一版，再告訴另外一個客戶說，黑，這也是你要的，要怎麼做? 我想這些HipHop歌手已經說明了很清楚。沒別的技巧，就是，拆解，實現再組合。

整件事的關鍵在於：公司為了降低成本，所以一定會想要開發產品，降低客製化的程度。但開發好幾套大產品，期待各個大產品打中不同客戶需求點的風險太大。反向思考，如果我們能夠把每個客製化的幅度變成30秒的歌詞，而且可以一用再用，要用時就像兜積木一樣簡單，那我們就可以像茶米一樣，把我們的對手，打死。

建立以業務團隊為首的專案型組織結構

C公司是一個量測系統整合公司，大部分的營收是來自專案，你要說它沒有產品嗎? 它其實是有產品的，只是因為每個客戶的需求都多多少少有點差異，所以導致這樣一個量測系統整合公司的營運模式很像一般的軟體公司，它們會有獨特專精的產品，比如說ERP、CRM或MES等等，但都不太可能直接賣到客戶端而不需要一些客製化的動作。因此，變得每一張訂單都幾乎會牽涉到一個動作，就是客製化，尤其是越大越專業的客戶，對自己的需求了解越深入，客製化的程度也許就越高。

客製化是一個複雜的動作，從需求確認、規格定義到執行，每個過程都難免會有變數。相信我，世事難預料，再厲害的客戶，也會遇到需要變更需求的狀況，更不用說那些搞不清楚自己需求，想要且戰且走的客戶了。一旦客製化程度變高，傳統的功能性組織就會不敷需求，彈性大、機動性強的專案型組織才有辦法面對各式各樣，因客製化產生的大量變化。舉個最簡單的例子，如果是在傳統的功能性組織裡，某個專案發生了技術問題，這個問題會在技術部門裡反覆討論，再由技術部門主管和業務部門主管開會討論該怎麼辦，再由業務部門主管交代業務處理，或是由技術部門主管交代工程師處理。另外，某個專案的物料也出問題了，物流主管可能也要和技術部門主管和業務部門主管開會討論該怎麼辦，各部門也要再回頭開會交代處理方式。如果今天一個公司裡只有五個案子，那各個部門主管都還可以應付，但如果今天公司裡有五十個案子呢? 會就開不完了。

所以，比較有效率的模式應該是針對每一個專案，成立專案組織，所有突發的、非結構性的問題都是在這個專案組織裡機動解決。功能性組織則是負責解決結構性的問題。比如說，某個案子的物料進貨特別慢，在專案組織內解決，但如果每個案子都慢，則回到物流部門解決。再者，某個案子的電路技術遇到瓶頸，在專案組織內解決，但大部分案子都遇到電路技術的問題，則由技術部門考慮如何提升技術部門的整體電路技術。

另外一個待釐清的問題是，站在公司的角度，這個專案型組織要由誰當Leader? 商業週刊1059期裡的文章 (將風險量化　回歸財務流程管控) 有明瞭且完整的答案。簡單地回答，這個Leader就是業務。在專案生命週期管理上，業務不只負責接訂單，還是專案的負責人。他的績效評估模式，將會包含專案的獲利率、客戶滿意度、客戶重複購買率與專案達成度等。他也需要協調每個環節。這就很自然的讓業務對風險擁有Ownership，會更重視整體的達成度。這件事的前提是，要讓業務有driving force承擔這樣的責任，也就是將績效與個人的driving force連結，例如把每個案子最後的獲利讓業務抽成，或是把績效值與升遷畫上直接的關係，都會是不錯的方式。

組織決定了之後，就剩下流程的問題，在這樣的一個組織內，流程就會像：由業務與客戶洽談需求、評估可行性及風險、評估成本及交期，評估過程中由物流部門及技術部門提供支援，最後報價。訂單下來之後，業務將需求會轉化成規格文件，交付物流部門及技術部門，由物流部門採購原物料，技術部門負責軟體開發及系統整合，所有非結構性的問題就會在這三個人當中協同解決，當然，過程當中這三個人還是可以向其他人提出支援的要求，如果必須的話。開發時如果遇到客戶要求工程變更，則統一由該負責業務出面與客戶接洽。技術部門將系統完成後，便可以將這個系統交由業務確認，是否滿足當初他與客戶達成的協議，如果業務確認完成，技術人員即可對業務進行教育訓練，之後就由業務向客戶進行驗收工作、教育訓練工作及後續簡單的維護。

最後我想提的是，雖然一個系統整合公司絕對沒辦法避免客製化這個動作，除非它堅持不做這樣的生意 (我懷疑這樣的公司是否能存活)。但如果能夠用越簡單的客製化動作來滿足大部分客戶的需求，那這間公司與其他系統整合公司的差距一定會非常的大，至於要怎麼做到這件事，我認為產品模組化會是一個關鍵，我會在下一期的文章做一個陳述，敬請期待。

ps. 在看下一期文章之前，請各位先去 YouTube 上看看茶米在上海的 Battle，像是這裡、這裡和這裡。

YoYo, Baby, Check it out, man.

資訊完整度與決策有效性

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

Test of feedburner subscription funtion

Test of feedburner subscription funtion

Problem Briefing of COMPANY C

今天是到Ｃ公司 on board 的第三天，前兩天已與組織裡的兩位 leader 各做了一次長時間的訪談，以了解之前提過的那些職務交接時該問的八大問題。我先將目前收集到的資訊整理如下，也請看到這篇文章的人可以給我一些想法，看有沒有什麼資訊是遺漏的，如果能提供我之後改善的建議，那就更好了，在下先謝過各位。

(Q:Question, A:Answer, S:Subsequence)
Ｑ．未來的合作夥伴們是誰 (這裡的夥伴包含老闆、同仁以及部屬)？誰是 key man？他們在組織內待了多久？人格特質是什麼？好惡是什麼？優缺點在哪裡？有沒有什麼需要幫忙的地方？
Ａ．所有的人 (包含老闆，工程師和管理師) 都很 nice，老闆和兩位 leader 都相當 open mind，負責會計的夥伴也是，但是不是大家都 open mind 還需要再觀察。有一些工程師比較內向，不太知道如何把自己的想法及遇到的困難表現出來，有一些工程師比較不會積極地去解決問題，工程師的技術落差相當大，部分工程師還沒有獨立結案的能力，還需要時間培養。
S．建立 driving force 讓工程師主動積極學習。
S．建立師徒制及培訓方法培養工程師獨立結案的能力，光拿到 NI 的 CLAD 的不夠的。
S．建立一套方法讓工程師認為提出問題及想法是一個 routine job ，而不是特例。
S．持續觀察每個人的個性及特點。

Ｑ．組織掌控哪些營運的流程？這些流程內包含哪些功能？以及這些功能分別由哪些夥伴負責？這些流程與其他組織之間的關聯性為何？有沒有什麼改善的目標及計畫？
Ａ．業務流程、總機接聽流程、訂單流程、　　
　　內部提案改善流程、產品開發流程、專案流程、外包流程、一般客服案件處理流程　　
　　請採購流程、會計核銷流程、庫存管理流程　　
　　銷貨流程　　
　　部分流程沒有文件化，沒有表單控制，或者是有，但卻沒有確實執行。部分流程內經辦人換手太多次，有些紊亂。流程與組織分工不明確。
S．重新 review 現有行政流程。
S．簡化行政流程，盡量讓行政流程內的經辦人數越少越好，並把所有行政流程文件化，表單化。理念溝通後，強調紀律執行。表單設計前先確認要 monitor 的高階項目 (比如說專案成本及執行效率等)，再確認表單內的低階項目能不能統計出那些高階項目。

Ｑ．組織內目前最急迫需要解決的問題是什麼？目前是哪些夥伴在處理？處理的計畫是什麼？deadline 是什麼時候？以及若來不及在 deadline 之前解決的衝擊是什麼？
Ａ．工程部分：delay 及 idle 的案子太多，不會有罰款，但客戶抱怨不可忽視。工程師之間無法互相 support。行政部分：流程紊亂，規定訂很多，執行上不確實。
S．討論是否要增補工程人力，前提是必須增補具有獨立結案能力的即戰力。
S．建立師徒制及培訓方法培養現有工程師獨立結案的能力，但緩不濟急。
S．討論重要需要先結的專案，重新分配處理人員，看整體速度能不能快一點。
S．重新 review 現有行政流程。
S．簡化行政流程，盡量讓行政流程內的經辦人數越少越好，並把所有行政流程文件化，表單化。理念溝通後，強調紀律執行。表單設計前先確認要 monitor 的高階項目 (比如說專案成本及執行效率等)，再確認表單內的低階項目能不能統計出那些高階項目。

Ｑ．組織的既定短中長期目標是什麼？這些目標是如何訂定的？以及有何計畫或專案去完成這些目標？計畫或專案的內容是什麼？最後，這些計畫或專案執行的進度到哪裡？
Ａ．無。
S．定義一年短期目標：增加工程部門專案 capacity (數據目標待訂)。需要建立工程及業務之間產銷協調機制、需要建立日報及日會或周會制度、需要增補人力或建立師徒制及培訓方法培養工程師獨立結案的能力、也需要建立激勵制度及績效制度。
S．定義一年短期目標：增加專案獲利率 (數據目標待訂)。需要建立成本計算制度。

Ｑ．組織針對年度營運有編列預算嗎？這些預算是如何訂定的？是否合理？這些預算是否能保證那些用來完成組織短期目標的計畫或專案可被執行？
Ａ．無。
S．暫無。

Ｑ．組織內有什麼固定的會議在 monitor 營運相關流程內的績效數字？有什麼固定的會議在 monitor 組織的既定短中長期目標的達成率、計畫或專案之執行進度、及預算的執行情形？除了上述目的的會議以外，還有沒有其他會議？這些會議的主持人及參與者是誰？
Ａ．每週一早上週會，老闆主持，全員參加，老闆交辦事項，夥伴問題反應，時間 30 min。沒有其他會議。
S．討論是否要舉辦專案進度日會或週會及定義會議 Routine 議題。
S．討論是否要舉辦行政事務週會及定義會議 Routine 議題。

Ｑ．組織內有什麼固定的報表在 monitor營運相關流程內的績效數字？有什麼固定的報表在 monitor 組織的既定短中長期目標的達成率、計畫或專案之執行進度、及預算的執行情形？除了上述目的的報表以外，還有沒有其他報表？這些報表由哪些夥伴負責產出？
Ａ．只有每個月出的財務報表而已。
S．制定專案日報所要蒐集的資訊及報表格式，與工程夥伴溝通做這件事的目的及好處，執行。
S．制定行政事務周報所要蒐集的資訊及報表格式，與工程夥伴溝通做這件事的目的及好處，執行。

Ｑ．有什麼資訊系統可以 support 組織掌控的營運流程？如何 support？不論有系統 support 或沒有系統 support，其原因為何？
Ａ．有 EIP，目前僅 support 事務公告，行事曆，訊息，及專案進度紀錄等四功能。
S．暫無，先等所有流程及表單和 report 都有第一版且 run 順再說。


統整上述所有的 Subsequences 並依 priority 排序如下：
S．討論是否要增補工程人力，前提是必須增補具有獨立結案能力的即戰力。
S．討論重要需要先結的專案，重新分配處理人員，看整體速度能不能快一點。
S．持續觀察每個人的個性及特點。
S．討論是否要舉辦專案進度日會或週會及定義會議 Routine 議題。
S．制定專案日報所要蒐集的資訊及報表格式，與工程夥伴溝通做這件事的目的及好處，執行。
S．建立一套方法讓工程師認為提出問題及想法是一個 routine job ，而不是特例。
S．建立 driving force 讓工程師主動積極學習。
S．建立師徒制及培訓方法培養工程師獨立結案的能力，光拿到 NI 的 CLAD 的不夠的。
S．重新 review 現有行政流程。
S．簡化行政流程，盡量讓行政流程內的經辦人數越少越好，並把所有行政流程文件化，表單化。理念溝通後，強調紀律執行。表單設計前先確認要 monitor 的高階項目 (比如說專案成本及執行效率等)，再確認表單內的低階項目能不能統計出那些高階項目。
S．討論是否要舉辦行政事務週會及定義會議 Routine 議題。
S．制定行政事務周報所要蒐集的資訊及報表格式，與工程夥伴溝通做這件事的目的及好處，執行。
S．定義一年短期目標：增加工程部門專案 capacity (數據目標待訂)。需要建立工程及業務之間產銷協調機制、需要建立日報及日會或周會制度、需要增補人力或建立師徒制及培訓方法培養工程師獨立結案的能力、也需要建立激勵制度及績效制度。
S．定義一年短期目標：增加專案獲利率 (數據目標待訂)。需要建立成本計算制度。


最後要強調的是，所有提出的問題，一定有它們發生的歷史因素，在此提醒我自己，切記要先弄清楚狀況後才擬定之後的改善計畫。　　

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

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

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

別低估了組織慣性

出處：商業週刊1058期
作者：麥肯錫台北分公司副董事暨台灣區電信與科技諮詢業務中心負責人之一　林璟驊
節錄：
做一個決策不難，但落實這個決策，很難。我們幫許多企業做轉型與組織變革時，發現多數人／組織都卡在「轉彎」處，卡在如何克服「慣性」這個節點。
原因是，人的行為有慣性，組織的運作方式也有慣性。根據實際的經驗，我們發現許多決策者及管理階層都低估了執行變革時，組織慣性（change inertia）的力量。
企業一開始想要變革的決策與出發點都正確，真正的問題是出在執行面，組織舊有的慣性，導致變革執行的不順利。大家往往都低估轉型時，組織應該要花多大的力氣來減少組織內部的反對聲浪和消極抵抗所產生的慣性，也忘記必須要花多少力氣支持新的事業。
面對這種情況時，如果不去研究阻力的來源，反而回頭懷疑當初決策的正確性，只會進一步虛耗了組織的力量。當對決策的信心越低，給予的支持就越少，最後不是以失敗收場就是整個企業卡在變革的過程中，前進也不是、退後也不是。當然，大部分企業仍然是會硬著頭皮走下去，用更多的時間和資源，撐到做出成績為止，再利用這個終於撐出的成績，來重新贏得公司內部的信心。但是如果能夠從一開始就清楚認知變革會面臨的挑戰，就可以將陣痛期縮短。
以下是我們依據過去經驗歸納的三點解決方案。
第一，傳教般不厭其煩溝通的精神。真正的傳教士精神，是經過二十次、三十次的溝通，每一次都不厭其煩的傳達相同的內容，最後成功達到目標。應用到企業變革上，就可以想像，變革需要的溝通不是只有一次、兩次，也不是只有針對直接執行決策者。所有相關的同仁都必須瞭解變革所要達成的目的和對組織的幫助。企業在實際執行時，可以透過工作坊或是短期快速輪調等形式，創造機會與第一線員工不斷溝通。
第二，特種部隊般的精密計畫。帶領變革的小組，包含企畫人員與高階管理者的特別助理，必須緊密的監控整個轉型的執行過程。他們的主要工作是每個星期一次或兩次與核心決策小組開會，密集的報告組織改革的舉措、執行狀況以及與當初決策的意圖是否有偏差和執行上的管理等。要破除組織的慣性，得靠一套嚴格執行的轉型計畫，並精準的執行。任何的怠惰都會讓組織的轉型遲緩甚至停頓。
第三，即時鼓勵。企業通常是在一個專案執行完成，才頒發一筆獎金，但常常這已經是十八個月之後的事了。這是不夠的。一件改革案的推動需要一定的時間才可能看到改變，但在這段期間內執行者可能已經因為內部的慣性和阻力而陣亡了。因此，企業主需要持續（至少每六至八個月）的給予公開支持與表揚，讓企業中其他人知道這群人正在做突破性的改變，需要組織的全面支持，並且從企業大家長開始給予精神上與群體上的認可。

瓦肯錢觀點：
這一期的文章刊出的時間有點巧。昨天才剛跟新老闆討論過去一年他認為組織內最需要處理的問題，就是這種陷入變革過程中進退兩難的麻煩。
新公司是一個以接系統整合專案為主力的小型公司，部分時間也會將專案的執行成果轉化成產品，以提供未來客戶更快速及專業的服務，它最主要的技術強項在於應變及震動方面的應用。我的老闆在半年前決定進行組織調整，他自己從技術部門中抽身，並將技術部門交給一位技術能力相當強的夥伴管理，其目的在於讓自己可以全力面對客戶，了解客戶的需求，並取得訂單。開始執行這樣的變革之後，陸陸續續發生技術部門結案速度大幅下降的問題。結案速度大幅下降的原因可能有三個 (但還沒有數據佐證)：
　　一、老闆在公司外面行程太滿，導致沒有時間將訂單需求完整的告知技術人員，以致於技術人員需要花很多時間猜測及了解需求。簡而言之就是溝通嚴重不足。
　　二、公司的技術主力在應變及震動領域，但卻接了很多與應變及震動無關的專案，在溝通不足的前提下，工程師要了解需求的困難度就大幅增加了。
　　三、技術部門只有那位夥伴有能力快速獨力結案，其他工程人員的技術能力則稍嫌不足。
於是，老闆有了一個想法，想讓自己再從客戶身上抽一點時間回到技術部門，解決技術部門的問題，於是一切有可能又回到當初變革的起點。
在上述的例子裡，很明顯的，組織變革的出發點在於『客戶導向』，而技術部門不適應新的流程與運作方式則是『組織慣性』。我相信大家都認同『客戶導向』的理念，而在當初討論時，新公司的夥伴們也應該都贊成這樣的變革，只是沒料想到會有多大的阻力及痛苦。公司負責人自技術部門抽身，本來就是一個完全正確的方向，企業的負責人最重要的職責就是了解市場、了解客戶、並據以定出組織的方向、策略及目標。至於內部的營運事務，雖然不是不重要，但相較起來，是可以授權其他專業官僚處理的。而技術部份，則又是內部事務中，最適合由專業人士處理的問題。
原文裡說得最好的一句話，我認為是『面對這種情況時，如果不去研究阻力的來源，反而回頭懷疑當初決策的正確性，只會進一步虛耗了組織的力量。』現在我們要解決的問題，並不是回頭懷疑『客戶導向』有沒有問題，而是應該維持原有的方向，然後由營運部門思考如何解決上述三個可能造成結案速度大幅下降的原因。
我已經有了一個大致的解決方向，但還需要更多數據佐證，藉以了解到底哪一個原因是最大的因子，再作最後的溝通、計畫與決定。希望下周我可以有機會把解決方向 post 出來讓所有夥伴共同討論。

職務交接時該問的八大問題

上一周整個禮拜都在忙著與繼任者作職務交接的工作，這禮拜休息，下星期又要去新公司作職務交接。原公司的繼任者在職務交接上相當有經驗，剛好可以作為一個範本，到時至新公司時照本宣科，依樣畫葫蘆一番即可。

職務交接時，最需要問的一個問題是，未來的合作夥伴們是誰 (這裡的夥伴包含老闆、同仁以及部屬)？誰是 key man？他們在組織內待了多久？人格特質是什麼？好惡是什麼？優缺點在哪裡？有沒有什麼需要幫忙的地方？

第二個問題是，組織掌控哪些營運的流程？這些流程內包含哪些功能？以及這些功能分別由哪些夥伴負責？這些流程與其他組織之間的關聯性為何？有沒有什麼改善的目標及計畫？

第三個問題是，組織內目前最急迫需要解決的問題是什麼？目前是哪些夥伴在處理？處理的計畫是什麼？deadline 是什麼時候？以及若來不及在 deadline 之前解決的衝擊是什麼？

第四個問題是，組織的既定短中長期目標是什麼？這些目標是如何訂定的？以及有何計畫或專案去完成這些目標？計畫或專案的內容是什麼？最後，這些計畫或專案執行的進度到哪裡？

第五個問題是，組織針對年度營運有編列預算嗎？這些預算是如何訂定的？是否合理？這些預算是否能保證那些用來完成組織短期目標的計畫或專案可被執行？

第六個問題是，組織內有什麼固定的會議在 monitor 營運相關流程內的績效數字？有什麼固定的會議在 monitor 組織的既定短中長期目標的達成率、計畫或專案之執行進度、及預算的執行情形？除了上述目的的會議以外，還有沒有其他會議？這些會議的主持人及參與者是誰？

第七個問題是，組織內有什麼固定的報表在 monitor營運相關流程內的績效數字？有什麼固定的報表在 monitor 組織的既定短中長期目標的達成率、計畫或專案之執行進度、及預算的執行情形？除了上述目的的報表以外，還有沒有其他報表？這些報表由哪些夥伴負責產出？

第八個問題是，有什麼資訊系統可以 support組織掌控的營運流程？如何 support？不論有系統 support 或沒有系統 support，其原因為何？

以上八大問題，相信可以讓一名繼任者在短時間內，對要接任的組織有一個全面的了解及認識。

離職感言

四年半，我終於在今天離開了這一間待了四年半的公司。

在這四年半當中，我絕大部分的時間都是快樂的，充滿想法的，興致勃勃地想要去完成一些理想的。雖然最後完成的也值得拿出來說嘴的事情不多，但絲毫不影響我的快樂的心情。一直到今天，我依然以如此這般的心情踏出這間公司。

在這四年半當中，我也看到了身旁的絕大部分人，很多時間都是不快樂的，他們也充滿想法，但大多數是負面的想法，負面到使自己沒有力氣去思考理想是什麼，理想在哪裡，以及為什麼還要待在這裡。一直到今天，他們依然覺得我的快樂是應該，因為我可以離開而且我選擇離開，他們的不快樂也是應該，因為他們走不了或是不願意走。

在這四年半當中，公司不僅從來沒賺過錢，連燒錢的速度都幾乎跟高鐵列車一樣快。快樂的人不多，士氣低落，似乎是一間不賺錢的公司難以擺脫的原罪與宿命。在不賺錢的公司裡，很難找到快樂的人。因為不賺錢，所以有人問為什麼不賺錢，是不是因為你沒做好，還是因為你，還是你，還是你，還是你，於是有人答，才不是因為我，你怎麼不說他，還是他，還是他，還是他。你今天從背後張家長捅我，明天就不要怪我暗地裡李家短戳你，亨，什麼玩意兒。大老闆也會有被逼得沒辦法的一天，所以策略要調整，東調調，西調調，亂槍打鳥，於是組織也要跟著東轉轉，西轉轉，七葷八素。結果是，在賺錢的那一天到來以前，只看結果的人都變得不高興了，因為沒人能對戳人被戳給一個交代，更沒人能對調整策略調整組織卻還是不賺錢給一個交代。

唉，何必呢，工作不就是一份工作嗎，幹嘛什麼事都要別人給交代？難道自己就不能給自己一個交代，一個簡簡單單的交代就足夠了，就可以不用這麼累，這麼不快樂了。從第一天進公司開始，我給自己的交代就是，我今天成長了嗎？成長了，就夠了。要讓自己成長絶對不是一件困難的事，任何一件小事都可以讓自己成長，我決定要寫這一個部落格，而且強迫自己每天盡量能針對一件公司發生的事或是閱讀到的一篇文章寫一篇文章，也是一種讓自己成長的方法。一間從一開始就很容易地賺錢的公司能夠讓人成長的地方也會很多，但不會讓你有這麼深刻的感覺，因為一切都像是理所當然，一切都不覺得有什麼不對。一間從一開始就在掙扎求生存的公司就不一樣，因為每一件事都有可能不對，每一件事都會強迫人思考到底有沒有問題，是不是因為策略有問題所以不賺錢，客戶定位對嗎？產品定位對嗎？產品線會不會太少？行銷方法是不是有問題？業務主管是不是夠　qualified？業務部門的人數夠多嗎？行政部門的人數又會不會太多了一點？部門之間的合作是不是有狀況？人力資源需不需要作調整？採購策略是不是要改變？大老闆作的每一項策略及組織變動，背後的目的和他的思考模式是什麼？天哪，可以問的問題太多了，每一個問題都可以讓自己有獨立思考的空間，也都可以讓自己慢慢建立一套企業運作的模型，這個模型會很強健，因為有太多 feedback 可以讓我們 fine tune，這個模型不會讓你背起來到處抄，因為你知道這個模型背後的每一個意義及由來，這個模型和到一間健全公司學習兩年複製到的模型絕對不一樣，那種模型是死的，但這一個是活的，活蹦亂跳到生命力旺盛而你不自知。最後，也許有那麼一天選擇離開，你很清楚地知道並不是因為在這裡不快樂，而是因為想去尋找有沒有會讓自己更快樂的地方，而且你也會很清楚，不管新的地方是什麼樣子，你都還是會很快樂，因為你的人生觀已經轉變了。

對於那些曾經對我說，嘿，恭喜阿，你可以走了，怪不得你看起來這麼高興的人，我的回應一向是，嘿，感謝，不過四年半中你那天看我不快樂了呢？:-) 這是我的離職感言，希望可以讓大家，不單單是這間公司的人，都可以更快樂一點。

一諾千金

一位共事情形很好也相當有默契的夥伴，在我在這間公司上班的最後一天，非常嚴肅地對我說，有一件事情要找我談談。以我過去的經驗，說這句話，通常後面跟著就是：老闆，我要離職了。『我今天都是最後一天了，跟我說離職，我還能用什麼立場說什麼，唉。』我心想。

事情起因於半年前，我和我的老闆曾經希望這位夥伴多 handle 一些組織功能，但因為組織結構上的因素，導致必須先將這位夥伴大幅 promote 後才能實行組織功能上的調整。於是我們就和這位夥伴說明，在沒有作出成績以前，一次作這麼大服務的升遷對他個人其實並不好，太多外界的同儕壓力及背後的耳語反而對他會是傷害，因此，當時先以特案 promote 一部分，等到今年一月這位夥伴績效考評時，再特案 promote 到需要的層級，然後再作組織功能上的調整。不料，半年後，組織功能調整的需求消失了，當這位夥伴績效考評時，我和我的老闆又剛好這麼不巧地都忘了半年前的這個承諾，並未特案處理，導致這位夥伴並未被 promote 到當初需要的那個層級，然後在我最後一天上班的時候，這位夥伴來向我 complain 了。當下，除了抱歉還是抱歉，還再三解釋真的是因為疏忽忘記了，沒有別的需要刻意隱瞞的原因。也立刻向他作了另一個承諾，就是在我離職前，會向我的老闆詢問是否有任何補救的辦法。這個承諾總算是有作到，雖然目前為止還不知道結果會是如何，但總之是希望能有一個圓滿的結果。

在四年工作生涯當中，我自認這件事情是相當大的一次失誤，沒有別的理由可以解釋，也無須解釋，就是怪自己疏忽了。很多事情可以疏忽，很多事情可以忘記，但，對組織裡的夥伴弟兄的承諾，是絕對不可以忘記的。