基于工作流的业务流程管理系统的研究与实现

第一篇：基于工作流的业务流程管理系统的研究与实现

基于工作流的业务流程管理系统的研究与实现

2009-10-14 13:06:57.0 机经网

北京机械工业自动化研究所 研发部 毛宏毅

在20世纪90年代以来的经济浪潮中，MIS(信息系统)与ERP（企业资源计划）成为企业管理的热点。但是，MIS/ERP的开发方式的缺点在于对需求表达不清晰、效率不高。在这种思维方式下的流程管理与真正的企业流程管理成了“两张皮”：ERP仅仅是IT领域一个不重要的支系，而非作为一种驱动力。更严重的是流程被固化在系统中，企业不能随着商业环境的变化而方便迅速的改变自身的业务流程。如何实现业务流程的自动化，使得各自相对独立业务实现无缝集成，如何保持商业伙伴之间的协同，并建立一种灵活的机制已经成为企业的首要问题。

BPM的出现，改变了这种IT思维方法。它希望在现有的MIS/ERP系统开发中表达商业需求，对根植在应用系统中的流程做出清晰的定义。为实现BPM，管理系统必须能够提供方便迅速分析业务流程、商业数据的工具，以便企业决定使用最适合流程引导商业目的的实现。

本文研究了业务流程管理理论，分析了业务流程管理与工作流管理的异同，并在此基础上，基于改进的工作流管理，实现了业务流程管理系统。

1、业务流程管理理论研究（1）业务流程管理概念

什么是业务流程管理？ BPM是一个描述一组服务和工具的一般名词，这些服务和工具为流程管理(如流程的分析、定义、执行、监视和管理)提供支持。它将生产流程、业务流程、各类行政申请流程、财务审批流程、人事处理流程、质量控制及客服流程等70%以上需要两人以上协作实施的任务全部或部分由计算机处理，并使其简单化、自动化。

从管理理论或战略的层面看，业务流程管理（BPM）就是在一个存在内部事件和外部事件的环境中，由一组相互依赖的业务流程出发，对业务进行描述、理解、表示、组织和维护。从具体实施的层面看，BPM还可分为流程分析、流程定义与重定义、资源分配、时间安排、流程管理、流程质量与效率测评、流程优化等。

从上图可以看出：在流程设计阶段，业务流程被定义或者是重新定义；系统在配置阶段，定义的流程在基于流程的信息系统中实施；在流程运行实施阶段，业务流程开始利用在配置阶段的内容开始实施；在诊断阶段，系统开始分析业务流程以发现其中的问题和需要改进的地方，在流程设计阶段重新定义，往返循环不断的优化业务流程。（2）工作流管理概念

20世纪60到70年代就有学者清楚的表达了利用信息技术实现工作流程自动化的想法，但是，工作流的真正成熟还是以1993年工作流技术标准化的工业组织WFMC（工作流管理联盟）的成立为标志的。工作流管理联盟成立以后，发布了用于工作流管理系统之间互操作的工作流参考模型，并相继制定了一系列工业标准。使得工作流系统的研究与开发进入了一个新的热潮。

工作流就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。工作流要解决的主要问题是：为实现某个业务目标，在多个参与者之间，利用计算机，按某种预定规则自动传递文档、信息或者任务。简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。我们可以将整个业务过程看作是一条河，其中流过的河水就是工作流。（3）WFM与BPM的区别与联系

事实上，WFM和BPM之间没有严格的概念界限区分。如果说WFM是早期人们为了解决“办公、流程自动化”而诞生的应用技术和解决方案的话；那么BPM则是为了“对全局性的业务分析、整合”，以及“能够基于这些分析提供对上层管理决策的支持”的一种应用技术和解决方案。与业务流程管理相比，传统的工作流管理的重点仅仅存在于BPM的下半部分，即流程设计、系统配置、流程运行三个部分。此外，传统的工作流管理对于设计阶段的支持很少，仅仅提供了一个编辑器，而对实时的设计分析没有支持。因此，传统的工作流管理系统软件中，几乎都无法支持流程设计的仿真，验证，确认以及对实时数据的收集、解释。从理论上说，可以从工作流日志中可以挖掘业务流程，然而能够真正做到这一点的很少。

2、基于工作流管理的业务流程管理系统的实现（1）系统架构

业务流程的定义使用C/S模式。C/S充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。在流程定义阶段，用户只需定义组织结构，流程和表单就能够完成流程的设计。

业务流程的运行为B/S模式，软件系统设计遵循目前国际上流行的B/S三层结构系统模型，即整个系统分为客户层、业务逻辑层和数据层。

这种模型具有软件发布更为灵活、程序开发更为高效、重负载下性能更好、系统安全性更强等优点。（2）系统实现

本系统采用J2EE平台结合Oracle数据库架构，流程页面主要有两种。

一、表单页

表单页的流程是根据企业的实际情况制定的，流程表单也是根据实际情况进行后台表的设计和前台界面的绘制，这也是工作流的基本使用。

二、接口页

接口页，顾名思义，就是对于已有的B/S模式的页面提供接口，使页面在工作流系统中流转。它成功解决了企业已有的ERP等信息系统流程固化无法进行流程优化的问题。使用接口页真正实现了业务的随需应变，可以随意的对于B/S模式的下信息管理系统进行流程的按需设计按需管理。

例如采购订单审批流程从两级审批变为一级审批，但是原有流程固化在ERP系统中，我们可以使用接口页方便的改变现有流程。

在整个定义中，工作流系统通过适配器提供工作流和业务数据进行数据交换的功能，根据业务数据进行流程的分支判断，实现业务流程的随需应变。

三、流程诊断

使用工作流系统的“已办流程”和“管理流程”两个功能，获得工作流系统的流程运行数据，对工作流系统的中正在运行的和已经运行完毕的流程进行管理和分析，发现系统中流程存在的问题和需要改进的地方，修改流程后重新发布，在发布之后发起的流程则按照新版本流程进行流转，这就实现了类似业务流程管理生命周期中的诊断功能。

第二篇：工作流技术论文：高校分布式协同办公系统研究与实现

工作流技术论文：高校分布式协同办公系统研究与实现

【中文摘要】分布式协同办公系统是一种基于先进的网络互连基础上的分布式软件系统,它通过有效的资源共享和信息交流与发布,其是提高个人工作效率、缩减劳动强度,以及减少重复的劳动。它重点强调人好人和人之间、部门和部门之间、企业之间的协同工作,及相互之间进行有效的交流和沟通。时至今日,分布式协同办公系统已经逐渐发展成为一门比较成熟的综合学科,其中涉及了诸多领域的学科内容,它正成为现代计算机应用的一个极其活跃的领域。本系统采用了“一校各地”的分布式异地协同的办公方式。总体上的框架是B/S(浏览器/服务器)结构,基于Domino Notes群件技术,综合ASP.NET、XML进行开发。系统运行的服务器平台是Windows 2003 Server,软件平台是IBM Lotus Domino/Notes 8.0,数据库存储管理平台是Lotus Notes数据库。本文对分布式协同办公自动化系统设计与实现进行了详细讨论,并对工作流相关技术做了深入的研究,同时也给出了系统部署、实施和项目管理等相关内容的说明。本文研究与设计的办公自动化系统在建成后将能够满足天津广播电视大学的学校教职员工的办公需求,针对学校“一校各地”的工作模式特点,加强了总校与各地分校之间、教职员工同部门之间、部门同部门之间的协作与沟通,并同时实现了将散落在个人和部门的信息进行集中的管理,有效利用。这不仅替代了原有的人工业务协作模式,提高了教职员工的工作效率,降低了劳动强度,而且,更加使得天津广播电视大学在教

育体制改革与发展的浪潮中进一步增强了自身的竞争力。

【英文摘要】Distributed collaborative office system is the use of effective resources sharing and information exchange, release, improve personal work efficiency and narrow labor intensity, the decrease of the repeated labor purpose is based on an advanced network interconnection based on distributed software systems.It emphasizes man and the good people, between departments and divisions between, between enterprise’s work together, and each other for effective communication.It is a science is developing comprehensive discipline involved in many areas of disciplines, is now a computer application of an extremely active field.This thesis of office automation system is in order to adapt to the tianjin radio and television university is “a school around” office demand to specifically for the design and development of a set of comprehensive coordination office system.The system through provide powerful communication platform, workflow automation, document database and information exchange and internal resources sharing, by function, strengthen total school mass with the regional branch, between staff with between departments, departments with cooperation and communication between departments, will be scattered in the personal and

department for centralized management information, effective use, at the same time to improve the work efficiency and reduce labor.This system uses a “one university of distributed collaborative around” office way.The overall frame is B/S(browser/server)structure, based on the Domino Notes of groupware, comprehensive asp.net, XML development.Of the system operation Server platform is Windows 2000 Server, software platform is IBM Lotus Domino/Notes 6.5, data inventory store management platform is Lotus Notes database.【关键词】工作流技术 办公自动化 协同工作平台

【英文关键词】Workflow technology Office automation Collaborative working platform 【目录】高校分布式协同办公系统研究与实现4-5Abstract5

第一章 绪论9-14

摘要1.1 课题研究的背景和意义9-10状10-1210-12结构13-14

1.2 国内外对办公自动化系统研究的现

1.2.2 国内研究现状

1.4 本文组织

2.1 工作流

2.1.2 2.2.1 2.2.3 工2.4 工作1.2.1 国外研究现状101.3 本课题主要研究工作

12-13

第二章 工作流技术介绍14-24

2.1.1 工作流的各种定义15

2.2 模型16-22技术的概念14-16工作流管理系统的定义15-16工作流元模型16-17作流接口类型18-22

2.2.2 过程建模17-182.3 工作流管理系统22

流系统中的业务过程描述及其分析22-2323-2424-2529-3029-303030-31设目标31计31-32第三章 系统需求分析24-313.2 系统功能需求25-293.3.1 性能需求293.4 系统实施需求303.4.2 运行环境约束30

2.5 本章小结3.1 系统业务需求3.3 系统非功能需求

3.3.2 质量需求3.4.1 开发环境约束3.5 本章小结

4.1 系统建第四章 办公自动化系统设计31-534.2 系统设计原则31

4.3 系统网络架构设

4.4.1 办4.4 分布式工作流模型设计32-35公自动化OA 系统工作流程32-33型规划与设计33-34总体架构设计35-36系统逻辑结构36系统界面设计38-4338-3939-434344-45

4.4.2 分布式工作流系统模

4.5 4.5.2 4.7

4.4.3 工作流流程设计34-354.5.1 系统技术架构35-364.6 建立系统的体系结构36-384.7.1 系统界面设计原则

4.7.3 个人办公界面4.7.2 界面划分394.7.4 子系统专用界面434.9 数据库设计43-50

4.8 系统安全性设计

4.9.1 主要E-R 图

4.10 数据集成接第五章 办公系统

5.2 系5.2.2 4.9.2 系统主要数据表45-50

4.11 本章小结51-53口设计50-51的实现与测试53-80统功能实现54-72系统主要模块的实现

5.1 系统实现环境53-545.2.1 系统主要界面54-6161-72

5.3 ASP.NET 安全机制实现

72-7575-7878-7980-825.4 系统测试75-795.4.2 系统性能测试785.5 本章小结79-806.1 系统开发总结805.4.1 系统功能性测试

5.4.3 系统测试总结第六章 结论与展望6.2 前景展望80-82致谢

82-83

参考文献

83-86

第三篇：CRM论文：基于CRM的高校学生管理系统研究与实现

CRM论文：基于CRM的高校学生管理系统研究与实现

【中文摘要】随着高等教育的发展,高校在校学生群体不断壮大,相关的数据量越来越庞大,提供和使用学生数据信息的部门和用户群体越来越多,传统的学生管理方法已经明显无法适应现今的管理需求,利用基于网络的管理信息系统(MIS)对学生管理进行系统整合已成为必然趋势。随着高校管理体制的改革与发展,面向学生的管理理念逐步向服务理念靠拢,越来越多的CRM(客户关系管理)思想已经应用于学生管理实际工作当中,如“以客户为中心”,“注重客户满意度与忠诚度”,“延长客户生命周期”,“充分利用客户信息进行数据分析与数据挖掘”等。而现行的学生管理系统大部分还只有纯粹的“管理”功能,急需新的理念融入其中。因此许多高校需要建立一套与原有学生管理系统不同的,基于客户服务理念的拥有统一网络平台的学生管理系统。该系统的建立,可以提升高校学生管理的水平,适应学生管理工作改革的各项要求,同时也符合高校建立信息化、数字化校园的发展方向。文章对高校学生管理系统做了基础调研后,综合分析,对实现基于CRM的学生管理系统进行了需求分析,技术可行性分析。在这些前期工作的基础上,进行的系统的网络结构设计、逻辑结构设计、详细结构设计、以及数据库结构设计等。在系统的实现部分,我们有针对性的选择学生基本信息管理、选课信息管理、以及学生成绩管理模块作为实现对象,融入CRM思想,让系统能够实现学生与管理人员互动沟通,在相应的模块进行数据挖掘、分析教学成果对学生实施个性

化教学等。在系统实现的基础上我们在windows环境下进行了系统的功能测试、压力测试、安全测试等,对系统的实现进行了评价,初步达到了预期。高校学生管理系统融入CRM思想是一个较新的研究领域,还有很多需要做的工作,由于时间仓促,限于个人能力,系统还有很多不完善的地方,需要进一步研究。

【英文摘要】With the development of higher education, college students’population has grown increasingly in the school.And students of the relevant data quantity become large, department provide and use student information which becomes more and more.The traditional student management method has obvious can’t adapt to today’s management requirements;Use of web-based management information system(MIS)to integrate student management system has become an inevitable trend.As college management system reform and development, facing the student management idea gradually moving to service concept, more and more CRM(customer relationship management)thought has been used in the student management practical work.Such as “take the customer as the center”, “pay attention to customer satisfaction and loyalty”, “customer lifecycle extension”, and “make full use of customer information data analysis and data mining” etc.The majority of the existing student management system has only a pure “management”

function, need new ideas into one.Therefore, many colleges and universities need to establish a difference with the existing student management system, based on the concept of customer service for students with a unified network platform management system.The set up of this system, can promote the college student management level, adapt the student management work requirements of reform, also with the establishment of the informationized, digital campus development direction.The paper has analyzed university student management system of basic research, to achieve the comprehensive analysis, the student management system based on CRM the requirement analysis, technical feasibility analysis.?In the previous work, based on the network structure of the system design, logic design, detailed design, and database structure design.?Implementation part of the system, we have targeted to select basic information management of the students, information management elective, and student performance management module as to achieve the object, Thinking into the CRM so that the system can achieve interactive communication with management and students, in the appropriate module for data mining, analysis of the results of teaching, and then to implement individualized teaching for students.Based on system

realization, we in Windows environment the system function test, pressure testing, safety testing, the system implementation evaluation, preliminary reach the expected purpose.? Student Management system into the CRM idea is a relatively new area of research, there are a lot of work needs to be done, due to time constraints, limited personal ability, there are many inadequacies in the system, needs further study.【关键词】CRM 学生管理系统 ASP.NET 【英文关键词】CRM student management system ASP.NET 【目录】基于CRM的高校学生管理系统研究与实现4-5ABSTRACT5-6

第一章 绪论12-16

摘要1.1 选题1.3 本文的第二章 研

2.1.1 来源和依据12-13内容和意义13-14

1.2 国内外研究现状131.4 论文结构安排14-16究和开发的关键技术16-29CRM 的概念及理论16-1818-20结构22-23术简介23-24

2.1 CRM 简介16-222.1.2 CRM 的发展历程2.1.3 CRM 的分类20-22

2.3 ASP.NET 技术23-26

2.2 B/S 模式三层体系

2.3.1 ASP.NET 技

2.4 第三章 系统

3.2

2.3.2 ASP.NET 的优点24-26

2.5 本章小结28-29ADO.NET 技术26-28的分析和设计29-48系统安全性分析30-31

3.1 系统可行性分析29-303.3 系统的总体设计

31-373.3.1 系统网络架构31-323.3.2 系统功能模

3.4.1 数据块设计32-373.4 系统的详细设计37-47库概念设计E-R 图37-3939-4147-4848-50信息50-52

3.4.2 数据库逻辑表结构设计

3.5 本章小结4.1 系统登录4.2.1 添加学生

4.2.3 查4.3.1 修4.4.1 录4.5 功4.7 数据挖第五章 系统的测5.1.1 系统测5.1.3 系统测试

5.3 3.4.3 程序流程图设计41-47第四章 系统的具体实现48-684.2 学生基本信息管理50-56

4.2.2 显示所有学生信息52-54

4.3 课程信息管理56-574.4 学生成绩管理57-604.4.2 学生成绩统计58-604.6 组权限管理61-634.8 本章小结67-685.1 系统的测试68-70询学生信息54-56改课程信息56-57入学生成绩57-58能模块管理60-61掘的实现63-67试和评价68-71试环境685.1.2 系统测试方法68-69方案的设计69-70本章小结70-71总结71文献73-75

5.2 系统的测试结果及评价70第六章 结束语71-72

6.1 论文的工作

参考6.2 问题与展望71-72致谢72-73

攻硕期间取得的研究成果75-76

第四篇：如何基于工作流,实现OA-ERP集成

如何基于工作流，实现OA-ERP集成

2002-10-30 13:15

郭应中、吴科/(AMT)

引言

ERP系统是对企业能够提供业务数据支持的信息系统，OA系统是实现公文收发、流转、签发、归档等群组化办公作业自动化的信息系统。两者都是为实现单一目标而运行的信息系统。

在企业的业务活动中，经常有些业务是贯穿ERP和OA两个系统的。比如采购流程：采购申请生成、采购定单生成、验收单生成是在ERP系统进行；采购单申批、入库准备单流转在OA系统进行。企业中存在对OA和ERP两个系统集成的需求。另外，ERP系统和OA系统实施的难度差别造成一个时期内系统覆盖范围不同，将两个系统集成，ERP的实施效果可以事半功倍。

将两个系统集成，涉及到组织、角色、任务和过程的定义和管理。通过工作流系统进行集成，不但可以把两个系统中的多个模型统一，还可以使企业专注于应用业务，更方便地进行企业流程重组（BPR）。

对ERP和OA两个系统的集成，主要的工作有集成方案的确定、系统集成功能范围的确定、工作流系统的创建或改造、组织模型的统一等。

集成方案的确定

实现OA和ERP系统的集成，通常的实现方案有以下三种：

1、更换原有的ERP系统，选择能够同时提供OA和ERP解决方案的供应商。

同时提供OA和ERP解决方案的供应商，其产品在设计阶段就考虑到了两个系统的集成。但是目前这样的方案往往是供应商出于市场份额的考虑而提供的，由于开发规模、成本和周期的限制，所提供的ERP－OA一体化方案的功能往往比较简单，不能满足企业个性化的需求。而且，ERP系统在企业内运行一段时间后，更换新的系统，会面临新旧系统间数据移植的巨大工作量、用户不愿意舍弃熟悉的界面和高昂的费用等困难。所以这个方案只能被未实施ERP系统企业中的少部分企业使用；

2、使用ERP供应商的合作伙伴提供的集成方案。

例如Lotus Notes为SAP、Oracle、JDE等公司的ERP产品都提供了集成化的解决方案。其方法是：在OA Server和ERP Server之间通过数据库连接工具DECS连接。在ERP 系统的DB 建立大量视图供OA访问，在OA Server上建立关系型数据库，存储定期从ERP系统中按照字段映射过来的静态数据，作为OA系统组织和资源定义的依据。OA系统中的表单鉴审后可以通过ERP系统的Interface table写入ERP系统。

这种方案可以两个系统的高度集成，但是存在以下问题：

（1）不是所有的ERP系统都有相应的集成方案提供。Lotus Notes仅对大型而且著名的ERP产品提供了这样的集成方案；

（2）这个方案的实现和维护费用非常高。如果在新增流程，需要在ERP系统中新增视图，在OA系统中新增表单。对于大型的ERP系统，其数据库中的table有近万个，加上在OA中创建表单，都是企业IT人员无法独立完成的，仍需要方案提供者的服务。即使是方案的提供者，在使用这种工具完成两个应用系统结合 时，也必须同时对两个系统了如指掌。然而，不论在国内和国外，同时能够深层次了解两个系统的技术人员极为紧缺，加上高昂的购买费用，企业很难接受；

（3）ERP实施模块增加，特别是ERP系统的升级，都会造成集成化系统的瘫痪，限制了企业的业务发展。

因此，此方案的应用仍然比较少。

3、通过工作流系统，实现工作流程在两个平台上切换。

在工作流系统的管理下，用户通过远程登录工具和模拟键盘录入，实现OA平台和ERP平台之间的简单切换。系统架构图如下：

图1集成后的系统架构

对应上图的每个步骤说明如下：

1.用户登录OA系统后，Workflow Server根据OA系统中人员配置管理功能确认其身份，此用户同时得到了相应的权限；

2.身份确认后，Workflow Server再根据此用户在其权限内申请的工作流程提供工作流表单，并在表单上显示用户对应的组织结构的层次度；

3.用户在工作流表单上填写本流程执行需要的数据，这些数据可能是请假天数、请假原因等不涉及ERP系统的数据，也可能是访问ERP系统的参数。如果在流程执行时仅仅需要在ERP系统中执行查询，工作流表单的填写要在访问ERP系统后进行。

4.当工作流程执行到ERP系统上的作业时，工作流系统自动引导用户进入ERP系统。通过OA系统本身的Script语言结合Terminal simulator script语言编写的访问ERP系统的任务项，根据执行的流程类型、顺序、工作流表单参数，用户可以直接进入ERP系统相应的功能模块。

5.用户操作ERP系统。可以根据权限执行不同的操作。以采购申请为例，用户可以填写需要采购的物料编号、采购数量、价格范围、供应商等，存储后保存在ERP DB中；

6.ERP DB保存后，通过ERP系统界面向用户提示保存成功；

7.ERP系统将保存成功的单据编号和单据状态等信息传送到工作流系统。根据需要，用户可以把ERP系统生成的表单导出为Excel文件保存在本地；

8.当工作流系统收到ERP系统传来的信息后，进行格式检查，确认无误后继续执行；

9.用户在屏幕上审查工作流系统执行情况是否正确，确认无误后，将工作流表单传送到Workflow Server，保存在本地的Excel文件也可以作为附件提交；

10.Workflow Server收到用户传来的工作流表单，并据此将工作流表单和附件传送到下一个执行者。

同前面两种方案比较，这种方案的适应性非常强，开发量、开放难度和费用都比较低。因此为本文采用。

系统集成功能范围的确定

如果把企业内所有的流程都通过工作流系统在OA和ERP系统中实现，不仅没有必要，而且有些流程是不适合在信息系统中实现的。因此，需要对系统集成的功能范围进行确定。

企业内部流程是由一个个动作组成的，根据动作发生的频率和流程特点，可以分为以下三个类别：

A类：发生频率高而且执行简单。如各种申请的上呈、核签、否决、查询；

B类：发生频率一般，执行方法复杂而且经常发生变化。如会签，往往人数不定，层次不定，后续动作不定；

C；类：发生频率特别低，或者其所在流程不具备管理意义。如卫生值日流程中的所有动作；

为使集成工作简单而有效，系统集成的功能应集中在由A类动作组成流程的范围内。在集成工作前阶段，工作流系统中计划实现的流程中，需要OA和ERP两个系统共同完成的流程有：

1．物料信息维护。当物料新增或停用时，经过层层签字，在ERP系统中做相应处理；

2．采购流程。采购申请、审核、采购申请汇总、分单验收、入库流程；

3．付款流程。付款申请、发票校验、审核、通知付款、付款登记；

4．报销流程。单据填写、网上审核、票据检查、登记入帐；

工作流系统的改造或重构

按照工作流管理联盟的定义，工作流是一类能够完全或部分自动执行的经营过程，将文档、信息和任务在不同的执行者之间传递、执行。

传统的工作流系统中，每一个业务流程都要根据企业内的业务流程完整构建出来的。这样每一个业务流程都有大量的代码来实现，流程的创建和维护工作量很大。

仔细分析企业内的众多业务流程中，相当部分的流程是有共同部分的，每个流程中都有功能重复的代码。动态工作流把完整的工作流分解为若干个活动（Task）（对象），使工作流建模工作得以简化，可以实现更复杂的工作流系统。

活动是动态工作流的一个重要概念：工作流是一组有关联关系的活动的集合。一个活动与其它活动之间有顺序，分支，循环，调用的关系，还有并行、有同步的关系。

按照动态工作流的概念，一个完整的工作流程被分解为若干个活动（Task）和活动间的逻辑控制器。每个活动不和其它活动作任何直接交互，交互完全在逻辑控制器间进行。如图2所示：

图2动态工作流系统结构

每个活动都有进入条件，工作条件，中断条件，完成条件，暂停条件及继续条件。执行时，判断每个工作项是否可以进入，可以则进行进入处理，然后，判断需要是否中断或暂停。活动的结构图如图3：

图3活动的内部结构

图3中，一个活动有不同的状态集、输入集、输出集。状态集包括等待、执行和完成。输入集和输出集分别由若干个输入和输出组成。输入来源可以是本活动的输出，也可以是其它活动的输入或输出或状态。当输入集中某项输入状态发生改变时，将触发工作项的状态发生改变。达到完成状态时，将产生输出集。输入不同，触发的执行过程和产生的输出集不同。当多个输入集同时被激活时，按优先级执行。

工作流系统的动作和逻辑控制器采用Java Bean和关系型数据库实现，可以设计为可视的图形元件，也可以设计为不可视的逻辑处理元件。这样做的好处是把工作流系统的各个活动做成代码行数小、功能明确的黑盒子，实现动态的工作流系统，并在多环境下运行。

OA系统和ERP系统都可能自带工作流功能。但ERP系统的工作流功能缺乏开放性和适应性，并且ERP系统开发商不允许对其进行修改，因此其工作流功能的存在在集成中实际上是一个障碍。完成系统集成后，ERP的部分功能会由系统管理员设定为只能通过远程登录的方式访问，这是要对ERP系统原有的工作流系统做重新的设置，以免系统运行出错。

OA的工作流功能，如果不能实现动态工作流机制，是无法满足集成的需要的。这时要对其工作流功能进行重构。如果已经实现了动态工作流机制，也要增加一些访问ERP系统的功能动作。

如果选择其它的工作流系统支持集成工作，虽然理论上可行，但是开发量未必减少，系统复杂度、维护量和费用必然上升，所以本文建议采用对原有的OA系统的工作流功能进行改造，实现企业的工作流系统。

组织模型的统一

OA系统和ERP系统都有各自的组织模型。OA的组织模型是服务于企业行政组织层面的，ERP的组织模型则是服务于企业业务层面的。在用工作流系统对两个系统集成时，要对两个系统的组织模型进行统一。在本方案中，就是要对OA系统的组织模型重新定义。

ERP系统的组织模型比OA系统要复杂，不同的ERP系统有不同的组织模型。以Oracle Application为例，其组织模型为：账簿集－法律实体－操作单元－库存组织，再往下是更细致的划分，可以做到用户－角色－所属组织－权限的一一对应，权限的设置可以明确到字段。

对OA系统的组织模型的重定义，主要是增加OA系统组织结构的层次数量，建立新组织结构数据库，把ERP用户和OA用户都在新的组织结构中反映出来。注意OA系统中的用户名要和ERP系统中的用户名统一，因为在ERP系统中用户名和角色、权限是对应的。但口令不能统一，登录ERP系统时，系统仍然会提示用户输入ERP系统的口令。

连接方法

本文中，Workflow Server是使用Lotus Notes Server＋Linux Red Had ver7.1系统，而在ERP系统上本文所采用的是HP/Unix＋鼎新Tip-top ERP系统＋HP9000，Client端则采用一般的Windows环境＋Lotus Notes客户端软件。

两个服务器通过TCP/IP协议连接。在Workflow Server上安装InterSoft公司编制的共享软件NetTerm 4.3.0简体中文版，可以在10个以上的操作系统上运行，对远程主机环境具有良好的设置能力。

NetTerm的作用是相应客户端发出的登录ERP Server的要求，所以连接型态选TCP/IP，端口填“23”，模拟型态和键盘定义都选VT100(上述设置适用于国内多数主机)，主机名称和地址填入ERP Server对应的地址和内容。

例如当用户需要访问ERP的采购申请功能时，工作流系统中访问ERP系统采购申请功能的活动中包含以下语句（用Terminal simulator script语言编写）：

expect 10”login:”

#username “Enter UserID”

#output “^U^M”

expect 10”Password:”

#password”Enter Password”

#output”^P^M”

output”12345^M”//工作流系统提示用户输入口令后生成该行

expect 10”/”

output”exe apmt420^M”

output “a”

流程执行完这段程序时，就自动打开了ERP系统的相应功能。在用户填写完采购申请单后，ERP系统数据库中的保存操作触发事件为：以XML的格式，把采购申请单编号、创建实际、创建人等信息传送到用户本地，并被用户本地服务响应，填写到工作流表单。用户可以执行修改功能再次访问ERP系统修改采购申请单。在用户确认无误后提交，下一个申批人接到提示申批的电子邮件，点击邮件中的连接，出现反映采购流程执行情况的流程表单。依次类推。

应用情况

在实际应用上，根据用户需求定义了采购流程、付款流程、报销流程等，并在ERP系统中开放部分数据访问和维护权限给Internet上自己的外地分子公司和上游客户，解决了ERP刚实施完本部，外地分子公司采购流程无法并入集团供应部采购流程的问题，使用户提前实现了集中采购的战略构想。目前，该用户的上游近600家企业中，已经有60家提供大宗原材料的供应商使用这些流程，集中采购和比价采购使该企业在每年10多亿的采购额中节约了大约1.5％的采购成本，给企业带来了良好的经济效益。

第五篇：工作流与K2 BPM的实现

1.结构化过程

这两个模式的共同点在于：模式所涉及流程的执行路径是由运行时决定的，而非设计时确定。包括：Arbitrary cycles（强制循环模式）、Implicit termination（隐式终止模式）。 11 任意循环（Arbitrary Cycles）

 描述：

工作流中的一个点可以让一个或多个活动反复的执行。

 案例：

“修改提交”后进入“经理审批”，但未通过，又回到“修改提交”。

 K2实现：

 12 隐式终止（Implicit Termination）

 描述：

在一个流程中，如果没有活动可执行了那么流程就会终止。换句话说，在工作流中没有active 状态的活动了，而且也没有活动会被激活，这就是隐式终止。（前提：工作流不能处于死锁状态）。

有的工作流引擎不支持。 案例：

“主管审批”通过后进入“经理审批”，未通过则无下一个活动。 K2实现：

如果“主管审批”的输入为“不同意”，流程将终止。

一般都会采用显示终止，因为隐式终止可能会引起不被察觉的错误，例如意外的输入可能导致流程的结束。

 多实例过程

“多实例”是指在流程图中，一个活动在同一时刻拥有多个可运行的、处于活动状态的实例。

 13 非同步的多实例（Multiple Instances Without Synchronization）

 描述：

在流程中，一个活动可以激活多个实例，也就是说可以把一个活动分发成几个控制线程。每个控制线程之间都是相互独立的，并不需要同步它们。

 案例：在网上订购书籍，以书为单位，每一本都会独立产生一个购书实例，并且每个实例之间不需要同步数据。 K2实现：

IPC Event调用方式需要选择为Asynchronous。

 14 在设计期间预先确定的多实例（Multiple Instances With a Priori Design Time Knowledge）

 描述：

一个活动可以激活多次产生多个实例。而产生的实例的个数在流程设计时就事先知道了。一旦所有的实例都执行完成，就会激活其他活动。 案例：

有关某些特定资源的请求需要完成固定几个不同的审核流程。 K2实现

主流程结构为模式2平行拆分 + 模式3同步，IPC Event中调用方式需要选择为Synchronous。

 15 在运行期预先确定的多实例（Multiple Instances With a Priori Runtime Knowledge）

 描述：

一个活动可以激活多次产生多个实例。而产生的实例的个数是变化的，取决于实例的特点或者可用资源数目，但是在流程执行过程的某个时期，在这个活动的实例产生以前，要产生的实例个数是能确定的。所有的实例都运行完成后，激活后续活动。 案例：

处理一个订单，订单中有多本书，要分别检查每一本都有库存，所有的书都检查完成后才开始进入送货。 K2实现：

主要结构为模式6多路选择 + 模式7同步合并，IPC Event中调用方式需要选择为Synchronous。

 16 无法在运行期预先确定的多实例（Multiple Instances With a Priori Runtime Knowledge）

 描述：

在一个活动能够被多次激活的这种情况下，在指定情况下的指定活动的实例数量无论是在设计时或者运行时都不能在活动的实例被创建之前预先确定。但是，在活动被创建之前，在运行中的某个阶段，这个数量是可以预知的。一旦所有的实例都完成了，其它的活动应该被启动。这个模式和模式14的区别在于，在某些实例运行结束之后，新的实例仍能被创建。 案例：

订购100 台电脑，涉及多个供应商，但是每个供应商供应多少台电脑是不知道的，因此供应商的数量事先也不确定。但是当每次供应商送货后，就会将现在所拥有的电脑数量和所需的100 台进行比较，来决定是否要下一个供应商继续送货。 K2实现：

比较复杂，可以利用模式11任意循环实现。

 基于状态的模式

这三个模式的共同点是：模式所涉及根据当前运行的流程状态来改变流程里的执行路径，包括：Deferred choice（延迟选择模式）、Interleaved parallel routing（交替平行路由模式）、Milestone（里程碑模式）。

 17 延迟选择（Deferred Choice）

 描述：

工作流中的一个点，有一个或多个分支已经被选择。与XOR拆分相比，并没有明确的选择，但是，选择是取决于环境的。与AND拆分相比，两者中只有一个被执行。这意味着一旦环境启动了其中的一个，另一个就被取消。要注意，选择是被延迟到两个分支中的一个真正开始执行时，也就是说，选择是可以尽可能的推后的。 案例：

在收到货物之后，可选择两种方法将其送到。选择取决于相关资源的可用性。如果资源均不可用，选择会被推迟到直到其中一个资源可用为止。 K2实现：

“监听资源状况”的Destination Rules是一个Robot帐号，只实现监听作用。

 18 交替平行路由（Interleaved Parallel Routing）

 描述：

一组活动以任意的顺序执行，每个活动都被执行，他们的顺序是在运行时决定的，并且在任意一个时刻都不会有两个活动在执行。 案例：

体检流程中的活动有各种常规检查和血液检查，哪个在先哪个在后都可以，但是不可能同时检查。 K2实现：

K2并无直接实现方法，需要编码，变通解决。

 19 里程碑（Milestone）

 描述：

一个活动能否执行取决于一个指定的状态。也就是说，只有在到达一个特定的未过期的里程碑时，活动才被执行。 案例：

客户在确定交付的前两天是可以取消订单的。 K2实现：

时间上的一些状态可以在Start Rule 和Activity Escalations中实现，其他的复杂逻辑需要编程实现。

 取消模式

这两个模式的共同点在于：模式所涉及的流程在运行时disables一个活动或者整个流程，包括：Cancel activity（活动取消模式）、Cancel case（实例取消模式）。 20 取消活动（Cancel Activity）

 描述：

一个可执行的活动被强制失效了，也就是说，一个正在等待执行的活动所在线程被移除了。 案例：

网上购书时已经下了订单，“支付货款”活动激活，这时如果取消了订单，那么相应的“支付货款”活动也要取消。 K2实现：

利用K2 的API实现。

 21 取消实例（Cancel Case） 描述：

如果一个活动产生了多实例，那么仅仅撤消这个活动是不行的，要将这个活动的所有后代（实例）都移除才行。 案例：

网上购书时如果取消了购书的活动，所有因订单激活的购书流程实例都要取消。 K2实现：

利用K2 的API实现。

 其他扩展模式

21个工作流模式并不能囊括所有情况，还有其他的一些扩展模式，例如：流程启动、回退、转发、通知、代理、催办、回收、任务批处理、任务分组处理、流程合并、子流程等等。