團隊熱情的建立與再激發 (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.

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．定義一年短期目標：增加專案獲利率 (數據目標待訂)。需要建立成本計算制度。


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