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

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

文章插图
4. 订单的多重绩效判定整个类图中，应该是下面这里看起来绕一些了，先后展示了多种订单的类，这里的作用其实是要设计一种完整的判定机制。
在一个未来要迭代成自动化营销和销售的CRM方案里，销售并不是成单唯一的因素，未来肯定还会有其他成单的归因点，此处要做到系统上有预留准备。
销售的成单是从订单系统的基础订单上同步的，在成单时通过关联查询成单手机号&跟进记录&跟进时刻&销售坐席来判定是销售成单，可视为销售归因的成单。这是第一层。
在第二层，及时判定为销售成单了，但这个成单的钱不一定会算到销售的绩效里，这个比较好理解，举个不恰当的例子，一个卖鸭梨的档口，在结算的时候突然出现了猪肉，这就是不合业务规范的。
所以就会有这层限制，不过也看业务的管理理念，如果放开，不配置即可，如果收紧，再开启就好，灵活性很高。此处的功能点也和研发评估过，成本很低，为了防止业务的不确定性，这算是一个很好的兜底。

文章插图
以上，就是我设计的CRM销售域的系统结构，这里还有很多细节，比如和大数据的打通，和人力系统的打通等等，以及具体页面设计，更上层的数据营销方法论，有很多内容可以分享的，只不过想分享的实在点，就需要拿结果验证这个方法可行，不过涉及到业务数据，内容略敏感，就没写，还请见谅~
看到这里，也希望对你有帮助，如果有其他问题，欢迎私信。
接下来，就来讲解下系统的实施。
五、系统的实施经过紧张的研发和测试之后，就涉及到系统上线后的实施工作了。对于一个B端的系统，在事后总结经验，实施阶段要做如下方面的准备。
1. 系统准备

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

2. 业务准备1）是否有实施的核心决策人？如果有的话最好是BOSS，如果BOSS躲在后面，又没有业务的人上前，只能说难度会很大。考验组织，也考验决策者。
2）是否有业务侧的实施指挥与培训人员，在实施遇到问题后及时跟进反馈。
3）是否有试点小组？可以尽量让业务的冲击降到最小。
4）提前准备新系统的配置方案。
5）提前准备新系统的申请相关机制，做到有序处理。
3. 产研侧准备

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

六、写到最后对于B端的业务而言，新产品的开发，决策者多少带些试试看的心理因素。
一方面想突破困局，另一方面也想避免风险，这个是非常合理的考量。能做的，就是保持信心，时刻权衡改革的初心还有现实的困难，如果确定无法承担，就及时止损，如果发现有明显的优势，就要继续坚持，哪怕反对的呼声很高也是暂时的，只要体现在了业绩上，大家就都没话说了。
感谢各位朋友的阅读，CRM的系统结构与实施工作的内容就告一段落，后面会针对本文提到的《业务属性的标记》《基于RBAC的权限体系设计》再出两篇文章。
大家如果有相关的想法，或者有问题，欢迎评论区留言交流，平时工作较忙，我会集中回复。