目录
业务场景分析
业务场景包括“场”和“景”，“场”是时空，“景”是情绪和互动。
熟悉开心麻花的同学应该都看过宋晓峰的小品。宋晓峰有一句口头禅，就是“此次此景我想吟诗一首”。
此“情”就是舞台和show time这个时间，而“景”就是气氛烘托下有点"嗨”的情绪和互动。
我在《业务架构师眼中的需求是什么？》一文中讲过：用户需求是用户在一定场景下产生的某种欲望或解决某些问题的需要。业务场景是业务需求的三要素之一，脱离业务场景谈需求无异于缘木求鱼。
业务场景分析是一种需求分析方法，它主要聚焦于某一类业务或某一组流程在特定环境下的运行上下文和逻辑。例如同样的产品，根据不同的客户需求或时期，生产制造流程可能分为按订单生产，按库存生产等。
业务场景包括了”谁“，”在什么情况下“，”做什么“，”为什么“四个要素。
之所以采用业务场景分析流程，主要是因为不同的产品类型，甚至相同的产品在不同的生命周期阶段，业务流程可能会有所差别。所以业务流程必须放在不同的场景下具体分析，才能验证流程的合理性，并结合业务场景进行优化和改进。
其次，我们讲业务场景切割了业务需求，用户的很多需求是通过场景激发出来的，如果不深入到用户的场景，很难挖掘出用户一些隐形需求。例如如果你打算做一个OA办公软件，可能需要考虑居家办公这样一个场景。居家办公时间会更为分散，人员也更加分散，如果你要做一个可以覆盖居家办公场景的软件，你就要思考如何添加更多的协同功能：如看板、提醒、异步操作等，可能还要增加更多权限管理。集中办公场景下，企业可以安排一个归档管理员统一归档文件，但分散办公后，每个人都需要上传文档，怎么管理权限就是产品需要考虑的问题。
业务场景不是一个独立的时空，而是发生迁移的连续的时间或者空间。例如一个用户使用滴滴打车，那么随着时间的迁移，TA要经历“叫车-》等车-》坐车》下车"四个场景，每个场景下用户都会有一些特殊的需求被激发出出来，例如下车的时候我希望抬腿就走，而不是坐在那里扫码支付，这样会引导产品经理设计一个免密自动支付的功能。
业务场景分析通常会结合流程分析，业务场景可以理解为业务流程的发生的阶段。流程和场景的关系就像珍珠项链里的珍珠和链子，流程就是串联起所有场景的那个链子。
业务场景建模案例
案例背景
我们以瑞星咖啡为例，介绍业务场景建模的设计过程。
瑞星是一家咖啡连锁店，有自营和联营两种模式。截至2022年年末，瑞幸咖啡门店数量达8214家，其中自营门店5652家，联营门店2562家。
瑞幸的门店类型，主要有四种：
-
旗舰店：S类店，丰富场景+堂食+外送；
-
悠享店：A类店，丰富场景+堂食+外送；
-
快取店：B类店，简配场景+自提+外送；
-
外卖厨房店：C类店，只做外送，不支持自提。
打开瑞星咖啡的小程序，你可以看到最上面三个一级菜单:到店取、幸运送、电商购。这三个一级菜单就是瑞星咖啡的三个主功能。
我们以到店取这个主功能为例，示范如何将模糊的“取餐”业务功能变得清晰明确。
我们采取的是业务场景+业务流程结合的分析方法。
第一步：识别业务触点
业务触点就是用户需求被触发的场景，以喝咖啡为例，就是“在什么时间，什么地点，我会有想喝咖啡的情绪或行为”。业务触点也可以理解为用户需求被触发的上下文，在业务架构中通常被建模为一个业务事件。
在一个充满竞争和交付压力的职场环境下，喝上一杯咖啡提神醒脑是很多白领的工作常态。除了咖啡机以外，很多人会选择外卖这种更便捷的消费方式。
数据显示，在中国用户咖啡消费行为当中，70%的是外带消费，只有30%的用户是留在店里，瑞幸目前聚焦的就是70%外带消费需求市场。瑞幸的早期的定位和场景场景非常清晰。
产品定位：“让咖啡找人，而不是人找咖啡。”
业务场景：写字楼(地点)+下午茶(时间）+外卖/自提（交互方式）
瑞幸找到了一个市场空白点，创造了新的消费场景。
第二步：识别主业务流程
有了这样一个业务触点，接下来通过流程分析，理骨架。主流程我们一般会舍弃细节，是业务大框清晰。
一个咖啡自取的主流程包括：提前下单/到店取餐/售后服务。
这三个阶段实际上也是三个细分的业务场景。在识别业务场景是我们需要注意的是：
1）是否发生了时空的显著变化？例如本例中，三个阶段在时间和空间上都发生了显著的变化
2）是否是从用户视角思考问题？例如本例中，我们用提前下单，而非在线下单，业务场景场景需要从用户视角描述，避免将解决方案也代入进去。
3）是否符合业务逻辑？例如一个去医院要先进行预约，这是系统外部条件进行了约束，这个约束会影响业务需求。我们如果做一个医院的APP就要识别出这种外部约束对用户行为逻辑的影响。
第三步：细化流程分析
有了主流程，我们可以继续细化流程，找分支。我们可以将主流程的每一个阶段(业务场景)进行细分，拆分出子流程。从不同视角看，每一个子流程也可以看做一个子功能。
-
提前下单包括四个子流程：身份识别、选择门店、选择商品、支付。
-
到店取餐包括三个子流程：去店、到店、取餐。
-
售后服务包括一个子流程：开发票(可选)
我们细化流程时也是按照第二步中的三个注意事项进行拆解的。列如，我们在识别去店和到店的思考是因为这两个过程时空发生了显著的变化，而发生显著变化意味者用户可能会产生新的需求。
同样的，我们在流程分析阶段也尽量不要代入解决方案，如我们用身份识别而不是“登录/注册”。
对于复杂的系统，可以继续拆解，细分每一个流程。在本例中，选择商品可以进一步分解为选择优惠券和选择规格两个三级流程。
到店可以分解为排队(非必须)和订单识别两个三级流程。开发票可以分解为填写开票信息和开票申请两个三级流程。
第四步：识别IT应用需求
在识别了一个业务触点、主干流程(包含3个业务场景)和11个分支流程后，可以进一步识别出实现这些业务流程的IT应用需求。
IT应用需求我们可以采用应用服务来进行建模。例如身份识别需要鉴权服务来实现；选择门店通过定位服务来实现(通过用户的位置自动定位到距离用户最近的门店)。服务我们习惯用动词+名词的形式来表述，例如提供优惠券，核销订单等等。
注意并不是所有业务流程都需要IT应用来实现，如取餐这个流程是通过人工服务来实现的。
所有的业务流程都是通过以下三种模式来实现的：
1)纯手工：靠工作人员或者客户自己手工处理，没有IT系统的辅助；
2)全自动：靠IT应用系统自动处理；
3)半手工/半自动：有IT应用系统辅助，但需要工作人员或客户操作和交互。
在本例中，定位用户和发出取餐通知是全自动处理的，取餐是纯手工处理的，其他都是半手工/半自动服务。
第五步：分配功能，识别应用
承接上一步，上一步识别了应用服务，还没有到具体的应用组件。
接下来，我们需要整理所有的应用功能和应用服务，并映射到到相应的应用系统和和应用组件中。
我们可以根据服务的模式来识别是前台还是后台功能：
-
半手工/半自动服务都是前台功能；
-
全自动服务是后台功能
-
支撑前台服务的后台服务也是后台功能。
用户前台功能我们可以封装到APP或者小程序中，并通过移动终端(建模为节点)来承载，后台功能可以封装到后台系统中，通过后台服务器来承载。
至此，瑞幸咖啡的“到店自取”这个核心功能的所有子功能和系统已经被我们识别出来。
End
493
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
