《漫談CRM體系化建設》系列共分五篇，前四篇討論了企業客戶管理的基本業務問題，客戶開發，留存，服務問題。本文是最后一篇，討論CRM的應用架構設計，建設階段與側重點，以及部門合作等問題。

五、CRM體系化解決方案

?1、標準CRM應用架構

通過對業務的逐步介紹，我們已經將CRM體系架構圖的血肉填充完整，一幅清晰地CRM架構藍圖在我們眼前呈現。此時，讀者應該對架構圖中每個版塊存在的價值和意義都有全面的認識和理解。

結合客戶開發、維護、服務的業務分工與職責定位，以及軟件架構設計的經典模式，整體CRM架構中包括以下幾大塊內容。

數據底層

數據底層主要包括集團級別的數據倉庫系統，數據集市，主數據。數據倉庫對公司所有業務數據進行統一匯總處理，提供標準統計口徑與計算維度，在數據倉庫上層，針對不同業務部門訴求，定制對應的數據集市，數據集市相對靈活可變。數據底層還包括主數據管理，常見的主數據有商品主數據，客戶主數據等。CRM關心的是客戶主數據。

基礎服務底層

在企業發展到一定階段后，通常需要把具有共性的模塊和功能單獨剝離出來，進行服務化建設，以便給所有上層系統提供基礎服務支持。這些基礎服務，既包括業務型服務，例如EDM、SMS、Push、Pay，也包括純技術底層，例如規則引擎，工作流引擎?；谶@些基礎服務，可以讓上層系統更關心業務邏輯，而不關心底層的實現機制，從而提升開發效率和IT服務能力。此外，統一客戶視圖，實現形式為接口服務，或web服務，支持全集團所有業務系統調用，在架構圖中作為基礎底層服務，繪制在基礎服務底層右側。

業務支持板塊

OCRM、銷售管理后臺、業務支持、CallCenter都是直接支持業務運轉的系統或平臺，主要聚焦客戶開發和客戶服務環節的業務動作。其中以OCRM和CallCenter最為重要，是支持銷售人員和客服人員的核心系統。

客戶建模與策略板塊

客戶建模和策略，是基于數據底層的上層應用，本身不具備業務屬性，屬于數據價值輸出的范疇。其中，客戶建模依賴于數據倉庫或數據集市，推薦與策略依賴于客戶建模和數據倉庫或數據集市。在架構圖中，我們在右側從下往上分別繪制了數據底層，客戶建模，推薦與策略，以體現其邏輯關聯關系。

運營管理板塊

運營管理板塊包含了CMS、營銷等內容。在純線上開展業務的公司，沒有銷售團隊，不需要OCRM系統，經常將CRM定義為管理后臺中的一個子模塊，承擔客戶分析和營銷職責。在本文中，我們假定運營管理板塊既支持線上業務前端，也要支持業務運營策略，通過營銷策略實現客戶留存。其中既包括手工營銷模塊，也包括自動化營銷模塊，也就是常說的Marketing CRM。

業務分析板塊

我們將分析型ACRM繪制在最頂層，以便體現出它和業務操作、數據建模本身無關的特性。ACRM實際上也是公司的BI系統。不論是ACRM系統，或者BI系統，都需要結合數據倉庫和數據集市來建設。數據底層定義指標口徑和緯度，BI提供不同主題或分析視角的數據呈現。有些觀點認為ACRM包括了客戶分析和營銷部分，但是本文認為ACRM僅同于BI。其實怎么定義和劃分都無所謂，關鍵是要清晰理解認識不同產品線的職責和定位。但我更推崇ACRM的定義就是BI，這樣便于理解和管理。

關于系統應用架構設計的相關話題，請參考作者的另一篇文章《漫談企業應用架構的演變》。

?2、CRM建設的幾個階段

在實施CRM項目前，首先要做出最基本的判斷，業務當前的發展階段，是否需要CRM系統？如果業務體量很小，業務人員很少，業務流程非常簡單，建設系統對業務幫助或價值不大，完全沒有必要做系統，不能為了上系統而上系統。

常見的商業，在業務發展上，可以劃分為業務試錯、精細運營、智慧管理三個階段，每個階段都有自己的側重點，對CRM建設有著不同的要求。CRM的體系化建設，不可能一步到位，要結合業務發展的情況，逐步演變完善。

另外需要注意的是，三個階段的劃分標準，只是一個參考，實際執行中，系統建設的優先級和實施順序，需要根據實際業務情況做出調整。

階段1：業務試錯

• 業務特點：業務剛開展的階段，企業對業務管理的流程、制度、規范，甚至商業模式本身都不能完全確定，需要在摸索中逐步完善。針對互聯網企業的特點，融資后需要大規模部署開展業務，版圖擴張快，業務變化快，管理粗放混亂，都是常見的現象。
• CRM的建設重點：提供初步、基本的管理運營體系支持，特別重視多層級組織結構的功能開發，以及銷售過程管理的實現，前者可以應對該階段必然會發生的頻繁的組織結構、團隊結構變化調整，后者可以保證在初期粗放的管理模式下盡可能掌控銷售團隊，避免管理失控。
• CRM的建設要點：此階段不能太在意系統架構的合理性，而要重點支持多變的業務。如果過分強調架構合理性，導致工期變慢，很可能功能還沒上線，業務已經關停。另外還要合理評估需求，可以線下處理的工作，盡量線下處理，不要一上來就改系統，原因很簡單，極有可能功能上線之際，業務已經停止。從CRM角度來講，系統永遠不是限制業務發展的阻力，牛逼的團隊用Excel也能做好業務。CRM可以幫助業務發展的更好，但不能決定業務是否成功。

此階段CRM重點關注的功能如下圖，基本上實現了業務系統化管理的最基本功能模塊要求，重點支持業務快速試錯與擴張。

階段2：精細運營

業務特點：核心業務形態、管理模式、經營方式基本確定，擴張階段結束，增長速度放緩，業務發展穩定。此階段需要企業開始提升內功，進一步規范管理，提升人效，降低成本，控制風險。

CRM的建設重點：基本功能模塊基本搭建完畢，架構體系初步成型，加強精細化運營管理以及風險控制方面的建設，針對業務流程，通過系統將管理過程標準化，規范化，數據化；針對營銷工作，通過進一步的客戶細分與營銷策略設計，實現具備業務價值的自動營銷策略與任務推送策略，協助銷售團隊識別機會、問題、風險，對各個生命周期階段的客戶提供差異化的刺激、喚醒策略，對不同貢獻度的客戶實現差異化的服務、跟進策略。

CRM的建設要點：架構設計合理化，對部分功能模塊進行服務化改造升級。加強客戶建模、客戶分析的資源投入，通過對客戶的精細分析，實現精細化的運營管理。

此階段CRM重點關注的功能如下圖，可以看到更多是在客戶分析建模，以及策略方面投入加大。

階段3：智慧管理

• 業務特點：業務成熟穩定，成為公司的現金牛業務。業務增長乏力，增長遇到瓶頸，需要尋找新的增長點。管理模式、經營模式、運營模式成熟，科學化管理代替了人治，即便高層人員放手不管，業務也能自發良性運轉。此時業務需要更加有效地控制成本，提升人效，尋找并嘗試其他增長機會，通過系統輔助甚至進行決策和工作安排。
• CRM的建設重點：系統架構已經完善，成型。加強行業分析、競對分析，給公司業務探索提供決策支持；加強異常分析，對公司穩定的經營中出現的異常進行感知捕獲；加強任務管理中心建設，將系統變成業務指揮的自動化控制中心，通過系統來發現問題，識別問題，觸發方案，推送方案，指揮業務人員執行方案；讓CRM系統變成管理人員地自動化管理指揮中心，從而進一步提升經營效率。
• CRM的建設要點：將系統建設成自動化的管理指揮決策大腦，是一個不小的挑戰，要拿捏好給計算機賦權的“度”，要設計好人干預和控制的“度”，什么情況下，什么事情，可以由計算機決策安排，或需要由人來檢查確認。還要考慮總部和分公司管轄關系問題，是總部強，指揮分公司，還是總部弱，分公司自主決策，這都決定了系統作為指揮中樞，是總部級別的中樞，還是分公司級別的中樞。

此階段CRM重點關注的功能如下圖。重點加強任務管理中心的建設，以及對行業、競對的數據搜集與分析。

上圖中實線部分表示CRM在三個階段中重點關注的功能，虛線部分需要結合實際業務情況判斷是否需要實現，在什么階段實現。

?3、產品線的分工與協作

CRM是一套龐大的體系，從系統層面包含了數據倉庫，主數據，基礎服務，業務系統，數據挖掘與策略等板塊。在大多數公司，這些板塊通常屬于不同團隊負責管理，如下圖。

• 綠色：業務運營產品部。CRM團隊常作為業務運營產品團隊管理，職責范圍包括OCRM，管理后臺，CallCenter，工單等。
• 橘色：基礎架構部。大型企業會把基礎服務底層或上層公共服務單獨設立一個團隊統一管理。
• 藍色：數據部。底層數據倉庫和部分數據集市，由專門的數據團隊管理。多數時候數據團隊還要負責公司的BI系統。
• 粉色：C端產品部。大多數時候，CMS、卡券都屬于C端團隊的業務端管理范疇，直接配合C端團隊以及C端對應的線上運營團隊。
• 黃色：風控團隊。風控團隊一般和業務運營團隊分開管理，作為集團層面的風控團隊統一管理建設，管控各條業務線的經營管理風險，這樣做的原因是因為不論集團有多少條業務線，客戶都是針對集團整體的服務對象，圍繞客戶的風險管理必須具備單條業務線之上的管理權限。
• 灰色：比較模糊的地帶，隸屬關系每個公司的情況不一樣，我們分別進行闡述。
• ACRM：此處我們理解成公司的BI。一般公司會安排數據倉庫和BI同屬一個團隊管理，CRM可以有自己的數據集市和針對銷售業務線的小型報表系統。但有些線下業務模式很重的公司，可能會將CRM團隊的報表系統和高管使用的BI系統分開建設，并列于同等重要的地位。
• 營銷板塊：包括優惠券管理，營銷管理，自動營銷。線上模式為主的公司，營銷板塊常屬于CRM范疇，由狹義的CRM團隊負責。如果線上線下營銷和銷售同等重要，則營銷板塊可能屬于大CRM團隊直接管理，給C端線上業務提供支持。
• 客戶數據與主數據：客戶數據與主數據最早設計時可能由交易系統團隊管理，或交易系統附屬的CRM板塊管理，隨著業務和架構的發展，可能會移交給數據團隊管理。
• 積分與會員：線上業務重的公司，會員和積分經常由C端團隊建設管理。線下業務重的公司，可能由大CRM團隊管理。
• 客戶建模、策略：這部分職責很難界定。線上業務需要建模和策略，線下業務也需要建模和策略。比較常見的安排是兩邊團隊都有建模和策略團隊，共享數據底層和部分模型與策略。雖然在一定程度上會造成一些重復性建設，但卻可以讓兩邊業務各自快速推進。需要明確的是，一些針對企業公用的客戶模型，必須由確定的團隊負責，不允許出現多頭建設的現象。

可以看出，從企業的視角來看，CRM是一套體系化的方案與系統部署，具體落地時，其中很多版塊會隸屬于不同的團隊負責。要根據業務和系統邊界，做好團隊分工與部署，避免團隊之間的資源沖突或管理沖突，也要給每個團隊提供足夠的發揮空間，讓優秀的團隊脫穎而出。

?4、業務部門合作問題

在純虛擬經濟的互聯網公司，產品團隊代表了業務部門，對業績負責。產品團隊擁有決策權，同時也要承擔業績壓力。系統如何做，怎么做，都由產品部門決定?，F如今的互聯網公司，已經深度參與到了實體經濟的業務，線下團隊和業務部門越來越越重要，更多的時候，由業務部門承擔業績和壓力，擁有決策權。

例如，IM產品，工具類產品，或小平臺類產品，公司的CEO或業務條線總經理常常出身于產品經理，運營和銷售向PM匯報，這是因為公司盈利的核心在于軟件產品本身建設的好壞。但是如今很多互聯網公司已不是虛擬經濟形態，和實體經濟深度結合，業務模式變得越來越重，很多時候商業上的成敗不是基于C端產品的好壞，而在于業務后端是否強大。業務團隊擁有很強的話語權，很多時候可以指揮產品技術團隊的工作，尤其是深度參與影響后端系統建設，這都是很正常的現象。

產品團隊，主要指后端系統的產品團隊，如何與業務團隊配合工作，是每一個產品經理都需要深入思考的問題。

總體來講，大家的利益和訴求一致，都是為了公司的經營發展。但很多時候，兩方的實現思路和解決方案卻經常出現分歧。業務部門對業務更熟悉，但不懂系統設計，喜歡既提出需求，又給出實現方案。產品部門，思維嚴謹，更擅長系統設計，總是很反感業務部門出爾反爾，考慮問題不夠全面深入，干預自己的方案設計。

產品部門如何與業務部門形成良好的合作關系？首先，產品經理要非常懂業務，要經常深入一線，如果不懂業務，和業務部門平等對話的前提就不存在。其次，要懂系統解決方案，知道系統該怎么配合業務。對于業務部門提出的需求也罷，方案也罷，要給出實事求是的合理分析，對于不合理的訴求，一方面做出明確拒絕，另一方面要給出替代性的解決方案，說服業務部門認可接受。最后，要學會處理人際關系，要像一個優秀銷售一樣經營自己，既有業務能力，又善于與人打交道，才能和業務部門和諧相處，拒絕不合理的方案，探討合理的方案，最終會得到業務部門的尊重與認可。

作為CRM產品經理，既要懂業務，也要懂系統，還要會做人，這三點缺一不可。缺少了任何一點，就會淪陷為業務執行的工具，而不能引導業務，實現自我價值。

?結語

至此，我們已經探討了CRM體系建設方方面面的話題。CRM建設，不僅僅是系統建設問題，更是業務體系設計問題。只有兩者很好的結合，才能真正產生價值。

希望讀者通過閱讀，能夠形成CRM體系的基本知識框架，當知識框架形成后，根據實際的工作經歷，堅持學習總結，逐步豐富框架中的細節，持續更新自己的知識體系，最后形成自己的知識框架。

希望文章對大家有所幫助。

相關閱讀

《漫談CRM體系化建設1 – CRM與客戶管理綜述》

《漫談CRM體系化建設2 – 如何開發客戶》

《漫談CRM體系化建設3 – 如何留住客戶》

《漫談CRM體系化建設4 – 如何服務客戶》

插播一條廣告

大家好，我是《決勝B端》作者楊堃，曾在VIPKID任產品總監一職。在工作中，遇見有很多優秀的B端產品經理，但缺少體系化、針對B端產品的實操訓練，在成長中走了許多彎路。

我努力將自己多年做B端產品的經驗提煉總結出來，和起點學院聯合打造了一門B端產品體系課——《To B產品實戰訓練營》希望能給需要的同學一些實質性的幫助。

幫助大家構建B端產品知識體系脈絡，掌握B端產品建設，從業務診斷、需求分析，到抽象建模、設計落地的全過程的方法思路，最終直接應用于工作實踐。

掃碼即可報名，還可為大家爭取到的專屬優惠~

立即搶座，報名成功后即可領取詳細課程資料！

作者：楊堃（微信號公眾號goYangKun），9年互聯網研發、產品設計經驗，曾就職于傳統外資保險公司，百度，現就職于vipkid。

本文由 @楊堃 原創發布于人人都是產品經理。未經許可，禁止轉載。