产品有场景，业务架构也要有

如果你是产品经理，你一定会非常重视“场景”这个词。它帮助每个产品经理找到解决用户痛点的方法。对于产品而言，用户需求是方向，场景是路径，而最终的产品功能是目的地。

在使用产品直觉做业务架构时，我们会自然地寻找场景。这个内容在许多业务架构模型中都被隐藏了。但产品直觉告诉我们，如果在业务架构中看到了场景，它应该能帮助我们更快地找到解决方案。

1. 什么是场景

场景，是指戏剧、电影等艺术作品中的场面。

而“场面”泛指在一定场合下的情景。基本解释为：在叙事性文学作品或戏剧、电影中，人物之间在一定的时间和环境中互相发生关系而构成的生活情景。

在描述一个业务时，我们通常会描述业务的“目标，做法，成效”，也就是所谓的“起因，经过，结果”。然而，当进行文学创作时，仅有“起因，经过，结果”无法支撑起一个完整的文学作品。同样，仅有这些元素也无法支撑业务。我们还需要考虑“时间，地点，人物”这些因素，以帮助我们还原整个业务的上下文，从而将我们带回业务发生的最真实场景。

1.1 产品中的场景

场景在产品中的作用是帮助我们快速了解用户的具体需求。从用户需求出发，有助于我们理解问题。因此，对产品经理来说，确定客户的需求场景是理解业务需求的最重要步骤。用户的需求场景是特定环境下的具体需求问题。针对这个场景下的问题，产品经理需要找到有针对性的解决方案，即功能及其使用场景。

因此，诉求和解决方案之间的关系是由场景来维系的。在这个场景下，产品经理从问题出发，找到解决方案，以规划产品功能。

举例来讲，我肚子很饿，想要吃东西，这是个需求。

• 场景一：我约了朋友，在商场边上，我肚子很饿，想找个地方坐下来，想要吃点东西。
• 场景二：我刚加完班，没有力气，我肚子很饿，手边没有吃的，想要吃点东西

同样是我，同样是想要吃东西，场景一和场景二对于产品来讲是截然不同的两种功能。甚至在细分的产品中，这成为两个不同核心功能的产品。场景一：大众点评；场景二：饿了么。

我们可以看到，需求场景众多。作为产品经理，我们需要根据产品定位，选择最具针对性的场景，进行细致深入的分析，以解决该场景下的用户需求问题。如果缺少了场景，产品将会失去解决需求的方向，从而没有了解决问题的路径——即针对性的产品功能。这样的产品可能会偏离目标，或者虽然包含了许多功能，但并未真正解决问题。

1.2 业务架构中的场景

业务架构通常以结构化的方式表达复杂的业务流程。对于流程较少、业务不复杂的企业，可以直接对每个流程进行详细的结构化表达，用最直接的方式建模就可以得到业务架构的内容。然而，对于复杂的流程，我们无法详细地对每个流程进行结构化。

从标准化的角度出发，目标相同且发生在相同“场景”的流程应该具有相同的执行过程。相反，目标相同但发生在不同“场景”的流程应该具有不同的执行过程。我们需要理解这种目标相同，但发生“场景”不同的流程。

还用肚子饿，想要吃东西来举例：

• 业务问题一：正在逛商场，肚子饿了，想要吃东西
• 业务问题二：刚加完班，肚子饿了，想要吃东西

两个业务问题都是肚子饿了，目标都是要解决肚子饿的问题，但是因为“场景”的不同，让我们去解决这个问题的方式就产生了很大的差异；一个可能需要找餐厅坐下来，另外一个则是点个外卖。

我们再用采购举例：

• 采购问题一：需要采购设备，金额很小
• 采购问题二：需要采购设备，金额很大，达到国家公开招标金额规定

两个问题均涉及设备采购，目标都是购买设备以供业务使用，但由于“场景”的不同，问题一可以通过单一来源或询价的方式进行采购，而问题二则必须走公开招标的过程。

我们理解了产品中场景的价值，那业务架构中的场景又有什么用呢？

在 TOGAF 中，它告诉我们场景的用途：“业务场景提供了一种语言，供应商社区可以用它来链接客户问题和解决方案。”简单来说，只有在具体的业务场景下，问题才能有针对性的解决，这正好映射了产品经理的直觉。因此，在业务架构中，场景是我们通向解决方案的路径。而问题则指向了业务架构的未来应用。

应用一：业务标准化——场景让业务标准化更加精细化

拥有业务架构后，我们可以清晰地看到业务的执行过程，进而进行后续的标准化。以采购为例，当我们进行标准化管理时，如果采用粗放式的方式来管理流程的始末，那我们只需要在采购开始和结束时进行管控。然而，对于管理者来说，我们都希望实现精细化管理，但如果颗粒度过细，就会陷入琐碎的流程中。

场景化的标准化为我们提供了一个中间位置，让精细化管理有一个可控制的程度，而这个控制的关键就是场景。

应用二：IT 信息化规划——场景让 IT 信息化规划结果更具针对性

如果业务架构的目标是 IT 信息化规划，那么场景就是这个目标的具体化。就像在产品中精确定义场景可以找到产品功能以满足具体需求一样，在业务架构中精确定义场景可以帮助信息化找到最具针对性的系统规划，来确保信息化规划对业务的贴合和支持。

2. 如何获取场景

我们理解场景的重要性，需要从业务本身出发，寻找最合适且最理想的划分。这将帮助我们从管理或规划的视角进行识别。

2.1 产品场景的获取

在讨论如何获取架构中的场景之前，我们先看看如何获取产品中的场景。对于产品经理来说，细分并理解产品的场景是一项必备技能，可以通过以下三条路径搭配使用：

1. 用户研究：这是获取场景的最基本方法，它让我们看到用户最基本的需求以及这些需求产生的实际“场景”或前提条件。在这样的条件下，用户的行为和需求就变得合理。
2. 战略拆解：任何产品都不会无限制地满足客户的各种场景需求，每个产品都有自己的定位和商业价值。因此，我们需要明确在哪些场景下满足客户的需求，以及我们期望培育的客户场景是什么，这些都是我们未来定义产品场景的方向。
3. 市场竞品：从市场角度看，我们需要观察未来的场景趋势，看竞品都在做什么，覆盖了哪些场景，分析定位的异同，找出真正的针对性场景。

这三条路径的搭配使用让我们的产品能够找到针对性的场景。

2.2 业务架构中场景的获取

与产品的场景获取类似，业务架构中的场景获取也可以通过以下三种方式来进行，这三种方式可以共同使用：

1. 实际业务调研：这是一种自下而上的方法，它让我们能够尽可能地接近业务，了解实际执行者的执行过程。经过适当的分类，我们可以最大限度地理解执行者的需求，进而合理地进行精细化管理的场景获取。
2. 业务模式：业务模式描述了公司的经营方式，帮助我们理解在这个经营模式下，具体的事务是如何进行的，存在什么不同。因此，从业务模式出发，我们能够从上到下地理解业务的场景。同时，业务模式也继承了战略，帮助我们清晰地看到未来可能出现的场景。

信息化系统：对于已经有信息化支撑的业务，或者市场上已经有成熟产品的业务，我们可以从产品的划分出发，这让我们能够更结构化地看到场景的情况，分析其与实际业务的差异，帮助我们发现遗漏的部分，从而找到真正的场景。

相比于产品和业务架构，场景在其中占有相同的地位。无论是在产品设计中或业务架构中的场景，都是为了帮助我们找到最具针对性的业务描述，以更好地展现业务应该呈现的样子。