起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識CRM系列02：銷售域的系統設計與實施（附UML建模內容）
編輯導語：B端業務系統的搭建并不容易。如何設計CRM系統，實現CRM系統的搭建和落地？本篇章里，作者總結了CRM系統銷售域的設計與操作流程，不妨來看一下，也許會對你有所啟發。
在系統現狀調研、代碼邏輯梳理、業務調研、老板意向調研等一系列“軟性工作”告一段落后，終于可以開啟產品設計這個“硬性工作”了，想想都覺得難，帶著鐐銬跳舞，哈哈。
難歸難，這正是產品經理存在的價值。
在CRM銷售域的整體設計過程中，我用到了3個工具：
- 《用戶體驗要素》的“戰范構架表”五層要素框架；
- 用戶故事地圖；
- UML，還記得最初的那篇UML文章嗎？->產品經理的思考利器——UML（7000字長文）。
一、工具1：用戶體驗五要素
用戶體驗要素一書中，定義自上而下存在五層邏輯關系，我翻譯成了更符合我語境的內容，依次為：
- 戰略層：可以理解為這個系統的定位和最終目的；
- 范圍層：基于戰略層歸納出的功能點和業務流程；
- 結構層：基于功能點與業務流程，設計出的頁面流程；
- 框架層：每個流程節點上頁面的內容布局；
- 表現層：每個頁面上的視覺設計。
作者又強調了兩個點讓我受益匪淺：
- 自下而上的建設；
- 讓每一層的工作在下一層結束之前完成。
關于第（2）點，是我在踩了坑之后才發現的，之前讀書的時候一直沒理解，也就是下圖中下方的波浪圖。
如果你也沒用過或者不理解，我可以舉一個例子你就明白了。
比如在范圍層的時候你設計了一套銷售代下單的流程，步驟A-B-C-D，然后你正常設計了結構層頁面的頁面間的跳轉流程，然后很快你又根據頁面流程設計出了頁面中的跳轉入口，相當于從范圍層開始，你不間斷地干通了結構層，框架層，共3層。
這時候老板突然說在范圍層的流程要改（日常操作……），你答應下來以后發現，不光是流程改了，后面結構層的頁面跳轉邏輯也要改，而緊隨其后的框架層的跳轉入口，改的就更大了，有的入口沒了，有的憑空出現好多內容……
而如果遵循第（2）點的要求，在干完范圍層的業務流程圖之后，是可以設計結構層的頁面流程圖的，但是不能繼續干了，必須要確認好范圍層的流程圖都沒問題了，再繼續干到框架層。
這樣看似麻煩，但其實是最省項目時間的做法，如果老板想看最終結果又要從根源否定，就跟老板打好提前量，告知時間上的損耗。否則就會出現大佬們在基礎流程上反復橫跳，對應的細節涉及了幾十個頁面，真的吐了。
二、工具2：用戶故事地圖
在戰略層梳理的時候，我用到了用戶故事地圖，這是一個針對敏捷開發使用的一套描述需求的工具，可以輔助描述更清晰的業務場景，業務需求。
用法也很簡單，頂部劃分用戶歷程的大階段，然后下方細拆，拆到每個業務部門，再拆到部門下的動作和目標，最后在最下方整理出需求點。
這樣的方式會很清晰，尤其是在流程很長的時候。圖可能看不清，不過沒關系，理解就好。
三、工具3：UML工具
正如我在UML那篇文章里提到的，UML作用的范圍，可以放到范圍層和結構層。如下圖。
真是一個利器，可以很清晰的梳理清楚思路，而且事后復盤的時候，也發現分配組那里沒有單獨抽象出來，造成了一些業務困擾，不過很快也都解決了。
如果沒有UML，可能溝通與討論就要花費更多的時間。下圖就是CRM系統設計中我整理的整套架構邏輯，已經脫敏（有點干）。
上圖是用的UML的類圖，這里不是流程圖，而是類圖，代表的是系統里的各個業務概念的關系。
四、系統結構講解
我們基于上面的類圖，逐個講解各個類代表的意義，考慮到篇幅的限制，我會介紹核心的模塊，剩余的模塊大家可以看大圖。
1. 名片&商機
業務中收集到的客戶聯系方式，一般為手機號
名片和商機的轉化，在我做的CRM業務語境下，名片即為一個單獨的手機號，商機是基于名片的手機號再附加一個“業務屬性1”來生成的（如下圖）。
這個邏輯下，就意味著一個名片可以有多個商機，便于銷售跟進。
其實這里也暗含一個理念，即客戶和商機是獨立的，一個客戶可有多個商機，有的同學在設計的時候會把商機和客戶概念統一，數據也只有一份，造成了浪費。
然后商機也有對應的狀態，用來判定是否被銷售跟進。
再引申個行業栗子——大家可以討論。
某電商平臺，針對店鋪的運營，把店家老板的手機號作為唯一名片標識，然后業務體系中一個老板的手機號會關聯多個店鋪。此時的商機應該以哪個實體為準？
這個問題屬于開放問題了，如果是店鋪業務體量都較小，可能以老板粒度為線索更合適，防止不同的銷售跟進店鋪導致撞單。
但如果是店鋪體量很大，小型集團級別，可能就是需要把集團下不同的采購組作為線索了。
針對這個問題，大家可以在評論區里交流，我想會有很多新的收獲。
2. 流轉規則
因為業務條線多，每個銷售適合打的商機種類不同，通過自定義規則的分發，可以讓銷售更高效的轉化。此處的規則積累到一定量級后，可以運用算法來協助，并且逐步替代。
流轉規則，是根據商機上的業務屬性來判斷，通過選定不同的屬性組合作為特征，把某個特征的商機，分到某個目標的分配組，讓分配組內對應的銷售進行轉化。業務屬性舉例如下：
其實這部分市面上有成熟的方案，叫做“工作流引擎”，甚至可以找到開源代碼。
這類工作流引擎也做過調研，靈活度可以滿足要求，但是批量管理工作流時會遇到實例結構不統一的問題，而且想做統計的時候，之前已有工作流會在流程結束時把日志清除，等等原因，改動已有的方案需要的成本更高，所以我們決定自研了一套類似引擎的解決方式，更貼合業務現實現狀。
此處會涉及到一個問題，即商機上的業務屬性如何標記？不要著急，我后面會單獨出一篇文章來講解。
Tips：這里也總結出一個系統設計經驗。在設計具體的邏輯限制時，這個邏輯限制總可以繼續向上抽象成類，然后把抽象的類做成功能，就能提高系統的可維護性
3. 角色權限控制
此處的角色控制，是基于RBAC理論來設計的，后面也會單獨出一篇文章講解。
RBAC直觀解釋，就是系統用戶的權限，可以拆成兩個層面，一個是頁面的權限，一個是數據的權限。
頁面權限控制這個用戶能訪問到那個頁面；
數據權限是此用戶能通過查詢看到的數據范圍，有行權限控制也有列權限控制，看具體業務需求。
把頁面和數據分開，可以很好的提高配置的靈活性。比如銷售類角色，必須包含工作臺，但是不同的銷售，他們每個人看到的銷售數據只能限制在他們自己的銷售組內，更細化的是只有組長能看到組內的，普通銷售只能看到自己的。
通過角色授權，讓“銷售”的角色頁面范圍包含工作臺。然后每個銷售員工在自己的用戶下有單獨的數據范圍選擇，這樣就實現了最大的靈活程度，最小的配置工作量。
4. 訂單的多重績效判定
整個類圖中，應該是下面這里看起來繞一些了，先后展示了多種訂單的類，這里的作用其實是要設計一種完整的判定機制。
在一個未來要迭代成自動化營銷和銷售的CRM方案里，銷售并不是成單唯一的因素，未來肯定還會有其他成單的歸因點，此處要做到系統上有預留準備。
銷售的成單是從訂單系統的基礎訂單上同步的，在成單時通過關聯查詢成單手機號&跟進記錄&跟進時刻&銷售坐席來判定是銷售成單，可視為銷售歸因的成單。這是第一層。
在第二層，及時判定為銷售成單了，但這個成單的錢不一定會算到銷售的績效里，這個比較好理解，舉個不恰當的例子，一個賣鴨梨的檔口，在結算的時候突然出現了豬肉，這就是不合業務規范的。
所以就會有這層限制，不過也看業務的管理理念，如果放開，不配置即可，如果收緊，再開啟就好，靈活性很高。此處的功能點也和研發評估過，成本很低，為了防止業務的不確定性，這算是一個很好的兜底。
以上，就是我設計的CRM銷售域的系統結構，這里還有很多細節，比如和大數據的打通，和人力系統的打通等等，以及具體頁面設計，更上層的數據營銷方法論，有很多內容可以分享的，只不過想分享的實在點，就需要拿結果驗證這個方法可行，不過涉及到業務數據，內容略敏感，就沒寫，還請見諒~
看到這里，也希望對你有幫助，如果有其他問題，歡迎私信。
接下來，就來講解下系統的實施。
五、系統的實施
經過緊張的研發和測試之后，就涉及到系統上線后的實施工作了。對于一個B端的系統，在事后總結經驗，實施階段要做如下方面的準備。
1. 系統準備
- 數據庫環境的打通兼容；
- 回滾方案的準備；
- 業務新老數據的切割。
2. 業務準備
1）是否有實施的核心決策人？如果有的話最好是BOSS，如果BOSS躲在后面，又沒有業務的人上前，只能說難度會很大。考驗組織，也考驗決策者。
2）是否有業務側的實施指揮與培訓人員，在實施遇到問題后及時跟進反饋。
3）是否有試點小組？可以盡量讓業務的沖擊降到最小。
4）提前準備新系統的配置方案。
5）提前準備新系統的申請相關機制，做到有序處理。
3. 產研側準備
- 產研在實施當天的現場值班，節假日值班安排；
- 產研側的應急聯系人；
- 實施期間的需求迭代工作節奏，便于快速反饋問題，迭代上線，降低業務情緒阻力；
- 運維側服務器的應急方案，回滾方案。
六、寫到最后
對于B端的業務而言，新產品的開發，決策者多少帶些試試看的心理因素。
一方面想突破困局，另一方面也想避免風險，這個是非常合理的考量。能做的，就是保持信心，時刻權衡改革的初心還有現實的困難，如果確定無法承擔，就及時止損，如果發現有明顯的優勢，就要繼續堅持，哪怕反對的呼聲很高也是暫時的，只要體現在了業績上，大家就都沒話說了。
感謝各位朋友的閱讀，CRM的系統結構與實施工作的內容就告一段落，后面會針對本文提到的《業務屬性的標記》《基于RBAC的權限體系設計》再出兩篇文章。
大家如果有相關的想法，或者有問題，歡迎評論區留言交流，平時工作較忙，我會集中回復。
作者：羅文正雄；公眾號：羅文正雄
本文由 @羅文正雄 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Pexels，基于 CC0 協議
客戶？是不是，只能成單之后才能叫客戶？
我也一直有這個疑問，一條線索進來什么時候被稱作商機，什么時候被稱作客戶
老師 留個微X唄，想跟你交流
teshutieqiu1600
另外我也在建群，歡迎交流哈！有碰撞才有成長
剛發現這個文章和微信公眾號的原文章略被小編刪減，讀起來承接性不是很強，不過主體內容不影響。