TOGAF 10 里的业务场景模型，业务场景究竟为何？3 个案例教你创建！

摘要：很多小伙伴可能一提到“业务场景”，脑袋里就想到了“什么是业务需求”“客户的需求到底是什么”，但实际上，业务场景可不光是“需求”那么简单。它是描述一个特定商业环境下，系统、流程和角色如何交互的一个框架。简单来说，业务场景帮助我们从整体上理解“现在的业务环境是怎样

今天我们来聊聊TOGAF 10中的一个重要概念——业务场景，以及如何创建一个切实可行的业务场景。话不多说，直接开始！

很多小伙伴可能一提到“业务场景”，脑袋里就想到了“什么是业务需求”“客户的需求到底是什么”，但实际上，业务场景可不光是“需求”那么简单。它是描述一个特定商业环境下，系统、流程和角色如何交互的一个框架。简单来说，业务场景帮助我们从整体上理解“现在的业务环境是怎样的，未来我们希望它变成什么样”。用《场景革命》中的一句话来说明场景的重要性：产品解决一个问题，场景持续解决问题。

如何用架构的视角来看待“业务场景”？TOGAF 10系列指南中明确指出：业务场景本质上是业务问题的完整描述，包括业务和架构方面的内容，确保各个需求在问题的上下文中关联起来。

02业务场景的创建过程

创建一个业务场景其实并不是拍脑袋的事，而是需要系统性思考。TOGAF 10的业务场景创建模型由5个部分组成（与TOGAF 9.2的7个步骤稍有不同），这5个部分帮助我们系统性地创建业务场景，确保业务、技术和架构的结合更加紧密。

Problem：识别和记录问题驱动因素
首先，明确问题的来源和性质，并将其文件化和定级。这一步的关键是了解为什么需要这个业务场景，以及它对业务的影响程度。
示例：假设你在一家电商公司，当前的退货流程太复杂，用户不满意，客服投诉率高。这就是一个明确的“问题驱动因素”，需要在业务场景中予以记录。Environment：识别业务和技术环境
明确业务和技术环境，并在业务场景模型中文件化。这一部分包括与业务场景相关的业务模型、技术模型和操作环境的描述。
示例：继续上面的例子，当前的业务环境是：客户提交退货申请，人工客服手动确认退货信息，耗时长、效率低。目标业务环境可能是：通过App自动提交退货申请，系统自动审核，减少人工介入。Outcomes：识别并文件化目标（“SMART”）

目标必须是“SMART”的，即具体的（Specific）、可衡量的（Measurable）、可实现的（Achievable）、相关的（Relevant）、有时限的（Time-bound）。

示例：

不具体的目标：提升客户满意度。具体的SMART目标：在未来3个月内，将退货流程从5天缩短到2天，客户满意度提高10%。

4. Human Actors：识别人员施动者（参与者）

在业务场景中，明确与业务场景相关的人员及其角色，并描述他们在业务模型中的位置。参与者可能包括客户、员工、管理员、外部合作方等。

示例：在退货业务场景中，人员施动者包括：

客户：提交退货申请，提供反馈。客服：跟进客户退货请求，提供帮助和支持。仓库管理员：处理退货的商品验收和入库。

明确在业务场景中起作用的计算机系统和技术元素，并标明其在技术模型中的位置。这包括应用程序、数据系统、自动化工具等。

示例：

退货管理系统：自动记录和处理客户的退货申请。客户服务系统：客服使用的客户支持工具，用于查看退货状态。库存管理系统：用于监控退货商品的入库和处理。

接下来，我们用一些现实工作中的问题来具体说说怎么创建业务场景。

1. 客户抱怨：“我们的业务系统太慢了！”

假设你是负责IT架构的主管，某个部门的同事跟你抱怨：“我们的业务系统太慢了，每天操作一堆数据，要花好几个小时。”这时候，传统的做法可能是急急忙忙开会，讨论怎么加速系统性能。但如果从TOGAF的角度来看，这个问题的背后其实可能隐藏着更深层次的业务需求和痛点。

在TOGAF中，我们可以通过创建一个“业务场景”，明确：这个慢系统是因为数据量大，还是业务流程太复杂？或者是技术架构不匹配？通过梳理出这些场景，我们就能找到根源，而不是简单的“加速”系统。

关键问题：

定义场景背景：系统慢的背景是什么？是因为用户同时操作太多，还是数据存储处理效率低？描述业务需求：到底是因为快速查询需求，还是是其他操作对性能要求过高？分析影响因素：是业务流程问题，还是技术架构问题，还是数据管理的问题？

通过这些步骤，你就能建立起一个具体的业务场景，从而为后续的解决方案提供有力支持。

用TOGAF10中的方法创建业务场景：

2. 团队成员：我们部门的沟通不畅，很多时候信息共享不到位

再比如，很多公司都有部门间沟通不畅的问题。有时，一个部门根本不知道另一个部门的需求，而另一个部门也不知道自己的需求变化已经影响到了他人。这种信息不对称经常导致重复工作、效率低下。

如果按照TOGAF的思路来做，我们可以通过“业务场景”来理清楚：在不同的部门和职能之间，信息流是如何流动的，哪些环节可能出现瓶颈，哪些环节又没有产生足够的价值？

关键问题：

界定场景范围：这不是一个部门的问题，而是整个公司的流程都没有优化。可以从跨部门合作入手，看看是否有工具可以促进信息的流动。分析场景影响：如果沟通不畅，部门之间的协作就会受到阻碍，导致业务延误，影响客户体验。定义解决方案：是否需要一个协作平台，或者一个统一的信息系统？这就是一个TOGAF框架下的具体业务场景，它帮你看清问题所在，并找到解决办法。

3. IT部门和业务部门“脱节”了

另一个常见的问题是，IT部门和业务部门的需求常常无法对接。IT部门认为自己的技术能力很强，业务部门却总是觉得IT无法理解他们的实际需求。这个脱节看似是沟通问题，但深入一看，往往是两者在目标和视角上的差异。

在TOGAF中，业务场景帮助我们明确，IT和业务之间的差异不仅仅是语言不通，而是两者从不同的角度看待问题。IT往往聚焦于技术细节，而业务则更多关注“这个技术能解决什么实际问题”。

关键问题：

定义目标和需求：明确IT部门和业务部门各自的目标。比如IT关注系统稳定性和安全性，而业务关注如何提升用户体验和加速市场反应。识别关键问题：这个场景里，业务和IT之间最大的鸿沟是什么？是不是业务对技术要求不够清晰，还是IT没有提前与业务讨论需求？寻找连接点：通过业务场景的创建，可以发现双方的共同目标，比如提升客户满意度，缩短开发周期等，从而帮助双方对齐目标。