ERP 개발, 패키지 도입·맞춤 개발·기존 시스템 연동을 결정하는 기준

매출이 늘고 거래처와 품목이 많아졌는데도 주문은 쇼핑몰 관리자에서 확인하고, 재고는 별도 엑셀로 관리하고, 정산 자료는 다시 회계 프로그램에 입력하는 기업이 있습니다.

처음에는 각 도구가 제 역할을 하는 것처럼 보입니다. 하지만 업무량이 늘어나면 같은 데이터를 여러 번 입력하게 되고, 담당자마다 숫자가 다르며, 승인 상태를 메신저에서 확인해야 하는 문제가 생깁니다.

이때 ERP 개발이나 도입을 검토하게 됩니다.

다만 ERP를 검토한다고 해서 반드시 모든 업무를 새로 개발해야 하는 것은 아닙니다. 기존 패키지 ERP를 도입하는 방법도 있고, 회사 업무에 맞는 시스템을 개발하는 방법도 있으며, 이미 사용 중인 회계·쇼핑몰·물류 시스템을 유지하면서 필요한 부분만 연결하는 방법도 있습니다.

중요한 것은 어떤 방식이 더 고급인지가 아닙니다.

회사의 업무가 어느 정도 표준화되어 있는지, 반드시 유지해야 하는 고유한 업무 규칙이 무엇인지, 현재 시스템 중 계속 사용할 것은 무엇인지에 따라 적합한 방식이 달라집니다.

ERP 개발을 검토할 때는 기능 목록부터 만들기보다 현재 업무가 어떤 순서로 진행되고, 어떤 데이터가 생성되며, 누가 확인하고 승인하는지부터 정리해야 합니다.

ERP 개발이 필요한 상황과 패키지 도입만으로 부족해지는 지점

ERP는 단순히 매출, 재고, 인사 데이터를 한 화면에 보여주는 프로그램이 아닙니다.

주문이 접수된 뒤 출고 가능한 재고를 확인하고, 필요한 경우 구매나 생산을 요청하며, 출고와 매출을 반영하고, 정산과 회계 처리까지 이어지는 업무 흐름을 연결하는 시스템에 가깝습니다.

따라서 다음과 같은 문제가 반복된다면 ERP 도입이나 맞춤형 업무 시스템 개발을 검토할 수 있습니다.

같은 고객·상품·거래 데이터를 여러 프로그램에 반복 입력한다.
주문 수량과 실제 출고 수량이 자주 다르다.
재고 수량이 담당자나 창고별 엑셀마다 다르다.
거래처별 가격과 할인 조건을 담당자가 기억하고 처리한다.
견적, 주문, 출고, 세금계산서, 입금 상태를 한 번에 확인하기 어렵다.
구매 요청과 승인 내역을 이메일이나 메신저에서 찾는다.
월말마다 여러 자료를 취합해 정산 보고서를 다시 만든다.
담당자가 자리를 비우면 업무 진행 상황을 확인하기 어렵다.
데이터는 쌓이지만 경영 지표를 만들려면 다시 가공해야 한다.
기존 쇼핑몰이나 홈페이지의 주문을 사내 시스템에 수동 입력한다.

이런 문제는 화면이 부족해서 발생하기도 하지만, 더 근본적으로는 업무 기준과 데이터 기준이 시스템 안에 정의되어 있지 않기 때문에 발생합니다.

예를 들어 주문 관리 화면을 만드는 것만으로는 부족합니다.

주문이 접수됐을 때 재고를 바로 차감할지, 결제가 완료된 뒤 차감할지, 출고가 확정된 시점에 차감할지 정해야 합니다. 주문 취소가 발생하면 확보했던 재고를 언제 되돌릴지도 결정해야 합니다.

거래처별 가격이 다르다면 가격표도 단순하지 않습니다.

기본 가격이 있고, 거래처 등급별 가격이 있으며, 계약 단가와 기간 한정 단가가 함께 존재할 수 있습니다. 여러 조건이 겹쳤을 때 어떤 가격을 우선 적용할지 정하지 않으면 담당자가 다시 수기로 판단하게 됩니다.

즉, ERP 개발은 메뉴와 화면을 만드는 일보다 회사의 업무 규칙을 시스템이 처리할 수 있는 형태로 정리하는 일이 먼저입니다.

패키지 ERP, 맞춤형 ERP 개발, 기존 시스템 연동의 차이

ERP 구축 방식은 크게 세 가지로 나누어 볼 수 있습니다.

| 구분 | 패키지 ERP 도입 | 맞춤형 ERP 개발 | 기존 시스템 연동 | |---|---|---|---| | 기본 방향 | 이미 만들어진 표준 기능 사용 | 회사 업무에 맞춰 시스템 설계 | 사용 중인 시스템을 유지하며 데이터 연결 | | 적합한 상황 | 업무를 표준 프로세스에 맞출 수 있음 | 고유한 승인·가격·정산·운영 규칙이 많음 | 회계·쇼핑몰·물류 등 교체하기 어려운 시스템이 있음 | | 장점 | 비교적 빠르게 표준 기능을 활용 가능 | 실제 업무 흐름을 구체적으로 반영 가능 | 전체 교체에 따른 부담을 줄일 수 있음 | | 확인할 점 | 필요한 기능의 제공 범위와 추가 설정 | 개발 범위, 유지보수, 향후 확장 구조 | API 제공 여부, 데이터 기준과 오류 처리 | | 주요 위험 | 과도한 커스터마이징 | 범위가 계속 늘어나는 문제 | 시스템 간 데이터 불일치 |

1. 패키지 ERP가 적합한 경우

회계, 구매, 재고, 인사 등 주요 업무가 일반적인 절차와 크게 다르지 않다면 패키지 ERP를 먼저 검토할 수 있습니다.

패키지 ERP는 이미 구성된 기능과 업무 절차가 있기 때문에 회사의 업무를 제품의 표준 흐름에 맞추는 방식으로 접근합니다.

이때 중요한 판단은 “현재 하던 방식을 그대로 구현할 수 있는가?”가 아니라 다음과 같습니다.

현재 업무 중 불필요하게 복잡한 절차는 없는가?
패키지의 표준 기능으로 바꿔도 사업 운영에 문제가 없는가?
반드시 유지해야 하는 업무 규칙은 무엇인가?
설정으로 해결할 수 있는 부분과 추가 개발이 필요한 부분은 무엇인가?

SAP의 ERP 구현 가이드에서도 표준 프로세스와 기업 요구사항을 비교해 표준을 그대로 채택할지, 조정할지, 확장할지를 구분하는 방식이 제시됩니다. 기존 절차를 모두 그대로 복제하기보다 표준 기능과 실제 업무의 차이를 먼저 확인하는 접근입니다. (help.sap.com)

패키지 ERP가 제공하는 기능을 충분히 확인하지 않고 익숙한 기존 절차를 모두 추가 개발하려 하면, 도입 비용뿐 아니라 업데이트와 유지보수 부담도 커질 수 있습니다.

따라서 패키지를 검토할 때는 기능표만 보는 것보다 실제 담당자가 참여해 주문, 구매, 입고, 출고, 정산과 같은 전체 업무를 시연해보는 과정이 필요합니다.

2. 맞춤형 ERP 개발이 적합한 경우

다음과 같이 회사 고유의 운영 방식이 경쟁력이나 서비스 품질과 직접 연결되어 있다면 맞춤 개발을 검토할 수 있습니다.

거래처마다 주문 가능 품목과 가격이 다르다.
영업 담당자, 팀장, 재무 담당자의 승인 단계가 복잡하다.
프로젝트별 원가와 인력 투입을 별도로 관리해야 한다.
일반적인 입출고가 아니라 가공, 조립, 검수, 분할 출고가 포함된다.
여러 사업부가 같은 데이터를 사용하지만 처리 절차는 다르다.
고객이 사용하는 주문 화면과 사내 처리 시스템을 함께 구축해야 한다.
기존 장비나 자체 시스템에서 생성되는 데이터를 업무에 활용해야 한다.
업무 상태에 따라 알림, 문서 생성, 배정 등 후속 작업이 자동으로 실행되어야 한다.

맞춤형 ERP 개발의 장점은 현재 업무를 구체적으로 반영할 수 있다는 점입니다.

하지만 “현재 사용 중인 엑셀을 그대로 웹으로 옮겨주세요”라는 방식으로 접근하면 문제가 생길 수 있습니다. 엑셀은 담당자가 상황에 맞게 값을 덮어쓰거나 열을 추가할 수 있지만, 여러 부서가 함께 사용하는 시스템은 데이터 형식과 변경 기준을 명확히 정해야 하기 때문입니다.

맞춤 개발에서는 현재 업무를 그대로 복제하기보다 다음을 구분해야 합니다.

회사가 반드시 유지해야 하는 고유한 업무 규칙
담당자의 습관 때문에 남아 있는 절차
중복 입력이나 수작업으로 인해 제거해야 하는 절차
시스템이 자동으로 처리할 수 있는 절차
담당자의 확인과 판단이 필요한 예외 절차

이 구분이 있어야 맞춤 개발이 단순한 전산화가 아니라 실제 업무 개선으로 이어질 수 있습니다.

3. 기존 시스템 연동이 적합한 경우

회계 프로그램, 온라인 쇼핑몰, 물류 시스템, 그룹웨어, 고객 관리 시스템처럼 이미 안정적으로 사용 중인 시스템이 있다면 전체를 교체할 필요는 없습니다.

대신 ERP 또는 별도의 통합 관리자 시스템을 중심으로 필요한 데이터만 연동하는 방법을 검토할 수 있습니다.

예를 들어 다음과 같은 구조입니다.

쇼핑몰에서 발생한 주문을 ERP로 가져온다.
ERP의 상품과 재고 정보를 쇼핑몰에 전달한다.
출고된 주문을 택배·물류 시스템으로 전달한다.
배송 상태를 다시 주문 관리 화면에 반영한다.
매출과 매입 데이터를 회계 시스템으로 전달한다.
거래처 정보는 CRM과 ERP에서 함께 활용한다.
경영 지표에 필요한 데이터는 별도의 분석 화면으로 모은다.

이 방식은 기존 시스템의 장점을 유지하면서 중복 입력을 줄일 수 있습니다.

다만 연동은 시스템을 연결하는 것만으로 끝나지 않습니다. 어느 시스템의 데이터를 기준으로 사용할지, 언제 전달할지, 실패한 데이터는 어떻게 재처리할지까지 정해야 합니다.

Microsoft의 ERP 구현 문서에서도 외부 시스템 통합, 데이터 마이그레이션, 보안 역할, 테스트와 전환 계획을 각각 별도의 구현 범위로 정의할 필요가 있다고 안내합니다. (learn.microsoft.com)

개발 전 먼저 정리해야 할 업무 흐름과 기준 데이터

ERP 개발 상담에서 자주 등장하는 자료는 현재 사용 중인 엑셀 파일입니다.

엑셀은 실제 업무를 파악하는 데 유용하지만, 파일의 열을 그대로 화면 입력 항목으로 옮기는 것만으로는 요구사항이 충분하지 않습니다.

같은 엑셀을 사용하더라도 누가, 언제, 어떤 근거로 값을 입력하는지에 따라 시스템 구조가 달라집니다.

ERP 개발 전에는 우선 핵심 업무를 시작부터 종료까지 연결해서 정리하는 것이 좋습니다.

예를 들어 주문 업무라면 다음과 같이 작성할 수 있습니다.

``text 고객 주문 접수 → 거래처와 계약 조건 확인 → 판매 단가 결정 → 재고 확인 → 부족 수량 구매 또는 생산 요청 → 주문 승인 → 출고 지시 → 실제 출고 → 매출 확정 → 청구 및 입금 확인 → 정산 완료 ``

각 단계에서는 다음 질문을 확인합니다.

이 업무를 시작시키는 조건은 무엇인가?
누가 처리하는가?
어떤 데이터를 입력하거나 조회하는가?
다음 단계로 넘어가는 조건은 무엇인가?
승인이 필요한가?
취소하거나 이전 단계로 되돌릴 수 있는가?
처리 결과가 다른 시스템에 전달되어야 하는가?
예외가 발생하면 누가 확인하는가?

이렇게 정리하면 필요한 화면뿐 아니라 상태값, 권한, 알림, 변경 이력과 연동 범위까지 함께 드러납니다.

기준 데이터는 거래 데이터보다 먼저 정해야 합니다

ERP에는 매일 쌓이는 주문과 입출고 같은 거래 데이터가 있습니다. 그보다 먼저 정리해야 하는 것이 기준 데이터입니다.

대표적인 기준 데이터는 다음과 같습니다.

거래처
고객
상품과 품목
상품 옵션과 규격
창고와 재고 위치
부서와 사용자
가격표와 할인 정책
세금과 정산 기준
공급처
프로젝트와 계약
비용 항목과 계정 분류

예를 들어 같은 상품이 쇼핑몰에서는 판매상품 코드로, 창고에서는 품목 코드로, 회계 시스템에서는 별도 코드로 관리될 수 있습니다.

이 코드들의 관계를 정하지 않으면 주문을 연동하더라도 어떤 재고를 차감해야 하는지 알 수 없습니다.

기존 데이터 이전 역시 단순 복사 작업이 아닙니다. 이전할 데이터 범위, 중복 데이터 정리, 필드 매핑, 값 변환, 검증과 전환 시점을 계획해야 합니다. Microsoft의 데이터 마이그레이션 가이드도 고객·상품 같은 마스터 데이터와 진행 중인 주문·재고·잔액 같은 거래 데이터를 구분하고, 매핑·변환·테스트·검증 과정을 별도로 계획하도록 설명합니다. (learn.microsoft.com)

개발 전에는 최소한 다음 내용을 확인해야 합니다.

같은 거래처가 여러 이름으로 중복 등록되어 있지 않은가?
사용하지 않는 상품과 퇴사자 데이터는 이전할 것인가?
과거 주문 전체가 필요한가, 최근 데이터만 필요한가?
진행 중인 주문과 미수금은 어떤 기준일에 이전할 것인가?
기존 코드와 신규 코드를 그대로 사용할 것인가?
잘못된 날짜, 수량, 금액 데이터는 누가 확인할 것인가?
데이터 이전 후 합계가 일치하는지 어떻게 검증할 것인가?

이 작업은 개발사만으로 결정하기 어렵습니다. 각 데이터의 의미와 실제 사용 방식을 알고 있는 사내 담당자가 함께 참여해야 합니다.

사용자·부서별 권한과 승인 절차를 어떻게 설계할 것인가

ERP는 여러 부서가 함께 사용하는 시스템이기 때문에 로그인 기능만으로는 충분하지 않습니다.

사용자마다 볼 수 있는 데이터와 실행할 수 있는 작업이 달라야 합니다.

예를 들어 다음과 같이 권한을 나눌 수 있습니다.

영업 담당자: 담당 거래처의 주문과 견적 조회·등록
영업 팀장: 소속 팀의 주문 조회와 할인 승인
물류 담당자: 출고 대기 주문과 재고 조회, 출고 처리
구매 담당자: 구매 요청 조회, 발주 등록, 입고 처리
재무 담당자: 매출·매입과 입금·지급 상태 확인
인사 담당자: 직원과 근태 정보 관리
경영진: 전체 현황과 주요 지표 조회
시스템 관리자: 사용자, 조직, 권한과 기준정보 관리

여기서 메뉴가 보이지 않게 처리하는 것과 실제 권한을 제한하는 것은 다릅니다.

사용자 화면에서 버튼을 숨겼더라도 서버에서 권한을 확인하지 않으면 비정상적인 요청으로 데이터가 조회되거나 수정될 수 있습니다. 조회, 등록, 수정, 삭제, 승인, 다운로드 등의 작업을 기능별로 구분해야 합니다.

역할 기반 접근 제어는 사용자의 직무와 책임에 따라 권한을 부여하는 방식입니다. NIST의 역할 기반 접근 제어 모델에서도 최소 권한과 업무 분리를 지원하는 구조를 설명합니다. (csrc.nist.gov)

승인 절차는 한 줄로 끝나지 않습니다

“팀장이 승인한다”라는 요구사항만으로는 승인 기능을 설계하기 어렵습니다.

다음 조건을 구체적으로 정해야 합니다.

어떤 금액이나 조건에서 승인이 필요한가?
한 명만 승인하면 되는가?
순차 승인인가, 병렬 승인인가?
승인자가 자리를 비우면 대리 승인이 가능한가?
반려할 때 사유 입력이 필요한가?
승인 후 내용이 변경되면 다시 승인해야 하는가?
긴급 처리나 사후 승인 절차가 있는가?
누가 언제 승인·반려했는지 기록해야 하는가?

예를 들어 할인율이 일정 기준 이하라면 영업 담당자가 바로 확정하고, 기준을 초과하면 팀장 승인을 받고, 더 큰 할인이 적용되면 임원 승인을 받도록 설계할 수 있습니다.

다만 승인 단계가 많다고 관리가 잘되는 것은 아닙니다.

모든 업무를 동일한 승인 절차에 넣으면 처리가 늦어지고, 결국 담당자가 시스템 밖에서 먼저 협의한 뒤 형식적으로 승인 버튼만 누르게 될 수 있습니다.

승인 기능은 실제 통제할 필요가 있는 업무를 중심으로 적용해야 합니다.

재고·주문·정산·인사 등 핵심 업무별 개발 범위 정하기

ERP 개발 범위는 “재고 관리”, “주문 관리”처럼 메뉴 이름만으로 정하기 어렵습니다.

같은 재고 관리라도 단일 창고에서 완제품 수량만 관리하는 기업과 여러 창고·로케이션·로트·유효기간을 관리하는 기업의 범위는 크게 다릅니다.

주문·영업 관리

주문 관리에서는 다음 항목을 확인합니다.

견적과 주문을 구분할 것인가?
거래처별 판매 가능 상품이 다른가?
거래처별 가격과 할인 조건이 있는가?
최소 주문 수량이나 주문 단위가 있는가?
신용 한도와 미수금에 따라 주문을 제한하는가?
부분 출고와 분할 배송이 가능한가?
주문 변경과 취소는 어느 단계까지 가능한가?
반품과 교환은 기존 주문과 어떻게 연결할 것인가?

B2B 주문이라면 일반 소비자 쇼핑몰보다 거래처별 조건과 사내 승인 절차가 중요할 수 있습니다.

고객이 직접 주문하는 웹 화면이 필요한지, 영업 담당자가 내부 시스템에서 대신 등록하는지에 따라서도 개발 범위가 달라집니다.

재고·물류 관리

재고 관리에서는 단순한 현재 수량보다 재고가 변한 이유를 추적할 수 있어야 합니다.

주문으로 확보된 수량
실제 출고된 수량
입고 예정 수량
반품된 수량
불량이나 폐기로 조정된 수량
창고 간 이동 중인 수량
실사 과정에서 조정된 수량

이 값들을 하나의 재고 숫자로만 관리하면 차이가 발생했을 때 원인을 찾기 어렵습니다.

여러 창고를 운영한다면 창고별 재고와 전체 재고를 구분해야 합니다. 동일한 창고 안에서도 구역이나 선반 단위까지 관리할 것인지 판단해야 합니다.

제조나 식품, 원료 관리가 포함된다면 로트, 유효기간, 원재료, 반제품, 완제품 관계까지 범위가 확장될 수 있습니다.

구매·발주 관리

구매 업무에서는 구매 요청, 승인, 발주, 입고, 검수와 매입 확정이 서로 다른 단계인지 확인해야 합니다.

재고가 부족하면 자동으로 구매 요청을 만들 것인가?
담당자가 여러 공급처의 가격을 비교하는가?
발주 후 일부 수량만 입고될 수 있는가?
검수 전 재고와 판매 가능 재고를 구분할 것인가?
발주 수량과 입고 수량이 다르면 어떻게 처리할 것인가?
공급처별 납기와 매입 단가 이력을 관리할 것인가?

구매와 재고가 연결되지 않으면 ERP를 사용하면서도 입고 예정 수량을 별도 엑셀로 관리하게 될 수 있습니다.

정산·회계 연결

맞춤형 ERP를 개발한다고 해서 회계 프로그램의 모든 기능까지 새로 만들어야 하는 것은 아닙니다.

회계와 세무 업무는 현재 사용 중인 전문 시스템을 유지하고, ERP에서 확정된 매출·매입·입금·지급 데이터를 전달하는 구조를 선택할 수 있습니다.

이 경우 다음을 정해야 합니다.

ERP에서 어느 상태가 되어야 매출이 확정되는가?
주문 금액과 실제 청구 금액이 다를 수 있는가?
선금, 잔금, 분할 입금을 어떻게 처리하는가?
부분 취소와 환불을 어떻게 반영하는가?
회계 시스템으로 어떤 데이터를 어느 주기로 전달하는가?
전송 후 수정이 필요하면 어느 시스템에서 처리하는가?
전송 실패 건을 누가 확인하고 재처리하는가?

회계 연동은 금액 합계가 맞는지만 확인해서는 부족합니다. 주문, 거래처, 품목, 세금 구분과 기준일이 함께 일치하는지 검증해야 합니다.

인사·근태 관리

인사 기능도 직원 목록만 관리하는 수준부터 근태, 휴가, 급여, 평가까지 범위가 크게 확장될 수 있습니다.

초기 ERP 개발에서는 다음과 같이 범위를 분리하는 편이 좋습니다.

조직과 직원 정보
입사·퇴사 상태
부서와 직급
시스템 권한
근무 일정
출퇴근과 휴가
급여 계산
평가와 교육

모든 기능을 한 번에 개발하기보다 다른 업무 모듈에서 필요한 조직·사용자 정보부터 구축하고, 근태나 급여는 전문 시스템을 연동하는 방안도 검토할 수 있습니다.

기존 홈페이지·쇼핑몰·회계·물류 시스템과 ERP를 연동할 때 확인할 기준

ERP 연동에서는 먼저 각 시스템의 역할을 정해야 합니다.

모든 데이터를 양쪽에서 수정할 수 있게 만들면 편리해 보이지만, 값이 다를 때 어느 쪽이 맞는지 판단하기 어려워집니다.

1. 데이터의 기준 시스템

데이터 종류별로 원본을 정해야 합니다.

| 데이터 | 기준 시스템 예시 | |---|---| | 상품 기본정보 | ERP | | 온라인 노출명과 상세 설명 | 쇼핑몰 | | 계약 단가 | ERP 또는 영업 관리 시스템 | | 온라인 주문 | 쇼핑몰 | | 실제 출고 수량 | 물류 시스템 | | 회계 전표 | 회계 시스템 | | 고객 상담 내역 | CRM | | 조직과 직원 정보 | 인사 시스템 |

기준 시스템이 정해지면 다른 시스템에서 수정할 수 있는 범위도 함께 제한할 수 있습니다.

2. 공통 식별자

이름만으로 데이터를 연결하면 변경이나 중복에 취약합니다.

거래처 코드, 상품 코드, 주문번호, 출고번호처럼 시스템 간에 공유할 식별자가 필요합니다.

기존 시스템마다 코드 체계가 다르다면 매핑 테이블을 두고 관계를 관리할 수 있습니다. 매핑되지 않은 상품이나 거래처가 들어왔을 때 운영자가 확인할 수 있는 화면도 필요할 수 있습니다.

3. 연동 시점과 방식

모든 데이터를 실시간으로 연동해야 하는 것은 아닙니다.

주문 접수처럼 즉시 처리가 필요한 데이터
재고처럼 짧은 간격으로 동기화할 데이터
정산처럼 하루 또는 특정 시간에 모아서 전달할 데이터
과거 데이터처럼 최초 한 번만 이전할 데이터

연동 시점은 업무 영향과 외부 시스템의 제공 방식에 따라 결정해야 합니다.

Microsoft의 공식 문서에서도 실시간에 가까운 동기화, 외부 데이터를 복제하지 않고 조회하는 방식, 파일 기반의 반복 가져오기 등 연동 목적에 따라 서로 다른 방식을 사용할 수 있다고 설명합니다. (learn.microsoft.com)

4. 실패와 재처리

외부 시스템은 점검, 네트워크 지연, 호출 제한과 데이터 오류로 응답하지 않을 수 있습니다.

따라서 연동 기능에는 다음과 같은 운영 구조가 필요합니다.

요청한 시간
요청 데이터
성공 또는 실패 상태
외부 시스템의 응답
실패 원인
재시도 횟수
마지막 처리 시간
수동 재처리 기능
중복 처리 방지용 고유값

예를 들어 주문을 물류 시스템으로 전달했지만 응답이 늦었다고 해서 바로 다시 전송하면 동일한 출고 요청이 두 번 생성될 수 있습니다.

반대로 실패한 요청을 자동으로 재시도하지 않으면 운영자가 매번 개발자에게 처리를 요청해야 할 수 있습니다.

ERP 연동에서는 정상 흐름뿐 아니라 실패한 데이터가 어디에 남고 누가 복구할 수 있는지까지 설계해야 합니다.

한 번에 전체 구축하지 않고 MVP와 단계별 확장으로 나누는 방법

ERP 범위는 주문, 재고, 구매, 회계, 인사, 고객 관리까지 쉽게 확장됩니다.

모든 기능을 동시에 구축하면 프로젝트 기간과 검토 항목이 늘어나고, 실제 사용자의 피드백을 늦게 받게 될 수 있습니다.

이 때문에 업무 우선순위나 부서, 모듈 단위로 단계적 구축을 검토할 수 있습니다. Microsoft의 구현 가이드도 단계별 배포를 기능, 사업부, 우선순위 또는 지역 단위로 나누는 방법을 설명하며, 단계 사이에는 기존 시스템과 신규 시스템을 연결하는 임시 인터페이스가 필요할 수 있다고 안내합니다. (learn.microsoft.com)

ERP에서의 MVP는 기능이 적은 데모가 아닙니다.

한 가지 핵심 업무가 시작부터 끝까지 실제로 처리되는 최소 운영 범위에 가깝습니다.

예를 들어 유통 기업이라면 다음 흐름을 1차 범위로 정할 수 있습니다.

``text 거래처 등록 → 상품과 거래처별 가격 관리 → 주문 등록 → 주문 승인 → 재고 확인 → 출고 처리 → 매출 확정 → 입금 상태 확인 ``

2차 범위에서는 다음 기능을 추가할 수 있습니다.

쇼핑몰 주문 자동 수집
구매 요청과 발주
창고 간 이동
반품과 교환
거래명세서 등 문서 출력
회계 프로그램 연동
경영 지표 대시보드

3차 범위에서는 업무 자동화와 분석 기능을 검토할 수 있습니다.

안전 재고 기준에 따른 구매 요청
장기 미수금 알림
거래처별 수익성 분석
담당자별 처리 지연 현황
반복 보고서 자동 생성
AI를 활용한 문서 인식이나 데이터 분류

단계적 구축에서는 1차 범위가 이후 확장의 기반이 되어야 합니다.

초기 기능만 빠르게 만들기 위해 상품, 거래처, 주문, 재고의 관계를 단순화하면 다음 단계에서 구조를 다시 변경해야 할 수 있습니다.

따라서 화면은 최소화하더라도 핵심 데이터 구조와 상태 흐름은 확장 가능성을 고려해 설계하는 것이 좋습니다.

ERP 개발은 어떤 순서로 진행해야 할까

ERP 프로젝트는 요구사항 문서를 전달하고 바로 개발에 들어가기보다 업무 분석과 범위 확정 단계를 거치는 편이 안전합니다.

1단계. 현재 업무와 문제 정리

부서별 인터뷰, 기존 엑셀, 사용 중인 프로그램과 업무 문서를 확인합니다.

이 단계에서는 화면 요구보다 다음 내용을 중심으로 정리합니다.

반복 입력되는 데이터
담당자 개인에게 의존하는 업무
승인이 지연되는 구간
데이터가 자주 달라지는 구간
고객 문의가 많이 발생하는 구간
월말에 수작업이 집중되는 구간
현재 시스템에서 수정하기 어려운 기능

2단계. 목표 업무 흐름 정의

현재 업무를 그대로 전산화할지, 일부 절차를 변경할지 결정합니다.

패키지를 도입한다면 표준 기능에 맞출 수 있는 부분과 추가 설정·개발이 필요한 부분을 구분합니다.

맞춤 개발이라면 반드시 시스템화할 규칙과 예외 처리 범위를 정합니다.

3단계. 기준 데이터와 상태값 설계

거래처, 상품, 창고, 조직 등의 데이터 구조를 정리하고 주문·출고·정산 상태를 정의합니다.

이 단계가 부족하면 화면 개발이 진행된 뒤에도 같은 용어를 부서마다 다르게 해석하는 문제가 발생할 수 있습니다.

4단계. 권한과 승인 정책 설계

사용자 유형별 조회·수정·승인 범위를 정합니다.

개인정보나 계약 단가처럼 민감한 항목은 데이터 단위의 접근 범위도 검토해야 합니다.

SAP의 최신 권한 가이드 역시 사용자에게 직무상 필요한 애플리케이션과 데이터 접근을 부여하고, 업무 분리와 중요 정보 보호를 권한 설계의 기준으로 설명합니다. (help.sap.com)

5단계. 화면과 관리자 기능 설계

업무 흐름이 정리된 뒤 실제 화면을 설계합니다.

ERP 화면에서는 시각적인 장식보다 검색, 필터, 일괄 처리, 엑셀 다운로드, 변경 이력과 상태 확인이 중요할 수 있습니다.

운영자가 자주 처리하는 업무는 클릭 수를 줄이고, 여러 건을 한 번에 처리할 수 있도록 구성할 필요가 있습니다.

6단계. 개발과 연동 테스트

기능별 개발뿐 아니라 주문부터 출고와 정산까지 전체 업무를 연결해 테스트합니다.

연동이 포함된다면 정상 데이터만 테스트해서는 부족합니다.

존재하지 않는 상품 코드
중복 주문
수량이 맞지 않는 데이터
외부 시스템 응답 지연
일부 데이터만 성공한 경우
승인 중 내용이 변경된 경우
동시에 같은 재고를 처리하는 경우

실제 운영에서 발생할 수 있는 예외를 포함해야 합니다.

7단계. 데이터 이전과 사용자 검증

데이터를 시험 이전하고 현업 사용자가 직접 업무를 처리해보는 사용자 인수 테스트가 필요합니다.

신규 시스템 전환 전에는 데이터 이전, 시스템 통합 테스트, 사용자 검증, 권한 부여와 전환 계획을 함께 확인해야 합니다. (learn.microsoft.com)

8단계. 전환과 운영 안정화

전환일에는 기존 시스템 입력을 언제 중단할지, 진행 중인 주문과 재고를 어떤 시점 기준으로 옮길지 정해야 합니다.

오픈 후에는 오류 수정뿐 아니라 실제 사용자 피드백을 바탕으로 검색 조건, 일괄 처리, 보고서와 권한을 조정하는 안정화 기간도 필요합니다.

ERP 개발 업체에 문의하기 전 준비할 요구사항

처음부터 완성된 요구사항 정의서를 준비할 필요는 없습니다.

다만 다음 내용을 정리하면 개발사와 훨씬 구체적으로 대화할 수 있습니다.

회사와 사용자

업종과 주요 사업 구조
사용 예정 부서
사용자 유형과 예상 인원
지점, 법인, 창고의 구분
외부 거래처나 고객의 시스템 사용 여부

현재 업무

주문부터 정산까지의 업무 순서
현재 사용하는 엑셀과 프로그램
중복 입력되는 데이터
시간이 많이 걸리는 반복 업무
자주 발생하는 오류와 문의
담당자 개인에게 의존하는 업무

필요한 기능

주문·영업
재고·창고
구매·발주
매출·매입
입금·지급
프로젝트·원가
조직·사용자
승인·알림
통계·보고서
문서 출력
데이터 다운로드

기존 시스템

홈페이지와 쇼핑몰
회계 프로그램
물류·택배 시스템
그룹웨어
CRM
생산·장비 시스템
외부에서 제공되는 API 문서
기존 데이터의 형식과 양

프로젝트 조건

우선 적용할 부서와 업무
희망하는 공개 또는 전환 시점
반드시 1차에 포함해야 하는 기능
추후 확장할 기능
데이터 이전 범위
사내 담당자와 의사결정자
운영 후 유지보수 방식

ERP 개발 견적을 비교할 때 확인할 체크리스트

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

같은 주문 관리 화면도 가격 정책, 승인 단계, 재고 반영 시점, 부분 출고와 외부 연동에 따라 개발 범위가 달라집니다.

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

[ ] 업무 분석과 요구사항 정리가 포함되어 있는가?
[ ] 현재 업무와 개선할 업무를 구분하는 과정이 있는가?
[ ] 사용자·부서·역할별 권한 설계가 포함되어 있는가?
[ ] 승인, 반려, 취소와 되돌림 절차가 정의되어 있는가?
[ ] 거래처·상품·창고 등 기준 데이터 범위가 구체적인가?
[ ] 주문·재고·정산 상태값이 구분되어 있는가?
[ ] 기존 데이터 정리와 이전 범위가 명시되어 있는가?
[ ] 외부 시스템별 연동 기능과 책임 범위가 구분되어 있는가?
[ ] 연동 실패, 재시도와 중복 방지 기능이 포함되어 있는가?
[ ] 검색, 필터, 일괄 처리와 엑셀 기능이 포함되어 있는가?
[ ] 변경 이력과 작업자 기록이 필요한 범위가 정해져 있는가?
[ ] 개발·테스트·운영 환경의 범위가 명시되어 있는가?
[ ] 사용자 인수 테스트와 수정 대응 기준이 있는가?
[ ] 서버 배포와 계정 인계 범위가 포함되어 있는가?
[ ] 오픈 후 안정화와 유지보수 조건이 구체적인가?
[ ] 추가 개발 시 비용을 산정하는 기준이 있는가?

또한 패키지 ERP 견적과 맞춤 개발 견적은 같은 기준으로 단순 비교하기 어렵습니다.

패키지는 라이선스, 초기 설정, 데이터 이전, 추가 개발, 교육과 운영 지원이 나뉠 수 있습니다. 맞춤 개발은 기획, 디자인, 개발, 인프라, 외부 연동과 유지보수 범위를 확인해야 합니다.

기존 시스템을 연동하는 경우에는 상대 시스템의 API 사용 비용이나 계약, 인증 방식, 호출 제한, 테스트 환경 제공 여부도 별도로 확인해야 합니다.

우리 회사에는 어떤 방식이 적합할까

다음 질문을 기준으로 1차 방향을 판단해볼 수 있습니다.

패키지 ERP를 먼저 검토할 수 있는 경우

업무를 일반적인 주문·구매·재고·회계 흐름에 맞출 수 있다.
내부 절차를 표준화하는 것이 프로젝트의 주요 목적이다.
고유한 업무 규칙보다 기본 기능의 빠른 활용이 우선이다.
패키지가 제공하는 기능과 확장 방식이 요구사항에 부합한다.

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

거래처별 가격·승인·정산 방식이 사업의 핵심이다.
여러 사용자 유형이 서로 다른 화면과 업무를 사용한다.
주문, 생산, 검수, 출고 등 고유한 업무 단계가 있다.
사용자용 웹·앱과 내부 ERP를 함께 연결해야 한다.
패키지에 맞추면 핵심 운영 방식이 훼손되거나 수작업이 많이 남는다.

기존 시스템 연동을 검토할 수 있는 경우

회계나 물류 등 계속 사용해야 하는 시스템이 있다.
전체 시스템 교체에 따른 업무 중단 위험이 크다.
중복 입력과 데이터 불일치를 먼저 줄이고 싶다.
시스템별 장점을 유지하면서 통합 조회와 자동화를 구현하고 싶다.

실제로는 세 가지 중 하나만 선택하기보다 혼합 구조가 적합할 수 있습니다.

예를 들어 회계는 기존 패키지를 사용하고, 거래처별 주문과 승인 업무는 맞춤 개발하며, 쇼핑몰·물류·회계 데이터를 API로 연결하는 방식입니다.

이 경우 중요한 것은 시스템 수를 줄이는 것이 아니라, 각 데이터가 어디에서 생성되고 어디에서 확정되는지를 명확히 만드는 것입니다.

ERP 개발은 기능보다 업무 기준을 정하는 프로젝트입니다

ERP 개발을 검토할 때 처음부터 모든 기능을 확정하기는 어렵습니다.

현재 사용하는 엑셀과 프로그램, 부서별 업무 순서, 반복되는 수작업과 오류를 먼저 정리하면 패키지 ERP로 해결할 수 있는 부분과 맞춤 개발이 필요한 부분을 구분할 수 있습니다.

그리고 기존 시스템을 유지해야 한다면 어느 데이터를 어떤 기준으로 연결할지 설계해야 합니다.

원소프트는 웹·앱·관리자 시스템과 외부 API·ERP 연동을 검토할 때 사용자 화면뿐 아니라 운영자의 업무 흐름, 권한, 데이터 구조와 향후 확장 범위를 함께 살펴봅니다.

ERP 전체를 한 번에 새로 구축하는 방향만 제안하기보다 현재 시스템 중 유지할 부분, 먼저 개선할 업무, 단계적으로 확장할 범위를 구분하는 접근이 필요합니다.

개발 문의 전 완성된 기획서가 없더라도 현재 사용 중인 업무 문서와 엑셀, 시스템 목록, 가장 불편한 업무를 바탕으로 1차 개발 범위를 정리할 수 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치한 웹·앱·관리자 시스템 개발사입니다. 동탄·화성을 비롯해 수원, 용인, 기흥, 오산 등 경기 남부에서 업무 시스템 개발을 검토하고 계신 기업이라면 현재 운영 방식과 필요한 기능을 기준으로 구축 방향을 함께 검토해드릴 수 있습니다.

제목 후보

ERP 개발, 패키지 도입·맞춤 개발·기존 시스템 연동을 결정하는 기준
ERP 개발 전 확인할 업무 흐름과 맞춤형 시스템 구축 범위
맞춤형 ERP 개발이 필요한 경우와 패키지 ERP를 선택하는 기준
ERP 개발 업체에 문의하기 전 정리해야 할 업무·권한·연동 범위
ERP 구축 방법 비교, 패키지·맞춤 개발·기존 시스템 연동 중 무엇이 적합할까

메인 키워드

ERP개발

서브 키워드

맞춤형 ERP 개발
ERP 구축
ERP 연동
업무 시스템 개발
ERP 개발 업체

썸네일 문구

ERP, 어떤 방식으로 구축해야 할까?
패키지·맞춤 개발·연동 선택 기준
ERP 개발 전 업무부터 정리하세요

글 요약

ERP 구축 방식은 패키지와 맞춤 개발 중 하나를 단순히 선택하는 문제가 아니라, 표준화할 수 있는 업무와 유지해야 하는 고유한 규칙을 구분하는 과정입니다. 업무 흐름, 기준 데이터, 사용자 권한, 승인 절차와 기존 쇼핑몰·회계·물류 시스템 연동 범위를 먼저 정리한 뒤 핵심 업무부터 단계적으로 구축하는 방법을 설명했습니다.

CTA 후보

현재 사용 중인 엑셀과 업무 시스템은 있지만 ERP 개발 범위를 정하기 어렵다면, 반복 입력되는 업무와 반드시 유지해야 하는 절차부터 함께 정리해볼 수 있습니다.

패키지 ERP 도입, 맞춤형 업무 시스템 개발, 기존 시스템 연동 중 어떤 방식이 적합한지 고민하고 계시다면 현재 업무 흐름과 사용 중인 프로그램을 기준으로 1차 구축 범위를 검토해드릴 수 있습니다.

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

ERP 연동 개발, 쇼핑몰·회계·물류 데이터의 기준 시스템을 정하는 방법
맞춤형 업무 시스템 개발, 엑셀 업무를 그대로 옮기면 안 되는 이유
재고 관리 시스템 개발, 주문·입고·출고 수량이 맞지 않는 원인과 설계 기준