0 引言
船舶行業是單批量、多品種、多專業參與的設計制造行業。船舶設計單位在經過長時間的設計工作，積累了大量的船舶設計文檔，這些文檔資料作為母型資料在新船型設計開發中有著極其重要的作用。但是隨著計算機技術的發展，在船舶設計活動中雖然擺脫了傳統的手工制圖階段，但是船舶設計文檔的管理技術并沒有跟上，設計人員要想從成千上萬的資料中找到所需要的文件還是非常困難的。另外，目前文檔的審簽仍以紙質手工審簽為主，這樣不但浪費大量的紙張，而且最主要的是對文檔的流動狀態不能進行實時的跟蹤和控制，不能進行統一的協調管理。一旦某一部門使用的文檔版本不正確，就會導致錯誤的信息獲得，可能造成不必要的重復工作，從而浪費大量的人力物力。這些目前都是船舶設計部門普遍存在的問題。而基于PDM的船舶設計文檔管理系統可以很好地解決上述問題。
基于PDM的文檔管理是用來組織電子文件的，說明該文件是由誰來擬制的，是屬于什么類型的，下一步需要誰來審核批準的。在項目執行過程中文檔設計人員只需要在自己的電腦上提交該電子文檔到項目的共享文件柜中，該文檔就會根據自身的生命周期流程自動執行該文檔的設計、校對、審核、審定等流程。PDM系統也會自動管理該文檔狀態情況以及版本變化情況。這樣就避免了設計人員拿著圖紙到處審核的低效率審簽流程，還可以保證文檔在傳遞過程中的版本一致性，便于其他工作人員查詢最新的信息，從而減少不必要的損失。
1 文檔屬性類型
要想對船舶文檔進行有效的管理，首要步驟就是對船舶文檔進行正確的分類研究。按照文檔的性質和在設計過程中所起的作用將文檔大致分為設計文檔、管理文檔、規范類文檔以及試驗文檔等，從文檔在產品開發過程中所起到的作用上來講可分為任務書、2D文件、3D文件、技術說明書、報告、會議紀要、通知書、建議書……。
2 文檔界面設計
用文檔擬制工具(Office/AutoCAD/Catia/Solidworks等)擬制船舶設計相關的電子文件。進入PDM系統，在個人文件柜下建立一個文檔對象，填入表1中需要手工填寫的屬性。把新建的文檔從個人文件柜中檢入到項目文件柜的相應目錄下，完成該電子文檔的提交。
表1 文檔屬性類型
因為PDM的文檔管理具有一般性，而不是在針對某一具體產品的，如在船舶圖紙類文檔中圖紙具有圖號的屬性，而在原有的PDM系統是沒有該項的，因此需要進行二次開發研究開發出符合船舶設計特點的文檔屬性界面，由于篇幅原因，這里僅以“圖號”為例進行研究。
為了保證原系統的完整性，“圖號”的開發采用的是在Windchill原有的數據模型基礎上，通過對代碼重新編譯（如圖1所示），然后通過系統代碼生成工具Windchill system generation進行代碼生成，最后采用SQL語句生成對應的數據庫中oracle表實現代碼的實現。而對于如“密級”屬性的實現則需要采用標準文檔類文件來實現，如圖2所示。
圖1 文檔開發程序
圖2 文件柜存儲文檔的結構
3 文檔的存儲
在船舶PDM系統中，文檔的存儲原則主要是按照船舶設計單位劃分的行政專業組在Windchill系統中對數據進行組織，這樣便于文件的查找，同時也可按不同部門的域權限對文檔進行訪問權限控制管理。文檔的數據存儲方案如下：
一級子目錄：各種不同型號的項目名稱（項目對象同時存放在該目錄下），在項目對象產生的時候在系統文件柜中自動產生這類目錄，這樣就可以在文件柜中很方便地查到該項目的文件資料。將來可以根據文檔的項目團隊屬性（該項目團隊屬性與項目對象同名）和所在的部門與專業組信息，很方便地將其自動檢人到該一級子目錄下。
二級子目錄：按照功能劃分的文檔類型和其他數據類型來劃分。
各部門根據自己所包括的專業組，在Windchill系統中設定文件柜，在創建某項目對象時，一級和二級子目錄同時被自動創建。
文檔在正式歸檔以前，不僅會決定自己所在的文件柜和一級子目錄，而且還會根據文檔功能類別屬性，自動決定文檔要存放的二級子目錄的位置。由于在Windchill系統中對文件柜本身進行權限限制，因此用戶并不能看到所有的文件柜，而只能看到被授權的文件柜（主要是自己所在專業組對應的文件柜）。
船舶設計文檔在創建之初只存放在相關人員的個人文件柜中，只有本人或者管理員可以訪問該文件，個人文件柜中存儲組織方式可以根據用戶每個人的個人喜好進行子目錄的劃分，對文檔進行分類存放。對于存在共享文件柜中的文件存儲需要按照該單位的項目要求進行統一規劃，子目錄名稱即為該科研項目名稱，同時可以在子目錄中再建子目錄來存儲子項目的信息資料。個人文件柜和共享的文檔之間需要通過檢入/檢出操作實現對文件的轉移和版本控制。
4 文檔的版本管理
船舶設計是一個反復修改的過程，其設計文檔的版本時有一個演化過程。任何一個文檔的版本由大小2種版本構成。大版本變化序列為：A→B→C→D；小版本變化序列為：1→2→3→4。版本的主要變化規律如圖3所示。一個文檔在沒有達到審批狀態之前的版本變化只是小版本的變化過程，系統只記錄修改過程和最新的小版本號，而不需要設計更改過程的控制，經過幾次修改，小版本的變化過程為：A.1→A.2→A.3→A.4。如果文檔通過審批狀態和發放狀態發現問題，則修改過程需要采用變更控制管理而且需要實現大版本的辯護，如從A.2版變到B.1版等，這種變化即為版本的升級過程。
一個完整的文檔版本演變過程為A.1→A.2→A.3‖B.1→B.2‖C.1→C.2→C.3。版本的變化不會造成文檔編號的改變。
圖3 文檔版本演變過程
5 工作流管理
文檔的傳遞過程是以文檔的工作流程為順序實現的，從而保證文檔傳遞的一致性、真實性以及完整性。在流程執行過程中，如果多審批環節每一個活動的角色都有項目工作人員或領導參與，則執行完整的多審批流程；否則，如果某一活動的角色沒有具體的項目工作人員以及領導參與，則該活動將會被自動跳過；如果僅僅有一個審批環節的角色被指定了參與人員，則該多審批環節在系統中將自動轉換成單審批環節（因為其他的環節均被系統自動地跳過）。不同類型的文檔具有的生命周期和工作流程是不同的。典型的船舶設計過程中的文檔需要經歷設計、校對、審核、標檢、審定5個階段才能歸檔，如圖4所示。
圖4 文檔審簽流程
以“船體結構計算書”為例說明文檔審簽流程。文檔審簽流程的參與者角色對應到具體的人員，這里假設“船體結構計算書”的整個審簽流程中設計者為總體科員A、校對者為總體科員B、審核者為總體科長、標檢者為總體科員C、審定者為總工程師。該文檔的審簽流程如下：
1)總體科員A把“結構計算書”在本地電腦設計完成后，將文檔提交到個人文件柜中再檢人共享文件柜中完成其提交工作。因為在“設計”階段不需要審核檢查，所以文檔設置自動升級。
2)校對者（總體科員B）在自己的工作表中收到審閱任務，如果在審閱后認為“結構計算書”中沒有問題，選擇批準，文檔進入“升級”狀態，文檔將升級到審核階段。如果有問題，則可以在圖上進行必要的標注。在這個進程中若發現文檔中有問題，則不批準，返回給設計者，設計者在自己的工作表中接收到修改任務書，將文檔檢出到自己的個人文件柜中，對文檔進行修改，并把修改的內容注釋填寫在說明中，在校對階段進程中，工作流模板如圖5所示，校對者的審閱過程模板如圖6所示。這樣就完成了設計——校對階段，其他階段相似，直至文檔達到歸檔狀態，這樣就完成了文檔的審簽流程。
圖5 工作流模板
圖6 審閱過程模板
6 文檔查詢
輸入查找信息——船體圖紙文件送船檢審查目錄，如圖7所示。搜索結果的顯示見圖8，可以選擇自己所有進行的操作。
圖7 輸入查找信息
圖8 結果顯示
7 結語
船舶文檔管理是一個很復雜的系統工程，本文從系統的角度對文檔的類型、制訂提交、存儲、權限管理、版本管理、工作流程管理進行設計研究，改變了傳統的文檔紙質傳統方式，提高了文檔的設計效率，增強了企業競爭能力。但由于其文檔類型的復雜性，其存儲管理和審簽流程也是復雜多變的，本文針對一些較典型的情況進行研究，只是船舶設計過程的一小部分，仍有大量的研究工作需要進一步展開。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://m.hanmeixuan.com/
本文標題：基于PDM的船舶文檔管理系統設計與開發
相關文章
