图文档的审批流程分析及其UML建模

1 引言

审批工作是目前企业普遍存在的一种基础性管理业务，是审批者对需要审批对象进行相关审核和批准认可，对合格对象给予某种资格或行为的小范围合理性。其中，图文档的审批工作占企业全部审批工作的绝大部分，其审批方式主要依靠各职能部门对纸质媒介的图文档进行手工审查批改，这种传统的图文档审批流程存在效率低、成本高和安全性差等不足，已无法满足产品快速研发的需求。随着企业信息化水平的提高，基于网络的图文档在线审批管理势在必行。如何加快图文档的审批流程、减少审批时间、加速产品上市，这已成为缩短产品生命周期的重要环节。

2 图文档审批流程定义

在对图文档的审批变更流程进行分析时，需明确各流程模板节点的定义、审批人员身份／角色、表决的类型、完成时的状态、流程审批对象及流程备注等内容。针对某企业对图文档管理的需求，定义了其图文档审批流程的主要节点任务，如表1所示。

表1 图文档审批流程表

(1)流程模块定义：给出了任务节点／功能块的名称，可定义为与角色名相关的名称，如部长审批，也可定义为与任务有关的名称，如校对评审等。在流程模块定义的同时，可预先定义审批人员身份，也可不定义，对于不定义审批人员身份的流程，流程发起者必须定义审批人员。对于执行多种操作需要预先定义，如当执行者拒绝或批准同意上游的申请时，流程将如何流转。

2)审批人员身份：用于设定任务审批人员，审批人员可以是组织、角色或具体的某个人。表中“*/设计者”表示组织部门没有限制，也没用指定某个特定的角色，但对角色进行了限制，即只允许设计者角色可参与设计模板的操作。

(3)表决类型：决定了任务节点的操作方式，表决类型的设定是依据流程对具体角色任务节点的需求，对于审批人员可设置批准、拒绝和不作决定等操作，对于某些只具有浏览过程的角色，可只设置完成等操作，减轻系统对用户决定方式的判断运行负担。

(4)完成状态：完成状态的设定用于区别审批和未审批状态的对象信息，无论是生产部门还是工艺部门只可对具有完成状态的对象进行调用。

3 图文档审批流程分析

根据表1定义，给出某企业工程图样审批流程，如图1所示。设计人员在图文档审批系统中对零部件工程图样发起审批流程，并对每个节点进行人员指派，系统自动检测所发起审批的零部件图样是否符合系统预定义要求，若符合将流转至下一个任务节点校核。校核节点处有三种操作：批准、拒绝和不作决定，当选择拒绝时，流程将退回至设计节点，若选择不作决定将使图样审批被挂起，若选择批准流程将流转至下一步审核。审核角色是一工艺部相关工艺人员，操作与校核类似，工艺人员对图样进行产品加工艺方面的审核，审核通过则零部件图样自动流转至标准化节点处，负责执行企业标准化的角色将检查是否符合企业规定标准，操作与校核类似，若通过则流转至定义设计部部长角色的标审任务节点，部长对图样也有三种操作，若通过则到批准节点。批准节点的角色是部长或副总经理，当审批对象是总装图样时，发起者在指派人员时应指派副总经理进行批准，当审批对象为其它，指派部长即可，部长或副总经理同意发放则零部件工程图样完成了整个审批的流程，会对发布的图样进行状态标记，并通知初始发起者。

图1 某企业图文档审批流程

4 图文档更改审批流程UML建模

图文档更改审批流程包括问题报告审批流程、变更申请审批流程和变更审批流程三个子流程，它远比图文档审批流程复杂得多，涉及的人员众多，任务处：理也多样化。而统一建模语言UML (Unified ModelingLanguage)的活动图往往用来表示在处理某个活动时，两个或者更多类对象之间的过程控制流。活动图既可以用于对高级别的业务过程进行建模，也可以对低级别的内部类操作进行建模。

(l)问题报告审批流程

创建问题报告节点：企业产品图样并不是一成不变的，对其更新或问题零部件图样进行更改都可用更改审批流程，在此任务节点上，用户发现需要修改的对象，并创建对象的问题报告( Problem Report，PR)附属在对象中，用于发起问题报告审批流程。

发起流程节点：该任务节点用于对上一节点创建的问题报告(PR)发起审批流程，流程的发起者需要对问题报告(PR)自审查，指派问题报告审批流程中各个人物节点的审批人员。若发起流程的内容符合系统定义范围之内则流转至设计校核节点中。

设计校核节点：角色与发起流程的角色相同，用于对问题报告(PR)和问题对象的核查，拥有同意和拒绝两种操作选择，若同意进入部长审批节点。

部长审批节点：角色为部门的部长，审核对象与设计校核节点类似，不同之处在于部长拥有批准、拒绝和不作决定三种操作选择，若批准则进入副总批准节点。

副总批准节点：角色是副总经理，任务与操作类型与部长审批节点类似，若批准同意，系统将提示流程的发起者问题报告审批流程的完成，并提示发起下一步流程。

完成通知节点：角色为初始流程的发起者，用于接收提示信息，此时发起者也具有变更申请审批流程权限。问题报告审批流程到此已经完全完成。

(2)变更申请审批流程

变更申请节点：角色为流程的初始发起者，在该节点的任务是创建变更需求(Change Request，CR)、设置变更申请审批流程节点中审批人员，当前两部完成后，可发起变更申请审批流程。

分析创建节点：用于分析变更需求(CR)对对象的影响，建立变更申请计划表，系统提供完成和未完成两种操作，完成后将进入部长会签节点中。

部长会签节点：审批角色为若干部门部长，对象的变更会影响多个部门，如零部件产品的变更会涉及到设计部、工艺部、生产部等部门。只有部长全部同意通过流程才可继续下去。

副总批准节点：该节点名称与问题报告审批流程中节点名称类似，但它们还是有本质的区别，首先是审批对象不一样，其次是系统提供的操作不一样，在该节点中不仅提供了批准、拒绝和不作决定操作，而且提供了拒绝所有操作。当副总经理选择拒绝时，该变更申请审批流程会返回流程的第一个节点变更申请中，若选择拒绝所有更改，审批流程会自动结束并通知发起者。

变更通知节点：角色是初始流程的发起者，用于通知变更申请流程的完成和提示发起下一流程。

(3)变更审批流程

申请更改节点：角色为流程的初始发起者，该节点的任务包括创建变更通知(Change Notice，CN)、指定审批对象人员角色和发起变更审批流程。

分析创建节点：用户接收上一流程的变更通知(CN)，创建执行变更时间计划表并确定相关变更对象。完成后流程进入部长审批节点。

部长审批节点：角色是部门部长，批准同意变更通知(CN)的发放，用于下一流程对象的设计者对对象的更改，对更改实现授权。

执行更改节点：角色为设计者，设计者对自己设计的对象有着其他人无法比拟的优势，可以快速进行对象的重设计和更改。设计者接到变更通知(CN)时，依据变更通知(CN)的要求结合更改时间计划表进行对象的更改。更改完成后提交，流程流转至多人会签节点中。

多人会签节点：角色为若干部门的专家审核人员，流程的发起者开始已指定。只有所有人员同意流程才会流转至下一步。

副总批准节点：角色为副总经理，此处节点与变更申请审批流程副总批准类似，不再详细描述。当副总批准同意后，对象变更审批流程完成，更改审批流程也完成，并对流程发起者和执行更改者发放批准通知。

审批流程是动态变化的工作流程，由于各种不确定因素（如审批人员出差等），正在运行中的审批流程可能无法继续下去，而且企业对时间审批流程的任务和节点的定义也会出现新的要求。因此，对系统审批流程提供良好的实施监控工具是非常必要的，以提高系统的应变能力和可用性：

5 结论

针对某企业图文档管理系统开发需求，分析并定义了其图文档审批流程的主要节点任务，并进行了相应的图文档审批流程分析。针对图文档更改需求，将图文档更改审批流程细分为问题报告审批、变更申请审批和变更审批i个子流程，对各子流程的主要节点任务进行了详细设计，在此基础上，基于UML建模方法建立了图文档更改审批流程的活动图模型，为图文档在线审批管理系统的开发提供了理论基础。