2023年9月9—10日，人人都是产品经理联合腾讯大讲堂举办的【2023产品经理大会（北京站）】完美落幕。京东/阿里本地生活前资深产品专家高晖老师为我们带来《以本地生活业务为例，看业务建模的全链路思考》为题的分享，本文为演讲内容实录。目前大会回放已上架，戳此购买，即可收看回放：https://996.pm/7gX2B

许多同学或者企业高管在与产研沟通的过程中，发现了一些问题：

其一，业务说不清楚什么是业务，比如业务方向的一线采购不知道如何提需求，也无法说清楚业务模式，他们只会说自己做了哪些事情、希望有什么功能。而这并不是业务的合理表达方式，这种情况的发生，导致产品在理解时可能会直接启用业务的方案，这就产生了后续的偏差。

其二，产品侧更倾向于向一线或相关部门进行调研，得到的答案往往是直接的方案，比如希望可以添加哪些功能。那么这类业务调研所收集的答案是主观的还是客观的？它是否可以解决业务模式中某个环节的问题，还是仅代表这一角色在个人角度下所希望得到的能力？

其三，许多人在做需求分析时更多凭借经验进行判断。其中是否存在着合理的逻辑关系？如何定义业务之间的转化？不少产品同学、尤其是5-8年的产品同学可以凭借经验找到“套路”，但却无法说清楚如何判断需求的合理性、需不需要解耦等一系列问题。

这就需要我们做架构建模设计，顶层设计决定底层逻辑，底层逻辑代表运行原理。架构建模设计本质上并非技术专有，它更倾向于一个基于业务导向和数据驱动的企业运行的普遍性问题解决方案。其实许多SaaS方案或多或少都有抽象建模动作，只是大家没有相应的感知。

业务架构设计、产品架构设计也并非只对技术人员有帮助，其实业务人员和产品人员都需要这方面的思维和认知。比如业务同学在拥有架构建模思维之后，可以将无序的业务场景、多变灵活的线下场景量化描述。架构建模思维还可以帮助业务人员建立SOP，帮助他们用更标准、量化的语言进行表达。

而产品人员作为业务和技术之间的桥梁，需要将无序的业务语言转化为可量化、可追踪、有标准的技术语言。在具备架构建模思维之后，产品人员可以更好地进行语言转化。

技术人员更不必说，架构建模思维可以帮助其提供满足开发设计的前置结构化信息。

那么究竟什么是架构建模？本质上而言，架构建模是企业架构的一部分，在国内企业场景中，大多涉及到两个环节，即应用建模与数据建模，分别对应现在常见的业务中台与数据中台。

而产品架构设计本质上来源于业务架构设计，但大多数企业没有能力做业务架构设计，所以大多数情况下需要产品引导业务给出标准的、规范化的交付物。这大多发生于业务调研以及与业务沟通的需求分析场景中，由产品进行引导，业务在逐渐有了相应思维能力之后，便可以提出类似的需求或规划，从而协助产品进行分析与规划。

架构设计的产出物大多偏向于框架性产物，包括梳理所得的业务价值链、流程清单等。而产品一侧需要做规划与架构，理清建设过程与如何为业务赋能的过程。

很多同学可能不理解为什么需要做建模架构设计？是因为如果没有架构思维，我们可能只能凭经验知道表象，却理解不了根本，这就导致我们无法适应场景的转换。举两个例子。

第一个例子，毕加索在最开始画牛的时候画得很繁琐，事无巨细，但随着他对事物本质的理解与阅历的沉淀，逐渐的，毕加索可以通过简单的抽象线条让观众理解他所画的内容是牛，原因在于他抓住了问题的本质，洞察到了架构的原理。

许多同学可能在电商、零售行业做了许多年，当需要跳到新生行业、或者新的业务模式中时，架构设计思维可以帮助我们更快速地融入体系及其运行原理。比如这几年，我为多个行业的企业做过顶层架构设计，虽然我不曾从事过相关行业，但大多数情况下，通过一个星期左右的调研，我便可以快速地画出产品规划与设计，原因就在于会洞察与具备架构建模思维。

第二个例子，我们要怎么表述房子的构成？答案是通过量化。所有产品的本质是将线下业务还原，变成量化型的工具或产品能力。如果做不到量化，则意味着其中存在着猜测的成分或逻辑偏差，这会导致后续的推进困难。这也是传统企业往往无法与外包软件长期兼容的原因，因为外包软件中可量化的能力很少。

所以架构设计本质上解决两个问题，其一是提炼，洞察本质，其二是量化规则。

接下来以本地生活为例为例，讲述业务建模的分析思路。

一、本地生活业务特点

下图中的模型是相对简易的标准电商模型，用户通过平台下单，平台进行基础信息维护，用户与商家之间通过履约能力来连接。

那么传统电商在向本地生活过渡的过程中，是靠什么变化来完成过渡？本质上来看，是通过改变模型中的某条或多条链路，从而产生了新能力。本地生活和传统电商的最大变化，就在于履约能力的变化，从传统电商的“天”转化成了本地生活的“小时”。总结来看，本地生活与传统电商的差异体现在这三点：

1. 小：商家体量更小，用户范围更小；
2. 快：配送速度更快，商家触达更快；
3. 灵：服务能力更灵活，售卖品类更灵活。

履约方式的变化造就了本地生活业务模式的变化，所以在做业务理解时，可以先从供给方向切入。

如下图所示，传统的B2C电商，其辐射距离、配送范围与用户范围可以扩至全国，而本地生活的辐射半径是3- 5公里，本质上解决的是时效问题，这就意味着本地生活服务需要在商家与用户选择上有所取舍。所以从供给上可以看到，更聚焦的供给关系要求履约配送更高效，精细化运营成为必备要求。

传统的B2C电商更倾向于全品类，主要以卖货为主，要求货品尽可能丰富。而本地生活则以生活为主，甚至还有服务类的商品如上门服务等，商品形式不再为单一的实物形式，虚拟商品成分加大。

品质类型则可以依照履约方式分为到家与到店，比如常见的外卖与到店自取场景。品类规格也相对更轻量，因为生活服务类的配送能力更为轻量化与现代化，运载能力相对较弱。这也导致了商品模型、商品打签策略上的差异。

辐射范围的缩小决定运营更聚焦，这其实好坏皆有，好处在于我们可以更容易地知道用户所想要的东西，坏处在于用户更换的机率相对较小，用户画像特征往往差异不大。在B2C场景中，用户大多以“逛”为主，可能看到什么就买什么。但生活服务场景就有所不同了，由于范围的固定，用户的生活模式可能更具有目的性，所以要以兴趣匹配为主去聚焦人群。

这个时候，可能会出现私域这类概念，因为人群变小，我们可以更容易地抓住核心用户，这类场景的私域收益也会大于B2C场景下的私域收益。

商家体量也变得更小，这意味着我们需要提供匹配线上运营支持，我们需要帮助小商家做好体系化进销存能力。这一场景与十几二十年前，品牌商用户为销商供应能力的场景相类似，许多以往做ERP的人士也慢慢移植到了生活服务下游环节。如果你具备整体架构思维逻，就会发现，其中的不少业务模式与当年的分销模式十分相似，甚至许多能力是可以复用的。

二、本地生活业务架构分析

很多同学可能无法理解业务，或者找到业务差异化过程中的产品切入点。这里先厘清几个思路。

首先，不少同学首先做的，是业务调研，但实际上，我们应该做业务架构分析，看清运行原理。

其二，业务架构分析大于业务调研，调研所得并不足以覆盖底层逻辑，我们需要进行深挖。所用的方法并不复杂，利用常见的5W2H方法即可，主要的方向为“人货场”原理与日常运行规则，在了解了运行基本流程、人、盈利模式等内容之后，我们就可以开始梳理业务流程。

而很多同学在业务流程和产品需求之间跳过了一步，即建模。如下图中的交易类模型，我们需要从交易方式、渠道、供给这三个方向进行建模。建模时需要抽象出以下几点。

其一是价值主张，很多时候，我们的价值主张总结得并不到位，价值主张本质上解释的是为什么要做这个事情，但许多人总结的是“这个工具你为什么要”。这就存在差异了，前者是客观性的，所说明的是为业务带来什么结果，而后者是主观性的，所说明的是为什么这个角色想要这个东西。

其二，价值链。价值链是最顶层的业务流程，它决定了所有业务流程的归属。举个例子，电商平台等交易类业务的核心价值链是“交易”，“交易”的核心节点可能有多个，如下单、支付、妥投等，而所有的流程都需要为这些节点所服务。我们需要知道这层关系。

最后，业务角色。

以上几点总结出来之后，我们就可以知道为什么做、做的大体方法和路径、具体怎么做以及谁去做。

业务价值链虽然相对较虚，但仍可以通过量化的方式来寻找到，即通过对商业模式和盈利方式进行业务访谈，从而找到对应的业务价值链路。

比如交易类B2C，其核心方式是正交易差价，所以其交易链路一定是其最重要的赚钱链路流程，那我们便可以围绕这一流程去梳理其二三四级业务流程；比如分销链路是供货商模式的重点，那么分销链路的二三四级业务流程便决定了企业运转的核心流程。通过流程和环节的梳理，我们便可以清楚业务价值究竟是什么。

再往下拆解，价值链还可推导出所需的SOP内容，许多业务都会梳理SOP，但他们无法将其进行量化。我们需要梳理出的SOP模型包括：

1. 价值流阶段（SOP流程节点）；
2. 业务子流程/规则（执行SOP的方式）；
3. 业务能力（通过流程和规则形成的结果）；
4. 业务角色（使用业务能力的人）。

接下来，就可以进入业务调研流程了，具体包含七大要素，如图所示：

在梳理完业务流程之后，我们要形成相应的业务能力，业务能力决定了产品上的相应模块如何去支持相应的业务。交易类的业务能力主要包括以下八类：

如果出现了个性化能力，怎么办？其实本质上来看，我们可以从供给基本元素如生产者、生产模式、生产关系等方面的分析获得行业特殊性。再结合先前的流程，即可形成完整的业务调研清单。

下图所示为本地生活的业务架构分析。可以看到，本地生活主要由骑手、线下门店、平台三者构成，其基础能力相对固定。那么本地生活所做的究竟是什么？其实可以用不同模式“套”上去，比如3-5公里小范围内的生活服务可以“套”前置仓模式，全国范围内的服务则可以“套”传统电商。本质上来看，这些电商模式的产品模式和业务模式大体相通。

下图是业务流程的简单分解。在某个国外业务场景中，我们分析后发现其信息化程度仍相对落后，他们甚至需要通过对讲机进行呼叫，而后由人工线下操作、衔接发单过程。基于此，我们做了简单的调整优化。

三、业务架构和产品架构的关系

如何理解业务架构与产品架构之间的关系？从价值流、业务SOP、到产品领域，如下图所呈现的对应关系。每个产品领域都要有明确的产品价值，这保证了后续的业务不跑偏。

四、本地生活产品架构设计

那么，怎么实现业务架构与产品架构的转化？我们需要将业务的内容还原至线上场景，并做好量化和标准化。

简单来说，在拿到业务流程之后，我们需要理清其核心价值与核心链路，随后定义抽象标准，其后按照底层逻辑、流程分析的规则与元素等，形成产品文档。

产出物可对应常见的BRD、PRD、交互图与架构图。可能的区别在于事件命令清单，它是转化业务架构与产品架构的关键所在。

下图所示的分层建模模型的核心理论为DDD理论，即“领域驱动设计”，开发人员可能使用得相对较多，产品人员则可以使用这套模型帮助业务和产品之间做好建模转化，把流程图量化为具体元素，进而结合元素撰写PRD与产品规划。

分层建模主要解决三个问题：

1. 业务需求分析如何转化；
2. 如何量化业务流程；
3. 如何量化规则与标准。

业务架构转化为产品架构也存在着一定路径：

• 第一步：获取业务输入，理解业务；
• 第二步：梳理价值流&业务模型；
• 第三步：产品架构设计。

最终，产出架构图与实时路径（roadmap）。

业务一侧所遵循的路径如下图所示：

其中，可以关注一下“事件风暴”，事件风暴可以最大程度还原业务线上行为，确保价值链在系统层面解读准确。在“事件风暴”中可以提炼出以下几点：

• 事件 → 某个行为的结果
• 属性 → 事件的输入、输出
• 命令 → 某个动作行为
• 角色 → 命令的触发者

这里以审核业务为例梳理了相应的事件与命令清单，在流程图画完后，我们可以基于每个节点梳理相应事件，事件梳理出来后，状态机便明晰了。命令明晰之后，我们即可知道每个节点的关键动作是什么，甚至产生子流程，最终通过流程分解，形成立体状的清单，再依凭清单做好一二级规划或PRD。

下图所示为SOP/业务流程与系统流程/逻辑之间的对应关系：

这里重点讲解领域建模模型，结合价值流及业务流程，对事件、命令不同纬度的使用和归纳，可以形成相应的产品领域：

在DDD领域中，有个概念叫“聚合根”，通过事件、命令可以提炼出相应的聚合根。再往下会出现“限界上下文”这一概念。如何理解“限界上下文”？即功能使用场景，比如信息维护、策略调度、任务分发等场景，我们可以通过事件与命令的二次聚合形成二级模块。最终，所有的事件与命令可以形成PRD中的功能点，即三级域。

通过三级梳理，我们就可以将相应的业务按照逻辑转化为线上产品逻辑，且过程中不会存在断点。

领域建模模型，我们可以结合脱敏数据，以订单业务为例做出示例图：

产品领域也有对应模块：

这里提供一个能力矩阵模型，可分为场景和职能两大维度。其中，场景指需要产品赋能的类型，主要包括业务执行、管理分析及流程控制：

下图则为产品流程梳理。

在流程梳理完毕之后，即可依照先前所阐述的逻辑梳理相应的架构图。

五、总结一下

最后说说我的感想。现在，越来越多人选择投身传统行业，甚至在未来，互联网行业也会逐渐变成传统行业。而大开大合的快速投钱经验已经不太适用于当下的环境，更多人选择追求精细化与控制成本。那么，我们要怎么应对多变的环境？关键在于掌握“方法”——

业务本无序，老经验不再是万事万灵的灵药，掌握“道理”的学习方法才是产品长存的“钥匙”。

大会直播回放

目前大会回放已上架，戳此购买，即可收看回放：https://996.pm/7gX2B