本文將以一個案例，向讀者逐步揭示一套業(yè)務(wù)系統(tǒng)從0到1的設(shè)計過程。重點講述架構(gòu)、模型等業(yè)務(wù)系統(tǒng)最本質(zhì)的設(shè)計精要。
理論知識
業(yè)務(wù)系統(tǒng)設(shè)計概述
1. 什么是業(yè)務(wù)系統(tǒng)
互聯(lián)網(wǎng)公司常常根據(jù)用戶性質(zhì)將產(chǎn)品分為兩大類：C端產(chǎn)品和B端產(chǎn)品。
C端產(chǎn)品主要是面向客戶和消費者的系統(tǒng)；B端產(chǎn)品的服務(wù)對象是組織機構(gòu)，給供應(yīng)商或商家使用的系統(tǒng)、給公司內(nèi)部業(yè)務(wù)人員使用的系統(tǒng)，都被稱為B端產(chǎn)品。
因為服務(wù)對象不同，二者在建設(shè)時的出發(fā)點和側(cè)重點也完全不同：
C端產(chǎn)品偏重用戶體驗，強調(diào)感性，每個按鈕的擺放位置都要精心設(shè)計、論證，需要進行持續(xù)的數(shù)據(jù)分析和優(yōu)化。
B端產(chǎn)品偏重流程化、模塊化，強調(diào)抽象和結(jié)構(gòu)性，講究整體的規(guī)劃和體系設(shè)計。
如果將B端產(chǎn)品進一步拆分，又可以分為三類：
第一類是業(yè)務(wù)平臺產(chǎn)品，即為業(yè)務(wù)部門提供基礎(chǔ)服務(wù)支持的產(chǎn)品。
第二類是供內(nèi)部員工使用的辦公協(xié)同產(chǎn)品，支持企業(yè)的經(jīng)營、管理和業(yè)務(wù)運轉(zhuǎn)。
第三類是商家端產(chǎn)品，常見于雙邊模式的平臺型互聯(lián)網(wǎng)公司，例如淘寶的賣家管理系統(tǒng)、美團的商家管理后臺。
常見的業(yè)務(wù)平臺產(chǎn)品包括：
常見的辦公協(xié)同產(chǎn)品包括：
因為絕大多數(shù)互聯(lián)網(wǎng)公司的業(yè)務(wù)模式都有自己的特點，所以很多時候類似CRM、WMS、TMS這類業(yè)務(wù)平臺系統(tǒng)都需要自主研發(fā)；而OA、HRM這類協(xié)同辦公系統(tǒng)會采購標準軟件，不過有些互聯(lián)網(wǎng)巨頭也會自主研發(fā)OA、HRM。
本文所說業(yè)務(wù)系統(tǒng)包括B端產(chǎn)品線中的業(yè)務(wù)平臺產(chǎn)品和辦公協(xié)同產(chǎn)品——因為B端產(chǎn)品都是面向業(yè)務(wù)（Business）的系統(tǒng)，服務(wù)于組織而非個人，所以其設(shè)計思想和原理都是相同的，因而本文講解的內(nèi)容適用于所有B端系統(tǒng)的設(shè)計場景。
當企業(yè)發(fā)展到一定階段時，業(yè)務(wù)系統(tǒng)對企業(yè)的高效管理和運轉(zhuǎn)具備不可替代的核心作用。
例如，當一家公司只有幾個銷售人員時，客戶資料用Excel即可管理；當銷售人員發(fā)展到上千人時，則必須通過一套OCRM系統(tǒng)進行管理。
總體來講，業(yè)務(wù)系統(tǒng)對企業(yè)具有四點價值：提升管控能力、控制經(jīng)營風險、降低運營成本、提升銷售業(yè)績。
很多時候，業(yè)務(wù)系統(tǒng)建設(shè)的好壞決定了企業(yè)的核心競爭力，例如，外賣公司之間的競爭，配送員的效率是業(yè)務(wù)成敗的決定因素之一，而配送員的效率取決于TMS（運輸管理系統(tǒng)）建設(shè)的好壞，這既包括軟件系統(tǒng)本身的質(zhì)量，也包括配套的管理運營體系的執(zhí)行情況。
2. 為什么要學(xué)習設(shè)計業(yè)務(wù)系統(tǒng)
商業(yè)模式的創(chuàng)新是互聯(lián)網(wǎng)行業(yè)最大的特點，商業(yè)模式的創(chuàng)新會帶來業(yè)務(wù)模式的創(chuàng)新，業(yè)務(wù)模式的創(chuàng)新又會帶來運營、管理機制的創(chuàng)新。
多數(shù)情況下，采取了創(chuàng)新業(yè)務(wù)模式的互聯(lián)網(wǎng)公司，無法通過采購成熟的標準軟件來支持業(yè)務(wù)，而作為技術(shù)驅(qū)動型企業(yè)，自主研發(fā)系統(tǒng)來支持新業(yè)務(wù)便成為不二選擇。
例如，滴滴公司在成立時，是無法在市面上找到一款成熟的司機管理運營軟件的，因此需要自主研發(fā)；這時就需要有專業(yè)經(jīng)驗的資深產(chǎn)品經(jīng)理，結(jié)合業(yè)務(wù)，從無到有地設(shè)計一套司機（甚至是針對司機運營的機構(gòu)）管理系統(tǒng)。
再例如，美團需要管理大量的地推人員和客戶，傳統(tǒng)的OCRM軟件根本無法滿足美團（美團對地理位置管理有很高要求）的訴求，即便采購成熟的OCRM做定制化開發(fā)，難度也比較大。最好的辦法是自主研發(fā)一套全新的基于獨特業(yè)務(wù)模式的OCRM軟件來支持業(yè)務(wù)。
由此可以看出，互聯(lián)網(wǎng)企業(yè)創(chuàng)新的本質(zhì)，決定了必須有一批優(yōu)秀的業(yè)務(wù)系統(tǒng)設(shè)計人員，結(jié)合公司特殊業(yè)務(wù)訴求，快速、合理地設(shè)計配套系統(tǒng)，并落地支持業(yè)務(wù)。
業(yè)務(wù)系統(tǒng)的產(chǎn)品經(jīng)理，要具備企業(yè)經(jīng)營管理、軟件系統(tǒng)設(shè)計的多方面經(jīng)驗和知識儲備，才能設(shè)計合理的業(yè)務(wù)系統(tǒng)。
3. 業(yè)務(wù)系統(tǒng)設(shè)計的流程
從無到有地設(shè)計業(yè)務(wù)系統(tǒng)，是有一套標準范式可以遵循的。
一般來講，一套業(yè)務(wù)系統(tǒng)從0到1的構(gòu)建，需要經(jīng)歷如下環(huán)節(jié)（其中PM代表產(chǎn)品經(jīng)理，需要從整體上把控業(yè)務(wù)系統(tǒng)的建設(shè)，協(xié)調(diào)各個相關(guān)方，對整個項目負責）：
業(yè)務(wù)方案設(shè)計
PM和業(yè)務(wù)負責人一起梳理、制定業(yè)務(wù)流程、制度、機制，理解業(yè)務(wù)的問題點，并確定軟件系統(tǒng)解決方案。
系統(tǒng)整體方案設(shè)計
PM結(jié)合業(yè)務(wù)訴求與目標完成系統(tǒng)概要設(shè)計，包括明確產(chǎn)品定位（界定業(yè)務(wù)和系統(tǒng)的邊界）、抽象功能模塊、設(shè)計演進藍圖、設(shè)計整體應(yīng)用架構(gòu)，明確新系統(tǒng)如何與公司已有系統(tǒng)連接、交互。
系統(tǒng)細節(jié)方案設(shè)計
PM需要負責細節(jié)方案的所有設(shè)計工作，包括數(shù)據(jù)建模、角色梳理、界面設(shè)計、權(quán)限設(shè)計等。
其中數(shù)據(jù)建模是最難的部分：數(shù)據(jù)建模的好壞決定了系統(tǒng)未來的靈活性、可擴展性，數(shù)據(jù)建模要求對業(yè)務(wù)有全面理解，并且有極強的抽象和歸納能力。
實施驗收
PM對項目的最終落地負責，系統(tǒng)上線后要展開持續(xù)的迭代優(yōu)化，深度參與產(chǎn)品運營、數(shù)據(jù)分析等。
如果是從無到有地設(shè)計一套業(yè)務(wù)系統(tǒng)，以上環(huán)節(jié)必須全面貫徹，尤其是應(yīng)用架構(gòu)設(shè)計和數(shù)據(jù)模型，是重中之重。
案例分析
某電商公司的渠道銷售系統(tǒng)設(shè)計
本文將結(jié)合一個案例，帶大家一步步設(shè)計一個業(yè)務(wù)系統(tǒng)，幫助讀者理解以上所有的設(shè)計環(huán)節(jié)。
背景
某電商企業(yè)M公司，成立5年，主營生鮮商品，以C端客戶為主，業(yè)務(wù)穩(wěn)定，系統(tǒng)建設(shè)成熟。
M公司在三個月前嘗試開展分銷業(yè)務(wù)，成立銷售團隊，開發(fā)分銷商合作伙伴（通過分銷商批量推廣和銷售商品）；業(yè)務(wù)試點在北京、上海開展，三個月以來發(fā)展迅速，同時，在高速發(fā)展中，若干流程、管理、風險問題突顯。
評估
經(jīng)公司管理層評估，目前分銷業(yè)務(wù)月流水50萬元，以月增長率20%的速度快速發(fā)展。公司決定投入研發(fā)資源建設(shè)軟件系統(tǒng)，支撐業(yè)務(wù)發(fā)展。
任務(wù)
公司要求在2~3個月的時間內(nèi)搭建出一套分銷業(yè)務(wù)平臺，支撐分銷業(yè)務(wù)在未來2年的高速發(fā)展，提升效率，控制經(jīng)營風險。項目期間CTO全力提供人力資源支持。
1. 工作計劃
作為項目負責人，產(chǎn)品經(jīng)理在接到任務(wù)后，首先要理清工作思路，拆解任務(wù)，制訂時間計劃。只有嚴格遵循時間計劃執(zhí)行工作，才能保證整體工作有序展開，如期落地。
根據(jù)經(jīng)驗和初步判斷，我們制訂粗略的工作計劃表如下：
時間緊，任務(wù)重，產(chǎn)品經(jīng)理需要立即開展行動。
當然，計劃表中的研發(fā)周期只是一個粗拍的時間，具體實施周期要結(jié)合一期項目范圍及人力投入，在立項時細化。
2. 業(yè)務(wù)調(diào)研與業(yè)務(wù)方案
設(shè)計系統(tǒng)之前，必須透徹理解業(yè)務(wù)現(xiàn)狀與業(yè)務(wù)目標，考慮如何結(jié)合現(xiàn)有系統(tǒng)改造、優(yōu)化業(yè)務(wù)流程和模式。
此階段可以由一個高級產(chǎn)品經(jīng)理帶領(lǐng)幾個初級產(chǎn)品經(jīng)理來做，最好邀請技術(shù)負責人一起參與；這樣有利于技術(shù)人員提前理解業(yè)務(wù)，為技術(shù)選型和方案設(shè)計做好準備，也便于讓技術(shù)負責人協(xié)助產(chǎn)品經(jīng)理共同完成整體方案設(shè)計和細節(jié)方案設(shè)計——因為有時產(chǎn)品方案設(shè)計會受技術(shù)方案影響。
2.1 業(yè)務(wù)調(diào)研的方法
業(yè)務(wù)調(diào)研有多種方法，例如輪崗實習、問卷調(diào)研、深度訪談等。
其中，輪崗實習是深入理解業(yè)務(wù)的好方法，但是需要的時間較長；深度訪談是一種更加便捷快速的方法。
訪談之前，最好對業(yè)務(wù)有大體的認知，安排好訪談的對象，提前準備好問題，讓訪談更加高效。
以下是針對分銷業(yè)務(wù)的訪談計劃和調(diào)研表：
主持人員：產(chǎn)品經(jīng)理、研發(fā)經(jīng)理
調(diào)研對象：業(yè)務(wù)負責人、一線主管、一線業(yè)務(wù)人員、合作伙伴（分銷業(yè)務(wù)客戶）
調(diào)研方式：
深度訪談（訪談大綱如下圖），并進行數(shù)據(jù)分析。
調(diào)研目標：
業(yè)務(wù)調(diào)研總結(jié)
業(yè)務(wù)調(diào)研主要需要梳理清楚以下方面的情況，我們結(jié)合案例依此來看。
2.2 組織架構(gòu)
通過調(diào)研，我們首先理清了當下的基本業(yè)務(wù)組織架構(gòu)（如下面左圖所示），通過組織架構(gòu)圖能夠方便地理解管理體系和職能單元的設(shè)計。
根據(jù)公司的要求，需要提升分銷業(yè)務(wù)的效率，控制經(jīng)營風險，所以我們計劃做出兩方面調(diào)整：各分公司成立自己的運營部，招聘自己的運營人員，以便對市場做出迅速響應(yīng)，提升效率；在分銷業(yè)務(wù)部下新增業(yè)務(wù)支持與風控部，以便控制風險。
規(guī)劃的組織架構(gòu)如上面右圖所示。
2.3 業(yè)務(wù)目標
我們梳理了關(guān)鍵業(yè)務(wù)指標和目標，如下表所示：
2.4 業(yè)務(wù)流程
通過調(diào)研，我們還梳理了目前的業(yè)務(wù)運作流程，這樣才能對實際業(yè)務(wù)運作有清晰的了解，如下圖所示：
可以看出：目前業(yè)務(wù)開展以手工作業(yè)為主，下單配送環(huán)節(jié)依托于公司已有的系統(tǒng)實現(xiàn)。
3. 問題梳理
基于目前手工作業(yè)流程，我們整理出如下業(yè)務(wù)問題：
當前流程下，一個運營人員只能跟進并維護5個左右的客戶，每日只能處理10筆左右的訂單，人效極低。
3.1 基于業(yè)務(wù)調(diào)研的核心訴求分析
基于整體調(diào)研結(jié)果，我們概要性地列出如下解決思路（括號中注明了優(yōu)先級）：
我們將業(yè)流程優(yōu)化確定為高優(yōu)訴求，將擴展功能或針對部分客戶的小眾功能，以及風控功能列為低優(yōu)。
經(jīng)過探討，和業(yè)務(wù)人員達成一致，一期項目聚焦高優(yōu)訴求的實現(xiàn)。
4. 業(yè)務(wù)主流程設(shè)計
經(jīng)過和業(yè)務(wù)人員充分溝通，我們設(shè)計出系統(tǒng)支持下的核心業(yè)務(wù)流程圖，如下圖所示：
其中，客戶開發(fā)、合同審核等前置流程，依然通過線下處理完成；而客戶簽約后的賬號管理、價格管理、自主下單等環(huán)節(jié)，則通過分銷系統(tǒng)來支持，以提升效率。
5. 系統(tǒng)整體方案設(shè)計
完成業(yè)務(wù)調(diào)研后，進入系統(tǒng)整體方案設(shè)計環(huán)節(jié)。
該環(huán)節(jié)需要由經(jīng)驗豐富的產(chǎn)品經(jīng)理以及公司的架構(gòu)師一起探討完成，因為方案涉及和公司現(xiàn)有應(yīng)用架構(gòu)如何融合的問題，因而還需要經(jīng)過產(chǎn)品委員會或架構(gòu)組的評審和確認。
5.1 系統(tǒng)定位
我們對業(yè)務(wù)進行分析。
首先，分銷客戶希望能有一個便捷快速下單的工具，所以需要有一個手機版商城C端；考慮到投入產(chǎn)出比，我們決定通過H5來實現(xiàn)，具有獨立域名，外網(wǎng)可訪問。
最后，考慮到公司運營人員和分銷客戶管理員的管理訴求不同，操作功能和頁面差異較大，所以決定將管理后臺拆解為兩個獨立的系統(tǒng)：
于是，我們打算將分銷系統(tǒng)拆分為三個獨立的子系統(tǒng)，來支持分銷業(yè)務(wù)：
設(shè)計業(yè)務(wù)系統(tǒng)常見的問題是：為了省事，把所有業(yè)務(wù)單元的功能糅合到一個系統(tǒng)中實現(xiàn)，這會造成管理的混亂，尤其是系統(tǒng)維護的混亂。
一般來講，系統(tǒng)的抽象要結(jié)合業(yè)務(wù)完成，獨立的業(yè)務(wù)職能單元要配合獨立的系統(tǒng)來使用；如果業(yè)務(wù)部門之間邊界模糊，權(quán)責界定不清，也會導(dǎo)致系統(tǒng)之間存在模糊性。
清晰的系統(tǒng)定位和邊界，可以讓各個子系統(tǒng)具備足夠的獨立性，是整個系統(tǒng)具備靈活性和可擴展性的基本前提。
5.2 整體架構(gòu)設(shè)計
現(xiàn)在，需要考慮分銷平臺的三個子系統(tǒng)如何與公司的整體應(yīng)用架構(gòu)融合。
公司經(jīng)過多年發(fā)展，系統(tǒng)架構(gòu)體系已經(jīng)非常完備，大量公共組件和模塊可以復(fù)用，這樣就減輕了新平臺的實現(xiàn)成本和難度。
分銷平臺只需要聚焦自己業(yè)務(wù)特殊獨立的地方，其他公共組件和模塊復(fù)用已有系統(tǒng)的即可。
具體分析如下：
電商業(yè)務(wù)是公司的主營業(yè)務(wù)，有成熟的訂單體系和倉配系統(tǒng)。
分銷業(yè)務(wù)的獨特性在于前置客戶（是企業(yè)客戶）的管理維護，下單后的分揀配送業(yè)務(wù)流程和之前的業(yè)務(wù)是一樣的，所以分銷商城的訂單中心直接復(fù)用已有訂單中心，訂單寫入后續(xù)的處理流程完全不變，只需要訂單中心稍作改造即可支持，這樣也可以保證整個訂單臺賬、財務(wù)、倉儲、配送基本都不需要重寫或改造。
另外分銷平臺的商品中心復(fù)用已有商品中心SKU數(shù)據(jù)，只是價格管理模塊部分需要新做一套獨立的，以支持特殊報價業(yè)務(wù)。
分銷業(yè)務(wù)的賬戶體系、權(quán)限管理體系、在線支付功能，都可以利用已有系統(tǒng)。其中賬戶體系需要做改造，以支持子母賬號管理；在線支付功能完全復(fù)用即可。
客戶資料的存儲利用已有的客戶主數(shù)據(jù)（MDM）系統(tǒng)實現(xiàn)——因為企業(yè)客戶資料和個人客戶資料的差異較大，所以需要對MDM做較大改造，要新做一套企業(yè)客戶數(shù)據(jù)模型。
但是在架構(gòu)上，必須將客戶（包括個人客戶和企業(yè)客戶）資料作為主數(shù)據(jù)來建設(shè)，統(tǒng)一管理維護。
最后一個問題：既然公司已經(jīng)有C端商城，為什么要單獨再做一套針對分銷客戶的C端商城？
經(jīng)過分析評估，個人客戶和企業(yè)客戶需要的功能差異，如果對原有商城進行改造來支持分銷業(yè)務(wù)，一方面需要投入的工時可能比新做一套還要多，另一方面會影響主營業(yè)務(wù)系統(tǒng)的健壯性，因此最終決定為分銷業(yè)務(wù)做一套新的C端商城。
基于上述分析，我們將三個子系統(tǒng)繪入簡化版的公司整體應(yīng)用架構(gòu)圖中，如下：
5.3 功能抽象
基于對業(yè)務(wù)的分析，以及三套系統(tǒng)的定位，可以抽象并繪制完整的系統(tǒng)功能藍圖。
功能模塊圖，是對業(yè)務(wù)訴求系統(tǒng)化設(shè)計的進一步高度抽象。模塊的設(shè)計，要體現(xiàn)出同一個業(yè)務(wù)職能單元中不同業(yè)務(wù)場景和操作的集合，模塊也代表了系統(tǒng)中的一二級導(dǎo)航菜單的設(shè)計。
常見的問題是：設(shè)計人員對模塊設(shè)計的隨意和混亂，以及后來新增功能的隨意擺放，會造成用戶使用系統(tǒng)時產(chǎn)生困惑，同時還會導(dǎo)致開發(fā)人員編碼設(shè)計的混亂。
功能模塊圖，代表了設(shè)計師對業(yè)務(wù)和系統(tǒng)本質(zhì)的理解和提煉，包含了對業(yè)務(wù)、系統(tǒng)未來發(fā)展的展望。
我們常說，系統(tǒng)建設(shè)要有規(guī)劃和節(jié)奏，實際上功能模塊圖就是一幅遠景規(guī)劃藍圖；是系統(tǒng)的骨架，決定了系統(tǒng)的整體結(jié)構(gòu)。
結(jié)合業(yè)務(wù)需求，每一個具體功能的實現(xiàn)，都是在對骨架不斷地填充血肉，讓他更真實，更立體，更豐富。
隨著業(yè)務(wù)的開展，變化，功能模塊圖可能會有新的規(guī)劃和調(diào)整，但如果業(yè)務(wù)單元的本質(zhì)和模式?jīng)]有變化，功能模塊圖不應(yīng)該出現(xiàn)結(jié)構(gòu)性的調(diào)整和改動。
5.4 演進藍圖
我們已經(jīng)繪制了系統(tǒng)的功能模塊圖，體現(xiàn)了業(yè)務(wù)和系統(tǒng)規(guī)劃的脈絡(luò)；現(xiàn)在，讓我們開始研究這套“體系”，大概需要幾期實現(xiàn)，每期實現(xiàn)的側(cè)重點是什么，也就是常說的演進藍圖——Roadmap：
白色部分，是一期的項目范圍。聚焦解決最基本的業(yè)務(wù)流程線上化問題，以及最痛的痛點，例如對賬功能。
一期功能有一個原則：凡是可以手工處理和解決的問題，都不做系統(tǒng)支持。
所以：
綠色部分，是二期的項目范圍。二期將解決部分特殊業(yè)務(wù)剛需的訴求，例如要支持“預(yù)付款”模式，“賬期”模式，“發(fā)票管理”，如果時間允許，可以一并實現(xiàn)若干報表查詢功能。
藍色部分，是三期的項目范圍。三期將聚焦風險控制，并強化運營功能。
一般來講，很多互聯(lián)網(wǎng)公司初期會先跑業(yè)務(wù)，走流水，驗證可行性，成本和風險控制并不是特別在意；當業(yè)務(wù)具備一定規(guī)模時，則必須引入系統(tǒng)風控機制；做到事前、事中、事后的風險控制。
此外，基于本案例B2B業(yè)務(wù)的特點，設(shè)計中并沒有考慮太多的C端功能；實際上C端只需要保證客戶能夠方便下單，并做一些很粗的運營、通知即可。
6. 系統(tǒng)細節(jié)方案設(shè)計
系統(tǒng)整體架構(gòu)和藍圖設(shè)計完成后，進入細節(jié)方案設(shè)計環(huán)節(jié)。
建模部分建議由高級PM和技術(shù)負責人共同完成，界面、權(quán)限設(shè)計可以由高級PM帶領(lǐng)初級PM共同完成。
6.1 實體建模
實體建模是細節(jié)設(shè)計中最難，也是最重要的環(huán)節(jié)。實體建模代表將客觀世界的對象，抽象成結(jié)構(gòu)化的描述。
實體建模有問題，會導(dǎo)致后續(xù)業(yè)務(wù)和系統(tǒng)完全喪失擴展性和靈活性，甚至會很快就無法支持業(yè)務(wù)，需要推倒重做。
實體建模實際上是數(shù)據(jù)庫設(shè)計中最重要的部分，會影響數(shù)據(jù)庫表結(jié)構(gòu)的設(shè)計，但更多體現(xiàn)了對業(yè)務(wù)本質(zhì)的理解和認知。
很多產(chǎn)品經(jīng)理常常忽略實體建模，只關(guān)注功能界面設(shè)計，最終會陷入邏輯的混亂和旋渦中。
只要模型清晰合理，功能設(shè)計、界面設(shè)計都是水到渠成的事。
我們將結(jié)合案例，以客戶模型設(shè)計為起點，詳細闡述實體建模的設(shè)計思路。
6.1.1 理想化的客戶模型
首先回顧客戶訴求。
目前的分銷客戶中，有比較大型的集團客戶，下設(shè)若干省市機構(gòu)和庫房、門店；調(diào)研時，集團客戶有如下訴求：
以上訴求，是業(yè)務(wù)系統(tǒng)建設(shè)中，最經(jīng)典常見的樹形組織機構(gòu)管理訴求——不論是公司、客戶，作為企業(yè)，都有多層級管理的要求，希望軟件系統(tǒng)能夠支持多層級業(yè)務(wù)體系。
多層級機構(gòu)管理，通常使用組織機構(gòu)樹實現(xiàn)，在一顆樹上繪制出業(yè)務(wù)的管理層級體系。
我們將分銷業(yè)務(wù)作為組織機構(gòu)管理樹的根節(jié)點，客戶屬于子樹，樹形結(jié)構(gòu)可以體現(xiàn)出客戶的行政管理層級結(jié)構(gòu)。
將賬號和門店（收貨對象，可以是中央倉，也可以是店鋪）作為葉子，掛在機構(gòu)節(jié)點下。
賬號管理的數(shù)據(jù)范疇（包括能給哪些門店下單，能查看哪些門店的數(shù)據(jù)），可以遍歷所在節(jié)點的子樹來實現(xiàn)。
繪制示意圖如下：
通過組織機構(gòu)樹，結(jié)合功能權(quán)限配置，可以實現(xiàn)集團客戶的管理訴求。
上圖中實際上存在三個對象，組織機構(gòu)節(jié)點/賬號/門店，通過實體建模ER圖，可以描述出三者的關(guān)系。
如下：
每個機構(gòu)都有一個“上級機構(gòu)”字段，通過該字段描述的關(guān)聯(lián)關(guān)系，可以繪制出完整的組織機構(gòu)樹；每個賬號或門店，只允許隸屬于一個組織機構(gòu)節(jié)點，每個門店下可以維護多個收貨人。
實體建模的過程，就是將業(yè)務(wù)對象抽象，并描述之間的對應(yīng)關(guān)系。
例如以上ER圖，看似簡單，但卻是對組織機構(gòu)樹以及賬號、門店管理體系的高度抽象。
如果實現(xiàn)以上模型，可以支持任意靈活地集團客戶管理訴求。
6.1.2 簡化版的客戶模型
實現(xiàn)組織樹模型，開發(fā)復(fù)雜度很高。
經(jīng)過和開發(fā)、業(yè)務(wù)溝通，最終決定采用一套簡版的客戶模型來支持一期業(yè)務(wù)，該簡版模型在需要時完全可以升級到理想版的客戶模型。
首先，和業(yè)務(wù)以及客戶溝通確認，一期暫不支持復(fù)雜的行政層級管理，只需要給客戶實現(xiàn)若干子賬號可以管理若干門店即可，示意圖如下。
這樣系統(tǒng)只需要實現(xiàn)一顆非常簡單的樹，每個客戶只有一個根節(jié)點而沒有子節(jié)點，以便業(yè)務(wù)系統(tǒng)開發(fā)時不需要編寫大量的遍歷算法，大大降低了開發(fā)難度。
根據(jù)上述規(guī)則，將模型簡化如下：
仔細觀察可以發(fā)現(xiàn)：該模型與前一個模型相比，唯一的變化，是在賬號和門店兩個對象之間創(chuàng)建了關(guān)聯(lián)關(guān)系，其他結(jié)構(gòu)不變（這樣處理，保持了模型未來的擴展性）。
當未來需要全面實現(xiàn)組織機構(gòu)管理時，將賬號/門店之間的對應(yīng)關(guān)系打斷，在業(yè)務(wù)系統(tǒng)中實現(xiàn)遍歷算法，以及組織樹管理維護功能即可，整個數(shù)據(jù)底層基本不需要調(diào)整。
6.1.3 更豐富一些的客戶模型
業(yè)務(wù)需求中很重要的一條：能夠針對每個客戶每個門店的個性報價，設(shè)置不同的系數(shù)表，結(jié)合時價動態(tài)計算商品價格。
這里涉及到幾個新的對象：系數(shù)表、報價單。
為了讓管理可控，系數(shù)表是全公司通用的多套參數(shù)集合。包括了商品和價格系數(shù)，給每個門店關(guān)聯(lián)并且只能關(guān)聯(lián)一個有效的報價單，報價單關(guān)聯(lián)系數(shù)表，以保證運營人員只需要調(diào)整一次系數(shù)表，就能刷新到所有需要修改的門店的價格表。
數(shù)據(jù)模型設(shè)計如下：
該模型體現(xiàn)了真實世界針對門店單獨報價的場景，同時也體現(xiàn)了價格系數(shù)表的設(shè)計思路。
理清了賬號、門店、機構(gòu)、報價單、價格系數(shù)表之間的關(guān)系，功能設(shè)計都是水到渠成的事情。如果沒有梳理清楚這些關(guān)系，功能設(shè)計、界面設(shè)計時必然是一頭霧水，漏洞百出。
6.1.4 建模錯誤會導(dǎo)致擴展的災(zāi)難
最后，我們來看一個建模錯誤導(dǎo)致災(zāi)難的例子。
如果我們將上圖數(shù)據(jù)模型中，賬號和門店的對應(yīng)關(guān)系調(diào)整成一對多，如下：
設(shè)計人員可能會認為，目前的業(yè)務(wù)訴求很明確：一個門店只能被一個賬號管理，所以賬號和門店被設(shè)計成一對多關(guān)系。
如果有一天，客戶明確并要求必須支持一個門店被多個賬號管理（也就是要實現(xiàn)賬號和門店多對多的設(shè)計）。
實現(xiàn)此訴求，難度將非常非常大——因為從數(shù)據(jù)底層，到前端功能實現(xiàn)，都認為是一對多結(jié)構(gòu)，如果要改成多對多，首先底層數(shù)據(jù)庫結(jié)構(gòu)得調(diào)整，所有歷史數(shù)據(jù)要處理；其次，基本上所有涉及到讀取賬號和門店關(guān)系的功能代碼需要全部重寫。
看似簡單的一個改造，會造成一場災(zāi)難。
設(shè)計人員應(yīng)該在設(shè)計之初，就要做好設(shè)計的預(yù)判。即便早期業(yè)務(wù)訴求是一對多，但是模型要按照多對多設(shè)計，因為這是在現(xiàn)實世界中合理的一種邏輯存在，即便早期沒有多對多管理的訴求，但只要模型和數(shù)據(jù)底層設(shè)計好，后續(xù)再調(diào)整會簡單很多。
那么問題來了：是不是所有對象的關(guān)系，都應(yīng)該設(shè)計成多對多就行了呢？
也不對。
比如門店和訂單的關(guān)系，只可能是一對多，不可能是多對多；一個訂單只能是一個門店提交的，現(xiàn)實世界中不存在門店和訂單多對多的邏輯關(guān)系。
建模的難點和重點，就是將現(xiàn)實世界抽象成對象，描述其關(guān)聯(lián)關(guān)系。
如果這些對象和關(guān)系沒有梳理清楚，流程、界面的設(shè)計都會是一筆糊涂賬。
6.2 用戶角色設(shè)計和流程圖
在整個方案中，我們設(shè)計了4個角色，來支持業(yè)務(wù)。
其中：
客戶管理員：負責下單賬號和門店的管理/維護，訂單查詢，對賬結(jié)算。
客戶采購：負責給門店下單。
角色的設(shè)計，取決于業(yè)務(wù)對權(quán)責的劃分。用戶角色設(shè)計完成后，可以繪制更加詳細的，基于系統(tǒng)的流程圖。
如下：
流程圖（以及頁面流轉(zhuǎn)圖）是所有軟件界面設(shè)計的基本前提，清晰的流程圖和各種異常情況的分支描述，可以讓后續(xù)的界面設(shè)計事半功倍。
如果沒有清晰地流程圖，界面設(shè)計絕對會陷入混亂。
7. 界面設(shè)計
建模合理，流程清晰，界面設(shè)計會變的非常簡單。
網(wǎng)上關(guān)于界面設(shè)計的文章也非常多，方法論也很多；比如尼爾森十大可用性原則，讀者可自行查閱，本文不再贅述，這里只講幾個建議。
7.1 模仿是最好的設(shè)計
研究并借鑒成熟的軟件系統(tǒng)的設(shè)計，可以提升設(shè)計能力，少走彎路。
網(wǎng)上有很多免費開放試用的系統(tǒng)，都可以用來參考。比如Google Analytics / 百度統(tǒng)計 / 管家婆云ERP / SalesForce等。結(jié)合你設(shè)計的軟件形態(tài)，找到行業(yè)內(nèi)相似的SASS軟件，借鑒并參考其排版、布局，可以提高設(shè)計效率與合理性。
7.2 拒絕花哨的前端
業(yè)務(wù)系統(tǒng)，不需要花哨的前端，不需要創(chuàng)意的控件。
有很多初入行的PM，喜歡在交互設(shè)計上做太多的發(fā)明創(chuàng)造；對于業(yè)務(wù)系統(tǒng)，價值不大，并且會增加研發(fā)的工作量。
我曾經(jīng)見過一個業(yè)務(wù)系統(tǒng)，把其中的多選控件做的異常復(fù)雜——多選框中隱含了其他的交互形態(tài)，導(dǎo)致前端需要耗費大量的精力去定制開發(fā)實現(xiàn)，實在沒有必要。
選用標準的控件方案，可以節(jié)約PM和前端的大量時間。
什么叫標準的控件呢？
MS Visio或Axure里提供的可以繪制的控件，就是標準控件。
不要在這些標準控件以外去發(fā)明創(chuàng)造控件！
對于復(fù)雜一點的報表和儀表盤設(shè)計，推薦兩個組件庫，一個是百度的ECharts，一個是Eclipse Birt，里邊包含了大量經(jīng)典的設(shè)計方案，這兩者都是開源的，可以直接拿來用。
8. 權(quán)限設(shè)計
權(quán)限設(shè)計，是業(yè)務(wù)系統(tǒng)設(shè)計中最重要的一部分。權(quán)限設(shè)計代表了對整個業(yè)務(wù)體系崗位和流程的理解和拆解。
軟件系統(tǒng)的權(quán)限設(shè)計包含兩部分，功能權(quán)限和數(shù)據(jù)權(quán)限。
功能權(quán)限是指不同角色可以操作的界面、按鈕等等。
例如：某一個角色在訂單查詢頁面能看到哪些字段，能操作哪些按鈕。
數(shù)據(jù)權(quán)限是指不同角色在同一頁面中看到的數(shù)據(jù)范圍。例如分公司管理員在訂單查詢頁面能看到分公司的所有訂單，而區(qū)域主管只能看到所在區(qū)域的訂單。
功能權(quán)限設(shè)計的經(jīng)典方法論是RBAC（Role Based Access Control），描述了一套用戶、角色、權(quán)限組的設(shè)計理念，簡單的可以抽象為以下實體關(guān)系圖：
該理論具體的講解，讀者可在網(wǎng)絡(luò)上自行查閱，請讀者理解RBAC的數(shù)據(jù)模型圖。
可以看出：軟件系統(tǒng)的設(shè)計，即便是權(quán)限管理體系設(shè)計，最終也都會歸結(jié)抽象到數(shù)據(jù)模型的設(shè)計。
由此可見，抽象建模能力，是PM必須掌握的核心技能。
我們將權(quán)限管理部分，進一步做一個延伸討論：
假設(shè)我們實現(xiàn)了前文提到的完整的組織機構(gòu)樹，同時也有完善的權(quán)限控制體系，此時，系統(tǒng)可以完美的支持各種復(fù)雜的業(yè)務(wù)場景訴求。
我們在之前的角色設(shè)計中，新增一個角色“客戶采購員2”，其中“客戶采購員2”和“客戶采購員1”的區(qū)別是：前者的數(shù)據(jù)權(quán)限范圍，是查詢用戶當前所在組織機構(gòu)樹葉子上的數(shù)據(jù)，而后者能夠查詢用戶當前所在組織機構(gòu)樹葉子，以及葉子下邊所有子節(jié)點的數(shù)據(jù)。
客戶的組織架構(gòu)如下：
不同賬號，所能看到的數(shù)據(jù)權(quán)限范圍見下表：
請讀者結(jié)合上圖和下表，自己做出判斷：賬號4能查看哪些門店的訂單數(shù)據(jù)？如果您理解了這個案例中隱含的邏輯，則掌握了業(yè)務(wù)系統(tǒng)權(quán)限管理體系的主要核心思想。
9. 技術(shù)方案與項目實施
產(chǎn)出PRD以后，進入了技術(shù)設(shè)計和實施環(huán)節(jié)。
當然，對于一套全新的系統(tǒng)，技術(shù)設(shè)計可能很早就已經(jīng)啟動。再往后，就進入實施環(huán)節(jié)，以及上線后的持續(xù)迭代和產(chǎn)品運營環(huán)節(jié)。
以后有機會單獨介紹此部分話題。
全文總結(jié)
至此，我們結(jié)合一個實際案例，完整的介紹了一套系統(tǒng)從無到有的設(shè)計。介紹的重點是調(diào)研、架構(gòu)、模塊、建模、權(quán)限，對于交互、界面等細節(jié)一筆帶過。
實際上，文中已經(jīng)多次強調(diào)，并且讀者現(xiàn)在應(yīng)該也有了充分的認識：抽象、流程、建模才是業(yè)務(wù)系統(tǒng)設(shè)計的重點和核心，只有將業(yè)務(wù)最本質(zhì)的東西高度剝離并正確抽象，才能構(gòu)建一套靈活強大的系統(tǒng)。
對于一名后端產(chǎn)品經(jīng)理來講，以下經(jīng)驗和技能必不可可少。
路漫漫其修遠兮，后端產(chǎn)品經(jīng)理的成長是一個厚積薄發(fā)的過程，需要長期的堅持、積累、思考。
希望本文能夠幫助讀者對系統(tǒng)的設(shè)計有一個大體的認知和理解，并融入到工作中，形成更深層次的思考。
如果想做好B端產(chǎn)品經(jīng)理，那么一方面需要學(xué)習相關(guān)的專業(yè)知識，另一方面需要深入了解行業(yè)知識，熟悉業(yè)務(wù)流程。只有這樣，才能針對B端人群和場景做好產(chǎn)品設(shè)計。
