導讀

本文將以一個案例，向讀者逐步揭示一套業(yè)務系統(tǒng)從0到1的設計過程猖任。重點講述架構病苗、模型等業(yè)務系統(tǒng)最本質(zhì)的設計精要瀑梗。

一叛复、業(yè)務系統(tǒng)設計概述

1****微谓、什么是業(yè)務系統(tǒng)

互聯(lián)網(wǎng)公司常常將產(chǎn)品方向分為兩類双谆，C端和B端，C端主要是面向客戶和消費者的系統(tǒng)，B端的范圍則相對模糊混聊，給供應商或商家使用的系統(tǒng)供璧，給內(nèi)部業(yè)務人員使用的系統(tǒng)愧捕，都統(tǒng)稱為B端系統(tǒng)申钩。C端和B端系統(tǒng)建設的出發(fā)點和側(cè)重點完全不同次绘。C端系統(tǒng)偏重用戶體驗，強調(diào)感性撒遣，持續(xù)的數(shù)據(jù)分析優(yōu)化邮偎，同一個按鈕不同的擺放位置都要精心設計、論證义黎，服務對象是個人禾进；B端系統(tǒng)偏重流程、模塊化廉涕，強調(diào)抽象和結(jié)構性泻云，講究整體的規(guī)劃和體系設計，服務對象是組織和機構狐蜕。

如果將B端系統(tǒng)進一步拆分宠纯，也可以分為兩類，第一類是商家端层释，常見于雙邊模式的平臺型互聯(lián)網(wǎng)公司婆瓜，例如淘寶的賣家管理系統(tǒng)，美團的商家管理后臺；第二類是內(nèi)部業(yè)務系統(tǒng)廉白，支持企業(yè)經(jīng)營个初、管理、業(yè)務運轉(zhuǎn)猴蹂。

本文所說業(yè)務系統(tǒng)勃黍，指****B****端產(chǎn)品線中的企業(yè)內(nèi)部業(yè)務系統(tǒng)。雖然B端系統(tǒng)也可以分為兩類晕讲，但因為都是面向業(yè)務的系統(tǒng)（Business）覆获，服務于組織而非個人，其設計思想和原理都是相同的瓢省，所以本文講解的內(nèi)容可以應用于所有B端系統(tǒng)的設計場景弄息。

常見的業(yè)務系統(tǒng)包括ERP（EnterpriseResource Planning），CRM（CustomerRelationship Management）勤婚，SCM（Supply ChainManagement）摹量，WMS（WarehouseManagement System），TMS（TransportationManagement System）馒胆，OA（Office Automation）缨称，HRM（Human ResourceManagement）等等。因為絕大多數(shù)互聯(lián)網(wǎng)公司都有獨特的業(yè)務模式祝迂，所以很多時候類似于CRM睦尽、WMS、TMS這類系統(tǒng)都自主研發(fā)型雳，OA当凡、HRM這類系統(tǒng)由于業(yè)務模型區(qū)別不大，多數(shù)都會采購標準軟件纠俭。有些互聯(lián)網(wǎng)巨頭也會自主研發(fā)OA沿量、HRM。習慣上冤荆，CRM朴则、WMS這類系統(tǒng)被稱為業(yè)務系統(tǒng)，OA钓简、HRM這類系統(tǒng)被稱為內(nèi)部協(xié)同軟件乌妒，但兩類系統(tǒng)之間也并沒有非常清晰的界定。

如果從軟件學的角度來看涌庭，所有軟件系統(tǒng)分為兩類芥被，第一類是能夠?qū)崟r產(chǎn)生業(yè)務數(shù)據(jù)的系統(tǒng)欧宜，叫做OLTP（Online TransactionProcessing）系統(tǒng)坐榆，第二類是對數(shù)據(jù)進行加工、處理冗茸、探查席镀、挖掘匹中、展現(xiàn)的系統(tǒng)，叫做OLAP（Online AnalyticalProcessing）系統(tǒng)豪诲，很顯然顶捷，業(yè)務系統(tǒng)屬于OLTP的范疇。當企業(yè)發(fā)展到一定階段屎篱，業(yè)務系統(tǒng)對企業(yè)的高效管理運轉(zhuǎn)具備不可替代的核心作用服赎。例如，當一家公司只有幾個銷售人員時交播，客戶資料用Excel即可管理重虑。當銷售發(fā)展到上千人時，必須通過一套OCRM系統(tǒng)進行管理秦士。

總體來講缺厉，業(yè)務系統(tǒng)對企業(yè)具有四點價值：提升管控能力、控制經(jīng)營風險隧土、降低運營成本提针、提升銷售業(yè)績。很多時候曹傀，業(yè)務系統(tǒng)建設好壞決定了企業(yè)的核心競爭力辐脖，例如外賣公司之間的競爭，配送員的效率是業(yè)務成敗的決定因素之一皆愉，而配送員的效率取決于TMS系統(tǒng)建設的好壞揖曾。當然，TMS系統(tǒng)建設的好壞亥啦，包括了軟件系統(tǒng)本身炭剪，以及配套落地的管理運營體系的執(zhí)行。

2****翔脱、為什么要學習設計業(yè)務系統(tǒng)

商業(yè)模式的創(chuàng)新是互聯(lián)網(wǎng)行業(yè)最大的特點奴拦，商業(yè)模式的創(chuàng)新會帶來業(yè)務模式的創(chuàng)新，業(yè)務模式的創(chuàng)新會帶來運營届吁、管理機制的創(chuàng)新错妖。多數(shù)情況下，互聯(lián)網(wǎng)公司獨特的業(yè)務模式疚沐，導致無法采買市面上成熟的標準軟件來支持業(yè)務暂氯，而作為技術驅(qū)動型企業(yè)，自主研發(fā)系統(tǒng)支持新業(yè)務成為不二的選擇亮蛔。

例如痴施，滴滴公司，是無法在市面上找到一款成熟的司機管理運營軟件的，要么找外包公司開發(fā)辣吃，要么自主研發(fā)动遭，自主研發(fā)似乎更靠譜一些，這時神得，就需要有專業(yè)經(jīng)驗的資深產(chǎn)品經(jīng)理厘惦，結(jié)合業(yè)務，從無到有設計一套司機（甚至是針對司機運營的機構）管理系統(tǒng)哩簿。

再例如宵蕉，美團有大量的地推人員和客戶需要管理，傳統(tǒng)的OCRM軟件根本無法支持美團這種強POI訴求的客戶管理节榜，因為業(yè)務模式特殊国裳，即便采購成熟的OCRM做定制化開發(fā)，也難以使用全跨。所以缝左，只能靠自主研發(fā)一套全新的基于獨特業(yè)務模式的OCRM來支持業(yè)務。

由此可以看出浓若，互聯(lián)網(wǎng)企業(yè)創(chuàng)新的本質(zhì)渺杉，決定了必須有一批優(yōu)秀的業(yè)務系統(tǒng)設計人員，能夠結(jié)合公司特殊業(yè)務訴求挪钓，快速是越、合理的設計配套系統(tǒng)，并落地支持業(yè)務碌上。業(yè)務系統(tǒng)的產(chǎn)品經(jīng)理倚评，要具備企業(yè)經(jīng)營管理、軟件系統(tǒng)設計的多方面經(jīng)驗和知識儲備馏予，才能設計合理的業(yè)務系統(tǒng)天梧。

3****、業(yè)務系統(tǒng)設計的流程

業(yè)務系統(tǒng)從無到有的設計霞丧，是有一套標準范式可以遵循的呢岗。實際上，隨便一套《軟件工程學》教程蛹尝，講述的都是業(yè)務系統(tǒng)的設計后豫，但是軟件工程已經(jīng)不滿足當前時代對專業(yè)人員的培養(yǎng)和要求⊥荒牵互聯(lián)網(wǎng)時代下的軟件設計挫酿，已經(jīng)被拆分成多個細分職能，產(chǎn)品經(jīng)理參與制定業(yè)務愕难，設計應用功能早龟；工程師負責技術架構惫霸，編碼實施；而在傳統(tǒng)軟件工程中拄衰，這兩項職能由一個角色承擔。如今的現(xiàn)實情況是饵骨，軟件設計人員更多的參與到了業(yè)務決策制定翘悉，軟件研發(fā)人員越來越遠離業(yè)務，只聚焦于技術居触。

即便如此妖混，軟件設計中的經(jīng)典思路、方法論轮洋，是沒有改變的制市。業(yè)務系統(tǒng)的產(chǎn)品經(jīng)理，必須理解軟件工程學中的部分核心要素弊予，才能真正設計出靠譜的系統(tǒng)祥楣。

一般來講，一套業(yè)務系統(tǒng)從0到1的構建汉柒，需要經(jīng)歷如下環(huán)節(jié)误褪。

image

業(yè)務方案設計

PM和業(yè)務負責人一起梳理、制定業(yè)務流程碾褂、制度兽间、機制，理解業(yè)務的問題點正塌，并確定軟件系統(tǒng)解決方案嘀略。

系統(tǒng)整體方案設計

PM結(jié)合業(yè)務訴求與目標，完成系統(tǒng)概要設計乓诽，包括界定業(yè)務帜羊、系統(tǒng)的邊界，系統(tǒng)功能的抽象和演進藍圖鸠天，整體應用架構的設計逮壁，如何與公司已有系統(tǒng)拼接、交互粮宛。

系統(tǒng)細節(jié)方案設計

PM完成細節(jié)方案的所有設計窥淆，包括建模、角色巍杈、界面忧饭、權限等筷畦。其中建模是最難的部分刺洒，建模好壞決定了系統(tǒng)未來的靈活性吼砂、可擴展性逆航。建模要求對業(yè)務的全面理解因俐，極強的抽象歸納能力。

實施驗收

PM對最終項目落地負責周偎，系統(tǒng)上線后要展開持續(xù)的迭代優(yōu)化，深度參與產(chǎn)品運營澳眷，數(shù)據(jù)分析等钳踊。

如果是從無到有設計系統(tǒng)勿侯，以上環(huán)節(jié)必須全面貫徹罐监，尤其是架構設計和模型設計弓柱，是重中之重。

4****航罗、案例：某電商公司的渠道銷售系統(tǒng)設計

本文將結(jié)合一個虛擬的案例粥血，逐步論述复亏，幫助讀者理解以上所有的設計環(huán)節(jié)缔御。

背景：

某電商企業(yè)A公司耕突，成立5年笤成，主營生鮮商品炕泳，以C端客戶為主培遵，業(yè)務穩(wěn)定荤懂，系統(tǒng)建設成熟。

訴求：

公司在三個月前嘗試開展分銷業(yè)務掉蔬，成立銷售團隊女轿，開發(fā)分銷商合作伙伴壕翩。業(yè)務試點在北京放妈、上海開展芜抒，三個月以來發(fā)展迅速宅倒，現(xiàn)急需配套的軟件系統(tǒng)提升業(yè)務效率拐迁，控制經(jīng)營風險线召。

評估：

經(jīng)公司管理層評估灶搜，目前分銷業(yè)務月流水五十萬，以月增長率20%的速度快速發(fā)展患雏。在高速發(fā)展中若干流程淹仑、管理匀借、風險問題突出吓肋，公司決定投入研發(fā)資源建設軟件系統(tǒng)，支撐業(yè)務發(fā)展均蜜。

任務：

公司要求在2~3個月的時間內(nèi)搭建出一套可以支撐分銷業(yè)務2年高速發(fā)展的軟件系統(tǒng)囤耳，提升效率充择，控制經(jīng)營風險聪铺。項目期間CTO全力提供人力資源支持铃剔。

5****键兜、工作計劃

作為項目負責人普气，某高級PM接到任務后现诀，首先要理清工作思路仔沿，拆解任務绵跷，制定時間計劃。只有嚴格遵循時間計劃執(zhí)行工作净当，才能保證整體工作有序展開蚯瞧，如期落地。根據(jù)經(jīng)驗和初步判斷萄传，產(chǎn)品經(jīng)理制定了粗略的工作計劃表如下秀菱。

image

時間緊，任務重脊串，PM需要立即開展行動琼锋。當然缕坎，計劃表中的研發(fā)周期谜叹，純粹是一個粗拍的時間荷腊，具體實施周期要結(jié)合一期項目范圍停局，以及人力投入董栽，在立項時細化锭碳。

二擒抛、業(yè)務調(diào)研與業(yè)務方案

設計系統(tǒng)之前歧沪，必須透徹理解業(yè)務現(xiàn)狀與業(yè)務目標诊胞，考慮如何結(jié)合系統(tǒng)改造迈着、優(yōu)化業(yè)務流程和模式裕菠。此階段可以由一個高級PM帶領幾個初級PM完成奴潘。最好邀請技術負責人一起參與萤彩，有利于技術人員提前理解業(yè)務雀扶，為技術選型和方案設計做好準備愚墓。此外浪册，技術人員具備更好的抽象能力村象，深入理解業(yè)務躁劣，可以讓技術負責人協(xié)助PM共同完成整體方案設計和細節(jié)方案設計账忘。

1****鳖擒、業(yè)務調(diào)研的方法

理解業(yè)務最好的方法蒋荚，是輪崗參與業(yè)務環(huán)節(jié)圆裕。此外更加便捷快速的方法，是調(diào)研訪談。調(diào)研之前最好對業(yè)務能有大體的認知诞吱，安排好訪談的對象房维，提前準備好問題咙俩，讓訪談更加高效阿趁。以下是針對分銷業(yè)務的訪談計劃和調(diào)研表脖阵。

主持人員：產(chǎn)品經(jīng)理呜呐、研發(fā)經(jīng)理

調(diào)研對象：業(yè)務負責人卵史、一線主管以躯、一線業(yè)務人員忧设、合作伙伴

調(diào)研方式：

? 訪談

? 數(shù)據(jù)分析

調(diào)研目標：

? 了解業(yè)務模式和業(yè)務特點

? 了解業(yè)務目標和業(yè)務規(guī)劃

? 了解當前業(yè)務運轉(zhuǎn)方式

? 挖掘當前問題與痛點

image

** 2****、業(yè)務調(diào)研總結(jié)**

** 組織架構**

通過調(diào)研谨垃，理清最基本的業(yè)務組織架構圖，通過組織架構圖理解管理體系和職能單元的設計匙隔，以及后續(xù)規(guī)劃纷责。

image

業(yè)務目標對關鍵業(yè)務指標和目標需要有相應梳理。

image

業(yè)務流程

通過調(diào)研喂柒，梳理出目前的業(yè)務運作流程湃番，如下圖吠撮。

image

可以看出，目前業(yè)務開展以手工作業(yè)為主鞋诗。下單配送環(huán)節(jié)依托于公司已有的系統(tǒng)實現(xiàn)削彬。

問題梳理

基于目前手工作業(yè)流程融痛，整理出如下業(yè)務問題。

• 手工下單容易出錯沛励，效率低目派；
• 生鮮實時變價址貌，每次下單要根據(jù)折扣表手工計算價格遍蟋；
• 無法實現(xiàn)客戶總部集采虚青，大區(qū)集采，城市集采，門店自采等混合采購模式淆院；
• 不支持特殊分揀土辩、配送要求；
• 賬期客戶不能及時控制回款進度和賬期風險启涯；
• 對賬和開票工作復雜逝嚎，大量數(shù)據(jù)表處理，容易出錯挽铁；
• 當前流程一個運營專員只能跟進維護5個左右客戶叽掘，每日處理10筆訂單更扁，人效極低；

3****膛薛、基于業(yè)務調(diào)研的核心訴求分析

基于整體調(diào)研結(jié)論雅任，總結(jié)出分銷系統(tǒng)解決業(yè)務難題的核心訴求如下沪么。

• 客戶自主下單（高優(yōu)）；
• 系統(tǒng)自動定價（高優(yōu)）哭当；
• 支持客戶多門店分別定價與下單（高優(yōu)）；
• 對賬報表（高優(yōu)）冗澈；
• 運營人員聚焦參數(shù)設置钦勘、審核和異常問題跟進（高優(yōu)）；
• 運營工作要下放到各城市分部（中優(yōu)）亚亲；
• 支持賬期和預付款模式（低優(yōu)）彻采；
• 系統(tǒng)實現(xiàn)賬期風控（低優(yōu)）捌归；

我們將業(yè)務主鏈路確定為高優(yōu)訴求肛响，將擴展功能或針對部分客戶的小眾功能，以及風控功能列為低優(yōu)惜索，和業(yè)務達成一致特笋，一期項目聚焦核心流程的實現(xiàn)。

4****巾兆、業(yè)務主流程設計

經(jīng)過充分的溝通猎物，設計出結(jié)合系統(tǒng)支持的核心業(yè)務流程。其中角塑，涉及到客戶開發(fā)蔫磨、合同審核等前置流程，依然通過線下處理完成圃伶，未來考慮實現(xiàn)分銷業(yè)務的OCRM系統(tǒng)進行支持堤如，本次項目暫不考慮。

創(chuàng)建一套系統(tǒng)或平臺窒朋，支持客戶簽約后的賬號管理搀罢、價格管理、自主下單等功能炼邀。

image

** 三魄揉、系統(tǒng)整體方案設計**

完成業(yè)務調(diào)研后亏娜，進入系統(tǒng)整體方案設計環(huán)節(jié)蕴坪。該環(huán)節(jié)需要由經(jīng)驗豐富的PM以及公司的架構師一起探討完成，因為方案涉及到和公司現(xiàn)有應用架構融合夹抗，還需要經(jīng)過產(chǎn)品委員會或架構組的評審和確認杰标。

** 1****兵怯、系統(tǒng)定位**

基于對業(yè)務的分析，考慮通過實現(xiàn)3套獨立子系統(tǒng)來支持分銷業(yè)務腔剂。

分銷商城前臺（H5）：分銷客戶的下單工具

客戶管理后臺（PC）：分銷客戶的子賬號管理媒区、門店管理及業(yè)務輔助工具

運營管理后臺（PC）：分銷業(yè)務部門對客戶及商品定價管理的業(yè)務支持工具

首先，客戶希望能有一個便捷快速下單的工具掸犬，所以需要有一個手機版商城C端袜漩。考慮到投入產(chǎn)出比湾碎，通過H5來實現(xiàn)宙攻，具有獨立域名，外網(wǎng)可訪問介褥。

其次座掘，需要有一套方便操作的管理后臺，因為涉及到大量的商品編輯處理柔滔，賬號溢陪、門店管理等功能，所以考慮PC版本實現(xiàn)睛廊，暫不支持手機版形真。

最后，考慮到公司運營和客戶管理員的管理訴求不盡相同超全，操作功能和頁面差異較大咆霜，所以決定將管理后臺拆解為兩個獨立的系統(tǒng)，給客戶管理員使用的客戶管理后臺卵迂，具備獨立域名裕便，外網(wǎng)可訪問；給公司管理人員和運營人員使用的運營管理后臺见咒，具備獨立域名偿衰，僅限內(nèi)網(wǎng)訪問。

設計業(yè)務系統(tǒng)常見的問題改览，是為了圖省事下翎，把所有業(yè)務單元的功能糅合到一個系統(tǒng)中實現(xiàn)，造成管理的混亂宝当，尤其是系統(tǒng)維護的混亂视事。一般來講，系統(tǒng)的抽象要結(jié)合業(yè)務完成庆揩，獨立的業(yè)務職能單元俐东，要有各自獨立的系統(tǒng)來配合使用跌穗。如果業(yè)務部門之間邊界模糊，權責界定不清虏辫，也會導致系統(tǒng)之間存在模糊性蚌吸。

清晰的系統(tǒng)定位，并劃清邊界砌庄，可以讓彼此具備足夠的獨立性羹唠，是系統(tǒng)靈活性和可擴展性的基本前提。

** 2****娄昆、整體架構設計**

現(xiàn)在佩微，需要考慮分銷平臺的三個子系統(tǒng)，如何與公司的整體應用架構融合問題萌焰。公司經(jīng)過多年發(fā)展哺眯，系統(tǒng)架構體系已經(jīng)非常完備，大量公共組建和模塊可以復用杆怕，這樣就減輕了新平臺的實現(xiàn)成本和難度族购。分銷平臺只需要聚焦自己業(yè)務特殊獨立的地方，其他公共組建和模塊復用已有系統(tǒng)即可陵珍。

關于如何理解公司應用架構圖寝杖，可參考本人之前的文章《從一個故事說起，談談企業(yè)應用架構的演變史》互纯。

我們將確定的三個子系統(tǒng)瑟幕，繪入簡化版的公司整體應用架構圖，如下留潦。

image

深綠色部分是分銷平臺的三個獨立子系統(tǒng)只盹，墨綠色部分是涉及打通和復用的已有系統(tǒng)。

電商是公司的主營業(yè)務兔院，有成熟的訂單體系和倉配體系殖卑，分銷業(yè)務的獨特性在于前置客戶管理維護，下單后的分揀配送業(yè)務流程都一樣坊萝，所以分銷商城的訂單中心直接復用已有訂單中心孵稽，訂單寫入后續(xù)的處理流程完全不變，只需要訂單中心稍作改造即可支持十偶，這樣也可以保證整個訂單臺賬菩鲜、財務、倉儲惦积、配送基本都不需要重寫或改造接校。另外分銷平臺的商品中心復用已有商品中心SKU數(shù)據(jù)，只是價格管理模塊部分需要新做一套獨立的狮崩，以支持特殊報價業(yè)務蛛勉。

分銷業(yè)務的賬戶體系鹿寻、權限管理體系、在線支付董习，都利用已有系統(tǒng)實現(xiàn)烈和，其中賬戶體系要做改造爱只，支持子母賬號管理皿淋，在線支付完全復用即可。

客戶資料的存儲恬试，利用已有的客戶主數(shù)據(jù)（MDM）實現(xiàn)窝趣，MDM改造較大，要新做一套企業(yè)客戶數(shù)據(jù)模型训柴。雖然是新做哑舒，但是在架構上，必須將客戶資料作為主數(shù)據(jù)來建設幻馁，統(tǒng)一管理維護洗鸵。

最后一個問題，既然公司已經(jīng)有C端商城仗嗦，為什么要單獨再做一套針對分銷客戶的C端商城膘滨？經(jīng)過分析評估，兩套商城整體區(qū)別較大稀拐，如果對原有商城進行改造支持分銷業(yè)務火邓，第一工時投入比新做一套還要大，第二會影響主營業(yè)務系統(tǒng)的健壯性德撬，因此最終決定新做C端商城支持分銷業(yè)務铲咨。

** 3****、功能抽象**

基于對業(yè)務的分析蜓洪，以及三套系統(tǒng)的定位纤勒，可以抽象并繪制完整的系統(tǒng)功能藍圖。

image

功能模塊圖隆檀，是對業(yè)務訴求系統(tǒng)化設計的進一步高度抽象摇天。模塊的設計，要體現(xiàn)出同一個業(yè)務職能單元中不同業(yè)務場景和操作的集合刚操，模塊也代表了系統(tǒng)中的一二級導航菜單的設計闸翅。常見的問題，是設計人員對模塊設計的隨意和混亂菊霜，以及后來新增功能的隨意擺放坚冀，會造成用戶使用系統(tǒng)時產(chǎn)生困惑，同時還會導致開發(fā)人員編碼設計的混亂鉴逞。

功能模塊圖记某，代表了設計師對業(yè)務和系統(tǒng)本質(zhì)的理解和提煉司训，包含了對業(yè)務、系統(tǒng)未來發(fā)展的展望液南。我們常說壳猜，系統(tǒng)建設要有規(guī)劃和節(jié)奏，實際上功能模塊圖就是一幅遠景規(guī)劃藍圖滑凉，是系統(tǒng)的骨架统扳，決定了系統(tǒng)的整體結(jié)構，結(jié)合業(yè)務需求畅姊，每一個具體功能的實現(xiàn)咒钟，都是在對骨架不斷地填充血肉，讓他更真實若未，更立體朱嘴，更豐富。

隨著業(yè)務的開展粗合，變化萍嬉，功能模塊圖可能會有新的規(guī)劃和調(diào)整，但如果業(yè)務單元的本質(zhì)和模式?jīng)]有變化隙疚，功能模塊圖不應該出現(xiàn)結(jié)構性的調(diào)整和改動壤追。

4****、演進藍圖

我們已經(jīng)繪制了系統(tǒng)的功能模塊圖甚淡，體現(xiàn)了業(yè)務和系統(tǒng)規(guī)劃的脈絡大诸，現(xiàn)在，讓我們開始研究這套“體系”贯卦，大概需要幾期實現(xiàn)资柔，每期實現(xiàn)的側(cè)重點是什么，也就是常說的演進藍圖撵割，Roadmap贿堰。

image

白色部分，是一期的項目范圍啡彬，聚焦解決最基本的業(yè)務流程線上化問題羹与，以及最痛的痛點，例如對賬功能庶灿。一期功能有一個原則纵搁，凡是可以手工處理和解決的問題，都不做系統(tǒng)支持往踢。所以腾誉，類似于“報表”，可以定期跑sql實現(xiàn)；類似于“價格系數(shù)設置”利职，考慮到維護頻率低趣效，可以由RD在后臺改數(shù)據(jù)庫完成；類似于“搜索猪贪、推薦”跷敬，并不影響客戶下單，因為根據(jù)調(diào)研目前每個客戶維護的最多sku數(shù)量只有二十個热押，沒有搜索功能并不會嚴重影響客戶下單效率西傀。

綠色部分，是二期的項目范圍楞黄，二期將解決部分特殊業(yè)務剛需的訴求池凄，例如要支持“預付款”模式，“賬期”模式鬼廓，“發(fā)票管理”，如果時間允許致盟，可以一并實現(xiàn)若干報表查詢功能碎税。

藍色部分，是三期的項目范圍馏锡，三期將聚焦風險控制雷蹂，并強化運營功能。一般來講杯道，很多互聯(lián)網(wǎng)公司初期會先跑業(yè)務匪煌，走流水，驗證可行性党巾，成本和風險控制并不是特別在意萎庭，當業(yè)務具備一定規(guī)模時，則必須引入系統(tǒng)風控機制齿拂，做到事前驳规、事中、事后的風險控制署海。此外吗购，基于本案例B2B業(yè)務的特點，設計中并沒有考慮太多的C端功能砸狞。實際上C端只需要保證客戶能夠方便下單捻勉，并做一些很粗的運營、通知即可刀森。

四踱启、系統(tǒng)細節(jié)方案設計

系統(tǒng)整體架構和藍圖設計完成后，進入細節(jié)方案設計環(huán)節(jié)。建模部分建議由高級PM和技術負責人共同完成禽捆，界面笙什、權限設計可以由高級PM帶領初級PM共同完成。

1****胚想、實體建模

實體建模是細節(jié)設計中最難琐凭，也是最重要的環(huán)節(jié)。實體建模代表將客觀世界的對象浊服，抽象成結(jié)構化的描述统屈。實體建模有問題，會導致后續(xù)業(yè)務和系統(tǒng)完全喪失擴展性和靈活性牙躺，甚至會很快就無法支持業(yè)務愁憔，需要推倒重做。

實體建模實際上是數(shù)據(jù)庫設計中最重要的部分孽拷，會影響數(shù)據(jù)庫表結(jié)構的設計吨掌，但更多體現(xiàn)了對業(yè)務本質(zhì)的理解和認知。很多產(chǎn)品經(jīng)理常常忽略實體建模脓恕，只關注功能界面設計膜宋，最終會陷入邏輯的混亂和旋渦中。

只要模型清晰合理炼幔，功能設計秋茫、界面設計都是水到渠成的事。我們將結(jié)合案例乃秀，以客戶模型設計為起點肛著，詳細闡述實體建模的設計思路。

理想化的客戶模型

首先回顧客戶訴求跺讯。目前的分銷客戶中枢贿，有比較大型的集團客戶，下設若干省市機構和庫房抬吟、門店萨咕。調(diào)研時，集團客戶有如下訴求：

• 上海是中央倉庫火本，需要由上海采購員賬號下單配送到上海中央倉庫危队；
• 廣州天河區(qū)是中央倉庫，需要由天河采購員下單配送到天河中央倉庫钙畔；
• 廣州其他區(qū)是門店自采茫陆，需要由各門店采購員下單配送到各門店；
• 廣東省需要有一個高級別采購員賬號擎析，能夠幫廣東各倉庫和門店代下單簿盅；

以上訴求挥下，是業(yè)務系統(tǒng)建設中，最經(jīng)典常見的樹形組織機構管理訴求桨醋。不論是公司棚瘟，還是客戶，作為企業(yè)喜最，都有多層級管理的要求偎蘸，希望軟件系統(tǒng)能夠支持多層級業(yè)務體系。

多層級機構管理瞬内，通常使用組織機構樹實現(xiàn)迷雪，在一顆樹上繪制出業(yè)務的管理層級體系。我們將分銷業(yè)務作為組織機構管理樹的根節(jié)點虫蝶，客戶屬于子樹章咧，樹形結(jié)構可以體現(xiàn)出客戶的行政管理層級結(jié)構。將賬號和門店（收貨對象能真，可以是中央倉赁严，也可以是店鋪）作為葉子，掛在機構節(jié)點下舟陆。賬號管理的數(shù)據(jù)范疇（包括能給哪些門店下單误澳，能查看哪些門店的數(shù)據(jù)），可以遍歷所在節(jié)點的子樹來實現(xiàn)秦躯。繪制示意圖如下。

image

通過組織機構樹裆装，結(jié)合功能權限配置踱承，可以實現(xiàn)集團客戶的管理訴求。上圖中實際上存在三個對象哨免，組織機構節(jié)點茎活，賬號，門店琢唾。通過實體建模ER圖载荔，可以描述出三者的關系，如下采桃。

image

每個機構都有一個“上級機構”字段懒熙，通過該字段描述的關聯(lián)關系，可以繪制出完整的組織機構樹普办。每個賬號或門店工扎，只允許隸屬于一個組織機構節(jié)點，每個門店下可以維護多個收貨人衔蹲。

實體建模的過程肢娘，就是將業(yè)務對象抽象，并描述之間的對應關系。例如以上ER圖橱健，看似簡單而钞，但卻是對組織機構樹以及賬號、門店管理體系的高度抽象拘荡。如果實現(xiàn)以上模型臼节，可以支持任意靈活地集團客戶管理訴求。

簡化版的客戶模型

實現(xiàn)組織樹模型俱病，開發(fā)復雜度很高官疲。經(jīng)過和開發(fā)、業(yè)務溝通亮隙，最終決定采用一套簡版的客戶模型來支持一期業(yè)務途凫，該簡版模型在需要時完全可以升級到理想版的客戶模型。

首先溢吻，和業(yè)務以及客戶溝通確認维费，一期暫不支持復雜的行政層級管理，只需要給客戶實現(xiàn)若干子賬號可以管理若干門店即可促王，示意圖如下犀盟。

image

這樣系統(tǒng)只需要實現(xiàn)一顆非常簡單的樹，每個客戶只有一個根節(jié)點而沒有子節(jié)點蝇狼，以便業(yè)務系統(tǒng)開發(fā)時不需要編寫大量的遍歷算法阅畴，大大降低了開發(fā)難度。

根據(jù)上述規(guī)則迅耘，將模型簡化如下贱枣。

image

更豐富一些的客戶模型

業(yè)務需求中很重要的一條梯投，能夠針對每個客戶每個門店的個性報價命辖，設置不同的系數(shù)表况毅，結(jié)合時價動態(tài)計算商品價格。這里涉及到幾個新的對象尔艇，系數(shù)表尔许，報價單，為了讓管理可控终娃，系數(shù)表是全公司通用的多套參數(shù)集合味廊，包括了商品和價格系數(shù)，給每個門店關聯(lián)并且只能關聯(lián)一個有效的報價單棠耕，報價單關聯(lián)系數(shù)表余佛，以保證運營人員只需要調(diào)整一次系數(shù)表，就能刷新到所有需要修改的門店的價格表窍荧。數(shù)據(jù)模型設計如下辉巡。

image

該模型體現(xiàn)了真實世界針對門店單獨報價的場景，同時也體現(xiàn)了價格系數(shù)表的設計思路蕊退。

理清了賬號郊楣、門店、機構瓤荔、報價單净蚤、價格系數(shù)表之間的關系，功能設計都是水到渠成的事情输硝。如果沒有梳理清楚這些關系今瀑，功能設計、界面設計時必然是一頭霧水点把，漏洞百出放椰。

建模錯誤會導致擴展的災難

最后，我們來看一個建模錯誤導致災難的例子愉粤。如果我們將上圖數(shù)據(jù)模型中，賬號和門店的對應關系調(diào)整成一對多拿撩，如下衣厘。

image

設計人員可能會認為，目前的業(yè)務訴求很明確压恒，一個門店只能被一個賬號管理影暴，所以賬號和門店被設計成一對多關系。

如果有一天探赫，客戶明確并要求必須支持一個門店被多個賬號管理型宙，也就是要實現(xiàn)賬號和門店多對多的設計。實現(xiàn)此訴求伦吠，難度將非常非常大妆兑，因為從數(shù)據(jù)底層魂拦，到前端功能實現(xiàn)，都認為是一對多結(jié)構搁嗓，如果要改成多對多芯勘，首先底層數(shù)據(jù)庫結(jié)構得調(diào)整，所有歷史數(shù)據(jù)要處理腺逛，其次荷愕，基本上所有涉及到讀取賬號和門店關系的功能代碼需要全部重寫，看似簡單的一個改造棍矛，會造成一場災難安疗。

設計人員應該在設計之初，就要做好設計的預判够委。即便早期業(yè)務訴求是一對多荐类，但是模型要按照多對多設計，因為這是在現(xiàn)實世界中合理的一種邏輯存在慨绳。即便早期沒有多對多管理的訴求掉冶，但只要模型和數(shù)據(jù)底層設計好，后續(xù)再調(diào)整會簡單很多脐雪。

那么問題來了厌小，是不是所有對象的關系，都應該設計成多對多就行了呢战秋？也不對璧亚，比如門店和訂單的關系，只可能是一對多脂信，不可能是多對多癣蟋，一個訂單只能是一個門店提交的，現(xiàn)實世界中不存在門店和訂單多對多的邏輯關系狰闪。

建模的難點和重點疯搅，就是將現(xiàn)實世界抽象成對象，描述其關聯(lián)關系埋泵。如果這些對象和關系沒有梳理清楚幔欧，流程、界面的設計都會是一筆糊涂賬丽声。

2****礁蔗、用戶角色設計和流程圖

在整個方案中，我們設計了4個角色雁社，來支持業(yè)務浴井。

電商公司分銷業(yè)務部

• 分銷管理員 – 負責業(yè)務稽查，審核霉撵，分公司賬號的管理維護
• 分銷運營 – 負責分公司客戶的賬號維護磺浙，報價管理

客戶

• 客戶管理員 – 負責下單賬號和門店的管理洪囤、維護，訂單查詢屠缭，對賬結(jié)算
• 客戶采購 – 負責給門店下單

角色的設計箍鼓，取決于業(yè)務對權責的劃分。用戶角色設計完成后呵曹，可以繪制更加詳細的款咖，基于系統(tǒng)的流程圖，如下奄喂。

image

流程圖（以及頁面流轉(zhuǎn)圖）是所有軟件界面設計的基本前提铐殃，清晰的流程圖和各種異常情況的分支描述，可以讓后續(xù)的界面設計事半功倍跨新。如果沒有清晰地流程圖富腊，界面設計絕對會陷入混亂。

** 3****域帐、界面設計**

建模合理赘被，流程清晰，界面設計會變的非常簡單肖揣。網(wǎng)上關于界面設計的文章也非常多民假，方法論也很多，比如尼爾森十大可用性原則龙优，讀者可自行查閱羊异，本文不再贅述，這里只講幾個建議彤断。

模仿是最好的設計

研究并借鑒成熟的軟件系統(tǒng)的設計野舶，可以提升設計能力，少走彎路宰衙。網(wǎng)上有很多免費開放試用的系統(tǒng)平道，都可以用來參考，比如GoogleAnalytics供炼，百度統(tǒng)計巢掺，管家婆云ERP，SalesForce等。結(jié)合你設計的軟件形態(tài)妒牙，找到行業(yè)內(nèi)相似的SASS軟件懈凹，借鑒并參考其排版、布局著洼，可以提高設計效率與合理性。

拒絕花哨的前端

業(yè)務系統(tǒng)，不需要花哨的前端疫蔓，不需要創(chuàng)意的控件含懊。有很多初入行的PM，喜歡在交互設計上做太多的發(fā)明創(chuàng)造衅胀，對于業(yè)務系統(tǒng)岔乔，價值不大，并且會增加研發(fā)的工作量滚躯。我曾經(jīng)見過一個業(yè)務系統(tǒng)雏门，把其中的多選控件做的異常復雜，多選框中隱含了其他的交互形態(tài)掸掏，導致前端需要耗費大量的精力去定制開發(fā)實現(xiàn)茁影，實在沒有必要。選用準的控件方案丧凤，可以節(jié)約PM和前端的大量時間募闲。

什么叫標準的控件呢？MS Visio或Axure里提供的可以繪制的控件愿待，就是標準控件浩螺。不要在這些標準控件以外去發(fā)明創(chuàng)造控件！

對于復雜一點的報表和儀表盤設計仍侥，推薦兩個組件庫要出，一個是百度的ECharts，一個是Eclipse Birt访圃，里邊包含了大量經(jīng)典的設計方案厨幻，這兩者都是開源的，可以直接拿來用腿时。

** 4****况脆、權限設計**

權限設計，是業(yè)務系統(tǒng)設計中最重要的一部分批糟。權限設計代表了對整個業(yè)務體系崗位和流程的理解和拆解格了。

軟件系統(tǒng)的權限設計包含兩部分，功能權限和數(shù)據(jù)權限徽鼎。功能權限是指不同角色可以操作的界面盛末、按鈕等等，例如某一個角色在訂單查詢頁面能看到哪些字段否淤，能操作哪些按鈕悄但；數(shù)據(jù)權限是指不同角色在同一頁面中看到的數(shù)據(jù)范圍，例如分公司管理員在訂單查詢頁面能看到分公司的所有訂單石抡，而區(qū)域主管只能看到所在區(qū)域的訂單檐嚣。

功能權限設計的經(jīng)典方法論是RBAC（Role Based AccessControl），描述了一套用戶啰扛、角色嚎京、權限組的設計理念嗡贺，簡單的可以抽象為以下實體關系圖。該理論具體的講解鞍帝，讀者可在網(wǎng)絡上自行查閱诫睬，請讀者理解RBAC的數(shù)據(jù)模型圖，可以看出帕涌，軟件系統(tǒng)的設計摄凡，即便是權限管理體系設計，最終也都會歸結(jié)抽象到數(shù)據(jù)模型的設計宵膨。由此可見架谎，抽象建模能力，是PM必須掌握的核心技能辟躏。

image

我們將權限管理部分谷扣，進一步做一個延伸討論。

假設我們實現(xiàn)了前文提到的完整的組織機構樹捎琐，同時也有完善的權限控制體系会涎，此時，系統(tǒng)可以完美的支持各種復雜的業(yè)務場景訴求瑞凑。

我們在之前的角色設計中末秃，新增一個角色“客戶采購員2”，其中“客戶采購員2”和“客戶采購員1”的區(qū)別是籽御，前者的數(shù)據(jù)權限范圍练慕，是查詢用戶當前所在組織機構樹葉子上的數(shù)據(jù)，而后者能夠查詢用戶當前所在組織機構樹葉子技掏，以及葉子下邊所有子節(jié)點的數(shù)據(jù)铃将。

image

客戶的組織架構如下。

image

不同賬號哑梳，所能看到的數(shù)據(jù)權限范圍見下表劲阎。請讀者結(jié)合上圖和下表，自己做出判斷鸠真，賬號4能查看哪些門店的訂單數(shù)據(jù)悯仙。如果您理解了這個案例中隱含的邏輯，則掌握了業(yè)務系統(tǒng)權限管理體系的主要核心思想吠卷。

image

** 5****锡垄、技術方案與項目實施**

產(chǎn)出PRD以后祭隔，進入了技術設計和實施環(huán)節(jié)。當然，對于一套全新的系統(tǒng)，技術設計可能很早就已經(jīng)啟動程奠。再往后丈牢，就進入實施環(huán)節(jié)瞄沙，以及上線后的持續(xù)迭代和產(chǎn)品運營環(huán)節(jié)。以后有機會單獨介紹此部分話題距境。

** 六申尼、總結(jié)**

至此，我們結(jié)合一個實際案例垫桂，完整的介紹了一套系統(tǒng)從無到有的設計诬滩。介紹的重點是調(diào)研、架構后控、模塊空镜、建模、權限吴攒，對于交互舶斧、界面等細節(jié)一筆帶過。實際上泽台，文中已經(jīng)多次強調(diào)矾缓，并且讀者現(xiàn)在應該也有了充分的認識，抽象蜕依、流程样眠、建模才是業(yè)務系統(tǒng)設計的重點和核心友瘤，只有將業(yè)務最本質(zhì)的東西高度剝離并正確抽象辫秧，才能構建一套靈活強大的系統(tǒng)被丧。

對于一名后端產(chǎn)品經(jīng)理來講，以下經(jīng)驗和技能必不可可少柿究。

• 具備基本的商業(yè)、管理蝇摸、運營常識糕簿；
• 理解商業(yè)模式、業(yè)務目標蜂嗽、組織植旧、流程离唐；
• 理解公司的企業(yè)應用架構和系統(tǒng)現(xiàn)狀；
• 具備將客觀世界抽象成架構完沪、模塊覆积、模型的能力熟呛；

路漫漫其修遠，后端產(chǎn)品經(jīng)理的成長是一個厚積薄發(fā)的過程吗冤，需要長期的堅持椎瘟、積累、思考篷朵。希望本文能夠幫助讀者對系統(tǒng)的設計有一個大體的認知和理解婆排，并融入到工作中段只，形成更深層次的思考鉴扫。

作者：楊堃（微信號公眾號goYangKun）坪创，9年互聯(lián)網(wǎng)研發(fā)、產(chǎn)品設計經(jīng)驗柠掂，曾就職于傳統(tǒng)外資保險公司依沮，百度，現(xiàn)就職于vipkid宋渔。

COVER FROM :https://coffee.pmcaff.com/article/qVkVlRlQOm