工作流系统：在误区中漫步

为什么现在的工作流系统总是遭到客户的抱怨？

为什么我发起的流程运转后总是不在我的掌控之下，甚至有的流程运转后竟无缘无故的没有的下文，这样的工作流系统怎么能构提高企业的工作效率？怎么能够不让客户抱怨？！

我觉得现在的许多工作流系统有太多不能解决（或者不能得到很好的解决）的问题的主要原因有2点：

1:面向组织结构还是面向过程？！（很多的工作流系统的模型是基于组织结构的！）

问题显而易见：这种结构本身就是放射性的，那么泼出去的水岂有收回的道理。当然，话也不能说的太绝对，我们也可以把水泼到一个容器里面，那么也可以收回了，这是一种解决方案；

另外一个解决的方案呢是：类似与雷达系统，对发出去的信息（信号）做一个追踪，这样总是会有反馈信息回来，即使是泼出去的水，只要我们知道了水去了哪里，为什么我们不能把水手回来呢

这种的模型还有另外一个问题：就是不能很好的体现参与者之间的交互状态：“We are a team!”我的一个项目经理经常这样提醒我们。现在的工作环境要求我们必须和其它的参与者进行交流，但是它已经不能很好的表达这种更加贴近人类思想的行为！（同时参考下面的2）

2:对流程中步骤的误解

上面说到了交互，那么既然有交互就必不可少的会出现不止一个的参与者，那么在制定工作流程的时候是否就不应该再指定参与者了？因为流程制定人不知道具体的有那些人参与，他要做的是“发起一个job”，最多是指定一个直接需要向发起人负责的参与者，或者只是做一个概略性的指导，那么参与者是不应该出现在刚刚制定出来的流程中的！

”流程中步骤的存在是因为有了上下文 “

类似与这种的结构：

传统的工作流程   步骤1 --> 步骤2 --> 步骤3 --> 步骤4....

我的设想              [参与者1，参与者2] --> [参与者2，参与者3] --> [参与者3,参与者4]....

说明：我的设想中不同于传统的地方在于，任何一个参与者都是承上启下的一个连接器，参与者需要向上一个参与者直接负责（比如提供必要的材料），也要向下一个参与者负责（提供自己完成的材料，如果材料有什么问题，也需要对材料进行修补完善），成对出现的（小的信息循环模型，方便交流），这样就实现了一种更加具有交互能力的模型；

或许有人会说，在一定程度上传统的工作流程也能表达这种模型啊！但是如果我说在我的设想中同时还表达了[工作]这个重要概念的时候呢？如果我把 流程流改成这种形式呢？

步骤	...[参与者2，参与者3] --> [参与者3，参与者4] --> [参与者4,参与者5]....
工作	[参与者1，参与者2] --> [参与者2，参与者3] --> [参与者3,参与者4]....

你看出这两个的不同了吗？如果我把这两个合并到一起呢，还和传统的点到点的结构相同吗？^_^

新的结构是这个样子的

参与者	....+-------+    +------+   +----------+  +---------+ +----------+......
工作	+----+ +----------+ +---------+ +---------+ +----------+ +------ .....

^_^，这是不是类似与一种链条的结构啊

那么流程制定者在制定流程的时候需要做哪些工作呢？

其实很简单：2个工作，一是制定工作的流程（就是下面的那一行的结构），另外一个就是指定参与者（通常是第一个工作节点的参与者，因为在向后就不确定了）

我们可以这样想，工作的那条线是主线，参与者的那条线呢是辅线，只有工作点被激活的时候，参与者才会被激活（不是绝对的，例子而已），那么参与者可以是该工作岗位上（现有）的任何一个人或者组织，也可以有上一个工作点的参与者指定

”这种结构有效的解决了面向[组织结构]还是面向[过程]的分歧 “

我说的可能不是特别的明白，因为我自己也想的不是特别的清除，只是有两个一个大体上的想法而已，如果谁有更好的想法，或者不同的观点，可以大家一起讨论一下！

 

 

工作流系统，分“流程定义”和“流程实例”的概念，如同类和对象的关系。
我粗浅接触的几个工作流系统，“流程定义”由点(node)和线(transition)组成，“参与者”只不过作为node的属性。这跟LZ的判断是一致的。

LZ似乎提出了两个问题：

一、“流程实例”在执行过程中，如何能够修改它的流程定义而不影响其它实例，并且保证可控？
是象copy-on-write呢？还是ruby的singleton class呢？发散一下，虽然做过这方面开发，但在理论上没有发言权。。。

二、如何对参与者进行动态解析？
这应该由“工作项管理系统”(workitem manager)负责。jbpm有，osworkflow就没有，它通过扩展机制让用户自己处理（内置了的几个简单实现）。

OA系统里，涉及复杂参与者及动态流程的可能性很大。

关于这两个问题（尤其第一个），在理论及实现上，我都很感兴趣，坛子里的工作流专家不少（俺不是），搬个板凳先。

请看下petri网建模，再来说啥“传统工作流”。流程案例（case)显然不应该是singleton，工作项本来就应该由资源驱动，资源可能是人工，可能是自动，可能是时间驱动，更可能是某个异步消息。《工作流管理：模型、方法和系统》这本书介绍的非常好。

谢谢dennis_zane,那本书的链接：
http://www.china-pub.com/17402
打算今天去书店买本学习学习，我接触的工作流系统，大都是状态机模型，我对petri网没有概念。

你说的流程案例（case）就是流程定义吧，我前面类比了ruby的singleton class（想想你以前ruby源码分析的blog，呵呵）。在OA中，可能有这样的场景：在一个基于某流程模板的流程实例在运行过程中，需要中途改变它的流程图，比如加签、减签、知会、会签。这些改变，不影响模板本身。

在jBPM PVM里，自动结点就是简单实现activity的execute方法，写自己的业务逻辑；人工结点/时间驱动/异步消息结点 对execute方法一般分两步：
1. 让工作项管理系统分配工作项/启动timer
2. 调用waitForSignal使流程暂停在这里

第三步是外部系统做的，它在特定时机下（人处理了工作项，timer超时，异步消息到达），回调activity的signal，通知其继续流转。

liusong1111  说的很有道理，如果分了“流程定义”和“流程实例”的概念，是会出现你所说的第一个问题
出现这个问题的原因是我们要对流程的定义进行复用，复用的方式有很多，这个只是一种；我们可以采用其它的方式，不如引入模板的概念，使用复制而不使用实例化的方式；优势是显而易见的，复制的方式更加灵活！
满足了复用的需求，自由度也有所提高
关于动态解析的问题比较好解决，我们根本不需要它自动解析，当步骤在没有被激活之前知道具体的参与者是没有意义的，因为太早指定具体参与者的时候如果这个人有别的工作还没有做完怎么办？我们再指定其它参与者吗？这样是不是徒增了流程的不确定性？而且决策者（或者发起人）往往不可能做这么具体的工作的，如果真的需要知道具体的参与者，也是在工作流结束（运因可能是失败了要追究责任，成功了要保障，或者是要查看资源是否有浪费等等），这也是在完成以后的事情，没有必要在开始的时候就指定的！
设想参与者是一个组织的话，那么这个组织只要有一个负责人，其它的参与者就由他指定（或者自己去领取工作）就可以了！他向决策者直接负责就可以了！
所以动态解析是一个比较乌托邦的想法，太美丽了，可是不现实啊！

记得是  模板+实例+控制

这样就基本可以完成workflow了，可是实现的时候做的不好

to deepthink：

我想我还是很理解你的困惑的，如果我没有猜错的化，你可能在做的工作流实施，是在电子政务行业或者某些领域的OA办公审批流程（如：公文收发之类）。

你所说的这种需求，在电子政务领域是比较普遍的，特别是“公文流转”。有时候，很难用一个业务性的流程来诠释“公文审批”。这样的审批总是围绕着“谁签？谁办？”在进行的。——也就是说，从大的审批流程过程来说，诸如“科员-->科长-->处长-->局长-->司长”（当然，中间总会穿插一些秘书或办公厅之类）。这样的过程是不会改变的，也不可能改变（组织的权限、级别的限制）。—— 但是，到底是哪些处长签、哪些局长签呢？这是无法用“预先定义的参与者来诠释的（很高兴你使用用参与者这个专业术语）”。

但是，任何事情，都会有“规章可循”。即使像公文这样“人为主导”的流程应用，也依然有流程的踪影：“科员-->科长-->处长-->局长-->司长（从组织角度看）”；“拟稿-->审核-->部门内会签-->审核-->会签--签发（从业务流程角度看）”（一个复杂的发文流程图，可以看看http://upload.mop.com/user/2005/05/27/843737ce.gif）。

这两者总是结合的，但有一点是不变的：引擎是站在流程的视角，至于参与者，则可以通过外围手段解决：简单的办法，允许动态创建工作项；复杂的办法，允许动态创建活动实例；再复杂的办法，连某一个“模型”都到动态创建。—— 但这，不会影响引擎的对流程的调度计算。
==================================
国内的流程，“人为因素、组织因素”影响很大。很多流程还依赖“人治”。这是西方的“流程系统”所不能领悟的。

时间关系，不再深入阐述。你所说的这个还只是“业务性问题”。这种业务场景，已经被很多工作流厂家很好的解决了：前参与者执行、动态角色、动态创建工作项、加减签处理、会签处理、多级流程、多流程实例独立等等等，反正很多很多。

胡长城（银狐999）
http://www.javafox.org

个人感觉工作流系统中，每个环节的人员选择是非常灵活的。像我现在的项目中，有的流程的人员是根据权限产生的，有的环节的人员是根据上一个环节指定的。而有的环节的人员是好几个环节以前指定的。所以说工作流系统关键是，系统只负责一定比例的工作流程控制，而一些极其特殊的控制应当交给开发人员，自己实现。

to 银狐999:
同意你的观点，这个是我没有分的太清楚，我是初衷就是为了能够把业务和流程做一个比较好的合并工作，因为我发现很多和业务关系很密切的的公文流转（举例）都是基于流程步骤的，也就是说某一个步骤的工作在流程图的表现太过于独立，而往往这个是不现实的！
我设想加入步骤的关联性，任何一个步骤的工作交给下一个步骤之后，这个步骤的工作并不完全的独立，所以我提出了“成对的步骤”（可能不是特别的确切）这么一个概念，任何一个步骤的工作都必须同时对上一个步骤和下一个步骤同时负责！
至于我最开始的所说的流程中“参与者”这个概念是经过你的讲解，我觉得你是对的，这样的话就解耦了我自己的设想，使我从这种错综复杂的关系中解脱出来！非常感谢！

光讲理论太空泛，我建议各位找几个工作流系统来研究一下，比较成熟的有东兰的liveflow，k2等，我对liveflow比较熟悉～

最近也在考虑个工作流的架构，不过主要是从实用角度去想的，还没考虑到wfmc标准那些。。。