一、背景介绍
1.1 什么是CRM
1.2 商机业务介绍
二、商机流转遇到的问题
2.1 商机流转业务特点
2.2 商机流转业务痛点
三、什么是规则引擎
3.1 什么是规则
3.2 推理引擎原理
3.3 Rete算法
3.4 规则引擎优势
3.5 规则引擎使用场景
3.6 规则引擎的分类
四、商机流转问题解决方案
4.1 Drools和easyRule对比
4.2 easyRule插件介绍
4.3 easyRule使用样例
4.4 商机流转如何接入easyRule
4.5 商机解绑流程举例
4.6 引入规则引擎前后效果对比
五、总结
商业CRM系统的商机模块业务复杂、场景繁多、规则调整频繁,商机流转效率一定程度决定了销售开单的效率。如何高效配合产品侧完成业务规则调整,商机流转经历了硬编码到半配置化的优化升级,过程中遇到了一些问题,也总结了一些经验,今天来和大家掰开揉碎了讲一讲这其中遇到的问题和解决方案。
先看一下CRM的官方定义:
CRM(Customer Relationship Management
):客户关系管理,是指企业为提高核心竞争力,利用相应的信息技术以及互联网技术协调企业与顾客间在销售、营销和服务上的交互,从而提升其管理效率,向客户提供创新式的个性化的客户交互和服务的过程。
其最终目标是:吸引新客户、保留老客户以及将已有客户转为忠实客户,增加市场。
可以这么简单的理解,CRM
的核心价值就是:将潜在客户更高效的转化为客户,将客户更高效的转化为长期客户。
介绍完什么是CRM
,那CRM
系统就很容易理解了,用于支撑企业进行客户关系管理的系统,就可以称作CRM
系统。这个定义比较宽泛,每个公司对CRM
中功能边界也不完全一样,大家初步理解这个概念就行。比如转转商业CRM
系统,主要包含:商机管理、客户管理、销售/运营人员管理、业绩管理、效率监控等功能模块。
要想把潜在客户变成客户,就需要销售人员进行跟进,对潜在客户进行产品的售卖,用户购买产品后,变成客户。这个潜在客户,我们称作“商机”,也就是一次成单的机会,有的CRM系统中,也称为“线索”。上图是潜在用户到客户简单的流转图
从商机生成到最终成单,销售跟进过程中,涉及一些概念,比如商机池(公海池、私海池)、商机状态/来源/类型/等级、商机的流转等。
商机池:各种商机的集合。
公海池:该集合里的商机当前不归属于任何销售,所有销售均可以看到公海里的商机。
私海池:绑定了特定销售的商机集合,比如销售A的商机私海池,只有销售A可以看到和跟进,其他销售不可见、不可跟进。
商机流转:商机在跟进过程中,被不同的销售跟进,状态发生不同的变化。
流转规则:流转过程中会有各种各样的业务规则限制,比如销售最多可以认领100条商机、负责手机类目的销售不能认领电脑类目的商机、销售刚放弃的商机不能立马重新认领、单位时间内不进行电话沟通的商机将流出销售私海等等。
这里举一个例子来说明商机的流转,业务背景:商机对应用户主营类目为手机,销售A、B负责手机类目,销售C负责电脑类目,销售D也负责手机类目。这是一个简单的流程,实际流程比这个复杂。从这个简易的流程介绍中,可以窥见部分商机流转模块的业务特点,总结起来有三点:
状态的多样性
状态间转换场景繁多
流转规则复杂多变
之前商业CRM
中关于流转的处理逻辑,好多都是硬编码,举个销售认领某条商机的例子:
//状态校验
if(checkClueStatus(param)){
return “状态不合法”;
}
//绑定人校验
if(checkClueBindUser(param)){
return “上一个绑定人不可以为···”;
}
//私海容量校验
if(checkPrivateClueCount(param)){
return “私海库已满,无法操作··”;
}
//类目校验
if(checkClueCate(param)){
return “类目不匹配,无法操作··”;
}
//任务是否完成校验
if(checkClueTaskFinished(param)){
return “任务未完成,无法操作··”;
} ······
bind(param);//绑定操作
log();//日志记录操作
从代码中可以看出,销售从公海进行认领一条自己觉得有价值的商机时,并不是直接就让该商机流入到该销售私海中,这个过程会有各种规则的业务校验。
带着我们的痛点和诉求,接下来看看可以找到什么样的解决方案。然后我们进入了调研阶段,发现对于这种策略比较密集的业务,规则引擎是一个可参考方向,然后就开始了解规则引擎相关细节,了解完后,发现和业务问题匹配度很高。接下来,先介绍一下规则引擎相关的基本知识。
规则就是:条件 --> 推理 --> 结果。一个完整的规则是需要这三部分元素的,平时大家讨论规则,某些时候只是在讨论第一部分的条件,比如学校的行为规范,咱们国家的各种法律条文,可能关注的部分是需要满足什么条件(不能做什么什么),后面的推理和结果省去了。比如学生准则里的不辱骂同学,这是一个条件,那怎么算辱骂呢,这是推理过程,辱骂后会发生什么呢,会受到老师批评,这是结果。
那什么是推理引擎和规则引擎呢?
推理引擎通过决定哪些规则满足事实或目标,并授予规则优先级,满足事实或目标的规则被加入议程,具体过程:
fact
)输入至工作内存(Working Memory
)。Pattern Matcher
将规则库(Rules repository
)的规则(rule
)和数据(fact
)比较。conflict
),即同时激活了多个规则,将冲突的规则放入冲突集合。Agenda
。Agenda
中的规则。Agenda
中的所有规则。推理方式分为正向推理和反向推理
常见的模式匹配算法有Rete
,LFA
,TREAI
,LEAPS
。Rete算法是目前效率最高的一个演绎法推理算法,许多规则引擎都是基于Rete
算法来进行推理计算的。
Rete
在拉丁语中是“net”,有网络的意思。Rete
算法由Carnegie Mellon University
的Dr Charles L. Forgy设计发明,是一个用来实现产生式规则系统(production/inference
)的高效模式匹配算法。RETE
算法可以分为两部分:规则编译(rule compilation
)和运行时执行(runtime execution
)。fact
):对象之间及对象属性之间的关系rule
):是由条件和结论构成的推理语句,一般表示为if…Then
。一个规则的if部分称为LHS
(left-hand-side
),then部分称为RHS
(right hand side
)。module
):就是指IF语句的条件。这里IF条件可能是有几个更小的条件组成的大条件。模式就是指的不能在继续分割下去的最小的原子条件。这是Rete算法的原理图,Rete算法涉及两种网络和6种不同作用的节点。
Type Node
、Select Node
、Join Node
、Teminal Node
、Alpha Memory
、Beta Memory
working memory
,找出符合规则中每一个模式的集合,生成alpha memory
(满足该模式的集合)。Beta Memory
和Join Node
。前者主要存储Join
完成后的集合。后者包含两个输入口,分别输入需要匹配的两个集合,由Join
节点做合并工作传输给下一个节点。root
节点(根节点),推理网络的入口。Alpha
节点是否存在,如果存在记录下节点的位置;如果没有,将模式1作为一个Alpha
节点加入到网络中。同时根据Alpha
节点建立Alpah
内存表。Beta
节点:Beta
(2)左输入节点为Alpha
(1),右输入节点为Alpha
(2);Beta
(i)左输入节点是Beta
(i-1),右输入节点为Alpha
(i),并将两个父节点的内存表内联成为自己的内存表。Beta
节点处理完毕。Beta
(n)。facts
集合中。facts
不为空,选择一个fact
进行处理。否则停止匹配过程。alpha
网的第一个节点运行(建立网络的时候设定的),通过该节点则进入alpha
网的下一个节点,直到进入alpha memory
。否则跳转到下一条判断路径。beta memory
中,如果不为Terminal
节点,则检测另一个输入集合中是否存在满足条件的事实,满足则执行join
,进入到下一个beta memory
重复执行3。若另一个输入集合无满足条件的事实,返回到2。如果该节点为Terminal
节点,执行ACT并添加到facts
中。上面介绍的这些都偏理论化,可能有一点不太容易理解,没关系,接下来咱们用一个具体的例子,看看Rete
算法到底是如何运行的。咱们依然以这个选拔篮球苗子的例子来说明。
StudentFact
的年级数值进行年级匹配,如果年级符合条件,则把该StudentFact
的引用记录到A节点的alpha
内存区中,退出年级匹配。StudentFact
的性别内容进行性别匹配,如果性别符合条件,则把该StudentFact
的引用记录到B节点的alpha
内存区中,然后找到B节点左引用的Beta
节点,也就是C节点。alpha
内存区中是否存放了StudentFact
的引用,如果存放,说明年级和性别两个条件都符合,则在C节点的Beta
内存区中存放StudentFact
的引用,退出性别匹配。StudentFact
的年龄数值进行年龄条件匹配,如果年龄符合条件,则把该StudentFact
的引用记录到D节点的alpha
的内存区中,然后找到D节点的左引用的Beta
节点,也就是E节点。Beta
内存区中是否存放了StudentFact
的引用,如果存放,说明年级,性别,年龄三个条件符合,则在E节点的Beta
内存区中存放StudentFact
的引用,退出年龄匹配。StudentFact
的身体数值进行身体条件匹配,如果身体条件符合,则把该StudentFact
的引用记录到D节点的alpha
的内存区中,然后找到F节点的左引用的Beta
节点,也就是G节点。Beta
内存区中是否存放了StudentFact
的引用,如果存放,说明年级,性别,年龄,身体四个条件符合,则在G节点的Beta
内存区中存放StudentFact
的引用,退出身体匹配。StudentFact
的身高数值进行身高条件匹配,如果身高条件符合,则把该StudentFact
的引用记录到H节点的alpha
的内存区中,然后找到H节点的左引用的Beta
节点,也就是I节点。Beta
内存区中是否存放了StudentFact
的引用,如果存放了,说明年级,性别,年龄,身体,身高五个条件都符合,则在I节点的Beta
内存区中存放StudentFact
引用。同时说明该StudentFact
对象匹配了该规则,形成一个议程,加入到冲突区,执行该条件的结果部分:该学生是一个篮球苗子。node
和memory
,提高效率;memory
存储中间结果,空间换时间,避免重复计算;Rete
匹配速度与规则数目无直接关系,因为fact
只有满足本节点才会继续向下沿网络传递。规则的条件与facts
的数目如果过大,对应memory
会指数级升高,极端情况下会耗尽系统资源。
Rete
算法内存开销大和facts
增加删除影响效率的问题,技术上应该在 AlphaMemory
和 BetaMemory
中,只存储指向内存的指针,并对指针建里索引(可用 hash 表或者非平衡二叉树)。Rete
算法 JoinNode
可以扩展为 AndJoinNode
和 OrJoinNode
,两种节点可以再进行组合。看完这个匹配的过程,相信大家对规则引擎中常用的Rete算法有了一定的了解。回到规则引擎,那为啥用规则引擎呢,也就是它有何优势,以及有哪些适用的场景呢?
一般多用于规则较多且规则调整频繁的业务场景,比如:积分规则、计费系统、信用风险评估、监控告警、工作流系统。
网上有两种分类方式,这里我列举出来,供大家了解。
了解了上面这些业务背景以及遇到的问题,也熟悉了规则引擎的理论知识,现在需要制定具体的解决方案了,我们怎么做的呢?市面有各种各样的规则引擎,先进行技术选型,这里列举下当前主流规则引擎优缺点。通过各方面综合评估,重点放到了Drools
和easyRule
两者,且easyRule
最终胜出。
确定了要使用easyRule
就得知道easyRule
如何使用的,先介绍下其相关概念和使用方法。
name
:规则命名空间中的唯一规则名称description
:规则的简要描述priority
:规则的优先级facts
:触发规则时的一组已知事实conditions
:在给定一些事实的情况下,为了应用该规则,需要满足的一组条件actions
:满足条件时要执行的一组操作(可能会添加/删除/修改事实)POJO
上添加注解来声明RuleBuilder API
编程Easy Rules
提供了3种CompositeRule
的实现。
UnitRuleGroup
:要么应用所有规则,要么不应用任何规则。--要么全用要么不用ActivationRuleGroup
:激活规则组触发第一个适用规则并忽略组中的其他规则。--首个选用ConditionalRuleGroup
:条件规则组将具有最高优先级的规则作为条件,如果具有最高优先级的规则的计算结果为true,那么将触发其余的规则。--优先级最高说了算值越低优先级越高。要覆盖此行为,可重写compareTo()
方法以提供自定义优先级策略。
skipOnFirstAppliedRule
:当一个规则成功应用时,跳过余下的规则。--一个成功,不管其他skipOnFirstFailedRule
:当一个规则失败时,跳过余下的规则。--一个失败,不管其他skipOnFirstNonTriggeredRule
:当一个规则未触发时,跳过余下的规则。--一个不符合,不管其他rulePriorityThreshold
:当优先级超过指定的阈值时,跳过余下的规则。--优先级达标,不管其他支持自定义规则监听器、规则引擎监听器。
支持MVEL
、SPEL
表达式语言,可通过编程方式定义规则。
还是用筛选篮球苗子的例子
public class Student {
/**
* 年级
*/
private Integer grade;
/**
* 性别
*/
private String gender;
/**
* 年龄
*/
private Integer age;
/**
* 是否强壮
*/
private Boolean isStrong;
/**
* 身高
*/
private Integer height;
/**
* 是否一个好苗子
*/
private Boolean isGoodSeed = true;
}
//创建规则1-年级
Rule rule1 = new MVELRule()
.name("grade rule")
.description("判断一个学生是否是一个篮球好苗子-年级")
.priority(1)
.when("student.getGrade() <= 3")
.then("System.out.println(\"年级-不是好苗子\");")
.then("student.setIsGoodSeed(false);");
//创建规则2-性别
Rule rule2 = new MVELRuleFactory(new YamlRuleDefinitionReader()).
createRule(new FileReader(
ResourceUtils.getFile("classpath:gender-rule.yml")));
规则2需要的yml文件内容如下:
name: "gender rule"
description: "判断一个学生是否是一个篮球好苗子-性别"
priority: 2
condition: "student.getGender().equals(\"girl\")"
actions:
- "System.out.println(\"性别-不是好苗子\");student.setIsGoodSeed(false);"
//创建规则3-年龄
Rule rule3 = new MVELRuleFactory(new JsonRuleDefinitionReader()).
createRule(new FileReader(
ResourceUtils.getFile("classpath:age-rule.json")));
//创建规则4-是否强壮
Condition condition = new MVELCondition("!student.getIsStrong()");
Action action = new Action() {
@Override
public void execute(Facts facts) throws Exception {
Student student1 = (Student) facts.get("student");
student1.setIsGoodSeed(false);
System.out.println("强壮-不是好苗子");
}
};
Rule rule4 = new RuleBuilder()
.name("strong rule")
.description("判断一个学生是否是一个篮球好苗子-是否强壮")
.priority(4)
.when(condition)
.then(action).build();
@Rule(name = "height rule" ,description = "判断一个学生是否是一个篮球好苗子-身高")
public class HeightRule {
@Condition
public boolean checkHeight(){ return student.getHeight() <= 170;}
@Action
public void action(){
System.out.println("身高-不是好苗子");
student.setIsGoodSeed(false);
}
private Student student;
public HeightRule(Student student){
this.student = student;
}
}
//创建规则5-身高
HeightRule rule5 = new HeightRule(student);
//创建一个Student实例(Fact)
Student student = new Student(3,"girl",9,true, 160,true);
Facts facts = new Facts();
facts.put("student", student);
//注册规则
Rules rules = new Rules();
rules.register(rule1);
rules.register(rule2);
//rules.register(rule3);
rules.register(rule4);
rules.register(rule5);
//创建规则执行引擎,并执行规则
RulesEngine rulesEngine = new DefaultRulesEngine();
System.out.println("开始判断是否是一个篮球苗子:" + JSON.toJSONString(student));
rulesEngine.fire(rules, facts);
System.out.println("是否为好苗子:" + student.getIsGoodSeed());
熟悉了easyRule
如何使用的,接下来看看我们如何在项目中落地的,我们分了几步:
easyRule
工具包进行二次改装,使其执行规则后能有返回值,封装成jar包,将规则引擎抽取成通用能力。public T fire(String ruleId, V v)
通用的规则引擎api接口。这里我们将规则引擎的处理结果进行了返回,因为业务上很多场景需要,比如不符合规则时的提醒文案。easyRule
工具。RuleEngineTemplate
类;context
;ruleEngineTemplate.fire(ruleId,context)
方法。引入后,我们的商机流转流程发生了如下变化:
spring:
easy-rule:
priority-threshold: 100
skip-on-first-failed-rule: false
skip-on-first-applied-rule: true
skip-on-first-non-triggered-rule: false
rules:
- rule-id: "opportunity_unbind"
rule-file-location: "opportunity_unbind" #规则配置文件
rule-config-type: JSON
rule-factory-type: SPEL
具体的规则配置json
[
{
"name": "bind_check_cate",
"description": "判断是否冻结-72小时",
"condition": "@opportunityUnbindRuleBll.checkOpportunityNeedFreeze(#context.getOpportunityId(), n,m)",
"priority": 4,
"actions": [
"@clueOpporBll.unbindOpportunity(#context,T(OpportunityStatusEnum).UNBIND, T(com.clue.enums.OpportunityMinorStatusEnum).UNBIND_FROZEN)"
]
},
{
"name": "task_bind_out",
"description": "任务商机流回公海",
"condition": "#context.getOpportunityStatus() == T(com.enums.OpportunityStatusEnum).TASK && #context.getOperationTypeEnum() == T(com.OpportunityOperationTypeEnum).TASK_BACK_PUBLIC",
"priority": 5,
"actions": [
"@clueBll.unbindOpportunity(#context,T(com.zhuanzhuan.biz.clue.enums.OpportunityStatusEnum).UNBIND, T(com.OpportunityMinorStatusEnum).UNBIND_NORMAL)"
]
},
{
"name": "unbind_operate",
"description": "判断解绑后去向,现阶段全部回到公海",
"condition": "true",
"priority": 10,
"actions": [
"@clueOpportunityBll.unbindOpportunity(#context,T(com.OpportunityStatusEnum).UNBIND, T(com.enums.OpportunityMinorStatusEnum).UNBIND_NORMAL)"
]
}
]
}
]
public Result<ParallelExecuteDTO> unbindOpportunity(UnbindOpportunityRequest request) {
return parallelExecutor.parallelExecute(request.getOpportunityIds(), (Long opportunityId) -> {
final Result<String> unbindResult = opportunityUnbindRuleBll.unbindOpportunity(opportunityId, request.getOperator(),
request.getReasonType(), request.getReasonDesc(), request.getOperationType());
logger.info("method=unbindOpportunity, act=unbind, opportunityId={},unbindResult={}", opportunityId, unbindResult);
return unbindResult;
}
);
}
在easyRule
引入商机流转业务过程中,从调研到选型再到最终落地,遇到了各种大大小小的问题,但最终的效果还是比较明显的,对团队的整体效率提升非常明显,这里有几点总结与建议与大家分享。
作者介绍
杨迎,转转商业后端开发工程师,目前负责商业B端相关业务系统开发(商机线索、客户运营、销售运营管理、广告发布等)。
想了解更多转转公司的业务实践,欢迎点击关注下方公众号: