Displaying extended context for query match # 65,684 in text YL201901363
<< Prev Next >>
    
 

管理 , 那麼 有 沒 有 人才 就 沒 什麼 關係 了 。 以往 , 只是 將 叫 不 動 的 業務員 帶去 「 喝水 的 地方 」 , 幾乎 就 用光 了 所有 的 力氣 。 可是 , 只 帶 他 到 飲水 的 地方 , 業務員 還是 不 喝水 。 但是 , 如果 有 了 不管 是 誰 都 能 一目瞭然 的 數位化 系統 , 那 就 不 一樣 了 。 什麼 時候 、 做 了 什麼 、 何時 之前 該 做好 、 做 了 沒 ? 這些 事情 都 不用 再 靠 人才 來 讓 他們 動 起來 , 而是 利用 系統 讓 他們 去 做 。 這 就 是 不 依靠 人才 ( 業務員 個人 , 以及 管理 者 ) 的 業務 系統 。 說 得 更 清楚 明白 一點 , 這 是 用 電腦 來 管理 人 。 ◆ __UNDEF__ 建構 一 個 可 極度 利用 現有 資料庫 的 新 業務 系統 放棄 人才 , 把 需要 由 人才 去 做 的 工作 系統化 之後 , 之後 就 不 需要 人才 了 。 不管 是 用 人 來 讓 人 動 起來 , 或是 自己 讓 自己 動 起來 的 方法 我 都 試 過 , 完全 行不通 。 但 如果 是 用 電腦 來 讓 人 動 起來 的話 , 就 不 需要 具有 什麼 能力 或 經驗 。 並且 , 藉由 系統化 , 誰 都 能 自由 去 看 所有 的 行動 記錄 , 所以 , 一 個 管理 者 應該 能 在 短 時間 內 看 十幾 個 業務員 的 動向 。 拜訪 之後 的 結果 , 銷售 之後 的 結果 , 拓展 新 客戶 之後 的 結果 , 取得 車檢 過關 的 台數 結果 , 跟 同 一 區 競爭 對手 競爭 之後 贏 還是 輸 的 結果 等 , 只要 將 這些 結果 出來 之前 的 過程 都 系統化 , 都 能 看 得 到 的話 , 就 能 管理 。 因為 前提 是 不 倚靠 人才 , 所以 不需 再 倚靠 管理 者 的 能力 , 只要 讓 所有 的 業務員 都 去 做 他們 非 做 不可 的 事 。 這 不 是 對 人才 的 要求 , 而是 對 系統 的 要求 。 此外 , 如果 每 個 業務員 自己 的 行動 結果 都 變成 了 客觀 資料 , 被 即時 顯示 , 那 他 就 不得不 去 面對 , 不得不 去 行動 。 既然 我 已 看見 方向 , 接下來 就 只要 思考 如何 付諸 實現 的 方法 就 行 了 。 因為 已經 知道 理想 的 業務 風格 , 所以 該 做 的 就 是 和 程式 設計師 互相 激盪 腦力 , 一起 建構出 可 實際 執行 的 新 管理 系統 。 我 的 整體 構想 如下 : 過去 的 基本 資料庫 已 整理好 。 和 業務日報表 有關 的 是 約 三萬 筆 詳細 的 顧客 名簿 , 和 約 五萬 到 六萬 台 已 交 車輛 的 相關 詳細 車輛 清單 。 可以 從 這 二 個 資料庫 , 抽出 可 配合 當時 目的 所 需要 的 資料 。 (一) 在 訂定 某些 基準 之後 , 能夠 自動 選出 應該 訪問 的 客戶 和 訪問 的 頻率 。 如果 能 決定出 一 個 要 進行 的 業務 活動 , 應該 就 要 能 自動 篩選 要 去 拜訪 「 哪 位 客戶 」 、 「 什麼 時候 」 、 「 要 有 什麼 行動 比較 好 」 。 (二) 拜訪 時 的 記錄 等 這些 日報表 的 內容 , 可 利用 每 個 人 的 電腦 或 手機 輸入 , 經由 網路 更新 消息 。 所 輸入 、 更新 的 消息 , 除了 以前 只有 讓 管理 者 可 觀看 之外 , 現在 所有人 也 都 能 隨時 閱覽 。 管理 者 可以 和 所有 部下 隨時 交換 意見 , 如此 應該 就 能 即時 掌握 業務 活動 。 (三) 因為 管理 者 可以 和 業務員 共享 消息 , 結果 就 能 彼此 討論 , 決定 出 下 一 步 要 採取 的 對策 。 我 拜託 程式 設計師 , 要 做出 連 這 種 很 細微 的 策略 都 放 得 進去 的 系統 。 設計 這 個 系統 的 同時 , 會 針對 業務 活動 的 所有 過程 再 從頭 檢討 確認 。 ◆ 不 由 業務員 而 由 系統 決定 拜訪 的 客戶 、 頻率 要 去 拜訪 銷售 客戶 之前 , 如果 不 先 了解 客戶 , 決定 目標 , 從事 適合 對方 的 業務 , 那 就 無法 提升 效率 。 所以 要 知道 「 何時 」 、 「 和 誰 見面 」 、 「 要 說 什麼 」 。 因此 , 首先 要 從 拜訪 客戶 和 拜訪 次數 著手 。 將 以往 由 業務員 自己 決定 要 去 拜訪 哪 位 客戶 、 多久 拜訪 一 次 的 工作 , 交給 由 電腦 指示 的 「 拜訪 客戶 管理表 」 。 我 利用 A 公司 本來 就 有的 客戶 資料庫 , 先 以 平均 一 間 公司 擁有 的 車子 台數 為 基準 , 利用 A 、 B 、 C 分析 的 方法 , 將 客戶 分成 四 個 級別 , 設定出 以下 的 拜訪 管理 標準 。 A : 最 優良 客戶 即 擁有 十 台 以上 車輛 的 客戶 。 為了 將來 的 發展性 , 所有 的 服務 、 支援 活動 都 要 優先 處理 。 負責 的 業務員 , 每 個 月 要 去 拜訪 三 次 , 管理 者 、 分店 經理 每 個 月 去 拜訪 一 次 , 部門 經理 每 三 個 月 要 去 拜訪 一 次 , 老闆 有 義務 一 年 要 去 拜訪 三 次 。 其他 級別 也 是 同樣 的 分法 。 B : 準重點 管理 客戶 C : 改善 管理 客戶 D : 再 檢討 管理 客戶 以上 , 將 每 個 客戶 的 拜訪 頻率 用 表格 一目瞭然 的 整理出來 。 因為 有 這 個 管理表 , 就 不能 再 憑 個人 喜好 去 選擇 想 拜訪 的 客戶 。 就算 再 不 好 應付 的 客戶 , 只要 他 是 歸 在 A級 的 最 重要 客戶 名單 裡 , 就 非得 每 個 月 去 拜訪 他 三 次 不可 。 而 管理 者 會 從 日報表 檢查 結果 如何 。 ◆ 藉由 組合 二 個 以上 的 觀點 , 執行 和 獲利 有 直接 關係 的 拜訪 只 是 , 難免 會 有 人 懷疑 , 光 靠 這 個 ABC 分析 所 做 的 選擇 , 真的 會 和 公司 的 獲利 有 直接 關係 嗎 ? 這 問題 的 意思 是 , 雖然 這 位 客戶 屬於 A 級 , 並 不一定 表示 他 未來 就 會 購買 較多 的 新 車 , 反而 是 那些 原本 買 很少 車 的 C 級 客戶 , 說不定 更 有 可能 因為 業務 要 擴大 的 緣故 , 而 下 大 筆 訂單 。 為了 能 做好 拜訪 客戶 的 管理 , 我 又 想 , 是 不 是 不能 只 從 客戶 的 擁有 台數 來 作 判斷 , 是 不 是 應該 還要 有 另 一 個 觀點 , 也 是 和 公司 的 獲利 有 直接 關係 的 基準 才 行 ? 這時 , 我 看到 了 車檢 。 我 的 說明 順序 可能 有點 顛倒 。