把传真订单迁移到 Web ── 双轨运行期的设计与分阶段迁移实务

在上一篇文章「什么是 EDI？如何让企业间订货变得更轻松」中，我们梳理了将通过传真或邮件收到的订单由人工重新录入的作业，替换为系统间数据交换的机制。

本文是它的续篇。主题从「理解机制」再前进一步，聚焦于该如何迁移。

「想把传真订单 Web 化」这类咨询，多半会这样接着说：

「不过有些客户只能用传真」

「销售管理系统想维持现状继续使用」

「切换期间订单中断会很麻烦」

也就是说，实务上的课题并不是打造一套 Web 订单系统，而是在传真仍然存在的情况下，如何设计逐步向 Web 迁移的这段期间。

本文将传真订单的 Web 化，围绕双轨运行期的设计、CSV 导入这一中间形态、商品与客户主数据的整备、如何让客户配合这四点来梳理。

1. 先说结论

规划传真订单 Web 化时，要点如下：

• 目标不是「废除传真」，而是「减少需要人工录入的订单件数」
• 前提是传真与 Web 的双轨运行期一定会发生，先设计好期限与衡量方式
• 接单方式（渠道）可以有多种，但公司内部的订单处理要归并为一条
• 不要一开始就要求用 Web 页面录入，先准备CSV 导入这一中间形态
• 由于 Web 订单页面会把商品、客户主数据直接呈现出来，要先整备主数据
• 客户不要一次性全部切换，按件数与配合度分类，依次迁移

JIPDEC 也指出，若仍保留传真、电话等人工处理，就需要配备相应人力，难以充分获得效率化的效果。正因如此，不应把双轨运行期当作「不得不发生的事」放任不管，而要把「缩短它」这件事本身作为设计对象。

2. 一次性全面 Web 化容易失败的原因

传真订单的 Web 化有一个特点，光靠公司内部系统的考量是无法决定的，因为发出订单的是客户。

如果统一向所有客户宣布「下个月起请改用 Web 下单」，很容易导致以下失败：

• 只能用传真下单的客户，不再是「例外」，而变成「计划的障碍」
• 每个客户情况不同，却被要求遵守相同的截止日期
• 未迁移客户的订单仍不断通过传真送来，双轨运行变得遥遥无期
• 被评价为「Web 化了，但人力并没有减少」，项目因此停滞

原因在于把目标定为「消除传真」。

如果把目标换成「减少需要人工录入的订单件数」，计划就会变得务实。例如，只要占订单七成的主要客户迁移到 Web 或 CSV，即便剩下三成仍用传真，录入工作量也会大幅减少。

不要一次性推动全部，而是从效果最大的部分依次推动，这就是分阶段迁移的基本思路。

3. 迁移后的样貌 ── 入口多元，内部处理归一

在设计分阶段迁移之前，先描绘出目标的样貌。

关键在于把接单渠道与订单处理分开来考虑。

[接单渠道]                     [统一的订单数据]          [内部处理]

传真 ──── 员工录入 ──┐
邮件附件 ── 员工录入 ─┤
CSV 导入 ─── 自动导入 ────┼──→ 订单数据 ──→ 库存分配・发货・开票
Web 订单页面 ── 自动登记 ───┘      (格式统一)

无论接单渠道有多少种，只要后端的订单数据格式与处理归并为一条，库存、发货、开票等后续环节就能保持共通的运作方式。

反之，如果每个渠道都各自建立不同的处理流程或不同的台账，渠道每增加一种，业务就会变得更复杂，双轨运行的负担也会持续加重。

即便是通过传真收到的订单，只要员工录入之后，也应让它变成与其他渠道相同的订单数据。所谓迁移，可以说就是不断减少流入这张图中「员工录入」这一行的件数，同时增加流入「自动导入」「自动登记」这两行件数的工作。

不一定非要对现有销售管理系统进行重做。只要能确认是否可以为订单数据新增一个入口（CSV 导入功能、数据库对接、API 等），就能在保留现有机制的情况下推进。这个确认要点，正如上一篇 EDI 文章中「确认与内部系统的连接」所整理的那样。

4. CSV 导入这一中间形态

要求客户从传真直接跳到 Web 页面录入，有时对客户来说负担会很大。

从下单方的角度来看，Web 页面录入意味着「把自己公司订购系统或 Excel 做好的订单，再重新录入一遍到对方的页面上」。如果客户已经用自己的系统生成订单数据，那么直接以文件形式接收并导入，对双方来说工作量都更少。

因此作为中间形态，准备 CSV（或 Excel）导入。

第一阶段：以邮件附件方式接收 CSV，由员工通过导入功能读取
第二阶段：客户从 Web 页面上传 CSV，系统自动导入
第三阶段：已定型化的客户改用 Web 订单页面或 EDI

即便是第一阶段，相比对照订购单手动录入，录入时间与转录错误都会大幅减少。客户端的变化仅仅是「把原本用传真发送的内容改成邮件附件」这种程度，因此也更容易获得配合，这是它的优点。

设计 CSV 导入时，至少要确定以下项目。

CSV 看似简单，但在字符编码、换行符、逗号与引号的处理等方面，其实是个坑不少的格式。实现导入处理时的技术注意事项，整理在「CSV 文件处理实务指南」中。

另外，CSV 导入并非最终形态，而是一种中间形态。这里确定的字段定义与编码体系，之后在 Web 订单或 EDI 中也会直接成为基础。

5. 先整备商品・客户主数据

在传真订单中，主数据的不完备是由员工来吸收的。

例如即便订购单上写的是旧商品名，员工也会判断「这指的是现行的这个商品」而录入。即便单位写的是「箱」，员工也会记住一箱装多少个而自行换算。

一旦迁移到 CSV 导入或 Web 订单，这种转译就要交给程序来完成。而且在 Web 订单页面上，商品主数据会直接呈现在客户面前。

因此，迁移前至少需要进行以下整备：

• 商品编码整理（停产品项的清理、重复编码的合并、新旧编码对照表）
• 商品名称表述统一（是否是可以呈现给客户看的名称）
• 单位与装箱数（散件・箱・托盘之间的关系、最低订购数量）
• 客户编码与送货地点编码（一个客户存在多个送货地点时的处理方式）
• 各客户适用单价或合同条件在哪里管理

这里重要的是不要试图把所有主数据都做到完美之后才开始。若一直等待，迁移就永远无法启动。

现实的做法是先只整备最初要迁移的客户（试点）所涉及的商品与送货地点范围，之后每增加一个迁移客户，就扩大整备范围。把主数据整备工作本身纳入分阶段迁移的各个阶段之中。

6. 双轨运行期的设计

传真与 Web（CSV）的双轨运行，在迁移期间必然会发生。若不加以设计而任其发展，双轨运行就会常态化，变成「渠道增加多少，工作就增加多少」的状态。

双轨运行期的设计，具体来说就是要确定以下事项。

6.1 确定期限与目标值

用数值确定「到什么时候为止，要把几成的订单件数改为自动导入」。例如「六个月内把传真订单比例从 70% 降到 30%」这样的形式。

没有期限的双轨运行，会就此固定下来。即便没能达成目标，只要有期限，也会促使你逐一确认每个客户「为什么迁移没有进展」。

6.2 每月度量各渠道的件数

迁移的进度不要凭感觉，而要用件数来跟踪。

• 各渠道的订单件数（传真、邮件附件、CSV、Web）
• 人工录入的订单件数与所需时间
• 导入错误的件数与原因
• 录入更正・重复登记的件数

这与上一篇文章提到的上线后应度量的指标是同样的思路。按渠道分开度量，就能看出「向哪个客户发力，效果最大」。

6.3 让运营规则在各渠道之间保持一致

双轨运行期间容易产生混乱的情况，往往出在不同渠道的业务规则不一致上。

• 传真与 Web 的截单时间是否相同
• 订单变更・取消要在哪个渠道受理（若 Web 收到的订单，变更却通过传真受理，就需要进行核对）
• 缺货时的通知方式是否因渠道而异
• 订单号在跨渠道时是否唯一（这是检测重复登记所必需的）

尤其「在 Web 下单，随后又立刻用电话或传真变更」这种模式一定会发生。要事先确定变更由哪个渠道受理，以及由谁来修改哪些数据。

6.4 把传真的接收方式也纳入改善对象

双轨运行期间，传真依然会存在。既然前提是它会存在，传真那一侧的处理也应该是改善对象。

• 用一体机接收传真并转成 PDF，不再管理纸质文件
• 把收到的 PDF 集中到订单文件夹，管理处理状态（未处理・已录入・待处理）
• 把录入后的传真原件（PDF）与订单数据用订单号关联，方便日后核对

如果认为「传真迟早会消失，所以不去处理」，双轨运行期间的负担就不会减轻。在迁移完成之前，应把传真处理也视为汇入同一份订单数据的一个渠道来对待。

7. 如何让客户配合

分阶段迁移能否成功，取决于对客户的沟通方式，而不仅仅是公司内部的工作。

7.1 为客户分类

不要一视同仁地对待所有客户，先进行分类。

决定效果的是 A 和 B。若勉强要求 C 类客户迁移，只会徒增成本，因此可以明确告知他们「我们也会持续接受传真」。

7.2 选定一家试点客户

不要一开始就同时并行迁移多家客户，先以一家客户建立起运作方式。选择标准与上一篇文章相同。

• 交易件数多，效果容易衡量
• 定型化订单较多
• 员工之间沟通顺畅，且对系统集成有一定理解

在试点阶段建立 CSV 格式、出错时的通知方式、主数据对照表、说明文档等「模板」，之后从第二家客户开始就可以复用这套模板。

7.3 以对方的收益来做说明

从客户的角度来看，订购方式的改变是出于本公司需求的一项要求。因此说明时应以对方的收益来阐述，而非本公司的效率化。

• 收单确认能立即返回，不再需要打电话确认「有没有收到」
• 因误读而导致的错误发货・数量差错会减少
• 可以自行查询订单历史，重复订购更方便（Web 订单的情况下）
• 不再需要传真发送作业以及发送失败后的重发

配合实务上的贴心考虑，效果会更好。

• 把操作步骤整理成一页的操作手册（以几张页面的说明就能讲清楚为目标）
• 明确告知开始日期与并行使用期间（「从◯月起也开放 Web 订单，传真目前仍可并行使用」）
• 最初几次，不管客户用传真还是 Web 送来都予以接受，并及时回应咨询

另外，不建议一开始就发布「传真将于◯月废止」这类通知。等到迁移有了进展、剩下的客户只剩少数时，再提起截止期限，才不至于伤及彼此的关系。

关于中小企业订货数字化，中小企业厅介绍了包括共通 EDI 在内的标准化举措及其成效。若所在行业协会或主要客户已经在对接这类标准，也可以考虑采用标准格式，而非自定义格式。

8. 分阶段迁移的模型案例

把到目前为止的内容整理成时间序列的模型。以下期限仅为一例，会因客户数量与公司内部体制而有所不同。

第 0 阶段的「现状梳理」，可以直接沿用上一篇文章介绍的订货方式清单化方法。

另外，如果在犹豫是否要把订单管理本身迁移到 Web 系统，还是维持桌面应用程序，可以参考「Windows 应用是否该迁移到 Web」中梳理的判断框架。接单渠道的 Web 化，与公司内部系统的 Web 化，是可以分开判断的。

9. 常见的绊脚石与对策

最后整理实际迁移中容易发生的绊脚石。

小结

传真订单的 Web 化，与其说是打造系统的工作，不如说是设计迁移期间的工作。

• 目标定在「减少需要人工录入的订单件数」，而非「废除传真」
• 接单渠道可以有多个，但公司内部的订单数据与处理要归并为一条
• 不要一开始就要求 Web 页面录入，中间加入 CSV 导入这一形态
• 主数据整备从最初要迁移的客户范围开始，分阶段推进
• 双轨运行期要设定期限与目标值，并以各渠道件数衡量进度
• 客户按件数与配合度分类，先以一家试点建立模板后再扩大

如同上一篇文章所梳理的，EDI 或 Web 订单的效果，取决于收到的数据能流转到公司内部业务的哪个环节。迁移设计，就是规划如何以不勉强的顺序，逐步提高汇入这条流程的订单比例。

致正在考虑订货 Web 化的您

如果正在考虑重新审视传真订单，但对客户协调、与现有销售管理系统的对接、CSV 格式与主数据整备该如何推进等问题，不知从何下手，建议先从梳理当前各渠道的订单件数开始着手。

小村软件有限公司可协助您完成基于既有 Windows 业务应用程序与数据库的 CSV 导入・Web 订单集成的设计与实现，以及迁移计划本身的梳理。

我们也可以在不以全面翻新为前提的情况下，帮助您在保留现有销售管理机制的同时，分阶段增加接单渠道。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。