2008-05-31
工作流系统：在误区中漫步
关键字: 工作流 workflow
为什么现在的工作流系统总是遭到客户的抱怨？
为什么我发起的流程运转后总是不在我的掌控之下，甚至有的流程运转后竟无缘无故的没有的下文，这样的工作流系统怎么能构提高企业的工作效率？怎么能够不让客户抱怨？！
我觉得现在的许多工作流系统有太多不能解决（或者不能得到很好的解决）的问题的主要原因有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个工作，一是制定工作的流程（就是下面的那一行的结构），另外一个就是指定参与者（通常是第一个工作节点的参与者，因为在向后就不确定了）
我们可以这样想，工作的那条线是主线，参与者的那条线呢是辅线，只有工作点被激活的时候，参与者才会被激活（不是绝对的，例子而已），那么参与者可以是该工作岗位上（现有）的任何一个人或者组织，也可以有上一个工作点的参与者指定
”这种结构有效的解决了面向[组织结构]还是面向[过程]的分歧 “
我说的可能不是特别的明白，因为我自己也想的不是特别的清除，只是有两个一个大体上的想法而已，如果谁有更好的想法，或者不同的观点，可以大家一起讨论一下！
评论
这个就是“提供给用户选择，而不是替用户选择”的意思
我们必须明确“机器是不能完全明白外部环境的”，机器始终是机器
我们需要做的是“提供给用户一个选择，而不是替用户做选择”
错，流程运行的一个重要环节就是处理人，一个好的工作流系统，必然是将处理人都定义在流程中，当然要有非常完善的逻辑关系来确定处理人，例如按组织架构，按角色，按关系等，让用户自己去选择处理人那是最后的选择，试想一下，每个节点都让用户选择下一步处理人，那和发邮件有什么不一样？让流程随意的流转，那才是不可控制的。
你这个可能有些武断,把人写死在流程里应该是可以动态指定人的一个特例出现,而不是规则.
试想,有一个流程在一个公司里不同的几组人重复使用,又怎么能够把人固定在里面呢!
我们需要做的是“提供给用户一个选择，而不是替用户做选择”
错，流程运行的一个重要环节就是处理人，一个好的工作流系统，必然是将处理人都定义在流程中，当然要有非常完善的逻辑关系来确定处理人，例如按组织架构，按角色，按关系等，让用户自己去选择处理人那是最后的选择，试想一下，每个节点都让用户选择下一步处理人，那和发邮件有什么不一样？让流程随意的流转，那才是不可控制的。
我认为不应该将人定义在流程中，而是将群组定义在流程中，提供给用户"一组人"选择，这样既能控制又能变通
关于某个业务，涉及某些条件由谁批准的问题。如果能够很好地抽象出这些就可以解决这个问题。
比如说：
业务 条件 执行者
车费报销 金额<50元 科长
车费报销 100>金额>50 处长
车费报销 金额>100 局长
如果企业建立一套这样的业务规则库，系统中应用业务规则引擎迅速找到执行者，
再将其赋给工作流系统的参与者，工作流就可以运作。 工作流系统要和业务规则引擎系统，以及企业组织机构建模良好地配合，才能更加灵活和强大。
目前，我所做的权限资源管理平台正在朝这个方向发展。由于时间和精力问题，现在还抽不出精力解决这个问题，但是我想迟早要将企业的业务规则同授权系统以及工作流系统要很好地整合起来，提供更加灵活和强大的平台。
如果你是开发自己企业应用的工作流系统，我建议你找第三方的产品来实现，都是现成的功能，也许就相当于你一个程序员的年薪而已。
谢谢你的提醒，如果我们没有工作流产品一定会采用你的建议。
关于某个业务，涉及某些条件由谁批准的问题。如果能够很好地抽象出这些就可以解决这个问题。
比如说：
业务 条件 执行者
车费报销 金额<50元 科长
车费报销 100>金额>50 处长
车费报销 金额>100 局长
如果企业建立一套这样的业务规则库，系统中应用业务规则引擎迅速找到执行者，
再将其赋给工作流系统的参与者，工作流就可以运作。 工作流系统要和业务规则引擎系统，以及企业组织机构建模良好地配合，才能更加灵活和强大。
目前，我所做的权限资源管理平台正在朝这个方向发展。由于时间和精力问题，现在还抽不出精力解决这个问题，但是我想迟早要将企业的业务规则同授权系统以及工作流系统要很好地整合起来，提供更加灵活和强大的平台。
如果你是开发自己企业应用的工作流系统，我建议你找第三方的产品来实现，都是现成的功能，也许就相当于你一个程序员的年薪而已。
我们需要做的是“提供给用户一个选择，而不是替用户做选择”
错，流程运行的一个重要环节就是处理人，一个好的工作流系统，必然是将处理人都定义在流程中，当然要有非常完善的逻辑关系来确定处理人，例如按组织架构，按角色，按关系等，让用户自己去选择处理人那是最后的选择，试想一下，每个节点都让用户选择下一步处理人，那和发邮件有什么不一样？让流程随意的流转，那才是不可控制的。
关于某个业务，涉及某些条件由谁批准的问题。如果能够很好地抽象出这些就可以解决这个问题。
比如说：
业务 条件 执行者
车费报销 金额<50元 科长
车费报销 100>金额>50 处长
车费报销 金额>100 局长
如果企业建立一套这样的业务规则库，系统中应用业务规则引擎迅速找到执行者，
再将其赋给工作流系统的参与者，工作流就可以运作。 工作流系统要和业务规则引擎系统，以及企业组织机构建模良好地配合，才能更加灵活和强大。
目前，我所做的权限资源管理平台正在朝这个方向发展。由于时间和精力问题，现在还抽不出精力解决这个问题，但是我想迟早要将企业的业务规则同授权系统以及工作流系统要很好地整合起来，提供更加灵活和强大的平台。
该如何做应参考实际业务中是如何处理的，而不应该局限于技术层面的东西。一般情况下，上一步处理的人取回该工作并重新提交给其他人是一种处理方法，由流程管理员参与重新调度该流程给其他人也是另外一直处理办法，甚至某人把身份密码高速其他人去处理也是可行的方案:)
总之，结合实际业务去考虑，不应停留在技术模型本身。
我们需要做的是“提供给用户一个选择，而不是替用户做选择”
以前做过一个Jbpm工作流的应用，流转时，是将工作流转到一个节点，然后系统根据用户是否有处理该节点的权限，来控制他是否可以处理该工作。这样的话，当一个处理人不能处理该工作是，只要将其他用户授权该节点，他就可以处理该任务了。
如果在流转时，是将工作直接流转到用户，那么当一个用户不能(比如出差)处理时，那么这个任务就只能够停止，一直等到处理人能够处理
这是因为你没有遇到复杂的流程，如果用户要求你自定义流程，自己写实现是“基本”不可能的
^_^
还是自己编码来得放心。
我们需要做的是“提供给用户一个选择，而不是替用户做选择”
二、如何对参与者进行动态解析？
这应该由“工作项管理系统”(workitem manager)负责。jbpm有，osworkflow就没有，它通过扩展机制让用户自己处理（内置了的几个简单实现）。
什么是对参与者动态解析
最近也在考虑个工作流的架构，不过主要是从实用角度去想的，还没考虑到wfmc标准那些。。。
同意你的观点，这个是我没有分的太清楚，我是初衷就是为了能够把业务和流程做一个比较好的合并工作，因为我发现很多和业务关系很密切的的公文流转（举例）都是基于流程步骤的，也就是说某一个步骤的工作在流程图的表现太过于独立，而往往这个是不现实的！
我设想加入步骤的关联性，任何一个步骤的工作交给下一个步骤之后，这个步骤的工作并不完全的独立，所以我提出了“成对的步骤”（可能不是特别的确切）这么一个概念，任何一个步骤的工作都必须同时对上一个步骤和下一个步骤同时负责！
至于我最开始的所说的流程中“参与者”这个概念是经过你的讲解，我觉得你是对的，这样的话就解耦了我自己的设想，使我从这种错综复杂的关系中解脱出来！非常感谢！
我想我还是很理解你的困惑的，如果我没有猜错的化，你可能在做的工作流实施，是在电子政务行业或者某些领域的OA办公审批流程（如：公文收发之类）。
你所说的这种需求，在电子政务领域是比较普遍的，特别是“公文流转”。有时候，很难用一个业务性的流程来诠释“公文审批”。这样的审批总是围绕着“谁签？谁办？”在进行的。——也就是说，从大的审批流程过程来说，诸如“科员-->科长-->处长-->局长-->司长”（当然，中间总会穿插一些秘书或办公厅之类）。这样的过程是不会改变的，也不可能改变（组织的权限、级别的限制）。—— 但是，到底是哪些处长签、哪些局长签呢？这是无法用“预先定义的参与者来诠释的（很高兴你使用用参与者这个专业术语）”。
但是，任何事情，都会有“规章可循”。即使像公文这样“人为主导”的流程应用，也依然有流程的踪影：“科员-->科长-->处长-->局长-->司长（从组织角度看）”；“拟稿-->审核-->部门内会签-->审核-->会签--签发（从业务流程角度看）”（一个复杂的发文流程图，可以看看http://upload.mop.com/user/2005/05/27/843737ce.gif）。
这两者总是结合的，但有一点是不变的：引擎是站在流程的视角，至于参与者，则可以通过外围手段解决：简单的办法，允许动态创建工作项；复杂的办法，允许动态创建活动实例；再复杂的办法，连某一个“模型”都到动态创建。—— 但这，不会影响引擎的对流程的调度计算。
==================================
国内的流程，“人为因素、组织因素”影响很大。很多流程还依赖“人治”。这是西方的“流程系统”所不能领悟的。
时间关系，不再深入阐述。你所说的这个还只是“业务性问题”。这种业务场景，已经被很多工作流厂家很好的解决了：前参与者执行、动态角色、动态创建工作项、加减签处理、会签处理、多级流程、多流程实例独立等等等，反正很多很多。
胡长城（银狐999）
http://www.javafox.org
这样就基本可以完成workflow了，可是实现的时候做的不好
出现这个问题的原因是我们要对流程的定义进行复用，复用的方式有很多，这个只是一种；我们可以采用其它的方式，不如引入模板的概念，使用复制而不使用实例化的方式；优势是显而易见的，复制的方式更加灵活！
满足了复用的需求，自由度也有所提高
关于动态解析的问题比较好解决，我们根本不需要它自动解析，当步骤在没有被激活之前知道具体的参与者是没有意义的，因为太早指定具体参与者的时候如果这个人有别的工作还没有做完怎么办？我们再指定其它参与者吗？这样是不是徒增了流程的不确定性？而且决策者（或者发起人）往往不可能做这么具体的工作的，如果真的需要知道具体的参与者，也是在工作流结束（运因可能是失败了要追究责任，成功了要保障，或者是要查看资源是否有浪费等等），这也是在完成以后的事情，没有必要在开始的时候就指定的！
设想参与者是一个组织的话，那么这个组织只要有一个负责人，其它的参与者就由他指定（或者自己去领取工作）就可以了！他向决策者直接负责就可以了！
所以动态解析是一个比较乌托邦的想法，太美丽了，可是不现实啊！
谢谢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，通知其继续流转。