工作流实施策略

工作流实施策略

这两年工作流应用越发火爆了，大多管理信息系统都或多或少涉及到流程应用。一方面客户对流程认识和需求在提高，另一方面开发商也希望通过流程技术为客户提供更灵活的应

用支持。

先简单说说什么是工作流：

工作流（Workflow）就是工作流程的计算模型，其表示的是：对流程中的任务（活动），以什么样的逻辑或者规则串接起来，并以什么样的模型进行表示和计算。

上面的概念解释比较抽象化，由于本篇不是定位于讲解工作流概念的文章，所以我们暂且不深入的探讨工作流的一些基础知识和理念。简单的举例加以说明：例如，在日常办公中，当撰写好某份报告之后，可能需要将其提交给领导进行审阅或批示；审批意见可能需要汇集并提交给另外一个人，以便对报告进行进一步的修改。这样，可能会形成同一篇文档在多个人之间的顺序或同时传递。对于这样的情况，我们可以使用工作流技术来控制和管理文档在各个计算机之间自动传递，而非手工传递。这就可以称之为工作流。

本篇主要探讨工作流实施过程中的一些需要注意的问题。对于工作流的实施，其实就是基于一个工作流引擎或平台，通过扩展开发实施，满足客户对流程信息化应用的需求。从一

个开发商接手一个流程应用开发，到其给客户实施成功，需要面对一些比较棘手的决策性问题，而这就是本篇所要探讨的主题。通过对一些工作流实施问题的讲解和方案探讨，来辅助开发商进行一些基本决策。

第一个问题：为什么就一定需要使用工作流技术？首先简单阐述一下为什么一定需要使用工作流技术。

我想最直接的原因应该是来自于客户的管理和运营信息化的需求推动：在客户的运行管理体系中，在不同的职能领域，是由各种各样的处理流程交互协助的，而这些处理流程都是由一些

处理活动和任务组成的。传统的信息系统仅能满足客户对数据处理信息化的最基本要求，却很难满足客户对“协助处理信息化”的要求，这就是客户为什么需要工作流技术的基本原因。而从另一个角度来说，开发商也希望通过流程技术的应用，一方面提高流程项目的实施进度，另一方面则希望能够为客户带来更高体验度的实施效果。

这个问题不过多的解释，因为目前工作流的应用已经是越来越广泛。

第二问题：工作流技术就真的可以提供工作流项目实施进度吗？

这几年在工作流培训过程中，碰到很多技术人员问我这个问题。在他们看来：首先他们对工作流系统是存在一些困惑的，特别是从来没有接触过工作流系统的开发人员；其次他们

搞不清楚工作流技术是否真的能提高项目开发进度。单纯说使用工作流技术提高项目实施效率，这不一定就有效。这几年的实施的流程项目很多，但只有个别几个，因为客

户对流程相关的应用应用的需求不是很复杂（如表单、权限等），我们流程产品本身辅助的表单系统也基本满足客户的需求，在这样的情况下实施的流程应用相对是快很多的。

但绝大多数实施的流程项目，单纯从按照客户的需求来完成流程运行和实施，有没有工作流引擎支持，其实并没有提高的太多。我记得2002 年下半年的时候，给国家发改委实施

了一个“提案信访”的流程，流程本身不是很复杂，如右图所示。当时我们已经有一个较为完善工作流系统了，但这个流程项目依然实施了半年多。主要原因是耗费了大量的开发精力在客户操作习惯、交互界面以及组织管理中的一些非常规权限方面。

可以说，一个单纯的工作流引擎，本身似乎并不能提高多少的流程项目实施效率。但是我们依然推崇使用工作流技术来解决流程性问题。这是因为工作流技术本身是基于“定义模型、解析模型、运行模型”原则，这就是说“流程是可被描述的”，一般我们会采用xml 来描述流程定义。基于这个模型“定义——解析——运行”原则，则会带来两个最直接的益处：（1）基于可被描述的模型，也就意味着流程定义是可被复制的。那么对于类似的流程就可以很容易被快速复制和扩展。

（2）基于模型的解析运行，也就代表着可被有效的监控和管理，这是传统硬编码开发很难逾越的。

第三个问题：如果去获取一个工作流引擎或平台？

工作流项目实施的前提就是必须已经存在一个工作流平台或工作流引擎，基于这个引擎或平台实施项目：这个平台或引擎，不论是够买第三方的，还是自己研发的，抑或是扩展自

开源的，但总归必须是有那么一个了。如果某一个厂商，其有自己的工作流产品，那么这个问题似乎就没有存在可能性了。但是对国内大多数开发商来说，这是一个很头疼的问题。当这些开发商接到一个工作流项目的时候，摆在他们面前的最直接问题就是：怎么搞定这个基础的工作流系统或工作流引擎，是够买一个现有流程产品，还是基于开源引擎扩展，抑或是自主研发？

这三个选择似乎都很困难，因为现在国内的工作流应用蓬勃发展，工作流厂商也如雨后春笋般一个接着一个的冒出来了，而且其中不乏有很多是以提供Platform 为主的；而开源引擎也越来越成熟和完善；而很多开上也着实希望能够用有自己知识产品的引擎，为以后项目实施解决成本。

下表就显示了一些代表性厂商和开源引擎：

平台厂商起步、浪潮楼上、炎黄盈动、普元、中创

工作流厂商西安协同、东兰、Joinwork、信亚达、华创动力、盛松

开源工作流引擎jBpm、OSWorkflow、Shark

所以对开发商来说，选择什么样的方式，是首要问题，甚至有可能上升到战略性问题。

在此，提供一些基本分析意见，供参考：

（1）如果仅仅只是实施一个或一些简单的流程应用，这个简单的意思不是指流程的结构简单，而是指客户的操作性简单，没有诸如“回退”“会签”“跳跃”之类的运转模型；而且客户对流程图形化定义也没有什么要求，只要能保证流程稳定运行，以及可进行简单的管理和监控操作即可。那么这种情况下，应该首先考虑“基于开源引擎扩展”。这是因为目前开源引擎基本上都比较成熟和稳定了，特别是jBpm，自从其被JBoss 收购之后，jBoss3 是越来越完善。据我所知，目前国内很多开发商就是基于jBpm 之上进行扩展实施流程项目的，并且很多都已经成功应用。

（2）如果项目要求非常紧，而且客户对流程设计、流程运行的要求也比较高。那么这种情况下，一般建议优先考虑商业应用产品，虽然采用商业产品必然会带来成本的增加，但是从满足客户的需求应用角度来讲，还是比较值的。但选择什么样的产品，这对很多厂商来说，也是较难于把握的。这一点我们随后再讲，先接下来看看什么情况适合自主研发。

（3）相信很多开发商都希望能拥有自己的工作流引擎或平台，因为对他们来说，首先是采用第三方的厂商产品会带来采购成本的增加，其次较为担心在流程项目实施过程中，因

为客户需求的复杂或突然变更，而厂商产品接口有限或功能却恰巧不满足的情况下，则会带来非常麻烦的事情。

但自主研发只在如下情况比较合适：目前项目交付压力不是很大，有至少两至三人的研发团队，持续投入半年到一年，并且其中有对工作流系统结构模型等方面有较深理解，并有

适当的实际引擎开发经验更好。从上面的条件可以看出来，这个要求是很高的，对国内大部分开发商来说，是很难提供这样的研发环境。自主研发工作流引擎或系统，一般都需要半年到一年左右的研发期，还需要一两年左右的项目实施和完善期，才大约能够走向成熟。

比较有代表性的开发商如下：

公司工作流引擎名称研发启动时间引擎初版发布

北京用友软件工程Nucleus 2004 年初2005 年中

北京慧点科技Galaxy 2003 底或2004 初2004 年底或2005 年初