我个人是不太喜好“道法术器”之类的描述的，所谓强国之策无奇计，结硬寨打呆仗一贯是我所笃信的策略和辅导见地，但不得不说，前述的几个短文大略的描述了风雅化运营的“道法术”，也便是为什么要做、到底怎么做、如何掌握其不偏离整体目标的问题。抛开这些，个人以为智能化商业化的决策引擎，算是改变了重人力职场作业模式的最主要的“器”。
在前雇主时，有段韶光，因项目和事情调度，卖力了部门决策引擎的更新换代，或者叫救去世扶伤。近期依稀想起来记得刚刚接手该项目时，囿于古人留下的SHIT MOUNTAIN CODE、无解释、无PRD等，作为一个接手一件事务，习气性理解其全貌的铁头娃，其实有一段韶光每天挠头。可以说无从下手，并不理解从怎么样的角度去切入。
基于后来的理解，大部分的决策引擎，或者说在市情上能买到的决策引擎，大都是基于Drools的二次封装，其基于JAVA措辞。可能是理解过于粗浅，但在我理解上来说，其无外乎做到了两点：①（理论上的）业务及策略职员可无代码利用；②赋值效率明显提升；
一个成熟可用的【决策引擎】，与其说是一个单独的系统，不如轻微扩展一下视野。其该当是包括Drools在内，包含KYC用户画像，KYE包办人画像，一个良好的配置中央，一个良好的展示页面（如稳定的电销系统/电催系统），以及一个稳定且健壮的策略/运营团队等。
在之后的业务需求中，任何一个环节和问题，都会引起终极的结果的偏差。
依稀记得当时遍寻适宜的教程而不得。要么流于形式，很显然是不知从哪里拾得的只鳞片爪的牙慧，要么便是伟光正但不办理实际问题的PPT，要么囿于一隅，很随意马虎将自己的眼力局限在一小块。并不知足一个策略部门决策引擎产品经理的需求。
本文基于，DroolsWorkBench6.2/6.4版本。仅对SQL/IMPALA/HIVE/PYTHON有过理解，对决策引擎、Drools毫无理解的视角去展开。希望能为由于各类缘故原由，在策略履行阶段，仍须要通过WorkBench编写伪代码的策略职员/数据产品职员供应一丢丢帮助，日行一善。如果有人看到了之后能少掉几根头发，希望少掉的头发能长在我的头上。
CSDN上’在风中的意志’大佬救了我不少头发，迢遥感谢下。
一、什么是决策引擎及利用范围
决策引擎，对付业务职员来讲，在大部分语境和语义下，都是指在业务线中，可根据繁芜的决策规则，起到路由浸染，可以支持繁芜决策流，决策树规则的，将案件/客户分发的一个工具。
最常见的利用范围有：
电销业务场景，尤其是‘热名单’分配；电催业务场景，巨量案件分配及案件滚动拨打的实现；风险管理场景，模型规则运用的配置等。至少在我浅薄的认知中，决策引擎紧张起到的便是【客户】这一核心资源的自动分配任务。
常规的决策引擎，不论是否支持“拖沓拽”的Fancy办法制订决策树/决策流，无论宣扬语上提到自己支持多少种业务场景。绝大部分的决策引擎，都是基于Drools(基于Java的BRMS办理方案）优化、迭代、领悟自己的一些业务履历，打包而成的东西。
相对付某些同行，仍旧利用手工的办法去分配案件，算不清楚营收平衡须要多少客户，做不到新增上岸APP的客户及时问询购买产品意向来说，决策引擎已经算是较为高科技的工具了。
What’s more .决策引擎，个人觉得是通过常规的业务管理办法，已经很难再挖掘业务潜力之后，所自然而然的，基于风雅化运营之后所需的一个产品，紧张用于策略的频繁修正及客户资源的令行禁止，而不是一个常规管理手段都没有做好的BU，通过引入决策引擎，就可以翻身了。
一个良好的决策引擎，隐含所需的 KYC客户画像水平，KYE 员工管理水平，坦而言之，两者间能做到一个长处已经可以算作精良，两个长处可以算作极品了。
KPI靠分解、分层、分类、分级，实行的时候靠定价、定级、定量、定责。做到这些决策引擎才能发挥最大浸染。当然这个就不在文章谈论范围内了。
二、决策引擎的组成
一个常规的决策引擎的组成有：
kmodule.xml：定义好的流程文件；.drl:由策略职员修正的策略集文件；KIE构造：’通过KieServices工具得到一个KieContainer，然后KieContainer根据session name来新建一个KieSession，末了通过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根本理解。如果之前对付代码，仅有谭浩强C措辞级别的理解。乃至C措辞课程都没有看过，建议花1天韶光，轻微理解一下类、变量、继续的观点。LESSON2: DROOLS根本理解。DROOLS WORKBENCH只管是基于JAVA的产品，但其核心观点KIE构造毕竟是单独的一个内容。建议花1天韶光，理解KIE构造，理解SESSION、容器、类的感念。LESSON3：决策流梳理。类似于上述的内容，请酌情花一段韶光，去理解各个组之间的决策流，理解不同组别对客户的需求、或者行列步队的差异。并根据实际情形，天生自己的构想。LESSON4：自己动手去做测试。不论DRL构想有多精良，除非利用ECLIPSE或者其他IDLE，在本地对自己的DRL文件进行测试，不然很难认知到自己的设想的缺点。请在任何版本更迭之前，做好测试及确认事情。五、末了的碎碎念不得不说，决策引擎的产品运营，相对付其他系统来说，考虑到其对生产的巨大影响，及与其他诸多系统的交互，及产品经理与诸多组别的交互，是非常磨练人耐心及细心的系统。其余，不论是运维的问题或者是系统的宕机，又或者是策略的翻来覆去，乃至是古人留下的屎山代码都会造成可能的生产事件。不理解情形的人，会认为均是你的问题。因此，建议有选择的时候，慎重选择决策引擎的产品运营角色。
此外，不得不说，决策引擎运营的久了，全体思路确实也更加相信掌握论，这可能是管理决策引擎带来的思路上面的改变。
祝愿所有管理决策引擎的晦气蛋少掉点头发。
本文由 @肥柴周 原创发布于大家都是产品经理。未经容许，禁止转载
题图来自Unsplash，基于CC0协议
