场景分析方法¶
本方法支持 Solution Outline（SO）中的场景探索：理解当前场景，判断问题或机会具体出现在哪里，并描绘 Solution 可能如何改善场景表现。它提供分析视角，不要求绘制完整的 Service Blueprint，也不取代 Integrated Assessment（IA）的证据评估。
何时使用¶
当 Solution Vision 还较宽泛，或团队需要弄清楚“问题具体发生在哪里、谁在做什么、数字触点如何参与、Solution 可能改变什么”时，可用场景分析把方向落到一个或多个优先场景。
先选一个值得探索的场景或场景切片；不必一开始覆盖整个用户旅程、所有用户或所有流程。只展开足以理解问题/机会及 Solution 改善主张的内容。
从场景观察到改善主张¶
可按下列思路进行分析；不要求每个项目机械地完成每一步：
- 界定场景。 选择值得探索的场景或场景切片，说明触发情境、场景起止范围，以及本次分析包括或不包括什么。
- 理解当前表现（As-is）。 观察或整理相关角色的行动、判断与协作，信息和数字触点如何参与，工作如何交接，以及哪里出现等待、重复、错误、例外或其他摩擦。将观察到的事实与推断、未知分开。
- 分析问题机制。 追问摩擦为什么发生、影响了谁的什么行动或结果。可参考本页“问题与机会分析视角”；多个视角可以同时适用，也可能暂时无法判断。
- 描绘 Solution 的可能改变（To-be）。 说明 Solution 可能改变哪些行动、信息、数字触点、判断或协作，以及希望场景表现或目标结果如何改善。把它作为待评估的主张，不当作已验证结果。
- 回到 Solution 主张。 说明该改变如何支持 Solution Vision，并依据场景中相关 User、Touchpoint 和 Action，识别可支持其行动的一个或多个 User Client(s) 方向。说明这些方向与相关 Touchpoint 的关系；Touchpoint 是场景中的服务或工作接点，不等同于 User Client。Solution Archetypes 可按需帮助表达主张承担的业务责任或主形态，不替代场景分析，也不直接决定技术实现。结合已识别的 Conditions（尤其 Location & Environment）回看 User Client(s) 方向，必要时修正或保留为候选。
如果 To-be 还不清楚，可以先保留多个可能方向或未解问题，再继续塑形；不要为了完成一张图而补造细节。
Service Blueprint：经典结构参考¶
Service Blueprint 是呈现场景中用户行为与服务交付关系的一种方法。经典结构通常包含以下元素：
| 元素 | 用途 |
|---|---|
| Physical Evidence（可见线索） | 用户在场景中看到或接触到的实体或数字线索，例如页面、通知、单据或商品信息。 |
| Customer Actions（用户行动） | 用户在场景中采取的行动、判断或等待。DDF 场景不一定面向外部客户，也可按实际对象理解。 |
| Frontstage Actions（前台行动） | 用户可见的人员或系统行动与交互。 |
| Backstage Actions（后台行动） | 支持前台交互、但用户通常看不到的人员或系统工作。 |
| Support Processes（支持流程） | 支撑前台与后台工作的流程、系统或组织活动。 |
经典 Blueprint 常用三条分界线组织这些元素：
- Line of Interaction：用户行动与服务提供方交互的边界；
- Line of Visibility：用户可见行动与不可见后台工作的边界；
- Line of Internal Interaction：后台工作与支持流程之间的边界。
这些元素和线条是参考结构，不是 DDF 的必填栏位。可按场景取舍、合并、改名或采用团队熟悉的图形表达；对于系统间处理或非客户场景，也可把 Customer Actions 替换为相关用户/角色或外部系统行动。可分别呈现 As-is 与 To-be，也可在一张图中标出拟议改变；只在比较有帮助时才需要两者。
经典 Service Blueprint 来源：Bitner, Ostrom & Morgan, “Service Blueprinting: A Practical Technique for Service Innovation” (2008)。
问题、需求与机会分析视角¶
这些视角帮助从观察到的摩擦进一步理解“什么需要改变”。它们不是互斥分类，也不是必填检查表；按场景选用，必要时组合使用。
| 分析视角 | 可帮助发现的问题或机会 |
|---|---|
| Information & Sensemaking（信息与理解） | 信息缺失、分散、冲突或难以解释；相关人员难以形成足够一致的理解。 |
| Decision & Cognitive Workload（判断与认知负担） | 判断复杂、规则难用、选项或影响难比较，或需要记住过多事项。 |
| Coordination & Handoff（协作与交接） | 等待、重复沟通、责任不清、跨角色/系统交接困难或升级不顺。 |
| Workflow & Exception Handling（流程与例外处理） | 工作状态不清、任务遗漏、例外无法闭环，或实际情况无法沿预期流程处理。 |
| Work Execution & Automation（工作执行与自动化） | 重复或规则明确的执行工作负担较高；可探讨简化、自动化或更好支持，但不预设应采用自动化。 |
| Record & Transaction Integrity（记录与交易完整性） | 业务对象、状态、记录或交易的一致性、完整性或权威性不足。 |
| Control, Risk & Accountability（控制、风险与责任） | 权限、审计、责任、适用义务或风险控制影响工作如何安全完成。 |
| Experience & Access（体验与可获得性） | 用户难以在需要时找到、理解、访问或使用相关支持。 |
Persona 可帮助理解关键用户的目标、行为、知识、限制与工作环境；场景证据和问题机制帮助说明值得改善什么；两者共同为 Solution Archetype 的选择提供依据。它们都不能机械推出某个 Archetype。若问题机制、责任或预期结果仍然不同，保留多个方向供 SO 进一步探索。
SO 阶段可形成的场景产出¶
场景分析的结果用于支撑 Solution 主张，可以是 Blueprint、简图、文字说明或其组合；按需要记录，不要求每个 SO 都完成完整 Blueprint。至少让参与者能理解：
- 当前优先场景及触发情境、相关用户/角色和目标行动；
- 现有触点、信息、协作或交接中与问题/机会相关的部分；
- 观察到的摩擦或机会，以及尚未确认的原因；
- Solution 设想会改变场景中的哪些行动、触点或结果，以及这些改变支持的 User Client(s) 方向（如已形成）；
- 需要 IA 进一步评估的重要假设、条件或未知（如有）。
同一场景可保留 As-is 与 To-be 两种描述；场景有实质变化时，可注明日期或简短修订说明。无需建立场景编号体系或严格版本管理。额外场景细节本身不要求拆分 SO；只有 Solution 主张、业务责任、结果、行动边界或范围有实质差异时，才考虑形成不同 SO。
与 SO 和 IA 的关系¶
- Blueprint 和相关场景分析材料用于说明 Solution 主张所针对的场景及可能的改善方式；它们是 SO 塑形的辅助材料，不等于 SO 本身。
- IA 评估相关 Solution 主张、范围和场景假设的证据支持程度、未知与影响。证据、评估维度结论、技术判断、风险接受及投资建议记录在 IA，不把 Blueprint 变成评估台账。
- 如果 IA 促使场景或 Solution 主张发生重要变化，应说明变化内容，并与 IA 一起判断既有评估中哪些仍适用、哪些需重新检查。
- 只需轻量识别相关 SO 主张、范围和场景；无需场景编号体系或严格版本管理。保留有用的 As-is / To-be 图示或修订快照即可。
不在本方法中规定¶
本方法不要求完整服务设计、完整用户旅程图、固定泳道模板、全量 Persona、每个场景都同时绘制 As-is 与 To-be，或将所有分析视角逐项填完。它也不规定 UI、产品/平台、API、架构、数据模型、实施计划、成本估算、详细运营方案或 IA 结论。