前言

產業界所賴以為生的，是以產品的開發與生產為首要任務。而在產品的開發與生產效率上，要如何提升與精進，則有賴於產品設計資料的管理。由於好的資料產品管理，可以控制複雜的產品資料，同時也可以有效地維持設計運作流程，因此，產業界對於一個好的產品資料管理系統 [PDMS]，是有其需要性與迫切性。

在本文中，筆者將針對產品資料管理系統的定義與內涵，為讀者做一個完整的介紹，在此基礎下，下期將對目前產品資料管理系統的市場與Web化狀況，做進一步的分析。

產品資料管理系統的定義與挑戰

產品資料管理系統的挑戰，在於如何適當的控制企業的設計資料，並有效地自動傳遞給需要使用的人員。這樣的運作效率，對於產品的上市時程 [time-to-market] 有著極為重要的影響。而一個好的產品資料管理系統，正是需要迎接這樣的挑戰，並且以保存原始主資料 [master data] 的方式，有效地追蹤、控制、以及記錄之後所有的設計與變更。

此外，主資料可以擁有多份的複製參考版本，這些所謂的參考版本，可以任意傳遞到不同部門的員工，以做為不同設計、分析、以及確認的需要，而更新修正過的產品資料，則會回存到系統之中。

在這裡有一點必須要注意：所謂產品資料的更新與修正，並不會覆蓋原有的資料內容，取而代之的是一個修正過的資料複本。這個複本，必須附帶有設計者的簽證與更新的日期，並與原始的資料共存在系統之中。請注意，原始的產品資料將會以永久資料的形式存於系統之中。

以上的說明，便是PDM系統最原始的概念與設計原則。要進一步的了解PDM系統，我們可以控制原始產品資料為出發點，分別仔細探討系統的特色。筆者將就兩個層面來探討PDM系統：一是資料管理的層面 [Data management] ，另一則是運作管理的層面 [Process management]。

PDM系統的資料管理層面

通常產業界在產品資料 [如元件的設計、零組件的圖樣] 案的進步與管理上，都相當地系統化。但是除此之外，卻忽略了許多必要附屬資料的記錄，如某些特定的屬性 [大小、重量、使用場合等等]。這樣的結果，通常會造成工程師有時無法取得他們所需要的屬性資料，這使產品資料的管理效率上，出現了一定的問題。因此，一個好的資料管理系統應該要能夠針對產品資料的屬性與文件記錄，做一個完善的管理，同時也要能夠有效維持資料之間的關聯。而這樣的一個系統，目前大都是建立在一個關聯式資料庫上。又由於產品資料的數量龐大，因此對於此類資訊的處理，如何建立有效且快速的分類方式，也是相當的重要。

所謂分類方法，對於PDM系統來說，是基本且重要的能力之一。相同或類似的資訊，必須要能夠群組成一個特殊的類別 [class] ，如果有需要更進一步的分類概念，則可以利用之前所提到的「屬性」概念 [也就是某些元件的重要性質] 來完成。以下筆者就針對元件的分類、文件的分類、產品的結構、以及資料的查詢四個方面予以說明。

1.元件的分類 [Classification of components]

企業通常會根據自身的商業需求，在資料庫中建立各種元件的資料，並同時賦予特定的類別架構。而類別與類別之間也可以根據需要組織成更廣的概念類別，從而建立起一個概念性的架構。這樣的方法，可以使得企業所擁有的各個元件自然地整合在一個容易追蹤的階層網路架構中，其中每個部份均可以被賦予不同的屬性整合。此外，某些 PDM 系統甚至可以允許針對某些特定的元件建立特別的「選擇性」屬性。(圖一) 說明了元件的結構，以及元件之間的架構關係。

《圖一　元件的結構以及元件之間的架構關係》

2.文件的分類 [Classification of documents]

之前我們討論過了元件的分類問題，相同地，於某些元件或是零組件的文件，也可以利用類似的分類方式予以歸類。舉例來說，我們可以擁有「製圖」類別、「3D模型」類別、「技術文件」類別、或是「試算表」類別等等。每個文件也是可以擁有自己的各項屬性，如編號、作者、日期等等。除此之外，文件與相對的元件之間，也必須要能夠建立二者之間的關聯。因此，我們便可以取出某些特定元件的相關資料，其中包含了平面設計圖、實體模型、以及其他相關說明文件等等。

PDM系統可以因其不同的分類功能而有極大的差異。有些PDM系統很缺乏分類功能，有些系統又只允許在資料庫初始化的同時建立其分類架構。而近年來所發展的PDM系統，則可以根據管理的需要，動態地依需求定義或修改其分類架構。因此，對PDM系統來說，分類架構的操作能力直接影響了系統所能達到的能力。(圖二) 說明了文件的分類架構，以及文件與元件之間可以建立的關聯。

《圖二　文件的分類架構以及文件與元件之間可以建立的關聯》

3.產品的結構 [Product structure]

產品的資料除了可以由上述這兩種方法來予以存取之外，也可以利用第三種方式，也就是產品的結構來予以存取。而對於任意一個被選定的產品而言，該產品和其元件零組件，以及其他部份資料之間的關係都可以取得。這意味著你可以針對某項產品，取得所有相關的元件資料，同時也可以調閱各種相關的文件。這種結構的優點，在於這種結構形式不只是能夠組織產品組件之間的實體關聯，同時也能夠維持與其他文件資料之間的關係，如生產方面、財物方面、維護方面的文件等等。也因為這種特別的結構，我門便可以定義出給予不同組織人員瀏覽資料的產品架構。(圖三) 說明了產品架構組件之間的關聯。

《圖三　產品架構組件之間的關聯》

4.資料的查詢 [Querying the data]

以上所討論的資料存取方式，顯示出使用者可以根據不同的需求與途徑來「定位」並存取元件資料，使用者可以在一個分類架構上，藉著上下移動瀏覽的方式來取出想要取得的產品架構。其實，另一種有效的方式是透過指定名稱、編號、或是其他屬性組合，藉著搜尋的方式來找出特定的產品結構集合。這樣的搜尋方式，便可以運用資料庫所提供的存取功能，在大量的資料中，藉著設定過濾標準，來取得符合的資料集合。(圖四) 說明了資料查詢的流程。

《圖四　PDM系統資料查詢的流程》

PDM系統的運作管理層面 [Process management aspect of PDMS]

到目前為止，筆者所討論的，僅止於資料的組織與架構方面，說明要用什麼樣的形式，可以加速資料的連結、存取、以及交互參考。但是這些方式，都是所謂的被動程序 [passive procedure]。接下來我們要探討的，不是所謂的被動程序，而是一種主動程序 [project procedure]，也就是如何去控制人員建立與修改資料的方法。這樣的內容，似乎很類似所謂的專案管理 [project management]，其實不然。所謂的專案管理，只會考慮各個工作之間的連接性；而所謂的運作管理，則會去處理工作中資料所會造成的影響。通常運作管理系統包含了三大主要的功能：

A. 系統會管理資料被人員修改時的狀態 [也就是所謂的「工作管理」] 。

B. 系統會控制人員之間的資料流動 [也就是所謂的「工作流程管理」] 。

C. 系統會追蹤所有前兩項功能 [工作管理與工作流程管理] 所產生的事件與異動，以當作專案的歷史資料記錄 [也就是所謂的「工作歷史資料管理」] 。

以下就針對PDM系統中這三項功能予以概要的說明。

1. 工作管理 [work management]

工程師的主要任務，就是不斷的建立以及修改資料，而這正是設計工作的最主要活動。舉例來說，一個實體的模型在完成之前，可能會歷經數百次的設計與修改才能完成開發，而每一次的修改，則包含了許許多多重要的工程資料。在工作過程中，工程師則會反覆的在不同的設計版本之間作取捨，來來回回，以求得最佳的設計結果。PDM 系統的設計，正是為了提供工程師以上的工作環境所開發出來的解決方案，系統對於資料與更新格外注意，並建立各個版本的資料，藉以詳實記錄工程師的每項工作。

當然了，如果一個工程師被投予資料修改的工作，則該名工程師除了必須擁有原始的設計資料之外，還必須要有所謂的工程變更命令 [Engineering Change Order，ECO]。而在此之中，也會有許多其他的參考文件，以及其他的設計團隊參與。在傳統的設計環境中，並無法達到這樣的功能，我們必須在每一項需求發生之前 [如其他團隊加入時] 重新組織整個專案的內容，包括一切相關的資料與文件。目前我們所能見到的 PDM 系統，大都能夠針對以上的需求做出適當的功能支援，其中常見的做法便是去模擬紙上作業的工作流程，也就是我們所熟知的「使用者封包」[user packet] 概念。

所謂的封包，主要的功能是允許工程師同時管理以及修改多份不同的原始文件，同時又能夠提供參考文件不同程度的支援。這種封包的概念也可以支援所謂的並行工程設計原則，舉例來說，雖然同一個時間內只有一位使用者可以動用某項原始設計，但是同一個團隊之中的工作人員可以隨時知道原始設計目前被更新的狀態，並且相關的參考資料可以即時的更新到該名人員的封包之中。縱使某些封包的資料必須在設計者登出系統之後才能被繼續變更，但是在此之前，這些資料的內容雀可以被相關有權限的工作人員調閱，以作為參考。這就是 PDM 系統在工作管理方面所必須擁有的功能內涵。

2. 工作流程管理 [Workflow management]

封包概念使得團隊成員在工作之中可以輕易地共享一些有意義的文件群組，但是封包的功能絕對不只如此。封包還可以使一建工作在部門之間流動，或是在團隊之中的成員間傳遞，當一項產品在開發的同時，可能會有數千件零件需要設計。對任何一個零件而言，其中相關的文件，必須經過許多相關人員的建立、修改、檢查、甚至是確認，有時這樣的程序會反覆許多回。除此之外，每種零件甚至有可能會需要不同的開發形式與技術，或是不同形態的資料，例如某些部份需要實體模型，某些部份需要電路圖，其他部份則有另外的需求等等。

除了以上所討論的特點以外，在原始的資料檔案上的任何動作，都有可能會對其他相關的檔案造成影響。因此，在這樣的流程之中，必須要有持續反覆的檢查、修改、送件、以及交互檢測。有了 PDM 系統的這些特色以後，工程師便可以在設計上投注大量的心力和時間，而不致於因為團隊其他成員的修改而使自己的設計毀於一旦。有了這樣的複雜工作流程管理之後，資料管理系統便可以發揮其強大的功能，同時又可以在數千個設計決策之間，順利的決定流程中下一個目的地為何。

大多數的 PDM 系統都能夠允許專案經理控制專案的處理程序，利用預先定義的「開關」來定義事件的「狀態」[state]，同時也可以定義一個路徑列表來安排專案中所會參與的組織形態以及其他專案。這樣的功能直接反應了系統的彈性與能力，目前設計最完整的流程管理系統是以程序為基礎，每一個個體或是團隊都代表了程序中的某個「狀態」，如「初始化」、「送件完畢」、「檢查完成」、「確認完成」、「已公佈發表」，而任一個檔案或是任一筆記錄在狀態轉換之前是無法更換設計者或團隊的。

此外，某些系統則會將每件單一的工作，根據工作人員的區別給予一個代號。舉例來說，假設某位工程師正在從事某項設計，且必須要和某些同事討論最好的設計方案，由於所有相關的參考資料都包含在某個特定的封包之中，因此整個郵件便可以藉此在相關人員之間傳遞，而不需要去定義任何狀態的改變模式。

除此之外，開發團隊中的溝通也相當的重要。當資料及檔案封包在傳遞過程之中時，這些封包可能都帶有不同的指示、重點、以及其他建議。因此，某些系統在設計上便會有提供附加非正式註解檔案的功能，就如同電子話的隨意貼貼紙一般。換言之，在一流程管理系統的設計上，應朝向所謂的彈性工作環境，而不是處處設立限制。而這項挑戰，就在於系統一方面要能夠允許許多非正式得團隊工作以及多次的交互運作，同時又要能夠對專案的成本與時程有全面的控管能力。大多數流程管理系統都會允許整件工作中的最新狀態，以及其相關文件，可以在任何時刻提供授權的使用者追蹤並瀏覽之。當然了，一個開發專案中可能包含有數千件工作，每件工作都會有一個封包代表它。因此，每個封包在系統中都必須遵循其傳遞路徑，同時封包之間的關聯也必須要有仔細的控制。為了要有效地協調如此複雜地工作流程，我們必須要根據個別專案的架構來定義各項工作之間的交互依存關係。目前來說，並不是所有的 PDM 系統都能夠輕易地達成這項工作，大多數的系統都只擁有建立檔案之間階層關聯的能力而已。舉例來說，系統可以做到避免工程師在所有零組件設計完成之前就發表公佈這項設計。綜合來說，工作流程管理是PDM系統中最重要且最複雜的一個部份，其功能直接牽涉並影響整個系統的運作效率。

3. 工作歷史資料管理 [Work History Management]

由以上的說明，我們可以知道 PDM 系統不只要能夠將目前專案的狀態記錄在複雜的資料庫結構中，同時也記載了專案所經歷過的各項狀態進度，這些詳盡的資料，正好也代表著可以供做稽核工作的寶貴資料來源。由於目前許多國際性的品質管理標準 [如ISO9000，EZ2900，以及BS5750] 都定義了如何進行標準的稽核程序，因此 PDM 系統會將擁有此項能力當做最基本的要求。

除此之外，專案資料歷史管理也可以提供重要的「回溯」功能，使得追蹤專案開發中特定問題的發生點變得可能，同時也可以自某個特定的時點另外開啟一個開發工作。這種由系統記錄特定開發進度的系統，對PDM系統來說，是相當重要的。目前有部份PDM系統只記錄了文件所有權的變更，因此這種所有權的變更便可以被追蹤，但不是追蹤變更本體。另外有些PDM系統則是利用檔案變更狀態時記錄當時的專案狀態，因此便會形成工作流程歷史記錄中的漏失。

此外，還有某些PDM系統會使用類似動畫的形式來記錄系統中的任何改變，甚至可以依據預先定義詳細程度來進行，例如每當檔案修改後並儲存時，便是很好的記錄時機。而某些層次的歷史資料追蹤，更可以近一步的利用為進階的稽核資料來源，不單如此，這樣的能力更可以提供人員效能的即時監控，這對於時程相當敏感的專案來說，是再寶貴也不過的能力。因此，一個好的工作歷史資料管理系統，不單能夠提供基本的記錄能力，同時能夠輔助專案中其他功能的發揮，其重要性自然不在話下。

小結

由於產品的開發效率，對於現今的企業競爭力來說，關係著產品推出時程的快慢與否，也間接關係到企業的生存與發展。因此，如何以一個有效率的管理系統，提升產品開發的素質，將會是各個企業思考的核心。筆者將會在下一期中，為各位介紹 PDM 系統的優勢，同時為讀者分析目前的市場規模與現狀，以達到充分了解PDM系統市場的目的。

[若有疑問，來信寄到：warren@nceasy.com.tw]