BPM（商业流程管理）标准与过程生命周期分析

BPM（商业流程管理）标准与过程生命周期分析

编译 余惠华 　　在BPM（商业流程管理）世界，简化了培训和支持，减少了失败的风险，使得元素的整合和再利用更加容易，增强系统和过程的移植性，扩大了共存技术的选择，提高了改造世界的灵活性，谁能够拒绝这些呢？ 但是如果你问问BPM团体现在标准的状态，你会听到这样的回答“迷惑”、“混论”、“乱七八糟”、“灾难”。讽刺的是，混乱正是标准委员会最近进步的直接结果。BPM标准的问题在于我们有太多的标准，常常重复却又来自于不同的标准体系并且似乎有着相互交叉的条款。 　　BPM标准问题的核心是过程描述或模式。在大部分人头脑中，BPM的标准化意味着对模式语言和图标元素的普遍理解，设计工具间模型的便携性和通过加工过程模型的可移植性。这样的标准化，在它身上体现着商业利益，假定三个条件：对在一个功能领域内单一标准的广泛接受；功能被这个标准彻底的包围；和通过功能领域标准的相互协调能力。这正是我们现在在BPM中还没有的东西。 　　2002年在他们出版的书里，商业流程管理——The Third Wave，Smith and Fingar想象了一种新的软件，BPM系统（BPMS），商业分析员可以通过图标构筑一个过程模型，通过模拟和分析优化模型，并且可能在经过计算机轻微的技术扭曲后在一个内置的过程引擎上执行它。所有的这些都将在单一的设计工具上完成，BPMS的一部分，使用一种功能完整标准化的模型语言。 　　商业分析员使用专门的工具通过图表的形式描绘模型过程，这可以被解释为允许模拟和分析，但是这缺乏执行中要求的技术细节。让我们将这些称作分析模型。系统设计师解释这些模型为商业需求和继续描绘完成所需要的数据元素和软件元素，使用企业构筑模型工具。下一步，计算机开发者使用项目工具（IDEs）和整合中介软件来创造这些元素。渐渐地，今天这些元素都被设计为可多次使用的“服务软件”。 　　在BPMS设计环境中，过程设计者引进分析模型并通过与开发者制作的元素的连接将这些模型转换为可执行模型。这些可执行模型从设计环境展开到BPMS引擎再到自动化管理过程。 　　在BPMS真实世界里，一个“过程设计者”通常比商业分析员更加技术化，但是远远不如一名Java设计员。在许多方面，The Third Wave的精神要领是实现，但取代商业分析员直接的执行过程，现实的生命周期包括有着不同技能的候选者之间的传递，与不同模型工具的合作。这是BPM标准的一个来源，由于每个标准都特定地针对这些候选者中的一个和过程生命周期的一个特别阶段。 　　比如，从BPMI.org中出来的商业流程模型标记法（BPMN）统一了分析模型中使用的图表的图形和线条的意义。然而对商业分析员而言，BPMN超越了简单的流程图来表现现代服务导向型BPMSs的高级特征，例如信息连接、事件和执行补偿。现在，BPMN仅仅是一个图表标准，它没有重点语句或概要。模型必须被描绘成通常使用的执行语言（BPEL）使得可以被工具所识别。 　　企业设计师所使用的成分模型并不是构筑在BPMN基础上，而是基于不同的模型语言，目标管理小组的UML。UML包括多样的图表，其中的一些——活动图和状态图——也能描绘过程流。BPMS为建立执行模型使用的语言依赖于它的重点产品的建筑组织。有两个基础形式：工作流程组织，基于已被广泛接受的工作流程管理联合模型（WfMC），特征模型基于WfMC中的XPDL，过程模型基于服务编织组织使用OASIS的商业流程执行语言（BPEL）。你常常听到BPEL是一种“执行语言，而不是设计语言”，事实是在一个基于BPEL的BPMS中，设计环境不变的特征图表元素一一对应于基本的BPEL活动。也就是说，在现实世界中，BPEL实际上被作为设计语言使用——过程设计师有足够的技术能力来使用它。 　　BPM标准的第二个问题在于XPDL和BPEL都会从他们各自的语言方面略去真实商业过程的主要元素。在XPDL中，运用整合逻辑被移植到过程活动中，比如过程模型的外型。在BPEL中，参与者和人类相互影响的其他细节都被移植到服务上，还是过程模型的外型。这样来处理现实世界商业流程，BPMS必须要么支持混合模型，一部分XPDL，一部分BPEL；要么，通常的解决方法——简单地将遗失的功能当作语言标准外部的合适的“价值增值”来添加。最功能完整BPMSs倾向于使用工作流程/XPDL组织，BPEL 的支持来自于IBM, Microsoft, BEA, Oracle, 和SAP，并且由于它包含网络服务标准“堆”，这使得大多数分析员宣布BPEL已经成为BPM标准战争的胜利者。 　　有了这些背景，让我们再回头看看BPM标准的现状： BPMN图表，没有标准语言或概要，无法在分析模型工具中portable。它们只能被BPEL描绘。但是BPMN能够描绘人类活动，人类相互影响的细节无法描绘成BPEL。他们必须被添加到BPMS的BPEL工具，正如讨论的那样，并不能和非技术过程设计者很好的配合。 　　BPMN无法映射到XPDL，即使BPMI.org想要提供这项功能，XPDL现在还不能支持BPMN的所有东西。这意味着基于XPDL的BPMN商贩必须在他们自己的设计环境中增加BPMN工具，通常功能没有分析模型专家那样强。 　　OMG在它自己得商业流程描述模型（BPDM）上运作。与其与OMG竞争，BPMI.org更希望与他们合作在BPDM基础上为BPMN开发一个基础性轮廓。但是这个任务似乎over the horizon，OMG在生命周期中实际上服务于不同的constituency。其他人认为BPMI.org必须标准化BPMN轮廓，并且无论BPEL还是XPDL都不是功能完整的。BPMN描述的一些信息可以对应到执行语言。真实世界中的BPMSs必须在执行模型的买方所有者部分添加这项功能，使得这些部分不再可以移动。 　　困惑和混乱？这是实情。混乱有一点极端，但它肯定不是一场灾难。这至少是BPMI.org的心态，他说：“当他们这个月在迈阿密召开BPM最大的客户和销售商峰会的时候，来自OASIS, OMG和WfMC的监督者也参与了会议。这里有一个公布的会议议程，但是事件的细节被有意地隐藏。结果使我很惊讶。我一直认为XPDL是不可能成功的，一个90年代客户/服务的遗物。我相信关键任务是主动的倡议来扩充BPEL——明显的“赢家”，来处理人类相互影响——被遗失的最大的部分。这里有一个叫做BPXL的东西——人类工作流程扩充到BPEL，一个OASIS的技术委员会并没有带宽（或者是动机）去攻击的东西。 　　但最终结果现实出席的主要的使用者和销售商对BPEL完全不感兴趣，事实上，许多人将其描绘成有点像第四代语言，使用网络服务的合成运用，与商业流程没有什么关系。这或许并不公平。BPEL中的“BP”，在某些人的观点中，可以被看成历史事故或一个经典的引导顾客的手段。肯定的是项目成员团体对应用BPEL的合成运用感兴趣，这与商业流程管理团体不同。在峰会的出席者中，更多的兴趣在于“固定的”BPMN——假定其是变异模型和轮廓，对应于XPDL——并且扩大XPDL（工作流定义语言）来处理所有BPMN可以扔给它的，包括信息连接和事件。XPDL 2.0真正的工作正在很好的进行中。 　　如果这些努力中的任何一个导致了一个成功的商业产品的完善，我们可能期待一个BPMS在生命周期方面新的方向——某种贴近于第三波视角的东西，但是有一个扭曲。取代了在BPMS环境中创造可执行模型，你可以在任何地方构筑它们，从企业构筑工具到专门的模型工具到廉价的Visio工具，把BPMS当作有利商业的结尾。你只要绘出BPMN（业务流程建模标记法）图表，对其进行模拟优化，并且点击它进行汇编以完成执行过程——在所有的BPMS中展开。在一般的环境中，可执行语言将永远不会被过程设计者看到。在某些方面这甚至比第三波理想更好，因为可以从BPMS中独立地选择模型工具，某些企业设计师可能会喜欢。在混乱背后，对BPM（业务流程管理）标准有着明确的希望，迷雾一定将慢慢散去。 但是如果你问问BPM团体现在标准的状态，你会听到这样的回答“迷惑”、“混论”、“乱七八糟”、“灾难”。讽刺的是，混乱正是标准委员会最近进步的直接结果。BPM标准的问题在于我们有太多的标准，常常重复却又来自于不同的标准体系并且似乎有着相互交叉的条款。 　　BPM标准问题的核心是过程描述或模式。在大部分人头脑中，BPM的标准化意味着对模式语言和图标元素的普遍理解，设计工具间模型的便携性和通过加工过程模型的可移植性。这样的标准化，在它身上体现着商业利益，假定三个条件：对在一个功能领域内单一标准的广泛接受；功能被这个标准彻底的包围；和通过功能领域标准的相互协调能力。这正是我们现在在BPM中还没有的东西。 　　2002年在他们出版的书里，商业流程管理——The Third Wave，Smith and Fingar想象了一种新的软件，BPM系统（BPMS），商业分析员可以通过图标构筑一个过程模型，通过模拟和分析优化模型，并且可能在经过计算机轻微的技术扭曲后在一个内置的过程引擎上执行它。所有的这些都将在单一的设计工具上完成，BPMS的一部分，使用一种功能完整标准化的模型语言。 　　商业分析员使用专门的工具通过图表的形式描绘模型过程，这可以被解释为允许模拟和分析，但是这缺乏执行中要求的技术细节。让我们将这些称作分析模型。系统设计师解释这些模型为商业需求和继续描绘完成所需要的数据元素和软件元素，使用企业构筑模型工具。下一步，计算机开发者使用项目工具（IDEs）和整合中介软件来创造这些元素。渐渐地，今天这些元素都被设计为可多次使用的“服务软件”。 　　在BPMS设计环境中，过程设计者引进分析模型并通过与开发者制作的元素的连接将这些模型转换为可执行模型。这些可执行模型从设计环境展开到BPMS引擎再到自动化管理过程。 　　在BPMS真实世界里，一个“过程设计者”通常比商业分析员更加技术化，但是远远不如一名Java设计员。在许多方面，The Third Wave的精神要领是实现，但取代商业分析员直接的执行过程，现实的生命周期包括有着不同技能的候选者之间的传递，与不同模型工具的合作。这是BPM标准的一个来源，由于每个标准都特定地针对这些候选者中的一个和过程生命周期的一个特别阶段。 　　比如，从BPMI.org中出来的商业流程模型标记法（BPMN）统一了分析模型中使用的图表的图形和线条的意义。然而对商业分析员而言，BPMN超越了简单的流程图来表现现代服务导向型BPMSs的高级特征，例如信息连接、事件和执行补偿。现在，BPMN仅仅是一个图表标准，它没有重点语句或概要。模型必须被描绘成通常使用的执行语言（BPEL）使得可以被工具所识别。 　　企业设计师所使用的成分模型并不是构筑在BPMN基础上，而是基于不同的模型语言，目标管理小组的UML。UML包括多样的图表，其中的一些——活动图和状态图——也能描绘过程流。BPMS为建立执行模型使用的语言依赖于它的重点产品的建筑组织。有两个基础形式：工作流程组织，基于已被广泛接受的工作流程管理联合模型（WfMC），特征模型基于WfMC中的XPDL，过程模型基于服务编织组织使用OASIS的商业流程执行语言（BPEL）。你常常听到BPEL是一种“执行语言，而不是设计语言”，事实是在一个基于BPEL的BPMS中，设计环境不变的特征图表元素一一对应于基本的BPEL活动。也就是说，在现实世界中，BPEL实际上被作为设计语言使用——过程设计师有足够的技术能力来使用它。 　　BPM标准的第二个问题在于XPDL和BPEL都会从他们各自的语言方面略去真实商业过程的主要元素。在XPDL中，运用整合逻辑被移植到过程活动中，比如过程模型的外型。在BPEL中，参与者和人类相互影响的其他细节都被移植到服务上，还是过程模型的外型。这样来处理现实世界商业流程，BPMS必须要么支持混合模型，一部分XPDL，一部分BPEL；要么，通常的解决方法——简单地将遗失的功能当作语言标准外部的合适的“价值增值”来添加。最功能完整BPMSs倾向于使用工作流程/XPDL组织，BPEL 的支持来自于IBM, Microsoft, BEA, Oracle, 和SAP，并且由于它包含网络服务标准“堆”，这使得大多数分析员宣布BPEL已经成为BPM标准战争的胜利者。 　　有了这些背景，让我们再回头看看BPM标准的现状： BPMN图表，没有标准语言或概要，无法在分析模型工具中portable。它们只能被BPEL描绘。但是BPMN能够描绘人类活动，人类相互影响的细节无法描绘成BPEL。他们必须被添加到BPMS的BPEL工具，正如讨论的那样，并不能和非技术过程设计者很好的配合。 　　BPMN无法映射到XPDL，即使BPMI.org想要提供这项功能，XPDL现在还不能支持BPMN的所有东西。这意味着基于XPDL的BPMN商贩必须在他们自己的设计环境中增加BPMN工具，通常功能没有分析模型专家那样强。 　　OMG在它自己得商业流程描述模型（BPDM）上运作。与其与OMG竞争，BPMI.org更希望与他们合作在BPDM基础上为BPMN开发一个基础性轮廓。但是这个任务似乎over the horizon，OMG在生命周期中实际上服务于不同的constituency。其他人认为BPMI.org必须标准化BPMN轮廓，并且无论BPEL还是XPDL都不是功能完整的。BPMN描述的一些信息可以对应到执行语言。真实世界中的BPMSs必须在执行模型的买方所有者部分添加这项功能，使得这些部分不再可以移动。 　　困惑和混乱？这是实情。混乱有一点极端，但它肯定不是一场灾难。这至少是BPMI.org的心态，他说：“当他们这个月在迈阿密召开BPM最大的客户和销售商峰会的时候，来自OASIS, OMG和WfMC的监督者也参与了会议。这里有一个公布的会议议程，但是事件的细节被有意地隐藏。结果使我很惊讶。我一直认为XPDL是不可能成功的，一个90年代客户/服务的遗物。我相信关键任务是主动的倡议来扩充BPEL——明显的“赢家”，来处理人类相互影响——被遗失的最大的部分。这里有一个叫做BPXL的东西——人类工作流程扩充到BPEL，一个OASIS的技术委员会并没有带宽（或者是动机）去攻击的东西。 　　但最终结果现实出席的主要的使用者和销售商对BPEL完全不感兴趣，事实上，许多人将其描绘成有点像第四代语言，使用网络服务的合成运用，与商业流程没有什么关系。这或许并不公平。BPEL中的“BP”，在某些人的观点中，可以被看成历史事故或一个经典的引导顾客的手段。肯定的是项目成员团体对应用BPEL的合成运用感兴趣，这与商业流程管理团体不同。在峰会的出席者中，更多的兴趣在于“固定的”BPMN——假定其是变异模型和轮廓，对应于XPDL——并且扩大XPDL（工作流定义语言）来处理所有BPMN可以扔给它的，包括信息连接和事件。XPDL 2.0真正的工作正在很好的进行中。 　　如果这些努力中的任何一个导致了一个成功的商业产品的完善，我们可能期待一个BPMS在生命周期方面新的方向——某种贴近于第三波视角的东西，但是有一个扭曲。取代了在BPMS环境中创造可执行模型，你可以在任何地方构筑它们，从企业构筑工具到专门的模型工具到廉价的Visio工具，把BPMS当作有利商业的结尾。你只要绘出BPMN（业务流程建模标记法）图表，对其进行模拟优化，并且点击它进行汇编以完成执行过程——在所有的BPMS中展开。在一般的环境中，可执行语言将永远不会被过程设计者看到。在某些方面这甚至比第三波理想更好，因为可以从BPMS中独立地选择模型工具，某些企业设计师可能会喜欢。在混乱背后，对BPM（业务流程管理）标准有着明确的希望，迷雾一定将慢慢散去。