每个TOB生命周期阶段都有着其应该对齐的目标及其关键任务，本文就产品方案设计阶段的目标和关键任务展开分析，详细介绍产品可执行落地的全过程，希望带给你一些启发。
上一篇分享了B端产品的“产品规划与调研”阶段的目标和关键任务，本篇将分享“产品方案设计”阶段的目标与任务。这阶段承接产品规划，将整体规划细化落地，形成可落地执行的产品方案。在这个阶段也是对产品经理基本能力的考验，包括：需求转化能力、复杂逻辑处理能力、文档输出能力等。
目标：梳理业务流程，形成满足需求且可落地的解决方案。
关键任务：
首先，需要明白什么是 “业务流程”，与之相对应的是 “系统流程”。
业务流程： 为达到特定的价值目标而由不同的人分别共同完成的一系列活动。活动之间不仅有严格的先后顺序限定，而且活动的内容、方式、责任等也都必须有明确的安排和界定（百度释义）。简而言之，业务流程的梳理就是了解完成某一特定业务，不同业务人员需要先后负责完成哪些“任务”。
如：为了完成合同的审核，需要由销售人员起草合同，提交后经销售总监对合同产品报价确认后，给到公司法务进行法务风险评估，再由高层领导进行审核确认。一个合同审核的业务流程，涉及了多个人员，包括：销售、销售总监、法务、高层领导，每个角色的人员在合同审批的流程里面，有先后顺序，也有各自需要确认的内容。
对于业务流程，核心关注点在于“做什么”，即：不同角色的人员在流程的不同环节需要完成什么业务。
系统流程：为完成特定的业务流程，不同人员需要在系统中完成一系列指定的操作，留存相关的数据。
如：为了完成合同的审核，销售人员需要在CRM系统中维护合同信息、合同产品报价；合同提交后，销售总监在CRM系统中对合同报价进行确认，报价有问题的在系统中进行修改；销售总监确认后，法务在CRM系统中进行确认，如有法务风险，则在系统中进行记录；法务确认后，高层领导在OA系统中对合同进行审批。
对于系统流程，核心关注点在于“怎么做”，即：不同角色的人员在哪个系统中需要完成什么操作。
先有业务流程，再有系统流程，系统流程是将业务流程系统化的过程，这一过程也是将业务需求转换成系统解决方案的过程。
（1）如何梳理业务流程？
①明确业务目标是什么
确认业务目标，即：明确业务范围，确定需要了解的业务流程是什么。
对于业务流程的范围，可以定义地很广泛，也可以定义得很聚焦，比如：企业从生产到销售到服务的过程可以定义为一个业务流程；但是拆分出来，产品的生产过程、订单的下单流程也可以分别定义成一个业务流程。
所以，当我们去梳理业务流程时，需要先明确流程的范围，即流程的起点与终点。这个起点和终点是根据业务目标去确认的。如：当我们去探讨“如何完成一份合同的制定与确认“，那么流程的起点就是合同的起草，流程的终点就是合同完成确认。
②流程涉及哪些部门哪些角色的业务人员
一个完整的业务流程中，需要涉及到哪些部门哪些角色的人员协同完成。以上面的合同审批为例，整个涉及到：销售部的销售员、销售总监；法务部的法务顾问；高层领导；
注意：梳理涉及的业务人员时，需要尽量梳理出这些人员对应的职位或者职责（如：销售业务员、销售总监），而非具体的人员（如：张三、李四）。因为具体的人员因调岗、辞职等原因，变化频率时比较高的，但是职位或者职责是相对固定的。
③梳理不同角色人员要完成哪些“任务”
业务流程中，不同的人员需要完成哪些业务。以上面的合同审批为例：
④各“任务”之间的关系、规则
明确各“任务”之前的先后、分支、判断等关系，根据“任务”的顺序与规则，将各人员的“任务”串连起来便是完整的业务流程。
（2）“业务流程的梳理两大原则”
“有始有终”：根据业务目标确认业务流程范围，保证业务流程可以闭环，不能中途戛然而止。
以上文的合同审核为例，探讨“如何完成一份合同的制定与确认“，那么该流程不能法务部确认完之后就终止。在这个环节，合同并没有真正完成确认。
当然，流程的终点需要匹配业务目标，如果是探讨“如何完成合同的起草”，那么上述的流程在法务确认后终止却也可以说通。
“有所取舍”：对于描述业务流程的颗粒度需要有所取舍，不可太过细致，也不可太过粗糙，应以“能够清晰描述流程，指导业务顺畅流转”为原则。
以上文的合同审核为例，“合同信息录入”这一节点，并没有细致地去描述录入合同时需要录入合同哪些信息、是否需要上传电子合同等。
描述业务流程的颗粒度，有时也需要结合查看人的需求。如果是管理层查看，可能并不关心太过流程细节，更关系流程的流转和关键管控点；如果是执行层查看，那么可能更关心细节，细致到如何能完成各个“任务”，如何完成工作直接影响到执行层每日的工作量。
（3）如何输出业务流程图？
业务流程图的输出没有固定的形式，可使用普通流程图或者泳道图或者其他图示方式进行呈现。推荐使用泳道图进行展示。泳道图：泳道图可使用Visio（本地软件）、ProcessOn（在线平台）进行绘制；
泳道图一般分为三个维度：职位维度、阶段维度和任务维度。
职位维度：通过部门/职位进行区分，不同部门不同角色得人各用一条泳道进行区分；如下图中横向排布的泳道。（不建议通过责任人进行区分，如：张三/李四。因为责任人可能因为职务变化、辞职等原因频繁变化）
阶段维度：通过任务阶段来区分，明确各阶段需要处理的任务环节；如下图中纵向排布的泳道。（非必要维度，可视个人绘制习惯而定）
任务维度：不同部门/职位的业务人员在不同阶段需要处理的任务；如下图中的各流程节点。
（1）如何梳理系统流程？
①划分系统边界
对于流程各环节，需要先划分哪些“任务”需要在哪个系统中完成，明确各系统功能边界。
以上诉合同流程为例，可以将合同流程各环节划分到不同业务系统，合同起草、合同报价确认、法务风险确认在CRM中完成；合同审核在OA系统中完成；合同产品生产、入库出库、物流运输、物流签收可在ERP系统中完成。
系统边界的划分，需要匹配不同业务系统的定位以及当前产品的产品定位。
如果是标准产品开发，则需要尽量减少对外部系统的依赖，尽量在本系统中完成业务流程的流转。否则，当产品销售时，如果高度依赖其他系统才能完成业务流程的运转，那么就需要与其他系统打包销售，这将降低产品的竞争力。当然，这也需要和公司产品策略相结合，如果产品策略是希望整合多套产品形成整体解决方案，那么各系统的边界则需要根据不同产品的定位来划分。
如果是客户定制化产品/项目开发，则需要根据客户内部业务系统定位进行划分。
②明确各业务环节的系统管控点
由于业务流转的需要、管理的要求或者其他原因，对于业务流程中关键节点，业务上会有一些管控要求。
如：合同录入时，需要必须上传合同附件，电子附件可以作为流程审批的依据，也可以在线上进行留存，方便后期查看。类似这部分业务管控要求，在系统流程设计时需要形成系统管控点。
③确定各系统数据交互的触发节点
明确单据在各业务系统之间流转的触发节点，即：什么环节可以将数据同步推送至其他业务系统。
如：CEO确认合同审批通过时，将合同同步至ERP系统进行生产。
④明确各系统数据的回传同步
单据在其他业务系统流转过程中，部分单据信息可能需要回传同步至源系统。
如：合同同步至OA系统审批后，审批结果（通过？拒绝）需要同步回传至CRM系统中，销售业务员可以及时了解合同审批情况；合同产品交付到ERP系统生产后，生产相关进度可能也需要同步回CRM系统中，对于销售人员而言，可及时了解到合同交付情况。
（2）如何输出系统流程？
系统流程同样可以使用泳道图进行输出，下方为示例：
与业务流程绘制的区别在于两点：
维度不同：业务流程的一般是职位维度、阶段维度和任务维度；系统流程的维度一般是职位维度、系统维度和任务维度。
即：系统流程描述了哪个职位的业务人员需要在什么系统完成哪些任务。
颗粒度不同：系统流程会比较细致地某一流程在系统中如何完成，以达到指导业务用户顺畅完成业务的目的。业务流程对于较细致的流程管控点并不一定会进行描述，系统流程则会较为细致地描述流程管控点及相关处理方式。
解决方案并非产品的PRD文档，而是用于向客户/用户介绍产品、介绍方案的介绍性文档，通常以PPT的方式呈现。
标准产品研发的过程中，不一定会需要产出解决方案，而是使用PRD文档描述需求与需求解决方案。
对于客户定制化项目/产品，多数情况下需要输出项目解决方案，向客户方业务人员（包括管理层、执行层）介绍项目整体方案内容，约定产品需求与范围。
（1）如何编写解决方案？
①了解方案汇报场景及汇报对象
不同的汇报场景汇报对象，解决方案的侧重点不同。对客户管理层汇报，会侧重于讲解业务管理方案、管理流程、项目价值等；对业务执行层汇报，则会侧重于讲解系统流程、业务管控点等。
所以，在编写解决方案前，需要先了解汇报的场景及对象，以明确方案编写的侧重点。
②方案需要呈现哪些内容（这里提供项目解决方案编写的基本框架思路）
项目概述：主要介绍项目背景、企业现状，核对项目目标。
项目概述篇是对整个项目定调的篇章，需要熟悉当前项目的背景、企业现状、业务流程等。
尤其需要关注企业高层领导对当前项目的看法与期待。高层领导对于当前项目未来能在企业的业务流程中扮演的角色和作用，是项目目标的核心提炼点，也是后续指导项目实施方向的关键因素。
整体业务解决方案：介绍基于项目目标、企业现状的整体业务管理方案。
结合项目目标和当前企业现状，对企业现有流程提出优化管理方案。核心是介绍新的管理流程、管理方案，输出整体业务规划蓝图、产品架构等。
详细功能设计方案：按业务流程分模块讲解各业务板块的流程、产品功能等。
根据各模块的业务流程、系统流程讲解模块功能设计，可包括：业务痛点、业务流程、系统流程、字段模型、权限设计、业务管控点、核心功能等。
对于整体业务解决方案和详细功能设计方案的内容占比和编写的细致颗粒度，需要根据汇报对象进行权衡。
当汇报对象是高层领导、管理层时，核心在于整体业务解决方案的介绍，详细功能介绍则介绍流程、管控点、核心功能即可，整体篇幅也应以业务解决方案为主。
当汇报对象主要是执行层时，整体业务解决方案的占比则可以适当减少，详细功能设计可写得更细致，可包括：系统流程、管控点、核心功能、字段模型、数据权限等。
除了上诉的介绍内容外，项目解决方案还可能会添加：项目实施计划、项目团队、项目风险等。这些内容可视实际情况添加。
MVP版本：最简化可实行产品。MVP版本这个词，在标准产品研发的过程中会听到多，说得浅显可理解一些，即是：通过较短的开发周期快速实现产品的基础功能，能够快速进入市场。随后通过获取市场反馈，不断迭代优化产品。
对于客户定制化项目/产品，很少会有MVP版本的概念，在项目立项时，就已经有基本明确的项目周期、需求范围。即使会有分版本迭代上线的情况，划分版本的依据更多的是根据客户需求的紧急程度来做划分。
那么，标准产品研发如何进行MVP版本的划分?
①明确产品目标，清晰了解产品需求
产品版本/迭代路线的规划，需要基于产品目标和产品需求去进行划分，对于各产品需求需要清晰了解需求背景、需求内容才能准确地定义清楚需求涉及范围、需求优先级。
②确定产品最简业务流程
基于产品主流程进行简化，在保证业务流程闭环的情况下，尽量减少业务流程环节，将一些非必须的周边环节均可归入迭代优化版本。
简化业务流程基本原则（以产品规划篇中讲解的车企销售线索管理为例）：
没有破坏产品目标的功能，不做；
销售线索管理模块目标：与外部获客渠道打通，实现线索从获取-跟进-转化的全过程管理。
下面列举几个线索模块的需求做示例：
能够暂时使用人工替代的功能，考虑不做；
根据线索相关信息自动分配销售人员进行跟进，不做，可由人工对线索进行分配。
销售线索一键转化成商机，可通过人工新建商机与线索关联进行实现，但是整体流程体验极差，需要规划进MVP版本。
客户定制化需求（适用客户范围比较小）的功能，不做；
线索分配时，需要根据销售人员（客服人员）当天是否上班进行分配，不做。
支持自定义配置的功能，考虑先用固定配置的方式实现。
线索可根据用户自定义设定的字段进行查重，不做。先按行业通用的默认规则（如：手机号码）进行查重。
线索转换成商机时，可自定义配置商机的基础信息字段从线索的基础信息中获取，不做；按固定的几个字段默认赋值进行实现。
③根据最简业务流程形成MVP版本需求范围
本文由 @茶话B端 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。