本文將以一個案例，向讀者逐步揭示一套業務系統從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的構建，需要經歷如下環節。
本文將以一個案例，向讀者逐步揭示一套業務系統從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接到任務後，首先要理清工作思路，拆解任務，制定時間計劃。只有嚴格遵循時間計劃執行工作，才能保證整體工作有序展開，如期落地。根據經驗和初步判斷，產品經理制定了粗略的工作計劃表如下。
本文將以一個案例，向讀者逐步揭示一套業務系統從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、業務調研的方法
理解業務最好的方法，是輪崗參與業務環節。此外更加便捷快速的方法，是調研訪談。調研之前最好對業務能有大體的認知，安排好訪談的對象，提前準備好問題，讓訪談更加高效。以下是針對分銷業務的訪談計劃和調研表。
主持人員：產品經理、研發經理
調研對象：業務負責人、一線主管、一線業務人員、合作伙伴
調研方式：
訪談
數據分析
調研目標：
瞭解業務模式和業務特點
瞭解業務目標和業務規劃
瞭解當前業務運轉方式
挖掘當前問題與痛點
本文將以一個案例，向讀者逐步揭示一套業務系統從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、業務調研總結
組織架構
通過調研，理清最基本的業務組織架構圖，通過組織架構圖理解管理體系和職能單元的設計，以及後續規劃。
本文將以一個案例，向讀者逐步揭示一套業務系統從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、業務調研總結
組織架構
通過調研，理清最基本的業務組織架構圖，通過組織架構圖理解管理體系和職能單元的設計，以及後續規劃。
業務目標
對關鍵業務指標和目標需要有相應梳理。
本文將以一個案例，向讀者逐步揭示一套業務系統從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、業務調研總結
組織架構
通過調研，理清最基本的業務組織架構圖，通過組織架構圖理解管理體系和職能單元的設計，以及後續規劃。
業務目標
對關鍵業務指標和目標需要有相應梳理。
業務流程
通過調研，梳理出目前的業務運作流程，如下圖。
本文將以一個案例，向讀者逐步揭示一套業務系統從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系統進行支持，本次項目暫不考慮。
創建一套系統或平臺，支持客戶簽約後的賬號管理、價格管理、自主下單等功能。
本文將以一個案例，向讀者逐步揭示一套業務系統從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、整體架構設計
現在，需要考慮分銷平臺的三個子系統，如何與公司的整體應用架構融合問題。公司經過多年發展，系統架構體系已經非常完備，大量公共組建和模塊可以複用，這樣就減輕了新平臺的實現成本和難度。分銷平臺只需要聚焦自己業務特殊獨立的地方，其他公共組建和模塊複用已有系統即可。
關於如何理解公司應用架構圖，可參考本人之前的文章《漫談企業應用架構的演變》。
我們將確定的三個子系統，繪入簡化版的公司整體應用架構圖，如下。
本文將以一個案例，向讀者逐步揭示一套業務系統從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、功能抽象
基於對業務的分析，以及三套系統的定位，可以抽象並繪製完整的系統功能藍圖。
本文將以一個案例，向讀者逐步揭示一套業務系統從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。
本文將以一個案例，向讀者逐步揭示一套業務系統從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、實體建模
實體建模是細節設計中最難，也是最重要的環節。實體建模代表將客觀世界的對象，抽象成結構化的描述。實體建模有問題，會導致後續業務和系統完全喪失擴展性和靈活性，甚至會很快就無法支持業務，需要推倒重做。
實體建模實際上是數據庫設計中最重要的部分，會影響數據庫表結構的設計，但更多體現了對業務本質的理解和認知。很多產品經理常常忽略實體建模，只關注功能界面設計，最終會陷入邏輯的混亂和旋渦中。
只要模型清晰合理，功能設計、界面設計都是水到渠成的事。我們將結合案例，以客戶模型設計為起點，詳細闡述實體建模的設計思路。
理想化的客戶模型
首先回顧客戶訴求。目前的分銷客戶中，有比較大型的集團客戶，下設若干省市機構和庫房、門店。調研時，集團客戶有如下訴求：
上海是中央倉庫，需要由上海採購員賬號下單配送到上海中央倉庫；
廣州天河區是中央倉庫，需要由天河採購員下單配送到天河中央倉庫；
廣州其他區是門店自採，需要由各門店採購員下單配送到各門店；
廣東省需要有一個高級別採購員賬號，能夠幫廣東各倉庫和門店代下單；
以上訴求，是業務系統建設中，最經典常見的樹形組織機構管理訴求。不論是公司，還是客戶，作為企業，都有多層級管理的要求，希望軟件系統能夠支持多層級業務體系。
多層級機構管理，通常使用組織機構樹實現，在一顆樹上繪製出業務的管理層級體系。我們將分銷業務作為組織機構管理樹的根節點，客戶屬於子樹，樹形結構可以體現出客戶的行政管理層級結構。將賬號和門店（收貨對象，可以是中央倉，也可以是店鋪）作為葉子，掛在機構節點下。賬號管理的數據範疇（包括能給哪些門店下單，能查看哪些門店的數據），可以遍歷所在節點的子樹來實現。繪製示意圖如下。
本文將以一個案例，向讀者逐步揭示一套業務系統從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圖，可以描述出三者的關係，如下。
本文將以一個案例，向讀者逐步揭示一套業務系統從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圖，看似簡單，但卻是對組織機構樹以及賬號、門店管理體系的高度抽象。如果實現以上模型，可以支持任意靈活地集團客戶管理訴求。
簡化版的客戶模型
實現組織樹模型，開發複雜度很高。經過和開發、業務溝通，最終決定採用一套簡版的客戶模型來支持一期業務，該簡版模型在需要時完全可以升級到理想版的客戶模型。
首先，和業務以及客戶溝通確認，一期暫不支持複雜的行政層級管理，只需要給客戶實現若干子賬號可以管理若干門店即可，示意圖如下。
本文將以一個案例，向讀者逐步揭示一套業務系統從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圖，看似簡單，但卻是對組織機構樹以及賬號、門店管理體系的高度抽象。如果實現以上模型，可以支持任意靈活地集團客戶管理訴求。
簡化版的客戶模型
實現組織樹模型，開發複雜度很高。經過和開發、業務溝通，最終決定採用一套簡版的客戶模型來支持一期業務，該簡版模型在需要時完全可以升級到理想版的客戶模型。
首先，和業務以及客戶溝通確認，一期暫不支持複雜的行政層級管理，只需要給客戶實現若干子賬號可以管理若干門店即可，示意圖如下。
這樣系統只需要實現一顆非常簡單的樹，每個客戶只有一個根節點而沒有子節點，以便業務系統開發時不需要編寫大量的遍歷算法，大大降低了開發難度。
根據上述規則，將模型簡化如下。
本文將以一個案例，向讀者逐步揭示一套業務系統從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圖，看似簡單，但卻是對組織機構樹以及賬號、門店管理體系的高度抽象。如果實現以上模型，可以支持任意靈活地集團客戶管理訴求。
簡化版的客戶模型
實現組織樹模型，開發複雜度很高。經過和開發、業務溝通，最終決定採用一套簡版的客戶模型來支持一期業務，該簡版模型在需要時完全可以升級到理想版的客戶模型。
首先，和業務以及客戶溝通確認，一期暫不支持複雜的行政層級管理，只需要給客戶實現若干子賬號可以管理若干門店即可，示意圖如下。
這樣系統只需要實現一顆非常簡單的樹，每個客戶只有一個根節點而沒有子節點，以便業務系統開發時不需要編寫大量的遍歷算法，大大降低了開發難度。
根據上述規則，將模型簡化如下。
仔細觀察可以發現，該模型與前一個模型相比，唯一的變化，是在賬號和門店兩個對象之間建立了關聯關係，其他結構不變。實際上這樣處理，保持了模型未來的擴展性。當未來需要全面實現組織機構管理時，將賬號、門店之間的對應關係打斷，在業務系統中實現遍歷算法，以及組織樹管理維護功能即可，整個數據底層基本不需要調整。
更豐富一些的客戶模型
業務需求中很重要的一條，能夠針對每個客戶每個門店的個性報價，設置不同的係數表，結合時價動態計算商品價格。這裡涉及到幾個新的對象，係數表，報價單，為了讓管理可控，係數表是全公司通用的多套參數集合，包括了商品和價格係數，給每個門店關聯並且只能關聯一個有效的報價單，報價單關聯繫數表，以保證運營人員只需要調整一次係數表，就能刷新到所有需要修改的門店的價格表。數據模型設計如下。
本文將以一個案例，向讀者逐步揭示一套業務系統從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圖，看似簡單，但卻是對組織機構樹以及賬號、門店管理體系的高度抽象。如果實現以上模型，可以支持任意靈活地集團客戶管理訴求。
簡化版的客戶模型
實現組織樹模型，開發複雜度很高。經過和開發、業務溝通，最終決定採用一套簡版的客戶模型來支持一期業務，該簡版模型在需要時完全可以升級到理想版的客戶模型。
首先，和業務以及客戶溝通確認，一期暫不支持複雜的行政層級管理，只需要給客戶實現若干子賬號可以管理若干門店即可，示意圖如下。
這樣系統只需要實現一顆非常簡單的樹，每個客戶只有一個根節點而沒有子節點，以便業務系統開發時不需要編寫大量的遍歷算法，大大降低了開發難度。
根據上述規則，將模型簡化如下。
仔細觀察可以發現，該模型與前一個模型相比，唯一的變化，是在賬號和門店兩個對象之間建立了關聯關係，其他結構不變。實際上這樣處理，保持了模型未來的擴展性。當未來需要全面實現組織機構管理時，將賬號、門店之間的對應關係打斷，在業務系統中實現遍歷算法，以及組織樹管理維護功能即可，整個數據底層基本不需要調整。
更豐富一些的客戶模型
業務需求中很重要的一條，能夠針對每個客戶每個門店的個性報價，設置不同的係數表，結合時價動態計算商品價格。這裡涉及到幾個新的對象，係數表，報價單，為了讓管理可控，係數表是全公司通用的多套參數集合，包括了商品和價格係數，給每個門店關聯並且只能關聯一個有效的報價單，報價單關聯繫數表，以保證運營人員只需要調整一次係數表，就能刷新到所有需要修改的門店的價格表。數據模型設計如下。
該模型體現了真實世界針對門店單獨報價的場景，同時也體現了價格係數表的設計思路。
理清了賬號、門店、機構、報價單、價格係數表之間的關係，功能設計都是水到渠成的事情。如果沒有梳理清楚這些關係，功能設計、界面設計時必然是一頭霧水，漏洞百出。
建模錯誤會導致擴展的災難
最後，我們來看一個建模錯誤導致災難的例子。如果我們將上圖數據模型中，賬號和門店的對應關係調整成一對多，如下。
本文將以一個案例，向讀者逐步揭示一套業務系統從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個角色，來支持業務。
電商公司分銷業務部
分銷管理員 – 負責業務稽查，審核，分公司賬號的管理維護
分銷運營 – 負責分公司客戶的賬號維護，報價管理
客戶
客戶管理員 – 負責下單賬號和門店的管理、維護，訂單查詢，對賬結算
客戶採購 – 負責給門店下單
角色的設計，取決於業務對權責的劃分。用戶角色設計完成後，可以繪製更加詳細的，基於系統的流程圖，如下。
本文將以一個案例，向讀者逐步揭示一套業務系統從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必須掌握的核心技能。
本文將以一個案例，向讀者逐步揭示一套業務系統從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”的區別是，前者的數據權限範圍，是查詢用戶當前所在組織機構樹葉子上的數據，而後者能夠查詢用戶當前所在組織機構樹葉子，以及葉子下邊所有子節點的數據。
本文將以一個案例，向讀者逐步揭示一套業務系統從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”的區別是，前者的數據權限範圍，是查詢用戶當前所在組織機構樹葉子上的數據，而後者能夠查詢用戶當前所在組織機構樹葉子，以及葉子下邊所有子節點的數據。
客戶的組織架構如下。
本文將以一個案例，向讀者逐步揭示一套業務系統從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能查看哪些門店的訂單數據。如果您理解了這個案例中隱含的邏輯，則掌握了業務系統權限管理體系的主要核心思想。
本文將以一個案例，向讀者逐步揭示一套業務系統從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以後，進入了技術設計和實施環節。當然，對於一套全新的系統，技術設計可能很早就已經啟動。再往後，就進入實施環節，以及上線後的持續迭代和產品運營環節。以後有機會單獨介紹此部分話題。
六、總結
至此，我們結合一個實際案例，完整的介紹了一套系統從無到有的設計。介紹的重點是調研、架構、模塊、建模、權限，對於交互、界面等細節一筆帶過。實際上，文中已經多次強調，並且讀者現在應該也有了充分的認識，抽象、流程、建模才是業務系統設計的重點和核心，只有將業務最本質的東西高度剝離並正確抽象，才能構建一套靈活強大的系統。
對於一名後端產品經理來講，以下經驗和技能必不可可少。
具備基本的商業、管理、運營常識；
理解商業模式、業務目標、組織、流程；
理解公司的企業應用架構和系統現狀；
具備將客觀世界抽象成架構、模塊、模型的能力；
路漫漫其修遠，後端產品經理的成長是一個厚積薄發的過程，需要長期的堅持、積累、思考。希望本文能夠幫助讀者對系統的設計有一個大體的認知和理解，並融入到工作中，形成更深層次的思考。
作者：楊堃 VIPKID 產品總監 ，決勝B端作者，曾任百度高級產品經理，曾從無到有建設多款企業級業務產品。