业务规则管理（Business Rules Management，简称BRM）

企业的业务规则对绝大多数人来说都非常抽象，就算是企业的决策者也说不清自己的企业内部到底有多少业务规
则在使用。如何让企业规则与企业的数据信息一样成为企业的重要资产？

业务规则管理“复苏”

规则和逻辑是人工智能理论中最基本的概念。比如机器人在遇到前方障碍物的时候，系统就会自动触发某种应对
规则，告诉机器人绕开障碍物继续向前。通过规则的逻辑运算，还可以赋予机器人简单的推理能力。当这些规则和逻
辑在一个机器人中出现的时候，我们似乎习以为常。但如果把规则用于商业应用系统又会产生什么样的效果？
其实，在一个企业实体中同样存在着各种各样的规则，像管理制度、业务手册、工艺流程、操作规范、收费标
准、促销策略等都是规则，甚至一些没有形成文字的惯例，也是企业规则的一部分。因为是与业务相关，所以又称它
们为业务规则。

业务规则分散在企业的各个角落，就算企业的决策者也很难说清楚自己的企业内部到底有多少业务规则在使用。
大部分的业务规则存在于业务人员的大脑中，或是为数不多的工作手册、操作规范等非结构化的文档上。作为描述企
业最重要特征的业务逻辑没有被有效地管理和使用，导致好的经验无法积累，差的经验无法总结。即使企业使用了计
算机系统，业务处理逻辑也总是被看成一个个过程写进了程序代码中，当某些需求和业务规则发生变化时，必须修改
原有代码，修改和维护的成本都相当高。

业务规则管理（Business Rules Management，简称BRM）技术的出现彻底改变了以过程形式处理业务逻辑的方
式，它将业务规则的实现从具体的程序代码中抽取出来，以结构化的业务规则数据来表示企业的业务行为，使得业务
规则与企业的数据信息一样成为企业的重要资产。与此同时，软件开发的习惯也开始因BRM 而改变。业务规则像数据
一样独立于程序之外，业务人员可以使用行业术语而不是专业编程语言来编写规则，从而使企业的业务系统真正面向
业务人员。

在20 世纪80 年代，基于规则的编程方法曾经随着人工智能的研究热潮达到顶峰，但因为当时规则引擎性能很
差，并且没有与当时主流应用系统的集成能力，所以没有得到很好的应用。不过现如今，商用业务规则引擎的性能和
稳定性都已经达到相当高的水平。按照Gartner 的观点，业务规则技术正从前一次的“垂死经历”迈向复苏。
国外几乎所有大型通用软件提供商、大型行业软件提供商以及大型行业用户都在系统开发和系统运行过程中使用
了BRM 技术。虽然BRM 并不是一个革命性的技术，却在商业应用中成为技术新贵。国内软件开发商和用户的反应稍稍
滞后，为了加深他们对BRM 的认识，本期专题将系统地介绍业务规则的基础概念、技术原理及其应用。本期专题由如
下几篇文章组成：
1． 业务规则成资产
2． 用规则引擎替换代码
3． BRM 产品走向成熟
4． BRM：行业应用新宠

规则有多种含义，英语单词“Rule”的中文意思有：规则、惯例、统治、章程、准则、标准、控制等。那到底什
么是业务规则，像我们日常所见到的管理制度、业务手册、工艺流程、操作规范、收费标准、促销策略以及没有形成
文字的惯例等都可以称作为业务规则。

通常企业的决策者很难说清楚自己的企业内部到底有多少业务规则在使用，大部分的业务规则存在于业务人员的
大脑中，或是为数不多的工作手册、操作规范等非结构化的文档上。作为描述企业最重要特征的业务逻辑没有被有效
地管理和使用，好的经验无法积累，差的经验无法总结。即使企业使用了计算机系统，业务处理逻辑也总是被当做一
个个过程写进了程序代码中，当某些需求和业务规则发生变化时，必须修改原有代码，修改和维护的成本都相当高。
业务规则管理技术的出现彻底改变了以过程形式处理业务逻辑的方式，将业务规则的实现从具体的程序代码中抽
取出来，以结构化的业务规则数据来表示企业的业务行为，使得业务规则与企业的数据信息一样成为企业的重要资
产。

Gartner 表示，商业灵活性正主导着业务规则引擎（Business Rules Engine,简称BRE）迅速向友好、实时性方
向发展，灵活的业务规则管理技术的市场渗透率将在2007 年达到80%（在2000 年这一数字为20%）。
BRM 迈向复苏

20 世纪70 年代，斯坦福大学使用LISP 开发的MYCIN 是第一个基于规则的系统。该系统用于血液疾病的诊断，并
推荐治疗方法，可以算做是一个专家决策系统。该系统实现的主要理念是知识和控制的分离，将以规则表示的知识从
用于评估、执行的控制逻辑（程序）中分离出来，这是规则管理技术的启蒙时期。
20 世纪80 年代，基于规则的编程方法随着人工智能的研究热潮达到顶峰，那时候有不少的开发者和组织购买商
业化的规则引擎，但当时规则引擎性能很差，并且没有与当时主流系统的集成能力，基于规则的编程方法没有得到很
好的应用。按照Gartner 的副总裁和研究主管Jim Sinur 的话说：“由于早期的许多业务规则产品都以人工智能领
域和推理系统为基础，所以这个阶段的业务规则技术非常复杂，运营和维护费用高昂，从而导致了这种技术的“垂死
经历”。但是研究工作仍在继续，基于规则的编程方法仍然在某些方面得到应用。

20 世纪80 年代后期随着面向对象技术的兴起，分类机制、信息隐藏（封装）、消息通信机制等技术为人们解决
复杂应用软件系统提供了新的概念和模型，同时也为基于规则程序提供了更好的集成和实现方式。可以说，面向对象
机制很好地解决了数据与数据操作的关系，而业务规则管理技术为对象之间的消息通信提供了（以业务规则数据形态
处理业务逻辑的）触发机制，使对象模型和业务规则模型较完美地结合在一起。此外，丰富的图形化的业务规则管理
工具也是业务规则管理技术得到广泛应用的重要基础。按照Jim Sinur 的观点，业务规则技术正从前一次的“垂死经
历”迈向复苏。

将规则从程序中剥离

对于一个以追求利润为使命的企业组织来说，规则对其使命的完成起着关键作用。一个组织的成功取决于及时有
效的决策能力，而这种决策能力最终要变成策略及规则去落实执行。
策略和规则总是在不断变化，但一旦把业务规则像数据一样从程序中剥离，业务规则易变的难题也就迎刃而解，
其中理念改变在于“用管理数据的方式来管理业务规则”。在说到业务流程管理（Business Process Management，
简称BPM）的时候，我们也曾经提到要以管理数据的方式来管理业务流程，虽然与BRM 的工作原理有些类似，但二者
关注的层面不同，业务流程关注的是对企业内部独立系统和实体的整合，商用BPM 产品大多把规则引擎嵌入在BPM 引
擎之中。

从本质上来说，业务规则并不是新鲜事物。GUIDE Business Rule Project 对业务规则的定义是：“业务规则是
描述和约束业务的语句，用来刻画业务的结构或控制和影响业务的行为。”业务规则具有如下特性:申明性、准确
性、原子性、一致性、非冗余性。

业务规则方法学提供了一种依照业务规则概念进行分析问题和解决问题的方式，帮助人们发现规则、表现规则、
管理规则、自动执行规则，建立规则运行机制，最终目的是实现业务规则管理系统（Business Rule Management
System，简称BRMS）。使得简单的非技术性的概念容易被技术人员和业务人员所理解，业务人员不必涉及数据模
型、处理模型和对象模型即可直接面对业务规则，同时更加深入地参与系统的需求分析、设计与实现。
业务规则存储在规则库中，完全独立于数据和程序。业务人员可以对业务规则进行查询、添加、更新、统计、提
交等操作，并且可以在线修改和测试业务规则。业务规则可以不断积累、调整和共享，并能对规则进行版本管理，设
定规则的有效期，实现对业务行为的知识管理。系统的稳定性也因此得到了保障，系统的维护成本大大降低。
改变软件开发方式

数据库把程序与程序所处理的数据进行了分离，它的出现使得数据不依赖于程序而独立存在，软件系统的升级无
需对数据库系统进行改动，并产生了关系数据模型、数据库操作语言、数据库查询语言等新概念，以及数据库系统分
析员、数据库开发人员、数据库系统管理员等新角色。
与数据库的出现相对应，把业务逻辑从程序代码中分离出来也将对软件的开发方式、软件的体系结构甚至软件开
发的组织结构都产生深远的影响。

业务规则管理将业务逻辑当做结构化的对象进行处理，使复杂的业务逻辑变成一条条简单的业务规则，而将业务
规则之间的复杂逻辑关系交给规则引擎去处理，因此产生了业务规则引擎、业务规则库、业务规则开发方法学、业务
规则管理系统等新概念，以及业务规则系统分析员、业务规则开发人员业务规则系统管理员等新角色。
下表是业务规则管理系统与数据库管理系统的特点对照。

业务规则管理系统的引入，使应用系统结构及其维护方式发生了巨大的改变：基于业务规则方法将大大缩短系统
的开发时间；更加适应系统业务逻辑的变化；开发者可以直接使用业务规则的技术而无需了解过多的实现细节；大大
减少了编程的工作量，减少了编程错误，使开发者更加关注系统本身的业务需求；基于业务规则的开发方法还模糊了
系统需求分析、设计和编程的界限;业务规则库介于用户界面和数据库之间，系统具有更好的灵活性；基于业务规则
的系统开发比定制开发更能节省费用，同时能满足用户的个性化需求。

不少软件开发商已经开始利用业务规则管理技术来开发商用软件，它们不仅能够为用户搭建规则库，让用户随意
添加自己的业务规则，而且会在一些针对行业的应用中，将自己的行业经验以业务规则的形式加进去，为用户提供最
佳实践经验。

BRM 将无处不在

分层和复用是当今软件开发的两大技术方向。分层技术解决了系统的复杂性问题，降低了系统内的耦合性;复用
技术解决了开发的效率和可靠性。业务规则管理技术恰恰与这两大技术的特点相吻合，综合体现了分层和复用所带来
的好处，并且很好地融合了数据库技术和面向对象技术的优势。

智能化是业务规则管理的另一大特点。业务规则最主要的能力是行为约束和知识推理，规则引擎可以进行逻辑判
断，建立数据对象和规则之间的映射关系，并且能够动态组织与该数据对象相关联的、满足条件的业务规则，自动实
现这些规则之间的一致性、时间顺序、相容等逻辑关系，可以推导出新的业务规则。随着规则引擎技术的进一步提
升，它的智能化特征将在知识管理、决策支持、BI 等领域具有非常好的应用前景。

其实，现在基于业务规则的应用系统越来越多。例如前面提到的业务流程管理系统，不少BPM 都内嵌了BRM 引
擎；使用业务规则技术对遗留系统进行改造，去掉系统中易变的业务逻辑处理程序，放置一个规则引擎，可大大减少
系统的改造费用，增强系统的可维护性;在客户关系管理系统中，可使用以事件驱动为特征的规则引擎，实时定制工
作流程和业务处理;此外，业务规则管理技术也可以用于在线分析处理、数据仓库、现代物流等应用中。

在一些个性化需求较强的应用中，为每个客户编写个性化的处理程序是不可能的，但为每个客户建立相应的业务
规则是可能的。利用业务规则管理技术，可以在不修改应用程序代码的情况下，为客户提供个性化的服务。目前电
信、金融、保险等行业已经有不少软件开发商和用户使用业务规则管理技术。

不过值得一提的是，目前还没有对业务规则的工业标准化定义，多种业务规则描述语言并存，各种规则引擎对这
些规则语言的解释与执行也不兼容，这在某种程度上妨碍了业务规则技术的发展。此外，虽然市场上已经出现了不少
规则引擎，但只有为数不多的引擎达到了实用性能（每秒触发上万次规则的执行）。

·小资料1·

业务规则管理

业务规则最基本的组成成份是用于表示它的语言，业务术语是人们用于定义事物的工具，例如术语表。一个组织
的本质和运行结构可以用相关的术语来描述，如“客户下一个订单”。类似“数据不可以更新”这样的规则则能够限
定和控制企业的某些行为。此外，利用业务规则可以从一种知识推导出另一种知识。

业务规则的属性包括名称、状态（被提议的、有效的、被核准的、存档的）、有效日期和终止日期、业务规则描
述、表达式、触发事件等。其主要形式有决策表、决策树、规则语言和脚本。
● 决策表: 以表格的形式表示业务规则，每一行表示一条规则，列表示条件或动作，当所有条件满足时，执行
动作。
● 决策树：将一组业务规则以树型结构来表示，每一个分支表示一条决策路径，叶子节点表示结果或动作。
● 规则语言：使用类似自然语言的句法描述规则。目前有很多种规则语言，每种语言适合解决其特定领域的问
题，可以提供较好的性能，但比图形化的表示难于维护。
● 脚本（模板）：用于描述过程性的业务逻辑，是决策表、决策树、规则语言的基础。如：
IF...THEN ...ELSE...。
业务规则的应用特性如下：
● 业务规则的非“固化性”
固化在程序代码中的策略和规则必然是僵硬的。客户的多态性和市场的多变性决定了业务规则和策略的变化必然
很频繁，如果规则的每次改变都要求对系统程序进行“伤筋动骨”式的修改，那么系统的维护和升级必然代价昂贵，
甚至难以维持。
● 业务规则的“逻辑性”
业务规则具有逻辑性，每条约束行为的业务规则至少包含两个部分：条件部分和执行部分；规则的条件涉及到对
业务数据作用的判定，规则的执行涉及到对业务数据的处理。所以规则不是简单的业务数据。
● 业务规则的“非过程性”
每条规则只能定义对一种现象的判断和操作，复杂的业务逻辑应该由多条规则协同处理。规则的“非过程性”带
来的好处是：每条规则的制定变得非常单纯，可以“就事论事”，将复杂的过程处理平摊成一个个有条件的执行单
元，实现了从简单到复杂的知识积累过程。
● 业务规则的“事件触发性”
业务规则会根据相应的条件被触发执行，触发规则执行的“事件”就是业务数据本身。比如一套信用分析的规则
集合，一旦客户信用记录信息进入系统处理，这组规则将会被激活，并启动相应的分析过程。
● 业务规则的“非技术性”
业务规则是属于业务人员的，业务人员应该使用行业语言而不是专业技术语言（如程序语言、数据库语言、脚本
语言等）编写规则。

      
业务规则的在行业领域的强大应用资料下载：
     
    1、电信和移动通信运营行业

       A、故障管理
       B、计费系统

    2、银行和保险行业

       A、银行信贷评级系统
       B、保险核保系统

    3、规则在业务系统中的应用

       A、用规则替换代码
       B、BRM：行业应用新宠