理论

BPM不是一个IT术语，更不是因技术的发展而起源的，相反，BPM自始至终都是管理学的术语和概念。它关注的一直都是效率、成本、利润、质量等核心问题。
BPM是一门学科和一种方法论，只是现代的企业管理已经越来越离不开IT技术手段，而BPM软件产品是一种构造工具，一种令人异常兴奋的工具，可以提供更快、更好、更便宜的解决方案。它将IT会话转变成业务语言，以解决IT长期存在的问题——业务与IT之间的沟通障碍，帮助企业改进效率，使得流程可视化、敏捷化，并帮助企业进行业务变革。

BPM相关标准

• BPEL（Business Process Execution Language）：以SOA为基础，针对SOA进行编排，其本身也是一个SOA，可以被更高层的业务流程当成活动编排进业务流程里。
  • 优点： 基于SOA，所以具备集成强大的跨部门、跨平台的异构系统的能力。
  • 缺点： 过于接近编程语言而非业务语言，并且缺少面向人工任务的定义。
• XPDL（XML Process Definition Language）：这是一个与开发者相关但与实现无关的流程过程描述规范和交换接口。
  • 优点：在业务流程完整性方面，比BPEL好。
  • 缺点：主要面向IT人员，缺乏对SOA的支持，集成能力比较差
• BPMN（Business Process Modeling Notation）：定义了一个业务流程图，该业务流程图基于一个流程图，而流程图被设计用于创建业务流程操作的图形化模型。它的主要目标是提供一些被所有业务用户容易理解的符号，从创建流程轮廓的业务分析到这些流程的实现，直到最终用户的管理监控。
  • 优点： 最接近业务语言。
  • 缺点： 不支持SOA，集成能力差。

BPMN适用于业务层面，BPEL适用于IT层面，XPDL则介于两者之间。目前最佳的解决方案是BPMN + BPEL。
IBM BPM 在7.5 中集成了面向业务人员的WebSphere Lombardi 和面向IT人员的WebSphere Process Server，包括了基于BPMN的流程设计器Process Designer和基于BPEL的Integration Designer。

BPM的生命周期

• 广义生命周期

广义的生命周期是从业务管理的角度进行说明，它几乎覆盖了企业战略管理、战略流程定义、业务构建、业务流程定义、业务服务定义和编排、业务执行和监控、业务流程优化改进以及战略调整等企业管理的方方面面。

• 狭义生命周期

狭义生命周期是从IT实现的角度进行说明，它指的是可执行业务流程在BPMS系统中从设计建模到部署执行、监控和改进的过程。

BPM的未来趋势

• 敏捷化
• 智慧化
• 社区化
• 移动化
• 虚拟化

IBM BPM产品架构

BPM产品设计的核心问题： 它必须横跨业务和IT两个部分，能够很好的支持业务用户采用业务语言来建设业务流程，同时它又必须能够支持IT人员使用IT语言来整合IT资产以实现业务流程。这要求BPM产品必须同时具备业务设计能力和IT设计能力，并且能够将这两种模型统一为一个完整的模型。

BPM可以集成这种系统，这要求BPM必须具备很强的扩展能力，能够容纳、扩展、整合各种企业应用，以BPM为核心形成的应用生态圈不仅仅是孤立的业务问题和流程问题。

IBM BPM产品由以下几部分构成：

• Process Center
• Process Server
• Process Designer
• Integration Designer

IBM BPM 项目开发方法论

BPM主要是由业务驱动的，这决定了流程开发是”粗粒度“的，所谓”粗粒度“是指BPM通过业务人员可以理解的业务部周的概念来描述业务的主要活动，屏蔽了业务部门不关心的技术细节。
流程开发是一个”粗粒度“的组合式开发过程，也是一个不断迭代、不断改进的过程。

BPM”粗粒度“开发的基本原则

• 用标准的、图形化的、可定制的流程产品开发工具开发流程和表单，尽量避免使用代码。
• 把需要用代码开发的部分尽量封装成可重用的组件。
• 先搭建流程平台，再做具体业务流程的开发。
• 把业务人员可以定制的业务规则外挂，成为通过业务人员定制就可以改变的业务组件。

BPM是一种管理理念，它不是要取代现有的系统，而是利用或者重用现有系统，达到管理企业各个层级的业务流程的目的。
从技术角度来看，人工工作流的实施有三个挑战：1）流程建模和流程环节之间的状态跳转；2）人工任务的人员分配；3）环节内的表单和表单业务逻辑。

BPM项目实施的顺序

• 人工工作流
• 协同流程
• 三级流程的监控流程
• 基于SOA的自动流程
• 二级流程以上的监控流程

流程平台的内容和开发原则

什么是”流程平台“？ 指搭建一个企业共享的功能模块平台，把流程开发中可以重用的模块和服务放在共享平台之上，让一个具体流程的开发变得简单。

人工工作流平台的开发内容

• 定义并建立流程平台和企业门户系统。业务系统之间的逻辑关系。
• 定义并建立流程平台对外提供的标准API接口。
• 建立流程平台常用的功能模块：流程的触发、挂起、恢复、终止。
• 建立流程监控的基本机制和监控页面
• 建立和服务总线的整合调用机制。
• 建立流程生命周期的管理。
• 满足流程平台的非功能指标
• 建刘流程部署的环境：开发、测试、生产。
• 建立流程平台的运维规范。

人工工作流程的开发原则

• 流程的路由环节和环节内的表单逻辑松耦合。
• 流程路由和环节的执行人的任务分配规则松耦合。
• 流程和后台服务松耦合。
• 流程数据和业务数据松耦合。

流程平台的对外接口

• 创建并启动流程实例
• 终止流程
• 删除流程实例
• 休眠流程实例
• 激活流程实例
• 节点跳转
• 认领任务
• 提交任务
• 获取任务的参与者
• 查看任务项
• 转派
• 建模工具参与者设置
• 强制办结
• 流程文档操作
• 性能数据

具体流程的开发步骤和开发原则

开发步骤

• 定义流程的业务数据结构
• 定义用到并画流程图
• 指定环节的属性并指定环节的执行角色以及任务的分配规则
• 定义开发环节中涉及到的表单和表单背后的逻辑
• 给出流程监控的绩效指标
• 和业务人员一起对流程进行”回放”，改进流程设计

什么是”环节“？ 环节可以是一个简单的人工任务，也可以是一个已经在工具箱里面的子流程。常见的环节类型：1）人工环节；2） 人工会签环节；3）业务自定义环节；4）自动环节；5） 控制环节；6）决策环节。
什么是”流程回放“？ 指和业务人员一起，用流程工具提供的流程回放功能对建立的业务流程进行场景回放，期间，讨论流程人员开发的流程模板和业务人员的流程功能开发说明书是否一致，有没有需要改进的地方，同时也要检视流程末班描述的业务活动环节。
流程回放是保证流程健康性的一个必要步骤，是流程开发过程中必须定期执行的。

流程回放一般包括的内容：

• 流程开发的”粒度“是否为业务人员明白的业务内容，尽量屏蔽业务人员不懂的IT部分
• 流程的业务数据结构是否和业务需求一致
• 流程图的各个环节之间的路由规则和跳转规则
• 各个环节的执行角色以及任务分配规则
• 各个环节的表单展现和表单逻辑是否和业务需求一致
• 流程监控的绩效指标是否和业务需求一致

流程梳理和设计

什么是流程梳理？流程梳理是指围绕企业的内部要素和外部要素，对整个企业的业务特点和管理现状进行深入细致的分析和提炼，识别流程现状和管理的关键点，搭建企业的流程框架，对流程进行分类分级，帮助企业更好的进行管理转型和业务运营，并帮助管理人员优化组织架构及平衡资源配置等。
流程梳理的过程：首先通过收集、分析企业现有的流程文档和业务事件列表，了解企业的整体情况并初步梳理出流程的大体框架，然后通过业务访谈、Workshop讨论、问卷调查等方式，明确流程清单并对流程进行逐级分解和定义描述，最后根据流程梳理的结果，编写流程需求文档，清晰的定义和描述流程，并与用户做最终确认。
流程体系框架的构建是一个企业进行流程管理的起点，一个完整的业务体系包括组织、流程和系统，构建的原则是从宏观的业务级别到微观的活动级别，从易到难，从简到繁，完整的覆盖企业从业务到运营的全部内容和细节。

流程体系框架设计的步骤

• 明确企业的业务框架，确定企业有竞争优势的价值链
• 针对每个流程的模块领域，明确核心业务和支持业务，并设计有效的业务管理模型
• 针对各业务模块下的管理模型，列出整体的流程清单，并考虑各流程间的关系，从而形成该业务模块的流程体系框架

流程分级

• 价值链
• 流程链
• 流程
• 任务
• 步骤

流程梳理完成之后，需要明确定义流程，将流程的输入、输出、活动步骤以及相关人员等描述出来，回答为什么做、做什么、怎么做、谁来做等问题。
在这个阶段，我们需要输出流程图和流程文档。

常使用的流程图定义工具：

• Visio
• SmartDraw
• UML
• BPMN

流程文档需要包括的内容：

• 流程概述
• 流程参与岗位
• 输入输出
• 流程活动描述
• 关键控制点
• 流程KPI
• 参考资料
• 版本管理

流程梳理的一个重要目的，是要把分析出来的流程进行梳理、分类、合并，归并出企业通用的流程末班，以供后面业务人员在开发流程中使用。

BPM流程设计

业务流程设计使之根据市场需求与企业要求调整企业流程，包括设计、分析和优化流程。其中，设计阶段的目的是根据分析结果并结合企业目标制定目标流程，进而在IT系统中实施，有助于今后为企业创造有价值的目标流程。

如何转换业务需求

• 用例模型
  • 服务用例
  • 业务用例
• 记录业务场景和数据要求

什么是BPMN？全称是“业务流程建模标记/业务流程建模标注（Business Process Model and Notation）”， 是由对象管理组织（OMG）管理的一种公共的建模标准，它提供了流程交互、异常处理和语义补充等诸多功能，是被业界主流厂商广泛接受的建模标准。
BPMN主要由4部分组成：1）流对象；2）连接对象；3）泳道；4）器物。

在构造表单时，IBM BPM支持两种方式：

• 基于Coach的表单
• 基于外部页面的表单，这是通过URL的方式来实现的，因此极大丰富了该部分的扩展性。

在业务流程中经常会出现一些自动环节，或者在人工服务中调用某些特殊的接口，甚至是某些环节需要调用外部系统的某些内容，这就要求BPM系统提供丰富的接口支持，BPM支持的方式：

• 基于WebService的接入
• 基于Java的接入

KPI定义

KPI（关键绩效指标，Key Performance Indicator）是通过对企业组织内部的某一流程的输入端、输出端的关键参数进行设置、取样、计算、分析，来衡量流程绩效的一种目标式量化管理指标。

IBM BPM允许用户执行如下KPI相关操作：

• 查看KPI属性并修改所有者。
• 打开“警报管理器”，并未KPI创建警报。
• 打开KPI的历史记录和预测配置选项。
• 将KPI窗口小部件作为一个任务发送给其他仪表板用户。

流程门户

IBM BPM支持的流程门户类型：

• 默认流程门户
• 定制化的流程门户
• 外部实现的流程门户

流程梳理和建模的基本原则

• 要从工作的目标而非工作的过程出发，定制岗位职责。
• 剔除对内部客户和外部客户不增值的活动。
• 使决策点尽可能的靠近需要进行决策的地点。
• 尽可能的使同一个人完成一项完整的工作。
• 部门之间的沟通、决策和问题的解决应在直接参与作业的层面进行。

流程设计和开发的基本原则

• 基本功能组件化，可变功能脚本化。
• 流程模板分类和可定制化。
• 考虑流程体系的可迁移性。

BPM开发基础及进阶

这一部分占的篇幅最多，但看的最快，因为日常工作中一直在用IBM BPM为客户提供解决方案，不过这一部分是整本书中最接地气的内容，可操作性很强。其中有一些内容在工作中没有怎么用过，特此记录。

• 定义coach时，可以直接将变量拖拽到页面中，会自动根据变量中各属性，自动生成对应的控件。
• IBM BPM应用的两种部署方式：1） 在线部署（twx）；2） 离线部署（offline package)。
• 关于服务器端脚本，IBM BPM使用了Mozilla的JavaScript引擎Rhino来解释之星脚本，Rhino引擎是一个纯粹的java实现，它的工作室桥接两个不同的语言，在它的实现里既可以通过JavaScript直接调用Java方法，也可以在Java方法里面调用JavaScript。
• IBM的用户组分为：1）系统管理层面的、物理的组——安全组；2）应用层面的、逻辑的组——参与者组，或者Team。
• 关于Team，分为：1）静态的团队；2）动态的团队。动态团队使用的服务包括：1）Team Retrieval Service; 2）Team Filter Service。
• 调用Ajax服务的例子很不错，之前一直在使用REST的方式调用Ajax服务，也可以在脚本中直接调用。

常用的Coach使用模式

• 数据同步模式，coach中不同的部分绑定相同的变量。
• 异步数据更新模式，使用Ajax服务。
• 页面刷新模式，刷新整个页面，在Human Service内部实现。
• 页面模板模式，相当于母页。
• 重复试图模式
• 基于角色的动态显示，在为每个控件设置visibility属性，在脚本中为属性进行赋值。
• 标签页面模式，使用选项卡控件。
• 数据列表模式，使用表控件。
• 数据列表监听模式，1）在load事件中处理；2）使用Change Data Boundary Event。
• 选项数据更新模式，灵活使用绑定变量。

理解和运用UCA

UCA的全称是“隐蔽（事件）代理”，Undercover Agent， 它由事件启动，事件通常是由消息或者特定时间触发，从而启动UCA，当UCA启动时，它将调用与之绑定的特定BPM服务来回应该触发事件。因此，当希望在某类消息事件发生时自动触发某个BPM服务或流程，或者当希望某个BPM服务或流程作为某类定时发生的消息事件自动触发的结果而被调用，应该使用UCA。

平时项目中使用UCA的地方很少，有一些场景：在每个月的指定时间启动特定的BPD，一般都使用Unix的cron脚本来实现，通过url的方式来启动BPD。

流程门户定制

流程门户允许用户对以下场景进行定制化：

• 修改登录页面
• 定制导航栏
• 修改主题元素

目前还没有遇到定制门户的要求，因为在生产环境中，一个BPM服务器为多个客户同时提供服务，如果定制流程门户，就会影响所有用户。

使用REST API管理业务流程

这部分很熟悉了，在项目中大量使用了REST。

使用REST API时的注意事项：

• URL长度的限制，可以使用ＰＯＳＴ方式建立请求，同时设置Content-Type HTTP头信息为application/x-www-form-urlencoded。
• 创建HTTP方法重写通道
• 切换数据格式

IBM BPM与Web Service集成

这部分平时很少用到，以后有机会再详细学习。

一些可重用资产

• 会签、动态加减签
• 代理
• 自定义实现树结构

我理解应该会随书提供一些可重用的toolkit，但目前还没有发现。

BPM开发中的注意事项

流程应用程序和工具箱

• 流程应用程序和工具箱的依赖关系是静态绑定的。
• 版本控制针对的是流程应用，而不是流程应用中的单个文件。
• 当针对一个流程应用程序产生一个快照时，在该快照中流程应用程序所包含的的工具箱版本也同时被确定了。

业务流程定义

• 在一个业务流程定义中定义适量的业务活动。
  • 一般认为，主流程的业务活动不超过7个
• 避免定义书序的系统通道活动。
  • 在业务流程定义引擎执行过程中，过多的顺序执行的活动，特别是系统通道活动，会大大降低整个引擎处理事务的能力，并增大数据库端的负载。
• 避免定义多实例的系统通道活动
  • 因为这样会产生大量的令牌，而同一时间，只能移动一个令牌。
• 避免定义无限循环的业务流程图
  • 使用业务流程定义进行轮询操作，会消耗一定的服务器处理器资源。
  • 尽可能考虑使用别的通讯机制替代轮询，例如Java消息服务。
  • 如果轮询是必要的，则应该使用秘密代理程序，即UCA。
• 避免有深层嵌套的流程或者活动
• 了解计时器（Timer）和服务级别协议（Service Level Agreement， SLA）的区别
  • 服务级别协议的裸机只会在关联的活动的开始或者完成时才会被触发。
  • 我们可以通过计时器事件来发送通知，而是用服务级别协议跟踪和监控历史趋势。

服务开发环节注意事项

• 人工任务节点定义，尽量将同一个人操作的页面封装在同一个human service中。
• 避免保存上下文
• 变量
  • 变量的数量和大小
    • 当某个变量不再被需要时，将其置空。
    • 尽量减少在每个活动节点间传输的变量的数量及内容。
  • 区分流程数据和业务数据
    • 不要把整个业务应用数据都定义为流程变量，业务应用数据应该单独维护
• 界面设计和脚本
  • 避免在一个页面展示过多内容
  • 避免使用大段JavaScript
• 跟踪，对于不需要手机和跟踪KPI的业务流程，可以金庸自动跟踪功能。
• 异常处理
  • 避免全局异常处理
  • 业务异常和运行时异常
    • 业务异常是指已经在业务系统中定义好、有业务含义的异常。
    • 运行时异常是指IT层面的异常。
• 命名规范
  • 流程应用程序和工具箱明明规则
    • 名称控制在64个字符以内
    • 除了约定俗成的名称，尽量避免使用缩写
    • 在描述栏中填写详细的描述信息
    • 名称中不带版本信息
  • 快照命名规则
    • 提供快照日期戳
    • 描述该版本的变化、增强内容

运行时性能调优

• 事件管理器调优
  • 事件管理器的主要功能是为了保证代码可以按照计划执行
  • 任何事件管理器计划好的任务实际上是在一个流程服务器上具体执行的。
  • 使用事件管理器的场景： 1）UCA调用；2）处理业务流程定义（ＢＰＤ）的通知；3）执行业务流程定义的系统通道活动；4）执行业务流程定义的定时器事件。
• 同步队列
• 异步队列

业务运维注意事项

• 通过流程管理控制台进行监控
• 通过流程监视器搜索流程实例
• 通过流程监视器对失败的流程实例中的错误和故障进行故障诊断
• 在流程服务器上部署新版本快照时参与者组的映射关系
• 迁移现行数据，使用策略文件
• 定期清除
  • 定期清除流程实例
  • 数据备份归档
• 管理员干预
  • IBMBPM中包含事件管理器组件，它负责在业务流程定义引擎和服务引擎中移动令牌，事件管理器持续不断的处理一个循环事件，知道事件管理器被停止或者循环终止。

IT运维注意事项

• 如何保证系统的健壮性，保持对系统的跟踪和记录
• 环境备份
  • BPM的概要文件目录
  • 数据库
  • IBM Installation Manager
• 更新流程门户任务索引，使用taskIndexFullReIndex脚本

BPM的高可用性

从系统运行的角度来看，高可用性分为两类：1）进程高可用性；2）数据高可用性。
高可用的建设目标是通过消除单点故障来提供持续服务，主要手段是通过冗余组件和集群技术来消除单点故障。
系统的高可用性不是由最可靠的组件的高可用新计算出来的，相反，整个系统的高可用性取决于系统中高可用性最低的组件。也就是木桶理论。

BPM高可用性架构

• 前台有两台Web服务器，可以是Active-Active模式或者Active-Standby模式
• BPM层的高可用性是通过WebSphere内嵌的集群技术来实现集群成员的高可用性
• LDAP服务器层的高可用性是通过配置一个或者多个Standby的LDAP服务器，然后再WebSphere中定义这些服务器
• 数据库服务器的高可用性可以通过集群技术或者数据库自身的HA技术来解决
• 单个存储本身就已经做了大量的工作，例如使用RAID来保护数据

BPM的管控方法论

企业采用和试试业务流程管理是一个长期的、持续的、不断提升、不断成熟的过程。

企业应用BPM的能力可以分为5个级别：

• 初始级，探索和尝试
• 掌控级，最佳实践的应用和积累
• 标准化级，从BPM项目发展到BPM项目组
• 流程优化级，BPM在企业层面全面实施
• 业务转型级，基于业务流程的企业文化

企业采用业务流程管理是为了解决自己的管理问题和业务问题，提升自己的业务价值和管理效率，最终提高自己的市场竞争力并实现自己的战略目标。
企业在决定采用业务流程管理之前既要有近期目标，也要有远期规划，在初期应该采取“想大做小，快速扩展”的原则

企业采用BPM时遇到的问题

• 业务流程实施和管理能力的缺失
  • 却反对业务流程的正确认识
  • 缺乏对业务流程的敏锐洞察
  • 缺乏采用业务流程的长期规划
  • 缺乏对业务流程的快速交付能力
  • 缺乏对业务流程实施的资源与技术
• 企业层面业务流程平台的缺失
  • 企业层面的业务流程存储库
  • 与企业其他系统的集成能力
  • 企业级的标准化
  • 企业级的安全机制
  • 企业级的监控机制
  • 企业业务的不断扩展
• 缺少企业组织架构的支持
  • 基于战略层面的指导和监控
  • 业务流程全生命周期的管控
  • 最佳实践的管理和维护
  • 企业级业务模型的描述
  • 业务层面和IT层面的协调
  • 共享平台的支撑和管理

成功实施第一个业务流程项目

第一个业务流程项目应该首先考虑选择在本企业里面运行已经比较成熟、达成共识、易于梳理、复杂度小的流程来实施。

应该注意避免的误区：

• 错误的项目范围导致需求不清
• 业务流程不会产生有效的投资回报率（ROI）
• 业务需求缺乏有效的沟通和表达
• 需求频繁变更，影响项目的及时交付
• 业务团队和IT团队是相互孤立的，需要一起进行playback
• 部门间缺乏有效协调，导致不同部门采用不一致的实施方略

BPM流程管控机制

业务流程管控的基本概念是企业的战略目标能够在业务流程层面得以成功实现的企业层面框架，同时，该框架还确保企业的业务价值能够通过业务流程得以体现。

BPM管控框架具备的要素

• 定义BPM管控以及与其他管控层面交互的总体原则
• 建立各项活动的标准、规范、指导原则或基本框架
• 定义所有相关角色及其责任。全力和沟通渠道
• 定义管理业务流程生命周期的组织架构
• 定义共享和重用业务流程相关信息的基本程序
• 定义BPM项目的资助模型
• 定义评估和测量业务流程业务价值的准则
• 定义业务层面和IT层面合作准则和沟通渠道

BPM管控机制的操作模型

• BPM执行指导委员会，负责调整方向和资金
• BPM项目评审委员会，负责计划、排序和宣讲
• BPM设计团队，负责构建和复用
• BPM解决方案团队，负责交付流程解决方案
• BPMSOA和平台团队，负责构建和管理基础架构

BPM卓越中心

什么是“BPM卓越中心”？这是一个实体组织，具体负责企业BPM相关的战略规划、行为规则、实施指导、项目监控、IT规划等事项，保证BPM管控机制在全企业的有效施行和不断改进。

BPM卓越中心的三个关键领域

• 战略
• 交付
• 共享平台