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系统为准,其他系统进行数据调用。

温馨提示:

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

以上。

 

本文作者 @耳目不染 。

版权声明

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

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部