首页 > 杂文归档 正文
精细化运营的核心支持工具:决策引擎

 2021-02-21 18:20:06     

在前东家时,有段时间,因项目和工作调整,负责了部门决策引擎的更新换代,或者叫救死扶伤。近期依稀想起来记得刚刚接手该项目时,囿于前人留下的SHIT MOUNTAIN CODE、无说明、无PR

在前东家时,有段时间,因项目和工作调整,负责了部门决策引擎的更新换代,或者叫救死扶伤。近期依稀想起来记得刚刚接手该项目时,囿于前人留下的SHIT MOUNTAIN CODE、无说明、无PRD等,作为一个接手一件事务,习惯性了解其全貌的铁头娃,着实有一段时间天天挠头。可以说无从下手,并不理解从怎么样的角度去切入。

基于后来的理解,大部分的决策引擎,或者说在市面上能买到的决策引擎,大都是基于Drools的二次封装,其基于JAVA语言。可能是理解过于粗浅,但在我理解上来说,其无外乎做到了两点:①(理论上的)业务及策略人员可无代码使用;②赋值效率明显提升;

一个成熟可用的【决策引擎】,与其说是一个单独的系统,不如稍微扩展一下视野。其应该是包括Drools在内,包含KYC用户画像,KYE经办人画像,一个良好的配置中心,一个良好的展示页面(如稳定的电销系统/电催系统),以及一个稳定且健壮的策略/运营团队等。

在之后的业务需求中,任何一个环节和问题,都会引起最终的结果的偏差。

精细化运营的核心支持工具:决策引擎

依稀记得当时遍寻适宜的教程而不得。要么流于形式,很显然是不知从哪里拾得的只鳞片爪的牙慧,要么就是伟光正但不解决实际问题的PPT,要么囿于一隅,很容易将自己的眼光局限在一小块。并不满足一个策略部门决策引擎产品经理的需求。

本文基于,DroolsWorkBench6.2/6.4版本。仅对SQL/IMPALA/HIVE/PYTHON有过了解,对决策引擎、Drools毫无了解的视角去展开。希望能为因为种种原因,在策略实施阶段,仍需要通过WorkBench编写伪代码的策略人员/数据产品人员提供一丢丢帮助,日行一善。如果有人看到了之后能少掉几根头发,希望少掉的头发能长在我的头上。

CSDN上’在风中的意志’大佬救了我不少头发,遥远感谢下。

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

决策引擎,对于业务人员来讲,在大部分语境和语义下,都是指在业务线中,可根据复杂的决策规则,起到路由作用,可以支持复杂决策流,决策树规则的,将案件/客户分发的一个工具。

最常见的使用范围有:

  1. 电销业务场景,尤其是‘热名单’分配;
  2. 电催业务场景,巨量案件分配及案件滚动拨打的实现;
  3. 风险管理场景,模型规则应用的配置等。

至少在我浅薄的认知中,决策引擎主要起到的就是【客户】这一核心资源的自动分配任务。

常规的决策引擎,不论是否支持“拖拉拽”的Fancy方式制定决策树/决策流,无论宣传语上提到自己支持多少种业务场景。绝大部分的决策引擎,都是基于Drools(基于Java的BRMS解决方案)优化、迭代、融合自己的一些业务经验,打包而成的东西。

相对于某些同业,仍然使用手工的方式去分配案件,算不清楚营收平衡需要多少客户,做不到新增登陆APP的客户及时问询购买产品意向来说,决策引擎已经算是较为高科技的工具了。

What’s more .决策引擎,个人感觉是通过常规的业务管理方式,已经很难再挖掘业务潜力之后,所自然而然的,基于精细化运营之后所需的一个产品,主要用于策略的频繁修改及客户资源的令行禁止,而不是一个常规管理手段都没有做好的BU,通过引入决策引擎,就可以翻身了。

一个良好的决策引擎,隐含所需的 KYC客户画像水平,KYE 员工管理水平,坦而言之,两者间能做到一个长处已经可以算作优秀,两个长处可以算作极品了。

KPI靠分解、分层、分类、分级,执行的时候靠定价、定级、定量、定责。做到这些决策引擎才能发挥最大作用。当然这个就不在文章讨论范围内了。

二、决策引擎的组成

一个常规的决策引擎的组成有:

  1. kmodule.xml:定义好的流程文件;
  2. *.drl:由策略人员修改的策略集文件;
  3. KIE结构:’通过KieServices对象得到一个KieContainer,然后KieContainer根据session name来新建一个KieSession,最后通过KieSession来运行规则’。
  4. (可能有)前段展示界面;

对于产品或者策略来说是不是看不懂。没事,我到现在也看不懂。这部分问题还是交给技术人员去考虑。

技术及组件相关的,在此我只想就个人经历着重提醒注意几个点:

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

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

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

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

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

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

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

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

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

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

精细化运营的核心支持工具:决策引擎

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

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

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

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

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

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

3. 成本、效率

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

四、我所建议的学习路径

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

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

五、最后的碎碎念

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

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

祝愿所有管理决策引擎的倒霉蛋少掉点头发。

原文链接:http://www.yuepc.com/a/6224.html

http://www.yuepc.com 为 “沈一博客” 唯一官方服务平台,请勿相信其他任何渠道。