無論做什么事情時，我們總是希望能深諳其道、舉一反三，找到底層邏輯和運轉規律，這就需要我們多加觀察、學習、積累、總結，繼而形成自己的方法論，上學、做研究、創業、做產品規劃、系統設計無不如此。本篇文章想以木筆本人切身經驗分享一些B端系統設計的方法和步驟，資淺望輕但赤誠所至，希望對一些新老朋友有所幫助。

幾周前的周末和前同事聚餐，回憶一下子被拉回十年前，當時移動互聯網剛剛興起，BAT一夫當關，百團大戰熱火朝天，微信還在和米聊紛爭天下，大家也正值當年，個個意氣風發、橫刀立馬，記憶最深的事情之一是大家在會議室里分享并討論互聯網和電商是什么關系，京東到底算不算互聯網公司，O2O模式是什么？幾個一知半解的人以為自己掌握了前沿，為了幾個新興概念爭的面紅耳赤。

十年一夢，如今互聯網早已滲透到我們工作和生活的每一個角落，淘寶京東已被冠以傳統電商，移動互聯網和O2O早已成了陳舊概念，新零售、直播電商、社區電商、工業互聯網、產業互聯網這些概念和模式逐一登臺亮相，層出不窮，歲月也把我們這幫曾經的小鮮肉打磨成了白發依稀的中年油膩大叔。但值得慶幸的是我們依舊還身處浪潮之中，并沒有掉隊，大家聊起供應鏈和互聯網模式時依舊熱血和好奇，這一刻像極了十年前，時光似乎并沒有走遠。

我始終相信，在這日新月異的社會里，很多東西外表在不停的變遷，但總能找到一些不變的底層邏輯，就像樓房，裝修風格可以千奇百怪，但主體結構建設卻大同小異，這才是支撐起整個結構的根本和基石，包含著以客觀規律為基礎的物理理論和無數前人的智慧結晶，是不會輕易改變的。再比如商業的本質、供應鏈的模式，還有系統的設計之道等，只要我們在各自的領域里多加觀察和提煉，總能找到一些處事的規律和方法，這便是我們自己的方法論。

在做系統設計時，遇到一個業務提的一個新的需求丟過來時，新手小Z經常焦頭爛額，就算對既有系統和流程已經很熟悉了，在涉及新的功能時還是漏洞百出，而老道的產品的老A卻總能得心應手，即便對過往業務不是很了解，經過幾天的學習，也總能設計出一份業務方比較滿意的方案，而且漏洞較少。兩人的差距在哪呢？不是責任心，不是態度，而是產品底層設計能力。因為老A經過多年摸爬滾打，總結了一套放之四海而皆準的產品法則，這套法則足以讓老A馳騁產品界，立馬定江山。

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

 第一步：理流程。當接到一個新的項目需求時，不要上來就開始聊系統實現，應該先和業務方一起把主干流程梳理一遍，保證流程是通暢無阻且切實可行的。流程理順了，業務方的訴求也就清晰了，是否可行，哪些環節有坑都一目了然了，同時在梳理的過程中，系統層面的流程節點也比較清晰了。

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

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

做系統設計和蓋實體大樓流程是一樣的，理流程的過程就像做規劃，是搞清楚業務訴求和分析可行性的過程，比如這塊地未來是要做商業中心還是蓋住房，樓間距幾何、地面規劃如何等；定單據就是打地基，把樓宇的主體結構固定下來，確定結構框架、材質和關鍵施工環節，然后開始動工；填功能是最后的裝修階段，是在主體結構上進行包裝、把最終成果呈現出來。流程是方向、單據是執行，功能是落地，流程決定了要什么，單據設計決定了怎么做，功能實現則決定做成什么樣子，三者相應相輝，一起達成業務目標。

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

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

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

當我們接到一個新的需求時，應該花50%以上的時間用于梳理流程，流程的梳理分為業務流程和系統流程兩部分，業務流程由業務負責規劃，用于描述操作流程的順序，關鍵元素是[操作角色][操作節點]；系統流程由產品經理負責出具，是對業務流程分析后產出的系統交互流程，重在梳理系統之間的交互邏輯，關鍵元素是[操作系統][系統功能]，下圖是業務流程和系統流程的泳道圖對比。

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

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

（1）主干流程：處理業務必不可少的主流程，就像樹的主干一樣，不實現就沒法滿足業務訴求，比如采購的建單、倉庫的收貨、上架等；

（2）輔助流程：從主干流程分出來的子流程，如同樹的細枝末節，屬于錦上添花，實現了有利于業務更好開展，不實現也不會影響，比如導入采購明細、批量收貨、批量上架等；

（3）異常流程：出現異常情況的處理流程，也必須實現，否則遇到異常了就出現了流程卡點，比如采購單的駁回、收貨錯誤修改、出庫揀貨異常等；

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

▲如何梳理流程

在梳理業務流程時，我們可以遵循先主干再異常，最后分支的原則，盡量把項目中涉及到的流程以及每一個操作角色、操作環節都清晰的描繪出來，然后再對著操作節點梳理系統功能，有些操作節點是需要系統功能支持的（比如采購建單、收貨），就需要有與之對應的系統功能，還有一些是純線下行為（比如搬運、清掃），則不需要系統功能。另外，操作節點和系統功能并不是一對一的，有的操作可能需要多個功能支持，也可能多個操作只對應一個功能。

系統功能梳理出來以后，我們接著梳理每個功能對應的輸入和輸出，有些輸入和輸出只體現在信息流上，有些則需要其它形式的產出。例如倉庫收貨完成時，我們需要對收貨的結果和過程數據保存下來，這是信息層面的輸出，同時還需要為收貨員打印一張紙質的收貨單，這是實體單據輸出，在梳理的過程中要對各環節的輸入和輸出做詳細的記錄和拆解，這是我們下一步設計單據和狀態的依據。

流程梳理的最后一步是做系統劃分，將系統功能與當前已有的系統進行匹對，定位每個系統功能的系統邊界，如果還沒有系統，正好以此梳理結果為依據做系統規劃。系統的劃分并沒有嚴格的執行標準，有些處于兩個系統交界的功能放在A系統也行，B系統也行（例如兩個系統交互時，枚舉值的映射），這時可以根據架構合理性、資源情況和操作便捷性等因素綜合評估。

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

在B端系統中，單據是用來存儲和流轉業務信息的憑證。系統流程及各環節的產出梳理出來以后，就可以以此規劃系統單據和單據狀態了。單據有兩大核心要素：關鍵屬性和流轉狀態。關鍵屬性來源于流程各環節的產出，記錄業務開展過程中的詳細數據，流轉狀態設計來源于系統關鍵節點的變化，記錄流程的流轉過程。

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

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

 例如下圖中，采購的結果會生成采購單，我們需要設計一張采購單來承載采購的所有信息，收貨的輸入信息來源于采購明細，但由于收貨結論與采購明細相差很大，兩者并不是一個維度的數據集合，采購單產生于采購系統，收貨則是在倉儲系統，一條采購明細會生成多條收貨明細，所以收貨結論需要單獨設計一張收貨單來承載。

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

▲如何定義單據

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

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

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

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

（1）狀態之間應該是平行且互斥的，不能存在交集。

（2）狀態之間流轉應該有清晰流向，是線型而不是網型，不要相互穿插跳躍。

（3）狀態的設計不是憑空捏造的，必須和某個關鍵節點相呼應，由節點觸發狀態機流轉。

（4）狀態設計最好只有一個開始節點，但可以有多個結束節點（正常結束狀態和異常結束狀態分開）。

（5）狀態設計應該足夠精簡，只有對關鍵邏輯產生影響的節點，才適合設計為狀態。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上便是老A的系統設計9字箴言了，掌握了這個方法，再復雜的系統設計也能夠層層剖析，直到最終落地，如庖丁解牛。方法本身并不神奇，其實就是需求分析和拆解的過程，但知易行難，每一步的技能磨練都需要我們懷謙卑之心深扎到一線去摸爬滾打才能慢慢領悟，這個過程叫做經驗，不經歷就無法得驗。

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

（正文完）

吃飯席間，我問了森哥一個問題：”創業十多年了，你最大的收獲是什么？”。森哥是我們當年的項目經理，團隊的帶頭大哥，酒量驚人，曾經和甲方的一位意氣相投的同鄉相見恨晚，喝了個通宵，后來連續創業，現在已經是兩家公司的創始人，雖然公司還不夠大，但都已經盈利了，而且茁壯成長，未來可期。

森哥想了想，自豪的說：“最大的收獲是找到了一些創業和讓企業盈利的方法，現在就算換個賽道，給我兩年時間，我也可以把一家公司做到盈利”。盈利，聽起來并不難，但要想持續發展，卻是非常困難的，我查了一下數據，互聯網公司的扭虧為盈的平均周期是5年，2018年2019年期間，在港股和美股上市的48家互聯網公司，有28家處于虧損狀態，其中有19家已經至少連續三年虧損。可想而知，就算是上市，想盈利依舊很難。

森哥的話是一句沒有對賭的玩笑，無從考證，但從他另外兩家公司的經營模式和現狀來看，我選擇相信，同時更加相信創業和盈利都是有章可循的，就像我們做系統設計一樣，掌握了方向和底層個規律，連續成功是完全可以的，只要足夠努力、足夠勤奮，當然，還需要有足夠的遠見和魄力，以及資源、人脈。

老當益壯，寧移白首之心。對于強者而言，時光可以摧毀他們的外表，卻無法吞噬他們的內心，經歷越多他們只會更加通透，繼而越加強大，越加能夠駕馭時光。