「哇! 好棒!」

Dear I:

人生苦短，不值得 (也沒必要) 花費在自己沒有熱情的事物上。有句話是這麼說的: Nothing great was achieved without enthusiasm。「Great」，對原本說出這句話的人來說，也許指的是「偉大」，但我倒比較樂意把它解釋成「好棒」。對，沒錯，就是好棒，就這麼簡單，一點都不偉大。沒有熱情，就做不出「好棒」的事。

好棒，多麼簡單而美麗的感覺，但我們已有多久沒有享受到這種單純的美好? 多久沒有因為一件很棒的小事很雀躍好幾天，讓我們有足夠的熱情與能量再去完成下一件很棒的小事? 好久了是吧? 那似乎是我們小時候的事了，以前以前以前，念故事書的時候好棒阿，可是自從上了小學 (或更早?)，有了考試，念書就變得不那麼棒了。以前以前以前，彈琴好快樂阿，可是突然有一天媽媽說要去YAMAHA考檢定，彈琴這件事就變了。以前以前以前，我好喜歡說話，可是有一天老師要我去參加辯論比賽，結果我發現有人比我還會說話，從此之後，我就再也不想在朋友面前說話了。以前以前以前，我好喜歡畫畫阿，可是有一天我的漂亮畫畫上面怎麼會被好醜的紅筆畫了一個數字? 而且隔壁小美的數字還比我高? 天哪，我再也不要畫畫了。

你知道為什麼嗎? 因為我們都把事情弄得複雜了。我們的心都老到忘記了事情的本質，忘記了要拋卻讓我們不愉快的因素，僅僅保留那事物中最吸引我們、最讓我們想要叫出「好棒」的部分。我們都忘記要去找那件事，忘記要去找那件事裡面最棒的因素，於是我們做了一件我們不愛做的工作，也許只是為了錢。我們也忘了要去想，除了每個月發薪水那一天會讓我們快樂一下下以外，其他30天要靠甚麼來支持度過。但如果，有這麼一天，我們都學會，只選擇看到彈琴好快樂或是畫畫好快樂，那我們就有無限的動力，練成一首美麗而動人的曲子或是畫出一幅令人感動的圖畫，然後，我們就會從心底發出一聲「哇! 好棒!」，然後我們就會很高興地去練下一首曲子或是畫下一幅圖畫，這種往下走一步的動力是甚麼? Dear I，你猜到了，那就是熱情。

人生似乎就是這樣子，一次一小步，一次一小步，走著走著，回頭一看，哇，離起點好遠好遠了，而且好像比別人都走的還遠，原來一個一個的「好棒」可以累積成「最棒」! 但如果沒有這一個一個小小的「好棒」，到最後就可能只是在起點打轉而已。加油，讓我們一起告訴身旁的人，找出那件會讓自己喊出「哇! 好棒!」的那件事，然後把它和旁邊的一切不愉快隔離開，專心的享受那個好棒就好，總有一天，他們也會發現自己是「最棒」的!

Dear I，請你和我一起大聲的念一次，「哇! 好棒」!

有沒有發現你離「最棒」又靠近一點了呢?

團隊熱情的建立與再激發 (P公司篇)

最近幾個還在P公司工作的朋友陸陸續續和我有一些連絡，也談到了現在P公司的狀況，無非就是基層士氣低落到谷底云云。因為前幾天才寫了一篇關於團隊熱情的建立與再激發的文章，只不過是以C公司作為實例，於是有些在P公司看過這篇文章的朋友們，自然就問到，那如果是P公司呢? 該怎麼辦? 是不是也來寫一篇分析?

P公司士氣低落的主要原因，在我的離職感言裡已經提過了，這裡無須再贅述。今天想要討論的只是，這種情形該如何改變? 我個人的離職感言裡的想法比較像是「反求諸己」，基層員工凡事說反求諸己還說得過去，但如果是高階經理人，要求基層員工凡事反求諸己，自己把自己搞得快樂一點就好，聽起來就百分之五千萬的沒說服力。再者老實說，像我這種天塌下來都可以找到開啪踢的理由的人也不多，如果你是高階經理人，就不用肖想下面都是一群腦袋有問題的樂天派神經病了，至少在P公司不是。

以下幾件事或許是P公司的高階經理人可以考慮作的：

1. Ｐ公司一直都有目標，而且目標很明確，只是很多年來都作不到。第一步，開誠佈公，和所有人討論溝通公司的走向，討論溝通該如何走出目前的困境，討論溝通該如何達到那個目標，甚至討論溝通是不是先設立一個短程較容易達成的目標。P公司的人數雖然是Ｃ公司的數倍，但畢竟還是一個很小的公司，和每一個人談，無論是個別地或是小群地，是一定可以做得到的事。
2. 討論溝通的過程中，同時篩選出每個人最願意合作及絶對不願意合作的對象。
3. 藉由坦率且真誠的討論溝通過程中，找出誰還有熱情願意提供自己的意見，甚至貢獻自己的力量，朝任何的可能性前進。這段話的重點有幾個，第一，真誠坦率裝不來，再笨的人都可以看出來你是不是真的要傾聽他的意見。第二，我們是要找出還有熱情的人，而不是要找出最聰明的人，最聰明的人的熱情通常消磨地最快，在這個節骨眼上，通常已經沒有什麼熱情，把公司當笑話看的成分還多一點。第三，找出來的人不只要有熱情，還要能夠願意傾聽其他人的意見，甚至是朝其他人建議的可能性前進。以這些人作為未來前進的keyman。
4. 請大部分人都不願意合作的對象走路，相信我，一定會有這種人存在，而且現階段P公司完全不需要這種關在自己房間不跟別人合作的人，現階段P公司需要的是重建一個有向心力的team。這種人在組織裡面不會有任何貢獻，這種人的存在只會造成組織力量的分散。
5. 請沒有熱情，沒有意願貢獻自己的力量甚至是意見的人也下車，這種人的存在也會變成組織前進的阻力。

也許局內人會問，也許這樣會看到一些在 function 上很重要的人被請下車，這對P公司是一件好事嗎? 好事壞事見仁見智，我比較好奇的是，這些所謂 function 上很重要的人是真的能夠對整體組織有正向的 contribution? 還是只是「function 上很重要」而已?

團隊熱情的建立與再激發 (C公司篇)

先和關心這個部落格的好友們致歉。既已自許為專業部落客，又發生一個月沒有新文章這種事，實在是不應該。



我最近發現C公司內大部分的工程師們士氣有點低落，當務之急自然是和所有工程師都面對面一對一地討論溝通。經過溝通了解之後，我歸納出了幾個原因：

1. 專案時程太長，過程中缺乏激勵。(過去的工程師能力很強，相同規格的專案所需要的時間比較短。現在的工程師都是新手或半熟手，專案時程相對來說會拉長，以前不是問題的問題現在全都顯現出來。)
2. 與客戶討論需求及規格的確認度不夠，客戶需求在開發後期會一再變更，也會導致專案時程拉長。
3. 基礎技術能力不夠，開發過程中會遇到較多的挫折。
4. 專案領域差異太大，專案領域了解不夠，開發過程中也會遇到較多的挫折。
5. 專案領域差異太大，每一個案子都是全新的案子，做完之後無法累積，工程師不了解自己的成長在哪裡。
6. 公司目標沒有讓工程師了解及內化，工程師不知道自己的努力與公司目標的達成有什麼關係。

首先，這些原因該如何分解成獨立的因子? 我認為造成工程師士氣低落的獨立因子有以下幾個：

1. 專案領域差異太大，
2. 基礎技術能力不足，
3. 需求及規格的確認度不足，
4. 人性需要被激勵，無論專案時程長短，
5. 未建立個人與團體之間的目標連結，
6. 人性需要自我成長。

該如何解決?

1. 盡量集中領域，確定公司的重點領域後，業務端就要盡量去挖掘該領域內的專案。某些情況下，其他領域的專案也必須接，但是要明確地知道、而且也要明確地讓工程師們知道，接這些專案的背後原因，比如說，為了達成基本營運目標、為了經營客戶、為了….等等。
2. 提供教育訓練，提升工程師基礎技術能力。軟體部分，請資深的工程師以公司重點領域的產品為例，建立 Development Q&A。安排教育訓練課程，資深開發工程師帶著資淺工程師實際看code，然後再看 Development Q&A (一邊看 Q&A，一邊看 code，從 code 裡面說明答案)。每個月月底定期測驗，為了激勵，於隔月月初的月會上頒發最佳進步獎。
3. 教育客戶需求確立的重要性。另外從制度面著手，強迫業務端在接案之前，必須由工程部的資深工程師與客戶偕同討論規格，並文件化，合約擬定必須以該文件為附件。使客戶明確了解需求及規格與價格之間的重要關聯性。
4. 每月月初的月會時，針對前一個月有重大進展以及正式結案的專案負責人，公開表揚，並頒發實質獎金獎勵。
5. 透過公開徵文比賽，讓每個人 (不只是工程師) 都能參與公司目標制定以及個人對該目標所能提供的貢獻的討論，針對最用心的提案者，於週會上公開表揚，並請其公開發表意見，最後頒發實質獎金獎勵。另外，每個月月底定期測驗也要固定把公司目標以及個人需要提供的貢獻置入題目內，讓每個人都能把個人與團體之間的目標連結並內化。(這個部分可以參考另外一篇文章。)
6. 經過公開討論過後，將公司的目標、策略及 to-do-list 明確化。並盡量讓每個工程師的工作或多或少都能與 to-do-list 連結，將to-do-list列入專案管理機制，藉以每周週會時提醒並鼓勵夥伴，他與公司目標的連結關係，以及他個人的重要性。

偷偷告訴大家，因為最近也剛好在思考公司未來的目標，所以就一併在上週舉辦了公開徵文比賽，第一名也在本週的週會上表揚及頒獎了，說真的，我覺得，初步效果真的很好。看到大部分人都不只是把它當成一個要交的作業，反而是在很認真地思考，還會三不五時來找我討論，感覺就像一個 team 在一起找 solution，這種感覺真棒。

C公司的三年目標 (1)

可以想見的是，這麼大的一個題目，不可能只思考一次，只寫一次。這必定是一個不斷蒐集資訊、不斷反思、不斷調整、不斷溝通、逐步建立共識的過程。會把它寫下來，也只是讓自己所有的思考留下紀錄。

過去的模式：
C公司是一間成立八年的量測系統整合商，過去主要是以專案的方式營利。所謂專案，就是當客戶有特殊量測需求，市場上卻沒有成熟的解決方案時，就會找上與Ｃ公司同類型的公司，以專案的方式委託其開發專用的量測系統。專案模式有幾個缺點：第一、客戶分散，不單單是分散在不同公司，也分散在不同領域。第二、需求分散，因為是不同領域不同公司的不同客戶，所以不太可能有幾乎類似的需求，這個月做的可能是Audio/Video的測試，下個月做的可能是振動噪音的測試，再下個月做影像辨識，這種狀況直接導致第三種缺點，也就是技術實力無法累積。另外需求分散也會帶來第四個缺點，因為業務人員很難把其中一個解決方案再複製給其他潛在客戶，所以當Ｃ公司真的要把解決方案包裝成產品推入市場時，銷售費用會變高。第五，風險過高，每個領域的需求都有其knowhow，每一個專案對於Ｃ公司來說都有許多的不可預測風險在裡面，任憑業務人員再有經驗，也很難在短時間內，把全新領域存在的風險給搞清楚再量化成成本，再者，對C公司是風險的東西對客戶不一定是，客戶能不能接受這樣的成本轉嫁是一個疑問。因此，又間接導致了研發費用升高。最後一個缺點，因為專案的硬體量小，缺乏與供應商議價的能力。

現在的挑戰：
C公司的主要供應商是一間美商公司，主要採購項目是量測系統上需要用到的擷取卡、控制卡、主機及系統開發軟體等等。過去大部分的end user都是向系統整合商購買完整解決方案，也就是由系統整合商設計、向其供應商採購零件、組裝、軟體撰寫、系統測試，最後再交由end user使用。近年來，這家供應商為了拓展銷售量，除了不斷開發簡單好用的系統開發工具以外，也開始對end user開辦教育訓練課程，教育end user如何使用簡單好用的工具開發自己需要的系統，另外，它們也培育自己的應用工程師，幫end user解決開發過程中的各種疑難雜症。簡單的說，這家供應商在告訴end user，你們不再需要花費心思找系統整合商了，我們的產品簡單到你可以自己搞定一切，就算不行，我們也還有應用工程師可以隨時支援你！不論事實是否真是如此，但至少end user會願意選擇一試，真的不成的，才回頭找系統整合商。
於是，Ｃ公司的利潤空間被壓縮了，同時，生存空間也被壓縮了。利潤空間被壓縮的原因是end user會直接向原廠購買硬體，所以C公司賺轉手差價的空間消失了。生存空間被壓縮的原因則是，end user也開始學習如何自己做系統整合，所以未來會需要系統整合商的專案量會下降，難度會上升，風險也會更高！

未來的模式：
C公司不可能回頭要求供應商放棄與end user之間的銷售路徑，這與供應商的根本利益直接衝突。供應商如果可以跟end user直接對話，本來就沒有必要維持系統整合商的生存。C公司能做的，就是要走在end user前面，我們必須比end user技術能力更高，比end user更了解knowhow及風險所在，速度更快，品質更好，成本更低廉，而且能夠讓end user長期信任。這樣才能讓end user覺得讓C公司作為其量測系統開發上的策略合作夥伴是值得的，end user也就不會想要自行開發系統。
要做到以上所說的，最重要的一點就是，C公司必須能夠先找出一至兩個領域 (例如PCB、LCD) 及應用 (例如應變、振動)，並把一部分技術資源自原有專案架構內抽離出來，聚焦在這一或兩個特定領域。資源過於分散，以上所說的事情就沒有一樣可以做得到。領域及應用集中之後，客戶與需求也會跟著集中，然後因為客戶集中，所以銷售費用直接降低。因為需求集中，所以整體研發費用可以降低、技術實力也可以快速累積、單一研發風險也跟著降低 (雖然也許會伴隨著整體經營風險的升高)，品質也會較好，同時，對供應商的議價能力也將大增，就能夠以更低成本提供給end user。再者，由於需求集中而且技術實力累積快速，自然也能夠以較快速度滿足end user的需求。整個模式就會成功。
End user要的是甚麼？無非就是速度、成本、品質與長期合作的信任。請問有哪一家半導體廠會自己開發黃光、蝕刻等生產設備？如果廠商不會自己投入資源開發生產設備，沒道理廠商會想要自己開發量測設備。我相信這是一條有機會的道路，只要我們找對領域跟應用。

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

最近不知道怎麼搞的，突然覺得聽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 了。當下，除了抱歉還是抱歉，還再三解釋真的是因為疏忽忘記了，沒有別的需要刻意隱瞞的原因。也立刻向他作了另一個承諾，就是在我離職前，會向我的老闆詢問是否有任何補救的辦法。這個承諾總算是有作到，雖然目前為止還不知道結果會是如何，但總之是希望能有一個圓滿的結果。

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

管理, 合作, 與領導

明天，2008/2/29，是我離開人生第一份全職工作的日子，我打算明天寫一篇離職感言，對自己四年來所獲得的經驗與感想作一個整理與回顧。但今天，我打算先寫一篇東西，內容是一位接任者給我的經驗分享，我覺得獲益匪淺，所以在此借花獻佛一番。這位接任者比我大十歲，有多年的管理經驗，也是上市公司的高階主管，對於領導組織有其獨到的見地。

基本上，雖然這個部落格的名字用了『管理』二字，但老實說，我個人是很排斥這兩個字，舉凡管理階級、管理者與被管理者都不是我喜歡的term。我的理想一直是，組織就是一個team，任何一個team裡面都會需要分工合作，有人提出夢想、使team member都相信這個夢想，願意為這個夢想努力，並在過程中激勵士氣以及尋找資源，讓其他team member更容易執行，共同合作把夢想實現，重點是，這整段話裡面，你看不到『管理與被管理』，但你可以看到『分工與合作』。當然，每一個組織裡面都會有誰的貢獻度高或低的問題，但這並不是我們今天談的重點，重點仍然只有一個，就是不管貢獻度的高低，每個人的基本關係都是不變的，就是『分工與合作』。

對於這個組織裡面負責提出夢想、說服成員、激勵士氣以及尋找資源的人，我個人比較喜歡用領導者這個term。領導者必須具備很多人格特質，其中最重要的是他提出的夢想一定是要無私的，是要讓所有team member都能達到更美好的境界，而且他必須把這個夢想當成他的志業一般的來經營，他還要有堅強的信念，相信他的夢想是正確的，也讓所有team member都堅定的相信他的夢想是正確的。除此之外，就像一個隊伍參加自由車比賽一樣，他必須自發地在隊伍的最前線帶領，幫其他成員減少阻力，而不是在組織的最後面推動，讓其他成員幫他一個人分擔阻力。第三，在面對困難時，他要自發地挺身而出，參與並帶領其他人一同解決困難。最後，在成功的達成目標後，把一切榮耀歸於別人，如果不幸失敗，把所有責任歸於自己。

我不是一個基督徒，但我願意用一個聖經故事說明這一切。當猶太人在埃及受難時，摩西站出來為她們畫了一個迦南美地的夢，並說服她們一同走上出埃及記的道路。在隊伍中，摩西一路走在最前面，當遇到紅海阻隔時，他舉起手杖，將紅海一分為二，讓隊伍得以繼續前進，最後成功時，他將一切榮耀歸於上帝。

領導者一定還有其他的人格特質，但，上述的這些，是一切特質的根本。

離職員工剩餘休假之計算方式

離職員工的剩餘休假天數應該如何計算？

由於管理上的方便，員工全年所有的休假在年初時即已全部賦予員工，由員工自行調配。若員工於年中離職，在離職當天，員工有可能有剩餘的休假，也有可能已超休，人資單位應該要有一套計算公式，將剩餘休假折算薪資給予員工，或是將超休假自最後一個月的薪資中折抵。

休假含特休及調休假，其性質不同，計算方式亦應分開處理。特休假較單純，以員工離職日佔全年的比例乘上該員工全年應有之特休天數，即是該員工到離職日為止所應享有的特休天數。調休假的計算方式則不同，因調休假本為勞基法所規定的放假日，企業因其運作順暢的考量，於當日上班，並把當日假期交由員工自行決定放假日，故，應以員工離職日前所遇到的調休假日天數，直接作為員工享有的調休天數，不可再併入特休假後以比例計算之，否則會有違反勞基法之虞，違反勞基法的理由是，未給予員工完整的，而僅以比例給予勞基法所定義之假日。

因此，人資單位應以上述計算方式分別計算特休及調休假日天數，加總之後減掉員工已休假天數，剩餘者若為正數，則將剩餘休假折算薪資給予員工，若為負數，則將超休假自最後一個月的薪資中折抵。

老闆要用哪種人?

今天咱家的一位軟體開發工程師問我一個有趣的問題：有兩種人，一種人是很認真但績效不好；另一種人是不認真弔兒郎當但總是能達成預定績效，我會想要用哪種人？
先聲明一點，我相信這位工程師並不是一個會揣摩上意的員工，我們也是在討論其他問題時引發出這樣的議題，他並不是想問我要用哪種人，然後把自己變成那種人地這麼有心機。

回歸正題，如果天底下的管理問題都是這麼的直接而且單純，那就不會有管理學大師，也不用開一堆像麥肯錫的管理顧問公司了。通常遇到這樣的問題，都還會有一些其他的條件或資訊輔助管理者作判斷，但如果我們就把這個問題給單純化，不要考慮太多，我們會作怎麼樣的選擇？這個問題很實際，就是，態度積極又很有績效的夥伴畢竟是鳳毛麟角，我們不可能期待手中的牌每一張都是大老二，那剩下的牌到底要怎麼打？

我對這個問題的看法是，員工的高績效是所有公司的期望，高績效是人才的產出，而人才都是需要培養的，在人才培養的過程當中，企業就免不了要承受些許的錯誤及低績效的情形發生。當然我們可以開一間從來不培養自己人才的公司，需要什麼人才就去外面挖角，但一個簡單的問題，如果是你即將被挖角進這間公司，但老闆面談時對你說，我們挖你來就是要你做這件事，以後更有挑戰性或更有趣的事情我們會挖別人來做，因為我們不能承受你在學習做新事情時的低效率，你還會答應去這家公司嗎？我相信絕大多數人的答案會是 No。最優秀的人才都往往都是以追尋新的發展新的挑戰為樂，所以就長遠的發展來看，這樣的企業不會具有發展性的，因為它根本吸引不到最優秀的人才。所以我認為企業必須先檢視員工低績效的原因是什麼，再確認該名員工是不是企業要繼續培養的對象，如果是，就應該要協助該員工，使其能達到企業期待的績效值。如果因為某些因素導致企業不願意繼續培養該名員工，則企業應該進行調離或汰換的機制以確保整體組織的運作效率。至於態度普通卻能達成預定績效的員工，我認為企業應該設計激勵機制，使員工利益與企業利益更加緊密，讓所有員工願意更主動地付出，以達成更高的績效。

以上討論，都建構在一個合理的假設上，亦即員工績效定義的合適性。企業一定要時時檢視每個組織成員在其任務上的績效定義是否合適。

希望之後可以有機會寫一篇關於激勵機制設計的文章，如果還能有機會實現，那就再好不過了。

易利信總裁的帆船領導學

出處：商業週刊1057期
作者：林鴻達
節錄：
談起讓易利信起死回生的方法，思文凱做的事，一是快速減重，二是找出方向。他發覺，經營公司就像是駕駛帆船，必須不斷減輕船上多餘的重量，再讓所有水手朝同樣的方向使力，船才跑得快。有效的溝通就像纜繩，掌握溝通原則，就能精準掌握這艘船的方向。我是靠溝通管理整家公司，他說。
領導最重要的，就是確認所有人朝同一方向移動，他分析。不斷購併，精簡成本的過程，合併的公司雙方都會遇上劇烈的組織改變。思文凱既要一面精簡公司組織架構，一面統一所有人的步伐。
公司內部討論策略的流程非常重要，他說。關鍵要建立一個能讓所有員工都參與未來策略制定的方法，我們要讓員工相信，她們的聲音會被聽見，而且只要是好的意見，就會真的成為公司的策略，他分析。
易利信最高決策單位是一個包含兩百個最高階主管的會議，全公司所有員工都能對這個主管會議提出問題與建議。有了公司的策略目標之後，就會發給下屬單位，討論她們是否同意這個策略，每個人又能有什麼貢獻，再把意見交給總公司，就像打乒乓球一樣反覆討論，甚至連每個人的考績方式都必須按照討論的結果制定。現在易利信的員工人數已回升到七萬人，思文凱可以一次抓住七萬名員工的方向，確定所有人都按公司策略前進。
透過這樣的溝通系統，思文凱一點一點的把易利信的包袱拿掉。用同樣的方法，他簡化了易利信的中層組織，也讓易利信從設備製造商開始轉型為電信服務提供者。

瓦肯錢觀點：
事前的討論溝通是一件專案推動過程中最花費時間的工作，但良好的溝通結果卻可以讓後續工作的效益加乘。坦誠、正直無私與公開是成功溝通的三大基礎，除非對方心存惡意，否則只要做到這三點，幾乎都可以讓所有人達成共識。
訂定組織方向及目標是一個組織內部最重要的工作，自然也是最需要全體組織成員溝通的工作，組織的方向及目標需要透過組織成員反覆溝通及辯證的過程，內化到組織成員的心裡，組織成員才能有所依據地快速做出細部決策，不致搖擺。
任何組織內都難免會有心存惡意，破壞溝通平台的破壞者，組織管理者的責任之一就是排除溝通平台內的負面溝通情緒，必要時將破壞者排除於組織外，維持溝通平台內的正向運作。