B端产品设计全链路SOP

B端产品设计全链路SOP

B端如何做产品设计？

B端产品设计相对于C端,更注重行业经3鳏口业务逻辑，所以设计思路

明显不同。本篇义章将和大家分享我在实际工作中不断优化的B端数字

化产品设计全链路流程，希望可以给你一些启发。

B端产品接收到的业务需求一般来自老板、业务方或者产品自己，如何

更高效、更准确的将其转为IT人员能看懂的产品需求就是考验产品经

理的设计功力了。

另外，在产品设计环节主要交付物有业务调研报告、产品地图、产品流

程图、数据宽表、原型界面、产品需求文档，如何把这些更有机的链接

在一起便是产品思维和产品方法论了。

一、调研报告

调研业务需求，一定要做的三步：

1.识别系统涉及的利益方

1.涉及的外部角色【客户】

2.涉及的内部角色【用户】

3.角色的职能【参与者、执行者、决策者】

4.职能的边界

5.角色、职能的交互

2.识别业务场景

梳理业务场景清单、业务处理流程，然后绘制出业务基本流程图。这也

是方便进一步识别业务当前各个环节出现的潜在问题。

控制场景

体系模块场景名称场景编码场景定义业务节

履预算控制采购预算一苜单3占KZ_001开单员确认采购开单苜单一采购需求.确认开I

财管预算控制采购预算.首单一扣减KZ_002采购订单确认订货首单一采购订单一审核通i

婕预算控制采购预算一首单一扣减撤回KZ_003采购订单确认订货后蚊回首单一采购订单一审核通i

财管预算控制采购预算一返单占KZ_004开单员确认采购开单返单一采购需求确认开单

财管预算捽制采购预算一次单一扣减KZ.005采购订单确认订货饭单一采购订单审核通过

婕预算控制采购预算一返单一扣减撤回KZ_006采购订单确认订货后蚊回返单一采购订单审核通过

预算控制采购预算一促销占KZ_007开单员确认采购开单促销一采购需求确认开单

婕预算控制采购预算一促销一扣减KZ_008采购订单确认订货促销一采购订单审核通过

财管预算控制采购预算一促销一扣减撤回KZ_009采购订单确认订货后装回促销一采购订单审核通过

预算控制物流一调拨费用占KZ_010业务产生物流调拨请求物流调拨请求确认完成a

履预算控制物流_调拨费用一扣减KZ_011仓库完成调拨出库仓库调拨出库完成时

婕预算控制物流一调拨费用一扣减撤回KZ_012仓库完成调拨出库后做回仓库调拨出库撤回完成a

3.识别问题矛盾点

一定要识别业务当前遇到问题的痛点，产品要解决的什么问题？目前B

端产品也是趋于稳定,当下企业更注重业务价值导向，而不是一味的技

术导向。

最终，输出产品调研报告。

二、产品地图

基于上述业务调研报告才妾下来就需要输出产品地图，即构思系统骨架。

产品地图，它是系统设计的一个整体性指导性文件，要想拥有一个完善

完整的产品地图是急不得的。

那如何完善自己的产品地图？一般我的操作思路大致是：通过不断的梳

理业务场景、业务流程、业务规则，按照低耦合、高复用原则，以及

MVC的软件架构模式，逐步确认产品骨架。有了产品地图也就有了产

品规划方向，便可以着手做原型设计了。所以可以看出我将产品地图作

为产品设计的整个环节的主要链条以及切入点。

系统架构设计的重点原则要做到低耦合、高复用：

•所谓低耦合：按照业务相关性设计多个系统应用，它们之间通过

API进行交互。这样，单个应用的升级，对其他应用的影响就小

很多，从而提高了系统的敏捷性。比如，把预算管理中的预算编

制、预算控制、预算审批就可以独立为多个应用。

•所谓高复用：将各个模块通用的功能抽离出来，单独形成一个系

统应用。这样，一方面确保了信息来源的一致性，另一方面也简

化了系统架构，避免了重复开发。

通常产品地图包含以下层级，每层都是起到承上启下的作用：

•业务层：主要展示上游系统功能模块或者下达操作的指令。

•网关层：主要提供通用接口供上游调用，完成业务层和应用层交

互，而无需关注架构或底层发生的怎样的变化。

・应用层：主要负责对数据层的操作，即系统逻辑的组合模块，也

是系统的主要核心逻辑层。

•数据层：主要展示各类模块的数据宽表，通常是结合上下游，以

及系统响应模块对数据需求整合而成。

•服务层：主势是供基础服务能力，比如为应用层传递的消息，为

数据层提供的基础资料等。

示例如下：

业务层

网关层

应用层

数据层

服务层

三、产品流程

B端产品往往需要支持多部门、多角色协同。因此需要在整理完业务行

为与场景后，找到各角色与职能，我们便可以提炼出系统核心运转的产

品流程。

在范围上，整体流程图需要覆盖所有关键流程。在颗粒度上，只需要展

示关键操作环节即可，不需要细致到具体功能页面。

示例如下：

四、数据宽表

数据宽表确认方式，一般是结合上游应提供给我的数据，下游需要我提

供的数据，再结合我自己需要的数据，将三者归纳聚合在一起，就有了

数据宽表及API规范。

关联单据预算计划单

传输节点预算计划编制时

【产品】XX

财务对接

【研发】XX

财务数据标准

字段名称必填业务意义

单据IDY主键ID系统自动生成；8位

预算计划单Y预算计划单编号

预算表名Y创建预算编制表名

创建日期Y预算编制日期，格式为年月日

创建人Y创建人姓名

0:新增

1:修改

变更类型Y

・1：注销

【默认新增，标识同一批创建的数据】

调整明细list（单个预算组织所需呈现的信息）

明细IDY系统自动生成明细ID;自动生成；8位

1部门

预算对象类型Y2经营期

3.品牌

选择需要控制的业务类型，具体枚举值如下

1.采购预算-首单

2.采购预算-返单

业务类型Y4.物流费用

5.调拨费用

6.固定仓租费用

7.非固定仓租费用

预算期间Y预算额度计划开始生效日期，年月日■年月E

分配境内/境外的预算

是否境外Y1.是

2.否

五、权限管理

B端业务开展，是基于多个部门的相互协同和相互监督的。当用户在使

用B端系统时,流程流转、数据安全性都必须符合企业协祠与管控的要

求。

因此就需要我们针对系统设置权限管理，这是必不可少的一步。权限管

理说明一般需要包含系统权限树说明以及对应权限配置要求，方便IT

人员在ERP上针对角色分配权限。

示例如下：

预算管理系统权限配置

系统一级节点二级节点三级节点四级节点

预算编制预算计划

预算执行执行服务

权限树说明站点容器财务预算管理预算调整

预算调整预算调配

预算分析可用余额列表

系统角色角色描述角色类别权限明细

预算管理员预算预算管理财务/IT所有菜单及数据权限

权限配置要求普通角色预算查看业务预算分析模块查看权限

站点容器

预算额度拆分审批流发走

计划管理发起审批业务

预算额度调整审批流发立

六、产品原型

基于以上内容，确定产品规划后，我们便需要思考系统功能页面的流转

图了，这里主要是设计用户可操作页