亚马逊AWS官方博客

业务数字化分析与业务领域建模设计

背景

随着第四次工业革命的蓬勃发展,数字化以其独特的方式和速度给各行各业带来前所未有的变化。它不仅对数字原生企业带来机遇,对于传统行业的冲击更甚。电商的崛起、出行习惯的改变、吃饭和买菜行为的变化都是身边鲜活的例子。数字化能力,尤其是业务数字化分析设计能力,成为传统行业能否在当前赛道上继续保持竞争力的关键。

但是面对一边是错综复杂的业务,一边是陈旧冗余的IT系统,如何让IT系统构建轻量化、弹性化的能力,成为现代业务的最大诉求。

业务数字化面对的挑战

在做业务数字化的过程中,用户不同的行业属性和组织结构,都会在业务数字化分析和建模上带来不同的挑战,但是从需求抽象的层面来看,大致包含以下4类。

从这4类挑战中,我们可以看出,在做业务数字化分析设计的过程中要切中“Alignment(定位)—Analysis(分析)—Abstract(抽象)“三个层面工作。

  • Alignment(定位)

这是一个提纲挈领的环节,我们更多的是探寻对问题认知的一致性和价值主张的方向,同时在这个过程中达成业务的利益相关方与IT的共识。

  • Analysis(分析)

这个环节关注在业务过程中用户的“活动轨迹”和他的痛点、痒点,以用户视角进行分析,同时对“活动”中涉及的内外部系统进行捕捉。

  • Abstract(抽象)

通过对价值主张的理解和业务活动的分析,我们最终要形成对系统能力的构建,而构建的依据就是通过对业务分析中发现的共性业务能力和痛点分类,进行抽象聚合。

如何做业务数字化分析及业务领域建模

这是一个从宏观到具象,从具象到抽象的过程。整个过程要充分运用如设计思维、干系人地图、用户画像、用户旅程等现代化的业务分析工具,同时结合领域驱动设计方法进行业务领域划分。从业务愿景出发到业务领域建模,并找到有价值的最小业务闭环进行模型验证,我们总结了6步分析建模法。

·       业务愿景对齐

业务开展的首要基础就是愿景的清晰认知和定义。愿景要回答为什么要做这个业务这一根本问题,用来使团队目标一致,对价值主张形成共识。但是如何在短时间内快速拉齐项目干系人对业务愿景的认知,对业务价值所服务的“WHO-WHY-WHAT-HOW”形成明确目标呢?这里我们可以借用“电梯演讲”这一工具,形成思维的快速聚焦和凝练。

那什么是电梯演讲呢?电梯演讲,即elevator pitch, elevator speech,最初是一种宣讲/推销方法。目的是在短时间内(大约30秒到2分钟)向对方介绍/推销一个想法、产品、个人。对于想法、产品,通常会解释who the thing is for(服务对象), what it does(功能描述), why it is needed(用户痛点), and how it will get done(实现路径)。正是由于电梯演讲有其严谨且聚焦的逻辑框架来回答“WHO-WHY-WHAT-HOW”这些核心问题,所以在业务愿景对齐的过程中就可以快速的拉齐相关干系人的价值认知。

通常在这一过程中,我们会通过一个七段式的框架,引导业务干系人进行“发散-收敛”,来聚焦“WHO-WHY-WHAT-HOW”的问题。

·       业务梳理及痛点分析

在业务梳理和痛点识别的过程中,我们会通过“用户旅程地图”来展开分析。用户旅程开展的前提是对系统用户及业务场景的分析。用户旅程地图的分析会关注以下几个方面:

  • 达成用户目的的完整活动闭环
  • 用户的体验
  • 用户旅程(场景)中的各种接触点
  • 用户达成目标面临的痛点、挑战

·      业务领域建模

通过对业务涉及的所有用户旅程梳理,及前端触点和后台既有服务能力的分析,进行系统能力的抽象和聚合,构建业务领域模型。在建模过程中,通常依据以下步骤进行构建:

  • 以用户为核心,抽象其系统角色及涉及的业务功能。
  • 对不同用户旅程中涉及到的同类型服务,加以抽象聚合,形成特定的能力中心,确定能力中心职责及边界。
  • 对业务功能相近的能力中心可划分到同一业务功能子域。
  • 根据业务重要性及价值,定义出平台的核心子域、支撑子域、通用子域,结合平台演进路线设计和不同子域的演进方式。

·      演进路线规划

数字化平台演进路线,一般需遵循业务价值优先(通常会优先覆盖核心域能力),同时兼顾技术实现复杂度的原则,起点通常会从一个有价值的业务场景切入。如果是全新的业务需求,可以微服务化的方式新建场景下的核心域能力;如果是既有业务,可用绞杀者模式对场景下涉及到的核心域能力剥离并微服务化,并随着平台演进的深入,“由点及面”的扩展丰富每一个能力中心。对于支撑域的演进策略,与核心域的思路类似,可依据场景和实现复杂度来进行设计。通用域的能力基于其成熟性和通用性,一般可以采用成熟套件的方式接入,直接使用。

·      MVP设计

通过用户旅程分析得出的领域建模蓝图,是一个宏观全局化的思考产物,但是如何验证设计内容对实际业务的支持性呢?通常,我们会选取典型业务的典型场景或即将开展的新业务中的某一场景,按照用户旅程的思维结合对应所需的系统能力来设计端到端的完整业务价值闭环,我们把其称之为MVP(Minimal Viable Products),这一过程来贯穿整个领域模型设计。当然,这一过程不可能完全覆盖所有子域的所有能力中心,但是因其场景典型性,通常可理解为其代表了二八原则中八的部分,覆盖度有一定的保证。

对于MVP的选择,建议可以从以下几个方面进行考量:

  • 以核心业务场景为优先,MVP设计要能形成端到端的业务闭环
  • 试点具备一定的独立性,避免选择高耦合的相关系统
  • 覆盖1-2个核心域,具备一定复杂性,验证系统能力可支撑业务实际需求
  • MVP试点开发周期一般不要超过3个月,可快速验证
  • 适合组建小规模精英团队(2-Pizza Team)

参考文献

https://en.wikipedia.org/wiki/Elevator_pitch

https://en.wikipedia.org/wiki/User_journey

https://aws.amazon.com/blogs/mt/find-your-business-domains-to-start-refactoring-monolithic-applications/

https://aws.amazon.com/blogs/enterprise-strategy/two-pizza-teams-are-just-the-start-accountability-and-empowerment-are-key-to-high-performing-agile-organizations-part-1/

本篇作者

韩国庆

AWS业务架构师,SAFe SPC认证教练,熟悉领域驱动设计方法(DDD)和现代业务分析方法体系框架,对从产品愿景、用户旅程分析、用户故事地图到业务领域建模设计有丰富的实战经验,曾主导过零售、教育、医疗、社交等领域多个大型业务产品系统的业务架构设计。

李雪阳

AWS—ProServe Product Manager , 负责ProServe客户的业务分析及产品研究与交付。针对产品全生命周期中所涉及的 用研、创意、原型及交付等均有涉猎,同时也参与帮助客户利用Amazon的能力进行创新咨询与设计。