作者：Amigo

從業務日報升級為業務工程管理

Amigo 經驗分享

Steve Sue 在 LinkedIn 分享閱讀財務煉金術的感想：“…將公司財務部門從單純只作收付與記帳的後勤單位，升級成主動透過財報檢視提高公司競爭力並降低財務風險的策略單位…提升企業的資本配置能力，可以讓公司走得更長久…"

我非常贊同他的觀點：從記帳升級到財務管理，才能提高資本配置效率，發揮資料的價值。

不光是財務部要拉高視野與思維，業務部門同樣需要反思傳統管理業務的日報表，引入科學化的現代銷售管理方法論，學習審視資源配置，才能提高業績。

CRM 不單純是一個資訊系統，他的欄位與作業流程，其實就是不斷演化的業務工程管理 (Sales Engineering)。考慮到單純將紙本作業改為電腦紀錄並不會自動提升銷售業績，因此，在系統導入的同時，我組織多場課程，說明各種銷售方法論（例如 IBM 的 BANT、通路培訓最佳實踐）；製作多維報表與檢視面板，從代理商、經銷商、國家、產業、機會 (Opportunity) 類型（例如 Box Moving, Design-in, Project）等不同角度綜合分析業務的銷售管線 (Sales Pipeline)與銷售紀錄的量化資料；透過業務訓練 (Sales Coach) 搭配框架思考去審視目前的資源配置是否合理並思考行動方針是否能推進銷售階段 (Sales Stage)（參考在不同的銷售情境中套用 BANT 探索潛在客戶）。想辦法協助業務從應付了事的業務日報提升為根據資料與思考框架的業務管理。

許多 CRM 系統的導入往往流於形式，單純將紙本或文件表單檔案轉為資料庫紀錄，這些死記錄是沒有辦法協助業務拿下訂單。業務被業績獎金所吸引，必須要搭配提升業務技巧，賦能利用數位化資料提高結案效率，只有成功拿下更多業績獎金才會真正打動人心。

導入 CRM 需要不斷微調組織與流程，持續最佳化客戶服務體驗

Amigo 經驗分享 、、、、

今天剛從一場 Salesforce 台北的活動回來，最精彩的是客戶海陸家赫的總經理分享他的導入經驗。

總經理瞭解到這並不是單純的資訊系統，而是不斷來回調整流程與組織，從單一業務部門逐漸拆解為行銷、業務、客服三個部門，持續最佳化客戶服務體驗。在系統上線後，強制要求導入前六週所有業務只做一件事：在 Salesforce 上輸入業務報告與相關資料，用 Salesforce 做業務報告，徹底切斷對現有以 Excel 為基礎的業務報告流程，十分有魄力

他在分享中多次提及 2012 年 SoLoMo 框架，建立多通路接觸客戶。我另外推薦三個與 CRM 相關的框架：

  1. Javelin Experiment Board – 設計、測試、與最佳化服務流程，追蹤假設、測試方法、與結果。
  2. Buyer’s Journey 買家旅程 – 第一個參考連結提供行銷文件與買家旅程的框架，應該針對處於不同的銷售階段的潛在客戶，設計與發送對應的行銷文件。
  3. 在不同的銷售情境中套用 BANT 探索潛在客戶 – 基本的銷售方法論，應該將業務活動依照框架整理摘要，實施業務訓練。

另外補充四點：

    1. 如果要開發歐美潛在客戶，可以善用 LinkedIn Sales Navigator。
    2. 商機的新鮮度管理，Salesforce 的 Data Storage 空間有限，價格不低。
    3. 善用流程自動化，自動安插工作、電話、或電子郵件，這也是一種業務訓練。
    4. 在 GRPD 的規範下，避免長期保存客戶的敏感資料，細節並非越多越好。

Reference

  1. Buyer’s Journey 買家旅程
  2. Lead 商機
  3. LinkedIn Sales Navigator
  4. Prospect 潛在客戶
  5. Sales Coaching 業務訓練
  6. Wiki: SoLoMo
  7. YouTube: Experiment Board Tutorial with Grace Ng
  8. 在不同的銷售情境中套用 BANT 探索潛在客戶

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

Amigo 經驗分享 、

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 是否適合矩陣組織

Amigo 專題研究

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 突發事件

Amigo 專業術語

服務需求 (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 探索潛在客戶

Amigo 專題研究

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 報表，與背後的原因

Amigo 閱讀心得

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

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

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

繼續閱讀 →