EDI 온보딩이란 무엇인가요?

EDI는 거래 파트너 간에 송장, 구매 주문서, 공급망 정보 등 비즈니스 데이터와 문서를 실시간 및 전자적으로(그리고 종종 자동적으로) 전송하기 위한 시스템 및 표준을 의미합니다.

EDI 트랜잭션에서 정보는 한 조직의 EDI 애플리케이션에서 다른 조직의 EDI 애플리케이션으로 직접 이동합니다. EDI 표준은 각 문서의 정보 위치와 순서를 정의합니다. 

EDI 솔루션은 자동화, 확장성 및 표준화를 통해 많은 이점을 제공합니다. EDI는 수십 년 동안 기업 간(B2B) 상호 작용을 위한 문서 교환 수단으로 선호되어 왔습니다. 특히 자동으로 생성되고 표준화된 양식은 데이터를 수동으로 입력할 필요성을 간소화하고 줄이거나 없애 오류와 관련 비용을 줄입니다.  

일부 기업과 일부 산업에서는 EDI를 사용하는 것이 선택이 아니라 필수입니다. 많은 대형 소매업체 및 제조업체에는 비즈니스 프로세스에 대한 EDI 요구 사항 및 규정 준수가 있습니다.

거래 파트너 간에는 규정 준수 요건, 문서 매핑 요구 사항, 통신 프로토콜 또는 테스트 프로세스 등의 차이가 존재할 수 있습니다. 이는 EDI 표준의 일반적인 복잡성과 결합되어 EDI 온보딩 프로세스를 어렵고 시간이 많이 소요되는 프로세스로 만들 수 있습니다. 

그러나 표준화되고 잘 문서화된 내부 온보딩 프로세스, 적절한 미들웨어 도구, 비즈니스 파트너와의 명확한 커뮤니케이션을 통해 EDI 설정 문제를 완화할 수 있습니다. 또한 조직이 데이터 정확성을 높이고 EDI 규정 준수가 필요한 기업과의 거래 능력을 포함하여 EDI의 이점을 누릴 수 있도록 지원합니다.

EDI 플랫폼을 전사적 자원 관리(ERP) 플랫폼과 같은 다른 내부 기업 시스템과 통합함으로써 조직은 자동화된 파이프라인을 구축할 수 있습니다. 이러한 파이프라인은 표준화된 비즈니스 데이터를 파트너에게 전송하고 내부 시스템을 EDI 플랫폼과 동기화할 수 있습니다.

이 통합은 '파이프라인을 완성'함으로써 EDI 소프트웨어의 파트너 간뿐만 아니라 비즈니스 파트너에서 조직의 백엔드 애플리케이션 및 비즈니스 시스템으로의 데이터 자동 흐름을 가능케 합니다. 통합되면 EDI 애플리케이션은 내부 플랫폼(예: ERP 시스템)에서 데이터를 추출하고, 이 정보를 표준화된 EDI 형식으로 변환하고, 파일을 거래 파트너에게 안전하게 전송할 수 있습니다. 이 자동화된 통합은 내부 플랫폼의 데이터를 EDI 플랫폼으로 다시 입력할 필요가 없으므로 수동 데이터 입력이 더욱 줄어듭니다.

EDI 온보딩은 EDI 플랫폼의 설정만 의미할 수도 있고, 플랫폼의 구성과 내부 엔터프라이즈 시스템과의 통합을 모두 의미할 수도 있습니다. 현대 IT 환경에서 통합 시스템의 중요성을 고려할 때 일반적으로 후자를 의미합니다.

온보딩은 개별 사례마다 다르게 진행될 수 있지만, 다음 단계는 대부분의 온보딩 과정에서 중요한 요소입니다.

온보딩의 첫 번째 단계에서 잠재적인 신규 거래 파트너는 EDI 연결이 작동하는 방식에 대한 기술적 기본 사항을 협의하고 동의해야 합니다. 이 계약은 일반적으로 거래 파트너 계약(TPA)을 통해 표현됩니다. TPA는 EDI 거래 파트너 간에 해당 EDI 교환의 전체 범위를 명시하는 계약입니다. TPA에는 문서 유형과 표준뿐만 아니라 책임 조건, 규정 준수 규칙, 계약 기간, 통신 프로토콜 등이 모두 포함됩니다. 파트너 온보딩을 위한 이러한 사전 협상은 온보딩 과정의 나머지 단계를 위한 토대를 마련합니다.

고려해야 할 주요 사항은 다음과 같습니다.

관련된 문서의 특성에 따라 EDI 온보딩 프로세스의 많은 후속 단계가 결정됩니다. 일부 산업이나 사업장에서는 다른 표준이나 다른 보안 조치가 필요할 수 있습니다. EDI를 통해 교환되는 가장 일반적인 문서에는 850 구매 주문서, 810 송장, 997 기능 승인서가 포함됩니다.

표준화는 EDI의 주요 구성 요소이지만, 다양한 목적을 위한 여러 표준이 있습니다. 일반적인 표준에는 북미에서 가장 일반적으로 사용되는 ANSI ASC X12(X12라고도 함)가 포함됩니다. HIPAA는 의료 거래 및 의료 정보에 대해 해당 표준의 특정 버전을 의무화합니다. EDIFACT는 UN에서 개발한 공통 국제 표준입니다.

EDI 온보딩의 두 번째 단계는 기술 사양을 교환하는 것으로, 이는 기본적으로 문서를 교환할 정확한 방식에 대해 논의하고 합의하는 과정입니다. 

EDI 원칙에 따라 문서를 전송하는 데 사용할 수 있는 통신 프로토콜에는 여러 가지가 있습니다. 그 예는 다음과 같습니다.

• AS2(Applicability Statement 2): HIPAA 규정 준수와 디지털 서명 및 전송 알림과 같은 기능을 지원하는 공통 프로토콜입니다.
  
  
• SFTP(Secure File Transfer Protocol): 사용이 간편하고 단순하지만, AS2에서 볼 수 있는 몇 가지 고급 기능이 없는 구형 프로토콜입니다.
  
  
• MFT(Managed File Transfer): 엔드투엔드 암호화 및 감사 추적 등 보다 최신 기능을 갖춘 FTP(File Transfer Protocol)의 발전된 버전입니다.
  
  
• SOAP(Simple Object Access Protocol): 플랫폼에 구애받지 않는 XML 기반 메시징 시스템으로, 레거시 EDI 시스템에서 사용되기도 합니다.

EDI 구현 가이드는 데이터 교환의 많은 기술적 측면을 정의하는 문서입니다. 구현 가이드에는 프로토콜, 문서 유형 및 표준을 포함하여 지금까지 논의한 모든 내용이 포함되어 있는 경우가 많습니다.

하지만 구현 가이드에서는 문서 자체를 더 깊이 있게 다루기도 합니다. 즉 각 문서 유형에서 작성해야 하는 필드, 발신자와 수신자를 식별하기 위한 각 거래소의 ID 코드 및 기타 파트너별 규칙을 정의합니다. 구현 가이드는 혼란이나 오류로 인해 심각한 중단이 발생할 수 있으므로 트랜잭션 양이 많은 대규모 조직에 일반적이고 유용합니다.

이제 모든 사양과 계약이 확정되었으므로 다음 단계는 EDI 교환을 위한 인프라를 설정하는 것입니다.

EDI 인터페이스를 처음부터 구축하는 것도 가능하지만, 조직에서는 사전 구축된 플랫폼을 사용하는 것이 더 일반적입니다. 최신 EDI 제공업체 플랫폼에는 시스템 간 수동 데이터 입력의 필요성을 줄이기 위해 ERP(Enterprise Resource Planning) 플랫폼 및 WMS(Warehouse Management System)와 같은 다른 내부 엔터프라이즈 플랫폼에 대한 통합이 포함되는 경우가 많습니다. 중소기업의 경우 클라우드 기반 웹 포털은 저렴한 시작 비용과 효율적인 EDI 사용을 위한 기본 기능(예: ERP 통합)을 제공합니다. 이러한 솔루션 중 상당수는 고급 검증 및 규정 준수 검사를 위해 AI 도구를 점점 더 많이 통합하고 있습니다.

규모가 큰 조직일수록 더 많은 고객 서비스와 주의가 필요할 수 있으며, 관리형 EDI 서비스는 웹 EDI 포털보다 가격은 높지만 매핑, 테스트, 지원 등을 제공하지만 운영 효율성이 향상됩니다.

매핑 단계에서 가장 많은 마찰을 발생할 수 있습니다. 기본적으로 데이터 매핑은 XML, CSV 또는 기타 형식일 수 있는 내부 데이터를 X12와 같은 표준화된 EDI 형식 중 하나로 변환하는 프로세스입니다.

대부분의 EDI 플랫폼에는 매핑 기능이 포함되어 있으며, 데이터 흐름 변환을 처리하기 위한 드래그 앤 드롭 인터페이스를 사용하는 경우가 많습니다. 프로세스를 보다 세부적으로 제어할 수 있는 독립형 EDI 매핑 소프트웨어도 있습니다. 이 프로세스는 매우 세분화되고 까다로울 수 있습니다. 즉 각 개별 EDI 데이터 필드는 구현 가이드에 따라 매핑해야 합니다.

예를 들어, 공급업체는 내부 부품 번호를 사용하지만, SKU를 사용하는 소매업체에 해당 부품을 판매할 수 있습니다. 이 경우 부품 번호가 SKU와 동일한 품목임을 나타내는 상호 참조 표가 있어야 합니다. 매핑과 관련된 다른 문제로는 '부서' 또는 '창고 통로'와 같이 공급업체는 사용하지만, 고객은 사용하지 않는 필드가 있을 수 있습니다. 이와 같은 정보는 일치하지 않으며 조건부 또는 선택 사항으로 레이블을 지정해야 할 수 있으므로 검증에 실패할 수 있습니다.

대형 소매업체와 같은 많은 조직에서는 이 프로세스를 좀 더 쉽게 만들기 위해 사전 구축된 매핑 템플릿 라이브러리를 제공합니다. 다른 조직에서는 타사 계약자를 고용하여 맵을 설정할 수도 있습니다.

Long View Systems의 분석에 따르면 EDI는 규정 미준수 오류 발생률이 높아서 까다로운 것으로 악명이 높습니다. EDI를 구현하는 동안 오류가 발생하면 공급 및 상거래 체인에 연쇄적인 영향이 발생할 수 있습니다. 바로 이러한 이유 때문에 테스트는 성공적인 온보딩 프로세스에서 매우 중요한 단계입니다.

연결성 테스트 단계는 한 시스템이 다른 시스템과 통신할 수 있는지 확인하는 것을 목표로 합니다. 일반적으로 이는 MDN 또는 메시지 처리 알림(자동 수신 응답)을 반환하는 간단한 '테스트' 메시지로 수행됩니다. 

이 단계에서는 EDI 파일이 EDI 형식 표준 및 구현 가이드에 따라 올바르게 구성되었는지 확인합니다. EDI 검증에는 여러 요소가 포함됩니다. 

가장 기본적인 것은 구문 검증일 것입니다. 필수 필드를 모두 채웠나요? 필드가 올바른 순서로 되어 있나요? 필드가 해당 데이터 유형에 따라 작성되었나요(예: 날짜가 '2026년 3월 18일'이 아닌 YYYYMMDD로 표시되었는 여부)? 

또 다른 검증 카테고리는 코드 세트 검증입니다. 국가 코드나 통화 코드와 같은 코드가 공식적으로 인정된 목록과 일치하나요? 

더미 문서 전송은 문서가 적절하게 전송되고 수신되는지 확인하는 중요한 단계입니다. 트랜잭션 양측의 팀은 함께 제공되는 오류 메시지를 분석하고 무엇이 잘못되었는지 확인할 수 있습니다. 일반적인 문제로는 잘못된 코드 값, 형식 오류, 불완전한 필수 필드 등이 있습니다. 

단일 트랜잭션이 제대로 작동하면 이제 전체 프로세스에 대한 엔드투엔드 테스트를 진행해야 합니다. 이 단계에는 ERP 또는 기타 플랫폼과의 통합이 오류 없이 작동하는지, 전송된 각 트랜잭션이 997(기능 승인 양식)을 반환하는지, 각 단계가 이전 단계의 후속 조치를 따르는지 확인하는 작업이 포함됩니다. 이러한 워크플로는 여러 단계로 이루어질 수 있습니다. 구매 주문이 있으면 송장 주문이 전송되나요? 

테스트가 완료되고 각 거래 파트너가 시스템을 출시할 준비가 되었다고 인정하면 플랫폼의 가동 준비가 끝납니다. 이는 테스트 환경에서 프로덕션 환경으로 이동하도록 EDI 플랫폼을 조정하는 것을 의미할 수 있으며, 이 작업은 단계적으로 또는 한 번에 모두 수행할 수 있습니다. 

라이브 EDI 출시 초기에는 모든 트랜잭션이 제대로 작동하는지 확인하기 위해 각 트랜잭션에 특별한 주의를 기울이는 것이 일반적입니다. 이러한 초기 거래에는 일반적으로 수동 검증을 통해 예상치 못한 오류나 오류가 나타나지 않는지 확인합니다. 

EDI의 전체 라이프사이클 동안 한 파트너가 구현 가이드를 변경하기로 결정할 수 있습니다. 예를 들어, 새 항목, 새 제품 유형 또는 새 필드를 추가할 수 있습니다. 이러한 요소들은 차례로 검증하고 테스트해야 합니다. EDI는 자동화되어 있지만 고정되어 있지는 않으며, 필요할 때 업데이트를 구현할 수 있습니다. 

EDI 온보딩 프로세스는 복잡하고 오류와 불만이 발생할 가능성이 높습니다. 일반적인 함정은 다음과 같습니다.