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

5 評論 9149 瀏覽 93 收藏 16 分鐘

編輯導語: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)層:每個頁面上的視覺設計。

CRM02 銷售域的系統(tǒng)設計與實施

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

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

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

CRM02 銷售域的系統(tǒng)設計與實施

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

比如在范圍層的時候你設計了一套銷售代下單的流程,步驟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è)務部門,再拆到部門下的動作和目標,最后在最下方整理出需求點。

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

CRM02 銷售域的系統(tǒng)設計與實施

三、工具3:UML工具

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

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

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

CRM02 銷售域的系統(tǒng)設計與實施

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

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

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

1. 名片&商機

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

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

CRM02 銷售域的系統(tǒng)設計與實施

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

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

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

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

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

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

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

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

2. 流轉規(guī)則

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

CRM02 銷售域的系統(tǒng)設計與實施

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

CRM02 銷售域的系統(tǒng)設計與實施

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

這類工作流引擎也做過調(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)了最大的靈活程度,最小的配置工作量。

CRM02 銷售域的系統(tǒng)設計與實施

4. 訂單的多重績效判定

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

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

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

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

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

CRM02 銷售域的系統(tǒng)設計與實施

以上,就是我設計的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é)議

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 客戶?是不是,只能成單之后才能叫客戶?

    回復
    1. 我也一直有這個疑問,一條線索進來什么時候被稱作商機,什么時候被稱作客戶

      來自北京 回復
  2. 老師 留個微X唄,想跟你交流

    來自北京 回復
    1. teshutieqiu1600
      另外我也在建群,歡迎交流哈!有碰撞才有成長

      來自北京 回復
  3. 剛發(fā)現(xiàn)這個文章和微信公眾號的原文章略被小編刪減,讀起來承接性不是很強,不過主體內(nèi)容不影響。

    來自北京 回復