CRM系统新思维
客戶關系管理系統(tǒng)（CRM系統(tǒng)）是管理公司當前以及未來潛在客戶的系統(tǒng)，其主要目的是通過優(yōu)化客戶關系實現(xiàn)公司銷售業(yè)績的長期增長，它是企業(yè)信息系統(tǒng)的核心之一。目前，移動互聯(lián)網(wǎng)、大數(shù)據(jù)以及人工智能技術發(fā)展日新月異，正在加速改變世界。但是在CRM等企業(yè)系統(tǒng)的構建和優(yōu)化方法論上，卻缺乏革命性的創(chuàng)新。本文作者在構建和優(yōu)化CRM系統(tǒng)的過程中總結出一些新方法論，與當下的一些先進理念不謀而合。每個具體的理念雖然并非原創(chuàng)，應用在CRM系統(tǒng)構建中還算新穎，并且所有的理念一起構成一個完整的體系。希望這些對負責CRM系統(tǒng)開發(fā)的管理者、工程師、產(chǎn)品人員有所幫助。
CRM系統(tǒng)的構建和優(yōu)化本質上是一個工程學問題。解決好一個工程學問題需要把控好四個主要環(huán)節(jié)： * 明確該工程的主要目標。 * 理清實現(xiàn)該目標的方法論。 * 構建快速支撐方法論實施的架構和系統(tǒng)。 * 打造一個優(yōu)秀的團隊。
本文基于這條線進行闡述。第一部分主要討論CRM系統(tǒng)的目標以及方法論。第二部分通過具體案例詳細闡述方法論實施。本文第三部分是關于如何設計靈活可擴展系統(tǒng)架構。最后一部分總結了在團隊管理方面的一些心得。
搭建優(yōu)秀的CRM系統(tǒng)的前提是清晰的目標，然后尋找實現(xiàn)系統(tǒng)目標的系統(tǒng)性的方法論。在方法論和目標之間建立關聯(lián)是一個復雜的分析過程。我們采用嚴謹?shù)臄?shù)學方法，從CRM系統(tǒng)目標中推導出獨特的方法論。確定了方法論之后，我們將深度闡述其具體內涵以及層次。本小節(jié)的最后一部分歸納出實現(xiàn)運營目標的路線圖（RoadMap）。
CRM系統(tǒng)目標
主流CRM系統(tǒng)的目標是實現(xiàn)運營收入的增長，嚴格的講，應該是收入預期的增長。從經(jīng)濟學的角度來講，收入預期不是一個值，而是一種分布，這就引入了“風險”的概念。所以，CRM系統(tǒng)的目標需要同時考慮風險和收入預期這兩個因素。簡而言之，CRM系統(tǒng)的目標應該是： * 實現(xiàn)收入預期最大化。 * 提高收入預期置信度。
CRM系統(tǒng)目標拆解
實現(xiàn)預期收入最大化這個目標可以從四個方面入手： * 增加客戶數(shù)量。 * 提升高質量客戶占比。 * 提高服務頻率以及延長服務時間。 * 提升運營人員服務效率，即“人效”。
CRM系統(tǒng)負責人真正能夠有效提升的因子是人效。提高人效最重要的手段就是讓機器承擔更多的工作，即“服務數(shù)字化”。
提高收入預期置信度的本質上就是降低戰(zhàn)略執(zhí)行的不確定因素，從人治模式轉型成系統(tǒng)管理模式，簡而言之就是“管理數(shù)字化”。
以上的結論經(jīng)過了嚴密的數(shù)學推導，對推導過程有興趣的同學，可以參考附錄 CRM系統(tǒng)目標拆解詳細推導。
全流程數(shù)字化閉環(huán)
根據(jù)上文，實現(xiàn)CRM系統(tǒng)目標的手段是提高數(shù)字化程度。基于此，我們提出了全流程數(shù)字化閉環(huán)概念，如下圖：
在對該圖進行詳細講解之前，先做兩點說明： * 整個閉環(huán)的起點來自于人。在目前階段，大部分的系統(tǒng)還無法完全獨立思考，這意味著它們的運轉需要外部的觸發(fā)點，也就是人。 * 整個閉環(huán)的終點也是人。決策者的想法經(jīng)過系統(tǒng)一輪循環(huán)之后，不僅產(chǎn)生業(yè)務價值，得出的反饋還會促進決策者成長。
我們對上圖進行詳細講解： * 實現(xiàn)CRM系統(tǒng)目標的前提是運營決策者戰(zhàn)略思考（Idea）。 * 工程師們負責將Idea進行數(shù)字化（Digitize），轉化成計算機能識別的策略（Policy）或規(guī)則。 * 系統(tǒng)對數(shù)字化的策略進行排期（Policy Schedule）。 * 排完期的策略將會被定期執(zhí)行（Policy Execution）。 * 策略執(zhí)行的結果是可具體執(zhí)行的一系列任務（Tasks）。 * 通過系統(tǒng)，一線運營人員負責任務執(zhí)行（Task Implementation）。 * 執(zhí)行完畢后，執(zhí)行者需要做一些紀錄（Record）。 * 系統(tǒng)收集記錄以及其他效果數(shù)據(jù)，形成統(tǒng)計數(shù)據(jù)（Statistics）。 * 統(tǒng)計數(shù)據(jù)將被制作成各種圖表或者報告（Report）。 * 運營決策者通過直接查看圖表的方式，或者接受系統(tǒng)的自動化分析（Analysis）結論獲得反饋。
每一輪循環(huán)都會提升運營決策者，決策者的提升反過來會促進CRM系統(tǒng)的改進。全流程數(shù)字化閉環(huán)本質上是決策者和系統(tǒng)不斷相互促進的過程。
數(shù)字化層次
既然核心方法論是“全流程數(shù)字化閉環(huán)”，我們需要先深入探討一下什么是數(shù)字化。數(shù)字化本身是一個非常抽象的概念，不同的人有不同的理解。我們根據(jù)在CRM系統(tǒng)的實踐經(jīng)驗，總結出了數(shù)字化的三個層次，即標準化、自動化和智能化。 * 標準化。標準化是數(shù)字化的基礎，物理世界絕大多數(shù)事物都是連續(xù)的（Continuous），而計算機只能保存離散的數(shù)據(jù)，所以標準化的核心是離散化、結構化。我們一般把靜態(tài)的（static）數(shù)據(jù)模型和概念的數(shù)字化稱為標準化，比如：賬戶、工單、分配等。 * 自動化。自動化指的是動態(tài)過程的數(shù)字化，比如流程、戰(zhàn)略、權限控制的數(shù)字化。“動態(tài)”意味著與時間相關，狀態(tài)之間存在依賴關系。 * 智能化。智能化是當下非常流行的概念，直觀的理解就是讓系統(tǒng)具備思考能力。所以，智能化包含兩種：第一種是分析過程的數(shù)字化，這意味著系統(tǒng)在比較確定的上下文中具備分析能力。第二種指的是在系統(tǒng)中應用統(tǒng)計學方法（Statistical Methods）、機器學習算法（Machine Learning）使其具備一定的學習、推理和思考能力。
業(yè)務分析
“數(shù)字化”并非空中樓閣，它是具體業(yè)務的數(shù)字化，本質上也是一種“物化”。從運營業(yè)務的角度如何看待CRM系統(tǒng)？傳統(tǒng)觀點認為CRM系統(tǒng)是一個“操作平臺”和“分析平臺”。對于像美團點評這樣級別公司，其CRM系統(tǒng)的使用人員很多，所以它是“高頻操作平臺”。此外，“全流程數(shù)字化”蘊含著“管理數(shù)字化”的概念，所以CRM系統(tǒng)是“戰(zhàn)略執(zhí)行平臺”。最后，優(yōu)秀的CRM系統(tǒng)要考慮人的因素，因人而設計，與人互動。對于擁有龐大運營團隊的CRM系統(tǒng)而言，團隊士氣的高低對“運營目標達成”的影響很大，所以，CRM系統(tǒng)是“激勵平臺”。綜上所述，CRM系統(tǒng)是“高頻操作平臺”、“戰(zhàn)略執(zhí)行平臺”、“激勵平臺”和“分析平臺”，如下圖:
RoadMap
以上分析指明了CRM系統(tǒng)目標以及實現(xiàn)該目標的方法論，但這些僅是抽象的概念。在現(xiàn)實生活中，我們實實在在擁有的只是一個技術和產(chǎn)品團隊。利用這個團隊去實現(xiàn)“運營目標達成”需要一個金字塔狀的RoadMap，如下圖：
- 金字塔最上層是CRM系統(tǒng)的最終目標，即“運營目標達成”。
- 下面一層是方法論，即“全流程數(shù)字化閉環(huán)”，具體而言指的是“運營業(yè)務數(shù)字化”和“運營決策數(shù)據(jù)化”。
- 所有的目標都要在規(guī)定的時間內完成，而完全數(shù)字化所需的時間是無限長。所以我們需要在有限的時間內高質量地實現(xiàn)盡可能多的重要功能的數(shù)字化，這就需要“靈活可擴展的系統(tǒng)架構”，這是第三層。
- 最底層是物理世界，即團隊，它必須是“具備創(chuàng)新意識、強執(zhí)行力的團隊”。
上文已經(jīng)談到數(shù)字化是一個層次化的概念，要想真正深入理解它并靈活應用到實際工作中，需要大量的實踐。本小節(jié)將重點闡述如何實現(xiàn)CRM系統(tǒng)的全流程數(shù)字化。同時，整個數(shù)字化闡述以及各個案例的講解過程也是幫助讀者進行數(shù)字化實踐的旅途，將會有助于讀者深入理解“數(shù)字化”。
高頻操作平臺數(shù)字化
這個過程需要三個步驟： * 高頻處理流程梳理。 * 高頻處理流程數(shù)字化。 * 流程中關鍵節(jié)點數(shù)字化。
高頻流程梳理
CRM系統(tǒng)的典型高頻處理流程包含三個節(jié)點：搜索客戶、分析客戶和客戶觸達，如下圖：
高頻流程數(shù)字化
流程數(shù)字化有兩層含義：閉環(huán)流程自身的標準化以及閉環(huán)流程操作方式的標準化。
“閉環(huán)流程本身標準化”意味著需要一個概念去描述完整的基本高頻操作閉環(huán)。我們把完整的“搜索客戶”、“分析客戶”和“客戶觸達”閉環(huán)稱之為工作單元，簡稱“工單”。所以高頻操作本質上就是對工單列表的順序操作。
談到閉環(huán)流程操作方式，嚴格地講，用戶的操作是一個圖（Graph）或者樹（Tree），而我們的目標就是要盡量讓高頻流程操作形成一個鏈表（List）結構。從技術上講，這會帶來兩個好處： * 鏈表式操作容易進行人效優(yōu)化。與鏈表相比，對圖或樹進行優(yōu)化要復雜很多。 * 鏈表式操作隱式地自動進行目標管理。圖或者樹式操作類似于隨機過程（Stochastic process），操作人員需要不停的做決策，記住每次操作的下一步目標。持續(xù)地進行高強度、高頻率的決策工作，這對操作人員的要求很高，很容易導致其疲勞或者目標迷失。采用鏈式操作模式，鏈表中節(jié)點之間的流轉固定，這近似于一個確定過程（Deterministic process）。
基于以上分析，我們做了兩方面的抽象： * 引入了工單（Task）的概念，并且將閉環(huán)的操作入口固定為“工單列表”。 * 工單操作主流程鏈式化。
高頻流程的數(shù)字化結果如下圖：
搜索客戶數(shù)字化
高頻操作流程的第一步就是搜尋客戶，實現(xiàn)該功能的最樸素的產(chǎn)品是多維度的客戶搜索、篩選功能。運營人員通過組合各種篩選項和搜索條件尋找目標客戶。這種操作方式類似于用戶在Amazon或者Taobao上購物。顯然這是低效的操作模式，在搜索客戶數(shù)字化方面，我們將進行三個層次的優(yōu)化，即：標準化、自動化和智能化。
搜索客戶標準化
搜索客戶的低效源自于搜索篩選條件的復雜，以及重復的搜索操作，所以最直接的解決方案就是讓系統(tǒng)記住這些復雜的篩選項，并避免重復搜索。基于此，我們的第一個改進措施是將“搜索模式”轉變成“分配模式”，具體而言，就是從“搜索客戶”轉向“分配工單”，它所導致的變化如下圖：
運營人員的操作模式從上圖左邊的循環(huán)轉變成了右邊的循環(huán)。這樣一個看似簡單的變化是對于人效提升而言卻是本質性的改進。從理論上講，我們取得了三個方面的進展： * 搜索操作效率改進。分配模式是一次搜索、大量分配，運營人員搜索次數(shù)從n降成1。 * 決策優(yōu)化。分配本質上是一個決策的過程，根據(jù)心理學理論，高質量的決策需要一定的時間。實施決策和操作分離，我們可以期望更高質量的決策。 * 上圖左邊的循環(huán)包括“搜索”和“操作”，右邊的循環(huán)只包含“操作”，顯然更小的循環(huán)有助于提升效率。理論上講，循環(huán)越小，上下文切換（Context Switch）成本也就越小，使用者熟練度也會提升，目標也更聚焦，所以人效也就自然得到提高。
在分配模式下，我們還可以為每次分配設置跟進優(yōu)先級。這就引入了“偏序（Partial Order）”的概念，這意味著，客戶之間不僅僅有是否需要跟進的區(qū)別，從跟進優(yōu)先級的角度來講還是可以比較的。眾所周知，無論工作還是生活，我們都應該“做正確的事情”。“偏序”概念的引入讓決策者具備了優(yōu)先安排正確工作的能力，讓執(zhí)行者具備了優(yōu)先做正確的事情的能力。
具體而言，工單分配就是將客戶分配給運營人員的過程，包含如下圖四塊：
- 客戶召回，通過對客戶的屬性和特征進行篩選和搜索實現(xiàn)。
- 運營人員召回，通過對運營人員的屬性和特征進行篩選和搜索實現(xiàn)。
- 匹配，將召回運營人員和客戶進行關聯(lián)。
- 生成工單，客戶與運營人員的關聯(lián)結果稱之為分配，分配的結果以及預期的執(zhí)行稱之為工單。
搜索客戶自動化
工單分配實現(xiàn)了n次搜索操作向1次分配操作的轉變，這是空間維度的人效提升，例如，運營管理層可以一次為多個運營人員分配工單。但是，運營決策者仍然需要定期進行工單分配，這也是一種重復勞動。所以，我們可以從時間維度提高人效。這種讓機器代替人來執(zhí)行重復操作的過程是一種自動化。自動化分配一般由規(guī)則引擎（Rule Engine）和調度系統(tǒng)（Scheduler）共同完成。這里的一個核心概念就是規(guī)則（Rule），它的核心內涵包括如下四個方面： * 召回細則（Recall Policy），指的是客戶篩選屬性和運營人員篩選屬性集合。 * 匹配細則（Match Policy），指的是對召回的客戶和運營人員進行匹配的規(guī)則或者模型。 * 排期（Schedule），指的是規(guī)則執(zhí)行頻率，即該規(guī)則多久執(zhí)行一次。 * 有效期（Lifetime），指的是規(guī)則從第一次執(zhí)行到最后一次允許執(zhí)行的生命周期。
規(guī)則（Rule）是上面四個概念的集合體，更復雜的規(guī)則還可以指定執(zhí)行優(yōu)先級等。
通過調度系統(tǒng)和規(guī)則引擎進行分配自動化的功能圖如下：
- Scheduler定期去查看Rules。
- 處于有效期內，到了執(zhí)行點的Rule將被Scheduler發(fā)送給Rule Engine。
- Rule Engine對Rules進行解釋和執(zhí)行，生成工單分配。為了執(zhí)行規(guī)則，Rule Engine還需要其他輔助Data才能完成工單分配。
搜索客戶智能化
最少可以從兩個維度去提高客戶分配的智能化：召回規(guī)則、匹配規(guī)則。同時，如上文所述，智能化的手段有兩個：分析過程數(shù)字化和規(guī)則模型化。
精確篩選高優(yōu)先級的客戶是一個非常復雜的分析過程，大部分的篩選和搜索操作都是基于客戶的靜態(tài)屬性完成的，比如賬戶的消耗、余額等等。現(xiàn)實生活中，對客戶的理解和分析卻是動態(tài)的，我們根據(jù)客戶過去一段時間的變化或者趨勢去識別客戶。幾乎不可能把所有時間維度的特征納入到篩選中，有幾個原因： * 人們對概念的理解基本上是靜態(tài)的。雖然每個人都具備動態(tài)理解能力，但是人們并不容易在動態(tài)思考上達成一致意見。 * 動態(tài)的特征轉換成篩選項，意味著在篩選項之間引入了邏輯關系，而不僅僅是簡單的集合關系。這種產(chǎn)品將很難理解，對使用者要求極高，用戶體驗極差。
在賬戶分析過程數(shù)字化方面，我們采用典型分析思路標準化的策略。具體做法如下： * 將典型的、已經(jīng)被證明有效的分析過程整體進行數(shù)字化。 * 整個分析過程的數(shù)字化后形成一個抽象的召回細則。這個復雜抽象的召回細則整體作為一個篩選項供用戶篩選，換句話說，一個篩選項意味著整個分析過程。 * 為了讓使用者明白復雜召回細則，工程師需要與使用者進行必要的溝通，所以對復雜召回細則的理解是通過線下溝通實現(xiàn)的。
規(guī)則模型化比較容易理解。實施召回規(guī)則和匹配規(guī)則，除了采用確定性的（Deterministic）規(guī)則，我們還可以采用自適應（Adaptive）的統(tǒng)計學模型（Statistical Model）。這也是我們通常意義的智能化。
客戶分析數(shù)字化
優(yōu)質的客戶服務需要長時間的客戶分析，所以這一塊的優(yōu)化空間很大。
客戶分析標準化
把客戶的各種信息采用圖、表或其他友好的產(chǎn)品形式進行展示稱之為客戶信息標準化，本質上信息可視化的過程。有了標準化的客戶信息展示之后，通過基本的培訓，運營人員就能掌握標準的客戶分析方法。采用這種分析方式得出的結論將會有助于提升運營效果。
客戶分析自動化、智能化
對客戶分析過程類似于醫(yī)生對病人進行診斷。現(xiàn)在醫(yī)學之前，醫(yī)生通過望聞問切等方式來對病人進行診斷。這種診斷方式有幾個缺點： 首先，它對診斷者的要求比較高，一般必須是醫(yī)生本人。 其次，比較浪費時間，除非能夠標準化，完整的記錄整個診斷結果，即使短時間內針對同一個病人，醫(yī)生仍然需要重復診斷（或者這個醫(yī)生一天只有幾個病人，所以能全部記住）。 最后，即使對一些簡單的病狀，醫(yī)生之間也不容易達成一致。 現(xiàn)代醫(yī)學將診斷和看病分開，診斷的工作交給護士和機器來完成，診斷的結果非常精確。對于簡單的診斷，普通人就能明白如何處理。
在客戶分析自動化、智能化方面，我們借鑒了現(xiàn)代醫(yī)學自動診斷思想。把一些典型的客戶診斷分析過程進行數(shù)字化。一般而言，典型的診斷分析涵蓋了客戶的大部分問題，符合80/20法則。這不僅僅提高了運營人員的分析人效，還大大提高了客戶分析的精確性和一致性。
客戶觸達數(shù)字化
可以從很多維度對客戶觸達進行數(shù)字化，CRM系統(tǒng)的終極目標當然是機器人直接觸達客戶，解決客戶的所有問題。目前，還沒有公司完全實現(xiàn)這個目標。典型的數(shù)字化思路有如下幾種： * 交互式語音應答（IVR）解決典型問題。 * 智能化Q&A。這包括采用智能搜索技術對結構化和非結構化的知識庫進行查詢、運用語音識別技術協(xié)助運營客服等。 * 客服質量檢查。通過語音識別技術將客服人員的語音轉換成文字，進行語法、語義分析，查找惡意作弊行為，識別并改進低質量的語音服務，推廣并培訓高質量的服務。
戰(zhàn)略執(zhí)行平臺
戰(zhàn)略執(zhí)行數(shù)字化非常復雜，大數(shù)據(jù)和人工智能技術使得其數(shù)字化變的可能。通俗的理解，戰(zhàn)略執(zhí)行數(shù)字化就是要將運營決策者的復雜抽象的戰(zhàn)略通過系統(tǒng)轉化成一個個可以具體執(zhí)行的任務。戰(zhàn)略執(zhí)行數(shù)字化降低了從戰(zhàn)略規(guī)劃到最終執(zhí)行過程中產(chǎn)生的方差，通過系統(tǒng)實現(xiàn)了全流程的監(jiān)控，最終提高了戰(zhàn)略目標實現(xiàn)的置信度。
一個中等規(guī)模的目標就需要戰(zhàn)略，所以戰(zhàn)略數(shù)字化應用非常廣泛，上文中談到的“工單分配標準化、自動化和智能化”就是一個典型的戰(zhàn)略執(zhí)行數(shù)字化的例子。但是，“戰(zhàn)略執(zhí)行”數(shù)字化的確是非常復雜抽象的概念，它給需求提供方和系統(tǒng)實施者帶來了巨大的挑戰(zhàn)。本小節(jié)將通過一個具體例子來講解“戰(zhàn)略數(shù)字化”的完整實施過程。整個講解過程詳細闡述了我們在實施過程中面臨的挑戰(zhàn)、應對挑戰(zhàn)的思考方式，以及在具體實施過程中的關注點和所做的妥協(xié)。到目前為止，在“戰(zhàn)略數(shù)字化”方法論方面，我們取得的進展是“編碼化”。
編碼化（Codify）
戰(zhàn)略執(zhí)行數(shù)字化對CRM系統(tǒng)負責人的最大挑戰(zhàn)來自于如何快速實施和快速應對變化。在具體實施中，需要重點解決如下問題： * 明確“戰(zhàn)略數(shù)字化”的目標和方向。 * 需求方和實施方在“戰(zhàn)略數(shù)字化”概念和內容上取得一致的理解。 * 在需求方和實施方之間建立標準語言，即標準化的需求文檔。 * 快速將標準化需求轉換成系統(tǒng)。
這四個步驟合在一起，我們稱之為“編碼化”，具體例子詳見編碼化實施。
激勵平臺
這是一個不證自明的道理，士氣影響團隊產(chǎn)出。CRM系統(tǒng)游戲化（Gamification）的理念很早就被提出，但在這塊的實施往往沒有給予應有的重視。移動互聯(lián)網(wǎng)時代，人類幾乎成了系統(tǒng)的奴隸。顯然，優(yōu)秀的CRM系統(tǒng)需要去擁抱這兩個現(xiàn)實，讓運營人員和系統(tǒng)能夠實現(xiàn)更好的互動，進而提升運營人員的興趣、士氣，從而提高運營收入。
分析平臺
網(wǎng)上有大量文章闡述如何構建優(yōu)秀的分析平臺。我們從實踐過中總結出兩個獨特的建議： * 為每種角色、甚至每個人提供定制化的分析平臺。這有兩層意義，第一，每個人都應該通過數(shù)據(jù)去決策，所以分析平臺要盡可能適應每個人的需求。第二、標準化分析是比較專業(yè)的工作，不同角色、不同人的分析能力不同，分析平臺必須非常貼合具體角色的能力要求。單一的分析方式總是有利于一部分人，而不利于另外一部分人，更精確的講，它不利于所有人。 * 分析平臺要具備“實時查詢、即查即得”的特征。據(jù)作者的觀察，由于大數(shù)據(jù)量的原因以及傳統(tǒng)的數(shù)據(jù)倉庫（Data Warehouse）的一些固有理念，大部分分析平臺都無法實現(xiàn)“即查即得”的要求，它們通過滯后的郵件或者CSV文件格式來提供分析結果。這增加決策者的數(shù)據(jù)分析時間，降低了其分析效率。在很多場景下低劣的用戶體驗會導致用戶放棄使用該產(chǎn)品功能。為了實現(xiàn)“實時查詢、即查即得”，我們自己編寫中間件去解決數(shù)據(jù)量和查詢性能問題。另外，對于一些使用場景少并且性能消耗很嚴重的需求，架構師需要進行一些取舍。畢竟，系統(tǒng)的目標不是實現(xiàn)所有的需求，而是實現(xiàn)所有人的需求收益最大化。
對于構建CRM系統(tǒng)而言意味著：必須要用最小的投入，完成最關鍵的目標。這就對系統(tǒng)架構的靈活可擴展性提出了很高的要求。
如何構建靈活可擴展的系統(tǒng)架構是一個開放式的問題，仁者見仁，智者見智。通過實踐，我們總結出構建靈活可擴展系統(tǒng)的四個準則：定制化、配置化、組件化和重引擎輕數(shù)據(jù)庫。
定制化（Customerization）
定制化指的是為不同的人提供不同的產(chǎn)品，從某種角度來說，這是一種空間適配的概念。CRM系統(tǒng)是高頻操作平臺，所以幾乎每個用戶都是高級用戶，為每個人提供定制化的產(chǎn)品必然能夠提高運營人效。但是，為每個用戶開發(fā)一套系統(tǒng)的成本太高，并不現(xiàn)實。所以，定制化指的是用一套技術架構提供不同的產(chǎn)品，具體的講就是用戶可以通過配置方式定制的滿足個性化需求的獨特產(chǎn)品展現(xiàn)形式。
配置化（Configuration）
如果說定制化是一種空間適配，配置化就是時間適配，它指的是產(chǎn)品隨著時間發(fā)生了變化，但是不需要額外開發(fā)工作。配置化是內容管理系統(tǒng)（CMS系統(tǒng)）的核心思想。具備了配置化功能的系統(tǒng)，新產(chǎn)品的上線或者老產(chǎn)品內容的更新不需要工程師的額外開發(fā)工作，系統(tǒng)管理者可以通過簡單的配置實現(xiàn)。
什么場景能夠進行配置化并沒有一個標準的答案。但是，配置化和模板化往往是孿生兄弟，所以我們可以從模板化的概念中得到一些啟示。設計模式里面的模板方法模式（Template method pattern）指的是在父類中實現(xiàn)框架，在子類中實現(xiàn)具體方法。類似的，一個產(chǎn)品功能是否具有模板化的特征，取決于其主體框架是否能夠保持不變，功能細節(jié)是否變化頻繁。如果一個功能具有模板化的特征，設計者就可以嘗試配置化的設計。
組件化（Componentization）
CRM系統(tǒng)非常復雜，包含眾多子系統(tǒng)。這些子系統(tǒng)共同組成一個有機的整體，在具體的產(chǎn)品開發(fā)過程中，一個小功能點往往需要對多個子系統(tǒng)進行修改。牽一發(fā)而動全身，這不利于產(chǎn)品快速交付。有很多系統(tǒng)架構理論用于解決類似問題，例如：SOA、高聚合低耦合（High Cohesion, Loose Coupling）等。我們同樣花了很長時間去思考和解決此類問題，最終形成了自己獨特的方法。我們稱這個方法論為“組件化”，需要注意的是，這里與業(yè)界通行術語的含義并不完全一致。組件化由四個步驟組成： * 長業(yè)務分組件。 * 組件專人負責。 * 組件功能聚焦。 * 組件之間解耦。
對于組件化四步驟，這里做一些說明。
什么樣的業(yè)務是“長業(yè)務”？如上文所述，頁面上的一個小功能點需要多個系統(tǒng)協(xié)作才能完成的情況比比皆是，所以大部分業(yè)務都是長業(yè)務。整個CRM系統(tǒng)設計都應該盡可能的按功能切分成子系統(tǒng)，子系統(tǒng)內部按照功能點進行再切分。例如，在我們CRM系統(tǒng)里面，所有與篩選相關的功能都被放到“篩選引擎”里面，所有數(shù)據(jù)獲取功能由“DataService”服務提供，所有的報表都由“ReportEngine”來完成。
“組建專人負責”看起來是管理學的問題，但是卻是非常高效的手段。經(jīng)驗表明，對系統(tǒng)熟悉的工程師在產(chǎn)品需求交付速度上有很多倍的提升。隨著熟練度的增加，專職工程師能夠接受更具挑戰(zhàn)的任務、提出更具創(chuàng)新性的思路。
后面兩步驟基本上就是設計高聚低耦的系統(tǒng)。雖然有很多關于如何設計“高聚低耦”系統(tǒng)的資料，在實際工作中這一點對很多工程師的挑戰(zhàn)還是比較大。
我們這里舉一個例子來形象地展示“什么樣的系統(tǒng)架構具備組件化設計標準”。對于很多產(chǎn)品而言，篩選和搜索都屬于復雜度比較高的系統(tǒng)，于此同時，新的業(yè)務需求導致篩選項不斷增加。這在我們的CRM系統(tǒng)中表現(xiàn)非常明顯。通過采用如下樹狀架構圖，我們的篩選引擎具備快速支持新篩選需求的能力。
采用如上架構圖，一個新的篩選需求對于工程師而言意味著三件事情之一： * 修改現(xiàn)有的篩選邏輯，即修改架構圖中的某個或者幾個節(jié)點代碼。 * 添加節(jié)點。在上面的架構圖中，添加節(jié)點只意味著最多和兩個現(xiàn)存節(jié)點之間有關聯(lián)，這實現(xiàn)了對現(xiàn)有系統(tǒng)入侵性最小化。 * 在Combiner下面添加完整的一個篩選鏈條，這個鏈條的代碼是完全獨立的，現(xiàn)有系統(tǒng)中只有Combiner需要修改。
無論哪種修改方式，新需求與現(xiàn)有系統(tǒng)的耦合非常少，開發(fā)非常輕。我們的報表引擎、分配引擎、診斷引擎都遵循類似的架構設計標準。
重引擎輕數(shù)據(jù)庫
Spark被認為是非常靈活的系統(tǒng)，它的核心思想之一就是把操作保留在內存里面，避免保存大量的中間結果數(shù)據(jù)。借鑒這個思想，為了快速支持系統(tǒng)數(shù)字化，我們的CRM系統(tǒng)引擎層做的比較重，盡可能的在引擎層去實現(xiàn)所有計算邏輯。除此之外，重引擎層還有如下幾個原因： * 需要進行數(shù)字化的業(yè)務方向非常多，類似業(yè)務有很大的共通性，業(yè)務之間并不具備互通性。組件化要求為不同的業(yè)務構建不同的引擎。 * 根據(jù)以上論述，對業(yè)務進行數(shù)字化的主要模式是：梳理典型業(yè)務邏輯，然后進行數(shù)字化。從技術的角度來看，這相當于對流程或分析過程進行數(shù)字化，這正是引擎的概念。 * 熟能生巧，每個業(yè)務引擎由專職工程師負責，這會讓整個團隊在引擎的思考深度和產(chǎn)品交付速度上有明顯的改善。
對于數(shù)據(jù)庫的使用，我們的態(tài)度是數(shù)據(jù)庫只負責存儲，計算盡可能由引擎實現(xiàn)。沒有辦法去證明這個觀點的正確性。因為存在反例，SQL的功能非常強大，某些團隊利用SQL去維護大項目，解決復雜問題。但是我們拒絕數(shù)據(jù)庫進行計算有如下理由： * CRM系統(tǒng)的需求變化頻繁，復雜的SQL語句很難實現(xiàn)“高聚低耦”。一個小需求變更可能意味著整個龐大的數(shù)據(jù)庫語句修改，很多時候難以接受。或許擁有眾多專業(yè)DBA可以緩解此類問題，但是前提是一定不能以犧牲項目迭代周期代價。 * 采用數(shù)據(jù)庫進行計算往往意味著重量級地使用Object-relational mapping框架。現(xiàn)實情況是，并非所有的工程師對于如何使用和優(yōu)化這些框架都熟悉，但是他們卻必須要全方位得快速解決所有業(yè)務問題。 * 大量采用SQL還存在一些安全隱患，并非所有工程師都是專業(yè)的安全工程師。 * 對于計算密集的業(yè)務，數(shù)據(jù)庫在性能上沒有保障。并且，數(shù)據(jù)庫性能調優(yōu)并非所有開發(fā)工程師所擅長。 * 大部分系統(tǒng)需要共享同一個數(shù)據(jù)庫，將計算交給數(shù)據(jù)庫意味著產(chǎn)品功能開發(fā)之間通過數(shù)據(jù)有了強耦合關系。 * 總的來說，數(shù)據(jù)庫比較擅長集合操作，在邏輯操作方面比較弱。
“重引擎輕數(shù)據(jù)庫”本質上是一個技術選型的問題，技術選型第一要素當然是滿足業(yè)務需求。滿足這個必要條件之后，人的因素就是技術選型的重要標準：團隊成員是否熟悉該技術，學習該技術成本是否高，使用該技術的風險是否大，都是重要考慮因素。
團隊管理是任何管理者都無法回避的問題，它是整個Roadmap的第一層。同時，它也一個非常大的話題，而且往往非常主觀，我們試圖總結一些比較客觀的經(jīng)驗。
創(chuàng)新、積極向上的團隊
創(chuàng)新意識和積極向上是保持團隊長期高效穩(wěn)定的基礎。顯而易見“正能量價值觀”和“關注個人成長”必然會促使團隊積極向上，并提高團隊成員的創(chuàng)新意識。
關于“正能量價值觀”這一塊，基本理解是：人們只會在愿意創(chuàng)新的地方去創(chuàng)新，只會對感興趣的事情表現(xiàn)出積極。幸運的是CRM系統(tǒng)解決的問題是非常正能量的，因為它的目標是提高運營人員的生產(chǎn)力，而提高生產(chǎn)力是人類最偉大的目標之一！所以，只要導向正確，很多工程師會對CRM系統(tǒng)表現(xiàn)出強烈的興趣。
關注個人成長很重要，畢竟成長是很多人的重要工作目標之一。沒有成長的團隊很難激發(fā)創(chuàng)新意識。對于一個團隊而言，實現(xiàn)個人長期持續(xù)的發(fā)展要關注兩點： * 納什均衡（Nash equilibrium）。在團隊管理里面，納什均衡指的是每個人要在團隊里面有自己清晰的定位。要實現(xiàn)這一點，為每個工程師找到一些能夠長期持續(xù)驅動的項目非常重要。 * 定位要盡量符合個人特長。進入社會之后，工程師之間在經(jīng)驗、特長都會有所不同。大家統(tǒng)一定位，則意味著忽視個性。這一方面意味著不公平，另一方面意味著壓制創(chuàng)新。為了盡可能讓工程師的定位符合其個人特長，團隊需要很多對能力類型要求不同的長期項目。
所以關注個人成長的一個重要措施就是挖掘出很多開放式的項目。幸運的是，CRM系統(tǒng)的“全流程數(shù)字化閉環(huán)”包含許多具有挑戰(zhàn)、值得探索的項目。
高執(zhí)行力
在提高團隊執(zhí)行力這塊，我們有三個總結：客戶價值、并行工作（Multitasking）和敏感度把控。
強調技術的客戶價值非常重要。一個沒有客戶使用，不能幫助客戶提升生產(chǎn)力的系統(tǒng)或者架構沒有價值。衡量執(zhí)行力的標準不是做了多少事情，而是給客戶帶來了什么好處。做一個簡單的算術題：假定有兩個團隊，A團隊60%的項目有價值，B團隊90%的項目有價值。為了實現(xiàn)同樣的業(yè)務目標，A團隊需要B團隊1.5倍的人力，人員成本增加是驚人的。
對CPU的進行多線程調優(yōu)，工程師們比較熟悉。對于團隊執(zhí)行力而言，并行工作同樣重要。可以從三個方面去提高團隊的并行工作能力： * 大團隊要分成獨立工作小組，提高團隊同時承接多項目的能力。對于美團點評這樣公司，工程師們的單兵作戰(zhàn)能力比較強，所以兩三個、甚至一個工程師可以獨立承接一個小項目。無論如何，把大團隊按照項目承接能力拆分成獨立工作小組都能提高團隊整體承接項目的能力。 * 提高個人并行工作能力。大部分人習慣于在一段時間專注一件事情，如果這個事情被阻塞住了，整個人就容易進入到閑置狀態(tài)（Idle）。早期的CPU就是這種工作模式，多任務（Multitasking）技術大大提高了CPU的工作效率，這同樣適用于工程師。 * 每個人要有自己主導的重要的開放式的項目。大家都知道“重要”和“緊急”的經(jīng)典理論，這里不詳述。理論上講，“緊急”需求占個人工作時間的比重應該是比較低的，或者說管理的目標之一就是減少“緊急”任務占個人工作時間的比重。當沒有緊急需求的時候，或者當前需求被阻塞的時候，工程師需要迅速找到其他重要任務去完成。讓每個工程師都有自我驅動的重要的開放式的項目是實現(xiàn)這個目標的關鍵。
項目敏感度控制和團隊成員松弛度管理非常重要。大部分團隊或者中等規(guī)模以上的項目都不是鐵板一塊，它們都有自己的結構或拓撲（Topology）。依據(jù)經(jīng)典運籌優(yōu)化理論，對敏感資源的少量投入往往能夠極大的提高最終的目標產(chǎn)出。通俗的講，很多公司或者團隊所謂的忙碌，都是結構性的忙碌，“忙的忙死，閑的閑死”。舉例來說，一個典型CRM開發(fā)團隊應該包含：產(chǎn)品經(jīng)理、前端工程師、后臺工程師、數(shù)據(jù)工程師、測試工程師等等。在一段時間內，各種角色的配置比例是相對固定，但是每個項目對各種資源的使用比例基本上不一樣。假如某個項目前端工程師資源很緊張，項目管理者就必須好好利用前端工程師資源。從敏感度和松弛度管理的角度，我們可以從兩方面進行優(yōu)化：第一、砍掉一些前端資源要求很高，但是重要性低的需求。第二、引入前端資源不密集的項目，把兩個項目合成一個項目，變相地增加前端資源。
本文以CRM目標為出發(fā)點，創(chuàng)新性的推導出“全流程數(shù)字化閉環(huán)”方法論。基于此，本文探討了“數(shù)字化層次”以及構建CRM系統(tǒng)的完整RoadMap。本文的后面部分都是基于該RoadMap進行講解的。
我們花了很大的篇幅去闡述“數(shù)字化”實施，從業(yè)務的角度講，它關注CRM系統(tǒng)。本質上講，整個互聯(lián)網(wǎng)的發(fā)展歷程就是傳統(tǒng)業(yè)務的數(shù)字化的歷史。所以，本文的關于“數(shù)字化”思想適用于任何系統(tǒng)，任何領域。這種思考問題的方式既適用于工程師，也適用于產(chǎn)品人員、管理者甚至創(chuàng)業(yè)者。
在系統(tǒng)架構和團隊管理方面，本文總結了作者所在團隊一些最重要的經(jīng)驗。所謂“天下大事，必作于細”，實際工作往往要繁瑣很多，我們需要關注更多細節(jié)，沒有完備性的解決方案。“天下難事，必作于易”，所有復雜繁瑣的事情都是通過少數(shù)重要的準則去分析解決的。本文在系統(tǒng)架構和團隊管理方面所給出的建議是我們在日常工作中最經(jīng)常使用的一些準則，堅持這些準則極大地提高了我們在產(chǎn)品交付方面的能力。
CRM系統(tǒng)目標拆解詳細推導
我們采用經(jīng)典運籌學分析方法拆解“收入預期最大化”目標。首先需要對客戶進行離散化，將收入預期相近的客戶分入同一個級別，目的是對客戶進行分級。每個級別內的客戶形成一個等價集合。收入預期最大化即Maximize(ERevenue)。收入預期ERevenue用如下公式表示：
公式中Customer_Num(inLevel)表示某個處于某個級別的客戶總量，ERevenuePerCustomer(inLevel)表示該級別單客戶收入預期。 根據(jù)公式，可以從兩個方面優(yōu)化收入預期： * 增加Level的數(shù)量將使得ERevenue變得更加精準。 * 提高單客戶收入預期。
單客戶收入預期與如下因素成正比例關系： * 其所處的級別，用LevelFactor表示。公式表示如下：
該客戶的服務頻率（ServiceFrequency）和單次服務時間（PeriodPerService）的乘積。公式表示如下：
單位時間的服務效率（ServiceEfficiency），通俗的說法就是“人效”。公式表示如下：
所以如下四方面的改進可以潛在的提高收入預期： * 客戶數(shù)量增加。 * 高質量客戶占比提升。 * 更高頻率的服務以及更長的服務時間。 * 提升運營人員服務效率，即“人效”。
在這些因素里面，高質量客戶占比提升既是改進的目標，也是改進的結果。單純地提高客戶數(shù)量、服務頻率以及服務時間是樸素而有效的方法，但是它要遵循一定的約束，也就是成本。可以用如下公式來表示：
運營人員的數(shù)量（OperatorNum）是由預算決定的，運營人員的工作時間（WorkingHour）相對固定的，所以這兩個因素往往非CRM系統(tǒng)負責人所能決定。所以，CRM系統(tǒng)負責人真正能夠有效提升預期收入的因子是人效。顯然提高人效最重要的手段就是讓機器承擔更多的工作，即服務數(shù)字化。
“提高收入預期置信度”，即Maximize( Confidence (ERevenue))，本質就是減少方差。實現(xiàn)一個稍具規(guī)模的目標就需要一個完善的規(guī)劃，任何的規(guī)劃都包含兩部分：確定性部分和非確定性部分。非確定性部分包括市場環(huán)境突變、重大自然災害等等，CRM系統(tǒng)的應對措施并不多。規(guī)劃的確定性部分一般可以通過工作流圖進行描述。工作流圖的實施過程會引入很多不確定因素，這包括：節(jié)點流轉不暢通、信息不對稱、關鍵指標衡量標準不一致、關鍵節(jié)點的監(jiān)控不到位等。在傳統(tǒng)的工程實施里面，這部分屬于項目經(jīng)理的管理范疇，但是單純的人治容易引入的很大的方差。管理數(shù)字化是降低方差的重要手段，也是目前的趨勢。從某種程度上講，數(shù)字化程度越高，方差也就越小，收入預期置信度也就越高。
編碼化實施
實施的前提是需求方和實施方在數(shù)字化目標方面取得一致。戰(zhàn)略數(shù)字化非常抽象費解，對于具體某個戰(zhàn)略，類似“什么是數(shù)字化”、“如何實現(xiàn)數(shù)字化”等關鍵問題，需求方和實施方達成一致理解并不容易。不能取得一致的理解會導致兩個嚴重后果： * 需求方不知道何時以及如何提需求，不知道什么戰(zhàn)略可以實現(xiàn)數(shù)字化。 * 將雜亂無章的定性需求轉化成系統(tǒng)對于實施方的挑戰(zhàn)和壓力很大。
我們從典型的“業(yè)務流程管理”（Business Process Management）中得到一些啟發(fā)。工作流業(yè)務的典型開發(fā)過程是： * 梳理出一些典型的業(yè)務工作流程，進行制度化。 * 完成制度化之后。系統(tǒng)有很多節(jié)點是可快速擴展的，對于類似的流程，系統(tǒng)具備了快速實施的能力。 * 對于不符合工作流思想的流程，很多情況我們不是對系統(tǒng)進行重構，而是修改并規(guī)范流程。
同理，雖然從業(yè)務的角度，有各種各樣的戰(zhàn)略需要進行數(shù)字化。但是大部分戰(zhàn)略具有一定的共同特征，并且最重要的戰(zhàn)略類別可枚舉，符合80/20法則，即最重要的少數(shù)戰(zhàn)略滿足80%的業(yè)務需求。基于這個理解，我們把主要精力用于梳理最重要的幾種典型戰(zhàn)略，并將其轉化成系統(tǒng)，持續(xù)優(yōu)化。對于非標準化的非重點戰(zhàn)略，需要做一些妥協(xié)：或者暫時采用線下方式支持，或者通過修改戰(zhàn)略實施流程的方式去適配現(xiàn)有系統(tǒng)。
梳理出重點戰(zhàn)略之后，我們需要在需求和數(shù)字化之間搭建一個橋梁，即提供一個需求方和實施方能夠理解的語言。如此，需求方能在適當?shù)臅r機，以正確的方式提出戰(zhàn)略數(shù)字化需求。我們在具體實施過程中總結出兩種模式： * 總則－細則模式。需求方只提簡單的總體目標需求，實施方負責將該目標轉換成細粒度的細則。基于細則，需求方和實施方對數(shù)字化的最終預期效果和所做的妥協(xié)進行溝通，取得一致認識。最后，實施方負責把細則轉化成系統(tǒng)。 * 表格模式。需求方以表格或者流程圖等標準的描述方式提供需求，實施方負責將標準需求文檔轉換成系統(tǒng)。當然，標準化的需求描述方式是實施方和需求方共同制定的，確保需求方能夠理解，實施方能夠實施。
讀者可能會比較疑惑，通過簡單的表格能否描述復雜的“戰(zhàn)略實施數(shù)字化”需求？我們從美國立法的過程中得到了啟發(fā)，法律要解決的問題是非常復雜的。神奇的地方在于：通過一些簡單的、標準的格式進行法律描述，立法方、執(zhí)法方以及受處罰方能夠取得比較一致的認識。類似的例子還包括“業(yè)務流程管理”理論和“權限控制”理論，讀者可以研究一下為什么工作流引擎可以滿足幾乎所有公司工作流程的需求，簡單的“Attribute-based access control”理論可以滿足從五角大樓到創(chuàng)業(yè)公司的權限管理需求。
我們舉一個簡化的例子去展示編碼化過程，它不是一個線性過程，簡化后仍然很復雜。讀者的關注點不在于理解例子中具體業(yè)務，而在于對整個編碼化過程有一個感性認識。
需求是將某個地區(qū)的客戶分配給某些運營人員，當然需要滿足一定的條件的客戶才是有效客戶，運營人員也是如此。候選客戶和運營人員的匹配需要滿足一些約束和公平性準則。該分配策略還需要與其他分配策略進行優(yōu)先級排序，只有高優(yōu)先級的策略執(zhí)行完之后，該策略才能執(zhí)行。 無論是“總則－細則模式”還是“表格模式”，需求都需要轉換成如下標準表格。采用“總則－細則模式”，工程師負責出具表格，采用“表格模式”，需求方直接出具如下表格。
| 背景 | XXX |
| 目標 | XXXX |
| 影響區(qū)域 | 江蘇省 |
| 承接單位 | 運營X組、運營Y組 |
| 賬戶召回規(guī)則 | 1.滿足條件A、B的客戶分配 2.滿足C或者D的賬戶不能召回 3.規(guī)則2優(yōu)先于規(guī)則1 |
| 人員召回規(guī)則 | 1.每個運營人員每日分配客戶不超過M個 2.每個運營人員總分配客戶不超過N 3.運營人員必須要符合P資質 |
| 匹配規(guī)則 | 1.每日客戶平均分配給運營候選人 2.運營人員分配的總數(shù)量之間實現(xiàn)方差最小 |
| 規(guī)則優(yōu)先級 | 本規(guī)則優(yōu)先級高于E規(guī)則，低于F規(guī)則 |
通過這個表格意味著，我們實現(xiàn)了如下目標： * 它提供了需求方能夠理解的語言，使得需求方具備獨立評估完成該策略數(shù)字化后的后果以及影響的能力。 * 基于標準化的表格，工程師具備了進行完備性分析的能力，確保沒有任何明顯遺漏。 * 工程師可以進行規(guī)則沖突分析，確保新規(guī)則與老規(guī)則沒有沖突，如果有產(chǎn)生沖突，需要進行規(guī)則合并。
為了能夠將如上需求表格快速進行數(shù)字化，工程師需要設計一個靈活可擴展的系統(tǒng)。我們系統(tǒng)簡化版本的流程圖如下：
我們可以依稀看到“需求表格”與“流程圖”之間存在如下對應關系：
| 影響區(qū)域、承接單位 | 組織城市對應規(guī)則 |
| 賬戶召回規(guī)則 | 賬戶召回、賬戶小組召回 |
| 人員召回規(guī)則 | 賬戶小組召回、賬戶候選人召回 |
| 匹配規(guī)則、規(guī)則優(yōu)先級 | 賬戶命中規(guī)則、分配規(guī)則優(yōu)化 |
再次強調，一個標準“需求表格”和“流程圖”之間并非絕對的一一對應關系，需求表格中某行的一個規(guī)則可能需要在流程圖的多個節(jié)點進行修改才能實現(xiàn)。“需求表格”中的細則和“流程圖”之間的節(jié)點的關聯(lián)關系實際上是由工程師在大腦中完成的。但是，對于相對固定的的戰(zhàn)略數(shù)字化，經(jīng)過幾輪的迭代，需求方應該具備快速提出需求的能力，工程師也能快速的進行完備性分析和沖突檢測，并能在較短的時間實現(xiàn)其數(shù)字化。
1.https://en.wikipedia.org/wiki/Customer_relationship_management 2.https://en.wikipedia.org/wiki/Business_process_management 3.https://en.wikipedia.org/wiki/Attribute-Based_Access_Control 4.https://en.wikipedia.org/wiki/Template_method_pattern 5.https://en.wikipedia.org/wiki/Pareto_principle 6.https://en.wikipedia.org/wiki/Topology
總結
- 上一篇： 最全多线程经典面试题和答案
- 下一篇： AC算法在美团上单系统的应用