編輯導語：在進行系統設計時，對產品底層設計能力的掌握十分重要，如此，才能夠在接手新需求、新業務時不慌不忙，做好產品規劃方案。在文中，作者提出了理流程、定單據、填功能的系統設計策略。具體如何實施？不妨來看看作者結合了自身經驗的這份解讀。

無論做什麼事情時，我們總是希望能深諳其道、舉一反三，找到底層邏輯和運轉規律，這就需要我們多加觀察、學習、積累、總結，繼而形成自己的方法論。

上學、做研究、創業、做產品規劃、系統設計無不如此。本篇文章以木筆本人切身經驗分享一些B端系統設計的方法和步驟，希望對一些新老朋友有所幫助。

在做系統設計時，遇到一個業務提的一個新的需求丟過來時，新手小Z經常焦頭爛額，就算對既有系統和流程已經很熟悉了，在設計新的功能時還是漏洞百出。

而老道的產品的老A卻總能得心應手，即便對過往業務不是很瞭解，經過幾天的學習，也總能設計出一份業務方比較滿意的方案，而且漏洞較少。

兩人的差距在哪呢？不是責任心，不是態度，而是產品底層設計能力。因為老A經過多年摸爬滾打，總結了一套放之四海而皆準的產品法則，這套法則足以讓老A馳騁產品界，立馬定江山。

小Z對老A仰慕至極，虛心求教，老A笑著送給了小Z9個字：理流程，定單據，填功能。而這9個字正是老A總結的產品箴言，可放諸四海，童叟無欺。

第一步：理流程。

當接到一個新的專案需求時，不要上來就開始聊系統實現，應該先和業務方一起把主幹流程梳理一遍，保證流程是通暢無阻且切實可行的。

流程理順了，業務方的訴求也就清晰了，是否可行，哪些環節有坑都一目瞭然了，同時在梳理的過程中，系統層面的流程節點也比較清晰了。

第二步：定單據。基於業務流程各關鍵環節的產出歸納出系統的單據和狀態，用單據儲存業務的過程資料，用狀態管理流程的關鍵節點。

第三步：填功能。針對需要系統支援的環節，設計系統功能，並與流程和單據相對應。

做系統設計和蓋實體大樓流程是一樣的，理流程的過程就像做規劃，是搞清楚業務訴求和分析可行性的過程，比如這塊地未來是要做商業中心還是蓋住房，樓間距幾何、地面規劃如何等。

定單據就是打地基，把樓宇的主體結構固定下來，確定結構框架、材質和關鍵施工環節，然後開始動工。

填功能是最後的裝修階段，是在主體結構上進行包裝、把最終成果呈現出來。

流程是方向、單據是執行，功能是落地，流程決定了要什麼，單據設計決定了怎麼做，功能實現則決定做成什麼樣子，三者相應相輝，一起達成業務目標。

▲系統設計核心3要素：流程、單據和功能

一、理流程：庖丁解牛，理清業務和系統流程

在B端業務裡，尤其是供應鏈這一類偏重業務流程和多系統互動的領域，流程是業務開展的基礎，幾乎所有的需求都來源於流程。

當我們接到一個新的需求時，應該花50%以上的時間用於梳理流程，流程的梳理分為業務流程和系統流程兩部分。

業務流程由業務負責規劃，用於描述操作流程的順序，關鍵元素是[操作角色][操作節點]；系統流程由產品經理負責出具，是對業務流程分析後產出的系統互動流程，重在梳理系統之間的互動邏輯，關鍵元素是[作業系統][系統功能]，下圖是業務流程和系統流程的泳道圖對比。

▲系統流程圖與業務流程圖

根據不同的業務場景，流程可以分為主幹流程、輔助流程、異常流程三種：

1. 主幹流程：處理業務必不可少的主流程，就像樹的主幹一樣，不實現就沒法滿足業務訴求，比如採購的建單、倉庫的收貨、上架等；
2. 輔助流程：從主幹流程分出來的子流程，如同樹的細枝末節，屬於錦上添花，實現了有利於業務更好開展，不實現也不會影響，比如匯入採購明細、批量收貨、批量上架等；
3. 異常流程：出現異常情況的處理流程，也必須實現，否則遇到異常了就出現了流程卡點，比如採購單的駁回、收貨錯誤修改、出庫揀貨異常等；

通常來說，主幹流程和異常流程優先順序最高，必須在專案上線時就要具備，但異常流程因為不經常發生，如果工期趕不上，可以考慮用簡單的方案替代（比如業務方線下處理）。輔助流程一般不緊急，可根據資源情況安排，如果專案第一期排不上，可放到後續迭代版本中。

▲如何梳理流程

在梳理業務流程時，我們可以遵循先主幹再異常，最後分支的原則，儘量把專案中涉及到的流程以及每一個操作角色、操作環節都清晰地描繪出來，然後再對著操作節點梳理系統功能。

有些操作節點是需要系統功能支援的（比如採購建單、收貨），就需要有與之對應的系統功能，還有一些是純線下行為（比如搬運、清掃），則不需要系統功能。

另外，操作節點和系統功能並不是一對一的，有的操作可能需要多個功能支援，也可能多個操作只對應一個功能。

系統功能梳理出來以後，我們接著梳理每個功能對應的輸入和輸出，有些輸入和輸出只體現在資訊流上，有些則需要其它形式的產出。

例如倉庫收貨完成時，我們需要對收貨的結果和過程資料儲存下來，這是資訊層面的輸出，同時還需要為收貨員列印一張紙質的收貨單，這是實體單據輸出。在梳理的過程中要對各環節的輸入和輸出做詳細的記錄和拆解，這是我們下一步設計單據和狀態的依據。

流程梳理的最後一步是做系統劃分，將系統功能與當前已有的系統進行匹對，定位每個系統功能的系統邊界，如果還沒有系統，正好以此梳理結果為依據做系統規劃。

系統的劃分並沒有嚴格的執行標準，有些處於兩個系統交界的功能放在A系統也行，B系統也行（例如兩個系統互動時，列舉值的對映），這時可以根據架構合理性、資源情況和操作便捷性等因素綜合評估。

二、定單據：框架構建，明確單據和狀態

在B端系統中，單據是用來儲存和流轉業務資訊的憑證。系統流程及各環節的產出梳理出來以後，就可以以此規劃系統單據和單據狀態了。

單據有兩大核心要素：關鍵屬性和流轉狀態。關鍵屬性來源於流程各環節的產出，記錄業務開展過程中的詳細資料，流轉狀態設計來源於系統關鍵節點的變化，記錄流程的流轉過程。

系統流程的每一個環節都會有輸入和輸出，輸出的資訊需要儲存下來，這些資訊就是單據的屬性，也是最原始的單據資料，還是下一環節的輸入資料。

我們試著對各環節的產出資料進行提煉，如果發現下一環節與上一環節的資訊集合一樣，只有個別資訊不同，則可以將這兩個環節設計為一個單據，但如果差異非常大，就需要設計成不同的單據。

例如下圖中，採購的結果會生成採購單，我們需要設計一張採購單來承載採購的所有資訊，收貨的輸入資訊來源於採購明細。

但由於收貨結論與採購明細相差很大，兩者並不是一個維度的資料集合，採購單產生於採購系統，收貨則是在倉儲系統，一條採購明細會生成多條收貨明細，所以收貨結論需要單獨設計一張收貨單來承載。

另外，收貨結論會作為驗收的輸入資訊，但驗收和收貨只是入庫流程中的兩個環節，並無很大的差異，所以可以統一設計到收貨單中，根據狀態加以區分（當然不同業務形態下的流程不盡相同，如果驗收需要對收貨結論進一步拆分或合併，則二者就無法共用單據儲存，就需要設計不同的單據了）。

▲如何定義單據

系統流程的流轉是基於單據的流轉狀態來的，單據流轉狀態是單據的非常重要的屬性，也是驅動流程流轉的靈魂。

狀態設計來源於系統關鍵節點的變化，在規劃狀態時，我們需要把系統流程從頭到尾所有的節點都整理成線，然後挑出哪些是影響流程流轉的關鍵節點，對節點的流向結果進行提煉，便得到了單據的狀態。

例如倉庫入庫流程中，供應商到貨以後，會分別進行①供應商簽到→②倉庫收貨或拒收（合格品驗收，不合格拒收）→③倉庫驗收→④倉庫入門上架等4個節點，根據4個節點的輸出結論，便能分別設計出供應商簽到、收貨完成、拒收、驗收完成、上架完成等5個收貨單狀態（當然這只是最簡單的舉例，實際倉庫收貨流程會複雜的多），如圖所示。

▲根據系統節點設計單據狀態

我們在設計單據狀態時，需要遵循幾個原則：

1. 狀態之間應該是平行且互斥的，不能存在交集。
2. 狀態之間流轉應該有清晰流向，是線型而不是網型，不要相互穿插跳躍。
3. 狀態的設計不是憑空捏造的，必須和某個關鍵節點相呼應，由節點觸發狀態機流轉。
4. 狀態設計最好只有一個開始節點，但可以有多個結束節點（正常結束狀態和異常結束狀態分開）。
5. 狀態設計應該足夠精簡，只有對關鍵邏輯產生影響的節點，才適合設計為狀態。

三、填功能：破繭而出，實現系統功能

當流程和單據梳理清晰以後，系統設計就成功了80% 了，最後20%在於系統功能的填充和實現，將功能按照業務需要的風格輸出，形成系統原型和需求文件。

在填充系統功能時，也是有章可循的，我們需要依賴前面所做的流程梳理和系統單據：

1）首先，將流程節點中的線下操作流程和系統處理流程進行分類，只有系統處理流程是需要實現系統功能的。

2）接著，基於各環節的輸入和輸出資訊設計對應的功能。功能包含帶頁面的操作性功能，以及不需要頁面的系統邏輯處理功能，輸入資訊對應到系統功能上通常是查詢條件、資訊錄入、匯入等功能，輸出資訊通常對應查詢結果、儲存資訊、操作日誌、匯出等功能。

3）然後，將關鍵功能與單據的狀態變更結合起來，梳理出每個功能的詳細邏輯以及對應的單據狀態變更，系統功能便設計完成了。

4）最後，功能設計完以後，將系統功能和非系統功能串在一起驗證一下是否和業務流程預期一致，不能出現流程盲區和卡點；若有，則繼續完善，直到整個業務流程通暢無阻。

在設計B端系統功能設計時，可以參考尼爾森經典十原則，同時一定要遵循實用大於美觀的原則，這裡總結幾個設計小貼士：

1）頁面功能應該分清主次，頁面越簡單越好，這樣的學習成本和實現成本最低，拒絕花裡胡哨。

2）同一個系統內各頁面設計的控制元件、頁面佈局、風格、顏色、字型應該統一，且符合大眾操作習慣。

3）如果可以，頁面應該聚焦，儘量在一個頁面完成核心操作，少做跳轉，因為每一次跳轉都是動作和時間上的浪費。

4）批量操作很有用，例如查詢時可以查多個SKU、操作時可以批量稽核等，系統的一個批量功能，可能會給業務的操作效率帶來飛躍。

5）操作記錄很重要，當出現問題需要排查時，日誌是案發現場最好的黑匣子，所以無論如何，核心操作的日誌功能不要省，否則總有一天，會為自己的一時懶惰埋單。

6）設計一個好的灰度策略，通過新老流程並行，由老流程逐步過渡到新流程，有問題了也可以隨時切換，可以極大的降低專案風險。

以上便是老A的系統設計9字箴言了，掌握了這個方法，再複雜的系統設計也能夠層層剖析，直到最終落地，如庖丁解牛。

方法本身並不神奇，其實就是需求分析和拆解的過程，但知易行難，每一步的技能磨練都需要我們懷謙卑之心深扎到一線去摸爬滾打才能慢慢領悟，這個過程叫做經驗，不經歷就無法得驗。

如果問我有沒有更快的系統設計成長技巧，答案是肯定的，就兩個字：實戰！百聞不如一見，百看不如一試，唯有多加實戰才能在真實的業務環境和專案壓力中迅速成長，繼而逐漸找到自己的方法論，以不變之策應萬變之事。到那時，你且看他……