漫谈业务系统从0到1的设计过程「业务管理流程化 数字化发展」

今天给大家普及一下漫谈业务系统从0到1的设计过程「业务管理流程化 数字化发展」相关知识，最近很多在问漫谈业务系统从0到1的设计过程「业务管理流程化 数字化发展」，希望能帮助到您。

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

一、业务系统设计概述

1、什么是业务系统

互联网公司常常将产品方向分为两类，C端和B端，C端主要是面向客户和消费者的系统，B端的范围则相对模糊，给供应商或商家使用的系统，给内部业务人员使用的系统，都统称为B端系统。C端和B端系统建设的出发点和侧重点完全不同。C端系统偏重用户体验，强调感性，持续的数据分析优化，同一个按钮不同的摆放位置都要精心设计、论证，服务对象是个人；B端系统偏重流程、模块化，强调抽象和结构性，讲究整体的规划和体系设计，服务对象是组织和机构。

如果将B端系统进一步拆分，也可以分为两类，第一类是商家端，常见于双边模式的平台型互联网公司，例如淘宝的卖家管理系统，美团的商家管理后台；第二类是内部业务系统，支持企业经营、管理、业务运转。

本文所说业务系统，指B端产品线中的企业内部业务系统。虽然B端系统也可以分为两类，但因为都是面向业务的系统（Business），服务于组织而非个人，其设计思想和原理都是相同的，所以本文讲解的内容可以应用于所有B端系统的设计场景。

常见的业务系统包括ERP（EnterpriseResource Planning），CRM（CustomerRelationship Management），SCM（Supply ChainManagement），WMS（WarehouseManagement System），TMS（TransportationManagement System），OA（Office Automation），HRM（Human ResourceManagement）等等。因为绝大多数互联网公司都有独特的业务模式，所以很多时候类似于CRM、WMS、TMS这类系统都自主研发，OA、HRM这类系统由于业务模型区别不大，多数都会采购标准软件。有些互联网巨头也会自主研发OA、HRM。习惯上，CRM、WMS这类系统被称为业务系统，OA、HRM这类系统被称为内部协同软件，但两类系统之间也并没有非常清晰的界定。

如果从软件学的角度来看，所有软件系统分为两类，第一类是能够实时产生业务数据的系统，叫做OLTP（Online TransactionProcessing）系统，第二类是对数据进行加工、处理、探查、挖掘、展现的系统，叫做OLAP（Online AnalyticalProcessing）系统，很显然，业务系统属于OLTP的范畴。

当企业发展到一定阶段，业务系统对企业的高效管理运转具备不可替代的核心作用。例如，当一家公司只有几个销售人员时，客户资料用Excel即可管理。当销售发展到上千人时，必须通过一套OCRM系统进行管理。

总体来讲，业务系统对企业具有四点价值：提升管控能力、控制经营风险、降低运营成本、提升销售业绩。很多时候，业务系统建设好坏决定了企业的核心竞争力，例如外卖公司之间的竞争，配送员的效率是业务成败的决定因素之一，而配送员的效率取决于TMS系统建设的好坏。当然，TMS系统建设的好坏，包括了软件系统本身，以及配套落地的管理运营体系的执行。

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

商业模式的创新是互联网行业最大的特点，商业模式的创新会带来业务模式的创新，业务模式的创新会带来运营、管理机制的创新。多数情况下，互联网公司独特的业务模式，导致无法采买市面上成熟的标准软件来支持业务，而作为技术驱动型企业，自主研发系统支持新业务成为不二的选择。

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

再例如，美团有大量的地推人员和客户需要管理，传统的OCRM软件根本无法支持美团这种强POI诉求的客户管理，因为业务模式特殊，即便采购成熟的OCRM做定制化开发，也难以使用。所以，只能靠自主研发一套全新的基于独特业务模式的OCRM来支持业务。

由此可以看出，互联网企业创新的本质，决定了必须有一批优秀的业务系统设计人员，能够结合公司特殊业务诉求，快速、合理的设计配套系统，并落地支持业务。业务系统的产品经理，要具备企业经营管理、软件系统设计的多方面经验和知识储备，才能设计合理的业务系统。

3、业务系统设计的流程

业务系统从无到有的设计，是有一套标准范式可以遵循的。实际上，随便一套《软件工程学》教程，讲述的都是业务系统的设计，但是软件工程已经不满足当前时代对专业人员的培养和要求。互联网时代下的软件设计，已经被拆分成多个细分职能，产品经理参与制定业务，设计应用功能；工程师负责技术架构，编码实施；而在传统软件工程中，这两项职能由一个角色承担。如今的现实情况是，软件设计人员更多的参与到了业务决策制定，软件研发人员越来越远离业务，只聚焦于技术。

即便如此，软件设计中的经典思路、方法论，是没有改变的。业务系统的产品经理，必须理解软件工程学中的部分核心要素，才能真正设计出靠谱的系统。

一般来讲，一套业务系统从0到1的构建，需要经历如下环节。

业务方案设计

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

系统整体方案设计

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

系统细节方案设计

PM完成细节方案的所有设计，包括建模、角色、界面、权限等。其中建模是最难的部分，建模好坏决定了系统未来的灵活性、可扩展性。建模要求对业务的全面理解，极强的抽象归纳能力。

实施验收

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

如果是从无到有设计系统，以上环节必须全面贯彻，尤其是架构设计和模型设计，是重中之重。

4、案例：某电商公司的渠道销售系统设计

本文将结合一个虚拟的案例，逐步论述，帮助读者理解以上所有的设计环节。

背景：

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

诉求：

公司在三个月前尝试开展分销业务，成立销售团队，开发分销商合作伙伴。业务试点在北京、上海开展，三个月以来发展迅速，现急需配套的软件系统提升业务效率，控制经营风险。

评估：

经公司管理层评估，目前分销业务月流水五十万，以月增长率20%的速度快速发展。在高速发展中若干流程、管理、风险问题突出，公司决定投入研发资源建设软件系统，支撑业务发展。

任务：

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

5、工作计划

作为项目负责人，某高级PM接到任务后，首先要理清工作思路，拆解任务，制定时间计划。只有严格遵循时间计划执行工作，才能保证整体工作有序展开，如期落地。根据经验和初步判断，产品经理制定了粗略的工作计划表如下。

时间紧，任务重，PM需要立即开展行动。当然，计划表中的研发周期，纯粹是一个粗拍的时间，具体实施周期要结合一期项目范围，以及人力投入，在立项时细化。

二、业务调研与业务方案

设计系统之前，必须透彻理解业务现状与业务目标，考虑如何结合系统改造、优化业务流程和模式。此阶段可以由一个高级PM带领几个初级PM完成。最好邀请技术负责人一起参与，有利于技术人员提前理解业务，为技术选型和方案设计做好准备。此外，技术人员具备更好的抽象能力，深入理解业务，可以让技术负责人协助PM共同完成整体方案设计和细节方案设计。

1、业务调研的方法

理解业务最好的方法，是轮岗参与业务环节。此外更加便捷快速的方法，是调研访谈。调研之前最好对业务能有大体的认知，安排好访谈的对象，提前准备好问题，让访谈更加高效。以下是针对分销业务的访谈计划和调研表。

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

调研对象：业务负责人、一线主管、一线业务人员、合作伙伴

调研方式：

访谈

数据分析

调研目标：

了解业务模式和业务特点

了解业务目标和业务规划

了解当前业务运转方式

挖掘当前问题与痛点

2、业务调研总结

组织架构

通过调研，理清最基本的业务组织架构图，通过组织架构图理解管理体系和职能单元的设计，以及后续规划。

业务目标

对关键业务指标和目标需要有相应梳理。

业务流程

通过调研，梳理出目前的业务运作流程，如下图。

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

问题梳理

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

手工下单容易出错，效率低；

生鲜实时变价，每次下单要根据折扣表手工计算价格；

无法实现客户总部集采，大区集采，城市集采，门店自采等混合采购模式；

不支持特殊分拣、配送要求；

账期客户不能及时控制回款进度和账期风险；

对账和开票工作复杂，大量数据表处理，容易出错；

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

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

基于整体调研结论，总结出分销系统解决业务难题的核心诉求如下。

客户自主下单（高优）；

系统自动定价（高优）；

支持客户多门店分别定价与下单（高优）；

对账报表（高优）；

运营人员聚焦参数设置、审核和异常问题跟进（高优）；

运营工作要下放到各城市分部（中优）；

支持账期和预付款模式（低优）；

系统实现账期风控（低优）；

我们将业务主链路确定为高优诉求，将扩展功能或针对部分客户的小众功能，以及风控功能列为低优，和业务达成一致，一期项目聚焦核心流程的实现。

4、业务主流程设计

经过充分的沟通，设计出结合系统支持的核心业务流程。其中，涉及到客户开发、合同审核等前置流程，依然通过线下处理完成，未来考虑实现分销业务的OCRM系统进行支持，本次项目暂不考虑。

创建一套系统或平台，支持客户签约后的账号管理、价格管理、自主下单等功能。

三、系统整体方案设计

完成业务调研后，进入系统整体方案设计环节。该环节需要由经验丰富的PM以及公司的架构师一起探讨完成，因为方案涉及到和公司现有应用架构融合，还需要经过产品委员会或架构组的评审和确认。

1、系统定位

基于对业务的分析，考虑通过实现3套独立子系统来支持分销业务。

分销商城前台（H5）：分销客户的下单工具

客户管理后台（PC）：分销客户的子账号管理、门店管理及业务辅助工具

运营管理后台（PC）：分销业务部门对客户及商品定价管理的业务支持工具

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

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

最后，考虑到公司运营和客户管理员的管理诉求不尽相同，操作功能和页面差异较大，所以决定将管理后台拆解为两个独立的系统，给客户管理员使用的客户管理后台，具备独立域名，外网可访问；给公司管理人员和运营人员使用的运营管理后台，具备独立域名，仅限内网访问。

设计业务系统常见的问题，是为了图省事，把所有业务单元的功能糅合到一个系统中实现，造成管理的混乱，尤其是系统维护的混乱。一般来讲，系统的抽象要结合业务完成，独立的业务职能单元，要有各自独立的系统来配合使用。如果业务部门之间边界模糊，权责界定不清，也会导致系统之间存在模糊性。

清晰的系统定位，并划清边界，可以让彼此具备足够的独立性，是系统灵活性和可扩展性的基本前提。

2、整体架构设计

现在，需要考虑分销平台的三个子系统，如何与公司的整体应用架构融合问题。公司经过多年发展，系统架构体系已经非常完备，大量公共组建和模块可以复用，这样就减轻了新平台的实现成本和难度。分销平台只需要聚焦自己业务特殊独立的地方，其他公共组建和模块复用已有系统即可。

关于如何理解公司应用架构图，可参考本人之前的文章《漫谈企业应用架构的演变》。

我们将确定的三个子系统，绘入简化版的公司整体应用架构图，如下。

深绿色部分是分销平台的三个独立子系统，墨绿色部分是涉及打通和复用的已有系统。

电商是公司的主营业务，有成熟的订单体系和仓配体系，分销业务的独特性在于前置客户管理维护，下单后的分拣配送业务流程都一样，所以分销商城的订单中心直接复用已有订单中心，订单写入后续的处理流程完全不变，只需要订单中心稍作改造即可支持，这样也可以保证整个订单台账、财务、仓储、配送基本都不需要重写或改造。另外分销平台的商品中心复用已有商品中心SKU数据，只是价格管理模块部分需要新做一套独立的，以支持特殊报价业务。

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

客户资料的存储，利用已有的客户主数据（MDM）实现，MDM改造较大，要新做一套企业客户数据模型。虽然是新做，但是在架构上，必须将客户资料作为主数据来建设，统一管理维护。

最后一个问题，既然公司已经有C端商城，为什么要单独再做一套针对分销客户的C端商城？经过分析评估，两套商城整体区别较大，如果对原有商城进行改造支持分销业务，第一工时投入比新做一套还要大，第二会影响主营业务系统的健壮性，因此最终决定新做C端商城支持分销业务。

3、功能抽象

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

功能模块图，是对业务诉求系统化设计的进一步高度抽象。模块的设计，要体现出同一个业务职能单元中不同业务场景和操作的集合，模块也代表了系统中的一二级导航菜单的设计。常见的问题，是设计人员对模块设计的随意和混乱，以及后来新增功能的随意摆放，会造成用户使用系统时产生困惑，同时还会导致开发人员编码设计的混乱。

功能模块图，代表了设计师对业务和系统本质的理解和提炼，包含了对业务、系统未来发展的展望。我们常说，系统建设要有规划和节奏，实际上功能模块图就是一幅远景规划蓝图，是系统的骨架，决定了系统的整体结构，结合业务需求，每一个具体功能的实现，都是在对骨架不断地填充血肉，让他更真实，更立体，更丰富。

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

4、演进蓝图

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

白色部分，是一期的项目范围，聚焦解决最基本的业务流程线上化问题，以及最痛的痛点，例如对账功能。一期功能有一个原则，凡是可以手工处理和解决的问题，都不做系统支持。所以，类似于“报表”，可以定期跑sql实现；类似于“价格系数设置”，考虑到维护频率低，可以由RD在后台改数据库完成；类似于“搜索、推荐”，并不影响客户下单，因为根据调研目前每个客户维护的最多sku数量只有二十个，没有搜索功能并不会严重影响客户下单效率。

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

蓝色部分，是三期的项目范围，三期将聚焦风险控制，并强化运营功能。一般来讲，很多互联网公司初期会先跑业务，走流水，验证可行性，成本和风险控制并不是特别在意，当业务具备一定规模时，则必须引入系统风控机制，做到事前、事中、事后的风险控制。此外，基于本案例B2B业务的特点，设计中并没有考虑太多的C端功能。实际上C端只需要保证客户能够方便下单，并做一些很粗的运营、通知即可。

四、系统细节方案设计

系统整体架构和蓝图设计完成后，进入细节方案设计环节。建模部分建议由高级PM和技术负责人共同完成，界面、权限设计可以由高级PM带领初级PM共同完成。

1、实体建模

实体建模是细节设计中最难，也是最重要的环节。实体建模代表将客观世界的对象，抽象成结构化的描述。实体建模有问题，会导致后续业务和系统完全丧失扩展性和灵活性，甚至会很快就无法支持业务，需要推倒重做。

实体建模实际上是数据库设计中最重要的部分，会影响数据库表结构的设计，但更多体现了对业务本质的理解和认知。很多产品经理常常忽略实体建模，只关注功能界面设计，最终会陷入逻辑的混乱和旋涡中。

只要模型清晰合理，功能设计、界面设计都是水到渠成的事。我们将结合案例，以客户模型设计为起点，详细阐述实体建模的设计思路。

理想化的客户模型

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

上海是中央仓库，需要由上海采购员账号下单配送到上海中央仓库；

广州天河区是中央仓库，需要由天河采购员下单配送到天河中央仓库；

广州其他区是门店自采，需要由各门店采购员下单配送到各门店；

广东省需要有一个高级别采购员账号，能够帮广东各仓库和门店代下单；

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

多层级机构管理，通常使用组织机构树实现，在一颗树上绘制出业务的管理层级体系。我们将分销业务作为组织机构管理树的根节点，客户属于子树，树形结构可以体现出客户的行政管理层级结构。将账号和门店（收货对象，可以是中央仓，也可以是店铺）作为叶子，挂在机构节点下。账号管理的数据范畴（包括能给哪些门店下单，能查看哪些门店的数据），可以遍历所在节点的子树来实现。绘制示意图如下。

通过组织机构树，结合功能权限配置，可以实现集团客户的管理诉求。上图中实际上存在三个对象，组织机构节点，账号，门店。通过实体建模ER图，可以描述出三者的关系，如下。

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

实体建模的过程，就是将业务对象抽象，并描述之间的对应关系。例如以上ER图，看似简单，但却是对组织机构树以及账号、门店管理体系的高度抽象。如果实现以上模型，可以支持任意灵活地集团客户管理诉求。

简化版的客户模型

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

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

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

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

仔细观察可以发现，该模型与前一个模型相比，唯一的变化，是在账号和门店两个对象之间建立了关联关系，其他结构不变。实际上这样处理，保持了模型未来的扩展性。当未来需要全面实现组织机构管理时，将账号、门店之间的对应关系打断，在业务系统中实现遍历算法，以及组织树管理维护功能即可，整个数据底层基本不需要调整。

更丰富一些的客户模型

业务需求中很重要的一条，能够针对每个客户每个门店的个性报价，设置不同的系数表，结合时价动态计算商品价格。这里涉及到几个新的对象，系数表，报价单，为了让管理可控，系数表是全公司通用的多套参数集合，包括了商品和价格系数，给每个门店关联并且只能关联一个有效的报价单，报价单关联系数表，以保证运营人员只需要调整一次系数表，就能刷新到所有需要修改的门店的价格表。数据模型设计如下。

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

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

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

最后，我们来看一个建模错误导致灾难的例子。如果我们将上图数据模型中，账号和门店的对应关系调整成一对多，如下。

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

如果有一天，客户明确并要求必须支持一个门店被多个账号管理，也就是要实现账号和门店多对多的设计。实现此诉求，难度将非常非常大，因为从数据底层，到前端功能实现，都认为是一对多结构，如果要改成多对多，首先底层数据库结构得调整，所有历史数据要处理，其次，基本上所有涉及到读取账号和门店关系的功能代码需要全部重写，看似简单的一个改造，会造成一场灾难。

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

那么问题来了，是不是所有对象的关系，都应该设计成多对多就行了呢？也不对，比如门店和订单的关系，只可能是一对多，不可能是多对多，一个订单只能是一个门店提交的，现实世界中不存在门店和订单多对多的逻辑关系。

建模的难点和重点，就是将现实世界抽象成对象，描述其关联关系。如果这些对象和关系没有梳理清楚，流程、界面的设计都会是一笔糊涂账。

2、用户角色设计和流程图

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

电商公司分销业务部

分销管理员 – 负责业务稽查，审核，分公司账号的管理维护

分销运营 – 负责分公司客户的账号维护，报价管理

客户

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

客户采购 – 负责给门店下单

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

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

3、界面设计

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

模仿是最好的设计

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

拒绝花哨的前端

业务系统，不需要花哨的前端，不需要创意的控件。有很多初入行的PM，喜欢在交互设计上做太多的发明创造，对于业务系统，价值不大，并且会增加研发的工作量。我曾经见过一个业务系统，把其中的多选控件做的异常复杂，多选框中隐含了其他的交互形态，导致前端需要耗费大量的精力去定制开发实现，实在没有必要。选用准的控件方案，可以节约PM和前端的大量时间。

什么叫标准的控件呢？MS Visio或Axure里提供的可以绘制的控件，就是标准控件。不要在这些标准控件以外去发明创造控件！

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

4、权限设计

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

软件系统的权限设计包含两部分，功能权限和数据权限。功能权限是指不同角色可以操作的界面、按钮等等，例如某一个角色在订单查询页面能看到哪些字段，能操作哪些按钮；数据权限是指不同角色在同一页面中看到的数据范围，例如分公司管理员在订单查询页面能看到分公司的所有订单，而区域主管只能看到所在区域的订单。

功能权限设计的经典方法论是RBAC（Role Based AccessControl），描述了一套用户、角色、权限组的设计理念，简单的可以抽象为以下实体关系图。该理论具体的讲解，读者可在网络上自行查阅，请读者理解RBAC的数据模型图，可以看出，软件系统的设计，即便是权限管理体系设计，最终也都会归结抽象到数据模型的设计。由此可见，抽象建模能力，是PM必须掌握的核心技能。

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

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

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

客户的组织架构如下。

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

5、技术方案与项目实施

产出PRD以后，进入了技术设计和实施环节。当然，对于一套全新的系统，技术设计可能很早就已经启动。再往后，就进入实施环节，以及上线后的持续迭代和产品运营环节。以后有机会单独介绍此部分话题。

六、总结

至此，我们结合一个实际案例，完整的介绍了一套系统从无到有的设计。介绍的重点是调研、架构、模块、建模、权限，对于交互、界面等细节一笔带过。实际上，文中已经多次强调，并且读者现在应该也有了充分的认识，抽象、流程、建模才是业务系统设计的重点和核心，只有将业务最本质的东西高度剥离并正确抽象，才能构建一套灵活强大的系统。

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

具备基本的商业、管理、运营常识；

理解商业模式、业务目标、组织、流程；

理解公司的企业应用架构和系统现状；

具备将客观世界抽象成架构、模块、模型的能力；

路漫漫其修远，后端产品经理的成长是一个厚积薄发的过程，需要长期的坚持、积累、思考。希望本文能够帮助读者对系统的设计有一个大体的认知和理解，并融入到工作中，形成更深层次的思考。

作者：杨堃 VIPKID 产品总监 ，决胜B端作者，曾任百度高级产品经理，曾从无到有建设多款企业级业务产品。