把 FAX 收單搬到網路上 ── 雙軌並行期的設計與分階段轉移實務

在上一篇文章「什麼是 EDI?如何讓企業間收發訂單更輕鬆」中,我們整理了將以 FAX 或郵件收到的訂單由人工重新輸入的作業,替換為系統間資料交換的機制。

本文是該篇的續集。主題從「理解機制」再往前一步,聚焦於該如何轉移。

「想把 FAX 收單網路化」這類諮詢,多半會接著這麼說:

「不過有些客戶只能用 FAX」

「銷售管理系統想維持現狀繼續使用」

「切換期間訂單中斷會很困擾」

也就是說,實務上的課題並不是打造一套網路收單系統,而是在 FAX 仍然存在的情況下,如何設計逐步轉移到網路的期間。

本文將 FAX 收單的網路化,聚焦在雙軌並行期的設計、CSV 匯入這種中間形態、商品與客戶主檔的整備、如何讓客戶配合這四點來整理。

1. 先講結論

規劃 FAX 收單網路化時,重點如下:

• 目標不是「廢除 FAX」,而是「減少需要人工輸入的訂單件數」
• 前提是FAX 與網路的雙軌並行期一定會發生,先設計期間與衡量方式
• 收單方式(管道)可以有多種,但公司內部的收單處理要整合成一條
• 不要一開始就要求用網頁畫面輸入,先準備CSV 匯入這種中間形態
• 由於網路收單畫面會直接把商品、客戶主檔呈現出來,要先整備主檔
• 客戶不要一次全部切換,依件數與配合度分類後依序轉移

JIPDEC 也指出,若仍保留 FAX、電話等人工處理,就需要對應人力,難以充分獲得效率化的效果。正因如此,不該把雙軌並行期當成「不得不發生的事」放著不管,而應該把「縮短它」這個計畫本身當作設計的對象。

2. 一次性全面網路化容易失敗的原因

FAX 收單的網路化有個特點,不是光靠公司內部系統的考量就能決定,因為送出訂單的是客戶。

若對所有客戶統一宣布「下個月起請改用網路下單」,容易導致以下失敗:

• 只能用 FAX 下單的客戶,不再是「例外」,而變成「計畫的障礙」
• 每個客戶的情況不同,卻被要求遵守同樣的期限
• 未轉移的客戶訂單仍持續透過 FAX 送來,雙軌並行變得無限期化
• 被評價為「網路化了,人力卻沒有減少」,專案因此停滯

原因在於把目標設定為「消除 FAX」。

若把目標換成「減少需要人工輸入的訂單件數」,計畫就會變得務實。舉例來說,只要占訂單七成的主要客戶轉移到網路或 CSV,即使剩下三成仍用 FAX,輸入作業也會大幅減少。

不要一次全部推動,而是從效果最大的地方依序推動,這就是分階段轉移的基本原則。

3. 轉移後的樣貌 ── 入口多元,內部處理統一

在設計分階段轉移之前,先描繪出目標的樣貌。

重點在於將收單管道與收單處理分開來思考。

[收單管道]                     [共通收單資料]            [公司內部處理]

FAX ──── 承辦人輸入 ──┐
郵件附件 ── 承辦人輸入 ─┤
CSV 匯入 ─── 自動匯入 ────┼──→ 收單資料 ──→ 庫存分配・出貨・請款
網路收單畫面 ── 自動登錄 ───┘      (格式統一)

無論收單管道有多少種,只要後端的收單資料格式與處理統一成一條,庫存、出貨、請款等後續作業就能維持共通運作。

反過來說,若每個管道都各自建立不同的處理或不同的帳冊,管道每增加一種,業務就會變得更複雜,雙軌並行的負擔也會持續增加。

即使是透過 FAX 收到的訂單,只要承辦人輸入之後,就要讓它成為與其他管道相同的收單資料。所謂轉移,可以說就是減少流入這張圖中「承辦人輸入」那一列的件數,增加流入「自動匯入」「自動登錄」那幾列件數的工作。

不一定要重做既有的銷售管理系統。只要能確認是否可以新增收單資料的入口(CSV 匯入功能、資料庫連接、API 等),就能在保留現有機制的情況下推進。這個確認要點,正如上一篇 EDI 文章中「確認與內部系統的連接」所整理的。

4. CSV 匯入這種中間形態

要求客戶從 FAX 直接跳到網頁畫面輸入,有時對客戶來說負擔會很大。

從下單方的角度來看,網頁畫面輸入意味著「把自己公司訂購系統或 Excel 做好的訂單,再重新輸入一次到對方的畫面上」。如果客戶已經用自己的機制產生訂單資料,那麼直接以檔案形式接收並匯入,對雙方的作業量都比較少。

因此作為中間形態,準備 CSV(或 Excel)匯入。

第一階段:以郵件附件方式接收 CSV,由承辦人透過匯入功能讀取
第二階段:客戶從網頁上傳 CSV,系統自動匯入
第三階段:已定型化的客戶改用網路收單畫面或 EDI

即使是第一階段,相較於看著訂購單手動輸入,輸入時間與轉錄錯誤都會大幅減少。客戶端的變化只是「把原本用 FAX 傳送的東西改成郵件附件」這種程度,因此也比較容易取得配合,這是它的優點。

設計 CSV 匯入時,至少要決定以下項目。

CSV 看似簡單,但在字元編碼、換行符號、逗號與引號的處理等方面,其實是個陷阱不少的格式。實作匯入處理時的技術注意事項,整理在「CSV 檔案處理實務指南」中。

另外,CSV 匯入並非最終型態,而是中間型態。這裡決定的欄位定義與代碼體系,之後在網路收單或 EDI 上也會直接成為基礎。

5. 先整備商品・客戶主檔

在 FAX 收單中,主檔的不完備是由承辦人來吸收的。

例如即使訂購單上寫的是舊商品名稱,承辦人也會判斷「這指的是現行的這項商品」而輸入。即使單位寫的是「箱」,承辦人也會記得一箱裝幾個而自行換算。

一旦轉移到 CSV 匯入或網路收單,這種轉譯就要交由機器來處理。而且在網路收單畫面上,商品主檔會直接呈現在客戶眼前。

因此,轉移前至少需要進行以下整備:

• 商品代碼的整理(停產品項的整理、重複代碼的整合、新舊代碼對照表)
• 商品名稱的表記統一(是否成為可以呈現給客戶看的名稱)
• 單位與入數(單件・箱・棧板之間的關係、最低訂購數量)
• 客戶代碼與送貨地點代碼(一個客戶有多個送貨地點時的處理方式)
• 各客戶適用的單價或合約條件要在哪裡管理

這裡重要的是不要試圖把所有主檔都做到完美才開始。如果一直等待,轉移就永遠不會開始。

現實的做法是先只整備最初要轉移的客戶(試點)所涉及的商品與送貨地點範圍,之後每增加一個轉移客戶,就擴大整備範圍。把主檔整備工作本身納入分階段轉移的各個階段中。

6. 雙軌並行期的設計

FAX 與網路(CSV)的雙軌並行,在轉移期間必然會發生。若不加以設計而放任不管,雙軌並行就會常態化,變成「管道增加多少,工作就增加多少」的狀態。

雙軌並行期的設計,具體來說就是要決定以下事項。

6.1 訂定期間與目標值

以數值決定「到什麼時候為止,要把幾成的訂單件數改為自動匯入」。例如「六個月內把 FAX 收單比率從 70% 降到 30%」這樣的形式。

沒有期限的雙軌並行,就會這樣一直固定下來。即使沒能達成目標,只要有期限,就能促使你去逐一確認每個客戶「為什麼轉移沒有進展」。

6.2 每月測量各管道的件數

轉移的進度不要靠感覺,而要用件數來追蹤。

• 各管道的收單件數(FAX、郵件附件、CSV、網路)
• 人工輸入的訂單件數與所需時間
• 匯入錯誤的件數與原因
• 輸入更正・重複登錄的件數

這與上一篇文章提到的導入後應測量的指標是同樣的思路。依管道分開測量,就能看出「該向哪個客戶推動,效果最大」。

6.3 讓各管道間的作業規則保持一致

雙軌並行期間容易產生混亂的情況,往往是因為不同管道的業務規則不一致。

• FAX 與網路的收單截止時間是否相同
• 訂單變更・取消要在哪個管道受理(若網路收到的訂單,變更卻透過 FAX 受理,就需要進行核對)
• 缺貨時的聯絡方式是否因管道而異
• 訂單編號在跨管道時是否唯一(這是偵測重複登錄所必須的)

尤其「在網路下單,隨後又立刻用電話或 FAX 變更」這種模式一定會發生。要事先決定變更要在哪個管道受理,以及由誰來修改哪些資料。

6.4 把 FAX 的接收方式也納入改善對象

雙軌並行期間,FAX 依然會存在。既然前提是它會存在,FAX 那一側的處理也應該是改善對象。

• 用複合機接收 FAX 並轉成 PDF,不再管理紙本
• 把收到的 PDF 集中到收單資料夾,管理處理狀態(未處理・已輸入・保留)
• 把輸入後的 FAX 原稿(PDF)與收單資料以訂單編號連結,方便日後核對

如果認為「FAX 遲早會消失,所以不去處理」,雙軌並行期間的負擔就不會減輕。在轉移完成之前,應把 FAX 處理也視為匯入同一份收單資料的其中一個管道來對待。

7. 如何讓客戶配合

分階段轉移能否成功,取決於對客戶的接洽方式,而不只是公司內部的作業。

7.1 為客戶分類

不要一視同仁地對待所有客戶,先進行分類。

決定效果的是 A 與 B。若勉強要求 C 分類的客戶轉移,只會徒增成本,因此可以明確告訴他們「我們也會持續接受 FAX」。

7.2 選定一家試點客戶

不要一開始就同時並行轉移多家客戶,先以一家客戶建立起運作方式。選擇標準與上一篇文章相同。

• 交易件數多,效果容易衡量
• 定型化的訂單較多
• 承辦人之間聯絡順暢,且對系統整合有一定理解

在試點階段建立 CSV 格式、錯誤時的聯絡方式、主檔對照表、說明文件等「範本」,之後第二家起就可以重複使用這套範本。

7.3 以對方的好處來說明

從客戶的角度來看,訂購方式的改變是出於己方公司的需求。因此說明時應以對方的好處來闡述,而非本公司的效率化。

• 收單確認能立即回覆,不再需要打電話確認「有沒有收到」
• 因誤讀而造成的錯誤出貨・數量錯誤會減少
• 可以自行查詢訂單歷史,重複訂購更方便(網路收單的情況)
• 不再需要 FAX 傳送作業以及傳送失敗後的重送

配合實務上的體貼措施也會有效果。

• 把操作步驟整理成一頁的說明手冊(以幾張畫面的說明就能講清楚為目標)
• 明確告知開始日期與併用期間(「◯月起也開放網路收單,FAX 目前仍可併用」)
• 最初幾次,不論用 FAX 或網路送來都予以接受,並即時回應詢問

另外,不建議一開始就發出「FAX 將於◯月廢止」這類公告。等到轉移有進展、剩下的客戶只剩少數時,再談期限,才不會傷害彼此的關係。

關於中小企業的收發訂單數位化,中小企業廳介紹了包含共通 EDI 在內的標準化措施及其效果。若業界團體或主要客戶已因應這類標準,也可以考慮採用標準格式,而非自訂格式。

8. 分階段轉移的模型案例

把到目前為止的內容整理成時間序列的模型。以下期間僅為一例,會依客戶數與公司內部體制而異。

第 0 階段的「現況整理」,可以直接沿用上一篇文章介紹的收發訂單方式的整理清單。

另外,若在猶豫是否要把收單管理本身遷移到網路系統,還是要維持桌面應用程式,可以參考「Windows 應用程式該不該搬到網路上」中整理的判斷架構。收單管道的網路化,與公司內部系統的網路化,可以分開來判斷。

9. 常見的絆腳石與對策

最後整理實際轉移中容易發生的絆腳石。

總結

FAX 收單的網路化,與其說是打造系統的工作,不如說是設計轉移期間的工作。

• 目標放在「減少需要人工輸入的訂單件數」,而非「廢除 FAX」
• 收單管道可以有多個,但公司內部的收單資料與處理要整合成一條
• 不要一開始就要求網頁畫面輸入,中間穿插 CSV 匯入這種形態
• 主檔整備從最初要轉移的客戶範圍開始,逐步進行
• 雙軌並行期要設定期限與目標值,並以各管道件數衡量進度
• 依件數與配合度為客戶分類,先以一家試點建立範本後再擴大

如同上一篇文章所整理的,EDI 或網路收單的效果,取決於收到的資料能流通到公司內部業務的哪個環節。轉移的設計,就是規劃如何以不勉強的順序,逐步提高匯入這條流程的訂單比例。

給正在考慮讓收發訂單網路化的您

若正在考慮重新檢視 FAX 收單,但對於客戶協調、與既有銷售管理系統的連接、CSV 格式與主檔整備該如何進行等問題,不知該從何下手,建議先從整理現有各管道的收單件數開始著手。

合同會社小村軟體可協助您進行活用既有 Windows 業務應用程式與資料庫的 CSV 匯入・網路收單整合的設計與實作,以及整理轉移計畫本身。

我們也可以在不以全面翻新為前提的情況下,協助您在維持現有銷售管理機制的同時,分階段新增收單管道。

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。