OA流程设计与实现单位：姓名：现任专业技术职务：评审任职资格：摘要随着计算机网络技术的发展，办公自动化系统（OA，Office Automation）应用越来越多。

但目前基于Lotus Domino/Notes的办公自动化系统还存在着一些不足之处。

例如公文流转中流程的灵活性和智能化问题、文档安全问题等。

本文以基于Lotus Domino/Notes的办公自动化系统中存在的问题为出发点，探讨OA系统流程设计的开发技术和策略。

本文以某公司现有公文流转模式为参考，设计开发该公司的公文管理模块，包括可视化表单、收发文流程，从而实现公文流转电子化，提高工作效率。

关键词：办公自动化，OA，工作流，公文流转，Lotus Domino/Notes目录摘要 (1)第一章绪论 (3)第二章系统架构 (4)2.1需求分析 (4)2.2开发平台 (4)2.3流程描述 (4)2.4数据库规划 (5)第三章系统设计 (6)3.1数据库设计 (6)3.2表单设计 (7)3.3视图设计 (9)3.4安全设计 (10)第四章结束语 (10)第五章参考文献 (11)第一章绪论步入二十一世纪后，计算机网络技术发展飞速，建设网络平台、推进网络办公、实现信息共享是企业发展中面临的问题。

如何解决这些问题，需要企业加快信息化建设步伐。

办公自动化系统做为信息化建设中基础管理系统，建设尤其重要。

最近十年，我国经济迅猛发展，企业快速扩充，随即出现了很多问题，如办公地点分散，办公人员众多，文件下达滞后等，传统办公方式效率较低，办公自动化有效解决了异地办公、信息共享。

公文流转做为办公自动化系统核心引擎流，一直是建设的重点内容，也是难点之一。

本文以某公司的办公自动化应用为背景，根据该公司现行公文处理过程，使用Lotus Domino/Notes的基础平台，设计公文管理模块。

本文设计的公文管理模块内容上主要包括两大部分：可视化表单和公文流程，功能上主要有发文流程和收文流程。

第二章系统架构2.1 需求分析现有一个大型集团公司，某公司属于集团公司的二级子公司，公司下设分子公司及项目部。

该公司日常公文有两大部分：一是发布本公司的文件，发文需经过公司职能部门、办公室、分管领导、总经理等流转过程，然后分发至相关职能部门；二是接收集团的文件，收文相对简单，主要经过办公室和总经理审批，然后分发至相关职能部门。

发文过程涉及各职能部门会签，需要各部门协作配合，同时需要主管部门监督，收集整理各职能部门提出的意见后进行修订，所以该流程必须有以下功能：第一，会签功能，解决多人同时处理公文问题，加快流转效率；第二，留痕功能，流程处理人可以提出自己的意见和看法，然后对文件进行修订，系统需记录每个人的操作痕迹；第三，加密功能，按照集团档案管理办法，每个文件设定了不同的浏览权限，所以需对文件进行加密，以防外泄。

2.2 开发平台选择一个好的开发平台对系统设计非常重要，本系统开发平台是IBM公司的Lotus Domino/Notes 6.5。

它不仅可以满足以上办公自动化系统建设的基本要求，其自身还具有许多独特的优势。

第一，Lotus Domino/Notes作为文档数据库管理系统，能够高效处理信息；第二，作为群件平台，能够实现信息共享；第三，具有先进的通信机制，便于多人同时操作；第四，兼容性好，可以将Web浏览器作为Notes 的客户机，从而实现顺畅连接Internet。

基于以上分析，选择Lotus Domino/Notes 6.5工作流软件平台做为OA系统建设的基础，使系统的开发具有较高的技术起点。

2.3处理流程本系统是为某公司而实现的电子政务系统，经过实际调查，在整个公司办公流程的处理流程中，人员角色首先从岗位角度划分为：主办单位核稿（部门经理）、主办单位领导审核（分管领导）、会签（专业分管领导），审批（总经理），办公室阅办（办公室主任），签发（董事长），文书登记编号（办公室文员），文书归档（档案员）等几个岗位。

办公信息处理分为两类就可以满足现实需要，即发文流程和收文流程。

(1) 发文流程。

部门的日常发文流程如图2-1所示。

首先，主办单位拟稿发起流程，然后主办单位部门经理核稿，部门经理具有修改权限，可以对文件进行修改。

部门经理同意后发给主办单位分管领导，主办单位分管领导有三种选择，第一种“不同意”情况，文件返还部门经理；第二种“同意”情况，如果需要其他分管领导提出意见，发至相关分管领导，各分管领导同时收到文件，分管领导签署意见后返还主办单位分管领导；第三种“同意”情况，主办单位分管领导发至总经理审批。

总经理有两种选择，一是“同意”后发至办公室主任，二是“不同意”，发至主办单位部门经理修改。

办公室主任根据公司发文授权体系决定文件是否需要经董事长签发，如果不需要直接发至办公室文员，如果需要发给董事长。

董事长如果同意，发至办公室秘书登记编号，如果不同意发给主办单位部门经理修改，部门经理修改完成后继续流转。

办公室文员负责对文件登记编号，然后发给档案员，档案员完成归档工作。

(2) 收文流程。

收文主要是公司接收集团下发的文件。

收文流程如图2-2所示。

首先办公室文员接收文件并登记，然后发给办公室主任拟办意见，根据文件内容不同，如果需要总经理批办的，办公室主任发给总经理批办，如果不需要总经理批办的，直接发办公室秘书承办，办公室秘书根据批示内容分发给相关部门后归档。

图2-1发文流程图2-2收文流程2.4 数据库规划文档、人员、权限等的管理都要通过数据库进行管理，数据库中的文档包含了所有的应用对象。

一般来说，先设计表单、视图等文档，然后按照定制的工作流程对文档进行处理。

每个数据库都可以包含不同格式和类型的文档。

在本系统中，可以充分利用Notes的工作流自动开发功能实现收发文的电子化操作。

而有些部门则存在大量的业务处理，这些处理产生大量的数据，最后生成许多报表。

本系统充分利用Notes和关系数据库的优势，将二者集成到一起，增强系统功能。

Notes客户端访问关系数据库时，首先扫描关系型数据库，生成待处理文档，访问接口按照当前打开的文档类型，把其表单属性赋给新生成的文档，然后将读出的关系数据添加到文档条目中，要显示该值，则可将该值赋给表单中预先定义好的域中。

这样我们就实现了Notes对关系数据库的访问，将两者相结合，后台拥有关系数据库的数据管理优势，前台充分发挥Notes分布数据管理的优点。

这样我们一方面可以满足日常办公流程中非结构化数据较多而且通信要求较高的需求，另一方面又方便用户对大量数据进行高效管理。

第三章系统设计本系统的公文流转模块主要分为发文管理和收文管理两大部分，系统界面如图3-1。

在发文管理中，定义了以下节点：登记编号、分送、归档、核稿、会签、拟稿、签发、清稿、审批、文章、校对、用印、阅办，另外用户可以根据实际工作需要另外定义其它节点。

功能菜单如下：新建、打开、保存、打印、查询等。

在收文管理中，定义了以下节点：承办、登记、分送、归档、拟办、批办。

由于收文管理主要处理的公文来自于集团，这些文档经过收文的一套处理流程，到达各部门基本上仅仅需要部门领导阅览一下，给出批示意见即可。

根据以上分析，设计了FWGL.nsf和SWGL.nsf两个数据库。

由于两个数据库的设计类似，所以只重点阐述FWGL.nsf的设计实现。

3.1 数据库设计创建数据库FWGL.nsf，数据库的重要属性如图3-2所示。

首先生成数据库中的文档，然后用户通过可视化界面对文档选择，组织设计好的视图，最后将整个数据库的内容显示出来。

3.2 表单设计表单是数据库设计的基本元素，也就是用户在前台操作的直接界面。

在FWGL.nsf 中，最重要的表单为报告表单（别名BG ）。

做为公文管理的一部分，该表单就是一个发起模板。

操作人员通过该表单启动，起草公文初稿，然后通过公文流转，形成正式的公文。

该表单的设计示意图如图3-3和图3-4所示。

在完成该表单上述功能设计时，涉及到两个关键问题：(1)办公人员按岗位角色不同，权限划分不同，操作不同。

该问题的解决是通过隐藏文档的操作按钮来实现的。

文档的操作按钮根据不同的角色和状态进行隐藏，有权限的人员就可以看到按钮，没权限的人就看不到，从而完成公文操作。

下面通过具体实例来进行详细阐述。

“董事长签发”操作的隐藏公式如下：!(Status="办公室主任"&(QCBM!="办公图3-1 系统主界面图3-2 发文管理数据库属性室主任"&QCBM!="董事长"&QCBM!="办公室"&QCBM!="董事长")。

该公式完成的功能是：如果当前文档的操作人是“办公室主任”而且签发部门不是董事长，且签发标志域QF为空值；以上的条件全不成立，则“董事长签发”操作被隐藏。

这样就保证了对不同人员的操作权限的控制。

另外BG表单中的“分管领导审核”、“总经理审批”、“会签”、“董事长签发”等操作也都用公式隐藏的方法对使用人员的权限进行了限制，这里就不一一介绍了。

(2) 公文流转中，同一时点节点操作权限唯一性，避免两个人同时对文档进行操作。

解决该问题是通过在BG表单的Globals选项中定义的一些全局变量、引用单元、一些公用的函数来实现的。

重点代码如下：•Options。

Option PublicUse "Aha" //其中“Aha”是表单（BG）资源中所编写好的Script库•Declarations。

Dim AllowEdit As IntegerDim AllowChange As Integer //定义了是否允许修改的全局变量标志•InitializeSub InitializeAllowChange=0 //给全局变量AllowChange赋初值0End Sub•OutOfEditSub OutOfEditAllowEdit = FalseEnd Sub•MyGotoEditSub MyGotoEdit //该函数主要是将文档置于编辑状态AllowEdit = TrueUidoc.EditMode = True //将文档置于编辑模式End Sub除此之外，还有相应的PostOpen，QueryModeChange，QuerySave，QueryClose等事件，实现对文档的控制以及具体的功能，保证系统的安全性和可操作性，具体就不一一例举了。

以上所述的BG表单是发文管理数据库中最重要的表单，提供了几乎所有对文档的操作。

另外数据库中还设计了“填写意见”、“拟稿纸”、“引入文档”等表单，这里就不再叙述了。

图3-3 BG表单第一部分图3-4 BG表单第二部分3.3 视图设计在发文管理数据库中视图的主要作用是根据公文的不同状态，对公文进行归类，从而方便用户在使用过程中的一些工作习惯，主要设计的视图如图3-5所示。