EDI란 무엇인가? 기업 간 수발주를 어떻게 편하게 만드는가 ── 팩스·메일·수작업 입력에서 데이터 연계로
· Go Komura · 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는 주문서만을 위한 구조가 아닙니다.
기업 간 거래에서 발생하는 다양한 정보를 교환할 수 있습니다.
| 업무 단계 | 교환하는 데이터의 예 |
|---|---|
| 견적 | 견적 의뢰, 견적 회답 |
| 발주 | 주문, 주문 변경, 주문 취소 |
| 수주 | 수주 확인, 납기 회답 |
| 출하 | 출하 예정, 출하 실적, 송장 번호 |
| 입하·검수 | 입하 실적, 검수 결과 |
| 청구 | 청구 명세, 청구 정정 |
| 지불 | 지불 통지, 송금 명세 |
예를 들어 발주 데이터를 받은 시점에서, 수주 측 시스템이 다음과 같은 처리를 할 수도 있습니다.
- 주문 번호의 중복을 확인한다
- 상품 코드가 존재하는지 확인한다
- 재고를 인당(引当)한다
- 납기를 계산한다
- 창고에 출하 지시를 보낸다
- 발주 측에 수주 확인을 돌려준다
또한 출하 후에는 출하 실적으로부터 매출을 계상하고, 청구 데이터를 작성할 수 있습니다.
즉 EDI는 단순한 통신 기능이 아닙니다.
수발주를 입구로 하여, 그 이후의 재고, 출하, 매출, 청구까지를 연결하기 위한 토대가 됩니다.
6. EDI는 기업 업무를 어떻게 편하게 만드는가
6.1. 수작업 입력과 전기를 줄일 수 있다
가장 알기 쉬운 효과는 수작업 입력의 감소입니다.
팩스로 도착한 주문서를 보면서 상품 코드, 수량, 단가, 납기를 입력하는 작업이 불필요해집니다.
수작업 입력을 줄이면, 담당자는 입력 그 자체가 아니라 다음과 같은 예외 대응에 시간을 사용할 수 있습니다.
- 재고가 부족한 주문
- 통상과는 다른 납기의 주문
- 상품 코드가 등록되어 있지 않은 주문
- 대량 주문
- 단가나 계약 조건의 확인이 필요한 주문
모든 주문을 사람이 처리하는 것이 아니라, 통상 주문은 자동 처리하고 문제가 있는 주문만 사람이 확인하는 형태로 바꿀 수 있습니다.
6.2. 입력 실수를 줄일 수 있다
사람이 입력하는 작업에는 일정 확률로 실수가 발생합니다.
- 상품 코드를 한 자리 잘못 입력한다
- 수량을 10개가 아니라 100개로 입력한다
- 납품처를 착각한다
- 희망 납기를 잘못 읽는다
- 동일한 주문을 이중으로 등록한다
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건의 주문을 팩스나 메일로 받고 있다고 합시다.
1건의 주문을 판매관리 시스템에 입력하고 내용을 확인하는 데 평균 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
- 웹 화면
- CSV 업로드
- 메일
- 팩스
- 전화
이 상태에서는 EDI를 도입해도 기존 업무의 담당자를 바로 줄일 수는 없습니다.
EDI의 효과를 높이려면 거래량이 많은 거래처부터 순서대로 이행하여, 수작업으로 처리하는 건수를 줄여 나갈 필요가 있습니다. JIPDEC도 팩스나 전화 등의 수작업 처리가 남아 있으면 그 대응 인력이 필요해져, 효율화의 효과를 충분히 얻기 어렵다고 지적하고 있습니다.
10. EDI가 적합한 기업
EDI는 특히 다음과 같은 기업에서 효과가 나기 쉬운 구조입니다.
- 매일 또는 매주 같은 거래처와 수발주를 하고 있다
- 주문 건수나 명세 수가 많다
- 팩스나 메일에서 시스템으로 전기하고 있다
- 입력 실수나 이중 등록이 발생하고 있다
- 주문 확인 전화나 메일이 많다
- 수주 후에 재고, 출하, 청구 처리가 이어진다
- 담당자가 쉬면 처리가 정체된다
- 주문 이력이나 거래 상황의 집계에 시간이 걸린다
한편, 연간 몇 번밖에 거래가 없는 상대나, 주문 내용이 매번 크게 다른 거래에서는 EDI의 구축·운용 비용이 효과를 웃도는 경우도 있습니다.
EDI를 도입할지 여부는 회사의 규모만으로 판단하는 것이 아닙니다.
중소기업청도 중소기업을 위해 수발주 업무를 표준화하는 「중소기업 공통 EDI」를 정비하고 있으며, 전용 단말이나 종이를 줄이고, 전표를 데이터로 일원 관리함으로써 업무 효율화가 가능함을 보여주고 있습니다.
봐야 할 것은 종업원 수가 아니라 반복적으로 발생하는 입력·확인·전기의 양입니다.
11. EDI 도입을 검토할 때의 진행 방법
EDI를 검토할 때, 처음부터 제품이나 통신 방식을 선택할 필요는 없습니다.
먼저 현재의 업무를 정리합니다.
11.1. 현재의 수발주 방법을 목록화한다
거래처별로 다음 정보를 정리합니다.
| 확인 항목 | 내용 |
|---|---|
| 거래처 | 어느 회사와 거래하고 있는가 |
| 주문 건수 | 하루·한 달에 몇 건 있는가 |
| 수주 방법 | 팩스, 메일, 웹, CSV 등 |
| 입력처 | 판매관리, Excel, 기간계 시스템 등 |
| 입력 시간 | 1건당 몇 분 걸리는가 |
| 실수 | 어떤 정정이 발생하고 있는가 |
| 후속 공정 | 재고, 출하, 청구로 어떻게 연결하고 있는가 |
| 예외 | 어떤 주문에서 사람의 판단이 필요한가 |
이 정리를 하면 EDI화로 인한 효과가 큰 거래처나 업무가 보이게 됩니다.
11.2. 거래량이 많은 한 곳부터 시작한다
처음부터 모든 거래처를 대상으로 하면 조정 항목이 늘어나, 도입이 장기화됩니다.
먼저 다음 조건에 해당하는 거래처를 한 곳 선택하는 것이 현실적입니다.
- 거래 건수가 많다
- 정형적인 주문이 많다
- 담당자 간의 연락이 원활하다
- 시스템 연계에 대한 이해가 있다
- 효과를 측정하기 쉽다
한 곳에서 운용 방법을 확립한 후, 다른 거래처로 확대합니다.
11.3. 교환 대상을 좁힌다
처음부터 견적, 수주, 출하, 검수, 청구, 지불의 모든 것을 대상으로 할 필요는 없습니다.
예를 들어 가장 입력 부담이 큰 주문 데이터만 먼저 EDI화하는 방법이 있습니다.
1단계: 주문 데이터
2단계: 수주 확인·납기 회답
3단계: 출하 통지
4단계: 청구 데이터
단계적으로 대상을 늘려 나가면 현장에 대한 영향을 억제하면서 효과를 확인할 수 있습니다.
11.4. 사내 시스템과의 연결을 확인한다
EDI 서비스를 도입해도 기존의 판매관리 시스템에 데이터를 가져올 수 없다면 수작업 입력이 남습니다.
사전에 다음 사항을 확인합니다.
- CSV 입출력 기능이 있는가
- API를 이용할 수 있는가
- 데이터베이스와의 연계가 가능한가
- 상품 코드 변환을 어디에서 할 것인가
- 수신 데이터의 중복을 어떻게 방지할 것인가
- 오류를 누구에게 통지할 것인가
- 처리 이력을 어디에 남길 것인가
제품 선정보다 먼저 기존 시스템과의 연결 방법을 확인하는 것이 중요합니다.
12. EDI 도입 후에 측정해야 할 지표
EDI를 도입했다면 「사용할 수 있게 되었다」로 끝내지 말고, 업무가 얼마나 바뀌었는지를 확인합니다.
예를 들어 다음 지표를 도입 전후로 비교합니다.
- 수주 입력에 걸리는 시간
- 1건의 주문을 처리하기까지의 시간
- 입력 정정 건수
- 이중 등록 건수
- 주문 확인 문의 건수
- 출하 지연 건수
- EDI로 처리할 수 있었던 주문의 비율
- 사람이 확인한 예외 주문의 비율
EDI에서 중요한 것은 데이터를 송신할 수 있다는 것이 아닙니다.
수작업이 실제로 줄어들고, 처리가 빨라지고, 실수가 줄었는지로 평가합니다.
정리
EDI란 기업 간에 발생하는 주문, 출하, 청구 등의 정보를, 컴퓨터가 그대로 처리할 수 있는 전자 데이터로서 교환하는 구조입니다.
팩스를 메일로 바꾸는 것만으로는 종이는 줄어도 수작업 입력이 남는 경우가 있습니다.
EDI의 진정한 효과는 거래처로부터 받은 데이터를 판매관리, 재고, 출하, 회계 등의 사내 시스템으로 직접 연결할 수 있다는 데 있습니다.
EDI를 통해 기대할 수 있는 주된 변화는 다음과 같습니다.
- 주문서를 보면서 하는 수작업 입력을 줄인다
- 전기로 인한 입력 실수를 줄인다
- 수주부터 출하까지의 처리를 빠르게 한다
- 주문이나 청구의 처리 상황을 확인하기 쉽게 한다
- 재고, 출하, 매출, 청구를 연계한다
- 축적한 거래 데이터를 집계나 수요 예측에 사용한다
- 담당자 개인에게 의존한 업무를 줄인다
다만 EDI 서비스를 계약하는 것만으로는 충분하지 않습니다.
상품 코드 등의 데이터를 정리하고, 거래처와 운용 규칙을 정하고, 기존의 사내 시스템에 데이터를 가져올 수 있도록 할 필요가 있습니다.
EDI 도입의 출발점은 「어느 제품을 사용할 것인가」가 아니라, 현재의 업무에서 동일한 정보를 몇 번 입력하고 있는지를 조사하는 것입니다.
팩스, 메일, Excel, 웹 화면, 판매관리 시스템 사이에서 사람이 정보를 나르고 있는 부분을 찾아, 그중에서 건수가 많고 정형적인 업무부터 순서대로 데이터 연계로 대체해 나가는 것이 현실적입니다.
수발주 업무의 데이터 연계를 검토 중이신 분께
기업 간의 수발주를 효율화하고 싶지만, 현재의 팩스·메일·Excel 운용을 어디서부터 재검토해야 할지 모르는 경우에는 먼저 업무의 흐름을 정리할 필요가 있습니다.
거래처로부터 어떤 형식으로 정보를 받고, 사내의 어느 시스템에 입력하며, 그 후의 재고·출하·청구로 어떻게 연결하고 있는지를 확인하면 자동화할 수 있는 범위가 보이게 됩니다.
합동회사 코무라소프트(合同会社小村ソフト)에서는 기존 Windows 업무 애플리케이션, CSV·고정 길이 파일, 데이터베이스, 웹 시스템 등을 포함한 업무 연계에 대해 현황 정리나 실현 방법의 검토를 상담받고 있습니다.
전면 개편을 전제로 하지 않고, 현재의 구조를 유지하면서 수작업 입력 부분만을 줄이는 구성도 검토할 수 있습니다.
관련 기사
같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.
FAX 수주를 웹으로 옮기려면 ── 이중 운영 기간 설계와 단계적 이행 실무
FAX 수주를 웹 수주나 CSV 가져오기로 이행하는 실무를 설명합니다. 갑작스러운 전면 웹화가 실패하기 쉬운 이유, FAX와 웹의 이중 운영 기간 설계, 상품·거래처 마스터 정비, CSV 가져오기라는 중간 형태, 거래처를 끌어들이는 방법을 단계적...
디지털 인보이스란? ── '청구서 PDF를 메일로 보내는 것'과 무엇이 다른가
디지털 인보이스란 청구 정보를 판매자 시스템에서 구매자 시스템으로 사람을 거치지 않고 직접 데이터로 연계하는 구조입니다. PDF 청구서와의 차이, 인보이스 제도와의 관계, Peppol·JP PINT의 구조, 전자장부보존법과의 관계, 중소기업의 시...
PowerShell 실용 명령어 모음 ── 일상 업무에서 자주 쓰는 작은 기능 늘리기
PowerShell로 일상 업무에 쓰는 실용 명령어로서, Measure-Object, Group-Object, Select-String, Compare-Object, Tee-Object, Start-Transcript 등의 활용 시점을 정리합니다.
Windows 앱의 작업 트레이 상주와 토스트 알림 ── NotifyIcon의 함정과 AppNotification 선택 기준
업무용 Windows 앱을 작업 트레이(알림 영역)에 상주시키고 토스트 알림으로 사용자에게 알리는 구현을 정리합니다. NotifyIcon의 올바른 사용법과 「닫으면 트레이로」설계, 탐색기 재시작 시 재등록, 토스트 API 3종(Windows Ap...
WordPress에서 Movable Type으로의 이전 ── '반대 방향'이기에 더욱 정리해 두어야 할 실무 절차
WordPress에서 Movable Type(MovableType.net)으로의 이전 절차를 실무 관점에서 해설합니다. 이전이 합리적인 경우, 게시물·고정 페이지·이미지 임포트, 커스텀 게시물 타입 처리, URL 설계와 301 리다이렉트를 통한 ...
관련 토픽
이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.
Windows 기술 토픽
Windows 개발, 장애 조사, 기존 자산 활용에 관한 KomuraSoft LLC 기사를 모은 토픽 허브입니다.
이 주제와 연결되는 서비스
이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.
Windows 앱 개발
기존 Windows 업무 애플리케이션과 CSV·고정 길이 파일·데이터베이스·웹 시스템을 연결하는 구성의 검토와 구현은 업무 애플리케이션 개발 상담 범위에 해당하기 때문입니다.
Windows 소프트웨어 유지 보수 & 현대화
전면 개편을 전제로 하지 않고, 기존 시스템을 유지하면서 수작업 입력이나 전기 작업을 단계적으로 줄이는 개수(改修)는 기존 Windows 소프트웨어의 개수·유지보수에 해당하기 때문입니다.
기술 상담 & 설계 리뷰
거래처와의 데이터 형식·운용 규칙·예외 처리를 정리하고 어디까지 자동화할 것인지를 결정하는 작업은 설계 리뷰를 수반하는 기술 상담이기 때문입니다.
저자 프로필
기사 저자의 프로필 페이지입니다.
Go Komura
합동회사 코무라소프트 대표
Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.
공개 링크