1、 前言：

目前工作流引擎技术是越来越流行了，甚至我们的许多终端客户在对应用系统的选型时都会问到是否包含工作流的问题。事实上工作流的概念已经在软件行业里深入人心，甚至连微软等大型软件企业都开始掺和进来。可是在不同技术平台下的工作流引擎企业的工作流产品却有着千差万别。有产品化的工作流引擎、有带应用架构的工作流引擎、有工作流二次开发平台、有工作流基础框架等，在工作流的二次开发平台里又有自带编译器的，有专用语法分析的，有依托Visual Studio IDE环境及编程语言的等等。

工作流引擎之所以存在并流行，从根本上来考虑，对应用软件开发企业来说是为了简化应用系统开发和维护的工作量，从而提高开发和维护的效率。对最终用户来说是为了一个能适应企业发展变化的应用系统，可以随时响应市场变化的应用系统，同时也降低了对开发商的维护依赖，对终端客户、软件开发商及工作流引擎提供商形成三赢的局面。

目前非常多的公司对于工作流引擎也走过了学习和实验的阶段，并且已经开始利用工作流引擎的技术设计企业的应用系统。然而利用工作流引擎技术设计应用系统的思路和方法是有所区别的。

2、 工作流引擎技术给应用系统设计带来的变化

传统的软件开发过程往往是经过详细的需求调研、制定各种业务用例图、制定各种业务流程图、分析用户角色、分析系统数据的权限范围及控制逻辑、分析正常的功能需求、分析功能异常的处理逻辑、分析及设计数据模型、分析及设计对象关系等等。

一个好的工作流引擎是把原来“已知”的需求当作“未知”、“可能”、“或许”的需求来设计的，对这些“非未知”的需求进行了“泛型”的归纳和抽象，从而利用OO编程思想中的一些设计模式设计出了合理、具扩展性又充分的业务处理接口，利用工作流平台的功能或流程应用架构及开发这些接口的具体实现可以创造出各种与流程处理有关的应用系统，工作流引擎往往也是提供了流程控制台，来设计具体的业务流程。

因此在工作流引擎技术下设计应用系统将与传统的设计思想有所区别，使用工作流引擎技术设计应用系统的变化主要体现在以下几个方面。

• 分析及设计时关注的重点变化

工作流引擎技术下的设计已经不会再把具体的业务流程及业务流程的控制逻辑作为关注重点，以往复杂的控制逻辑交由流程控制台去设计和管理，交由工作流引擎去实现，开发人员只需要核实业务流程及控制逻辑在当前引擎下的可行性、相关信息项的充足性、查询分析的可行性及可用性。

• 开发和维护工作量的变化

绝大部分真正的工作流引擎技术是已经实现了对于各种业务流程的处理逻辑，而这些处理逻辑是开发一个应用系统过程中算法和控制最复杂的，也是维护工作最头痛的，在工作流引擎的技术下，业务流程变更就可以交给控制台来完成，省去了这些工作，开发的工作量是可以大大减少。一些更好的工作流架构甚至提供了非常多的组件、及可重用的业务控件，将开发量降到更小。使软件开发商的成本得到绝对的控制和胸有成竹的把握。

• 对终端用户的变化

好的工作流引擎是体现了管理思想的，在功能的设计上满足企业管理特性的需求，通过管理特性的应用使应用系统达到事倍功半的效果。流程的绩效分析更为用户提供业务流程优化的机会。

3、 E8.Net工作流平台设计应用系统的思路

在E8.Net工作流技术下开发应用系统的设计思路依然有些区别，目前E8.Net工作流平台的用户已经很多，与很多合作伙伴都在这个问题上进行过探讨。现在总结一下。

E8.Net工作流平台是基于微软.Net技术架构下的工作流应用架构，提供应用开发架构、移动应用架构及异步服务架构，软件企业可以在E8.Net工作流平台下开发各种流程管理相关的应用系统。

E8.Net工作流提供的应用开发的源码架构，包含了非常多可重用的用户控件、业务控件、业务组件及母版页等等，虽然提供了源码，但在不改变流程应用最佳实践的情况下，开发是非常简单的一件事情。开发视图如下：

开发人员只需开发流程的表单、跟踪、查询及统计分析即可，至于业务流程是如何，则由企业流程设计人员进行制定即可，定制完成后企业用户就可以体验整体的业务系统了。

有了带源码的架构及这些可重用件，在E8.Net工作流下开发相对简化了不少，由于使用的是主流的数据库技术及visual studio2005开发环境，设计及编码习惯基本上保持与传统开发一致，也不需要额外学习新的开发技能，但因为使用了工作流引擎，工作流引擎已经处理了业务流程的逻辑部分，在设计上需要做的是如何把应用加载上来，在应用设计的思路上还是有所区别，应用设计系统的思路是如何呢？具体从以下几个方面考虑。

• 流程应用的识别

我们调研一个业务系统的需求时，终端用户和软件开发商往往还是按传统的业务术语来描述的，比如运维管理、IT服务管理、物流揽收调度。因此在设计工作流引擎下的应用系统时对系统中的流程应用的识别是关键，也是一个系统设计的开始。

E8.Net工作流引擎处理了流程的业务逻辑，处理的是抽象的逻辑，跟应用的关联是通过关系型数据库来关联，一个应用对应的应该是传统业务用例中的一个用例主体，对应对象模型中的一个主实体。是诸多信息项[属性]的共同载体。也是统计报表、跟踪查询需求中的“根源”。例如在设备运维的系统中，巡检和运行可以是两个应用；合同管理可以是一个流程应用；IT服务系统中，工单和问题管理是不同的流程应用等等。

• 流程控制信息项的设计

流程控制信息项不完全是物理数据库表中的字段，而是逻辑的，设计流程控制信息项主要的出发点是分析和归纳出提交给终端客户或实施人员可能会控制状态或者可能作为条件判断的项。例如：字段里有人工费用、材料费用，但流程应用中可能需要一个总计费用[不在数据库中]，总计费用可能会作为一个条件路径的条件项供终端用户或实施人员使用。再例如在一个邮政代办点审批管理的系统里，数据库里可能有代办点法人资料相关的字段多个，可是流程应用中，只需要一个控制点，就是法人资料。这样通过终端用户或实施人员对流程的定制就可以做到对法人相关资料的统一控制。

这类实际应用的例子非常多，流程控制信息项的设计主要是区分逻辑与物理的关系。

• 视图的识别

E8.Net工作流下视图是对应一个物理的表单的，也asp.net中的一个web form，虽然流程控制台在设计一个流程的时候可以控制到信息项是否可以编辑，是否可见等。但对于整体表单逻辑差异比较大，或功能意图不一致的情况下，需要区分视图的。例如：在建筑项目管理流程应用中，项目预算阶段和执行阶段的视图是完全不同的。

当然绝大部分的流程应用是一个视图足够处理了，复杂的流程应用是可能有多个视图的。

• 业务环节的设计

业务环节的设计在E8.Net工作流下设计系统不是必须的，但对于统计需求比较精细的业务系统来说，是非常必要的，工作流引擎是不知道会加载什么样的应用系统的，因此工作流的统计是基于流程环节的统计，但一些精细的业务统计需求是会根据具体的业务状态或业务环节来统计的，比如：物流企业的应用系统可能就需要统计揽收的数量。这种情况下设计业务环节是必要的，工作流引擎通过业务环节的设计提供了业务系统按照业务逻辑统计的机会。

• 字典信息的设计

字典信息也不是必须的，但工作流中提供了对应的控件及存储，相关的一些字段信息项不必再去设计数据库表和编写存储和展示的代码，减少开发量

• “分类”的设计

“分类”信息也不是必须的，与字典项不同在于分类是有层次结构的基础信息，但工作流中也提供了对应的控件及存储，相关的一些字段信息项不必再去设计数据库表和编写存储和展示的代码，减少开发量。

• 数据库的设计

数据库的设计跟传统的设计基本一样，只是需要在主表中添加字段flowid 与流程信息关联。当然为了提供统计、查询、分析的性能，完全可以在主表或相应的重表中增加冗余信息。技术完全依赖传统的开发经验。

• 工作流应用架构的二次开发需求

当然在不改变流程应用架构最佳实践的前提下，应用架构完全可以不做任何修改。如果需要调整用户的使用习惯，可以对工作流应用架构做二次开发，整个应用架构的源码全部是提供的。基于.Net技术完全可以做到调整后的应用架构。例如：领导需要一次审批通过一个月来所有办公用品采购报销事项，完全可以通过对流程应用架构的源码的二次开发来实现。

传统的开发在设计时也许会考虑更多，在E8.Net工作流下基于以上思路及例子的过滤、整理及归纳后，相信会开发出非常优秀，真正提升企业战略执行力的应用系统。

4、 工作流引擎技术下应用系统的特征

我们为用户开发应用系统的目标是为了解决终端用户的问题，提高效率，创造价值，利用工作流引擎技术设计的应用系统依然需要以这个为目标。在工作流引擎技术下的应用系统特征也会有些变化。业务型工作流和状态型工作流带来的特征也是不同的，业务型工作流的特征体现在：

• 以事项为核心

在终端用户的操作层面上在使用应用系统的时候，往往处理一件事情（称为事件）时会由多个人在不同的时间内参与或处理不同的事（称为事项），工作流引擎技术下的系统往往给用户体验带来的感觉会是，事项是系统人机交互界面的核心，以最方便的方式展示用户待处理的事项、待接收的事项、登记事项、关注事项。。。。。。以非常方便的方式获知这些事项，同时通过各种途径通知、提醒到用户。

• 以跟踪、监督、检查为手段

管理层和事件参与者使用应用系统的时候往往是需要知道事件的处理情况，处理过程、检查或回访事件的处理真实性、监督、督导事件的处理方法，这样的应用系统从管理的角度上保证了事件处理的效能。

• 以分析结果为依据

决策层在考核、调整优化企业战略的决策是需要些依据的，在工作流引擎下会提供各种流程绩效的分析数据或其它企业分析的数据，作为战略决策的依据。

• 以持续改善为目标

传统的应用系统，往往是依据某一个相对固定的业务模式而设计开发的，当终端用户需要对业务经营或模式做改善时，往往依赖于现有的应用系统，依赖于开发商，在工作流引擎技术下的应用系统，持续改善的可行性大大提高，终端用户自己就可以调整业务流程，达到更好的绩效。

当然每种工作流引擎技术带来特征的变化也是不同的，工作流引擎本身而言，工作流引擎是没有价值的，好的工作流引擎是一定绑定了某种管理思想，这种思想通过加载的应用系统体现出来，这样才是真正有价值的工作流引擎。

5、 使用工作流引擎技术开发系统的客户价值

使用好的工作流引擎技术开发的系统带来的客户价值是显而易见的，主要体现为：

• 将为公司未来经营战略的发展提供稳定灵活的信息技术基础设施，使公司IT规划能够满足企业若干年成长的需要。成熟而开放的微软技术架构，良好的投资保护方案。
• 会提高企业运营的灵活性和适应性，通过信息技术平滑实现组织结构调整和业务流程变更，降低企业改革成本。
• 跟踪事务处理全过程，可以量化考核每个处理环节的效率，结合公司KPI体系建设，提高公司流程执行力和绩效管理能力；有利于推进公司精细化管理目标的落实。
• 作为企业诊断和业务流程重组（BPR）的最佳实践工具，能够量化分析和评价业务流程的效率和效果，便于持续优化和改善业务流程，提升企业战略执行力。

后记：

选择工作流引擎技术的时候，关键是看应用系统的管理特性，工作流引擎技术是否符合这些管理特性，是否能将这些管理特性充分体现出来，而不是为了追求一堆无血无肉所谓的标准，也不是为了追求毫无意义的功能点，选择工作流引擎设计应用系统是为了效率，追求的是价值。这一点目前在业界是最容易偏移的思想。