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

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í)間、加速產(chǎn)品上市，這已成為縮短產(chǎn)品生命周期的重要環(huán)節(jié)。

2 圖文檔審批流程定義

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

表1 圖文檔審批流程表

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

    根據(jù)表1定義，給出某企業(yè)工程圖樣審批流程，如圖1所示。設(shè)計(jì)人員在圖文檔審批系統(tǒng)中對(duì)零部件工程圖樣發(fā)起審批流程，并對(duì)每個(gè)節(jié)點(diǎn)進(jìn)行人員指派，系統(tǒng)自動(dòng)檢測所發(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ì)部部長角色的標(biāo)審任務(wù)節(jié)點(diǎn)，部長對(duì)圖樣也有三種操作，若通過則到批準(zhǔn)節(jié)點(diǎn)。批準(zhǔn)節(jié)點(diǎn)的角色是部長或副總經(jīng)理，當(dāng)審批對(duì)象是總裝圖樣時(shí)，發(fā)起者在指派人員時(shí)應(yīng)指派副總經(jīng)理進(jìn)行批準(zhǔn)，當(dāng)審批對(duì)象為其它，指派部長即可，部長或副總經(jīng)理同意發(fā)放則零部件工程圖樣完成了整個(gè)審批的流程，會(huì)對(duì)發(fā)布的圖樣進(jìn)行狀態(tài)標(biāo)記，并通知初始發(fā)起者。

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

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

    圖文檔更改審批流程包括問題報(bào)告審批流程、變更申請審批流程和變更審批流程三個(gè)子流程，它遠(yuǎn)比圖文檔審批流程復(fù)雜得多，涉及的人員眾多，任務(wù)處：理也多樣化。而統(tǒng)一建模語言UML (Unified ModelingLanguage)的活動(dòng)圖往往用來表示在處理某個(gè)活動(dòng)時(shí)，兩個(gè)或者更多類對(duì)象之間的過程控制流。活動(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)圖

    (l)問題報(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)入部長審批節(jié)點(diǎn)。

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

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

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

    (2)變更申請審批流程

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

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

    部長會(huì)簽節(jié)點(diǎn)：審批角色為若干部門部長，對(duì)象的變更會(huì)影響多個(gè)部門，如零部件產(chǎn)品的變更會(huì)涉及到設(shè)計(jì)部、工藝部、生產(chǎn)部等部門。只有部長全部同意通過流程才可繼續(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í)，該變更申請審批流程會(huì)返回流程的第一個(gè)節(jié)點(diǎn)變更申請中，若選擇拒絕所有更改，審批流程會(huì)自動(dòng)結(jié)束并通知發(fā)起者。

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

    (3)變更審批流程

    申請更改節(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)入部長審批節(jié)點(diǎn)。

    部長審批節(jié)點(diǎn)：角色是部門部長，批準(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)勢，可以快速進(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)與變更申請審批流程副總批準(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)告審批、變更申請審批和變更審批i個(gè)子流程，對(duì)各子流程的主要節(jié)點(diǎn)任務(wù)進(jìn)行了詳細(xì)設(shè)計(jì)，在此基礎(chǔ)上，基于UML建模方法建立了圖文檔更改審批流程的活動(dòng)圖模型，為圖文檔在線審批管理系統(tǒng)的開發(fā)提供了理論基礎(chǔ)。

核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://m.hanmeixuan.com/

本文標(biāo)題：圖文檔的審批流程分析及其UML建模

本文網(wǎng)址：http://m.hanmeixuan.com/html/solutions/1401939098.html