大人學-流程設計與跨部門溝通-課程心得
從去年上了第一堂大人學的課程後，到這堂課()已經是我在大人學的第六堂課(之後還有2堂課要上)，算是正式成為大人學學粉了XD 到底是什麼魔力這麼吸引人呢? 除了舒適的上課環境與好吃的便當+下午茶，最重要的還是課程的實用性，每次都是在我工作卡關的時候讓我有種豁然開朗的感覺，雖然不一定可以很快在工作上施展出來，但至少有給我一個改善的方向與心法。我覺得大人學跟別的以商業課程為主的教育機構最為不同的地方在於"心法"的傳授，商管類課程最可怕的大概就是上完感覺沒上，例如：大家都知道SWOT分析、BCG矩陣、PDCA流程改善方法，但怎麼分析完，改善後都跟沒做好像一樣，到底有融會貫通這些東西是長什麼樣子，我覺得上大人學的課超有感的。
而這堂課的上課方式對我也是一個滿新的體驗，用遊戲來讓同學模擬職場上的跨部門團隊合作會發生哪些事，以及我們到底如何改善。在過往上過的遊戲類課程都滿水的，號稱培養團隊合作與領導能力，但好像都比較是單純的玩遊戲，能把課程與遊戲內容巧妙結合的真的還是第一次看到。
遊戲內容
模擬作戰時要將武器製作後以適當方式運往前線，團隊要在20分鐘內完成老師所設定的武器種類與數量目標，全部的同學大致上可以分為3種角色：工廠(分為A廠與B廠)、調度(+通訊)、前線(分為A廠與B廠)，工廠將武器以原料、半成品或成品的方式放上小火車後送往前線，而這看似不太難的遊戲，同學剛開始也覺得只要依照各自的分工行事應該就可以順利達成目標。
然而，在遊戲開始之後就發現原本設計好的流程跟實務狀況有些落差，導致過程一片混亂，我是負責工廠B製作機砲，遊戲開始後我就非常認真的做機砲以達到通關的門檻，過程中我只在意我有沒有拿到我需要的原料，以及到底做了幾台。
直到遊戲剩下1分鐘左右，我做完指定的數量，好不容易鬆了一口氣，抬頭望向前線才發現我做的機砲好像只有一台出現在那裡，剩下的都還在工廠A的出貨區…才發現我們整個流程的瓶頸根本不在產能，而是物流，而此時看著慘烈的成績，內心的那種挫折感跟上班時候遇到跨部門合作不順導致產出東西有問題真的是一模一樣，讓我非常期待可以從下午的課程中獲得救贖。
課程的啟發
公司整體高效率與高品質產出仰賴「遊戲規則」 以前我都以為是每個崗位的專業能力+優良的溝通(多溝通產生互信)，但直到公司開始導新ERP，要跟母公司ERP接軌後(我的任務是讓財務模組和銷售模組可以順利接軌)，發現了一件非常神奇的事，就是他們的財務竟然可以在不用很了解前端的狀況下有效率且正確度很高的把東西產出，當時看了真的是嘖嘖稱奇，因為一直以來我都滿自豪於以對合作部門的了解與跨部門溝通能力，但工作好像沒有因為我非常願意主動溝通而效率變好，有時候中間還會因為一些狀況導致最後產出有問題，然後財務部又身處流程最下游，常常變成苦主部門。
而上了這堂課後，我終於了解為什麼母公司可以做到這樣，因為他們從銷售端開始就將各種銷售端的情境做分類，並在系統設置相對應的計算模組自動計算，而銷售端到財務端的資料都有明確的規格定義，然後用系統串接，直接拋資料到財務端，所以中間不會出現斷鏈問題。我們目前資料只有在最後財務端才會進系統變成規格化數據，前端給我們的資料只有幾種是有做正規化，所以很多都常常仰賴財務做覆核，導致工作量一直降不下來，跟前端溝通是很多，但問題還是很多。母公司在銷售端就直接把財務要的資料規格開好，所以業務助理算好，通過系統把關沒問題，資料就直接到財務，所以財務可以不用知道東西怎麼算出來的，就可以做後續的作業。
這讓我想到之前看過的文章，提到Amazon著名的The Bezos API Mandate，大意主要是每個團隊之間要呼叫存取資料都要透過API，而Amazon這樣的運作方式確保即使公司很大，也不會發生需要花很多力氣溝通、資料一團亂的狀況，因為遊戲規則Bezos早就訂好了。
API (application programming interface)
應用程式介面是指電腦作業系統或程式函式庫提供給應用程式呼叫使用的程式碼，其主要目的是讓應用程式開發人員得以呼叫一組常式功能，而無須考慮其底層的原始碼為何、或理解其內部工作機制的細節。API本身是抽象的，它僅定義了一個介面，而不涉及應用程式在實作過程中的具體操作。
上完這堂課+最近導ERP系統的經驗讓我了悟原來我的問題不是溝通做的不夠多，而是沒有定義好"遊戲規則"，而學習如何設計好規則是我之後要努力的部分。
化被動溝通為主動溝通 在遊戲的過程中老師有提點大家可以設置Dashboard來讓團隊可以很容易知道現在遊戲的狀況，像是產出幾個武器，有多少已經到前線了，可惜我們在第二次玩遊戲的時候還是沒有用上，然後整個場面還是非常吵鬧，因為大家都用呼喊的方式在做溝通，雖然最後有完成遊戲設定的目標，但可以感覺到過程還是滿混亂的。然後，老師的一句點評讓我印象深刻，22個人在一個5*2的空間，大家就已經搞不清楚對方在幹嘛，更何況在一個大的辦公室XD
這也讓我開始思考公司目前是用什麼方式讓每個部門可以即時知道目前的狀況，同時也檢討自己在工作的時候怎麼讓部門、老闆和跨部門合作專案的同仁知道目前的進度與狀況。平心而論，還真的有滿多地方需要改善的，尤其自己的Function在公司算是新Function，怎麼跟各部門之間怎麼接軌，有效利用Dashboard而不是一封又一封追殺的email來讓大家知道工作進度與狀況，還要有更多的思考才行。
關於Dashboard的優良案例，自己目前想到一個案例還是新ERP導入專案，母公司在專案的一開始就有一個專案時辰表，並每個階段都會發進度報告表格讓大家填寫，標準化大家的報告方式，也方便專案經理追蹤專案狀況，我自己覺得這是一個滿有效的方式。不過，目前公司每個專案經理在執行表格填寫這件事狀況就差異很大，因為常常發生發了E-mail通知大家要填表格，但大家還是不太會填表格，或是沒按時填寫表格，我自己覺得Dashboard的實際運作方式其實也是需要形成一套作業方式，但作業方式一旦形成，其實就可以降低大家無效溝通的狀況，並實際讓流程更順。
流程優化-降低人治 講到這一個Part的時候，老師提到"不要被大神綁架"，這個概念真的震驚到我，一般公司都會希望拿請到越多大神越好，感覺大神很聰明，工作效率很好，所以整個組織效率就會很好，但說實話，人力市場很現實，台灣哪些公司財力強大到連一般會計都是名校畢業的我們心知肚明。因此，老師認為應該要透過流程設計，讓可能不是那麼聰明的人也可以很快上手，並產出品質穩定的東西，而把大神的資源用在需要高度判斷力的地方。最近跟朋友吃飯也有討論到國內某知名公司有一陣子RD都被大陸挖腳，重挫研發進度，後來公司改變專案人員配置方式，將專案拆解的更細，讓每一小部分都盡量標準化，讓沒有工作經驗的工程師也能很好上手，如此一來就降低對人員被挖腳會產生的殺傷力，真是很聰明的做法。
同時，老師也在課程中強調局部強不等於整體強，流程設計要避免斷鏈，在做流程設計時，要找出流程的瓶頸，我覺得這些真的都是在實務工作中常遇見的狀況，特別是在部門部門之間晦暗不明的三不管地帶，因為大家很常只專注於自己主要負責的工作，結果這部分超級容易發生漏接，一旦出事的都要花很多時間補。
結語
看看我寫這麼多感想，就知道我有多推這堂課，而且今年這堂課超搶手的，要提前3個月報名，想上的人手腳真的要快。最後也感謝老闆和公司出錢讓我在平日爽爽搭計程車和高鐵去上課，我會繼續認真工作，優化公司流程的。
如果喜歡我的文章，歡迎按下Follow，並按下愛心給我鼓勵一下，謝謝大家!
分享至
成為作者繼續創作的動力吧！
© 2024 vocus All rights reserved.