业务场景是在形成顾客期望、影响顾客经历和实现服务组织差异化等方面发挥着重要作用。从吸引顾客，到保留顾客，再到提升顾客关系，在服务组织实现这一系列顾客关系目标的过程中，业务场景都有着深刻的影响。业务场景曾被定义为业务所处的建构环境，这种定义及由此而形成的业务场景框架只是建立于“有形环境”这一个维度上。
业务场景不支持什么意思
该场景暂不可用。
业务场景是在形成顾客期望、影响顾客经历和实现服务组织差异化等方面发挥着重要作用。
从吸引顾客，到保留顾客，再到提升顾客关系，在服务组织实现这一系列顾客关系目标的过程中，业务场景都有着深刻的影响。
流程感悟
首先，要明确几点认知，这是开展流程建设工作的基础，后面的建设步骤中会用到。
1、流程是流程，文件是文件，二者不是一回事。 流程的本质是一组活动流，其可以是原生态自然形成的，也可以是人为干预后的。文件是描述和定义流程的，特别是描述人为对流程进行理解、分析、梳理、规划、重构等干预成果的。
2、文件有多种类型。 如流程图、控制程序、流程指南、管理制度、工作规范、作业指导等等。根据需要而选用。
3、分清什么是业务模式，什么是业务场景。 业务模式与价值链模型相关，服从相同价值链模型的，就是同一种业务模式，比如说“to B销售”，就是一种业务模式。业务场景跟业务活动的运作场景有关，同一个业务模式，可能细分为很多种业务场景，比如说“针对轨道交通行业的to B销售”，就是一种业务场景。
4、尽量不要为每一种业务场景都建立一个单独的流程。 这样组织里面流程太多太散，不够集约。不便后续管理、监控和数据分析。相同业务模式的，尽量统一成同一个基础流程。
5、同一个业务模式下的各种典型业务场景，应考虑在同一个基础流程的框架下，在应用层加以变化。 在文件中予以明确。比如可同一个基础流程图，对应多个流程控制程序，每一个业务场景一个控制程序。模式定流程，场景定应用。
6、要理解“最详流程，最优实现路径”。 在梳理和策划基础流程时，要考虑最复杂的业务场景，定出具有普遍性，兼顾特殊性的流程出来。并明确流程中的关键路径和关键活动。在策划业务场景的流程程序时，要考虑场景的特殊性，确定出最优的应用路径出来。
7、要理解“流程角色”和“职能岗位”的区别。 同一个流程角色，在不同的业务场景下，可以由不同的职能岗位担任。
下面是单一流程的建设步骤：
第一步： 确定需要建设的流程，明确其建设的必要性和迫切性。一切以痛点为导向，无痛点，不轻易动手。
第二步： 分析流程所属于的业务模式和业务场景，确定其是否归属于哪一个基础流程。
第三步： 对该基础流程进行流程规划，确定流程的定位、边界、价值链模型、输入输出。
第四步： 确定基础流程的流程所有人，承担流程建设责任。初期流程所有人可以由流程管理部的人担任，后期还是最好由业务负责人担任。
第五步： 确定基础流程当前的现状、痛点（没有流程？流程不清晰？流程混乱？流程风险？流程效率？），判断是否需要建设。基础流程没建设好，来搞对应业务场景的流程，基础不牢。
第六步： 确定基础流程建设的阶段性目标，也就是这一轮流程建设要达成的样子。此时切忌完美主义，一定要确定出可以达成的阶段性小目标。
第七步： 梳理初版基础流程，画成流程图，保持基本流程活动畅通，确定出流程角色。以及在典型的业务场景下，流程角色所对应的职能岗位。
第八步： 把对应业务模式（例如，整个to b销售）的基础流程确定下来。召集整个业务模式的各个典型场景的流程角色，一轮或多轮会议PK，从流程的价值链模型起步梳理，考虑流程的普遍性和特殊性，先把整个业务模式的流程图定下来。在这个过程中，流程所有人，及流程部的流程工程师，在其中要起到“引导师”的作用。各流程角色要致力于发表建设性意见，不要情绪，不要抱怨，不要光提问题不提解决方案。经过一轮又一轮，逐步把基础流程的成熟度攀升，最终确定一个终版的流程图出来。（一般以泳道图的形式呈现）
第九步： 在确定基础流程之后，再来搞基础流程在业务场景的应用。再组织一轮或多轮会议PK，召集相关业务场景（如轨道交通行业销售）的各职能岗位人员，代表相应的流程角色，对该业务场景下的流程发表意见。从痛点解决、风险控制、保持效率等多个角度，并考虑通用的流程中的设定的关键活动和关键路径，对具体到该业务场景下流程的应用发表建设性意见（不抱怨、不情绪、不只提问题不给方案）。经过一轮又一轮，逐步把该业务场景的流程应用的成熟度攀升，最终确定一个终版的流程文件出来（一般以程序文件的形式呈现）。
第十步： 把第八步形成的流程图和第九步形成的流程文件，都整理出来，受控发行，执行和监控。并适度考虑，有无信息或技术手段，对流程或程序加以固化。
以上转至夏恩余老师！
有效需求分析-业务场景分析
识别出系统要支持的业务场景之后，将以“场景-问题/挑战-方案”的逻辑来分析每个业务场景，从而导出所需的功能；细化业务事件流，从而实现以用户角度发现系统应该提供的功能，深入了解用户视角的场景描述；
基于操作界面为线索的讲述，用户就必须接受这个复杂，非用户预期逻辑的操作过程，这样是难以融入和理解的，所以要给用户创设使用场景，提升带入感，在需求分析中先梳理整个使用场景的各个步骤，也就能够让用户更有带入感地发现功能需求；具体应该怎么做呢？简单来说：（1）场景细化：将场景细化为事件流，整理出用户预期的正常步骤，然后写出变化的情况；（2）问题/挑战识别：针对每一步骤，站在用户的角度来思考他们会遇到什么问题，面对什么样的挑战；（3）思考应对方案：针对这些问题，思考系统应该提供什么样的功能；
目的：建立大家对场景的认识
（1）明确业务场景中，用户要实现的业务目的：用一句话概述用户在此场景下的业务目的，尽量使用用户语言，重在传达用户的意图；
（2）业务场景前提条件确定：有部分业务场景存在执行条件，比如：前置条件（用户在执行该业务场景之前，系统需要检查什么状态）、后置条件（用户在结束该业务场景之前，系统需要检查以确保什么状态）；
（3）是否有其他人关注此业务场景：一个业务场景中，除了执行它的用户之外，可能涉及上游、下游、管理者、协作者等其他关心该场景的其他人；
可通过访谈用户代表、观察他们的工作来细化业务场景的业务步骤，思考最典型的、用户预期内的业务步骤是怎么样的（基本事件流），针对各个步骤，有哪些潜在的变化情况（扩展事件流），有无异常情况，异常如何处理（异常事件流）；
（1）重在人机交互而非人机界面，重在用户意图而非用户动作；以用户意图的角度陈述人机交互，简洁且易懂；
（2）不是写程序，而是结构化陈述；
用例描述通常就是细化业务步骤，通过“遍历步骤分析困难”的方法，导出所需的功能，针对每一步骤与客户了解存在的困难、挑战，然后构思系统解决方案；思考：（1）在执行各个业务步骤、变化及异常情况下会遇到什么困难？（2）系统需要提供什么样的功能支持？（3）是否存在不能按以上步骤处理的情况？这种情况需要系统提供什么样的功能支持？
在分析一个业务场景时，需要考虑到环境、业务特点给系统实现带来的要求和影响；主要从 3 个方面考虑：（1）性能：执行该业务场景的人数、典型的业务量、峰值情况的业务量、密度；（2）易用性：用户的成长经历和相关系统使用的经验，它对于系统易用性设计有指向性作用；（3）部署环境：说明用户所在的网络，软硬件等相关环境；
交互设计起到澄清需求的作用：（1）交互过程：界面流转图，用来表达你希望系统如何实现该场景的所有业务步骤；（2）静态快照：即每个页面上的具体内容，可以使用之纸上原型呈现；（3）设计说明：针对每个页面内容、界面流转做一些描述，核心在于说明自己为什么这样考虑，以及他是一种建议还是一种约束；
