產品業務模型，是整個產品的核心模型。好的業務模型，可以通過對日常業務的抽象形成基本要素，通過對要素的再組合，在滿足現有業務的情況下，預見中長期的業務創新。

為什么有些產品經理，經常能預見業務方的需求了？因為日常的產品需求，大多數是原有要素的排列組合，或者在原有基礎上加入部分新的要素（對原有模型的豐富）。因此對于產品經理來說，整理出一個好的業務模型，并用它來指導工作，可以批量解決大部分的日常需求，同時底層的業務架構會更加明晰，盡可能減少對系統打補丁的情況。接下來，我們就來看看，如何搭建一個完善的業務模型吧！

一、組成——產品業務模型構成

產品的業務模型是業務的抽象模型，包括從底層的業務對象，業務范圍、業務限制、業務規則等、執行層的數據流動方式及展現層的前臺展現交互的設計。一個較為通用的業務模型模板，可以由架構層，數據層，展現層三層構成。其中各層的主要內容為：

• 架構層：業務對象、業務范圍、業務規則等；
• 實現層：產品的數據流動，及技術實現的流程；
• 展現層：交互設計，邊際條件設計，空白、報錯提示等。

二、準備——深入了解業務

業務模型最難設計的部分，也是最底層的部分，當屬業務架構層。要設計好業務模型，需要對業務具備一定的了解。

對業務的了解，可以分為3個部分，分別是對業務背景的了解，對業務本質的了解，以及對業務邊界的了解。下面，以交易中的一個簡單功能，限購，進行舉例。

01 對業務背景的了解

限購業務產生的背景主要有二：

a.特價商品，讓利過大：這個業務剛開始，是源于商家進行限時特價，拉新讓利。商家進行相關營銷的目的是，通過讓利，刺激拉新及留存。這就需要盡可能多的讓新用戶及老用戶能夠享受到讓利。

然而實際操作過程中可能出現的三種損害商家利益的情況： 一些用戶拍得過多，影響其他客戶的購買； 一些用戶惡意拍光庫存讓活動商品下架（惡拍）； 拍光低價商品，然后到平臺進行倒賣，沖擊市場價格。

為了限制這部分胃口過大用戶，惡意用戶及羊毛黨，商家有了對用戶購買件數限制的需求。這是需求的起源。

后續隨著營銷業務的發展，平臺開始發展出了低價試用或者包郵試用的業務。這些業務的營銷方式，是低價（接近免費）的進行新用戶觸達，因此和限時折扣一致，會面臨同樣的問題，因此歸為一類。

b.熱門商品，庫存有限：商家只能拿到限量的熱門商品，然而該部分商品庫存有限，不足以支持開放購買。為了讓顧客盡可能公平地購買，需要進行限制。

以上兩種情形，是目前商家進行限購的主要場景。

而平臺也有使用限購的場景，比如對特定的用戶允許購買讓利商品。由于平臺面對的用戶量更大，無法一一滿足，只能選擇擴大觸達覆蓋率的方式，因此也會限購。原因與商家進行限購的原因大同小異。因此限購這個業務，不僅是商家的要求，還是平臺的要求。

02 對業務本質的了解

從上面的業務演變中，我們可以看出限購業務的本質。

a.限購的前提之一是稀缺性

稀缺性的本質是供求關系不匹配中的一種——供不應求。稀缺性由商品價格與行業價格的落差，以及庫存的數量體現。一雙普通的喬丹鞋，理論上是沒有稀缺性的，但如果一雙喬丹鞋在保證正品的情況下，只賣100塊，大大低于行業價格，那就具有了價格上的稀缺性；或者推出全球限量款，只制作5雙，而有10000人想買，就具有了庫存上的稀缺性。沒有稀缺性，就無需限購。

b.限購的目的是提高同等數量商品對特定用戶的觸達率

從需求背景我們可以看出，限購的目的，并不是讓用戶減少購買，而是通過限制個人購買的方式提高同等數量商品對特定用戶的觸達率。

因此我個人對限購業務本質的理解是：限購是由于資源稀缺，商家或平臺通過限制用戶的購買行為，以提高同等數量商品對特定用戶觸達率的行為。

03 對業務邊界的了解

業務邊界，換個說法就是，由誰來做，由誰來維護？

其實，限制購買是個比較寬泛的概念，可以有多重理解。理論上，對用戶任何的購買行為進行限制，都屬于限制購買。簡單舉例：

1. 至少購買2件，和至多購買n件，都是限制購買的概念，需要整合一起做么？
2. 至多購買0件，就是禁止下單，涉及到風控的業務，需要與風控整合一起做么？
3. 如果限制購買數量（前100享受優惠價，然后恢復原價）的話，會涉及到庫存分割的概念，需要整合在商品平臺中的庫存中心一起做么？
4. 限購與限時折扣相關的話，其中限購價格是否需要考慮？考慮的話是否要由促銷的同學來做呢？

限購的邊界在哪里？以上三個例子，涉及風控，促銷，價格，庫存，交易等多個不同環節。這個問題沒有明確好，就容易造成業務劃分不清晰，功能不明確。

針對以上問題，我是這么看的：

1. 至少購買2件，是為了提高客單價的促銷考慮，目的是增加客件數及客單價，因此應該放在促銷，促銷的落地點在銷量，而限購只是提高觸達率，對銷量沒有直觀的提高作用，甚至還有阻礙作用；同時有部分非促銷的場景也需要用到限購工具（如庫存問題導致的限購），因此不屬于促銷，因此也不放在促銷、價格相關的設計中，否則會加大促銷模塊的維護成本；
2. 業務邊界需要根據業務本質來制定。限購是處于營銷或者交易公平的考慮，進行的限制，因此風控需要被排除。也就是禁止下單的功能，風控需要自己做，否則后續業務與風控耦合會越來越緊，導致限購功能尾大不掉；
3. 限量一般來說是前XX件，本質上也屬于通過階梯價的方式進行促銷，因此也不放在限購中考慮；
4. 價格是商品和促銷的一部分，在庫存限制的場景中，價格的變動與限制購買關系不大。

因此，既不在風控、促銷、價格、商品等模塊中，那應該歸結到哪里呢？

個人認為，放在交易是比較好的選擇。放在交易的原因，是因為限購的場景可能部分是在風控、促銷、價格、商品等模塊中，但所有的限購場景都是在交易中落地。因此限購，應該是交易的業務，主要服務于交易。其他業務有臨時的業務需要，來進行調用即可。

三、架構搭建——產品業務模型搭建方法

我們在對業務有較為深入的了解之后，我們就可以著手搭建我們的產品模型了。在搭建產品模型這一點上，我的方法論是：厚-薄-厚，下面我們開始著手進行模型搭建。

第一個厚，是指遍歷業務場景；薄是指抽象業務元素，建立業務模型；第二個厚，是指將建立的業務模型重新返回業務中進行校驗。

還是以限購為例。我們來看看如何通過厚—薄-厚建立業務模型。

首先，我們來看下，限購的具體的業務場景： 購買過某些類目商品的用戶，每個ID限購限量玩具n件；

購買特定活動店鋪的用戶，每個ID限購限量玩具n件；

來自返利渠道的用戶，每個ID限購限量玩具n件；

APP用戶可以購買每個ID限購限量玩具n件；

僅限APP上，使用微信支付的用戶，每個ID限購限量玩具n件；

……

這么多的場景，窮舉得完么？（偷偷插一句，這就是日常需求的來源=。=）

讓我們來造個句子。 限制購買商品。

記下來，我們來完善下這個句子，用填充定語的形式進行補充： 限制（參加特定活動的）（特定來源）的（特定用戶）（在特定時間）（在特定地點）（以特定支付方式）（以特定規則）購買（特定數量的）（特定商品）。

那么接下來，我們就可以按照這個邏輯進行梳理。

這就是第一個階段。我們在這個階段，盡可能把所有涉及到的要素都進行窮舉。窮舉之后，其中各個部分可以進行自由組合。我們可以通過這個方式遍歷大部分的業務場景，最高效地找出之前遺漏的場景。

好，那我們接下來看下，如何進行最關鍵的薄的轉化（這其中需要對上面的定語再進行一次抽象，將相同屬性的定語進行歸類）。這么做的目的，是再找出這些定語之間的共性。目的是后續架構拓展可以以業務元素為維度進行拓展，無需為新增的定語打補丁。這提供了更大的拓展空間。

以限購為例，我主要分為限購時間，限購范圍，限購對象，限購方式，限購規則這幾個方式。這真正構成了業務元素。 薄的這一層，需要多次調整才能將所有的業務元素盡可能地放到合適的屬性中。不過做完之后，長征路上就已經完成了50%了！

接下來是驗證的厚了。這時候，我們會把之前的場景，都放到業務模型初稿中，進行試驗，看通過模型能夠實現這些場景功能，滿足需求；然后再看看能不能通過整理的業務元素的再組合，實現目前有可能實現，但還未提出的需求（也就是傳說中的預測需求的部分啦~）

如果以上兩點都驗證完畢，那恭喜你初步建立了自己的業務模型！這時候就可以拿著這個模型，與團隊的同學們討論一下，是否有遺漏的點，是否有可以調整的地方。如果大家都覺得模型沒有問題，那么就可以進入到下面的環節，數據層模型的搭建以及展現層的表現設計環節。

因為內容較多，因此分為兩篇呈現，下一篇會數據層模型的搭建、展現層的表現設計，以及業務模型的應用及局限，比心~！

本文由 @啟辰菌 原創發布于人人都是產品經理。未經許可，禁止轉載。