经销商|SaaS从0到1，案例实操系列（三）( 二 )

本着“能复用就复用，不能复用就新开发”的思路，小张分析了模块复用的优劣势。
1. 复用的优势

可以充分利用原有资产，后续迭代也减少重复开发；
由于共用一套表结构，未来“面对经销商的SaaS系统”与“面对厂商的SaaS系统”如果打通，那么打通的难度将大大降低。

2. 复用的劣势1）由于一个功能需要满足更多不同类型客户的需求，产品设计难度大大增加
2）不同类型客户对功能有不同期望，多方兼顾的产品设计，可能影响用户体验
基于以上考虑，小张决定对“基础模块”尽量复用。
首先这些模块都是低频操作，用户体验问题相对不严重，产品设计难度也相对没那么大。其次，考虑到未来如果两个SaaS系统打通，共用基础数据模块肯定能大大降低打通的难度。
不过，由于原有SaaS系统的客户主要是经销商，并不需要单独的“促销管理”和“商圈管理”模块，因此新的SaaS系统将新增这两个模块。
而“业务模块”和“报表模块”都是高频操作，客户对用户体验要求很高，如果复用以前模块，很可能影响客户工作，导致客户投诉。而且由于“原有SaaS系统的目标客户群体”的业务和“新SaaS系统的目标客户群体”的业务差异很大，即便不考虑用户体验，整个产品设计的难度也将大大增加。
因此，小张计划开发新的“业务模块”和“报表模块”。
而原有SaaS系统暂时不需要“集成模块”，因此本次也将全新开发。
四、多组织架构设计由于业务规模大、组织架构和数据权限较为复杂，客户很担心小张设计的系统能否满足数据安全性方面的要求。
小张也明白，对于针对大型企业的SaaS产品，多组织架构是几乎所有功能的基础，一旦设计出现疏漏，后期改造的代价就会很大。
慎重思考后，小张决定把组织分为三类。
1. 总部组织比如总部销售管理部、IT部。这一类组织并不涉及实际的业务管理，但是他们需要全局权限。
2. 内部业务组织比如上海分公司。这一类组织负责具体的业务，并且他们拥有自身组织的数据权限。比如销售部同事需要查看到所有归属于上海分公司的销售订单数据，物流部同事需要查看到所有归属于上海分公司的待发货和已发货数据。
3. 外部业务组织比如上海分公司负责某商圈配送的经销商。这一类组织负责具体的业务，他们也拥有自身组织的数据权限。比如A经销商负责A商圈，那么A商圈的门店信息、订单信息和物流信息等，A经销商都需要查看。
外部业务组织比较特别的地方在于，归属于外部业务组织的账号，将被判定为外部账号，只能申请或分配特定功能，比如“经销商-采购申请”功能等。同时，外部业务组织必须挂靠在内部业务组织下面，并且该内部业务组织将共享他的所有数据权限。
小张决定，抽象出“利润中心”的概念，所有的门店、价目表、经销商和销售订单等数据，都必须归属于一个“利润中心”。
这样，如果某个员工被分配了某个“利润中心”，他就拥有了归属于该“利润中心”的所有门店、价目表、经销商和销售订单等数据的权限。
【 经销商|SaaS从0到1，案例实操系列（三）】再结合功能权限，比如物流部员工只分配物流相关功能，这样，他们虽然有完整的数据权限，但是仍然看不到价目表等非物流信息。
当然，考虑到一个人可能会被分配多个“角色”。比如上海分公司的物流部员工张三，暂代了成都分公司的物流部经理。可以把“利润中心”先分配给“角色”，再把多个“角色”分配给员工，如此，就能实现最复杂的数据权限需求。逻辑示意图如下：

文章插图
黄色方块实际上起到了桥梁的作用，最终目的是将右边的“业务数据权限”，正确分配给左边的“员工”账号。
关于多组织架构，大家也可以阅读我的原创《B端大PM必备：多组织架构设计》。
五、后记完成整体方案后，小张首先组织团队的产品经理和核心研发人员进行了讨论，大家达成一致后，小张约了客户的项目负责人，将整体方案和客户进行了沟通确认。
小张明白，应该抓住一切机会多和客户沟通。一方面，产品经理需要通过沟通去发现问题；另一方面，客户也需要通过产品经理的引导，对产品方案能否支撑业务，以及是否满足项目期望进行确认。
本篇完。下一篇，我们接着讲SaaS产品的详细方案如何编制。