ERP개발 외주 상담 전, 기존 업무를 표준·맞춤·연동으로 나누는 방법

“지금 쓰는 엑셀과 사내 프로그램을 하나로 합치고 싶습니다.”

“회계 프로그램은 그대로 두고 영업·재고·승인 업무만 새로 만들 수 있을까요?”

“패키지 ERP를 도입해야 할지, 우리 회사에 맞게 전부 개발해야 할지 모르겠습니다.”

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

이때 기존 업무를 모두 새 시스템에 넣으려고 하면 개발 범위가 빠르게 커집니다. 반대로 패키지 ERP의 기본 기능에 업무를 무리하게 맞추면 현장에서는 다시 엑셀과 메신저를 사용하게 될 수 있습니다.

ERP개발 외주 상담 전에 가장 먼저 할 일은 기능 목록을 만드는 것이 아닙니다.

현재 업무를 다음 세 가지로 나누는 작업이 먼저입니다.

표준 기능으로 처리할 업무
회사 운영 방식에 맞춰 개발할 업무
기존 시스템과 연결할 업무

이렇게 구분하면 패키지 ERP, 맞춤 개발, 시스템 연동 중 어떤 방식을 선택해야 하는지 판단하기 쉬워집니다. 개발사도 필요한 화면과 기능뿐 아니라 데이터 구조, 권한, 승인 절차, 연동 범위와 단계별 전환 계획을 구체적으로 검토할 수 있습니다.

ERP개발이 필요하다는 신호부터 확인해야 합니다

ERP라는 이름의 시스템을 새로 구축하는 것 자체가 목표가 되어서는 안 됩니다.

먼저 현재 운영에서 어떤 문제가 반복되는지 확인해야 합니다.

다음과 같은 상황이라면 ERP개발이나 기존 업무 시스템 개선을 검토할 수 있습니다.

영업, 구매, 재고, 생산, 정산 자료가 서로 다른 엑셀에 저장되어 있다.
같은 거래처와 상품 정보를 여러 부서가 각각 입력한다.
발주서, 견적서, 주문서의 품목명과 코드가 서로 다르다.
담당자에게 물어봐야 주문이나 업무의 현재 상태를 알 수 있다.
승인 요청과 결과가 메신저나 이메일에 흩어져 있다.
회계 프로그램의 매출 데이터와 영업팀의 실적 데이터가 맞지 않는다.
월말마다 여러 파일을 취합해 보고서를 다시 만든다.
담당자가 자리를 비우면 업무 처리 기준을 알기 어렵다.
기존 시스템에 필요한 기능을 추가하기 어려워 별도 프로그램이 계속 늘어난다.
수정 권한과 승인 권한이 구분되지 않아 데이터 오류를 추적하기 어렵다.

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

예를 들어 회계와 세무 업무는 현재 사용 중인 솔루션으로 충분하지만, 영업 견적과 주문 승인 과정만 회사 고유의 절차를 따를 수도 있습니다. 이 경우 회계까지 다시 만드는 것보다 주문·승인 시스템을 별도로 구축하고 필요한 결과만 회계 시스템과 연결하는 편이 현실적일 수 있습니다.

ERP개발의 범위는 ‘어떤 메뉴가 필요한가’보다 ‘어떤 업무를 유지하고, 무엇을 바꾸며, 어디까지 연결할 것인가’에서 결정됩니다.

단순한 솔루션 도입만으로 해결하기 어려운 업무

패키지 ERP는 회계, 영업, 구매, 재고처럼 여러 기업에서 공통으로 사용하는 업무를 일정한 구조로 제공합니다.

표준 기능을 활용하면 검증된 업무 구조를 사용할 수 있고, 처음부터 모든 기능을 개발하는 부담도 줄일 수 있습니다. 실제 ERP 구현 방법론에서도 먼저 표준 프로세스가 기업 요구사항에 맞는지 검토한 후, 표준으로 해결되지 않는 차이만 별도 요구사항으로 정리하는 방식이 활용됩니다. SAP의 Fit-to-Standard 접근도 표준 프로세스를 우선 검토하고 필요한 차이를 요구사항으로 분리하도록 안내합니다. (learning.sap.com)

하지만 다음과 같은 업무는 패키지 설정만으로 맞추기 어려울 수 있습니다.

거래처 등급마다 가격과 할인 기준이 다르다.
주문 금액, 품목 또는 거래처에 따라 승인 단계가 달라진다.
재고가 단순 수량이 아니라 예약, 검사, 불량, 출고 대기 상태로 나뉜다.
상품이 아닌 프로젝트나 계약 단위로 매출과 비용을 관리한다.
현장 직원, 협력사, 본사 운영자가 서로 다른 화면과 권한을 사용한다.
고객 주문이 접수된 뒤 여러 부서의 검토와 배정을 거친다.
문서 인식, 모바일 현장 입력, 외부 장비 연동 등 별도 기능이 필요하다.
기존 회계·생산·물류 시스템을 중단할 수 없어 양방향 연동이 필요하다.

이때 패키지를 무조건 포기할 필요는 없습니다.

표준 기능은 패키지 ERP에서 처리하고, 회사 고유 업무는 별도의 웹 시스템이나 관리자 시스템으로 구현한 뒤 API나 파일 교환 방식으로 연결할 수 있습니다. 복잡한 확장 기능을 ERP 핵심 영역과 분리하면 향후 버전 변경과 유지보수의 부담을 줄이는 데도 도움이 됩니다. SAP 역시 복잡한 확장 기능을 표준 ERP 핵심 코드와 분리하는 방식을 권장하고 있습니다. (help.sap.com)

현재 업무를 표준·맞춤·연동으로 나누는 방법

ERP개발 상담 전에 부서별 기능을 바로 나열하기보다, 실제 업무를 처음부터 끝까지 따라가며 구분하는 것이 좋습니다.

예를 들어 기업의 주문 업무를 다음과 같이 적어볼 수 있습니다.

거래처 등록 → 견적 작성 → 내부 승인 → 고객 확정 → 주문 등록 → 재고 확인 → 출고 요청 → 세금계산 및 회계 반영 → 정산 확인

그다음 각 단계를 표준 업무, 맞춤 업무, 연동 업무 중 하나로 분류합니다.

| 구분 | 판단 기준 | 예시 | |---|---|---| | 표준 업무 | 여러 기업에서 유사하게 사용하는 업무 | 거래처 등록, 품목 등록, 일반 매입·매출, 기본 재고 입출고 | | 맞춤 업무 | 회사의 경쟁력이나 운영 방식에 직접 연결된 규칙 | 거래처별 가격, 다단계 승인, 프로젝트별 원가, 특수 배정 로직 | | 연동 업무 | 이미 사용 중인 시스템의 기능이나 데이터를 유지해야 하는 영역 | 회계 전표 연동, 쇼핑몰 주문 수집, 물류·배송 연동, 그룹웨어 승인 연동 |

이 분류는 시스템 종류가 아니라 업무 단위로 해야 합니다.

예를 들어 재고 업무 전체를 맞춤 개발로 분류할 필요는 없습니다.

품목과 창고 등록은 표준 기능
거래처별 판매 가능 재고 계산은 맞춤 기능
물류센터의 실제 출고 결과 수신은 연동 기능

이처럼 하나의 업무 영역 안에서도 세 가지 방식이 함께 사용될 수 있습니다.

1. 표준 업무는 기존 방식을 유지해야 하는지부터 질문합니다

현재 회사에서 오랫동안 사용해 온 방식이라고 해서 반드시 새 ERP에도 그대로 구현해야 하는 것은 아닙니다.

다음 질문으로 표준화 가능성을 판단해볼 수 있습니다.

이 절차가 법적·계약상 반드시 필요한가?
고객이 요구하는 방식인가?
회사의 경쟁력과 직접 연결되는가?
단순히 기존 시스템의 불편 때문에 생긴 절차는 아닌가?
특정 담당자만 익숙한 방식은 아닌가?
패키지 ERP의 설정과 기본 기능으로 대체할 수 있는가?
이 절차를 단순화해도 업무 결과에 문제가 없는가?

예를 들어 모든 주문을 출력한 뒤 담당자가 수기로 확인하는 절차가 있을 수 있습니다.

이를 그대로 전자문서 출력 기능으로 옮기는 것이 맞춤 개발은 아닙니다. 실제 목적이 ‘주문 누락 방지’라면 미처리 주문 목록, 담당자 배정, 상태별 알림과 마감 대시보드가 더 적합할 수 있습니다.

ERP개발은 기존 수작업을 화면으로 복사하는 프로젝트가 아니라, 현재 업무의 목적을 확인하고 더 단순한 흐름으로 재구성하는 과정이 되어야 합니다.

2. 맞춤 개발은 ‘다른 회사와 무엇이 다른가’로 판단합니다

맞춤 개발이 필요한 업무는 단순히 복잡한 업무가 아닙니다.

회사별로 규칙이 달라 표준 기능에 맞추기 어렵거나, 사업 운영에 직접 영향을 주는 업무가 맞춤 개발의 후보입니다.

예를 들어 다음과 같은 요구사항입니다.

거래처 계약 조건에 따라 상품별 가격이 자동으로 계산된다.
견적 금액과 마진율에 따라 승인권자가 달라진다.
주문이 들어오면 지역, 담당자 일정, 재고 상태를 고려해 배정한다.
프로젝트별 계약금·중도금·잔금과 비용을 연결해 수익성을 확인한다.
입고된 상품이 검수 전, 정상, 불량, 반품 예정 상태로 나뉜다.
협력사가 직접 작업 결과와 증빙 문서를 등록한다.
특정 상태가 되면 다음 부서의 업무가 자동으로 생성된다.

맞춤 개발 범위를 정할 때는 화면 이름보다 규칙을 구체적으로 적어야 합니다.

예를 들어 ‘주문 승인 기능’이라고만 작성하면 다음 내용이 빠질 수 있습니다.

누가 승인을 요청하는가?
어떤 조건에서 승인이 필요한가?
승인자는 한 명인가, 여러 명인가?
순차 승인인가, 병렬 승인인가?
승인자가 부재하면 대결 권한이 있는가?
반려할 때 사유 입력이 필요한가?
승인 후 주문이 변경되면 재승인이 필요한가?
긴급 주문은 별도 절차를 사용하는가?
승인 이력은 언제까지 보관해야 하는가?

이 질문에 대한 답이 실제 개발 범위가 됩니다.

3. 연동 업무는 어느 시스템이 원본인지 정해야 합니다

기존 회계, 영업, 재고, 쇼핑몰, 그룹웨어 또는 생산 시스템을 유지한다면 데이터별 기준 시스템을 먼저 정해야 합니다.

연동한다고 해서 두 시스템의 데이터를 항상 동일하게 수정할 수 있어야 하는 것은 아닙니다. 양쪽에서 같은 데이터를 수정할 수 있게 만들면 충돌과 중복이 발생할 수 있습니다.

다음과 같이 데이터별 원본을 정리하는 것이 좋습니다.

| 데이터 | 기준 시스템 예시 | 다른 시스템의 역할 | |---|---|---| | 거래처 기본정보 | ERP | 영업 시스템에서 조회 | | 상품 정보 | 상품관리 시스템 | ERP와 쇼핑몰로 전달 | | 계약별 판매가격 | B2B 주문 시스템 | 주문 시 계산에 사용 | | 실제 재고 | ERP 또는 물류 시스템 | 웹·앱에서 조회 | | 주문 접수 | 쇼핑몰 또는 주문 시스템 | ERP로 전달 | | 회계 전표 | 회계 시스템 | ERP 또는 업무 시스템에서 결과 조회 | | 배송 상태 | 택배·물류 시스템 | 고객 화면과 관리자에 반영 |

외부 시스템과 연동할 때는 데이터 방향, 전달 시점, 실패 처리와 재처리 방식까지 함께 정해야 합니다. 공식 ERP 구현 가이드에서도 연동의 보안, 가용성, 복구 조건과 실제 상황을 반영한 통합 테스트를 계획하도록 안내합니다. (learn.microsoft.com)

특히 다음 항목이 정해져야 견적 범위를 비교할 수 있습니다.

실시간으로 연결할지, 일정 시간마다 동기화할지
전체 데이터를 보낼지, 변경된 데이터만 보낼지
한 방향으로 전달할지, 양방향으로 수정할지
거래처·상품·주문을 연결하는 고유 식별자는 무엇인지
양쪽 시스템의 상태값이 다르면 어떻게 변환할지
연동 실패 시 자동으로 재시도할지
운영자가 실패 내역을 확인하고 재처리할 수 있는지
중복 요청이 들어와도 한 번만 처리되게 할지
외부 시스템이 중단되면 내부 업무를 어디까지 진행할지

단순히 “ERP API 연동 포함”이라고 적힌 견적만으로는 이러한 범위를 알기 어렵습니다.

회계·영업·재고 연동 전에 기준정보를 먼저 정해야 합니다

ERP개발에서는 화면보다 기준정보 정리가 먼저 필요할 수 있습니다.

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

대표적으로 다음과 같은 항목이 있습니다.

거래처
고객과 공급사
품목과 상품
품목 분류
단위
창고와 위치
부서와 조직
담당자
프로젝트
계약
세금 코드
결제 조건
통화
상태 코드

문제는 기존 시스템마다 같은 대상을 다른 이름과 코드로 관리하는 경우입니다.

영업팀에서는 ‘A상사’, 회계 프로그램에서는 ‘주식회사 A상사’, 물류 시스템에서는 ‘A-001’로 저장되어 있을 수 있습니다. 이 상태에서 시스템만 연결하면 같은 거래처가 여러 건으로 생성되거나 매출과 수금 자료가 맞지 않을 수 있습니다.

ERP 구현 가이드에서도 통화·세금 코드와 같은 환경 설정 데이터와 고객·상품·거래처 같은 이전 데이터를 구분하고, 원본과 대상 시스템 사이의 필드 및 값 매핑을 계획하도록 안내합니다. (learn.microsoft.com)

따라서 개발 전에는 다음 내용을 정리해야 합니다.

각 기준정보를 어느 시스템에서 생성할지
코드 생성 규칙은 무엇인지
중복 데이터를 어떻게 판단할지
사용 중지된 데이터도 이전할지
과거 코드와 새 코드를 어떻게 연결할지
부서별로 서로 다른 명칭을 통일할지
시스템 간 데이터 전달이 실패하면 누가 확인할지

기준정보가 정리되지 않으면 주문, 재고, 정산과 통계의 정확성도 확보하기 어렵습니다.

사용자 권한은 메뉴 접근보다 업무 행위로 설계해야 합니다

ERP에는 영업 담당자, 부서장, 구매 담당자, 창고 담당자, 회계 담당자, 경영진, 시스템 관리자 등 여러 사용자가 참여합니다.

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

권한은 다음처럼 행위 단위로 구분하는 것이 좋습니다.

조회
등록
수정
삭제
승인 요청
승인
반려
확정 취소
엑셀 다운로드
금액 조회
개인정보 조회
다른 부서 데이터 조회
변경 이력 조회
연동 데이터 재전송

예를 들어 영업 담당자는 자신의 견적을 작성하고 수정할 수 있지만, 승인된 견적의 단가를 임의로 바꿀 수 없도록 해야 할 수 있습니다.

부서장은 소속 부서의 주문을 승인할 수 있지만 다른 부서의 고객 정보는 볼 필요가 없을 수 있습니다. 회계 담당자는 확정된 매출 자료를 조회할 수 있지만 영업 진행 중인 견적을 수정해서는 안 됩니다.

역할 기반 권한은 단순한 화면 숨김과도 다릅니다. 사용자가 메뉴에 직접 접근하거나 API를 호출하더라도 서버에서 권한을 다시 확인해야 합니다. Microsoft의 ERP·CRM 구현 가이드 역시 사용자 또는 사용자 그룹에 부여된 보안 역할을 통해 데이터, 서비스, 메뉴와 기능에 대한 접근을 제어하도록 설명합니다. (learn.microsoft.com)

승인 절차와 업무 상태값을 함께 정의해야 합니다

ERP개발에서 자주 빠지는 항목 중 하나가 상태값입니다.

화면 목록에는 견적, 주문, 발주, 입고, 출고가 적혀 있어도 각 업무가 어떤 단계를 거치는지는 정리되지 않은 경우가 많습니다.

주문 하나도 다음과 같은 상태를 가질 수 있습니다.

``text 작성 중 → 승인 요청 → 검토 중 → 승인 → 재고 확인 → 출고 준비 → 출고 완료 → 매출 확정 → 정산 완료 ``

여기에 반려, 취소 요청, 부분 출고, 보류, 재처리 같은 예외 상태가 추가될 수 있습니다.

상태값을 정할 때는 상태 이름만 나열하지 말고 다음을 함께 정리해야 합니다.

누가 이 상태로 변경할 수 있는가?
어떤 조건을 충족해야 변경할 수 있는가?
다음으로 이동할 수 있는 상태는 무엇인가?
이전 단계로 되돌릴 수 있는가?
변경 시 알림이나 연동이 발생하는가?
변경된 시간과 작업자를 기록하는가?
상태 변경 후 수정 가능한 항목은 무엇인가?
외부 시스템 전송에 실패하면 내부 상태는 어떻게 표시하는가?

승인 절차 역시 업무 상태와 분리해서 생각하기 어렵습니다.

주문이 승인됐다고 바로 출고 가능한 것은 아닐 수 있습니다. 재고 확인, 결제 조건 검토, 고객 신용 확인과 같은 단계가 추가될 수 있기 때문입니다.

따라서 승인 버튼 하나를 만드는 것이 아니라 승인 전후의 업무 흐름을 설계해야 합니다.

기존 데이터는 ‘전부 이전’보다 사용 목적에 따라 나눕니다

기존 ERP, 엑셀과 사내 프로그램에 오랜 기간 축적된 데이터를 모두 새 시스템으로 이전하려 하면 프로젝트 일정과 테스트 범위가 크게 늘어날 수 있습니다.

데이터는 다음처럼 구분해볼 수 있습니다.

반드시 이전할 데이터

현재 거래 중인 거래처
판매 또는 구매 중인 품목
현재 재고
진행 중인 주문과 발주
미수금과 미지급금
유효한 계약
처리 중인 프로젝트

필요 여부를 검토할 데이터

최근 일정 기간의 주문과 매출
종료된 계약
사용 중지된 품목
과거 재고 이동 이력
이전 담당자의 활동 기록

별도 보관을 검토할 데이터

오래된 완료 거래
확인이 어려운 중복 거래처
형식이 일정하지 않은 메모
더 이상 사용하지 않는 첨부파일
업무 활용도가 낮은 과거 로그

과거 데이터 전체를 새 ERP 구조에 맞추는 것보다 조회 전용 데이터베이스나 기존 시스템을 일정 기간 유지하는 방식이 적합할 수도 있습니다.

데이터 이전 범위가 정해지면 다음 작업이 필요합니다.

원본 데이터 추출
중복과 오류 확인
새 구조에 맞는 필드 매핑
코드와 상태값 변환
시험 이전
사용자 검증
실제 전환 전 최종 이전
이전 결과 대조

Microsoft의 구현 지침도 데이터 이전을 원본 조사, 범위와 전략 수립, 필드 매핑, 변환, 적재, 검증이 필요한 별도 프로젝트 활동으로 설명하며 시스템 통합 테스트와 사용자 인수 테스트 환경에서 이전 절차를 검증하도록 권고합니다. (learn.microsoft.com)

업무 중단을 줄이려면 단계적으로 구축해야 합니다

모든 부서와 기능을 한 번에 새 ERP로 전환하면 부서 간 의존성과 연동 범위가 커집니다.

초기에는 다음 기준으로 1차 구축 범위를 정할 수 있습니다.

현재 수작업과 중복 입력이 가장 많은 업무
데이터 오류가 반복되는 업무
담당자 의존도가 높은 업무
다른 부서 업무의 시작점이 되는 영역
매출, 재고와 정산에 직접 영향을 주는 업무
비교적 독립적으로 전환할 수 있는 업무

예를 들어 다음과 같은 단계로 구성할 수 있습니다.

1단계: 기준정보와 핵심 접수 업무

거래처
품목
조직과 사용자
영업 견적
주문 접수
기본 승인

2단계: 구매·재고·출고 연결

발주
입고
창고별 재고
재고 이동
출고 요청과 처리

3단계: 회계·정산 연동

매출·매입 자료 전송
수금·지급 결과 수신
세금계산 관련 데이터
거래처별 정산 현황

4단계: 통계와 자동화

부서별 실적
프로젝트별 손익
재고 회전 분석
지연 업무 알림
반복 보고서 자동화

단계적 구축은 기능을 나중으로 미루는 것만을 의미하지 않습니다.

각 단계에서 실제 업무를 끝까지 처리할 수 있어야 합니다. 주문 입력 화면만 먼저 만들고 승인과 출고 처리를 다시 엑셀로 관리한다면 이중 입력이 늘어날 수 있습니다.

또한 단계별 배포에는 교육, 데이터 이전, 기존 시스템 병행 기간, 장애 시 복구 방법과 다음 단계 반영 계획이 필요합니다. 공식 구현 가이드도 단계별 출시에서 각 배포의 경험을 다음 계획에 반영하고, 구축팀에서 운영 지원팀으로 지식을 이전할 계획을 준비하도록 안내합니다. (learn.microsoft.com)

ERP개발 외주 상담 전에 준비할 자료

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

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

1. 업무 흐름 자료

문서 형식보다 실제 순서가 중요합니다.

``text 고객 요청 접수 → 담당자 견적 작성 → 팀장 승인 → 고객 확정 → 주문 등록 → 재고 확인 → 출고 요청 → 회계 시스템 매출 반영 ``

정상 흐름뿐 아니라 반려, 취소, 수정, 부분 처리 같은 예외 상황도 함께 적어두는 것이 좋습니다.

2. 현재 사용하는 화면과 문서

기존 ERP 화면
사내 프로그램 화면
엑셀 양식
견적서와 발주서
승인 요청 문서
월별 보고서
거래처가 작성하는 양식
운영자가 반복 작성하는 자료

개인정보와 민감한 거래 정보는 가린 뒤 전달할 수 있습니다.

3. 사용자와 권한 목록

부서명만 나열하기보다 각 사용자가 무엇을 조회하고 처리하는지 적어야 합니다.

| 사용자 | 주요 업무 | 필요한 권한 | |---|---|---| | 영업 담당자 | 견적·주문 작성 | 담당 거래처 조회, 작성 중 문서 수정 | | 영업 관리자 | 견적 검토 | 부서 문서 조회, 승인·반려 | | 창고 담당자 | 입출고 처리 | 재고 조회, 출고 확정 | | 회계 담당자 | 매출·수금 확인 | 확정 자료 조회, 회계 연동 확인 | | 시스템 관리자 | 계정과 코드 관리 | 사용자·권한·기준정보 관리 |

4. 데이터 샘플

거래처 목록
품목 목록
주문 내역
재고 파일
상태 코드
조직 정보
기존 시스템에서 추출한 파일 형식

실제 데이터 구조를 확인하면 이전과 연동의 난이도를 보다 구체적으로 판단할 수 있습니다.

5. 연동 자료

연동 대상이 있다면 다음 내용을 준비합니다.

시스템명과 운영 주체
API 문서 제공 여부
데이터베이스 직접 접근 가능 여부
파일 가져오기·내보내기 지원 여부
테스트 계정과 테스트 환경 제공 여부
연동할 데이터와 전달 주기
상대 시스템 업체와 협의할 담당자
보안과 네트워크 제한 사항

API가 있다고 해서 필요한 기능이 모두 제공되는 것은 아닙니다. 외주 상담 단계에서 실제 제공 범위와 호출 조건을 확인해야 합니다.

6. 우선순위

각 기능을 다음과 같이 구분할 수 있습니다.

1차 오픈에 반드시 필요
있으면 운영 효율이 좋아짐
데이터가 쌓인 후 검토 가능
기존 시스템으로 당분간 처리 가능

고급 통계, 복잡한 자동 배정, AI 예측처럼 초기 데이터가 부족하거나 업무 규칙이 확정되지 않은 기능은 후속 단계로 분리할 수 있습니다.

ERP개발 견적서에서 확인할 범위

개발사별 견적을 비교할 때 총액만 보면 범위 차이를 놓치기 쉽습니다.

최소한 다음 항목이 포함되어 있는지 확인하는 것이 좋습니다.

기획 범위

현행 업무 분석
업무 흐름 정리
화면과 기능 정의
사용자·권한 설계
상태와 승인 절차 정리
데이터와 연동 범위 정의

디자인 범위

사용자용 화면
관리자·업무 화면
반응형 지원 여부
디자인 시안과 수정 횟수
공통 UI 구성

개발 범위

프론트엔드
백엔드와 API
데이터베이스
사용자 인증
권한 관리
업무 상태와 승인
검색·필터·다운로드
알림
변경 이력
관리자 기능

데이터 이전 범위

이전 대상 데이터
데이터 정제 책임
필드와 코드 매핑
시험 이전 횟수
최종 이전 방식
이전 결과 검증 주체

외부 시스템 연동 범위

연동 대상
전송 방향과 주기
인증 방식
실패 재시도
중복 방지
로그와 모니터링
운영자 재처리
상대 시스템 변경 시 대응 범위

테스트와 배포 범위

기능 테스트
통합 테스트
사용자 인수 테스트 지원
운영 환경 구성
서버와 데이터베이스 배포
보안 설정
데이터 백업
오픈 당일 지원
장애 발생 시 복구 계획

개발, 테스트, 교육과 데이터 이전에는 서로 다른 환경이 필요할 수 있으며, 운영 환경 구성과 접근 권한을 뒤늦게 정하면 일정에 영향을 줄 수 있습니다. Microsoft도 ERP 구현에서 개발·테스트·교육·데이터 이전에 필요한 환경과 역할별 접근 권한을 프로젝트 초기에 계획할 것을 안내합니다. (learn.microsoft.com)

인수인계와 유지보수 범위

소스코드 제공 여부
서버와 클라우드 계정 소유 주체
데이터베이스 접근 권한
배포 절차 문서
API 문서
관리자 매뉴얼
운영자 교육
하자 수정 기간과 기준
유지보수 응답 시간
기능 추가의 산정 방식
외부 서비스 비용과 갱신 책임

ERP는 오픈 후에도 조직 변경, 신규 상품, 거래처 정책, 승인 기준과 연동 대상이 바뀔 수 있습니다. 따라서 개발 완료 조건뿐 아니라 변경 요청과 운영 지원 방식도 계약 전에 확인해야 합니다.

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

원소프트는 웹·앱·AI 및 관리자 시스템을 개발하며, 사용자 화면만이 아니라 운영자의 업무 흐름과 데이터 구조를 함께 검토합니다.

ERP개발이나 업무 시스템 구축에서도 현재 사용하는 메뉴를 그대로 복제하기보다 다음 내용을 먼저 확인합니다.

업무가 시작되고 종료되는 기준
사용자 유형과 역할
승인과 상태 변경 조건
여러 부서가 공유하는 기준정보
기존 시스템에서 유지할 기능
새로 개발할 고유 업무
외부 시스템과 연결할 데이터
실패와 예외 상황의 운영 방법
1차 구축과 후속 구축의 구분

원소프트가 개발한 바토너는 ERP 프로젝트는 아니지만, 경매 물건 조회부터 입찰 신청, 계약 문서, 결제, 포인트, 정산과 고객 문의를 하나의 업무 흐름으로 연결한 업무형 플랫폼입니다.

이 프로젝트에서는 일반 회원, 전문가, 운영자의 역할과 접근 범위를 구분하고, 입찰·계약·결제·정산의 진행 상태를 데이터로 관리했습니다. 또한 OCR, 결제, 푸시 알림을 연동하고 운영자가 회원·입찰·결제·정산·문의 데이터를 확인할 수 있는 관리자 기능을 구성했습니다.

이처럼 여러 담당자가 참여하고 업무 단계가 이어지는 시스템에서는 개별 화면보다 역할, 상태, 데이터와 외부 연동의 관계를 먼저 설계해야 합니다.

ERP개발 상담은 기능 수보다 업무 분류에서 시작해야 합니다

ERP개발은 패키지와 맞춤 개발 중 하나를 고르는 문제가 아닐 수 있습니다.

회계와 일반 재고처럼 표준화할 수 있는 업무는 검증된 기능을 활용하고, 회사의 가격 정책·승인·배정·정산처럼 고유한 업무는 별도로 개발하며, 기존 회계·물류·그룹웨어는 필요한 데이터만 연동하는 혼합 구조를 검토할 수 있습니다.

상담 전에는 다음 세 가지 질문부터 정리해보시기 바랍니다.

표준 방식으로 변경해도 되는 업무는 무엇인가?
회사 운영을 위해 반드시 유지해야 하는 고유 규칙은 무엇인가?
새로 만들지 않고 기존 시스템과 연결할 업무는 무엇인가?

여기에 기준정보, 사용자 권한, 승인 절차, 상태값, 데이터 이전과 단계적 전환 범위를 더하면 개발사와 훨씬 구체적인 상담이 가능합니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치한 웹·앱·업무 시스템 개발사입니다. ERP개발이나 기존 사내 시스템 개선을 검토하고 있다면 현재 사용 중인 엑셀, 업무 문서, 시스템 화면을 바탕으로 표준화할 업무와 맞춤 개발·연동이 필요한 범위를 함께 정리할 수 있습니다.

제목 후보

ERP개발 외주 상담 전, 기존 업무를 표준·맞춤·연동으로 나누는 방법
ERP개발 범위, 패키지 기능·맞춤 개발·기존 시스템 연동으로 구분하세요
ERP개발 견적 전 확인할 표준 업무·고유 업무·시스템 연동 기준
ERP개발, 회계·영업·재고 업무를 한 번에 다시 만들 필요는 없습니다
ERP개발 외주 범위 정하기, 패키지와 맞춤 개발을 함께 활용하는 기준

메인 키워드

ERP개발

서브 키워드

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

썸네일 문구

우리 업무, 전부 새로 개발해야 할까?
표준·맞춤·연동부터 구분하세요
ERP개발 외주 전 업무 분류법

글 요약

ERP개발은 모든 업무를 새로 만드는 것이 아니라, 현재 업무를 패키지의 표준 기능으로 처리할 영역, 회사 고유 규칙에 맞춰 개발할 영역, 기존 회계·영업·재고 시스템과 연동할 영역으로 나누는 것에서 시작해야 합니다. 기준정보, 사용자 권한, 승인과 상태값, 데이터 이전 및 단계적 구축 순서를 정리하고 외주 견적에서 테스트·배포·인수인계·유지보수 범위까지 확인하는 방법을 설명했습니다.

CTA 후보

현재 사용 중인 엑셀과 업무 문서, 기존 시스템 화면을 기준으로 표준 기능으로 처리할 업무와 별도 개발·연동이 필요한 범위를 함께 검토해드릴 수 있습니다.

ERP개발 전체 범위가 아직 정리되지 않았다면 가장 불편한 업무 흐름부터 공유해 주세요. 기존 시스템을 유지할 부분과 단계적으로 개선할 부분을 나누어 검토할 수 있습니다.

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

ERP 데이터 이전, 거래처·품목·재고 데이터를 정리하는 실무 방법
ERP 연동 개발, 회계·쇼핑몰·물류 시스템의 기준 데이터를 정하는 방법
맞춤형 ERP 관리자 화면, 권한·승인·변경 이력을 설계하는 기준