|
锁定老帖子 主题：工作流？BPM？云中的流程？这是个问题
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-10-14
引用 实际上，工作流软件与 BPM 软件最大的区别不在于技术实现，而是它们解决的问题域发生了变化。 确实是二者的本质区别，非常认可荣昊兄的简介。 引用 因为解决的问题域发生变化，那么 BPM 软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。 此处，我感觉“强调快速的开发能力”改为“强调业务系统的柔性”更为恰当。我并不是鸡蛋里头挑骨头的意思，因为“强调快速的开发能力”导致了很多厂商的BPM产品出现一个共同的致命的弊端，就是改变了大家喜闻乐见的变成模型，搞出来一条私有的很封闭的所谓“免编程”的东西；这种产品在开发人员群体里面是没有生命里的，最终用户实际上也不会用、不屑用。所以，用“强调业务系统的柔性”更合理，它更能体现业务价值。 |
| 返回顶楼 | |
|
发表时间：2010-10-16
引用 因为解决的问题域发生变化，那么 BPM 软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。
此处，我感觉“强调快速的开发能力”改为“强调业务系统的柔性”更为恰当。我并不是鸡蛋里头挑骨头的意思，因为“强调快速的开发能力”导致了很多厂商的BPM产品出现一个共同的致命的弊端，就是改变了大家喜闻乐见的变成模型，搞出来一条私有的很封闭的所谓“免编程”的东西；这种产品在开发人员群体里面是没有生命里的，最终用户实际上也不会用、不屑用。所以，用“强调业务系统的柔性”更合理，它更能体现业务价值。 谢谢！你的意见非常好，这里确实不太恰当，本质上要解决的是业务问题。我个人也很反对所谓图形化的快速开发平台。 我现在越来越觉得BPM做B2B的集成非常非常重要。 |
| 返回顶楼 | |
|
发表时间：2010-10-16
ronghao 写道 引用 因为解决的问题域发生变化，那么 BPM 软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。
此处，我感觉“强调快速的开发能力”改为“强调业务系统的柔性”更为恰当。我并不是鸡蛋里头挑骨头的意思，因为“强调快速的开发能力”导致了很多厂商的BPM产品出现一个共同的致命的弊端，就是改变了大家喜闻乐见的变成模型，搞出来一条私有的很封闭的所谓“免编程”的东西；这种产品在开发人员群体里面是没有生命里的，最终用户实际上也不会用、不屑用。所以，用“强调业务系统的柔性”更合理，它更能体现业务价值。 谢谢！你的意见非常好，这里确实不太恰当，本质上要解决的是业务问题。我个人也很反对所谓图形化的快速开发平台。 我现在越来越觉得BPM做B2B的集成非常非常重要。 你去看看国外做集成的的软件哪个没BPM啊..... |
| 返回顶楼 | |
|
发表时间：2010-10-16
GRDJE 写道 ronghao 写道 引用 因为解决的问题域发生变化，那么 BPM 软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。
此处，我感觉“强调快速的开发能力”改为“强调业务系统的柔性”更为恰当。我并不是鸡蛋里头挑骨头的意思，因为“强调快速的开发能力”导致了很多厂商的BPM产品出现一个共同的致命的弊端，就是改变了大家喜闻乐见的变成模型，搞出来一条私有的很封闭的所谓“免编程”的东西；这种产品在开发人员群体里面是没有生命里的，最终用户实际上也不会用、不屑用。所以，用“强调业务系统的柔性”更合理，它更能体现业务价值。 谢谢！你的意见非常好，这里确实不太恰当，本质上要解决的是业务问题。我个人也很反对所谓图形化的快速开发平台。 我现在越来越觉得BPM做B2B的集成非常非常重要。 你去看看国外做集成的的软件哪个没BPM啊..... 集成分很多层面，常见的有数据层（ETL）、应用层（EAI）、展现层（Portal） 我想你们说的应该是应用层吧，BPM在这个层面还是可以大有作为的，尤其是很多涉及到人工操作的环节 |
| 返回顶楼 | |
|
发表时间：2010-11-01
无论是什么BPM，首先还是要在工作流这块打下基础，不能够学习某些厂商偷换概念，好像BPM和WORKFLOW是两个东西，互不沾边，呵呵，BPM是工作流的一种扩展，工作流基础打好了，BPM产品才能够做得好。。玩概念这些东西，一次两次就够了，玩多了就没有意思了
|
| 返回顶楼 | |
|
发表时间：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之间并不存在清晰的界线，市场和资本更需要新名词。 |
| 返回顶楼 | |
