第五章 研究發現
第三節 產品生命週期管理系統採納之後的設計鏈管理
國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
第三節 產品生命週期管理系統採納之後的設計鏈管理
為了讓使用者比較容易接受產品生命週期管理系統的使用，優品公司在採 納之前做了相當多的努力。在決定採納產品生命週期管理系統之前，公司先成 立一個調查委員會，除了進行市售產品生命週期管理系統軟體的評估之外，還 肩負著發掘各部門在運作上的問題以及需求彙總，並對這些問題提供對策或解 決方案。。該委員會的成員以公司各部門最資深的員工為代表，由於他們通常 有較廣泛的人脈關係，且熟知許多組織部門的運作規則，因此有助於組織運作 與軟體的瞭解。一位參與的資深協理提到：
核心推動小組就是決策小組，在剛開始推動時，先進行調查工 作。小組成員來自於製造、採購、研發/零組件工程師代表和一些瞭 解公司程序的代表，加起來共 7 位，雖然未必涵蓋所有團隊，但是已 經具有代表性。核心推動小組在系統上線之後，多數陸續歸建到原單 位；未歸建者則成為新單位「流程創新部」的成員，成為我部門旗下 的一部份，繼續推動此一採納專案。
核心推動小組是暫時性任務編組，在系統正式上線之後，任務就此結束。
代之而起的是流程創新部，目的在解決因為產品生命週期管理系統的採納所衍 生的問題。公司在正式採納產品生命週期管理系統後，成立關鍵使用者團隊
（Key User Group）協助系統的使用。這些關鍵使用者是由各部門指派或推選，
原則是以最熟悉產品生命週期管理系統的使用者，可以協助解決部門其他成員 在運用產品生命週期管理系統上的困難。關鍵使用者不能解決的事，會提到流 程創新部的會議上討論，議決出解決方案。
在採納的過程中，會定期舉辦組織中成員的教育訓練，期望每一位同仁都 可以熟悉產品生命週期管理系統的功能及操作，務必使先前沒有參加訓練的成 員都有機會接受訓練，原則上這是公司的策略規定，因此每一位設計鏈的成員 都必須熟悉此套系統的應用。另外，如果組織成員遇到使用上或是操作上的問
‧
間。我之前使用的零組件管理程式與 IIIndex（零組件索引資料庫）是 分開的，我要去零組件管理程式那個資料庫找資料，然後在 IIIndex 系統內完成。現在產品生命週期管理系統中這些資料完整的連結，我‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
壹、新工作例規
一、設計啟動（Design Initiation）例規
1、確認料件與廠商驗證
在訂單取得的程序裡，使用產品生命週期管理系統前後並未發生太大不 同。不過在新料號的申請方面卻有新的變化，特別是在確認零件供應商是否為 合格廠商的部分。採納產品生命週期管理系統後，使用者必需遵守許多預先設 定的規則，否則料號申請的程序就無法進行下去，這不像以前的作法可以有相 當的彈性，系統在新料號的資料申請傳遞上有著嚴格控管的作用。一位零組件 工程部的處長提到：
基本上，產品生命週期管理系統具有規範使用者行為的功能，這 是本公司特有的。這些規則對設計鏈有所規範，並且對整體產品開發 和之後量產是有幫助。其他公司只是把這個系統當作資料庫而已，我 們不是。我們現在正在使用產品生命週期管理系統開發一些新程式，
有些東西你沒有經過某些條件，你就只能執行某些工作，例如你不是 合格廠商就只能買當作樣品的零組件，而不能買這些零組件當作是要 做量產的東西，我們會在系統設定下單的時候下不出去。
優品公司透過設定產品生命週期管理系統中的規則，部分替代了過去人工 審核的功能，這些規則具有強制/限制使用者行為的作用。以上述的案例來說，
關於量產時所需的零件，其規則被設定為需滿足由「合格廠商」供應，若不符 合此項規則，採購工程師在採購時就不能購買，採購行動便無法執行。久而久 之，採購工程師會特別注意所採購的是否為合格廠商所生產，並提醒設計工程 師注意；而設計工程師也會盡量避免採用此類廠商的零組件，就算不得已要採 用，也會提醒此廠商的資料必須送審。
在 零 組 件 資 訊 蒐 集 方 面 ， 採 購 人 員 透 過 產 品 生 命 週 期 管 理 系 統 使 用”where-used”（類似一種 Google 的搜尋機制）的功能，去找尋現有用料的重
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
複性、更換性之外，並參考公司中企業資源規劃系統中現有的庫存資料，以決 定要不要換零件。這種跨資料庫的整合資料搜尋功能，過去的系統無法提供，
需要人工在不同資料庫中不斷地比對。同樣地，物料管理人員也有類似的使用 上好處，像在判斷料件的庫存水準時，不需要在不同資料庫間搜尋計算，透過 產品生命週期管理系統可以容易地決定所選定的料件是否斷貨還是在正常供貨 的狀態。這不僅節省了資料蒐集的時間，也不需要靠設計工程師各自的搜尋能 力，就能提高查詢效力。
2、料號審核與料號修改
過去設計工程師在接到新的專案，確認客戶所要的零組件規格，填具新料 件申請書即可，之後的審核及資料輸入工作由其他部門的同仁完成。採納產品 生命週期管理系統之後，設計工程師在系統中填具新料號申請欄位，自動傳遞 到零組件工程師審核，審核後的資料若無誤，則自動輸入到資料庫中；若有問 題，系統自動退回申請者修正。對於不確定技術參數的零組件或是開發中的關 鍵零組件，設計工程師在申請時，會將技術參數的欄位先空白，單單申請料號，
這些空白的資料最遲需要在進入量產程序之前填入系統中，否則此零件就必須 更換，此一期限稱之為「發送製造作業」（Release To Manufacturing;簡稱 RTM）。 發送製造作業是量產前的一個重要關卡，若是無法在此把關，許多不合標準或 規定零組件便會被採購，甚至進入量產，影響製造品質甚鉅。
從申請料號的過程來看，新的流程增加了設計工程師的工作負荷。過去設 計工程師只要填完申請書後就好，現在把原本專案工程師的工作轉移過來，工 作量增加不少，引起相當多的抱怨。為了使設計工程師能可以聚焦於設計工作 上，研發部門找了助理工程師來處理新增的工作，一位資深協理提到這樣的狀 況：
‧
‧
‧
‧
（upgrade part revision），去調整成為你用的東西，但是你放棄這方法 而去用新料件的申請，這也會產生新的料號。舉實際的例子來說，有
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
頭正確之後，資料庫的建置才有意義。因此，設計工程師需要瞭解每一個零件 的特性、規格以及技術參數等相關細節，並仔細填入系統中的欄位，才能申請 新料號，不再是像過去丟給零組件工程師審核就完成了。就算工程師使用了彈 性機制，最後在量產之前仍必須補填，因此輸入工作也成為設計工程師的新工 作，有了新的工作負荷；雖然增加助理工程師協助作資料輸入，但是助理工程 師的工作成效如何仍須持續觀察。而產品生命週期管理系統嚴格規定程序的特 性，也解決了彈性機制的料號申請方式所衍生的缺點，透過設定「發送製造作 業最終期限」（RTM），解決了過去因為資料填寫不完整而產生的風險，提升了 整體的設計績效。
二、設計整合（Design Consolidation）例規
1、設計與版本管理
在設計採納初期，許多設計工程師並未真正改變自己在設計上的習慣，依 然用過去沒有產品生命週期管理系統時的習慣在處理工作；過去設計者將設計 資料儲存在自己的電腦中，以方便隨時修改，等到設計完成之後，才會送給設 計部門主管或是資深設計者審核。之後，才會上傳到指定的伺服器中儲存，供 相關人員存取使用。採納產品生命週期管理系統帶來的改變是每一個版本的變 更都要依據一定的程序上傳到系統之中，系統會依時間記錄每一個變更點，儲 存在系統之中；在使用時也需依據一定的程序及權限才可開啟檔案使用，這是 基於提高資料保護的安全性。不過，一位資深協理提到他去詢問設計工程師為 何不用產品生命週期管理系統來做版本管理時，所得到的結論卻是剛好相反，
他描述設計工程師心中的顧慮：
研發設計產生的主要原始檔案並沒有在產品生命週期管理系統中 有效的控管，而是由設計工程師以自己的方式控管。主要的問題是：
他們會擔心產品開發的原始資料安全性問題，而不願意在系統提供的 控管機制下面來管理版本。
‧
師許多負荷，主要是 check-in 以及 check-out 的過程。他們除了要做文 件之外，在改下一版時，還需要透過重重關卡取出資料，設計工程師 單（checking list）、設定規則（validation rules）以及限制（constraint）的部分，也是產品生命週期管理系統所需設定的審核規則。
‧
‧
4 ECO （Engineering Change Order）工程變更命令：工程部門確認必 要的變更後，發出文件交相關單位會簽，以確保庫存品、再製品被妥善處 理，是立即變更、使用完畢後變更等，銷售單位、製造單位、物料單位都 要同意且採取必要行動。
‧ 國
立 政 治 大 學
‧
Na tiona
l Ch engchi University
專案工程師認為與其等待系統的提醒，以人工方式反而更快、更有效率。但是，
這樣卻又形成專案工程師新的工作負擔。在此，系統並不能解決人的問題，對
這樣卻又形成專案工程師新的工作負擔。在此，系統並不能解決人的問題，對