CRM 的導入與推動需要系統管理者的參與

CRM 專案的系統管理者與開發者

在一般的軟體客製開發專案中,會擁有比較多的開發者 (Developer)。但是在 CRM 導入專案中,系統管理者 (System Admin) 的角色非常吃重,因為這類專案通常會選擇低程式需求的可高度自訂平台 (Codeless Configurable Platform),透過管理者完成大部分的基本功能。CRM 的開發者會專注在與其他系統整合,正規化與串接資訊。隨著目前越來越成熟的連接器隨選服務 (SaaS Connector),未來串接工作也會逐漸轉移到管理者身上。

在下面的三篇文章,有針對 Salesforce.com 平台,從技術的觀點比較兩者工作與職涯差異:

  1. desynit: The Difference Between a Salesforce Administrator and Developer – Jenny’s Admin Tip #10
  2. DeZyre: Salesforce Careers- Salesforce Administrator vs. Salesforce Developer
  3. Salesforce Developers: Difference between Customization and Configuration

觀點、過程、與成果均不同

管理者熟悉系統內建功能,思考需求可以如何被設定

他們會與使用者密切溝通,在系統限制下協調出使用者可以接受的結果,並且隨時視情況調整,需求可以快速變動。

管理者的交付品質會與軟體平台的彈性與成熟度有關,通常能夠比開發者更快交付上線,並且提供高度的穩定性。

另一方面,開發者會深入瞭解使用者需求,偏重在如何使用程式語言完美地搭乘使用者交付的任務。

使用者的需求要確認與凍結,盡可能地避免規格變動,雖然會受限於系統平台,但會比管理者來的更有彈性,比較能滿足深入的客製。

開發者的最終交付成果會與使用者需求管理、時程管理、開發者資質、團隊協同合作默契、可用資源、與系統平台本身的限制等等多項因素有關。通常會經歷完整的軟體開發流程,相對比開發者更慢才能交付上線。在上線初期的穩定性需要密切觀察,沒有歷史資料可以協助判斷。

CRM 的需求特性

高度的不確定性、要能快速反應組織與業務需求、高度的政治敏感性。

市場瞬息萬變,業務單位必須盡快跟上腳步,通常無法接受以月或季的單位交付功能。延遲交付的功能通常也早已不會是使用者當下的需求。也因為缺乏即時驗證可行性,交付後也面臨不斷被修改,開發團隊容易深陷泥沼,無法脫身。

例如,應映公司業務擴大,組織重整 (Reorg),將原先單一的 EMEA 分為四個部門,需要重新配置人員,調整每個人的業務方向。期間也會因為人員補充與調度,經常需要重新分配每個人負責的銷售區域與產品,這對開發者是一個充滿不確定性而且緊急的需求。在壓力下趕工,增加出現錯誤的機率。又,業務部門之間彼此競爭,客戶資料存取權的錯誤導致資料讓其他部門存取,政治矛盾最終會撲向開發者身上,造成業務與資訊部門對立。

國外如何管理

行銷業務部門設置專屬管理者直接對行銷業務主管負責,不屬於資訊部門。通常稱為使用者端的商業分析師 (User Side Business Analyst)。資訊部會對應到管理者,並不與使用者直接接觸。

也有案例是直接將 CRM 歸屬行銷業務部管理,預算也由前者編列。資訊部負責相對單純的系統整合,有被指派的行銷業務窗口對應,彙整與分析需求,降低直接面對使用者的機會,減少全面性的摩擦。

如果能順利運作,累積溝通經驗,接下來的利潤中心 (Profit Center) 與資訊外包 (IT Outsourcing) 會相對順利推展。

台灣現況

許多公司從黑手起家,相對堅持既有業務流程的原創與獨特性。考慮到大量客製,團隊充斥開發者而缺乏管理者參與,一開始就缺乏管理思維。這也導致業務流程被程式碼寫死,也相對容易被開發團隊綁架。後續不斷的疊床架屋與追加預算,徒增系統複雜度與擁有成本。

從斷捨離出發,打造你的新家感一書中有提到,設計新的居家環境要從改變現有生活習慣開始,否則美好只會在剛搬入的新鮮期,之後倒入亂堆垃圾與髒衣物很快就會出現。

最重要的企業流程再造 (Business Reengineering) 經常被忽略,跳過參考國外最佳實踐 (Best Practice) 重新升級行銷業務團隊,單純的紙張電子化是看不到數位時代真正的影響力。

將管理者加入專案,分層負責是成功的關鍵

我推薦客戶的導入方式是根據 CRM 成熟度模型,採取:

  1. 以顧問與管理者團隊主導,逐步測試探索,同時提升使用者對業務工程學 (Sales Engineering) 的認知
  2. 由部門管理者滿足第一線需求,資訊部負責第二線

利用管理者協助行銷業務團隊在最短的時間內,有效的測試各種提升業務的手法。讓開發者專心在系統整合,從 CRM 存取財務與客戶服務系統的資訊,CRM 才能成為提昇協同合作效率的平台,集中分散的資訊。

Reference

  1. desynit: The Difference Between a Salesforce Administrator and Developer – Jenny’s Admin Tip #10
  2. DeZyre: Salesforce Careers- Salesforce Administrator vs. Salesforce Developer
  3. Salesforce Developers: Difference between Customization and Configuration
  4. 博客來:從斷捨離出發,打造你的新家感
  5. 從探索 CRM 成熟度模型著手整理 SFA 成熟度模型
廣告

評估 EspoCRM 是否適合矩陣組織

EspoCRM 是一套 OpenSource CRM,可以在 TurnKey Linux 的 EspoCRM 頁面選擇打包好的虛擬機器映像檔案快速設定啟用。

除了與其他系統整合之外,我比較常遇到大型客戶的需求包括:

  1. 機會管理要支援多種不同的銷售方法論,有各自的銷售階段贏率
  2. 部門主管會兼任其他平行部門主管
  3. 矩陣式組織共享機會管理
  4. 群組與矩陣報表
  5. 容納多報表的顯示面板
  6. 協同作業溝通

這些功能在 Salesforce.com 上都可以利用設定做到,但是在 Open Source CRM 上就比較難找到滿意的解決方案,我使用過的經驗包括:

  1. SugarCRM Community Edition: 已經停止維護,完全不建議繼續使用
  2. Zurmo: 3.1.3 版本自從 2016/5/1 之後就沒有大變動,目前是 2017/10/24 的 3.2.3。內建 Gamification,報表工具優良,有支援工作流程,無法透過設定建立新物件,與跨物件的關聯欄位。
  3. vTiger 7 Open Source: 報表工具非常不理想,有簡單的工作流程,可以快速建立物件,但尚未支援跨物件的關聯欄位。
  4. SuiteCRM: Email 設定失敗,始終無法順利管理 Email Campaign 的點擊成效。介面為了搭配行動裝置,尺寸都很大,反而造成在一般電腦上的操作不變。報表工具不理想,有簡單的工作流程,可以快速建立物件,但尚未支援跨物件的關聯欄位。

目前在 EspoCRM 上看到可以滿足多數功能,雖然報表與工作流程需要另購 EspoCRM Advanced Pack,每年 USD 344/Instance。相對於自行開發的費用,還是便宜許多,因此紀錄分享相關業務需求要如何利用內建設定達成需求與限制,隨著越來越熟悉這套軟體,我會持續更新這篇文章:

繼續閱讀

Service Request 服務需求與 Incident 突發事件

服務需求 (Service Request) 是指提供給使用者的服務,通常會預先批准,或屬於標準變動;突發事件 (Incident) 意指因不正常運作或損毀,導致預期外的中斷。

服務目錄 (Service Catalog) 羅列可以提供的服務項目 (Service Item),有時會以自助式服務 (Self-service) 的方式呈現。它包含使用者提供的相關資訊,自動化的工作指派,與批准流程。

範例

服務需求:教育訓練、韌體升級

突發事件:無法載入系統、無法列印、無法執行程式

Reference

  1. fresh service Blog: Incident and Service request: How are they different?
  2. samanage: What’s the Difference Between Incidents, Service Requests, and Tickets?

在不同的銷售情境中套用 BANT 探索潛在客戶

BANT 原始是用在辨識潛在客戶 (Prospect) 的機會 (Opportunity) ,在不同類型的機會中我會詢問業務下列問題:

銷售產品或服務類型的機會

業務向使用單位銷售產品或服務。

Budget 預算

  1. 是否有預算
  2. 預算如何執行
  3. 預算如何編列

Authority 職權

  1. 誰負責編列預算單位
  2. 誰負責評估產品
  3. 誰負責採購
  4. 誰做最後決定

Need 需求

  1. 痛苦是什麼
  2. 那些人感到痛苦
  3. 為了消除痛苦,曾經做過那些事

Timeline 時程

  1. 何時決定
  2. 何時下單
  3. 何時上線
  4. 何時驗收

開發經銷商或代理商的通路機會

當原廠業務向經銷商或代理商銷售合作夥伴合約,或代理商業務向經銷商推廣產品。

Budget 預算

  1. 合作夥伴預計的總銷售金額
  2. 規劃如何達成銷售目標
  3. 訂單如何計算有效性

Authority 職權

  1. 誰負責向使用單位銷售
  2. 誰負責評估產品與組合
  3. 誰負責下單採購
  4. 誰做最後決定

Need 需求

  1. 對現有產品組合有哪些產品規格與品質上的不滿
  2. 對現有產品組合有哪些支援服務上的不滿
  3. 對現有產品組合有哪些推廣/行銷上的不滿
  4. 那些人感到痛苦,在什麼部門
  5. 為了消除痛苦,曾經做過那些事

Timeline 時程

  1. 何時決定簽約
  2. 何時安排業務簡報
  3. 何時安排業務訓練
  4. 何時購買測試機器
  5. 何時會有第一筆訂單

Reference

  1. BANT
  2. Opportunity 機會
  3. Prospect 潛在客戶

業務代表與業務主管關心的 CRM 報表,與背後的原因

CRM 平台上有許多來自業務與其他系統彙整的資料,透過檢視 (View) 與報表工具 (Report Tools),可以快速整理過濾資料,將自己先前紀錄的資料,加以分析,協助找出突破業績的盲點。

對於業務主管,CRM 平台可以將麾下的業務資料統計整理,挑出重點做機會管理,並且隨時掌握業務狀況,不必等到週報會議才發現狀況。

我根據 Salesforce.com 的 BEST PRACTICES: Sales & Marketing Overview5 Sales Reports Every Sales Manager Should Be ReviewingSales reports every sales manager should be reviewing4 Sales Reports For Successful Sales Managers、等來源,與本身擔任原廠國外業務、代理商通路業務、與 CRM 導入經驗,整理出必備的業務報表,並且說明背後的原因:

繼續閱讀

從探索 CRM 成熟度模型著手整理 SFA 成熟度模型

CRM 導入的問題

標準化的快速導入服務

相對於傳統冗長耗時的系統導入,Salesforce.com 由合作夥伴提供的 SFA (Salesforce Automation) 快速導入服務藉由是先定義好的Project Scope標準化作業程序、與統一的公開定價,設定好客戶的期待、費用、與合作夥伴有限的工作範圍,協助客戶在 5 個工作天內將系統上線。

繼續閱讀