CRM系列02:销售域的系统设计与实施(附UML建模内容)

4 评论 4646 浏览 40 收藏 16 分钟

编辑导语:B端业务系统的搭建并不容易。如何设计CRM系统,实现CRM系统的搭建和落地?本篇章里,作者总结了CRM系统销售域的设计与操作流程,不妨来看一下,也许会对你有所启发。

在系统现状调研、代码逻辑梳理、业务调研、老板意向调研等一系列“软性工作”告一段落后,终于可以开启产品设计这个“硬性工作”了,想想都觉得难,带着镣铐跳舞,哈哈。

难归难,这正是产品经理存在的价值。

在CRM销售域的整体设计过程中,我用到了3个工具:

  1. 《用户体验要素》的“战范构架表”五层要素框架;
  2. 用户故事地图;
  3. UML,还记得最初的那篇UML文章吗?->产品经理的思考利器——UML(7000字长文)

一、工具1:用户体验五要素

用户体验要素一书中,定义自上而下存在五层逻辑关系,我翻译成了更符合我语境的内容,依次为:

  • 战略层:可以理解为这个系统的定位和最终目的;
  • 范围层:基于战略层归纳出的功能点和业务流程;
  • 结构层:基于功能点与业务流程,设计出的页面流程;
  • 框架层:每个流程节点上页面的内容布局;
  • 表现层:每个页面上的视觉设计。

CRM02 销售域的系统设计与实施

作者又强调了两个点让我受益匪浅:

  1. 自下而上的建设;
  2. 让每一层的工作在下一层结束之前完成。

关于第(2)点,是我在踩了坑之后才发现的,之前读书的时候一直没理解,也就是下图中下方的波浪图。

CRM02 销售域的系统设计与实施

如果你也没用过或者不理解,我可以举一个例子你就明白了。

比如在范围层的时候你设计了一套销售代下单的流程,步骤A-B-C-D,然后你正常设计了结构层页面的页面间的跳转流程,然后很快你又根据页面流程设计出了页面中的跳转入口相当于从范围层开始,你不间断地干通了结构层,框架层,共3层。

这时候老板突然说在范围层的流程要改(日常操作……),你答应下来以后发现,不光是流程改了,后面结构层的页面跳转逻辑也要改,而紧随其后的框架层的跳转入口,改的就更大了,有的入口没了,有的凭空出现好多内容……

而如果遵循第(2)点的要求,在干完范围层的业务流程图之后,是可以设计结构层的页面流程图的,但是不能继续干了,必须要确认好范围层的流程图都没问题了,再继续干到框架层。

这样看似麻烦,但其实是最省项目时间的做法,如果老板想看最终结果又要从根源否定,就跟老板打好提前量,告知时间上的损耗。否则就会出现大佬们在基础流程上反复横跳,对应的细节涉及了几十个页面,真的吐了。

二、工具2:用户故事地图

在战略层梳理的时候,我用到了用户故事地图,这是一个针对敏捷开发使用的一套描述需求的工具,可以辅助描述更清晰的业务场景,业务需求。

用法也很简单,顶部划分用户历程的大阶段,然后下方细拆,拆到每个业务部门,再拆到部门下的动作和目标,最后在最下方整理出需求点。

这样的方式会很清晰,尤其是在流程很长的时候。图可能看不清,不过没关系,理解就好。

CRM02 销售域的系统设计与实施

三、工具3:UML工具

正如我在UML那篇文章里提到的,UML作用的范围,可以放到范围层和结构层。如下图。

真是一个利器,可以很清晰的梳理清楚思路,而且事后复盘的时候,也发现分配组那里没有单独抽象出来,造成了一些业务困扰,不过很快也都解决了。

如果没有UML,可能沟通与讨论就要花费更多的时间。下图就是CRM系统设计中我整理的整套架构逻辑,已经脱敏(有点干)。

CRM02 销售域的系统设计与实施

上图是用的UML的类图,这里不是流程图,而是类图,代表的是系统里的各个业务概念的关系。

四、系统结构讲解

我们基于上面的类图,逐个讲解各个类代表的意义,考虑到篇幅的限制,我会介绍核心的模块,剩余的模块大家可以看大图。

1. 名片&商机

业务中收集到的客户联系方式,一般为手机号

名片和商机的转化,在我做的CRM业务语境下,名片即为一个单独的手机号,商机是基于名片的手机号再附加一个“业务属性1”来生成的(如下图)。

CRM02 销售域的系统设计与实施

这个逻辑下,就意味着一个名片可以有多个商机,便于销售跟进。

其实这里也暗含一个理念,即客户和商机是独立的,一个客户可有多个商机,有的同学在设计的时候会把商机和客户概念统一,数据也只有一份,造成了浪费。

然后商机也有对应的状态,用来判定是否被销售跟进。

再引申个行业栗子——大家可以讨论。

某电商平台,针对店铺的运营,把店家老板的手机号作为唯一名片标识,然后业务体系中一个老板的手机号会关联多个店铺。此时的商机应该以哪个实体为准?

这个问题属于开放问题了,如果是店铺业务体量都较小,可能以老板粒度为线索更合适,防止不同的销售跟进店铺导致撞单。

但如果是店铺体量很大,小型集团级别,可能就是需要把集团下不同的采购组作为线索了。

针对这个问题,大家可以在评论区里交流,我想会有很多新的收获。

2. 流转规则

因为业务条线多,每个销售适合打的商机种类不同,通过自定义规则的分发,可以让销售更高效的转化。此处的规则积累到一定量级后,可以运用算法来协助,并且逐步替代。

CRM02 销售域的系统设计与实施

流转规则,是根据商机上的业务属性来判断,通过选定不同的属性组合作为特征,把某个特征的商机,分到某个目标的分配组,让分配组内对应的销售进行转化。业务属性举例如下:

CRM02 销售域的系统设计与实施

其实这部分市面上有成熟的方案,叫做“工作流引擎”,甚至可以找到开源代码。

这类工作流引擎也做过调研,灵活度可以满足要求,但是批量管理工作流时会遇到实例结构不统一的问题,而且想做统计的时候,之前已有工作流会在流程结束时把日志清除,等等原因,改动已有的方案需要的成本更高,所以我们决定自研了一套类似引擎的解决方式,更贴合业务现实现状。

此处会涉及到一个问题,即商机上的业务属性如何标记?不要着急,我后面会单独出一篇文章来讲解。

Tips:这里也总结出一个系统设计经验。在设计具体的逻辑限制时,这个逻辑限制总可以继续向上抽象成类,然后把抽象的类做成功能,就能提高系统的可维护性

3. 角色权限控制

此处的角色控制,是基于RBAC理论来设计的,后面也会单独出一篇文章讲解。

RBAC直观解释,就是系统用户的权限,可以拆成两个层面,一个是页面的权限,一个是数据的权限。

页面权限控制这个用户能访问到那个页面;

数据权限是此用户能通过查询看到的数据范围,有行权限控制也有列权限控制,看具体业务需求。

把页面和数据分开,可以很好的提高配置的灵活性。比如销售类角色,必须包含工作台,但是不同的销售,他们每个人看到的销售数据只能限制在他们自己的销售组内,更细化的是只有组长能看到组内的,普通销售只能看到自己的。

通过角色授权,让“销售”的角色页面范围包含工作台。然后每个销售员工在自己的用户下有单独的数据范围选择,这样就实现了最大的灵活程度,最小的配置工作量。

CRM02 销售域的系统设计与实施

4. 订单的多重绩效判定

整个类图中,应该是下面这里看起来绕一些了,先后展示了多种订单的类,这里的作用其实是要设计一种完整的判定机制。

在一个未来要迭代成自动化营销和销售的CRM方案里,销售并不是成单唯一的因素,未来肯定还会有其他成单的归因点,此处要做到系统上有预留准备。

销售的成单是从订单系统的基础订单上同步的,在成单时通过关联查询成单手机号&跟进记录&跟进时刻&销售坐席来判定是销售成单,可视为销售归因的成单。这是第一层。

在第二层,及时判定为销售成单了,但这个成单的钱不一定会算到销售的绩效里,这个比较好理解,举个不恰当的例子,一个卖鸭梨的档口,在结算的时候突然出现了猪肉,这就是不合业务规范的。

所以就会有这层限制,不过也看业务的管理理念,如果放开,不配置即可,如果收紧,再开启就好,灵活性很高。此处的功能点也和研发评估过,成本很低,为了防止业务的不确定性,这算是一个很好的兜底。

CRM02 销售域的系统设计与实施

以上,就是我设计的CRM销售域的系统结构,这里还有很多细节,比如和大数据的打通,和人力系统的打通等等,以及具体页面设计,更上层的数据营销方法论,有很多内容可以分享的,只不过想分享的实在点,就需要拿结果验证这个方法可行,不过涉及到业务数据,内容略敏感,就没写,还请见谅~

看到这里,也希望对你有帮助,如果有其他问题,欢迎私信。

接下来,就来讲解下系统的实施。

五、系统的实施

经过紧张的研发和测试之后,就涉及到系统上线后的实施工作了。对于一个B端的系统,在事后总结经验,实施阶段要做如下方面的准备。

1. 系统准备

  1. 数据库环境的打通兼容;
  2. 回滚方案的准备;
  3. 业务新老数据的切割。

2. 业务准备

1)是否有实施的核心决策人?如果有的话最好是BOSS,如果BOSS躲在后面,又没有业务的人上前,只能说难度会很大。考验组织,也考验决策者。

2)是否有业务侧的实施指挥与培训人员,在实施遇到问题后及时跟进反馈。

3)是否有试点小组?可以尽量让业务的冲击降到最小。

4)提前准备新系统的配置方案。

5)提前准备新系统的申请相关机制,做到有序处理。

3. 产研侧准备

  1. 产研在实施当天的现场值班,节假日值班安排;
  2. 产研侧的应急联系人;
  3. 实施期间的需求迭代工作节奏,便于快速反馈问题,迭代上线,降低业务情绪阻力;
  4. 运维侧服务器的应急方案,回滚方案。

六、写到最后

对于B端的业务而言,新产品的开发,决策者多少带些试试看的心理因素。

一方面想突破困局,另一方面也想避免风险,这个是非常合理的考量。能做的,就是保持信心,时刻权衡改革的初心还有现实的困难,如果确定无法承担,就及时止损,如果发现有明显的优势,就要继续坚持,哪怕反对的呼声很高也是暂时的,只要体现在了业绩上,大家就都没话说了。

感谢各位朋友的阅读,CRM的系统结构与实施工作的内容就告一段落,后面会针对本文提到的《业务属性的标记》《基于RBAC的权限体系设计》再出两篇文章。

大家如果有相关的想法,或者有问题,欢迎评论区留言交流,平时工作较忙,我会集中回复。

 

作者:罗文正雄;公众号:罗文正雄

本文由 @罗文正雄 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Pexels,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 客户?是不是,只能成单之后才能叫客户?

    回复
  2. 老师 留个微X呗,想跟你交流

    回复
    1. teshutieqiu1600
      另外我也在建群,欢迎交流哈!有碰撞才有成长

      回复
  3. 刚发现这个文章和微信公众号的原文章略被小编删减,读起来承接性不是很强,不过主体内容不影响。

    回复