流程图|CRM系列02：销售域的系统设计与实施( 二 )_

文章插图
上图是用的UML的类图，这里不是流程图，而是类图，代表的是系统里的各个业务概念的关系。
四、系统结构讲解我们基于上面的类图，逐个讲解各个类代表的意义，考虑到篇幅的限制，我会介绍核心的模块，剩余的模块大家可以看大图。
1. 名片&商机业务中收集到的客户联系方式，一般为手机号
名片和商机的转化，在我做的CRM业务语境下，名片即为一个单独的手机号，商机是基于名片的手机号再附加一个“业务属性1”来生成的（如下图）。

文章插图
这个逻辑下，就意味着一个名片可以有多个商机，便于销售跟进。
其实这里也暗含一个理念，即客户和商机是独立的，一个客户可有多个商机，有的同学在设计的时候会把商机和客户概念统一，数据也只有一份，造成了浪费。
然后商机也有对应的状态，用来判定是否被销售跟进。
再引申个行业栗子——大家可以讨论。
某电商平台，针对店铺的运营，把店家老板的手机号作为唯一名片标识，然后业务体系中一个老板的手机号会关联多个店铺。此时的商机应该以哪个实体为准？
这个问题属于开放问题了，如果是店铺业务体量都较小，可能以老板粒度为线索更合适，防止不同的销售跟进店铺导致撞单。
但如果是店铺体量很大，小型集团级别，可能就是需要把集团下不同的采购组作为线索了。
针对这个问题，大家可以在评论区里交流，我想会有很多新的收获。
2. 流转规则因为业务条线多，每个销售适合打的商机种类不同，通过自定义规则的分发，可以让销售更高效的转化。此处的规则积累到一定量级后，可以运用算法来协助，并且逐步替代。

文章插图
流转规则，是根据商机上的业务属性来判断，通过选定不同的属性组合作为特征，把某个特征的商机，分到某个目标的分配组，让分配组内对应的销售进行转化。业务属性举例如下：
其实这部分市面上有成熟的方案，叫做“工作流引擎”，甚至可以找到开源代码。
这类工作流引擎也做过调研，灵活度可以满足要求，但是批量管理工作流时会遇到实例结构不统一的问题，而且想做统计的时候，之前已有工作流会在流程结束时把日志清除，等等原因，改动已有的方案需要的成本更高，所以我们决定自研了一套类似引擎的解决方式，更贴合业务现实现状。
此处会涉及到一个问题，即商机上的业务属性如何标记？不要着急，我后面会单独出一篇文章来讲解。
Tips：这里也总结出一个系统设计经验。在设计具体的逻辑限制时，这个逻辑限制总可以继续向上抽象成类，然后把抽象的类做成功能，就能提高系统的可维护性
3. 角色权限控制此处的角色控制，是基于RBAC理论来设计的，后面也会单独出一篇文章讲解。
RBAC直观解释，就是系统用户的权限，可以拆成两个层面，一个是页面的权限，一个是数据的权限。
页面权限控制这个用户能访问到那个页面；
数据权限是此用户能通过查询看到的数据范围，有行权限控制也有列权限控制，看具体业务需求。
把页面和数据分开，可以很好的提高配置的灵活性。比如销售类角色，必须包含工作台，但是不同的销售，他们每个人看到的销售数据只能限制在他们自己的销售组内，更细化的是只有组长能看到组内的，普通销售只能看到自己的。