圖文檔的審批流程分析及其UML建模

王少鵬， 夏清華，， 葛燕飛， 汪永明

（1.安徽工業(yè)大學(xué) 機(jī)械工程學(xué)院，安徽 馬鞍山243002；2.安徽泰爾重工股份有限公司，安徽 馬鞍山243000）

1 引 言

審批工作［1］是目前企業(yè)普遍存在的一種基礎(chǔ)性管理業(yè)務(wù)，是審批者對(duì)需要審批對(duì)象進(jìn)行相關(guān)審核和批準(zhǔn)認(rèn)可，對(duì)合格對(duì)象給予某種資格或行為的小范圍合理性。其中，圖文檔的審批工作占企業(yè)全部審批工作的絕大部分，其審批方式主要依靠各職能部門對(duì)紙質(zhì)媒介的圖文檔進(jìn)行手工審查批改，這種傳統(tǒng)的圖文檔審批流程存在效率低、成本高和安全性差等不足，已無法滿足產(chǎn)品快速研發(fā)的需求。隨著企業(yè)信息化水平的提高，基于網(wǎng)絡(luò)的圖文檔在線審批管理勢(shì)在必行［2，3］。如何加快圖文檔的審批流程、減少審批時(shí)間、加速產(chǎn)品上市，這已成為縮短產(chǎn)品生命周期的重要環(huán)節(jié)。

2 圖文檔審批流程定義

在對(duì)圖文檔的審批變更流程進(jìn)行分析時(shí)，需明確各流程模板節(jié)點(diǎn)的定義、審批人員身份/角色、表決的類型、完成時(shí)的狀態(tài)、流程審批對(duì)象及流程備注等內(nèi)容。針對(duì)某企業(yè)對(duì)圖文檔管理［4］的需求，定義了其圖文檔審批流程的主要節(jié)點(diǎn)任務(wù)，如表1 所示。

表1 圖文檔審批流程表

（1）流程模塊定義：給出了任務(wù)節(jié)點(diǎn)/功能塊的名稱，可定義為與角色名相關(guān)的名稱，如部長(zhǎng)審批，也可定義為與任務(wù)有關(guān)的名稱，如校對(duì)評(píng)審等。在流程模塊定義的同時(shí)，可預(yù)先定義審批人員身份，也可不定義，對(duì)于不定義審批人員身份的流程，流程發(fā)起者必須定義審批人員。對(duì)于執(zhí)行多種操作需要預(yù)先定義，如當(dāng)執(zhí)行者拒絕或批準(zhǔn)同意上游的申請(qǐng)時(shí)，流程將如何流轉(zhuǎn)。

（2）審批人員身份：用于設(shè)定任務(wù)審批人員，審批人員可以是組織、角色或具體的某個(gè)人。表中“*/設(shè)計(jì)者”表示組織部門沒有限制，也沒用指定某個(gè)特定的角色，但對(duì)角色進(jìn)行了限制，即只允許設(shè)計(jì)者角色可參與設(shè)計(jì)模板的操作。

（3）表決類型：決定了任務(wù)節(jié)點(diǎn)的操作方式，表決類型的設(shè)定是依據(jù)流程對(duì)具體角色任務(wù)節(jié)點(diǎn)的需求，對(duì)于審批人員可設(shè)置批準(zhǔn)、拒絕和不作決定等操作，對(duì)于某些只具有瀏覽過程的角色，可只設(shè)置完成等操作，減輕系統(tǒng)對(duì)用戶決定方式的判斷運(yùn)行負(fù)擔(dān)。

（4）完成狀態(tài)：完成狀態(tài)的設(shè)定用于區(qū)別審批和未審批狀態(tài)的對(duì)象信息，無論是生產(chǎn)部門還是工藝部門只可對(duì)具有完成狀態(tài)的對(duì)象進(jìn)行調(diào)用。

3 圖文檔審批流程分析

圖1 某企業(yè)圖文檔審批流程

根據(jù)表1 定義，給出某企業(yè)工程圖樣審批流程，如圖1 所示。設(shè)計(jì)人員在圖文檔審批系統(tǒng)中對(duì)零部件工程圖樣發(fā)起審批流程，并對(duì)每個(gè)節(jié)點(diǎn)進(jìn)行人員指派，系統(tǒng)自動(dòng)檢測(cè)所發(fā)起審批的零部件圖樣是否符合系統(tǒng)預(yù)定義要求，若符合將流轉(zhuǎn)至下一個(gè)任務(wù)節(jié)點(diǎn)校核。校核節(jié)點(diǎn)處有三種操作：批準(zhǔn)、拒絕和不作決定，當(dāng)選擇拒絕時(shí)，流程將退回至設(shè)計(jì)節(jié)點(diǎn)，若選擇不作決定將使圖樣審批被掛起，若選擇批準(zhǔn)流程將流轉(zhuǎn)至下一步審核。審核角色是工藝部相關(guān)工藝人員，操作與校核類似，工藝人員對(duì)圖樣進(jìn)行產(chǎn)品加工工藝方面的審核，審核通過則零部件圖樣自動(dòng)流轉(zhuǎn)至標(biāo)準(zhǔn)化節(jié)點(diǎn)處，負(fù)責(zé)執(zhí)行企業(yè)標(biāo)準(zhǔn)化的角色將檢查是否符合企業(yè)規(guī)定標(biāo)準(zhǔn)，操作與校核類似，若通過則流轉(zhuǎn)至定義設(shè)計(jì)部部長(zhǎng)角色的標(biāo)審任務(wù)節(jié)點(diǎn)，部長(zhǎng)對(duì)圖樣也有三種操作，若通過則到批準(zhǔn)節(jié)點(diǎn)。批準(zhǔn)節(jié)點(diǎn)的角色是部長(zhǎng)或副總經(jīng)理，當(dāng)審批對(duì)象是總裝圖樣時(shí)，發(fā)起者在指派人員時(shí)應(yīng)指派副總經(jīng)理進(jìn)行批準(zhǔn)，當(dāng)審批對(duì)象為其它，指派部長(zhǎng)即可，部長(zhǎng)或副總經(jīng)理同意發(fā)放則零部件工程圖樣完成了整個(gè)審批的流程，會(huì)對(duì)發(fā)布的圖樣進(jìn)行狀態(tài)標(biāo)記，并通知初始發(fā)起者。

4 圖文檔更改審批流程UML 建模

圖文檔更改審批流程包括問題報(bào)告審批流程、變更申請(qǐng)審批流程和變更審批流程三個(gè)子流程，它遠(yuǎn)比圖文檔審批流程復(fù)雜得多，涉及的人員眾多，任務(wù)處理也多樣化。 而統(tǒng)一建模語言UML （Unified Modeling Language）的活動(dòng)圖往往用來表示在處理某個(gè)活動(dòng)時(shí)，兩個(gè)或者更多類對(duì)象之間的過程控制流［5，6］?；顒?dòng)圖既可以用于對(duì)高級(jí)別的業(yè)務(wù)過程進(jìn)行建模，也可以對(duì)低級(jí)別的內(nèi)部類操作進(jìn)行建模。為能夠更好地表達(dá)更改審批流程的交互性，對(duì)圖文檔更改審批流程進(jìn)行了UML 活動(dòng)圖建模，如圖2 所示。

圖2 圖文檔更改審批流程UML 活動(dòng)圖

（1）問題報(bào)告審批流程

創(chuàng)建問題報(bào)告節(jié)點(diǎn)：企業(yè)產(chǎn)品圖樣并不是一成不變的，對(duì)其更新或問題零部件圖樣進(jìn)行更改都可用更改審批流程，在此任務(wù)節(jié)點(diǎn)上，用戶發(fā)現(xiàn)需要修改的對(duì)象，并創(chuàng)建對(duì)象的問題報(bào)告（Problem Report，PR）附屬在對(duì)象中，用于發(fā)起問題報(bào)告審批流程。

發(fā)起流程節(jié)點(diǎn)：該任務(wù)節(jié)點(diǎn)用于對(duì)上一節(jié)點(diǎn)創(chuàng)建的問題報(bào)告(PR)發(fā)起審批流程，流程的發(fā)起者需要對(duì)問題報(bào)告（PR）自審查，指派問題報(bào)告審批流程中各個(gè)人物節(jié)點(diǎn)的審批人員。若發(fā)起流程的內(nèi)容符合系統(tǒng)定義范圍之內(nèi)則流轉(zhuǎn)至設(shè)計(jì)校核節(jié)點(diǎn)中。

設(shè)計(jì)校核節(jié)點(diǎn)：角色與發(fā)起流程的角色相同，用于對(duì)問題報(bào)告（PR）和問題對(duì)象的核查，擁有同意和拒絕兩種操作選擇，若同意進(jìn)入部長(zhǎng)審批節(jié)點(diǎn)。

部長(zhǎng)審批節(jié)點(diǎn)：角色為部門的部長(zhǎng)，審核對(duì)象與設(shè)計(jì)校核節(jié)點(diǎn)類似，不同之處在于部長(zhǎng)擁有批準(zhǔn)、拒絕和不作決定三種操作選擇，若批準(zhǔn)則進(jìn)入副總批準(zhǔn)節(jié)點(diǎn)。

副總批準(zhǔn)節(jié)點(diǎn)：角色是副總經(jīng)理，任務(wù)與操作類型與部長(zhǎng)審批節(jié)點(diǎn)類似，若批準(zhǔn)同意，系統(tǒng)將提示流程的發(fā)起者問題報(bào)告審批流程的完成，并提示發(fā)起下一步流程。

完成通知節(jié)點(diǎn)：角色為初始流程的發(fā)起者，用于接收提示信息，此時(shí)發(fā)起者也具有變更申請(qǐng)審批流程權(quán)限。問題報(bào)告審批流程到此已經(jīng)完全完成。

（2）變更申請(qǐng)審批流程

變更申請(qǐng)節(jié)點(diǎn)：角色為流程的初始發(fā)起者，在該節(jié)點(diǎn)的任務(wù)是創(chuàng)建變更需求（Change Request，CR）、設(shè)置變更申請(qǐng)審批流程節(jié)點(diǎn)中審批人員，當(dāng)前兩部完成后，可發(fā)起變更申請(qǐng)審批流程。

分析創(chuàng)建節(jié)點(diǎn)：用于分析變更需求（CR）對(duì)對(duì)象的影響，建立變更申請(qǐng)計(jì)劃表，系統(tǒng)提供完成和未完成兩種操作，完成后將進(jìn)入部長(zhǎng)會(huì)簽節(jié)點(diǎn)中。

部長(zhǎng)會(huì)簽節(jié)點(diǎn)：審批角色為若干部門部長(zhǎng)，對(duì)象的變更會(huì)影響多個(gè)部門，如零部件產(chǎn)品的變更會(huì)涉及到設(shè)計(jì)部、工藝部、生產(chǎn)部等部門。只有部長(zhǎng)全部同意通過流程才可繼續(xù)下去。

副總批準(zhǔn)節(jié)點(diǎn)：該節(jié)點(diǎn)名稱與問題報(bào)告審批流程中節(jié)點(diǎn)名稱類似，但它們還是有本質(zhì)的區(qū)別，首先是審批對(duì)象不一樣，其次是系統(tǒng)提供的操作不一樣，在該節(jié)點(diǎn)中不僅提供了批準(zhǔn)、拒絕和不作決定操作，而且提供了拒絕所有操作。當(dāng)副總經(jīng)理選擇拒絕時(shí)，該變更申請(qǐng)審批流程會(huì)返回流程的第一個(gè)節(jié)點(diǎn)變更申請(qǐng)中，若選擇拒絕所有更改，審批流程會(huì)自動(dòng)結(jié)束并通知發(fā)起者。

變更通知節(jié)點(diǎn)：角色是初始流程的發(fā)起者，用于通知變更申請(qǐng)流程的完成和提示發(fā)起下一流程。

（3）變更審批流程

申請(qǐng)更改節(jié)點(diǎn)：角色為流程的初始發(fā)起者，該節(jié)點(diǎn)的任務(wù)包括創(chuàng)建變更通知（Change Notice，CN）、指定審批對(duì)象人員角色和發(fā)起變更審批流程。

分析創(chuàng)建節(jié)點(diǎn)：用戶接收上一流程的變更通知（CN），創(chuàng)建執(zhí)行變更時(shí)間計(jì)劃表并確定相關(guān)變更對(duì)象。完成后流程進(jìn)入部長(zhǎng)審批節(jié)點(diǎn)。

部長(zhǎng)審批節(jié)點(diǎn)：角色是部門部長(zhǎng)，批準(zhǔn)同意變更通知（CN）的發(fā)放，用于下一流程對(duì)象的設(shè)計(jì)者對(duì)對(duì)象的更改，對(duì)更改實(shí)現(xiàn)授權(quán)。

執(zhí)行更改節(jié)點(diǎn)：角色為設(shè)計(jì)者，設(shè)計(jì)者對(duì)自己設(shè)計(jì)的對(duì)象有著其他人無法比擬的優(yōu)勢(shì)，可以快速進(jìn)行對(duì)象的重設(shè)計(jì)和更改。設(shè)計(jì)者接到變更通知（CN）時(shí)，依據(jù)變更通知（CN）的要求結(jié)合更改時(shí)間計(jì)劃表進(jìn)行對(duì)象的更改。更改完成后提交，流程流轉(zhuǎn)至多人會(huì)簽節(jié)點(diǎn)中。

多人會(huì)簽節(jié)點(diǎn)：角色為若干部門的專家審核人員，流程的發(fā)起者開始已指定。只有所有人員同意流程才會(huì)流轉(zhuǎn)至下一步。

副總批準(zhǔn)節(jié)點(diǎn)：角色為副總經(jīng)理，此處節(jié)點(diǎn)與變更申請(qǐng)審批流程副總批準(zhǔn)類似，不再詳細(xì)描述。當(dāng)副總批準(zhǔn)同意后，對(duì)象變更審批流程完成，更改審批流程也完成，并對(duì)流程發(fā)起者和執(zhí)行更改者發(fā)放批準(zhǔn)通知。

審批流程是動(dòng)態(tài)變化的工作流程，由于各種不確定因素（如審批人員出差等），正在運(yùn)行中的審批流程可能無法繼續(xù)下去，而且企業(yè)對(duì)時(shí)間審批流程的任務(wù)和節(jié)點(diǎn)的定義也會(huì)出現(xiàn)新的要求。因此，對(duì)系統(tǒng)審批流程提供良好的實(shí)施監(jiān)控工具是非常必要的，以提高系統(tǒng)的應(yīng)變能力和可用性。

5 結(jié) 論

針對(duì)某企業(yè)圖文檔管理系統(tǒng)開發(fā)需求，分析并定義了其圖文檔審批流程的主要節(jié)點(diǎn)任務(wù)，并進(jìn)行了相應(yīng)的圖文檔審批流程分析。針對(duì)圖文檔更改需求，將圖文檔更改審批流程細(xì)分為問題報(bào)告審批、變更申請(qǐng)審批和變更審批三個(gè)子流程，對(duì)各子流程的主要節(jié)點(diǎn)任務(wù)進(jìn)行了詳細(xì)設(shè)計(jì)，在此基礎(chǔ)上，基于UML 建模方法建立了圖文檔更改審批流程的活動(dòng)圖模型，為圖文檔在線審批管理系統(tǒng)的開發(fā)提供了理論基礎(chǔ)。

［1］ 王正方，南琳，王作鵬，等.企業(yè)信息系統(tǒng)中的業(yè)務(wù)信息審批模型［J］.計(jì)算機(jī)工程，2008，34（9）：257-259.

［2］ 辛華，薛福任，等.工作流技術(shù)及其在網(wǎng)上審批中的應(yīng)用［J］.計(jì)算機(jī)工程與應(yīng)用，2004，40（22）：217-219.

［3］ 于重重.基于UML 的網(wǎng)上審批系統(tǒng)的建模研究［J］.計(jì)算機(jī)仿真，2004，21（7）：169-171.

［4］ 李宗學(xué)，胡志勇，范文學(xué)，等.企業(yè)實(shí)施圖文檔管理系統(tǒng)的關(guān)鍵技術(shù)［J］.機(jī)械制造與自動(dòng)化，2007，36（4）：76-80.

［5］ 蔣勝龍，鄭忠，高小強(qiáng)，等.基于UML 的煉鋼物流仿真系統(tǒng)分析與設(shè)計(jì)［J］.系統(tǒng)仿真學(xué)報(bào)，2007，19（16）：3676-3679.

［6］ 張立春，趙合計(jì).UML 活動(dòng)圖支持的工作流建模分析［J］.計(jì)算機(jī)應(yīng)用，2003，23（5）：28-30.