ERP개발 외주 문의 전, 표준 기능·맞춤 업무·기존 시스템 연동을 나누는 방법

영업팀은 거래처와 견적을 엑셀로 관리하고, 물류팀은 별도의 재고 프로그램을 사용하며, 회계팀은 다시 회계 시스템에 매출과 매입 내역을 입력하는 기업이 있습니다.

업무량이 적을 때는 담당자 간 확인으로 운영할 수 있지만, 거래가 늘어나면 같은 데이터를 여러 번 입력하게 됩니다. 부서마다 수량이나 금액이 다르게 기록되기도 하고, 현재 주문이 승인 단계인지 출고 단계인지 확인하려면 담당자에게 직접 물어봐야 하는 상황도 생깁니다.

이런 문제를 해결하기 위해 ERP개발을 검토하지만, 상담 과정에서는 곧바로 선택의 문제가 생깁니다.

기존 ERP 패키지를 도입하면 되는가?
우리 회사 업무에 맞춰 전부 새로 개발해야 하는가?
회계 시스템은 유지하고 영업·재고 기능만 개발할 수 있는가?
현재 사용하는 시스템을 연결하면 어디까지 자동화할 수 있는가?
과거 엑셀 데이터는 모두 이전해야 하는가?

이 질문에 답하려면 필요한 기능을 한꺼번에 나열하기보다 현재 업무를 표준 기능, 맞춤 업무, 기존 시스템 연동이라는 세 영역으로 먼저 나눠야 합니다.

ERP는 단순히 여러 관리 화면을 모아 놓은 프로그램이 아닙니다. 영업, 구매, 재고, 정산 등 서로 연결된 업무에서 어떤 데이터를 기준으로 삼고, 누가 어떤 단계에서 처리하며, 다음 업무로 어떻게 전달할지를 정하는 시스템에 가깝습니다.

Oracle의 ERP 설명에서도 ERP는 회계·조달·프로젝트·공급망 등 일상적인 기업 업무를 관리하고, 여러 업무의 데이터를 연결하는 통합 시스템으로 설명됩니다. 중요한 것은 기능의 수보다 부서 간 데이터와 업무 흐름이 하나의 기준으로 이어지는지입니다. (oracle.com)

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

업무에 불편함이 있다고 해서 항상 맞춤형 ERP를 처음부터 개발해야 하는 것은 아닙니다.

일반적인 회계 처리, 거래처 관리, 구매 등록, 재고 입출고처럼 많은 기업이 비슷한 방식으로 수행하는 업무는 기존 패키지의 표준 기능으로 해결할 수 있습니다. 이미 검증된 기능을 활용하면 처음부터 모든 기능을 개발하는 것보다 초기 범위를 줄일 수 있습니다.

반면 회사마다 계약 조건, 승인 순서, 가격 계산, 생산 방식, 정산 기준이 다르다면 표준 기능만으로는 실제 업무를 반영하기 어려울 수 있습니다.

예를 들어 다음과 같은 상황입니다.

거래처 등급마다 판매 가능한 상품과 단가가 다름
영업 담당자의 할인율에 따라 추가 승인이 필요함
본사 승인 후 지점에서 발주를 확정해야 함
주문 제작 상품마다 생산 단계와 납기 계산 방식이 다름
출고 수량이 아니라 검수 완료 수량을 기준으로 정산함
프로젝트별 예산과 집행 금액을 여러 부서가 나눠 관리함
계약 유형에 따라 청구 시점과 매출 인식 기준이 달라짐
기존 회계 프로그램에 매입·매출 전표를 다시 전달해야 함

이런 업무는 화면 몇 개를 추가하는 수준으로 해결되지 않을 수 있습니다. 기준정보, 계산 규칙, 권한, 승인 단계, 상태값과 예외 처리까지 함께 설계해야 하기 때문입니다.

따라서 ERP개발 방식은 다음 세 가지 중 하나를 단순히 고르는 문제가 아닙니다.

기존 패키지의 표준 기능을 활용하는 영역
회사 고유 업무에 맞춰 별도로 개발하는 영역
현재 사용 중인 시스템을 유지하면서 연결하는 영역

실제 프로젝트에서는 이 세 가지를 조합하는 방식이 현실적일 수 있습니다.

1. 표준 기능으로 처리할 업무를 먼저 찾습니다

표준 기능은 특정 회사만의 규칙보다 여러 기업에서 공통으로 사용하는 업무에 적합합니다.

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

거래처와 공급처 기본정보 관리
품목과 상품 정보 관리
일반적인 견적·주문·발주 등록
창고별 입고·출고·재고 조회
매입·매출 기초 데이터 관리
세금과 통화 등 환경 설정
부서와 사용자 관리
기본 보고서와 데이터 내보내기

표준 기능을 검토할 때는 “현재 업무 방식과 완전히 같은가?”만 확인해서는 안 됩니다.

현재의 수작업 절차를 그대로 유지하기 위해 불필요한 맞춤 개발을 추가하면 ERP 도입 이후에도 복잡한 업무가 남을 수 있습니다. 반대로 패키지에 맞추기 위해 회사의 핵심 경쟁력과 관련된 업무까지 무리하게 변경하는 것도 적절하지 않습니다.

다음 질문을 기준으로 판단하는 것이 좋습니다.

이 절차가 회사의 사업 모델에 꼭 필요한가?
법적·계약상 이유로 유지해야 하는가?
단지 기존 담당자가 익숙해서 사용하고 있는 방식은 아닌가?
다른 부서에서도 같은 절차를 사용해야 하는가?
표준 기능에 맞춰 변경해도 고객이나 거래에 영향이 없는가?
업무를 바꾸는 비용과 맞춤 개발 비용 중 어느 쪽이 더 큰가?

SAP의 ERP 구축 자료에서도 표준 업무 프로세스를 먼저 확인하고, 기업의 실제 요구사항과 맞지 않는 부분을 구분하는 Fit-to-Standard 방식이 활용됩니다. 이는 기존 업무를 모두 그대로 개발하기보다 표준 기능으로 처리할 영역과 추가 검토가 필요한 차이를 먼저 찾는 접근입니다. (learning.sap.com)

표준화할 수 있는 업무는 표준 기능을 활용하고, 회사의 수익 구조나 서비스 품질에 직접 영향을 주는 규칙은 맞춤 영역으로 남기는 방식이 필요합니다.

2. 맞춤 개발이 필요한 업무는 ‘차이’가 아니라 ‘규칙’으로 설명해야 합니다

“우리 회사 업무는 일반 ERP와 다릅니다”라는 설명만으로는 개발 범위를 정하기 어렵습니다.

맞춤 개발이 필요한 업무는 실제 입력값, 판단 조건, 처리 결과를 기준으로 정리해야 합니다.

예를 들어 영업 할인을 관리한다고 가정해 보겠습니다.

단순한 요구사항은 다음과 같습니다.

영업 담당자가 할인된 가격으로 견적을 등록하고 팀장이 승인합니다.

하지만 개발 범위를 정하려면 더 구체적인 조건이 필요합니다.

영업 담당자마다 할인 가능한 최대 비율이 다른가?
거래처 등급별 기본 할인율이 있는가?
상품군에 따라 할인이 제한되는가?
일정 비율 이하는 자동 승인되는가?
팀장 승인 이후 임원이 다시 승인하는 조건이 있는가?
승인 요청 후 견적이 수정되면 기존 승인은 취소되는가?
반려할 때 사유를 필수로 입력해야 하는가?
긴급 주문은 승인 전에도 임시 출고할 수 있는가?
승인 이력을 누가 조회할 수 있는가?

이처럼 맞춤 업무는 화면보다 업무 규칙의 수와 예외 상황의 수가 개발 범위에 더 큰 영향을 줍니다.

맞춤 개발 후보를 정리할 때는 다음 형식을 사용할 수 있습니다.

| 항목 | 정리할 내용 | |---|---| | 업무 시작 조건 | 어떤 요청이나 데이터가 들어오면 업무가 시작되는가 | | 처리 담당자 | 누가 등록·검토·승인·확정하는가 | | 판단 조건 | 금액, 수량, 거래처, 상품, 부서에 따라 무엇이 달라지는가 | | 처리 결과 | 승인 후 어떤 데이터와 다음 업무가 생성되는가 | | 예외 상황 | 취소, 반려, 수정, 부분 처리 시 어떻게 되는가 | | 기록 항목 | 변경자, 변경 시점, 변경 사유를 남겨야 하는가 | | 외부 전달 | 처리 결과를 다른 시스템으로 보내야 하는가 |

이 표를 업무별로 작성하면 개발업체가 단순 화면 목록보다 실제 업무 복잡도를 파악하기 쉬워집니다.

3. 기존 시스템 연동으로 남길 영역을 구분합니다

ERP개발을 검토할 때 기존 회계·재고·영업 시스템을 모두 폐기해야 한다고 생각하기 쉽습니다.

하지만 현재 시스템이 안정적으로 운영되고 있고 담당자도 익숙하다면, 필요한 영역만 새로 개발하고 기존 시스템과 연결하는 방식을 검토할 수 있습니다.

예를 들어 다음과 같은 구성이 가능합니다.

회계 시스템은 유지하고 영업 주문 데이터를 전달
기존 쇼핑몰 주문을 ERP로 수집
ERP의 재고 수량을 B2B 주문 사이트에 제공
생산 시스템의 작업 완료 데이터를 ERP에 반영
그룹웨어에서 완료된 결재 결과를 ERP로 전달
물류 시스템에서 송장과 출고 상태를 가져옴
고객관리 시스템의 거래처 정보를 ERP와 동기화

연동 여부는 “API가 있는가?”만 확인해서 결정할 수 없습니다.

먼저 어떤 시스템이 각 데이터의 기준인지 정해야 합니다.

예를 들어 거래처 정보는 영업 시스템에서 생성하지만 회계 시스템에서도 관리할 수 있습니다. 두 시스템에서 거래처명을 각각 수정할 수 있다면 어느 데이터가 최신인지 판단하기 어렵습니다.

따라서 데이터별 기준 시스템을 표로 정리해야 합니다.

| 데이터 | 기준 시스템 | 전달 방향 | 전달 시점 | 수정 가능한 곳 | |---|---|---|---|---| | 거래처 | ERP | ERP → 회계 | 등록·수정 시 | ERP | | 상품 | ERP | ERP → 쇼핑몰 | 승인 후 | ERP | | 주문 | 쇼핑몰 | 쇼핑몰 → ERP | 주문 접수 시 | 조건별 구분 | | 재고 | ERP 또는 물류 | ERP → 쇼핑몰 | 실시간·주기별 | 기준 시스템 | | 매출 전표 | 회계 | ERP → 회계 | 출고·정산 확정 후 | 회계 | | 배송 상태 | 물류 | 물류 → ERP | 출고 처리 시 | 물류 |

여기에는 정상 처리만이 아니라 실패 처리도 포함해야 합니다.

상대 시스템이 응답하지 않으면 어떻게 하는가?
같은 주문이 두 번 전달되면 어떻게 구분하는가?
상품은 전달됐지만 옵션 일부만 실패하면 어떻게 하는가?
데이터 형식이 맞지 않으면 누가 확인하는가?
실패 건을 자동으로 다시 전송할 것인가?
운영자가 직접 수정하고 재처리할 수 있는가?
연동 이력과 오류 원인을 어디에서 확인하는가?

Microsoft의 ERP 구현 지침에서도 시스템 연동을 검토할 때 데이터 교환 기준, 보안, 예상 처리량과 성능, 상대 시스템에서 발생한 문제를 해결하는 절차를 함께 정의하도록 안내합니다. 운영 가능한 연동을 만들려면 정상 데이터 전달뿐 아니라 외부 시스템 장애와 예외 상황까지 범위에 포함해야 합니다. (learn.microsoft.com)

기준정보를 먼저 정리해야 ERP 데이터가 연결됩니다

ERP에서 기준정보는 여러 업무가 공통으로 참조하는 기본 데이터입니다.

대표적인 기준정보는 다음과 같습니다.

거래처와 공급처
상품, 품목과 원자재
상품 분류와 단위
창고와 재고 위치
조직, 부서와 담당자
가격표와 거래처 등급
세금 유형과 결제 조건
프로젝트와 비용 항목
계정과목과 정산 구분
배송·출고 방식

ERP개발에서 기준정보가 중요한 이유는 여러 업무가 동일한 데이터를 사용하기 때문입니다.

영업팀은 같은 회사를 고객사로 보고, 구매팀은 공급처로 관리하며, 회계팀은 세금계산서 발행 대상 또는 입금처로 관리할 수 있습니다. 부서마다 서로 다른 거래처 코드를 사용하면 연동 과정에서 같은 회사를 다른 대상으로 인식할 수 있습니다.

상품 데이터도 마찬가지입니다.

영업팀은 판매 상품명을 사용하고, 물류팀은 재고관리 코드를 사용하며, 회계팀은 매출 분류로 관리할 수 있습니다. ERP에서는 이 데이터들이 어떻게 연결되는지 정의해야 주문, 출고, 재고, 매출 데이터가 이어집니다.

기준정보를 정리할 때는 다음 항목을 확인하는 것이 좋습니다.

누가 최초로 등록하는가?
어떤 항목이 필수인가?
등록 후 바로 사용할 수 있는가, 승인이 필요한가?
코드가 자동으로 생성되는가?
중복 데이터는 어떤 기준으로 검사하는가?
이미 사용된 데이터도 수정하거나 삭제할 수 있는가?
사용 중단된 데이터는 어떻게 표시하는가?
다른 시스템에서는 어떤 코드로 관리하는가?
변경 내역을 기록해야 하는가?

ERP 화면을 먼저 개발한 뒤 기준정보를 맞추려 하면 데이터 구조를 다시 수정해야 할 수 있습니다. 업무 화면을 설계하기 전에 핵심 데이터와 데이터 간 관계를 정리해야 하는 이유입니다.

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

ERP에는 영업, 구매, 물류, 회계, 관리자 등 여러 역할이 참여합니다.

사용자가 로그인할 수 있다는 것과 특정 데이터를 처리할 권한이 있다는 것은 다릅니다.

예를 들어 영업 담당자는 자신의 거래처와 견적만 조회할 수 있지만 팀장은 팀 전체의 견적을 조회할 수 있습니다. 물류 담당자는 출고 수량을 입력할 수 있지만 판매 가격은 수정하지 못하게 할 수 있습니다. 회계 담당자는 정산 상태를 확정할 수 있지만 주문 수량은 바꾸지 못하게 할 수 있습니다.

권한은 다음과 같이 나눠 검토해야 합니다.

메뉴를 볼 수 있는 권한
목록을 조회할 수 있는 권한
상세정보를 열람할 수 있는 권한
신규 데이터를 등록할 수 있는 권한
기존 데이터를 수정할 수 있는 권한
승인·반려·확정할 수 있는 권한
엑셀로 다운로드할 수 있는 권한
민감한 금액이나 개인정보를 볼 수 있는 권한
삭제 또는 취소할 수 있는 권한
다른 부서의 데이터를 조회할 수 있는 권한

NIST에서 정의하는 역할 기반 접근제어도 사용자 개인에게 권한을 하나씩 부여하기보다 조직 내 역할에 따라 허용된 작업을 연결하는 방식입니다. ERP처럼 사용자와 기능이 많은 시스템에서는 직무와 책임을 기준으로 역할을 만들고, 역할에 권한을 연결하는 방식이 관리에 적합합니다. (csrc.nist.gov)

단, 역할만 나눈다고 권한 설계가 끝나는 것은 아닙니다.

같은 영업 담당자라도 담당 지점, 거래처, 프로젝트에 따라 조회 범위가 달라질 수 있습니다. 임시 대체 근무, 겸직, 퇴사자 업무 이관처럼 실제 운영에서 발생할 상황도 고려해야 합니다.

승인 절차와 상태값은 함께 설계해야 합니다

승인 기능을 “승인 버튼 하나”로 정의하면 실제 업무를 충분히 반영하기 어렵습니다.

ERP에는 다음과 같은 여러 단계가 존재할 수 있습니다.

``text 임시 저장 → 승인 요청 → 팀장 검토 → 임원 승인 → 주문 확정 → 출고 준비 → 출고 완료 → 정산 대기 → 정산 완료 ``

각 단계에서는 처리할 수 있는 기능이 달라집니다.

예를 들어 승인 요청 전에는 상품과 수량을 자유롭게 수정할 수 있지만, 승인 이후에는 수정이 제한될 수 있습니다. 출고가 시작된 주문은 취소 대신 반품 절차를 거쳐야 할 수 있습니다. 정산이 완료된 데이터는 일반 사용자가 변경할 수 없도록 제한해야 할 수도 있습니다.

상태값을 설계할 때는 다음 질문을 확인해야 합니다.

이 상태로 변경할 수 있는 담당자는 누구인가?
변경 전에 충족해야 하는 조건은 무엇인가?
상태가 변경되면 어떤 알림을 보내는가?
다음 담당자에게 업무가 자동 배정되는가?
이전 상태로 되돌릴 수 있는가?
되돌릴 때 사유와 승인 절차가 필요한가?
상태 변경 후 다른 시스템에 데이터를 전송하는가?
취소·반려·보류는 각각 어떤 의미인가?
일부 수량만 처리된 경우 어떤 상태로 표시하는가?

특히 주문, 출고, 결제, 정산 상태를 하나의 값으로 합치면 관리가 어려워질 수 있습니다.

한 주문 안에서도 출고는 완료됐지만 결제는 일부만 완료될 수 있습니다. 일부 상품은 출고됐지만 나머지는 재고 부족으로 대기할 수도 있습니다. 따라서 업무 성격이 다른 상태는 분리하고, 화면에서 종합적으로 보여주는 방식을 검토하는 것이 좋습니다.

회계·영업·재고 시스템 연동 전 확인할 항목

기존 시스템 연동 범위를 정할 때는 시스템 이름보다 주고받을 데이터와 업무 결과를 기준으로 확인해야 합니다.

회계 시스템 연동

매출·매입 전표를 어떤 시점에 전달하는가?
주문일, 출고일, 세금계산서 발행일 중 어떤 날짜를 기준으로 하는가?
거래처 코드와 계정과목은 어떻게 연결하는가?
수정·취소 전표를 어떻게 전달하는가?
회계 시스템에서 확정된 결과를 ERP로 다시 가져오는가?
전송 실패 시 담당자가 어디에서 확인하는가?

영업·CRM 시스템 연동

고객과 거래처 중 어느 단위로 연결하는가?
담당자 변경을 어느 시스템에서 처리하는가?
상담 이력과 확정 주문을 모두 가져오는가?
견적 버전과 승인 결과를 어떻게 구분하는가?
중복된 고객과 거래처를 어떻게 정리하는가?

재고·물류 시스템 연동

현재고, 가용재고, 안전재고 중 어떤 값을 전달하는가?
창고별 재고를 구분해야 하는가?
주문 접수 시 재고를 즉시 차감하는가?
출고 확정 시점에 차감하는가?
취소·반품·교환 재고를 어떻게 반영하는가?
송장과 배송 상태를 어느 주기로 가져오는가?

쇼핑몰·B2B 주문 시스템 연동

상품과 옵션의 식별자를 어떻게 연결하는가?
채널별 판매 가격과 할인 금액을 어떻게 처리하는가?
결제 완료 주문만 가져오는가?
품절이나 주문 취소를 어느 시스템에서 확정하는가?
ERP의 재고를 외부 판매 채널에 얼마나 자주 전달하는가?

연동 시스템이 많아질수록 모든 데이터를 실시간으로 처리하는 것이 반드시 좋은 것은 아닙니다. 재고처럼 빠른 반영이 필요한 데이터가 있는 반면, 전표나 정산처럼 일정 시간마다 모아서 처리해도 되는 데이터도 있습니다.

업무상 필요한 속도와 외부 시스템의 처리 한도, 오류가 발생했을 때의 영향도를 함께 고려해야 합니다.

데이터 이전은 ‘모두 옮기기’보다 운영에 필요한 범위를 정합니다

기존 엑셀과 시스템 데이터를 새 ERP로 이전할 때 과거 데이터를 전부 옮기려고 하면 정제 범위가 커질 수 있습니다.

오래된 데이터에는 다음과 같은 문제가 남아 있을 가능성이 있습니다.

같은 거래처가 여러 이름으로 등록됨
사용하지 않는 상품과 거래처가 그대로 남아 있음
담당자마다 코드 작성 방식이 다름
날짜와 금액 형식이 일정하지 않음
필수값이 비어 있음
삭제된 담당자의 이름만 기록되어 있음
주문 상태와 실제 처리 결과가 맞지 않음
출고 수량과 재고 변동 내역이 연결되지 않음

따라서 데이터 이전 범위를 다음과 같이 구분할 수 있습니다.

반드시 이전할 데이터

현재 사용 중인 거래처와 공급처
판매·구매 중인 상품과 품목
현재고와 창고 정보
미출고 주문과 미입고 발주
미수금·미지급금 등 진행 중인 잔액
현재 수행 중인 프로젝트
운영에 필요한 조직과 사용자

조건에 따라 이전할 데이터

최근 몇 년의 주문·매출 이력
거래처별 단가 변경 이력
완료된 프로젝트와 계약 문서
과거 재고 이동 이력
결재와 변경 이력

별도 보관을 검토할 데이터

오래된 완료 거래
사용이 중단된 품목
중복되거나 품질이 낮은 데이터
법적 보관만 필요하고 일상 업무에서는 조회하지 않는 데이터

Microsoft는 ERP 데이터 이전 범위를 환경 설정 데이터, 고객·상품·공급처 같은 기준정보, 진행 중인 주문·재고·잔액 등의 거래 데이터로 구분해 설명합니다. 데이터의 성격을 나누면 이전 우선순위와 검증 기준을 정하기 쉬워집니다. (learn.microsoft.com)

데이터 이전은 한 번의 파일 업로드로 끝나는 작업이 아닙니다.

필드 연결, 코드 변환, 중복 제거, 오류 검증, 건수와 금액 대조가 필요합니다. 운영 전에는 실제와 유사한 데이터로 여러 차례 이전을 테스트하고, 이전 전후의 거래처 수·재고 수량·미처리 주문·잔액이 맞는지 확인해야 합니다.

Microsoft의 운영 전환 지침에서도 실제 전환 전에 데이터 이전을 반복 테스트하고, 데이터 손상과 중복 문제, 이전 소요 시간, 검증 절차를 확인하도록 권고합니다. (learn.microsoft.com)

오류 대응과 관리자 운영 기능도 ERP개발 범위입니다

ERP 견적에서 사용자 화면과 업무 기능만 확인하면 운영에 필요한 기능이 빠질 수 있습니다.

실제 운영에서는 정상 처리보다 다음과 같은 예외 상황에 더 많은 시간이 들 수 있습니다.

외부 시스템으로 전송하지 못한 주문
상품 코드가 연결되지 않은 데이터
승인자를 찾지 못한 결재 요청
중복 등록된 거래처
재고가 부족해 일부만 출고된 주문
잘못된 상태로 변경된 정산 건
데이터 이전 중 누락된 레코드
담당자 퇴사로 처리자가 없는 업무

운영자가 이러한 문제를 직접 확인하고 조치할 수 있어야 매번 개발자에게 데이터 수정을 요청하지 않아도 됩니다.

ERP 관리자 기능에는 다음 항목을 검토할 수 있습니다.

사용자와 역할·권한 관리
거래처·품목 등 기준정보 관리
업무별 검색과 상세 필터
미처리·지연·오류 건 조회
외부 연동 성공·실패 이력
실패 데이터 재전송
데이터 일괄 등록과 다운로드
승인자와 담당자 변경
상태 수동 조정과 사유 기록
주요 데이터 변경 이력
공통 코드와 업무 설정 관리
대시보드와 운영 현황 조회

관리자 기능은 모든 데이터를 자유롭게 바꾸는 도구가 되어서는 안 됩니다.

정산 완료 데이터나 회계와 연결된 전표처럼 영향이 큰 정보는 수정 권한을 제한하고, 변경 사유와 이전 값을 남겨야 합니다. 삭제가 필요한 경우에도 실제 데이터를 즉시 제거하기보다 사용 중단, 취소, 보관 상태로 전환하는 방식을 검토할 수 있습니다.

전면 구축과 단계적 구축을 결정하는 기준

ERP 범위를 한 번에 모두 구축하면 부서 간 데이터 연결을 전체적으로 설계하기 쉽다는 장점이 있습니다. 하지만 초기 범위가 커지고, 사용자 교육과 데이터 전환 부담도 함께 늘어날 수 있습니다.

단계적으로 구축하면 가장 불편한 업무부터 개선하면서 실제 사용 결과를 다음 개발에 반영할 수 있습니다. 반면 초기 데이터 구조를 임시로 만들면 이후 확장할 때 다시 개발해야 할 수 있습니다.

따라서 단계적 구축은 단순히 기능을 조금씩 추가하는 방식이 아니라, 전체 데이터 구조와 연동 방향을 먼저 설계한 뒤 공개 순서를 나누는 방식으로 접근해야 합니다.

예를 들어 다음과 같이 구분할 수 있습니다.

1차 구축 범위

거래처·상품·조직 기준정보
사용자와 역할별 권한
견적·주문·발주 핵심 흐름
기본 승인 절차
재고 입출고와 현재고
기존 회계 시스템에 필요한 데이터 전달
운영자용 조회·오류 확인 기능
핵심 데이터 이전

2차 확장 범위

거래처별 가격 정책 자동화
다단계 승인과 대결 기능
생산·물류 시스템 추가 연동
정산 자동화
고급 통계와 경영 대시보드
모바일 승인 기능
반복 업무 알림과 자동 배정
여러 지점과 법인 통합 관리

1차 범위에는 예쁜 대시보드보다 실제 거래가 시작되고 처리되어 다음 시스템으로 전달되는 흐름이 포함되어야 합니다.

예를 들어 주문 관리가 핵심이라면 거래처와 상품 등록, 주문 접수, 승인, 재고 확인, 출고, 회계 전달까지 최소한의 운영 단위가 이어져야 합니다. 주문 등록 화면만 먼저 만들고 출고와 정산을 계속 엑셀로 처리하면 시스템과 수작업 사이의 중복 입력이 남게 됩니다.

ERP개발 견적은 같은 범위로 비교해야 합니다

ERP개발 업체마다 총견적이 다른 이유는 기술력이나 단가 차이만이 아닙니다. 각 업체가 포함한 범위가 다를 수 있습니다.

한 업체는 사용자 화면과 기본 등록 기능만 포함하고, 다른 업체는 데이터 이전, 연동 오류 처리, 관리자 기능과 운영 배포까지 포함할 수 있습니다.

견적서를 비교할 때는 다음 항목을 같은 기준으로 확인해야 합니다.

| 구분 | 확인할 내용 | |---|---| | 업무 분석 | 현행 업무와 개선 업무 정리가 포함되는가 | | 기획 | 화면 목록 외에 권한·상태·예외 처리를 설계하는가 | | 디자인 | ERP 사용자 화면과 관리자 화면이 모두 포함되는가 | | 개발 | 프론트엔드·백엔드·데이터베이스 범위가 명확한가 | | 권한 | 역할별 조회·등록·수정·승인 권한이 포함되는가 | | 승인 | 승인 단계와 반려·취소·재요청이 포함되는가 | | 연동 | 대상 시스템과 데이터별 개발 범위가 명시되는가 | | 오류 처리 | 로그, 재시도, 관리자 재처리가 포함되는가 | | 데이터 이전 | 대상 데이터, 정제, 테스트 이전이 포함되는가 | | 테스트 | 단위·통합·사용자 검수 범위가 정해져 있는가 | | 배포 | 서버 구성과 운영 환경 반영이 포함되는가 | | 인수인계 | 소스코드·서버·계정·문서의 인계 조건이 있는가 | | 유지보수 | 하자 수정과 추가 개발 기준이 구분되는가 |

총액만 비교하기보다 각 항목의 포함·제외 조건과 결과물을 확인해야 합니다.

“회계 시스템 연동 포함”이라고 적혀 있어도 단방향 전표 전송만 포함하는지, 결과 수신과 실패 재처리까지 포함하는지에 따라 실제 범위는 달라질 수 있습니다.

ERP개발 업체 문의 전 준비하면 좋은 자료

완성된 요구사항 정의서가 없어도 상담은 가능합니다.

다만 다음 자료를 준비하면 현재 업무와 우선순위를 더 빠르게 설명할 수 있습니다.

1. 현재 업무 흐름

부서별로 업무가 시작되고 끝나는 순서를 적습니다.

``text 영업 견적 등록 → 팀장 승인 → 고객 주문 확정 → 재고 확인 → 구매 또는 출고 요청 → 출고 완료 → 회계 전표 전달 → 입금 확인 ``

2. 사용 중인 문서와 엑셀

견적서
발주서
거래명세서
재고 현황표
거래처 목록
상품 목록
정산표
승인 요청 양식
월별 보고서

실제 데이터가 포함된 파일을 외부에 전달할 때는 개인정보와 민감한 거래정보를 제거하거나 샘플 데이터로 바꾸는 것이 좋습니다.

3. 사용자와 역할

영업 담당자
팀장과 승인자
구매 담당자
물류·창고 담당자
회계·정산 담당자
지점 관리자
시스템 관리자
외부 거래처 사용자

역할별로 조회, 등록, 수정, 승인할 수 있는 업무를 간단히 정리합니다.

4. 기존 시스템 목록

회계 프로그램
그룹웨어와 전자결재
CRM
재고·물류 시스템
쇼핑몰과 B2B 주문 사이트
생산관리 시스템
결제·배송 서비스
사내 데이터베이스

시스템별 담당 업체, API 제공 여부, 데이터 내보내기 가능 여부, 계약 주체도 확인하면 좋습니다.

5. 반복적으로 발생하는 문제

같은 데이터를 여러 번 입력함
승인 지연을 확인하기 어려움
부서마다 거래처·상품 코드가 다름
재고가 맞지 않아 수기로 대조함
연동 실패를 담당자가 알기 어려움
변경 이력을 찾을 수 없음
보고서를 만들기 위해 매번 엑셀을 합침
특정 담당자만 전체 업무를 이해함

6. 1차 구축의 목표

“모든 업무를 ERP로 전환”하는 목표보다 측정 가능한 업무 목표가 좋습니다.

주문 정보를 회계 시스템에 중복 입력하지 않기
승인 대기 업무를 담당자별로 확인하기
거래처·상품 코드를 하나의 기준으로 통합하기
창고별 현재고와 가용재고를 구분하기
연동 실패 건을 운영자가 직접 재처리하기
주문부터 출고까지의 진행 상태를 한 화면에서 확인하기

ERP개발에서 먼저 결정해야 할 것은 제품이 아니라 업무 경계입니다

ERP개발을 검토할 때 처음부터 모든 업무를 새 시스템에 넣으려고 하면 범위가 빠르게 커집니다. 반대로 패키지에서 제공하는 기능만 기준으로 삼으면 회사의 핵심 업무가 시스템 밖에 남을 수 있습니다.

먼저 현재 업무를 다음 세 가지로 나눠보는 것이 좋습니다.

일반적인 방식으로 표준화할 수 있는 업무
회사의 계약·가격·승인·생산·정산 규칙 때문에 맞춤 개발이 필요한 업무
현재 시스템을 유지하면서 데이터를 연결할 업무

그다음 기준정보, 역할별 권한, 승인 단계, 상태값, 데이터 이전과 오류 대응 범위를 정리해야 합니다.

ERP는 사용자 화면만 만드는 프로젝트가 아닙니다. 여러 부서가 같은 데이터를 기준으로 업무를 이어갈 수 있도록 백엔드, 데이터베이스, 관리자 기능과 기존 시스템 연동을 함께 설계하는 프로젝트입니다.

원소프트는 웹·앱·관리자 시스템 개발과 외부 API·ERP 연동을 포함해 기획, UX/UI, 프론트엔드, 백엔드, 서버·데이터베이스, 배포와 유지보수를 프로젝트 범위에 따라 통합적으로 검토합니다.

ERP개발을 검토하고 있지만 패키지 도입과 맞춤 개발, 기존 시스템 연동 중 어느 방식이 적합한지 판단하기 어렵다면 현재 사용하는 엑셀과 시스템, 업무 흐름을 기준으로 1차 구축 범위를 먼저 정리할 수 있습니다.

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

제목 후보

ERP개발 외주 문의 전, 표준 기능·맞춤 업무·기존 시스템 연동을 나누는 방법
ERP개발, 패키지 도입과 맞춤 개발 범위를 구분하는 실무 기준
ERP개발 업체 상담 전, 업무·데이터·권한·연동 범위 정리하기
맞춤형 ERP개발이 필요한 업무와 기존 시스템 연동 기준
ERP개발 견적 비교 전, 표준·맞춤·연동 범위를 먼저 정하세요

메인 키워드

ERP개발

서브 키워드

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

썸네일 문구

ERP 업무 범위 나누기
표준·맞춤·연동 구분법
ERP 외주 전 체크리스트

글 요약

ERP개발 범위는 필요한 기능을 모두 나열하기보다 패키지의 표준 기능으로 처리할 업무, 회사 고유 규칙에 맞춰 개발할 업무, 기존 회계·영업·재고 시스템과 연동할 업무로 나눠야 합니다. 기준정보와 권한·승인·상태값, 데이터 이전, 연동 오류 대응과 관리자 기능을 정리한 뒤 1차 구축과 추후 확장 범위를 구분해야 업체별 견적을 같은 기준으로 비교할 수 있습니다.

CTA 후보

현재 사용 중인 엑셀과 시스템이 여러 곳에 나뉘어 있다면, 업무 흐름과 데이터 기준을 바탕으로 표준 기능·맞춤 개발·연동 범위를 함께 정리해드릴 수 있습니다.

ERP 전면 구축이 필요한지, 기존 회계·재고 시스템을 유지하면서 필요한 영역만 개발할 수 있는지 고민하고 계신다면 현재 업무와 1차 구축 목표를 기준으로 검토해보세요.

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

ERP연동 개발, 회계·재고·쇼핑몰 데이터의 기준 시스템을 정하는 방법
맞춤형 ERP개발 견적, 권한·승인·데이터 이전에서 비용 차이가 나는 이유
엑셀 업무를 ERP로 전환할 때 기준정보와 코드 체계를 정리하는 방법