2023年9月9—10日，人人都是產品經理聯合騰訊大講堂舉辦的【2023產品經理大會（北京站）】完美落幕。京東/阿里本地生活前資深產品專家高暉老師為我們帶來《以本地生活業務為例，看業務建模的全鏈路思考》為題的分享，本文為演講內容實錄。目前大會回放已上架，戳此購買，即可收看回放：https://996.pm/7gX2B

許多同學或者企業高管在與產研溝通的過程中，發現了一些問題：

其一，業務說不清楚什么是業務，比如業務方向的一線采購不知道如何提需求，也無法說清楚業務模式，他們只會說自己做了哪些事情、希望有什么功能。而這并不是業務的合理表達方式，這種情況的發生，導致產品在理解時可能會直接啟用業務的方案，這就產生了后續的偏差。

其二，產品側更傾向于向一線或相關部門進行調研，得到的答案往往是直接的方案，比如希望可以添加哪些功能。那么這類業務調研所收集的答案是主觀的還是客觀的？它是否可以解決業務模式中某個環節的問題，還是僅代表這一角色在個人角度下所希望得到的能力？

其三，許多人在做需求分析時更多憑借經驗進行判斷。其中是否存在著合理的邏輯關系？如何定義業務之間的轉化？不少產品同學、尤其是5-8年的產品同學可以憑借經驗找到“套路”，但卻無法說清楚如何判斷需求的合理性、需不需要解耦等一系列問題。

這就需要我們做架構建模設計，頂層設計決定底層邏輯，底層邏輯代表運行原理。架構建模設計本質上并非技術專有，它更傾向于一個基于業務導向和數據驅動的企業運行的普遍性問題解決方案。其實許多SaaS方案或多或少都有抽象建模動作，只是大家沒有相應的感知。

業務架構設計、產品架構設計也并非只對技術人員有幫助，其實業務人員和產品人員都需要這方面的思維和認知。比如業務同學在擁有架構建模思維之后，可以將無序的業務場景、多變靈活的線下場景量化描述。架構建模思維還可以幫助業務人員建立SOP，幫助他們用更標準、量化的語言進行表達。

而產品人員作為業務和技術之間的橋梁，需要將無序的業務語言轉化為可量化、可追蹤、有標準的技術語言。在具備架構建模思維之后，產品人員可以更好地進行語言轉化。

技術人員更不必說，架構建模思維可以幫助其提供滿足開發設計的前置結構化信息。

那么究竟什么是架構建模？本質上而言，架構建模是企業架構的一部分，在國內企業場景中，大多涉及到兩個環節，即應用建模與數據建模，分別對應現在常見的業務中臺與數據中臺。

而產品架構設計本質上來源于業務架構設計，但大多數企業沒有能力做業務架構設計，所以大多數情況下需要產品引導業務給出標準的、規范化的交付物。這大多發生于業務調研以及與業務溝通的需求分析場景中，由產品進行引導，業務在逐漸有了相應思維能力之后，便可以提出類似的需求或規劃，從而協助產品進行分析與規劃。

架構設計的產出物大多偏向于框架性產物，包括梳理所得的業務價值鏈、流程清單等。而產品一側需要做規劃與架構，理清建設過程與如何為業務賦能的過程。

很多同學可能不理解為什么需要做建模架構設計？是因為如果沒有架構思維，我們可能只能憑經驗知道表象，卻理解不了根本，這就導致我們無法適應場景的轉換。舉兩個例子。

第一個例子，畢加索在最開始畫牛的時候畫得很繁瑣，事無巨細，但隨著他對事物本質的理解與閱歷的沉淀，逐漸的，畢加索可以通過簡單的抽象線條讓觀眾理解他所畫的內容是牛，原因在于他抓住了問題的本質，洞察到了架構的原理。

許多同學可能在電商、零售行業做了許多年，當需要跳到新生行業、或者新的業務模式中時，架構設計思維可以幫助我們更快速地融入體系及其運行原理。比如這幾年，我為多個行業的企業做過頂層架構設計，雖然我不曾從事過相關行業，但大多數情況下，通過一個星期左右的調研，我便可以快速地畫出產品規劃與設計，原因就在于會洞察與具備架構建模思維。

第二個例子，我們要怎么表述房子的構成？答案是通過量化。所有產品的本質是將線下業務還原，變成量化型的工具或產品能力。如果做不到量化，則意味著其中存在著猜測的成分或邏輯偏差，這會導致后續的推進困難。這也是傳統企業往往無法與外包軟件長期兼容的原因，因為外包軟件中可量化的能力很少。

所以架構設計本質上解決兩個問題，其一是提煉，洞察本質，其二是量化規則。

接下來以本地生活為例為例，講述業務建模的分析思路。

一、本地生活業務特點

下圖中的模型是相對簡易的標準電商模型，用戶通過平臺下單，平臺進行基礎信息維護，用戶與商家之間通過履約能力來連接。

那么傳統電商在向本地生活過渡的過程中，是靠什么變化來完成過渡？本質上來看，是通過改變模型中的某條或多條鏈路，從而產生了新能力。本地生活和傳統電商的最大變化，就在于履約能力的變化，從傳統電商的“天”轉化成了本地生活的“小時”?？偨Y來看，本地生活與傳統電商的差異體現在這三點：

1. ?。荷碳殷w量更小，用戶范圍更??；
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中的功能點，即三級域。

通過三級梳理，我們就可以將相應的業務按照邏輯轉化為線上產品邏輯，且過程中不會存在斷點。

領域建模模型，我們可以結合脫敏數據，以訂單業務為例做出示例圖：

產品領域也有對應模塊：

這里提供一個能力矩陣模型，可分為場景和職能兩大維度。其中，場景指需要產品賦能的類型，主要包括業務執行、管理分析及流程控制：

下圖則為產品流程梳理。

在流程梳理完畢之后，即可依照先前所闡述的邏輯梳理相應的架構圖。

五、總結一下

最后說說我的感想?，F在，越來越多人選擇投身傳統行業，甚至在未來，互聯網行業也會逐漸變成傳統行業。而大開大合的快速投錢經驗已經不太適用于當下的環境，更多人選擇追求精細化與控制成本。那么，我們要怎么應對多變的環境？關鍵在于掌握“方法”——

業務本無序，老經驗不再是萬事萬靈的靈藥，掌握“道理”的學習方法才是產品長存的“鑰匙”。

大會直播回放

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