每个TOB生命周期阶段都有其目标和关键任务，这些目标和任务应该保持一致。本文分析了产品方案设计阶段的目标和重点任务，详细介绍了产品实施的全过程，希望能给你一些启发。

第一部分分享了B端产品“产品策划与研究”阶段的目标和重点任务，本部分将分享“产品方案设计”阶段的目标和任务。在这个阶段，我们进行产品规划，细化整体规划，形成可落地实施的产品方案。这个阶段也是对产品经理基本能力的考验，包括:需求转化能力、复杂逻辑处理能力、文档输出能力等。

1.产品方案设计

目标:梳理业务流程，形成符合需求、可实施的解决方案。

关键任务:

1.业务流程梳理:每个模块业务涉及哪些不同部门、不同角色的员工，每个员工负责哪些业务？

首先要明白什么是“业务流程”，它对应的是一个“系统流程”。

业务流程:不同的人为了实现特定的价值目标而完成的一系列活动。活动之间不仅有严格的先后顺序，而且活动的内容、方式、责任都要有明确的安排和界定(百度解读)。简而言之，梳理业务流程就是要知道不同的业务人员需要负责哪些“任务”来完成某项特定的业务。

比如为了完成合同的审核，需要销售人员起草合同，提交给销售总监并确认合同产品的报价，然后交给公司法务部门进行法律风险评估，再由高层领导审核确认。合同审批的业务流程涉及许多人员，包括销售、销售总监、法律事务和高级领导。在合同审批过程中，每个角色的人员都有自己需要确认的顺序和内容。

对于业务流程来说，最核心的关注点是“做什么”，即不同角色的业务人员在流程的不同环节需要完成什么。

流程:为了完成一个特定的业务流程，不同的人需要在系统中完成一系列指定的操作，并保留相关数据。

比如，销售人员为了完成合同评审，需要在CRM系统中维护合同信息和合同产品报价；合同提交后，销售总监在CRM系统中确认合同报价，如果报价有问题，会在系统中修改；销售总监确认后，法务会在CRM系统中确认，如有法律风险，会记录在系统中；法律确认后，高级领导将在OA系统中批准合同。

对于系统流程来说，最核心的关注点在于“怎么做”，即不同角色的人需要在哪个系统中完成哪些操作。

先有业务流程，再有系统流程。系统流程是将业务流程系统化的过程，这个过程也是将业务需求转化为系统解决方案的过程。

(1)如何梳理业务流程？

①明确的业务目标是什么？

确认业务目标，即定义业务范围，确定需要了解哪些业务流程。

至于业务流程的范围，可以广义定义，也可以重点定义。比如企业从生产到销售再到服务的过程，可以定义为业务流程；但是拆分后，产品的生产流程和订单的订购流程也可以定义为一个业务流程。

所以我们在梳理业务流程的时候，需要明确流程的范围，也就是流程的起点和终点。这个起点和终点是根据业务目标确定的。比如我们在讨论“如何完成一份合同的制定和确认”时，过程的起点是合同的起草，过程的终点是合同完成的确认。

②流程中涉及哪些部门和角色的业务人员。

在一个完整的业务流程中，需要来自哪些部门和角色的人协同完成。以上述合同审批为例，整个流程涉及:销售部业务员、销售总监；法律部法律顾问；高层领导；

注意:在梳理涉及的业务人员时，尽量梳理其对应的职位或职责(如销售文员、销售总监)，而不是具体的人员(如张三、李四)。因为特定人员的岗位调动、辞职等原因，变动频率相对较高，但岗位或职责相对固定。

③梳理不同角色的人要完成哪些“任务”。

在业务流程中，哪些业务需要由不同的人来完成。以上述合同审批为例:

销售人员:输入合同信息并提交合同以供审查。销售总监:审核合同产品报价。法律顾问:确认合同法律风险。高级领导:批准合同。

④“任务”之间的关系和规律

在每个“任务”之前明确顺序、分支、判断等关系。按照“任务”的顺序和规则，将所有人员的“任务”串联起来，就是一个完整的业务流程。

(2)“梳理业务流程的两个原则”

“从头到尾”:根据业务目标，确认业务流程的范围，保证业务流程可以关闭，不能中途戛然而止。

以上面的合同审核为例讨论“如何完成一份合同的制定和确认”，那么这个过程在法律部确认后就不能终止了。现阶段，合同还没有真正确认。

当然，流程的终点需要与业务目标相匹配。如果是讨论“如何完成合同的起草”，那么上述过程在法律确认后终止也可以说得通。

“作出取舍”:描述业务流程的粒度需要选择，不能太细，也不能太粗，以“清晰描述流程，引导业务顺畅”为原则。

以上面的合同评审为例。“合同信息录入”节点没有详细描述需要录入合同的哪些信息，是否需要上传电子合同等。

描述业务流程的粒度，有时需要结合查看者的需求。如果以管理层的眼光来看，可能不会太在意流程的细节，更多的是在意流程的流程和关键控制点；如果是执行层来看，可能更在意细节，细致到如何完成每一项“任务”，如何完成工作直接影响到执行层的日常工作量。

(3)如何输出业务流程图？

业务流程图的输出没有固定的形式，可以用普通流程图、车道图或其他图形方式呈现。建议使用车道图进行显示。车道图:车道图可以用Visio(本地软件)和ProcessOn(在线平台)绘制；

车道图一般分为三个维度:位置维度、阶段维度、任务维度。

职位维度:以部门/职位区分，不同部门和角色的人用一条泳道区分。下图中水平排列的车道。(不建议按负责人区分，比如张三/李四。因为负责人可能会因为工作变动、辞职等原因而频繁变动。)

阶段维度:按任务阶段区分，定义每个阶段要处理的任务链接；下图中纵向排列的泳道。(非必要尺寸，看个人画图习惯)

任务维度:不同部门/岗位的业务人员在不同阶段需要处理的任务；下图中的每个流程节点。

2.系统流程梳理:将业务流程转化为系统流程，形成可执行、高效、符合需求的系统流程。

(1)如何梳理系统流程？

①划分系统边界

对于流程的每一个环节，首先要划分哪些“任务”需要在哪个系统中完成，明确每个系统的功能边界。

以上诉合同流程为例，合同流程的每个环节都可以划分到不同的业务系统中，合同起草、合同报价确认、法律风险确认都可以在CRM中完成；合同审核在OA系统中完成；合同生产、仓储入库、物流运输、物流签收都可以在ERP系统中完成。

系统边界的划分需要匹配不同业务系统的定位和当前产品的产品定位。

如果是标准产品开发，就要尽量减少对外部系统的依赖，尽量在这个系统中完成业务流程的流转。否则，在产品销售时，如果高度依赖其他系统来完成业务流程的运行，那么就需要和其他系统打包销售，这样就会降低产品的竞争力。当然这也需要结合公司的产品策略。如果产品策略是整合多套产品形成整体解决方案，那么就需要根据不同产品的定位来划分各个系统的边界。

如果是客户定制产品/项目开发，需要根据客户内部业务系统定位进行划分。

②明确各业务环节的系统控制点。

由于业务流转的需要、管理要求或其他原因，业务流程中的关键节点会有一些业务控制要求。

例如，在输入合同时，需要上传合同附件。电子附件可以作为流程审批的依据，也可以保留在网上供以后查看。与这部分业务管控需求类似，需要在系统流程设计时形成系统管控点。

③确定各系统数据交互的触发节点。

明确业务系统间单据流转的触发节点，即哪个环节可以同步推送数据到其他业务系统。

例如，当CEO确认合同获得批准时，合同将同步到ERP系统进行生产。

④明确各系统的数据返回同步。

在其他业务系统的公文流转过程中，可能需要将一些公文信息发回并同步到源系统。

比如合同同步到OA系统审批后，审批结果(通过？拒绝)需要同步发回CRM系统，以便销售文员及时了解合同审批状态；合同交付到ERP系统进行生产后，生产进度可能还需要同步回CRM系统。对于销售人员来说，可以及时了解合同交付情况。

(2)如何输出系统进程？

系统还可以使用车道图来输出流程。下面是一个例子:

与业务流程图有两个不同之处:

维度不同:一般业务流程是岗位维度、阶段维度、任务维度；流程的维度一般有岗位维度、系统维度、任务维度。

即系统流程描述了哪个岗位的业务人员需要在哪个系统中完成哪些任务。

粒度不同:系统流程会更详细的讲述某个流程在系统中是如何完成的，从而指导业务用户顺利完成业务。业务流程不一定描述详细的流程控制点，但是系统流程会详细描述流程控制点和相关的处理方法。

3.方案制定:结合产品目标、需求范围、业务流程等。形成一个解决方案。

解决方案不是产品的PRD文档，而是用于向客户/用户介绍产品和解决方案的介绍性文档，通常采用PPT格式。

在标准产品研发过程中，不一定需要输出解决方案，而是使用PRD文档描述需求和需求解决方案。

对于定制项目/产品，大多数情况下，需要导出项目解决方案，向客户的业务人员(包括管理层和执行人员)介绍整体项目解决方案内容，并就产品需求和范围达成一致。

(1)如何写解决方案？

①了解方案报表的场景和报表对象。

不同的报表场景报表对象不同，解决方案的侧重点也不同。向客户管理层汇报将重点解释业务管理计划、管理流程、项目价值等。向业务执行层汇报将着重解释系统流程、业务控制点等。

所以在写解决方案之前，你需要先了解报告的场景和对象，从而明确解决方案写作的重点。

②方案中需要呈现的内容(这里是项目方案写作的基本框架)。

项目概述:主要介绍项目背景，企业现状，检查项目目标。

项目概述章节是为整个项目定调的章节，需要熟悉目前的项目背景、企业现状、业务流程等。

尤其需要关注企业高层领导对当前项目的看法和期望。高层管理人员在企业的业务过程中对当前项目在未来的作用和角色是项目目标的核心提炼点，也是指导项目实施方向的关键因素。

整体业务解决方案:根据项目目标和企业现状，介绍整体业务管理解决方案。

结合项目目标和企业现状，对企业现有流程提出优化管理方案。核心是引入新的管理流程和方案，输出整体业务规划蓝图、产品架构等。

详细的功能设计方案:以业务流程模块说明各业务板块的流程和产品功能。根据各模块的业务流程和系统流程，讲解模块功能设计，包括:业务痛点、业务流程、系统流程、字段模型、权限设计、业务控制点、核心功能等。

对于整体业务解决方案和详细功能设计方案的内容比例和详细粒度，需要根据申报对象进行权衡。

当报告对象为高层领导和管理层时，核心在于整体业务解决方案的介绍，而详细的功能介绍只需介绍流程、控制点和核心功能，整体篇幅也要以业务解决方案为重点。

当汇报对象主要是高管层时，可以适当降低整体业务解决方案的比重，详细的功能设计可以写得更详细，包括:系统流程、控制点、核心功能、字段模型、数据权限等。

除了引入上诉，项目解决方案还可能包括:项目实施计划、项目团队、项目风险等。这些内容可以根据实际情况补充。

4.产品版本划分:定义产品MVP版本，确定产品MVP版本需求和后续迭代路线。

MVP版本:最简化和可实现的产品。在标准产品研发过程中经常会听到“MVP”这个词。很好理解，就是通过较短的开发周期，快速实现产品的基本功能，产品能够快速进入市场。然后通过获取市场反馈，对产品进行迭代优化。

对于定制的项目/产品，很少有MVP版本的概念。项目立项时，项目周期和需求范围基本明确。即使会有按版本在线迭代的情况，但版本划分的依据更多的是根据客户需求的迫切程度。

那么，标准产品研发如何划分MVP版本呢？

①明确产品目标，清楚了解产品需求。

产品版本/迭代路线的规划需要根据产品目标和产品需求进行划分。对于每一个产品需求，都需要清楚地了解需求背景和内容，才能准确地定义需求范围和需求优先级。

②确定产品最简单的业务流程。

简化产品主流程，尽可能减少业务流程环节，在保证业务流程闭环的同时，将一些不必要的外围环节放到迭代优化版本中。

简化业务流程的基本原则(以产品规划中讲解的车企销售线索管理为例):

不破坏产品目标的功能；

销售线索管理模块的目标:打通外部客户获取渠道，实现线索从获取-跟进-转化的全流程管理。

以下是线索模块要求的一些示例:

对接外部获客渠道(如易车网、知车皇、Tik Tok等。):线索获取的核心功能需要规划成MVP版本。不过可能会考虑优先选择使用频率最高的渠道或者暂时不用平台对接使用EXCEL导入线索。潜在客户重复检查:潜在客户获取的核心功能需要计划到MVP版本中。Lead价值评估:不影响产品目标的lead获取非核心功能不做。线索分配功能:线索跟进的核心功能需要规划到MVP版本中。

能够暂时使用人工替代的功能，考虑不做；

根据与销售线索相关的信息，销售人员将被自动分配进行跟进。否则，可以手动分配销售线索。

销售线索一键转化为商机，可以通过手工创建新商机、关联线索来实现，但整体流程体验很差，需要规划成MVP版本。

定制客户要求(适用于比较小范围的客户)，不做；

在分配线索时，需要根据销售人员(客服人员)当天是否上班来分配，但不要这样做。

支持自定义配置的功能，考虑先用固定配置实现。

线索可以根据用户自定义的字段重新检查，但不能完成。先按照行业常用的默认规则(比如***号)检查重复。

当一个lead转化为opportunity时，你可以自己配置opportunity的基本信息字段，不用做就可以从lead的基本信息中获取。显示默认赋值的几个固定字段。

③根据最简单的业务流程形成MVP版本需求范围。

本文由@茶花B端原创发布。大家都是产品经理，未经允许禁止转载。

来自Unsplash的图像，基于CC0协议。

此观点仅代表作者本人，大家都是产品经理。平台只提供信息存储空服务。