CRM系列02：銷售域的系統設計與實施（附UML建模內容）在系統現狀調研、代碼規律梳理、業務調研、老板意向調研等一系列“軟性工作”告一段落后，最終可以開啟產品設計這個“硬性工作”了，想想都覺得難，帶著鐐銬跳舞，哈哈。

難歸難，這正是產品經理存在的價值。

在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端的業務而言，新產品的開發，決策者多少帶些試試看的心理因素。

一方面想突破困局，另一方面也想避開風險，這個是特別合理的考量。能做的，就是保持信念，時刻權衡改革的初心還