進入 Corporate Engineering（企業工程支援）之後，我開始接觸不同於單一工廠或特定製程的工程工作。
過去在工廠裡，工程師通常長時間面對相近的產品、設備與製程，透過持續改善與問題處理累積專業經驗。但 Corporate Engineering 必須支援不同事業部與新創事業，工作可能涉及材料與製程整合、設備能力、品質風險、自動化，以及跨廠量產移轉。隨著專案與技術不斷改變，工程師不只需要既有經驗，更需要具備從基本原理出發，分析陌生問題、整合資源並支持決策的能力。
在這樣的背景下，主管開始思考一個更長遠的問題：如果每次遇到技術瓶頸，都必須依賴少數熟悉該項技術的工程師，那麼組織真正累積下來的，究竟是工程能力，還是個人的經驗？
這個問題，後來成為我們建立工程能力發展藍圖（Engineering Capability Development Blueprint）的起點。
一、從專案支援，看見工程能力發展的需求
傳統工程人才的培養，很大一部分來自師徒傳承與工作經驗。資深工程師透過多年實務，熟悉材料特性、設備限制與製程中的各種異常，再將這些經驗傳授給後進。
這種方式有它的價值，特別是許多現場判斷，原本就很難完全透過教科書或技術文件傳遞。不過，當組織必須不斷面對不同技術、產品與產業需求時，單靠師徒傳承也會遇到限制。
不同工站可能發展出不同的工作方法與判斷標準。有些問題只有特定人員熟悉，一旦人員異動或技術轉變，既有經驗不一定能順利轉移到新的工作情境。
主管希望改善的，就是工程能力過度依賴個別人員的情況。
我們需要思考如何將個人經驗背後的工程原理、問題分析方法與決策邏輯，整理成可以被定義、評估及持續發展的能力架構，讓工程師即使面對陌生的技術挑戰，也能運用共同的方法展開工作。
對我而言，這個任務也恰好串起過去多年累積的不同經驗。
早期從不鏽鋼產業的客訴分析與失效驗證開始，到了陶瓷產業，我接觸 QC Story、實驗設計（DOE）與全面品質管理（TQM）；進入玻璃產業後，陸續接受 Six Sigma Green Belt、Innovation Black Belt 等訓練，並參與產品開發與製程改善。我也透過工程管理進修，逐漸理解專案管理、生產管理與產品生命週期等不同管理架構。
這些學習原本分散在不同階段，各自回應當時工作上的需求。直到開始規劃工程能力發展，我才有機會把它們放進同一個架構，重新思考工程人才的專業應該如何建立。
二、從 Job Description 走向 Engineering Capability
團隊最初很自然地從各職位的 Job Description（JD，職務說明書）開始整理。
JD 可以幫助我們理解一個職位的工作內容、責任範圍與任職條件，也是組織進行招募與人力配置的重要依據。
但在討論過程中，我逐漸發現，JD 與我們想建立的工程能力架構，其實處理的是兩個不同層次的問題。
JD 描述的是一個職位需要做什麼；Engineering Capability 則是從專業領域出發，定義工程人才應具備的知識、技能與判斷能力。
如果完全依據既有職位整理能力，很容易受到當下組織分工、產品類型與設備配置的限制。當新的製造技術出現，或工程功能需要重新組合時，原本的能力定義未必能直接適用。
因此，我沒有從安排訓練課程開始，而是先尋找能夠支持能力定義的專業架構。
其中包括製造工程相關的 CMfgT／CMfgE、品質工程的 Certified Quality Engineer（CQE），以及集團內部的 Innovation Process。同時，我也將工程管理所涉及的專案管理、生產管理、產品生命週期與創新發展納入參考。
這些架構提供了不同的視角。
CMfgT／CMfgE 幫助我們檢視製造工程所需要的知識廣度，包括材料、製程、設備與製造系統。CQE 則讓品質工程的能力不再侷限於產品檢驗與異常判定，而是延伸到客戶需求、量測系統、風險分析、驗證與預防。
Innovation Process 提供另一個重要的時間軸，讓我們可以依據產品從概念、可行性評估、開發驗證到量產移轉的不同階段，確認工程師需要介入的時機、應承擔的責任，以及必須提供哪些決策證據。
我並不是直接將幾套專業認證內容合併成一份清單，而是將它們作為能力設計的輸入，逐步辨識共同能力、功能專業、不同發展階段的需求，以及後續評估與驗證的方法。
如此建立的架構，才有機會超越單一職位或製程的限制。
三、建立共同工程底盤，再發展專業深度
在整理不同專業架構時，我想起自己過去接受材料工程教育的方式。
大學階段先從數學、物理、化學與材料科學建立基礎，再逐漸延伸到不同材料與專業應用。這種先建立共同知識底盤、再往專業領域深化的結構，也成為我規劃工程能力發展時的重要參照。
我們先整理工程功能共同需要的能力，包括工程科學與材料理解、統計與量測、數據分析、問題定義、實驗設計與根因驗證，以及風險辨識、持續改善、專案管理和跨功能溝通。
有了共同基礎之後，再依不同工程功能建立專業能力的深度。
以當時我負責的製程工程與品質工程為例，兩者都需要工程原理、數據分析與問題解決能力，但各自的專業任務並不相同。
製程工程（Process Engineering） 的核心，在於理解材料、設備、製程條件與產品性能之間的因果關係。工程師必須透過觀察、實驗與驗證，將技術假設轉化為可以放大、量產與持續控制的製程窗口。
品質工程（Quality Engineering） 則需要將客戶需求、關鍵品質特性、量測、風險與驗證證據串接起來，從產品開發階段建立品質驗證邏輯，再逐漸延伸到量產後的品質控制與預防機制。
兩種工程功能都參與產品開發，但隨著開發階段推進，各自需要提供的技術判斷、關鍵技能與決策證據也會不同。
這也讓我進一步確認，能力發展不能只用「是否學過某項工具」來判斷。對不同專業與職級而言，即使使用同一項分析方法，所需理解的深度、獨立判斷能力與承擔的責任，也可能有很大差異。
因此，能力架構除了定義應具備的知識與技能，還必須考慮不同職級的能力要求，以及如何從真實工作成果判斷能力是否已經建立。
四、透過 DESIGN，建立可以持續運作的能力發展流程
當共同能力與專業架構逐漸成形，接下來要面對的就是如何執行。
如果只是整理出一份完整的工程技能清單，卻沒有能力盤點、評估與後續發展機制，這套架構很容易變成另一份需要定期更新的管理文件。
因此，我們運用 DESIGN 方法，將工程能力發展整理成可重複使用的標準流程，串接能力定義、能力盤點、評估、缺口分析與發展規劃。
在實際運作中，先依據工程功能及不同職級確認能力需求，再盤點既有人員的能力狀況，辨識目前與未來需求之間的差距，進一步規劃所需的專業訓練與專案歷練。
其中一個重要環節，是讓能力評估回到實際工作的證據。
工程師參與過某項專案，並不必然代表已完整具備相關能力；同樣地，沒有特定工作經歷，也不代表缺乏可以轉用的基礎。因此，評估必須進一步確認個人在專案中實際承擔的工作、使用的方法、形成的判斷，以及能夠驗證的成果。
另一方面，能力藍圖也不能在建立後就維持不變。
當企業進入新的技術領域，或專案執行過程出現原先沒有預期的問題時，這些經驗都可以成為重新檢視能力需求的依據。透過專案回饋，逐步調整能力定義與發展方向，才能讓架構持續反映企業真正面對的工程挑戰。
這套方法也不只適用於我當時負責的製程工程與品質工程。設備工程、自動化工程、控制工程，甚至未來新增的工程功能，都可以依據相同邏輯，重新辨識共同基礎、專業深度與發展需求。
對我而言，DESIGN 在這個任務中的價值，是讓原本分散的能力定義、人才評估與發展活動，形成一套能夠持續執行與修正的流程。
五、從個人經驗，走向組織能力的累積
回頭看，這次工作的收穫，不只是完成了一份工程能力發展藍圖。
過去我比較習慣在專案裡運用自己的工程知識，透過觀察、分析、實驗與驗證，把問題一步一步解開。這次任務則讓我換了一個角度：不再只是思考自己如何解決問題，而是思考一個組織如何辨識、培養與延續解決問題所需要的能力。
這也是 Corporate Engineering 與傳統工程支援工作之間，我逐漸理解到的一個差異。
工程團隊當然需要能夠處理關鍵技術問題的專家，但如果一項技術只存在於少數人的經驗裡，組織的能力仍然受到人員與環境的限制。當經驗背後的原理、方法與判斷能夠被整理、驗證，再透過人才發展與專案實踐逐漸擴散，才有機會讓更多工程師承接新的挑戰。
當年主管提出的問題，現在回頭看，仍然很值得思考。
如果每一次遇到陌生技術，都必須重新依賴少數專家，那麼組織究竟累積了多少工程能力？
對我來說，這份能力藍圖最大的意義，就是試著讓每一次專案留下的，不只是當次的技術成果，也包括下一次可以繼續使用的工程方法、判斷經驗與人才能力。
回到系列導讀｜職涯回顧
發表迴響