ERP 연동 SCM 구축: 기존 시스템을 유지하며 운영 조회 통합하기

ERP 연동 SCM 구축에서 기존 ERP를 유지하려면 어떤 데이터를 읽어 운영 조회로 모을지 먼저 정하세요. ERP를 재고·발주·마감의 정본으로 두고 별도 조회 사본을 만드는 범위라면 원장 교체와 구분해 견적을 받을 수 있습니다. ERP에 값을 다시 쓰는 기능은 별도 승인·예외·복구 검수가 필요합니다.

ERP는 계속 쓰고 싶은데 채널별 현황까지 한 번에 보기는 어렵다는 요청이 있습니다. 이때 전체 시스템을 새로 만드는 대신 ERP와 채널에서 필요한 데이터를 읽어 조회 화면을 구성하는 방안을 비교할 수 있습니다. 연동이라는 말만으로는 구매 범위가 정해지지 않습니다. 오늘의 입고 현황을 보여주는 것인지, ERP에 새 입고를 등록하는 것인지에 따라 권한과 검수 책임이 크게 달라집니다.

이 글은 기존 ERP를 정본으로 유지한 운영 조회 통합의 발주 기준입니다. API를 어떤 형식으로 구현할지 설명하는 기술 명세나 재고 수량을 여러 시스템에 맞추는 실행 가이드와는 범위가 다릅니다. 구매 담당자는 ERP 담당 부서와 데이터 제공 권한을 확인하고 조회 화면에서 내릴 판단을 정리하세요. 연결 기술을 선정하기 전에 원천의 의미와 변경 승인 절차를 합의해야 개발사 간 제안도 같은 기준으로 비교할 수 있습니다.

가상 예시로 ERP의 확정 입고 현황과 쇼핑몰의 주문 흐름을 함께 보는 화면을 가정합니다. 두 원천의 기준일이 다르면 한 표의 수치가 서로 맞아 보이지 않을 수 있습니다. ERP의 마감 자료와 채널의 진행 중 자료를 구분해 표시하고 비교 가능한 구간만 합의합니다. 이 예시는 실제 고객의 구현 범위가 아니며 모든 ERP에서 같은 필드나 조회 기능을 제공한다는 뜻도 아닙니다.

ERP를 유지한다는 결정에는 업무 절차와 지원 계약을 보존한다는 조건도 포함될 수 있습니다. 기존 공급자가 허용하는 연결 방식, 사용자 정의 확장 가능 여부, 운영 중 조회 부하와 버전 변경 계획을 확인합니다. 데이터베이스를 직접 열어달라는 요청이 가장 빠르게 보이더라도 공식 지원과 보안·업그레이드 영향을 먼저 검토해야 합니다. 발주사가 접근 권한을 갖고 있는지도 별도 확인 사항입니다.

제품 문서는 연결 조건의 참고 자료입니다#

2026년 10월 27일 확인한 Microsoft Business Central API 안내는 읽기와 수정 요청을 구분하고 회사별 자원 접근 구조를 설명합니다. 이 문서는 Business Central의 동작이며 모든 ERP에 동일한 설정이 있다는 뜻은 아닙니다. 읽기 의도를 지정해도 복제본 사용이 항상 보장되지는 않는다는 문서의 제한도 함께 봐야 합니다. 알파카랩스의 Omnidash 공개 개요는 쇼핑몰 운영 조회·비교 사례이며 특정 ERP 연결이나 ERP 변경 쓰기의 수행 증거로 사용하지 않습니다.

• Microsoft Learn: Business Central API tips: 제품별 읽기·수정 경계를 참고합니다. 대상 ERP의 지원 방식은 따로 확인해야 합니다.
• Omnidash 공개 프로젝트: 쇼핑몰 통합 조회 사례입니다. ERP 연결과 실행 기능을 확인한 자료는 아닙니다.

ERP 업무를 방해하지 않는 조회 운영#

ERP 운영 부서와 수집 시간을 협의합니다. 월말 마감이나 대량 작업 중에도 같은 빈도로 조회해야 하는지, 데이터를 가져오는 작업을 일시 중단할 수 있는지 정하세요. 화면에서 새로고침을 누를 때마다 ERP 전체를 읽는 방식이면 사용자 증가가 원천 부하로 이어질 수 있습니다. 수집 작업과 사용자 조회를 어떻게 분리하는지 제안서에 설명하도록 요청하고 실제 부하는 승인된 환경에서 확인합니다.

연동 계정은 사용자 개인 계정과 구분하고 소유자, 읽을 회사·법인·자원과 만료·회수 절차를 기록합니다. 화면의 권한이 원천보다 넓어지지 않도록 사업장과 부서별 조회 범위를 맞춰야 합니다. 운영 로그와 내려받기에도 같은 경계를 적용하세요. 계정 변경 때 어떤 수집이 멈추는지 목록으로 확인할 수 있어야 담당자 교체가 곧 데이터 장애로 이어지는 일을 줄일 수 있습니다.

코드가 바뀌거나 새로운 품목이 들어오면 미매핑 목록을 업무 담당자가 확인하도록 합니다. 이름이 비슷하다는 이유로 서로 다른 품목을 자동 합치지 않습니다. 매핑이 승인되기 전에는 미분류로 보여주고 합계 포함 조건을 명시하세요. 과거 자료의 매핑까지 바꿀 경우 이미 배포한 보고서 수치가 달라질 수 있으므로 적용 시점과 재산출 범위를 함께 승인받습니다.

조회 사본을 복구하는 일과 ERP 거래를 복구하는 일은 구분해야 합니다. 조회 데이터가 손상됐다면 합의한 범위를 다시 가져와 대사하는 절차를 검토할 수 있습니다. 이를 이유로 ERP의 거래나 마감 원장을 초기화하지 않습니다. 로그에는 재수집 대상 기간, 실행자, 결과와 남은 차이를 남기고 완료 판정은 원천과의 비교 뒤에 내리도록 운영 인수서에 적으세요.

기존 ERP가 업그레이드될 때 조회 연결도 영향 검토 대상이 됩니다. 변경 공지를 받을 창구, 시험 환경 접근, 필드·코드 변경 확인과 배포 순서를 정합니다. ERP 공급자와 대시보드 개발사가 서로 다른 경우 발주사가 조정할 책임도 필요합니다. 두 계약의 지원 시간과 원인 조사 범위가 맞지 않으면 장애가 오래 머물 수 있으므로 계약 전 합동 확인 절차를 논의해두는 편이 좋습니다.

데이터 제공 계약과 보관 조건도 발주 범위에 포함합니다. 원천 ERP에서 조회를 허용했다고 해서 모든 자료를 장기간 복제하거나 외부에 전달할 권한까지 확보한 것은 아닐 수 있습니다. 자료별 목적·보관 기간·접근자와 계약 종료 시 반환·삭제 조건을 확인하세요. 개발사에 전달할 표본은 업무 검증에 필요한 필드를 남기고 개인 정보와 비공개 가격 등 불필요한 항목은 가리는 방식으로 준비합니다.

업체 선정 때에는 기존 ERP를 수정하지 않는 조건을 어떤 산출물로 확인할지 묻습니다. 연결 계정의 권한표, 호출 대상 목록, 설정 변경 이력과 원장 변경이 없는 표본 확인을 요청할 수 있습니다. 이 자료는 특정 기술 하나를 강제하기 위한 것이 아니라 계약한 경계를 설명하기 위한 것입니다. 원천 제공 방식 때문에 추가 개발이 필요하면 기존 ERP 공급자의 동의와 비용·운영 책임을 먼저 확정하세요.

검수에서 확인하지 못한 제품·회사·법인은 별도 목록으로 남깁니다. 한 법인 연결이 성공했다고 다른 법인의 품목 코드와 접근 조건까지 같다고 가정하지 않습니다. 확장할 때 조사할 자료, 승인 담당과 기대 결과를 정하고 새 범위의 표본 대사를 다시 수행하세요. 초기 구축 때의 가정을 복사하기보다 달라진 원천 조건을 확인해야 조회 범위가 늘어도 정본과 권한의 경계를 유지할 수 있습니다.

기술 계약의 세부 항목은 API 연동 개발 가이드를 참고하세요. 거래 입력을 추가하려면 기존 ERP 확장 개발과 조회 범위를 구분해 검토하세요.

유지형 ERP 연동의 인수 조건#

가상 검수 표본으로 ERP 한 법인의 확정 입고와 채널 주문 자료를 준비합니다. 동일한 품목 코드가 아닌 경우 매핑표를 함께 제공하고 미매핑 품목도 남겨둡니다. 업체는 정본 필드를 추적하고 서로 다른 날짜와 단위를 화면에 어떻게 표시하는지 설명해야 합니다. 거래 한 건의 일부만 조회되거나 제공되지 않는 필드가 있으면 범위를 숨기지 않고 미확인으로 표시하는지 확인하세요.

부정 검수에서는 읽기 전용 계정으로 원천 변경을 시도할 수 없는지 확인합니다. 메뉴에 수정 버튼이 없다는 것만으로 충분하지 않습니다. 연결 계정과 서버 경로도 계약한 조회 범위에 맞는지 승인된 방식으로 점검합니다. 다른 법인 식별자를 넣었을 때 자료가 노출되지 않는지, 다운로드가 부서 권한을 넘어가지 않는지도 함께 확인해야 합니다.

예외 표본에는 ERP 점검, 인증 만료, 일부 자료 지연과 코드 변경을 넣습니다. 수집 실패 뒤 이전 값이 최신처럼 보이지 않는지, 재개 후 빠진 기간을 확인할 수 있는지 봅니다. 원천 수치가 소급 정정되면 조회 사본의 차이를 어떻게 찾고 반영하는지도 검수하세요. 단순히 연결이 다시 성공했다는 로그만으로 소급 변경까지 모두 해결됐다고 판단하지 않습니다.

운영 담당자는 문서를 보고 시험 환경의 수집 중단과 재개를 수행하고 표본 대사 결과를 설명해봅니다. 계정 소유권, 설정값 목록, 배포·복원 절차와 기존 ERP 공급자 연락 경로가 인수물에 포함돼야 합니다. 변경 쓰기 기능을 추가할 계획이 있더라도 이번 조회 인수와 혼합하지 마세요. 다음 계약에서는 승인·원장·중복·마감 이후 정정 기준을 별도로 합의합니다.

자주 묻는 질문#