BPM在技术和业务间搭起桥梁

作者：

欢迎访问e展厅 展厅 3 CIO信息化管理展厅 电子商务/企业门户, IT运维管理, 制造执行系统MES, 流程管理BPR/BPM, SOA/SaaS/云计算, ... 业务与IT的交叉点正是BPM关注的焦点，这也是大多数重大IT问题出现的地方，通过为业务分析员和软件开发人员提供通用的工具，BPM有希望使应用集成发生革命性变化。也正因为如此，很多人认为，BPM将成为下一个企业信息化选型的热点。 BPM（业务流程管理）企图在无秩序的业务与技术的“十字路口”寻找它们之间的联系，它将图形流程建模功能与应用开发相结合起来，使业务分析人员可以通过解析和描述业务功能下面的流程，使工作流合理化，并最终优化它们。而IT技术人员必须让现有的EAI软件协调行动，使开发基于流程的应用所需的现有应用功能可以实现跨企业集成。正像B2B集成提供商Grand Central Communications公司CTO David Linthicum所说的那样：“实际上，（BPM）等于是在开发一种组织协调数百个系统的神圣程序。” 微软公司业务流程与集成部产品经理StevenMartin说：“（如果）你询问5位顾客BPM的含义是什么，你将得到7种答案。” 要从上而下看待BPM 人们对BPM的看法各不相同，取决于是从IT角度看待它，还是从业务角度看待它。IT一般从“自下而上”的角度审视BPM，即从数据集成层到顶级BPM层。但是，当业务人员在BPM上层构建工作流，帮助IT决定各种功能如何在框架下实现时，他们以“从上到下”的视角看问题。 然而，人们普遍认为，受业务驱动的方式最有效。Tibco公司上个月收购了纯BPM厂商Staffware公司。该公司技术营销经理Matt Quinn说：“业务流程必须完全独立于IT进行定义。必须以业务为中心的观点看待业务流程的构成。当然，你不能让所有一切都从上到下地进行，你还必须在一个技术水平上捕获业务流程。但是，如果你从端到端了解业务流程，而且最初没有IT的限制，你就有了真正了解你的业务是什么的更广的环境。” 不久前，BPM还意味着“业务流程建模”，然而据有关专家介绍，由于这种观念需要业务分析人员学习软件工程的原理，因而在90年代后期宣告失败。相比之下，今天的BPM为业务分析员提供了完成绘制工作流、执行业务仿真、制作GUI等任务的方便的工具，因而可以很好地为业务端创造价值。 业务流程管理面临的第一个挑战是发现一家公司中、一个系统内、工作人员与系统环境内以及公司外部存在哪些流程，尤其是动态变化中的流程，并且将这些流程用技术语言描述出来。 流程源自对业务的理解 BPM厂商Lombardi公司的CEO Favaron说：“企业运营中有一类真正动态的流程。这些流程时刻面临压力，它们需要变化,因为机构在发生变化，或者产品组合在发生变化，或者工作流在发生变化，或者合作伙伴在发生变化，或者业务规则在发生变化。因此我们决定将一套产品集成在一起，使由IT和业务人员构成的交叉职能小组可以在一起工作，实现动态的、高度变化的流程的自动化。” 流程确定之后，业务人员就可以利用一种类似Visio那样的BPM系统工具为多个流程建立模型，然后将它们组合在一起。当这个业务设计阶段完成时，模型送到开发人员的手中，开发人员将业务流程映射到考虑EAI细节的一个开发环境中。 这种从业务人员到开发人员的移交过程非常关键。大多数厂商提供两种建模器：一种供业务分析员使用，另一种供实际描述应用如何开发和集成的细节的IT人员使用。但是依然存在的一个问题是，业务分析人员建立受业务规则制约的模型，而IT人员必须创建和维持受现有软件能力制约的模型。所以说，业务分析员无需开发人员的帮助就能利用BPM建模器开发可行的应用程序的说法是一种常见的误解。我们可能距这一现实还有很长的距离，只是今天用于业务人员的BPM建模器通常生成一些在IT开发阶段很有用的代码。 这些代码有时是UML（统一建模语言）代码（UML自20世纪90年代中期开始被用于描述面向对象的软件系统的行为），然而目前，时髦的语言是BPEL（业务流程执行语言）。大多数BPM建模器都生成BPEL代码，并且所有重要软件厂商都认可这项标准，尽管BPEL规范还不成熟，尽管BPM系统必须使用其他手段来全面组织流程。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (7/23/2005)