ERP개발, 업무를 멈추지 않고 단계적으로 구축하려면 무엇부터 정해야 할까요?

ERP 도입을 검토하는 기업에서는 비슷한 고민이 반복됩니다.

“지금 사용하는 엑셀과 기존 프로그램을 모두 바꿔야 할까요?”

“패키지 ERP를 도입하면 우리 회사의 승인 절차까지 반영할 수 있을까요?”

“재고부터 먼저 구축하고 회계나 정산은 나중에 연결해도 될까요?”

“새로운 ERP를 도입하는 동안 현재 업무는 어떻게 처리해야 할까요?”

ERP개발은 단순히 여러 업무 화면을 하나의 프로그램으로 만드는 프로젝트가 아닙니다. 기존에 부서별로 사용하던 데이터와 업무 규칙을 정리하고, 앞으로 어떤 시스템을 기준으로 운영할 것인지 결정하는 과정에 가깝습니다.

특히 이미 엑셀, 회계 프로그램, 쇼핑몰, 사내 주문 시스템, 생산관리 프로그램 등을 사용하고 있다면 모든 업무를 한 번에 새로운 ERP로 옮기는 방식은 부담이 클 수 있습니다.

이때 필요한 것은 패키지 ERP와 맞춤형 ERP 중 하나를 빠르게 선택하는 것이 아닙니다.

현재 업무 가운데 표준화할 수 있는 영역과 회사 고유의 절차를 유지해야 하는 영역을 구분하고, 기존 업무를 중단하지 않으면서 단계적으로 전환할 범위를 정해야 합니다.

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

ERP를 검토한다고 해서 반드시 모든 기능을 맞춤 개발해야 하는 것은 아닙니다.

회계, 인사, 급여처럼 업무 처리 방식이 비교적 표준화되어 있고 기존 패키지의 기능으로 충분히 운영할 수 있다면 새로운 시스템을 직접 개발하는 것보다 검증된 패키지를 도입하는 편이 적합할 수 있습니다.

반대로 다음과 같은 상황에서는 맞춤형 ERP개발이나 기존 시스템과의 연동을 함께 검토할 수 있습니다.

• 거래처마다 상품과 공급 가격이 다르게 적용되는 경우
• 주문이 접수된 뒤 여러 부서의 검토와 승인을 거쳐야 하는 경우
• 품목별로 재고 차감 기준이나 생산 방식이 다른 경우
• 일반적인 매입·매출 처리 외에 회사만의 정산 규칙이 있는 경우
• 패키지 ERP에 입력한 내용을 다시 엑셀로 내려받아 재가공하는 경우
• 주문, 재고, 배송, 회계 데이터가 서로 다른 시스템에 분리되어 있는 경우
• 현장 직원과 본사 직원이 서로 다른 화면과 권한을 사용해야 하는 경우
• 기존 프로그램을 유지하면서 일부 업무만 웹이나 앱으로 전환해야 하는 경우

패키지를 사용하고 있는데도 직원들이 별도의 엑셀 파일을 계속 만든다면, 패키지에 기능이 부족하다는 의미일 수도 있지만 업무 규칙이 제대로 정리되지 않았다는 신호일 수도 있습니다.

예를 들어 ERP에는 주문 완료로 등록되어 있지만 운영팀은 별도의 엑셀에서 다음 항목을 추가로 관리할 수 있습니다.

• 거래처 확인 여부
• 제작 가능 여부
• 출고 예정일
• 부분 출고 여부
• 정산 보류 사유
• 세금계산서 발행 여부
• 담당자 확인 상태

이러한 항목이 실제 업무에 필요하다면 새 ERP에서도 단순히 주문 목록만 만드는 것으로는 부족합니다. 주문 이후의 처리 상태와 담당 부서의 업무까지 함께 설계해야 합니다.

패키지 ERP로 충분한 업무와 맞춤 개발이 필요한 업무

패키지 ERP와 맞춤형 ERP개발은 어느 한쪽이 항상 더 좋은 선택은 아닙니다.

판단 기준은 우리 회사의 업무를 패키지의 표준 절차에 맞출 수 있는지, 맞추기 어려운 차이가 실제 경쟁력이나 운영에 필요한 규칙인지에 있습니다.

패키지 ERP를 먼저 검토할 수 있는 상황

다음과 같은 경우에는 패키지 ERP의 설정과 부가 기능만으로도 필요한 범위를 충족할 수 있습니다.

• 회계·급여·세무 등 표준적인 업무가 중심인 경우
• 거래처와 품목 구조가 비교적 단순한 경우
• 승인 절차가 부서별로 크게 다르지 않은 경우
• 기존 시스템과의 실시간 연동이 많지 않은 경우
• 내부 업무를 패키지의 표준 프로세스에 맞춰 변경할 수 있는 경우
• 빠른 도입과 초기 구축 부담 절감이 우선인 경우

이 경우에는 맞춤 개발을 시작하기 전에 패키지의 기본 기능, 설정 가능한 항목, 데이터 업로드 방식, API 제공 범위를 확인하는 것이 좋습니다.

패키지에 이미 있는 기능을 다시 개발하면 초기 구축 범위뿐 아니라 이후 유지보수 범위도 불필요하게 커질 수 있습니다.

맞춤형 ERP개발을 검토할 수 있는 상황

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

• 회사 고유의 견적·수주·발주·생산·출고 절차가 있는 경우
• 거래처별 계약 조건에 따라 가격과 정산 방식이 달라지는 경우
• 여러 사업장이나 창고의 재고 계산 규칙이 복잡한 경우
• 특정 조건에 따라 승인 담당자와 승인 단계가 달라지는 경우
• 기존 생산, 물류, 쇼핑몰, 그룹웨어와 밀접한 연동이 필요한 경우
• 모바일이나 태블릿을 사용하는 현장 업무가 있는 경우
• 표준 보고서가 아니라 회사 고유의 운영 지표가 필요한 경우
• 사용자 유형에 따라 조회 가능한 데이터 범위가 크게 다른 경우

다만 고유한 업무라고 해서 모두 그대로 개발해야 하는 것은 아닙니다.

오랫동안 사용했다는 이유로 유지되는 절차, 담당자 개인의 편의를 위해 추가된 입력 항목, 다른 엑셀에서 이미 관리되는 중복 정보까지 전부 시스템에 반영하면 새로운 ERP도 빠르게 복잡해질 수 있습니다.

개발 전에는 각 절차에 대해 다음 질문을 해보는 것이 좋습니다.

1. 이 단계가 없으면 실제 업무나 내부 통제에 문제가 발생하는가?
2. 법적·회계적 근거가 있어 반드시 유지해야 하는가?
3. 특정 담당자가 아니라 조직 전체에 필요한 절차인가?
4. 다른 시스템에 이미 같은 데이터가 존재하지 않는가?
5. 자동화하거나 더 단순한 규칙으로 바꿀 수 없는가?

패키지와 맞춤 개발을 함께 사용하는 방법도 있습니다

ERP 구축 방식을 패키지 또는 맞춤 개발 중 하나로만 구분할 필요는 없습니다.

회계와 인사는 패키지 ERP를 유지하고, 주문·재고·현장 업무는 별도의 맞춤형 시스템으로 구축한 뒤 필요한 데이터만 연동할 수 있습니다.

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

• 회계·세무: 기존 패키지 ERP 사용
• 거래처별 상품과 가격: 맞춤형 주문 시스템에서 관리
• 주문 승인과 출고 요청: 맞춤형 관리자 시스템에서 처리
• 매출 확정 데이터: 회계 ERP로 전달
• 재고 데이터: 기존 창고 시스템에서 조회하거나 동기화
• 경영 현황: 필요한 데이터를 통합한 대시보드에서 확인

이 방식에서는 어느 시스템이 원본 데이터를 관리하는지 분명해야 합니다.

거래처 정보가 패키지 ERP와 주문 시스템 양쪽에서 수정될 수 있다면 어느 쪽의 변경 사항을 우선할지 결정하기 어렵습니다. 동일한 거래처가 서로 다른 코드로 생성되거나, 한쪽에서 수정한 주소가 다른 시스템에서 다시 이전 값으로 변경될 수도 있습니다.

따라서 혼합형 ERP 구조에서는 기능 목록보다 먼저 데이터별 기준 시스템을 정해야 합니다.

| 데이터 | 기준 시스템 예시 | 다른 시스템의 역할 |<br>|---|---|---|<br>| 거래처 | ERP | 조회 또는 주문 시 참조 |<br>| 상품 | ERP 또는 상품관리 시스템 | 판매 가능한 상품만 동기화 |<br>| 거래처별 가격 | 맞춤 주문 시스템 | 주문·견적에 적용 |<br>| 주문 | 주문 시스템 | ERP에 매출 또는 출고 정보 전달 |<br>| 재고 | 창고·ERP | 쇼핑몰과 주문 시스템에 제공 |<br>| 정산 | ERP | 주문 시스템에서 처리 상태 조회 |

기준 시스템은 회사마다 다릅니다. 중요한 것은 동일한 데이터를 여러 시스템에서 임의로 수정하지 않도록 책임을 나누는 것입니다.

ERP개발은 화면보다 기준정보를 먼저 정리해야 합니다

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

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

• 거래처
• 사용자와 부서
• 품목과 품목 분류
• 창고와 사업장
• 공급 가격과 할인 정책
• 결제 조건
• 세금 유형
• 계정과목
• 단위와 규격
• 담당자
• 배송 방법

기준정보가 정리되지 않으면 주문, 재고, 정산 기능도 안정적으로 연결하기 어렵습니다.

예를 들어 같은 거래처가 다음과 같이 여러 이름으로 등록되어 있을 수 있습니다.

• 원소프트
• 원소프트 주식회사
• ㈜원소프트
• 원소프트 동탄
• 원소프트_신규

담당자는 이름만 보고 같은 거래처라고 판단할 수 있지만 시스템에서는 서로 다른 데이터로 인식할 수 있습니다.

이 상태로 데이터를 옮기면 거래처별 매출 집계가 분리되고, 미수금이나 주문 이력을 한 번에 확인하기 어려워집니다.

따라서 ERP개발 초기에는 기존 엑셀과 프로그램에 어떤 기준정보가 존재하는지 확인하고 다음 항목을 정리해야 합니다.

• 중복된 데이터가 있는가?
• 동일한 항목을 서로 다른 이름으로 사용하고 있지 않은가?
• 더 이상 거래하지 않는 거래처도 이전해야 하는가?
• 삭제하지 않고 비활성 상태로 보관해야 하는가?
• 기존 코드 체계를 유지할 것인가?
• 새로운 코드 규칙을 적용할 것인가?
• 코드가 변경된다면 기존 이력과 어떻게 연결할 것인가?

이 작업은 단순한 데이터 정리가 아니라 앞으로 ERP가 업무를 구분하는 기준을 만드는 과정입니다.

업무를 기준정보·거래 데이터·승인 절차로 나눠보세요

현재 업무를 정리할 때 화면 목록부터 작성하면 빠지는 내용이 많습니다.

‘주문 관리’, ‘재고 관리’, ‘매출 관리’처럼 메뉴 이름만 적기보다 업무를 다음 세 가지로 나누면 ERP개발 범위를 더 구체적으로 설명할 수 있습니다.

1. 기준정보

반복적으로 참조되는 기본 데이터입니다.

• 거래처
• 품목
• 사용자
• 부서
• 창고
• 가격 정책
• 세금 구분
• 결제 조건

2. 거래 데이터

실제 업무가 발생할 때 생성되는 데이터입니다.

• 견적
• 주문
• 발주
• 입고
• 출고
• 반품
• 정산
• 수금
• 재고 조정

3. 승인과 처리 절차

거래 데이터가 생성된 후 누가 확인하고 변경할 수 있는지를 결정합니다.

• 작성
• 검토 요청
• 승인 대기
• 승인
• 반려
• 수정 요청
• 처리 완료
• 취소
• 마감

예를 들어 ‘발주 관리’라는 기능을 개발한다고 가정해보겠습니다.

단순한 화면 목록만 있으면 발주 등록, 발주 목록, 발주 상세 정도로 정리될 수 있습니다.

하지만 실제 ERP개발 범위를 정하려면 다음 질문이 필요합니다.

• 누가 발주서를 작성하는가?
• 거래처는 등록된 공급사만 선택할 수 있는가?
• 품목별 최소 발주 수량이 있는가?
• 발주 금액에 따라 승인자가 달라지는가?
• 승인 전 발주서는 수정할 수 있는가?
• 승인 후 수량을 변경하면 재승인이 필요한가?
• 부분 입고가 가능한가?
• 발주 취소 시 입고 예정 수량은 어떻게 처리하는가?
• 발주 정보가 회계 또는 재고 시스템으로 전달되는 시점은 언제인가?

이 질문에 따라 데이터 구조, 화면, 권한, 알림, 연동 범위가 달라집니다.

기존 데이터 이전은 파일을 복사하는 작업이 아닙니다

ERP개발에서 데이터 이전 범위는 예상보다 큰 차이를 만드는 항목입니다.

Microsoft의 Dynamics 365 구현 가이드에서도 데이터 이전을 데이터 원천 확인, 정제, 매핑, 변환, 가져오기를 포함하는 별도의 구축 활동으로 다루고 있습니다. 보안 역할 설계, 외부 시스템 연동, 사용자 인수 테스트와 전환 계획 역시 구현 전략에서 함께 정해야 할 항목으로 안내합니다. (learn.microsoft.com)

기존 엑셀의 열을 새로운 ERP의 데이터베이스에 그대로 넣는다고 이전이 끝나는 것은 아닙니다.

데이터 이전 전 확인할 내용

• 기존 데이터가 어느 파일과 시스템에 있는가?
• 같은 데이터가 여러 곳에 중복되어 있지 않은가?
• 필수 항목이 비어 있는 데이터는 어떻게 처리할 것인가?
• 코드와 이름이 일치하지 않는 항목이 있는가?
• 날짜와 금액 형식이 일정한가?
• 퇴사자나 폐업 거래처도 이전해야 하는가?
• 첨부파일과 메모도 함께 옮겨야 하는가?
• 과거 변경 이력을 보존해야 하는가?
• 현재 진행 중인 주문과 완료된 주문을 어떻게 구분할 것인가?

모든 데이터를 옮겨야 하는 것은 아닙니다

오래된 데이터 전체를 새로운 ERP에 넣으면 조회가 편할 것 같지만, 데이터 품질이 낮거나 구조가 다른 경우 이전 작업과 검증 범위가 크게 늘어날 수 있습니다.

다음과 같이 나누는 방법도 있습니다.

• 현재 사용 중인 거래처와 품목은 신규 ERP로 이전
• 진행 중인 주문과 미정산 건은 신규 ERP에서 계속 처리
• 최근 일정 기간의 완료 이력은 조회용으로 이전
• 오래된 자료는 기존 시스템이나 별도의 보관 데이터로 유지
• 법적·회계적으로 필요한 자료는 원본 형태로 별도 보관

중요한 것은 이전 건수를 줄이는 것보다 신규 ERP에서 어떤 데이터를 수정하고 처리해야 하는지, 어떤 데이터는 조회만 하면 되는지를 구분하는 것입니다.

코드 매핑도 필요합니다

기존 시스템의 상태 코드가 다음과 같다고 가정해보겠습니다.

• A: 접수
• B: 확인
• C: 처리
• D: 완료

신규 ERP에서는 다음과 같이 더 세분화할 수 있습니다.

• 접수
• 검토 대기
• 승인 대기
• 승인 완료
• 출고 준비
• 부분 출고
• 출고 완료
• 취소

이 경우 기존의 B와 C를 신규 상태 중 어디에 연결할지 결정해야 합니다.

SAP의 데이터 마이그레이션 관련 문서에서도 매핑값을 별도로 관리하고, 기존 값의 교체 또는 중복값 변경·추가 방식을 선택할 수 있도록 안내합니다. 이는 데이터 이전이 단순 복사가 아니라 기존 값과 신규 체계의 관계를 정의하는 작업이라는 점을 보여줍니다. (help.sap.com)

권한은 메뉴를 보여주거나 숨기는 기능만이 아닙니다

ERP에는 여러 부서와 역할의 사용자가 접속합니다.

• 영업 담당자
• 구매 담당자
• 창고 담당자
• 회계 담당자
• 팀장
• 사업부 관리자
• 시스템 관리자
• 외부 거래처
• 협력사 담당자

이 사용자가 모두 같은 데이터를 조회하고 수정할 수 있도록 만들면 운영과 보안 측면에서 문제가 생길 수 있습니다.

권한은 다음과 같이 여러 단계로 구분할 수 있습니다.

메뉴 접근 권한

어떤 메뉴에 들어갈 수 있는지를 결정합니다.

예를 들어 창고 담당자는 입출고와 재고 메뉴에 접근하고, 회계 담당자는 매출과 정산 메뉴에 접근하도록 구성할 수 있습니다.

데이터 조회 권한

같은 메뉴에서도 조회 가능한 데이터 범위를 다르게 설정할 수 있습니다.

• 본인이 등록한 주문만 조회
• 소속 팀의 주문 조회
• 특정 사업장의 주문 조회
• 전체 법인의 주문 조회
• 특정 거래처 데이터만 조회

처리 권한

조회는 가능하지만 등록, 수정, 삭제, 승인, 다운로드는 제한할 수 있습니다.

특히 엑셀 다운로드는 화면 조회와 별도의 권한으로 관리할 필요가 있습니다. 화면에서 일부 정보만 확인할 수 있는 사용자에게 전체 고객 정보가 포함된 파일을 내려받게 하면 권한을 구분한 의미가 줄어들 수 있기 때문입니다.

민감 정보 권한

단가, 원가, 마진, 급여, 계좌번호, 개인정보처럼 민감한 항목은 역할에 따라 숨기거나 일부만 표시할 수 있습니다.

임시 권한과 대리 승인

휴가, 출장, 결산 등 특정 기간에만 다른 담당자가 업무를 대신 처리해야 할 수도 있습니다.

이 경우 관리자 권한을 공유하기보다 시작일과 종료일이 있는 임시 권한 또는 대리 승인 기능을 검토하는 것이 좋습니다.

Oracle의 ERP 접근 권한 관련 문서에서도 역할 요청 과정에 직무 분리와 민감 권한 분석, 검토와 승인 절차를 포함하고 있습니다. ERP의 권한은 단순한 화면 접근을 넘어 역할 충돌과 승인 책임까지 함께 고려해야 한다는 의미입니다. (docs.oracle.com)

승인 절차는 단계 수보다 조건이 중요합니다

ERP개발 상담에서 “3단계 결재가 필요합니다”라고 설명하는 경우가 있습니다.

하지만 실제 개발에는 단계 수보다 승인자가 달라지는 조건이 더 중요합니다.

예를 들어 구매 요청의 승인자가 다음 기준에 따라 달라질 수 있습니다.

• 요청 금액
• 소속 부서
• 사업장
• 품목 분류
• 신규 거래처 여부
• 예산 초과 여부
• 긴급 발주 여부

100만 원 미만은 팀장 승인으로 끝나지만 100만 원 이상은 본부장 승인이 필요할 수 있습니다. 신규 거래처 발주라면 금액과 관계없이 구매팀 검토가 추가될 수도 있습니다.

이러한 조건을 개발 전에 정하지 않으면 승인 기능을 만든 뒤에도 예외 업무가 계속 메신저와 이메일로 빠져나갈 수 있습니다.

승인 절차를 정리할 때는 다음 항목을 확인해보세요.

• 승인 요청 전 작성자가 수정할 수 있는 범위
• 승인 요청 후 수정 가능 여부
• 반려 후 재요청 방식
• 승인자 부재 시 대리 처리 방식
• 금액이나 조건 변경 시 재승인 여부
• 여러 승인자의 순차 승인 또는 병렬 승인 여부
• 승인 완료 후 취소 권한
• 승인 이력과 의견 보존 범위
• 알림 발송 방식
• 처리 기한을 넘긴 요청의 표시 방식

승인 화면만 만드는 것보다 승인 전후에 데이터가 어떻게 잠기고 다시 열리는지를 정하는 것이 더 중요합니다.

모든 ERP 기능을 한 번에 구축할 필요는 없습니다

ERP개발 범위가 커질수록 모든 부서의 요구사항을 동시에 반영하려는 경향이 있습니다.

하지만 주문, 구매, 재고, 생산, 회계, 정산, 인사까지 한 번에 변경하면 테스트해야 할 업무 조합도 함께 늘어납니다. 기존 업무를 중단하기 어려운 기업이라면 핵심 업무부터 단계적으로 전환하는 방식을 검토할 수 있습니다.

1단계: 기준정보와 핵심 거래 흐름

먼저 여러 부서가 공통으로 사용하는 기준정보와 반복 빈도가 높은 업무를 구축합니다.

예시:

• 거래처
• 품목
• 사용자와 부서
• 견적
• 주문
• 주문 승인
• 기본 현황 조회

2단계: 재고·발주·입출고 연결

주문과 실제 물류 흐름을 연결합니다.

예시:

• 발주
• 입고
• 출고
• 반품
• 창고별 재고
• 재고 조정
• 입출고 이력

3단계: 정산과 외부 시스템 연동

업무 데이터가 안정적으로 쌓인 뒤 회계와 정산, 외부 시스템 연결 범위를 확장합니다.

예시:

• 매출 확정
• 거래처별 정산
• 세금계산서 처리 상태
• 회계 ERP 연동
• 쇼핑몰 주문 연동
• 물류·배송 시스템 연동

단계는 반드시 위와 같은 순서일 필요는 없습니다.

회사의 가장 큰 문제가 재고 불일치라면 재고와 입출고부터 시작할 수 있고, 거래처 주문 접수가 복잡하다면 주문과 승인 기능을 먼저 구축할 수 있습니다.

중요한 기준은 다른 기능과 연결되는 정도와 업무 중단 시 영향을 함께 판단하는 것입니다.

단계적 구축에서는 임시 운영 방식도 설계해야 합니다

1단계 ERP가 공개되었지만 회계 연동은 2단계에 포함되어 있다면, 그 사이에 매출 데이터를 어떻게 전달할지 정해야 합니다.

예를 들어 다음과 같은 임시 운영 방식이 필요할 수 있습니다.

• ERP에서 매출 자료를 엑셀로 내려받아 회계 프로그램에 업로드
• 주문 승인 완료 건만 정산 담당자가 별도로 확인
• 기존 재고 시스템을 기준으로 유지하고 신규 ERP는 조회만 수행
• 신규 주문은 ERP에서 처리하고 기존 주문은 이전 시스템에서 마감
• 일정 기간 두 시스템의 집계 결과를 비교

이러한 임시 절차도 프로젝트 범위에 포함해야 합니다.

그렇지 않으면 신규 ERP의 일부 기능은 정상적으로 작동하지만 부서 간 데이터 전달이 끊겨 현장에서 다시 엑셀과 메신저를 사용하게 될 수 있습니다.

외부 시스템 연동은 실패 상황까지 설계해야 합니다

ERP는 다양한 외부 시스템과 연결될 수 있습니다.

• 쇼핑몰
• 회계 프로그램
• 그룹웨어
• 전자결재
• 물류·배송 시스템
• 생산 설비 또는 생산관리 시스템
• 결제 서비스
• 문자·알림 서비스
• 외부 거래처 시스템

연동 범위를 정할 때는 “API 연결 가능” 여부만 확인해서는 부족합니다.

어떤 데이터를 전달하는가?

상품, 거래처, 주문, 재고, 매출, 배송 상태 등 연동 대상 데이터를 구체적으로 정해야 합니다.

언제 전달하는가?

• 사용자가 저장하는 즉시
• 승인 완료 시
• 일정 시간마다
• 하루 한 번
• 관리자가 직접 전송할 때

어느 시스템의 값이 기준인가?

ERP에서 수정한 거래처 정보가 쇼핑몰로 전달되는지, 쇼핑몰에서 수정한 정보가 ERP로 들어오는지 정해야 합니다.

실패하면 어떻게 처리하는가?

외부 시스템이 일시적으로 응답하지 않거나 일부 데이터만 처리될 수 있습니다.

이때 필요한 운영 기능은 다음과 같습니다.

• 실패 건 목록
• 실패 원인
• 요청 및 응답 기록
• 재전송 버튼
• 자동 재시도 횟수
• 중복 전송 방지
• 마지막 성공 시각
• 운영자 알림

연동 기능은 정상적인 상황보다 실패 후 복구 방법을 먼저 정해야 실제 운영에서 대응하기 쉽습니다.

기존 업무를 멈추지 않으려면 전환 계획이 필요합니다

ERP개발의 마지막 단계는 프로그램을 서버에 배포하는 것이 아닙니다.

기존 시스템에서 신규 ERP로 업무 기준을 바꾸는 전환 작업이 필요합니다.

Microsoft의 구축 지침은 운영 전 사용자와 보안 역할 설정, 구성값 검증, 연동 점검, 최종 데이터 이동과 확인을 준비 항목으로 제시합니다. 또한 실제 전환 전에 샌드박스 환경에서 모의 전환을 수행하고, 이전된 데이터와 실제 사용자 권한으로 업무 전체를 테스트하도록 안내합니다. (learn.microsoft.com)

전환 계획에는 다음 내용이 포함될 수 있습니다.

• 기존 시스템 입력을 중단하는 시점
• 최종 데이터를 추출하는 시점
• 신규 ERP에 데이터를 반영하는 순서
• 데이터 건수와 금액을 검증하는 담당자
• 진행 중인 주문을 처리하는 방법
• 오류 발생 시 기존 시스템으로 돌아갈 기준
• 신규 ERP 사용 시작일
• 초기 문의와 오류를 접수할 채널
• 부서별 사용자 교육 일정
• 오픈 후 집중 대응 기간

업무를 멈출 수 없다면 일정 기간 기존 시스템과 신규 ERP를 병행할 수도 있습니다.

다만 병행 기간이 너무 길어지면 동일한 데이터를 두 시스템에 입력하는 문제가 생깁니다. 따라서 병행 운영을 한다면 어떤 시스템에 실제 데이터를 등록하고, 다른 시스템은 조회와 검증에만 사용할지 명확하게 정해야 합니다.

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

완성된 기획서가 없어도 상담은 가능합니다.

다만 다음 자료를 준비하면 현재 업무와 필요한 개발 범위를 더 빠르게 파악할 수 있습니다.

현재 사용하는 자료

• 업무별 엑셀 파일
• 기존 프로그램 화면
• 사용 중인 패키지 ERP 목록
• 수기로 작성하는 문서와 양식
• 부서별 업무 매뉴얼
• 거래처·품목 데이터 예시

민감한 정보는 가리거나 예시 데이터로 바꿔도 됩니다.

업무 흐름

다음과 같이 실제 순서로 적어보는 것이 좋습니다.

영업 담당자가 견적을 작성한다 → 팀장이 검토한다 → 고객이 확정하면 주문으로 전환한다 → 재고를 확인한다 → 부족하면 구매 요청을 생성한다 → 출고 후 매출을 확정한다 → 회계 담당자가 정산한다.

예외 상황도 함께 적어두면 도움이 됩니다.

• 일부 수량만 출고하는 경우
• 주문 후 가격이 변경되는 경우
• 반품과 재출고가 함께 발생하는 경우
• 승인자가 부재중인 경우
• 거래처별 정산일이 다른 경우

사용자와 권한

• 부서별 사용자 수
• 외부 거래처 접속 여부
• 조회 가능한 사업장
• 승인할 수 있는 금액
• 다운로드 가능한 데이터
• 관리자 역할 구분

데이터 이전 범위

• 이전할 시스템과 파일
• 데이터 보유 기간
• 전체 건수
• 첨부파일 존재 여부
• 중복 데이터 여부
• 과거 이력의 수정 필요 여부

외부 연동 자료

• 연동할 시스템 이름
• API 문서 제공 여부
• 계약과 계정의 보유 주체
• 실시간 연동 필요 여부
• 현재 데이터 전달 방식
• 연동 실패 시 담당 부서

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

ERP개발 견적은 총금액만 비교하기보다 각 업무의 포함 범위를 동일한 기준으로 확인해야 합니다.

기획 범위

• 현행 업무 분석이 포함되는가?
• 사용자 인터뷰를 진행하는가?
• 업무 흐름과 상태값을 문서화하는가?
• 화면 설계와 데이터 구조 설계가 포함되는가?

기능 범위

• 사용자 화면과 관리자 화면이 구분되어 있는가?
• 권한과 승인 조건이 구체적으로 적혀 있는가?
• 검색, 필터, 엑셀 업로드·다운로드가 포함되는가?
• 변경 이력과 작업자 기록이 포함되는가?

데이터 이전 범위

• 원본 데이터 정리는 누가 담당하는가?
• 코드 매핑 작업이 포함되는가?
• 시험 이전과 최종 이전을 각각 진행하는가?
• 이전 결과의 검증 책임은 어떻게 나뉘는가?
• 첨부파일과 과거 이력도 포함되는가?

연동 범위

• API 개발과 외부 시스템 설정이 모두 포함되는가?
• 연동 테스트 환경이 제공되는가?
• 실패 기록과 재전송 기능이 포함되는가?
• 외부 서비스 이용료는 별도인가?
• API 정책 변경 시 유지보수 기준은 무엇인가?

테스트와 배포

• 단위 테스트와 통합 테스트 범위
• 사용자 인수 테스트 지원 여부
• 모의 데이터 이전 여부
• 운영 서버 배포 범위
• 오픈 후 오류 대응 기간
• 사용자 교육과 매뉴얼 제공 여부

인수인계와 유지보수

• 소스코드 제공 범위
• 서버와 데이터베이스 계정의 소유 주체
• 외부 서비스 계정의 소유 주체
• 하자 수정과 추가 개발의 구분
• 유지보수 비용과 대응 범위
• 데이터 백업과 복구 방법
• 담당 개발사 변경 시 인수인계 조건

같은 ERP개발 견적이라도 데이터 정리, 권한, 연동 오류 처리, 테스트, 교육, 운영 안정화가 포함되어 있는지에 따라 실제 범위는 크게 달라질 수 있습니다.

ERP개발의 시작점은 프로그램이 아니라 업무 기준입니다

ERP개발을 검토할 때는 패키지 도입과 맞춤 개발 중 하나를 먼저 선택하기보다 현재 업무를 세 가지로 나누어보는 것이 좋습니다.

첫째, 패키지의 표준 기능에 맞출 수 있는 업무입니다.

둘째, 회사의 운영 방식 때문에 별도의 개발이 필요한 업무입니다.

셋째, 기존 시스템을 유지하면서 연동으로 해결할 수 있는 업무입니다.

그다음 기준정보, 거래 데이터, 권한, 승인, 데이터 이전, 외부 연동 범위를 정리하면 ERP개발업체와 상담할 때도 기능과 견적을 더 구체적으로 비교할 수 있습니다.

기존 업무를 중단하지 않아야 한다면 모든 기능을 한 번에 교체하기보다 주문, 재고, 정산처럼 문제가 큰 핵심 흐름부터 단계적으로 전환하는 방법을 검토할 수 있습니다.

원소프트는 웹·앱·AI와 관리자 시스템 개발을 수행하며, 사용자 화면뿐 아니라 관리자 운영 흐름, 데이터 구조, 외부 API와 기존 시스템 연동 범위를 함께 검토합니다. 모든 ERP 업무를 새로 개발하기보다 기존 시스템에서 유지할 영역과 맞춤 개발할 영역, 단계적으로 확장할 영역을 나누어 현실적인 구축 범위를 정리하는 방향을 지향합니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치하고 있습니다. 화성·동탄을 비롯해 수원, 용인, 기흥, 오산 등 경기 남부 지역에서 ERP와 업무 시스템 개발을 검토하고 계신다면 현재 사용하는 엑셀, 프로그램 화면과 업무 흐름을 바탕으로 필요한 개발 범위를 함께 정리해볼 수 있습니다.

제목 후보

1. ERP개발, 기존 업무를 멈추지 않고 단계적으로 구축하는 방법
2. ERP개발 외주 전, 데이터·권한·연동 범위를 정하는 실무 기준
3. ERP개발, 패키지 도입과 맞춤 개발을 업무별로 구분하는 방법
4. ERP개발 견적 전 확인할 데이터 이전·승인·시스템 연동 범위
5. ERP개발, 주문·재고·정산을 한 번에 바꾸지 않아도 되는 이유

추천 제목

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

메인 키워드

ERP개발

서브 키워드

1. 맞춤형 ERP 개발
2. ERP 데이터 이전
3. ERP 시스템 연동
4. ERP 권한 관리
5. ERP 개발업체

추천 해시태그

#ERP개발 <br>#맞춤형ERP개발 <br>#ERP시스템개발 <br>#ERP데이터이전 <br>#ERP연동개발 <br>#업무시스템개발 <br>#관리자페이지개발 <br>#동탄개발업체 <br>#화성웹개발 <br>#경기남부웹개발

썸네일 문구

1. 업무를 멈추지 않는 ERP개발
2. ERP, 한 번에 바꾸지 않아도 됩니다
3. 데이터·권한·연동부터 정하세요

글 요약

ERP개발은 패키지와 맞춤 개발을 단순 비교하기보다 표준화할 업무, 별도 개발할 업무, 기존 시스템과 연동할 업무를 구분하는 것부터 시작해야 합니다. 기준정보와 거래 데이터, 권한·승인, 데이터 이전, 외부 연동 범위를 정리하고 핵심 업무부터 단계적으로 전환하면 기존 운영의 중단 위험을 줄이면서 현실적인 구축 범위와 견적을 마련할 수 있습니다.

CTA 후보

1. 현재 사용 중인 엑셀과 기존 프로그램을 모두 교체해야 할지 판단하기 어렵다면, 유지할 업무와 우선 개발할 업무를 나누는 것부터 함께 검토할 수 있습니다.

1. 주문·재고·정산 흐름과 사용자별 권한, 기존 시스템 연동 범위를 알려주시면 단계별 ERP개발 범위를 정리하는 데 도움을 드릴 수 있습니다.

관련 포트폴리오

사용하지 않음

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

1. ERP 데이터 이전, 거래처·품목 코드와 과거 이력을 정리하는 방법
2. ERP 권한 관리, 부서·사업장·담당자별 조회와 승인 범위를 나누는 기준
3. ERP 연동 개발, 쇼핑몰·회계·물류 시스템의 기준 데이터를 정하는 방법