目前自动化运营业务决策做得相当好，可以业务逻辑的编码从程序员转移到专门规则引擎平台，从而显着提高 IT 生产力。
但是程序员仍然要对另一种与规则相关的编码负责，这种类型得编码不仅消耗大量资源，而且对服务质量和数据质量都有深远的影响。
让我们通过一个示例规则来探讨这个问题。
规则：如果客户已下订单，则必须将客户分配给代理。 |
正如我一直推荐的业务规则一样，该规则以纯粹的声明方式表达。因此，规则声明并未指明任何特定的流程、程序或其他方式来执行或应用它。
现在问自己这个基本问题：为什么我需要任何流程模型来执行它？！
人类无需参考任何流程模型即可正确理解和执行规则。那为什么机器不能呢？！
在当今世界，大量的程序员工作量来自于构建流程模型和编写代码来执行规则。
这是一个巨大的工作量，在任何规模或复杂性的企业中，实际上都有 1,000 条这样的规则。
这里的规则并没有说：请观察“当客户下订单时”，然后 [做XXX]。(它是说：如果客户已下订单，而不是：当客户下订单时)
（banq注：当然，跟踪“客户已下单”这个事件，一般是在动作“客户下订单时”命令发出的时候，但不只是在这个命令动作，还有另外一命令：代理辞职）
“当客户下订单时”并不是唯一可能违反本规则并因此需要评估的事件。
还有一个可能违反此业务规则的事件：
“当代理离开我们公司时……”。
当代理离开时，他被分配的客户可能会被搁置一旁，这也违反了本规则。
因此，业务规则也需要在后一种事件中进行评估。
换句话说，在两种截然不同的运营业务事件中可能会违反此规则：
- 第一个，“当客户下订单时……”，这类事件发生概率相当大。
- 第二个，“当代理人离开我们公司时……”这类事件发生概率可能要少得多。
尽管如此，这两个事件都很重要，因为任何一个都可能产生违规行为。我把这些明确的事件称为规则的闪点。
如果你喜欢从决策的角度思考，问问自己第二个闪点对应的业务决策是什么。
也许您可以为此目的发明一个，但从商业角度来看，这不是很自然。
现在问自己这个后续问题：当前 IT 方法和工具中的哪些内容可以确保您在所有可能出现规则闪点的所有流程、程序和用例中获得一致的规则结果？
不要忘记临时事件；也就是说，轻量级甚至无脚本的业务事件。
不幸的是，今天的答案是几乎没有。
如果这项工作完成了，那就是程序员的工作，换句话说，这变成了程序员的工作量。
而且由于这是程序员的责任，因此很容易出错。它会产生难以维护的脆弱系统，尤其是当您的规则发生变化时。
顺便说一句，这个编程黑洞是许多组织的数据质量如此糟糕的一大原因。
定义性规则与行为规则
回过头来看整个规则空间，这个例子表明，从业务（和逻辑[1]）的角度来看，实际上存在两种不同类型的规则，而不仅仅是一种。
- 定义性规则
这种规则不能被打破。一条“定义性规则”可能是坏的或错误的，但它不能被违反。当然，您可以选择忽略结果，但那是完全不同的事情。
示例：如果客户在一个日历年内下达超过 12 个订单，则该客户必须被视为黄金客户。
决策规则和决策表属于第一类。
- 行为规则
行为规则可能会被违反或破坏。它们管理持续活动的行为，因此对人员、组织和业务活动至关重要。非常粗略地，您可以将行为规则视为业务约束。
示例：如果客户已下订单，则必须将客户分配给代理。
通常，行为规则可能会在多个闪点被违反。
观察者
让我们用足球来说明和分析行为规则的执行情况。众所周知的足球行为规则包括越位和禁止从背后铲球。
这些规则是由观察正在进行的比赛活动的裁判进行评估的，并实时判断是否有违规行为。
踢足球不需要任何流程模型。这将是一个多么奇怪的概念啊
相反，为了执行行为规则，足球运动有一个裁判，我称之为观察者，他是事件活动的外部人员，能够在任何时候打断事件活动。
对违反行为规则的检测和反应都是实时发生的。
对行为规则的执行进行实时干预的概念是至关重要的。
就像在足球比赛中，你不能等到事件活动的后期才执行许多或大多数行为规则，因为那时已经太晚了。
违规行为所造成的伤害可能是其本身的许多倍。
行为规则的来源
在我们捕获的所有规则中，有超过50%是行为规则。
行为规则的自然来源包括法律、行为、法规、条例、合同、协议、谅解备忘录、交易、许可证、证明、契约、保证、引证、收据、通知等等。最后但同样重要的是大多数商业政策。
我们 "发现 "这么多行为规则的事实让决策界的一些人感到惊讶。恕我直言，这是因为我们的方法并不局限于只看决策模型和决策表。
相反，我们认为适当的焦点是更大的商业治理和知识协调问题。