工作流实施策略

 

工作流项目实施的一些问题和解决策略


更多工作流参考文档，请访问在 http://www.javafox.org

这两年工作流应用越发火爆了，大多管理信息系统都或多或少涉及到流程应用。一方面
客户对流程认识和需求在提高，另一方面开发商也希望通过流程技术为客户提供更灵活的应
用支持。
先简单说说什么是工作流：
工作流（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 年初
在这里也顺便提个忠告，存在一些开发商的管理人员把工作流技术看的过于简单。当突
然碰到有类似的项目的时候，以为找个开发人员，让其在开源引擎上去研究一段时间就可以
应付复杂流程项目，这是大错特错的，而且大多都以失败告终。在我前面的参考方法中，第
一句话就是——“仅仅只是实施一个或一些简单的流程应用”，才应该优先考虑开源引擎。
第四个问题：如果考虑第三方工作流产品，那么选择哪家产品更合适自己？
接下来，讲讲如何选择商业工作流引擎。
这两年国内工作流厂商是越来越成熟，产品的定位和分层也逐渐显现出来，比如西安协
同的流程产品逐渐开始支持于基于ESB 的分布式流程应用，而上海携创的Joinwork 则依然
定位在嵌入式工作流引擎。但是对于那些决定采用第三方工作流产品的开放商来说，如何选
择一个最适合的产品，也依然是件非常困难的事情，毕竟国内大大小小的工作流产品有数十
家：
在 google 上搜索“工作流产品”，大约会搜索出7840000 条记录。下表列出一些较为常
见的工作流厂商和产品（不包括一些平台性厂商，如起步、普元、炎黄盈动等）：
神马 EasyFlow、西安协同SynchroFLOW、上海携创的Joinwork、
信雅达 SunFlow、东兰LiveFlow、中创InfoFlow、
有生博大 RiseBPM、华创动力MatrixFlow、慧点Galaxy
东方易维Workflow、华苓AgentFlow、世纪金政Koof、盛松W-Flow、
东方通 TongWorkFlow、维泰WiseFlow、超微SuperFlow、明基逐鹿eFlow
面对这么多的工作流厂商，开发商的选择主要困难在三个方面：
（1） 很多开发商只有在接到工作流项目的时候才匆忙考虑购买产品，但此时客户需
求详细调研还尚未完成，其所面对的客户也很难提出清晰明确的流程应用需求。
所以开发商很难有个准确的衡量标准来评价什么产品最适合他们
（2） 很多产品的功能表述的都很类似，产品演示也看似相近。功能似乎很多，但是
到底哪些功能是真正需要的，而哪些产品是适合后续应用和扩展的，对开发商
来说是很难决断的。
（3） 开发商的心理担心和犹豫：毕竟购买的工作流产品，对他们来说，似乎就像一
个“黑匣子”一样，很担心后期实施中，因为客户的需求不满足而又无法更改
产品，从而造成实施不下去的情况发生。
基于这几年工作流咨询和培训的经验，简单阐述一些选择的标准。主要是从如下几个角
度进行选择：
（1） 首先搞清楚客户对流程设计器的要求或期望如何，是倾向于B/S 的web 设计器
还是，还对C/S 设计器也可接受。可能很多最终客户对这两者是用上的区别不
胜清楚，那么就需要开发商首先自己需要清楚这两者的区别，以及斟酌所定位
的客户的应用习惯和场景，那种操作凡是更适合客户使用。
（2） 其次，客户对流程的应用模型和操作习惯如何，诸如是否支持“串型”“并型分
支”“条件分支”“同步异步子流程”“多种类型的执行人分配”“会签”“回退”
“取回”“跳跃（速称自由流）”等等，这些都是国内常用的基本流程应用需求。
相信这些功能很多产品也都宣称支持，但是具体支持的力度，却需要自己仔细
分析。举个例子：有些产品宣称支持回退，但是在项目实施的时候，却告诉开
发商在流程图上需要额外多绘制一条转移连接线来实现回退的操作。那么一旦
开发商所面对的客户要求能够实现“逐级回退”则变得非常棘手。
（3） 客户的流程变更性如何，如果客户提出了流程变更，那么如何维护流程的变更
操作是开发商需要仔细考虑的。一方面以此来分析工作流产品如何支持流程变
更，一方面需要确定是否会存在客户自己进行流程定义更改的情况。毕竟一个
工作流系统实施后，最终的使用者还是客户，而客户的业务应用有可能会在后
续发展中发生变化的。
（4） 客户的应用系统中流程是否很多。存在有些工作流应用中，只实施几个流程而
已，但也存在有的项目实施中，一个系统却包含几十个甚至上百个流程定义。
前一种情况如果产品提供商所提供的工作流系统完整性还不够的话，通过后续
开发商的实施尚且可以弥补；而后一种情况则要非常小心了，开发商必须选择
一个系统完整化和成熟度比较高的工作流产品。这样一类的工作流产品除了流
程设计器和引擎以外，还可能会包含：可扩展的组织模型、表单系统、工作列
表系统，甚至还有监控和管理部分。——但是系统复杂度越高，扩展复杂度也
越大，所以开发商必须在这个层面寻找一个适度的平衡。
（5） 就国内目前的绝大多数流程应用来说，流程监控应用性需求还不是很高。很多
客户提出对流程监控的需求，也仅仅只是“觉得有这个必要”，但等到系统真正
上线后，使用流程监控功能的却很少的。但是，有这一类功能的工作流产品总
归比没有要强一些，但需要哪种深度的监控，那就需要开发商自己斟酌一下了。
这两年在给一些开发商咨询的过程中，碰到很多开发商希望工作流产品能够“assembling
on demand”，就是能够按照需要的功能组装。因为很多开发商抱怨，他们用昂贵的价格选择
了一个很好的工作流产品，但是却只使用了很少的功能；而那些价格较低的轻量型流程产品，
却在有些功能上不能满足或细粒度不够，很难达到客户和二次开发的需求。事实上我也一直
在期待国内能有这样架构的流程产品出现。
第五个问题：如何更加有效的进行流程系统实施
如果此时开发商已经有一个基础的工作流引擎或产品了，不论是采购第三方的，还是自
主研发的，那么接下来所面对的最大的一个问题就是如何更加有效的实施流程了。
很多工作流实施阶段本身其实没有太多的技术难度关口，最大的难度是在需求调研阶段
的“流程梳理”。很多开发商在需求阶段都会反复抱怨“客户没有什么需求，或者客户让我
们先做个demo 再提需求”。
就目前国内流程应用情况来说，绝大多数客户都会直接把“流程需求”的问题直接推给
开发商自己处理。这就需要开发商采取正确的策略和方式来一步步推进，而不能再像早期实
施其它MIS 系统似的采用“需求+静态页面Demo+数据库设计+开发”策略了。
对于很多客户来说，实施工作流系统一方面是响应“从有纸化转变为无纸化”号召，逐
渐推进信息化应用；另一方面则希望通过“流程系统”有效的梳理出某些流程在办理过程中
的真正处理过程。
在早期没有流程系统的时候，不论在政府办公还是企业管理，某些处理流程虽然有“规
章制度约束”，但是在真正办理过程中，因为一些人为的因素，会存在一些变通的处理，从
而会造成某些流程实际在审批过程中会“跳过”或“多出”一些环节。而且对一个管理人员
来说，当其面对一个审批文件过来的时候，一般是很难非常清晰这个事情到底要经过哪些环
节、哪些人的审批的。所以在现实操作过程中，很多情况是依据一些常规经验和个人判断处
理。
那么流程信息化就要逐步帮助管理人员来逐步规范和梳理这些流程的处理步骤。这也是
很多客户在流程信息化中的现阶段真实目标。开发商只有摸清客户对流程的真实目标期待，
才能过采取有效的需求调研和实施方案，以及流程实施功能定位。
网络上不乏有一些所谓工作流实施介绍的文章，大体会告诉大家采用如下的步骤：建立
项目管理办公室、业务分析、确定目标、确定实施计划、流程建模、软件集成······。这套
步骤对于那些具有深厚的行业应用积累经验以及成熟的工作流实施经验的厂商是非常合适
的，但是对于很多开发商来讲，却存在很大的误导性。
前面已经说过，对很多客户来说，其真正关心的是“梳理真实清晰的现实流程”。如果
开发商能够通过与客户的不断沟通，逐渐帮助客户梳理现实操作中的流程处理过程，并用流
程系统实现，则基本百分之九十的满足客户需求了。这个梳理过程不是一次两次就可以清晰
搞定的，需要开发商在需求调研阶段不断的绘制流程图（最好就用流程设计器直观的绘制），
每绘制一次就与客户进行沟通和演示，依据客户确认后提出意见再修改，再完善，再由客户
确认。如此反复，才能正确帮助客户梳理出流程。
在梳理流程阶段，一定要把握几点：
（1） 一定不要抱怨客户提不出什么需求，这个必须自己去逐步挖掘需求。因为客户
对流程系统和流程信息化所带来的办公操作和影响并没有预见性，这需要开发
商逐步帮助客户去理解，去应用。
（2） 一定要不断的找相关业务处理的负责人进行流程确认，找真实办理职员进行系
统演示，因为只有这些人员才清楚现实流程的真实办理过程。
（3） 不要把需求调研和流程实施过分区分开，如果在需求调研过程中，就一步步地
用流程设计器进行流程绘制，并给客户演示，则更容易让客户提出一些潜在的
流程需求，而不至于到了项目后期或上线试运行阶段，客户才大量的提出修改
需求来。
作者简介：
胡长城，网名“银狐 999”。就职于TIBCO CDC，Infrastructure team
国内J2EE 开源应用的支持者，有过六年的J2EE 应用和产品开发及架构经验，huihoo
开源组织成员。
国内工作流应用的推广者，有过四年的工作流研发经验。利用个人主页和 Blog 共享了
很多宝贵的工作流研究心得。尝试开拓了工作流培训方式，为企业工作流应用提供咨询和指
导。