每周三上午八点半，「星球精选问答」栏目会从「决胜B端」星球中，挑选出几个典型的问题分享给大家。

来看看有没有你遇到过的相似问题吧~

Q：老师 您好~我有个产品架构的问题想请教下：

产品设计时，会把相近的功能设计放一起成为一个模块，区分各个模块 ，各模块间数据接口调用的原则？但我一直都不太明白这么做的底层原因？可能大家都这么做 那我也这么做了…

会有原因说是为了解耦，要高内聚低耦合，我也查了资料，但感觉这是因为技术原因？所以要这么设计的？

举例：tms基础资料模块有维护仓库信息的功能，为了物流统一管理监管和调度，需要在tms中维护自营仓库和厂商仓库的信息，目前wms有仓库管理模块，但wms目前只有配置我们自营仓，像厂商发货wms没有配置一个虚拟的仓库（非实体仓库），有两个产品方案：

1.仓库统一都在wms配置 包括厂商虚拟仓 那么tms同步wms的仓库数据 然后加上物流部门再完善一些仓库资料即可，主信息在wms维护并同步，tms不可修改

2.tms仓库信息自营仓库部分由wms同步过来，厂商仓库在tms的仓库模块创建。两种方案看着都能走通，但开发觉得第二种对他来说不妥，处理的表、逻辑更多 不能实现解耦。

我自己其实不太明白原由。想请教下~

自己对产品架构这块认知少，不太懂，另外想问问老师有没有推荐的书或资料讲产品架构的 想深入学习下

A：首先，产品的模块应该体现业务上的主题性质，一般模块划分依据有以下几种：

1. 基于业务主题或部门（例如电商erp）

2. 基于作业流程（例如wms和his）

3. 基于数据对象（例如sfa crm）

模块在逻辑层面（也就是产品层面）保证隔离清晰，只聚焦自己需要做的事情，模块之间不正交。这样在业务感知上非常清晰，再往技术方案传导实现时，技术上代码、库表都会隔离。带来的好处。

1. 产品逻辑清晰，业务人员不用背错综混乱的菜单搞崩溃

2. 技术方案库表隔离，不会出现a模块上线了一个功能，把毫不相干的b模块干挂。

不过你给的案例，并不是严格的模块划分问题，针对你的案例，实际上本质问题是公司的仓库数据底层应该是一套管理方案，前端应用只是处理数据的皮子his业务模块划分，只要保证仓库的数据底层唯一，无论wms去编辑，还是tms编辑，其实都无所谓了。

学习这块知识，需要时间沉淀积累，《决胜B端》应用架构部分其实就是在讲这些。

Q：杨老师，你好。咨询关于CRM实施和推广问题。

背景：我们是装修公司，客户没有进行归属保护，业务归最终签单人员。有10多个业务部门，各自发展客户，只有新小区有进行业务划分，老小区大家都可以签单。

新上CRM，目前主要用了客户线索导入、新增、分配，App直接拨打电话，客户标签等功能。公海没有用起来。目前存在问题：

1、因为每个业务部门都可以发展老小区客户。出现一个客户会由公司多个业务部门人员跟进，甚至已在公司装修的客户，还会不断收到公司业务员的电话。而且系统里面信息重复较多，要求允许不同业务部门录入相同的客户。怎么减少数据重复，减少对客户的骚扰？

2、CRM的功能应用很少，目前最常用的是App直接拨打电话，记录录音和通话记录。客户接触记录、客户标签业务人员都不想用，觉得增加工作量。公海也没有用。怎么推进CRM更多的应用？

3、业务员为了保护自己的客户信息，经常不录入客户信息，或者录入了电话是假的。确定签单的时候才进行录入。怎么保证数据的准确、及时？希望帮忙提供以上问题的解决思路。

A：1. 系统保证对唯一客户的识别（通过具体家庭住址，线索阶段通过手机号），业务部门必须确定职责，如果不是交叉售卖不同产品，没有必要多个部门同时跟进，这个问题首先必须从销售流程管理开始重新梳理制定规则