导读

本文将以一个案例,向读者逐步揭示一套业务系统从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以后,进入了技术设计和实施环节。当然,对于一套全新的系统,技术设计可能很早就已经启动。再往后,就进入实施环节,以及上线后的持续迭代和产品运营环节。以后有机会单独介绍此部分话题。

 六、总结

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

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

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

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


作者:杨堃(微信号公众号goYangKun),9年互联网研发、产品设计经验,曾就职于传统外资保险公司,百度,现就职于vipkid。