业务分析能力是B端产品经理的必备技能，包括业务分析和业务建模能力。本文作者从TOGAF中的价值流建模方法出发，结合案例，分享了业务分析的具体步骤并对过程中需要注意的问题进行了总结，希望对你有所启发。

很多B端产品经理在开始做产品的时候，总会陷入需求分析、功能设计之中难以自拔，认为自己无需过多接触业务，只有和IT产品开发有关的工作才是自己要做的。但事实上对于B端产品经理来说，前端的业务分析与业务建模能力才是一切IT产品的基础，业务分析能力是B端产品经理的必备技能。

有时候我们会遇到这样的场景：

• 接到一项任务，需要跨多个业务线，或涉及多个IT产品，不知道该如何下手；
• 从0到1设计一款IT产品，面对繁多的功能需求，无法判断当前需要哪些；
• 想通过IT产品解决一些问题，但不知道现在的问题是什么；
• ……

以上场景，均可以通过业务分析逐步定位并解决，本文将借鉴TOGAF中的价值流建模方法，结合实际案例，通过使用一些方法论，讲解如何从0到1进行业务分析，并最终落地到IT产品的解决方案中。

业务分析的具体步骤：

1. 规划你的蓝图—进行价值流建模
2. 识别出你要做的事情—识别业务流程
3. 理清事与事之间的关系—制作流程视图
4. 分析具体要做的事情—流程分析与优化

业务分析的过程实际上是将业务架构逐步拆解的过程，按照业务架构→价值流→业务活动→业务流程→工作说明的路径图逐步细化，这与应用架构在产品设计中的的使用方法类似。

一、规划你的蓝图—进行业务建模

在明确了项目的目的和目标后，首先要对项目的整体业务运作进行分析，通过业务建模的方式，从一个更高阶的维度讲清楚当前业务的运作情况，为后面做业务流程与解决方案提供一个参考蓝图。

业务建模的方法有很多，这里推荐使用TOGAF的价值流建模方法。价值流的优势是可以将达成业务目标的主要活动组合起来，组成端到端的一组活动，并进行可视化的呈现，相对来说更看重结果的实现，且更容易让业务方理解。

1. 价值流相关介绍

价值流：一个端到端的增值活动集合，为客户、利益相关者或最终用户创造整体结果。

——James Martin.《大转变（The Great Transition）》

（1）价值流不是业务能力，也不是业务流程——价值流可以帮助验证业务能力和业务流程，反之亦然。价值流描述企业为了实现目标所需要进行的一系列标准的活动，至于企业是否有这些活动，或者是否达到标准，可以借助业务流程或业务能力来验证。

（2）价值流要足够精简——价值流可以看作是一组最小实现模型，过程中的每个阶段都要对目标和结果能够产生价值。——TOGAF

2. 本文案例背景

笔者在一家劳动密集型服务业，老板希望能够将一线员工的工作计划、工作绩效、员工工资数据通过IT产品关联起来，以此来进行合理的人员配置，改进人力资源结构，在服务业实现类似制造业的计划-执行-评估-计薪的精益管理模式。

3. 价值流建模的方法

如果公司有现成的业务架构可用，我们可以将业务架构中的L2或L3层级的内容进行修饰来搭建项目的价值流，如果没有现成可用的，可以参考一些行业内先进的业务架构或端到端流程，如LTC、IPD等。因为价值流是较高阶的，它只能粗略的描述我们需要做哪些事情，因此先可以不用考虑具体的场景与流程。

举例：按照本项目的背景，我们确定了价值流如下：

此外还需要完成价值流的说明，需要列出价值流每个阶段的关键要素，包括描述、利益相关者、进入条件、退出条件以及产生的价值。目的是框定价值流每个阶段的范围，作为未来流程识别的输入。

举例：价值流说明

二、识别出你要做的事情—识别业务流程

业务建模只是一组高阶的运作模型，它描述为了达到目标而必须要做的事情，但是大多数运作模型的层级较高，我们无法直接到具体方案落地。一般而言，从业务建模到解决方案至少要经历以下几个步骤：

首先，将业务运作模型中的每个阶段进行细化，识别出包含哪些具体的业务流程；

其次，梳理清楚业务流程之间的逻辑关系；

最后，对具体的业务流程进行分析，输出解决方案。

1. 识别业务流程的工具—流程框架

很多B端产品经理由于不熟悉业务，在业务分析时总是会遗漏一些业务流程，轻则导致业务方的不信任，重则导致业务流程的断层与IT产品的数据孤岛。因此建议大家使用流程框架来辅助业务分析，流程框架包含了一个企业所需要的所有业务流程，产品经理可以根据价值流按图索骥，在流程框架中识别出所有相关的业务流程。

一些流程管理较为完善的企业有自己的流程框架，会更加贴近该企业的实际情况。如果没有，也可以使用一些通用的流程框架，如APQC的PCF、IBM推出的EPF等。

流程框架（ProcessClassification Framework）：包含了企业运营过程所需要的所有的流程，目的是提供一个从流程角度运营企业的标准样例。

2. 识别业务流程的方法—回溯法

信息化的本质是数据的拉通，将价值流每个阶段产生的关键数据作为终点，借助流程框架识别出产生该数据的关键业务流程，这些关键业务流程就是需要着重关注的，此外，还需要筛选出一些关键流程的主要支撑流程。

举例：工作评价阶段主要产生工作绩效数据，该数据是由工作绩效评估流程产生，但因为满意度调查流程与质量检查流程是工作绩效评估流程的主要支撑流程，因此也要将其考虑进去，这样下来，工作评价阶段的关键流程就是质量检查流程、满意度调查流程以及工作绩效评估流程这三条业务流程。

识别后的业务流程：

三、理清事与事之间的关系—制作流程视图

识别出项目的所有关键业务流程后，我们需要将关键业务流程用逻辑关系串起来，组成流程视图/流程蓝图。流程视图可以帮我们梳理清楚流程与流程之间的逻辑关系，是进行数据流、流程分析、功能设计的必须输入。

流程视图的梳理原则：

以业务流程的现状作为梳理的依据，以数据流作为流程之间逻辑关系的主要考量，参考业务运作模型与行业内的标杆项目。

举例：本项目的流程视图

四、分析具体要做的事情—流程分析与优化

这一步也是大部分B端产品经理经常在做的事情，关注于具体某个场景、流程的落地，流程分析到产品设计的具体方法不再赘述，可以参考我的上一篇文章——B端产品经理：如何用流程优化进行产品设计？

总结

在企业数字化建设初期，大多数人对业务分析、业务流程的理解是狭义的，认为只要通过大量IT产品，实现了某领域的线上操作，就是成功且创造价值的项目。但伴随着近几年企业数字化领域发展的逐渐成熟，越来越多的企业意识到数字化是建立在业务流程上的信息化，业务流程才是一切数字化的基础。因此对于一个B端产品经理来说，业务分析能力一定是技能树中的必点技能。

以上是我近期总结做产品设计过程中的一些思路，真实场景的业务流程远比此复杂、困难。文中有些不足的地方，因笔者经验尚浅，难免疏漏，更多是希望和大家讨论，一起成长。

本文由 @老韩 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议