工作流模型需要有突破

我常常面对这样的问题：为什么要用工作流呢，写死在代码里面也可以啊，或者用个状态字段也可以搞定。

 

我乍一想这个观点似乎也很有道理，很多工作流系统用上去之后反而带来了更多的麻烦，那种宣传上的“业务敏捷性、流程自定义”被流程系统的复杂性摧毁的一干二净。

 

所以，我个人认为工作流系统首先应该达到的目标就是：要使得应用工作流的项目“易维护、易扩展” 。

 

这个易维护易扩展当然不是想当然的“流程自定义”，而是开发商花较小的代价就能调整系统，以适应需求的变化。要达到这个目标，工作流系统的设计是最关键 的。至于是否遵守所谓的XPDL、BPMN、BPEL标准一点都不重要。

 

但是从业务的角度来说，最终用户需要的是什么呢？业务敏捷性 当然没错，还应该包括对现有流程运行监控 、运行结果的反馈 、业务资源的使用状况 等等。

 

要满足这个需求，我认为最关键的是流程模型必须提供良好的支持 。我感觉不论是XPDL,BPEL还是BPMN，都把重点放在了流程运行控制的结构的设计、流程交互的设计上去了，都是从程序运行的视角来看问题。BPMN貌似好一点，但是太复杂。当然，你可以认为他很强大。我个人认为，任何一个东西如果“强大”到别人不会用，“强大”到任何一个企业必须聘请顶尖人士来维护他，那就没有意义了！

 

所以，我个人认为，工作流的模型需要突破，需要一种简明扼要的模型。

 

说的很对。

工作流引擎是一个模块，在这个基础上，还需要考虑很多管理问题

关键是小公司的工作流系统时常变动，经常修改，只要能做到便于修改就行了吧！

我觉得也是，感觉简单的东西让工作流给复杂化了。

有的系统其实就是 领域的生命周期管理 但是往往设计为工作流，工作流重在协作，而不是改变周期状态。

BPMN是给业务人员用的，设计出的是不可执行的业务流程，没说必须企业顶尖的人用啊。
不支持这些标准xpdl,bpel,bpmn的产品怎么跟别人的产品竞争，jbpm现在不也在支持标准吗。
硬编码实现的工作流，当流程改变的时候，不容易修改。要实现流程的图形化监控，流程的终止，暂停，流程的分析，比较难。

其实我的观点说得简单一点就是：

1、现在很多工作流产品，尤其是那些声称遵守标准的产品复杂的让人吐血，这种复杂性摧毁了一切它所宣传的优点。因此从这个角度说，这可以算是标准的“副作用”。

   jbpm的成功在我看来就是因为他不遵守标准，实用至上，尽管有位兄弟列举了jbpm的“N大罪状”，但是jbpm还是“一篮子烂苹果中较为不烂的”。jbpm4遵守标准也不是完全遵守，而是挑了一些简单的Notation，BPMN的所有Notation只有那些学者才搞的懂，记得清，要一个企业的用户去弄明白，简直不可能。


2、现在的标准即使如此复杂，还是没有很好的解决最终用户关注的“业务敏捷性、流程运行监控 、运行结果的反馈 、业务资源的使用状况” 等等需求，是什么缘故呢？
 
   是引擎开发者开发的不够好吗？

   个人感觉很有可能是标准自身的问题，这个标准没有为这些需求提供很好的数据模型。

所以，我的结论是：工作流模型需要突破，需要简明的，扼要的模型。

另外，在BPM领域，没有遵守规范就不能和别人竞争的神话早就破灭了，记得2003-2004年间，WfMC的XPDL风靡一时，言必称“WfMC标准”，大家可以看到，现在XPDL在市场上落魄到什么程度！

因此，我认为，工程实用性是检验一切规范的唯一标准。

业务导向；实务导向是根本的

国外基于数学模型的工作流是不适合中国的国情的，实际上国内工作流难做就在于，破坏规则的都是企业领导

我感觉“数学模型”只是工作流模型的一个方面，还该包括数据模型，资源模型等。但是数据模型和资源模型做到什么程度，是一个值得探讨的问题。