编辑导语：在掌握基本资料、对客户需求等方面有了较为深刻的认知后，此时，SaaS产品设计人员就应当输出相应的设计方案，推动后续的工作进展。那么要如何进行整体架构设计？本文作者便结合相关案例做了总结，一起来看一下。
在上一篇《SaaS从0到1，案例实操系列（二）》中我们讲到，SaaS产品经理小张经过一周的调研，已经对客户的相关业务和系统有了较为全面、深入的认识。接下来，小张需要制定产品方案，并形成原型设计，以便UI和开发同学能够正式开展工作。
小张决定首先制作“整体方案”，他主要基于以下两方面的考虑：
- 对于产品经理来说，整体方案是详细方案的基础；
- 对于客户和其他同事来说，整体方案能帮助尽早发现整体架构层面的问题。
小张认为，整体方案应该包含以下几个部分：
1）方案概要
说明由于产品的目标客户明确，且有合同约束，因此方案概要说明主要是对客户痛点进行简单阐述，并说明产品方案如何解决客户最关注的问题。
2）整体方案流程图
通过整体方案流程图，客户可以“鸟瞰”整个产品方案，从而确认流程不存在错漏。
3）应用架构设计
应用架构设计可以明确产品包含的模块，以及模块之间的关系。有利于产品经理和研发同学分工，也有利于和客户对产品功能范围初步达成一致。
4）多组织架构设计
由于客户是年销售额高达百亿的集团型企业，对于数据权限管理，以及分公司之间、部门之间和经销商之间的数据安全性有着很高的要求，因此有必要对多组织架构进行单独设计和确认。
一、方案概要说明由于产品已经有明确的客户，小张在“方案概要说明”重点阐述了客户的主要诉求，并且说明了我们将如何满足客户诉求。以下为重点内容节选：
1. 客户主要诉求
XX企业为快消品行业知名品牌商，主要采取了以下分销模式：
1）传统批发模式：【具体说明略】。
2）KA直销模式：【具体说明略】。
3）深度分销模式：【具体说明略】。
在本次项目中，客户期望对以上三种模式的分销业务进行管理，并重点解决销售人员外勤作业效率问题，以及销售过程管理问题，主要包括：
1）销售人员拜访计划自动生成
给销售人员分配相应的拜访路线、拜访日期，并结合拜访频率等信息，自动生成合理的每日拜访计划。
【其他具体说明略】。
2. 重点方案说明
本次项目将提供商品管理、价格和促销管理、门店管理、经销商管理、销售人员管理、拜访管理、采购订单管理、销售订单管理、物流管理等模块，全面满足客户的各项诉求。
其中，拜访管理将支持拜访路线管理，并支持将路线分配给具体的销售人员。客户信息将支持拜访频率管理，可以根据所在商圈、客户等级等信息，给不同客户自动分配合理的拜访频率。最终，结合销售人员的考勤安排等，系统将自动生成销售人员每日拜访计划，并支持管理人员调整。
【其他具体说明略】。
二、整体方案流程图对于小张来说，整体方案流程图除了确认整体方案的逻辑与范围无误，也是和其他同事沟通和分工的重要基础。毕竟，产品经理最重要的工作之一，就是帮助团队其他成员准确无误的理解整个方案。
整体方案（1）：深度分销
由于项目涉及业务较为复杂，整体方案流程图分为了多个流程图，以上是“深度分销”模式下的整体流程图。整体流程图说明：
通过整体流程图，我们能够看到整个方案涵盖了从采购、库存到拜访和销售的整个核心业务，而且，使用系统的用户，除了厂商-分公司销售部的员工，还有经销商的员工。
另外，根据流程图：小张团队的产品需要与客户Oracle系统打通。这样，负责采购模块的产品经理以及开发团队，就可以提前讨论对接方案。
三、应用架构设计整体方案流程图更多是从业务视角来表述整体方案，但是小张还需要从研发视角来表述整体方案，这样，大家才知道到底要改造哪些模块，要新研发哪些模块。
应用架构设计（示例）
由于公司已经有一套针对快消品行业的分销SaaS系统，小张需要考虑哪些模块应该复用，哪些模块需要全新开发。
本着“能复用就复用，不能复用就新开发”的思路，小张分析了模块复用的优劣势。
1. 复用的优势
- 可以充分利用原有资产，后续迭代也减少重复开发；
- 由于共用一套表结构，未来“面对经销商的SaaS系统”与“面对厂商的SaaS系统”如果打通，那么打通的难度将大大降低。
2. 复用的劣势
1）由于一个功能需要满足更多不同类型客户的需求，产品设计难度大大增加
2）不同类型客户对功能有不同期望，多方兼顾的产品设计，可能影响用户体验
基于以上考虑，小张决定对“基础模块”尽量复用。
首先这些模块都是低频操作，用户体验问题相对不严重，产品设计难度也相对没那么大。其次，考虑到未来如果两个SaaS系统打通，共用基础数据模块肯定能大大降低打通的难度。
不过，由于原有SaaS系统的客户主要是经销商，并不需要单独的“促销管理”和“商圈管理”模块，因此新的SaaS系统将新增这两个模块。
而“业务模块”和“报表模块”都是高频操作，客户对用户体验要求很高，如果复用以前模块，很可能影响客户工作，导致客户投诉。而且由于“原有SaaS系统的目标客户群体”的业务和“新SaaS系统的目标客户群体”的业务差异很大，即便不考虑用户体验，整个产品设计的难度也将大大增加。
因此，小张计划开发新的“业务模块”和“报表模块”。
而原有SaaS系统暂时不需要“集成模块”，因此本次也将全新开发。
四、多组织架构设计由于业务规模大、组织架构和数据权限较为复杂，客户很担心小张设计的系统能否满足数据安全性方面的要求。
小张也明白，对于针对大型企业的SaaS产品，多组织架构是几乎所有功能的基础，一旦设计出现疏漏，后期改造的代价就会很大。
慎重思考后，小张决定把组织分为三类。
1. 总部组织
比如总部销售管理部、IT部。这一类组织并不涉及实际的业务管理，但是他们需要全局权限。
2. 内部业务组织
比如上海分公司。这一类组织负责具体的业务，并且他们拥有自身组织的数据权限。比如销售部同事需要查看到所有归属于上海分公司的销售订单数据，物流部同事需要查看到所有归属于上海分公司的待发货和已发货数据。
3. 外部业务组织
比如上海分公司负责某商圈配送的经销商。这一类组织负责具体的业务，他们也拥有自身组织的数据权限。比如A经销商负责A商圈，那么A商圈的门店信息、订单信息和物流信息等，A经销商都需要查看。
外部业务组织比较特别的地方在于，归属于外部业务组织的账号，将被判定为外部账号，只能申请或分配特定功能，比如“经销商-采购申请”功能等。同时，外部业务组织必须挂靠在内部业务组织下面，并且该内部业务组织将共享他的所有数据权限。
小张决定，抽象出“利润中心”的概念，所有的门店、价目表、经销商和销售订单等数据，都必须归属于一个“利润中心”。
这样，如果某个员工被分配了某个“利润中心”，他就拥有了归属于该“利润中心”的所有门店、价目表、经销商和销售订单等数据的权限。
再结合功能权限，比如物流部员工只分配物流相关功能，这样，他们虽然有完整的数据权限，但是仍然看不到价目表等非物流信息。
当然，考虑到一个人可能会被分配多个“角色”。比如上海分公司的物流部员工张三，暂代了成都分公司的物流部经理。可以把“利润中心”先分配给“角色”，再把多个“角色”分配给员工，如此，就能实现最复杂的数据权限需求。逻辑示意图如下：
黄色方块实际上起到了桥梁的作用，最终目的是将右边的“业务数据权限”，正确分配给左边的“员工”账号。
关于多组织架构，大家也可以阅读我的原创《B端大PM必备：多组织架构设计》。
五、后记完成整体方案后，小张首先组织团队的产品经理和核心研发人员进行了讨论，大家达成一致后，小张约了客户的项目负责人，将整体方案和客户进行了沟通确认。
小张明白，应该抓住一切机会多和客户沟通。一方面，产品经理需要通过沟通去发现问题；另一方面，客户也需要通过产品经理的引导，对产品方案能否支撑业务，以及是否满足项目期望进行确认。
本篇完。下一篇，我们接着讲SaaS产品的详细方案如何编制。
#专栏作家#
王戴明，微信公众号：To B老人家，人人都是产品经理专栏作家，多年互联网产品与信息化管理经验。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
,
