这两者是很有争议的，区别也越来越细微，但有必要澄清。
工作流的概念产生得比业务过程管理早，它起源于办公室自动化，可以追溯到60年代底和70年代初。它强调业务过程的自动化，
因此在不需太多人工干涉的业务过程上用得比较多。
业务过程管理的概念是在 Michael Hammer, James Champy， Tom Davenport, 和 H. James Harrington等一些人在90年代初提
出的过程再造和改进等概念的基础上产生的，它强调过程，但不管是什么过程。
业务过程管理包括对业务过程的分析，计划，设计，实施，运行，监控，和仿真各个方面。相较于工作流，它更属于是管理和组
织的概念；而工作流则侧重技术层面的实施和运行业务流程。从这种角度看，工作流可以说是业务流程管理的子集。基于这两个
概念，现在有工作流管理系统（Workflow Management System)和业务过程管理系统(Business Process Management System)。
这两种系统的区别就在于工作流管理系统只能定义和运行业务过程，而业务过程管理系统还能监控运行的业务过程和分析评价业
务过程的效能。
老余认为工作流只是个过渡的概念；但我觉得工作流还会存在和发展，而工作流管理系统会成为业务过程管理系统的一个子系
统，甚至会是核心系统。

我提到工作流是过渡型概念，新明博士似乎不很赞成我这个说法，在业内，简单抛出这个说法，不同意甚至不屑的口水也许足以
把我淹死。但这个想法于我却是由来已久，今天借此检视一下。（因为这里的文字是公开的，所以我加了参考注释，方便不在这
个语境中的人看。）

工作流（workflow）在国内，正热火朝天，很像曾经的OA（Office Automation，办公自动化）热。实际上，我发现 OA 这个概
念在中国比外国流行[1]。Michael Hammer 1990 年发表在哈佛商业评论那篇经典论文“Reengineering Work: Don't 
Automate, Obliterate”几乎可以说是直接宣判 OA 这个概念的死刑（不了解背景的朋友可参看[2]）。但中国大陆情形不同，
这里的开发商集热衷于办公室应用开发时，并没有受到BPR的什么影响，而且与Lotus/Domino流行，以及B/S架构热衔接上，而且
这条线又联系到了工作流。这应该是中国大陆独特的条件、机会下独特的发展方式。若在简体中文网站中搜索一下，会发现各种
基于网络的办公系统，并宣称支持工作流的，多不胜数，而另外比较“有水平的”，则利用Lotus/Domino为开发平台。还有一类
创新力更强的，则自己开发工作流引擎。有些软件虽然起了个更深奥的名字，但基本功能仍然是办公系统，很多圈内人在比拼谁
的工作流好，却不是以用户感受做评价标准。

其实我对工作流并没有任何歧视，相反，差不多5年前，我认真地考察了工作流的概念，并关注到它与 BPR 间内在或实践上的关
系等[3]，在这篇文章中，我有这样的叙述：
“实际上，已有的关于工作流体系的描述，本身就是一个通用的业务模型框架。仅仅囿于工作流是不够的，必须对整个体系的目
标及所有相关要素综合考虑——这正是企业工程。”

新明在上面的贴子中说：
“我觉得工作流还会存在和发展，而工作流管理系统会成为业务过程管理系统的一个子系统，甚至会是核心系统。”

这与我在98年末的时候所持观点很像：
“近年发展起来的‘工作流管理系统’，最有希望成为未来信息系统的事务处理核心架构”[4]

可以说，现在国内的发展，正在证明着这个“预言”。但后来对此我的看法有了一些改变。基本上我认对“业务过程”的支持是
企业应用的重要、核心的功能，但这是在一个整体的企业解决方案（或称架构）基础上实现的功能之一。既往的、独立发展的工
作流技术和实践，是一种可借鉴的预演，只能被消化吸收或借鉴。在这个意义上，它是一个过渡。这里提出几个理由：

1）Workflow是一个“计算机”的概念

计算机的概念发展而被企业管理者接受是完全可能的。但对 workflow，这条路几乎断了。因为有势大力沉的业务过程再造工程
（BPR），和继承 BPR 的业务过程规划、业务过程工程、业务过程管理。作为一个企业管理的概念，工作流是不完整的、暧昧
的。会被管理界接纳的一定是后者，workflow 若不是溶入后者，就要甘愿沦为一个技术性概念。而作为一个技术性概念，它似
乎又不纯粹，又可能变成空中河流，为找到适合的陆地而发愁。我认为workflow在管理理论里没什么存在的必要，在软件领域还
要看。

2）Workflow太早熟、独立了

工作流的发展在整个企业应用、企业体系的大情境中独树一帜。这种自成一格，容易在早期立足，但当企业应用发展到一定水
平，从整体去考虑时，这种局部的过渡优化和独立性、成熟性就是溶入大体系的障碍。而且这种障碍还可能实际地来自那些拥工
作流而自立的“领导厂商”、“权威组织”。保持自己的优势，让别人来“集成”这种努力是一定会做的，但最终系统不会对个
体让步，要加入一个进化的、有机的系统，一定要放弃掉部分自身的封闭、独立性。

3）Workflow的商业背景

我觉得Workflow是一个商业上比较成功的例子。商业概念一定是阶段性的，除非在非商业领域有足够的存在价值。工作流在管理
理论体系、软件架构或建模理论体系中有没有一个适当的位置？这在第一点里已经讨论了。

4）Workflow的先天不足

发表了[3]、[4]之后，在对工作流和企业应用的整体架构的更进一步研究中，我发现必须先考虑一些更基本的东西，然后才有基
础去考虑过程的实现，到那时再看工作流有什么用（或该怎么用）。当对整个企业需求和解决方案有了更完整的认识之后发现，
要支持全面的业务过程（用户的），或者作为一个全面的业务过程解决方案，现有的工作流有些像一个早产儿。它本来就 不 
是 作为完整的“业务过程模型”提出的。从建模的角度说，对一个设计完整的建模架构为新的更大的目标升级，不如重新构建
一个架构，将旧的架构作为一个借鉴。


我昨天收到的金新明博士最新论文中对业务过程建模语言的一个评论：“Dilemma between user-oriented and software-
oriented”（在面向用户还是面向软件之间进退两难）[5]，我觉得这是一个很精辟的论点，恰恰是戳到了痛处。这与我上面的
一些看法一致。

毫无疑问，工作流的实用性，（尤其加上基于互联网的远程工作环境）比 OA 强很多，故有它的生存空间，在更好地支持业务过
程的应用系统普及之前，它会一直生存。但它终究只是抓住了企业应用中的一部分而已。

它是软件开发者所理解、钟爱的一个精致的小东西，基于网络的分布式应用（网上办公），甚至涉及到企业间的某些沟通，使它
找到了一个幸运的空间。但终究要被全面的、真正的“业务过程”支撑方案所替代。

国内一些应用开发企业对工作流所下的功夫令人钦佩，但对工作流的这种偏爱往往掩盖了对企业全面的、本质的业务或功能性需
求理解方面的不足。更本质的问题是，工作流的这种发展，将许多国内开发者、用户继续引向国外在90年代初就彻底反思、扬弃
的“自动化陷阱”。


[参考]

[1] 企业信息化的N个陷阱, http://ee-forum.org/eita_ntrap.html
[2] 重规划是什么, http://www.ee-forum.org/bpr0.html
[3] 工作流是什么, http://www.ee-forum.org/wf0.html
[4] 迈向21世纪的企业信息技术应用, http://www.ee-forum.org/eis21c.html
[5] Jin Xinming, Scenario-based comparison and evaluation: issues of current business process modelling 
languages

最近，刚刚完成本人的博士论文－－电子政府架构研究，这实际上是企业架构在电子政府中的应用。在研究期间，本人研究了各
类企业架构，如TOGAF，FEA，CIMOSA，InfoCitizen，SAGA等和各类企业建模技术，结合现代SOA，BPM技术，建立了自己的电子
政府架构。在研究过程中，对BPM和工作流之区别也阅读了大量文献。可以说讨论是非常模糊的。
   我认为，二者的区别可以从理论和实践两个方面来看。

从理论上说，BPMI的一个重要成员Harvard Smith发表了一篇引起广泛争议的文章－－workflow is just a Pi-calculus.其基本
观点是BPM和工作流系统的数学基础不同，现代BPM主要基于Pi-calculus，而大多数工作流系统基于PeriNet，进而说明现代BPM
比工作流系统具有优势。但是，工作流管理联盟的主席Jon Pyke 立即发表了一篇反驳文章－－Does Better Math Lead to 
Better Business Processes?世界最顶尖的人物在此争论不休，你觉得其它人还能说清楚吗，他们的争论见
http://www.workflow-research.de/Forums/index.php?act=ST&f=10&t=28&s=704051af9b67ad7d72ddeab3b4c9195a
而本人倾向与利用数学基础区分BPM和工作流系统的方法。

从实践上说，许多基于PetriNet的系统也声称为BPM产品，我的感觉是传统工作流系统缺乏跨应用、跨系统的集成能力，对现代
集成的核心技术Web服务支持不是非常自然（因为它出现在Web服务之前），因此，从实践上区分BPM和工作流系统就看它是否自
然支持Web服务、是否支持跨应用集成的能力。当然，工作流系统也在演进，未来BPM和工作流系统在实际功能上的区别可能模
糊，到时大家也许就不必在争论了。

真高兴这里又多了一名专家朋友。希望以后多多探讨！

秦先生提出以“数学基础”区分BPM和工作流系统的观点，我也十分感兴趣，以后有机会向你请教。

但无论如何，这是“技术层面”的探讨。它们虽然重要，但更成问题的问题，却不是技术问题。

工作流、业务流程管理本身就不是纯技术课题，它们的价值，不是取决于技术的成就，而是用户——企业，企业中的业务人员，
企业中的管理人员——它们感受到的价值。技术必须为这个目标服务。

秦先生指出技术的问题所谓的“顶尖人物”争论不休，别人还能说清楚吗？
也许吧。不过我还关心另一个方面的问题，作为“应用”技术，它的前提是否已经清楚了？

从老家回来，上论坛来看，本是想推荐一个帖子的，是一名法律工作者发在自己的网络日志《素为法学》上的一篇题为《需要怎
样的办案软件》的日志，网址为 http://www.verylaw.com/lawblog/index.php?job=art&articleid=a_20050411_204302 

作者在日志中叙述到：

“虽然各家软件公司都声称，他们是经过长期在各级检察机关体验生活之后才编写了办案软件，但事实的情况是，没有几个办案
干警买他们的帐，甚至有个干脆就认为办案软件是‘脱裤子放屁’。”

“抛开一些诸如‘思想老化’干警本身的因素不说，事实上那也只是个次要因素，关键的问题是，除了能节省几张纸（甚至连纸
也不可能节省，因为装卷存档的文书依然要打印出来的），很难说办案软件给我们的工作带来了多少方便。”

对任何产品开发者，这种用户的真实体验和思考，应该是宝贵财富。

再谈谈从应用上的区别。
现代BPM强调BPM系统应支持的几个最重要的特性：
1 流程可视化（使用BPMN、UML等）
2 流程操作独立化，即能够象关系数据库系统操作表一样操作流程
3 流程直接部署运行（从可视化的BPMN映射到WS4BPEL）
4 流程跨应用集成（与其它流程和Web服务）
5 流程监控
Harvard Smith特别强调基于Pi-calculus（一种过程代数语言）的BPM系统特别适合流程操作独立化，能够使得各家系统能够以
一致的方式操作流程。但我发现工作流产品实际上也能做到这一点，但是各家系统之间的操作模式是不一致的。Harvard Smith
认为，如果各家都采用Pi-calculus，那么现代BPMS就会取得类似关系数据库系统的地位（Pi-calculus相当于关系代数）。

实际上，两大派别组织BPMI和工作流管理联盟的不同技术方向可以看作BPM和工作流的不同发展方向，我看其核心就是对Web服务
的支持。这两家最近在合作，所以似乎BPM和工作流会融合。

另外，工作流管理联盟的人一直都认为BPMI没有什么新东西，BPM不过是工作流的另一个名称而已，他们对BPM的一些宣传特别反
感，认为存是促销，缺乏严格的学术性。不错，上面列出的特性，工作流系统其实在理论上早就支持，只不过在Web服务出现之
前，实现过于麻烦，各家各搞一套，没有形成统一的模式。而Web服务、XML出现后，BPMI抓住这个技术机遇，引入BPM概念，得
到微软、IBM、BEA等大厂支持,前景看好。（微软的Biztalk早期基于Pi-calculus，IBM的WebSphere基于PetriNet，后来两家和
搞的Ws4BPEL数学基础融合了Pi-calculus，PetriNe）。

另外，现代信息系统的体系结构我有一篇文章在“程序员”杂志2005第一期，可参见。

秦先生的再论要谈应用上的区别，却把我们引向了更深的技术层面，直至数学基础的层面。

在秦博士的论域中，基本把这二者放到一个纯技术的层面。

而在金博士的某些讨论（我前面帖子提到，拜读的金博士的论文）中，对“面向软件”还是“面向用户”做了分析。

我的关注点，从最终的目标的用户开始，探究为了达成用户、应用的目标或利益，需要什么，欠缺什么，有什么疑问，寻找适
合的技术方案。所以，在没有搞清具体的应用目标或需求之前，我一般不会深入地讨论技术的细节，同时也不倾向于或排除任
何技术。前面我对工作流的一点讨论，也主要是基于用户视域中的应用、功能或产品的角度，包括管理的概念角度着眼。

上面的一些讨论，着眼点或层次、定位不尽相同，但每个层次上展开都是有意义的。

前面，我提出了区别工作流和BPM的两个方法
1 从数学基础区分
2 从跨应用集成能力区分
但是，这两个方法对用户选择系统似乎过于模糊，所以，我碰到厂商宣传时，主要看其支持的核心标准，我问
3 你的产品支持BPMI的标准（主要是BPEL4WS尽管这个标准不是BPMI提出的，但得到BPMI支持、或BPML）还是支持WfMC的标准
这就是我区分BPM和工作流的实用标准。

当然，余先生想从一个更高的管理层次来区分，我认为这里不可能存在严格的各方一致的区分标准。

余先生说其“关注点，从最终的目标的用户开始，探究为了达成用户、应用的目标或利益，需要什么，欠缺什么，有什么疑问，
寻找适合的技术方案。所以，在没有搞清具体的应用目标或需求之前，我一般不会深入地讨论技术的细节，同时也不倾向于或排
除任何技术。”这实际上是任何一本理论教材都强调的，而我认为恰恰这里过于忽视了技术的重要性，理论探讨主观性的、定性
的东西太多。一些突破性技术的出现，往往会推动管理和应用前进一大步，正如工作流管理联盟的主席Jon Pyke 所说，工作流
系统其实老早就出现了，其理论非常吸引人，热过一阵子，但90年代沉寂下去了，这是因为技术条件的限制导致其无法实现其理
论承诺，而近几年，工作流又热起来了，为什么，因为新技术能力使得其似乎可以实现其理论承诺了。现代工作流系统或BPM系
统可以实现如下特性：
1 流程可视化（使用BPMN、UML等）
2 流程操作独立化，即能够象关系数据库系统操作表一样操作流程
3 流程直接部署运行（从可视化的BPMN映射到WS4BPEL）
4 流程跨应用集成（与其它流程和Web服务）
5 流程监控
注意，这些特性都是以流程为中心的，现在流程不再硬编码于程序代码，而是可视化在BPMS中，这就使得流程真正成为企业可管
理的资产。从企业战略到业务流程到Web服务，即从业务到技术的联系被清晰地展示出来，这一切，都归功于BPM技术的发展。

现代BPM的上述特性实际隐含了另一个最重要的特性，即现在，流程的动态调整不再费时，费力了。
这是所有以流程为中心的管理理论如BPR能够成功的一个基本前提。
没有这一点，理论承诺就难以实现

作为用户，甚至作为一个向用户提供产品与服务的供应商，为何要区分什么是workflow或BPM呢？为何要澄清它们的数学模型
呢？应用技术必须为用户服务，达到这一目标，完全可能有多种途径、多种技术或多种风格……

无疑，某些用户需求，是必须由某些特定的技术才能实现的；而新的技术，带来了全新的可能性，可以彻底改变用户本来的做事
方法甚至做的事情——这个认识，就是以“再造工程”（reengineering）为代表的思潮中的精华部分。

但观察现实普遍的情形，我认为不是偏向轻视的一边，而是偏向了轻视用户的一边（workflow，甚至秦先生所提到的BPM方面的
一些工作，从侧重、深度的角度看，我认为也体现了这种倾向），我将这种倾向概括为“概念驱动、技术导向”，并针它提出
“用户导向，技术驱动”的方针。

进一步的思考，由于新技术背后的新可能性不可能由不掌握新技术的人提出，同时用户做事的新方法也不可能由非用户业务专家
的技术者完成，所以必须有一些跨领域的专家来做这种结合、创新的工作。从思想和方法论的角度，我把这些跨领域的专家的工
作概括为“实质性需求分析与研究””（Essential Requirements Analysis and Research, ERAR，也可简称为需求研究）。

如果说管理理论，“以流程为中心”，是现代企业管理思想的一个基本特点，并非从BPR开始，也不是基于workflow这样的概
念。（本论坛上的《过程中心观》http://www.ee-forum.org/pc0.html专门讨论了这个话题）

而workflow恰恰因为不是真正的“业务过程”，而是所谓自动化过程，而与“管理”拉开了距离。BPM在字面上，距离近一些，
但如秦博士所提出的那些研究，说明它（至少一部分）也在走workflow的老路。

从企业管理或企业建设层面讨论，强调“自动化”、“可集成”甚至还可加上“基于互联网”的计算机化流程及流程规划、管理
仍然是次要的。

我所提出的“用户导向、技术驱动”就是站在一种兼顾的立场上，技术可以驱动，但不能脱离用户的导向。
技术驱动的最终的结果，将是使某些可能令应用者取得更大收益的技术没有得到发展或充分的应用。

最平白不过的例子就是企业电脑、操作系统一次一次的被迫升级，却常常做着多年前一样的事情。

精通技术的人，还可以探讨一个例子，就是E.F. Codd的“数据银行”（data bank），我认为它最卓越的方面还没有充分得到发
挥——就是他对于应用（而非技术）的卓越构思部分。这是一个例子，即所构思的新的应用，必须发展一些技术才能实现——由
于人们对他的应用思想有所忽略，因而也对这一技术的发展有所侧重，而忽略了其中一些部分（体现在Codd12条规则中某些被认
为难以实现的部分）。

首先，我并不否认“用户导向、技术驱动”，这篇帖子本想对工作流和BPM做一个学术上的澄清，看了余先生的下面一句话

“作为用户，甚至作为一个向用户提供产品与服务的供应商，为何要区分什么是workflow或BPM呢？为何要澄清它们的数学模型
呢？应用技术必须为用户服务，达到这一目标，完全可能有多种途径、多种技术或多种风格……”

我才知道，余先生是想从用户的角度来区分。那么我就谈谈自己的看法。
的确有许多厂商，包括传统的工作流厂商现在在推销产品时都宣称自己的系统是BPM系统，用户往往对BPM和工作流的区别云里雾
里，于是各类从管理角度提出的所谓区别应运而生了，如前所述，由于在这个层次事实上并无严格的区别，所以单单问你是BPM
还是工作流是毫无意义的。例如，有人会说工作流系统没有跨应用集成能力、不能集成人员手工流程，没有流程监控能力，但
是，这都是以前的工作流，一些现代工作流厂商产品实际上已具有了这些能力。在欧洲，事实上人们还是习惯于用工作流的术
语。

因此，从用户的角度，我觉得没必要从名词上区分两个概念，重要的是自己需要的功能产品是否支持，仅此而已。否则就会被厂
商推销搞昏头。我前面列出的一些特性都是可供参考的。

“而workflow恰恰因为不是真正的“业务过程”，而是所谓自动化过程，而与“管理”拉开了距离。BPM在字面上，距离近一
些”这句话也是说传统的工作流，仅代表一些厂商或咨询人员的观点，是不会得到现代工作流厂商认可的，因为现代工作流系统
和BPM系统已在考虑将非自动化的流程融合在系统中了。

秦先生这句话：“因为现代工作流系统和BPM系统已在考虑将非自动化的流程融合在系统中了。”正接近或印证了我的基本看
法：至少在传统上（包括现在的相当一部分workflow也许还可以包括一些BPM开发者），是把它们作为一种软件技术为主的概念
看，并且隐含着强烈的自动化理念。对所谓“非自动化流程融合”的问题——是“已在考虑”——当然是必须、不得不考虑的。

我的看法（本主题第二个贴子的主要意思）恰恰是从这个点开始的：

站在更完整的企业应用系统的考虑上，会发现过往发展得相当好、相当成熟的workflow技术，是需要某种改造的。而从我个人的
研究看，作为一种建模的体系和“模型驱动”的应用体系，为了达成一种高度用户化的、用户立场可以充分理解、操纵的、人机
真正交互结合的业务过程（business process, 最好不用流程或flow）支撑方案，改造这种基于自动化理念发展起来的workflow
技术并非好的途径。宁可“借鉴”，当然也应该借鉴。

先要说明一下，秦博士对于workflow，BPM的一些论述，我并非不赞成，而那个层面，你显然是专家，我要向你学习。

这里想说个“题外话”，在这个时代，很多时候，我们讨论问题十分困难，因为这个时代的商业化力量实在太强悍了，反应在名
词和概念的使用上，常常使我们失去了正常讨论技术或学术性问题的概念环境或前提。基本的表现一种是“概念的泛化”，还有
一种是“字面翻新”。

概念的泛化，比如所谓ERP。泛化的基本动力来自于一种商业利益的保护和吵作，以某种“概念”来标识自己的产品，是很流
行、有效、甚至必须的做法，然后，随着发展，就不断地更改这个概念的内涵与外延，这种人为的偷换打乱了自然语言中对概念
的正常使用。这也就是我所说“概念驱动”的一个意义：如果一个概念比较成功，得到大公司采用，大家就会一拥而上，然后一
起来“保护”它。

字面翻新方面，真正新的概念并不常有。于是很多人就玩名词游戏，不断发明“自己的概念”，将本应用同一名词表达的东西搞
得神乎其神，好像是新东西，其实大部分都是原有的东西。

“不客气”地说:)，workflow也在发生着类似的现象。BPM也难完全摆脱字面翻新的嫌疑。

这些现象造成了相当多的迷惑，并且令有效的讨论很难进行。就我个人习惯，则倾向于强调最初、原始的，或早期被明确界定的
意义，而将其后泛化的东西小心区分。

赞同您的分析，“概念的泛化”，“字面翻新”是商业界的老毛病，不过商业利益驱动，也没办法。

但真正抓住核心问题的学术争论也是有的，例如
http://www.workflow-research.de/Forums/index.php?act=ST&f=10&t=28&s=704051af9b67ad7d72ddeab3b4c9195a

由于BPMI的Harvard Smith在其论文中对基于Pi-calculus的BPM系统大家赞赏，声称其特别适合于描述动态过程（Mobile 
Process），比PetriNet好，WfMC的人认为其有推销嫌疑，要求提供理论和实践的依据，就形成了http://www.workflow-
research.de/Forums/index.php?act=ST&f=10&t=28&s=704051af9b67ad7d72ddeab3b4c9195a
研究这些争论，相信会有启发。

我认为BPM，Web服务具有突破性的意义，企业工程的权威 Clive Finkelstein 为此发表过一系列文章，他们为以流程为中心的
管理的真正实现打下了技术基础

很有价值的推荐，可惜这个论坛代码比较简陋，不支持直接链接，要剪贴到地址栏才能访问。

秦博士说的Web服务是指SOA吗？其实这是一个很朴实的思想，没有流行这个缩写名词之前，大概已经有很多东西经充分体现了这
种思想。

至于BPM，从BPR到BPM，就好像从ERP到ERM一样，从字面意义上，向“管理”靠近，是很自然的，但这种概念也很自然地会引发
你前面提到的一些质疑。

但是虽然“过程”是关注的焦点，企业毕竟不是过程本身，焦点也不能脱离整体或环境。

Clive Finkelstein等较早是从“业务驱动的信息工程”发展而来的，要是我没记错，他们提BPE而不是BPR，但其实背后的合理
或精华的思想内核是一致的，Engineering这个东西在企业管理者、业务人员那里不讨好，所以变成M更容易被接受，虽然如此，
BPM仍然不是一个自然、正宗的管理概念，还是存在着金博士所指出的那种“面向谁”的矛盾。
另一位“EE大师”James Martin，同样对BPR加以批评，但他的EE的合理内涵，同样是在BPR的合理内涵基础上建立的（我是指逻
辑的关系，而不是历史的关系）。

对同一事物好的、正确的理论之间总是有自然的、有机的关系，但这个年头，“大师”们同样喜欢玩名词游戏，将有机的理论实
质切割成各式的蛋糕。

看了前面的讨论，很高兴有人加入。
但秦先生从数学和技术的角度来区分工作流和业务过程管理的标准是值得推敲的。Pi-calculus 可以用于业务过程管理，它一样
也可以用于工作流；而对于Petri-Net，也是可以用于两者的。现在工作流和业务过程管理的标准都倾向于支持Web service。但
是，在当前Web service都还没有一个统一标准的情况下，想要有一个支持Web service的工作流或业务过程管理的标准更是空中
楼阁。我强调一个观点，技术是中性的，它可以是某种标准或系统的驱动力量，但不可能是区分的标准。如果一种技术适用于一
个系统而不适用于另一个系统，那是本身两个系统的概念和范围的不同。对于工作流和业务过程管理这种区分很模糊的概念，我
还看不出对特殊技术的要求。

另外，我也是http://www.workflow-research.de/Forums/index.php 论坛的注册用户，但关于Harvard Smith和其他人关于工作
流和业务过程管理的争论，应该看http://www.bptrends.com/，这是当前最活跃的论坛。

我也是最近1年才开始搞工作流方面的研究，工作流的国外文献我也读了大概100多篇了，研究的方向主要包括：工作流建模、语
义优化、实现技术等几个方面。其中欧洲国家对工作流理论研究的很深入，美国的研究人员，单从文章上看，主要侧重对应用层
面研究。我个人认为工作流技术和petri网技术从语义角度看比较相似，就是说petri网是一种建模工具，它已经被抽象的几乎没
有了语义，你打算解决什么问题，它就能描述什么，比如能够描述业务过程、财务记帐等等。我觉得工作流技术也一样，工作流
技术要是不和研究的领域结合起来，也是没多少语义的。这是我的一点看法，不知是否正确。

另外，我还有一个疑惑，因为我也刚刚涉足工作流，因此对于工作流技术在我们国家企业实际应用当中，引发过哪些具体问题？
这些还请各位专家介绍介绍经验。

同意这种观点：语义越丰富，相对的应用的面就越窄，反之就越广。

   我是一名架构设计师，关注余老师的论坛已经很久，自认为才疏学浅，一直不敢参与讨论！现有个问题已经困扰了很久，
今天正好翻看前面的文章！可能我的问题就是前面这段话：“金新明博士最新论文中对业务过程建模语言的一个评论：
“Dilemma between user-oriented and software-oriented”（在面向用户还是面向软件之间进退两难）[5]” 提到的---
  在面向用户还是面向软件之间进退两难！！！

  目前我正在设计开发一套”业务架构平台“这样一个产品，目标是提高生产力，快速应对复杂多变的需求，能够以业务导向的
模式快速开发及部署实际的应用系统。目前碰到了一个难题，就是系统最终的用户是面向不懂编成技术的用户呢，还是面向懂编
成技术的程序员呢？如果面向的是不懂技术的最终用户，那就是业务基础平台，在系统装配构建当中就要屏蔽很多专业的技术术
语，包括开发模式，操作流程等，甚至要屏蔽OOP，OOD的概念，因为面向的用户是不懂这些东西的，他们可能更为熟悉的是业务
术语，业务过程，业务实例。因此系统要做的越傻瓜越好，但是将丧失一部份灵活性，功能受到限制。如果面向的懂技术的程序
员，那就是构件平台，系统要提供快速开发的工具，提供构件库，提供一大堆现有的构件，程序员只要通过简单构建就可以搭出
一个应用系统来。这个想法是好，开发也能开发的出来，但是真正能用起来就是个疑问了？因为这样的系统面向的是更为挑剔的
程序员，目前的程序员已经习惯了先有的开发模式，喜欢有一定创造性地工作。不希望做个简单的建筑工人。而这样的系统往往
沦落外，会用的（程序员）觉的太简单，太死板，不够灵活，不想用， 想用的（不懂技术的业务人员）又用不来。
  如果两类用户兼顾，往往又会做得不伦不类，两头不讨好。未来架构平台将何去何从，真是很难抉择?
希望大师们不吝赐教，给出指引！

注：  
  前面提到的 ”业务基础平台“ 复用的是开发模式，选择一套开发模式，并按这套开发模式设计开发的IDE，通过该IDE不懂技
术的业务人员也能通过配置，复制出一套适合业务的系统。类似于北京思维加速的Justep Business。 
  前面提到的 ”构件平台“ 复用的是设计模式和具体的构件，程序员按自己的开发思路，用现有的构件搭建出一套系统来。
类似于上海普元的EOS。
  

分析得好。

从这个切入点出发思考，或许就更会理解我最新发出《新一代企业信息系统——从实质性需求分析与研究到模型驱动系统》。比
如为什么要从ERAR开始，为什么要落实到MDS上，为什么MDA不能解决上述困惑，为什么需要企业工程。联系到上面李雨雪的话，
不面向软件开发者，就在面向用户吗？即使面向最终用户，用户中不同的角色又有什么不同之处呢？等等。

我们还可以稍稍转一个角度来讨论一下：
为什么我们总是等到产品设计了甚至开发出来，才意识到面到向谁的问题？有什么东西已开始就被忽略了？

还有，所谓业务基础平台“复用”的到底是什么？这是一个有趣的话题。

如果从Role的角度去看这个问题，那么应该有一个可以接受的方案，不过系统的开发可能会稍微复杂。
我还是强调Model-based system development， 模型是核心，是对系统的定义。但是，针对不同的用户，系统可以有不同的
Presentation。也就是，同一个系统， 针对不同的用户类型， 它可以有不同的界面，不同的权限。对于开发人员，系统应该提
供尽可能多的开发功能，如构件库等等；对于管理层的用户，他们只关心系统可以提供给他们的数据，分析结果， 和界面等
等，那么系统就应该提供这方面的功能，而可以屏蔽技术层面的概念；对于一个底层的操作人员，那么也许系统应该只提供一个
简单的输入，查询等界面即可。
但是，需要注意的是， 虽然对不同的ROLE系统有不同的界面，但它们应该都是基于同一个模型。
当前不少的软件产品其实已经是这样开发的了，比如3SL的Cradle，它支持三种不同类型的用户。

新明这里说到了另一个关键点：针对不同的角色，可以有不同的表现（presentation）——但基于同一个模型。这就是我在《新
一代企业信息系统研究与开发纲要》中，强调区分建模的“理论、表示法、方法论……”背后的一个出发点，也是我在一些讨论
表现出对具体“哪一种”建模语言不太在意的一个未曾言明的背景。

这一点，与欧阳前面在主题为“工作流的基本问题”（http://www.ee-forum.org/bbs/bbsview2.asp?type=2&id=153后面的跟
贴）点到的东西联系起来……

新明所推荐的 Keith 的 mechanistic process 与 human-driven process 说，是支持我前面这个观点的一个重要的论点。

参见本论坛上的帖子：
《从information management 到process management》
http://www.ee-forum.org/bbs/bbsview2.asp?type=2&id=218

引用 Keith 的观点，做为“工作流是过渡性的”第五条基本论点：
即传统的工作流研究，仅仅捕捉了业务过程中的“机械性”的部分，也就是“可自动化的部分”。对于那些人为的、随机的、动
态变化中的实际业务过程的支持而言，自动化流的辨别和支持仍只是一小步。

例如，单从技术的角度看——如何精确描述——建模，现有的工作流方法就是不够的，对此 Keith 找到 RAD 。

嘉文提出“事脉”，也具有类似的思想背景。

归纳起来，这也是我一直以来的基本观点（的一部分）：信息系统对业务过程的支持，传统的工作流是担负不起这个角色的，在
通往比较完整的业务过程支持方案的道路上，它是初级的、入门的、过渡的，这些理论、技术与实践固然有其不可磨灭的价值，
但对“业务过程支持”这个课题，有着更大的价值空间，并且还没有被真正地开发出来。

看过你们的讨论,感到不只是我一个人在思考事脉的问题,只不过是大家使用的词汇稍有不同罢了.
也许不同的词汇意味着对问题的不同侧面和出发点进行的思考.但大家面对的事实是基本相同的,就是:对现实的工作事务管理的
需求是工作流概念乃至技术还远不能够满足的.
我是从实际工作中悟出"事脉"概念的.
事脉是从事务发展过程一般规律的角度,企图用贴近现实的,通俗的概念来描述事务在发生和发展过程中,事务之间相互作用关系
的规律,然后,从整体的范围内,考虑如何管理和调整这些关系,可使得事务的发展在相应的环境条件的约束下,可以取得尽可能顺
利的进展.

我是把work flow定位为"机器驱动"之类的概念来理解;把business process定位为"人员驱动"之类的概念来理解的.
其实,在目的层面上,我们是期望事务发展是按人类的需求来驱动的,也就是说,事务本质上的驱动者,不可避免地是人类.提出"机
器驱动"出于在操作层面的,对这样一种信任程度的乐观评估:目前,人类是否可以对机器可以给予足够的信任,可以更多地让机器
来代替人类来驱动大多数事务的进展?二者存在操作层面的"驱动者之争"问题,实际上,这是一个误区.

事脉概念企图跳出这个"驱动者之争"误区,在操作层面上,真正的驱动者是谁并不那么重要,让机器代替人来主导事务的管理和由
人来主导事务的管理都不是我们必须考虑的要点,我们真正要考虑的要点是:如何管理和调整事务之间的关系,可使得事务的发展
在相应的环境条件的约束下,可以取得尽可能顺利的进展.

当人在操作层面来主导事务的进展时,并不是机器的作用就被忽略了,人就一定会很辛苦。如果我们把视线先收回到纯粹由人来驱
动事务进展的图景上来，去找出人在驱动过程中可能遇到的问题和困难，然后再来看新的技术成果能在哪些环节提供帮助，也许
能得到一种人和机器相互协同来主导事务进展的一种结果。

我非常认同彤鹰对“业务过程支持”的说法，这是对计算机协同技术的一个正确定位。这会引导我们从业务过程的“本来面目”
的起点上来观察思考。

业务过程“本来的面目”应该是业务工作中每一件具体事务的发展过程，但被我们总结归纳出来的“业务过程定义”实际上经过
了抽象和概括，是一种基于经验的与本来面目有误差的过程统计知识。我们使用业务过程定义实际上就是主观上强求未来要发生
的某个事务的过程要和这些过程知识中某个类似的过程定义保持一致。这就在重用历史过程知识时冒了过程僵化的风险，如果想
从过程定义方面规避这一风险，就必须对过程定义做大量的Case分支，这加大了过程的复杂性和降低了过程定义的可操作性。

选择处理事务走向的最直接的参考信息是事务当前的进展情况，而不是过程定义上给予的历史知识，如何面对事务可能出现的任
何意外的局面，做出事务流向的尽可能正确的选择，这也不是业务流程定义或业务流程改进能响应得过来的。反过来说，如果我
们通过一些其他方式的计算机的辅助协同作业，让我们能做到“面对事务的大部分可能出现的局面，做出事务流向的尽可能正确
的选择”，那么，业务流程改进的压力就会大大减小。事脉概念就是选择了这样的一个定位。

“事脉概念企图跳出这个"驱动者之争"误区,在操作层面上,真正的驱动者是谁并不那么重要,让机器代替人来主导事务的管理和
由人来主导事务的管理都不是我们必须考虑的要点,我们真正要考虑的要点是:如何管理和调整事务之间的关系,可使得事务的发
展在相应的环境条件的约束下,可以取得尽可能顺利的进展.”

嘉文这段论述，说出了更高的立意。嘉文真正地理解我用“业务过程支持”的深意。
相信嘉文也理解我所提出的这一要点——适管理性（well-manageable）

  “这是企业应用与个人应用最基本的区别。以往的软件开发者，常将许多系统管理工作与技术维护工作放在一起（例如所谓系
统授权管理），而它们本应是主管、经理使用的功能，这就是对适管理性缺乏重视的一个基本例子。我们认为适管理性并非天然
的，而是必须专门加以设计和保证的。对这一原则的贯彻和深入的实施带来的内容和变化意外地丰富。”

引自：《新一代企业信息系统——从实质性需求分析与研究到模型驱动系统》，2.3.5
       http://www.ee-forum.org/bbs/bbsview2.asp?type=6&id=150

这段话后面我所提到的“意外地丰富”，是对此实在地研究体验过之后的感受。

现在，对上述观点我稍有修正，即对个人应用而言，“适管理性”同样是一个很重要、很有实际价值的东西，但对于企业应用
（在大量的事务和许多人乃至许多机构间的协同环境中），这后面的会带来的变化也是革命性的（是的，在我对新一代企业信息
系统的研究过程中，发现了不止一种足以带来革命性变化的要素）。

作为一个信息系统,应该尽量将更多的信息系统的功能封装为业务系统的功能提供给合适的业务人员使用,衡量这种封装的有效程
度的指标就是"适管理性".
如果上述理解偏差不大的化,那么,据我的理解,RUP中谈到的业务建模过程,就包含这一目标,而且是我所知道的对此问题给出了最
详尽的解决方案的过程定义.
用我自己的话说,适管理性就是器官移植过程中的排他性，说到这，会和我的业务部件软件开发的观点产生联系。

我提出的业务部件软件开发的观点并不大为人知晓，我认为：所谓的信息系统，应该是一个更大的业务系统中的组成成分，就象
人体这个大系统是由神经系统，消化系统，血液循环系统，呼吸系统,...等成分有机组合的一样，信息系统也要和业务系统中的
其他系统有机组合。

有机组合的含义是，各系统的划分是人为的，根据功能特点划分的。实际人体这个有机体是由协同运作的部件，如四肢，头，躯
干，内脏等组成，各部件有多个系统的功能参与，才成就人体的协调。

构造一个企业就象构造一个人体，我们实际的构造过程会考虑不同系统的功能层面的不同，但并不意味着我们要独立完整地实现
构造出各类功能系统，然后再来考虑这些系统的相互整合，这实际上走了一条“孤军深入”的不平衡发展的艰难道路。

如果认识到一个业务系统大系统就象一个人体系统一样，实际的组成成分还可以按照组成部件来划分的话，我们也许可以考虑另
外一种平衡发展的道路：逐渐升级替换组成整体的各部件，完成整体演化的道路。于是，就会引出“器官移植手术”的问题。

把信息系统的建设过程理解为制造更优良的“人造器官”来移植取代业务系统中原来的器官的过程，是一种值得考虑的思路。在
这个思路下，当一个新的器官移植到一个旧的大系统环境下，能否和旧系统原有的系统功能协调一致，不被原系统排斥，就是一
个值得分析和设计的课题。

我始终觉得：活的人体是业务系统最佳的隐喻。

我归纳的适管理性，主要是一种系统功能设计的思想，已不是“体系架构”领域的事情（尽管如可变性这样的功能要点联系到模
型驱动系统上一样，它也直接联系/决定着某些系统架构上的特征。

封装是实现、加强适管理性的可能手段之一。

其实没有那么深奥。为管理而设计，为方便管理而设计，可管理性（最初我是用这个词），都挺接近的。

这个道理并不深奥，但被忽略的程度非常高，而且当真正从这个角度去设计功能、系统时，带来的变化是有些出乎意料的。

嘉文说“我们真正要考虑的要点是:如何管理和调整事务之间的关系”，再从这个考虑的结果延伸到软件的设计上，这就是得到
适管理性的途径。当然，如果做这个考虑的人是如此地理解软件可能的功用，他就不会用基于纸张的工作方式来思考了。

诸位新年好呀,我也来谈点自己的想法:
如果把工作流看作是一种分配资源的引擎,就是一种优化算法的运筹学,自动的成份(机器)就多.这是调度系统所强调的,比如小吉
星所做的一些研究.
我的体会是:只有在调度系统的最优算法才特别强调流程,时序因素,因为它是最优的基础.
值得注意:这个最优是在系统可以调整资源的前提下才有意义,也就是在系统冗余的前提下才有可能.
如果是一个没有机动资源可以利用的企业,只有一种可能性和必然性,就没有所谓最优的问题.
工作流的普遍意义是要超越具体业务流程,达到数据库超越具体文件,与业务的语义无关,它是通过对资源的分配来抽象.
注意:同一个业务流程,即可以按部门岗位来进行流程分解,也可以按数据的语义性质来进行分解,因为选择的基础单元不一样,分
解出来的流程就不一样.这里的基础单元可以看作是一种资源分配.
所以,同一个业务流程可以分解出不同的工作流来.
工作流的抽象结果是最后只关注流程的拓扑性质,来考察一个流程的合理性,比如不会形成死锁,不会有不可达到的状态等等,具有
相当的理论性.
在现实企业模型中,因为有实际业务发生为背景,很少会出现那种"不可达状态"纯逻辑上的错误情况.同样,现实中冗余的可选择性
也不是很大.
我们为什么要再现流程中的先后次序?回答是为了进行最优调度,指挥实际的生产.
除此之外,我们还有必要在企业模型中真实再现流程的时序因素吗?
我认为并无必要.相反,企业的功能模型,常常是对流程离散的表达,比如对于库存管理,就是一进一出,设置两个采样点,并不需要
对每一个动作的时序进行描述.
因为有时离散表达可以大大简化模型的复杂性.
是人驱动还是机器驱动并不重要,我同意这个观点,因为我们可以把人的驱动变成机器驱动,比如设计一个调度算法,就是典型代替
人脑.
但是,这个问题其实隐藏着更重要的问题:是被决定论的驱动,还是容纳了随机因素的驱动,这也许是更深层的问题,无法回避的问
题.
比如人的驱动中,就更多的随机因素,比如人随机在界面上触发某个功能,不同的角色对一个系统的随机触发等等.
只有分析了角色的随机触发,这个模型才能动起来,否则就是一个静态的平台.

先正一下名：“机器驱动和人驱动”这个话题，是由前面新明推荐的 Keith 的观点中来的，见本论坛上的另一组帖子：《从
information management 到process management》http://www.ee-forum.org/bbs/bbsview2.asp?type=2&id=218

开始我看到他的提法是 machine-driven processes 和 human-driven processes ，即“机器驱动过程和人驱动过程”（注意，
其实由 flow 到 process 已经是一个实质的不同，这在流行的中译中就被掩盖掉了），而在上述系列帖子中新明推荐的 keith 
2005年12月的新文章中（http://tinyurl.com/b52xr），改用了“mechanistic”与“human-driven 来对应，也就是“机械的过
程与人驱动的过程”（其实，到这个层面上，在中文中直接使用“人为过程”是更恰当的）。行文中还有一种说法，就是自动化
的过程。

我在帖子中已经提到，这是一个重要的进步。其实，这里所谓“机器驱动”背后隐藏的某种佯谬，与“模型驱动”这个说法背后
的佯谬是很一致的（而后者更严重），这方面新明也有研究。

我要说，“机械化过程”和“人为过程”的区分并非不重要，它是摆脱“工作流”（宽一点就是信息技术应用中的自动化陷阱）
的认识阶梯上重要的一个台阶（其实还是决定软件架构的重要因素）。但这不够——所谓适管理性，或者新明上面帖子中所述的
事脉立意“管理和调整事务之间的关系”，是在这“之上”的认识。

嘉文说“跳出驱动者之争”是对的，但“驱动者之分”是很重要的认识基础。也是实现适管理性的重要基础。

这个帖子从正名开始，就在正名上结束：更好的提法，还是“自动化/机械化”过程与“人为过程/实际过程”的区分，其实这二
者之间并没有“争”，Keith 指出这个区别，强调了传统工作流实际捕捉的只是前者，而不能解决后者，后者是更基本的实际发
生的过程。

其实要特别强调，我对现有的工作流从理论到软件实现，不是“否定/不要”，而是强调其“初步性，不够”。
而我说的这个不够，主要不在于流的数学模型这样一些层面上，而是在“应用软件或信息系统对业务过程的支持”这个层面上。

这个“对业务过程的支持”，首先包括：怎样令业务过程更有效率，更好地被管理、监控，更好地被规划、理解、改变，等；提
升一个层次，还有“在信息技术的可能支持方案之下，可能实现怎样的过程，更好地达到业务目的与目标？”

在后一个课题中，“可能的方案”与“可能的过程”，是一个“蛋生鸡/鸡生蛋”的循环，我把这样的工作，在靠近系统开发一
侧，归结于“实质性需求分析与研究”；在靠近企业管理（规划）一侧，归结于 “企业工程”。

大家新年好！
刚看到这篇和Keith的论点不同的文章，很有意思，转过来部分给大家看看：
I’m a bit more disturbed, however, by the use of the dichotomy that seeks to classify processes
as either mechanical or human processes. I spent most of my time in the Eighties studying
Artificial Intelligence and Expert Systems and know just how hard it is to specify exactly what
distinguishes a computer system from a human reasoning system. I know that most of the
processes humans undertake can be modeled as states and transitions. I also know that
computers can use rules and inferencing, or neural networks, to handle problems that are
dynamic and innovative. In any case, since I know that the people promoting this distinction plan
on automating the processes that they refer to as “human,” I suspect that this dichotomy isn’t
really very useful.
The real issue, as I see it, isn’t the “nature” of the process; it’s the ability of the notation to help
business managers understand processes. Harrison-Broninski and others who argue for RAD
are computer scientists. They grew up using workflow diagrams in computing and apparently
associate them with computers. I come from a very different tradition. My graduate work is in
psychology. I first encountered “workflow diagrams” when I went to work for Geary Rummler in
the late Sixties. We used simple workflow diagrams to help business people describe what they
did. We didn’t focus on processes as candidates for automation. We weren’t interested in
automation and neither were our clients. We were focused on describing how people worked
together to accomplish company goals. We would use a few boxes and arrows to describe the
steps bank officers would go through to assemble a complex loan package, or how sales people
would organize their sales effort. In particular, we used diagrams that had “swimlanes” -- an
innovation that I associate with Geary Rummler -- which indicated which department, individual or
role that was responsible for which activities in the process. Rummler always situated the
customer on the top lane in any diagram to constantly remind everyone why they were doing the
process and focus everyone on the dynamic, human interactions with the customer. (Years later,
in the early Nineties, I personally provided Grady Booch with documentation about the Rummler-
Brache swimlane notation when the UML task force was considering adding swimlanes to UML
activity diagrams, thus introducing this “human process documentation” technique into UML
activity diagrams.) I say all this to say that I do not necessarily associate workflow diagrams with
software diagramming or with machines. Much more important, Rummler-Brache, I, and many
others have used Rummler-Brache diagrams for 35 years to teach business managers to analyze,
model, and improve their processes.

If
we want to get business managers to rely on process modeling and to create diagrams as readily
as they create spreadsheets, we need a simple, standard notation. It doesn’t make much
difference about the specifics, but we need to settle on one notation and stick with it to avoid
confusing people. BPMN, with its rectangles, arrows, diamond decision points, and swimlanes is
about as simple and straight forward as you can get. It’s now an open standard and it has
momentum behind it. Thus, it is by far the best candidate on the scene today. RAD diagrams, as
far as I’m concerned, are just one more idiosyncratic variation on the basic concepts that’s being
pushed by a small group. I’m sure RAD advocates believe their diagrams add something.
Similarly, everyone promoting a special notation thinks their diagrams add something. But if we
are to arrive at a common notation, we’ve got to decide if the little differences really amount to an
important difference. This is what standardization is all about.

全文可以看：http://www.bptrends.com/publicationfiles/01%2D06%20DIS%20Sieves%2C%20Mech%2C%20Pragmatics%20%2D%
20Harmon%2Epdf

看了金博的转摘,发现原来我对工作流概念有"窄解",而且这种"窄解"是很有代表性的.
这个老外并没有局限把工作流视图局限在计算视图范围内使用.是吗?我想,能这样用的这个人一定是大师,没准是创始人之一.
但工作流的流行定义本身确实能够给我们这些非大师这样的窄解啊.

回彤鹰:
我确实把"为管理而设计，为方便管理而设计"引入到了更深的操作层面,这不可避免地要显得深奥一些了.
到底怎样地做到"为管理而设计，为方便管理而设计"呢? 我认为RUP的业务建模过程定义给了我们一个不错的指引.
到底怎样才是做到了"为管理而设计，为方便管理而设计"呢?当"器官移植手术"成功了,没有出现排他反应,机体运作效率更高了,
就可称为做到了"为管理而设计，为方便管理而设计",我给出了一个自认为恰当的隐喻.
当然,彤鹰说的没错,这只是我个人的理解,而且加入了自己的特定的实现架构下的考虑.可以说,我提出的是提高"适管理性"的一
种具体的过程和技术构架方案.并不排除还有其他的方案.

第一,试图得到一个独立业务流程的逻辑关系,比如一个完整的系统生命周期,所谓的业务流程图.
第二,得到一个作业的最优算法,典型的是调度系统,狭义的工作流引擎,有自动化的倾向,资源配置，属于运筹学.
第三,在自动控制领域,要进行有效的实时控制,比如前馈控制,就必须知道系统的内部结构和状态.如果只是反馈控制,并且响应可
以滞后,就可以采用I/O方法,不需要知道内部结构,就相当于不需要知道具体的流程.
I/O方法既可以是离散控制方法,也是黑盒表达方法,它的控制表达能力在自控理论中有着深入的研究.
所以,流程是模型的结构因素,是决定模型实时性的一个关键因素,要满足控制要求就必须研究流程中的时序(一阶惯性,二阶阻尼
都是我们熟悉的因素),否则控制系统会产生振荡等一系列问题.
第四,得到一个业务流程中的参与者是如何合作的,如新明所提供的老外例子.用流程图来表达一种协作关系,一种组织关系,这是
一种新用法?它的重点表达是协作和组织关系,而不是被处理的数据.这就是它的新意所在?我的理解不知是否正确.
其实,最原始MIS中的流程图,就是在部门岗位之间的流程图,它关注数据在哪些部门之间流转,它是随着组织机构的变化而改变,所
以与上面第一条所说的业务流程逻辑关系相比,稳定性要差一些.但是,它的聚焦点还是数据流本身,甚至可以说是数据本身,流程
不过是加工数据的过程而已.
至于彤鹰与嘉文所谈的流程和事脉,我还缺乏理解.你们谈的好像是还没有形成流程的流程,或者是流程的产生和制定过程?随着需
求目标而改变?是否可以再举一个小例子帮助理解.
如果已有的流程是按法律行事,你们谈的就是如何立法的问题?又如何同资源配置的“立法”从本质上相区别呢？就是说它不是一
种运筹算法呢？

嘉文的眼光很好,那文章的作者Paul Harmon确实也可以说是业务流程方面的大师了。
Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business 
problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and 
Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures 
(2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as 
a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 
Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component 
Development Strategies.

有时侯那些争论的不同观点让人耳目一新啊！

http://www.smarthings.net/bbs/index.php,最近陆续有内容更新

有个问题在这里请教一下各位。
ECA规则用来描述业务过程，自然有它的优势。但是我想问问，除了业务规程之外，企业的其他规则，如资源约束等，是否也可
以全部用ECA规则来统一描述呢？注意，我这里强调的全部。因为我的目的是：一旦有了一种途径统一描述业务过程规则以及过
程外的规则，那么就可能找到一种方法去分析过程外的规则对业务过程执行的影响了。
忘回复

ECA规则对于业务流程的普适性是值得怀疑的。它的表达能力对于复杂的业务流程是否足够？它对哪些业务流程有优势？诸如此
类都是值得研究的问题。业务规则本来就是个大问题，我觉得它的研究还远未成熟。数据库的那套机制对于现实的业务流程来说
太僵化，太有限。相关研究可以看看： http://www.businessrulesgroup.org/home-brg.shtml， 
http://www.brcommunity.com/index.php。
约束对于业务流程是至关重要的，但对其研究我觉得也是刚起步。可以说，没有约束的流程其实是空中楼阁。OCL的产生其实就
是认识到建模中约束的重要性。很多的语义其实是通过约束表达出来的。即使缩小范围到资源约束，情况还是极端复杂。至少应
该考虑以下问题：
1） 资源竞争问题；
2） 资源优先问题；
3） 资源替代问题；
4） 资源分类问题， 如无损耗资源和损耗资源， 人和机器；
5） 资源消耗问题；
6） 资源的可靠性问题；
7）。。。。
这些都应该说是基本问题，但当前还没有有效方法来解决。

海波的目标很有意义，但在当前的技术条件下，我觉得还有很长的路要走。但我相信规则是应该和业务流程融合的，或者就成为
业务流程的一部分。

看了新明的回复受益匪浅。
在本论坛种的另一个工作流的板块里，记得大家几乎都有这样的共识（大概是这个意思吧，也许我概括的不准确）：企业是一个
大系统，应该站在系统的观点看待业务过程，而不是把业务过程理解成一个单纯的具有时序关系的有向图。
最近对业务过程的研究中，也有人对“业务过程规则”和“过程外规则”的叫法提出质疑，他们称“如何界定过程内外的规
则？”。看了上面的回复，觉得这种反问也不无道理。但是，如果狭义地把业务过程理解成有向图的话，我还真想举出几个例子
来说明“过程外的规则对过程执行是有影响的”的情况是存在的。
比如，销售业务流程，从发车计划->出库->质检->...，如果执行到某步时，外部资源发生变化（过程外的业务规则），可供运
输的交通工具撤销了，那么业务过程再继续的话就没太大意义。

希望各位充实一下这个思路，给出几个能准确说明问题的例子，因为上个例子只说明了让业务过程终止的情况，其他情况不只如
此，比如：在过程中跳跃一些步骤继续执行，等等。

从系统的角度来看，我是不赞成内外规则的区分的，看不出这种区分有什么意义。我总是强调视角，因为我觉得那是基本点。而
视角对规则的取舍也起决定作用。至于规则，我觉得是无穷的。只要你去想，就会不断找到新的约束（我觉得约束也是规则）。
以海波的销售业务流程为例，可以考虑小的《如果车坏了。。。》到大的《如果地球毁灭了。。》；可以考虑有意义的《如果油
不够。。。》，到无聊的《如果陨石砸到车。。。》。在IDEF0中，它的ICOM中的C和M其实就是规则。而IDEF0建模的第一步就是
选视角。视角提供了选择规则的一个标准。
至于海波想要的例子，随便举几个：1）火车站，飞机场的VIP或绿色通道；2）在英国的一个电影院，有个Ticket Box的东东，
每次你去看电影，就给盖一个章在上面，积满三次了你就可以不买票看一次电影（跳过了买票的步骤）。。。这些都是日常生活
中的例子，但我想也可以说明问题。
建模其实只是想表达实际/现实的一个有意义的侧面。但模型永远也不是真实。模型是把真实进行了规范，进行了简化和取舍，
进而期望能让自己把握真实。面对现实中如此多的不可知，如果都去考虑的话，建模就不可行了。就象我们自己的人生，有那么
多的茫然/意外/不确定/不知道，但我们还是要兴致勃勃地去计划/憧憬。建模也是这样吧。

新明说得对，规则是无穷尽的，正是因为忽略了视角，就像资源那样，不考虑观察事务的视角就谈资源，很难分清资源到底是什
么。
即使是规范的业务过程，也常常受外界环境和需求变化的影响，有的变化，能够判断出业务过程未来若干步骤的执行会失败或者
肯定会成功。所以就有了优化的余地，可以采取一些方法去搜索、判定那些路径。
我曾在CIMS上发表过一篇文章，里面的例子就是描述了制造业中类似的场景，即判定未来执行步骤的成功与否。现在看来例子举
的还是不理想，比较作作。

workflow 还是BPM,谈论这些文字上东西有意义吗?
俺觉得工作流不能解决企业信息管理的所有东西,但是它是必不可少的一个平台,或许他以后叫workflow ,或者不叫BPM,但是这个
思想是确实存在的.它来源企业管理的现实,而不是"专家学者"的文章论述.因此它不是一个过渡.(或许这个词workflow可能是过
度吧,或许某些专家或者学者能够绞尽脑汁发明出更加贴切的词,哎,IT界有时侯就是需要有些人发明些词汇,然后大家来炒作,真
是无奈啊!)

很久没来了，这里还在讨论呀，再发一点个人见解，错误难免。
个人认为有些同志期望工作流或BPM能够为企业创造“正确”的业务流程，但这是它们做不到的，因为流程是否正确是个管理问
题，现在正确以后未必正确，管理人员不应期待利用工作流（这里不妨视为BPM的同义词）能够帮他创造正确的流程，那末他可
以期待工作流什么呢？ 我的看法是，他可以期待工作流系统能够快速、低成本实现他头脑中所谓的正确流程，并且当他头脑中
的正确流程变化了时，工作流系统能够方便地修改实现流程。这就是我们对工作流或BPM的期待。毫无疑问，工作流系统的这个
能力是一个技术能力，但这种技术的价值不应低估，几十年来，从工作流到BPM都在向这个方向努力。直到最近，XML、Web服
务、BPMN、BPEL的出现，似乎使得这个目标接近达成。
最好的结果是，业务人员采用BPMN建立流程模型，BPMS自动将其转换为BPEL可执行流程并执行之，无需编码。当然，目前，尚不
能达到这个效果，但看来有希望，特别是业务流程需要调用的基础Web服务都建立好了的时候。

有道理，最近对咬文嚼字的玩概念有了很多感受。总是在那玩概念而不去从语义上理解业务过程，没太大意义的。呵呵

看了上面几位专家的发言，我也来发表一点不成熟的看法。
其实现在BPM发展到现在，已经是比较成熟的一个平台了，为什么称之为平台，而不是软件？
就是因为在这个上面能够对企业的工作流程（workflow）建模、管理、自动化、监控、优化与改善，而这些完全是通过BPM平台
的流程设计器拖、拉、放的操作把企业的流程电子化，并通过BPM平台的其他工具去监控与优化流程。

所以个人认为BPM包含了workflow。

无内容！

期待这里有新的内容，我在这里受益匪浅。在各位专家的讨论中学到了，从学术期刊论文中很难看到的东西。我一直在思考跨组
织业务流程建模的问题，但一直没有大的进展，甚至在建模过程中应该主要解决的几个问题我还没有思考清楚，不知道这里的专
家学者有没有从事这方面研究的。能否给我些指点呢。我曾考虑过用工作流或petri做为主要的建模工具，但是我找不到在这方
面的参考文献。望得到各位的帮助！

上面讨论的朋友大都是事业中人、学业中人，来这里讨论，没有丝毫的功利回报，所以是纯粹的学问、知识的交流与讨论。
工作流（workflow）还有petri net的文献非常之多，跨组织业务流程建模，也许可以参考一下供应链建模方面的研究或实践
（比如 SCOR (Supply-Chain Operations Reference-model)，这就是个实践、理论两方面都很有价值的切入点

从上面的论点来看，所论的主要有几点是我们在流程中要注意的，流程发生的背景，流程的系流性，可控性，测量性，流程中的
操作性等表述了它应有的价值及流程的组建都谈的很好，我很高兴来到这个论坛

愿闻更多的见解，互相学习