起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識電商O2O后臺產品的需求對接和產品設計
后臺產品籠統地概括來說就是各種管理系統，本文作者根據自己的經驗總結了需求對接和產品設計兩方面完整的工作內容，大家可以參考學習。
互聯網產品領域，可以籠統地分為前臺產品和后臺產品。前臺產品即是C端的產品，后臺產品可以籠統地概括為各種管理系統。
我們常說的C端產品價值在于滿足用戶需求、提升用戶體驗，后端產品完全不同，第一要義是對業務的支持和提升，通過業務操作和數據的線上化，來標準化業務管理流程、提升業務運轉效率，以及發掘數據的價值，進而在各環節影響到公司的成本和收入。這對于主營業務為電商、O2O等任何形式交易的公司來說尤為重要。
四五年前，當互聯網還處于線上產品為主的階段，業內會說有很多公司不注重后臺。但現在互聯網各行業各類線下服務早已層出不窮，都8012年了，如果還有認為后臺產品的價值小于產品的公司，可以倒閉了。
我本人在小公司做了一段時間的公司內部支持系統，總結出了一部分關于后臺產品的個人經驗。
本文分為六個部分，按后臺產品設計過程的順序，分別是后臺產品有什么用、有哪些后臺產品、業務需求怎么對接、產品本身怎么設計、如何上線和如何跟進使用情況。
這是第二篇，上篇寫了些比較虛的產品目標和作用，這篇從具體工作內容出發，寫業務需求對接和產品設計這兩方面的體驗和心得。
三、后臺產品的需求對接
3.1 是不是業務方說什么，我們做什么
后臺產品服務于業務，在產品需求調研的階段，后臺產品經理要做的事情和做C端產品自然有區別。
C端端產品通常是通過各種手段去接觸用戶、挖掘用戶的需求，面向B端客戶的產品也差不多，只是調研對象變成了B端用戶。而面向企業內部的后端支撐產品，需求調研的主要方式是與所謂的“業務方”進行業務需求的對接。
這個業務方，指的就是公司其他部門的人，比如做供應鏈系統，就要找供應鏈部門的采購、倉管對接需求，比如做CRM系統，市場部門就是業務方。這一節主要寫需求對接方面的問題，具體的需求調研和分析就不拓展了。
在我剛做后臺產品的時候，我一直有個疑惑。我們的需求方是很確定的那幾個人，我們的產品只要面向他們服務，那我們做的豈不就是既定的需求，只要他們說什么，我們做什么就行了？在各種需求對接的時候，業務方通常會直接說你給我一個什么什么功能，我們按他說的做，不就已經滿足需求了？
后來我逐漸發現，業務方提出來的具體需求不一定是合理的。盡管我們做的系統是給他們用的，但產品需求的出發點更多是站在公司業務的角度，考慮系統對業務的價值，流程是否合理，這些是需要由我們產品去規劃的，而不只是功能用著怎么樣。
還有，業務方并不一定了解產品能給他們帶來什么，他們提出要什么功能，并不一定能解決他們真正的需求目的。
這個產品經理自己的能力有關系，在初階階段，因為自己能力有限，會停留在接收需求并執行的階段，但水平提高后，就會知道怎么做更合理，逐漸去規劃整個產品。
因此，除了一些細節的小功能很簡單，直接做就行，一旦涉及到整個業務模塊的需求，一定是由產品經理主導，了解到業務本身，然后給業務方標準化的流程，告訴他們怎么用，并不一定要按照他們說的做，不然做出來的很可能不會是可行的方案，業務方也只會認為產品經理只是個做系統的。
不過我也看到有些牛人說，面向公司內部的產品經理發展空間有限，畢竟用戶太少，既定的需求多，在項目中業務方的重要性更高，確實沒法像做C端或者平臺的產品經理那樣能主宰一個項目。這種情況或多或少存在，這個問題只能說見仁見智吧。
3.2 業務對接的常見現象和解決方法
業務對接不比挖掘C端用戶的需求容易多少，這個過程中同樣會出現各種各樣的問題。尤其是當你的業務方不是做互聯網的，那么在需求對接的時候確實會有一定阻力。我在現在這家公司，業務方中就有很多人是從傳統行業過來，習慣用excel工作、對系統并沒有什么概念的人。在我和業務方對接需求的過程，出現過以下這些情況：
- 第一，業務方不一定知道后臺產品的價值是什么，能給業務本身帶來什么提升，他們可能只知道業務數據和操作要在系統上進行，比手工更方便一些；
- 第二，有些人習慣于在傳統行業用excel工作，對系統的理解會停留在記錄和查詢的作用。他們提的需求，通常會提一個具體的功能，你要是不問就不會說具體的目的。比如真實目的是要做一項數據統計，但提過來的需求只是某個頁面加個導出功能，或者某個列表加個什么字段之類的；
- 第三，業務方通常會站在自己操作的角度提需求，不一定會關注產品宏觀層面的價值、業務流程的標準化、管理規范的問題等。尤其是直接操作系統的人，他們提的最多的就是具體的功能，如何方便他們操作，會出現有一些功能不能按他們說的做，但他們不理解；
- 第四，業務方不一定有迭代思維，以為產品上線和傳統企業的交付一樣，一次性做完形成最終版然后給他們用。產品從0到1的過程我們會規劃MVP，先上線基本功能并持續迭代，但他們看了會說這個怎么沒有我要的什么什么功能，一定要等我們把他們要的都做完了再開始使用；
- 第五，有時候一個事情習慣了會不容易改變，假如我們出于管理上的目的需要迭代一些操作，改變的他們平時線下的操作習慣，他們可能會抗拒，反而說我已經有辦法處理這些問題了，不理解我們為什么還要去改這些功能。
當然，這些情況不絕對，只是有可能會遇到其中的一部分問題。在經歷了那么些個業務對接之后，針對業務對接這項需求收集方式，我總結出了幾點可以作為參考的辦法：
- 第一，找準業務方的人。別小看這點，有體會了就知道找人很重要的。比如一個部門里，下面的人更了解業務，但通常只會站在自己操作的角度考慮問題。部門管理人員能決定事情，也通常知道系統要做什么，但對業務流程的細節不一定熟，也不一定有時間和你對需求。再比如，同一個部門的業務方，有些人對各類互聯網產品比較了解，至少會告訴你他之前用過的系統是什么樣的，另一些人就會更傳統行業一點，也許前一個人半小時就能對清楚的需求，后一個人得和他講倆小時。我至今記得我接觸的一個系統從0的起步時候，跟第一個業務負責人一個月開4次會，到最后對方還在糾結為什么不買個系統，接下來換業務負責人之后，開了兩次會后項目直接順利啟動；
- 第二，聽他們說，但不要照著做。這一點和我們對待用戶需求的態度一樣，從他們說的要加XX功能的背后，了解到他們需求的本質，然后想一種更好的方式滿足他們的需求，并且可以直接告訴業務方我們方案，以及這樣做的好處，相信他們不會拒絕；
- 第三，多參與到實際的業務中去，知道業務方日常的工作，如何開展工作，系統上關注的點，最好直接幫助業務方做一天的系統操作，甚至可以參與到他們的業務目標、會議、KPI這些領域中去。這一點也和我們對待用戶需求一樣，但比理解用戶需求要難的多，因為一般C端的用戶需求門檻低，而業務可是實實在在的專業知識，有專業門檻的。比如說作為供應鏈系統的產品經理，要深入倉儲的業務，就要了解倉管人員管理倉庫的核心目標是什么，什么是周轉率，庫存成本的計算規則，安全庫存有什么用、怎么算，需求預測有什么用、怎么算等物流管理領域的專業知識。如果不深入業務，即使去幫業務方操作系統，也只能看到一些交互層面的小問題。
- 最后一點，和業務方畢竟是真人面對面溝通，所以只要加強溝通，告訴他們我們產品的價值，我們每個方案為什么要這么做，每塊業務我們會怎么去迭代，很多問題自然會迎刃而解。
四、后端產品設計的主要內容
終于到了產品經理自由發揮的主戰場，產品設計環節。當我們明確了產品目標，完成業務需求的對接后，接下來就開始進行產品方案的設計。
不同于C端產品，后端產品設計的重點在于業務邏輯和流程，其次是操作效率體驗，前端界面幾乎是最次要的部分。
我最開始做后臺的時候，以為和C端一樣只需要畫原型，附帶一點流程圖就可以了，然后發現原型根本無從下手。后來，我總結出了十個步驟，作為我自己做后端產品設計的方法。這些步驟是以比較完整的角度設計一個業務模塊，一般的一小個頁面或流程，可以省略中間幾步。
在此以我接觸過的一個電商/O2O領域的供應鏈系統為例，描述一下從0到1設計系統的采購模塊需要如何進行。
1. 確定業務名詞的定義
這是第一步，先要知道我們即將做的是一個什么東西，以及這項業務中會涉及到哪些業務名詞，他們在實際業務中是什么意思，和在系統中如何定義。
如果系統沒有，那需要從0開始定義。
比如說在供應鏈系統中，僅僅是和庫存相關的詞就有可用庫存、在途庫存、凍結庫存、良品、不良品、廢品、庫房、庫區、庫位等等，如果一開始不定義清楚，后面就會一臉懵逼。
2. 確定這項業務中參與的人員角色
通過和業務方的對接，確定有哪些不同的角色參與到了這項業務中，每個角色做什么事情，并明確不同角色之間權限的邊界，避免出現職責混亂。
這個環節看似簡單，但需要在對接業務需求的時候就考慮清楚。此外，有些角色的參與可能會涉及到其他產品線，這種情況下需要在其他系統中同步這項業務。
在這里引入UML圖，具體定義自行百度。
UML圖我所知道的很多公司都不要求畫這個，但可以作為產品經理在后臺產品設計過程中的幫助。在這一步可以產出UML中的用例圖。
舉例，在供應鏈系統的采購業務中，會涉及到的角色如下：采購人員，負責采購下單，跟進供應商，做賬結算；庫存計劃員，負責計算庫存需求預測并提交采購申請；供應商，負責接受采購單進行發貨；倉管人員，負責收貨入庫；質檢人員，負責對采購的商品質量檢驗；財務人員，負責根據賬單打款。
這其中，由于財務的參與，需要將采購結算信息同步至財務系統。
3. 梳理整個業務的核心流程；
核心流程是整塊業務中那幾個重要的環節，確定了角色后，可以將核心業務環節按照正向流程畫出來。這里的流程圖不用特別細，只畫重要環節，即核心事項的走向，并標明事項的角色。具體的判斷、變化、異常等后面再說。
下圖為采購業務的核心流程圖：
4. 根據核心流程梳理核心數據的流動規則；
這一步是重點。在電商、O2O等交易型的公司中，訂單、庫存、成本、收入這些就是核心數據。事實上流程本身不難梳理，核心業務數據才是系統數據正確的保證。
這一步需要理清整個流程中哪些數據會產生變化，分別在哪個環節發生，如何加如何減，具體數字是多少，計算規則又是什么，之后的環節又流轉到哪里。
比如說供應鏈系統，核心在于庫存流和資金流，所以每個流程都需要明確這兩個數據，庫存的入庫、出庫、凍結、在途都是什么規則，在哪一步發生；每次入庫出庫時庫存的金額是多少，收入和支出又如何計算。
在采購模塊中，首先是庫存，通常是將最后一步入庫作為庫存增加的環節。還有一種方案是收貨環節庫存增加且凍結，入庫時將凍結庫存轉化為可用庫存，質檢不合格退貨的則凍結庫存減少。
然后是資金，采購流程涉及到兩點：
- 入庫的庫存成本計算規則，常見的是將當前采購價作為庫存成本，此外還有加權平均法等方式，這里就不展開了；
- 采購結算金額的支出，等于每批次入庫庫存數量的采購價格總額。
以上環節的內容確定后，可以開始找業務方進行第一輪評審，核對基本的業務流程和規則。完成確認后，接下來的事項就是逐步細化。
5. 細化流程，梳理每個流程節點的具體操作和流程節點之間的走向；
這一步就是把流程細化，將前面梳理的核心流程根據實際業務情況擴展，確定每個步驟有哪些操作，每個操作的前置條件和后置條件是什么，流程之間是如何流轉的，以及各種異常情況和處理方式。這個步驟可以產出完整的流程圖。
采購業務的流程細節就不寫了，完成的流程圖如下：
6. 確定整個流程中有哪幾個實體類型，和每個實體類型包含的字段
實體類型可以理解為業務上的一個單子、批次，或者數據上需要進行增刪改查操作的一條記錄。細化流程后已經確定了每個環節要操作什么，接下來理清整個流程模塊中有哪些實體類型，以及每個實體類型里有具體哪些重點字段。
這一步和下一步要確定的關聯關系，本身的作用是從后端研發的角度去設計數據的基礎結構，這兩步可以產出UML圖中的類圖。
盡管類圖不一定要畫，不過作為后臺產品經理，確定實體類型的意義在于通過了解后臺結構和關系來梳理業務邏輯，理清整個業務的后端結構，并作為之后具體頁面結構和操作設計的基礎。
回到采購系統的案例中，在采購流程中可以梳理出這幾個實體類型和重要字段：
采購申請單（倉庫、采購申請量），采購單（倉庫，供應商，采購量），采購收貨單（倉庫，供應商，發貨批次，采購收貨量），采購入庫單（倉庫，供應商，發貨批次，采購入庫量），采購退貨單（倉庫，供應商，發貨批次，采購退貨量）。
7. 確定各實體類型之間的的關聯關系，和他們之間詳情數量的關系
有實體類型之后，接下來根據實際業務情況，確定各個實體類型之間的關聯關系，一對一還是一對多，強關聯還是弱關聯。
數量的關聯比較好理解，在采購的案例中，基于一個采購申請單可以根據不同供應商創建多個采購單，那就是一對多；一個采購單可以多次發貨，采購單和發貨單也是一對多；一個采購收貨單只能一次全部入庫或退貨，那就是一對一。注意不要有多對多就行了。
強弱的關聯可以理解為某個實體是否一定要通過關聯它的實體創建。比如采購單可以從采購申請單中創建，也可以單獨創建，那就是弱關聯；采購收貨單一定要有采購單才能創建，采購入庫單一定是收貨單收貨后才能入庫，這兩個不能憑空創建，所以是強關聯。
詳情數量指的是流程中核心數據的明細，比如供應鏈的各種入庫出庫數量、訂單的各種金額等。事實上這些個數量即是實體中的一個字段，每個流程節點中的操作會隨之產生數據，原則上后續的流程不能覆蓋前面的數據，需要新建一個數據字段來記錄，于是會有一大堆數據字段，他們之間存在具體的計算方式、關聯規則，會直接關系到數據的準確性，需要按照實際業務情況確定。
采購流程中的數據字段前面已經寫了，它們之間的關系，首先采購申請數量和實際采購數量，因為存在供應商無法滿足和有不良品會退貨的情況，采購量通常會大于采購申請量，這兩者之間沒有明確的關系；接下來是采購收貨數量，由于供應商發貨的不確定性，收貨量和采購量也沒直接關系；再是質檢后的入庫量和退貨量，顯然他們和收貨數量就有嚴格的關系限制了，入庫量+退貨量=收貨量。
這兩步整理出來的類圖如下（不過格式不標準，可以將就看下）：
8. 設定頁面架構
明確實體關系之后，頁面層級結構自然就出來了。通常來說后臺頁面的層級結構遵循兩個原則，不同的實體類型需要劃分為不同頁面，以及不同角色需要劃分到不同的頁面。
同一個角色和同一個實體，在一個頁面中操作即可。此外，如果有需要把多條記錄中的某類數據詳情放一起列出來，然后大批量操作的功能，也需要獨立到一個頁面中實現，比如說如果需要多個采購單的庫存一起入庫，那就需要加一個庫存列表頁面，展示所有待入庫的詳細庫存（當然實際業務上通常不需要）。
后臺產品的頁面架構設計滿足邏輯和操作即可，不會像C端產品那么精細。
9. 確定每個頁面的列表數據有哪幾種狀態
頁面設計的重點是不同列表各自的狀態和操作。狀態的作用是為了告訴用戶當前的動態描述和需要進行的事項。
狀態的設置有三個參考因素：
一個是流程中當前所處的環節需要做什么或者已經做了什么，我們常見的待XX，已XX就是根據基本流程梳理出來的；
二是操作的數量，存在有些環節無法直接通過流程判斷狀態，需要將操作的數量和總數量進行對比，得出狀態。
有些業務中會有先操作一部分數量的情況，比如采購收貨時，可能只收了一部分，用戶又需要了解到收貨數量的情況，因此狀態可以設計為部分收貨、全部收貨這兩種。
有些情況下完結也需要通過數量進行判定，主要是各類申請的滿足情況，比如采購申請單，會關聯多個采購單，采購申請數量和采購數量、收貨數量之間由于不確定性，沒有強關聯關系，因此采購申請單的完結，只能用實際入庫數量和采購申請數量做對比，數量都滿足了狀態再更新為完結。
三是和其他列表狀態的同步更新。一個復雜的流程會涉及到多個實體的列表，每個列表都有各自的狀態，某個列表狀態變化后，需要根據用戶實際情況，考慮其他列表是否要同步這個變化。
比如采購流程中，收貨、質檢、入庫都是基于采購收貨單的操作，由倉庫、質檢進行，那么因為采購需要實時跟進這些信息，所以在被關聯的采購單中就需要同步這些操作，顯示全部收貨、已質檢、已入庫這些狀態。
再比如采購申請單和采購單，由于采購申請單的角色是庫存計劃員，不需要跟進采購的情況，所以主流程只需要顯示待采購、采購中、已完結這3個狀態，不需要同步采購單的其他狀態。
10. 確定各狀態下有哪些操作，如何進行
操作是根據狀態實時變動的，每個狀態有它對應能做的操作。根據前面梳理的詳細流程中每個操作節點，和用戶在這個步驟中需要查看的信息，整理成操作和詳情內容。
具體操作包含通用的操作比如創建、編輯、刪除、啟用禁用、取消、回退；流程中的操作，比如發貨、收貨、入庫、質檢、退貨、完結、審核通過不通過，將這些操作放到對應的狀態中即可。
具體功能設計的時候，要考慮用戶的操作效率，同一個操作可以針對多個場景設置不同的方式。
比如一些大數據量的操作，除了正常的逐條操作，還可以增加批量操作、導入導出的功能；一些復雜的操作，可以設置為多個步驟；還有當需要填寫很多表單信息的時候，可以幫用戶默認填寫。
最后三個步驟的結果考慮清楚后，原型自然就出來了。畫完原型，產品設計階段就大功告成了。
當然以上10個步驟看起來有點復雜，我見過很多人習慣于畫完流程圖后直接畫原型，不需要詳細考慮中間那么些個步驟。
我自己有時候也會這樣，因為一邊畫原型可以幫自己梳理思路，而且簡潔明了。只是一旦遇到流程復雜的業務，如果中間的步驟不考慮清楚，那么原型改來改去會非常耗時間，所以還是一步步來比較好。
#專欄作家#
潘帕斯雄鷹，人人都是產品經理專欄作家，進擊、踩坑中的產品狗一枚，關注互聯網，寫過小說，看過哲學。簡書：潘帕斯雄鷹。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
不錯 比較詳細 思路很對
好文章，把流程講得好細致了！感謝作者
嗯供應鏈管理平臺真的很復雜 涉及到入庫出庫備貨采購財務核算庫存計算等 供應鏈是門大學問！
挺好的，做了3年后臺，目前感覺不錯
錯別字2018