ERP개발 외주 문의 전, 기존 시스템 연동과 단계적 구축 범위를 정하는 방법

“회계 프로그램은 이미 사용하고 있는데 재고와 영업 데이터가 연결되지 않습니다.”

“ERP를 새로 만들고 싶지만 기존 시스템을 한꺼번에 바꾸면 업무가 멈출까 걱정됩니다.”

“부서마다 엑셀 양식과 업무 처리 방식이 달라서 어디부터 개발해야 할지 모르겠습니다.”

ERP개발을 검토하는 기업에서 자주 겪는 상황입니다.

ERP를 도입한다고 하면 회계, 영업, 구매, 재고, 생산, 인사 업무를 하나의 시스템으로 통합하는 모습을 먼저 떠올리기 쉽습니다. 하지만 실제 프로젝트에서는 모든 업무를 처음부터 다시 만드는 것보다 현재 사용 중인 시스템을 파악하고, 유지할 기능과 개선할 기능, 새 ERP와 연동할 기능을 구분하는 작업이 먼저 필요합니다.

이미 회계 솔루션을 안정적으로 사용하고 있다면 회계 기능까지 새로 개발할 필요가 없을 수 있습니다. 반대로 회사만의 견적 승인 절차, 거래처별 단가 정책, 재고 배정 규칙처럼 일반적인 패키지에서 처리하기 어려운 업무가 있다면 해당 영역은 맞춤 개발이 적합할 수 있습니다.

따라서 ERP개발의 시작점은 “어떤 메뉴가 필요한가”가 아닙니다.

현재 업무가 어디에서 시작되고, 누가 처리하며, 어떤 데이터를 다른 시스템으로 전달하고, 어느 단계에서 반복 입력과 확인 작업이 발생하는지를 먼저 정리해야 합니다.

ERP개발이 필요한 상황부터 구분해야 합니다

ERP와 관련된 모든 불편을 맞춤 개발로 해결해야 하는 것은 아닙니다.

현재 사용 중인 패키지의 설정을 변경하거나 추가 모듈을 도입하는 것만으로 해결할 수 있는 문제도 있습니다. 반면 회사 고유의 업무 규칙이 많고 여러 시스템 사이에서 데이터를 반복해서 옮기고 있다면 맞춤형 ERP개발이나 연동 시스템 구축을 검토할 수 있습니다.

기존 솔루션이나 패키지 설정으로 해결할 수 있는 경우

다음과 같은 상황이라면 새로운 ERP를 처음부터 개발하기 전에 기존 제품의 기능과 설정 범위를 확인하는 편이 좋습니다.

일반적인 매입·매출과 회계 처리가 중심인 경우
표준적인 근태·급여·인사 관리가 필요한 경우
거래처와 상품 구조가 비교적 단순한 경우
현재 솔루션에 필요한 기능이 있지만 설정하지 않은 경우
별도 개발보다 업무 절차를 표준화하는 편이 효율적인 경우
기존 제품의 추가 모듈이나 API로 필요한 기능을 제공할 수 있는 경우

패키지 ERP는 검증된 표준 기능을 비교적 빠르게 적용할 수 있다는 장점이 있습니다. 회사 업무가 패키지의 기본 구조와 잘 맞는다면 맞춤 개발 범위를 줄이는 것이 유지보수와 운영에도 유리할 수 있습니다.

맞춤 ERP개발을 검토할 수 있는 경우

반면 다음과 같은 상황에서는 회사 업무에 맞춘 개발이 필요할 수 있습니다.

거래처마다 상품, 가격, 결제 조건이 다른 경우
견적, 승인, 주문, 출고, 정산 절차가 일반적인 흐름과 다른 경우
영업팀과 재고팀이 서로 다른 시스템을 사용해 데이터를 반복 입력하는 경우
생산·물류·정산 규칙이 회사 사업 방식에 따라 달라지는 경우
여러 지점이나 법인별 데이터 접근 범위를 구분해야 하는 경우
기존 시스템에 API가 있지만 실제 업무에 필요한 연결 기능이 부족한 경우
현장 담당자용 웹이나 앱이 ERP 업무와 연결되어야 하는 경우
운영자가 반복하는 엑셀 취합과 수기 확인을 시스템으로 전환해야 하는 경우

다만 맞춤 개발이 필요하더라도 모든 기능을 새로 만들 필요는 없습니다.

회계는 기존 솔루션을 유지하고, 영업·주문·재고 업무만 맞춤 개발한 뒤 필요한 결과를 회계 시스템으로 전달하는 혼합형 구조도 가능합니다. 어떤 방식을 선택할지는 제품명이 아니라 현재 업무를 어느 수준까지 표준화할 수 있는지, 회사 고유의 규칙이 어디에 있는지를 기준으로 판단해야 합니다.

화면 목록보다 현재 업무 흐름을 먼저 정리해야 합니다

ERP개발 문의를 준비할 때 메뉴 구조부터 작성하는 경우가 많습니다.

예를 들어 다음과 같이 기능을 정리할 수 있습니다.

거래처 관리
상품 관리
견적 관리
주문 관리
재고 관리
매출 관리
통계 관리

이 목록만으로는 실제 개발 범위를 판단하기 어렵습니다.

같은 주문 관리라도 회사마다 처리 절차가 다르기 때문입니다. 어떤 회사는 영업 담당자가 주문을 등록하면 바로 출고가 진행되지만, 다른 회사는 팀장 승인, 신용 한도 확인, 재고 확보, 입금 확인을 거친 뒤 출고할 수 있습니다.

따라서 메뉴보다 다음과 같은 업무 흐름을 먼저 작성하는 편이 좋습니다.

``text 거래처 등록 → 담당자 검토 → 거래 조건 승인 → 견적 작성 → 고객 확인 → 주문 전환 → 재고 확인 또는 발주 요청 → 출고 → 세금계산서·회계 처리 → 입금 확인 → 거래 종료 ``

각 단계에는 담당자, 입력 데이터, 승인 조건, 예외 상황이 연결됩니다.

예를 들어 주문 접수 단계만 보더라도 다음 질문에 대한 답이 필요합니다.

주문은 고객이 직접 등록합니까, 영업 담당자가 대신 등록합니까?
거래처별 계약 단가를 자동으로 적용해야 합니까?
재고가 부족하면 주문을 막습니까, 발주 대기로 전환합니까?
한도 초과 거래는 누구의 승인을 받아야 합니까?
입금 전 출고가 가능한 거래처가 있습니까?
부분 출고와 분할 결제가 가능합니까?
주문이 취소되면 확보한 재고는 언제 다시 사용할 수 있습니까?

이러한 기준이 정리되어야 ERP의 데이터 구조, 상태값, 권한, 승인 절차를 설계할 수 있습니다.

기준정보를 먼저 정리해야 시스템 간 데이터가 맞습니다

ERP에서는 매일 발생하는 주문이나 입출고 내역만큼 기준정보가 중요합니다.

기준정보는 여러 업무에서 공통으로 사용하는 데이터입니다. 거래처, 상품, 창고, 부서, 담당자, 세금 코드, 결제 조건 등이 대표적입니다. Microsoft의 업무 시스템 구현 가이드에서도 고객·상품·공급업체 같은 마스터 데이터와 통화·세금 코드·결제 방식 같은 설정 데이터를 구분하고, 시스템 구축과 데이터 이전 과정에서 각각 계획하도록 안내합니다. (learn.microsoft.com)

ERP개발 전에 최소한 다음 항목을 확인할 필요가 있습니다.

| 구분 | 확인할 기준정보 | |---|---| | 거래처 | 거래처 코드, 사업자번호, 담당자, 결제 조건, 신용 한도 | | 상품 | 상품 코드, 상품명, 규격, 단위, 과세 구분, 사용 여부 | | 가격 | 기본 가격, 거래처별 단가, 수량별 단가, 적용 기간 | | 재고 | 창고, 로케이션, 가용 재고, 예약 재고, 불량 재고 | | 조직 | 법인, 사업장, 부서, 담당자, 비용 센터 | | 회계 | 계정과목, 세금 코드, 결제 수단, 정산 기준 | | 권한 | 사용자 역할, 소속 조직, 조회 범위, 승인 한도 |

문제는 같은 데이터를 부서마다 다르게 관리하는 경우입니다.

영업팀은 거래처를 회사명으로 찾고, 회계팀은 사업자번호를 사용하며, 물류팀은 별도의 거래처 약칭을 사용할 수 있습니다. 상품도 영업용 상품명, 창고용 품목 코드, 회계용 코드가 서로 다를 수 있습니다.

이 상태에서 시스템만 연결하면 같은 거래처나 상품이 중복 등록되거나, 서로 다른 데이터로 인식될 수 있습니다.

따라서 ERP개발 전에는 다음 세 가지를 정해야 합니다.

각 데이터의 고유 식별자는 무엇인지
어느 시스템이 해당 데이터의 원본인지
다른 시스템에는 어떤 항목을 전달할 것인지

기존 시스템 연동에서는 ‘기준 시스템’을 정해야 합니다

ERP개발을 검토하는 회사는 대개 이미 여러 시스템을 사용하고 있습니다.

회계·세무 프로그램
영업관리 또는 CRM
쇼핑몰과 주문 채널
창고·재고관리 시스템
생산관리 시스템
그룹웨어와 전자결재
인사·근태 시스템
택배·물류 시스템
엑셀과 사내 데이터베이스

새 ERP가 모든 시스템을 즉시 대체하지 않는다면 기존 시스템과 데이터를 주고받아야 합니다. 이때 가장 먼저 정할 것은 어느 시스템의 값을 기준으로 사용할 것인가입니다.

공식적인 업무 시스템 통합 가이드에서도 시스템 간 데이터를 연결할 때 해당 정보의 소유 시스템, 즉 기준 시스템을 식별하는 작업을 주요 설계 기준으로 다룹니다. 하나의 데이터라도 기본 고객 정보는 영업 시스템이 관리하고, 신용 한도와 결제 조건은 재무 시스템이 관리하는 것처럼 항목별 소유 시스템이 달라질 수도 있습니다. (learn.microsoft.com)

예를 들어 고객 정보를 CRM과 ERP에서 모두 수정할 수 있도록 만들면 다음과 같은 문제가 발생할 수 있습니다.

CRM에서 변경한 주소가 ERP의 주소로 다시 덮어써짐
영업 담당자가 수정한 연락처가 다음 동기화에서 사라짐
동일한 거래처가 서로 다른 코드로 중복 등록됨
어느 값이 최신인지 운영자가 판단하기 어려움
연동 오류가 발생했을 때 원인을 추적하기 어려움

이를 방지하려면 항목별로 관리 주체를 정해야 합니다.

| 데이터 | 기준 시스템 예시 | 다른 시스템의 역할 | |---|---|---| | 고객 기본 정보 | CRM | ERP로 전달 | | 거래처 결제 조건 | ERP | CRM에서 조회 | | 상품 기본 정보 | ERP | 쇼핑몰·영업 시스템으로 전달 | | 온라인 주문 | 쇼핑몰 | ERP로 전달 | | 실제 출고 결과 | ERP 또는 물류 시스템 | 쇼핑몰에 상태 전달 | | 회계 전표 | 회계 시스템 | 다른 시스템에서는 조회만 제공 |

연동 방향도 모두 실시간일 필요는 없습니다.

주문 접수처럼 바로 반영해야 하는 데이터가 있는 반면, 전일 매출 집계나 재고 리포트는 일정 시간마다 동기화해도 될 수 있습니다. 실시간 연동은 빠르지만 시스템 간 의존성이 높아지고, 외부 시스템 장애가 내부 업무에 영향을 줄 가능성도 커집니다.

따라서 데이터별로 다음 기준을 정하는 것이 좋습니다.

실시간으로 전달해야 하는가?
일정 시간마다 일괄 처리해도 되는가?
사용자가 버튼을 눌렀을 때만 전송해도 되는가?
연동에 실패하면 자동으로 재시도할 것인가?
운영자가 실패 건을 확인하고 다시 처리할 수 있어야 하는가?
중복 전송이 발생해도 한 번만 처리되도록 해야 하는가?
일부 항목만 성공했을 때 전체를 취소할 것인가?

전면 재구축과 단계적 구축을 구분해야 합니다

ERP개발 범위를 검토할 때 모든 업무를 한 번에 전환할지, 단계적으로 적용할지를 결정해야 합니다.

전면 재구축이 적합할 수 있는 상황

다음과 같은 경우에는 전체 업무 구조를 다시 설계하는 방안을 검토할 수 있습니다.

기존 시스템의 데이터 구조와 소스 코드를 파악하기 어려운 경우
핵심 업무가 여러 프로그램과 엑셀에 복잡하게 분산된 경우
시스템별 중복 데이터와 수기 입력이 지나치게 많은 경우
오래된 시스템의 수정이 어렵고 장애가 반복되는 경우
새로운 사업 구조를 기존 시스템에 반영하기 어려운 경우
업무 모듈이 강하게 연결되어 일부만 교체하기 어려운 경우

전면 재구축은 업무 구조를 일관되게 정리할 수 있지만 분석, 데이터 이전, 교육, 전환 테스트의 범위가 커집니다. 기존 ERP와 신규 ERP를 바꾸는 시점에는 일정 기간 데이터 입력을 제한하거나 별도의 전환 작업이 필요할 수 있습니다.

단계적 구축이 적합할 수 있는 상황

다음과 같은 경우에는 우선순위를 정해 단계적으로 개발하는 편이 현실적일 수 있습니다.

회계 시스템은 유지하면서 영업과 재고 업무만 개선하려는 경우
특정 부서의 반복 작업이 가장 큰 문제인 경우
업무를 중단하기 어려워 한 번에 전환할 수 없는 경우
기존 시스템이 API나 파일 연동을 제공하는 경우
초기 예산과 일정을 핵심 업무에 집중해야 하는 경우
실제 사용자 피드백을 반영하면서 범위를 확장하려는 경우

단계적 적용은 모듈, 업무 우선순위, 사업부, 지역 등의 기준으로 나눌 수 있습니다. Microsoft의 구현 가이드도 한 번에 장기간 개발하는 방식보다 가치가 높은 영역부터 적용하고 확장하는 접근을 권장하며, 단계적 배포에서는 신규 시스템과 기존 시스템을 연결하는 임시 인터페이스가 필요할 수 있다고 설명합니다. (learn.microsoft.com)

예를 들면 다음과 같이 범위를 나눌 수 있습니다.

``text 1차: 거래처·상품 기준정보와 영업 견적 관리 2차: 주문·승인·재고 확인 3차: 구매·입고·출고 관리 4차: 회계 시스템과 전표 연동 5차: 경영 리포트와 업무 자동화 ``

단계적 구축에서 주의할 점은 각 단계를 독립적인 프로그램처럼 만드는 것이 아닙니다.

1차 개발에서도 이후 주문, 재고, 회계 연동에 사용할 식별자와 데이터 관계를 고려해야 합니다. 그렇지 않으면 2차 개발을 시작할 때 1차 구조를 다시 수정해야 할 수 있습니다.

권한은 메뉴 접근보다 업무 책임을 기준으로 설계해야 합니다

ERP에서는 같은 화면을 사용하더라도 사용자마다 할 수 있는 작업이 다릅니다.

예를 들어 주문 화면에서 영업 담당자는 자신이 담당하는 거래처의 주문만 등록할 수 있고, 영업 팀장은 소속 팀의 주문을 승인할 수 있으며, 물류 담당자는 승인된 주문의 출고 정보만 수정할 수 있습니다.

권한을 단순히 관리자와 일반 사용자로만 나누면 실제 업무를 반영하기 어렵습니다.

다음 기준을 함께 확인해야 합니다.

어떤 데이터를 조회할 수 있는가?
신규 데이터를 등록할 수 있는가?
기존 데이터를 수정할 수 있는가?
취소하거나 삭제할 수 있는가?
승인·반려·확정 처리를 할 수 있는가?
엑셀 다운로드가 가능한가?
금액이나 원가 정보를 볼 수 있는가?
다른 부서와 사업장의 데이터를 볼 수 있는가?
승인 한도가 얼마인가?

ERP에서는 업무 분리도 고려해야 합니다.

예를 들어 구매를 요청한 담당자가 자신의 요청을 직접 승인하고 지급까지 처리할 수 있다면 내부 통제 측면에서 문제가 될 수 있습니다. ERP 제품에서도 입고 확인과 공급업체 지급처럼 상충할 수 있는 업무를 서로 다른 역할로 분리하는 기능을 제공하며, 역할 기반 권한과 최소 권한 원칙을 중요한 보안 기준으로 다룹니다. (learn.microsoft.com)

권한표는 다음과 같은 형식으로 정리할 수 있습니다.

| 업무 | 영업 담당자 | 영업 팀장 | 물류 담당자 | 회계 담당자 | |---|---:|---:|---:|---:| | 거래처 조회 | 담당 거래처 | 소속 팀 | 배송 대상 | 전체 | | 견적 등록 | 가능 | 가능 | 불가 | 조회 | | 견적 승인 | 불가 | 가능 | 불가 | 불가 | | 출고 처리 | 불가 | 조회 | 가능 | 조회 | | 입금 처리 | 조회 | 조회 | 조회 | 가능 | | 원가 조회 | 제한 | 가능 | 제한 | 가능 | | 데이터 삭제 | 불가 | 제한 | 불가 | 제한 |

개발 문의 단계에서 완성된 권한표까지 만들 필요는 없지만, 최소한 사용자 유형과 각 사용자가 담당하는 업무는 정리해두는 것이 좋습니다.

승인 절차와 상태값을 실제 업무에 맞게 정의해야 합니다

ERP 화면에는 주문, 견적, 구매 요청, 출고, 정산과 같은 업무 데이터가 표시됩니다. 그러나 운영에서 더 중요한 것은 각 데이터가 현재 어느 단계에 있는지를 정확히 구분하는 것입니다.

주문 상태를 예로 들면 다음처럼 나눌 수 있습니다.

``text 임시 저장 → 승인 요청 → 검토 중 → 승인 → 재고 확보 → 출고 준비 → 부분 출고 → 출고 완료 → 정산 대기 → 정산 완료 ``

반려, 취소, 보류, 재처리 같은 예외 상태도 필요할 수 있습니다.

상태값은 화면에 표시할 문구만 정하는 것이 아닙니다. 각 상태에서 가능한 행동과 다음 상태로 이동하는 조건을 함께 정의해야 합니다.

승인 요청 후 작성자가 내용을 수정할 수 있는가?
수정하면 기존 승인을 다시 받아야 하는가?
일부 수량만 출고되면 주문 상태를 어떻게 표시하는가?
출고 후 주문을 취소할 수 있는가?
승인자가 부재중이면 대리 승인할 수 있는가?
일정 금액 이상일 때 승인 단계를 추가할 것인가?
반려 후 재요청하면 이전 이력을 유지할 것인가?

승인 절차에는 수동 처리와 자동 처리가 함께 존재할 수 있습니다. 예를 들어 담당자가 구매 요청서를 검토하는 작업은 수동이지만, 거래처 신용 한도 확인이나 재고 검사에는 자동 규칙을 적용할 수 있습니다. 실제 ERP 워크플로도 수동 작업, 자동 작업, 승인, 반려, 변경 요청 같은 단계를 조합하는 구조를 사용합니다. (learn.microsoft.com)

따라서 개발사에 “전자결재가 필요합니다”라고 전달하기보다 승인 대상, 승인 조건, 단계, 예외 상황을 함께 설명해야 범위를 구체적으로 산정할 수 있습니다.

기존 데이터는 전부 옮기기보다 사용 목적을 기준으로 나눕니다

ERP를 새로 구축할 때 오래된 데이터를 모두 이전해야 한다고 생각하기 쉽습니다.

하지만 오랫동안 누적된 데이터에는 중복 거래처, 사용하지 않는 상품, 잘못된 코드, 누락된 필수값이 포함되어 있을 수 있습니다. 이를 정리하지 않고 그대로 이전하면 신규 시스템에서도 같은 문제가 반복됩니다.

먼저 이전 대상 데이터를 구분하는 것이 좋습니다.

일반적으로 검토할 데이터

현재 거래 중인 거래처
사용 중인 상품과 품목
창고별 현재고
미처리 주문과 구매 요청
미수금·미지급금 등 진행 중인 잔액
유효한 계약과 가격 조건
재직 중인 사용자와 조직 정보
법적으로 또는 업무상 보관이 필요한 이력

별도 보관을 검토할 데이터

장기간 사용하지 않은 거래처
단종된 상품
종료된 과거 주문과 출고 이력
중복되거나 잘못 등록된 데이터
신규 시스템에서 구조가 달라지는 임시 데이터
조회 빈도가 낮은 첨부파일과 로그

과거 데이터 전체를 신규 ERP에 넣지 않고, 기존 시스템을 조회 전용으로 유지하거나 별도의 보관 데이터베이스를 구성하는 방법도 있습니다.

데이터 이전에서는 단순히 행의 개수만 맞추는 것으로 검증을 끝내기 어렵습니다.

다음 항목을 함께 비교해야 합니다.

원본과 이전 결과의 전체 건수
거래처·상품 코드의 중복 여부
필수 항목 누락 여부
날짜와 숫자 형식 변환 결과
현재 재고 수량과 재고 금액
미수금·미지급금과 잔액 합계
미처리 주문의 상태와 수량
첨부파일 연결 여부
사용자와 담당자 매핑 결과

데이터 이전은 원본 분석, 범위 정의, 필드 매핑, 변환, 시험 이전, 결과 검증을 포함하는 별도의 프로젝트 업무로 보는 것이 안전합니다. 공식 구현 지침에서도 데이터 이전 계획에 원본과 대상, 데이터 규모, 이전 방식, 순서와 의존성, 사전·사후 검증을 포함하고 실제 전환 전에 통합 테스트와 사용자 인수 테스트 환경에서 검증하도록 안내합니다. (learn.microsoft.com)

사용자 화면보다 관리자 운영 기능이 더 중요할 수 있습니다

ERP는 운영 담당자가 매일 사용하는 업무 시스템입니다.

따라서 보기 좋은 대시보드만큼 검색, 필터, 일괄 처리, 오류 확인 기능이 중요합니다.

실제 운영에 필요한 관리자 기능

거래처·상품·사용자 기준정보 관리
다양한 조건의 검색과 필터
자주 사용하는 검색 조건 저장
여러 데이터를 선택하는 일괄 변경
엑셀 업로드와 다운로드
승인 대기 업무 모아보기
연동 실패 내역 조회와 재처리
변경 이력과 작업자 기록
공지와 업무 알림
권한과 조직 관리
코드와 상태값 관리
데이터 마감과 잠금 처리

예를 들어 주문 목록은 단순 조회 기능만으로 충분하지 않을 수 있습니다.

운영자는 출고 예정일, 창고, 거래처, 주문 상태, 결제 상태로 데이터를 검색해야 할 수 있습니다. 검색한 주문을 선택해 출고 준비 상태로 일괄 변경하거나, 연동에 실패한 건만 모아 다시 전송해야 할 수도 있습니다.

리포트도 “통계 기능”이라는 한 줄로 정리하면 범위를 판단하기 어렵습니다.

다음 내용을 구체적으로 정리해야 합니다.

어떤 지표를 볼 것인지
어느 기간을 비교할 것인지
실시간 집계가 필요한지
부서·담당자·거래처별 분석이 필요한지
화면 조회만 필요한지
엑셀이나 PDF 출력이 필요한지
집계 결과를 누가 볼 수 있는지
계산 기준이 기존 보고서와 같은지

초기 구축에서는 경영 대시보드 전체보다 실제 운영에 필요한 목록과 보고서를 우선하는 편이 나을 수 있습니다. 데이터가 충분히 쌓인 이후에 필요한 지표가 달라질 가능성도 있기 때문입니다.

업무 중단을 줄이려면 전환 계획이 필요합니다

ERP개발이 완료되었다고 바로 기존 시스템을 종료할 수 있는 것은 아닙니다.

신규 시스템을 실제 업무에 적용하려면 데이터 이전, 사용자 계정 설정, 권한 배정, 연동 전환, 교육, 최종 검증이 필요합니다.

전환 전에 다음 내용을 정해야 합니다.

기존 시스템의 입력을 언제 중단할 것인가?
마지막 데이터는 언제 추출할 것인가?
데이터 이전에 필요한 시간은 얼마나 되는가?
전환 중 발생한 주문은 어디에 기록할 것인가?
연동 대상 시스템의 변경 작업은 누가 담당하는가?
전환 결과를 누가 검증하고 승인하는가?
문제가 발생하면 기존 시스템으로 되돌릴 수 있는가?
전환 직후 문의와 오류는 누가 처리하는가?

전체 전환이 부담스럽다면 특정 부서나 사업장에 먼저 적용하는 방법도 있습니다. 다만 시범 적용 기간에는 기존 시스템과 신규 시스템이 함께 사용될 수 있으므로 중복 입력과 데이터 불일치에 대한 운영 기준을 마련해야 합니다.

운영 적용 전에는 기능별 테스트만이 아니라 통합 테스트, 사용자 인수 테스트, 데이터 이전 검증, 외부 연동 확인, 운영 지원 계획을 함께 준비해야 합니다. 공식 ERP 구현 체크리스트도 시스템 통합 테스트, 사용자 인수 테스트, 데이터 이전 검증, 외부 의존성 확인, 전환 계획과 운영 지원 준비를 주요 출시 조건으로 제시합니다. (learn.microsoft.com)

ERP개발 견적에서는 포함 범위를 같은 기준으로 비교해야 합니다

ERP개발 비용은 메뉴 수만으로 정하기 어렵습니다.

같은 재고관리 기능이라도 단순 입출고 기록만 필요한지, 다중 창고·예약 재고·로트·유통기한·재고 조정 승인까지 필요한지에 따라 범위가 달라집니다.

견적을 비교할 때는 총액보다 다음 항목의 포함 여부를 확인하는 것이 좋습니다.

1. 업무 분석과 기획

현재 업무 인터뷰가 포함되는가?
기존 문서와 엑셀을 분석하는가?
업무 흐름도와 요구사항 문서를 작성하는가?
상태값과 예외 상황을 정의하는가?
사용자별 권한을 설계하는가?

2. UX/UI와 화면 설계

화면 구조와 사용자 흐름 설계가 포함되는가?
디자인 시안 범위는 어디까지인가?
PC 외에 태블릿과 모바일 사용을 고려하는가?
복잡한 입력 업무의 편의성을 검토하는가?

3. ERP 기능 개발

기준정보 관리
영업·견적·주문
구매·입고·재고
승인과 워크플로
관리자 기능
리포트와 데이터 출력

필요한 모듈이 무엇인지 구분해 확인해야 합니다.

4. 기존 시스템 연동

API 분석 비용이 포함되는가?
연동 대상 회사와의 기술 협의는 누가 담당하는가?
실시간·배치 연동 범위가 구분되어 있는가?
실패 재처리와 로그 관리가 포함되는가?
외부 서비스 이용료가 별도로 발생하는가?

5. 데이터 이전

원본 데이터 분석이 포함되는가?
데이터 정제는 누가 담당하는가?
시험 이전을 몇 차례 진행하는가?
첨부파일도 이전하는가?
이전 결과 검증과 오류 수정이 포함되는가?

6. 테스트와 배포

기능 테스트만 포함되는가?
시스템 간 통합 테스트도 진행하는가?
사용자 인수 테스트를 지원하는가?
운영 서버 구성과 배포가 포함되는가?
백업, 모니터링, 로그 설정이 포함되는가?

7. 교육과 인수인계

관리자와 실무자 교육이 포함되는가?
운영 매뉴얼을 제공하는가?
소스 코드와 서버 계정은 누구에게 귀속되는가?
외부 API와 클라우드 계정은 누구 명의로 개설하는가?

8. 유지보수

하자 수정 기간과 범위는 무엇인가?
운영 중 문의는 어떤 방식으로 접수하는가?
기능 추가는 별도 견적인가?
외부 시스템 변경에 따른 수정은 어떻게 처리하는가?
장애 대응 시간과 책임 범위가 정해져 있는가?

두 개발사의 견적 금액이 달라도 한쪽에는 업무 분석, 데이터 이전, 배포와 교육이 포함되어 있고 다른 쪽에는 개발만 포함되어 있을 수 있습니다. 따라서 동일한 기능명보다 전체 책임 범위를 맞춰 비교해야 합니다.

원소프트가 ERP개발 범위를 검토하는 관점

원소프트는 ERP개발 문의에서 요구사항을 그대로 화면 목록으로 옮기기보다 현재 업무가 어떻게 진행되고 있는지부터 확인합니다.

사용 중인 회계·영업·재고 시스템
부서별로 사용하는 엑셀과 문서
반복 입력되는 데이터
사용자 유형과 조직별 권한
승인과 반려 절차
주문·입고·출고·정산의 상태 변화
외부 API와 기존 시스템 연동 가능 여부
관리자 화면에서 처리해야 하는 업무
1차 구축과 이후 확장 범위

원소프트는 웹·앱·관리자 시스템 개발과 외부 API 연동을 통합적으로 수행하며, 사용자 화면뿐 아니라 백엔드, 데이터베이스, 권한, 관리자 운영 흐름을 함께 설계합니다. 모든 프로젝트에 같은 기술 구성을 적용하지 않고 기존 시스템, 운영 환경, 필요한 연동과 확장성을 기준으로 개발 구조를 검토합니다.

부동산 경매 업무 통합 플랫폼인 바토너 프로젝트에서는 고객, 전문가, 운영자 등 사용자 역할을 구분하고, 입찰 신청부터 계약 문서, 결제, 포인트, 정산, 알림과 문의까지 이어지는 업무 상태를 백엔드와 관리자 기능으로 연결했습니다.

이 프로젝트를 일반적인 ERP 구축 사례라고 표현할 수는 없지만, 여러 사용자 역할과 복잡한 상태, 결제·정산 데이터, OCR 문서 처리, 관리자 운영 기능을 하나의 업무 흐름으로 설계했다는 점은 업무형 시스템을 검토할 때 연결할 수 있는 경험입니다.

개발사에 문의하기 전에 준비하면 좋은 자료

완성된 요구사항 정의서를 만들 필요는 없습니다.

현재 업무를 이해할 수 있는 실제 자료가 더 도움이 될 수 있습니다.

현재 사용 중인 자료

업무에 사용하는 엑셀 파일
견적서, 주문서, 발주서 양식
업무 매뉴얼
조직도와 결재 규정
기존 시스템 화면 캡처
부서별 업무 보고서
사용 중인 프로그램과 외부 서비스 목록
API 문서 또는 연동 가능 여부

업무 흐름 자료

업무가 시작되는 조건
단계별 담당자
입력하고 확인하는 데이터
승인과 반려 조건
자주 발생하는 예외 상황
업무 종료 기준
다른 부서로 전달하는 정보

1차 구축 범위

지금 가장 많은 시간이 드는 업무
오류와 누락이 자주 발생하는 업무
중복 입력이 많은 데이터
기존 시스템에서 반드시 유지할 기능
새 ERP에서 먼저 개발할 기능
이후 단계에서 추가할 기능

ERP개발 외주 문의 전 체크리스트

아래 항목에 답할 수 있다면 개발사와의 첫 상담에서 범위를 훨씬 구체적으로 검토할 수 있습니다.

[ ] ERP개발로 해결하려는 업무 문제가 정리되어 있는가?
[ ] 기존 패키지 설정이나 추가 모듈로 해결할 수 있는지 확인했는가?
[ ] 현재 사용 중인 회계·영업·재고·인사 시스템을 정리했는가?
[ ] 부서별 업무 흐름과 담당자를 설명할 수 있는가?
[ ] 거래처·상품·창고 등 기준정보의 관리 시스템을 알고 있는가?
[ ] 시스템별로 연동할 데이터와 방향을 정리했는가?
[ ] 사용자 유형과 조회·등록·승인 권한을 구분했는가?
[ ] 업무 상태와 승인·반려 절차를 정리했는가?
[ ] 이전할 데이터와 조회용으로 보관할 데이터를 구분했는가?
[ ] 1차 구축에서 반드시 필요한 업무를 선정했는가?
[ ] 전면 전환과 단계적 적용 중 어느 방식이 적합한지 검토했는가?
[ ] 기획·연동·데이터 이전·테스트·배포가 견적에 포함되는지 확인했는가?
[ ] 운영 이후 유지보수와 계정·소스 코드 인수인계 조건을 확인했는가?

ERP개발은 여러 메뉴를 한곳에 모으는 작업만으로 끝나지 않습니다.

기존 업무와 시스템을 분석하고, 데이터의 기준을 정하며, 사용자별 권한과 승인 절차를 실제 운영 방식에 맞게 연결하는 과정입니다. 모든 기능을 한 번에 교체하는 것이 부담스럽다면 현재 운영을 유지하면서 반복 작업이 많거나 오류가 자주 발생하는 영역부터 단계적으로 구축할 수도 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치한 웹·앱·관리자 시스템 개발사입니다. ERP개발이나 기존 시스템 연동을 검토하고 계신다면 현재 사용 중인 프로그램과 업무 자료를 바탕으로 유지할 영역, 연동할 영역, 우선 개발할 영역을 함께 정리해드릴 수 있습니다.

제목 후보

ERP개발 외주 문의 전, 기존 시스템 연동과 단계적 구축 범위를 정하는 방법
ERP개발, 회계·재고·영업 시스템을 모두 다시 만들어야 할까요?
ERP개발 견적 전 확인할 기존 시스템 연동과 데이터 이전 기준
맞춤 ERP개발, 전면 재구축보다 업무별 우선순위를 먼저 정하세요
ERP개발 외주, 기존 업무를 유지하면서 단계적으로 구축하는 실무 기준

메인 키워드

ERP개발

서브 키워드

ERP개발 외주
맞춤형 ERP개발
ERP 시스템 연동
ERP 데이터 이전
ERP 구축 범위

썸네일 문구

ERP, 전부 새로 만들어야 할까?
기존 시스템 연동부터 확인하세요
업무를 멈추지 않는 단계적 ERP 구축

글 요약

ERP개발은 회계·영업·재고 기능을 모두 새로 만드는 작업보다 현재 사용하는 시스템과 기준정보, 업무 흐름을 먼저 파악하는 과정이 중요합니다. 기존 시스템의 유지·연동·대체 범위를 구분하고 권한, 승인, 데이터 이전, 관리자 운영 기능을 단계별로 설계하는 방법과 외주 견적 확인 기준을 정리했습니다.

CTA 후보

현재 사용하는 회계·영업·재고 시스템과 반복 업무를 알려주시면 유지할 기능과 연동할 기능, 우선 개발할 범위를 함께 검토해드릴 수 있습니다.

완성된 요구사항 문서가 없어도 괜찮습니다. 사용 중인 엑셀과 업무 양식, 기존 시스템 화면을 기준으로 1차 ERP개발 범위를 정리할 수 있습니다.

다음에 작성하면 좋은 연관 글

ERP 데이터 이전, 거래처·상품·재고 정보를 옮기기 전 확인할 기준
ERP 연동 개발, 회계·영업·재고 중 어느 시스템을 기준으로 정해야 할까?
맞춤형 ERP 관리자 화면, 권한·승인·변경 이력을 설계하는 방법