什么是 EDI?如何让企业间的订购业务更轻松 ── 从传真、邮件、手动录入迈向数据对接

· · EDI, 企业间交易, 订购业务, 业务效率化, 系统对接, BtoB, DX

「交易对象通过传真发来订单,负责人将其录入销售管理系统」

「打开邮件附带的 Excel,核对商品编码和数量后进行转录」

「交货后开具发票,对方也要将同样的内容录入财务系统」

在企业间交易中,同样的订单信息或账单信息,有时会被多家公司、多位负责人反复录入好几次。

而能够减少这种重复录入、让下单、接单、发货、开票等数据直接在企业之间往来的机制,就是 EDI。

一提到 EDI,或许会让人联想到大企业使用专线搭建的大型系统。但它的本质其实要简单得多。

EDI 是一种机制,让来自交易对象的信息不再需要由人重新阅读并录入,而是直接作为计算机可以处理的数据进行交换。

本文将以订购业务为例,梳理 EDI 是什么、它与传真、邮件有何不同,以及引入后企业业务会变得多轻松。

1. 先说结论

EDI 是 Electronic Data Interchange 的缩写,中文称为「电子数据交换」。

这是企业之间以事先约定好格式的电子数据,交换订单、发货通知、发票等交易信息的一种机制。

JIPDEC 将 EDI 解释为:企业或行政机构等通过网络连接计算机,自动以电子数据形式交换单据或文件的机制。

引入 EDI 的目的并非单纯地消除纸张。

其主要目的是减少以下这类工作:

  • 一边看传真或 PDF 一边进行的手动录入
  • 从 Excel 转录到销售管理系统
  • 目视核对录入内容
  • 查找订单或发票的工作
  • 用来确认订单状态的电话或邮件
  • 销售、库存、账单数据的重新汇总

一言以蔽之,EDI 是让原本停滞在公司与公司之间的数据能够直接流动起来的机制。

2. 没有 EDI 的订购业务中,正在发生什么

首先来看看没有使用 EDI 的订购业务。

在下单方公司,采购负责人用自家系统或 Excel 制作订单内容,将其打印成订单,通过传真或邮件发给交易对象。

在接单方,负责人核对收到的订单,并将其录入自家的销售管理系统。

之后,会制作接单确认书、发货通知、送货单、发票等,再寄回给下单方。下单方也会将这些信息录入库存管理系统或财务系统。

下单方录入订单数据
        ↓
打印订单・转为 PDF
        ↓
通过传真或邮件发送
        ↓
接单方核对内容
        ↓
在接单方系统中重新录入
        ↓
制作发货、开票数据
        ↓
下单方再次录入自家系统

在这一流程中,同样的信息会被反复录入多次。

例如商品编码、商品名称、数量、单价、交期、送货地点等。

最初的订单数据其实已经存在于下单方的计算机中了。尽管如此,由于被转换成纸质文件或 PDF,接单方还是需要由人重新阅读,再重新录入到计算机里。

问题并不在于信息没有电子化。

而在于原本已经生成为数据的信息,被转换成供人阅读的文档,然后在对方那一端又被重新转换回数据。

3. 使用 EDI 之后,订购业务会如何变化

使用 EDI 之后,下单方系统中生成的订单数据,会被转换为接单方系统可以读取的格式,直接发送出去。

在接单方,负责人不再需要一边看订单一边录入,而是直接将接收到的数据导入销售管理系统。

flowchart LR
    A[下单方的采购系统] --> B[订单数据]
    B --> C[通过 EDI 发送・转换]
    C --> D[接单方的销售管理系统]
    D --> E[接单确认]
    D --> F[发货通知]
    D --> G[开票数据]
    E --> C
    F --> C
    G --> C
    C --> A

下单方向接单方发送订单数据,接单方再向下单方回传接单确认、发货、开票等数据。

关键在于,不需要经过人一边看文件一边转录的环节,数据直接从系统传递到系统。

JIPDEC 将 EDI 解释为一种机制:把各企业专有格式的数据转换为标准格式,接收方同样也会将标准格式转换为自家的格式。

4. EDI 与邮件、PDF、Excel 有什么不同

有时会有人认为「订单已经做成 PDF 用邮件发送了,已经算电子化了」。

确实,这比邮寄纸质文件更快,也更便于保存。但如果接收方仍然是一边看 PDF 一边录入系统,那么录入工作本身其实并没有消失。

整理一下差异,如下表所示:

方式 发送给对方 对方端的处理 重新录入
纸质・邮寄 寄送纸质文件 看文件录入 需要
传真 以图像形式发送 看传真录入 需要
PDF 通过邮件发送 以电子文档形式发送 看 PDF 录入 需要
Excel 通过邮件发送 发送文件 核对内容、加工、导入 视方式而定
EDI 以约定好的数据格式发送 系统直接导入 原则上不需要

JIPDEC 的说明 中,将单据扫描而成的图像,或以普通文字撰写的邮件,与计算机可以再处理的 EDI 数据区分开来。此外,在网页界面上由人手动录入的方式,严格来说也不同于计算机之间的自动交换。

不过,使用 PDF 或 Excel 本身并不是坏事。

重要的是收到的信息之后是如何被处理的。

  • 由人看着 PDF 录入
  • 打开 Excel 后复制粘贴
  • CSV 直接导入系统
  • 通过 API 自动登记

即便同样是「电子文件」,后续工作的负担也大不相同。

在判断 EDI 效果时,不能只看发送方式,还要看接收之后人做了什么。

5. EDI 可以交换的信息

EDI 并不只是用于订单的机制。

它可以交换企业间交易中产生的各种信息。

业务阶段 交换数据示例
报价 报价请求、报价回复
下单 订单、订单变更、订单取消
接单 接单确认、交期回复
发货 发货计划、发货实绩、运单号
收货・验收 收货实绩、验收结果
开票 账单明细、账单更正
付款 付款通知、汇款明细

例如,在收到下单数据的那一刻,接单方系统就可以进行如下处理:

  1. 核对订单编号是否重复
  2. 核对商品编码是否存在
  3. 进行库存分配
  4. 计算交期
  5. 向仓库发出发货指示
  6. 向下单方回传接单确认

此外,发货之后还可以根据发货实绩确认销售额,并生成开票数据。

也就是说,EDI 并不只是一个单纯的通信功能。

它以订购业务为入口,成为串联起后续库存、发货、销售、开票的基础。

6. EDI 如何让企业业务更轻松

6.1. 可以减少手动录入与转录

最容易理解的效果就是手动录入的减少。

一边看传真送达的订单,一边录入商品编码、数量、单价、交期的工作将变得不再需要。

减少手动录入后,负责人就可以把时间用在录入以外的异常处理上,例如:

  • 库存不足的订单
  • 交期异常的订单
  • 商品编码尚未登记的订单
  • 大额订单
  • 需要核对单价或合同条款的订单

不再由人处理所有订单,而是改为常规订单自动处理、只有有问题的订单才由人核对的形式。

6.2. 可以减少录入错误

由人进行的录入工作,总会有一定概率出错。

  • 商品编码输错一位
  • 数量输成 100 个而不是 10 个
  • 送货地点搞混
  • 误读期望交期
  • 同一订单被重复登记两次

即使使用 EDI,如果原始数据本身有误,问题依然会出现。但由于正确生成的数据不需要在对方端重新录入,因此可以减少因转录而产生的错误。

中小企业厅 也将订购业务数字化的效果列为提升作业效率、减少人为失误、提升交易记录的可检索性。

6.3. 可以加快接单处理速度

在传真或邮件的情况下,接单处理要等到负责人注意到收件、核对内容、完成录入之后才能开始。

订单较多的日子会出现录入排队积压。若负责人休假,处理也可能因此延迟。

在 EDI 中,接收到的数据可以自动导入系统。

在收到订单后,可以立即开始:

  • 订单受理
  • 库存核对
  • 交期计算
  • 向仓库发出发货指示
  • 回复接单确认

等一系列处理。

接单处理加快,发货所需时间也更容易缩短。JIPDEC 也将 EDI 的效果列为事务作业提速、交付周期缩短、库存压缩等。

6.4. 更容易确认订单状态

当纸质文件、传真、邮件、Excel 混杂在一起时,要查清「那笔订单现在状态如何」需要花费不少时间。

需要依次查看负责人的邮箱、共享文件夹、纸质文件、销售管理系统等。

在 EDI 中,可以以订单编号等为基准,将以下信息关联起来管理:

  • 何时收到订单
  • 是否已正常导入
  • 是否已回复接单确认
  • 是否已发货
  • 是否已验收
  • 是否已开票
  • 是否发生过错误或重发

即使收到咨询,也不需要依赖负责人的记忆或个人邮件,而是可以从处理历史中查证。

6.5. 可以对接库存、发货、财务业务

EDI 的效果并不仅限于减少接单负责人的录入工作。

通过将接收到的数据与内部系统对接,后续流程也可以实现自动化。

订单数据
    ↓
接单登记
    ↓
库存分配
    ↓
发货指示
    ↓
销售登记
    ↓
生成开票数据
    ↓
收款核销

反过来说,即使通过 EDI 收到了订单数据,如果仍然是打印出来由人录入销售管理系统,效果就会相当有限。

JIPDEC 也说明,若通过 EDI 收到的数据没有导入企业内部系统,而是打印出来人工处理,那与传真并没有太大差别。

引入 EDI 不仅仅是与交易对象之间的通信对接,接收到的数据要流转到企业内部业务的哪个环节,这一点同样重要。

6.6. 交易数据可以用于经营决策

以纸质文件或 PDF 收到的订单,即使被保存下来,也难以用于汇总分析。

在 EDI 中,交易信息会以结构化数据的形式积累下来。

因此可以进一步连接到以下这类分析:

  • 各商品的接单量
  • 各交易对象的销售趋势
  • 按星期、时段划分的下单倾向
  • 交期延误的发生情况
  • 缺货较多的商品
  • 从下单到发货所需的时间
  • 退货或更正较多的交易

JIPDEC 也表示,除了库存分配、生产调度、进出货验收、应收账款登记等日常业务外,EDI 数据还可以用于畅销商品分析、需求预测等。

通过 EDI 建立起可以汇集数据的状态,不仅有助于业务效率化,也是未来实现库存优化与需求预测的前提。

7. 用简单的例子看 EDI 的效果

假设某家批发公司,一天通过传真或邮件收到 100 份订单。

假设将一份订单录入销售管理系统并核对内容,平均需要 3 分钟。

100 份 × 3 分钟 = 300 分钟

也就是说,每天要花费 5 小时用于订单录入与核对。

假设引入 EDI 之后,其中 80 份可以自动导入,剩下 20 份才需要人工核对。

20 份 × 3 分钟 = 60 分钟

虽是简化后的例子,但录入工作从 5 小时变为了 1 小时。

实际上,除此之外,以下这些时间也可能随之减少:

  • 辨认难以看清的传真
  • 更正录入错误
  • 用来核对订单内容的电话
  • 查找订单的工作
  • 汇总订单清单
  • 负责人之间的交接

引入 EDI 的效果,并不仅仅是「节省纸张费用」这类直接成本。

其真正的意义在于,能够减少每天反复发生的细小核对、录入、更正工作。

8. 按部门来看 EDI 的优点

EDI 带来的业务改善,并不仅限于接单部门。

部门 引入 EDI 前的工作 引入 EDI 后可期待的变化
销售・接单 看订单内容录入 常规订单自动登记,只核对异常情况
采购 制作采购单并寄送 从采购系统直接发送
仓库 接收纸质发货指示 从接单数据生成发货指示
财务 重新录入账单明细 从销售数据生成开票信息
管理层 用 Excel 汇总业绩 从积累的交易数据中汇总
咨询窗口 查找邮件或纸质文件 按订单编号确认处理状态

EDI 能够减少的,不仅仅是单纯的录入工时。

由于信息的所在位置变得清晰,即便不是负责人本人也能方便地确认情况,因此还能减轻业务对特定个人的依赖。

9. 引入 EDI 并不意味着所有工作都能自动化

EDI 是很方便的机制,但仅仅引入并不能让所有工作都自动化。

9.1. 需要与交易对象达成协议

企业之间要交换数据,至少需要确定以下事项:

  • 交换哪些信息
  • 使用哪种数据格式
  • 何时收发
  • 订单变更或取消如何处理
  • 发生错误时如何应对
  • 同一数据重复发送时如何处理
  • 在哪个时间点正式确立订单

在 EDI 中,不仅是通信方式,数据项与业务运营规则同样重要。JIPDEC 也整理出需要就通信协议、数据格式、消息项、错误应对、交易基本协议等达成一致。

9.2. 需要统一商品编码等项目

下单方与接单方,有时会对同一商品使用不同的编码。

例如下单方的商品编码是 A-001,接单方则是 100245 这样的情况。

在这种情况下,需要一份用来转换编码的对照表。

除商品编码外,还需要梳理以下项目:

  • 交易对象编码
  • 送货地点编码
  • 单位
  • 每包数量
  • 税务分类
  • 币种
  • 日期格式
  • 字符编码

即便能够收发数据,只要项目的含义不一致,就无法构成正确的交易。

9.3. 异常处理依然存在

即使常规订单能够自动处理,异常性的交易依然会存在。

  • 库存不足
  • 已停产商品
  • 与平常不同的价格
  • 紧急订单
  • 订单变更
  • 订单取消
  • 分批交货
  • 退货
  • 数据缺陷

重要的是,并不需要勉强将一切都自动化。

将常规处理与异常处理区分开来,常规处理自动化,只把需要判断的部分交给人处理,这样的设计才更现实。

9.4. 会出现与传真、邮件并行的过渡期

并非所有交易对象都能同时切换到 EDI。

因此,在引入初期,有时会出现以下多种接单方式并行的情况:

  • EDI
  • Web 界面
  • CSV 上传
  • 邮件
  • 传真
  • 电话

在这种状态下,即使引入了 EDI,也无法立即减少负责传统业务的人力。

要提升 EDI 的效果,需要从交易量较大的交易对象开始依次迁移,逐步减少人工处理的件数。JIPDEC 也指出,如果仍保留传真或电话等人工处理,就需要相应人员来对应,因此难以充分获得效率化的效果。

10. 适合引入 EDI 的企业

EDI 尤其容易在以下这类企业中见效:

  • 每天或每周都与同一交易对象进行订购
  • 订单数量或明细数量较多
  • 目前是从传真或邮件转录到系统
  • 发生过录入错误或重复登记
  • 用于确认订单的电话或邮件较多
  • 接单之后还会接续库存、发货、开票处理
  • 负责人休假时处理就会停滞
  • 汇总订单历史或交易状况需要花费较多时间

另一方面,对于一年只交易几次的对象,或订单内容每次都大相径庭的交易,EDI 的建设与运营成本有时可能超过其收益。

是否引入 EDI,不应该只以公司规模来判断。

中小企业厅 也为中小企业建立了用来标准化订购业务的「中小企业通用 EDI」,展示了通过减少专用终端与纸张、将单据以数据形式集中管理,来实现业务效率化的方式。

应该关注的不是员工人数,而是反复发生的录入、核对、转录的工作量。

11. 考虑引入 EDI 时的推进方式

在考虑 EDI 时,并不需要从一开始就选定产品或通信方式。

首先,应先梳理现有业务。

11.1. 将当前的订购方式列成清单

按交易对象,梳理以下信息:

确认项 内容
交易对象 与哪家公司交易
订单数量 每天・每月有多少笔
接单方式 传真、邮件、Web、CSV 等
录入去向 销售管理、Excel、核心系统等
录入时间 每笔需要多少分钟
错误情况 发生过哪些更正
后续流程 如何对接库存、发货、开票
异常情况 哪些订单需要人工判断

完成这一梳理后,就能看出哪些交易对象或业务采用 EDI 化的效果最大。

11.2. 从交易量最大的一家开始

如果一开始就以所有交易对象为目标,需要协调的事项会增多,导入周期也会拉长。

比较现实的做法是,先选择一家符合以下条件的交易对象:

  • 交易量较大
  • 常规订单较多
  • 双方负责人之间沟通顺畅
  • 对系统对接有一定理解
  • 效果容易衡量

在一家公司确立运营方式之后,再推广到其他交易对象。

11.3. 缩小交换对象范围

一开始并不需要将报价、接单、发货、验收、开票、付款全部纳入范围。

例如,可以先将录入负担最大的订单数据进行 EDI 化。

第一阶段:订单数据
第二阶段:接单确认・交期回复
第三阶段:发货通知
第四阶段:开票数据

通过分阶段扩大对象范围,可以在控制对一线影响的同时确认效果。

11.4. 确认与企业内部系统的对接

即使引入了 EDI 服务,如果无法将数据导入现有的销售管理系统,手动录入的工作仍然会保留下来。

事前应确认以下几点:

  • 是否具备 CSV 导入导出功能
  • 是否可以使用 API
  • 是否能与数据库对接
  • 商品编码转换在何处进行
  • 如何防止接收数据重复
  • 出错时通知谁
  • 处理历史保留在何处

在选定产品之前,先确认与现有系统的对接方式是非常重要的一步。

12. 引入 EDI 之后应衡量的指标

引入 EDI 之后,不应止步于「已经可以使用了」,而要确认业务究竟发生了多大变化。

例如,可以对比以下指标在引入前后的变化:

  • 接单录入所需的时间
  • 处理一笔订单所需的时间
  • 录入更正的件数
  • 重复登记的件数
  • 订单确认的咨询件数
  • 发货延误的件数
  • 能通过 EDI 处理的订单比例
  • 由人核对的异常订单比例

EDI 中重要的并不是能否发送数据。

而是要以手动作业是否真正减少、处理是否变快、错误是否减少来评价。

总结

EDI 是一种机制,让企业之间发生的订单、发货、开票等信息,以计算机可以直接处理的电子数据形式进行交换。

仅仅把传真改成邮件,纸张虽然减少了,但手动录入有时依然存在。

EDI 真正的效果,在于能够将从交易对象收到的数据,直接对接到销售管理、库存、发货、财务等企业内部系统。

通过 EDI 可以期待的主要变化如下:

  • 减少一边看订单一边进行的手动录入
  • 减少因转录而产生的录入错误
  • 加快从接单到发货的处理速度
  • 让订单或账单的处理状态更容易确认
  • 将库存、发货、销售、开票串联起来
  • 将积累的交易数据用于汇总或需求预测
  • 减少依赖特定负责人的业务

不过,仅仅签约引入 EDI 服务是不够的。

还需要梳理商品编码等数据,与交易对象约定运营规则,并让数据能够导入现有的企业内部系统。

引入 EDI 的出发点,并不是「使用哪款产品」,而是调查在当前业务中,同样的信息究竟被录入了多少次。

找出在传真、邮件、Excel、Web 界面、销售管理系统之间由人搬运信息的环节,并从中挑选件数多、属于常规化的业务,依次替换为数据对接,这才是切实可行的做法。

致正在考虑订购业务数据对接的您

若想提升企业间订购业务的效率,却不知道该从哪里开始重新审视当前的传真、邮件、Excel 使用方式,首先需要梳理业务的流程。

只要确认交易对象以何种格式提供信息、录入到企业内部的哪个系统、之后又如何对接到库存、发货、开票,就能看清可以自动化的范围。

合同会社小村软件(合同会社小村ソフト)可以为您梳理现状,并就包含现有 Windows 业务应用、CSV・定长文件、数据库、Web 系统等在内的业务对接,提供实现方式的咨询。

我们也能够在不以全面重建为前提的情况下,探讨保留现有架构、仅减少手动录入部分的方案。

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

作者简介

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

Go Komura

小村软件有限公司 代表

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

返回博客列表