業務類系統（通常稱爲To B 類產品），一般包括crm，供應鏈，物流等。系統的架構設計非常具有挑戰性。面向用戶的To C 類前臺產品，無論產品經理還是用戶都已經培養起了使用習慣，對功能有一定程度的理解，見過的模式足夠多，能夠建立起一定的產品模型，也容易找到參照物去模仿。
但是業務類的系統，常常是沒有參照和模仿，一些業務流程的不同，一點公司組織結構的不同，你家的CRM和他家的CRM可能完全沒有參考性。所以在搭建產品架構的時候則要求產品經理非常懂業務，考驗PM能力的同時，對技術架構也具備很大的挑戰。
首先，思考一下好的產品(業務模式)是什麼？一、 業務類系統， 一般需要加強的三個方面
基礎服務包括技術方面基礎這不用多說。業務型基礎服務也不要忽視，比如城市服務，入口管理等，這些如果前期沒有執行好的標準，系統一旦累計幾年，將難以調整。
業務架構和數據運營，都會在後面專項的提到
重點說業務系統的架構方法
二、技術架構的三個要素
1. 三要素的順序一定是從功能到系統，最後是架構
先說功能，功能元素指的是一系列的操作集合，能構成一個完整的功能，比如登錄，註冊。
使用者通過一個功能元素完整的完成一項唯一的工作，技術上可以叫做模塊，產品上稱爲功能。
當然在產品設計和持續迭代過程裏，常常很難如此實現唯一。。。
系統是指相互之間有直接或間接關係的功能元素形成的集合，此集合能單獨爲特定使用者提供特定的服務，比如銷售系統，客服系統
我們說的技術架構， 一定是“多個”獨立系統之間的事情。
我們開始談技術架構的第一步，各系統必須先獨立，工程和數據耦合的一起的系統，沒有架構可言
沒有任何關係的功能元素組成，不能稱爲系統。同樣的沒有任何關係的系統組成，不需要架構
2. 要區分技術實現方法和技術架構的不同
針對功能和系統的實現，會對應的採用DB，ES，負載均衡等實現方法。很多實現方法可能技術含量很高，
但不要把技術實現方法和整體技術架構混淆，技術實現方法和技術架構是兩回事
3 . 制定技術架構，必須考慮系統功能層級。
技術架構就是指把不同的功能元素（系統）放在適宜的環節、合適的層級，
並且建立功能與功能，系統與系統之間關係，形成一個結構化、平臺化、體驗簡約的大系統。
架構和功能層級表達的其實是信息之間的流轉關係，不同信息層級之間一定是有邏輯關係的。
各層次之間雖然相關，但同一層級的功能系統之間一定是獨立的，同時客觀上也常常對應着不同的技術部門和業務部門。
業務類系統的架構設計比ToC的複雜很多。
• a.按功能模塊來進行劃分 –
適合產品目標單一的ToC 產品，或者單一上下游的ToB系統，系統的使用者羣體單一，使用者羣體單一，功能和功能之間並沒有太多的邏輯關係
• b.按業務邏輯來進行劃分 --
適合複雜類的ToB系統，多角色共同完成一系列的工作
一個功能（系統）務必在同一層級內解決，否則容易造成信息架構被打破
首先要總結出第一級別的功能元素，這個第一級別功能元素，其實就是我們的業務主線，也就是核心業務。 線索，cc，建單，帶看，成交，過戶。。。。。
合格的系統，需要第一功能層級間建立合理的關係（現實原因，的確常常次要功能間，不容易建立合理關係）
三、技術架構的兩個原則
1 . 說到系統架構，架構師的組織能力很重要，組織的不只是一個系統的各個功能元素，需要具備組織不同的系統的能力。在於理解要爲誰，解決什麼問題。
技術架構和產品架構，必須一致，各自用不同邏輯做拆分，建關係，那是災難
對業務整體有深刻的思考和理解，還需要更強的產品抽象能力。
九成的產品經理，其實不談產品架構。常常掛在嘴邊就是業務需求，好像工作就是業務的翻譯官
-
我們通常所謂的某產品，其實就是業務模式，就是流程和規則，如果業務系統的主流程和規則不是你設計的，只是翻譯業務需求，那業務部門直接找技術也行得通。
一個產品的使命是爲使用者提供特定的服務，要我們通過什麼樣的方式爲使用者提供什麼樣的產品和服務。所以一定是業務導向的，以業務結果的好壞評定，一切都是爲業務服務的
所謂產品架構，還是技術架構， 都是信息架構。
作爲系統業務架構師，需要時刻腦子裏有個大系統的產品（技術）架構圖。要有能力把
產品功能（技術模塊）抽象成信息化的層級的架構。通過功能與功能的組合、層級關係的交互傳遞信息的流轉，整個架構圖傳遞的是我們的業務流程、商業模式。
產品要有技術能力，技術如果不懂產品，那再資深的工程師，也只能是碼農。。。。※ 這裏說一下系統擴展性的問題，爲最後第八章的實例做個鋪墊。
好的架構各個子系統之間相互配合形成一體化平臺，子系統間只有最小的重複度獨立，系統各自支持不同的業務板塊，多個系統作爲一個整體，共同爲支撐公司業務
可擴展性其實是在傳達一個信息，我們是否瞭解未來這個產品會有哪些哪方面的新增加功能或者內容，也就是產品規劃。
沒有人真的能預知未來，但新增功能，新的系統都會導致信息架構重新調整和使用者的認知成本。
所謂可擴展性，就是儘可能爲明天的改變降低成本，減少調整，這就需要系統架構設計是可橫向共享的
而在業務系統裏什麼是能橫向共享的呢， 就是自始至終貫穿整個業務鏈條的，一般是客戶，訂單，商品等。所謂各系統的打通，其實就是各系統間如何有效的傳遞客戶，商品等的信息狀態
好的架構能良好的支持業務的橫向擴展。這點很重要，新的業務很多時候都在試錯階段，隨時會增減業務環節，也就是不斷地新的系統，新功能的融入。比如在幾個流程節點上增減一個三方部門審覈操作，審覈系統本身不麻煩，但要做到即插即用，對接多個系統和公司多個單位，那不同的架構可能工作量差異很大
好的業務架構各個系統的數據在業務整體上是連續的、完整的、準確的。通過數據採集，方便建立DW。可以很好的爲業務運營提供數據支撐。
好的業務架構，系統能提供的不止於業務功能，還有無時不刻無處不在的驅動各模塊業務和各合作伙伴業務更好決策的數據。四。業務系統和用戶系統
以產品爲中心，是我有好的市場調研，我有牛掰的產品經理，我給你的產品就是我能做的最好的，最大可能是你需要的。
以客戶爲中心，適合面向運營單位，面向商家的企業級應用，理念是你需要什麼
這裏的你，可以是直接用戶，商家，也可能是公司的銷售，客服。
而你公司自己的業務系統，是需要所有人共同承擔業務結果的。用戶產品，你不需要承擔用戶使用後的結果。
理論上，只有業務系統纔可以說數據是永遠的程序是暫時的，用戶系統不應該如是說。
如果不理解這個以產品爲中心和以客戶爲中心的不同， 以用戶產品的思路做企業級應用， 就會出發點出錯，就是鬧笑話。 比如，我之前的公司，明明是以CRM爲主的營銷管理系統，但同事們喜歡拿個淘寶網站的架構來做參考。
理論上， 用戶系統裏淘寶網站和人人車、鏈家、京東都是一樣，都是把商品（車/房）展示給用戶，獲得訂單（線索）。 作爲“信息”提供方，是把自己有的東西，用自己的方式展示出來。
理解兩類系統在邏輯上的差異，我也是用了很多年，過去在公司總是和同事說不清楚，其實也是我自己沒想明白。可能是我在寫這篇文章時候纔多了些思考。
- 用戶產品關注怎麼幫助使用者實現發郵件，看新聞等功能，很多功能技術難度非常大，但就是一個複雜的軟件，而業務系統爲什麼核心是數據，因爲我們要關注使用者的業務結果，業務到底有沒有把商品賣出去，廣告的直接效果如何
- 爲什麼說用戶產品就是一個軟件？我們誇張一點理解，所有的互聯網用戶產品都屬於“SAAS”類軟件， 屬於某種在線OFFICE。你的郵件和我的郵件沒有直接關係，你寫的PPT也和我的Word沒關係，使用者之間是隔離的，大家用的是大致同一套界面
- 而業務系統，使用ERP的部門上下架多少商品直接影響到後續銷售系統和售後系統的使用者的邏輯，甚至銷售業務訂單的完成度也互相影響業績，所以業務系統的核心是數據，核心邏輯除了實現業務動作，更在於你的數據對我的數據的影響。很多小公司可以沒有“軟件”，用Excel也能實現業務管理，但不能沒有數據
理論上，只有業務系統纔可以說數據是永遠的程序是暫時的，用戶系統不應該如是說
一般公司的內部銷售運營體系，都是業務導向，但會經歷兩個階段，
一是 ，業務驅動。 這段時期，業務模式不穩定，產品能力的問題或者業務人員強勢， 業務部門引導公司方向 。這種情況，產品的作用有限，雖然也有便利性，創新性的要求，但總體說還是業務需求的翻譯官，業內稱作功能性產品經理
二是，產品驅動。當業務模式固化下來，尤其是業務流程相對標準化以後，產品經理（或者運營）主導規則和流程 CRM 是最具代表性的業務系統
五。運營驅動
現在回答一下，什麼是好的產品（業務模式）應該就是解決用戶真實需求的實際痛點。從痛處入手。這裏的用戶可以是Toc的消費者，也可以是面向公司運營單位
產品思維：
從痛點入手，去解決問題，這是我理解的產品思維。而產品經理常常掛在嘴邊的需求分析其實是個僞命題。做用戶產品，產品經理能接觸到多少用戶瞭解到多少需求？ 做業務系統，北區大佬要APP，南區大佬要網頁版，產品經理那個都惹不起，聽誰的？
無論做什麼產品，得是PM自己有能力設計主流程和規則，緊貼公司的方向和核心KPI，而不是翻譯誰的需求。
至於抽象，迭代，交互設計，那可能叫產品能力更合適。 就像java能力可能是技術的基本能力，java再好和是否能開發出微博微信，沒直接關係。漢語再流利，和寫一篇量子力學論文基本也沒關係
接上一節的話題，我認爲比較合理的公司架構是運營驅動。
什麼是運營？？
運營就是人爲的干預規則。規則就是咱們的產品邏輯，也就是業務規則。
在電信行業出來以前，世界上是沒有真正的運營的。 甚至諾基亞和微軟賣出去產品，很難知道用戶打了多少電話，用電腦做了什麼， 而電信和互聯網時代的到來，一切不一樣了， 我們可以清楚的掌握業務執行結果，也就是用戶使用我們的系統到底做了什麼。通過使用者的使用情況，從結果知道客戶需要什麼，更新規則。
這套邏輯在業務系統提現得更加清楚明確， 用規則去約束銷售、客戶，接單後的動作，規定動作的時間等。
通過了解使用者對規則的執行情況，對比團隊以及公司的KPI，分析偏差了那些，爲什麼偏差，再次升級系統，干預規則，干預偏差。
運營驅動，適合多個運營單位合作，非業務驅動的產品模式。很多時候，業務流程和公司組織架構的實際情況，做不到或者不需要運營驅動
✘ 多說一句，無論是做產品還是技術，掌握業務結果非常極其特別十分的重要，但大部分產品和技術都對此不感興趣，也就限制了個人的上升空間。
業務結果分兩部分，一是系統運行狀況，二是使用結果。前者及格線是系統出了問題你要第一時間知道，不能等運營單位投訴再排查。後者就是每天到底多少用戶，多少訂單成立率轉化率，這些必須關心。不能光想着系統怎麼去實現，更要知道業務用你的系統做出了什麼，以及每次升級爲什麼而做。
職場上，大家不同的能力，薪水，崗位，最終都會不同程度成爲解決不同問題的人。這個說起來就是職業規劃和價值觀了，不多扯。但我們總得知道產品（系統）當前的問題以及產品（業務）最重要的事情（KPI）
六、數據運營
這張圖，照搬我一箇舊同事的PPT，至今沒見過用一頁紙把數據解釋得如此清楚的
前面說到運營驅動，運營離不開數據。一般的公司， 在一定規模前，暫時都達不到數據運營。
不是說數據不重要。 數據能起到的作用，分三個階段。這三個階段簡單的說就是
！ 發生了什麼（報表）
! 爲什麼發生（數據分析）
! 將要發生什麼（決策支持）。**
大多數互聯網公司，包括那些上市的，其實還沒解決業務發生了什麼，對，說的沒錯。別看這麼多互聯網公司，包括很多上市公司，每天到底多少線索，多少訂單，各種轉化率，真的沒譜。各團隊口徑差距巨大，這是大概率事情，國內也就BAT（京東，滴滴，美團不夠了解）的主營業務算是數據過關。
而這頁PPT真正解釋牛的在右側部分，數據正在發生什麼和我期望發生什麼，這比較超出我的能力， 不解釋了，O(∩_∩)O哈哈~
1、決策人員：決策者、高層管理者，通常只是用送到手中的極簡單工具，極少自己分析
2、分析人員：業務管理者、專業分析人員利用商務智能各種工具向決策者製作數據內容並解釋數據含義
3、一線人員：一線業務人員，利用工具向管理者固定彙報業務狀態、進行少量分析
七。什麼是CRM
一、CRM的意義是實現收入可預期的最大化
並且可有計劃的提升預期。無論什麼樣的CRM，都是爲了營收，這沒啥可掩飾的，沒有哪家會爲免費用戶花力氣做CRM。
二、 重點是提升人效
客戶開源和提升高質量客戶的UP值貢獻，理論上是管理問題，是運營策略問題。我們 所有CRM的參與者，重點是提升人效。人效，就是人均賣多少商品或人均貢獻多少收入，是考覈團隊首要的KPI。 這裏的人包括銷售，運營，客服，產品和技術等。
三、 提升人效的路徑，就是讓機器承擔更多的工作，即“服務數字化”。
標準化。標準化是數字化的基礎，計算機只能保存離散的數據，所以標準化的核心是離散化的信息結構化。比如：建單、工單、分配等。
自動化。自動化指的是動態過程的數字化，比如流程、規則、權限控制的數字化。“動態”意味着各種存在依賴關係的元素互相之間的狀態關係。
智能化。直觀的理解就是讓系統具備思考能力。這意味着系統在比較確定的上下文中具備分析能力。
我在公司時候講解CRM，常常用比較得罪人的邏輯解釋。我說，CRM的理念就是通過標準化操作，讓銷售和運營平庸化，所有銷售業績差異不應該過大，如果有銷售總是遠遠超常發揮，那說明我們的業務模式出了問題。哈哈，比較得罪人，但是這套理念也適合技術團隊。。。
八。業務系統架構實例
——橫向共享的架構設計
複習:技術架構就是指把不同的功能元素（系統）放在適宜的環節、合適的層級，
公司的CRM應是面向企業不同運營單位的業務系統，會覆蓋售前售中售後多個系統集合。我們講技術架構是系統之間的關係，那如何建立這麼多系統之間的關係？
這裏講一下一種技術架構案例，橫向共享的設計
你的系統裏，那些信息和信息的變化是其他系統關注的？？？
一般交易類業務有三種東西，可能是貫徹公司各業務線的。商品，客戶，訂單，尤其是前兩種。商品和客戶的信息保留在多個系統裏，面向的也是企業內不同的運營單位，甚至第三方公司。
以商品爲例，一個商品從採購倉儲直到客戶手裏，生命週期可能幾天到個把年。有負責採購相關的供應鏈部門，有負責營銷的銷售部門，有負責物流運輸部門，還有售後等其他部門。這麼多部門，對應着諸多的系統都有商品相關的信息和狀態。
某個系統裏，商品的狀態信息變化了，其他系統如何第一時間掌握，並及時作出對應動作？？
比如一個簡單的問題，商品成交了退訂退貨等事件，其他相關部門怎麼知道呢，然後做相關處理，靠各系統間API調用？？只要業務跑兩三年，保證各系統間的API成百上千，
我之前供職的一家公司，上萬的員工，有個有趣的現象。供應鏈部門負責商品採購驗收和上架，公司網站展示相應的商品。但是，二者數據長期不一致，能有多不一致。說出來嚇死人，有四分之一的商品狀態幾年來一直對不上，每每想起，趕腳都會被人笑死。爲什麼會產生這樣的情況? 因爲供應鏈上架是API通知網站以及各部門，其他部門銷售了，退訂了商品等也是API調用供應鏈和網站。也就是各系統啥都是API調用，甚至什麼是上架，定義都不一致，並且API調用不夠穩定，又缺乏監控，也就是第五章說的產品技術都完全沒有掌握業務結果的意識。。。
建設主數據，採用橫向共享的設計取代系統間API調用的網狀依賴。
主數據能做什麼，一般主數據的輸出是客戶或商品全景視圖，所有業務系統將有跨業務系統需要的相關信息同步到主數據，並從全景視圖獲得其他相關的數據
主數據真正實現各個業務系統的打通
主數據通過統一的數據採集，數據存儲，數據管理，需要足夠的產品認知能力和全局業務意識。
主數據對外提供的是統一的信息查詢和信息變更服務訂閱，這裏技術實現其實並不複雜，也就是ES和MQ。
例如，銷售系統通過主數據的“商品變革信息訂閱中心”的信息訂閱獲取供應鏈上架的商品後，而供應鏈和售後等系統通過同樣的訂閱中心獲取商品是否成交的信息決定商品上下架等操作再重申幾點：
- 比較適合做主數據的也就是商品和客戶
- 理論上可以有多個主數據，但實際操作過程裏， 需要具體看情況。比如電商，商品和廣告是兩個業務線，甚至兩個事業部，各自的架構，各自的橫向共享，可能完全隔離更合適
- 選擇的重點，可以參照業務重點，比如我們到底是幫商家賣東西還是幫用戶買東西。。。
- 並不是業務一開始，上來就搞主數據，就想着橫向共享。在初期野蠻生長時候，各系統儘可能獨立，劃清界限即可
- 主數據目的是跨系統的共享主要數據的變化，應該盡最大可能不要侵入業務系統。 也就是不要讓業務系統直接把業務結果往主數據裏更新，一定是通過數據採集的方式，各業務系統儘可能不做任何變化
- 主數據不要直接產生業務數據，但可以有間接的。比如跨業務的指標（例：網站PV和成交量的比例），業務系統自身不關注的指標（例：最近10天成交率）
寫了好多，真不知道如何收尾。。。