本文将以1个案例，向读者逐渐揭露1套业务系统从0到1的设计进程。重点讲述架构、模型等业务系统最本质的设计精要。
理论知识
业务系统设计概述
1. 甚么是业务系统
互联网公司常常根据用户性质将产品分为两大类：C端产品和B端产品。
C端产品主要是面向客户和消费者的系统；B端产品的服务对象是组织机构，给供应商或商家使用的系统、给公司内部业务人员使用的系统，都被称为B端产品。
由于服务对象不同，2者在建设时的动身点和侧重点也完全不同：
C端产品偏重用户体验，强调感性，每一个按钮的摆放位置都要精心设计、论证，需要进行延续的数据分析和优化。
B端产品偏重流程化、模块化，强调抽象和结构性，讲求整体的计划和体系设计。
如果将B端产品进1步拆分，又可以分为3类：
第1类是业务平台产品，即为业务部门提供基础服务支持的产品。
第2类是供内部员工使用的办公协同产品，支持企业的经营、管理和业务运转。
第3类是商家端产品，常见于双边模式的平台型互联网公司，例如淘宝的卖家管理系统、美团的商家管理后台。
常见的业务平台产品包括：
- 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端系统的设计场景。
当企业发展到1定阶段时，业务系统对企业的高效管理和运转具有不可替换的核心作用。
例如，当1家公司只有几个销售人员时，客户资料用Excel便可管理；当销售人员发展到上千人时，则必须通过1套OCRM系统进行管理。
整体来说，业务系统对企业具有4点价值：提升管控能力、控制经营风险、下降运营本钱、提升销售事迹。
很多时候，业务系统建设的好坏决定了企业的核心竞争力，例如，外卖公司之间的竞争，配送员的效力是业务成败的决定因素之1，而配送员的效力取决于TMS（运输管理系统）建设的好坏，这既包括软件系统本身的质量，也包括配套的管理运营体系的履行情况。
2. 为何要学习设计业务系统
商业模式的创新是互联网行业最大的特点，商业模式的创新会带来业务模式的创新，业务模式的创新又会带来运营、管理机制的创新。
多数情况下，采取了创新业务模式的互联网公司，没法通过采购成熟的标准软件来支持业务，而作为技术驱动型企业，自主研发系统来支持新业务便成为不2选择。
例如，滴滴公司在成立时，是没法在市面上找到1款成熟的司机管理运营软件的，因此需要自主研发；这时候就需要有专业经验的资深产品经理，结合业务，从无到有地设计1套司机（乃至是针对司机运营的机构）管理系统。
再例如，美团需要管理大量的地推人员和客户，传统的OCRM软件根本没法满足美团（美团对地理位置管理有很高要求）的诉求，即使采购成熟的OCRM做定制化开发，难度也比较大。最好的办法是自主研发1套全新的基于独特业务模式的OCRM软件来支持业务。
由此可以看出，互联网企业创新的本质，决定了必须有1批优秀的业务系统设计人员，结合公司特殊业务诉求，快速、公道地设计配套系统，并落地支持业务。
业务系统的产品经理，要具有企业经营管理、软件系统设计的多方面经验和知识储备，才能设计公道的业务系统。
3. 业务系统设计的流程
从无到有地设计业务系统，是有1套标准范式可以遵守的。
1般来说，1套业务系统从0到1的构建，需要经历以下环节（其中PM代表产品经理，需要从整体上把控业务系统的建设，调和各个相干方，对全部项目负责）：
业务方案设计
PM和业务负责人1起梳理、制定业务流程、制度、机制，理解业务的问题点，并肯定软件系统解决方案。
系统整体方案设计
PM结合业务诉求与目标完成系统概要设计，包括明确产品定位（界定业务和系统的边界）、抽象功能模块、设计演进蓝图、设计整体利用架构，明确新系统如何与公司已有系统连接、交互。
系统细节方案设计
PM需要负责细节方案的所有设计工作，包括数据建模、角色梳理、界面设计、权限设计等。
其中数据建模是最难的部份：数据建模的好坏决定了系统未来的灵活性、可扩大性，数据建模要求对业务有全面理解，并且有极强的抽象和归纳能力。
实行验收
PM对项目的终究落地负责，系统上线后要展开延续的迭代优化，深度参与产品运营、数据分析等。
如果是从无到有地设计1套业务系统，以上环节必须全面贯彻，特别是利用架构设计和数据模型，是重中之重。
案例分析
某电商公司的渠道销售系统设计
本文将结合1个案例，带大家1步步设计1个业务系统，帮助读者理解以上所有的设计环节。
背景
某电商企业M公司，成立5年，主营生鲜商品，以C端客户为主，业务稳定，系统建设成熟。
M公司在3个月前尝试展开分销业务，成立销售团队，开发分销商合作火伴（通过分销商批量推行和销售商品）；业务试点在北京、上海展开，3个月以来发展迅速，同时，在高速发展中，若干流程、管理、风险问题突显。
评估
经公司管理层评估，目前分销业务月流水50万元，以月增长率20%的速度快速发展。公司决定投入研发资源建设软件系统，支持业务发展。
任务
公司要求在2~3个月的时间内搭建出1套分销业务平台，支持分销业务在未来2年的高速发展，提升效力，控制经营风险。项目期间CTO全力提供人力资源支持。
1. 工作计划
作为项目负责人，产品经理在接到任务后，首先要理清工作思路，拆解任务，制定时间计划。只有严格遵守时间计划履行工作，才能保证整体工作有序展开，如期落地。
根据经验和初步判断，我们制定粗略的工作计划表以下：
时间紧，任务重，产品经理需要立即展开行动。
固然，计划表中的研发周期只是1个粗拍的时间，具体实行周期要结合1期项目范围及人力投入，在立项时细化。
2. 业务调研与业务方案
设计系统之前，必须透彻理解业务现状与业务目标，斟酌如何结合现有系统改造、优化业务流程和模式。
此阶段可以由1个高级产品经理带领几个低级产品经理来做，最好约请技术负责人1起参与；这样有益于技术人员提早理解业务，为技术选型和方案设计做好准备，也便于让技术负责人协助产品经理共同完成整体方案设计和细节方案设计——由于有时产品方案设计会受技术方案影响。
2.1 业务调研的方法
业务调研有多种方法，例如轮岗实习、问卷调研、深度访谈等。
其中，轮岗实习是深入理解业务的好方法，但是需要的时间较长；深度访谈是1种更加便捷快速的方法。
访谈之前，最好对业务有大体的认知，安排好访谈的对象，提早准备好问题，让访谈更加高效。
以下是针对分销业务的访谈计划和调研表：
主持人员：产品经理、研发经理
调研对象：业务负责人、1线主管、1线业务人员、合作火伴（分销业务客户）
调研方式：
深度访谈（访谈大纲以下图），并进行数据分析。
调研目标：
- 了解业务模式和业务特点
- 了解业务目标和业务计划
- 了解当前业务运转方式
- 发掘当前问题与痛点
业务调研总结
业务调研主要需要梳理清楚以下方面的情况，我们结合案例依此来看。
2.2 组织架构
通过调研，我们首先理清了当下的基本业务组织架构（以下面左图所示），通过组织架构图能够方便地理解管理体系和职能单元的设计。
根据公司的要求，需要提升分销业务的效力，控制经营风险，所以我们计划做出两方面调剂：各分公司成立自己的运营部，招聘自己的运营人员，以便对市场做出迅速响应，提升效力；在分销业务部下新增业务支持与风控部，以便控制风险。
计划的组织架构如上面右图所示。
2.3 业务目标
我们梳理了关键业务指标和目标，以下表所示：
2.4 业务流程
通过调研，我们还梳理了目前的业务运作流程，这样才能对实际业务运作有清晰的了解，以下图所示：
可以看出：目前业务展开以手工作业为主，下单配送环节依托于公司已有的系统实现。
3. 问题梳理
基于目前手工作业流程，我们整理出以下业务问题：
- 生鲜实时变价，每次下单要根据折扣表手工计算价格，效力低，易出错。
- 由于缺少完善的客户账号管理体系，所以没法实现客户总部集采、大区集采、城市集采、门店自采等灵活的混合采购模式。
- 由于没法标识特殊客户的特殊定单，所以没法支持特殊分拣、配送要求，例如对某些定单加急配送。
- 没法对账期客户及时控制回款进度和账期风险。
- 对账和开票工作复杂，需要处理大量数据表，容易出错。
当前流程下，1个运营人员只能跟进并保护5个左右的客户，逐日只能处理10笔左右的定单，人效极低。
3.1 基于业务调研的核心诉求分析
基于整体调研结果，我们概要性地列出以下解决思路（括号中注明了优先级）：
- 实现客户自主下单（高优）
- 实现系统自动定价（高优）
- 支持客户多门店分别定价与下单（高优）
- 实现对账报表（高优）
- 运营人员聚焦参数设置、审核和异常问题跟进（高优）
- 将运营工作下放到各城市分部（中优）
- 支持账期和预支款模式（低优）
- 系统实现账期风控（低优）
我们将业流程优化肯定为高优诉求，将扩大功能或针对部份客户的小众功能，和风控功能列为低优。
经过探讨，和业务人员达成1致，1期项目聚焦高优诉求的实现。
4. 业务主流程设计
经过和业务人员充分沟通，我们设计出系统支持下的核心业务流程图，以下图所示：
其中，客户开发、合同审核等前置流程，仍然通过线下处理完成；而客户签约后的账号管理、价格管理、自主下单等环节，则通过分销系统来支持，以提升效力。
5. 系统整体方案设计
完成业务调研后，进入系统整体方案设计环节。
该环节需要由经验丰富的产品经理和公司的架构师1起探讨完成，由于方案触及和公司现有利用架构如何融会的问题，因此还需要经过产品委员会或架构组的评审和确认。
5.1 系统定位
我们对业务进行分析。
首先，分销客户希望能有1个便捷快速下单的工具，所以需要有1个手机版商城C端；斟酌到投入产出比，我们决定通过H5来实现，具有独立域名，外网可访问。
其次，需要为分销客户提供1套方便操作的管理后台——由于触及大量的商品编辑处理，账号、门店管理等功能，所以斟酌PC版本实现，暂不支持手机版。
最后，斟酌到公司运营人员和分销客户管理员的管理诉求不同，操作功能和页面差异较大，所以决定将管理后台拆解为两个独立的系统：
- 给分销客户管理员使用的客户管理后台，具有独立域名，外网可访问。
- 给公司运营人员使用的运营管理后台，具有独立域名，仅限内网访问。
因而，我们打算将分销系统拆分为3个独立的子系统，来支持分销业务：
- 分销商城前台（移动端，用H5实现）：为分销客户提供下单功能。
- 客户管理后台（PC端）：为分销客户提供子账号管理、门店管理及业务辅助功能。
- 运营管理后台（PC端）：为分销业务部门提供对客户及商品定价管理的业务支持。
设计业务系统常见的问题是：为了省事，把所有业务单元的功能糅合到1个系统中实现，这会造成管理的混乱，特别是系统保护的混乱。
1般来说，系统的抽象要结合业务完成，独立的业务职能单元要配合独立的系统来使用；如果业务部门之间边界模糊，权责界定不清，也会致使系统之间存在模糊性。
清晰的系统定位和边界，可让各个子系统具有足够的独立性，是全部系统具有灵活性和可扩大性的基本条件。
5.2 整体架构设计
现在，需要斟酌分销平台的3个子系统如何与公司的整体利用架构融会。
公司经过量年发展，系统架构体系已非常完备，大量公共组件和模块可以复用，这样就减轻了新平台的实现本钱和难度。
分销平台只需要聚焦自己业务特殊独立的地方，其他公共组件和模块复用已有系统的便可。
具体分析以下：
电商业务是公司的主营业务，有成熟的定单体系和仓配系统。
分销业务的独特性在于前置客户（是企业客户）的管理保护，下单后的分拣配送业务流程和之前的业务是1样的，所以分销商城的定单中心直接复用已有定单中心，定单写入后续的处理流程完全不变，只需要定单中心稍作改造便可支持，这样也能够保证全部定单台账、财务、仓储、配送基本都不需要重写或改造。
另外分销平台的商品中心复用已有商品中心SKU数据，只是价格管理模块部份需要新做1套独立的，以支持特殊报价业务。
分销业务的账户体系、权限管理体系、在线支付功能，都可以利用已有系统。其中账户体系需要做改造，以支持子母账号管理；在线支付功能完全复用便可。
客户资料的存储利用已有的客户主数据（MDM）系统实现——由于企业客户资料和个人客户资料的差异较大，所以需要对MDM做较大改造，要新做1套企业客户数据模型。
但是在架构上，必须将客户（包括个人客户和企业客户）资料作为主数据来建设，统1管理保护。
最后1个问题：既然公司已有C端商城，为何要单独再做1套针对分销客户的C端商城？
经过分析评估，个人客户和企业客户需要的功能差异，如果对原有商城进行改造来支持分销业务，1方面需要投入的工时可能比新做1套还要多，另外一方面会影响主营业务系统的硬朗性，因此终究决定为分销业务做1套新的C端商城。
基于上述分析，我们将3个子系统绘入简化版的公司整体利用架构图中，以下：
5.3 功能抽象
基于对业务的分析，和3套系统的定位，可以抽象并绘制完全的系统功能蓝图。
功能模块图，是对业务诉求系统化设计的进1步高度抽象。模块的设计，要体现出同1个业务职能单元中不同业务场景和操作的集合，模块也代表了系统中的12级导航菜单的设计。
常见的问题是：设计人员对模块设计的随便和混乱，和后来新增功能的随便摆放，会造成用户使用系统时产生困惑，同时还会致使开发人员编码设计的混乱。
功能模块图，代表了设计师对业务和系统本质的理解和提炼，包括了对业务、系统未来发展的展望。
我们常说，系统建设要有计划和节奏，实际上功能模块图就是1幅远景计划蓝图；是系统的骨架，决定了系统的整体结构。
结合业务需求，每个具体功能的实现，都是在对骨架不断地填充血肉，让他更真实，更立体，更丰富。
随着业务的展开，变化，功能模块图可能会有新的计划和调剂，但如果业务单元的本质和模式没有变化，功能模块图不应当出现结构性的调剂和改动。
5.4 演进蓝图
我们已绘制了系统的功能模块图，体现了业务和系统计划的脉络；现在，让我们开始研究这套“体系”，大概需要几期实现，每期实现的侧重点是甚么，也就是常说的演进蓝图——Roadmap：
白色部份，是1期的项目范围。聚焦解决最基本的业务流程线上化问题，和最痛的痛点，例如对账功能。
1期功能有1个原则：凡是可以手工处理和解决的问题，都不做系统支持。
所以：
- 类似于“报表”，可以定期跑SQL实现；
- 类似于“价格系数设置”，斟酌到保护频率低，可以由RD在后台改数据库完成；
- 类似于“搜索、推荐”，其实不影响客户下单——由于根据调研，目前每一个客户保护的最多SKU数量只有210个，没有搜索功能其实不会严重影响客户下单效力。
绿色部份，是2期的项目范围。2期将解决部份特殊业务刚需的诉求，例如要支持“预支款”模式，“账期”模式，“发票管理”，如果时间允许，可以1并实现若干报表查询功能。
蓝色部份，是3期的项目范围。3期将聚焦风险控制，并强化运营功能。
1般来说，很多互联网公司早期会先跑业务，走流水，验证可行性，本钱和风险控制其实不是特别在乎；当业务具有1定范围时，则必须引入系统风控机制；做到事前、事中、事后的风险控制。
另外，基于本案例B2B业务的特点，设计中并没有斟酌太多的C端功能；实际上C端只需要保证客户能够方便下单，并做1些很粗的运营、通知便可。
6. 系统细节方案设计
系统整体架构和蓝图设计完成后，进入细节方案设计环节。
建模部份建议由高级PM和技术负责人共同完成，界面、权限设计可以由高级PM带领低级PM共同完成。
6.1 实体建模
实体建模是细节设计中最难，也是最重要的环节。实体建模代表将客观世界的对象，抽象成结构化的描写。
实体建模有问题，会致使后续业务和系统完全丧失扩大性和灵活性，乃至会很快就没法支持业务，需要推倒重做。
实体建模实际上是数据库设计中最重要的部份，会影响数据库表结构的设计，但更多体现了对业务本质的理解和认知。
很多产品经理常常疏忽实体建模，只关注功能界面设计，终究会堕入逻辑的混乱和漩涡中。
只要模型清晰公道，功能设计、界面设计都是瓜熟蒂落的事。
我们将结合案例，以客户模型设计为出发点，详细论述实体建模的设计思路。
6.1.1 理想化的客户模型
首先回顾客户诉求。
目前的分销客户中，有比较大型的团体客户，下设若干省市机构和库房、门店；调研时，团体客户有以下诉求：
- 上海是中央仓库，需要由上海采购员账号下单配送到上海中央仓库；
- 广州天河区是中央仓库，需要由天河采购员下单配送到天河中央仓库；
- 广州其他区是门店自采，需要由各门店采购员下单配送到各门店；
- 广东省需要有1个高级别采购员账号，能够帮广东各仓库和门店代下单；
以上诉求，是业务系统建设中，最经典常见的树形组织机构管理诉求——不论是公司、客户，作为企业，都有多层级管理的要求，希望软件系统能够支持多层级业务体系。
多层级机构管理，通常使用组织机构树实现，在1颗树上绘制出业务的管理层级体系。
我们将分销业务作为组织机构管理树的根节点，客户属于子树，树形结构可以体现出客户的行政管理层级结构。
将账号和门店（收货对象，可以是中央仓，也能够是店铺）作为叶子，挂在机构节点下。
账号管理的数据范畴（包括能给哪些门店下单，能查看哪些门店的数据），可以遍历所在节点的子树来实现。
绘制示意图以下：
通过组织机构树，结合功能权限配置，可以实现团体客户的管理诉求。
上图中实际上存在3个对象，组织机构节点/账号/门店，通过实体建模ER图，可以描写出3者的关系。
以下：
每一个机构都有1个“上级机构”字段，通过该字段描写的关联关系，可以绘制出完全的组织机构树；每一个账号或门店，只允许隶属于1个组织机构节点，每一个门店下可以保护多个收货人。
实体建模的进程，就是将业务对象抽象，并描写之间的对应关系。
例如以上ER图，看似简单，但却是对组织机构树和账号、门店管理体系的高度抽象。
如果实现以上模型，可以支持任意灵活地团体客户管理诉求。
6.1.2 简化版的客户模型
实现组织树模型，开发复杂度很高。
经过和开发、业务沟通，终究决定采取1套简版的客户模型来支持1期业务，该简版模型在需要时完全可以升级到理想版的客户模型。
首先，和业务和客户沟通确认，1期暂不支持复杂的行政层级管理，只需要给客户实现若干子账号可以管理若干门店便可，示意图以下。
这样系统只需要实现1颗非常简单的树，每一个客户只有1个根节点而没有子节点，以便业务系统开发时不需要编写大量的遍历算法，大大下降了开发难度。
根据上述规则，将模型简化以下：
仔细视察可以发现：该模型与前1个模型相比，唯1的变化，是在账号和门店两个对象之间建立了关联关系，其他结构不变（这样处理，保持了模型未来的扩大性）。
当未来需要全面实现组织机构管理时，将账号/门店之间的对应关系打断，在业务系统中实现遍历算法，和组织树管理保护功能便可，全部数据底层基本不需要调剂。
6.1.3 更丰富1些的客户模型
业务需求中很重要的1条：能够针对每一个客户每一个门店的个性报价，设置不同的系数表，结合时价动态计算商品价格。
这里触及到几个新的对象：系数表、报价单。
为了让管理可控，系数表是全公司通用的多套参数集合。包括了商品和价格系数，给每一个门店关联并且只能关联1个有效的报价单，报价单关联系数表，以保证运营人员只需要调剂1次系数表，就可以刷新到所有需要修改的门店的价格表。
数据模型设计以下：
该模型体现了真实世界针对门店单独报价的场景，同时也体现了价格系数表的设计思路。
理清了账号、门店、机构、报价单、价格系数表之间的关系，功能设计都是瓜熟蒂落的事情。如果没有梳理清楚这些关系，功能设计、界面设计时必定是1头雾水，漏洞百出。
6.1.4 建模毛病会致使扩大的灾害
最后，我们来看1个建模毛病致使灾害的例子。
如果我们将上图数据模型中，账号和门店的对应关系调剂成1对多，以下：
设计人员可能会认为，目前的业务诉求很明确：1个门店只能被1个账号管理，所以账号和门店被设计成1对多关系。
如果有1天，客户明确并要求必须支持1个门店被多个账号管理（也就是要实现账号和门店多对多的设计）。
实现此诉求，难度将非常非常大——由于从数据底层，到前端功能实现，都认为是1对多结构，如果要改成多对多，首先底层数据库结构得调剂，所有历史数据要处理；其次，基本上所有触及到读取账号和门店关系的功能代码需要全部重写。
看似简单的1个改造，会造成1场灾害。
设计人员应当在设计之初，就要做好设计的预判。即使初期业务诉求是1对多，但是模型要依照多对多设计，由于这是在现实世界中公道的1种逻辑存在，即使初期没有多对多管理的诉求，但只要模型和数据底层设计好，后续再调剂会简单很多。
那末问题来了：是否是所有对象的关系，都应当设计成多对多就好了呢？
也不对。
比如门店和定单的关系，只多是1对多，不多是多对多；1个定单只能是1个门店提交的，现实世界中不存在门店和定单多对多的逻辑关系。
建模的难点和重点，就是将现实世界抽象成对象，描写其关联关系。
如果这些对象和关系没有梳理清楚，流程、界面的设计都会是1笔胡涂账。
6.2 用户角色设计和流程图
在全部方案中，我们设计了4个角色，来支持业务。
- 电商公司分销业务部
- 分销管理员 – 负责业务稽查，审核，分公司账号的管理保护
- 分销运营 – 负责分公司客户的账号保护，报价管理
- 客户
其中：
客户管理员：负责下单账号和门店的管理/保护，定单查询，对账结算。
客户采购：负责给门店下单。
角色的设计，取决于业务对权责的划分。用户角色设计完成后，可以绘制更加详细的，基于系统的流程图。
以下：
流程图（和页面流转图）是所有软件界面设计的基本条件，清晰的流程图和各种异常情况的分支描写，可让后续的界面设计事半功倍。
如果没有清晰地流程图，界面设计绝对会堕入混乱。
7. 界面设计
建模公道，流程清晰，界面设计会变的非常简单。
网上关于界面设计的文章也非常多，方法论也很多；比如尼尔森10大可用性原则，读者可自行查阅，本文不再赘述，这里只讲几个建议。
7.1 模仿是最好的设计
研究并鉴戒成熟的软件系统的设计，可以提升设计能力，少走弯路。
网上有很多免费开放试用的系统，都可以用来参考。比如Google Analytics / 百度统计 / 管家婆云ERP / SalesForce等。结合你设计的软件形态，找到行业内类似的SASS软件，鉴戒并参考其排版、布局，可以提高设计效力与公道性。
7.2 谢绝花梢的前端
业务系统，不需要花梢的前端，不需要创意的控件。
有很多初入行的PM，喜欢在交互设计上做太多的发明创造；对业务系统，价值不大，并且会增加研发的工作量。
我曾见过1个业务系统，把其中的多选控件做的异常复杂——多选框中隐含了其他的交互形态，致使前端需要耗费大量的精力去定制开发实现，实在没有必要。
选用标准的控件方案，可以节俭PM和前真个大量时间。
甚么叫标准的控件呢？
MS Visio或Axure里提供的可以绘制的控件，就是标准控件。
不要在这些标准控件之外去发明创造控件！
对复杂1点的报表和仪表盘设计，推荐两个组件库，1个是百度的ECharts，1个是Eclipse Birt，里边包括了大量经典的设计方案，这二者都是开源的，可以直接拿来用。
8. 权限设计
权限设计，是业务系统设计中最重要的1部份。权限设计代表了对全部业务体系岗位和流程的理解和拆解。
软件系统的权限设计包括两部份，功能权限和数据权限。
功能权限是指不同角色可以操作的界面、按钮等等。
例如：某1个角色在定单查询页面能看到哪些字段，能操作哪些按钮。
数据权限是指不同角色在同1页面中看到的数据范围。例如分公司管理员在定单查询页面能看到分公司的所有定单，而区域主管只能看到所在区域的定单。
功能权限设计的经典方法论是RBAC（Role Based Access Control），描写了1套用户、角色、权限组的设计理念，简单的可以抽象为以下实体关系图：
该理论具体的讲授，读者可在网络上自行查阅，请读者理解RBAC的数据模型图。
可以看出：软件系统的设计，即使是权限管理体系设计，终究也都会归结抽象到数据模型的设计。
因而可知，抽象建模能力，是PM必须掌握的核心技能。
我们将权限管理部份，进1步做1个延伸讨论：
假定我们实现了前文提到的完全的组织机构树，同时也有完善的权限控制体系，此时，系统可以完善的支持各种复杂的业务场景诉求。
我们在之前的角色设计中，新增1个角色“客户采购员2”，其中“客户采购员2”和“客户采购员1”的区分是：前者的数据权限范围，是查询用户当前所在组织机构树叶子上的数据，而后者能够查询用户当前所在组织机构树叶子，和叶子下边所有子节点的数据。
客户的组织架构以下：
不同账号，所能看到的数据权限范围见下表：
请读者结合上图和下表，自己做出判断：账号4能查看哪些门店的定单数据？如果您理解了这个案例中隐含的逻辑，则掌握了业务系统权限管理体系的主要核心思想。
9. 技术方案与项目实行
产出PRD以后，进入了技术设计和实行环节。
固然，对1套全新的系统，技术设计可能很早就已启动。再往后，就进入实行环节，和上线后的延续迭代和产品运营环节。
以后有机会单独介绍此部份话题。
全文总结
至此，我们结合1个实际案例，完全的介绍了1套系统从无到有的设计。介绍的重点是调研、架构、模块、建模、权限，对交互、界面等细节1笔带过。
实际上，文中已屡次强调，并且读者现在应当也有了充分的认识：抽象、流程、建模才是业务系统设计的重点和核心，只有将业务最本质的东西高度剥离并正确抽象，才能构建1套灵活强大的系统。
对1名后端产品经理来说，以下经验和技能必不可可少。
- 具有基本的商业、管理、运营常识；
- 理解商业模式、业务目标、组织、流程；
- 理解公司的企业利用架构和系统现状；
- 具有将客观世界抽象成架构、模块、模型的能力；
路漫漫其修远兮，后端产品经理的成长是1个厚积薄发的进程，需要长时间的坚持、积累、思考。
希望本文能够帮助读者对系统的设计有1个大体的认知和理解，并融入到工作中，构成更深层次的思考。
如果想做好B端产品经理，那末1方面需要学习相干的专业知识，另外一方面需要深入了解行业知识，熟习业务流程。只有这样，才能针对B端人群和场景做好产品设计。
在《决胜B端：产品经理升级之路》1书中，作者将自己10余年经验悉数分享，以1个实践性很强的案例贯穿全书，不但逻辑清晰地梳理了专业知识，还用1个饱满的行业案例带领读者利用这些知识，非常实用。
作者:杨堃
查看更多关于【产品设计】的文章
