TOGAF 10中的业务场景模型：业务场景是啥？用3个案例教你如何创建业务场景？
业务场景不只是一个需求文档，它是连接业务痛点和技术方案的桥梁。TOGAF 10用5步模型帮助企业从"现在在哪"到"未来要去哪"，让技术和业务真正对齐。
今天我们来聊聊TOGAF 10中的一个重要概念——业务场景，以及如何创建一个切实可行的业务场景。话不多说，直接开始！
一、业务场景是啥？
很多小伙伴可能一提到"业务场景"，脑袋里就想到了"什么是业务需求""客户的需求到底是什么"，但实际上，业务场景可不光是"需求"那么简单。它是描述一个特定商业环境下，系统、流程和角色如何交互的一个框架。简单来说，业务场景帮助我们从整体上理解"现在的业务环境是怎样的，未来我们希望它变成什么样"。 用《场景革命》中的一句话来说明场景的重要性：产品解决一个问题，场景持续解决问题。
如何用架构的视角来看待"业务场景"？TOGAF 10系列指南中明确指出：业务场景本质上是业务问题的完整描述，包括业务和架构方面的内容，确保各个需求在问题的上下文中关联起来。
二、业务场景的创建过程
创建一个业务场景其实并不是拍脑袋的事，而是需要系统性思考。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%。
Human Actors：识别人员施动者（参与者）
在业务场景中，明确与业务场景相关的人员及其角色，并描述他们在业务模型中的位置。参与者可能包括客户、员工、管理员、外部合作方等。
示例：在退货业务场景中，人员施动者包括：
- 客户：提交退货申请，提供反馈。
- 客服：跟进客户退货请求，提供帮助和支持。
- 仓库管理员：处理退货的商品验收和入库。
Computer Actors：识别计算机施动者（系统元素）
明确在业务场景中起作用的计算机系统和技术元素，并标明其在技术模型中的位置。这包括应用程序、数据系统、自动化工具等。
示例：
- 退货管理系统：自动记录和处理客户的退货申请。
- 客户服务系统：客服使用的客户支持工具，用于查看退货状态。
- 库存管理系统：用于监控退货商品的入库和处理。
三、通过创建业务场景解决工作中的一些常见问题
接下来，我们用一些现实工作中的问题来具体说说怎么创建业务场景。
1.客户抱怨："我们的业务系统太慢了！"
假设你是负责IT架构的主管，某个部门的同事跟你抱怨："我们的业务系统太慢了，每天操作一堆数据，要花好几个小时。"这时候，传统的做法可能是急急忙忙开会，讨论怎么加速系统性能。但如果从TOGAF的角度来看，这个问题的背后其实可能隐藏着更深层次的业务需求和痛点。
在TOGAF中，我们可以通过创建一个"业务场景"，明确：这个慢系统是因为数据量大，还是业务流程太复杂？或者是技术架构不匹配？通过梳理出这些场景，我们就能找到根源，而不是简单的"加速"系统。
关键问题：
- 定义场景背景：系统慢的背景是什么？是因为用户同时操作太多，还是数据存储处理效率低？
- 描述业务需求：到底是因为快速查询需求，还是是其他操作对性能要求过高？
- 分析影响因素：是业务流程问题，还是技术架构问题，还是数据管理的问题？
通过这些步骤，你就能建立起一个具体的业务场景，从而为后续的解决方案提供有力支持。
用TOGAF10中的方法创建业务场景：
| 步骤 | 详情 |
| 识别和记录问题驱动因素 |
|
| 识别业务和技术环境 |
|
| 识别并文件化目标（SMART 原则） |
|
| 识别人员施动者 |
|
| 识别计算机施动者 |
|
2.团队成员：我们部门的沟通不畅，很多时候信息共享不到位
再比如，很多公司都有部门间沟通不畅的问题。有时，一个部门根本不知道另一个部门的需求，而另一个部门也不知道自己的需求变化已经影响到了他人。这种信息不对称经常导致重复工作、效率低下。
如果按照TOGAF的思路来做，我们可以通过"业务场景"来理清楚：在不同的部门和职能之间，信息流是如何流动的，哪些环节可能出现瓶颈，哪些环节又没有产生足够的价值？
关键问题：
- 界定场景范围：这不是一个部门的问题，而是整个公司的流程都没有优化。可以从跨部门合作入手，看看是否有工具可以促进信息的流动。
- 分析场景影响：如果沟通不畅，部门之间的协作就会受到阻碍，导致业务延误，影响客户体验。
- 定义解决方案：是否需要一个协作平台，或者一个统一的信息系统？这就是一个TOGAF框架下的具体业务场景，它帮你看清问题所在，并找到解决办法。
用TOGAF10中的方法创建业务场景：
| 步骤 | 详情 |
| 识别和记录问题驱动因素 |
|
| 识别业务和技术环境 |
|
| 识别并文件化目标（SMART 原则） |
|
| 识别人员施动者 |
|
| 识别计算机施动者 |
|
3.IT部门和业务部门"脱节"了
另一个常见的问题是，IT部门和业务部门的需求常常无法对接。IT部门认为自己的技术能力很强，业务部门却总是觉得IT无法理解他们的实际需求。这个脱节看似是沟通问题，但深入一看，往往是两者在目标和视角上的差异。
在TOGAF中，业务场景帮助我们明确，IT和业务之间的差异不仅仅是语言不通，而是两者从不同的角度看待问题。IT往往聚焦于技术细节，而业务则更多关注"这个技术能解决什么实际问题"。
关键问题：
- 定义目标和需求：明确IT部门和业务部门各自的目标。比如IT关注系统稳定性和安全性，而业务关注如何提升用户体验和加速市场反应。
- 识别关键问题：这个场景里，业务和IT之间最大的鸿沟是什么？是不是业务对技术要求不够清晰，还是IT没有提前与业务讨论需求？
- 寻找连接点：通过业务场景的创建，可以发现双方的共同目标，比如提升客户满意度，缩短开发周期等，从而帮助双方对齐目标。
用TOGAF10中的方法创建业务场景：
| 步骤 | 详情 |
| 识别和记录问题驱动因素 |
|
| 识别业务和技术环境 |
|
| 识别并文件化目标（SMART 原则） |
|
| 识别人员施动者 |
|
| 识别计算机施动者 |
|
TOGAF 10 认证：从"会做"到"会想"的架构思维升级
上文提到的业务场景模型，是TOGAF 10标准中连接业务需求与架构设计的核心工具。无论你是产品经理、IT架构师还是项目经理，掌握这套系统思维，不仅能帮你精准定位问题、对齐业务与技术目标，更是企业数字化转型中不可或缺的能力。
艾威培训是The Open Group授权的培训机构，提供TOGAF EA企业架构（TOGAF标准第10版）认证课程，由资深架构师GaryZou老师亲授，帮助学员系统掌握ADM方法、业务场景建模、架构治理等核心技能，快速通过认证考试。
总结
TOGAF 10中的业务场景，帮助我们从战略层面思考问题，了解业务环境的变化，以及如何通过技术和流程的调整来实现目标。TOGAF 10的业务场景创建模型包含5部分：
- 识别和记录问题驱动因素
- 识别业务和技术环境
- 识别并文件化目标（SMART）
- 识别人员施动者
- 识别计算机施动者
通过这一套系统的流程，业务和技术团队可以更紧密地协作，确保从业务愿景到技术实现的无缝对接，帮助企业在复杂的架构环境中更加敏捷和高效地前行。
所以，不管你是做产品、做开发，还是做项目管理，都可以用业务场景的思维来解决现实工作中的各种问题。记住，清晰的目标、明确的角色、流畅的流程，这就是业务场景的精髓！
好了，今天的分享就到这里。如果你希望了解并学习更多架构（业务架构）方面的知识、方法与技能，建议参加TOGAF EA企业架构（TOGAF标准第10版）认证 以及CBA业务架构师认证。
TOGAF 认证是 The Open Group 颁发的架构框架专业认证，是企业在规划、设计、实施和管理 IT 架构时所使用的一种方法和标准。它提供了一个开放的、灵活的、可扩展的方法来构建、部署和管理企业的 IT 架构，帮助企业提高 IT 效率、降低成本、提高业务灵活性和创新能力。
- 中文名TOGAF企业架构师认证
- 英文名The Open Group Architecture Framework
- 英文简称TOGAF
- 颁证机构The Open Group
- 证书类别企业架构（业务架构，数据架构，应用架构，技术架构）
- 同类认证SAFe for Architects、CBA
