过去几年，尽管在更大的圈子中存在质疑，但一种业务规则编程方法还是在保险公司等面向规则的组织处找到了立脚点。今天，各行业数量越来越多的组织都在指望能实现业务规则管理（BRM）。

　　BPM专业人士、技术领袖以及业务主管都知道BRM可以促进敏捷、改善决策制定、降低成本并支撑业务流程。正如Forrester Research的副总裁及首席分析师John Rymer概括的那样：“业务规则管理是一组未被赏识的产品和方案。谢天谢地，它在发展，因为大家能够从中获得一些真正的价值。”

　　不过专家同样警告称，如果背后没有适当的战略支持，相对于帮助，BRM技术更有可能帮倒忙。

　　尽管选择合适的BRM技术肯定是至关重要的，但是光有BRM是没有办法确保成功的。要想真正驾驭规则的力量，同时避免常见的陷阱，组织需要关注战略、业务-IT协作以及整体架构这些东西。

　　BRM技术现状

　　BRM以实现决策自动化及策略逻辑为目标，同时支持规则方便快速的变更。BRM工具把规则独立于代码，并显式地存储逻辑，令其可以方便地编辑，使得商业用户可以自行编辑规则，从而释放了IT资源。当然，快速方便地变更规则的能力对于在不断快速变化的经济形势下生存来说也是至关重要的。

　　当前的BRM技术，从基本的业务规则引擎和BPM工具，到完整的业务规则系统（也被称为业务规则平台）不等。Decision Management Solutions的CEO James Taylor说最常见的技术是业务规则系统，这是专门针对决策制定逻辑管理而设计的。

　　各种BPM产品和企业应用具备一些处理业务规则的能力，通常是通过用户界面的方式。然而，专家说BPM套件不符合业务规则和业务流程管理的一站式解决方案标准。

　　“当【BPM产品】所谓的‘业务规则’只是一些非常简单的运行脚本的环境，”Rymer说：“没有业务规则管理、没有编写工具，什么都没有。用脚本语言只能够写些简单的程序。”他是2011年Forrester若干份有关业务规则报告的联合作者之一。

　　其中一份名为“市场概览：2011年的业务规则平台”的报告建议寻找业务规则管理的客户放弃BPM套件，用内置的业务规则平台来代替。报告推荐对专注于业务规则的产品进行投资。

　　与此类似，单独使用的业务规则引擎也缺乏对规则管理的大规模解决方案。“如果大家使用的主要业务规则文档工具都是业务规则引擎的话，他们就会发现自己也能做这样的工具，”Kathy Long说：“人们不需要仅仅是规则引擎的工具。他们要的是该规则引擎如何跟工作流工具工作到一起。”Kathy Long是一位资深的BPM顾问，最近刚刚加盟了Shell Oil，担任其勘探与产品北美陆上分部的BPM领导。

　　最流行的业务规则系统通过规则管理整体解决方案来克服这一障碍，这个整体方案包含以下要素：

　　—带编辑工具的业务规则引擎，可根据业务方案编写代码，

　　—方便管理、变更规则的容器

　　—可以对规则存储和执行的服务器进行控制的管理能力。

　　Taylor说，今天的业务规则系统面向决策的程度是前所未有的高，既可以管理决策逻辑也可以建立预测分析模型。另一份Forrester报告，“业务规则平台的未来”，则把目标指向BRM技术中包括事件及决策管理在内的趋势。该报告注意到客户正在不断地寻求采用业务规则来对决策生命周期进行自动化管理—供应商对此也有响应。

　　对于许多人来说这也许并不出奇。“你购买一套业务规则管理系统或对等的技术的原因—不是简单地使用在你的业务流程工具或CRM系统中就有的业务规则能力，而是因为你希望管理决策，”Taylor说：“理解那些决策是什么、对于指定决策来说它又意味着什么，其重要性是很难夸大的。”

　　自顶向下策略

　　在某些情况下，确定哪一条规则和决定需要进行管理是成功的最大障碍。

　　这在很大程度上是由于规则的无所不在，组织努力想要识别哪一条业务规则属于关键业务决策背后的决策逻辑。如果不掌握这一点，就很难为何处使用业务规则环境，如何衡量成功谋划出集中化的战略。结果：留给组织的是没有效率的规则，会对维护构成挑战。

　　为了避免这一陷阱，Kathy Long建议采取彻底自上而下的业务规则管理办法。她提到了自己目前正在做的一个BPM项目。在这个项目上她在高层流程工作方面投入了时间以确保可以把BRM完全固化下来。“我们从顶层开始，”Long说：“一旦我们重新设计了自己的流程并准备好进入更多的细节，那个时候就是我们开始寻找工具之际。”

　　树立对流程和规则的集中观点有助于确定哪一项规则对业务最至关重要，并因此帮助组织的BRM战略适应业务目标。Long指出，对于一些公司来说，其主要的拦路虎是管理层不愿意花时间去把事情做对。

　　协作练习

　　甚至有了适当的BRM技术及可靠战略之后，组织往往也会成为组织性挑战的牺牲品。业务规则需要来自业务和IT工人的输入，这要求内部跨部门的沟通与协作。

　　许多组织专门使用BRM是想让做业务的编写或维护规则的。尽管业务规则系统也许能够帮助将这一责任从程序员转移到业务员那里，成功的关键还是文化的改变。

　　“作为一个组织，你必须认真思考项目的这些组织变更方面的东西，确保你投资的部分可以作为在两个部门之间建立信任的练习，”Taylor说：“你必须把它作为项目的一项明确的目标，”确保工作责任划分清晰、一开始就组织良好至关重要。

　　在同一阵线上，工人—尤其业务员需要培训，需要分配时间摸清楚新BRM工具与技术的门道。开发技能掌握业务规则系统最好的东西，比方说，组织可以提供继续教育，以最好的方式在那个特殊的环境里表达和管理规则。

　　传统的壁垒

　　从编写代码到编写业务规则的转变在许多IT组织内都引起了争议，程序员往往更习惯于使用Java或C#之类的编程语言。实现BRM技术以便与先前已有的应用以及已有的思考过程成功工作到一起—这对于某些企业来说也构成了挑战。这两个问题的根源都在于不愿意打破传统。

　　“这是一种不同的比喻，不同的逻辑思考方法，”Taylor说：“如果【业务规则系统】也跟编程语言一样用，人们就会按照写代码一样的方式写规则，最终只会得到极糟糕的业务规则。要想成功，你不能仅仅按照使用别的工具一般的套路来用它。”

　　除了拥抱不同的编写规则方式以外，组织需要适应已有的应用和软件，以便跟新适配的BRM工具平滑工作在一起。这会是一个障碍，尤其是当独立的工具被用于执行分析客户习惯之类的事情时。“有时候决策来自于对你正在做的事情的分析……对那个时候来到你网站的人的分析，”Rymer解释道：“规则引擎是你如何确定提供什么东西给他们，但分析是用别的东西、别的软件完成的。集成这些东西到一起真的挑战很大。”

　　解决方案又回到自顶向下策略。通过在跳到BRM之前把注意力放到架构上（包括业务和数据），组织可以牢牢控制与其他系统的集成点。

　　展望

　　好的BRM是面向未来的。如果一切都做得妥当，就可以确保未来很容易改变规则。从许多方面来说，这都是企业如何处理规则的一种背离，其关注的是短期项目和当前问题。在渐进的办法下，随着时间的推移，BRM考虑到了规则的成功管理。

　　Kathy Long担心BRM的这一主要好处有时候被忽视。“如果你做对了一次，那么它的维护就相当于没有，”她指出：“你只是改变了内容，但你不必改变访问这些规则的结构。”

　　一说到快节奏的业务变化，那一类的敏捷可赋予公司对竞争对手强有力的优势、“业务变更是那么的快，那么充满地方性，”Rymer说：“业务规则真的给了你跟进的武器。”