业务场景作为一种需求分析技术用途十分广泛

业务场景作为一种需求分析技术用途十分广泛。本文涛哥就和大家聊聊业务场景是什么，以及如何创建业务场景。

一、业务场景是什么？

所谓“场景”，本意是指：影视剧情中的人物在特定时间与空间内发生的行动。

而业务场景，意思是说：企业和商家需要在用户某个特定的环节中，适时提供给消费者可能需要的以及关联的产品或服务。

以“职场白骨精典型的一天”为例，那么业务场景包括：

• 一大早，“阿姨帮”的家政服务人员来敲门、做早餐；
• 小白们吃完早餐，用“滴滴”叫车去上班；
• 中午，几个同事一边吃着“饿了么”的快餐，一边讨论项目方案；
• 下班回家，“佳沃”刚送到新鲜便宜的蔬菜水果，“爱大厨”的厨师就已经上门了；
• 晚饭后，享受完“河狸家”的美甲，又在“时光网”上预定了电影票和座位，心情美美的出门约会了。

业务场景，是商家和消费者，是企业和客户，是平台商和供应商之间的连接器。这种连接器在时间和空间两个维度上进行延伸，包含了人、事、物和相关要素的集合。

场和景可以拆开理解：“场”是时间和空间的概念，一个场就是时间加空间。用户可以在这个空间里停留和消费，如果一个人不能在某个空间去停留、消费，这个场就是不存在的。

“景”是什么意思？

景就是情景和互动。当用户停留在这个空间的时间里，要有情景和有价值的互动，要能带动用户的情绪和裹挟用户的意见，这就是场景。

比如，分众广告就是在空间上，也就是通过电梯、居民楼、电影院等等，建造出一个“生活圈”媒体，从而占领人们的生活圈。而各种短视频平台，则是通过时间，也就是通过轻松好玩的视频娱乐内容占领用户的时间。

二、业务场景的要素

一个业务场景总是可以通过“谁”，“在什么环境下”，“干什么&遇到什么问题”，“如何互动”，“有何价值”这样一个范式进行表述。

• 谁：识别参与者，用人或者系统描述；
• 在什么环境下：识别上下文，用时间、空间和状态描述；
• 干什么&遇到什么问题：识别完成的事情，用任务序列描述；
• 如何互动：识别人如何与业务连接，用产品介质和服务形态描述；
• 有何价值：识别目标，用价值描述。

前三个是End-user视角，而后两个是业务视角。

以大家熟悉的扫码点餐这一场景，业务场景和要素的映射关系如下：

通过场景识别，我们可以将需求和解决方案构想链接起来，形成初始的可验证解决方案。

1. 业务触点

前面我们提到了业务场景是人和产品交互的上下文。

这个交互的过程在时间和空间上具有连续性，而触点触点就是业务场景的起点，也是人切入场景的方式、模式和方法。

在扫码点餐的案例中，二维码充当了触点，除了二维码其他常见的触点还包括：

• 搜索引擎：目前主流的搜索引擎推广有百度、搜狗、360；
• 电商流量：电商流量也是O2O入口中比较重要的一种；
• 与消费者的即时聊天：客服系统是引流客户的关键；
• 地图导航入口：现在各大地图导航都植入了本地化的生活服务信息，是引流客户的重要平台；
• 评价信息入口：这种方式电商平台用的比较多；
• 促销入口：通过转发促销信息，让消费者可以获得更多优惠，进而起到引流作用；
• 支付入口：如餐饮店里结账时关注店里的微信公众号可以得到优惠；
• 广告联盟入口：最常见的就是各种互推广告；
• 免费wifi入口：酒店、餐饮行业用的比较多，顾客想用wifi 就得先关注店里的微信公众号；
• 上门服务入口：家政服务、家政。

对于企业用户来说，触点还包括：

• 企业办公入口：如待办提醒、邮件提醒、工作电子流、会议等；
• 员工管理入口：如考勤、绩效考评、总结汇报、员工团建、薪酬发放、招聘、培训等；
• 业务入口：如签订合同、采购、入库、调配、对账、结算、支付等；
• 用户服务入口：如到店、400电话、APP、门户网站、二维码等。

产品经理在充分考虑到用户时间与空间的立体化接触点后，还需要针对企业服务流中的每一个细节去挖掘其商业价值。

三、如何创建业务场景

1. 识别主题

首先是是识别主题，主题确定了业务场景中的上下文，也就是环境和状态。

可以通过利益相关者访谈、市场调研、头脑风暴的方式获取主题的相关信息。

以访谈为例，提问的内容可以是：

• 你现在面临的问题是什么？
• 如果这个问题解决了，你将能够做些什么？
• 你在哪里遇到这个特殊的问题？在什么业务流程？
• 你什么时候遇到这些问题？
• ….

以某服装连锁门店CRM项目为例，通过市场调研和客户访谈，我们了解到客户需求是门店进行数字化改造，核心诉求就是提高客户到店转化率。

2. 判断角色和入口场景(触点)

接下来就是确定参与者。参与者是业务场景中行动的发起方，或者说“主动方”，术语“施动者”是对参与者的另外一个叫法。

参与者可以分为“参与者-人”，“参与者-计算机”系统两大类。而角色指的是“参与者-人”在使用系统过程中扮演的角色，常见的角色包括：

• 公司管理者
• 部门经理/主管
• 部门业务员
• 后台管理者
• End-user
• 开发商
• 供应商
• 合作伙伴

可以通过回答这样一组利益相关者的问题来分析场景：

• “参与者-人”是谁？
• 参与者的期待是什么？
• 参与者主要任务是什么？
• 参与者必须读/写/更改任何信息吗？
• 参与者是否必须通知系统外部的变化吗？
• 参与者是否希望被告知意外的变化吗？

针对主题六，我们可以获取到这样一组分析结果：

通过以上几个问题，我们可以确定几个业务场景：

• 场景一：店长需要在店铺管理中了解相关的数据
• 场景二：店长需要知道数据背后的原因
• 场景三：店长需要采取相应的行动，包括下单采购新品、提高员工服务水平等。

3. 延伸场景，整理“角色”预期的步骤

常见的业务场景延伸技术包括用例图、价值流分析、用户故事等。

3.3.1 UML用例图

UML用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图，常被用于描述参与者和参与者、参与者和系统之间的关系，是一种常见的业务场景分析技术。

用例图中涉及的关系有：关联、泛化、包含、扩展。

UML用例图

UML用例图有五种功能：用例图、静态图、行为图、对象图、实现图。

其中用例图用于从用户角度描述系统功能，指出各个功能的操作者（角色），本例中操作者包含店长和店员，其中店长涉及的操作功能如图：

行为图描述系统动态模型与对象组成的交换关系