概要设计整体设计(决胜B端：从0到1教你设计业务系统)

本文来源： goYangKun

本文将以一个案例，向读者逐步揭示一套业务系统从0到1的设计过程。重点讲述架构、模型等业务系统最本质的设计精要。

理论知识

业务系统设计概述

1. 什么是业务系统

互联网公司常常根据用户性质将产品分为两大类：C端产品和B端产品。

C端产品主要是面向客户和消费者的系统；B端产品的服务对象是组织机构，给供应商或商家使用的系统、给公司内部业务人员使用的系统，都被称为B端产品。

因为服务对象不同，二者在建设时的出发点和侧重点也完全不同：

C端产品偏重用户体验，强调感性，每个按钮的摆放位置都要精心设计、论证，需要进行持续的数据分析和优化。

B端产品偏重流程化、模块化，强调抽象和结构性，讲究整体的规划和体系设计。

如果将B端产品进一步拆分，又可以分为三类：

第一类是业务平台产品，即为业务部门提供基础服务支持的产品。

第二类是供内部员工使用的办公协同产品，支持企业的经营、管理和业务运转。

第三类是商家端产品，常见于双边模式的平台型互联网公司，例如淘宝的卖家管理系统、美团的商家管理后台。

常见的业务平台产品包括：

• ERP（Enterprise Resource Planning）
• CRM（Customer Relationship Management）
• SCM（Supply Chain Management）
• WMS（Warehouse Management System）
• TMS（Transportation Management System）

常见的办公协同产品包括：

• OA（Office Automation）
• HRM（Human Resource Management）
• ……

因为绝大多数互联网公司的业务模式都有自己的特点，所以很多时候类似CRM、WMS、TMS这类业务平台系统都需要自主研发；而OA、HRM这类协同办公系统会采购标准软件，不过有些互联网巨头也会自主研发OA、HRM。

本文所说业务系统包括B端产品线中的业务平台产品和办公协同产品——因为B端产品都是面向业务（Business）的系统，服务于组织而非个人，所以其设计思想和原理都是相同的，因而本文讲解的内容适用于所有B端系统的设计场景。

当企业发展到一定阶段时，业务系统对企业的高效管理和运转具备不可替代的核心作用。

例如，当一家公司只有几个销售人员时，客户资料用Excel即可管理；当销售人员发展到上千人时，则必须通过一套OCRM系统进行管理。

总体来讲，业务系统对企业具有四点价值：提升管控能力、控制经营风险、降低运营成本、提升销售业绩。

很多时候，业务系统建设的好坏决定了企业的核心竞争力，例如，外卖公司之间的竞争，配送员的效率是业务成败的决定因素之一，而配送员的效率取决于TMS（运输管理系统）建设的好坏，这既包括软件系统本身的质量，也包括配套的管理运营体系的执行情况。

2. 为什么要学习设计业务系统

商业模式的创新是互联网行业最大的特点，商业模式的创新会带来业务模式的创新，业务模式的创新又会带来运营、管理机制的创新。

多数情况下，采取了创新业务模式的互联网公司，无法通过采购成熟的标准软件来支持业务，而作为技术驱动型企业，自主研发系统来支持新业务便成为不二选择。

例如，滴滴公司在成立时，是无法在市面上找到一款成熟的司机管理运营软件的，因此需要自主研发；这时就需要有专业经验的资深产品经理，结合业务，从无到有地设计一套司机（甚至是针对司机运营的机构）管理系统。

再例如，美团需要管理大量的地推人员和客户，传统的OCRM软件根本无法满足美团（美团对地理位置管理有很高要求）的诉求，即便采购成熟的OCRM做定制化开发，难度也比较大。最好的办法是自主研发一套全新的基于独特业务模式的OCRM软件来支持业务。

由此可以看出，互联网企业创新的本质，决定了必须有一批优秀的业务系统设计人员，结合公司特殊业务诉求，快速、合理地设计配套系统，并落地支持业务。

业务系统的产品经理，要具备企业经营管理、软件系统设计的多方面经验和知识储备，才能设计合理的业务系统。

3. 业务系统设计的流程

从无到有地设计业务系统，是有一套标准范式可以遵循的。

一般来讲，一套业务系统从0到1的构建，需要经历如下环节（其中PM代表产品经理，需要从整体上把控业务系统的建设，协调各个相关方，对整个项目负责）：

业务方案设计

PM和业务负责人一起梳理、制定业务流程、制度、机制，理解业务的问题点，并确定软件系统解决方案。

系统整体方案设计

PM结合业务诉求与目标完成系统概要设计，包括明确产品定位（界定业务和系统的边界）、抽象功能模块、设计演进蓝图、设计整体应用架构，明确新系统如何与公司已有系统连接、交互。

系统细节方案设计

PM需要负责细节方案的所有设计工作，包括数据建模、角色梳理、界面设计、权限设计等。

其中数据建模是最难的部分：数据建模的好坏决定了系统未来的灵活性、可扩展性，数据建模要求对业务有全面理解，并且有极强的抽象和归纳能力。

实施验收

PM对项目的最终落地负责，系统上线后要展开持续的迭代优化，深度参与产品运营、数据分析等。

如果是从无到有地设计一套业务系统，以上环节必须全面贯彻，尤其是应用架构设计和数据模型，是重中之重。

案例分析

某电商公司的渠道销售系统设计

本文将结合一个案例，带大家一步步设计一个业务系统，帮助读者理解以上所有的设计环节。

背景

某电商企业M公司，成立5年，主营生鲜商品，以C端客户为主，业务稳定，系统建设成熟。

M公司在三个月前尝试开展分销业务，成立销售团队，开发分销商合作伙伴（通过分销商批量推广和销售商品）；业务试点在北京、上海开展，三个月以来发展迅速，同时，在高速发展中，若干流程、管理、风险问题突显。

评估

经公司管理层评估，目前分销业务月流水50万元，以月增长率20%的速度快速发展。公司决定投入研发资源建设软件系统，支撑业务发展。

任务

公司要求在2~3个月的时间内搭建出一套分销业务平台，支撑分销业务在未来2年的高速发展，提升效率，控制经营风险。项目期间CTO全力提供人力资源支持。

1. 工作计划

作为项目负责人，产品经理在接到任务后，首先要理清工作思路，拆解任务，制订时间计划。只有严格遵循时间计划执行工作，才能保证整体工作有序展开，如期落地。

根据经验和初步判断，我们制订粗略的工作计划表如下：

时间紧，任务重，产品经理需要立即开展行动。

当然，计划表中的研发周期只是一个粗拍的时间，具体实施周期要结合一期项目范围及人力投入，在立项时细化。

2. 业务调研与业务方案

设计系统之前，必须透彻理解业务现状与业务目标，考虑如何结合现有系统改造、优化业务流程和模式。

此阶段可以由一个高级产品经理带领几个初级产品经理来做，最好邀请技术负责人一起参与；这样有利于技术人员提前理解业务，为技术选型和方案设计做好准备，也便于让技术负责人协助产品经理共同完成整体方案设计和细节方案设计——因为有时产品方案设计会受技术方案影响。

2.1 业务调研的方法

业务调研有多种方法，例如轮岗实习、问卷调研、深度访谈等。

其中，轮岗实习是深入理解业务的好方法，但是需要的时间较长；深度访谈是一种更加便捷快速的方法。

访谈之前，最好对业务有大体的认知，安排好访谈的对象，提前准备好问题，让访谈更加高效。

以下是针对分销业务的访谈计划和调研表：

主持人员：产品经理、研发经理

调研对象：业务负责人、一线主管、一线业务人员、合作伙伴（分销业务客户）

调研方式：

深度访谈（访谈大纲如下图），并进行数据分析。

调研目标：

• 了解业务模式和业务特点
• 了解业务目标和业务规划
• 了解当前业务运转方式
• 挖掘当前问题与痛点

业务调研总结

业务调研主要需要梳理清楚以下方面的情况，我们结合案例依此来看。

2.2 组织架构

通过调研，我们首先理清了当下的基本业务组织架构（如下面左图所示），通过组织架构图能够方便地理解管理体系和职能单元的设计。

根据公司的要求，需要提升分销业务的效率，控制经营风险，所以我们计划做出两方面调整：各分公司成立自己的运营部，招聘自己的运营人员，以便对市场做出迅速响应，提升效率；在分销业务部下新增业务支持与风控部，以便控制风险。

规划的组织架构如上面右图所示。

2.3 业务目标

我们梳理了关键业务指标和目标，如下表所示：

2.4 业务流程

通过调研，我们还梳理了目前的业务运作流程，这样才能对实际业务运作有清晰的了解，如下图所示：

可以看出：目前业务开展以手工作业为主，下单配送环节依托于公司已有的系统实现。

3. 问题梳理

基于目前手工作业流程，我们整理出如下业务问题：

• 生鲜实时变价，每次下单要根据折扣表手工计算价格，效率低，易出错。
• 因为缺少完善的客户账号管理体系，所以无法实现客户总部集采、大区集采、城市集采、门店自采等灵活的混合采购模式。
• 因为无法标识特殊客户的特殊订单，所以无法支持特殊分拣、配送要求，例如对某些订单加急配送。
• 无法对账期客户及时控制回款进度和账期风险。
• 对账和开票工作复杂，需要处理大量数据表，容易出错。

当前流程下，一个运营人员只能跟进并维护5个左右的客户，每日只能处理10笔左右的订单，人效极低。

3.1 基于业务调研的核心诉求分析

基于整体调研结果，我们概要性地列出如下解决思路（括号中注明了优先级）：

• 实现客户自主下单（高优）
• 实现系统自动定价（高优）
• 支持客户多门店分别定价与下单（高优）
• 实现对账报表（高优）
• 运营人员聚焦参数设置、审核和异常问题跟进（高优）
• 将运营工作下放到各城市分部（中优）
• 支持账期和预付款模式（低优）
• 系统实现账期风控（低优）

我们将业流程优化确定为高优诉求，将扩展功能或针对部分客户的小众功能，以及风控功能列为低优。

经过探讨，和业务人员达成一致，一期项目聚焦高优诉求的实现。

4. 业务主流程设计

经过和业务人员充分沟通，我们设计出系统支持下的核心业务流程图，如下图所示：

其中，客户开发、合同审核等前置流程，依然通过线下处理完成；而客户签约后的账号管理、价格管理、自主下单等环节，则通过分销系统来支持，以提升效率。

5. 系统整体方案设计

完成业务调研后，进入系统整体方案设计环节。

该环节需要由经验丰富的产品经理以及公司的架构师一起探讨完成，因为方案涉及和公司现有应用架构如何融合的问题，因而还需要经过产品委员会或架构组的评审和确认。

5.1 系统定位

我们对业务进行分析。

首先，分销客户希望能有一个便捷快速下单的工具，所以需要有一个手机版商城C端；考虑到投入产出比，我们决定通过H5来实现，具有独立域名，外网可访问。

其次，需要为分销客户提供一套方便操作的管理后台——因为涉及大量的商品编辑处理，账号、门店管理等功能，所以考虑PC版本实现，暂不支持手机版。

最后，考虑到公司运营人员和分销客户管理员的管理诉求不同，操作功能和页面差异较大，所以决定将管理后台拆解为两个独立的系统：

• 给分销客户管理员使用的客户管理后台，具备独立域名，外网可访问。
• 给公司运营人员使用的运营管理后台，具备独立域名，仅限内网访问。

于是，我们打算将分销系统拆分为三个独立的子系统，来支持分销业务：

• 分销商城前台（移动端，用H5实现）：为分销客户提供下单功能。
• 客户管理后台（PC端）：为分销客户提供子账号管理、门店管理及业务辅助功能。
• 运营管理后台（PC端）：为分销业务部门提供对客户及商品定价管理的业务支持。

设计业务系统常见的问题是：为了省事，把所有业务单元的功能糅合到一个系统中实现，这会造成管理的混乱，尤其是系统维护的混乱。

一般来讲，系统的抽象要结合业务完成，独立的业务职能单元要配合独立的系统来使用；如果业务部门之间边界模糊，权责界定不清，也会导致系统之间存在模糊性。

清晰的系统定位和边界，可以让各个子系统具备足够的独立性，是整个系统具备灵活性和可扩展性的基本前提。

5.2 整体架构设计

现在，需要考虑分销平台的三个子系统如何与公司的整体应用架构融合。

公司经过多年发展，系统架构体系已经非常完备，大量公共组件和模块可以复用，这样就减轻了新平台的实现成本和难度。

分销平台只需要聚焦自己业务特殊独立的地方，其他公共组件和模块复用已有系统的即可。

具体分析如下：

电商业务是公司的主营业务，有成熟的订单体系和仓配系统。

分销业务的独特性在于前置客户（是企业客户）的管理维护，下单后的分拣配送业务流程和之前的业务是一样的，所以分销商城的订单中心直接复用已有订单中心，订单写入后续的处理流程完全不变，只需要订单中心稍作改造即可支持，这样也可以保证整个订单台账、财务、仓储、配送基本都不需要重写或改造。

另外分销平台的商品中心复用已有商品中心SKU数据，只是价格管理模块部分需要新做一套独立的，以支持特殊报价业务。

分销业务的账户体系、权限管理体系、在线支付功能，都可以利用已有系统。其中账户体系需要做改造，以支持子母账号管理；在线支付功能完全复用即可。

客户资料的存储利用已有的客户主数据（MDM）系统实现——因为企业客户资料和个人客户资料的差异较大，所以需要对MDM做较大改造，要新做一套企业客户数据模型。

但是在架构上，必须将客户（包括个人客户和企业客户）资料作为主数据来建设，统一管理维护。

最后一个问题：既然公司已经有C端商城，为什么要单独再做一套针对分销客户的C端商城？

经过分析评估，个人客户和企业客户需要的功能差异，如果对原有商城进行改造来支持分销业务，一方面需要投入的工时可能比新做一套还要多，另一方面会影响主营业务系统的健壮性，因此最终决定为分销业务做一套新的C端商城。

基于上述分析，我们将三个子系统绘入简化版的公司整体应用架构图中，如下：

5.3 功能抽象

基于对业务的分析，以及三套系统的定位，可以抽象并绘制完整的系统功能蓝图。

功能模块图，是对业务诉求系统化设计的进一步高度抽象。模块的设计，要体现出同一个业务职能单元中不同业务场景和操作的集合，模块也代表了系统中的一二级导航菜单的设计。

常见的问题是：设计人员对模块设计的随意和混乱，以及后来新增功能的随意摆放，会造成用户使用系统时产生困惑，同时还会导致开发人员编码设计的混乱。

功能模块图，代表了设计师对业务和系统本质的理解和提炼，包含了对业务、系统未来发展的展望。

我们常说，系统建设要有规划和节奏，实际上功能模块图就是一幅远景规划蓝图；是系统的骨架，决定了系统的整体结构。

结合业务需求，每一个具体功能的实现，都是在对骨架不断地填充血肉，让他更真实，更立体，更丰富。

随着业务的开展，变化，功能模块图可能会有新的规划和调整，但如果业务单元的本质和模式没有变化，功能模块图不应该出现结构性的调整和改动。

5.4 演进蓝图

我们已经绘制了系统的功能模块图，体现了业务和系统规划的脉络；现在，让我们开始研究这套“体系”，大概需要几期实现，每期实现的侧重点是什么，也就是常说的演进蓝图——Roadmap：

白色部分，是一期的项目范围。聚焦解决最基本的业务流程线上化问题，以及最痛的痛点，例如对账功能。

一期功能有一个原则：凡是可以手工处理和解决的问题，都不做系统支持。

所以：

• 类似于“报表”，可以定期跑SQL实现；
• 类似于“价格系数设置”，考虑到维护频率低，可以由RD在后台改数据库完成；
• 类似于“搜索、推荐”，并不影响客户下单——因为根据调研，目前每个客户维护的最多SKU数量只有二十个，没有搜索功能并不会严重影响客户下单效率。

绿色部分，是二期的项目范围。二期将解决部分特殊业务刚需的诉求，例如要支持“预付款”模式，“账期”模式，“发票管理”，如果时间允许，可以一并实现若干报表查询功能。

蓝色部分，是三期的项目范围。三期将聚焦风险控制，并强化运营功能。

一般来讲，很多互联网公司初期会先跑业务，走流水，验证可行性，成本和风险控制并不是特别在意；当业务具备一定规模时，则必须引入系统风控机制；做到事前、事中、事后的风险控制。

此外，基于本案例B2B业务的特点，设计中并没有考虑太多的C端功能；实际上C端只需要保证客户能够方便下单，并做一些很粗的运营、通知即可。

6. 系统细节方案设计

系统整体架构和蓝图设计完成后，进入细节方案设计环节。

建模部分建议由高级PM和技术负责人共同完成，界面、权限设计可以由高级PM带领初级PM共同完成。

6.1 实体建模

实体建模是细节设计中最难，也是最重要的环节。实体建模代表将客观世界的对象，抽象成结构化的描述。

实体建模有问题，会导致后续业务和系统完全丧失扩展性和灵活性，甚至会很快就无法支持业务，需要推倒重做。

实体建模实际上是数据库设计中最重要的部分，会影响数据库表结构的设计，但更多体现了对业务本质的理解和认知。

很多产品经理常常忽略实体建模，只关注功能界面设计，最终会陷入逻辑的混乱和旋涡中。

只要模型清晰合理，功能设计、界面设计都是水到渠成的事。

我们将结合案例，以客户模型设计为起点，详细阐述实体建模的设计思路。

6.1.1 理想化的客户模型

首先回顾客户诉求。

目前的分销客户中，有比较大型的集团客户，下设若干省市机构和库房、门店；调研时，集团客户有如下诉求：

• 上海是中央仓库，需要由上海采购员账号下单配送到上海中央仓库；
• 广州天河区是中央仓库，需要由天河采购员下单配送到天河中央仓库；
• 广州其他区是门店自采，需要由各门店采购员下单配送到各门店；
• 广东省需要有一个高级别采购员账号，能够帮广东各仓库和门店代下单；

以上诉求，是业务系统建设中，最经典常见的树形组织机构管理诉求——不论是公司、客户，作为企业，都有多层级管理的要求，希望软件系统能够支持多层级业务体系。

多层级机构管理，通常使用组织机构树实现，在一颗树上绘制出业务的管理层级体系。

我们将分销业务作为组织机构管理树的根节点，客户属于子树，树形结构可以体现出客户的行政管理层级结构。

将账号和门店（收货对象，可以是中央仓，也可以是店铺）作为叶子，挂在机构节点下。

账号管理的数据范畴（包括能给哪些门店下单，能查看哪些门店的数据），可以遍历所在节点的子树来实现。

绘制示意图如下：

通过组织机构树，结合功能权限配置，可以实现集团客户的管理诉求。

上图中实际上存在三个对象，组织机构节点/账号/门店，通过实体建模ER图，可以描述出三者的关系。

如下：

每个机构都有一个“上级机构”字段，通过该字段描述的关联关系，可以绘制出完整的组织机构树；每个账号或门店，只允许隶属于一个组织机构节点，每个门店下可以维护多个收货人。

实体建模的过程，就是将业务对象抽象，并描述之间的对应关系。

例如以上ER图，看似简单，但却是对组织机构树以及账号、门店管理体系的高度抽象。

如果实现以上模型，可以支持任意灵活地集团客户管理诉求。

6.1.2 简化版的客户模型

实现组织树模型，开发复杂度很高。

经过和开发、业务沟通，最终决定采用一套简版的客户模型来支持一期业务，该简版模型在需要时完全可以升级到理想版的客户模型。

首先，和业务以及客户沟通确认，一期暂不支持复杂的行政层级管理，只需要给客户实现若干子账号可以管理若干门店即可，示意图如下。

这样系统只需要实现一颗非常简单的树，每个客户只有一个根节点而没有子节点，以便业务系统开发时不需要编写大量的遍历算法，大大降低了开发难度。

根据上述规则，将模型简化如下：

仔细观察可以发现：该模型与前一个模型相比，唯一的变化，是在账号和门店两个对象之间建立了关联关系，其他结构不变（这样处理，保持了模型未来的扩展性）。

当未来需要全面实现组织机构管理时，将账号/门店之间的对应关系打断，在业务系统中实现遍历算法，以及组织树管理维护功能即可，整个数据底层基本不需要调整。

6.1.3 更丰富一些的客户模型

业务需求中很重要的一条：能够针对每个客户每个门店的个性报价，设置不同的系数表，结合时价动态计算商品价格。

这里涉及到几个新的对象：系数表、报价单。

为了让管理可控，系数表是全公司通用的多套参数集合。包括了商品和价格系数，给每个门店关联并且只能关联一个有效的报价单，报价单关联系数表，以保证运营人员只需要调整一次系数表，就能刷新到所有需要修改的门店的价格表。

数据模型设计如下：

该模型体现了真实世界针对门店单独报价的场景，同时也体现了价格系数表的设计思路。

理清了账号、门店、机构、报价单、价格系数表之间的关系，功能设计都是水到渠成的事情。如果没有梳理清楚这些关系，功能设计、界面设计时必然是一头雾水，漏洞百出。

6.1.4 建模错误会导致扩展的灾难

最后，我们来看一个建模错误导致灾难的例子。

如果我们将上图数据模型中，账号和门店的对应关系调整成一对多，如下：

设计人员可能会认为，目前的业务诉求很明确：一个门店只能被一个账号管理，所以账号和门店被设计成一对多关系。

如果有一天，客户明确并要求必须支持一个门店被多个账号管理（也就是要实现账号和门店多对多的设计）。

实现此诉求，难度将非常非常大——因为从数据底层，到前端功能实现，都认为是一对多结构，如果要改成多对多，首先底层数据库结构得调整，所有历史数据要处理；其次，基本上所有涉及到读取账号和门店关系的功能代码需要全部重写。

看似简单的一个改造，会造成一场灾难。

设计人员应该在设计之初，就要做好设计的预判。即便早期业务诉求是一对多，但是模型要按照多对多设计，因为这是在现实世界中合理的一种逻辑存在，即便早期没有多对多管理的诉求，但只要模型和数据底层设计好，后续再调整会简单很多。

那么问题来了：是不是所有对象的关系，都应该设计成多对多就行了呢？

也不对。

比如门店和订单的关系，只可能是一对多，不可能是多对多；一个订单只能是一个门店提交的，现实世界中不存在门店和订单多对多的逻辑关系。

建模的难点和重点，就是将现实世界抽象成对象，描述其关联关系。

如果这些对象和关系没有梳理清楚，流程、界面的设计都会是一笔糊涂账。

6.2 用户角色设计和流程图

在整个方案中，我们设计了4个角色，来支持业务。

1. 电商公司分销业务部
2. 分销管理员 – 负责业务稽查，审核，分公司账号的管理维护
3. 分销运营 – 负责分公司客户的账号维护，报价管理
4. 客户

其中：

客户管理员：负责下单账号和门店的管理/维护，订单查询，对账结算。

客户采购：负责给门店下单。

角色的设计，取决于业务对权责的划分。用户角色设计完成后，可以绘制更加详细的，基于系统的流程图。

如下：

流程图（以及页面流转图）是所有软件界面设计的基本前提，清晰的流程图和各种异常情况的分支描述，可以让后续的界面设计事半功倍。

如果没有清晰地流程图，界面设计绝对会陷入混乱。

7. 界面设计

建模合理，流程清晰，界面设计会变的非常简单。

网上关于界面设计的文章也非常多，方法论也很多；比如尼尔森十大可用性原则，读者可自行查阅，本文不再赘述，这里只讲几个建议。

7.1 模仿是最好的设计

研究并借鉴成熟的软件系统的设计，可以提升设计能力，少走弯路。

网上有很多免费开放试用的系统，都可以用来参考。比如Google Analytics / 百度统计 / 管家婆云ERP / SalesForce等。结合你设计的软件形态，找到行业内相似的SASS软件，借鉴并参考其排版、布局，可以提高设计效率与合理性。

7.2 拒绝花哨的前端

业务系统，不需要花哨的前端，不需要创意的控件。

有很多初入行的PM，喜欢在交互设计上做太多的发明创造；对于业务系统，价值不大，并且会增加研发的工作量。

我曾经见过一个业务系统，把其中的多选控件做的异常复杂——多选框中隐含了其他的交互形态，导致前端需要耗费大量的精力去定制开发实现，实在没有必要。

选用标准的控件方案，可以节约PM和前端的大量时间。

什么叫标准的控件呢？

MS Visio或Axure里提供的可以绘制的控件，就是标准控件。

不要在这些标准控件以外去发明创造控件！

对于复杂一点的报表和仪表盘设计，推荐两个组件库，一个是百度的ECharts，一个是Eclipse Birt，里边包含了大量经典的设计方案，这两者都是开源的，可以直接拿来用。

8. 权限设计

权限设计，是业务系统设计中最重要的一部分。权限设计代表了对整个业务体系岗位和流程的理解和拆解。

软件系统的权限设计包含两部分，功能权限和数据权限。

功能权限是指不同角色可以操作的界面、按钮等等。

例如：某一个角色在订单查询页面能看到哪些字段，能操作哪些按钮。

数据权限是指不同角色在同一页面中看到的数据范围。例如分公司管理员在订单查询页面能看到分公司的所有订单，而区域主管只能看到所在区域的订单。

功能权限设计的经典方法论是RBAC（Role Based Access Control），描述了一套用户、角色、权限组的设计理念，简单的可以抽象为以下实体关系图：

该理论具体的讲解，读者可在网络上自行查阅，请读者理解RBAC的数据模型图。

可以看出：软件系统的设计，即便是权限管理体系设计，最终也都会归结抽象到数据模型的设计。

由此可见，抽象建模能力，是PM必须掌握的核心技能。

我们将权限管理部分，进一步做一个延伸讨论：

假设我们实现了前文提到的完整的组织机构树，同时也有完善的权限控制体系，此时，系统可以完美的支持各种复杂的业务场景诉求。

我们在之前的角色设计中，新增一个角色“客户采购员2”，其中“客户采购员2”和“客户采购员1”的区别是：前者的数据权限范围，是查询用户当前所在组织机构树叶子上的数据，而后者能够查询用户当前所在组织机构树叶子，以及叶子下边所有子节点的数据。

客户的组织架构如下：

不同账号，所能看到的数据权限范围见下表：

请读者结合上图和下表，自己做出判断：账号4能查看哪些门店的订单数据？如果您理解了这个案例中隐含的逻辑，则掌握了业务系统权限管理体系的主要核心思想。

9. 技术方案与项目实施

产出PRD以后，进入了技术设计和实施环节。

当然，对于一套全新的系统，技术设计可能很早就已经启动。再往后，就进入实施环节，以及上线后的持续迭代和产品运营环节。

以后有机会单独介绍此部分话题。

全文总结

至此，我们结合一个实际案例，完整的介绍了一套系统从无到有的设计。介绍的重点是调研、架构、模块、建模、权限，对于交互、界面等细节一笔带过。

实际上，文中已经多次强调，并且读者现在应该也有了充分的认识：抽象、流程、建模才是业务系统设计的重点和核心，只有将业务最本质的东西高度剥离并正确抽象，才能构建一套灵活强大的系统。

对于一名后端产品经理来讲，以下经验和技能必不可可少。

• 具备基本的商业、管理、运营常识；
• 理解商业模式、业务目标、组织、流程；
• 理解公司的企业应用架构和系统现状；
• 具备将客观世界抽象成架构、模块、模型的能力；

路漫漫其修远兮，后端产品经理的成长是一个厚积薄发的过程，需要长期的坚持、积累、思考。

希望本文能够帮助读者对系统的设计有一个大体的认知和理解，并融入到工作中，形成更深层次的思考。