以本地生活为例，看业务建模的全链路思考

关注并将「人人都是产品经理」设为 ★ 星标

每天早上更新，与你一起成长

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

其一，业务说不清楚什么是业务，比如业务方向的一线采购不知道如何提需求，也无法说清楚业务模式，他们只会说自己做了哪些事情、希望有什么功能。

而这并不是业务的合理表达方式，这种情况的发生，导致产品在理解时可能会直接启用业务的方案，这就产生了后续的偏差。

其二，产品侧更倾向于向一线或相关部门进行调研，得到的答案往往是直接的方案，比如希望可以添加哪些功能。那么这类业务调研所收集的答案是主观的还是客观的？

它是否可以解决业务模式中某个环节的问题，还是仅代表这一角色在个人角度下所希望得到的能力？

其三，许多人在做需求分析时更多凭借经验进行判断。其中是否存在着合理的逻辑关系？如何定义业务之间的转化？

不少产品同学、尤其是5-8年的产品同学可以凭借经验找到“套路”，但却无法说清楚如何判断需求的合理性、需不需要解耦等一系列问题。

这就需要我们做架构建模设计——顶层设计决定底层逻辑，底层逻辑代表运行原理。架构建模设计本质上并非技术专有，它更倾向于一个基于业务导向和数据驱动的企业运行的普遍性问题解决方案。

其实许多SaaS方案或多或少都有抽象建模动作，只是大家没有相应的感知。

业务架构设计、产品架构设计也并非只对技术人员有帮助，其实业务人员和产品人员都需要这方面的思维和认知。

比如业务同学在拥有架构建模思维之后，可以将无序的业务场景、多变灵活的线下场景量化描述。架构建模思维还可以帮助业务人员建立SOP，帮助他们用更标准、量化的语言进行表达。

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

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

那么究竟什么是架构建模？

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

而产品架构设计本质上来源于业务架构设计，但大多数企业没有能力做业务架构设计，所以大多数情况下需要产品引导业务给出标准的、规范化的交付物。

这大多发生于业务调研以及与业务沟通的需求分析场景中，由产品进行引导，业务在逐渐有了相应思维能力之后，便可以提出类似的需求或规划，从而协助产品进行分析与规划。

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

很多同学可能不理解：为什么需要做建模架构设计？

是因为如果没有架构思维，我们可能只能凭经验知道表象，却理解不了根本；这就导致我们无法适应场景的转换。

举两个例子：

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

许多同学可能在电商、零售行业做了许多年，当需要跳到新生行业、或者新的业务模式中时，架构设计思维可以帮助我们更快速地融入体系及其运行原理。

比如这几年，我为多个行业的企业做过顶层架构设计，虽然我不曾从事过相关行业，但大多数情况下，通过一个星期左右的调研，我便可以快速地画出产品规划与设计，原因就在于会洞察与具备架构建模思维。

第二个例子，我们要怎么表述房子的构成？

答案是：通过量化。

所有产品的本质是将线下业务还原，变成量化型的工具或产品能力；如果做不到量化，则意味着其中存在着猜测的成分或逻辑偏差，这会导致后续的推进困难。

这也是传统企业往往无法与外包软件长期兼容的原因，因为外包软件中可量化的能力很少。

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

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

本地生活业务特点

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

那么传统电商在向本地生活过渡的过程中，是靠什么变化来完成过渡？

本质上来看，是通过改变模型中的某条或多条链路，从而产生了新能力。

本地生活和传统电商的最大变化，就在于履约能力的变化，从传统电商的“天”转化成了本地生活的“小时”。

总结来看，本地生活与传统电商的差异体现在这三点：

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

如下图所示，传统的B2C电商，其辐射距离、配送范围与用户范围可以扩至全国，而本地生活的辐射半径是3- 5公里，本质上解决的是时效问题，这就意味着本地生活服务需要在商家与用户选择上有所取舍。

所以从供给上可以看到，更聚焦的供给关系要求履约配送更高效，精细化运营成为必备要求。

传统的B2C电商更倾向于全品类，主要以卖货为主，要求货品尽可能丰富。

而本地生活则以生活为主，甚至还有服务类的商品如上门服务等，商品形式不再为单一的实物形式，虚拟商品成分加大。

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

辐射范围的缩小决定运营更聚焦。

这其实好坏皆有，好处在于我们可以更容易地知道用户所想要的东西，坏处在于用户更换的机率相对较小，用户画像特征往往差异不大。

在B2C场景中，用户大多以“逛”为主，可能看到什么就买什么；但生活服务场景就有所不同了——由于范围的固定，用户的生活模式可能更具有目的性，所以要以兴趣匹配为主去聚焦人群。

这个时候，可能会出现私域这类概念。

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

商家体量也变得更小，这意味着我们需要提供匹配线上运营支持，我们需要帮助小商家做好体系化进销存能力。

这一场景与十几二十年前，品牌商用户为销商供应能力的场景相类似，许多以往做ERP的人士也慢慢移植到了生活服务下游环节。

如果你具备整体架构思维逻，就会发现，其中的不少业务模式与当年的分销模式十分相似，甚至许多能力是可以复用的。

本地生活业务架构分析

很多同学可能无法理解业务，或者找到业务差异化过程中的产品切入点。

这里先厘清几个思路：

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

其二，业务架构分析大于业务调研，调研所得并不足以覆盖底层逻辑，我们需要进行深挖。

所用的方法并不复杂，利用常见的5W2H方法即可，主要的方向为“人货场”原理与日常运行规则，在了解了运行基本流程、人、盈利模式等内容之后，我们就可以开始梳理业务流程。

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

建模时需要抽象出以下几点：

其一是价值主张，很多时候，我们的价值主张总结得并不到位，价值主张本质上解释的是为什么要做这个事情，但许多人总结的是“这个工具你为什么要”。

这就存在差异了：前者是客观性的，所说明的是为业务带来什么结果，而后者是主观性的，所说明的是为什么这个角色想要这个东西。

其二，价值链。价值链是最顶层的业务流程，它决定了所有业务流程的归属。

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

最后，业务角色。

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

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

比如交易类B2C，其核心方式是正交易差价，所以其交易链路一定是其最重要的赚钱链路流程，那我们便可以围绕这一流程去梳理其二三四级业务流程。

比如分销链路是供货商模式的重点，那么分销链路的二三四级业务流程便决定了企业运转的核心流程。通过流程和环节的梳理，我们便可以清楚业务价值究竟是什么。

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

我们需要梳理出的SOP模型包括：

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

在梳理完业务流程之后，我们要形成相应的业务能力，业务能力决定了产品上的相应模块如何去支持相应的业务。

交易类的业务能力主要包括以下八类：

如果出现了个性化能力，怎么办？

其实本质上来看，我们可以从供给基本元素如生产者、生产模式、生产关系等方面的分析获得行业特殊性。

再结合先前的流程，即可形成完整的业务调研清单。

下图所示为本地生活的业务架构分析：

可以看到，本地生活主要由骑手、线下门店、平台三者构成，其基础能力相对固定。

那么本地生活所做的究竟是什么？

其实可以用不同模式“套”上去：比如3-5公里小范围内的生活服务可以“套”前置仓模式，全国范围内的服务则可以“套”传统电商。

本质上来看，这些电商模式的产品模式和业务模式大体相通。

下图是业务流程的简单分解：

在某个国外业务场景中，我们分析后发现其信息化程度仍相对落后，他们甚至需要通过对讲机进行呼叫，而后由人工线下操作、衔接发单过程。

基于此，我们做了简单的调整优化。

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

如何理解业务架构与产品架构之间的关系？

从价值流、业务SOP、到产品领域，如下图所呈现的对应关系，每个产品领域都要有明确的产品价值，这保证了后续的业务不跑偏：

本地生活产品架构设计

那么，怎么实现业务架构与产品架构的转化？

我们需要将业务的内容还原至线上场景，并做好量化和标准化。

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

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

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

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

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