宝塔服务器面板，一键全能部署及管理，送你10850元礼包，点我领取

编辑指南：决策引擎是支持企业在客户管理CRM )中的各种决策的工具，可以在决策引擎上开发各种解决方案。 运营必须追求精细化，根据产品、用户、市场的具体情况制定具体的运营措施。 本文主要分享了决策引擎在用户层次精细化运营领域的应用方法我希望对你有帮助。

我个人不太喜欢“道术器”之类的记述。 所谓强国之策，无奇计，连接坚硬的村庄作战一直是我相信的战略和指导意见，但是前面几篇短文，都是精细化运营的“道术”，也就是为什么要做，怎么做才不会偏离整体目标抛开这些，我个人认为智能商业化的决策引擎是改变了重工人职场工作模式的最重要的“器皿”。

前东家的时候，为了项目和工作的协调，负责部门决策引擎的更新换代，或者拯救生命。 最近刚模糊地接手这个项目的时候，作为一个囿于前人留下的SHIT MOUNTAIN CODE、无说明、无PRD等，接手一个事务，习惯性地了解其全貌的铁头娃，真的是一段时间天天挠头可以说无从下手，也没有理解从什么角度切入。

基于之后的理解，大部分的决策引擎，或者市面上的决策引擎，大部分都是基于Drools的二次包，基于JAVA语言。 可能理解得太浅了，但我的理解是，理论上的)业务和战略负责人可以不用代码； 代入效率明显提高；

成熟后可以使用的【决策引擎】，与其说是单独的系统，不如稍微开阔一下视野。 包括Drools在内，应该是KYC用户画像、KYE负责人画像、良好的配置中心、良好的展示网页如稳定的电子销售系统/电子督促系统)、稳定稳健的战略/运营团队等。

在之后的业务需求中，任何阶段和问题都会导致最终结果的偏差。

我记得当时到处寻找合适的教程。 是流于形状，还是明显不知从哪里捡来的鳞爪牙慧，是帅气但不解决实际问题的PPT，或者是囿于一隅，都很容易把自己的眼睛局限在小疙瘩上。 不满足战略部门决策引擎的产品经理的需要。

基于Droolsworkbench版本6.2/6.4。 只知道SQL/IMPALA/HIVE/PYTHON，对决策引擎、Drools以不知道的观点展开。 由于各种原因，我们希望为需要在WorkBench上编写伪代码的战略人员/数据产品人员提供在策略实施阶段丢失的帮助，并每天进行改进。 如果有人看到它能掉几根头发，我希望掉下来的头发长在我头上。

在cdn上“风中的意志”伟大的人拯救了我很多头发，我从很远的地方就非常感谢。

一、什么是决策引擎及使用范围

决策引擎是指，对于业务人员来说，在大多数上下文和意义下，在业务线中，根据复杂的决策规则发挥路由作用，可以支持复杂的决策流程、决策树规则，分发案件/客户

最常见的使用范围如下。

电子商务场景，特别是“热名单”的分配； 业务场景、庞大的案件分配、促使案件滚动拨号实现的风险管理场景、模型规则APP的配置等。 至少在我浅浅的认识中，决策引擎主要完成了【顾客】这一核心资源的自动分配任务。

通常的决策引擎是“拖拽&amp； 无论是否支持“投放”的粉丝方式，在宣传语句中创建决策树/决策流，而不管自己支持的业务场景数量如何。 大多数决策引擎都是基于基于jrools 基于Java的BRMS解决方案)进行优化、迭代、集成和打包的独特业务经验。

对于一些商家，仍然是手工分配案件，不知道需要多少顾客来平衡收益。 无法在APP上注册的顾客马上询问购买产品的意向，决策引擎已经成为高科技的工具。

what’s more .决策引擎在常规业务管理方式难以挖掘业务潜力后，自然基于精细化运营所需的产品，主要用于战略频繁修改和禁止客户资源命令，而不是常规管理手段不完善的BU，

优秀的决策引擎，隐含所需的KYC客户画像水平，KYE员工管理水平，坦率地说，两者之间能达到一个优点已经很好了，可以说两个优点是最好的。

KPI依靠分解、分级、分类、分级，执行时决定定价、分级、定量、责任。 这些决策引擎可以发挥最大的作用。 当然，这不在文章的讨论范围之内。

二、决策引擎的组成

的典型决策引擎的组成部分如下：

kmodule.xml :预定义的工艺文件； *.drl:策略负责人修改的策略集文件KIE结构：’从KIE服务对象获取KIE容器，KIE容器根据会话名称创建新的KieSession 也许有)对前段的展示界面产品和战略来说是不知道的，不是吗？ 没关系。 至今也不知道。 这部分问题还是请技术人员考虑。

关于技术和组件，在这里我想关注一下个人经验的几点。

还请稍微注意一下*.drl语法：如经典的no-loop 、static 是否循环判断等，对计算效率及最后结果是否是自己想要的有极大影响；还请稍微注意一下'<groupid>/<artifactId>/kbasename’等：编写DRL规则文件时，如果使用的不是拖拉拽版本的决策引擎，针对此类字眼名称，烦请多次检查，否则打包时，会导致各种各样的报错频频；标签少点、少点、少点：不论是风控决策引擎，或者是电销、电催相关的决策引擎；不论是从外部引入第三方的数据标签，或者是在自己的KYC/KYE中形成自己客户、坐席的标签；标签是有悄无声息地突然增多的倾向的。标签应用到决策引擎上，应当是有详尽完善的测试之后再进行的。此外，标签应当多一些类别，少一些数量。否则标签的不及时清理，又会堆积成新的屎山。新的策略包上线时，不论有多困难，还请做一次上线测试，一次灰度测试：按之前的经验，假如说待判断案件有200万左右时，一次策略回滚，可能导致近12个小时无法生产，在这个时候，锅是甩不到运维那边计算效率低的。还请在上线前做一次上线测试。如果条件允许，配按量的灰度测试是极佳的；版本管理、版本管理、版本管理：现在大部分封装好的决策引擎已经可以提供版本管理和回滚的功能。但如果你使用的是裸露在外的DROOLS，还请自行做好版本管理的工作，以免之后领导突发奇想想回滚时找不到；队列管理、队列管理、队列管理：不论是电销或催收、或者是风控决策引擎，合理的学习交行卡中心所做的队列管理思路是不会错的。在编写策略包时，要清晰的知道这一个策略，是将案件从案件池分到队列（队列可以包含虚拟队列或者所谓的’场景’），还是从队列分到个人；要做到金字塔原理中的MECE规则，即全覆盖和不交叉。如果你所编写的策略，队列混乱且交叉。只能祝你之后查错的时候好运，希望接手你工作的人不是200斤带金链子的我。

三、一个策略方的产品经理，日常应该更关心什么

抛开DRL文件，抛开测试类，抛开标签，抛开赋值语句。窃以为，对一个策略部门的决策引擎产品经理来说，以下的内容才是更应该花时间去考虑的：

1. 清晰、流畅、兼顾各方、高内聚低耦合的决策流

作为一个BRMS工具，某种意义而言，整个系统，都是为了更好地实现业务的决策流。但常规存在的问题是，对于业务而言，每一个部门、小组，对于客户资源分配，都有自己的一些考虑，任何系统方面的偏差几乎必然成为业务与产品之间龃龉的理由。

第二个方面，画在XIMND上的决策树，在DroolsWorkBench中，因为性能、规则编辑方式、甚至因为其他组件不全、甚至因为技术提供的Drools版本太老的问题，难以实现。甚至需要人肉去划分两个进程、决策表来处理同一个问题。此操作是反奥卡姆剃刀原则的。每多一个环节，就会多一分出错的可能性。

因此，策略部门的决策引擎产品经理，在编写DRL文件之前，最需要做的，是了解并排查当前决策流中的问题。大概率，当新增一个决策引擎，或者更换一个决策引擎时，当前日常决策流程中，是存在各种各样的问题的。在梳理过程中发现的各个组之间的客户冲突，请直接暴露给决策层，避免造成后续的问题。

再具体梳理决策流时，请注意各个层级之间的内聚及不同层级之间的耦合，尽管产品经理并没有在具体写实施代码（其实决策引擎除了初期开发外，DRL文件修改也主要是产品运营去写。），但是这个原则一定会在之后方便复盘、修改等等。

应当尊重现有工作流，并尝试改变不合理的工作流，而不是一味服从：在编写DRL文件，或者调整决策引擎时，决策引擎的产品经理，是比其他任何人更能发现现有的决策流、工作流的问题的。可能是重复判断、可能是队列交叉，可能就是两个判断流之间有空隙等等。

可以尊重现有的工作流，但也请在有余力的时候，进一步清晰化决策流；否则屎山代码的积累，会变成一个击鼓传花的游戏，问题总会在一个人手上爆炸，你无法知道自己不是那个愤怒的白开水。

2. 注意与其他系统之间的交互和协同

抛开机械化地看待系统、看待工作；深觉得任何一个策略人员、数据分析人员、或者产品经理，都应该确实的理解一个问题，任何业务，尤其是一线作业人员较多的业务，系统之间的衔接和补充，甚至是比有多少个系统更重要的问题。重复造轮子拓展自己权限边界当我没说。

根据经验，会与决策引擎会产生交互的系统有：

前端展示即作业系统、标签集市或数据管理系统、配置管理系统、（有可能）大数据平台、（有可能）智能外呼机器人等，当然，还有最主要的系统，人。

因此，出于解决生产问题考虑，会有如下一些问题需要考虑：

决策引擎的日志需要保留到怎么样的一种程度，或者日常作业的数据可以仅保留在作业系统的数据库中；如何减少代码的使用量地，可扩展地与标签集市发生交互；当计算资源不足时，如何妥善的分解决策流，更高效地使用计算资源等等。甚至，需要考虑，如何编写完善的文档，当一线作业人员对自己手里的案件有疑问时，可以妥善的处理疑问。

3. 成本、效率

当所使用的数据有外部引入的数据时，或在整个体系中需要使用收费的外部服务时，就会明确牵扯到成本的管控问题。即使是仅出于自己安全考虑，也应当注意到每一笔调用的费用带来了什么。成本是否可控，是否有足够的性价比。

四、我所建议的学习路径

基于之前的不堪回首的经历，如果你是一个新人的策略部门的决策引擎管理员，建议采用以下的流程去学习熟悉（仅针对非可视化非商业化的产品）:

LESSON1：JAVA基础了解。如果之前对于代码，仅有hxdmjC语言级别的了解。甚至C语言课程都没有看过，建议花1天时间，稍微了解一下类、变量、继承的概念。LESSON2: DROOLS基础了解。DROOLS WORKBENCH尽管是基于JAVA的产品，但其核心概念KIE结构毕竟是单独的一个内容。建议花1天时间，了解KIE结构，了解SESSION、容器、类的感念。LESSON3：决策流梳理。类似于上述的内容，请酌情花一段时间，去了解各个组之间的决策流，了解不同组别对客户的需求、或者队列的差异。并根据实际情况，生成自己的构想。LESSON4：自己动手去做测试。不论DRL构想有多优秀，除非使用ECLIPSE或者其他IDLE，在本地对自己的DRL文件进行测试，不然很难认知到自己的设想的错误。请在任何版本更迭之前，做好测试及确认工作。

五、最后的碎碎念

不得不说，决策引擎的产品运营，相对于其他系统来说，考虑到其对生产的巨大影响，及与其他诸多系统的交互，及产品经理与诸多组别的交互，是非常考验人耐心及细心的系统。另外，不论是运维的问题或者是系统的宕机，又或者是策略的翻来覆去，甚至是前人留下的屎山代码都会造成可能的生产事故。不了解情况的人，会认为均是你的问题。因此，建议有选择的时候，慎重选择决策引擎的产品运营角色。

此外，不得不说，决策引擎运营的久了，整个思路确实也更加相信控制论，这可能是管理决策引擎带来的思路上面的改变。

祝愿所有管理决策引擎的愤怒的白开水少掉点头发。

本文由 @肥xhdqc 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议