CRM系統新思維

02-02

介紹

客戶關係管理系統（CRM系統）是管理公司當前以及未來潛在客戶的系統，其主要目的是通過優化客戶關係實現公司銷售業績的長期增長，它是企業信息系統的核心之一。目前，移動互聯網、大數據以及人工智慧技術發展日新月異，正在加速改變世界。但是在CRM等企業系統的構建和優化方法論上，卻缺乏革命性的創新。本文作者在構建和優化CRM系統的過程中總結出一些新方法論，與當下的一些先進理念不謀而合。每個具體的理念雖然並非原創，應用在CRM系統構建中還算新穎，並且所有的理念一起構成一個完整的體系。希望這些對負責CRM系統開發的管理者、工程師、產品人員有所幫助。

CRM系統的構建和優化本質上是一個工程學問題。解決好一個工程學問題需要把控好四個主要環節：

明確該工程的主要目標。
理清實現該目標的方法論。
構建快速支撐方法論實施的架構和系統。
打造一個優秀的團隊。

本文基於這條線進行闡述。第一部分主要討論CRM系統的目標以及方法論。第二部分通過具體案例詳細闡述方法論實施。本文第三部分是關於如何設計靈活可擴展系統架構。最後一部分總結了在團隊管理方面的一些心得。

CRM系統目標和方法論

搭建優秀的CRM系統的前提是清晰的目標，然後尋找實現系統目標的系統性的方法論。在方法論和目標之間建立關聯是一個複雜的分析過程。我們採用嚴謹的數學方法，從CRM系統目標中推導出獨特的方法論。確定了方法論之後，我們將深度闡述其具體內涵以及層次。本小節的最後一部分歸納出實現運營目標的路線圖（RoadMap）。

CRM系統目標

主流CRM系統的目標是實現運營收入的增長，嚴格的講，應該是收入預期的增長。從經濟學的角度來講，收入預期不是一個值，而是一種分布，這就引入了「風險」的概念。所以，CRM系統的目標需要同時考慮風險和收入預期這兩個因素。簡而言之，CRM系統的目標應該是：

實現收入預期最大化。
提高收入預期置信度。

CRM系統目標拆解

實現預期收入最大化這個目標可以從四個方面入手：

增加客戶數量。
提升高質量客戶佔比。
提高服務頻率以及延長服務時間。
提升運營人員服務效率，即「人效」。

CRM系統負責人真正能夠有效提升的因子是人效。提高人效最重要的手段就是讓機器承擔更多的工作，即「服務數字化」。

提高收入預期置信度的本質上就是降低戰略執行的不確定因素，從人治模式轉型成系統管理模式，簡而言之就是「管理數字化」。

以上的結論經過了嚴密的數學推導，對推導過程有興趣的同學，可以參考附錄 CRM系統目標拆解詳細推導。

全流程數字化閉環

根據上文，實現CRM系統目標的手段是提高數字化程度。基於此，我們提出了全流程數字化閉環概念，如下圖：

在對該圖進行詳細講解之前，先做兩點說明：

整個閉環的起點來自於人。在目前階段，大部分的系統還無法完全獨立思考，這意味著它們的運轉需要外部的觸發點，也就是人。
整個閉環的終點也是人。決策者的想法經過系統一輪循環之後，不僅產生業務價值，得出的反饋還會促進決策者成長。

我們對上圖進行詳細講解：

實現CRM系統目標的前提是運營決策者戰略思考（Idea）。
工程師們負責將Idea進行數字化（Digitize），轉化成計算機能識別的策略（Policy）或規則。
系統對數字化的策略進行排期（Policy Schedule）。
排完期的策略將會被定期執行（Policy Execution）。
策略執行的結果是可具體執行的一系列任務（Tasks）。
通過系統，一線運營人員負責任務執行（Task Implementation）。
執行完畢後，執行者需要做一些紀錄（Record）。
系統收集記錄以及其他效果數據，形成統計數據（Statistics）。
統計數據將被製作成各種圖表或者報告（Report）。
運營決策者通過直接查看圖表的方式，或者接受系統的自動化分析（Analysis）結論獲得反饋。

每一輪循環都會提升運營決策者，決策者的提升反過來會促進CRM系統的改進。全流程數字化閉環本質上是決策者和系統不斷相互促進的過程。

數字化層次

既然核心方法論是「全流程數字化閉環」，我們需要先深入探討一下什麼是數字化。數字化本身是一個非常抽象的概念，不同的人有不同的理解。我們根據在CRM系統的實踐經驗，總結出了數字化的三個層次，即標準化、自動化和智能化。

標準化。標準化是數字化的基礎，物理世界絕大多數事物都是連續的（Continuous），而計算機只能保存離散的數據，所以標準化的核心是離散化、結構化。我們一般把靜態的（static）數據模型和概念的數字化稱為標準化，比如：賬戶、工單、分配等。
自動化。自動化指的是動態過程的數字化，比如流程、戰略、許可權控制的數字化。「動態」意味著與時間相關，狀態之間存在依賴關係。
智能化。智能化是當下非常流行的概念，直觀的理解就是讓系統具備思考能力。所以，智能化包含兩種：第一種是分析過程的數字化，這意味著系統在比較確定的上下文中具備分析能力。第二種指的是在系統中應用統計學方法（Statistical Methods）、機器學習演算法（Machine Learning）使其具備一定的學習、推理和思考能力。

業務分析

「數字化」並非空中樓閣，它是具體業務的數字化，本質上也是一種「物化」。從運營業務的角度如何看待CRM系統？傳統觀點認為CRM系統是一個「操作平台」和「分析平台」。對於像美團點評這樣級別公司，其CRM系統的使用人員很多，所以它是「高頻操作平台」。此外，「全流程數字化」蘊含著「管理數字化」的概念，所以CRM系統是「戰略執行平台」。最後，優秀的CRM系統要考慮人的因素，因人而設計，與人互動。對於擁有龐大運營團隊的CRM系統而言，團隊士氣的高低對「運營目標達成」的影響很大，所以，CRM系統是「激勵平台」。綜上所述，CRM系統是「高頻操作平台」、「戰略執行平台」、「激勵平台」和「分析平台」，如下圖:

RoadMap

以上分析指明了CRM系統目標以及實現該目標的方法論，但這些僅是抽象的概念。在現實生活中，我們實實在在擁有的只是一個技術和產品團隊。利用這個團隊去實現「運營目標達成」需要一個金字塔狀的RoadMap，如下圖：

金字塔最上層是CRM系統的最終目標，即「運營目標達成」。
下面一層是方法論，即「全流程數字化閉環」，具體而言指的是「運營業務數字化」和「運營決策數據化」。
所有的目標都要在規定的時間內完成，而完全數字化所需的時間是無限長。所以我們需要在有限的時間內高質量地實現儘可能多的重要功能的數字化，這就需要「靈活可擴展的系統架構」，這是第三層。
最底層是物理世界，即團隊，它必須是「具備創新意識、強執行力的團隊」。

數字化實施

上文已經談到數字化是一個層次化的概念，要想真正深入理解它並靈活應用到實際工作中，需要大量的實踐。本小節將重點闡述如何實現CRM系統的全流程數字化。同時，整個數字化闡述以及各個案例的講解過程也是幫助讀者進行數字化實踐的旅途，將會有助於讀者深入理解「數字化」。

高頻操作平台數字化

這個過程需要三個步驟：

高頻處理流程梳理。
高頻處理流程數字化。
流程中關鍵節點數字化。

高頻流程梳理

CRM系統的典型高頻處理流程包含三個節點：搜索客戶、分析客戶和客戶觸達，如下圖：

高頻流程數字化

流程數字化有兩層含義：閉環流程自身的標準化以及閉環流程操作方式的標準化。

「閉環流程本身標準化」意味著需要一個概念去描述完整的基本高頻操作閉環。我們把完整的「搜索客戶」、「分析客戶」和「客戶觸達」閉環稱之為工作單元，簡稱「工單」。所以高頻操作本質上就是對工單列表的順序操作。

談到閉環流程操作方式，嚴格地講，用戶的操作是一個圖（Graph）或者樹（Tree），而我們的目標就是要盡量讓高頻流程操作形成一個鏈表（List）結構。從技術上講，這會帶來兩個好處：

鏈表式操作容易進行人效優化。與鏈表相比，對圖或樹進行優化要複雜很多。
鏈表式操作隱式地自動進行目標管理。圖或者樹式操作類似於隨機過程（Stochastic process），操作人員需要不停的做決策，記住每次操作的下一步目標。持續地進行高強度、高頻率的決策工作，這對操作人員的要求很高，很容易導致其疲勞或者目標迷失。採用鏈式操作模式，鏈表中節點之間的流轉固定，這近似於一個確定過程（Deterministic process）。

基於以上分析，我們做了兩方面的抽象：

引入了工單（Task）的概念，並且將閉環的操作入口固定為「工單列表」。
工單操作主流程鏈式化。

高頻流程的數字化結果如下圖：

搜索客戶數字化

高頻操作流程的第一步就是搜尋客戶，實現該功能的最樸素的產品是多維度的客戶搜索、篩選功能。運營人員通過組合各種篩選項和搜索條件尋找目標客戶。這種操作方式類似於用戶在Amazon或者Taobao上購物。顯然這是低效的操作模式，在搜索客戶數字化方面，我們將進行三個層次的優化，即：標準化、自動化和智能化。

搜索客戶標準化

搜索客戶的低效源自於搜索篩選條件的複雜，以及重複的搜索操作，所以最直接的解決方案就是讓系統記住這些複雜的篩選項，並避免重複搜索。基於此，我們的第一個改進措施是將「搜索模式」轉變成「分配模式」，具體而言，就是從「搜索客戶」轉向「分配工單」，它所導致的變化如下圖：

運營人員的操作模式從上圖左邊的循環轉變成了右邊的循環。這樣一個看似簡單的變化是對於人效提升而言卻是本質性的改進。從理論上講，我們取得了三個方面的進展：

搜索操作效率改進。分配模式是一次搜索、大量分配，運營人員搜索次數從n降成1。
決策優化。分配本質上是一個決策的過程，根據心理學理論，高質量的決策需要一定的時間。實施決策和操作分離，我們可以期望更高質量的決策。
上圖左邊的循環包括「搜索」和「操作」，右邊的循環只包含「操作」，顯然更小的循環有助於提升效率。理論上講，循環越小，上下文切換（Context Switch）成本也就越小，使用者熟練度也會提升，目標也更聚焦，所以人效也就自然得到提高。

在分配模式下，我們還可以為每次分配設置跟進優先順序。這就引入了「偏序（Partial Order）」的概念，這意味著，客戶之間不僅僅有是否需要跟進的區別，從跟進優先順序的角度來講還是可以比較的。眾所周知，無論工作還是生活，我們都應該「做正確的事情」。「偏序」概念的引入讓決策者具備了優先安排正確工作的能力，讓執行者具備了優先做正確的事情的能力。

具體而言，工單分配就是將客戶分配給運營人員的過程，包含如下圖四塊：

客戶召回，通過對客戶的屬性和特徵進行篩選和搜索實現。
運營人員召回，通過對運營人員的屬性和特徵進行篩選和搜索實現。
匹配，將召回運營人員和客戶進行關聯。
生成工單，客戶與運營人員的關聯結果稱之為分配，分配的結果以及預期的執行稱之為工單。

搜索客戶自動化

工單分配實現了n次搜索操作向1次分配操作的轉變，這是空間維度的人效提升，例如，運營管理層可以一次為多個運營人員分配工單。但是，運營決策者仍然需要定期進行工單分配，這也是一種重複勞動。所以，我們可以從時間維度提高人效。這種讓機器代替人來執行重複操作的過程是一種自動化。自動化分配一般由規則引擎（Rule Engine）和調度系統（Scheduler）共同完成。這裡的一個核心概念就是規則（Rule），它的核心內涵包括如下四個方面：

召回細則（Recall Policy），指的是客戶篩選屬性和運營人員篩選屬性集合。
匹配細則（Match Policy），指的是對召回的客戶和運營人員進行匹配的規則或者模型。
排期（Schedule），指的是規則執行頻率，即該規則多久執行一次。
有效期（Lifetime），指的是規則從第一次執行到最後一次允許執行的生命周期。

規則（Rule）是上面四個概念的集合體，更複雜的規則還可以指定執行優先順序等。

通過調度系統和規則引擎進行分配自動化的功能圖如下：

Scheduler定期去查看Rules。
處於有效期內，到了執行點的Rule將被Scheduler發送給Rule Engine。
Rule Engine對Rules進行解釋和執行，生成工單分配。為了執行規則，Rule Engine還需要其他輔助Data才能完成工單分配。

搜索客戶智能化

最少可以從兩個維度去提高客戶分配的智能化：召回規則、匹配規則。同時，如上文所述，智能化的手段有兩個：分析過程數字化和規則模型化。

精確篩選高優先順序的客戶是一個非常複雜的分析過程，大部分的篩選和搜索操作都是基於客戶的靜態屬性完成的，比如賬戶的消耗、餘額等等。現實生活中，對客戶的理解和分析卻是動態的，我們根據客戶過去一段時間的變化或者趨勢去識別客戶。幾乎不可能把所有時間維度的特徵納入到篩選中，有幾個原因：

人們對概念的理解基本上是靜態的。雖然每個人都具備動態理解能力，但是人們並不容易在動態思考上達成一致意見。
動態的特徵轉換成篩選項，意味著在篩選項之間引入了邏輯關係，而不僅僅是簡單的集合關係。這種產品將很難理解，對使用者要求極高，用戶體驗極差。

在賬戶分析過程數字化方面，我們採用典型分析思路標準化的策略。具體做法如下：

將典型的、已經被證明有效的分析過程整體進行數字化。
整個分析過程的數字化後形成一個抽象的召回細則。這個複雜抽象的召回細則整體作為一個篩選項供用戶篩選，換句話說，一個篩選項意味著整個分析過程。
為了讓使用者明白複雜召回細則，工程師需要與使用者進行必要的溝通，所以對複雜召回細則的理解是通過線下溝通實現的。

規則模型化比較容易理解。實施召回規則和匹配規則，除了採用確定性的（Deterministic）規則，我們還可以採用自適應（Adaptive）的統計學模型（Statistical Model）。這也是我們通常意義的智能化。

客戶分析數字化

優質的客戶服務需要長時間的客戶分析，所以這一塊的優化空間很大。

客戶分析標準化

把客戶的各種信息採用圖、表或其他友好的產品形式進行展示稱之為客戶信息標準化，本質上信息可視化的過程。有了標準化的客戶信息展示之後，通過基本的培訓，運營人員就能掌握標準的客戶分析方法。採用這種分析方式得出的結論將會有助於提升運營效果。

客戶分析自動化、智能化

對客戶分析過程類似於醫生對病人進行診斷。現在醫學之前，醫生通過望聞問切等方式來對病人進行診斷。這種診斷方式有幾個缺點：

首先，它對診斷者的要求比較高，一般必須是醫生本人。

其次，比較浪費時間，除非能夠標準化，完整的記錄整個診斷結果，即使短時間內針對同一個病人，醫生仍然需要重複診斷（或者這個醫生一天只有幾個病人，所以能全部記住）。

最後，即使對一些簡單的病狀，醫生之間也不容易達成一致。

現代醫學將診斷和看病分開，診斷的工作交給護士和機器來完成，診斷的結果非常精確。對於簡單的診斷，普通人就能明白如何處理。

在客戶分析自動化、智能化方面，我們借鑒了現代醫學自動診斷思想。把一些典型的客戶診斷分析過程進行數字化。一般而言，典型的診斷分析涵蓋了客戶的大部分問題，符合80/20法則。這不僅僅提高了運營人員的分析人效，還大大提高了客戶分析的精確性和一致性。

客戶觸達數字化

可以從很多維度對客戶觸達進行數字化，CRM系統的終極目標當然是機器人直接觸達客戶，解決客戶的所有問題。目前，還沒有公司完全實現這個目標。典型的數字化思路有如下幾種：

互動式語音應答（IVR）解決典型問題。
智能化Q&A。這包括採用智能搜索技術對結構化和非結構化的知識庫進行查詢、運用語音識別技術協助運營客服等。
客服質量檢查。通過語音識別技術將客服人員的語音轉換成文字，進行語法、語義分析，查找惡意作弊行為，識別並改進低質量的語音服務，推廣並培訓高質量的服務。

戰略執行平台

戰略執行數字化非常複雜，大數據和人工智慧技術使得其數字化變的可能。通俗的理解，戰略執行數字化就是要將運營決策者的複雜抽象的戰略通過系統轉化成一個個可以具體執行的任務。戰略執行數字化降低了從戰略規划到最終執行過程中產生的方差，通過系統實現了全流程的監控，最終提高了戰略目標實現的置信度。

一個中等規模的目標就需要戰略，所以戰略數字化應用非常廣泛，上文中談到的「工單分配標準化、自動化和智能化」就是一個典型的戰略執行數字化的例子。但是，「戰略執行」數字化的確是非常複雜抽象的概念，它給需求提供方和系統實施者帶來了巨大的挑戰。本小節將通過一個具體例子來講解「戰略數字化」的完整實施過程。整個講解過程詳細闡述了我們在實施過程中面臨的挑戰、應對挑戰的思考方式，以及在具體實施過程中的關注點和所做的妥協。到目前為止，在「戰略數字化」方法論方面，我們取得的進展是「編碼化」。

編碼化（Codify）

戰略執行數字化對CRM系統負責人的最大挑戰來自於如何快速實施和快速應對變化。在具體實施中，需要重點解決如下問題：

明確「戰略數字化」的目標和方向。
需求方和實施方在「戰略數字化」概念和內容上取得一致的理解。
在需求方和實施方之間建立標準語言，即標準化的需求文檔。
快速將標準化需求轉換成系統。

這四個步驟合在一起，我們稱之為「編碼化」，具體例子詳見編碼化實施。

激勵平台

這是一個不證自明的道理，士氣影響團隊產出。CRM系統遊戲化（Gamification）的理念很早就被提出，但在這塊的實施往往沒有給予應有的重視。移動互聯網時代，人類幾乎成了系統的奴隸。顯然，優秀的CRM系統需要去擁抱這兩個現實，讓運營人員和系統能夠實現更好的互動，進而提升運營人員的興趣、士氣，從而提高運營收入。

分析平台

網上有大量文章闡述如何構建優秀的分析平台。我們從實踐過中總結出兩個獨特的建議：

為每種角色、甚至每個人提供定製化的分析平台。這有兩層意義，第一，每個人都應該通過數據去決策，所以分析平台要儘可能適應每個人的需求。第二、標準化分析是比較專業的工作，不同角色、不同人的分析能力不同，分析平台必須非常貼合具體角色的能力要求。單一的分析方式總是有利於一部分人，而不利於另外一部分人，更精確的講，它不利於所有人。
分析平台要具備「實時查詢、即查即得」的特徵。據作者的觀察，由於大數據量的原因以及傳統的數據倉庫（Data Warehouse）的一些固有理念，大部分分析平台都無法實現「即查即得」的要求，它們通過滯後的郵件或者CSV文件格式來提供分析結果。這增加決策者的數據分析時間，降低了其分析效率。在很多場景下低劣的用戶體驗會導致用戶放棄使用該產品功能。為了實現「實時查詢、即查即得」，我們自己編寫中間件去解決數據量和查詢性能問題。另外，對於一些使用場景少並且性能消耗很嚴重的需求，架構師需要進行一些取捨。畢竟，系統的目標不是實現所有的需求，而是實現所有人的需求收益最大化。

系統架構靈活可擴展

對於構建CRM系統而言意味著：必須要用最小的投入，完成最關鍵的目標。這就對系統架構的靈活可擴展性提出了很高的要求。

如何構建靈活可擴展的系統架構是一個開放式的問題，仁者見仁，智者見智。通過實踐，我們總結出構建靈活可擴展系統的四個準則：定製化、配置化、組件化和重引擎輕資料庫。

定製化（Customerization）

定製化指的是為不同的人提供不同的產品，從某種角度來說，這是一種空間適配的概念。CRM系統是高頻操作平台，所以幾乎每個用戶都是高級用戶，為每個人提供定製化的產品必然能夠提高運營人效。但是，為每個用戶開發一套系統的成本太高，並不現實。所以，定製化指的是用一套技術架構提供不同的產品，具體的講就是用戶可以通過配置方式定製的滿足個性化需求的獨特產品展現形式。

配置化（Configuration）

如果說定製化是一種空間適配，配置化就是時間適配，它指的是產品隨著時間發生了變化，但是不需要額外開發工作。配置化是內容管理系統（CMS系統）的核心思想。具備了配置化功能的系統，新產品的上線或者老產品內容的更新不需要工程師的額外開發工作，系統管理者可以通過簡單的配置實現。

什麼場景能夠進行配置化並沒有一個標準的答案。但是，配置化和模板化往往是孿生兄弟，所以我們可以從模板化的概念中得到一些啟示。設計模式裡面的模板方法模式（Template method pattern）指的是在父類中實現框架，在子類中實現具體方法。類似的，一個產品功能是否具有模板化的特徵，取決於其主體框架是否能夠保持不變，功能細節是否變化頻繁。如果一個功能具有模板化的特徵，設計者就可以嘗試配置化的設計。

組件化（Componentization）

CRM系統非常複雜，包含眾多子系統。這些子系統共同組成一個有機的整體，在具體的產品開發過程中，一個小功能點往往需要對多個子系統進行修改。牽一髮而動全身，這不利於產品快速交付。有很多系統架構理論用於解決類似問題，例如：SOA、高聚合低耦合（High Cohesion, Loose Coupling）等。我們同樣花了很長時間去思考和解決此類問題，最終形成了自己獨特的方法。我們稱這個方法論為「組件化」，需要注意的是，這裡與業界通行術語的含義並不完全一致。。組件化由四個步驟組成：

長業務分組件。
組件專人負責。
組件功能聚焦。
組件之間解耦。

對於組件化四步驟，這裡做一些說明。

什麼樣的業務是「長業務」？如上文所述，頁面上的一個小功能點需要多個系統協作才能完成的情況比比皆是，所以大部分業務都是長業務。整個CRM系統設計都應該儘可能的按功能切分成子系統，子系統內部按照功能點進行再切分。例如，在我們CRM系統裡面，所有與篩選相關的功能都被放到「篩選引擎」裡面，所有數據獲取功能由「DataService」服務提供，所有的報表都由「ReportEngine」來完成。

「組建專人負責」看起來是管理學的問題，但是卻是非常高效的手段。經驗表明，對系統熟悉的工程師在產品需求交付速度上有很多倍的提升。隨著熟練度的增加，專職工程師能夠接受更具挑戰的任務、提出更具創新性的思路。

後面兩步驟基本上就是設計高聚低耦的系統。雖然有很多關於如何設計「高聚低耦」系統的資料，在實際工作中這一點對很多工程師的挑戰還是比較大。

我們這裡舉一個例子來形象地展示「什麼樣的系統架構具備組件化設計標準」。對於很多產品而言，篩選和搜索都屬於複雜度比較高的系統，於此同時，新的業務需求導致篩選項不斷增加。這在我們的CRM系統中表現非常明顯。通過採用如下樹狀架構圖，我們的篩選引擎具備快速支持新篩選需求的能力。

採用如上架構圖，一個新的篩選需求對於工程師而言意味著三件事情之一：

修改現有的篩選邏輯，即修改架構圖中的某個或者幾個節點代碼。
添加節點。在上面的架構圖中，添加節點只意味著最多和兩個現存節點之間有關聯，這實現了對現有系統入侵性最小化。
在Combiner下面添加完整的一個篩選鏈條，這個鏈條的代碼是完全獨立的，現有系統中只有Combiner需要修改。

無論哪種修改方式，新需求與現有系統的耦合非常少，開發非常輕。我們的報表引擎、分配引擎、診斷引擎都遵循類似的架構設計標準。

重引擎輕資料庫

Spark被認為是非常靈活的系統，它的核心思想之一就是把操作保留在內存裡面，避免保存大量的中間結果數據。借鑒這個思想，為了快速支持系統數字化，我們的CRM系統引擎層做的比較重，儘可能的在引擎層去實現所有計算邏輯。除此之外，重引擎層還有如下幾個原因：

需要進行數字化的業務方向非常多，類似業務有很大的共通性，業務之間並不具備互通性。組件化要求為不同的業務構建不同的引擎。
根據以上論述，對業務進行數字化的主要模式是：梳理典型業務邏輯，然後進行數字化。從技術的角度來看，這相當於對流程或分析過程進行數字化，這正是引擎的概念。
熟能生巧，每個業務引擎由專職工程師負責，這會讓整個團隊在引擎的思考深度和產品交付速度上有明顯的改善。

對於資料庫的使用，我們的態度是資料庫只負責存儲，計算儘可能由引擎實現。沒有辦法去證明這個觀點的正確性。因為存在反例，SQL的功能非常強大，某些團隊利用SQL去維護大項目，解決複雜問題。但是我們拒絕資料庫進行計算有如下理由：

CRM系統的需求變化頻繁，複雜的SQL語句很難實現「高聚低耦」。一個小需求變更可能意味著整個龐大的資料庫語句修改，很多時候難以接受。或許擁有眾多專業DBA可以緩解此類問題，但是前提是一定不能以犧牲項目迭代周期代價。
採用資料庫進行計算往往意味著重量級地使用Object-relational mapping框架。現實情況是，並非所有的工程師對於如何使用和優化這些框架都熟悉，但是他們卻必須要全方位得快速解決所有業務問題。
大量採用SQL還存在一些安全隱患，並非所有工程師都是專業的安全工程師。
對於計算密集的業務，資料庫在性能上沒有保障。並且，資料庫性能調優並非所有開發工程師所擅長。
大部分系統需要共享同一個資料庫，將計算交給資料庫意味著產品功能開發之間通過數據有了強耦合關係。
總的來說，資料庫比較擅長集合操作，在邏輯操作方面比較弱。

「重引擎輕資料庫」本質上是一個技術選型的問題，技術選型第一要素當然是滿足業務需求。滿足這個必要條件之後，人的因素就是技術選型的重要標準：團隊成員是否熟悉該技術，學習該技術成本是否高，使用該技術的風險是否大，都是重要考慮因素。

團隊管理

團隊管理是任何管理者都無法迴避的問題，它是整個Roadmap的第一層。同時，它也一個非常大的話題，而且往往非常主觀，我們試圖總結一些比較客觀的經驗。

創新、積極向上的團隊

創新意識和積極向上是保持團隊長期高效穩定的基礎。顯而易見「正能量價值觀」和「關注個人成長」必然會促使團隊積極向上，並提高團隊成員的創新意識。

關於「正能量價值觀」這一塊，基本理解是：人們只會在願意創新的地方去創新，只會對感興趣的事情表現出積極。幸運的是CRM系統解決的問題是非常正能量的，因為它的目標是提高運營人員的生產力，而提高生產力是人類最偉大的目標之一！所以，只要導向正確，很多工程師會對CRM系統表現出強烈的興趣。

關注個人成長很重要，畢竟成長是很多人的重要工作目標之一。沒有成長的團隊很難激發創新意識。對於一個團隊而言，實現個人長期持續的發展要關注兩點：

納什均衡（Nash equilibrium）。在團隊管理裡面，納什均衡指的是每個人要在團隊裡面有自己清晰的定位。要實現這一點，為每個工程師找到一些能夠長期持續驅動的項目非常重要。
定位要盡量符合個人特長。進入社會之後，工程師之間在經驗、特長都會有所不同。大家統一定位，則意味著忽視個性。這一方面意味著不公平，另一方面意味著壓制創新。為了儘可能讓工程師的定位符合其個人特長，團隊需要很多對能力類型要求不同的長期項目。

所以關注個人成長的一個重要措施就是挖掘出很多開放式的項目。幸運的是，CRM系統的「全流程數字化閉環」包含許多具有挑戰、值得探索的項目。

高執行力

在提高團隊執行力這塊，我們有三個總結：客戶價值、並行工作（Multitasking）和敏感度把控。

強調技術的客戶價值非常重要。一個沒有客戶使用，不能幫助客戶提升生產力的系統或者架構沒有價值。衡量執行力的標準不是做了多少事情，而是給客戶帶來了什麼好處。做一個簡單的算術題：假定有兩個團隊，A團隊60%的項目有價值，B團隊90%的項目有價值。為了實現同樣的業務目標，A團隊需要B團隊1.5倍的人力，人員成本增加是驚人的。

對CPU的進行多線程調優，工程師們比較熟悉。對於團隊執行力而言，並行工作同樣重要。可以從三個方面去提高團隊的並行工作能力：

大團隊要分成獨立工作小組，提高團隊同時承接多項目的能力。對於美團點評這樣公司，工程師們的單兵作戰能力比較強，所以兩三個、甚至一個工程師可以獨立承接一個小項目。無論如何，把大團隊按照項目承接能力拆分成獨立工作小組都能提高團隊整體承接項目的能力。
提高個人並行工作能力。大部分人習慣於在一段時間專註一件事情，如果這個事情被阻塞住了，整個人就容易進入到閑置狀態（Idle）。早期的CPU就是這種工作模式，多任務（Multitasking）技術大大提高了CPU的工作效率，這同樣適用於工程師。
每個人要有自己主導的重要的開放式的項目。大家都知道「重要」和「緊急」的經典理論，這裡不詳述。理論上講，「緊急」需求佔個人工作時間的比重應該是比較低的，或者說管理的目標之一就是減少「緊急」任務佔個人工作時間的比重。當沒有緊急需求的時候，或者當前需求被阻塞的時候，工程師需要迅速找到其他重要任務去完成。讓每個工程師都有自我驅動的重要的開放式的項目是實現這個目標的關鍵。

項目敏感度控制和團隊成員鬆弛度管理非常重要。大部分團隊或者中等規模以上的項目都不是鐵板一塊，它們都有自己的結構或拓撲（Topology）。依據經典運籌優化理論，對敏感資源的少量投入往往能夠極大的提高最終的目標產出。通俗的講，很多公司或者團隊所謂的忙碌，都是結構性的忙碌，「忙的忙死，閑的閑死」。舉例來說，一個典型CRM開發團隊應該包含：產品經理、前端工程師、後台工程師、數據工程師、測試工程師等等。在一段時間內，各種角色的配置比例是相對固定，但是每個項目對各種資源的使用比例基本上不一樣。假如某個項目前端工程師資源很緊張，項目管理者就必須好好利用前端工程師資源。從敏感度和鬆弛度管理的角度，我們可以從兩方面進行優化：第一、砍掉一些前端資源要求很高，但是重要性低的需求。第二、引入前端資源不密集的項目，把兩個項目合成一個項目，變相地增加前端資源。

總結

本文以CRM目標為出發點，創新性的推導出「全流程數字化閉環」方法論。基於此，本文探討了「數字化層次」以及構建CRM系統的完整RoadMap。本文的後面部分都是基於該RoadMap進行講解的。

我們花了很大的篇幅去闡述「數字化」實施，從業務的角度講，它關注CRM系統。本質上講，整個互聯網的發展歷程就是傳統業務的數字化的歷史。所以，本文的關於「數字化」思想適用於任何系統，任何領域。這種思考問題的方式既適用於工程師，也適用於產品人員、管理者甚至創業者。

在系統架構和團隊管理方面，本文總結了作者所在團隊一些最重要的經驗。所謂「天下大事，必作於細」，實際工作往往要繁瑣很多，我們需要關注更多細節，沒有完備性的解決方案。「天下難事，必作於易」，所有複雜繁瑣的事情都是通過少數重要的準則去分析解決的。本文在系統架構和團隊管理方面所給出的建議是我們在日常工作中最經常使用的一些準則，堅持這些準則極大地提高了我們在產品交付方面的能力。

附錄

CRM系統目標拆解詳細推導

我們採用經典運籌學分析方法拆解「收入預期最大化」目標。首先需要對客戶進行離散化，將收入預期相近的客戶分入同一個級別，目的是對客戶進行分級。每個級別內的客戶形成一個等價集合。收入預期最大化即Maximize(ERevenue)。收入預期ERevenue用如下公式表示：

公式中Customer_Num(inLevel)表示某個處於某個級別的客戶總量，ERevenuePerCustomer(inLevel)表示該級別單客戶收入預期。

根據公式，可以從兩個方面優化收入預期：

增加Level的數量將使得ERevenue變得更加精準。
提高單客戶收入預期。

單客戶收入預期與如下因素成正比例關係：

其所處的級別，用LevelFactor表示。公式表示如下：
該客戶的服務頻率（ServiceFrequency）和單次服務時間（PeriodPerService）的乘積。公式表示如下：
單位時間的服務效率（ServiceEfficiency），通俗的說法就是「人效」。公式表示如下：

所以如下四方面的改進可以潛在的提高收入預期：

客戶數量增加。
高質量客戶佔比提升。
更高頻率的服務以及更長的服務時間。
提升運營人員服務效率，即「人效」。

在這些因素裡面，高質量客戶佔比提升既是改進的目標，也是改進的結果。單純地提高客戶數量、服務頻率以及服務時間是樸素而有效的方法，但是它要遵循一定的約束，也就是成本。可以用如下公式來表示：

運營人員的數量（OperatorNum）是由預算決定的，運營人員的工作時間（WorkingHour）相對固定的，所以這兩個因素往往非CRM系統負責人所能決定。所以，CRM系統負責人真正能夠有效提升預期收入的因子是人效。顯然提高人效最重要的手段就是讓機器承擔更多的工作，即服務數字化。

「提高收入預期置信度」，即Maximize( Confidence (ERevenue))，本質就是減少方差。實現一個稍具規模的目標就需要一個完善的規劃，任何的規劃都包含兩部分：確定性部分和非確定性部分。非確定性部分包括市場環境突變、重大自然災害等等，CRM系統的應對措施並不多。規劃的確定性部分一般可以通過工作>流圖進行描述。工作流圖的實施過程會引入很多不確定因素，這包括：節點流轉不暢通、信息不對稱、關鍵指標衡量標準不一致、關鍵節點的監控不到位等。在傳統的工程實施裡面，這部分屬於項目經理的管理範疇，但是單純的人治容易引入的很大的方差。管理數字化是降低方差的重要手段，也是目前的趨勢。從某種程度上講，數字化程度越高，方差也就越小，收入預期置信度也就越高。

編碼化實施

實施的前提是需求方和實施方在數字化目標方面取得一致。戰略數字化非常抽象費解，對於具體某個戰略，類似「什麼是數字化」、「如何實現數字化」等關鍵問題，需求方和實施方達成一致理解並不容易。不能取得一致的理解會導致兩個嚴重後果：

需求方不知道何時以及如何提需求，不知道什麼戰略可以實現數字化。
將雜亂無章的定性需求轉化成系統對於實施方的挑戰和壓力很大。

我們從典型的「業務流程管理」（Business Process Management）中得到一些啟發。工作流業務的典型開發過程是：

梳理出一些典型的業務工作流程，進行制度化。
完成制度化之後。系統有很多節點是可快速擴展的，對於類似的流程，系統具備了快速實施的能力。
對於不符合工作流思想的流程，很多情況我們不是對系統進行重構，而是修改並規範流程。

同理，雖然從業務的角度，有各種各樣的戰略需要進行數字化。但是大部分戰略具有一定的共同特徵，並且最重要的戰略類別可枚舉，符合80/20法則，即最重要的少數戰略滿足80%的業務需求。基於這個理解，我們把主要精力用於梳理最重要的幾種典型戰略，並將其轉化成系統，持續優化。對於非標準化的非重點戰略，需要做一些妥協：或者暫時採用線下方式支持，或者通過修改戰略實施流程的方式去適配現有系統。

梳理出重點戰略之後，我們需要在需求和數字化之間搭建一個橋樑，即提供一個需求方和實施方能夠理解的語言。如此，需求方能在適當的時機，以正確的方式提出戰略數字化需求。我們在具體實施過程中總結出兩種模式：

總則－細則模式。需求方只提簡單的總體目標需求，實施方負責將該目標轉換成細粒度的細則。基於細則，需求方和實施方對數字化的最終預期效果和所做的妥協進行溝通，取得一致認識。最後，實施方負責把細則轉化成系統。
表格模式。需求方以表格或者流程圖等標準的描述方式提供需求，實施方負責將標準需求文檔轉換成系統。當然，標準化的需求描述方式是實施方和需求方共同制定的，確保需求方能夠理解，實施方能夠實施。

讀者可能會比較疑惑，通過簡單的表格能否描述複雜的「戰略實施數字化」需求？我們從美國立法的過程中得到了啟發，法律要解決的問題是非常複雜的。神奇的地方在於：通過一些簡單的、標準的格式進行法律描述，立法方、執法方以及受處罰方能夠取得比較一致的認識。類似的例子還包括「業務流程管理」理論和「許可權控制」理論，讀者可以研究一下為什麼工作流引擎可以滿足幾乎所有公司工作流程的需求，簡單的「Attribute-based access control」理論可以滿足從五角大樓到創業公司的許可權管理需求。

我們舉一個簡化的例子去展示編碼化過程，它不是一個線性過程，簡化後仍然很複雜。讀者的關注點不在於理解例子中具體業務，而在於對整個編碼化過程有一個感性認識。

需求是將某個地區的客戶分配給某些運營人員，當然需要滿足一定的條件的客戶才是有效客戶，運營人員也是如此。候選客戶和運營人員的匹配需要滿足一些約束和公平性準則。該分配策略還需要與其他分配策略進行優先順序排序，只有高優先順序的策略執行完之後，該策略才能執行。

無論是「總則－細則模式」還是「表格模式」，需求都需要轉換成如下標準表格。採用「總則－細則模式」，工程師負責出具表格，採用「表格模式」，需求方直接出具如下表格。

標題XXX賬號分配背景XXX目標XXXX影響區域江蘇省承接單位運營X組、運營Y組賬戶召回規則1.滿足條件A、B的客戶分配

2.滿足C或者D的賬戶不能召回

3.規則2優先於規則1人員召回規則1.每個運營人員每日分配客戶不超過M個

2.每個運營人員總分配客戶不超過N

3.運營人員必須要符合P資質匹配規則1.每日客戶平均分配給運營候選人

2.運營人員分配的總數量之間實現方差最小規則優先順序本規則優先順序高於E規則，低於F規則

通過這個表格意味著，我們實現了如下目標：

它提供了需求方能夠理解的語言，使得需求方具備獨立評估完成該策略數字化後的後果以及影響的能力。
基於標準化的表格，工程師具備了進行完備性分析的能力，確保沒有任何明顯遺漏。
工程師可以進行規則衝突分析，確保新規則與老規則沒有衝突，如果有產生衝突，需要進行規則合併。

為了能夠將如上需求表格快速進行數字化，工程師需要設計一個靈活可擴展的系統。我們系統簡化版本的流程圖如下：

我們可以依稀看到「需求表格」與「流程圖」之間存在如下對應關係：

需求表格流程圖節點影響區域、承接單位組織城市對應規則賬戶召回規則賬戶召回、賬戶小組召回人員召回規則賬戶小組召回、賬戶候選人召回匹配規則、規則優先順序賬戶命中規則、分配規則優化

再次強調，一個標準「需求表格」和「流程圖」之間並非絕對的一一對應關係，需求表格中某行的一個規則可能需要在流程圖的多個節點進行修改才能實現。「需求表格」中的細則和「流程圖」之間的節點的關聯關係實際上是由工程師在大腦中完成的。但是，對於相對固定的的戰略數字化，經過幾輪的迭代，需求方應該具備快速提出需求的能力，工程師也能快速的進行完備性分析和衝突檢測，並能在較短的時間實現其數字化。

參考文獻

1.Customer relationship management

2.Business process management

3.Attribute-Based Access Control

4.Template method pattern

5.Pareto principle

6.Topology - Wikipedia

不想錯過技術博客更新？想給文章評論、和作者互動？第一時間獲取技術沙龍信息？

請關注我們的官方微信公眾號「美團點評技術團隊」。