从0到1教你设计业务系统 - 4

简介:通过一个案例,手把手教您从无到有设计一套业务系统,B端产品经理必看!

从0到1教你设计业务系统 - 1

从0到1教你设计业务系统 - 2

从0到1教你设计业务系统 - 3

从0到1教你设计业务系统 - 4

从0到1教你设计业务系统 - 5

四、系统细节方案设计

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

1、实体建模

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

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

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

(1)理想化的客户模型

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

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

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

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

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

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

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

从0到1教你设计业务系统 - 4_第1张图片

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

从0到1教你设计业务系统 - 4_第2张图片

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

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

(2)简化版的客户模型

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

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

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

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

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

从0到1教你设计业务系统 - 4_第3张图片

(3)更丰富一些的客户模型

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

从0到1教你设计业务系统 - 4_第4张图片

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

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

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

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

从0到1教你设计业务系统 - 4_第5张图片

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

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

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

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

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

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

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

电商公司分销业务部:

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

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

客户:

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

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

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

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

3、界面设计

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

(1)模仿是最好的设计

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

(2)拒绝花哨的前端

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

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

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

4、权限设计

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

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

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

从0到1教你设计业务系统 - 4_第6张图片

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

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

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

从0到1教你设计业务系统 - 4_第7张图片

客户的组织架构如下:

从0到1教你设计业务系统 - 4_第8张图片

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

从0到1教你设计业务系统 - 4_第9张图片

5、技术方案与项目实施

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

你可能感兴趣的:(从0到1教你设计业务系统 - 4)