B端产品设计：整体方案长这样？

经过充分调研，我们了解了业务现状和问题。接下来是不是应该画原型写PRD了？其实不然，还需要再输出“整体解决方案”。

整体解决方案是一个产品的实现思路、明确产品的基本框架和范围。只有确定了整体方案，才能够细化后续的工作内容，为产品做详细设计。

方案主要由五部分组成：梳理业务梳理、明确产品定位，功能模块设计、划分实施阶段、应用架构设计。

方案呈现形式根据团队的规范要求输出即可，如果团队没有输出要求，产品经理也应和对应干系人沟通情况并达成共识。达成共识的内容需要公示，让团队及相关人知晓。

接下来依次讲述整体解决方案的各组成部分。

01 梳理业务流程

在调研时已经梳理过业务流程，明确了在业务运行时各环节各角色的具体任务。

现在我们再次梳理业务流程，是需要进一步将业务和系统（产品）相结合，确定需要系统介入的环节、保留线下操作的环节、对接三方系统的环节。

系统不是纯粹的将线下操作改为线上操作，而是根据业务现状、项目目标、资源限制等因素，设计出符合当下需求又为未来保留了拓展可能性的灵活产品。

举例：

Z公司TMS项目中，调研得知目前的紧急需求在于2部分：

• 运输任务初步信息化，提高作业环节效率；
• 车辆执行监控，掌握车辆位置相关信息。

关于运输任务：任务来源于上游的业务系统，由于时间和资源限制，暂不考虑系统对接；所以订单创建与管理、运单调度等环节均由本系统操作；在运输执行的交接环节涉及多业务方，暂时保留线下操作。

关于执行监控：因为对司机行为管控力度不足、软件对手机设备要求等因素影响，最终采用安装GPS硬件设备的方式采集车辆执行信息，TMS系统和GPS设备系统对接获取相应行驶数据，从而达到监控目的。

02 明确产品定位

当我们知道了产品会参与哪些业务部分，这也要求我们为产品做好“定位”。

定位的意义在于明确产品是做什么的，即：针对谁（角色）在什么场景下提供什么支持。这样也就限定了产品对业务支持的边界，或者说是功能边界。

定位是锚，让我们知道自己在哪里，该做什么，让产品设计不偏离跑道。

举例：

Z公司TMS项目中，运输执行的最后环节是将物料运至仓库签收，因此在运输送货和仓库收货会有交接；业务场景中，车辆送货到达仓库后进行挂号排队，然后等待叫号卸货。

在此之前我们为“TMS”做好定位：为运输任务管理和任务执行提供支撑，以此为中心拓展服务内容。

在实际场景中“排号”属于仓储业务范围，同时为了后续系统的拓展性考虑，将排号划分到WMS系统中，即便WMS的1.0版本只有排号功能；现阶段车辆达到仓库的自动排号由TMS向WMS传数据并触发任务，以此支持双方后续业务的开展。

03 功能模块设计

从表面上看，系统就是由各个功能模块通过逻辑组装在一起的集合体；实际上是基于业务场景，对对应角色在该业务环节中需要做的操作进行抽离，以此提炼出功能模块。

提炼过程中常出现对资源、业务的管控边界模糊问题，就需要及时代入实际业务场景验证，或者和业务负责人沟通，避免设计偏差。

当功能模块提炼完成后，需要规划出系统的菜单结构。菜单结构犹如身体骨架，具体功能犹如不断填充的血肉；菜单万不能随意摆放，结构若是不符合整体逻辑，对系统设计和用户体验都是极不友好的。

举例：

Z公司TMS项目中，通过业务逻辑能够划分出前期资源准备、运输任务执行、运营结果数据。

所以在提炼功能模块时1期功能主要分为以下：

• 资源管理：物料管理、供应商管理、承运商管理、车型管理、车辆管理、司机管理。
• 业务管理：订单管理、运单管理、车次管理、异常管理（运单）。
• 数据报表：数据概览（首页）、车次统计。

上述功能为主要模块，在实际场景中存在其他功能；如“在途监控”，调度需要观察执行任务的所有车辆当前状态，此功能不能归属于具体车次；因此在设计菜单时需要充分考虑全局。

1期功能菜单如下，后续功能可进行延伸：

04 划分实施阶段

划分实施阶段又称为演进蓝图，可以理解成系统规划不同的发展阶段。

俗话说一口吃不成胖子，产品也不是一次就开发成最终版；往往基于重要紧急程度、功能影响面等因素，先明确功能优先级，进而划分产品不同阶段的功能模块以及实现节奏。

阶段划分的影响因素有很多，比如项目资源（时间、人员、支持…）、业务诉求（当前诉求和未来诉求），要根据权重综合考量。

举例：

Z公司TMS项目中，在调研时已明晰了当前重要紧急需求，因此以实现此目标为主。其他功能都要靠边站，哪怕很有技术含量、提升用户操作体验等。

车辆调度时运输任务执行的核心之一，系统至少可以通过2种方式实现。

• 调度员在系统中手动指派车辆和司机；
• 系统自动指派车辆和司机，系统通过维护物料和车型匹配数据、送货时间和车辆任务匹配等多种参数自动指派。

方式2比方式1从工作效率和操作体验上都加分不少，但是在1期的项目目标、项目各项资源、实际场景（前期业务量不是特别多）约束下，选择了方式1来实现调度功能，方式2则规划至2期阶段实施。

05 应用架构设计

应用架构属于技术层面的考虑，关注系统的整体结构。需要考虑公司不同系统之间的对接；考虑新系统在公司战略定位下延伸出的诉求（有时和项目目标有所区别），考虑公司或项目的其他诉求。

系统架构对产品的拓展性影响深远，需要和技术及相关负责人充分沟通后才能进行应用架构的设计。

举例：

Z公司TMS项目中，因为业务方当前存在ERP、SAP等多系统同时运行，所以要考虑TMS系统如何和现有系统架构进行结合，不同系统模块之间如何进行更好衔接。

复杂的暂且不论，简单的如物料基础数据是通用数据，多系统维护成本较大，后续要进行多系统复用；所以从技术实现成本、降低数据偏差异常、减少用户重复工作等多方考虑；基础数据以SAP系统为准，其他系统进行数据调用。

温馨提示：

• 产品设计和规划不是一经确认就固定不变的，而是随着设计深入、业务发展、环境变化而变化，是不断进行调整的。
• 设计系统结构时需要考虑满足现状，同时兼容未来发展，满足系统的拓展性。
• 系统小的调整经常有，大的调整只有业务模式发生较大范围或本质变化，功能模块才会出现结构性的变动。

以上。

本文作者 @耳目不染 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！