好的架構能良好的支持業(yè)務的橫向擴展，各個系統(tǒng)的數(shù)據(jù)在業(yè)務整體上是連續(xù)的、完整的、準確的。業(yè)務系統(tǒng)的技術架構如何搭建？文章圍繞這個問題展開了詳細的說明，與大家分享。

業(yè)務類系統(tǒng)（通常稱為To B 類產品），一般包括CRM，供應鏈，物流等。系統(tǒng)的架構設計非常具有挑戰(zhàn)性。

面向用戶的To C 類前臺產品，無論產品經(jīng)理還是用戶都已經(jīng)培養(yǎng)起了使用習慣，對功能有一定程度的理解，見過的模式足夠多，能夠建立起一定的產品模型，也容易找到參照物去模仿。

但是業(yè)務類的系統(tǒng)，常常是沒有參照和模仿，一些業(yè)務流程的不同，一點公司組織結構的不同，你家的CRM和他家的CRM可能完全沒有參考性。所以在搭建產品架構的時候則要求產品經(jīng)理非常懂業(yè)務，考驗PM能力的同時，對技術架構也具備很大的挑戰(zhàn)。

首先，思考一下好的產品(業(yè)務模式)是什么？

一、 業(yè)務類系統(tǒng)， 一般需要加強的三個方面

基礎服務包括技術方面基礎這不用多說。業(yè)務型基礎服務也不要忽視，比如城市服務，入口管理等，這些如果前期沒有執(zhí)行好的標準，系統(tǒng)一旦累計幾年，將難以調整。

業(yè)務架構和數(shù)據(jù)運營，都會在后面專項的提到，重點說業(yè)務系統(tǒng)的架構方法。

二、技術架構的三個要素

1. 三要素的順序一定是從功能到系統(tǒng)，最后是架構

先說功能，功能元素指的是一系列的操作集合，能構成一個完整的功能，比如登錄，注冊。

使用者通過一個功能元素完整的完成一項唯一的工作，技術上可以叫做模塊，產品上稱為功能。

當然在產品設計和持續(xù)迭代過程里，常常很難如此實現(xiàn)唯一……

系統(tǒng)是指相互之間有直接或間接關系的功能元素形成的集合，此集合能單獨為特定使用者提供特定的服務，比如銷售系統(tǒng)，客服系統(tǒng)

我們說的技術架構， 一定是“多個”獨立系統(tǒng)之間的事情。

我們開始談技術架構的第一步，各系統(tǒng)必須先獨立，工程和數(shù)據(jù)耦合的一起的系統(tǒng)，沒有架構可言

沒有任何關系的功能元素組成，不能稱為系統(tǒng)。同樣的沒有任何關系的系統(tǒng)組成，不需要架構

2. 要區(qū)分技術實現(xiàn)方法和技術架構的不同

針對功能和系統(tǒng)的實現(xiàn)，會對應的采用DB，ES，負載均衡等實現(xiàn)方法。很多實現(xiàn)方法可能技術含量很高，

但不要把技術實現(xiàn)方法和整體技術架構混淆，技術實現(xiàn)方法和技術架構是兩回事

3. 制定技術架構，必須考慮系統(tǒng)功能層級

技術架構就是指把不同的功能元素（系統(tǒng)）放在適宜的環(huán)節(jié)、合適的層級，并且建立功能與功能，系統(tǒng)與系統(tǒng)之間關系，形成一個結構化、平臺化、體驗簡約的大系統(tǒng)。

架構和功能層級表達的其實是信息之間的流轉關系，不同信息層級之間一定是有邏輯關系的。

各層次之間雖然相關，但同一層級的功能系統(tǒng)之間一定是獨立的，同時客觀上也常常對應著不同的技術部門和業(yè)務部門。

業(yè)務類系統(tǒng)的架構設計比ToC的復雜很多。

（1）按功能模塊來進行劃分：

適合產品目標單一的ToC 產品，或者單一上下游的ToB系統(tǒng)，系統(tǒng)的使用者群體單一，使用者群體單一，功能和功能之間并沒有太多的邏輯關系

（2）按業(yè)務邏輯來進行劃分：

適合復雜類的ToB系統(tǒng)，多角色共同完成一系列的工作

一個功能（系統(tǒng)）務必在同一層級內解決，否則容易造成信息架構被打破

首先要總結出第一級別的功能元素，這個第一級別功能元素，其實就是我們的業(yè)務主線，也就是核心業(yè)務。 線索，cc，建單，帶看，成交，過戶。。。。。

合格的系統(tǒng)，需要第一功能層級間建立合理的關系（現(xiàn)實原因，的確常常次要功能間，不容易建立合理關系）

三、技術架構的兩個原則

（1）說到系統(tǒng)架構，架構師的組織能力很重要，組織的不只是一個系統(tǒng)的各個功能元素，需要具備組織不同的系統(tǒng)的能力。在于理解要為誰，解決什么問題。

技術架構和產品架構，必須一致，各自用不同邏輯做拆分，建關系，那是災難。

對業(yè)務整體有深刻的思考和理解，還需要更強的產品抽象能力。

九成的產品經(jīng)理，其實不談產品架構。常常掛在嘴邊就是業(yè)務需求，好像工作就是業(yè)務的翻譯官

（2）我們通常所謂的某產品，其實就是業(yè)務模式，就是流程和規(guī)則，如果業(yè)務系統(tǒng)的主流程和規(guī)則不是你設計的，只是翻譯業(yè)務需求，那業(yè)務部門直接找技術也行得通。

一個產品的使命是為使用者提供特定的服務，要我們通過什么樣的方式為使用者提供什么樣的產品和服務。所以一定是業(yè)務導向的，以業(yè)務結果的好壞評定，一切都是為業(yè)務服務的

所謂產品架構，還是技術架構， 都是信息架構。

作為系統(tǒng)業(yè)務架構師，需要時刻腦子里有個大系統(tǒng)的產品（技術）架構圖。要有能力把產品功能（技術模塊）抽象成信息化的層級的架構。通過功能與功能的組合、層級關系的交互傳遞信息的流轉，整個架構圖傳遞的是我們的業(yè)務流程、商業(yè)模式。

產品要有技術能力，技術如果不懂產品，那再資深的工程師，也只能是碼農。。。。

※ 這里說一下系統(tǒng)擴展性的問題，為最后第八章的實例做個鋪墊。

好的架構各個子系統(tǒng)之間相互配合形成一體化平臺，子系統(tǒng)間只有最小的重復度獨立，系統(tǒng)各自支持不同的業(yè)務板塊，多個系統(tǒng)作為一個整體，共同為支撐公司業(yè)務

可擴展性其實是在傳達一個信息，我們是否了解未來這個產品會有哪些哪方面的新增加功能或者內容，也就是產品規(guī)劃。

沒有人真的能預知未來，但新增功能，新的系統(tǒng)都會導致信息架構重新調整和使用者的認知成本。

所謂可擴展性，就是盡可能為明天的改變降低成本，減少調整，這就需要系統(tǒng)架構設計是可橫向共享的

而在業(yè)務系統(tǒng)里什么是能橫7共享的呢， 就是自始至終貫穿整個業(yè)務鏈條的，一般是客戶，訂單，商品等。所謂各系統(tǒng)的打通，其實就是各系統(tǒng)間如何有效的傳遞客戶，商品等的信息狀態(tài)

好的架構能良好的支持業(yè)務的橫向擴展。這點很重要，新的業(yè)務很多時候都在試錯階段，隨時會增減業(yè)務環(huán)節(jié)，也就是不斷地新的系統(tǒng)，新功能的融入。比如在幾個流程節(jié)點上增減一個三方部門審核操作，審核系統(tǒng)本身不麻煩，但要做到即插即用，對接多個系統(tǒng)和公司多個單位，那不同的架構可能工作量差異很大

好的業(yè)務架構各個系統(tǒng)的數(shù)據(jù)在業(yè)務整體上是連續(xù)的、完整的、準確的。通過數(shù)據(jù)采集，方便建立DW?？梢院芎玫臑闃I(yè)務運營提供數(shù)據(jù)支撐。

好的業(yè)務架構，系統(tǒng)能提供的不止于業(yè)務功能，還有無時不刻無處不在的驅動各模塊業(yè)務和各合作伙伴業(yè)務更好決策的數(shù)據(jù)。

四、業(yè)務系統(tǒng)和用戶系統(tǒng)

以產品為中心，是我有好的市場調研，我有牛掰的產品經(jīng)理，我給使用者的產品就是我能做的最好的，最大可能是使用者需要的。

以客戶為中心，適合面向運營單位，面向商家的企業(yè)級應用，理念是使用者需要什么

使用者，可以是直接用戶，商家，也可能是公司的銷售，客服。

兩類系統(tǒng)，一個標志性的區(qū)別，就是我們是否關注和承擔使用者的業(yè)務結果。

CRM、供應鏈等業(yè)務系統(tǒng)是需要所有人共同承擔業(yè)務結果的。郵件新聞用戶產品，我們不需要承擔用戶使用后增長多少知識的結果。

如果不理解這個以產品為中心和以客戶為中心的不同， 以用戶產品的思路做企業(yè)級應用， 就會出發(fā)點出錯，就是鬧笑話。 比如，我之前的公司，明明是以CRM為主的銷售管理系統(tǒng)，但同事們喜歡拿個淘寶網(wǎng)站的架構來做參考。

理論上， 用戶系統(tǒng)里淘寶網(wǎng)站和人人車、鏈家、京東都是一樣，都是把商品（車/房）展示給用戶，獲得訂單（線索）。 作為“信息”提供方，是把自己有的東西，用自己的方式展示出來。

理解兩類系統(tǒng)在邏輯上的差異，我也是用了很多年，過去在公司總是和同事說不清楚，其實也是我自己沒想明白?？赡苁俏以趯戇@篇文章時候才多了些思考。

1. 用戶產品關注怎么幫助使用者實現(xiàn)發(fā)郵件，看新聞等功能，很多功能技術難度非常大，但就是一個復雜的軟件，而業(yè)務系統(tǒng)為什么核心是數(shù)據(jù)，因為我們要關注使用者的業(yè)務結果，業(yè)務到底有沒有把商品賣出去，廣告的直接效果如何
2. 為什么說用戶產品就是一個軟件？我們夸張一點理解，所有的互聯(lián)網(wǎng)用戶產品都屬于“SAAS”類軟件， 屬于某種在線OFFICE。你的郵件和我的郵件沒有直接關系，你寫的PPT也和我的Word沒關系，使用者之間是隔離的，大家用的是大致同一套界面而已
3. 而業(yè)務系統(tǒng)，使用ERP的部門上下架多少商品直接影響到后續(xù)銷售系統(tǒng)和售后系統(tǒng)的使用者的邏輯，甚至銷售業(yè)務訂單的完成度也互相影響業(yè)績，所以業(yè)務系統(tǒng)的核心是數(shù)據(jù)，核心邏輯除了實現(xiàn)業(yè)務動作，更在于你的數(shù)據(jù)對我的數(shù)據(jù)的影響。很多小公司可以沒有“軟件”，用Excel也能實現(xiàn)業(yè)務管理，但不能沒有數(shù)據(jù)

因此，只有業(yè)務系統(tǒng)才可以說數(shù)據(jù)是永遠的程序是暫時的，用戶系統(tǒng)不應該如是說。

五、運營驅動

一般公司的內部銷售運營體系，都是業(yè)務導向，實現(xiàn)業(yè)務目標是第一位。但會經(jīng)歷兩個階段，

一是 ，業(yè)務驅動。 這段時期，業(yè)務模式不穩(wěn)定，產品能力的問題或者業(yè)務人員強勢， 業(yè)務部門引導公司方向 。這種情況，產品的作用有限，雖然也有便利性，創(chuàng)新性的要求，但總體說還是業(yè)務需求的翻譯官，業(yè)內稱作功能性產品經(jīng)理

二是，產品驅動。當業(yè)務模式固化下來，尤其是業(yè)務流程相對標準化以后，產品經(jīng)理（或者運營）主導規(guī)則和流程 CRM 是最具代表性的業(yè)務系統(tǒng)

現(xiàn)在回答一下，什么是好的產品（業(yè)務模式）應該就是解決用戶真實需求的實際痛點。從痛處入手。這里的用戶可以是Toc的消費者，也可以是面向公司運營單位

產品思維：

從痛點入手，去解決問題，這是我理解的產品思維。而產品經(jīng)理常常掛在嘴邊的需求分析其實是個偽命題。做用戶產品，產品經(jīng)理能接觸到多少用戶了解到多少需求？ 做業(yè)務系統(tǒng)，北區(qū)大佬要APP，南區(qū)大佬要網(wǎng)頁版，產品經(jīng)理那個都惹不起，聽誰的？ 無論做什么產品，得是PM自己有能力設計主流程和規(guī)則，緊貼公司的方向和核心KPI，而不是翻譯誰的需求。

至于抽象，迭代，交互設計，那可能叫產品能力更合適。 就像java能力可能是技術的基本能力，java再好和是否能開發(fā)出微博微信，沒直接關系。漢語再流利，和寫一篇量子力學論文基本也沒關系

接上一節(jié)的話題，我認為比較合理的公司架構是運營驅動。

什么是運營？？

運營就是人為的干預規(guī)則。規(guī)則就是咱們的產品邏輯，也就是業(yè)務規(guī)則。

在電信行業(yè)出來以前，世界上是沒有真正的運營的。 甚至諾基亞和微軟賣出去產品，很難知道用戶打了多少電話，用電腦做了什么， 而電信和互聯(lián)網(wǎng)時代的到來，一切不一樣了， 我們可以清楚的掌握業(yè)務執(zhí)行結果，也就是用戶使用我們的系統(tǒng)到底做了什么。通過使用者的使用情況，從結果知道客戶需要什么，更新規(guī)則。

這套邏輯在業(yè)務系統(tǒng)提現(xiàn)得更加清楚明確， 用規(guī)則去約束銷售、客戶，接單后的動作，規(guī)定動作的時間等。

通過了解使用者對規(guī)則的執(zhí)行情況，對比團隊以及公司的KPI，分析偏差了那些，為什么偏差，再次升級系統(tǒng)，干預規(guī)則，干預偏差。

運營驅動，適合多個運營單位合作，非業(yè)務驅動的產品模式。很多時候，業(yè)務流程和公司組織架構的實際情況，做不到或者不需要運營驅動

多說一句，無論是做產品還是技術，掌握業(yè)務結果非常極其特別十分的重要，但大部分產品和技術都對此不感興趣，也就限制了個人的上升空間。

業(yè)務結果分兩部分，一是系統(tǒng)運行狀況，二是用戶（業(yè)務人員）的使用結果。前者及格線是系統(tǒng)出了問題你要第一時間知道，不能等運營單位投訴再排查。后者就是每天到底多少用戶，多少訂單成立率轉化率，這些必須關心。不能光想著系統(tǒng)怎么去實現(xiàn)，更要知道業(yè)務用你的系統(tǒng)做出了什么，以及每次產品升級為什么而做。

職場上，大家不同的能力，薪水，崗位，最終都會不同程度成為解決不同問題的人。對問題沒有感知，對結果沒興趣的產品技術leader，百分百就是廢柴，你就是問題本身。這個說起來,就是職業(yè)規(guī)劃和價值觀了，不多扯。

六、數(shù)據(jù)運營

這張圖，照搬我一個舊同事的PPT，至今沒見過用一頁紙把數(shù)據(jù)解釋得如此清楚的

前面說到運營驅動，運營離不開數(shù)據(jù)。一般的公司， 在一定規(guī)模前，暫時都達不到數(shù)據(jù)運營。

不是說數(shù)據(jù)不重要。 數(shù)據(jù)能起到的作用，分三個階段。這三個階段簡單的說就是發(fā)生了什么（報表），為什么發(fā)生（數(shù)據(jù)分析）和將要發(fā)生什么（決策支持）。大多數(shù)互聯(lián)網(wǎng)公司，包括那些上市的，其實還沒解決業(yè)務發(fā)生了什么，對，說的沒錯。別看這么多互聯(lián)網(wǎng)公司，包括很多上市公司，每天到底多少線索，多少訂單，各種轉化率，真的沒譜。各團隊口徑差距巨大，這是大概率事情，國內也就BAT（京東，滴滴，美團不夠了解）的主營業(yè)務算是數(shù)據(jù)過關。

為什么會產生這樣的情況，我們明明人人都在說數(shù)據(jù)多么多么重要的廢話。我理解，這不是技術問題，其實是管理問題。各部門的KPI都是擺設，沒有人真正對數(shù)據(jù)結果負責，比如成交率下跌了兩個點，有人會因此離職嗎？ 沒有，那也就沒人去啃那些對不上的數(shù)據(jù)，各部門數(shù)據(jù)差異越來越大，在第八章會再次提及。

而這頁PPT真正解釋牛的在右側部分，數(shù)據(jù)正在發(fā)生什么和我期望發(fā)生什么，這比較超出我的能力， 不解釋了，O(∩_∩)O哈哈~

1. 決策人員：決策者、高層管理者，通常只是用送到手中的極簡單工具，極少自己分析
2. 分析人員：業(yè)務管理者、專業(yè)分析人員利用商務智能各種工具向決策者制作數(shù)據(jù)內容并解釋數(shù)據(jù)含義
3. 一線人員：一線業(yè)務人員，利用工具向管理者固定匯報業(yè)務狀態(tài)、進行少量分析

七、什么是CRM

1. CRM的意義是實現(xiàn)收入可預期的最大化

并且可有計劃的提升預期。無論什么樣的CRM，都是為了營收，這沒啥可掩飾的，沒有哪家會為免費用戶花力氣做CRM。

2. 重點是提升人效

客戶開源和提升高質量客戶的UP值貢獻，理論上是管理問題，是運營策略問題。我們 所有CRM的參與者，重點是提升人效。人效，就是人均賣多少商品或人均貢獻多少收入，是考核團隊首要的KPI。 這里的人包括銷售，運營，客服，產品和技術等。

3. 提升人效的路徑，就是讓機器承擔更多的工作，即“服務數(shù)字化”

• 標準化，標準化是數(shù)字化的基礎，計算機只能保存離散的數(shù)據(jù)，所以標準化的核心是離散化的信息結構化。比如：建單、工單、分配等。
• 自動化，自動化指的是動態(tài)過程的數(shù)字化，比如流程、規(guī)則、權限控制的數(shù)字化?！皠討B(tài)”意味著各種存在依賴關系的元素互相之間的狀態(tài)關系。
• 智能化，直觀的理解就是讓系統(tǒng)具備思考能力。這意味著系統(tǒng)在比較確定的上下文中具備分析能力。

我在公司時候講解CRM，常常用比較得罪人的邏輯解釋。我說，CRM的理念就是通過標準化操作，讓銷售和運營平庸化，所有銷售業(yè)績差異不應該過大，如果有銷售總是遠遠超常發(fā)揮，那說明我們的業(yè)務模式出了問題。哈哈，比較得罪人，但是這套理念也適合技術團隊。。。

八、業(yè)務系統(tǒng)架構實例——橫向共享的架構設計

復習：技術架構就是指把不同的功能元素（系統(tǒng)）放在適宜的環(huán)節(jié)、合適的層級。

公司的CRM應是面向企業(yè)不同運營單位的業(yè)務系統(tǒng)，會覆蓋售前售中售后多個系統(tǒng)集合。我們講技術架構是系統(tǒng)之間的關系，那如何建立這么多系統(tǒng)之間的關系？

這里講一下一種技術架構案例，橫向共享的設計。你的系統(tǒng)里，那些信息和信息的變化是其他系統(tǒng)關注的？？？

一般交易類業(yè)務有三種東西，可能是貫徹公司各業(yè)務線的。商品，客戶，訂單，尤其是前兩種。商品和客戶的信息保留在多個系統(tǒng)里，面向的也是企業(yè)內不同的運營單位，甚至第三方公司。

以商品為例，一個商品從采購倉儲直到客戶手里，生命周期可能幾天到個把年。有負責采購相關的供應鏈部門，有負責營銷的銷售部門，有負責物流運輸部門，還有售后等其他部門。這么多部門，對應著諸多的系統(tǒng)都有商品相關的信息和狀態(tài)。

某個系統(tǒng)里，商品的狀態(tài)信息變化了，其他系統(tǒng)如何第一時間掌握，并及時作出對應動作？？

比如一個簡單的問題，商品成交了退訂退貨等事件，其他相關部門怎么知道呢，然后做相關處理，靠各系統(tǒng)間API調用？？只要業(yè)務跑兩三年，保證各系統(tǒng)間的API成百上千，

我之前供職的一家公司，上萬的員工，有個有趣的現(xiàn)象。供應鏈部門負責商品采購驗收和上架，公司網(wǎng)站展示相應的商品。但是，二者數(shù)據(jù)長期不一致。能有多不一致？說出來嚇死人，有四分之一的商品狀態(tài)幾年來一直對不上，每每想起，趕腳都會被人笑死。

為什么會產生這樣的情況? 因為供應鏈上架是API通知網(wǎng)站以及各部門，其他部門銷售了，退訂了商品等也是API調用供應鏈和網(wǎng)站。也就是各系統(tǒng)啥都是API調用。同時什么是上架，下架和成交，各系統(tǒng)定義都不一致，并且API調用不夠穩(wěn)定，又缺乏監(jiān)控，也就是第五章說的產品技術都完全沒有掌握業(yè)務結果的意識。。。

理論上說， 如果各系統(tǒng)自身足夠強壯，系統(tǒng)間通訊嚴絲合縫，指標定義清晰明了，那什么問題都不會有，根本不需要做橫向共享，不需要搞什么輔助設計。但這幾乎是不可能的.

要明白，除非系統(tǒng)上線后永不升級，否則一切都是逐步演進的，日積月累差異會大的驚人

建設主數(shù)據(jù)，采用橫向共享的設計取代系統(tǒng)間API調用的網(wǎng)狀依賴。

主數(shù)據(jù)能做什么，一般主數(shù)據(jù)的輸出是客戶或商品全景視圖，所有業(yè)務系統(tǒng)將有跨業(yè)務系統(tǒng)需要的相關信息同步到主數(shù)據(jù)，并從全景視圖獲得其他相關的數(shù)據(jù)。

主數(shù)據(jù)真正實現(xiàn)各個業(yè)務系統(tǒng)的打通

主數(shù)據(jù)通過統(tǒng)一的數(shù)據(jù)采集，數(shù)據(jù)存儲，數(shù)據(jù)管理，需要足夠的產品認知能力和全局業(yè)務意識。

主數(shù)據(jù)對外提供的是統(tǒng)一的信息查詢和信息變更服務訂閱，這里技術實現(xiàn)其實并不復雜，也就是ES和MQ。

例如，銷售系統(tǒng)通過主數(shù)據(jù)的“商品變革信息訂閱中心”的信息訂閱獲取供應鏈上架的商品后，而供應鏈和售后等系統(tǒng)通過同樣的訂閱中心獲取商品是否成交的信息決定商品上下架等操作

再重申幾點：

1. 比較適合做主數(shù)據(jù)的也就是商品和客戶
2. 理論上可以有多個主數(shù)據(jù)，但實際操作過程里， 需要具體看情況。比如電商，商品和廣告是兩個業(yè)務線，甚至兩個事業(yè)部，各自的架構，各自的橫向共享，可能完全隔離更合適
3. 選擇的重點，可以參照業(yè)務重點，比如我們到底是幫商家賣東西還是幫用戶買東西。。。
4. 并不是業(yè)務一開始，上來就搞主數(shù)據(jù)，就想著橫向共享。在初期野蠻生長時候，各系統(tǒng)盡可能獨立，劃清界限即可
5. 主數(shù)據(jù)目的是跨系統(tǒng)的共享主要數(shù)據(jù)的變化，應該盡最大可能不要侵入業(yè)務系統(tǒng)。 也就是不要讓業(yè)務系統(tǒng)直接把業(yè)務結果往主數(shù)據(jù)里更新，一定是通過數(shù)據(jù)采集的方式，各業(yè)務系統(tǒng)盡可能不做任何變化
6. 主數(shù)據(jù)不要直接產生業(yè)務數(shù)據(jù)，但可以有間接的。比如跨業(yè)務的指標（例：網(wǎng)站PV和成交量的比例），業(yè)務系統(tǒng)自身不關注的指標（例：最近10天成交率）

本文由 @王以弘 原創(chuàng)發(fā)布于人人都是產品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議