使用业务规则管理系统(BRMS)管理决策逻辑以实现透明度和敏捷性是构建决策管理系统所需的五大关键功能之一。每个功能都可以逐步采用，并且可以根据资源和业务驱动因素进行扩展。
托管的可执行业务规则比传统代码具有许多优势，尤其是在自动化和管理决策时：
l 业务规则更易于非技术业务专家阅读，从而改善业务/IT协作并提高相对于代码的准确性。
l 业务规则是声明性的，允许单独管理每个规则。这简化了决策逻辑的管理和重用，同时还允许对一致性、完整性和质量进行更精确和更细致的评估。
l 业务规则要么针对特定交易“触发”（条件元素评估为真），要么不触发。这代表了对决策如何做出的精确描述，支持后续分析和决策改进。
概述
构建决策管理系统需要一套完整的软件组件，用于在生产运营环境中创建、测试、管理、部署和持续维护决策逻辑（业务规则）。此功能最常见的产品类别名称是业务规则管理系统(BRMS)。
就本文而言，我们仅关注可执行逻辑、可执行业务规则，即在允许其在计算机系统中执行的级别定义的业务规则。业务规则可以作为需求方法进行定义和管理，并确保手动决策的一致性和准确性，但这不是本文的重点。
通常，可执行业务规则只是对给定一组条件为真时应采取什么行动的陈述。每个规则都有一个条件元素，可以在某个时刻对其进行评估，以查看它是真还是假，以及如果它为真则要采取的一个或多个行动。这些行动可能多种多样，例如发送电子邮件或调用函数，但通常涉及设置数据值。在大多数BRMS中，每条规则还可以具有所有者、注释、版本历史记录和其他描述它的元数据。
托管的可执行业务规则比传统代码具有许多优势，特别是在自动化和管理决策时：
l 业务规则更易于非技术业务专家阅读，从而改善业务/IT协作，并提高业务规则相对于代码的准确性。这尤其如此，因为业务规则也可以用各种图形和表格隐喻来表示。
l 业务规则是声明性的，允许每个规则独立管理，从而简化决策逻辑的管理和重用，同时还允许对一致性、完整性和质量进行更精确和更细致的评估。
l 业务规则要么为特定事务“触发”（条件元素评估为真），要么不触发。这可以（也应该）在每次做出决策时记录下来，并代表决策如何做出的精确描述。这支持后续的决策分析和改进。
BRMS或同等功能使业务用户和分析师能够对关键业务系统进行常规更改和更新，同时释放IT资源以专注于更高附加值的项目和计划。即使IT组织以更传统的方式使用BRMS，BRMS也可以通过更轻松地查找、进行和测试决策逻辑的更改来实现更快速的更改。
架构
管理决策逻辑需要支持一系列活动的软件：
l 与其他应用程序和服务集成并将业务规则链接到数据源，以便可以开发使用现有系统和流程中可用数据的业务规则。
l 技术用户和非技术用户开发和测试业务规则，以便所有参与定义决策的人员都可以参与编写业务规则。
l 为技术用户和非技术用户识别规则冲突、一致性问题、质量问题等，以便充分利用业务规则的声明性。
l 通过模拟和报告评估业务规则更改对业务的影响，以确保进行正确的更改并了解必须进行的更改的业务后果。
l 将定义的业务规则包部署到不同计算环境中的决策服务。根据在决策服务中执行业务规则的结果来衡量和报告决策和业务规则的有效性。
这样的系统需要以下功能。
功能
规则管理
至少适合技术用户的业务规则管理环境是必不可少的。此环境通常还包括设计工具，用于将部署的业务规则与企业计算环境的其余部分集成在一起。通常，这是作为集成开发环境或IDE的一部分提供的，通常基于Eclipse或VisualStudio。
技术用户通常不是唯一需要编辑业务规则的人。允许业务分析师和业务用户直接和在上下文中管理业务规则的接口，或允许构建和维护此类接口的工具，是管理决策逻辑的强大方法的关键要素。这些接口可以是IDE的一部分，尽管这种情况不太常见，而瘦客户端接口更有可能。一些产品基于MicrosoftOffice产品（特别是MicrosoftWord和MicrosoftExcel）为非技术用户提供编辑环境。
通常使用各种隐喻来编写业务规则。规则流或决策流用于布置决策中的多个步骤。可以为此类流程中的每个步骤或任务指定业务规则，例如决策树、决策表、规则表、决策图、决策模型、规则系列或仅仅是独立规则的列表。这些隐喻之间的差异以及每个隐喻的价值将在其他文件中讨论。
验证和确认
验证和确认工具可检查业务规则的完整性、一致性和逻辑错误，有助于确保编写的业务规则有效。此类工具应适合技术和业务用户使用，并应与提供的各种编辑界面集成。这些工具应确保编写的业务规则至少具有潜在有效性。它们无法判断业务规则是否适合业务，或者是否能处理每种业务场景，但它们可以判断业务规则在结构和逻辑上是否完整，以及它们是否能处理已知的数据变化（例如值列表）。
图1.管理决策逻辑的功能
测试和调试
支持单元、系统和验收测试的测试和测试管理工具是必需的。虽然在某些情况下，业务规则变化如此之快，以至于正式测试不是发布周期的一部分，但大多数组织在允许部署一组新的业务规则之前，仍会希望运行一组测试。管理这些测试应该很简单。有时必须在更广泛的应用程序部署环境中使用其他新组件测试业务规则，并且能够在此环境中测试业务规则很有用。许多产品支持与开放测试管理标准（如xUnit）集成。
技术用户（最好是技术水平较低的用户）也应该能够调试业务规则。他们应该能够浏览决策中执行的业务规则，以查看特定情况下会发生什么。这可能仅适用于本地测试环境，或者同时适用于本地和生产环境。
影响分析
影响分析和业务模拟工具允许非技术用户查看一组规则更改对其业务结果的影响，这是管理决策逻辑中越来越重要的一部分。业务分析师和业务用户通常不愿意更改业务规则，除非他们能够看到更改会产生什么影响。同样，当由于监管或政策变化等原因必须对业务规则进行更改时，业务用户将希望看到此更改可能产生的影响。结果必须以业务术语呈现才有用——盈利能力提高、欺诈减少等。
这些设施可以作为批处理工具提供，用于通过一组业务规则运行历史数据或样本数据，也可以作为更具交互性的工具提供，允许业务用户选择他们关心的数据并针对该数据运行新的或更改的规则。最佳做法显然是将其更接近规则本身的编辑，并在编辑工具中进行更改时自动显示更改的潜在业务影响。
数据管理
决策逻辑必须与部署业务规则时可用的数据集成。它需要提供至少允许技术用户将业务规则与组织数据集成的工具。此外，产品能够引入大量历史数据以及大型测试数据集以支持有效的测试和影响分析是很有用的。
部署
需要一组部署工具，支持将一组业务规则部署为可执行代码或可由高性能业务规则引擎执行的包，最好是在多个企业平台上。
容易混淆的一点是业务规则引擎(BRE)和业务规则管理系统(BRMS)之间的区别。BRE可以作为处理与业务规则相关的所有事务的完整系统的一部分。它显然是一个重要部分，但它只处理执行。它确定需要以什么顺序执行哪些业务规则，BRMS涉及的内容更多。
部署后，业务规则可以以多种不同的方式执行。一些BRMS支持推理执行。基于各种算法，许多算法源自原始Rete算法，这些算法根据业务规则的结构和必须评估时可用的数据确定正确的执行顺序。当业务规则触发并更改数据时，引擎会重新评估接下来可能需要触发哪些业务规则。
虽然有些场景在没有推理支持的情况下很难甚至无法处理，但这些场景并不常见。推理在正常使用中的主要优势是它允许以任何顺序编写业务规则，并确保在其条件中使用的数据发生变化时重新评估业务规则。
业务规则也可以按顺序执行，使用在设计时为业务规则指定的顺序。在许多情况下，尤其是当一组中的大多数业务规则将针对大多数事务执行时，这种方法更快。它还允许业务规则生成代码，从而可以实现更小、更便携的部署。
最后，有几种产品提供设计执行，其中规则按顺序执行，但顺序由部署时对业务规则的自动分析确定。这简化了执行，但允许以任何顺序编写和编辑业务规则，而不会对其行为产生任何意外影响，因为部署时分析将适当地对新的和更改的业务规则进行排序。
对于大多数业务场景，所有这些方法都很有效。每种方法都有一套自己的业务规则编写最佳实践。
存储库
最后，但绝非最不重要的一点是，产品应提供用于存储和管理业务规则的企业级存储库。该存储库可能是一个完整的决策管理存储库，还存储预测分析模型和优化模型。它更可能只管理业务规则。它应提供访问控制和安全性、对业务规则所做更改的审计跟踪以及多个级别的版本控制。可扩展的存储库允许添加其他信息以及用于存储库访问的API，可以改善产品与其他企业组件的集成。一些产品提供与源代码控制系统的集成，允许将业务规则与应用程序其余部分使用的代码一起存储和管理。
下一步
嵌入预测分析需要一个软件组件来创建、验证、管理、部署和持续重建预测分析模型。这样的预测分析工作台允许数据挖掘者、数据科学家、分析专业人员或业务分析师探索历史数据并使用各种数学技术来识别和建模该数据中可能有用的模式。
我们拥有丰富的经验，专注于帮助客户使用决策管理、业务规则和高级分析技术构建以决策为中心、以行动为导向的系统和流程。使客户快速有效地采用决策建模并将其集成到他们的系统中。我们的客户涉及保险、银行、医疗、制造、供应链、物联网、电信、电商、健康管理和零售等领域的领先公司。
您可以联系我们进行免费咨询并了解有关我们服务的更多信息。
