产品复盘：从0到1设计业务系统

一、为什么要由专业的PM设计业务系统

很多公司特别是创业公司都低估了系统架构设计的重要性，特别是前期业务系统的架构地基没打好，业务模块设计随意和混乱，新增的功能随意摆放，不仅导致业务人员使用系统时产生困惑，同时还会导致开发人员编程设计混乱。以至于随着公司的业务发展，后期重构系统时所花费的精力和成本都是难以想象。

企业创新的业务模式，决定了必须要有一批业务系统设计人员，参与理解公司特殊的业务诉求，利用互联网产品的开发方式和方法，快速、合理的设计系统支持业务。

业务系统的产品经理，要深刻理解公司的经营管理、业务模式，参与制定业务决策，才能设计合理、靠谱的业务系统。本次分享通过复盘搭建渠道分销平台，谈一谈PM如何参与设计业务系统的方法。

业务管理系统设计流程

1、业务方案设计：明确业务角色和工作流

业务调研

设计业务系统，必须要透彻理解业务现状，而理解业务最好的方法：

• 第一，有机会参与轮岗到业务环节，亲身体会业务人员的工作状态；

• 第二，调研访谈。在调研之前，需要提前制定访谈计划，安排好访谈的对象即参与的业务人员，明确调研目的，提前准备好问题，让访谈更加高效。

组织架构

通过业务调研，对业务体系大体上有一定的了解之后，梳理出组织结构图：

组织结构将影响业务系统设计的以下几个方面：

• 组织结构的层级决定业务系统的工作流，间接决定业务流程；

• 组织结构是否清晰决定权限划分是否正确；

业务流程

通过调研，梳理出对于渠道销售的业务流程，例如下图：

需要特殊说明的是：

• 如果业务部门已经有成熟的业务流程，落地可行且执行了一段时间后，效果不错。PM在前期规划上先把这个方案搬到线上，基于目前的工作流设计功能。

• 如果业务部门还没有落地可行的业务方案，PM就需要和业务负责人一起梳理、制定业务流程，梳理业务中有哪些业务角色参与工作？各个角色参与了哪些工作阶段？业务角色是否跨部门协作？业务环节是否可以通过部门进行拆分？

• 如果涉及多个部门协同及分工，那么在确定业务流程时及时与多部门业务负责人沟通确认

业务诉求分析

基于目前的业务流程，需要和业务负责人确定业务系统现阶段需要解决的问题，实现对应的功能，如下：

• 支持将渠道信息从线下纸质合同录入到线上系统中，优先级：高；

• 支持二级分销模式，优先级：高；

• 支持对账报表，优先级：高；

• 支持账期提醒和预付款模式，优先级：低；

• 处于业务流程中必不可少的环节定为较高优先级，扩展功能和针对部分客户的小众功能，定为较低的优先级。

经验总结

• 必须要有标准化的业务流程，明确系统边界，这一点一定要和业务负责人确定清楚。标准化=高效率。

• 了解业务中参与的角色、包含哪些关键工作节点，工作流程是怎样的？

• 如果有必要，在最终与业务负责人敲定业务方案时，最好拉上技术负责人，一方面，有利于技术人员提前理解业务，另一方面，技术负责人可以站在技术角度为技术选型做好准备。

• 业务人员作为系统的用户，相对来说，更能明确自己的需求，但是在沟通交流中，业务负责人可能会提出较为复杂，认为“完美”的系统，这个时候PM要过滤出重要的需求通过MVP等方法排出需求优先级，缩短研发周期。

• 不要依赖业务方提需求，要帮业务方想方案，由于角色的不同、思维方式的不同，业务方同学只能提出自己最终想要的功能，提出模糊的功能需求，并不一定能提出自己真正的需求，产品经理需要主动思考业务中的问题，并形成业务需求。

• 扩展性和效率之间需要做权衡，有的时候想得太多容易给自己和团队挖坑，所以平衡扩展性和效率是门艺术

2、系统架构设计：业务模块拆分和权限划分

业务模块

通过调研对业务有了整体的认识，与相关的业务人员确定了业务方案，接下来就是结合业务诉求与目标，梳理出整体的业务系统的架构图，如下：

经过分析，这次业务系统迭代主要的目的是为了支持渠道销售的业务诉求，系统已经有底层的业务模块可以直接复用，减轻了新平台的实现难度和开发工作量，渠道销售模块只需要聚焦业务特殊独立的地方，渠道销售业务的独特性在于前置的渠道管理维护和后置的账单管理。

电商业务是系统主要的业务流程，也是最底层的业务逻辑，有完善的订单管理和出库管理。渠道下单后，产品的出库配送直接复用已有的出库管理，后续为客户提供的服务。

如：样本检测和出具报告，业务流程完全一样。只需要对订单管理的数据结构稍加拓展即可支持（订单管理中的客户信息与渠道管理的渠道信息关联性），这样就可以保证订单、仓储、样本、报告等模块业务逻辑不需要重写或改造。

需要特殊说明的是，渠道销售的商品可以直接复用已有的商品SKU，但每个渠道对应的商品价格都不同，因此需要将商品价格维护在渠道管理模块中，以支持财务和账单管理。

业务模块要做到“高内聚、低耦合”。

内聚描述的是模块内部各个元素彼此结合的紧密程度，越紧密，内聚性越高，单一责任原则越强，单一责任指一个模块负责一项任务。

耦合描述的是模块外部各个模块彼此结合的紧密程度，越紧密，耦合性越强，模块的独立性越差。

权限划分：RBAC权限设计模型

权限管理三要素：账号、角色、权限

账号：业务系统的用户就是业务人员，每个业务人员分配一个账号，通过给业务人员分配账号验证身份登录业务管理系统进行操作。新增账号时需要设定：用户名、密码和角色，如下：

角色：角色用来控制账号的查看和操作范围，在系统中由于权限较多，不可能每个每个账号都分别设置权限，且由于账号对应的业务人员从属同一岗位和部门，工作内容多有重合。在创建账号时，就可以直接赋予账号不同的角色，从而将权限通过角色给到这个账号。一个账号可以绑定多个角色，一个角色又拥有多个权限。

权限内容包括：操作权限、查看权限、数据权限

数据权限：即角色能看到的数据范围。比如销售总监能看到销售部门下所有销售员的销售数据，而销售员则只能看到自己的销售数据。

页面权限：即角色在业务系统中看到的页面内容和元素。比如对于订单管理，客服人员可以看到订单的基础信息和详情等所有信息，而仓储人员只能看到订单的基础信息。

操作权限：即角色可以进行的操作，如增删改查。同样拿订单管理举例，客服人员可以对订单进行删改，而仓储人员却无法对订单进行删改，可以查询。

对于母子账号管理，在创建角色时，就已经限定了数据权限。在给角色选择权限分配时，需要选择该角色的对应的页面权限（如，列表信息：渠道商）和操作权限（如，查看详情）。

Tips：

• 一个账号对应多个角色时，当该用户登录系统时，他在系统中的权限是所有角色权限的并集。

• 创建角色之前，需要明确各个部门之间的业务范围和工作职责，根据这些业务人员划分权限。随着公司的业务和后台系统功能的改变，各个角色的权限是需要不断完善和调整的。

• 如果公司管理比较扁平化时，同一部门的业务人员会共同使用同一角色，数据权限相同。但如果部门的职级关系需要映射到业务系统中，那么在创建角色时需要增加一个拓展的功能点-母子账号管理，以此来划分数据权限。

3、产品原型设计及PRD

PM在绘制原型时需要跟开发部门确定开发系统时使用什么样式的前端框架，这样就不需要UI设计师参与到业务系统的工作中，交互也可以直接引用开源的前端框架，提高效率。

原型尽量使用高保真制作，一方面排版舒适，良好的体验是团队的润滑剂，另一方面，将数据项、列表项等细节信息已经绘制在原型中，不需要在文档中特殊说明。

基本信息

基本信息即本次迭代产品说明书的总览，包含：

修订历史：包括修订时间、版本号，修订历史的作用是为了产品人员方便后期查阅，一旦产品人员变动或工作交接给新员工，让新的产品负责人查看产品迭代历史

版本说明：即本次产品改动修改了什么（功能），新增了什么（功能），优化了哪些（功能），

业务背景&需求分析：在产品评审的时候，一定要和技术的同事交代清楚这次开发背后的目的是什么？谁提出来的需求？需求分析的结果什么？要不然技术同事会听着很懵，评审时如果技术同事很少和你互动，那么技术的同事就只能低头敲自己的代码，完全不知道自己设计的这个功能是干什么的。

业务流程图

PRD的灵魂，重中之重，不多说，PRD可以什么都不写，但是流程图必须要有。

权限说明

如果这次产品迭代是新增业务模块和业务逻辑，那么可能在系统中新增了一个角色，需要在文档中说明新增的角色名称和该角色下分配的具体有哪些权限，同时还需要说明业务人员的账号增删改了哪些角色。

如果是优化了业务模块或业务逻辑，调整业务流程，那么可能需要在文档说明系统角色中调整的权限。

数据说明

数据类型是什么？是否必填？长度是否有限制？是否校验唯一性？（如用户名，是否唯一？）有无特殊说明？（如密码以星号展示）是否有默认值？刷新数据是否还在？空数据展示什么？

交互说明

模态框，弹出框、提示框等的样式，按钮、筛选项的状态和位置区域，页面切换样式，提示样式？（成功提示、失败提示、异常提示），操作反馈（点击、滑动、缩放等等）。

页面规则：是否需要使用面包屑，列表页的数据条数，排序规则等，空数据、页面报错等页面。

操作说明

操作是否可以撤回？（如回滚功能，回收站功能）？关键操作之前是否需要给予提示/警告（如删除操作）？是否需要为某些操作添加特殊说明（如后台产品，有些操作并不是所有用户都了解的，有必要给出特殊文字说明）？操作如果异常/失败/强制中断，如何处理？是否有备份？操作中是否允许中断？

权限说明

如果这次产品迭代是新增业务模块和业务逻辑，那么可能在系统中新增了一个角色，需要在文档中说明新增的角色名称和该角色下分配的具体有哪些权限，同时还需要说明业务人员的账号增删改了哪些角色。

如果是优化了业务模块或业务逻辑，调整业务流程，那么可能需要在文档说明系统角色中调整的权限。

业务系统产品设计的特点

更关注业务流程与业务逻辑

前台产品注重用户体验，站在用户角度设计产品，考虑用户使用场景，打磨产品细节，让用户用着爽。相比较而言，后台产品更注重实际的业务逻辑，用户在前台产品的每一个触发操作行为，产品如何应答，需要处理那些数据，如何处理数据，如何传输数据，传输哪些数据给前台产品与用户交互互动。

后台产品设计更注重功能实现，后台产品设计时更贴合产品MVP设计的理念，对于后台业务系统来说，很多功能模块可以采用开发成本更低的临时方案，即使体验不好，业务人员操作效率不高，只要能保障功能可以实现，业务逻辑处理正常，业务可以正常运转即可。

需求更为明确

用户端的产品需要通过不断的调研分析、需求挖掘，测试验证，提升产品价值。而业务系统的用户是内部的业务人员，业务方往往都是主动推进需求。

但是，对于业务人员的需求仍然需要判断其真实性及目的。由于业务系统的业务逻辑的复杂性，业务主流程之外的异常流程也较多，如果没有正确理解需求的真实意图，就会导致业务系统的功能叠加，系统愈发混乱。

高效率、灵活性、可拓展

而内部业务人员在使用后台系统时，一般都属于工作范畴，所以要讲究高效率，如此才能快速高效的完成相应任务，说的更宏观一些，能否提高业务人员的工作效率是衡量业务系统好坏的标尺。

高效率：比如，在设计报告打印管理时，业务人员需要接收从打印厂中打印完成的报告然后交付给下一个部门，报告就在多个部门中流转产生多个状态变更。相应的业务人员需要标记每个报告的状态变更。为了严谨防止实际操作中业务人员出现操作失误，业务人员需要一个个确认报告的状态变更。如下图：

但在实际使用场景中，业务人员经常从打印厂接收一批报告，报告数量较大。业务人员可能要重复性的操作标记每一个报告的状态变更，这个时候，“批量操作”、“全选”功能就解决了业务人员重复性的操作，效率较低的情况。

再比如在下载excel表格时，状态自动变更，而不需要业务人员手动调整状态。

灵活性：灵活性处理的是同一业务场景下，某个环节一但出现异常，系统可以进行补救，从而使该业务场景下异常状态回归正常业务逻辑，跑通业务流程。正常业务场景是，用户购买基因检测产品后，我们将采样盒邮寄给用户，用户自助将采样盒绑定到自己的账号下，并完成样本采集，后期才能查看报告。

有个异常的业务场景是，用户忘记绑定样本并邮寄回来，用户没有任何补绑的机会怎么办？也就是说在前台的用户端产品，对于这个样本没有任何补救的机会，最后考虑只能从业务系统进行优化，调整系统的灵活性。即使用户没有绑定自己的样本，客服人员可以在后台帮助用户填写信息完成绑定，用户可以在后期通过手机号索取到自己的样本。如下图：

拓展性：拓展性是指业务系统可以处理不同的业务场景，让不同的业务场景可以兼并符合同一业务逻辑。

上一点提到的业务系统的灵活性主要符合的场景是单一用户完成样本绑定，属于2C业务。如果是2B业务怎么办呢？通过调研之后，我们了解到2B的业务场景完全不同于2C的业务场景，2B大企业是通过召集大批量的客户集中在一个会场中完成样本采集。

对于2B的客户来说，不需要用户自己单独进行绑定采样盒，因为2B的大企业已经有了客户的个人信息。对于这种业务场景，设计一个“批量导入样本”的功能，2B销售员只需要通过Excel表格将客户信息录入到系统中就可以完成采样盒绑定。如下图：

以上，本次的 《产品复盘：从0到1设计业务系统 分享结束》，希望对你有所帮助！

作者：独猫X