BPM呼唤流程新理念

当企业计划通过业务流程管理（BPM）实现新的业务逻辑时，必须注意到一些传统的系统设计与配置方法并不适用于显性流程的实施。假如企业的方法论、团队人员不够灵活，或者对流程不够清楚，那么BPM将充分暴露出这种不适用。BPM要求企业采用全新的流程理念，下面的四个例子正说明了这一点。

BPM呼唤流程新理念：BPM改变了IT和用户之间的系统改进循环

开发团队总是从项目时间进度、资金预算、里程碑、最终用户接受度和移交系统等角度出发来考虑问题。当然，这是避免项目范围不断爬升、无限制持续的合理方法。但最终用户却是从功能需求升级、使用反馈、小组学习、系统强化等方面考虑的。这也是接受新的定制性业务功能的一个自然过程。平衡IT和用户需求是一个老生常谈的话题了，但假如项目所用的工具能够实现灵活性、快速更新、敏捷性等功能，是否能够更好的实现这种平衡呢？如果没能给BPM工具进行正确定位，那么它们可能造成开发人员和最终用户之间的冲突。对BPM工具进行正确定位的第一步，是要对员工进行BPM技能、技术、观点的培训。培训可以先从IT部门开始，然后逐渐扩展到使用BPM方法的各个项目团队。

假如IT部门交付给用户的是编译好的系统，那么用户基本上就无法做任何程序调整了，最多只能修改一下参数表。如果系统需要做较大的改进，那么IT部门只能重新编写程序源代码，开发一个新系统。新系统和原系统存在着明显的区别。假如是用BPM方法，那么用户能够更为自由的对系统做出调整。BPM实现了概念模型（即流程图）和物理实现（即运行“代码”）之间的紧密连接。这种模型到实现的连接能够让用户方便地修改模型——最终改变运营功能。最低限度来讲，诸如增加或删除步骤、增加新的决策点、修改角色等流程更改都可以在短时间内完成。这些新的能力要求IT部门和最终用户平衡各自在系统改进中的角色。假如用户不事先和IT部门沟通流程更改事宜，擅自更改逻辑模型，那么这种能力反而会成为一种带来混乱的因素。

BPM呼唤流程新理念：流程设计永无止境

由于企业经常需要灵活的改变流程，因此IT部门在系统开发过程中，不应过早的锁定某个流程，阻止流程的更改。这将是一种挑战。IT人员往往倾向于锁定一种流程设计，然后全力以赴的实现这种设计。这种想法也是十分自然的。某些流程变更可以归结为角色变更（可能是增加新的角色），这种变更可能引起报表和视图设计的变更，因为出现了对数据、决策和流程步骤的新需求。许多研究都证实了在软件开发后期引入的变更会造成很大的麻烦。但BPM不同于传统的瀑布设计，适用于COBOL和C的规则并不适用于流程设计。另外一些研究表明，流程知识来源于循环改进。第一次实施的流程并不是最好的终期版本。

当创建一个流程时，需要对其进行测试、体验（例如初步的用户接受测试）和修改。BPM工具能够较好的支持流程调试，提供技术性方法实现动态修改。IT、用户和业务分析员必须牢记，一个流程在其整个生命周期中都是可以修改的。如果在开发过程中过早的锁定流程，必然会引起用户的不满意。当然，毫无限制的进行流程修改也不是明智之举，但必须保证某些流程因素能够在其生命周期中能够被修改：工作流变更、新角色，新决策规则。为了达到灵活性和严谨性之间的平衡，可以采用业务规则引擎（Business Rules Engine，BRE）。将BRE运用到工作流决策上。如果将业务规则设置为显性可调整，那么用户能自行实现多种流程变更。尽管如此，流程设计还是有可能引起IT部门和用户之间的冲突。

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部门和最终用户对角色、职责和能力的共识。