编辑导读：B端是近几年的风口行业，各大企业和巨头纷纷入场，希望能挖掘出市场的最大价值。而B端的用户需求与C端有很大不同，如何进行需求分析，梳理业务流程呢？本文作者对此发表了自己的看法，与你分享。
在上一篇文章《Ｂ端产品需求的3个层次，你都了解吗？》中，我讲到：在用户需求与产品需求之间（也就是把用户需求转化为功能需求的中间）有一个重要的过程叫做：需求分析。
这个过程，容易被工作时间不长的产品经理忽略；又或者，这个过程需要解决的问题，容易被工作时间不长的产品经理产生误解。误以为需求分析的目的是：分析软件系统如何实现用户的需求。
然而并不是这样。实际上，需求分析的目的是：业务分析。也就是：选择一种以业务为导向的方式将零散的、不同颗粒度的需求串起来，形成一个完整的、内容清晰的框架，指导后续相关的产品设计 、产品开发工作。提到“分析”一词，对任何“事务”的分析，都有相应的分析、思考框架。提到“人力资源”分析，我们可以使用力资源规划、招聘、培训、绩效、薪酬、员工关系思考框架。提到“营销”分析，我们可以使用产品、价格、渠道、促销思考框架；以及认知顾客价值、创造顾客价值、交付客户价值、传播客户价值思考框架。同理而言，提到“需求”分析，我们可以使用：业务流程；业务场景；领域建模；状态图，共4个思考模型。
业务流程是需求分析的主要手段，它可以帮助产品人员系统性的厘清思路，和相关人员沟通达成共识。
这篇文章先讲“业务流程”分析需求的方法（其它3个思考模型，再另写3篇文章单独详细讲）。
关于业务流程，我将从以下3点详细讲解：
接下来，我一个一个的讲。
01 定义及要素
这里我们先对业务流程做一个定义。
百度百科对业务流程的定义是：
业务流程是指，为达到特定的价值目标而由不同的人分别共同完成一系列的活动。活动之间不仅有严格的先后顺序限定，而且活动的内容、方式、责任等也必须有明确的安排和界定，以使不同活动在不同岗位间进行转手交接成为可能。
从业务流程的定义里，可以找出业务流程包含的要素如下：
1. 角色
业务流程里的第一个基本元素就是角色，有了角色才会有分工、有协作，才能完成特定的价值目标。
2. 活动
也就是指具体做的事，每个角色都会有具体需要做的事。
3. 协作
一家公司或者说一个组织里面，不同人做不同事，最终通过协助才能完成一系列的事。
而且的协作方式，有并行、也有串行（也就是可以在同一时间完成，或者是不同的时间段里完成）。
4. 产出物
每个人有了具体活动，就会有产出，产出的东西形成产出物，以使不同活动在不同岗位间进行转手交接成为可能。
5. 规则
正所谓，无规矩不成方圆。
定义中提到：而且活动的内容、方式、责任等也必须有明确的安排和界定。
案例，关于业务流程相关的5要素，我上面的介绍可能比较抽象，这里举一个具体的例子讲一讲。
有一家做Saas产品的互联网初创公司，公司目前的部分主要有产品部、营销部、销售部、客户成功部四个部门。
产品部门有A一个人，营销部门有Ｂ一个人 ，销售部门有C、D两个人、客户成功部门有M一个人。
产品部门A的工作目标是做出一个能帮助商家解决业务问题的产品，所以经常做需求挖掘、需求分析、需求管理等工作；
营销部B的工作目标是获取到一定量、且有效的销售线索，经常要做的内容就是内容运营、活动运营等工作；
销售部C、D的工作目标是将有效的销售线索进行转化，转化客户付费，经常要做的工作就是线下拜访、PPT演示、签合同等相关工作。
客户成功部的工作目标是助力客户成功，提升客户产品的使用率，经常要做的工作就是新手培训、客户成功案例分享等等。在这个案例里，各部门的相关工作人员就是角色；每个角色具体做的事就是活动；产品人员做产品、营销人员获取销售线索、销售做销售转化、客户成功做客户服务，这就是协作；营销部门交付有效的客户线索，销售交付已付费的客户，这就是交付物；营销部门必须获得的是有效线索才可以交给销售部，什么是有效线索也会有相应的标准，这就是规则。
关于业务流程的定义以及包含的基本要素要素有哪些，有了一定的了解之后，接下来进入下一个环节：业务流程的绘制。
02 业务流程的绘制
按照UML的标准，业务流程的分类有很多。
例如，顺序图、活动图、时序图等等。
但在日常的工作中，基本上用两种类型的图就可以把业务流程梳理清楚以及讲清楚。
这两种图，分别是：
1）部门级流程图，也就是跨部门流程图
跨部门流程图是一种比较复杂的流程图，可以清晰的描述分角色、跨系统的业务流程。
2）个人级流程图，也就是个人为完成某个业务，实施了多个业务步骤过程的流程
在绘制流程图时（不管是部门级流程图还是个人级流程图），流程图的基本符号有很多，但基本上只需要开始、结束、活动要素、判断、流程线（流程线是指连接活动与活动的流程线），五个基本符号来绘制流程图就可以。
甚至还可以再简化，开始和结束两个符号都可以不要，最终只需要活动、判断、流程线就可以。
流程图包含的3个基本符号如下图：
这里我用2个实际案例讲讲流程图的绘制方法。
如下：
做了一个大转盘抽奖活动的跨部门级业务流程图：
做了一个商家注册过程的个人级业务流程图：
关于流程图的补充说明：每一个流程图，只有一个开始节点，但可以有多个结束节点（如上图大转盘抽奖流程图，只有一个开始节点，但有2个结束节点）；活动和流程线是必有符号，判断情况视情况而定（如上面大转盘抽奖流程图，有活动和流程线符号，但没有判断符号）；在画“泳道”流程图时，需要注意泳道的顺序，以便流程图看起来简单易懂，而不是各种复杂的交叉在一起。
03 业务流程的分析与优化
我上面讲到的部门级流程图、个人级流程图的案例，其实已经靠近软件需求了，也就是客户在使用软件过程中的业务流程图是什么样的，通过整体、系统的分析、思考。
然后进入软件的设计阶段。在进入与系统相关的业务流程图绘画之前，还可以根据业务实际情况的需要：绘画出没有系统之前的业务流程图是什么样的（同样可以使用文中讲到的部门级流程图和个人级流程图绘制方法）。
这个步骤也非常重要。
为什么会这样讲？
因为：我们开发软件是为了支持业务需要，软件支持业务的核心是对业务流程的固化、优化和重构。
因此把没有系统之前相关的业务流程图画出来，然后看看，哪些流程环节需要系统来固化；哪些流程环节需要系统来进行优化；哪些流程环节需要重构。
最终，通过对传统流程的固化、优化或者是重构，实现企业的降本增效，提升企业用户的消费体验。
最后，关于业务流程的梳理与绘制就讲到这里。
通过流程图思考框架，以及接下来几篇文章，我即将要写的几个思考框架的运用。
我相信，关于需求分析这个问题，将会分析的更透彻，以及对业务的理解将会更系统和彻底。
#专栏作家#
本文原创发布于人人都是产品经理，未经允许，禁止转载。
题图来自Unsplash, 基于CC0协议。
