2023年CRM系列02：销售域的系统设计与实施（附UML建模内容）

CRM系列02：销售域的系统设计与实施（附UML建模内容）在系统现状调研、代码规律梳理、业务调研、老板意向调研等一系列“软性工作”告一段落后，最终可以开启产品设计这个“硬性工作”了，想想都觉得难，带着镣铐跳舞，哈哈。

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

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

《用户体验要素》的“战范构架表”五层要素框架；用户故事地图；UML，还记得最初的那篇UML文章吗？-产品经理的思索利器——UML（7000字长文）。一、工具1：用户体验五要素

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

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

又强调了两个点让我受益匪浅：

自下而上的建设；让每一层的工作在下一层结束之前完成。关于第（2）点，是我在踩了坑之后才发觉的，之前读书的时候始终没理解，也就是下图中下方的波浪图。

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

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

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

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

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

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

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

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

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

三、工具3：UML工具

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

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

假如没有UML，可能沟通与争论就要花费更多的时间。下图就是CRM系统设计中我整理的整套架构规律，已经脱敏（有点干）。

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

四、系统结构讲解

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

1.名片商机

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

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

这个规律下，就意味着一个名片可以有多个商机，便于销售跟进。

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

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

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

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

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

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

针对这个问题，大家可以在评论区里沟通，我想会有许多新的收获。

2.流转规章

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

流转规章，是依据商机上的业务属性来推断，通过选定不同的属性组合作为特征，把某个特征的商机，分到某个目标的安排组，让安排组内对应的销售进行转化。业务属性举例如下：

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

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

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

Tips：这里也总结出一个系统设计阅历。在设计详细的规律限制时，这个规律限制总可以连续向上抽象成类，然后把抽象的类做胜利能，就能提高系统的可维护性

3.角色权限掌握

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

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

页面权限掌握这个用户能访问到那个页面；

数据权限是此用户能通过查询看到的数据范围，有行权限掌握也有列权限掌握，看详细业务需求。

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

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

4.订单的多重绩效判定

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

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

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

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

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

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

看到这里，也盼望对你有关心，假如有其他问题，欢迎私信。

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

五、系统的实施

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

1.系统预备

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

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

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

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

4）提前预备新系统的配置方案。

5）提前预备新系统的申请相关机制，做到有序处理。

3.产研侧预备

产研在实施当天的现场值班，节假日值班支配；产研侧的应急联系人；实施期间的需求迭代工作节奏，便于快速反馈问题，迭代上线，降低业务心情阻力；运维侧服务器的应急方案，回滚方案。六、写到最终

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

一方面想突破困局，另一方面也想避开风险，这个是特别合理的考量。能做的，就是保持信念，时刻权衡改革的初心还