ERP개발, 기존 업무를 멈추지 않고 단계적으로 구축하는 실무 기준

“현재 사용 중인 회계 프로그램은 그대로 두고 영업과 재고 관리부터 바꿀 수 있을까요?”

“엑셀로 관리하는 업무가 많지만, 한 번에 전부 ERP로 옮기면 현장이 혼란스러울 것 같습니다.”

“패키지 ERP를 도입해야 할지, 우리 회사에 맞게 새로 개발해야 할지 판단하기 어렵습니다.”

ERP개발을 검토하는 기업에서 자주 나오는 고민입니다.

ERP는 여러 부서의 업무와 데이터를 연결하는 시스템입니다. 그래서 새로운 화면을 만드는 것보다 현재 업무를 어디까지 유지하고, 무엇을 바꾸며, 어떤 시스템을 연결할지 결정하는 과정이 더 중요합니다.

특히 이미 회계·영업·재고·생산·그룹웨어 등의 시스템을 사용하고 있다면 모든 기능을 한 번에 교체하는 방식이 항상 적합한 것은 아닙니다. 운영 중인 업무를 멈추기 어렵고, 기존 데이터의 구조도 바로 파악하기 힘들 수 있기 때문입니다.

이럴 때는 현재 업무를 다음 세 가지로 나누어 보는 것이 좋습니다.

패키지나 공통 기능으로 처리할 수 있는 표준 업무
회사의 운영 규칙에 맞춰 별도로 구현해야 하는 맞춤 업무
기존 회계·영업·재고 시스템과 데이터를 주고받아야 하는 연동 업무

이 구분이 되어야 패키지 도입, 맞춤 ERP개발, 기존 시스템 연동 중 어떤 방식을 선택할지 판단할 수 있습니다. 개발 범위와 견적도 같은 기준으로 비교할 수 있습니다.

ERP개발이 필요한 시점부터 확인해야 합니다

ERP라는 이름이 붙었다고 해서 모든 기업에 대규모 맞춤 개발이 필요한 것은 아닙니다.

회계 처리, 직원 정보 관리, 일반적인 발주와 입고처럼 이미 표준화된 업무가 대부분이라면 기존 ERP 패키지나 SaaS를 활용하는 편이 더 적합할 수 있습니다.

반면 다음과 같은 상황이라면 맞춤 개발이나 기존 시스템과의 연동을 검토할 수 있습니다.

같은 정보를 여러 엑셀 파일에 반복해서 입력하고 있다.
영업팀, 물류팀, 회계팀이 서로 다른 기준으로 데이터를 관리한다.
담당자가 메신저나 이메일로 승인받은 뒤 결과를 다시 시스템에 입력한다.
거래처별 가격과 결제 조건이 달라 표준 프로그램으로 관리하기 어렵다.
주문, 생산, 출고, 정산의 진행 상태를 한곳에서 확인하기 어렵다.
기존 회계 프로그램은 유지해야 하지만 다른 업무 시스템과 연결되지 않는다.
일부 담당자만 전체 업무 흐름을 알고 있어 인수인계가 어렵다.
업무량이 늘어날수록 입력 누락과 중복 처리도 함께 늘어난다.
운영 현황을 확인하려면 여러 파일과 시스템의 데이터를 다시 취합해야 한다.

이러한 문제가 있다고 해서 곧바로 전체 ERP를 새로 개발해야 하는 것은 아닙니다.

예를 들어 기존 회계 시스템이 안정적으로 사용되고 있다면 회계 기능까지 다시 만드는 것보다 주문·재고·승인 시스템을 별도로 구축하고 필요한 회계 데이터를 연동하는 방법이 현실적일 수 있습니다.

반대로 기존 시스템의 데이터 구조를 파악하기 어렵고 업무 규칙이 여러 프로그램과 엑셀에 중복되어 있다면 부분 연동만으로는 문제를 해결하기 어려울 수 있습니다. 이 경우에는 핵심 데이터와 업무 흐름을 다시 정의한 뒤 단계적으로 재구축하는 방향을 검토해야 합니다.

ERP개발 여부를 결정할 때는 “어떤 프로그램을 만들 것인가”보다 다음 질문을 먼저 확인해야 합니다.

현재 가장 많은 시간이 드는 반복 업무는 무엇인가?
입력 오류가 발생하면 어느 부서까지 영향을 받는가?
기존 시스템 중 반드시 유지해야 하는 것은 무엇인가?
표준 절차로 바꿔도 되는 업무와 회사 고유의 업무는 무엇인가?
시스템이 바뀌는 동안에도 계속 처리되어야 하는 핵심 업무는 무엇인가?

이 질문에 대한 답이 ERP 구축 방식의 출발점이 됩니다.

첫 번째 구분: 표준 기능으로 처리할 업무

표준 기능은 많은 기업에서 비슷한 방식으로 사용하는 업무입니다.

대표적으로 다음과 같은 기능을 생각할 수 있습니다.

거래처 등록과 관리
상품·품목 등록
부서와 사용자 관리
일반적인 견적·수주·발주 등록
입고와 출고 처리
기본적인 재고 조회
매출·매입 내역 관리
공통 코드와 기초 설정
기본 보고서와 엑셀 다운로드

이러한 기능은 회사마다 명칭은 다르더라도 기본 구조가 비슷할 수 있습니다. 기존 패키지 ERP가 제공하는 기능으로 충분하다면 별도로 개발하지 않는 편이 비용과 운영 부담을 줄이는 데 도움이 됩니다.

다만 기능의 이름이 같다고 실제 업무도 같은 것은 아닙니다.

예를 들어 ‘발주 관리’라는 기능이 있어도 기업마다 다음 조건이 다를 수 있습니다.

누가 발주를 등록할 수 있는가?
일정 금액 이상이면 추가 승인이 필요한가?
발주 수량이 재고나 판매 계획과 연결되는가?
거래처별 최소 주문 수량이 있는가?
일부 품목은 별도의 검토가 필요한가?
승인 후 발주서를 자동으로 발송해야 하는가?
입고 수량이 발주 수량과 다를 때 어떻게 처리하는가?

따라서 표준 기능을 검토할 때는 메뉴 이름만 비교하면 부족합니다.

실제 업무 시나리오를 기준으로 패키지가 어느 범위까지 지원하는지 확인해야 합니다. 설정만으로 처리할 수 있는지, 별도 확장이 필요한지, 수작업을 일부 유지해야 하는지도 함께 살펴봐야 합니다.

표준 기능을 억지로 맞춤 개발하면 개발 범위가 불필요하게 커질 수 있습니다. 반대로 회사 고유의 업무를 표준 기능에 무리하게 맞추면 현장에서 다시 엑셀이나 메신저를 사용하게 될 수 있습니다.

두 번째 구분: 회사 고유의 맞춤 업무

맞춤 업무는 경쟁력이나 운영 방식과 직접 연결된 회사만의 규칙입니다.

예를 들면 다음과 같습니다.

거래처 등급에 따라 상품과 가격이 달라지는 구조
프로젝트별 원가와 투입 인력을 함께 관리하는 업무
여러 부서가 순차적으로 검토하는 승인 절차
주문 내용을 기준으로 제작 사양을 확정하는 업무
재고가 아닌 생산 가능 수량을 기준으로 납기를 계산하는 구조
계약 조건에 따라 청구와 정산 시점이 달라지는 업무
한 주문이 여러 창고와 출고지로 분리되는 처리 방식
품질 검사 결과에 따라 출고 가능 여부가 결정되는 업무
고객사별 별도 양식으로 문서를 만들어야 하는 업무

이러한 업무는 패키지의 기본 설정만으로 처리하기 어려울 수 있습니다.

하지만 현재 하고 있는 업무를 그대로 화면으로 옮기는 것만으로는 충분하지 않습니다. 기존 업무에 불필요한 중복 입력이나 과거 방식이 포함되어 있을 수도 있기 때문입니다.

맞춤 ERP개발을 진행할 때는 업무를 다음 순서로 분해해보는 것이 좋습니다.

누가 업무를 시작하는가?
어떤 데이터를 입력하는가?
입력값은 어디에서 가져오는가?
누가 내용을 확인하거나 승인하는가?
승인·반려·취소 시 어떤 상태로 바뀌는가?
다음 담당자에게 무엇이 전달되는가?
결과 데이터는 어느 시스템에 저장되는가?
오류가 발생하면 누가 어떻게 수정하는가?

예를 들어 견적 승인 업무를 만든다고 가정해보겠습니다.

단순히 ‘견적 등록’, ‘승인’ 버튼만 구현하면 실제 운영 과정에서 여러 질문이 발생합니다.

영업 담당자가 할인율을 자유롭게 입력할 수 있는가?
일정 할인율을 넘으면 팀장 승인이 필요한가?
금액에 따라 승인자가 달라지는가?
승인 대기 중인 견적을 수정할 수 있는가?
수정하면 기존 승인 결과를 유지할 것인가?
반려된 견적은 누가 다시 제출할 수 있는가?
승인 후 발주로 전환되면 견적을 수정할 수 있는가?
승인 이력과 변경 전 금액도 확인해야 하는가?

이와 같은 규칙이 ERP의 실제 개발 범위를 결정합니다.

맞춤 업무를 정리할 때는 화면 개수보다 업무 규칙과 예외 상황의 수를 확인해야 합니다. 같은 화면이라도 권한, 승인 조건, 상태 변화, 변경 이력이 복잡하면 개발과 테스트 범위가 달라집니다.

세 번째 구분: 기존 시스템과 연동할 업무

ERP를 구축한다고 해서 현재 사용하는 모든 시스템을 없앨 필요는 없습니다.

회계 프로그램은 회계팀이 계속 사용하고, 영업·재고·주문 업무만 새롭게 구축할 수도 있습니다. 기존 생산관리 시스템이나 쇼핑몰, 그룹웨어, 물류 시스템을 유지하면서 필요한 데이터만 ERP와 연결하는 방식도 가능합니다.

중요한 것은 단순히 “연동이 가능한가”가 아닙니다.

다음과 같은 데이터 흐름을 구체적으로 정해야 합니다.

| 확인 항목 | 검토할 내용 | |---|---| | 기준 시스템 | 어느 시스템의 데이터를 원본으로 볼 것인가 | | 연동 대상 | 거래처, 품목, 주문, 재고, 매출, 입금 등 무엇을 전달할 것인가 | | 데이터 방향 | 한쪽 전달인지, 양방향 동기화인지 | | 처리 시점 | 실시간, 일정 주기, 담당자 실행 중 어떤 방식인지 | | 식별 기준 | 두 시스템의 거래처·품목·주문을 어떤 값으로 연결할 것인지 | | 상태 매핑 | 각 시스템의 상태값을 어떻게 대응시킬 것인지 | | 실패 처리 | 오류 발생 시 자동 재시도할지, 운영자가 확인할지 | | 변경 처리 | 이미 전송한 데이터가 수정·취소되면 어떻게 반영할지 | | 이력 관리 | 누가 언제 어떤 데이터를 전송했는지 기록할지 |

예를 들어 새 ERP에서 주문을 등록하고 기존 회계 프로그램으로 매출 데이터를 전달하는 구조를 생각해보겠습니다.

이 경우에도 여러 예외 상황이 생길 수 있습니다.

ERP에는 거래처가 있지만 회계 시스템에는 없는 경우
두 시스템의 거래처 코드가 서로 다른 경우
품목의 세금 구분이나 단위가 다른 경우
주문 일부만 출고되어 매출이 분할되는 경우
전송 직후 회계 시스템이 응답하지 않는 경우
동일한 매출 데이터가 두 번 전송되는 경우
전송 완료 후 ERP에서 주문이 취소되는 경우
일부 항목만 성공하고 나머지는 실패한 경우

운영 가능한 연동을 만들려면 이러한 상황을 개발 범위에 포함해야 합니다.

Microsoft의 공식 구현 가이드에서도 외부 시스템 연동은 운영 전 통합 테스트를 거쳐야 하며, 실제 운영 부하에 가까운 조건에서 연동 성능을 확인하고 모니터링과 지원 체계를 준비하도록 안내합니다. (learn.microsoft.com)

SAP의 공식 통합 자료에서도 시스템 간 데이터 전달뿐 아니라 연동 메시지의 상태를 모니터링하고 오류를 처리하는 운영 기능을 별도로 다룹니다. 즉, ERP 연동은 데이터를 보내는 기능만이 아니라 실패 건을 찾고 복구할 수 있는 구조까지 포함해야 합니다. (help.sap.com)

기준정보를 먼저 정리해야 하는 이유

ERP 화면을 설계하기 전에 거래처, 품목, 창고, 조직, 사용자처럼 여러 업무에서 공통으로 사용하는 기준정보를 정리해야 합니다.

기준정보가 불명확하면 각 부서가 같은 대상을 서로 다른 이름과 코드로 관리하게 됩니다.

예를 들어 한 거래처가 다음과 같이 등록되어 있을 수 있습니다.

영업팀 엑셀: 원소프트
회계 프로그램: 원소프트 주식회사
물류 시스템: 원소프트_동탄
담당자 개인 파일: OS001

사람은 같은 거래처라는 사실을 알 수 있지만 시스템은 별개의 데이터로 판단할 수 있습니다.

품목도 마찬가지입니다.

같은 상품을 낱개, 박스, 세트 단위로 관리하거나 영업팀과 창고에서 다른 코드를 사용한다면 재고와 매출 데이터를 연결하기 어렵습니다.

ERP개발 전에 정리할 주요 기준정보는 다음과 같습니다.

거래처 코드와 거래처 유형
사업자 정보와 정산 조건
품목 코드와 품목 분류
옵션·규격·단위
창고와 재고 위치
부서와 조직 구조
사용자와 담당 업무
세금·통화·결제 조건
공통 코드와 상태값
시스템 간 연결에 사용할 식별자

Microsoft의 데이터 관리 가이드도 환경 설정에 필요한 구성 데이터와 기존 시스템에서 이전할 데이터를 구분합니다. 고객·상품·공급업체 같은 마스터 데이터와 미처리 주문·재고·잔액 같은 진행 중 거래 데이터는 성격이 다르기 때문에 각각 이전 범위와 순서를 계획해야 한다고 설명합니다. (learn.microsoft.com)

기준정보를 정리한다는 것은 오래된 엑셀의 모든 값을 그대로 옮기는 작업이 아닙니다.

다음 항목을 함께 판단해야 합니다.

중복 데이터를 어떤 기준으로 합칠 것인가?
사용하지 않는 거래처와 품목도 이전할 것인가?
과거 코드와 신규 코드를 어떻게 연결할 것인가?
누락된 필수값은 누가 보완할 것인가?
시스템마다 다른 분류 기준을 어떻게 통합할 것인가?
ERP 도입 후 기준정보를 누가 생성하고 수정할 것인가?

이 과정이 빠지면 개발이 완료된 후에도 데이터가 맞지 않아 부서별 엑셀을 계속 사용하게 될 수 있습니다.

사용자 권한은 메뉴 접근보다 업무 책임을 기준으로 나눠야 합니다

ERP에는 영업, 구매, 물류, 회계, 관리자 등 여러 사용자가 접속합니다.

권한을 ‘관리자’와 ‘일반 사용자’ 두 종류로만 나누면 실제 조직의 업무를 반영하기 어렵습니다.

예를 들어 영업 담당자에게는 다음과 같이 세분된 권한이 필요할 수 있습니다.

본인이 담당하는 거래처만 조회
본인이 작성한 견적만 수정
승인 완료 전까지 주문 내용 수정
일정 할인율 이하에서만 가격 변경
원가 정보는 조회 불가
엑셀 다운로드 제한
개인정보 일부 마스킹
삭제는 불가능하고 취소 요청만 가능

구매 담당자는 발주를 등록할 수 있지만 공급업체의 계좌 정보는 수정하지 못하게 할 수도 있습니다. 팀장은 담당 팀의 데이터만 승인하고, 본부장은 일정 금액 이상의 건만 최종 승인하도록 구성할 수도 있습니다.

NIST의 보안 통제 지침에서는 사용자가 맡은 업무를 수행하는 데 필요한 범위로 권한을 제한하는 최소 권한 원칙과 역할 분리를 다룹니다. ERP처럼 여러 부서와 민감한 업무 데이터가 모이는 시스템에서는 사용자 역할과 데이터 범위를 함께 설계하는 것이 필요합니다. (csrc.nist.gov)

권한은 다음 세 단계로 구분해 정리하면 이해하기 쉽습니다.

1. 메뉴 권한

어떤 메뉴에 접근할 수 있는지를 정합니다.

예를 들어 영업 담당자는 주문 관리에 접근할 수 있지만 급여 관리에는 접근하지 못하도록 설정할 수 있습니다.

2. 기능 권한

메뉴 안에서 조회, 등록, 수정, 삭제, 승인, 다운로드 중 어떤 작업을 할 수 있는지 정합니다.

같은 주문 메뉴를 사용하더라도 담당자는 등록과 수정만 하고 팀장은 승인까지 할 수 있습니다.

3. 데이터 권한

같은 기능을 사용하더라도 어느 범위의 데이터를 볼 수 있는지 정합니다.

본인 데이터만 조회
소속 팀 데이터 조회
특정 사업부 데이터 조회
특정 거래처 데이터 조회
전체 데이터 조회

이 세 가지를 분리해야 실제 업무와 맞는 권한 구조를 만들 수 있습니다.

권한 변경과 주요 업무 처리 내역도 기록할 필요가 있습니다. OWASP는 애플리케이션 로그가 접근 통제 문제의 조사와 보안 감사, 장애 원인 확인에 활용될 수 있다고 안내합니다. 다만 민감 정보를 불필요하게 기록하지 않도록 로그 범위도 함께 설계해야 합니다. (cheatsheetseries.owasp.org)

승인 절차와 상태값을 ERP 범위에 포함해야 합니다

ERP개발에서 빠지기 쉬운 항목 중 하나가 상태값입니다.

화면 목록에는 ‘견적 관리’, ‘발주 관리’, ‘출고 관리’만 적혀 있어도 실제 시스템에서는 각 업무의 진행 단계를 구분해야 합니다.

예를 들어 주문은 다음과 같이 나뉠 수 있습니다.

임시 저장
승인 요청
승인 대기
승인 완료
출고 준비
일부 출고
출고 완료
취소 요청
취소 완료
보류

승인 상태와 업무 상태를 하나로 관리하면 규칙이 복잡해질 수 있습니다.

‘승인 완료’는 내부 검토 결과를 뜻하지만 ‘출고 완료’는 물류 업무의 진행 결과입니다. 서로 다른 목적의 상태는 분리해서 관리하는 편이 변경과 오류를 추적하기 쉽습니다.

승인 절차를 설계할 때는 다음 질문을 확인해야 합니다.

어떤 업무에 승인이 필요한가?
금액이나 품목에 따라 승인자가 달라지는가?
승인자가 부재중이면 대체 승인자가 필요한가?
반려할 때 사유를 필수로 입력해야 하는가?
승인 대기 중인 데이터를 수정할 수 있는가?
수정하면 다시 승인을 받아야 하는가?
긴급 처리나 승인 생략 조건이 있는가?
승인 완료 후 취소하려면 별도 승인이 필요한가?
누가 언제 승인했는지 이력을 남겨야 하는가?

이러한 기준은 단순한 부가 기능이 아니라 업무 책임과 데이터의 신뢰성을 결정하는 요소입니다.

기존 데이터를 옮길 때는 ‘전체 이전’보다 ‘사용 목적’을 먼저 봐야 합니다

오래된 ERP나 엑셀 데이터를 새 시스템으로 옮길 때 모든 데이터를 그대로 이전하려는 경우가 많습니다.

하지만 과거 데이터에는 다음과 같은 문제가 포함될 수 있습니다.

같은 거래처가 여러 번 등록되어 있다.
사용하지 않는 품목이 남아 있다.
필수값이 비어 있다.
날짜와 금액 형식이 일정하지 않다.
담당자가 퇴사해 데이터의 의미를 확인하기 어렵다.
엑셀마다 상태값의 표현이 다르다.
현재 업무에서는 사용하지 않는 열이 많다.

데이터 이전 범위는 다음과 같이 나눠볼 수 있습니다.

반드시 이전해야 하는 데이터

현재 거래 중인 거래처
사용 중인 품목과 가격 정보
현재 재고
진행 중인 주문과 발주
미수금·미지급금 등 운영에 필요한 잔액
ERP 공개 후에도 이어서 처리해야 하는 업무

필요에 따라 이전할 데이터

최근 일정 기간의 거래 내역
유지보수나 고객 응대에 필요한 과거 이력
법적·내부 보관 기준에 필요한 자료
통계와 비교 분석에 사용할 데이터

별도 보관을 검토할 데이터

현재 사용하지 않는 오래된 기준정보
중복되거나 의미가 불분명한 데이터
조회 빈도가 낮은 과거 상세 이력
새로운 ERP의 구조와 맞지 않는 데이터

모든 데이터를 신규 ERP에 적재하지 않고 기존 시스템을 조회 전용으로 남기거나 별도 보관 데이터베이스를 두는 방법도 검토할 수 있습니다.

중요한 것은 “몇 년 치 데이터를 옮길 것인가”만 정하는 것이 아닙니다.

어떤 업무를 위해 필요한가?
신규 데이터 구조로 변환할 수 있는가?
이전 결과를 누가 검수할 것인가?
원본 합계와 이전 후 합계를 어떻게 비교할 것인가?
이전 실패 데이터는 어떻게 확인할 것인가?

이 기준까지 정해야 데이터 이전의 완료 조건을 판단할 수 있습니다.

공식 Dynamics 365 구현 가이드에서도 데이터 이전은 원본과 대상 시스템, 이전 대상과 방향, 전체·증분 방식, 빈도, 처리 순서, 담당 역할, 전환 전후 작업을 포함한 전략으로 계획하도록 안내합니다. 또한 시스템 통합 테스트와 사용자 인수 테스트 환경에서 데이터 이전을 미리 실행하고 검증할 것을 권고합니다. (learn.microsoft.com)

업무를 중단하지 않으려면 단계적 전환 계획이 필요합니다

ERP를 한 번에 전환하면 새로운 시스템을 빠르게 적용할 수 있지만, 여러 부서와 시스템이 연결된 환경에서는 위험도 함께 커질 수 있습니다.

단계적 구축은 ERP 전체를 작은 메뉴 단위로 잘게 나누는 것이 아닙니다. 하나의 업무가 실제로 완료될 수 있는 단위로 나누는 것이 중요합니다.

예를 들어 1차 구축 범위를 다음과 같이 구성할 수 있습니다.

거래처와 품목 기준정보
견적 등록과 승인
주문 등록
재고 확인
출고 처리
기본 운영자 화면
기존 회계 시스템으로 매출 데이터 전달
오류 확인과 수동 재처리

이 경우 견적부터 출고와 회계 전달까지 하나의 운영 흐름이 연결됩니다.

반면 견적 입력 화면, 재고 조회 화면, 통계 대시보드처럼 서로 연결되지 않은 기능만 우선 개발하면 실제 업무에는 적용하기 어려울 수 있습니다.

단계적 전환 방식은 다음과 같이 구분할 수 있습니다.

부서별 전환

특정 부서부터 먼저 사용하고 운영 결과를 확인한 뒤 다른 부서로 확대합니다.

부서별 업무가 비교적 독립적일 때 적용하기 좋습니다. 다만 공통 기준정보와 다른 부서로 전달되는 데이터 흐름은 먼저 정리해야 합니다.

업무 영역별 전환

영업, 구매, 재고, 생산, 정산처럼 업무 영역을 나누어 전환합니다.

영업과 재고가 강하게 연결되어 있다면 두 영역을 함께 구축하고, 회계는 기존 시스템과 연동하는 방식으로 시작할 수 있습니다.

사업장·법인별 전환

여러 사업장이나 법인이 비슷한 업무를 수행한다면 한 곳에서 먼저 적용한 뒤 다른 곳으로 확장할 수 있습니다.

이 경우 공통으로 사용할 설정과 사업장별로 달라지는 규칙을 구분해야 합니다.

기존 시스템과 병행 운영

일정 기간 기존 시스템과 새 ERP를 함께 사용하면서 결과를 비교합니다.

다만 같은 데이터를 두 시스템에 반복 입력하면 담당자의 업무가 크게 늘어날 수 있습니다. 병행 기간, 이중 입력 대상, 비교 방법과 종료 조건을 미리 정해야 합니다.

단계적 출시는 앞 단계에서 발견한 문제를 다음 단계에 반영할 수 있다는 장점이 있지만, 단계마다 데이터 이전과 시스템 간 연결을 관리해야 합니다. Microsoft의 구현 가이드 역시 단계별 배포에서는 이후 배포까지 고려해 설정과 데이터 의존성을 관리하고, 각 출시에서 얻은 내용을 다음 계획에 반영하도록 안내합니다. (learn.microsoft.com)

1차 구축과 이후 확장 기능을 나누는 기준

ERP는 부서별 요구사항을 모두 모으면 범위가 빠르게 커질 수 있습니다.

이때 단순히 “있으면 좋은 기능”을 제외하는 방식보다 다음 네 가지 질문으로 우선순위를 판단하는 것이 좋습니다.

1. 이 기능이 없으면 핵심 업무를 완료할 수 없는가?

주문 ERP라면 거래처, 품목, 주문, 승인, 출고와 같은 기능은 핵심 흐름에 포함될 가능성이 높습니다.

반면 고급 통계나 예측 기능은 데이터가 쌓인 이후에 추가해도 될 수 있습니다.

2. 수작업으로 임시 대응할 수 있는가?

사용 빈도가 낮고 담당자가 명확하다면 초기에는 수작업으로 처리한 뒤 운영 데이터를 확인해 자동화할 수 있습니다.

다만 수작업이 데이터 누락이나 금액 오류로 이어질 가능성이 높다면 초기 범위에 포함해야 합니다.

3. 다른 기능의 구조에 영향을 주는가?

권한, 기준정보, 상태값, 데이터 식별자처럼 시스템의 기본 구조에 영향을 주는 항목은 나중에 변경하기 어려울 수 있습니다.

화면에서 보이는 기능은 아니더라도 1차 설계에서 포함해야 합니다.

4. 운영자가 오류를 복구할 수 있는가?

외부 시스템 연동이나 일괄 처리 기능을 넣었다면 성공 기능뿐 아니라 실패 확인과 재처리 기능도 함께 필요할 수 있습니다.

자동화 기능만 만들고 운영자 확인 화면을 이후 단계로 미루면 오류가 발생할 때마다 개발자가 데이터를 직접 확인해야 할 수 있습니다.

1차 구축 범위의 예시는 다음과 같습니다.

핵심 기준정보 관리
필수 업무 등록과 조회
사용자별 권한
업무 상태와 승인
기본 검색과 필터
기존 시스템과 필요한 최소 연동
데이터 이전
주요 변경 이력
오류 확인과 운영자 재처리
배포와 사용자 교육에 필요한 기본 자료

이후 확장 기능으로는 다음 항목을 검토할 수 있습니다.

고급 통계와 경영 대시보드
자동 발주와 재고 예측
모바일 승인
다양한 외부 시스템 추가 연동
반복 업무 자동화
거래처 전용 포털
데이터 분석과 AI 기능
사업장·법인 확대
세부 권한과 결재 규칙 확장

ERP개발 견적이 달라지는 주요 항목

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

다음 항목에 따라 기획, 개발, 테스트와 전환 범위가 달라질 수 있습니다.

업무 영역의 수
사용자와 조직의 유형
권한의 세분화 수준
승인 단계와 조건
상태값과 예외 처리
기준정보의 종류와 관계
기존 시스템의 수와 연동 방식
데이터 이전 대상과 품질
보고서와 문서 출력 양식
엑셀 업로드·다운로드 방식
변경 이력과 감사 기록
모바일 또는 외부 사용자 지원
운영 중단 가능 시간
테스트와 사용자 교육 범위
배포 후 유지보수 조건

예를 들어 ‘회계 시스템 연동’이라고 적혀 있어도 견적 범위는 크게 달라질 수 있습니다.

API가 제공되는지, 파일로 주고받아야 하는지, 실시간 처리가 필요한지, 양방향 동기화인지, 실패 건을 운영자가 다시 처리해야 하는지에 따라 개발 범위가 달라집니다.

따라서 ERP개발 견적서를 비교할 때는 총액보다 포함 범위를 확인해야 합니다.

ERP개발 외주 문의 전 준비하면 좋은 자료

완성된 요구사항 문서가 없어도 괜찮습니다.

다음 자료가 있으면 현재 업무와 개발 범위를 파악하는 데 도움이 됩니다.

현재 업무 흐름

업무가 시작되어 완료되는 순서를 부서별로 적어보면 좋습니다.

예를 들면 다음과 같습니다.

영업 담당자가 견적 등록 → 팀장 승인 → 고객 주문 확정 → 재고 확인 → 부족 수량 구매 요청 → 출고 → 회계 매출 등록

정식 순서도까지 만들 필요는 없습니다. 담당자, 입력 정보, 승인자, 다음 단계가 보이면 됩니다.

현재 사용하는 자료

업무용 엑셀
거래처·품목 목록
견적서와 발주서
보고서 양식
승인 요청 화면
기존 시스템 화면
수기로 작성하는 업무 문서
부서별 관리 파일

실제 데이터에 개인정보나 민감한 계약 정보가 포함되어 있다면 샘플이나 마스킹된 자료로 준비하는 편이 좋습니다.

사용자와 권한

어떤 부서가 사용하는가?
부서별 담당 업무는 무엇인가?
조회와 수정 범위가 다른가?
승인이 필요한 업무는 무엇인가?
외부 거래처나 협력사도 접속하는가?

기존 시스템 정보

현재 사용하는 시스템의 종류
유지할 시스템과 교체할 시스템
API 또는 데이터 내보내기 지원 여부
관리 업체와 계약 상태
데이터베이스 접근 가능 여부
연동에 필요한 기술 문서와 담당자

단계적 구축 우선순위

가장 먼저 개선해야 하는 업무
현재 오류가 자주 발생하는 구간
일정상 반드시 필요한 기능
기존 시스템 계약 종료 시점
병행 운영이 가능한 기간
이후 추가하려는 업무 영역

이 자료가 있으면 개발사도 단순한 화면 목록이 아니라 업무 흐름과 전환 위험을 기준으로 범위를 검토할 수 있습니다.

ERP개발 견적서에서 확인할 항목

견적을 받을 때는 다음 항목이 포함되어 있는지 확인해보세요.

업무 분석과 요구사항 정리 범위
화면 및 기능 설계
사용자·조직·권한 구조
기준정보와 데이터 구조
승인 절차와 상태값
사용자 화면과 관리자 화면
기존 시스템 연동
데이터 이전과 정제 범위
변경 이력과 로그
단위 테스트와 통합 테스트
사용자 인수 테스트 지원
운영 환경 배포
전환 계획과 장애 대응
매뉴얼과 사용자 교육
소스코드와 서버 계정 인수인계
하자 수정과 유지보수 범위
추가 개발 시 산정 기준

특히 데이터 이전과 기존 시스템 연동이 단순히 ‘포함’이라고만 적혀 있다면 세부 범위를 확인해야 합니다.

몇 종류의 데이터를 이전하는가?
중복과 누락 데이터의 정제는 누가 하는가?
이전 결과를 어떤 기준으로 검수하는가?
연동 실패 시 재처리 기능이 포함되는가?
외부 시스템의 테스트 환경을 사용할 수 있는가?
운영 전환 시 어떤 순서로 배포하는가?
문제 발생 시 기존 방식으로 돌아갈 수 있는가?

ERP 공개 전에는 기능 테스트만이 아니라 실제 업무 담당자가 사용하는 데이터와 시나리오로 검수할 필요가 있습니다. 공식 구현 지침에서도 시스템 통합 테스트, 사용자 인수 테스트, 데이터 이전 검증, 외부 의존성 확인, 운영 지원 계획과 전환 절차를 공개 준비 항목으로 제시합니다. (learn.microsoft.com)

ERP 구축의 출발점은 프로그램이 아니라 업무 구분입니다

ERP개발은 기존 업무를 모두 새 시스템으로 옮기는 프로젝트가 아닐 수 있습니다.

현재 업무 중 표준 기능으로 처리할 부분, 회사 고유의 규칙에 맞춰 개발할 부분, 기존 시스템과 연동할 부분을 구분해야 합니다. 그다음 기준정보, 권한, 승인 절차, 상태값, 데이터 이전과 오류 대응 범위를 연결해야 합니다.

업무 중단을 줄이려면 전체 기능을 한 번에 공개하기보다 실제로 완료할 수 있는 핵심 업무 단위부터 구축하는 방법을 검토할 수 있습니다.

이 과정에서 중요한 것은 기능을 무조건 줄이는 것이 아닙니다. 1차 구축에 필요한 운영 기능과 오류 복구 기능은 포함하고, 데이터가 쌓인 후 판단해도 되는 통계·자동화 기능은 이후 단계로 분리하는 것입니다.

원소프트는 웹·앱·관리자 시스템과 외부 API·ERP 연동을 함께 검토하며, 사용자 화면뿐 아니라 운영자의 업무 흐름과 데이터 구조까지 포함해 개발 범위를 정리합니다.

현재 사용 중인 ERP나 엑셀 업무를 어디까지 유지해야 할지, 맞춤 개발과 연동 범위를 어떻게 나누어야 할지 고민하고 있다면 현재 업무 자료를 바탕으로 단계별 구축 범위를 검토할 수 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치한 개발사입니다. 화성·동탄을 비롯해 경기 남부 지역에서 ERP개발이나 업무 시스템 구축을 검토하고 계신 경우에도 현재 운영 방식과 필요한 기능을 기준으로 상담을 진행할 수 있습니다.

제목 후보

ERP개발, 기존 업무를 멈추지 않고 단계적으로 구축하는 방법
ERP개발 외주 전, 표준 기능·맞춤 업무·기존 시스템 연동을 나누는 기준
ERP개발 범위, 패키지·맞춤 개발·시스템 연동을 구분하는 실무 기준
ERP개발 견적 비교 전, 데이터 이전과 단계적 전환 범위를 확인하세요
맞춤형 ERP개발, 기존 회계·영업·재고 시스템을 유지하며 구축하는 방법

메인 키워드

ERP개발

서브 키워드

ERP개발 외주
맞춤형 ERP개발
ERP 시스템 구축
ERP 연동 개발
ERP개발 견적

썸네일 문구

업무를 멈추지 않는 ERP 구축
표준·맞춤·연동 범위 나누기
ERP 단계적 구축 실무 기준

글 요약

ERP개발은 패키지와 맞춤 개발 중 하나를 바로 선택하기보다 현재 업무를 표준 기능, 회사 고유의 맞춤 업무, 기존 시스템 연동으로 나누는 것에서 시작해야 합니다. 기준정보·권한·승인·상태값·데이터 이전과 오류 대응을 함께 정리하고, 핵심 업무가 실제로 완료되는 단위부터 단계적으로 전환하는 방법을 설명했습니다.

CTA 후보

현재 사용 중인 ERP, 엑셀과 부서별 업무 자료가 있다면 유지할 기능과 새로 구축할 기능, 연동할 기능을 구분해 단계별 개발 범위를 함께 검토할 수 있습니다.

패키지 도입과 맞춤 ERP개발 사이에서 판단이 어렵다면 현재 업무 흐름과 기존 시스템을 기준으로 1차 구축 범위와 이후 확장 기능을 정리해보세요. 원소프트가 요구사항 검토를 도와드릴 수 있습니다.

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

ERP 연동 개발, 회계·영업·재고 데이터의 기준 시스템을 정하는 방법
ERP 데이터 이전, 엑셀과 기존 시스템 자료를 정리하는 실무 체크리스트
맞춤형 ERP개발 견적, 권한·승인·데이터 이전에서 차이가 나는 이유