工作流？BPM？云中的流程？这是个问题? 我认为从概念上进行一定的区分是必要，因为每个产品都有其理念和想解决
工作流？BPM？云中的流程？这是个问题
?
我认为从概念上进行一定的区分是必要，因为每个产品都有其理念和想解决的问题，了解一个产品最好的方式就是看它的历史和要解决的问题。
另外，我也同意你的部分观点，从技术上讲，大部分BPM都是从工作流发展而来，它们之间从技术实现上说并没有明显的差异。可是如果依旧以工作流的方式来解决BPM想解决的问题，这是存在问题的。 4 楼 comsci 2009-12-05 其实我对BPM的概念并不是非常了解，可以说还比较模糊，希望老大能够多转帖点关于BPM概念的文章，让我们学习学习 5 楼 comsci 2009-12-15 无论是什么XPM还是XPDL，始终要运行，一旦运行起来，其控制运行的系统就成为整个系统的核心部分，前面的XML定义语言就没有什么作用了，而我看无论是BPM还是XPDL这些规范都是在说流程设计过程的规范，而从来没有看到过在后期运行控制方面的问题？ 是否请楼主提示下 6 楼 ronghao 2009-12-15 comsci 写道无论是什么XPM还是XPDL，始终要运行，一旦运行起来，其控制运行的系统就成为整个系统的核心部分，前面的XML定义语言就没有什么作用了，而我看无论是BPM还是XPDL这些规范都是在说流程设计过程的规范，而从来没有看到过在后期运行控制方面的问题？ 是否请楼主提示下
这些规范本身就只是规范对流程进行xml建模的，你说的运行期的管理和控制属于其他的范畴，这个我认为倒不大可能形成规范，因为涉及的内容太多，只能从大的方面进行约束，例如工作流系统的5个接口、组成等等。
7 楼 comsci 2009-12-26 就我目前看来，前一个阶段基于对流程设计阶段的XML规范标准的这个门槛，已经在国内失去它应有的作用了，那么今后一段时期对工作流产品市场的竞争，将在什么领域，什么层次上面展开，请各位老大一起来讨论下。。。。
我想很多工作流产品开发企业现在都面临市场上同类型产品的激烈竞争，上面的这个问题也许值得我们认真思考。。。 8 楼 comsci 2010-03-09 XPDL中对流程数据的定义，有些显得过于冗余，一般来讲，完全可以根据自己的业务需要自定义一个XML规范。。。 9 楼 comsci 2010-03-11 BPM如果能够在工作流系统的基础上面增加一些东西，比如说流程运行上面的管理，流程的效率方面的控制，关键是如果能够增加流程与其它应用平台的接口，那么BPM与WF的这种结合是非常有利的。。。 10 楼 nychen2000 2010-10-14 引用实际上，工作流软件与 BPM 软件最大的区别不在于技术实现，而是它们解决的问题域发生了变化。
确实是二者的本质区别，非常认可荣昊兄的简介。
引用因为解决的问题域发生变化，那么 BPM 软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。
此处，我感觉“强调快速的开发能力”改为“强调业务系统的柔性”更为恰当。我并不是鸡蛋里头挑骨头的意思，因为“强调快速的开发能力”导致了很多厂商的BPM产品出现一个共同的致命的弊端，就是改变了大家喜闻乐见的变成模型，搞出来一条私有的很封闭的所谓“免编程”的东西；这种产品在开发人员群体里面是没有生命里的，最终用户实际上也不会用、不屑用。所以，用“强调业务系统的柔性”更合理，它更能体现业务价值。 11 楼 ronghao 2010-10-16 引用因为解决的问题域发生变化，那么 BPM 软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。
此处，我感觉“强调快速的开发能力”改为“强调业务系统的柔性”更为恰当。我并不是鸡蛋里头挑骨头的意思，因为“强调快速的开发能力”导致了很多厂商的BPM产品出现一个共同的致命的弊端，就是改变了大家喜闻乐见的变成模型，搞出来一条私有的很封闭的所谓“免编程”的东西；这种产品在开发人员群体里面是没有生命里的，最终用户实际上也不会用、不屑用。所以，用“强调业务系统的柔性”更合理，它更能体现业务价值。
谢谢！你的意见非常好，这里确实不太恰当，本质上要解决的是业务问题。我个人也很反对所谓图形化的快速开发平台。
我现在越来越觉得BPM做B2B的集成非常非常重要。
12 楼 GRDJE 2010-10-16 ronghao 写道引用因为解决的问题域发生变化，那么 BPM 软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。
此处，我感觉“强调快速的开发能力”改为“强调业务系统的柔性”更为恰当。我并不是鸡蛋里头挑骨头的意思，因为“强调快速的开发能力”导致了很多厂商的BPM产品出现一个共同的致命的弊端，就是改变了大家喜闻乐见的变成模型，搞出来一条私有的很封闭的所谓“免编程”的东西；这种产品在开发人员群体里面是没有生命里的，最终用户实际上也不会用、不屑用。所以，用“强调业务系统的柔性”更合理，它更能体现业务价值。
谢谢！你的意见非常好，这里确实不太恰当，本质上要解决的是业务问题。我个人也很反对所谓图形化的快速开发平台。
我现在越来越觉得BPM做B2B的集成非常非常重要。
你去看看国外做集成的的软件哪个没BPM啊..... 13 楼 daquan198163 2010-10-16 GRDJE 写道ronghao 写道引用因为解决的问题域发生变化，那么 BPM 软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。
此处，我感觉“强调快速的开发能力”改为“强调业务系统的柔性”更为恰当。我并不是鸡蛋里头挑骨头的意思，因为“强调快速的开发能力”导致了很多厂商的BPM产品出现一个共同的致命的弊端，就是改变了大家喜闻乐见的变成模型，搞出来一条私有的很封闭的所谓“免编程”的东西；这种产品在开发人员群体里面是没有生命里的，最终用户实际上也不会用、不屑用。所以，用“强调业务系统的柔性”更合理，它更能体现业务价值。
谢谢！你的意见非常好，这里确实不太恰当，本质上要解决的是业务问题。我个人也很反对所谓图形化的快速开发平台。
我现在越来越觉得BPM做B2B的集成非常非常重要。
你去看看国外做集成的的软件哪个没BPM啊.....
集成分很多层面，常见的有数据层（ETL）、应用层（EAI）、展现层（Portal）
我想你们说的应该是应用层吧，BPM在这个层面还是可以大有作为的，尤其是很多涉及到人工操作的环节 14 楼 comsci 2010-11-01 无论是什么BPM，首先还是要在工作流这块打下基础，不能够学习某些厂商偷换概念，好像BPM和WORKFLOW是两个东西，互不沾边，呵呵，BPM是工作流的一种扩展，工作流基础打好了，BPM产品才能够做得好。。玩概念这些东西，一次两次就够了，玩多了就没有意思了 15 楼 Alexyin_sc 2010-11-10 如果工作流管理从一开始就被称为“BPM”，那么现在关于这两个术语的争论就不会那么激烈了。个人认为，在理论上，WFM和BPM所需研究的问题并无本质区别，只不过称为BPM可能更容易被非IT人士所接受。
“新瓶装老酒”（Old Wine in New Bottles，这篇文章网上有）这是曾经的WF权威Aalst最初对BPM看法。遗憾的是，Aalst在其后续文章中也多是谈BPM而很少提及WF，可能也是随大流吧。更有争议的文章还有《Workflow is just a Pi process》，《Why workflow is NOT just a Pi-process》等等，这些也都是几年前的事了，但其中反应出的问题是：无论BPM还是WFM，都仍然没有一个各方公认的数学模型，包括过程结构模型和引擎的驱动模型等等，尤其在人工活动的协调方面更显不足，而像数据库事务那样能够保证过程执行正确性的机制几乎没有。我相信，未来BPM方面的创新源动力应该是来自BPM(或者WFM)基础理论研究方面的突破。
总之，WFM和BPM之间并不存在清晰的界线，市场和资本更需要新名词。
