MES와 ERP 통합 방법: 생산 현장에서 본 관점

Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.

By Mirko Peters · 2026-11-12

MES 관점에서 본 MES와 ERP 통합 방법입니다. 현장이 ERP에 필요로 하는 것, ERP가 돌려받아야 하는 것, 마스터 데이터를 맞추는 방법, 그리고 프로젝트에서 피해야 할 함정을 다룹니다.

Automatically translated with AI from the original post. Read the English original

MES와 ERP를 통합하려면 먼저 몇 가지 핵심 데이터 객체와 메시지를 합의한 뒤, 기준 데이터, 오더 출고, 현장 피드백, 오류 처리 순서로 구축하십시오. MES 관점에서 보면 작업은 단순합니다. 무엇을 만들지 받고, 무슨 일이 있었는지 보고하는 것입니다. 어려운 부분은 두 시스템이 "품목", "작업", "완료"의 의미를 동일하게 이해해야 한다는 점과, 오류에 대한 책임자를 정해야 한다는 점입니다. 이 글은 프로젝트에서 현장 측 업무를 책임지는 공장장을 위한 것입니다.

핵심 포인트

• MES 관점에서 보면 이 통합은 두 가지 역할을 합니다. 무엇을 어떤 데이터와 함께 만들지 받고, 무슨 일이 있었는지 ERP가 전기할 수 있는 형태로 보고하는 것입니다.
• 오더 메시지와 기준 데이터는 서로 다른 흐름입니다. Microsoft의 MES 인터페이스에서는 제품, 자재명세서, 라우팅을 데이터 엔터티나 OData를 통해 별도로 가져옵니다.
• 인터페이스를 구축하기 전에 완료의 의미, 폐기 보고 방식, 정정 절차를 먼저 합의하십시오.
• 마스터 데이터에는 담당자, 식별자 매핑, 정기적인 대사가 필요합니다. MES는 ERP 라우팅과 시간의 모든 오류를 그대로 물려받기 때문입니다.
• 실패 상황을 의도적으로 테스트하고, 실패한 메시지를 누가 확인할지 정하십시오. 거부된 확인 메시지가 조용히 쌓이면 결국 재고 차이로 이어지기 때문입니다.

MES는 ERP에서 무엇을 필요로 합니까?

세 가지이며, 각각 다른 방식으로 전달됩니다.

첫째, 오더입니다. MES에는 제품, 수량, 일정, 이후의 상태 변경이 포함된 출고 생산 오더가 필요합니다. 타사 MES용 Microsoft 인터페이스에서는 오더가 출고되거나 상태가 바뀔 때 MES가 비즈니스 이벤트를 수신합니다. 다른 ERP 시스템은 다른 메커니즘을 사용하지만 원칙은 같습니다. ERP가 알리고, MES가 가져갑니다.

둘째, 기준 데이터입니다. 제품을 만드는 방법에 대한 설명, 즉 품목, 자재명세서, 라우팅, 셋업 시간을 말합니다. 같은 Microsoft 페이지에서는 해당 메시지가 현장 이벤트만 다루며 마스터 데이터는 포함하지 않는다고 명시합니다. MES는 데이터 엔터티나 OData를 통해 ERP에서 제품, 자재명세서, 라우팅을 가져옵니다. 팀들이 종종 놓치는 부분이므로 이를 두 번째 통합 작업으로 계획하십시오.

셋째, 리소스 정보입니다. ISA-95 표준은 기업 계층과 운영 계층 사이에서 시스템이 교환하는 네 가지 정보를 정의합니다. 자재, 설비, 물리적 자산, 그리고 역할과 자격을 포함한 인력입니다. MES가 기술이나 설비 역량에 따라 작업을 배정한다면, ERP 또는 HR 시스템의 해당 정보가 필요합니다. 어느 시스템이 원천인지 명확히 하십시오.

SAP, Dynamics 365 또는 기타 ERP 시스템을 사용하든 질문은 동일합니다. 기술적인 명칭만 달라집니다.

MES는 ERP에 무엇을 돌려줘야 합니까?

이를 실적 보고(confirmation)라고 생각하시면 됩니다. Microsoft 문서는 인터페이스에 대해 다음과 같은 프로세스를 정의합니다. 주문 시작, 생산 수량과 폐기 수량 보고, 자재 소비 보고, 작업에 사용된 시간 보고, 주문 종료입니다. 각 프로세스마다 별도의 메시지 유형을 사용합니다. 종료 메시지에는 생산 오더 번호만 필요하지만, 수량 메시지에는 품목, 양품 수량, 폐기 시의 오류 원인을 담은 행이 포함될 수 있습니다.

이 모델을 그대로 따를 필요는 없습니다. 다만 구축하기 전에 다음 사항은 반드시 결정해야 합니다.

• 실적 보고는 얼마나 세분화되어야 합니까? 주문 단위, 공정 단위, 교대 단위 중 어디에 해당합니까?
• 작업자가 부분 수량을 실적으로 보고할 수 있습니까? 그렇다면 ERP는 이를 어떻게 처리합니까?
• 폐기는 어떻게 보고합니까? 두 시스템 모두에 존재하는 사유 코드는 무엇입니까?
• 자재 소비량은 작업장에서 측정합니까, 아니면 ERP가 자재명세서(BOM)를 기준으로 계산합니까?
• 오류는 어떻게 수정합니까? 취소(reversal), 조정(adjustment), 새로운 실적 보고 중 무엇으로 처리합니까?
• "완료"는 무엇을 의미하고 "종료"는 무엇을 의미합니까? Microsoft의 생산 프로세스 개요에 따르면, 완료 보고를 하면 제품이 재고에 반영되고, 주문을 종료하면 실제 원가가 계산되며 이후 원가 전기가 차단됩니다. 귀사의 ERP는 이 경계를 다르게 설정할 수도 있습니다.

마지막 질문이 가장 많은 논쟁을 일으킵니다. 계획, 재무, 품질 부서는 모두 같은 상태를 보지만, 각자 원하는 것이 다릅니다. 인터페이스를 작성하기 전에 세 부서가 함께하는 짧은 회의를 열어 정의를 확정하십시오.

MES와 ERP 간에 마스터 데이터는 어떻게 매칭합니까?

주문은 거래입니다. 마스터 데이터는 공정에 대한 설명이며, MES는 그 안의 모든 오류를 그대로 물려받습니다. 실제로는 20분이 걸리는 작업을 12분으로 기재한 라우팅은, 누군가 바로잡기 전까지 현장에서는 성능 문제처럼 보이게 됩니다.

파일럿 라인에 대해 다음 사항을 검토하십시오.

1. 각 객체의 소유자를 지정하십시오. 일반적인 방식은 ERP가 품목, 자재명세서, 라우팅을 소유하고, MES가 설비 설정과 작업 지침서를 소유하는 것입니다. 이는 권장 사항이지 규칙이 아닙니다. 중요한 것은 누구도 추측할 필요가 없도록 하는 것입니다.
2. 식별자를 매핑하십시오. ERP의 작업장 "WC-110"이 현장에서는 "프레스 3"일 수 있습니다. ISA-95에는 이를 위한 부분도 있습니다. 동등한 식별자를 연결하고 매핑하는 방법을 정의하는 별칭(alias) 서비스 모델입니다. 이에 대해서는 ISA의 표준 설명에 나와 있습니다.
3. 작업 순서를 비교하십시오. ERP 라우팅에 있는 단계와 작업자가 실제로 수행하는 단계를 나열해 보십시오. 현장에만 존재하는 검사나 디버링 단계처럼 차이는 금방 드러납니다.
4. 단위, 캘린더, 시간대를 확인하십시오. 개수와 박스 단위, 현지 시간과 UTC의 차이는 조용한 오류를 일으킵니다.
5. 변경 규칙을 정하십시오. 엔지니어링이 라우팅을 변경하면 누가 MES에 알리고, 얼마나 빨리 반영되며, 이미 진행 중인 주문은 어떻게 됩니까?
6. 일정을 정해 비교를 반복하십시오. 마스터 데이터는 시간이 지나면서 실제와 어긋납니다.

가상의 사례를 하나 들어 보겠습니다. ERP 라우팅에는 공정이 3개 있지만, 작업자는 5개 공정을 수행합니다. 검사와 디버링 공정은 수년 전에 추가되었지만 라우팅에 입력되지 않았습니다. MES는 라우팅에 있는 내용만 보고할 수 있습니다. 그래서 ERP에서는 3번 공정이 지연된 것으로 보이지만, 현장에서는 ERP가 모르는 단계를 수행하고 있을 뿐입니다. 누구도 잘못한 것이 없습니다. 데이터가 불완전한 것입니다. 이 예시는 가상이지만, 실제 공장에서도 이런 차이는 자주 발생합니다.

파일 형식으로는 B2MML을 알아둘 가치가 있습니다. MESA는 B2MML을 ISA-95를 구현한 XML 스키마 정의 집합으로, ERP 같은 비즈니스 시스템과 MES 같은 제조 시스템을 통합하는 데 사용된다고 설명합니다. 버전 7에서는 최초의 JSON 스키마가 추가되었습니다. 게시된 스키마를 사용하면 공통된 출발점이 되는 용어를 얻을 수 있지만, 각 필드의 의미에 대해 합의할 필요가 없어지는 것은 아닙니다.

문제가 발생했을 때 인터페이스는 어떻게 동작해야 합니까?

정상 경로는 데모에서 잘 작동할 것입니다. 프로젝트 시간은 다른 경로에 쓰십시오.

Microsoft 문서는 한 제품이 어떻게 동작하는지 보여 주며, 자사 벤더에게 던질 질문의 좋은 출발점이 됩니다. 같은 생산 오더에 대한 메시지는 수신된 순서대로 처리됩니다. 서로 다른 오더의 메시지는 배치 작업이 병렬로 실행되므로 순서가 뒤바뀔 수 있습니다. 실패한 메시지는 최대 세 번까지 재시도한 뒤 실패로 표시됩니다. 모니터링 페이지에서 실패한 메시지를 검토하고 수정하여 다시 처리할 수 있으며, 알림을 통해 IT 관리자나 현장 관리자에게 통보할 수도 있습니다.

ERP와 MES 조합이라면 어떤 환경에서든 다음 네 가지 질문으로 정리해 보십시오.

• ERP가 거부한 확인 메시지는 어떻게 처리됩니까? 예를 들어 오더가 이미 종료된 경우가 해당합니다.
• 실패를 누가, 얼마나 빨리 알게 됩니까?
• ERP를 사용할 수 없는 동안에도 현장에서 작업을 계속할 수 있으며, 이후 모든 데이터를 올바른 순서로 전송할 수 있습니까?
• 같은 확인 메시지가 두 번 도착해도 중복으로 전기되지 않습니까?

실패한 메시지에 책임자가 없으면 누군가 월말에 재고 차이를 발견할 때까지 메시지가 계속 쌓이게 됩니다. 팀이 아니라 담당자 한 명을 지정하십시오.

생산 유형에 따라 연동 방식이 달라집니까?

그렇습니다. ISA-95 구현에 관한 Automation World 기사에서는 수주 설계 생산(engineer-to-order)을 아마도 가장 까다로운 연동 유형으로 꼽습니다. 기업 시스템과 제어 시스템이 거의 실시간으로 정보를 교환해야 하기 때문입니다. 항공우주 산업이 대표적인 예입니다. 설계가 계획을 주도하지만 실행 중에도 변경될 수 있습니다. 변경이 발생하면 계획에 반영될 때까지 실행이 중단되고, 검사 추가와 같은 새로운 작업이 현장으로 전달됩니다. 같은 기사는 표준을 해석하는 벤더마다 차이가 있어 상호운용성 문제가 생길 수 있다고 경고합니다.

여기서 두 가지 교훈을 얻을 수 있습니다. 제품이 구성 또는 설계 주문 방식으로 만들어진다면, 변경 시나리오를 마지막이 아니라 첫 번째 파일럿에 포함하십시오. 그리고 표준 기반 인터페이스는 자사 데이터로 직접 테스트하십시오. "표준"이 "동일함"을 뜻하지는 않습니다.

MES와 ERP를 단계별로 연동하려면 어떻게 해야 합니까?

범위는 작게, 점검은 매일 하십시오.

1. 라인 하나와 제품군 하나를 선택하십시오.
2. 객체, 송신자, 수신자, 트리거, 주기, 담당자를 포함한 인터페이스 표를 작성하십시오. 담당자가 없는 행이 첫 번째 위험 요소입니다.
3. 위에서 언급한 대로 해당 제품군의 마스터 데이터를 대조하십시오.
4. 상태 값과 완료, 폐기, 재작업의 의미에 대해 합의하십시오.
5. 오더, 시작 및 완료 확인부터 구축하십시오. 자재와 시간 데이터는 그다음에 추가하십시오.
6. 실패 상황을 의도적으로 테스트하십시오. 잘못된 수량을 보내 보고, 인터페이스를 중지했다가 재시작해 보고, 중복 메시지를 보내 보십시오.
7. 오픈 당일 이미 진행 중인 오더를 어떻게 처리할지 결정하십시오.
8. 새 흐름을 기존 프로세스와 나란히 몇 주 동안 운영하면서, 두 시스템에서 오더별 양품 수량, 폐기량, 工数, 자재 사용량을 매일 비교하십시오.
9. 현장 작업자가 추가로 해야 할 단계를 세어 보십시오. MES에서 확인하는 데 종이 양식보다 오래 걸린다면, 확대 적용하기 전에 그 이유를 파악하십시오.
10. 차이가 설명된 뒤에만 다음 라인으로 확대하십시오.

흔한 실수

• 마스터 데이터를 일회성 적재 작업으로 취급하고 지속적인 업무로 관리하지 않는 것.
• ERP 관점에서만 인터페이스를 설계해 MES가 현장에서 사용하는 세부 수준으로 보고하지 못하게 되는 것.
• 두 시스템에서 같은 상태 용어를 서로 다른 의미로 사용하는 것.
• 오픈 시점에 진행 중인 오더에 대한 규칙이 없는 것.
• 정상 경로만 테스트하는 것.
• 실패한 메시지에 담당자를 지정하지 않는 것.
• 작업자에게 두 시스템에 같은 데이터를 각각 한 번씩 입력하도록 요구하는 것.

Polaris가 들어갈 자리

ERP 계획과 현장 사이의 순환 고리가 문제라면 iFAKT Polaris를 검토해 볼 만한 선택지가 될 수 있습니다. iFAKT는 Polaris를 ERP 데이터와 함께 작동하는 생산용 AI 및 디지털 트윈으로 설명합니다. Polaris Designer 모듈은 ERP 데이터, 자재명세서(BOM), 공정 시간, 리소스 구조를 제품-공정-리소스 지식 그래프로 변환합니다. Polaris Operator 모듈은 계획을 시간 기반 작업으로 현장에 전달하고, 진행 상황, 지연, 중단 정보를 다시 계획에 반영합니다. 다만 재고, 원가 계산, 추적성을 위해 ERP에서 반드시 전기해야 하는 확인 항목이 무엇인지는 별도의 문제입니다. 따라서 어떤 도구가 무엇을 담당할지 정하기 전에 이 항목부터 먼저 정리하십시오.

함께 살펴볼 관련 주제

• ISA-95를 쉽게 풀어 보면, 어떤 활동이 ERP 계층에 속하고 어떤 활동이 운영 계층에 속하는지 살펴봅니다.
• 폐쇄 루프 계획: 현장에서 올라오는 확인 정보가 다음 일정을 어떻게 바꾸는지 설명합니다.
• 공장 네트워크와 비즈니스 네트워크 사이 연결 보안: 계정, 네트워크 분리, 인터페이스 패치 적용 방법을 다룹니다.
• 완전한 MES 없이 현장 보고하기: 스캔과 간단한 확인 절차로 무엇을 처리할 수 있는지 알아봅니다.

다음 단계

제품군 하나를 골라 MES와 ERP 사이에서 이동해야 하는 모든 객체를 표로 정리하십시오. 각 객체의 발신자, 수신자, 담당자를 함께 적습니다. MES와 ERP 통합을 문제없이 진행하고 싶다면 이 표를 IT 부서 및 공급업체와의 첫 모임에 가져가십시오.