수정 이력(4건, 최종 수정 2026년 09월 03일)
이 글에 적용한 변경 사항의 기록입니다. 보관해 둔 수정 전 버전은 DOI가 부여된 고정 URL에서 읽을 수 있습니다.
- permalink·저자 표기·지식 맵 래퍼·깨진 내부 링크 등 CI가 지적한 표시용 수정을 반영했습니다. 본문의 기술적인 주장은 바꾸지 않았습니다.
- 기사 앞부분에 「이 기사의 지식 맵」 절을 추가했습니다. 본문에서 다루는 개념과 그 관계를 요약·그림·상세 페이지 링크로 정리한 것입니다. 본문의 주장은 바꾸지 않았습니다.
- 외부 리뷰(1283건)에 대응해 본문을 업데이트했습니다. 개별 변경 내용은 아래 이력을 참조해 주십시오.
- EDI, CSV, API, 프로토콜 같은 용어 표와, 「EDI」라고 불리는 것의 전체 그림 도식을 추가했습니다.
- 최초 공개
이 글을 인용하기(DOI(등록된 아카이브): 10.5281/zenodo.21635418)
아래 DOI는 이전에 등록된 아카이브를 가리키며 현재 본문과 다를 수 있습니다. 현재 본문을 참조할 때는 이 페이지의 URL을 사용하세요.
Go Komura (2026). 「EDI란? 기업 간 수발주를 어떻게 편하게 만드는가 ── FAX·메일·수기 입력에서 데이터 연계로」. 합동회사 코무라소프트. https://comcomponent.com/ko/blog/what-is-edi-business-efficiency/
- DOI(등록된 아카이브)
- 10.5281/zenodo.21635418
- DOI(마지막 등록 버전)
- 10.5281/zenodo.21635419
「거래처에서 FAX로 발주서가 도착하면 담당자가 판매관리 시스템에 입력한다」「메일에 첨부된 Excel을 열고 상품 코드와 수량을 확인한 뒤 전사한다」「납품 후 청구서를 작성하고, 상대 쪽에서도 그 내용을 회계 시스템에 입력한다」── 기업 간 거래에서는 같은 주문 정보나 청구 정보를 여러 회사·여러 담당자가 반복해서 입력하는 경우가 있습니다.
이 중복 입력을 줄이고, 발주, 수주, 출하, 청구 등의 데이터를 기업 간에 직접 주고받는 구조가 EDI입니다. EDI라고 하면 대기업이 전용 회선을 써서 도입하는 대규모 시스템을 떠올릴 수도 있지만, 본질은 더 단순합니다. 거래처에서 도착한 정보를 사람이 다시 읽고 입력하는 것이 아니라, 컴퓨터가 그대로 처리할 수 있는 데이터로 교환하는 것입니다. 그것뿐입니다.
이 기사에서는 EDI가 무엇인지, FAX나 메일과 무엇이 다른지, 도입하면 기업 업무가 어떻게 편해지는지를 수발주 업무를 예로 정리합니다. 전문 용어는 최소한으로 줄이지만, 다음 네 가지만 먼저 알아 두십시오.
| 용어 | 의미 |
|---|---|
| EDI | Electronic Data Interchange. 한국어로는 「전자 데이터 교환」 |
| CSV | Comma-Separated Values. 값을 쉼표로 구분하고, 한 줄에 한 건씩 나열한 텍스트 파일 형식입니다. 스프레드시트 소프트웨어에서도 업무 시스템에서도 읽고 쓰기 쉽기 때문에, 시스템 간 데이터 전달에 널리 쓰입니다 |
| API | Application Programming Interface. 어떤 시스템의 기능이나 데이터를, 다른 시스템의 프로그램에서 직접 호출하기 위한 창구입니다. 사람이 화면을 조작하지 않아도 데이터를 주고받을 수 있습니다 |
| 프로토콜 | 통신의 절차·약속입니다. 어떻게 연결하고, 어떻게 데이터를 보내며, 어떻게 완료를 확인할지를 정해 둔 것입니다 |
1.먼저 결론
EDI는 기업끼리 발주서, 출하 통지, 청구서 등의 거래 정보를, 미리 정한 형식의 전자 데이터로 교환하는 구조입니다.
일반재단법인 일본정보경제사회추진협회(JIPDEC)는 전자상거래나 정보 보안, 개인정보 보호 등의 분야에서 표준화와 보급 계몽을 수행하는 단체로, 기업 코드나 EDI에 관한 정보를 지속적으로 공개하고 있습니다. 이 기사에서도 EDI의 정의와 효과에 대해 이 협회의 해설을 참조합니다. JIPDEC의 해설에서는 EDI를 「기업이나 행정기관 등이 컴퓨터를 네트워크로 연결하고, 전표나 문서를 전자 데이터로 자동으로 교환하는 것」이라고 설명하며, 더불어 JIS X 7011에 따른 정의도 소개하고 있습니다.
EDI를 도입하는 목적은 단순히 종이를 없애는 것이 아닙니다. 주된 목적은 다음과 같은 작업을 줄이는 것입니다.
- FAX나 PDF를 보면서 하는 수기 입력
- Excel에서 판매관리 시스템으로의 전사
- 입력 내용의 육안 확인
- 발주서나 청구서를 찾는 작업
- 주문 상황을 확인하는 전화나 메일
- 매출, 재고, 청구 데이터의 재집계
한 마디로 말하면, EDI는 회사와 회사 사이에서 멈춰 있던 데이터를 그대로 흐르게 하는 구조입니다.
그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 17건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle
2.EDI가 없는 수발주 업무에서는 무엇이 일어나는가
먼저, EDI를 쓰지 않는 수발주 업무를 생각해 보겠습니다. 발주 측 회사에서는 구매 담당자가 자사 시스템이나 Excel로 주문 내용을 만들고, 그것을 발주서로 인쇄해 FAX나 메일로 거래처에 보냅니다. 수주 측에서는 도착한 발주서를 담당자가 확인하고, 자사 판매관리 시스템에 입력합니다. 그 후 수주 확인서, 출하 통지, 납품서, 청구서 등을 작성해 발주 측으로 돌려보내고, 발주 측에서도 그 정보를 재고관리 시스템이나 회계 시스템에 입력합니다.
flowchart TD
A["발주 측에서 주문 데이터를 입력"] --> B["발주서를 인쇄하거나 PDF화"]
B --> C["FAX 또는 메일로 송신"]
C --> D["수주 측 담당자가 내용을 확인"]
D --> E["수주 측 시스템에 재입력"]
E --> F["출하 데이터·청구 데이터를 작성"]
F --> G["발주 측이 다시 자사 시스템에 입력"]
그림 1: EDI가 없는 경우의 수발주 흐름. 데이터가 두 번, 사람의 손을 거쳐 다시 입력되고 있습니다
이 흐름에서는 상품 코드, 상품명, 수량, 단가, 납기, 납품처처럼 동일한 정보가 여러 번 입력됩니다. 처음 주문 데이터는 이미 발주 측 컴퓨터에 들어 있는데도, 종이나 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
그림 2: EDI를 쓴 경우의 수발주 흐름. 그림 1에 있던 「인쇄」「육안 확인」「재입력」 공정이 사라졌습니다
발주 측에서 수주 측으로 주문 데이터를 보내고, 수주 측에서 발주 측으로 수주 확인, 출하, 청구 등의 데이터를 돌려줍니다. 사람이 문서를 보면서 전사하는 공정을 끼우지 않고, 시스템에서 시스템으로 데이터를 넘기는 것이 핵심입니다.
JIPDEC의 해설에서는 각 기업이 가진 고유 형식의 데이터를 표준 형식으로 변환하고, 수신 측에서도 표준 형식에서 자사 형식으로 변환하는 구조를 EDI로 설명하고 있습니다.
4.EDI와 메일·PDF·Excel은 무엇이 다른가
「발주서를 PDF로 만들어 메일로 보내고 있으니 이미 전자화되어 있다」고 생각하는 경우가 있습니다. 확실히 종이를 우편으로 보내는 것보다 빠르고 보관도 쉬워집니다. 그러나 받은 쪽이 PDF를 보면서 시스템에 입력하고 있다면 입력 작업 자체는 남아 있습니다. 차이를 정리하면 다음과 같습니다.
| 방법 | 상대에게 송신 | 상대 측의 처리 | 재입력 |
|---|---|---|---|
| 종이·우편 | 종이를 보냄 | 서류를 보고 입력 | 필요 |
| FAX | 이미지로 보냄 | FAX를 보고 입력 | 필요 |
| PDF를 메일 송부 | 전자 문서로 보냄 | PDF를 보고 입력 | 필요 |
| Excel을 메일 송부 | 파일을 보냄 | 내용 확인, 가공, 가져오기 | 방법에 따라 다름 |
| EDI | 정해진 데이터 형식으로 보냄 | 시스템이 직접 가져옴 | 원칙적으로 불필요 |
JIPDEC의 설명에서는 전표를 스캔한 이미지나, 일반적인 글로 작성된 메일은 컴퓨터에서 재처리할 수 있는 EDI 데이터와 구별됩니다. 또한 Web 화면에 사람이 수기 입력하는 방식도, 엄밀히는 컴퓨터 간 자동 교환과는 다릅니다.
다만 PDF나 Excel을 쓰는 것 자체가 나쁜 것은 아닙니다. 중요한 것은 받은 정보가 그 후 어떻게 처리되는가입니다. 「PDF를 사람이 보고 입력한다」「Excel을 열고 복사한다」「CSV를 시스템에 직접 가져온다」「API로 자동으로 등록한다」── 같은 「전자 파일」이라도 후속 공정의 부담은 전혀 다릅니다. EDI의 효과를 판단할 때는 송신 방법만이 아니라, 수신 후에 사람이 무엇을 하는지를 볼 필요가 있습니다.
4.1.「EDI」라고 불리는 것들의 지도
여기까지 「EDI」로 한데 묶어 적어 왔지만, 실제로 검토를 시작하면 여러 가지 명칭이 나옵니다. 전체의 위치 관계를 먼저 알아 두면 제품 설명을 읽을 때 헤매지 않습니다.
| 명칭·구분 | 어떤 것인가 | 검토 시 짚을 점 |
|---|---|---|
| 거래처별 개별 대응 | 거래처마다 데이터 형식·항목·운영 규칙이 제각각인 상태로 데이터를 교환함 | JIPDEC는 거래처마다 데이터 변환 구조를 마련해야 해서 「비용이 너무 들어 현실적이지 않다」고 지적합니다. 상대가 늘어날수록 불리해집니다 |
| 표준에 기반한 EDI | 널리 합의된 표준 형식을 거쳐 주고받음 | 「표준⇔자사 형식」 변환을 하나 마련하면 어느 기업과도 주고받을 수 있다는 것이 JIPDEC의 정리입니다. 이것이 EDI의 본래 모습입니다 |
| Web-EDI(Web 화면 방식) | 거래처가 마련한 Web 화면에 브라우저로 로그인하여 발주·수주함 | 도입은 쉽지만 사람이 화면을 조작하는 점은 남습니다. 앞에서 말한 대로, 엄밀히는 컴퓨터 간 자동 교환과는 구별됩니다. CSV 일괄 다운로드·업로드에 대응하는지 여부가 갈림길입니다 |
| 중소기업 공통 EDI | 중소기업을 위해 수발주 업무를 표준화한 구조입니다. 중소기업청이 정비하고 있습니다(제10장) | 대형 거래처 사양에 개별 대응할 수 없는 규모의 회사에는 현실적인 출발점이 됩니다 |
| 디지털 인보이스(Peppol / JP PINT) | 청구 분야의 국제 규격 Peppol에 기반한 전자 인보이스입니다. 일본의 표준 사양이 JP PINT이며, 디지털청이 일본의 Peppol Authority로서 사양을 관리·공개하고 있습니다 | 수발주 EDI와는 다른 계통의 이야기이지만, 「청구만 먼저 표준화한다」는 진행 방식이 있을 수 있습니다 |
구분의 축은 두 가지뿐입니다. 하나는 주고받는 형식이 거래처별 개별 사양인지, 널리 합의된 표준인지입니다. 다른 하나는 마지막에 사람이 화면을 조작하는지, 시스템에서 시스템으로 넘어가는지입니다. 이 두 축으로 자사 현황과 후보를 놓아 보면, 어디를 고치면 효과가 나는지가 보입니다.
5.EDI로 교환할 수 있는 정보
EDI는 발주서만의 구조가 아닙니다. 기업 간 거래에서 발생하는 다양한 정보를 교환할 수 있습니다.
| 업무 단계 | 교환하는 데이터의 예 |
|---|---|
| 견적 | 견적 의뢰, 견적 회답 |
| 발주 | 주문, 주문 변경, 주문 취소 |
| 수주 | 수주 확인, 납기 회답 |
| 출하 | 출하 예정, 출하 실적, 송장 번호 |
| 입고·검수 | 입고 실적, 검수 결과 |
| 청구 | 청구 명세, 청구 정정 |
| 지급 | 지급 통지, 이체 명세 |
예를 들어 발주 데이터를 받은 시점에 수주 측 시스템이 다음 처리를 수행할 수도 있습니다.
- 주문 번호의 중복을 확인한다
- 상품 코드가 존재하는지 확인한다
- 재고를 할당한다
- 납기를 계산한다
- 창고로 출하 지시를 보낸다
- 발주 측으로 수주 확인을 돌려준다
나아가 출하 후에는 출하 실적에서 매출을 계상하고 청구 데이터를 만들 수 있습니다. 즉 EDI는 단순한 통신 기능이 아니라, 수발주를 입구로 그 이후의 재고, 출하, 매출, 청구까지 잇기 위한 토대가 됩니다.
6.EDI는 기업 업무를 어떻게 편하게 만드는가
제2장부터 제4장까지에서 본 대로, EDI의 직접적인 효과는 「발주서를 보면서 하는 수기 입력이 없어지는 것」입니다. 이 장에서는 그 다음에 무엇이 일어나는지를 여섯 가지로 나눠 정리합니다. 효과는 입력 공수 절감만이 아닙니다.
6.1.담당자의 시간을 예외 대응에 돌릴 수 있다
수기 입력이 없어지면 담당자의 시간 쓰임이 바뀝니다. 모든 주문을 사람이 처리하는 것이 아니라, 통상 주문은 자동 처리하고 판단이 필요한 것만 사람이 확인하는 형태로 만들 수 있기 때문입니다. 사람이 봐야 하는 것은 예를 들어 다음과 같은 주문입니다.
- 재고가 부족한 주문
- 평소와 다른 납기의 주문
- 상품 코드가 등록되지 않은 주문
- 대량 주문
- 단가나 계약 조건 확인이 필요한 주문
입력에 쫓기는 상태에서는 이런 확인이 뒤로 밀리기 쉽습니다. EDI의 가치는 「작업이 줄어드는 것」보다 「줄어든 시간을, 본래 주의를 기울여야 할 주문에 쓸 수 있는 것」에 있습니다.
6.2.입력 실수를 줄일 수 있다
사람이 입력하는 작업에는 일정 확률로 실수가 발생합니다. 상품 코드를 한 자리 잘못 입력하기, 수량을 10개가 아니라 100개로 입력하기, 납품처를 혼동하기, 희망 납기를 잘못 읽기, 같은 주문을 이중으로 등록하기 같은 종류입니다.
EDI에서도 원데이터가 잘못되어 있으면 문제는 일어납니다. 그러나 올바르게 만든 데이터를 상대 쪽에서 다시 입력할 필요가 없으므로, 전사 단계에서 발생하는 실수는 줄일 수 있습니다. 중소기업청도 수발주 디지털화의 효과로 작업 효율 향상, 인적 실수 경감, 거래 기록 검색성 향상을 들고 있습니다.
6.3.수주 처리를 빠르게 할 수 있다
FAX나 메일에서는 담당자가 수신을 알아차리고, 내용을 확인하고, 입력을 마칠 때까지 수주 처리가 시작되지 않습니다. 주문이 많은 날에는 입력 대기가 생기고, 담당자가 쉬고 있으면 처리가 늦어집니다.
EDI에서는 수신한 데이터를 시스템에 자동으로 가져올 수 있으므로, 주문을 받은 직후에 주문 접수, 재고 확인, 납기 계산, 창고로의 출하 지시, 수주 확인 회신 같은 처리를 시작할 수 있습니다. 수주 처리가 빨라지면 출하까지의 시간도 줄이기 쉬워집니다. JIPDEC도 EDI의 효과로 사무 작업의 효율화·신속화, 적시(just-in-time) 납품, 리드 타임 단축, 재고 압축 등을 들고 있습니다.
6.4.주문 상황을 확인하기 쉬워진다
종이, FAX, 메일, Excel이 섞여 있으면 「그 주문이 지금 어떤 상태인지」를 조사하는 데 시간이 걸립니다. 담당자의 메일함, 공유 폴더, 종이 파일, 판매관리 시스템 등을 차례로 확인하게 되기 때문입니다.
EDI에서는 주문 번호 등을 기준으로 다음 정보를 관련지어 관리할 수 있습니다.
- 언제 주문을 받았는지
- 정상적으로 가져왔는지
- 수주 확인을 돌려줬는지
- 출하했는지
- 검수되었는지
- 청구했는지
- 오류나 재송신이 발생했는지
문의가 들어왔을 때도 담당자의 기억이나 개인 메일에 의존하지 않고, 처리 이력에서 확인할 수 있습니다.
6.5.재고·출하·회계 업무로 이을 수 있다
받은 데이터를 사내 시스템과 연계하면 수주 등록 이후의 후속 공정도 자동화할 수 있습니다.
flowchart TD
A["주문 데이터를 수신"] --> B["수주 등록"]
B --> C["재고 할당"]
C --> D["출하 지시"]
D --> E["매출 계상"]
E --> F["청구 데이터 작성"]
F --> G["입금 반제"]
그림 3: 수신한 주문 데이터가 사내에서 거치는 후속 공정. 어디까지 잇느냐가 도입 효과를 결정합니다
반대로 EDI로 주문 데이터를 받아도 그것을 인쇄해 사람이 판매관리 시스템에 입력하고 있다면 효과는 한정됩니다. JIPDEC도 EDI로 받은 데이터를 사내 시스템에 가져오지 않고 인쇄해 수작업으로 처리하면 FAX와 크게 다르지 않다고 설명합니다. EDI는 거래처와의 통신만 도입하는 것이 아니라, 받은 데이터를 사내 업무의 어디까지 흘릴지가 중요합니다.
6.6.거래 데이터를 경영 판단에 쓸 수 있다
종이나 PDF로 받은 발주서는 보관되어 있어도 집계에는 쓰기 어렵습니다. EDI에서는 거래 정보가 구조화된 데이터로 축적되므로 다음과 같은 분석으로 이을 수 있습니다.
- 상품별 수주량
- 거래처별 매출 추이
- 요일별·시간대별 주문 경향
- 납기 지연 발생 상황
- 결품이 많은 상품
- 주문부터 출하까지 소요 시간
- 반품이나 정정이 많은 거래
JIPDEC도 EDI 데이터를 재고 할당, 생산 지시, 입출하 검품, 매출채권 계상 같은 일상 업무에 더해, 잘 팔리는 상품 분석, 스펜드 애널리시스, 수요 예측과 같은 경영 판단 재료로 활용할 수 있다고 합니다. EDI로 데이터를 모을 수 있는 상태를 만드는 것은 업무 효율화뿐 아니라 장래의 재고 최적화나 수요 예측의 전제가 되기도 합니다.
7.단순한 예로 보는 EDI의 효과
예를 들어 어떤 도매 회사가 하루에 100건의 주문을 FAX나 메일로 받고 있으며, 한 건의 주문을 판매관리 시스템에 입력하고 내용을 확인하는 데 평균 3분이 걸린다고 합시다.
100건 × 3분 = 300분 → 하루 5시간
EDI 도입 후 80건을 자동으로 가져오고, 나머지 20건만 사람이 확인하는 형태가 되었다고 하면 이렇게 됩니다.
20건 × 3분 = 60분 → 하루 1시간
단순화한 예이지만, 입력 작업은 5시간에서 1시간이 됩니다. 실제로는 여기에 더해 읽기 어려운 FAX 확인, 입력 실수 정정, 주문 내용을 확인하는 전화, 발주서를 찾는 작업, 주문 목록 집계, 담당자 간 인수인계 같은 시간도 줄어들 가능성이 있습니다. EDI 도입의 효과는 「종이 비용이 줄어든다」와 같은 직접 비용만이 아니라, 매일 반복되는 작은 확인·입력·정정을 줄일 수 있다는 데 큰 의미가 있습니다.
7.1.자사 숫자로 시산한다
위의 100건·3분은 어디까지나 예입니다. 자사 숫자를 넣어 계산해 보십시오. 필요한 것은 네 가지 숫자뿐입니다.
(1) 하루 수주 건수 …… A 건
(2) 1건당 입력·확인 시간 …… B 분
(3) EDI로 자동 처리할 수 있을 것으로 보는 비율 …… C %
(4) 1년 영업일 수 …… D 일
현재 걸리는 시간 = A × B (분/일)
EDI 도입 후 남는 시간 = A × (1 - C ÷ 100) × B (분/일)
하루 절감 시간 = A × (C ÷ 100) × B (분/일)
1년 절감 시간 = 하루 절감 시간 × D ÷ 60 (시간/년)
(3)의 「자동 처리할 수 있는 비율」은 다음 장 이후에서 다루는 예외의 많음으로 정해집니다. 처음부터 높은 값을 두지 말고, 우선 거래 건수가 많은 상위 몇 개 사가 전체의 몇 %를 차지하는지를 세는 것부터 시작하십시오. 거래처별 건수는 제11.1장의 목록 표를 만들면 나옵니다.
다만 이 시산에서 나오는 것은 줄일 수 있는 시간이지, 그대로 줄일 수 있는 인건비가 아닙니다. 비운 시간을 무엇에 쓸지(예외 대응의 질을 높인다, 다른 업무로 돌린다, 잔업을 줄인다)까지 정해야 비로소 도입 효과로 설명할 수 있는 숫자가 됩니다.
8.부문별로 보는 EDI의 이점
EDI에 의한 업무 개선은 수주 부문에만 한정되지 않습니다.
| 부문 | EDI 도입 전의 작업 | EDI 도입 후 기대할 수 있는 변화 |
|---|---|---|
| 영업·수주 | 주문 내용을 보고 입력한다 | 통상 주문은 자동 등록하고, 예외만 확인한다 |
| 구매 | 발주서를 작성해 송부한다 | 구매 시스템에서 직접 송신한다 |
| 창고 | 종이 출하 지시를 받는다 | 수주 데이터에서 출하 지시를 만든다 |
| 경리 | 청구 명세를 다시 입력한다 | 매출 데이터에서 청구 정보를 만든다 |
| 관리자 | Excel로 실적을 집계한다 | 축적된 거래 데이터에서 집계한다 |
| 문의 창구 | 메일이나 종이를 찾는다 | 주문 번호로 처리 상황을 확인한다 |
정보의 소재가 분명해지고 담당자 이외에도 상황을 확인하기 쉬워지므로, EDI로 줄일 수 있는 것은 입력 공수만이 아니라 업무의 속인화도 있습니다.
9.EDI를 도입한다고 모두 자동화되는 것은 아니다
EDI는 편리한 구조이지만, 도입하는 것만으로 모든 작업이 자동화되는 것은 아닙니다.
9.1.거래처와의 합의가 필요하다
기업 간에 데이터를 교환하려면 적어도 다음 사항을 정해야 합니다. 어떤 정보를 교환할지, 어떤 데이터 형식을 쓸지, 언제 송수신할지, 주문 변경이나 취소를 어떻게 다룰지, 오류가 발생했을 때 어떻게 할지, 같은 데이터를 다시 보냈을 때 어떻게 다룰지, 그리고 어느 시점에 정식 주문으로 성립할지입니다.
이런 합의에는 계층이 있으며, JIPDEC는 다음 다섯 가지로 정리하고 있습니다. 「EDI를 넣는다」는 이야기가 구체적으로 어느 층의 이야기인지를 혼동하면 논의가 맞지 않습니다.
| 합의의 층 | 정하는 것 |
|---|---|
| 통신 프로토콜 | 어떻게 연결하고 어떻게 보낼지입니다. VAN에서 인터넷으로 바뀌어 온 층입니다 |
| 신택스 규칙 | 데이터를 어떻게 적을지(항목의 나열 방법이나 구분 방법)입니다. 고정 포맷에서 XML로 바뀌어 온 층입니다 |
| 메시지와 데이터 항목 | 어떤 이름의 항목을 어떤 의미로 둘지입니다. 업계 특성에 강하게 의존합니다 |
| 업무 운영 규약 | 언제 보낼지, 오류 시 어떻게 할지, 재송신을 어떻게 다룰지 같은 운영상의 약속입니다 |
| 거래 기본 규약 | 어느 시점에 주문이 성립할지 등, 거래 자체의 법적 약속입니다 |
제품이나 서비스 비교는 위의 두 층(통신 프로토콜과 신택스 규칙) 이야기에 치우치기 쉽지만, 도입에서 고생하는 것은 아래 세 층입니다. 특히 「메시지와 데이터 항목」은 다음 9.2에서 다루는 코드 정비 그 자체이며, 여기를 거래처와 맞추지 않은 채 제품만 정하면 나중에 재작업이 됩니다.
9.2.상품 코드 등을 맞출 필요가 있다
발주 측과 수주 측에서 같은 상품에 다른 코드를 쓰는 경우가 있습니다. 발주 측에서는 상품 코드가 A-001, 수주 측에서는 100245인 식의 사례입니다. 이 경우에는 코드를 변환하기 위한 대응표가 필요합니다. 상품 코드 외에도 다음 항목을 정리합니다.
- 거래처 코드
- 납품처 코드
- 단위
- 입수
- 세 구분
- 통화
- 날짜 형식
- 문자 코드
데이터를 송수신할 수 있어도 항목의 의미가 일치하지 않으면 올바른 거래가 되지 않습니다.
9.3.예외 처리는 남는다
통상 주문을 자동 처리할 수 있어도, 재고 부족, 단종 상품, 평소와 다른 가격, 긴급 주문, 주문 변경, 주문 취소, 분할 납품, 반품, 데이터 미비 같은 예외적인 거래는 남습니다.
중요한 것은 모두를 무리하게 자동화하는 것이 아닙니다. 통상 처리와 예외 처리를 나누고, 통상 처리는 자동화하며, 판단이 필요한 것만 사람에게 넘기는 설계가 현실적입니다. 제6.1장에서 든 「사람이 봐야 할 주문」이 바로 여기서 말하는 예외에 해당합니다.
9.4.FAX나 메일과의 병용 기간이 생긴다
모든 거래처가 동시에 EDI로 이행할 수 있는 것은 아닙니다. 그래서 도입 초기에는 EDI, Web 화면, CSV 업로드, 메일, FAX, 전화 같은 여러 접수 방법이 병행되는 경우가 있습니다.
이 상태에서는 EDI를 도입해도 기존 업무 담당자를 바로 줄이지는 못합니다. 효과를 높이려면 거래량이 많은 거래처부터 차례로 이행하고, 수작업으로 다루는 건수를 줄여 가야 합니다. JIPDEC도 FAX나 전화 같은 수작업이 남으면 그 대응 인원이 필요해져 효율화 효과를 충분히 얻기 어렵다고 지적합니다. 제7.1장의 시산에서 「자동 처리할 수 있는 비율」을 낮게 잡아야 하는 이유도 여기에 있습니다.
10.EDI가 맞는 기업
EDI는 특히 다음과 같은 기업에서 효과가 나기 쉬운 구조입니다.
- 매일 또는 매주 같은 거래처와 수발주하고 있다
- 주문 건수나 명세 수가 많다
- FAX나 메일에서 시스템으로 전사하고 있다
- 입력 실수나 이중 등록이 발생하고 있다
- 주문 확인 전화나 메일이 많다
- 수주 후 재고, 출하, 청구 처리가 이어진다
- 담당자가 쉬면 처리가 막힌다
- 주문 이력이나 거래 상황 집계에 시간이 걸린다
한편 1년에 몇 번밖에 거래가 없는 상대나, 주문 내용이 매번 크게 다른 거래에서는 EDI 구축·운영 비용이 효과를 웃도는 경우도 있습니다.
EDI를 도입할지 여부는 회사 규모만으로 판단하는 것이 아닙니다. 중소기업청도 중소기업을 위해 수발주 업무를 표준화하는 「중소기업 공통 EDI」를 정비하고 있으며, 전용 단말이나 종이를 줄이고 전표를 데이터로 일원 관리함으로써 업무를 효율화하는 방향을 제시하고 있습니다. 봐야 할 것은 직원 수가 아니라, 반복해서 발생하는 입력·확인·전사의 양입니다.
11.EDI 도입을 검토할 때의 진행 방법
EDI를 검토할 때 처음부터 제품이나 통신 방식을 고를 필요는 없습니다. 먼저 현재 업무를 정리합니다.
11.1.현재 수발주 방법을 목록으로 만든다
거래처마다 다음 정보를 정리합니다.
| 확인 항목 | 내용 |
|---|---|
| 거래처 | 어느 회사와 거래하고 있는지 |
| 주문 건수 | 하루·한 달에 몇 건인지 |
| 수주 방법 | FAX, 메일, Web, CSV 등 |
| 입력처 | 판매관리, Excel, 기간계 시스템 등 |
| 입력 시간 | 1건당 몇 분이 걸리는지 |
| 실수 | 어떤 정정이 발생하고 있는지 |
| 후속 공정 | 재고, 출하, 청구로 어떻게 잇고 있는지 |
| 예외 | 어떤 주문에서 사람의 판단이 필요한지 |
이렇게 정리하면 EDI화로 효과가 큰 거래처나 업무가 보입니다. 제7.1장 시산에 넣을 건수와 시간도 이 표에서 가져올 수 있습니다.
11.2.거래량이 많은 한 곳부터 시작한다
처음부터 모든 거래처를 대상으로 하면 조정 항목이 늘어나고 도입이 장기화됩니다. 우선 다음 조건에 해당하는 거래처를 한 곳 고르는 것이 현실적입니다.
- 거래 건수가 많다
- 정형적인 주문이 많다
- 담당자끼리 연락이 쉽다
- 시스템 연계에 대한 이해가 있다
- 효과를 측정하기 쉽다
한 곳에서 운영 방법을 확립한 뒤 다른 거래처로 넓힙니다.
11.3.교환 대상을 좁힌다
처음부터 견적, 수주, 출하, 검수, 청구, 지급 전부를 대상으로 할 필요는 없습니다. 예를 들어 입력 부담이 가장 큰 주문 데이터만 먼저 EDI화하고, 다음과 같이 단계적으로 넓혀 가는 방법이 있습니다.
- 제1단계: 주문 데이터
- 제2단계: 수주 확인·납기 회답
- 제3단계: 출하 통지
- 제4단계: 청구 데이터
단계적으로 대상을 늘리면 현장에 미치는 영향을 줄이면서 효과를 확인할 수 있습니다.
11.4.사내 시스템 연결을 확인한다
EDI 서비스를 도입해도 기존 판매관리 시스템에 데이터를 가져오지 못하면 수기 입력이 남습니다. 사전에 다음 점을 확인합니다.
- CSV 입출력 기능이 있는지
- API를 쓸 수 있는지
- 데이터베이스와의 연계가 가능한지
- 상품 코드 변환을 어디서 할지
- 수신 데이터 중복을 어떻게 막을지
- 오류를 누구에게 알릴지
- 처리 이력을 어디에 남길지
제품 선정에 앞서 기존 시스템과의 연결 방법을 확인하는 것이 중요합니다. 여기서 「CSV 입출력을 할 수 없다」「API가 없다」는 점이 드러나면, EDI 서비스 선정보다 기존 시스템 쪽 개수나 중계 구조를 마련하는 일이 먼저가 됩니다.
12.EDI 도입 후 측정하고 싶은 지표
EDI를 도입했다면 「쓸 수 있게 되었다」로 끝내지 말고, 업무가 얼마나 바뀌었는지를 확인합니다. 예를 들어 다음 지표를 도입 전후로 비교합니다. 제7.1장 시산에 쓴 숫자를 그대로 실측값으로 바꾸면, 가정과 실제의 차이도 그대로 보입니다.
- 수주 입력에 걸리는 시간
- 주문 한 건을 처리하기까지의 시간
- 입력 정정 건수
- 이중 등록 건수
- 주문 확인 문의 건수
- 출하 지연 건수
- EDI로 처리한 주문의 비율
- 사람이 확인한 예외 주문의 비율
EDI에서 중요한 것은 데이터를 송신할 수 있는 것이 아닙니다. 수작업이 실제로 줄고, 처리가 빨라지고, 실수가 줄었는지로 평가합니다.
정리
EDI란 기업 간에 발생하는 주문, 출하, 청구 등의 정보를, 컴퓨터가 그대로 처리할 수 있는 전자 데이터로 교환하는 구조입니다. FAX를 메일로 바꾸는 것만으로는 종이는 줄어도 수기 입력이 남는 경우가 있습니다. EDI의 진짜 효과는 거래처에서 받은 데이터를 판매관리, 재고, 출하, 회계 등의 사내 시스템에 직접 이을 수 있다는 점에 있습니다.
EDI로 기대할 수 있는 주된 변화는 다음과 같습니다.
- 발주서를 보면서 하는 수기 입력을 줄인다
- 전사로 인한 입력 실수를 줄인다
- 수주부터 출하까지 처리를 빠르게 한다
- 주문이나 청구의 처리 상황을 확인하기 쉽게 한다
- 재고, 출하, 매출, 청구를 연계한다
- 축적한 거래 데이터를 집계나 수요 예측에 쓴다
- 담당자 개인에 의존한 업무를 줄인다
다만 EDI 서비스를 계약하는 것만으로는 충분하지 않습니다. 상품 코드 등의 데이터를 정리하고, 거래처와 운영 규칙을 정하며, 기존 사내 시스템에 데이터를 가져올 수 있게 해야 합니다.
EDI 도입의 출발점은 「어느 제품을 쓸까」가 아니라, 현재 업무에서 같은 정보를 몇 번 입력하고 있는지를 조사하는 것입니다. FAX, 메일, Excel, Web 화면, 판매관리 시스템 사이에서 사람이 정보를 나르는 지점을 찾고, 그중 건수가 많고 정형적인 업무부터 차례로 데이터 연계로 바꿔 가는 것이 현실적입니다.
수발주 업무의 데이터 연계를 검토하시는 분께
기업 간 수발주를 효율화하고 싶지만 현재의 FAX·메일·Excel 운영을 어디서부터 손봐야 할지 모르겠다면, 먼저 업무 흐름을 정리해야 합니다.
거래처에서 어떤 형식으로 정보를 받고, 사내 어느 시스템에 입력하며, 그 이후의 재고·출하·청구로 어떻게 잇고 있는지를 확인하면 자동화할 수 있는 범위가 보입니다.
合同会社小村ソフト에서는 기존 Windows 업무 앱, CSV·고정 길이 파일, 데이터베이스, Web 시스템 등을 포함한 업무 연계에 대해 현황 정리나 구현 방법 검토를 상담받으실 수 있습니다.
전면 재구축을 전제로 하지 않고, 현재 구조를 남기면서 수기 입력 부분만 줄이는 구성도 검토할 수 있습니다.
참고 링크
- JIPDEC(일반재단법인 일본정보경제사회추진협회), EDI란. EDI의 정의(기업이나 행정기관 등이 컴퓨터를 네트워크로 연결하고, 전표나 문서를 전자 데이터로 자동으로 교환하는 것), JIS X 7011에 따른 정의, 각사 고유 형식과 표준 형식의 상호 변환이라는 구조, 스캔 이미지나 일반적인 글 메일이 EDI 데이터와 구별된다는 점에 대해.
- JIPDEC, EDI의 이점과 EDI 표준의 필요성. 사무 작업의 효율화·신속화, 적시(just-in-time) 납품, 리드 타임 단축, 재고 압축, 인위적 실수 배제, 잘 팔리는 상품 분석이나 스펜드 애널리시스·수요 예측으로의 활용, 표준을 따르지 않으면 거래처마다 변환 구조가 필요해 비용이 맞지 않는다는 점, 합의가 필요한 5가지 사항(통신 프로토콜, 신택스 규칙, 메시지와 데이터 항목, 업무 운영 규약, 거래 기본 규약), 수신 데이터를 인쇄해 수작업으로 처리하면 FAX와 크게 다르지 않다는 점에 대해.
- 중소기업청, 수발주의 디지털화(중소기업 공통 EDI). 수발주 디지털화에 따른 작업 효율 향상·인적 실수 경감·거래 기록 검색성 향상, 중소기업을 위해 수발주 업무를 표준화하는 「중소기업 공통 EDI」 정비에 대해.
- 디지털청, JP PINT(전자 인보이스의 표준 사양). 디지털청이 일본의 Peppol Authority로서 Peppol 네트워크에서 주고받는 일본 전자 인보이스 표준 사양 「JP PINT」를 관리·공개하고 있다는 점에 대해.
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.
FAX 수주를 Web으로 옮기려면 ── 이중 운용 기간의 설계와 단계 이행의 실무
FAX 수주를 Web 수주나 CSV 가져오기로 이행하는 실무를 설명합니다. 한꺼번에 전면 Web화하기가 실패하기 쉬운 이유, FAX와 Web의 이중 운용 기간 설계, 상품·거래처 마스터 정비, CSV 가져오기라는 중간 형태, 거래처를 끌어들이는 ...
디지털 인보이스란? ── '청구서 PDF를 메일로 보내는 것'과 무엇이 다른가
디지털 인보이스란, 청구 정보를 판매자의 시스템에서 구매자의 시스템으로 사람을 거치지 않고 직접 데이터 연계하는 구조입니다. PDF 청구서와의 차이, 인보이스 제도와의 관계, Peppol·JP PINT, 중소기업의 시작 방법을 해설합니다.
생력화 투자 보조금으로 FAX 수주를 웹으로 전환할 수 있는가 ── 일반형으로 접근하는 수발주 시스템 투자
FAX 수주의 웹 전환·자동 가져오기는 중소기업 생력화 투자 보조금(일반형)의 검토 대상이 될 수 있습니다. 카탈로그 주문형과 일반형의 차이, 수발주 시스템이 생력화 투자에 해당하는 이유, 임금 인상 요건 등 주의점을 정리합니다.
winget + PowerShell로 PC 키팅을 자동화한다 ── 절차서를 실행 가능하게 만들기
신입 사원 PC 설정을 재현 가능하게 만드는 방법을 정리합니다. winget으로 앱을 도입하고 export/import하는 방법, WinGet Configuration의 선언적 구성, PowerShell로 보완하는 설정, 무인 실행 시 주의점까지...
PowerShell에서 COM과 .NET을 호출하는 실무 ── 스크립트가 닿는 범위를 한 번에 넓히기
PowerShell에서 .NET 클래스를 호출하는 방법, Add-Type으로 C#과 Win32 API를 넣는 방법, COM 조작, Excel 프로세스 잔류와 뒷정리, Office 무인 실행이 지원되지 않는 이유, 5.1과 7의 차이까지 실무 관점...
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용에 관한 KomuraSoft LLC 기사를 모은 토픽 허브입니다.
이 주제와 연결되는 서비스
이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.
Windows 앱 개발
기존 Windows 업무 앱과 CSV·고정 길이 파일·데이터베이스·Web 시스템을 잇는 구성 검토나 구현은 업무 앱 개발 상담 범위이기 때문입니다.
Windows 소프트웨어 유지 보수 & 현대화
전면 재구축을 전제로 하지 않고, 기존 시스템을 남기면서 수기 입력이나 전사를 단계적으로 줄이는 개수는 기존 Windows 소프트웨어의 개수·유지보수에 해당하기 때문입니다.
기술 상담 & 설계 리뷰
거래처와의 데이터 형식·운영 규칙·예외 처리를 정리하고, 어디까지 자동화할지 정하는 작업은 설계 리뷰를 수반하는 기술 상담이기 때문입니다.