业务流程重组BPM

BPM体系

业务流程重组（BusinessProcessReengineering，BPR）自90年代初由美国的两位管理学专家首次正式提出来以后，迅速风靡全球，近年来随着国内信息化的进程，也日渐被国人所熟悉。然而这个诞生在美国，在大规模生产向个性化定制转变，IT技术被广泛应用的这样一个大背景中的产生的管理理论曾一度受到质疑。其原因是大规模的业务流程重组的成功几率不高，连BPR理论的创始人之一哈默后来也承认BPR理论过于激进，在更多的时候，应该采用业务流程优化(BusinessProcessImprove,BPI）而不是BPR。其实，对于国内的企业来讲，业务流程的管理按照其变革的程度应该分为三个层次：业务流程的建立和规范、业务流程优化和业务流程重组。这三个不同层次的变革分别适用于不同阶段和管理基础的企业。

业务流程的建立和规范

BPM的生命周期

在一个企业尤其是中小企业建立的初期，由于企业生存的压力，管理者普遍关注市场和销售，对流程和制度不重视，运作基本靠员工的经验和一些简单的制度，企业的成功往往取决于企业主的个人能力和一些偶然的机会，比如拥有该行业成功所需要的特定资源。处于这个层次的企业，当在解决了生存问题，开始走向规模化的时候，面临着从人治向法治的转变。这个时候解决的是一个从无到有的问题，象许多企业推行ISO9001体系或其他一些基本制度的建设，都是为了解决这个问题。国内的大部分中小企业和一些市场化程度不高的行业里的企业大都属于这个层次。

处于第一个层次的企业，面临的最大的问题是无序，通常会出现组织结构不健全，机构因人设岗的，权责不清和没有制度流程。这些企业通常没有成型的组织机构，谁熟悉哪一块也就由谁负责该项业务，职能通常会有交叉，企业的运作基本上依赖于人的经验和惯性，经常会发生越级指挥事件，同时会表现出高度集权的特点。

从流程管理的角度，这个时期的企业急需的是建立起基本的流程和规范，如业务运作流程、作业指引、岗位说明书、人力资源管理体系等。这个时期的企业不能强求业务流程的精细，关键是明确权责，识别和描述流程，使工作例行化．

业务流程优化

传统工作流解决方案和BPM的区别

由于企业规模的扩大，组织的机构会逐渐庞大，分工会越来越细，企业官僚化程度也在随着增加，这个时候面临的最大问题是低效，也就是效率的低下，通常这类企业会表现出以下特点：

组织机构完整，甚至大而全，也有书面的职责说明、制度流程，但是会出现部门间合作不畅，跨部门流程工作效率低下，决策时间长，制度流程虽然有但是没有达到精细化的程度，流程执行不到位等等问题。有相当一部分企业还通过了ISO9001认证或有完整的制度流程体系。具备这个特点的企业一般是一些迅速膨胀后颇具规模的民营企业和一些国有企业。其业务模式相对稳定，而且通常企业发展比较快。

在这个阶段的企业需要解决的问题如何提高企业的效率和反应速度。通常采用的方法是先对现有流程的绩效进行评估，识别缺失的关键环节和需要改善的环节，针对流程各环节从可以以下四个角度进行分析：

－活动：是否过于复杂，存在精简的可能性

－活动实现形式：是否能用更有效率的工具来实现活动

－活动的逻辑关系：各环节的先后关系可否作调整以达到改进目标

－活动的承担者：是否可以通过改变活动的承担者来使流程更有效率

然后通过对现有流程的简化、整合、增加、调整等方式来提升流程效率，还可以通过明确流程所有者（processowner）的形式来监督流程的整体表现，从而避免部门间推委的问题。

一般在进行流程优化的时候关注的是相对低层次的流程的效率和成本等，可以采用一些方法和工具对现有的流程进行改良，同时强调流程的有效执行，一般不会涉及到大的组织变革和流程变革，这个时候解决一个从有到更好的问题。

以一家家电企业的研发流程为例，该企业有完整的研发流程和制度，但在实际运作中，新产品研发周期很长而且研发效率较低，设计变更频繁，模具空置率高；各类评审的手续复杂，研发与市场以及工艺部门、生产部门之间经常发生推委事件等等。通过对研发流程的绩效表现、流程各个环节以流程的运作情况进行诊断分析，发现流程.各个阶段包括概念阶段、计划阶段、开发阶段、验证阶段、发布阶段、生命周期阶段各个阶段的关键控制要点的操作性不强，缺乏有效的检查清单而使重要的评审点评审受限于评审点的经验甚至流于形式；和各个相关部门之间的接口不清晰、导致重复返工；不同类型和难度的研发项目采用同样的流程导致流程的效率低下等等，找出上述问题后，针对性的优化上述流程以后，就可以有效的解决上述问题，提高研发流程的效率。

业务流程优化的特点是一些局部的变革，对企业的冲击相对较小，相对比较容易实施，缺点是只是一些改良，对一些存在结构性问题的企业往往不能解决根本性问题。

业务流程重组

这个时候往往是公司的战略转型期，需要对流程进行根本性的变革，需要全面评估业务流程，需要根据战略对流程进行重新设计和重组流程以适应公司的战略，流程重组往往伴随着IT系统的实施、重大的组织变革和业务模式的变革。这个阶段往往是一次重大的管理变革。

这个时候企业的流程本身并没有很多的问题，但是往往不能适应新的战略，一般伴随IT系统的实施或者新的战略调整，需要对企业的流程进行全面的评估和战略性思考，同时随着流程的调整需要进行一系列的配套措施。

以某知名的房地产企业为例，公司的新战略要求能够快速的交付产品，快速的进行存货周转，但是在对房地产开发的整体业务流程进行审视时，发现对现有的业务流程进行简单的优化和完善并不能解决问题，在整个开发流程中，招标采购占了相当长的时间，如果只是对该流程进行一些局部的优化并不能有效的解决快速交付产品的问题，在对整个业务流程进行后战略性思考，提出了从设计角度对一些材料和工程进行标准化设计，在采购方面建立战略采购系统的模式，通过这种标准化的产品设计和战略采购，使得一些费事费力的采购招标过程可以免去，从而极大的加快了产品的交付和提高了效率。这个变革涉及到整个规划设计、采购招标乃至成本预算等流程的变革。

业务流程重组因为往往伴随着业务模式的调整，是一次重大的管理变革，存在较大的实施风险，但一旦成功，往往能给企业带来业绩的重大改善。

这三个层次的流程管理适用于不同阶段的企业，当然他们之间的界限不是严格意义上的。在进行业务流程的规范时，最好能对流程进行一些优化，业务流程优化和业务流程重组之间的界限也只是程度上的区别，关键是进行流程管理时根据管理的现状采用合适的方法和步骤。

BPM的4种方法

面向工作流的BPM

工作流描述了在BPM空间内人与人的交互和人与系统的交互。根据独立分析师Sandy Kemsley所述，工作流就是我们所熟知的BPM的初始阶段。“一开始就有工作流，”Kemsley在她网站的第二专栏中写道。“更确切地说，在预先确定的流程图中有一个扫描过的人与人之间交互的路由文档。”在当代BPM的大背景下，工作流和EAI（企业应用集成）平起平坐，并在某种程度上，可以看成是人的集成。工作流BPM旨在优化业务流程中以人为本的活动。这些措施包括活动监控，流程治理，正如BPM的成因，是对未完成文档向下进一步处理的编制。

面向文档的BPM

文档管理和工作流齐头并进。当文件穿过工作流时，追踪文件的去向以及它们的变动，维护文档记录的可靠性、安全性、可用性，早在计算机革命之前，已经成为了业务的必要元素。今天的企业文档管理系统利用计算机技术来提供存储、安全、索引和检索选项。可用性正日益重要，因为多方参与者经常需要凭借多个应用来使用同一个文件。因此，依靠现有业务系统的集成是面向文档BPM成功的一个主要元素。

面向业务规则的BPM

自动化这门学科可以追溯到人工智能的早期，当时研究人员试图以最简单的术语，集中于规则的使用来描述复杂的系统。像最早的尝试模拟国际象棋游戏实验计算机，这些系统按照状态机的模式工作。有点像游戏规则，组织显式地或隐式地按照关键“规则”来定义过程，这些关键“规则”在流程的某些点上提出要做出哪些决定或更改——或请求哪些授权。一旦被称为推理机，同类的软件系统就发展成了业务规则引擎或者业务规则管理系统。创建和维护业务规则的复杂性常常成为这些推广这些系统的阻碍成分。

这些系统承担了类似以建模为中心的BPM工具的角色。（诚然，很多用户会将以建模为中心的BPM作为一个独特的类别。）以建模为中心的方法起初倾向于自上而下的进行工作，这些工作就是在模型中用特殊符号描述一个组织，或组织的改进。近年来一些工具厂商已经完成对可执行模型的支持——他们的模型可以生成或者帮助形成可用的业务逻辑的代码。与这里介绍的其他类型的BPM系统相比，业务规则引擎在纯BPM系统中的规模将变得更大。

面向EAI的BPM

在整个90年代从不同系统对集成可操作型数据方法的改进，采取的是企业应用集成或EAI的形式。虽然这些往往是硬接线的一对一集成，消息队列这种应用集成变得尤其流行，同时隐含业务流程表现为有组织的队列，例如，清除银行支票或执行库存订单，让集成服务器很大程度上有了面向工作流的BPM的味道。今天，许多架构师都倾向于把数据集成问题看成业务流程问题。同样地，一些架构师将期望根据B2B或电子数据交换（EDI）来集成的过程自动化。

业务流程建模BPM

业务流程建模（BPM, Business Process Modeling）是对业务流程进行表述的方式，它是过程分析与重组的重要基础。在跨组织业务流程重组的前提下，流程建模的主要目的就是提供一个有效的跨组织流程模型并辅助相关人员进行跨流程的分析与优化。目前有大量的流程建模技术能够支持业务流程的重组，但同时这也给相关人员带来困惑：面对如此众多的技术，他们很难选择一种合适的技术或工具。同时，目前对流程建模技术的研究大多集中于建模技术的提出与应用，缺乏对现有技术的整理与分类以及技术之间的横向对比，这也就加深了建模技术选择的复杂性。

BPM 标准

在这个体系结构的核心部位是一个执行流程的运行时引擎，其流程的源码是由基于XML的BPEL语言写成，BPEL是当今最着名、广泛应用的BPM标准，及最优秀的BPM执行语言。这些流程是由业务和技术分析家使用支持可视化流程图语言BPMN——最好的BMP图形语言——的图形编辑器设计出来的。此编辑器包括一个导出器，可以从BPMN图生成BPEL代码（之后部署到引擎）。（在当前许多Java开发工具中，BPMN到BPEL的流程与UML到 Java的流程相类似。）

人和计算机的交互驱动引擎里流程的执行。人这个参与者使用一个图形化工作列表应用程序浏览并执行未执行完毕的手工工作（在流程运行的引擎里）。依附于公司网络的但在引擎地址空间外的内部IT系统，被储如web服务，j2EE，或COM的集成技术，通过XML作为选用的消息格式所访问；用编成语言如 java、C#写出的内部交互可以是更轻便的内嵌代码片断。外部交互是典型的基于web服务的通信，由编排控制，例如那些用新兴的XML语言——WS- CDL 这个领先的编排语言所创作出的外部交互。虽然编排描述了多个参与者流程交互（在business-to-business电子商务里很典型）的整体、引人注意的视图，但是编排工具包可以用来生成一个基本的BPMN模型，其可以捕捉某个特定参与者流程所要求的通信，同时这个工具还可以验证一个给定的流程是否满足编排的要求。（WS-CDL文献建议由WS-CDL生成BPEL而不是BPMN。但是在现在的体系结构中，BPMN作为一种设计语言是一个必要的间接层。）

开发过程

BPM系统管理员里利用一个图形化的监视控制台来维护和跟踪引擎流程的状态。控制台使用一种管理语言与引擎衔接。实时引擎将流程状态持久化到数据库，控制台直接与数据库碰面，而不是用管理语言来沟通。运行时引擎将流程状态持久化到数据库，控制台直接与数据库碰面而不是使用管理语言来专门执行流程的请求。监控构造也支持业务活动监控（Business Activity Monitoring （BAM））或者仪表板式的业务监控。

在这个平台上的开发过程如下：

1.从一个WS-CDL choreography生成一个初始的BPMN模型。如果流程并不是从一个编排衍生而来则越过此步。

2.设计BPMN模型

3.从BPMN模型生成BPEL

4.开发必要的人和系统（内部和外部）的接口

5.部署BPEL代码和其必要的接口到引擎

6.使用管理和监控接口跟踪正在运行的流程。

这个体系结构的全貌（由WFMC——众多BPM标准组织中最成熟的一家——的参考模型激发而成）类似许多集成厂商（如，IBM、BEA,、Oracle、Tibco,、SeeBeyond和Vitria ）所提供的平台。使这个体系结构特别的地方是其标准的选择。BPEL、 在理想体系中的BPM 标准 图2

BPMN和 WS-CDL都被包含进来，因为他们分别是执行、设计和编排的最好解决方案，BPM最重要的三个部分。

（如图2所示未来可能包括新兴标准BPQL——用于监控，BPSM和BPDM——用于元模型建模，BPRI——用于运行时接口，BPXL——用于BPEL扩展）。事实上，很多厂商支持或正在实现支持BPEL。但是BPMN的支持非常少（大多数厂商提供各自的方案），WS-CDL的支持几乎没有。BPEL并不够。这个体系很理想化，需要实际的实现。[1]

音乐中的BPM

BPM = Beat Per Minute，每分钟节拍数的单位。最浅显的概念就是在一分钟的时间段落之间，鼓总共发出了几次声音，这个数量的单位便是BPM。

现多出现于音乐类游戏，用来衡量游戏的难度，《qq炫舞》《劲舞团》《炫舞吧》……里面都有。

其他意义

BPM = bipolar membran，双极膜。

BPM = Beam Propagation Method，束传播方法。