編輯導語：B端業(yè)務系統(tǒng)的搭建并不容易。如何設計CRM系統(tǒng)，實現(xiàn)CRM系統(tǒng)的搭建和落地？本篇章里，作者總結了CRM系統(tǒng)銷售域的設計與操作流程，不妨來看一下，也許會對你有所啟發(fā)。

在系統(tǒng)現(xiàn)狀調(diào)研、代碼邏輯梳理、業(yè)務調(diào)研、老板意向調(diào)研等一系列“軟性工作”告一段落后，終于可以開啟產(chǎn)品設計這個“硬性工作”了，想想都覺得難，帶著鐐銬跳舞，哈哈。

難歸難，這正是產(chǎn)品經(jīng)理存在的價值。

在CRM銷售域的整體設計過程中，我用到了3個工具：

1. 《用戶體驗要素》的“戰(zhàn)范構架表”五層要素框架；
2. 用戶故事地圖；
3. UML，還記得最初的那篇UML文章嗎？->產(chǎn)品經(jīng)理的思考利器——UML（7000字長文）。

一、工具1：用戶體驗五要素

用戶體驗要素一書中，定義自上而下存在五層邏輯關系，我翻譯成了更符合我語境的內(nèi)容，依次為：

• 戰(zhàn)略層：可以理解為這個系統(tǒng)的定位和最終目的；
• 范圍層：基于戰(zhàn)略層歸納出的功能點和業(yè)務流程；
• 結構層：基于功能點與業(yè)務流程，設計出的頁面流程；
• 框架層：每個流程節(jié)點上頁面的內(nèi)容布局；
• 表現(xiàn)層：每個頁面上的視覺設計。

作者又強調(diào)了兩個點讓我受益匪淺：

1. 自下而上的建設；
2. 讓每一層的工作在下一層結束之前完成。

關于第（2）點，是我在踩了坑之后才發(fā)現(xiàn)的，之前讀書的時候一直沒理解，也就是下圖中下方的波浪圖。

如果你也沒用過或者不理解，我可以舉一個例子你就明白了。

比如在范圍層的時候你設計了一套銷售代下單的流程，步驟A-B-C-D，然后你正常設計了結構層頁面的頁面間的跳轉流程，然后很快你又根據(jù)頁面流程設計出了頁面中的跳轉入口，相當于從范圍層開始，你不間斷地干通了結構層，框架層，共3層。

這時候老板突然說在范圍層的流程要改（日常操作……），你答應下來以后發(fā)現(xiàn)，不光是流程改了，后面結構層的頁面跳轉邏輯也要改，而緊隨其后的框架層的跳轉入口，改的就更大了，有的入口沒了，有的憑空出現(xiàn)好多內(nèi)容……

而如果遵循第（2）點的要求，在干完范圍層的業(yè)務流程圖之后，是可以設計結構層的頁面流程圖的，但是不能繼續(xù)干了，必須要確認好范圍層的流程圖都沒問題了，再繼續(xù)干到框架層。

這樣看似麻煩，但其實是最省項目時間的做法，如果老板想看最終結果又要從根源否定，就跟老板打好提前量，告知時間上的損耗。否則就會出現(xiàn)大佬們在基礎流程上反復橫跳，對應的細節(jié)涉及了幾十個頁面，真的吐了。

二、工具2：用戶故事地圖

在戰(zhàn)略層梳理的時候，我用到了用戶故事地圖，這是一個針對敏捷開發(fā)使用的一套描述需求的工具，可以輔助描述更清晰的業(yè)務場景，業(yè)務需求。

用法也很簡單，頂部劃分用戶歷程的大階段，然后下方細拆，拆到每個業(yè)務部門，再拆到部門下的動作和目標，最后在最下方整理出需求點。

這樣的方式會很清晰，尤其是在流程很長的時候。圖可能看不清，不過沒關系，理解就好。

三、工具3：UML工具

正如我在UML那篇文章里提到的，UML作用的范圍，可以放到范圍層和結構層。如下圖。

真是一個利器，可以很清晰的梳理清楚思路，而且事后復盤的時候，也發(fā)現(xiàn)分配組那里沒有單獨抽象出來，造成了一些業(yè)務困擾，不過很快也都解決了。

如果沒有UML，可能溝通與討論就要花費更多的時間。下圖就是CRM系統(tǒng)設計中我整理的整套架構邏輯，已經(jīng)脫敏（有點干）。

上圖是用的UML的類圖，這里不是流程圖，而是類圖，代表的是系統(tǒng)里的各個業(yè)務概念的關系。

四、系統(tǒng)結構講解

我們基于上面的類圖，逐個講解各個類代表的意義，考慮到篇幅的限制，我會介紹核心的模塊，剩余的模塊大家可以看大圖。

1. 名片&商機

業(yè)務中收集到的客戶聯(lián)系方式，一般為手機號

名片和商機的轉化，在我做的CRM業(yè)務語境下，名片即為一個單獨的手機號，商機是基于名片的手機號再附加一個“業(yè)務屬性1”來生成的（如下圖）。

這個邏輯下，就意味著一個名片可以有多個商機，便于銷售跟進。

其實這里也暗含一個理念，即客戶和商機是獨立的，一個客戶可有多個商機，有的同學在設計的時候會把商機和客戶概念統(tǒng)一，數(shù)據(jù)也只有一份，造成了浪費。

然后商機也有對應的狀態(tài)，用來判定是否被銷售跟進。

再引申個行業(yè)栗子——大家可以討論。

某電商平臺，針對店鋪的運營，把店家老板的手機號作為唯一名片標識，然后業(yè)務體系中一個老板的手機號會關聯(lián)多個店鋪。此時的商機應該以哪個實體為準？

這個問題屬于開放問題了，如果是店鋪業(yè)務體量都較小，可能以老板粒度為線索更合適，防止不同的銷售跟進店鋪導致撞單。

但如果是店鋪體量很大，小型集團級別，可能就是需要把集團下不同的采購組作為線索了。

針對這個問題，大家可以在評論區(qū)里交流，我想會有很多新的收獲。

2. 流轉規(guī)則

因為業(yè)務條線多，每個銷售適合打的商機種類不同，通過自定義規(guī)則的分發(fā)，可以讓銷售更高效的轉化。此處的規(guī)則積累到一定量級后，可以運用算法來協(xié)助，并且逐步替代。

流轉規(guī)則，是根據(jù)商機上的業(yè)務屬性來判斷，通過選定不同的屬性組合作為特征，把某個特征的商機，分到某個目標的分配組，讓分配組內(nèi)對應的銷售進行轉化。業(yè)務屬性舉例如下：

其實這部分市面上有成熟的方案，叫做“工作流引擎”，甚至可以找到開源代碼。

這類工作流引擎也做過調(diào)研，靈活度可以滿足要求，但是批量管理工作流時會遇到實例結構不統(tǒng)一的問題，而且想做統(tǒng)計的時候，之前已有工作流會在流程結束時把日志清除，等等原因，改動已有的方案需要的成本更高，所以我們決定自研了一套類似引擎的解決方式，更貼合業(yè)務現(xiàn)實現(xiàn)狀。

此處會涉及到一個問題，即商機上的業(yè)務屬性如何標記？不要著急，我后面會單獨出一篇文章來講解。

Tips：這里也總結出一個系統(tǒng)設計經(jīng)驗。在設計具體的邏輯限制時，這個邏輯限制總可以繼續(xù)向上抽象成類，然后把抽象的類做成功能，就能提高系統(tǒng)的可維護性

3. 角色權限控制

此處的角色控制，是基于RBAC理論來設計的，后面也會單獨出一篇文章講解。

RBAC直觀解釋，就是系統(tǒng)用戶的權限，可以拆成兩個層面，一個是頁面的權限，一個是數(shù)據(jù)的權限。

頁面權限控制這個用戶能訪問到那個頁面；

數(shù)據(jù)權限是此用戶能通過查詢看到的數(shù)據(jù)范圍，有行權限控制也有列權限控制，看具體業(yè)務需求。

把頁面和數(shù)據(jù)分開，可以很好的提高配置的靈活性。比如銷售類角色，必須包含工作臺，但是不同的銷售，他們每個人看到的銷售數(shù)據(jù)只能限制在他們自己的銷售組內(nèi)，更細化的是只有組長能看到組內(nèi)的，普通銷售只能看到自己的。

通過角色授權，讓“銷售”的角色頁面范圍包含工作臺。然后每個銷售員工在自己的用戶下有單獨的數(shù)據(jù)范圍選擇，這樣就實現(xiàn)了最大的靈活程度，最小的配置工作量。

4. 訂單的多重績效判定

整個類圖中，應該是下面這里看起來繞一些了，先后展示了多種訂單的類，這里的作用其實是要設計一種完整的判定機制。

在一個未來要迭代成自動化營銷和銷售的CRM方案里，銷售并不是成單唯一的因素，未來肯定還會有其他成單的歸因點，此處要做到系統(tǒng)上有預留準備。

銷售的成單是從訂單系統(tǒng)的基礎訂單上同步的，在成單時通過關聯(lián)查詢成單手機號&跟進記錄&跟進時刻&銷售坐席來判定是銷售成單，可視為銷售歸因的成單。這是第一層。

在第二層，及時判定為銷售成單了，但這個成單的錢不一定會算到銷售的績效里，這個比較好理解，舉個不恰當?shù)睦?，一個賣鴨梨的檔口，在結算的時候突然出現(xiàn)了豬肉，這就是不合業(yè)務規(guī)范的。

所以就會有這層限制，不過也看業(yè)務的管理理念，如果放開，不配置即可，如果收緊，再開啟就好，靈活性很高。此處的功能點也和研發(fā)評估過，成本很低，為了防止業(yè)務的不確定性，這算是一個很好的兜底。

以上，就是我設計的CRM銷售域的系統(tǒng)結構，這里還有很多細節(jié)，比如和大數(shù)據(jù)的打通，和人力系統(tǒng)的打通等等，以及具體頁面設計，更上層的數(shù)據(jù)營銷方法論，有很多內(nèi)容可以分享的，只不過想分享的實在點，就需要拿結果驗證這個方法可行，不過涉及到業(yè)務數(shù)據(jù)，內(nèi)容略敏感，就沒寫，還請見諒~

看到這里，也希望對你有幫助，如果有其他問題，歡迎私信。

接下來，就來講解下系統(tǒng)的實施。

五、系統(tǒng)的實施

經(jīng)過緊張的研發(fā)和測試之后，就涉及到系統(tǒng)上線后的實施工作了。對于一個B端的系統(tǒng)，在事后總結經(jīng)驗，實施階段要做如下方面的準備。

1. 系統(tǒng)準備

1. 數(shù)據(jù)庫環(huán)境的打通兼容；
2. 回滾方案的準備；
3. 業(yè)務新老數(shù)據(jù)的切割。

2. 業(yè)務準備

1）是否有實施的核心決策人？如果有的話最好是BOSS，如果BOSS躲在后面，又沒有業(yè)務的人上前，只能說難度會很大?？简灲M織，也考驗決策者。

2）是否有業(yè)務側的實施指揮與培訓人員，在實施遇到問題后及時跟進反饋。

3）是否有試點小組？可以盡量讓業(yè)務的沖擊降到最小。

4）提前準備新系統(tǒng)的配置方案。

5）提前準備新系統(tǒng)的申請相關機制，做到有序處理。

3. 產(chǎn)研側準備

1. 產(chǎn)研在實施當天的現(xiàn)場值班，節(jié)假日值班安排；
2. 產(chǎn)研側的應急聯(lián)系人；
3. 實施期間的需求迭代工作節(jié)奏，便于快速反饋問題，迭代上線，降低業(yè)務情緒阻力；
4. 運維側服務器的應急方案，回滾方案。

六、寫到最后

對于B端的業(yè)務而言，新產(chǎn)品的開發(fā)，決策者多少帶些試試看的心理因素。

一方面想突破困局，另一方面也想避免風險，這個是非常合理的考量。能做的，就是保持信心，時刻權衡改革的初心還有現(xiàn)實的困難，如果確定無法承擔，就及時止損，如果發(fā)現(xiàn)有明顯的優(yōu)勢，就要繼續(xù)堅持，哪怕反對的呼聲很高也是暫時的，只要體現(xiàn)在了業(yè)績上，大家就都沒話說了。

感謝各位朋友的閱讀，CRM的系統(tǒng)結構與實施工作的內(nèi)容就告一段落，后面會針對本文提到的《業(yè)務屬性的標記》《基于RBAC的權限體系設計》再出兩篇文章。

大家如果有相關的想法，或者有問題，歡迎評論區(qū)留言交流，平時工作較忙，我會集中回復。

作者：羅文正雄；公眾號：羅文正雄

本文由 @羅文正雄 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉載

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