[轉]從0到1教你設計業務系統

導讀

本文將以一個案例，向讀者逐步揭示一套業務系統從0到1的設計過程。重點講述架構、模型等業務系統最本質的設計精要。

一、業務系統設計概述

1****、什麼是業務系統

網際網路公司常常將產品方向分為兩類，C端和B端，C端主要是面向客戶和消費者的系統，B端的範圍則相對模糊，給供應商或商家使用的系統，給內部業務人員使用的系統，都統稱為B端系統。C端和B端系統建設的出發點和側重點完全不同。C端系統偏重使用者體驗，強調感性，持續的資料分析優化，同一個按鈕不同的擺放位置都要精心設計、論證，服務物件是個人；B端系統偏重流程、模組化，強調抽象和結構性，講究整體的規劃和體系設計，服務物件是組織和機構。

如果將B端系統進一步拆分，也可以分為兩類，第一類是商家端，常見於雙邊模式的平臺型網際網路公司，例如淘寶的賣家管理系統，美團的商家管理後臺；第二類是內部業務系統，支援企業經營、管理、業務運轉。

本文所說業務系統，指****B****端產品線中的企業內部業務系統。雖然B端系統也可以分為兩類，但因為都是面向業務的系統（Business），服務於組織而非個人，其設計思想和原理都是相同的，所以本文講解的內容可以應用於所有B端系統的設計場景。

常見的業務系統包括ERP（EnterpriseResource Planning），CRM（CustomerRelationship Management），SCM（Supply ChainManagement），WMS（WarehouseManagement System），TMS（TransportationManagement System），OA（Office Automation），HRM（Human ResourceManagement）等等。因為絕大多數網際網路公司都有獨特的業務模式，所以很多時候類似於CRM、WMS、TMS這類系統都自主研發，OA、HRM這類系統由於業務模型區別不大，多數都會採購標準軟體。有些網際網路巨頭也會自主研發OA、HRM。習慣上，CRM、WMS這類系統被稱為業務系統，OA、HRM這類系統被稱為內部協同軟體，但兩類系統之間也並沒有非常清晰的界定。

如果從軟體學的角度來看，所有軟體系統分為兩類，第一類是能夠實時產生業務資料的系統，叫做OLTP（Online TransactionProcessing）系統，第二類是對資料進行加工、處理、探查、挖掘、展現的系統，叫做OLAP（Online AnalyticalProcessing）系統，很顯然，業務系統屬於OLTP的範疇。當企業發展到一定階段，業務系統對企業的高效管理運轉具備不可替代的核心作用。例如，當一家公司只有幾個銷售人員時，客戶資料用Excel即可管理。當銷售發展到上千人時，必須通過一套OCRM系統進行管理。

總體來講，業務系統對企業具有四點價值：提升管控能力、控制經營風險、降低運營成本、提升銷售業績。很多時候，業務系統建設好壞決定了企業的核心競爭力，例如外賣公司之間的競爭，配送員的效率是業務成敗的決定因素之一，而配送員的效率取決於TMS系統建設的好壞。當然，TMS系統建設的好壞，包括了軟體系統本身，以及配套落地的管理運營體系的執行。

2****、為什麼要學習設計業務系統

商業模式的創新是網際網路行業最大的特點，商業模式的創新會帶來業務模式的創新，業務模式的創新會帶來運營、管理機制的創新。多數情況下，網際網路公司獨特的業務模式，導致無法採買市面上成熟的標準軟體來支援業務，而作為技術驅動型企業，自主研發系統支援新業務成為不二的選擇。

例如，滴滴公司，是無法在市面上找到一款成熟的司機管理運營軟體的，要麼找外包公司開發，要麼自主研發，自主研發似乎更靠譜一些，這時，就需要有專業經驗的資深產品經理，結合業務，從無到有設計一套司機（甚至是針對司機運營的機構）管理系統。

再例如，美團有大量的地推人員和客戶需要管理，傳統的OCRM軟體根本無法支援美團這種強POI訴求的客戶管理，因為業務模式特殊，即便採購成熟的OCRM做定製化開發，也難以使用。所以，只能靠自主研發一套全新的基於獨特業務模式的OCRM來支援業務。

由此可以看出，網際網路企業創新的本質，決定了必須有一批優秀的業務系統設計人員，能夠結合公司特殊業務訴求，快速、合理的設計配套系統，並落地支援業務。業務系統的產品經理，要具備企業經營管理、軟體系統設計的多方面經驗和知識儲備，才能設計合理的業務系統。

3****、業務系統設計的流程

業務系統從無到有的設計，是有一套標準正規化可以遵循的。實際上，隨便一套《軟體工程學》教程，講述的都是業務系統的設計，但是軟體工程已經不滿足當前時代對專業人員的培養和要求。網際網路時代下的軟體設計，已經被拆分成多個細分職能，產品經理參與制定業務，設計應用功能；工程師負責技術架構，編碼實施；而在傳統軟體工程中，這兩項職能由一個角色承擔。如今的現實情況是，軟體設計人員更多的參與到了業務決策制定，軟體研發人員越來越遠離業務，只聚焦於技術。

即便如此，軟體設計中的經典思路、方法論，是沒有改變的。業務系統的產品經理，必須理解軟體工程學中的部分核心要素，才能真正設計出靠譜的系統。

一般來講，一套業務系統從0到1的構建，需要經歷如下環節。

業務方案設計

PM和業務負責人一起梳理、制定業務流程、制度、機制，理解業務的問題點，並確定軟體系統解決方案。

系統整體方案設計

PM結合業務訴求與目標，完成系統概要設計，包括界定業務、系統的邊界，系統功能的抽象和演進藍圖，整體應用架構的設計，如何與公司已有系統拼接、互動。

系統細節方案設計

PM完成細節方案的所有設計，包括建模、角色、介面、許可權等。其中建模是最難的部分，建模好壞決定了系統未來的靈活性、可擴充套件性。建模要求對業務的全面理解，極強的抽象歸納能力。

實施驗收

PM對最終專案落地負責，系統上線後要展開持續的迭代優化，深度參與產品運營，資料分析等。

如果是從無到有設計系統，以上環節必須全面貫徹，尤其是架構設計和模型設計，是重中之重。

4****、案例：某電商公司的渠道銷售系統設計

本文將結合一個虛擬的案例，逐步論述，幫助讀者理解以上所有的設計環節。

背景：

某電商企業A公司，成立5年，主營生鮮商品，以C端客戶為主，業務穩定，系統建設成熟。

訴求：

公司在三個月前嘗試開展分銷業務，成立銷售團隊，開發分銷商合作伙伴。業務試點在北京、上海開展，三個月以來發展迅速，現急需配套的軟體系統提升業務效率，控制經營風險。

評估：

經公司管理層評估，目前分銷業務月流水五十萬，以月增長率20%的速度快速發展。在高速發展中若干流程、管理、風險問題突出，公司決定投入研發資源建設軟體系統，支撐業務發展。

任務：

公司要求在2~3個月的時間內搭建出一套可以支撐分銷業務2年高速發展的軟體系統，提升效率，控制經營風險。專案期間CTO全力提供人力資源支援。

5****、工作計劃

作為專案負責人，某高階PM接到任務後，首先要理清工作思路，拆解任務，制定時間計劃。只有嚴格遵循時間計劃執行工作，才能保證整體工作有序展開，如期落地。根據經驗和初步判斷，產品經理制定了粗略的工作計劃表如下。

時間緊，任務重，PM需要立即開展行動。當然，計劃表中的研發週期，純粹是一個粗拍的時間，具體實施週期要結合一期專案範圍，以及人力投入，在立項時細化。

二、業務調研與業務方案

設計系統之前，必須透徹理解業務現狀與業務目標，考慮如何結合系統改造、優化業務流程和模式。此階段可以由一個高階PM帶領幾個初級PM完成。最好邀請技術負責人一起參與，有利於技術人員提前理解業務，為技術選型和方案設計做好準備。此外，技術人員具備更好的抽象能力，深入理解業務，可以讓技術負責人協助PM共同完成整體方案設計和細節方案設計。

1****、業務調研的方法

理解業務最好的方法，是輪崗參與業務環節。此外更加便捷快速的方法，是調研訪談。調研之前最好對業務能有大體的認知，安排好訪談的物件，提前準備好問題，讓訪談更加高效。以下是針對分銷業務的訪談計劃和調研表。

主持人員：產品經理、研發經理

調研物件：業務負責人、一線主管、一線業務人員、合作伙伴

調研方式：

• 訪談

• 資料分析

調研目標：

• 瞭解業務模式和業務特點

• 瞭解業務目標和業務規劃

• 瞭解當前業務運轉方式

• 挖掘當前問題與痛點

** 2****、業務調研總結**

** 組織架構**

通過調研，理清最基本的業務組織架構圖，通過組織架構圖理解管理體系和職能單元的設計，以及後續規劃。

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

業務流程

通過調研，梳理出目前的業務運作流程，如下圖。

可以看出，目前業務開展以手工作業為主。下單配送環節依託於公司已有的系統實現。

問題梳理

基於目前手工作業流程，整理出如下業務問題。

• 手工下單容易出錯，效率低；
• 生鮮實時變價，每次下單要根據折扣表手工計算價格；
• 無法實現客戶總部集採，大區集採，城市集採，門店自採等混合採購模式；
• 不支援特殊分揀、配送要求；
• 賬期客戶不能及時控制回款進度和賬期風險；
• 對賬和開票工作複雜，大量資料表處理，容易出錯；
• 當前流程一個運營專員只能跟進維護5個左右客戶，每日處理10筆訂單，人效極低；

3****、基於業務調研的核心訴求分析

基於整體調研結論，總結出分銷系統解決業務難題的核心訴求如下。

• 客戶自主下單（高優）；
• 系統自動定價（高優）；
• 支援客戶多門店分別定價與下單（高優）；
• 對賬報表（高優）；
• 運營人員聚焦引數設定、稽核和異常問題跟進（高優）；
• 運營工作要下放到各城市分部（中優）；
• 支援賬期和預付款模式（低優）；
• 系統實現賬期風控（低優）；

我們將業務主鏈路確定為高優訴求，將擴充套件功能或針對部分客戶的小眾功能，以及風控功能列為低優，和業務達成一致，一期專案聚焦核心流程的實現。

4****、業務主流程設計

經過充分的溝通，設計出結合系統支援的核心業務流程。其中，涉及到客戶開發、合同稽核等前置流程，依然通過線下處理完成，未來考慮實現分銷業務的OCRM系統進行支援，本次專案暫不考慮。

建立一套系統或平臺，支援客戶簽約後的賬號管理、價格管理、自主下單等功能。

** 三、系統整體方案設計**

完成業務調研後，進入系統整體方案設計環節。該環節需要由經驗豐富的PM以及公司的架構師一起探討完成，因為方案涉及到和公司現有應用架構融合，還需要經過產品委員會或架構組的評審和確認。

** 1****、系統定位**

基於對業務的分析，考慮通過實現3套獨立子系統來支援分銷業務。

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

客戶管理後臺（PC）：分銷客戶的子賬號管理、門店管理及業務輔助工具

運營管理後臺（PC）：分銷業務部門對客戶及商品定價管理的業務支援工具

首先，客戶希望能有一個便捷快速下單的工具，所以需要有一個手機版商城C端。考慮到投入產出比，通過H5來實現，具有獨立域名，外網可訪問。

其次，需要有一套方便操作的管理後臺，因為涉及到大量的商品編輯處理，賬號、門店管理等功能，所以考慮PC版本實現，暫不支援手機版。

最後，考慮到公司運營和客戶管理員的管理訴求不盡相同，操作功能和頁面差異較大，所以決定將管理後臺拆解為兩個獨立的系統，給客戶管理員使用的客戶管理後臺，具備獨立域名，外網可訪問；給公司管理人員和運營人員使用的運營管理後臺，具備獨立域名，僅限內網訪問。

設計業務系統常見的問題，是為了圖省事，把所有業務單元的功能糅合到一個系統中實現，造成管理的混亂，尤其是系統維護的混亂。一般來講，系統的抽象要結合業務完成，獨立的業務職能單元，要有各自獨立的系統來配合使用。如果業務部門之間邊界模糊，權責界定不清，也會導致系統之間存在模糊性。

清晰的系統定位，並劃清邊界，可以讓彼此具備足夠的獨立性，是系統靈活性和可擴充套件性的基本前提。

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

現在，需要考慮分銷平臺的三個子系統，如何與公司的整體應用架構融合問題。公司經過多年發展，系統架構體系已經非常完備，大量公共組建和模組可以複用，這樣就減輕了新平臺的實現成本和難度。分銷平臺只需要聚焦自己業務特殊獨立的地方，其他公共組建和模組複用已有系統即可。

關於如何理解公司應用架構圖，可參考本人之前的文章《從一個故事說起，談談企業應用架構的演變史》。

我們將確定的三個子系統，繪入簡化版的公司整體應用架構圖，如下。

深綠色部分是分銷平臺的三個獨立子系統，墨綠色部分是涉及打通和複用的已有系統。

電商是公司的主營業務，有成熟的訂單體系和倉配體系，分銷業務的獨特性在於前置客戶管理維護，下單後的分揀配送業務流程都一樣，所以分銷商城的訂單中心直接複用已有訂單中心，訂單寫入後續的處理流程完全不變，只需要訂單中心稍作改造即可支援，這樣也可以保證整個訂單臺賬、財務、倉儲、配送基本都不需要重寫或改造。另外分銷平臺的商品中心複用已有商品中心SKU資料，只是價格管理模組部分需要新做一套獨立的，以支援特殊報價業務。

分銷業務的賬戶體系、許可權管理體系、線上支付，都利用已有系統實現，其中賬戶體系要做改造，支援子母賬號管理，線上支付完全複用即可。

客戶資料的儲存，利用已有的客戶主資料（MDM）實現，MDM改造較大，要新做一套企業客戶資料模型。雖然是新做，但是在架構上，必須將客戶資料作為主資料來建設，統一管理維護。

最後一個問題，既然公司已經有C端商城，為什麼要單獨再做一套針對分銷客戶的C端商城？經過分析評估，兩套商城整體區別較大，如果對原有商城進行改造支援分銷業務，第一工時投入比新做一套還要大，第二會影響主營業務系統的健壯性，因此最終決定新做C端商城支援分銷業務。

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

基於對業務的分析，以及三套系統的定位，可以抽象並繪製完整的系統功能藍圖。

功能模組圖，是對業務訴求系統化設計的進一步高度抽象。模組的設計，要體現出同一個業務職能單元中不同業務場景和操作的集合，模組也代表了系統中的一二級導航選單的設計。常見的問題，是設計人員對模組設計的隨意和混亂，以及後來新增功能的隨意擺放，會造成使用者使用系統時產生困惑，同時還會導致開發人員編碼設計的混亂。

功能模組圖，代表了設計師對業務和系統本質的理解和提煉，包含了對業務、系統未來發展的展望。我們常說，系統建設要有規劃和節奏，實際上功能模組圖就是一幅遠景規劃藍圖，是系統的骨架，決定了系統的整體結構，結合業務需求，每一個具體功能的實現，都是在對骨架不斷地填充血肉，讓他更真實，更立體，更豐富。

隨著業務的開展，變化，功能模組圖可能會有新的規劃和調整，但如果業務單元的本質和模式沒有變化，功能模組圖不應該出現結構性的調整和改動。

4****、演進藍圖

我們已經繪製了系統的功能模組圖，體現了業務和系統規劃的脈絡，現在，讓我們開始研究這套“體系”，大概需要幾期實現，每期實現的側重點是什麼，也就是常說的演進藍圖，Roadmap。

白色部分，是一期的專案範圍，聚焦解決最基本的業務流程線上化問題，以及最痛的痛點，例如對賬功能。一期功能有一個原則，凡是可以手工處理和解決的問題，都不做系統支援。所以，類似於“報表”，可以定期跑sql實現；類似於“價格係數設定”，考慮到維護頻率低，可以由RD在後臺改資料庫完成；類似於“搜尋、推薦”，並不影響客戶下單，因為根據調研目前每個客戶維護的最多sku數量只有二十個，沒有搜尋功能並不會嚴重影響客戶下單效率。

綠色部分，是二期的專案範圍，二期將解決部分特殊業務剛需的訴求，例如要支援“預付款”模式，“賬期”模式，“發票管理”，如果時間允許，可以一併實現若干報表查詢功能。

藍色部分，是三期的專案範圍，三期將聚焦風險控制，並強化運營功能。一般來講，很多網際網路公司初期會先跑業務，走流水，驗證可行性，成本和風險控制並不是特別在意，當業務具備一定規模時，則必須引入系統風控機制，做到事前、事中、事後的風險控制。此外，基於本案例B2B業務的特點，設計中並沒有考慮太多的C端功能。實際上C端只需要保證客戶能夠方便下單，並做一些很粗的運營、通知即可。

四、系統細節方案設計

系統整體架構和藍圖設計完成後，進入細節方案設計環節。建模部分建議由高階PM和技術負責人共同完成，介面、許可權設計可以由高階PM帶領初級PM共同完成。

1****、實體建模

實體建模是細節設計中最難，也是最重要的環節。實體建模代表將客觀世界的物件，抽象成結構化的描述。實體建模有問題，會導致後續業務和系統完全喪失擴充套件性和靈活性，甚至會很快就無法支援業務，需要推倒重做。

實體建模實際上是資料庫設計中最重要的部分，會影響資料庫表結構的設計，但更多體現了對業務本質的理解和認知。很多產品經理常常忽略實體建模，只關注功能介面設計，最終會陷入邏輯的混亂和旋渦中。

只要模型清晰合理，功能設計、介面設計都是水到渠成的事。我們將結合案例，以客戶模型設計為起點，詳細闡述實體建模的設計思路。

理想化的客戶模型

首先回顧客戶訴求。目前的分銷客戶中，有比較大型的集團客戶，下設若干省市機構和庫房、門店。調研時，集團客戶有如下訴求：

• 上海是中央倉庫，需要由上海採購員賬號下單配送到上海中央倉庫；
• 廣州天河區是中央倉庫，需要由天河採購員下單配送到天河中央倉庫；
• 廣州其他區是門店自採，需要由各門店採購員下單配送到各門店；
• 廣東省需要有一個高階別採購員賬號，能夠幫廣東各倉庫和門店代下單；

以上訴求，是業務系統建設中，最經典常見的樹形組織機構管理訴求。不論是公司，還是客戶，作為企業，都有多層級管理的要求，希望軟體系統能夠支援多層級業務體系。

多層級機構管理，通常使用組織機構樹實現，在一顆樹上繪製出業務的管理層級體系。我們將分銷業務作為組織機構管理樹的根節點，客戶屬於子樹，樹形結構可以體現出客戶的行政管理層級結構。將賬號和門店（收貨物件，可以是中央倉，也可以是店鋪）作為葉子，掛在機構節點下。賬號管理的資料範疇（包括能給哪些門店下單，能檢視哪些門店的資料），可以遍歷所在節點的子樹來實現。繪製示意圖如下。

通過組織機構樹，結合功能許可權配置，可以實現集團客戶的管理訴求。上圖中實際上存在三個物件，組織機構節點，賬號，門店。通過實體建模ER圖，可以描述出三者的關係，如下。

每個機構都有一個“上級機構”欄位，通過該欄位描述的關聯關係，可以繪製出完整的組織機構樹。每個賬號或門店，只允許隸屬於一個組織機構節點，每個門店下可以維護多個收貨人。

實體建模的過程，就是將業務物件抽象，並描述之間的對應關係。例如以上ER圖，看似簡單，但卻是對組織機構樹以及賬號、門店管理體系的高度抽象。如果實現以上模型，可以支援任意靈活地集團客戶管理訴求。

簡化版的客戶模型

實現組織樹模型，開發複雜度很高。經過和開發、業務溝通，最終決定採用一套簡版的客戶模型來支援一期業務，該簡版模型在需要時完全可以升級到理想版的客戶模型。

首先，和業務以及客戶溝通確認，一期暫不支援複雜的行政層級管理，只需要給客戶實現若干子賬號可以管理若干門店即可，示意圖如下。

這樣系統只需要實現一顆非常簡單的樹，每個客戶只有一個根節點而沒有子節點，以便業務系統開發時不需要編寫大量的遍歷演算法，大大降低了開發難度。

根據上述規則，將模型簡化如下。

仔細觀察可以發現，該模型與前一個模型相比，唯一的變化，是在賬號和門店兩個物件之間建立了關聯關係，其他結構不變。實際上這樣處理，保持了模型未來的擴充套件性。當未來需要全面實現組織機構管理時，將賬號、門店之間的對應關係打斷，在業務系統中實現遍歷演算法，以及組織樹管理維護功能即可，整個資料底層基本不需要調整。

更豐富一些的客戶模型

業務需求中很重要的一條，能夠針對每個客戶每個門店的個性報價，設定不同的係數表，結合時價動態計算商品價格。這裡涉及到幾個新的物件，係數表，報價單，為了讓管理可控，係數表是全公司通用的多套引數集合，包括了商品和價格係數，給每個門店關聯並且只能關聯一個有效的報價單，報價單關聯絡數表，以保證運營人員只需要調整一次係數表，就能重新整理到所有需要修改的門店的價格表。資料模型設計如下。

該模型體現了真實世界針對門店單獨報價的場景，同時也體現了價格係數表的設計思路。

理清了賬號、門店、機構、報價單、價格係數表之間的關係，功能設計都是水到渠成的事情。如果沒有梳理清楚這些關係，功能設計、介面設計時必然是一頭霧水，漏洞百出。

建模錯誤會導致擴充套件的災難

最後，我們來看一個建模錯誤導致災難的例子。如果我們將上圖資料模型中，賬號和門店的對應關係調整成一對多，如下。

設計人員可能會認為，目前的業務訴求很明確，一個門店只能被一個賬號管理，所以賬號和門店被設計成一對多關係。

如果有一天，客戶明確並要求必須支援一個門店被多個賬號管理，也就是要實現賬號和門店多對多的設計。實現此訴求，難度將非常非常大，因為從資料底層，到前端功能實現，都認為是一對多結構，如果要改成多對多，首先底層資料庫結構得調整，所有歷史資料要處理，其次，基本上所有涉及到讀取賬號和門店關係的功能程式碼需要全部重寫，看似簡單的一個改造，會造成一場災難。

設計人員應該在設計之初，就要做好設計的預判。即便早期業務訴求是一對多，但是模型要按照多對多設計，因為這是在現實世界中合理的一種邏輯存在。即便早期沒有多對多管理的訴求，但只要模型和資料底層設計好，後續再調整會簡單很多。

那麼問題來了，是不是所有物件的關係，都應該設計成多對多就行了呢？也不對，比如門店和訂單的關係，只可能是一對多，不可能是多對多，一個訂單隻能是一個門店提交的，現實世界中不存在門店和訂單多對多的邏輯關係。

建模的難點和重點，就是將現實世界抽象成物件，描述其關聯關係。如果這些物件和關係沒有梳理清楚，流程、介面的設計都會是一筆糊塗賬。

2****、使用者角色設計和流程圖

在整個方案中，我們設計了4個角色，來支援業務。

電商公司分銷業務部

• 分銷管理員 – 負責業務稽查，稽核，分公司賬號的管理維護
• 分銷運營 – 負責分公司客戶的賬號維護，報價管理

客戶

• 客戶管理員 – 負責下單賬號和門店的管理、維護，訂單查詢，對賬結算
• 客戶採購 – 負責給門店下單

角色的設計，取決於業務對權責的劃分。使用者角色設計完成後，可以繪製更加詳細的，基於系統的流程圖，如下。

流程圖（以及頁面流轉圖）是所有軟體介面設計的基本前提，清晰的流程圖和各種異常情況的分支描述，可以讓後續的介面設計事半功倍。如果沒有清晰地流程圖，介面設計絕對會陷入混亂。

** 3****、介面設計**

建模合理，流程清晰，介面設計會變的非常簡單。網上關於介面設計的文章也非常多，方法論也很多，比如尼爾森十大可用性原則，讀者可自行查閱，本文不再贅述，這裡只講幾個建議。

模仿是最好的設計

研究並借鑑成熟的軟體系統的設計，可以提升設計能力，少走彎路。網上有很多免費開放試用的系統，都可以用來參考，比如GoogleAnalytics，百度統計，管家婆雲ERP，SalesForce等。結合你設計的軟體形態，找到行業內相似的SASS軟體，借鑑並參考其排版、佈局，可以提高設計效率與合理性。

拒絕花哨的前端

業務系統，不需要花哨的前端，不需要創意的控制元件。有很多初入行的PM，喜歡在互動設計上做太多的發明創造，對於業務系統，價值不大，並且會增加研發的工作量。我曾經見過一個業務系統，把其中的多選控制元件做的異常複雜，多選框中隱含了其他的互動形態，導致前端需要耗費大量的精力去定製開發實現，實在沒有必要。選用準的控制元件方案，可以節約PM和前端的大量時間。

什麼叫標準的控制元件呢？MS Visio或Axure裡提供的可以繪製的控制元件，就是標準控制元件。不要在這些標準控制元件以外去發明創造控制元件！

對於複雜一點的報表和儀表盤設計，推薦兩個元件庫，一個是百度的ECharts，一個是Eclipse Birt，裡邊包含了大量經典的設計方案，這兩者都是開源的，可以直接拿來用。

** 4****、許可權設計**

許可權設計，是業務系統設計中最重要的一部分。許可權設計代表了對整個業務體系崗位和流程的理解和拆解。

軟體系統的許可權設計包含兩部分，功能許可權和資料許可權。功能許可權是指不同角色可以操作的介面、按鈕等等，例如某一個角色在訂單查詢頁面能看到哪些欄位，能操作哪些按鈕；資料許可權是指不同角色在同一頁面中看到的資料範圍，例如分公司管理員在訂單查詢頁面能看到分公司的所有訂單，而區域主管只能看到所在區域的訂單。

功能許可權設計的經典方法論是RBAC（Role Based AccessControl），描述了一套使用者、角色、許可權組的設計理念，簡單的可以抽象為以下實體關係圖。該理論具體的講解，讀者可在網路上自行查閱，請讀者理解RBAC的資料模型圖，可以看出，軟體系統的設計，即便是許可權管理體系設計，最終也都會歸結抽象到資料模型的設計。由此可見，抽象建模能力，是PM必須掌握的核心技能。

我們將許可權管理部分，進一步做一個延伸討論。

假設我們實現了前文提到的完整的組織機構樹，同時也有完善的許可權控制體系，此時，系統可以完美的支援各種複雜的業務場景訴求。

我們在之前的角色設計中，新增一個角色“客戶採購員2”，其中“客戶採購員2”和“客戶採購員1”的區別是，前者的資料許可權範圍，是查詢使用者當前所在組織機構樹葉子上的資料，而後者能夠查詢使用者當前所在組織機構樹葉子，以及葉子下邊所有子節點的資料。

客戶的組織架構如下。

不同賬號，所能看到的資料許可權範圍見下表。請讀者結合上圖和下表，自己做出判斷，賬號4能檢視哪些門店的訂單資料。如果您理解了這個案例中隱含的邏輯，則掌握了業務系統許可權管理體系的主要核心思想。

** 5****、技術方案與專案實施**

產出PRD以後，進入了技術設計和實施環節。當然，對於一套全新的系統，技術設計可能很早就已經啟動。再往後，就進入實施環節，以及上線後的持續迭代和產品運營環節。以後有機會單獨介紹此部分話題。

** 六、總結**

至此，我們結合一個實際案例，完整的介紹了一套系統從無到有的設計。介紹的重點是調研、架構、模組、建模、許可權，對於互動、介面等細節一筆帶過。實際上，文中已經多次強調，並且讀者現在應該也有了充分的認識，抽象、流程、建模才是業務系統設計的重點和核心，只有將業務最本質的東西高度剝離並正確抽象，才能構建一套靈活強大的系統。

對於一名後端產品經理來講，以下經驗和技能必不可可少。

• 具備基本的商業、管理、運營常識；
• 理解商業模式、業務目標、組織、流程；
• 理解公司的企業應用架構和系統現狀；
• 具備將客觀世界抽象成架構、模組、模型的能力；

路漫漫其修遠，後端產品經理的成長是一個厚積薄發的過程，需要長期的堅持、積累、思考。希望本文能夠幫助讀者對系統的設計有一個大體的認知和理解，並融入到工作中，形成更深層次的思考。

作者：楊堃（微訊號公眾號goYangKun），9年網際網路研發、產品設計經驗，曾就職於傳統外資保險公司，百度，現就職於vipkid。

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