一、BPM历史
BPM（Business Process Management），即业务流程管理。从字面意思理解，它并不是一个技术名词，而是一个管理学术语，实际上的确如此。BPM不是近期出现的新概念，其起源可以一直追溯到20世纪初。弗雷德里克·温斯洛·泰勒在1911年出版了《科学管理原理》，标志着早期流程管理技术的诞生。在科学分析的基础上，泰勒研究了如何建立最优的工作流程，以此提高生产效率。泰勒进行的研究有以下几个方面。
● 动作和时间研究，以科学研究结论代替经验教条。
● 能力与工作相适应，合适的人从事特定的工作。
● 标准化，包括操作方法、工具、机器和工作环境等。
● 比较标准和执行的实际情况，并进行控制。
这些研究使管理在历史上第一次从经验上升为科学，成为讲求效率的优化思想和调查研究的科学方法。尽管已经过去了100年，尽管那时并不叫BPM，但是这些思想至今仍然在现代BPM方法论中占据着核心的地位。虽然现代社会和信息技术的发展使商业模式已经变得与传统迥然不同，但从本质上看，效率、成本、利润、质量等流程管理关注的核心问题一直没有变过。
从流程管理的本质上可以看出，BPM并不是一个IT术语，更不是因技术的发展而起源的，相反，BPM自始至终都是管理学的术语和概念。一方面，尽管在现代加入了更多流程改进、效率提升等的方法，提出了业务敏捷的概念，但其核心仍然与100年前泰勒的理论相去不远；另一方面，虽然在整个发展历史上，与流程管理相关的方法、关注点和技术曾经以各种各样的面貌出现，但其本质也一直没有太大变化。
二、BPM的生命周期
2.1广义生命周期
广义生命周期是从业务管理的角度说明的。BPM的本质是企业业务流程的管理，可以说是企业运营的流程表现形式和管理形式，因此，BPM的生命周期与企业的整个管理架构密切相关。
从业务上说，完整的BPM几乎覆盖企业战略管理、战略流程定义、业务构建、业务流程定义、业务服务定义和编排、业务执行和监控、业务流程优化改进以及战略调整等企业管理的方方面面，如下图所示。
从上图中可以看出，业务流程的产生总是来自企业的某个战略构想或目标，从而产生如何实现该构想的需求。实现该构想，需要一系列的执行步骤和业务能力，并由一系列的职能部门来执行。这个决策会转变为实施计划，进而转变为具体的可执行的业务流程。为了洞悉该战略构想的执行状态、发展趋势，需要对业务流程进行监控。一旦发现问题和偏离，就要进行改进。若通过监控发现是战略构想出了问题，还需要改进战略，从而形成新一轮的发展。直至该战略构想完全实现或废弃，进而不再需要相应的业务流程为止。
2.2狭义生命周期
狭义生命周期是从BPM管理系统（BPMS），即IT实现的角度说明的。BPM的建设是一个长期的过程，不可能一蹴而就。通常，企业的BPM旅程都是从可执行业务流程而不是从战略管理开始的。因此，作为BPM的实现工具，IT工具的战略管理和业务流程建模、执行通常也是分离的。所谓“狭义生命周期”，即是指可执行业务流程在BPMS系统中从设计建模到部署执行、监控和改进的过程。
一个合格的BPM产品至少必须覆盖狭义的生命周期管理。因此，在一个BPM产品中，能够看到流程设计器、业务流程的运行环境、业务流程的指标定义器、业务流程的实施监控及业务流程的模拟、仿真、分析等工具。
三、BPM和企业业务框架（EA）的关系
在企业提出了自己的战略目标，并指定了企业发展的业务框架之后， BPM成为了将企业的业务框架（EA）落地的一个很好的承上启下的方法和工具。
由于BPM以业务流程为中心，并且明确地指向特定的战略目标，因此，BPM项目的需求获取不能再以部门或单一业务模块为单元，而必须自顶向下，从战略目标开始进行全面的流程梳理和资源整合。可以从纵向、横向、环向三个方向来说明BPM建设的整个生命周期，如下图。
3.1纵向
业务流程的建模明确地指向特定的战略目标，整个业务流程的建模、分析、设计、执行、度量、监控及优化都围绕着如何提升战略目标的价值来进行。换言之，一个或一组业务流程的建设目标是为了实现某个战略目标；流程的分析、设计是为了用最高的效率实现最大的战略目标价值；业务流程及业务流程活动的度量指标定义，是为了测量每个业务流程及业务流程活动执行过程和执行结果向战略目标价值提供了什么价值点；监控的目的是为了发现影响了业务流程价值输出的那些关键活动，并采取措施优化之，使整个战略目标的价值最大化。
如上图所示，BPM实施自顶向下是战略实施的过程，而自底向上则是实现战略目标价值增值的过程。
1A.洞悉现状
洞悉现状是一个持续不断的过程。它通过对企业运营的各层次和各方面进行全方位监控，来全面了解企业现状，进行SWOT分析，找到改进的目标和方向。
2A.战略规划
根据对现状的分析，制订发展和改进的战略目标模型，它包括定义战略目标、定义用于度量战略目标执行情况的KPI模型以及建立监控战略目标执行情况的监控模型。
3A.业务分析与决策
根据战略规划，分析实现战略目标所需的业务能力，定义提供这些业务能力的组织和机构，然后使用所定义的业务能力和组织机构来建立实现战略目标的战略业务流程模型。为了监控战略目标的实施情况，还需要定义测量这些业务能力贡献于战略目标的价值KPI。
以上三个阶段是业务需求的定义和分析阶段，由此获得BPM建设的目标和业务需求。接下来的三个阶段，是将上述目标和需求实施落地的阶段。
1B.战略实施计划
根据上述的目标和业务需求，将执行战略目标的业务能力分配到具体的业务部门，寻找并定义每个业务部门用于执行该业务能力的工作单元（科室、组等），然后使用这些工作单元定义业务流程模型，该流程模型将实现所需要的业务能力。为了监控战略目标的执行情况，接下来定义业务部门绩效KPI来测量这些业务部门执行战略的绩效。
通过这一轮工作，将特定的战略目标、战略测量和业务能力按照组织架构分配到具体的职能部门，每个职能部门都承担某些业务能力，向战略目标提供特定的价值。显而易见，这样业务流程是端到端的（从战略目标执行开始到战略执行结果输出），是面向价值的（从业务流程的定义到业务流程的执行都指向战略目标的实现），是跨部门的（各个部门都只是统一的战略目标中业务能力链中的一环），是面向业务的（到目前为止，业务流程的建模仅需业务人员就能够完成，不依赖于具体的IT实现）。
2B. 业务构建
在业务构建阶段，要把战略实施计划阶段所建立的端到端的业务流程中的每一项业务活动落实到具体的业务执行角色，定义处理业务逻辑所需的SOA服务，定义具体的业务数据、业务表单和人机交互界面，并且定义监控业务执行情况的KPI，使之成为可执行的业务流程。在此阶段仍然以业务人员为主来构建业务流程，IT人员则负责提供业务数据和业务逻辑所需的SOA服务。IT人员需要从基础信息化系统中开发、集成或编排已有的服务来提供所需的业务数据和处理业务逻辑。
经过这一轮的开发工作，指向特定战略目标的端到端的业务流程已经成为可执行的业务流程，可以在BPM 模拟仿真环境里运行。业务人员和IT人员可以对其进行模拟仿真，找出业务流程设计中的热点和瓶颈并进行性能的优化和改进。
3B. 实施与执行
在实施和执行阶段，业务人员和IT人员对已经构建完毕的业务流程进行版本管理，可以将某个版本部署到测试环境中进行测试，部署到演练环境中进行正式上线前的演练，最后部署到正式的生产环境。在运行期间，可以进行流程版本的替换、流程实例的迁移以实现快速的业务变更。
在此阶段，随着业务流程的执行，所定义的KPI将实时地、持续地展现战略目标实施的动态。管理者可以实时地、准确地获知战略目标实现的趋势，因此得以洞察现状，获得改进的目标和方向，从而完成整个BPM建设的闭环管理。
3.2横向
业务流程明确地指向特定的战略目标，每个战略目标都需要多项业务能力和多个组织机构的协作才能完成。因此，BPM的建设必须在横向上贯通，并全面整合业务能力，这样才能够实现战略目标价值。下图展示了横向整合所包含的内容。
1.业务分析与决策阶段
在此阶段需要跨越组织机构，将实现战略目标的业务能力整合起来，以完成战略目标。
此项整合主要依靠的是企业整体管理制度的改革。在此基础上，BPM即可通过其IT工具将业务能力整合为端到端的业务流程活动。
2.战略实施计划阶段
在此阶段需要跨越部门设置，将以前各自为战的各个工作单元统一整合到一个端到端的流程中来。每个工作单元所执行的业务活动均明确地服务于特定的战略目标，可以被统一的绩效指标所考核。此项整合主要依靠的是企业的行政管理方法的改革。在此基础上，BPM可通过其IT工具将各个工作单元整合为端到端的业务流程的执行者。
3.业务构建阶段
在此阶段需要通过BPM所提供的技术架构，将以前分散于各个工作单元的业务服务以SOA服务资产的形式统一整合到端到端的业务流程中，使企业的资产得以重用，同时也使服务资产可以被KPI所测量，得到每个服务资产相对于战略目标的贡献程度，由此获得优化服务资产的依据。
4.实施与执行阶段
在此阶段，端到端的业务流程执行所需的服务分散于各个异构的基础信息化系统，需要通过SOA技术架构将各个IT节点整合起来，以提供业务流程端到端的执行能力。
通过以上四个层次的整合，企业可借助BPM工具完成战略构想到业务执行的落地。
3.3环向
业务流程最终服务于战略目标，因此，业务流程的监控、优化、改进也紧紧围绕着战略目标进行。下图展示了环向上各阶段的业务流程监控目标。
1.战略级监控
在此级别，监控的主要内容是战略目标实现的一系列指标的实时动态，以获知战略目标执行的趋势。战略目标的指标来源于业务分析与决策阶段所定义的一系列价值指标。
2.业务分析与决策级监控
在此级别，监控的主要内容是用于衡量战略目标的一系列价值指标的实时动态。通过对每一个价值指标的监控，可以获得实现特定战略目标的某一业务的执行情况，以便及时响应。
3.战略实施计划级监控
在此级别，监控的主要内容是以职能部门为单位的工作单元绩效指标的实时动态。通过对这些指标的监控，获得每个职能工作单元执行战略目标的情况，以便针对流程瓶颈及时进行调整。
4.业务构建级监控
在此级别，监控的主要内容是以业务服务（业务流程活动）为单元的执行指标的实时动态。通过对这些指标的监控，获得业务流程健康度、效率等的评估，从而及时优化和改进业务流程。
5.实施与执行级监控
在此级别，监控的主要内容是IT系统和设施的各项性能、可靠性、服务能力等指标，从而获知IT系统和基础设施对业务流程执行的影响，以及时优化和改进IT系统和基础设施。
四、企业业务框架（EA）
企业IT架构和企业业务架构是一体的，在企业构建IT架构时，需要先搞清楚企业的业务架构，确定业务组件，然后对应上相应的IT系统。
下图是一个零食企业的CBM（Component Based Modeling的缩写，即“业务组件建模”）图。
组件化就是把企业的产品、销售、采购、生产、财务等业务功能转变化为业务模块，即业务组件。
下图是找出热组件，通过热映射图确定出“热”领域，以发掘新的业务价值。通过分析不同映射领域的相对业务价值，管理者就可以确定需要及时关注哪些组件，这个叫做热图。这类分析得出的“热映射”突出了具有最大经济价值的组件。
要确定出热映射的优先级，管理人员一般情况下会考虑下列问题：哪些组件使企业具有最显著的市场特征？哪些组件对企业持续获得、增加利润的影响最大？哪些组件存在重大的成本、资本优化的可能性？
业务组件可以比喻为搭建企业的积木或者部件。根据业务的复杂程度不同，一般的企业会有100到200个业务组件，它们涵盖了企业所有的业务活动。组件内部的活动在企业范围内要做到全面且不重复。企业所有的业务活动必须而且只能归属于某一个组件，如果其他组件也需要相似的服务，只能通过标准的调用方式来使用，而不能重新定义一次这项活动。这种调用就成为一项服务，这也是SOA的理念在业务层面的体现。
每个业务组件都有自己的业务目标，有一系列紧密关联的业务活动，还有人力、技术、财务等资源和管理的方法以及可以对外提供的服务。业务组件能够独立地进行运作，即可以由企业内部完成也可以外包。下图说明业务组件的五个方面：业务用途、活动、资源、治理模式和业务服务。
下图说明按照责任和能力组织活动，实现内部专业化和外部专业化。
业务的开展依赖于IT系统的支持，而IT系统的需求又来自业务。如何使业务与IT的关系协调一致一直是企业管理者极为关注的问题。业务与IT的关系是相互支持和相互促进的，但是在不同的企业或者企业不同的发展阶段，业务和IT的关系也会有所不同。
在企业架构中，业务架构是核心内容，它决定了IT架构的内容，但是IT架构对于业务也有推动的作用。互联网、5G、人工智能、混合云等新技术的出现，从根本上改变了很多企业运作的方式。
大部分IT系统功能是通过与用户交互方式实现的。IT系统流程顺序是与业务流程密切相关的，或者说，IT系统的开发需求和目标就是实现业务流程，以及业务功能性和非功能性的需求。所以IT系统的设计和开发需要以业务流程、业务用例、业务需求说明等作为输入。
当IT系统开发完成上线以后，业务流程开始在系统的支持下运转，企业则需要一段时间才能评估其是否实现了既定的目标。通过对运营数据的分析，可以发现实际运营与目标之间的差距。根据差异的情况，企业可以决定是调整流程、系统，还是调整运营目标，重新开始业务架构和IT架构的设计，从而进入新的迭代的设计过程。
五、BPM项目开发方法论
BPM建设不同于传统的基础信息化项目，它具有如下的特点。
● 有着极强的导向性：面向价值增值（战略目标）而非仅仅实现当前业务。每个流程和流程里的每个活动都可以用指标衡量其价值贡献（相对于战略目标）。因此，BPM的建设成功与否，可以用企业最为熟悉的商业价值评估体系来评判并优化调整。
● 以端到端的业务流程为中心：这意味着流程梳理是BPM建设的前提条件。基于片断化的、局限于部门内部的流程建设，BPM难以获得BPM带来的价值。
● 由业务而非IT驱动：这意味着业务人员将从单一被动的需求提供者和业务执行者的角色提升为更积极主动的业务设计者、业务优化者角色。业务人员和IT人员将密切配合起来。
● 强调服务的编排和集成：利用并整合企业资产（包括IT和非IT），以快速、敏捷地建设和变更业务流程。从开发到应用，周期短、见效快。因此，SOA是建设好BPM必不可少的条件。
正是由于上述BPM项目区别于一般信息化项目的显著特点，BPM的实施方法论也与通常的信息化项目有着巨大的区别。
5.1 BPM项目实施和其他项目实施的主要区别
BPM主要是由业务来驱动的，这个特点决定了流程的开发是“粗粒度”的（或者说是“业务粒度”的）。
所谓“粗粒度”和“业务粒度”，是指BPM通过业务人员可以理解的业务步骤（即流程中的活动“环节”）的概念来描述业务的主要活动，屏蔽掉了业务部门不必关心（或者看不懂）的细节。
开发一个业务流程最先要定义的，是定义出流程中的“泳道”。泳道界定了这个流程要管理的“业务粒度”的边界，规定了流程中不同角色的范围和相互作用关系。
● 所谓“BPM”（业务流程管理），是要管理一个有序的业务过程的“流动”。流程中的“泳道”里面有“环节”，每个“环节”都有“状态”，代表着业务活动中的一个状态点。这个环节状态是业务部门所理解，同时也可以被业务部门监控和度量的状态。这个状态又是有序的，流程中一个业务环节状态的“结束”，标志着流程中另一个业务环节状态的“开始”（当然也不排除有“并行环节”的流程）。这些环节状态的顺序变化表述了一个有明确业务含义的流动，是一个由“粗粒度”颗粒组成的，具有明显业务意义的流动。
● 流程的每个环节都可以被“绩效”，可以通过流程的“业务绩效指标”来监控和改进流程效率。也就是说，流程的监控是在业务粒度上的监控，以提供企业的业务价值为目标。
● 如果是以人工任务为主的流程，每个环节的执行人需要依赖于公司人员的组织结构和岗位角色的结构。由公司的组织结构和业务内容来决定“谁”可以做“什么”业务。
● 对于人工环节的表单开发。表单是根据业务人员实际工作的前端页面设计的，直接表示业务的应用页面。因此，BPM的产品套件一般都带有图形化表单设计工具，以便和业务人员更方便地交流，甚至能让业务人员直接使用。BPM的产品套件里面也有“页面流”的开发工具，让业务人员更方便地开发表单逻辑。
以上这几个特点都说明了流程的开发是围绕着业务的粗粒度的开发，需要在流程开发设计的过程中更多地和业务人员交流，一起来完成流程的定义、开发和改进。
当然，根据BPM要管理的流程的不同，这个“粒度”的大小也不同。BPM梳理方法论里面说的BPM的五级流程，对应的就是五种粒度。第一个是企业高层要管理的粒度（战略级的业务粒度）；第二个是部门级要度量的粒度；第三个是业务分析师在描述具体流程时需要有的业务粒度；第四个是执行层面的流程的粒度（执行环节）； 第五个是执行层面的简单操作的粒度（如表单业务逻辑）。粒度不同，流程的开发和处理方法也不同。例如，第四级或第五级流程的粒度最细，属于执行层面的流程，通常有IT部门的介入。
因此，流程开发是一个“粗粒度”的组合式开发过程，也是一个不断迭代、不断改进的过程。和一般IT项目相比，流程开发是使用符合业界标准的流程工具进行开发。纯代码的开发量相对较少，开发人员更多的是使用图形化工具定义流程，对参数进行定制，通过服务的调用去编排已有的服务。因此，BPM项目的开发强调了如下内容。
● 交流。不断地和业务部门交流，共同开发流程。业务部门应该能够使用流程开发工具对流程进行定义和修改，用标准和工具来减少开发过程中IT部门和业务部门的交流障碍。
● 简单。流程开发是一个“粗粒度”的开发，需要业务人员的参与驱动流程的开发和完善。正因为如此，流程开发需要一个“粗粒度”的开发模式。在这个“粗粒度”下，要尽量屏蔽掉业务人员弄不懂的IT语言和实现，尽量使用业务人员能够看懂并使用的流程开发工具。
● 流程生命周期管理。基于业务流程经常需要变化的背景，流程开发必须把流程的生命周期管理作为流程开发不可忽略的部分。这里需要考虑的不仅是流程模板的版本控制机制，还有流程实例对版本的升级机制（分水岭，一刀切），以及流程部署上线的运维管理流程等。
5.2 BPM“粗粒度”开发的基本原则
“粗粒度”（或者“业务粒度”）开发模式的基本原则如下。
● 用标准的、图形化的、可定制化的流程产品开发工具开发流程和表单，尽量避免使用代码。
● 把需要用代码开发的部分尽量包装成可重用的组件，一般分为两类组件。
一类是可以重复调用的服务，这个服务要包装成为“粗粒度”的有业务含义的服务（即SOA）。SOA的出现是流程管理技术从工作流转向业务流的分水岭，是指SOA的服务使BPM的开发可以简化成为一个个“人工任务环节”和“SOA服务环节”，把业务人员不懂的IT细节屏蔽在SOA的服务环节之内。
一类是公用的基本模块库，可以在搭建流程平台时作为平台模块库提供。例如，将常用的表单模板、常用的子流程、常用的开发环节表单所需要的组件（菜单、按钮、人员选择框等）封装成组件的目的，是要尽量保证在这个“粗粒度”以下的这些业务组件（SOA服务）的相对稳定性。这样在未来不断的流程改进中，业务人员可以简单明了地掌握流程的各个环节，需要时直接组装和重用（而不是重新开发）流程中的各个组件。
● 先搭建流程平台，再做具体业务流程的开发。在流程项目实施时，首先搭建业务流程平台，也就是把常用的公共组件建到流程平台上，把企业常用的典型流程模板库放在平台上。在流程平台搭建完毕后，再开发具体流程。这样，具体的流程功能开发就可以重用平台的通用功能模块和流程库，做到真正由业务驱动的“粗粒度”开发。
● 把业务人员可以定制的业务规则（包括人员任务分配规则）外挂，成为通过业务人员制订（而不是开发）就可以改变的业务组件。
六、BPM的管控方法论
企业采用和实施业务流程管理是一个长期的、持续的、不断提升、不断成熟的过程。为了保证BPM实施的成功，需要对BPM项目进行必要的管控。
6.1 BPM能力模型
企业采用和实施业务流程管理是一个长期的、持续的、不断提升、不断成熟的过程。为了评估企业应用业务流程管理的能力和成熟度，定义了如下图所示的BPM能力模型。
把企业应用BPM的能力分为五个级别，分别定义如下。
- 初始级：BPM的探索和尝试。企业此前没有任何实施BPM的经验，这时实施BPM项目完全是探索性的，BPM项目对企业来说也是局部的和非核心的。BPM项目的计划与实施之间存在较大误差，实施过程缺乏有效的协调和合作，会经历很多坎坷甚至弯路。项目最后成功与否主要取决于项目团队有关BPM的学习能力、技术能力以及是否采用了正确的业务流程模型。在这个阶段，BPM项目所带来的实际价值和大家的期望还有很大距离。尽管如此，初始阶段对企业来说还是很重要的，企业可以通过实践BPM的项目实施来真正认识BPM，了解BPM项目的特点，总结经验教训和最佳实践，为进入下一个高级阶段打下基础。
- 掌控级：最佳实践的应用和积累。经历了初始阶段，企业总结了BPM项目实施的经验教训和最佳实践，因而能够更顺利地实施BPM项目，同时团队有关BPM及其产品的技能有了很大提升。但是企业缺少统一的标准和规范，可以确保将这些有价值的经验教训和最佳实践应用到每一个项目，同时缺乏形式化的BPM方法论对项目进行指导。
- 标准化级：从BPM项目到BPM项目组。这一阶段，企业已经将前几个阶段的经验教训和最佳实践进行了总结归纳，更重要的是，形成了可操作的、必须遵循的BPM项目标准，这样企业就可以轻松地从单一的BPM项目扩展到可同时进行的BPM项目组，并且项目组的成本和质量是可以预知的。在此基础上，BPM项目实施的方法论也已经形式化，保证每一个项目都有统一的方法论指导，并且还处于标准的不断完善和自我更新的良性过程之中。在此阶段，企业应该建立起全局的BPM管控模型，用以统一管理、指导和规范所有的BPM项目；企业层面的BPM体系架构已经创建，以提供全局的BPM的IT支撑平台；企业的BPM项目正以前所未有的规模加速进展，企业将从BPM中获得很大的投资回报（ROI）。
- 流程优化级：BPM在企业层面全面实施。在此阶段，BPM项目被企业的战略目标和业务价值链驱动，同时做到了企业层面的业务流程的质量监控，实现了企业战略目标—>业务价值度量—>分区（部门）业务价值度量—>业务流程度量指标的映射。通过业务流程，企业全面掌控每一项业务是否合理高效，对企业价值链直至战略目标的贡献如何，进而将监控结果反馈到业务流程，实现业务流程的持续优化。
- 业务转型级：基于业务流程的企业文化。在此阶段，BPM已成为企业战略、企业文化和管理层面的一部分，企业业务都由业务流程来管控。例如，BPM度量指标成为企业评估绩效的最重要指标，用于企业的激励机制。
6.2 开启业务流程管理之路
已经提到企业采用和实施业务流程管理是一个长期的、持续的、不断提升、不断成熟的过程。在广泛总结企业实施业务流程管理的成功与失败的经验， 并基于最新的业务流程管理理念的基础上，本节描绘出一个企业从零开始采用业务流程管理的一般路径，为正在实施和准备实施业务流程管理的企业提供一个参考蓝图，目的是为了使企业在应用业务流程管理的过程中少走弯路，使业务流程管理的理念和技术更加有效地为企业的业务价值链乃至企业的战略服务。
6.2.1 企业业务流程管理之路
下图定义了一般意义上的企业采用业务流程管理的路径。
企业采用业务流程管理是为了解决自己的管理问题和业务问题，提升自己的业务价值和管理效率，最终提高自己的市场竞争力并实现自己的战略目标。因此，业务流程管理更多的是一种管理理念和管理科学，而不仅仅是技术问题。企业在决定采用业务流程管理之前，应该全面审视和分析目前企业所面临的业务挑战和业务价值，明确自己在哪些领域迫切需要业务流程管理，采用业务流程管理要解决哪些问题，最终实现哪些业务价值。针对这些问题列出所有需要的业务流程，并排出优先级。
企业在决定采用业务流程管理之前既要有近期目标，也要有远期规划。在初期应该采取 “想大做小，快速扩展”的原则，也就是采用BPM要有大的设想和规划，最终实现BPM在企业范围内的广泛采用，实现企业的BPM转型，但又要始于小项目。起初的项目尽量选择规模和复杂度小、价值和影响度适中的项目，争取不断取得项目的成功，增强信心和影响力，积累最佳实践和经验教训。随着成功的BPM项目的不断增加，特别是对企业价值链的贡献有目共睹，BPM的项目规模和项目数量也会快速扩展。此时BPM的规模和数量决定了企业必须实行有效的、统一的BPM管控机制。以企业层面的BPM卓越中心的建立和有效运转，标志着企业进入BPM的项目组阶段。随着企业BPM的深入进行，BPM逐步成为企业管理文化的一部分并在全企业范围内普遍采用也就成了顺理成章的事情了。下图给出了企业采用BPM之路中各个阶段的主要行为和特点。
6.2.2 企业采用BPM所遇到的各种问题
对采用业务流程管理所面临的各种问题在管理层面、业务层面和技术层面进行全面彻底的分析和总结，必然会对企业今后的业务流程管理之路起到事半功倍的效果。在下面总结了企业在业务流程管理之路中可能面临的各种问题和挑战。
1. 业务流程实施和管理能力的缺失（软技术）
（1）缺乏对业务流程的正确认知
很多企业对业务流程的理解仍然停留在页面流或办公自动化的层面，这必然限制了业务流程管理在企业的应用层面和今后的发展。
（2）缺乏对业务流程的敏锐洞察
业务流程是企业无形而宝贵的资产，业务的流程化实际上是对业务的高层次抽象、提升并用标准语言描述的过程。建立业务流程化的长效机制以及驱动业务流程向清晰、健壮、优化的方向不断演化，需要对业务的深入理解以及对业务流程的敏锐洞察。
（3）缺乏采用业务流程的长远规划
企业应该认识到业务流程管理的应用是伴随企业成长的长期过程，企业在实施业务流程管理之前就应该对企业的业务流程管理有一个长远的规划，避免盲目性、短视性以及随之而来的管理失控、投资回报低以及重复建设等负面效果。
（4）缺乏对业务流程的快速交付能力
业务流程经常与企业的核心业务紧密相连。业务流程项目的快速交付能力直接影响业务流程管理系统的运行效果和人们对它的信心。提前对业务流程的交付能力进行评估，包括业务、技术和管理层面，找到其中的瓶颈所在，对今后的业务流程管理的高效运转非常重要。
（5）缺乏对业务流程实施的资源和技术
业务流程管理从某种意义上说是IT技术在企业业务和管理层面的应用，需要各种资源、资金和技术的全面支撑。企业应提前做好这方面的评估工作，认识到自己的不足和风险，提前做好计划和调整工作。
2. 企业层面业务流程平台的缺失 本项目中已经采购
企业层面业务流企业可能从某一个部门开始实施业务流程管理，但会逐步扩大范围，甚至覆盖核心业务，最终依赖业务流程管理平台进行全方位的管理。因此，企业在一开始考虑业务流程管理平台的选型时应有一定的前瞻性，提前规划将来的各种需求（包括功能的和非功能的），充分考虑业务流程管理平台的可扩展性和健壮性是否能适应将来的业务需求，避免重复投资。一般来说，企业在选型业务流程平台时应充分考虑以下几个方面。
（1）企业层面的业务流程存储库
企业在实施第一个业务流程项目之前，就应该充分认识到业务流程是企业的重要资产，利用和管理好这一无形资产对于企业具有重要意义。应该提前设想建立企业层面的业务流程存储库的问题。在企业层面建立对业务流程资产的存储机制和管控机制，一定是企业在业务流程管理之路上的必经阶段。因此，要把业务流程管理平台是否具备这样的能力作为重要的考察方面。
（2）与企业其他系统的集成能力
业务流程管理系统与传统工作流系统的区别之一，就是与其他系统的集成能力。业务流程管理系统能够自动地、安全地、基于标准地与第三方信息系统进行交互操作和数据交换，真正做到端到端的业务流程自动运行，将业务人员、信息系统以及企业的其他资源有效地整合。即使最初的业务流程项目并不涉及很多与第三方信息系统的集成问题，企业也必须提前认识到这一需求可能带来的挑战，充分考虑到业务流程管理平台与已有的信息系统的集成问题。
（3）企业级的标准化
业务流程在企业范围内的全面采用，必然带来标准化问题。例如，业务流程从需求描述到实现需求，企业需遵循一致的标准，这样才能进行统一的存储、部署和管理。再如，对流程的存储和管理本身也需要企业范围内定义标准的流程加以规范等。企业在实施业务流程项目前，应根据自身的特点充分考虑到自己应选择什么样的标准对业务流程进行建模，需要什么样的标准与第三方系统进行集成，需要什么样的标准实现人机交互等，将这些作为选择业务流程平台的重要依据。
（4）企业级的安全机制
安全机制对企业范围内的业务流程应用也至关重要。例如，什么人或角色可以对流程进行编辑和修改，什么角色可以对流程的运行状态进行监控或干预，什么角色可以对企业的资源或人员的角色定义进行调整，什么角色可以对业务流程管理平台进行系统级的维护和操作等。企业必须考虑业务流程管理平台是否具备足够的安全设置以支持自己的潜在需求。企业在实施业务流程时就应在安全方面多加考虑、逐步完善，对每一个业务流程项目进行指导，避免各自为政，为将来业务流程在企业范围内的全面采用创造条件。
（5）企业级的监控机制
企业层面的业务流程应用必然对业务流程的监控机制提出更高的要求，如对业务流程实例监控、关键业务指标监控以及业务统计数据监控的支持，以及对监控的高度定制化的支持等，这些对企业价值链的分析和业务决策都具有重要意义。同时，对IT层面监控的良好支持，对于业务流程系统的健康运行和良好的可维护性也十分重要。
（6）企业业务的不断扩展
企业的业务种类和业务量必然伴随着企业的发展而不断扩展，企业的业务流程管理平台也必须具备高度的可扩展性。例如，业务流程管理平台应该在不对当前业务产生影响的前提下很容易地通过添加节点的方式扩展容量和性能，支持企业的发展规模。
3. 缺少企业组织架构的支持
企业要认识到业务流程管理平台将来会作为企业层面的业务运行和管理的平台全方位地整合企业资源，因此，需要企业自顶向下的组织架构的支持。这主要包括以下几个方面。
（1）基于战略层面的指导和管控
基于企业的战略目标和业务价值链，对业务流程项目的立项、实施、运行给予指导和管控，确保业务流程项目符合企业规范及企业的战略方向。
（2）业务流程全生命周期的管控
建立企业范围内的业务流程生命周期标准，保证业务流程的发现、分析、开发、部署、更新、运行、归档等环节是可控制、可管理的。
（3）最佳实践的管理和维护
在企业层面建立业务流程项目的最佳实践以及经验教训的管理和维护机制，使业务流程项目的经验不断积累、不断成熟，同时也为战略层面和业务流程生命周期的管控提供依据。
（4）企业级业务模型的描述
在企业层面定义业务模型（包括业务流程、业务对象等）的描述标准和描述工具。
（5）业务层面和IT层面的协调
业务模型最终要在IT层面实现、运行和维护。在企业架构层面应预先定义好业务层面、IT层面的责任及其协调机制，实现业务与IT的无缝对接。
（6）共享平台的支撑和管理
企业架构层面应预先做好共享平台的选型、搭建和管理工作，建立企业层面统一的业务流程资产库和共享平台。
6.2.3 企业价值链分析
企业在进行业务流程管理的初期经常在业务流程的发现和选择、优先级安排、关键业务指标定义、监控数据选择等环节感到迷茫，不知如何下手。实际上，业务流程管理是为企业的价值增值和战略目标服务的，进行充分的企业价值链分析无疑会给业务流程管理项目的进行指明方向。
“价值链”概念是波特（Michael E.Porter）于1985年在其著作《竞争优势》中提出的。波特认为：“每一个企业都是在设计、生产、销售、发送和辅助其产品的过程中进行种种活动的集合体。所有这些活动可以用一个价值链来表明。”企业的价值创造是通过一系列活动构成的，如下图所示，这些活动可分为主体活动和支撑活动两类。
主体活动包括原材料采购、运营、交付、市场、售后等。支撑活动包括基础设施建设、人力资源管理、技术开发以及其他采购等。价值链分析有助于明确企业所从事的种种活动及其相互关系。
价值链分析并不意味着业务流程管理项目只关注于主体活动，而是要以是否能给企业带来价值增值、是否和企业的总体战略目标相一致为依据。例如，企业的招聘流程虽然属于企业的支撑流程，但是如果能够实现招聘流程的自动管理，能够监控它的关键业务指标，并实现招聘流程的不断优化，就可以提高企业的运行效率，降低招聘成本，增强企业的市场竞争力，这样的投资回报（ROI）无疑是合适的，这样的流程理应成为候选者。面对众多的流程候选者，需要对它们进行评估和优先级排序，高优先级的业务流程项目应该首先被考虑。下面简要介绍一下业务流程发现和评估的一般方法。
如下图所示，业务流程的发现和评估一定位于整个业务流程生命周期的最前端，一般包括流程识别、流程评估、流程发现和流程分析几个阶段，这个过程应伴随着知识发掘和文档记录，保证整个过程是经过认真思考讨论和有据可查的。这里特别强调的是，在业务流程发现和评估的各个阶段要摒弃传统的从IT角度考虑问题的思维方式，而应从业务价值的角度出发来考察业务流程的必要性、合理性、可行性以及价值的重要性等。
1. 流程识别阶段
流程识别阶段的主要任务是发现潜在的业务流程需求，需要工具和存储库的帮助来记录和管理所有识别的业务流程。例如，可以利用集团已经上线的业务流程平台来担当这一功能。在这一阶段，要召开简短（不到一小时）的座谈会，与会者包括可能的流程利害关系人、可能的流程参与者或是相应业务领域的专家（Subject Matter Experti，SME），为每一个识别的业务流程记录以下信息。
● 业务流程的责任人。
● 三到五句话的简短描述。
● 业务价值。
● 复杂性评估（流程规模、涉及部门、实现难度等）。
● 风险评估。
● 痛苦点。
2. 流程评估阶段
流程评估阶段的主要任务是从众多的业务流程候选者中排出优先级，决定优先实现哪些业务流程。在这一阶段有必要安排为期2～3天的流程提升与发现专题研讨会，用以对识别的流程进行进一步的理解和评估。研讨会包括如下主要内容。
● 识别业务价值：与会的业务专家和流程责任人要对业务流程在企业价值链中所起的作用以及对企业战略目标的贡献达成共识。
● 业务流程理解：与会的业务人员和技术人员应当对业务流程的定义、业务影响、关键业务指标以及业务流程的规模、边界、复杂度等关键问题达成一致。
● 业务流程评估：主要完成业务流程和企业价值链的映射，通过评审关键业务指标KPI和SLA来确定业务流程对企业价值链和企业战略目标的贡献，从而形成确定优先级的理由。
● 定义流程：参与者共同定义业务流程项目的解决方案。
● 流程的初步分析：针对以上阶段发现的流程，初步分析它的有效性和合理性，记录下是否有进一步提升和优化的可能。
3. 流程发现阶段
在流程发现阶段，业务流程的所有参与者和利害相关者应该共同讨论确定业务流程项目的里程碑、所包含的活动、流程路径、是否采用已有的流传模式等，并确定KPI和SLA。这一阶段确定的KPI和SLA应该真正帮助业务人员做出决策，实现企业价值链的增值，并最终有助于企业战略目标的实现。可以参照下图追溯KPI或SLA是否有效。前一阶段识别的一些KPI和SLA也许看上去很必要，但实际上并不一定能给业务人员的决策提供支持，这时应该将它们剔除。
4. 流程分析阶段
流程分析阶给所有业务流程相关的业务人员和技术人员一个机会来全面审视这个流程，包括以下方面。
● 流程是否全面、精确地反应了业务需求？
● 流程模型的定义是否清晰，容易被各方理解？
● 流程关键环节的文档是否清晰易懂？
● 流程的KPI和SLA的定义是否完整和必要？
● 流程中各个活动的粒度是否合适？
实现这一阶段的最好办法就是业务流程责任人现场演示流程，边演示，边理解，边讨论，边修正。这是一个迭代的过程，目的是为业务流程项目的成功实现输出正确、成熟的模型。
6.2.4 成功实施第一个业务流程项目
第一个业务流程项目的成功对企业今后的业务流程管理之路十分重要。它的成功会给企业的管理团队、业务团队、IT团队以信心和经验。业务流程的选择是业务流程项目的成功关键因素。第一个业务流程项目应该首先考虑选择在本企业里面已经比较运行成熟、达成共识、易于梳理、复杂度小的流程来实施。
1. 明确业务流程责任人（Owner）
业务流程项目和传统的IT项目相比较，一个本质的不同是，传统的IT项目关注于开发的产品或交付的服务是否满足需求、质量是否可靠，而业务流程项目的成功与否则最终会落在是否给企业带来了业务价值的增值。因此，业务流程项目的成功是否要通过业务流程在企业的业务部门运转才能检验，而不仅体现在业务流程项目的实现过程。业务流程经常横跨企业的多个部门，从识别开始到流程的发现、评估、分析、建模、实现以及部署运行的各个阶段，都需要所涉及的业务部门、IT部门的参与和协调。一开始就明确某个业务流程的责任人，自始至终负责这个业务流程的创建、运行、维护、优化等，对于业务流程项目的成功、业务价值的保证十分重要。把业务流程责任人的主要职责简要列举如下。
● 端到端地负责业务流程的定义、实施和运转。
● 是该业务流程相关的所有工作的负责人和协调人，拥有该业务流程相关事项的决策权和执行权。
● 负责不断对该业务流程进行改进和优化，确保它在业务运行中能正确反映并不断提升关键业务指标，为企业的整体业务目标和战略目标做出贡献。
2. 第一个业务流程项目应避免的误区
企业进行第一个业务流程项目的过程，实际上是一个总结最佳实践和经验教训、探索建立适合自己的业务流程项目模式和运作机制的过程。下面总结了一些企业在实施第一个业务流程项目时经常陷入的误区和可能的解决办法。
● 错误的项目范围（Scope）导致需求不清，业务流程无法正确表达，项目复杂性无限放大，致使项目无法完成。解决方法是进行严格的项目管理，同时先开展流程梳理，对要实现的业务流程进行清晰的描述。
● 业务流程不会产生有效的投资回报ROI。这样的业务流程项目不会得到企业的认可和后续支持。解决方法是在业务流程项目的早期阶段（如流程识别、流程发现阶段）就进行自顶向下的价值链分析并广泛达成共识，保证业务流程项目不会中途流产。
● 业务需求缺乏有效的沟通和表达。各部门、团队理解偏差，到最后无法集成到一起，甚至南辕北辙，需要返工。业务流程责任人要保证业务需求得到各方认可，特别是要选用形式化、标准化的业务流程建模语言来描述业务流程及其需要交互的资源。一致的业务模型和IT的实现模型，可以保证业务需求在业务人员和IT人员之间的无缝传递。
● 需求频繁变更，影响项目的及时交付。业务流程责任人有权冻结需求变更，保证项目的及时交付。
● 业务团队和IT团队是相互孤立的，IT实施的不是业务部门想要的。IT在业务流程实施的关键节点应该将业务流程的最新成果反馈给相关业务部门审核确认。最理想的方式是在项目协调会上现场运行业务流程（Playback），即使它不是最终的成品。
● 部门间缺乏有效协调，导致不同部门采用不一致的实施方略，最后难以在企业层面统一业务流程的实施策略。例如，某部门的流程无法被更高层面的业务流程作为子流程调用。这就需要在企业层面建立统一的管控机制，保证企业内部各业务的流程采用统一的策略。
6.2.5 实现从单个BPM项目到BPM流程平台的转变
企业从第一个BPM项目开始将逐步走向成熟，实现从BPM项目到BPM流程平台的转变，最终实现企业的BPM转型。
BPM项目是指单一的、孤立的BPM项目，它的业务流程往往局限于企业的某个部门内部，以实现单一的业务目标；而BPM流程平台则是多个BPM项目同时进行，它们之间相互关联、协同进展，经常是跨部门或产品线的，却服务于共同的业务价值或企业战略目标。
企业从BPM项目到BPM流程平台的转变是一个循序渐进的过程，需要持续的投入、时间和耐心。在企业成功实现第一个BPM项目并持续实施BPM的过程中，应该注重不断总结最佳实践和经验教训，特别是改变传统思维和业务流程管理项目以IT为主的思想，以企业业务价值链驱动BPM。当企业的BPM项目具备以下特点时，意味着企业的BPM开始了从BPM项目到BPM流程平台的转变。
1. 多个BPM项目同时进行
● 业务流程运行在共享的BPM平台上。
● 流程相关的知识储备在共享的存储库里。
● 共享的业务流程实施团队。
● 统一的业务流程词汇和语言。
● 统一的方法论指导流程的识别、评估、发现和分析。
● 统一的方法论指导流程的实现、部署和管理。
● 共享的业务流程最佳实践。
● 共享的企业业务价值链分析。
● BPM专业队伍的持续培养和不断壮大。
2. 共同的战略目标
企业要在BPM之路上真正进入BPM项目组阶段，具备大规模业务流程的交付能力，就必须在企业层面的机制和组织架构上予以保证，这需要建立企业层面的业务流程管控机制和BPM卓越中心（CoE）。下面将对业务流程管控机制和BPM CoE的基本框架进行讲述。
6.3 建立企业级流程管控（Governance）机制
企业成功实施了第一个业务流程项目，并不意味着企业能继续成功实施更多的业务流程项目，并实现基于业务流程的业务转型。随着企业业务流程的规模不断变大，企业往往面临着种种挑战。
● 如何管理多个部门或团队并行开发多个流程，并重用尚未开发完成的流程或服务？
● 大型企业经常有数以千记的业务流程分布于不同部门，它们可能采用不同的建模方式，又同时拥有数个版本。这种情况可能使得业务流程项目越来越难以进行，最终导致项目进度的失控。
● 流程资产不断增长，而又各自为政、不断更新。这种情况缺乏有效的管理，使得业务流程的可重用度降低，重复开发的可能性增高，最终导致流程资产的复杂度爆炸式增长，面临整体失控的危险。
在企业层面上建立对业务流程资产和业务流程项目的统一管控机制，是企业在业务流程管理之路上走向成熟的表现，企业会因此受益。
业务流程管控的基本概念是，企业的战略目标能够在业务流程层面得以成功实现的企业层面框架。同时，此框架确保企业的业务价值能够通过业务流程得以体现。
6.3.1 业务流程管控的基本框架
业务流程管控机制是业务流程持续改进以及业务层面和IT层面协作实现公司业务目标的保证。业务流程管控机制有必要定义一个基本框架，确保BPM的所有相关团队采用统一的方式和工具进行BPM的相关活动（如建模、实现、交付等）。
业务流程管控框架应该符合企业整体管控框架的定义。企业整体管控框架定义了公司层面的发展方向和指导原则。特别是，它对企业的资源使用做出了指导，定义了各种资源的责任人及其职责。业务管控框架的指导原则应该和企业整体管控框架的原则相一致。下图说明了业务流程管控框架的地位和作用。
从上图中可以看到，BPM管控框架在企业的管控体制中起到了承上启下的重要作用。它保证了企业管控原则在操作层面的实现，以及企业的战略方向和目标可以通过操作层面体现出来。同时，它也负责IT层面和SOA层面的交互。
IT管控是指企业IT层面的管理机制和规范，保证企业的战略方向在技术层面的有效支撑。SOA管控是指IT管控原则以SOA方法实现的原则和规范。
BPM管控框架具备以下要素。
● 定义BPM管控及与其他管控层面交互的总体原则。
● 建立各项活动的标准、规范、指导原则或基本框架。
● 定义所有相关角色及其责任、权利和沟通渠道。
● 定义管理业务流程生命周期的组织架构。
● 定义共享和重用业务流程相关信息的基本程序。
● 定义BPM项目的资助模型。
● 定义评估和测量业务流程业务价值的准则。
● 定义业务层面和IT层面的合作准则和沟通渠道。
6.3.2 业务流程管控机制的几个重要方面
企业在建立业务流程管控机制的过程中要特别注意以下几个重要方面。
1. 企业最高领导的直接支持
业务流程的管控机制是企业层面自顶向下推行业务流程的统一管理规则和理念，要求企业全体必须遵守。因此，企业最高领导的直接支持和参与是十分必要的，这有利于业务流程管控机制的快速推行和严格遵守。同时，有必要形成业务流程管控相关的企业文化，使业务流程在其生命周期的各个阶段遵守管控规范成为一种自觉。
2. 建立业务流程相关的指导规范
业务流程指导规范是指对业务流程生命周期各个阶段活动所需遵循基本规则的清晰表述，用以指导业务流程责任人和相关团队在实施、交付和运行业务流程项目的所有活动。企业应该结合自己的实际情况制订可行、清晰、有效的指导规范。下面给出了一些一般原则，企业可以尝试从这些原则入手。
● 在业务流程的初始阶段，企业的高层领导、相关业务团队、技术团队以及管控保证团队应该以集中的方式讨论、沟通和培训等，共同推进业务流程项目的进行。
● 业务流程项目应关注业务流程所带来的业务价值和用户体验，而不是流程的复杂度。
● 业务流程责任人是业务流程项目的核心角色，赋予其突出的权利和责任是业务流程项目成功的保证。
● 业务流程项目应致力于降低流程层面和IT层面的复杂性，如在系统集成点应尽量采用基于SOA的集成模式，而不是点对点的集成模式。
● 由BPM卓越中心（CoE）对业务流程项目中遇到的技术问题和IT平台问题进行指导，确保业务流程责任人和公司资助方的业务价值的实现。
● 业务架构师、应用架构师、IT架构师以及管理者应该不断向BPM CoE提供管控规范、最佳实践和经验教训，由BPM CoE汇总整理，形成管控规范，予以发布。
● BPM CoE应制订具体的管控规则，如业务流程责任人以及开发团队在业务流程需要变更时必须遵循管控流程，保证一切重要操作都是可控和可追踪的。
6.3.3 BPM管控机制的操作模型
下图给出了BPM管控机制的操作参考模型，用于指导企业建立业务流程管控机制。
BPM执行指导委员会是企业层面BPM项目的最高领导和决策机构，负责企业BPM项目的战略目标、总体规划、关键问题决策、资金支持等重要事宜。公司高层领导以及关键业务流程责任人应是该机构成员。
BPM项目评审委员会负责具体的业务流程项目的指导和决策工作。它对所负责业务流程项目的选项、进度、质量、业务度量体系以及技术力量的培养等负有领导责任。由于企业的业务流程项目可能来自不同领域，企业可有针对性地建立多个BPM项目评审委员会以专门负责某一领域的业务流程。
BPM设计团队在BPM CoE的指导下负责业务流程方案的设计工作，包括业务流程关键业务度量的选取和设计，保证业务流程的最终实现符合企业的总体价值目标；同时，还应注重业务流程及其相关元素符合标准并具备可重用性。
BPM解决方案团队在BPM CoE指导下负责具体BPM项目的实施和按期交付，确保所交付的业务流程项目符合业务流程责任人的要求，达到预期的业务价值目标。随着企业业务的发展，BPM解决方案团队还负责业务流程后续的更新和优化工作。
BPM SOA和平台团队负责构建和维护BPM项目依赖的SOA平台，提供BPM所需的数据、安全、服务集成等支持，还负责平台使用情况的监测，及时发现平台瓶颈，调优性能，保证BPM的正常运转；同时，随着业务的不断增加，做好平台的规划和扩展工作。
下图说明了BPM管控的操作模型如何应用于一个BPM项目。
● BPM管控团队的责任人（可以是主任业务架构师或BPM CoE成员）安排业务评审会，对第0次业务流程演示（Playback 0）进行评审。
● 业务流程责任人向业务架构团队讲解业务流程的业务价值、设计和业务测量指标。
● 获得BPM管控责任人的批准后，业务流程责任人继续业务流程的深度设计（Playback 1），并确定业务流程已经适合业务需要。
● 在第二次业务演示（Playback 2）完成后，BPM管控责任人应安排SOA相关的评审会议。
● 主任业务架构师和业务流程责任人应向SOA专家团讲解业务流程与业务集成方面的设计方案和业务价值，包括业务价值测量指标及业务价值用例。
● 得到批准后，业务流程责任人应该认为目前的业务流程和集成设计是适合业务需求的，并进入第三次业务演示（Playback 3）。随后，BPM解决方案团队准备部署业务流程。
● 在业务流程部署上线之后，业务流程的运转情况和业务价值度量将被持续监控并汇报给BPM CoE。
6.4 建立BPM卓越中心
6.4.1 为什么需要BPM卓越中心
已经知道BPM管控机制是一个企业由孤立的BPM项目向可扩展、可管理、可度量以及统一于企业战略目标和业务价值的BPM全面采用的关键。显然，这里需要一个实体组织，具体负责企业BPM相关的战略规划、行为规则、实施指导、项目监控、IT规划等事项，保证BPM管控机制在全企业的有效施行和不断改进。这样的企业层面的组织被称为“BPM 卓越中心”（CoE）。
6.4.2 BPM卓越中心的三个关键领域
企业的BPM卓越中心必须在以下三个关键领域履行职责，才能有效地保障BPM管控机制在企业范围的有效施行。这三个关键领域是相互关联而又相互独立的，它们可由BPM卓越中心不同团队或个人分别负责。当然，它们应该具有足够的权利、业务知识和经验。
● 战略（Strategy）：根据企业的战略目标和方向制订企业层面BPM的战略方向和长期规划。特别是，要基于企业价值链定义能度量BPM总体成功与否的KPI指标。该领域还负责全企业BPM的宣传，赢得企业上下对BPM策略的理解和支持，最大限度地形成基于BPM的管理思维，同时建立BPM资金模型，保证BPM项目的资金支持。
● 交付（Delivery）：建立高度可扩展的业务流程交付模型，包括资源配备、人员配备、BPM项目生命周期的管控，以及最佳实践的管理和维护等。该领域还负责BPM相关人才的培养和储备。
● 共享平台（Shared Infrastructure）：该领域负责规划、设计、构建、监控企业级流程管理共享平台，为企业的业务流程提供一个统一的建模、设计、实施、部署、运行和监控的平台。在IT层面保证业务与IT的统一，以及业务流程与业务价值的一致。
6.4.3 战略
可以将BPM CoE中的战略领域细分为以下几个责任。
1. BPM的总体战略方向、目标和规划，以及基于业务价值链的KPI定义BPM CoE 的战略领域应该首先给出应用BPM要解决的首要问题和战略方向的清晰表述，这将为BPM选项及业务价值的确定指明方向。以下给出了几个示例。
●减少客户的犹豫时间，从而从竞争对手那里赢得更多的市场份额。
●增强KPI的可视性，使业务决策者更容易地洞察问题和机会，增加对业务的敏感度。
●简化所有相关的管理流程，从而降低产品的销售成本。
●通过减少客户接触环节中的重复步骤（如重复的拜访电话）来提高客户的满意度。
BPM CoE战略领域提出的目标应该和战略方向相一致，而且是清晰的、可度量的，在合理的时间内可实现的。下面给出了几个战略目标的示例。
●减少价值链中因流程某些环节重复执行而消耗的75%成本。
●为每一个业务流程建立标准化的可视性关键业务指标。
●把获取用户联系方式的时间减少50%。
确定了战略方向和战略目标之后，BPM CoE的战略领域还有责任在业务和技术层面制订详细的指导规范、主要问题的决策意见、带有时间表的计划书，以指导BPM项目的各个方面，确保战略方向，使战略目标可以达到。下面给出了几个示例。
●技术层面的相关指导：
对于所有BPM解决方案中的系统集成需求必须通过ESB。
所有BPM解决方案不得直接访问业务数据库。
所有BPM解决方案只能使用企业唯一的LDAP作为注册用户来源。
●业务层面的相关指导：
所有的BPM解决方案必须提供KPI。
对于所有的BPM解决方案，业务人员都应该拥有不同级别的修改权限，并且所有的修改都应该是受控的和可审计的。
●有关技术决策的指导：
对于BPM解决方案中的附件，应该使用IBM FileNet进行管理。
对于BPM解决方案中有关规则的实现，应该使用IBM ODM。
禁止再使用以前遗留的工作流系统实现业务流程。
●有关业务决策的指导:
和客户直接相关的BPM项目应有更高的优先级。
和前三名供应商相关的业务流程的优化应优先进行。
关键的技术事件时间表。
关键的业务事件时间表。
BPM CoE的战略领域应该定义KPI用以量化评估BPM项目的总体表现。下面列出了KPI的示例。
●每年交付的BPM项目数量。
●每个业务流程节点的开发成本。
●每个业务流程的ROI和时间成本。
●由于重用业务流程资产而带来的成本（资金和时间）的节省。
●每个业务流程的运行健康状况评分（是否由于系统故障引起过业务中断等）。
●每个BPM项目的业务部门（非IT）投入。
这些指标都会给BPM CoE中的战略团队以重要反馈，帮助他们不断改进战略领域的决策和指导规范。
2. 激发和培养企业的BPM意识，增加企业对BPM的拥护度
只有在企业范围内形成BPM企业文化，企业上下都具有BPM的基本概念和基本意识，才能形成企业全体对BPM的真正拥护，用BPM思维去解决业务问题，这样企业的BPM转型也就是顺理成章的事情了。因此，BPM CoE的战略团队要把激发和培养企业的BPM意识作为一项重要和长期的工作。企业对BPM接受的成熟度也可以用相关的KPI来度量。下面是有关KPI的示例。
●业务流程发现过程中的贡献者数量：贡献者越多，说明BPM的参与者越多。
●业务流程场景演示的参加者：参加者越多，说明对BPM的认可者越多。
●每个业务流程或单位时间内的业务流程场景演示数量：数量越多，说明重视的程度越高。
●单位时间内业务流程的上线数量：单位时间内的数量增多，说明BPM在企业内的采用在加速。
●业务流程存储库中的业务流程数量：数量越多，说明流程资产越多，可重用性就越高。
3. BPM资金模型
BPM项目的进行需要资金的持续投入，包括人员培养、软硬件资产、运行维护等。企业早期的BPM项目可能由项目发起部门或主要受益部门提供资金，但是随着BPM在企业范围内的采用，如BPM项目可能会重用BPM CoE提供的流程资产，会使用BPM CoE提供的业务流程共享平台，或是使用BPM CoE提供的BPM顾问或技术专家等，这些已经改变了最初的BPM项目资金模式，有必要建立新的企业层面的BPM资金模型，保证BPM项目资金的有效使用。下图描述了企业层面BPM资金模型的主要思想。
由企业出面（CIO）向BPM CoE提供资金用于进行人员培养、共享平台建设、运行维护等。同时，企业的各部门作为业务流程项目的受益人，根据BPM项目从BPM CoE的受益程度向BPM CoE缴纳费用，用为BPM CoE的资金。这种资金模型是企业采用BPM的成熟体现。 BPM CoE的战略团队应该根据企业的自身情况制订BPM资金模型的具体细则。
4. 与企业价值链一致的业务流程资产管理
BPM CoE战略团队有责任识别和分析与企业价值链最相关的业务流程，它们和企业的战略方向和战略目标直接相关，或对关键业务指标有很大影响。BPM CoE应定义基本的规范和指导原则，将它们分类管理和存储，并驱动这些流程的进一步实现和优化。
5. BPM CoE 战略领域的组织架构
定义清晰的BPM CoE战略领域的组织架构，对于BPM CoE战略团队履行职责十分重要。这里给出了BPM CoE战略领域的核心角色及其职责。
●主管总经理：BPM CoE的最高领导和BPM资助者，负责公司层面对BPM CoE的资金支持，领导BPM CoE的发展方向，建立和改进BPM资金模型，监控BPM CoE的运行。
●业务架构师：企业的高级业务专家或业务流程分析师，构建企业的业务价值链模型，负责企业流程资产库的建立和监控，负责企业重要业务流程的识别和分析，构建和维护企业业务流程路线图，定义业务流程的优先级，建立和监控业务流程的分析标准，建立和监控业务流程的度量标准。
●BPM 技术架构师：与BPM技术相关的最高领导，规划BPM系统的架构和容量，建立企业层面的业务流程管理平台，构建BPM平台的使用规范，监控BPM平台的使用情况，指导和监控业务流程组件重用的流程和规则，对BPM平台的性能指标和容量提出指导意见。
●BPM 战略经理：这是一个BPM CoE战略团队的全职角色，负责BPM CoE所有战略事务的管理和协调，是BPM CoE团队的项目经理，这个角色定义BPM CoE战略团队事项的优先级，计划和安排人才培养需求，建立和监控所有BPM CoE战略事项的交付标准，跟踪和监控BPM CoE项目的执行情况。
下图给出了BPM CoE战略团队组织架构的参考模型。
6.4.4 交付（Delivery）
基于BPM CoE战略领域制订的战略方向、目标、基本原则和模型，BPM CoE的交付领域负责BPM项目实施和运行相关的事务。交付领域负责的事项简要列举如下。
●制订和维护BPM 项目实施过程中的资源以及人员的配备模型和规则。
●制订和维护BPM项目实施、交付和运行相关的方法论、最佳实践、规范准则，并负责BPM项目关键点的评审工作。
●针对BPM项目生命周期各阶段中遇到的流程和技术问题负责指导、解答和仲裁。
●制订BPM相关的人才招募和培养计划。
1. BPM CoE 交付领域的评估
和其他领域一样，需要定义具体的度量指标来评估BPM CoE团队的有效性和价值。下面列举了一些具体的度量指标以供参考。
●BPM接受程度的评估：业务流程的部署数量，业务流程的版本数量，BPM问题域内的业务流程总量。
●BPM解决方案的交付情况评估：按时交付的比率，预算内交付的比率，缺陷比例，解决缺陷所用的平均时间。
●BPM重用度评估：业务流程的重用率，服务组件的重用率
企业可以根据自身的实际情况选择合适的度量指标，对BPM CoE交付团队的效率和价值给出量化的评估。
2. 建立可扩展的人员和资源配置模型
根据BPM在企业应用的成熟度，建立可扩展的人员和资源配置模型，是BPM CoE交付领域的重要职责。
BPM CoE应在企业层面建立集中式的人员和资源配置模型，实际上是一个资源池。各BPM项目应向BPM CoE交付中心申请需要的人员和资源并支付费用，待BPM项目结束后予以释放，BPM CoE交付中心应对BPM项目的成功负责。BPM CoE所定义的资源池中的资源可以同时参与多个BPM项目，以提高资源池中资源的利用率。资源池中资源的高利用率是BPM高成熟度的体现，也是BPM CoE的价值体现。BPM CoE所设立的资源池应该定义和BPM 交付方法论相一致的角色。下面列举了其中的典型角色以供参考。
●BPM项目经理：该角色应该掌握BPM项目各阶段的方法论，提供BPM项目的指导，并承担传统项目经理的角色。
●BPM业务分析师：该角色将在BPM项目早期的流程发现、分析和建模等环节中起关键作用。他将驱动和协调业务流程责任人、不同领域的业务专家及业务流程的参与者对业务流程的需求和模型达成一致，确保业务价值在业务流程中的体现。指导业务流程的参与者完成首次业务流程场景（Playback 0）的演示，为业务流程的实现打下基础，并对业务流程的优化提出意见。
●BPM开发者：该角色具有BPM解决方案实现方面的技术和经验，同时也是BPM平台的专家，能够依据业务需求和模型，通过BPM平台提供的各种工具，应用BPM CoE确定的BPM方法论以实现BPM解决方案，并将BPM解决方案交付运行。
●BPM集成开发者：该角色关注于BPM平台自带工具无法解决的技术问题，如开发定制的集成连接器等。由于BPM平台自带的工具无法解决所有问题，BPM解决方案经常不可避免地进行定制开发，这就需要BPM集成开发者这样具有很强技术背景的开发人员，进而也成为业务流程中的一部分。和BPM开发者不同，BPM集成开发者更偏向于代码级的开发，然后形成业务流程的一个节点或服务；而BPM开发者更侧重于用BPM平台自身的工具实现BPM解决方案的基本框架。
●其他相关角色：除了以上角色之外，BPM项目的成功还需要其他角色的共同协作。但是这些角色并不与具体的BPM项目直接相关，因此不能归属于BPM CoE交付领域的资源池，而仍然属于传统的IT部门或业务部门。下面列举了这样一些角色，如BPM平台系统管理员、数据库管理员、企业架构师、第三方系统的架构师和开发者、业务流程使用者（业务用户）、相关领域专家、业务流程责任人。
下图给出了BPM解决方案交付团队各种角色的关系。
3. 建立和维护BPM交付方法论
BPM CoE交付领域的一个重要责任是建立和维护适合企业自身的BPM交付方法论，并保证方法论在BPM各阶段的正确执行。这主要包括以下几个方面。
建立BPM项目生命周期模型：BPM项目生命周期模型应该是一个端到端的、典型BPM解决方案的完整的生命周期模型，包括项目资助→流程发现→流程实现与部署→流程运行支持等所有阶段，为BPM项目的进行提供了指导。
●建立最佳实践和基本规范指导：BPM CoE交付领域要基于BPM项目生命周期模型建立生命周期各阶段对应的最佳实践和基本规范，指导BPM项目的具体实施。下面列举了一些具体例子，如主导业务流程场景演示（playback）的责任人、业务流程内部的变量的命名规范（如必须以小写开头）、尽量避免同一泳道中有多个相邻的活动。
●建立设计模式库：BPM CoE交付领域应该不断抽取业务流程的设计模式，形成共享的设计模式库，供BPM在设计和实现时进行借鉴。特别是对于某些模式，应该强制要求BPM必须遵守。例如，BPM CoE可根据企业的统一要求，定义标准的会签流程模式，并要求所有业务流程在遇到相同需求时必须应用该模式。
●建立共享工具库：BPM CoE交付领域除了定义设计模式外，还可提供共享的工具库，将已经实现的单一功能作为工具资产通过工具库予以共享，如SAP集成服务、用户查询工具、地图搜索用户控件等。这样BPM项目就可以依赖和重用这些工具，既提高了效率，又实现了功能的统一，同时便于BPM CoE对重要功能实现的统一管理。
●项目评审：尽管BPM CoE建立了丰富的规范标准、最佳实践、设计模式和共享工具库，为了保证它们能够真正在BPM项目中得到执行，BPM CoE的交付团队有责任在BPM项目生命周期的重要环节设立评审点，评审BPM项目是否遵守了规范标准，是否应用了最佳实践和规定的设计模式等。BPM CoE交付团队可以设立BPM项目交付质量的评估框架，为每一个评审点定义详细的评审检查表，逐项检查BPM项目是否符合要求。
4. 对业务流程的持续支持
BPM CoE交付领域还应设立专门的支持团队，他们的主要职责是分析和解决业务流程在运行过程中的各种问题，如有必要，协调和驱动开发人员、IT部门或相关业务部门予以解决。
5. BPM人才的招募、培养和评估
BPM CoE交付领域应根据BPM资源池所定义的角色和BPM在企业内部的采用情况，制订人才招募计划和招募标准，并负责人才培养和业绩评估。
6. BPM CoE交付团队的组织架构
下图给出了BPM CoE交付团队的核心组织架构参考模型。
●交付领域资助人：代表企业监控BPM CoE交付团体的运行情况，确保符合企业的整体战略和价值。
●BPM CoE交付经理：具体负责BPM CoE的主要事宜，包括维护和管控BPM候选项目，维护和管控BPM项目的人员和资源配置，维护和管控BPM人员的招募和培养，监控所有BPM项目的进展情况以及制订和监控BPM CoE交付领域的绩效评估。
●BPM项目管理资深经理：负责BPM项目方法论的制订和实施，并制订和监控确保BPM项目质量的流程和标准。该角色还负有BPM项目经理团队的领导责任。
●BPM业务分析资深经理：负责业务流程的需求发现、流程分析和相关方法论的制订。他对BPM CoE交付领域中的业务分析师团队负有领导责任。
●BPM解决方案开发资深经理：负责BPM解决方案的实现以及BPM实现相关方法论的制订和驱动，还负责BPM实现中设计模式的抽取、最佳实践的归纳等。他对BPM CoE交付领域中的BPM开发者团队负有领导责任。
●BPM技术开发资深经理：负责BPM解决方案中的技术实现部分，特别是BPM平台工具无法解决的实现，同时负责创建和维护BPM集成实现过程中的方法论、规范标准和最佳实践，还负责共享工具库的创建和维护。他是BPM CoE交付领域BPM集成开发者团队的领导。
下图给出了BPM CoE交付团队的核心组织架构参考模型。
6.4.5 共享平台
企业的第一个BPM项目往往开始于某个部门的非核心流程，BPM运行平台也往往限于该部门所有或是归属于IT部门。随着BPM越来越广泛地被企业所采用，越来越多的跨部门核心业务也会被逐步纳入BPM范畴。这时企业会发现，原来的BPM系统已经不能满足需要，无论在用户容量、业务流程数量，还是安全、性能等方面都已经捉襟见肘。更为重要的是，随着BPM业务的增多，如果BPM运行平台缺乏有效管理，将会面临失控的危险。企业层面跨部门的业务流程需要高度统一的业务流程平台管理。同时，由于BPM平台的不断扩容、升级甚至整体迁移，也会带来业务流程和业务数据迁移的巨大工作量和风险。因此，随着BPM在企业应用成熟度的提高，必须将BPM平台的规划、建设和管理等工作提升到企业层面进行统一管理，为全企业的业务流程提供服务。BPM平台和业务流程项目生命周期的各个阶段是密不可分的，它直接关系到业务流程项目的成败以及企业的业务价值和战略目标，自然而然地成为BPM CoE中的一个重要领域。具体来说，BPM CoE 共享平台领域主要关注于BPM共享平台的以下各方面。
●可用性 （Availability）。
●性能（Performance）。
●可扩展性（Scalability）。
●安全性 （Security）。
●业务流程应用的管控能力（Governance）。
针对以上各方面，BPM CoE共享平台领域必须做好规划、建设、维护、改进工作，保证BPM共享平台能持续支持企业的BPM需求。尽管IT层面的软硬件执行工作可能由IT等部门具体执行，但是BPM CoE共享平台领域必须提供规划、指导、度量指标和测试评审。
BPM CoE共享平台领域应该从产品选型、IT基础设施、共享平台的拓扑结构、数据存储配置、高可用性配置、灾备考虑、IT层面安全访问控制、业务层面访问控制，以及近期容量、远期容量、用户并发访问数量、用户规模和增长速度等方面综合考虑。
1. BPM CoE共享平台领域的评价指标
下面列举了对于BPM CoE共享平台领域进行量化评价的指标。
●BPM解决方案的持续正常运行时间（Availability）。
●BPM对用户的响应速度。
●部署新BPM应用所需时间和人力。
●BPM共享平台扩容的频率、时间和人力。
●BPM共享平台的安全性问题发生次数。
2. BPM CoE共享平台领域的组织架构
下图给出了BPM CoE领域组织架构的参考模型。
●共享平台总监：代表企业监控BPM CoE 共享平台领域的运行情况。
●IT架构师：负责共享平台的IT层面，确保共享平台符合企业的IT标准和规范，满足企业共享平台的安全要求和灾难恢复要求，审核共享平台的IT拓扑，为业务流程应用中的系统集成需求提供解决方案（如通过SOA/ESB平台等）。
●BPM平台架构师：是BPM共享平台关键问题的决策者，该角色应该同时属于BPM CoE的战略领域。他主要负责BPM共享平台规划与演进中的关键问题，如容量与性能指标的设定、可扩展性的考虑、平台架构的决策、和IT架构师合作解决与企业IT系统集成的问题，负责BPM平台安全标准的制订以及日志、错误恢复标准的制订等。
●BPM平台支持经理：是BPM平台支持团队的负责人，具体负责BPM平台的支持和维护工作，如监控系统运行的健康情况、与业务流程应用开发和支持团队共同解决问题、总结BPM平台运行维护的最佳实践等。BPM平台支持团队可以包括BPM平台管理员、网络管理员、数据库管理员、BPM应用支持工程师等。
上面内容主要来自于IBM中国开发中心BPM团队编著的《IBM BPM实战指南》。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
