在2015年，我们因SMARTS红笔功能获得了一项决策引擎领域的专利。回过头看，我们收获了不少认可。这里我还是想说明一下，为什么我们不断地投入资金和精力来进行红笔功能的研发。毕竟，相关研究大多发生在上世纪80年代，而我们当时还只是一个小公司，致力于通过应用新技术来优化决策管理流程。

       首先，决策管理系统有如下优势：

  • 运营决策的自动化、批量化处理
  • 降低失误率和决策的不一致性
  • 让公司于专注于高附加值业务以及处理复杂决策
  • 协助企业快速、高效的迭代决策策略
  • 通过以上方法帮助公司提升效益

为什么现在决策管理技术仍没有得到普及？

       据我推测，困难点可能仍是如何提取专家经验并将其维护进系统。毕竟只要我们知晓了业务规则，大约在几天或几周内，就可以完成项目的部署。所以，其中最困难的仍是将哪些知识和规则维护进决策管理系统中。

       目前，市面上比较普遍的做法是咨询顾问或决策建模专家和相关领域专家沟通项目需求，或者通过工作手册和其他方式侧面了解项目需求。我见过最坏的情况是，开发团通过对COBOL或C语言代码进行解码来找出相应规则。

       好消息是如今我们有DMN等方法帮助我们进行决策知识系统的搭建，同时也有如SMARTS Pencil等支持DMN格式的工具。我们仍然相信，尽管建模工具十分有价值，其仍然没能完全解决如何将业务经验进行提取并维护进系统的问题。


规则提取/启发的挑战

       近些年来，在研究如何将业务经验转换为规则上的投入一直很低，究其原因，还是因为难以取得突破性进展。所以，怎样才能更方便的将业务专家（非决策管理专家）的专业知识和经验转换成完整且准确的业务规则呢？

       我们是否能提供更便于使用的组件，功能强大到能够完全展现所有的业务逻辑呢？这不失为一条有趣的切入点，但作为一个产业，我们仍需不断打磨这些组件的细节。如果一开始就知道需要执行的规则，那么我们就能够针对性的设计出相应的基本组件。就像Lego（乐高）一样，当我们知道Ninjago的模型后，我们能将其拆分成不同的特制模块。然而就如《第二十二条军规》一般，期望和现实的悖论我们无法避免。

       难道我们不应该让业务专家来亲自编写业务规则吗？如果我们的设计不能让业务专家维护规则，那么科技的主要优势将荡然无存。传统的业务专家—建模团队—规则模型发布模式不仅会降低工作效率，还可能产生沟通偏误，造成产品迭代滞后的后果。


为什么规则提取/启发很重要？

       我们的研究收获了两项关于决策逻辑提取/启发技术的专利，现如今都在SMARTS明策智能决策引擎中有所应用。其中涵盖了两个主要方面。

       其中一个最大的挑战就是让业务专家们能够按照他们习惯的模式来展示业务规则。他们熟悉的是业务本身，也就是说他们明白整个业务流程，并且知道如何处理其中遇到的问题。最初，我们主要研究如何简单、自然地展现规则，不辅以数据进行验证。您不仅可以直观了解规则的内容，还可以通过执行决策来检查它是否能输出正确的结果。

       我们获得的第二个专利与业务场景有关。比如，我可以知道在某个决策中哪一些字段发挥了作用，或者也能知道这些字段被调用到的频数及频次。关于理解决策逻辑，还有很多现在仍然被忽略的方面。当然，如果一开始就没有方法去编辑业务规则，那么理解决策本身也就没那么重要了。但是如若当我们知道了如何编辑和维护业务规则时，理解决策逻辑就变得十分重要了。

       毕竟，我们并不是为“改”而“改”，而是需要通过调整业务规则来改善我们的决策逻辑。