2023年CRM系列02：銷售域的系統(tǒng)設(shè)計與實施（附UML建模內(nèi)容）

CRM系列02：銷售域的系統(tǒng)設(shè)計與實施（附UML建模內(nèi)容）在系統(tǒng)現(xiàn)狀調(diào)研、代碼規(guī)律梳理、業(yè)務(wù)調(diào)研、老板意向調(diào)研等一系列“軟性工作”告一段落后，最終可以開啟產(chǎn)品設(shè)計這個“硬性工作”了，想想都覺得難，帶著鐐銬跳舞，哈哈。

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

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

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

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

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

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

自下而上的建設(shè)；讓每一層的工作在下一層結(jié)束之前完成。關(guān)于第（2）點，是我在踩了坑之后才發(fā)覺的，之前讀書的時候始終沒理解，也就是下圖中下方的波浪圖。

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

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

這時候老板突然說在范圍層的流程要改（日常操作……），你答應(yīng)下來以后發(fā)覺，不光是流程改了，后面結(jié)構(gòu)層的頁面跳轉(zhuǎn)規(guī)律也要改，而緊隨其后的框架層的跳轉(zhuǎn)入口，改的就更大了，有的入口沒了，有的憑空消失好多內(nèi)容……

而假如遵循第（2）點的要求，在干完范圍層的業(yè)務(wù)流程圖之后，是可以設(shè)計結(jié)構(gòu)層的頁面流程圖的，但是不能連續(xù)干了，必需要確認(rèn)好范圍層的流程圖都沒問題了，再連續(xù)干到框架層。

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

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

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

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

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

三、工具3：UML工具

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

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

假如沒有UML，可能溝通與爭論就要花費更多的時間。下圖就是CRM系統(tǒng)設(shè)計中我整理的整套架構(gòu)規(guī)律，已經(jīng)脫敏（有點干）。

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

四、系統(tǒng)結(jié)構(gòu)講解

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

1.名片商機

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

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

這個規(guī)律下，就意味著一個名片可以有多個商機，便于銷售跟進。

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

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

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

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

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

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

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

2.流轉(zhuǎn)規(guī)章

由于業(yè)務(wù)條線多，每個銷售適合打的商機種類不同，通過自定義規(guī)章的分發(fā)，可以讓銷售更高效的轉(zhuǎn)化。此處的規(guī)章積累到肯定量級后，可以運用算法來幫助，并且逐步替代。

流轉(zhuǎn)規(guī)章，是依據(jù)商機上的業(yè)務(wù)屬性來推斷，通過選定不同的屬性組合作為特征，把某個特征的商機，分到某個目標(biāo)的安排組，讓安排組內(nèi)對應(yīng)的銷售進行轉(zhuǎn)化。業(yè)務(wù)屬性舉例如下：

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

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

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

Tips：這里也總結(jié)出一個系統(tǒng)設(shè)計閱歷。在設(shè)計詳細(xì)的規(guī)律限制時，這個規(guī)律限制總可以連續(xù)向上抽象成類，然后把抽象的類做勝利能，就能提高系統(tǒng)的可維護性

3.角色權(quán)限掌握

此處的角色掌握，是基于RBAC理論來設(shè)計的，后面也會單獨出一篇文章講解。

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

頁面權(quán)限掌握這個用戶能訪問到那個頁面；

數(shù)據(jù)權(quán)限是此用戶能通過查詢看到的數(shù)據(jù)范圍，有行權(quán)限掌握也有列權(quán)限掌握，看詳細(xì)業(yè)務(wù)需求。

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

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

4.訂單的多重績效判定

整個類圖中，應(yīng)當(dāng)是下面這里看起來繞一些了，先后展現(xiàn)了多種訂單的類，這里的作用其實是要設(shè)計一種完整的判定機制。

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

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

在其次層，準(zhǔn)時判定為銷售成單了，但這個成單的錢不肯定會算到銷售的績效里，這個比較好理解，舉個不恰當(dāng)?shù)睦?，一個賣鴨梨的檔口，在結(jié)算的時候突然消失了豬肉，這就是不合業(yè)務(wù)規(guī)范的。

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

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

看到這里，也盼望對你有關(guān)心，假如有其他問題，歡迎私信。

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

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

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

1.系統(tǒng)預(yù)備

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

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

2）是否有業(yè)務(wù)側(cè)的實施指揮與培訓(xùn)人員，在實施遇到問題后準(zhǔn)時跟進反饋。

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

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

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

3.產(chǎn)研側(cè)預(yù)備

產(chǎn)研在實施當(dāng)天的現(xiàn)場值班，節(jié)假日值班支配；產(chǎn)研側(cè)的應(yīng)急聯(lián)系人；實施期間的需求迭代工作節(jié)奏，便于快速反饋問題，迭代上線，降低業(yè)務(wù)心情阻力；運維側(cè)服務(wù)器的應(yīng)急方案，回滾方案。六、寫到最終

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

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