ERP개발 외주 문의 전, 기존 시스템 연동과 단계적 구축 범위를 정하는 방법

ERP개발을 검토하는 기업의 상황은 생각보다 다양합니다.

회계 프로그램은 이미 사용하고 있지만 영업팀의 견적과 수주 관리는 엑셀에 남아 있을 수 있습니다. 재고는 별도 솔루션에서 관리하고, 구매 요청과 승인은 이메일이나 메신저로 처리하기도 합니다. 각 부서가 사용하는 도구는 있지만 하나의 업무가 여러 시스템과 문서를 오가면서 중복 입력과 확인 작업이 계속 발생하는 구조입니다.

이런 상황에서 ERP개발을 논의하면 흔히 다음과 같은 질문부터 나옵니다.

기존 시스템을 모두 교체해야 할까요?
패키지 ERP와 맞춤 개발 중 어떤 방식이 적합할까요?
회계 시스템은 그대로 두고 영업이나 재고 업무만 개발할 수 있을까요?
데이터를 한 번에 모두 이전해야 할까요?
어느 업무부터 1차로 구축해야 할까요?
ERP개발 견적에는 어디까지 포함해야 할까요?

이 질문에 답하려면 먼저 ERP를 하나의 거대한 프로그램으로 보는 관점에서 벗어날 필요가 있습니다.

실제 ERP개발 범위는 회계·영업·구매·재고·생산·정산 등의 기능 목록만으로 정해지지 않습니다. 어떤 시스템이 데이터를 보유할지, 누가 등록하고 승인할지, 시스템 간에는 어떤 정보를 주고받을지, 오류가 발생하면 누가 어떻게 확인할지까지 정해야 합니다.

따라서 ERP개발 외주를 문의하기 전에는 전면 교체 여부보다 유지할 시스템과 새로 만들 업무, 서로 연결할 데이터를 구분하는 작업이 먼저입니다.

ERP개발이 필요한 상황과 기존 시스템 연동으로 해결할 수 있는 상황

현재 업무가 불편하다고 해서 모든 기능을 새로 개발해야 하는 것은 아닙니다.

먼저 지금 사용하고 있는 도구와 시스템을 다음 세 가지로 나누어보는 것이 좋습니다.

그대로 유지할 시스템
기능을 보완하거나 연동할 시스템
새로 개발할 시스템

예를 들어 회계팀이 사용하는 회계 솔루션이 안정적으로 운영되고 있고 세금계산서, 전표, 결산 업무에 큰 문제가 없다면 해당 기능까지 새로 만들 필요는 없을 수 있습니다.

대신 영업팀의 견적·수주 정보가 회계 시스템에 전달되지 않아 반복 입력이 발생한다면, 맞춤형 영업 관리 시스템을 개발하고 확정된 수주나 매출 데이터를 기존 회계 시스템과 연동하는 방식을 검토할 수 있습니다.

반대로 현재 시스템이 다음과 같은 상태라면 단순 연동만으로 문제를 해결하기 어려울 수 있습니다.

동일한 거래처가 시스템마다 다른 코드로 관리되는 경우
주문, 출고, 매출 데이터의 기준이 부서마다 다른 경우
업무 상태를 시스템에서 구분하지 못하는 경우
담당자별 접근 권한을 설정하기 어려운 경우
승인 과정을 메신저나 구두로 별도 처리하는 경우
기존 시스템에서 필요한 데이터를 외부로 제공하지 않는 경우
수정과 확장에 필요한 기술 자료나 관리 권한이 없는 경우

이때는 기존 시스템에 데이터를 연결하기 전에 업무 기준부터 다시 정리해야 합니다.

기존 솔루션을 유지하기 좋은 경우

다음 조건에 해당한다면 기존 솔루션을 유지하고 일부 기능만 연동하는 방식이 현실적일 수 있습니다.

현재 솔루션이 핵심 업무를 안정적으로 처리하고 있다.
기존 사용자들이 업무에 익숙하다.
필요한 데이터를 API나 파일 방식으로 주고받을 수 있다.
시스템 교체에 따른 교육과 전환 부담이 크다.
새로 필요한 기능이 특정 부서나 업무에 집중되어 있다.
기존 시스템의 계약과 데이터 접근 조건이 명확하다.

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

다음과 같은 기업 고유의 업무 규칙이 많다면 맞춤 개발의 비중이 커질 수 있습니다.

거래처마다 가격과 계약 조건이 다르다.
주문 전에 견적·검토·승인 단계가 필요하다.
품목별 재고 계산 방식이 일반적인 구조와 다르다.
여러 부서가 하나의 건을 단계별로 처리한다.
특정 상태가 되어야 다음 담당자가 업무를 시작할 수 있다.
문서, 사진, 검사 결과, 첨부 파일을 업무 데이터와 함께 관리해야 한다.
기존 영업·회계·물류·그룹웨어와 연결해야 한다.
관리자별로 조회·수정·승인 범위를 세밀하게 나눠야 한다.

핵심은 패키지와 맞춤 개발 중 하나만 선택하는 것이 아닙니다.

표준적인 회계와 세무 업무는 기존 솔루션을 활용하고, 기업 고유의 영업·주문·재고·승인 업무는 맞춤 개발하며, 필요한 데이터만 시스템 간에 연결하는 혼합형 구조도 가능합니다.

화면 목록보다 현재 업무 흐름을 먼저 정리해야 합니다

ERP개발 상담을 준비할 때 메뉴 목록부터 작성하는 경우가 많습니다.

거래처 관리
상품 관리
견적 관리
주문 관리
재고 관리
매출 관리
통계
관리자 관리

하지만 이 정도 목록만으로는 실제 개발 범위를 판단하기 어렵습니다.

같은 ‘주문 관리’라도 기업마다 처리 방식이 다르기 때문입니다.

한 기업은 영업 담당자가 주문을 등록하면 바로 출고 요청으로 넘어갈 수 있습니다. 다른 기업은 거래처별 단가 확인, 재고 검토, 팀장 승인, 선결제 확인을 모두 거쳐야 출고할 수 있습니다.

따라서 메뉴가 아니라 하나의 업무가 시작되고 종료되는 흐름을 적어야 합니다.

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

``text 영업 담당자가 견적 작성 → 팀장이 할인율 검토 → 고객에게 견적서 발송 → 고객이 주문 확정 → 재고 담당자가 출고 가능 수량 확인 → 부족 수량은 구매 요청 → 출고 완료 → 매출 확정 → 회계 시스템으로 매출 데이터 전달 ``

이 흐름을 작성하면 필요한 기능이 구체적으로 보이기 시작합니다.

견적 작성과 버전 관리
거래처별 가격 적용
할인율에 따른 승인
견적서 파일 생성
주문 전환
현재고와 가용 재고 확인
구매 요청
출고 상태 관리
매출 확정
회계 시스템 연동
단계별 담당자 알림
처리 및 변경 이력

이렇게 업무 흐름을 기준으로 범위를 정해야 개발사도 단순 등록 화면과 복잡한 업무 시스템을 구분할 수 있습니다.

표준 기능, 맞춤 개발 기능, 외부 연동 기능으로 나누기

현재 업무 흐름을 정리했다면 각 기능을 세 가지로 분류해볼 수 있습니다.

| 구분 | 의미 | 예시 | |---|---|---| | 표준 기능 | 일반적인 솔루션으로 처리할 수 있는 기능 | 기본 회계, 전표, 세금계산서, 일반 인사 관리 | | 맞춤 개발 | 기업 고유의 규칙을 구현해야 하는 기능 | 거래처별 견적, 다단계 승인, 특수 재고 계산, 프로젝트별 정산 | | 외부 연동 | 다른 시스템과 데이터를 주고받는 기능 | 회계 매출 연동, 쇼핑몰 주문 수집, 택배 송장 연동, 그룹웨어 승인 결과 반영 |

이 분류는 개발 방식뿐 아니라 견적 비교에도 도움이 됩니다.

예를 들어 ‘재고 관리’라고만 작성하면 개발사는 입출고 등록과 현재고 조회 정도로 해석할 수 있습니다. 하지만 실제로는 다음 기능이 필요할 수 있습니다.

창고별 재고
정상·불량·반품 재고 구분
예약 재고와 가용 재고 구분
로트 또는 유통기한 관리
입고 예정 수량 반영
주문 취소 시 재고 복원
외부 쇼핑몰 주문에 따른 재고 차감
재고 조정 사유와 승인
재고 변경 이력
일정 수량 이하 알림

기능 명칭은 같아도 업무 규칙에 따라 개발 범위가 크게 달라집니다.

외주 문의서에는 기능 이름만 나열하기보다 다음 내용을 함께 적는 편이 좋습니다.

누가 사용하는가?
어떤 정보를 입력하는가?
어떤 조건에서 처리할 수 있는가?
처리가 끝나면 상태가 어떻게 바뀌는가?
다음 담당자는 누구인가?
다른 시스템으로 어떤 정보를 전달하는가?
취소하거나 되돌릴 수 있는가?
변경 이력이 필요한가?

ERP의 시작은 기준정보를 정하는 일입니다

ERP 화면을 만들기 전에 먼저 정해야 할 것은 기준정보입니다.

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

거래처
고객
공급사
품목
상품과 옵션
창고
부서
직원
프로젝트
계약
단가
세율
결제 조건
배송 방법
계정과목

예를 들어 영업 시스템에서는 고객사 이름을 사용하고, 회계 시스템에서는 사업자등록번호와 거래처 코드를 사용할 수 있습니다. 쇼핑몰에서는 별도의 회원 번호를 사용할 수도 있습니다.

세 시스템의 정보를 연결하려면 무엇을 동일한 거래처로 판단할지 정해야 합니다.

회사명은 변경될 수 있고 같은 이름의 회사도 있을 수 있습니다. 사업자등록번호가 없는 개인 고객이나 해외 거래처가 존재할 수도 있습니다. 본사와 지점을 하나의 거래처로 볼지 각각 관리할지도 결정해야 합니다.

따라서 ERP개발 전에는 다음 질문에 답할 수 있어야 합니다.

거래처를 구분하는 고유한 기준은 무엇인가?
품목 코드는 어느 시스템에서 생성하는가?
거래처 정보는 누가 등록하고 수정하는가?
가격 정보는 ERP와 영업 시스템 중 어디에서 관리하는가?
재고 수량은 어느 시스템의 값을 기준으로 보는가?
퇴사자와 사용 중지 거래처의 데이터는 어떻게 보관하는가?
동일한 정보가 여러 시스템에 있다면 어느 쪽이 원본인가?

Microsoft의 공식 ERP 구현 가이드에서도 데이터 이전 범위를 정할 때 고객·제품과 같은 마스터 데이터, 미처리 주문과 재고·잔액 같은 진행 데이터를 구분하고, 원본과 대상 시스템, 변환 방식, 이전 순서와 책임자를 문서화하도록 안내합니다. (learn.microsoft.com)

데이터마다 소유 시스템을 정해야 합니다

모든 데이터를 새 ERP에서 관리해야 하는 것은 아닙니다.

예를 들어 다음처럼 나눌 수 있습니다.

| 데이터 | 기준 시스템 | 다른 시스템의 역할 | |---|---|---| | 거래처 기본정보 | ERP | 회계·영업 시스템에서 조회 | | 회계 계정과목 | 회계 시스템 | ERP가 연동해 사용 | | 상품정보 | ERP | 쇼핑몰로 전달 | | 온라인 주문 | 쇼핑몰 | ERP가 수집해 출고 처리 | | 실재고 | 창고 시스템 | ERP가 조회 또는 동기화 | | 매출 전표 | 회계 시스템 | ERP가 확정 데이터를 전달 |

기준 시스템을 정하지 않으면 양쪽에서 동시에 수정한 데이터가 충돌할 수 있습니다.

ERP에서 거래처 주소를 변경했는데 회계 시스템의 오래된 주소가 다시 넘어와 덮어쓰는 문제가 대표적입니다. 이를 막으려면 각 데이터의 생성·수정 권한과 동기화 방향을 함께 정해야 합니다.

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

ERP에는 다양한 사용자 유형이 참여합니다.

영업 담당자
영업 관리자
구매 담당자
재고 담당자
출고 담당자
회계 담당자
부서장
경영진
시스템 관리자
외부 협력사

이때 단순히 관리자와 일반 사용자로만 나누면 실제 업무를 반영하기 어렵습니다.

예를 들어 영업 담당자는 자신이 담당하는 거래처의 견적을 작성할 수 있지만 확정된 매출을 수정해서는 안 될 수 있습니다. 팀장은 담당 조직의 주문을 조회하고 할인 승인을 처리할 수 있어야 합니다. 회계 담당자는 매출과 입금 정보를 확인해야 하지만 영업 조건을 변경할 필요는 없습니다.

권한은 다음 단위로 나누어 검토해야 합니다.

메뉴 접근
데이터 조회
신규 등록
수정
삭제
승인
승인 취소
파일 다운로드
엑셀 내보내기
개인정보 열람
금액 정보 열람
전체 조직 또는 담당 조직 조회
변경 이력 조회

역할 기반 권한과 업무 분리는 ERP 제품의 공식 보안 가이드에서도 핵심 요소로 다뤄집니다. 예를 들어 공급사 정보를 등록하고, 입고를 확인하고, 지급까지 처리하는 권한이 한 사람에게 모두 집중되지 않도록 역할과 업무를 분리할 수 있습니다. (learn.microsoft.com)

결재와 승인은 업무 상태와 연결해야 합니다

승인은 버튼 하나를 추가하는 작업으로 끝나지 않습니다.

다음과 같은 정책이 필요합니다.

어떤 조건에서 승인이 필요한가?
금액이나 할인율에 따라 승인자가 달라지는가?
승인자가 자리를 비우면 위임할 수 있는가?
반려되면 어느 단계로 돌아가는가?
승인 후 원본을 수정할 수 있는가?
수정하면 다시 승인을 받아야 하는가?
긴급 처리 권한은 누구에게 있는가?
승인 과정과 의견을 보관해야 하는가?

예를 들어 모든 견적을 팀장이 승인하는 방식은 초기에는 단순해 보이지만, 실제 운영에서는 업무가 한 사람에게 몰릴 수 있습니다.

다음과 같이 조건을 나눌 수도 있습니다.

```text 정상 단가 적용 → 별도 승인 없이 발송 가능

기준 할인율 이내 → 팀장 승인

기준 할인율 초과 → 팀장 승인 후 본부장 승인

특정 금액 이상 → 재무 담당자 추가 검토 ```

이 구조를 개발하려면 단가 기준, 승인 단계, 담당자 지정, 부재 시 위임, 반려와 재요청, 변경 이력까지 함께 정의해야 합니다.

기존 데이터는 ‘모두 이전’보다 ‘왜 필요한지’부터 판단해야 합니다

ERP개발 과정에서 예상보다 많은 시간이 필요한 영역이 데이터 이전입니다.

오랫동안 사용한 시스템과 엑셀에는 다음과 같은 문제가 섞여 있을 수 있습니다.

같은 거래처가 여러 이름으로 등록되어 있다.
품목 코드 규칙이 부서마다 다르다.
필수 값이 비어 있다.
날짜와 금액 형식이 일정하지 않다.
퇴사자 계정이 활성 상태로 남아 있다.
이미 종료된 주문이 진행 중으로 표시되어 있다.
고객 정보가 여러 파일에 중복되어 있다.
코드만 있고 코드의 의미를 설명하는 자료가 없다.

이 데이터를 그대로 새 ERP로 옮기면 기존 문제도 함께 이동합니다.

먼저 데이터를 다음과 같이 나누는 것이 좋습니다.

1. 반드시 이전해야 하는 기준정보

현재 거래 중인 거래처
사용 중인 품목
직원과 부서
창고
활성 계약
적용 중인 가격 정책

2. 업무를 이어가기 위해 필요한 진행 데이터

미처리 주문
출고 대기 건
미입고 구매 건
미수금과 미지급금
현재 재고
진행 중인 프로젝트

3. 조회 목적으로 필요한 과거 데이터

완료 주문
과거 매출
종료 계약
이전 견적
과거 재고 이동 내역

4. 별도 보관할 수 있는 데이터

법적·내부 정책상 보관은 필요하지만 일상적으로 조회하지 않는 자료
오래된 첨부 파일
중단된 업무의 기록
품질을 확인하기 어려운 데이터

모든 과거 데이터를 새 구조에 맞춰 이전하기보다, 최근 데이터와 진행 데이터만 ERP에 넣고 오래된 자료는 기존 시스템이나 별도 조회 저장소에 보관하는 방식도 검토할 수 있습니다.

다만 법률, 세무, 회계 또는 사내 보존 정책과 관련된 데이터는 담당 부서의 확인을 거쳐야 합니다.

데이터 이전 전에 정할 항목

이전 대상 기간
대상 테이블과 파일
중복 판단 기준
누락 값 처리 기준
기존 코드와 신규 코드의 변환표
담당자와 승인자
파일 첨부 이전 여부
이전 후 검증 방법
실패 데이터의 수정 및 재실행 방법
최종 전환 시점의 추가 데이터 반영 방법

공식 구현 지침에서도 실제 전환 전에 데이터 이전을 반복 시험하고, 중복이나 손상 문제와 소요 시간을 검증하며, 업무 담당자의 확인을 받도록 권고합니다. (learn.microsoft.com)

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

ERP개발에서는 기존 시스템을 유지하면서 데이터를 연결하는 경우가 많습니다.

연동 대상은 다음처럼 다양합니다.

회계 프로그램
영업 관리 시스템
재고·창고 관리 시스템
쇼핑몰
B2B 주문 시스템
그룹웨어
전자결재
결제 서비스
택배·배송 시스템
세금계산서 서비스
은행 또는 입금 확인 서비스
외부 거래처 시스템

연동은 API 주소를 연결하는 것만으로 끝나지 않습니다.

API 제공 범위

먼저 필요한 기능이 실제 API로 제공되는지 확인해야 합니다.

화면에서 할 수 있는 모든 기능을 API로도 처리할 수 있는 것은 아닙니다. 조회는 가능하지만 등록이나 수정은 제한될 수 있고, 실시간 전달 기능 없이 일정 간격으로 조회해야 할 수도 있습니다.

확인할 자료는 다음과 같습니다.

API 문서
인증 방식
개발용 테스트 환경
호출 제한
조회·등록·수정 가능 범위
웹훅 제공 여부
오류 코드
데이터 형식
계약과 추가 비용
운영 서버 접근 조건
담당 기술 지원 창구

동기화 방향

데이터를 어느 방향으로 전달할지도 정해야 합니다.

ERP에서 회계 시스템으로만 전달
회계 시스템에서 ERP로만 전달
양방향 동기화
최초 한 번만 이전
일정 주기로 일괄 동기화
특정 상태가 되었을 때 전달

양방향 연동은 편리해 보이지만 충돌 기준이 필요합니다.

양쪽 시스템에서 동일한 거래처를 수정했을 때 어떤 값을 유지할지, 이미 확정된 매출을 한쪽에서 취소했을 때 다른 시스템에도 자동 반영할지 결정해야 합니다.

실시간 연동이 필요한지

모든 연동을 실시간으로 처리할 필요는 없습니다.

결제 승인이나 주문 확정처럼 즉시 반영이 필요한 업무가 있는 반면, 일일 매출 집계나 정산 자료처럼 일정 시간마다 처리해도 되는 데이터가 있습니다.

실시간 연동은 외부 시스템이 느려지거나 중단되었을 때 현재 ERP 업무까지 영향을 받을 수 있으므로 다음을 함께 검토해야 합니다.

사용자가 응답을 기다려야 하는가?
연동이 실패해도 현재 업무는 저장할 수 있는가?
임시 저장 후 나중에 다시 전송할 수 있는가?
지연된 데이터가 업무에 어떤 영향을 주는가?
실패 사실을 운영자가 어디에서 확인하는가?

오류와 재처리

ERP 연동은 정상 상황보다 실패 상황을 먼저 정의하는 편이 좋습니다.

외부 시스템이 응답하지 않는 경우
인증 정보가 만료된 경우
일부 데이터만 성공한 경우
같은 데이터가 두 번 전송된 경우
상대 시스템에 필요한 코드가 없는 경우
원본이 수정되거나 삭제된 경우
처리 순서가 바뀐 경우
호출 제한을 초과한 경우

실패 건을 개발자만 확인할 수 있다면 운영 중 대응이 늦어질 수 있습니다.

관리자 화면에서 연동 상태, 실패 원인, 시도 시각, 재시도 횟수와 처리 결과를 확인하고 필요한 경우 재전송할 수 있는 구조를 검토해야 합니다.

ERP 공식 구현 가이드에서도 시스템 통합 테스트 시 외부 시스템의 중단 상황과 실제 업무 영향을 점검하고, 양쪽 시스템의 보안·성능·데이터 교환 규칙과 장애 대응 절차를 정의하도록 안내합니다. (learn.microsoft.com)

1차 구축은 부서 수가 아니라 하나의 업무 흐름으로 정합니다

ERP 범위를 줄이기 위해 “영업은 1차, 재고는 2차”처럼 부서 단위로 나누기도 합니다.

그러나 영업 업무가 재고, 출고, 매출과 연결된다면 영업 화면만 먼저 만들어도 실제 운영이 완료되지 않을 수 있습니다.

단계적 구축 범위는 하나의 업무가 처음부터 끝까지 처리될 수 있는지를 기준으로 정하는 편이 좋습니다.

예를 들어 1차 구축의 목표가 ‘수주부터 출고까지 엑셀 없이 처리하는 것’이라면 다음 기능이 하나의 범위가 될 수 있습니다.

``text 거래처 및 품목 조회 → 견적 작성 → 주문 확정 → 재고 확인 → 출고 요청 → 출고 완료 → 매출 확정 → 회계 시스템 전달 ``

고급 통계, 자동 발주, 수요 예측, 복잡한 성과 지표 등은 실제 데이터가 쌓인 후 확장할 수 있습니다.

1차 구축에 포함할 가능성이 높은 항목

핵심 기준정보
사용자와 역할별 권한
핵심 업무 등록·조회·수정
상태 변경
필요한 승인
업무 검색과 필터
기본 파일 출력
필수 외부 시스템 연동
변경 이력
오류 확인을 위한 관리자 기능
진행 데이터 이전
기본 운영 매뉴얼

이후 확장을 검토할 수 있는 항목

고급 통계와 대시보드
예측 기능
복잡한 자동 배정
예외적인 소수 업무의 완전 자동화
사용 빈도가 낮은 과거 자료의 전체 이전
부가적인 모바일 기능
추가 외부 시스템 연동
AI 기반 문서 처리와 업무 보조
부서별 세부 리포트

물론 어떤 기능이 1차에 필요한지는 기업마다 다릅니다.

사용 빈도가 낮더라도 해당 기능이 없으면 결산이나 출고를 완료할 수 없다면 1차 범위에 포함해야 합니다. 반대로 자주 사용하더라도 기존 도구로 일정 기간 유지할 수 있다면 후속 단계로 나눌 수 있습니다.

단계별 전환 방법도 함께 결정해야 합니다

특정 부서부터 사용할 것인가?
일부 거래처나 사업장부터 적용할 것인가?
기존 시스템과 일정 기간 병행할 것인가?
전환 시점부터 신규 데이터만 ERP에 입력할 것인가?
병행 운영 중 어느 시스템의 값을 기준으로 볼 것인가?
문제가 발생하면 기존 방식으로 되돌릴 수 있는가?
전환 기간의 문의와 장애는 누가 접수할 것인가?

단계적 구축은 기능을 여러 번 나누는 것만을 의미하지 않습니다. 데이터와 사용자, 운영 책임까지 함께 나누는 계획이 필요합니다.

ERP개발 외주 문의서에 포함하면 좋은 자료

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

다음 자료만 준비해도 개발사가 현재 상황과 필요한 범위를 이해하는 데 도움이 됩니다.

현재 시스템 목록

| 시스템 | 사용 부서 | 주요 기능 | 유지 여부 | 연동 필요 | |---|---|---|---|---| | 회계 프로그램 | 회계팀 | 전표·매출·결산 | 유지 | 매출 데이터 전달 | | 엑셀 견적서 | 영업팀 | 견적·단가 관리 | 교체 검토 | ERP로 통합 | | 재고 프로그램 | 물류팀 | 입출고·현재고 | 검토 필요 | 재고 조회 | | 그룹웨어 | 전사 | 전자결재 | 유지 | 승인 결과 연동 검토 |

사용자와 역할

전체 예상 사용자
부서별 사용자
외부 사용자 존재 여부
관리자 유형
승인자와 대리 승인자
조회만 필요한 사용자
민감 정보 접근이 필요한 역할

핵심 업무 흐름

업무별로 시작부터 종료까지 간단한 문장이나 화살표로 작성합니다.

견적부터 주문까지
구매 요청부터 입고까지
주문부터 출고까지
매출 확정부터 회계 반영까지
반품 접수부터 재고 복원까지

현재 사용 중인 자료

엑셀 양식
견적서와 발주서
업무 매뉴얼
화면 캡처
코드 목록
승인 규정
기존 시스템의 API 문서
데이터 샘플
출력물 예시

실제 자료를 전달할 때는 개인정보와 거래 정보가 포함될 수 있으므로 샘플 데이터를 별도로 만들거나 비식별 처리하는 것이 좋습니다.

우선순위

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

1차 운영에 반드시 필요
있으면 업무 효율이 높아짐
운영 후 검토
현재 방식 유지 가능
추가 논의 필요

이 구분은 단순히 개발비를 줄이는 목적만이 아니라, 핵심 업무를 먼저 안정적으로 전환하는 데 의미가 있습니다.

견적서에서 기능 개발 외에 확인해야 할 범위

ERP개발 견적을 비교할 때 총금액만 보면 업체별 차이를 이해하기 어렵습니다.

같은 기능 목록이라도 다음 범위의 포함 여부가 다를 수 있습니다.

기획과 설계

현재 업무 분석
사용자 인터뷰
업무 흐름 정리
요구사항 정의
화면 설계
데이터 구조 설계
권한과 승인 설계
연동 방식 검토

데이터 이전

원본 데이터 분석
중복과 누락 정리
코드 변환
이전 프로그램 개발
시험 이전
검증 결과 수정
최종 데이터 이전
실패 데이터 재처리

외부 시스템 연동

API 분석
테스트 계정 설정
인증 처리
데이터 변환
동기화
실패 로그
재처리 기능
운영 모니터링
외부 업체와의 기술 협의

테스트

기능 테스트
권한 테스트
승인 흐름 테스트
시스템 통합 테스트
데이터 이전 테스트
성능 테스트
사용자 인수 테스트
수정 후 재검증

ERP는 개별 화면이 정상 작동하는지만 확인해서는 부족합니다. 실제 사용자 역할과 이전 데이터를 적용한 상태에서 견적 등록부터 승인, 출고, 매출 반영까지 전체 업무를 연결해 시험해야 합니다.

Microsoft의 구현 가이드도 기능뿐 아니라 보안, 사용성, 통합, 성능, 데이터 이전을 테스트 범위에 포함하고, 실제 업무 담당자가 사용자 인수 테스트에 참여하도록 안내합니다. (learn.microsoft.com)

배포와 전환

개발·테스트·운영 환경 구성
서버와 데이터베이스 설정
최종 데이터 이전
사용자 계정 생성
권한 배정
도메인과 보안 인증서
배포 절차
전환 당일 점검
문제 발생 시 복구 계획

실제 전환 전에는 데이터 이전, 연동, 권한, 업무 검증을 포함한 모의 전환을 진행할 수 있습니다. 공식 가이드에서도 전환 작업을 테스트 환경에서 반복 연습하고 각 작업의 담당자, 순서, 검증 기준, 문제 발생 시 복구 계획을 마련하도록 권고합니다. (learn.microsoft.com)

인수인계

소스코드 제공 범위
서버와 클라우드 계정 소유권
데이터베이스 접근 권한
외부 서비스 계정
배포 방법
API 문서
데이터 구조 문서
관리자 매뉴얼
사용자 매뉴얼
장애 대응 절차

유지보수

하자 수정과 추가 개발의 구분
문의 접수 방법
대응 가능 시간
장애 등급
백업과 복구
서버 모니터링
외부 API 변경 대응
권한 변경과 사용자 추가
기능 개선 절차
유지보수 종료 시 인계 범위

ERP는 출시 후 업무 정책과 조직 구조가 바뀌면서 수정 요구가 생길 수 있습니다. 따라서 유지보수 범위뿐 아니라 변경 요청을 어떻게 검토하고 배포할지도 확인하는 것이 좋습니다.

ERP개발 외주 상담 전 체크리스트

아래 항목을 모두 확정할 필요는 없습니다. 현재 알고 있는 내용과 확인이 필요한 내용을 구분해두는 것만으로도 상담의 정확도가 높아집니다.

현재 업무

[ ] ERP개발로 해결하려는 문제가 정리되어 있다.
[ ] 현재 사용하는 시스템과 엑셀 목록이 있다.
[ ] 부서별 핵심 업무 흐름을 설명할 수 있다.
[ ] 반복 입력과 수작업이 발생하는 지점을 알고 있다.
[ ] 현재 방식에서 오류가 자주 발생하는 구간을 알고 있다.

데이터

[ ] 거래처·품목·재고 등의 기준 시스템을 알고 있다.
[ ] 시스템마다 사용하는 코드가 다른지 확인했다.
[ ] 데이터 이전 대상 기간을 검토했다.
[ ] 진행 데이터와 과거 데이터를 구분했다.
[ ] 중복과 누락 데이터의 정리가 필요한지 확인했다.

권한과 승인

[ ] 사용자 유형을 구분했다.
[ ] 부서별 조회 범위를 검토했다.
[ ] 등록·수정·삭제·승인 권한을 구분했다.
[ ] 금액이나 조건에 따른 승인 절차를 정리했다.
[ ] 변경 이력이 필요한 업무를 확인했다.

외부 연동

[ ] 유지할 회계·영업·재고 시스템을 정리했다.
[ ] 필요한 API 문서와 계약 조건을 확인했다.
[ ] 데이터 전달 방향과 시점을 검토했다.
[ ] 연동 실패 시 업무 처리 방식을 검토했다.
[ ] 운영자가 오류를 확인하고 재처리할 필요가 있는지 확인했다.

구축과 운영

[ ] 1차 구축의 목표를 한 문장으로 정리했다.
[ ] 핵심 업무와 이후 확장 기능을 구분했다.
[ ] 기존 시스템과의 병행 운영 여부를 검토했다.
[ ] 실제 업무 담당자가 테스트에 참여할 수 있다.
[ ] 배포·인수인계·유지보수 범위를 견적에서 확인할 계획이다.

ERP개발은 ‘전체 교체’보다 업무와 데이터의 경계를 정하는 일입니다

ERP개발을 검토할 때 처음부터 모든 부서의 요구를 하나의 시스템에 담으려 하면 범위가 빠르게 커집니다.

반대로 현재의 불편한 업무를 그대로 화면으로 옮기기만 하면 새로운 시스템을 구축한 뒤에도 엑셀과 메신저가 계속 남을 수 있습니다.

먼저 현재 업무를 기준으로 다음을 구분해보는 것이 좋습니다.

기존 솔루션으로 계속 처리할 표준 업무
기업 고유의 규칙 때문에 맞춤 개발이 필요한 업무
기존 시스템과 데이터를 연결해야 하는 업무
1차 구축에 반드시 포함할 핵심 흐름
실제 운영 후 확장할 수 있는 기능

여기에 데이터의 기준 시스템, 사용자 권한, 승인 절차, 이전 범위, 오류 처리와 운영 책임을 더하면 개발업체가 검토할 수 있는 요구사항이 됩니다.

원소프트는 기획, UX/UI, 프론트엔드, 백엔드, 서버·데이터베이스, 외부 API 연동, 관리자 시스템과 배포·유지보수를 프로젝트 상황에 맞게 함께 검토합니다. 요구사항을 그대로 화면으로 옮기기보다 사용자 업무와 관리자 운영 흐름, 데이터 구조와 이후 확장 가능성을 기준으로 개발 범위를 정리하는 방식을 지향합니다.

경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치하고 있으며, ERP 전체 교체가 필요한지 또는 기존 회계·영업·재고 시스템을 유지하면서 필요한 업무만 단계적으로 개발할 수 있는지 검토하고 계신다면 현재 업무 자료를 기준으로 범위를 함께 정리해볼 수 있습니다.

제목 후보

ERP개발 외주 문의 전, 기존 시스템 연동과 단계적 구축 범위를 정하는 방법
ERP개발, 회계·영업·재고 시스템을 모두 교체하지 않고 구축하는 방법
맞춤 ERP개발 전 확인할 데이터·권한·승인·연동 체크리스트
ERP개발 견적 비교, 기능 목록보다 기존 시스템과 업무 흐름을 먼저 확인하세요
ERP개발 범위 정하기, 표준 기능·맞춤 개발·외부 연동을 구분하는 기준

메인 키워드

ERP개발

서브 키워드

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

썸네일 문구

ERP 전면 교체가 답일까요?
기존 시스템을 살리는 ERP개발
ERP개발 범위 정하는 방법

글 요약

ERP개발은 기존 회계·영업·재고 시스템을 모두 교체하기보다 유지할 기능, 맞춤 개발할 업무, 외부 연동할 데이터를 구분하는 것에서 시작해야 합니다. 기준정보와 데이터 소유 시스템, 권한·승인, 데이터 이전, 연동 오류 처리와 단계별 전환 범위를 정리하고, 외주 견적에서 테스트·배포·인수인계·유지보수까지 확인하는 방법을 설명했습니다.

CTA 후보

현재 사용 중인 회계·영업·재고 시스템과 엑셀 업무를 정리하고 계신다면, 전면 재개발과 단계적 연동 중 어떤 방식이 적합한지 요구사항부터 함께 검토할 수 있습니다.

완성된 ERP 기획서가 없더라도 현재 업무 흐름, 사용 중인 양식과 시스템 목록을 바탕으로 1차 구축 범위와 이후 확장 기능을 구분해볼 수 있습니다.

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

ERP 데이터 이전, 거래처·품목·재고 데이터를 옮기기 전에 정할 기준
ERP 연동 개발, 회계·영업·재고 시스템의 데이터 충돌을 줄이는 방법
사내 업무 시스템 권한 설계, 조회·수정·승인·다운로드 범위를 나누는 기준