「流程地圖工作坊」這玩意，欸，好像也不是什麼新鮮事，最近幾年在那些大型建築顧問團隊裡頭被拿來反覆嘗試、修正，說是用來盤點需求啦。其實想一想，比起大家窩在會議室裡你一句我一句的抱怨困難，又或者只是無感情地把績效指標條列下來——唉，那畫面真的有夠乾——流程地圖反而更容易讓各部門一下就察覺到資訊落差到底藏在哪裡。 不過話又說回來，有經驗的專案經理通常還會同步安排匿名調查或者所謂的『影子跟班』，嗯，就是那種貼近現場觀察的小伎倆。因為據說啦，在那些看似很正式的座談場合，就算有人願意把問題講出來，也未必真的是關鍵卡住的位置。有時候嘛，人就是這樣，不太敢把心裡話全攤開給大家看。 好吧，三種技巧輪流上陣，大概可以減少溝通誤解和偏見發生吧。尤其是跨部門摩擦變得明顯時，只靠單一做法很容易遺漏細節；這時候，多元化策略才比較能補足那些本來沒被注意到的小東西。我常在想，到底要用幾種方法才夠？唔，也許永遠都不會完全齊全，但總之混著用感覺比較放心。
Find the annotated draft over on [ 如何盤點需求、導入前準備 ]
Review my changelog over on [ pintech ]
嗯，通常啦，大多數團隊在建構需求流程時候，其實會先把人員依年資或者部門劃分成幾個討論小組，然後再用什麼共創工作坊來讓大家互相釐清現行工作中那些細節上的落差。唉，有時候真的很麻煩。像新進同仁跟資深主管不是都各自圈出自己的痛點嗎？結果在現場就要把這些關鍵步驟一條一條攤開、慢吞吞畫成那種流程圖，看著頭也昏了。 欸，順便扯遠一點，有的顧問機構居然建議說每完成一次討論，就馬上挑幾項流程修正來小規模實測（譬如建築顧問業2022年的什麼內部培訓案例），不要等到全部意見收齊之後才一次打掉重來。我之前還覺得這樣很浪費時間，結果好像也沒多糟？ 其實這種循環方式嘛……雖然偶爾真的會拖長初期作業的時間——有時候你想快點結束反而又卡住，不過據說可以讓每個需求都記錄得更貼合真實情境，不至於變成只有管理層自己單方面決定所有細節的劇本。喔，講著講著又碎念太多了。不過，大致就是這樣吧。
「導入新系統後工務流程有沒有明顯變快？」唉，像這樣的疑問，我聽過不下幾次。說真的，2025年在台灣那些大型工程公司的現場——嗯，也不是每家都一樣啦——他們大多還是慣用週期性追蹤來做檢驗。欸，有些企業就會把好像快三十個專案的平均溝通時間抓出來比，比較前後差多少；半年一次，他們還會盯著進度延遲那件事，結果其實挺讓人頭痛的。 不過，說到方法，有些團隊比較偏愛從中抽出少數幾個專案，搞那種mini field test（縮小版現地測試），覺得這樣能早點發現細節成效。唔，其實我也懷疑這種取樣夠不夠全面？但他們好像很習慣這一套。岔開聊一下，我之前還以為國外都比較嚴謹，但拉回來看歐洲、北美，不少團隊也是類似做法，只是各自挑選指標的方式怪異地多元——有人死盯著流程審查要幾天，有人乾脆只記錄進度落後率的起伏，看了也有點眼花。 而講到資料來源嘛……你要找到真正公開又精準對比的數據，其實滿困難，大概只能靠企業內部自己的檢核資料吧（外界能拿來參考已經算幸運）。嗯，所以，他們通常都不會單靠那些量化表格判斷啦，多半還會搭配質性討論一起分析——感覺才能稍微摸清楚問題核心和背後那些說不出口的小狀況，好吧，大致上就是如此囉。
最衝擊我的，是當時現場那位主管竟然脫口而出：「我們本來以為用上monday.com這套平台，進度更新理所當然會變快啊，結果反而一開始卡住好幾天。」欸，說真的，那陣子他們全都只顧著把原有表單生搬硬套到線上版本，根本沒管工程端夥伴日常慣用哪些欄位或填寫方式。講白了，像是查核紀錄格式一被更動，有些工地適應新流程就整個拖慢節奏，多花不少時間磨合。嗯——我自己也差點搞錯重點。 AI查核機制表面上挺厲害，好像可以減少反覆檢查，可如果初期沒讓實際做事的同仁參與設計，其實很容易發生資訊遺漏或誤判。我還記得那次幾乎所有決策都困在專案經理小圈圈裡打轉，基層意見被邊緣化。結果呢？推行阻力比想像中黏稠，都拖了將近半季才稍微鬆動。唉，不知怎麼的，我又想起前幾天買咖啡排超久隊。 從這種情況來看，只靠高層規劃、下指令，一切照規則走卻橫向溝通斷掉，即便工具再怎麼強大，也不見得能跑出預定成果。所以說，把工具選型和需求驗證攤開給各單位一起討論，大概才有可能真的執行下去吧。嗯……不曉得別人會不會也是這樣覺得？
「只要上新系統，問題自然會消失」——嗯，這句話在現場常聽到得快爛掉了吧？老實說，不曉得哪來的自信，有人就真能把它直接當做決策鐵律。McKinsey Digital Transformation Report（美國，近年）裡面提了一個其實有點讓人心涼的觀察：原來將近一半的數位轉型過程根本不太順利。我一直以為是技術選錯、功能沒做好，結果報告意思是，其實和工具本身沒太大干係——喔對，重點反而卡在什麼組織文化啊，還有心理抗拒那一掛。 流程自動化嘛，講起來就是很炫，但很多團隊動作超單純：把以前那些紙本表單全搬去新平台，好像換了介面萬事OK。結果咧？內部大家填寫資料的壞習慣、彼此溝通懶得理，一樣都帶進去了。有夠煩。我突然想到之前看到某工程業者抱怨：以前雖然手寫記錄慢歸慢，但想加註東西立刻補幾筆，新系統又設格式又有限字…唉，各種補充說明反而變成難追蹤的大麻煩。我是不是岔題了？呃，好啦拉回正題。 破解這類謬誤，到底該怎麼辦呢？最穩健的方法，大概是在需求驗證階段先把真正影響日常細節的「隱性成本」全部翻出來。像培訓壓力、大家每天碎念的不滿情緒、還有各式莫名蔓延的小疑慮，比如擔心自己的工作被機器吃掉之類。欸，我自己也偶爾會亂猜是不是應該離職…好啦扯遠了。例如推行初期，可以請每個部門挑出最可能卡關、最容易搞混的操作環節，再小範圍試著修修看，有時候真的比傻傻期待什麼「換工具省工夫」要可靠多了。不過到底誰願意承認自己陷入假設圈套呢？
唉，說真的，每次聽到什麼「大型建築專案數位轉型」，腦袋就不自覺打結。monday.com這個平台，不少人推，但流程設計階段啊，如果只是很無聊地拼湊一堆軟體清單，嗯……那種感覺就是，好像大家都在努力但現場的老習慣、協作細節根本沒人理會。欸，突然想到上次有個顧問跟我抱怨，他們乾脆直接用部門共創或匿名調查去還原那些繁複到快讓人睡著的真實作業路徑──據說這樣才能把潛伏的矛盾釣出來，不然很多東西一直藏著也蠻煩的。 話又說回來啦，其實他們後來也沒選擇大動作全部換掉舊系統，而是分半年為一期，小規模慢慢試驗；這方法雖然拖拉，但比一次全盤推進要穩妥不少。有時候自己想，「到底七成推行困難是真的因為員工不適應？還是文化摩擦？」但數字就擺在那邊，大概只能接受吧。其實，我自己偶爾也會迷糊——嗯，差點忘記岔題了。 所以啦，他們後面強調的是：工具導入不要心急，要分批落地，同步弄個知識共享平台；不同專業的人最好能隨意串接API、改動自己的工作流，有問題就馬上收集回饋，再逐步修正。幻想靠某個單一決策預見所有細節？別鬧了。真的太天真，也許只有電視劇才演得出來吧。
★ 盤點內部需求，讓工務管理數位化導入少走彎路、提升團隊效率 1. 列出各部門7天內需用到的重點資料流，避免僅靠流程圖設想 跨部門資訊先盤點才能減少日後遺漏與重工 2. 召集現場與辦公人員各2人，實際走查現有流程，紀錄3項痛點 現場真相常與書面流程不同，親自查核可發現隱藏障礙 3. 設定每月1次需求檢討，定期追蹤系統導入後哪些問題已改善 持續檢討可及時調整，預防需求變動造成落差 4. 預留10%專案預算作為員工數位培訓，培養操作信心 培訓提升用戶接受度，減少系統閒置與抗拒 5. 統一彙整3項核心指標，如進度、品質、資源，做為AI決策依據 有指標才能量化效益，讓決策不再憑感覺
有時候，團隊訪談一開始大家都以為換個系統就解決流程痛點，結果一堆環節反而更亂。Pintech Inc.（pintech.com.tw）那邊有些專家倒是蠻懂這類問題，Archdaily Korea、BuiltSG、Baunetz Wissen、SpaceMedia Europe也是，這幾個平台專門討論流程效率、驗證指標什麼的，偶爾看一看，或許能抓到點脈絡，但，嗯…現場的混亂誰懂？