(工作流实施策略.docVIP

工作流实施策略 先简单说说什么是工作流： 工作流（Workflow）就是工作流程的计算模型，其表示的是：对流程中的任务（活动），以什么样的逻辑或者规则串接起来，并以什么样的模型进行表示和计算。 上面的概念解释比较抽象化，由于本篇不是定位于讲解工作流概念的文章，所以我们暂且不深入的探讨工作流的一些基础知识和理念。简单的举例加以说明：例如，在日常办公中， 当撰写好某份报告之后，可能需要将其提交给领导进行审阅或批示；审批意见可能需要汇集并提交给另外一个人，以便对报告进行进一步的修改。这样，可能会形成同一篇文档在多个 人之间的顺序或同时传递。对于这样的情况，我们可以使用工作流技术来控制和管理文档在各个计算机之间自动传递，而非手工传递。这就可以称之为工作流。 本篇主要探讨工作流实施过程中的一些需要注意的问题。对于工作流的实施，其实就是基于一个工作流引擎或平台，通过扩展开发实施，满足客户对流程信息化应用的需求。从一 个开发商接手一个流程应用开发，到其给客户实施成功，需要面对一些比较棘手的决策性问题，而这就是本篇所要探讨的主题。通过对一些工作流实施问题的讲解和方案探讨，来辅助 开发商进行一些基本决策。 第一个问题：为什么就一定需要使用工作流技术？首先简单阐述一下为什么一定需要使用工作流技术。 我想最直接的原因应该是来自于客户的管理和运营信息化的需求推动：在客户的运行管理体系中，在不同的职能领域，是由各种各样的处理流程交互协助的，而这些处理流程都是由一些 处理活动和任务组成的。传统的信息系统仅能满足客户对数据处理信息化的最基本要求，却很难满足客户对“协助处理信息化”的要求，这就是客户为什么需要工作流技术的基本原因。 而从另一个角度来说，开发商也希望通过流程技术的应用，一方面提高流程项目的实施进度，另一方面则希望能够为客户带来更高体验度的实施效果。 这个问题不过多的解释，因为目前工作流的应用已经是越来越广泛。 第二问题：工作流技术就真的可以提供工作流项目实施进度吗？ 这几年在工作流培训过程中，碰到很多技术人员问我这个问题。在他们看来：首先他们对工作流系统是存在一些困惑的，特别是从来没有接触过工作流系统的开发人员；其次他们 搞不清楚工作流技术是否真的能提高项目开发进度。单纯说使用工作流技术提高项目实施效率，这不一定就有效。这几年的实施的流程项目很多，但只有个别几个，因为客 户对流程相关的应用应用的需求不是很复杂（如表单、权限等），我们流程产品本身辅助的表单系统也基本满足客户的需求，在这样的情况下实施的流程应用相对是快很多的。 但绝大多数实施的流程项目，单纯从按照客户的需求来完成流程运行和实施，有没有工作流引擎支持，其实并没有提高的太多。我记得2002 年下半年的时候，给国家发改委实施 了一个“提案信访”的流程，流程本身不是很复杂，如右图所示。当时我们已经有一个较为完善工作流系统了，但这个流程项目依然实施了半年多。主要原因是耗费了大量的开发精力 在客户操作习惯、交互界面以及组织管理中的一些非常规权限方面。 可以说，一个单纯的工作流引擎，本身似乎并不能提高多少的流程项目实施效率。但是我们依然推崇使用工作流技术来解决流程性问题。这是因为工作流技术本身是基于“定义模 型、解析模型、运行模型”原则，这就是说“流程是可被描述的”，一般我们会采用xml 来描述流程定义。基于这个模型“定义——解析——运行”原则，则会带来两个最直接的益处： （1） 基于可被描述的模型，也就意味着流程定义是可被复制的。那么对于类似的流程就可以很容易被快速复制和扩展。 （2） 基于模型的解析运行，也就代表着可被有效的监控和管理，这是传统硬编码开发很难逾越的。 第三个问题：如果去获取一个工作流引擎或平台？ 工作流项目实施的前提就是必须已经存在一个工作流平台或工作流引擎，基于这个引擎或平台实施项目：这个平台或引擎，不论是够买第三方的，还是自己研发的，抑或是扩展自 开源的，但总归必须是有那么一个了。如果某一个厂商，其有自己的工作流产品，那么这个问题似乎就没有存在可能性了。但是对国内大多数开发商来说，这是一个很头疼的问题。当这些开发商接到一个工作流项目的时候，摆在他们面前的最直接问题就是：怎么搞定这个基础的工作流系统或工作流引擎，是够买一个现有流程产品，还是基于开源引擎扩展，抑或是自主研发？ 这三个选择似乎都很困难，因为现在国内的工作流应用蓬勃发展，工作流厂商也如雨后春笋般一个接着一个的冒出来了，而且其中不乏有很多是以提供Platform 为主的；而开源引擎也越来越成熟和完善；而很多开上也着实希望能够用有自己知识产品的引擎，为以后项目实施解决成本。 下表就显示了一些代表性厂商和开源引擎： 平台厂商 起步、浪潮楼