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

“지금 사용 중인 엑셀과 프로그램을 하나로 합치고 싶습니다.”

“패키지 ERP를 도입했는데 우리 회사 업무와 맞지 않는 부분이 많습니다.”

“쇼핑몰 주문과 재고 정보가 ERP에 자동으로 반영되게 만들 수 있을까요?”

ERP개발을 검토하는 기업의 상황은 서로 다릅니다.

어떤 기업은 회계·구매·재고처럼 비교적 표준화된 업무를 통합하려고 하고, 어떤 기업은 자사만의 견적·승인·생산·출고 절차를 시스템으로 만들려고 합니다. 이미 ERP를 사용하고 있지만 쇼핑몰, 홈페이지, 물류 프로그램과 연결되지 않아 데이터를 반복 입력하는 경우도 있습니다.

이때 중요한 것은 처음부터 “어떤 ERP를 도입할 것인가”를 결정하는 것이 아닙니다.

먼저 현재 업무 중 패키지의 표준 기능에 맞출 수 있는 부분과 맞춤 개발이 필요한 부분을 구분해야 합니다. 기존 시스템을 유지하면서 연동만 해도 되는지, 핵심 업무를 별도의 시스템으로 개발해야 하는지도 함께 검토해야 합니다.

ERP개발은 화면 몇 개를 만드는 프로젝트가 아니라 회사의 업무 기준, 데이터, 권한과 승인 절차를 시스템 안에 옮기는 작업에 가깝습니다. 따라서 구축 방식을 결정하기 전에 실제 업무가 어떻게 시작되고, 누가 처리하며, 어떤 조건에서 다음 단계로 넘어가는지를 정리해야 합니다.

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

ERP라는 용어는 기업마다 다르게 사용됩니다.

어떤 기업은 회계와 재고를 관리하는 프로그램을 ERP라고 부르고, 다른 기업은 영업·견적·발주·구매·생산·출고·정산까지 연결된 전체 업무 시스템을 의미하기도 합니다.

따라서 개발업체에 단순히 “ERP를 만들고 싶다”고 전달하면 정확한 범위를 산정하기 어렵습니다. 같은 ERP개발이라도 실제 프로젝트 범위는 다음처럼 달라질 수 있습니다.

영업 담당자가 고객과 상담한 내용을 등록하는 CRM 기능
견적서를 작성하고 내부 승인을 받는 기능
거래처별 단가와 계약 조건을 관리하는 기능
주문을 확인하고 재고를 차감하는 기능
구매 요청과 발주를 관리하는 기능
생산 지시와 공정 상태를 기록하는 기능
출고, 배송, 반품 상태를 관리하는 기능
매출·매입·정산 자료를 회계 시스템으로 전달하는 기능
부서별 실적과 재고 현황을 확인하는 대시보드
담당자·부서·직급에 따른 조회 및 승인 권한
쇼핑몰, 홈페이지, 물류, 회계 프로그램과의 데이터 연동

이 가운데 필요한 기능이 일부에 그칠 수도 있고, 여러 기능이 하나의 흐름으로 연결되어야 할 수도 있습니다.

ERP개발을 검토해야 하는 대표적인 상황은 다음과 같습니다.

엑셀과 메신저로 관리하는 업무가 너무 많아진 경우

초기에는 엑셀로 거래처, 견적, 주문과 재고를 관리해도 충분할 수 있습니다.

하지만 담당자가 늘어나고 처리 건수가 많아지면 파일마다 값이 달라지거나 최신 자료를 구분하기 어려워집니다. 주문 상태는 엑셀에 있고, 승인 내용은 이메일에 있으며, 출고 요청은 메신저로 전달되는 식으로 업무가 분산되기도 합니다.

이런 상황에서는 단순히 엑셀 파일을 웹 화면으로 옮기는 것보다 데이터가 어떤 순서로 생성되고 변경되는지를 먼저 확인해야 합니다.

같은 데이터를 여러 프로그램에 반복 입력하는 경우

쇼핑몰 주문을 내려받아 내부 관리 파일에 옮기고, 다시 재고 프로그램과 회계 프로그램에 입력한다면 담당자의 반복 작업이 늘어납니다.

수기 입력 과정에서 주문번호, 상품 코드, 수량, 거래처명 등이 잘못 입력될 수도 있습니다. 데이터가 수정되었을 때 어느 시스템의 값이 최신인지 판단하기 어려워지는 문제도 발생합니다.

이 경우 ERP 전체를 새로 개발하기보다 기존 시스템 사이의 API 연동이나 데이터 동기화 프로그램을 우선 검토할 수 있습니다.

우리 회사의 업무 규칙을 기존 패키지에 적용하기 어려운 경우

패키지 ERP는 일정한 표준 프로세스를 기반으로 만들어집니다.

구매, 재고, 회계처럼 일반적인 업무는 패키지 기능과 설정만으로 처리할 수 있지만, 거래처마다 승인 절차가 다르거나 주문 조건에 따라 생산·출고 방식이 바뀌는 업무는 추가 설정이나 개발이 필요할 수 있습니다.

다만 기존 업무를 그대로 시스템에 복제하는 것이 항상 좋은 방법은 아닙니다. Microsoft의 ERP 구현 가이드에서도 기존 시스템의 절차를 그대로 재현하려 하면 불필요한 맞춤화와 추가적인 설계·개발·테스트·교육 부담이 생길 수 있으므로, 표준 기능에 맞출 수 있는 업무와 실제 차별화가 필요한 업무를 먼저 구분하도록 안내합니다. (learn.microsoft.com)

운영 현황을 실시간에 가깝게 확인하기 어려운 경우

경영진은 매출과 재고를 확인하고 싶고, 영업팀은 견적 및 계약 상태를 확인해야 하며, 운영팀은 주문·출고 현황을 알아야 할 수 있습니다.

하지만 부서별로 서로 다른 파일과 프로그램을 사용하면 같은 질문에 대해 다른 결과가 나올 수 있습니다.

ERP개발은 이런 데이터를 한 화면에 모으는 것뿐 아니라 어떤 데이터를 기준으로 집계할지를 정하는 과정도 포함합니다.

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

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

기존 패키지 ERP 도입
맞춤형 ERP개발
기존 시스템을 유지하면서 연동 또는 일부 기능 개발

각 방식에는 적합한 상황이 다릅니다.

| 구분 | 패키지 ERP 도입 | 맞춤형 ERP개발 | 기존 시스템 연동 | |---|---|---|---| | 적합한 상황 | 업무를 표준 프로세스에 맞출 수 있을 때 | 고유한 업무 규칙이 핵심일 때 | 기존 시스템을 유지하면서 데이터 이동을 줄이고 싶을 때 | | 초기 범위 | 제품 설정과 데이터 이관 중심 | 업무 분석부터 화면·서버·DB·관리자 기능 개발 | API, 파일, DB 등 연동 구조 개발 | | 장점 | 검증된 표준 기능을 비교적 빠르게 활용 가능 | 실제 업무 흐름에 맞게 설계 가능 | 기존 투자와 사용자 환경을 일부 유지 가능 | | 확인할 점 | 라이선스, 설정 범위, 추가 개발 제한 | 개발 후 유지보수와 확장 구조 | 데이터 기준 시스템과 오류 재처리 방식 | | 변화 대응 | 제품이 지원하는 범위 안에서 설정 | 필요에 따라 기능 확장 가능 | 연결된 시스템의 정책과 API 변화에 영향 |

패키지 ERP가 적합한 경우

다음과 같은 상황이라면 패키지 ERP를 우선 검토할 수 있습니다.

구매·재고·회계 업무가 비교적 일반적인 구조인 경우
회사의 업무 방식을 표준 기능에 맞춰 변경할 수 있는 경우
필요한 기능이 이미 제품 안에 제공되는 경우
자체적으로 시스템을 장기간 관리할 인력이 부족한 경우
복잡한 맞춤 기능보다 안정적인 기본 기능이 중요한 경우

패키지를 선택할 때는 현재 업무의 모든 세부 사항을 구현하려 하기보다, 어떤 업무를 표준 프로세스에 맞출 수 있는지를 먼저 확인하는 것이 좋습니다.

표준 기능으로 처리할 수 있는 업무까지 모두 맞춤 개발하면 초기 개발뿐 아니라 버전 업데이트와 유지보수에서도 추가 검토가 필요해질 수 있습니다.

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

다음과 같은 상황에서는 맞춤 개발의 비중이 높아질 수 있습니다.

견적, 승인, 주문, 생산, 출고의 순서가 일반적인 방식과 다른 경우
거래처·상품·계약 조건에 따라 처리 방식이 달라지는 경우
여러 사용자 유형이 같은 데이터를 서로 다른 권한으로 처리하는 경우
회사의 고유 업무 규칙이 경쟁력과 직접 연결되는 경우
고객용 서비스와 내부 업무 시스템이 함께 동작해야 하는 경우
기존 패키지의 추가 개발만으로는 업무를 처리하기 어려운 경우

맞춤형 ERP개발의 장점은 현재 업무에 맞는 기능을 설계할 수 있다는 점입니다.

반면 현재 업무가 정리되지 않은 상태에서 개발을 시작하면 부서마다 서로 다른 요구사항이 추가되거나 기존 수작업을 그대로 화면에 옮기는 결과가 나올 수 있습니다.

맞춤 개발을 결정하기 전에는 “현재 방식대로 만들 것인가”가 아니라 “왜 이 절차가 필요한가”를 확인해야 합니다.

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

이미 회계 프로그램, 쇼핑몰, WMS, 그룹웨어처럼 잘 사용하고 있는 시스템이 있다면 전부 교체할 필요는 없습니다.

예를 들어 다음과 같은 혼합형 구조를 고려할 수 있습니다.

쇼핑몰에서 주문을 수집해 내부 주문 관리 시스템으로 전달
ERP의 상품·재고 정보를 쇼핑몰에 반영
내부 승인 완료 건만 회계 프로그램으로 전달
물류 시스템의 출고 결과를 ERP에 반영
기존 ERP는 유지하고 영업·견적 관리 기능만 별도 개발
여러 시스템의 데이터를 모아 통합 대시보드 제공

이 방식에서는 어느 시스템이 원본 데이터를 관리할지가 중요합니다.

상품 정보는 ERP를 기준으로 하고, 고객이 입력한 배송지는 쇼핑몰을 기준으로 하며, 실제 출고 결과는 물류 시스템을 기준으로 할 수 있습니다. 이 기준이 정해지지 않으면 한쪽에서 수정한 값이 다른 시스템의 값으로 다시 덮어써지는 문제가 생길 수 있습니다.

공식 구현 가이드에서도 시스템 연동을 설계할 때 양쪽 업무에 미치는 영향, 데이터 교환 규칙, 보안, 처리량과 성능, 상대 시스템에서 발생한 오류의 해결 절차를 함께 정의하도록 안내합니다. (learn.microsoft.com)

고유 업무 규칙과 표준화 가능한 업무를 구분하는 방법

ERP개발 방향을 결정할 때 가장 먼저 해야 할 작업은 전체 업무를 두 가지로 나누는 것입니다.

기존 솔루션의 표준 기능에 맞출 수 있는 업무
회사에 필요한 고유한 업무 규칙

다음 질문을 활용하면 구분하는 데 도움이 됩니다.

이 절차는 법적·계약상 필요한가요?

세금계산서, 회계 처리, 개인정보 접근과 같이 법적 또는 계약상 지켜야 하는 기준이 있을 수 있습니다.

반면 오래전부터 해왔다는 이유만으로 유지되는 절차도 있습니다. 담당자가 바뀌면서 이유를 알 수 없는 승인 단계가 남아 있거나, 시스템이 지원하지 않아 엑셀로 보완하던 작업이 계속될 수도 있습니다.

이 규칙이 고객 경험이나 경쟁력에 영향을 주나요?

거래처별 견적 정책, 주문 제작 절차, 파트너 정산 방식처럼 회사의 서비스 품질과 직접 연결되는 규칙은 맞춤 개발의 근거가 될 수 있습니다.

반대로 일반적인 직원 등록, 부서 관리, 기본적인 구매 요청까지 모두 새로 개발해야 하는지는 검토가 필요합니다.

예외가 얼마나 자주 발생하나요?

한 달에 한 번 발생하는 예외를 위해 전체 시스템 구조를 복잡하게 만드는 것이 적절하지 않을 수 있습니다.

예외 업무는 관리자 권한으로 별도 처리하거나 사유를 기록한 뒤 수동으로 완료하도록 설계할 수도 있습니다. 반면 전체 업무의 상당 부분이 예외라면 현재 정의한 표준 흐름 자체를 다시 검토해야 합니다.

업무를 표준화하면 문제가 생기나요?

영업팀, 물류팀, 지점별로 서로 다른 방식으로 일하고 있다고 해서 모든 방식을 시스템에 각각 구현해야 하는 것은 아닙니다.

ERP개발을 계기로 입력 항목, 상태값, 승인 기준을 통합할 수 있다면 시스템 구조가 단순해지고 운영 데이터의 일관성도 높아질 수 있습니다.

패키지의 표준 기능을 우선 검토한 뒤 실제 업무상 정당한 차이가 있는 부분만 확장하는 방식은 불필요한 맞춤화를 줄이는 접근이 될 수 있습니다. (learn.microsoft.com)

ERP개발 전에 기준 데이터를 정리해야 합니다

ERP의 화면을 설계하기 전에 기준 데이터부터 확인해야 합니다.

기준 데이터는 여러 업무에서 공통으로 사용하는 핵심 정보를 의미합니다. 다음과 같은 항목이 포함될 수 있습니다.

고객사와 거래처
사업장과 부서
직원과 담당자
상품, 품목과 옵션
창고와 재고 위치
공급처와 제조사
거래처별 가격과 할인 정책
세금과 결제 조건
계정과 비용 항목
프로젝트와 계약
배송 방식과 출고 유형

예를 들어 같은 거래처가 영업팀 파일에는 정식 법인명으로, 회계 프로그램에는 약칭으로, 쇼핑몰에는 고객이 입력한 이름으로 저장되어 있을 수 있습니다.

새로운 ERP에서 데이터를 통합하려면 다음을 결정해야 합니다.

거래처를 구분하는 고유값은 무엇인지
중복 거래처를 어떻게 찾을지
폐업하거나 사용하지 않는 거래처를 이관할지
담당자와 거래처의 관계를 어떻게 저장할지
과거 주문과 변경 이력을 어디까지 옮길지
코드 체계를 유지할지 새로 만들지

ERP 데이터 이전은 단순히 기존 엑셀을 업로드하는 작업이 아닙니다.

기존 데이터와 새 시스템의 항목을 연결하고, 형식을 변환하며, 중복과 오류를 정리해야 합니다. 데이터 이관 범위에는 고객·상품 같은 기준 정보뿐 아니라 미처리 주문, 미수금, 진행 중인 계약과 같은 현재 업무 데이터도 포함될 수 있습니다.

Microsoft의 데이터 이전 가이드에서도 원본과 대상 시스템, 이관할 데이터의 양과 특성, 전체 또는 증분 이관 여부, 실행 순서, 데이터 간 의존 관계와 담당 역할을 사전에 정하도록 설명합니다. 또한 실제 운영 전에 시스템 통합 테스트와 사용자 인수 테스트 환경에서 이관 결과를 검증하도록 안내합니다. (learn.microsoft.com)

업무 흐름은 화면 목록이 아니라 상태 변화로 정리해야 합니다

ERP개발 문의를 준비할 때 메뉴 목록만 작성하는 경우가 많습니다.

거래처 관리
견적 관리
주문 관리
재고 관리
출고 관리
정산 관리

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

예를 들어 주문 관리 기능이라면 다음과 같은 흐름을 함께 확인해야 합니다.

``text 주문 접수 → 담당자 확인 → 재고 확인 → 승인 요청 → 주문 확정 → 출고 요청 → 출고 완료 → 정산 대기 → 정산 완료 ``

각 단계에서 누가 무엇을 할 수 있는지도 정해야 합니다.

주문 접수 후 내용을 수정할 수 있는가?
승인 요청 후에도 수량을 변경할 수 있는가?
재고가 부족하면 어떤 상태로 이동하는가?
승인자가 부재 중이면 대결 처리가 가능한가?
일부 상품만 먼저 출고할 수 있는가?
출고가 취소되면 재고를 다시 복원하는가?
정산 완료 후 금액을 수정할 수 있는가?
수정이 필요하면 기존 기록을 변경할지, 취소 후 다시 생성할지?

ERP개발에서는 정상 흐름뿐 아니라 보류, 반려, 취소, 재처리 같은 예외 상태를 함께 설계해야 합니다.

상태값이 지나치게 단순하면 담당자는 메모나 엑셀로 현재 상황을 다시 관리하게 됩니다. 반대로 상태를 너무 세분화하면 입력해야 할 항목이 늘어나 시스템 사용이 불편해질 수 있습니다.

업무 담당자가 실제로 구분하고 대응해야 하는 단계만 상태로 만드는 것이 좋습니다.

사용자 유형과 권한은 부서명만으로 나누기 어렵습니다

ERP에는 다양한 사용자가 접속합니다.

일반 직원
영업 담당자
구매 담당자
물류 담당자
회계 담당자
팀장과 승인자
시스템 관리자
외부 협력사
지점 또는 사업장 담당자

이때 권한을 단순히 관리자와 일반 사용자로 나누면 실제 운영에 적용하기 어렵습니다.

권한은 다음과 같이 기능별로 나누어 확인할 수 있습니다.

목록 조회
상세 정보 조회
신규 등록
수정
삭제
승인과 반려
금액 조회
개인정보 조회
엑셀 다운로드
일괄 처리
통계 조회
사용자와 권한 관리

같은 영업 담당자라도 본인이 등록한 고객만 확인할 수 있는지, 같은 팀의 고객까지 볼 수 있는지, 전사 고객을 검색할 수 있는지에 따라 구현 범위가 달라집니다.

조회 권한과 수정 권한도 구분해야 합니다. 매출 금액을 볼 수는 있지만 변경할 수 없는 사용자, 주문은 수정할 수 있지만 할인율은 바꿀 수 없는 사용자가 있을 수 있습니다.

민감한 데이터는 화면 메뉴를 숨기는 것만으로 보호되지 않습니다. 서버에서도 권한을 검증해야 하며, 다운로드와 API 접근에도 같은 기준을 적용해야 합니다.

결재와 승인은 조건에 따라 달라질 수 있습니다

ERP의 승인 기능은 단순히 승인 버튼 하나를 추가하는 작업이 아닙니다.

다음과 같은 조건을 확인해야 합니다.

금액에 따라 승인자가 달라지는가?
부서별로 결재선이 다른가?
할인율이 기준을 넘을 때만 추가 승인이 필요한가?
특정 상품이나 거래처는 별도 검토가 필요한가?
여러 명이 순서대로 승인해야 하는가?
한 명만 승인해도 되는 병렬 승인인가?
반려 후 기존 요청을 수정할 수 있는가?
승인자가 부재 중일 때 대리 승인이 가능한가?
이미 승인된 자료를 변경하면 재승인이 필요한가?

예를 들어 일반 견적은 팀장이 승인하지만 일정 금액을 넘는 견적은 본부장까지 승인해야 할 수 있습니다. 할인율이 기준 이상이면 재무 담당자의 검토가 추가될 수도 있습니다.

이때 승인 당시의 금액과 항목을 별도로 보관하는 것도 검토해야 합니다.

승인 후 원본 데이터가 수정되었는데 승인 기록만 남아 있다면 실제로 무엇을 승인했는지 확인하기 어려울 수 있기 때문입니다. 주요 데이터에는 변경 전후 값, 작업자, 변경 시점과 사유를 기록하는 기능이 필요할 수 있습니다.

기존 쇼핑몰·홈페이지·회계·재고 시스템과의 연동 범위

ERP개발에서는 외부 시스템 연동이 전체 일정과 범위에 큰 영향을 줄 수 있습니다.

먼저 어떤 시스템을 연결할지 목록으로 정리해야 합니다.

| 연동 대상 | 전달할 수 있는 데이터 예시 | |---|---| | 쇼핑몰 | 상품, 옵션, 주문, 결제, 취소, 배송 상태 | | 회사 홈페이지 | 문의, 회원, 견적 요청, 신청 정보 | | 회계 프로그램 | 매출·매입, 거래처, 세금계산서 관련 자료 | | 재고·물류 시스템 | 입고, 출고, 창고, 재고 수량 | | 그룹웨어 | 직원, 부서, 결재 결과 | | 결제 서비스 | 결제 승인, 취소, 환불 | | 택배·배송 서비스 | 송장번호, 배송 상태 | | 외부 파트너 시스템 | 발주, 작업 상태, 정산 자료 |

연동 대상이 정해졌다면 다음 기준을 추가로 확인합니다.

어느 시스템이 원본인가요?

상품명과 판매 가격은 쇼핑몰에서도 수정할 수 있고 ERP에서도 수정할 수 있습니다.

양쪽에서 모두 수정하도록 만들면 충돌 기준이 필요합니다. 일반적으로는 데이터별 원본 시스템을 하나 정하고 다른 시스템은 전달받은 값을 사용하는 구조가 관리하기 쉽습니다.

실시간으로 연결해야 하나요?

모든 데이터를 즉시 동기화할 필요는 없습니다.

주문 접수처럼 빠른 반영이 필요한 정보가 있는 반면, 하루 한 번 집계해도 되는 통계나 정산 데이터도 있습니다. 실시간 연동은 사용자 경험에 도움이 될 수 있지만 상대 시스템의 장애와 응답 지연에 더 직접적인 영향을 받을 수 있습니다.

연동에 실패하면 어떻게 하나요?

외부 시스템은 점검, 호출 제한, 네트워크 문제 등으로 일시적으로 응답하지 않을 수 있습니다.

이때 필요한 것은 단순한 오류 메시지가 아니라 다음과 같은 운영 구조입니다.

실패한 요청 저장
재시도 가능 여부 판단
자동 재시도 횟수와 간격
수동 재전송 기능
중복 전송 방지
부분 성공 데이터의 처리 기준
운영자 알림
요청과 응답 로그
개인정보와 인증 정보의 마스킹

연동이 성공한 경우만 가정하면 오류가 발생했을 때 개발자가 직접 데이터베이스를 확인하고 수정해야 할 수 있습니다. 운영자가 실패 건을 확인하고 필요한 조치를 할 수 있는 관리자 기능까지 개발 범위에 포함하는 것이 좋습니다.

처음부터 전체 ERP를 구축하지 않아도 됩니다

ERP개발 범위가 커지는 이유는 회사의 여러 부서와 업무가 연결되어 있기 때문입니다.

영업 관리만 만들려고 해도 거래처, 상품, 견적, 승인과 연결되고, 주문 관리는 재고·출고·정산으로 이어질 수 있습니다.

그렇다고 첫 프로젝트에서 모든 기능을 한 번에 구축해야 하는 것은 아닙니다.

다음 기준으로 1차 범위를 정할 수 있습니다.

반복 작업이 가장 많은 업무

같은 데이터를 여러 번 입력하거나 여러 파일을 합치는 업무는 개선 효과를 확인하기 쉽습니다.

예를 들어 쇼핑몰 주문 수집과 내부 주문 등록을 연결하거나, 반복적인 견적서 작성과 승인 절차를 시스템화하는 방식입니다.

오류가 발생했을 때 영향이 큰 업무

재고, 출고, 정산처럼 오류가 고객 응대나 금액 문제로 이어지는 업무를 우선할 수 있습니다.

단순 편의 기능보다 데이터 불일치와 누락을 줄이는 기능의 우선순위가 높을 수 있습니다.

다른 업무의 기준이 되는 데이터

거래처, 상품, 직원, 부서와 같은 기준 데이터가 정리되어야 이후 주문·재고·정산 기능을 안정적으로 연결할 수 있습니다.

따라서 초기에는 눈에 띄는 대시보드보다 기준 데이터와 핵심 업무 흐름을 먼저 구축하는 것이 적절할 수 있습니다.

독립적으로 운영 가능한 업무

전체 ERP가 완성되지 않아도 사용할 수 있는 범위를 선택해야 합니다.

예를 들어 1차로 거래처·견적·승인 기능을 구축하고, 2차로 주문·출고, 3차로 정산·통계를 추가할 수 있습니다.

단계적으로 구축하더라도 이후 기능 확장을 고려해 데이터 관계와 권한 구조를 설계해야 합니다. 단계별 배포에서는 각 단계의 데이터 이관, 사용자 교육, 기존 시스템과의 병행 운영 기간도 함께 계획해야 합니다.

공식 구현 가이드에서도 운영 전환을 단순한 기술 작업으로 보지 않고 테스트, 데이터 이전, 외부 시스템 의존성, 교육, 지원 준비와 담당자의 역할까지 포함해 계획하도록 권고합니다. (learn.microsoft.com)

ERP개발에서 관리자 시스템이 빠지면 안 되는 이유

ERP 자체가 내부 업무 시스템이더라도 별도의 관리 기능이 필요한 경우가 많습니다.

일반 사용자가 처리하는 업무와 시스템 운영자가 관리하는 업무는 다르기 때문입니다.

관리자 시스템에서는 다음 기능을 검토할 수 있습니다.

사용자와 부서 관리
역할 및 권한 설정
코드와 기준 데이터 관리
승인 규칙 설정
데이터 일괄 등록과 수정
연동 성공·실패 내역 확인
실패 데이터 재처리
변경 이력과 접속 기록 확인
공지 및 운영 안내
엑셀 업로드와 다운로드
시스템 설정 관리
통계와 현황 조회

특히 기준 데이터를 변경하는 권한은 신중하게 설계해야 합니다.

상품 코드, 거래처 구분, 세금 조건과 승인 기준이 바뀌면 이후 생성되는 업무 데이터에 영향을 줄 수 있습니다. 변경 가능 사용자와 적용 시점, 기존 데이터에 대한 반영 여부를 함께 정해야 합니다.

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

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

다만 다음 자료를 준비하면 개발업체가 현재 상황을 이해하고 구축 방식을 제안하는 데 도움이 됩니다.

1. 현재 사용 중인 도구와 시스템 목록

엑셀 파일
회계 프로그램
재고 프로그램
쇼핑몰
그룹웨어
사내 홈페이지
물류 또는 배송 시스템
외부 파트너 시스템

각 시스템의 제품명만 적기보다 어떤 업무에 사용하는지도 함께 작성하는 것이 좋습니다.

2. 현재 업무 흐름

업무를 다음처럼 순서대로 정리해볼 수 있습니다.

``text 고객 문의 접수 → 영업 담당자 배정 → 견적 작성 → 팀장 승인 → 고객 확정 → 주문 등록 → 재고 확인 → 출고 요청 → 배송 완료 → 정산 ``

각 단계에서 사용하는 프로그램과 담당 부서를 표시하면 데이터가 어디서 끊기는지 확인하기 쉽습니다.

3. 사용자 유형

전체 사용자 수
부서와 직급
외부 사용자 포함 여부
승인자와 실무 담당자
지점 또는 사업장 구분
사용자별 데이터 접근 범위

정확한 인원수가 확정되지 않았다면 대략적인 범위라도 전달할 수 있습니다.

4. 자주 사용하는 문서와 엑셀

견적서, 발주서, 주문 목록, 재고 파일, 정산 자료처럼 실제 업무에서 사용하는 양식은 요구사항을 이해하는 데 도움이 됩니다.

다만 기존 양식의 모든 항목을 그대로 시스템에 옮기기보다 각 항목이 필요한 이유와 실제 사용 여부를 확인해야 합니다.

5. 우선 해결하고 싶은 문제

“통합 ERP가 필요하다”는 표현보다 다음처럼 구체적으로 전달하는 것이 좋습니다.

쇼핑몰 주문을 수기로 옮기는 작업을 줄이고 싶다.
거래처별 견적과 승인 내역을 찾기 어렵다.
실제 재고와 엑셀 재고가 자주 달라진다.
출고 요청이 메신저에 흩어져 처리 여부를 확인하기 어렵다.
정산 자료를 만들기 위해 여러 파일을 합쳐야 한다.
담당자가 바뀌면 업무 진행 상황을 파악하기 어렵다.

문제가 구체적일수록 패키지 도입, 맞춤형 ERP개발, 연동 개발 중 어떤 방향이 적합한지 판단하기 쉬워집니다.

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

ERP개발 견적은 총금액만 비교해서는 범위를 정확히 판단하기 어렵습니다.

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

업무 분석과 기획

현행 업무 분석이 포함되는가?
업무 흐름도와 화면 설계서를 제공하는가?
부서별 요구사항을 어떻게 정리하는가?
기획 확정 이후 변경 요청은 어떻게 처리하는가?

사용자 화면과 관리자 기능

사용자별 메뉴와 권한이 구분되어 있는가?
관리자 설정 기능이 포함되어 있는가?
검색, 필터, 일괄 처리와 엑셀 기능이 범위에 포함되는가?
변경 이력과 로그 기능이 포함되는가?

데이터 이전

어떤 데이터를 이관하는가?
과거 데이터를 어디까지 옮기는가?
중복·오류 데이터 정리는 누가 담당하는가?
시험 이관과 최종 이관이 포함되는가?
이관 결과의 검수 기준은 무엇인가?

외부 시스템 연동

연동 대상과 데이터 항목이 명시되어 있는가?
API 이용료나 외부 서비스 비용은 별도인가?
연동 실패와 재처리 기능이 포함되는가?
상대 시스템 변경 시 유지보수 기준은 무엇인가?

테스트와 운영 전환

단위 테스트, 통합 테스트와 사용자 검수가 포함되는가?
실제 업무 시나리오를 기준으로 테스트하는가?
데이터 이관과 연동을 포함한 전체 흐름을 검증하는가?
기존 시스템에서 새 시스템으로 전환하는 계획이 있는가?
사용자 교육이나 운영 매뉴얼이 제공되는가?

운영 시작 전에는 기능 테스트뿐 아니라 시스템 통합, 사용자 인수, 데이터 이전, 외부 의존 시스템과 운영 지원 준비까지 확인해야 합니다. (learn.microsoft.com)

배포와 인수인계

서버와 클라우드 계정은 누구 명의로 개설하는가?
소스코드와 데이터베이스를 인계받을 수 있는가?
개발·검수·운영 환경이 구분되는가?
배포와 백업 설정이 포함되는가?
관리자 계정과 외부 서비스 계정을 인계받는가?

유지보수

하자 수정 기간과 기준은 무엇인가?
기능 변경과 오류 수정은 어떻게 구분하는가?
외부 API 변경은 유지보수에 포함되는가?
서버 모니터링과 백업 점검이 포함되는가?
긴급 오류의 대응 시간과 연락 방법은 무엇인가?

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

ERP개발에서는 처음부터 화면 목록을 확정하기보다 현재 운영 방식과 데이터의 흐름을 먼저 확인해야 합니다.

원소프트는 웹·앱·AI 및 관리자 시스템을 개발하며 사용자 화면뿐 아니라 운영자의 처리 과정, 데이터 구조, 역할별 권한과 외부 시스템 연동을 함께 검토합니다.

관련 경험으로는 부동산 경매 업무 통합 플랫폼인 바토너 프로젝트가 있습니다.

바토너는 ERP 프로젝트로 분류되는 서비스는 아니지만, 회원·전문가·운영자별 권한을 구분하고 경매 물건 조회부터 입찰 신청, 계약 문서, 결제·포인트, 정산, 알림과 문의까지 이어지는 업무 상태를 하나의 시스템으로 연결한 업무형 플랫폼입니다.

또한 OCR을 통한 문서 정보 인식, 결제와 푸시 알림 같은 외부 기능을 연동하고, 운영자가 회원·입찰·결제·정산·문의 데이터를 관리할 수 있는 구조를 개발했습니다.

이처럼 여러 담당자와 업무 단계가 연결되는 시스템은 메뉴 수보다 다음 기준이 중요합니다.

어떤 데이터가 업무의 기준이 되는가?
각 단계에서 누가 처리할 수 있는가?
어떤 조건에서 다음 상태로 이동하는가?
취소·반려·오류가 발생하면 어디로 돌아가는가?
외부 시스템과 어떤 데이터를 주고받는가?
운영자가 문제를 직접 확인하고 처리할 수 있는가?

ERP개발 역시 같은 관점으로 접근할 수 있습니다.

패키지를 도입할지, 전체를 맞춤 개발할지, 기존 시스템을 연동할지는 제품 이름만으로 결정하기 어렵습니다. 현재 업무를 표준화할 수 있는 정도, 고유한 업무 규칙, 기준 데이터의 상태와 외부 시스템의 범위를 함께 확인해야 합니다.

처음부터 모든 부서의 기능을 한 번에 구축하기보다 핵심 업무와 기준 데이터를 먼저 정리하고, 실제 운영 결과를 바탕으로 다음 범위를 확장하는 방법도 검토할 수 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치한 웹·앱·관리자 시스템 개발사입니다.

ERP개발이나 기존 업무 시스템 연동을 검토하고 있다면 현재 사용하는 프로그램, 엑셀과 업무 흐름을 바탕으로 패키지 활용이 가능한 부분과 맞춤 개발이 필요한 부분을 함께 정리해볼 수 있습니다.

제목 후보

ERP개발, 패키지 도입·맞춤 개발·기존 시스템 연동을 결정하는 기준
ERP개발 전 확인할 8가지, 패키지와 맞춤형 구축은 무엇이 다를까요?
맞춤형 ERP개발이 필요한 경우와 기존 시스템 연동으로 해결할 수 있는 경우
ERP 구축 방법, 패키지·맞춤 개발·연동 방식 비교와 준비 체크리스트
ERP개발업체 문의 전 업무 흐름·권한·승인·연동 범위를 정리하는 방법

메인 키워드

ERP개발

서브 키워드

맞춤형 ERP개발
ERP개발업체
ERP시스템개발
ERP연동
업무관리시스템개발

썸네일 문구

패키지 ERP와 맞춤 개발, 무엇을 선택할까?
ERP개발 전 먼저 정해야 할 업무 기준
ERP 구축 방식 결정 체크리스트

글 요약

ERP 구축 방식은 제품이나 견적만으로 결정하기보다 현재 업무를 표준화할 수 있는 정도와 회사 고유의 규칙을 기준으로 판단해야 합니다. 패키지 ERP, 맞춤형 ERP개발, 기존 시스템 연동의 차이를 비교하고 기준 데이터·업무 상태·권한·승인·외부 연동·단계적 구축 범위를 정리하는 방법을 설명했습니다.

CTA 후보

현재 사용 중인 엑셀과 프로그램은 정리되어 있지만 어떤 방식으로 통합해야 할지 판단하기 어렵다면, 업무 흐름과 연동 대상을 바탕으로 개발 범위를 함께 검토해드릴 수 있습니다.

패키지 ERP의 추가 개발, 별도 업무 시스템 구축, 기존 쇼핑몰·회계·재고 시스템 연동 중 어떤 방향이 적합한지 고민하고 계신다면 현재 운영 방식부터 정리해보시기 바랍니다.

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

ERP연동 개발, 쇼핑몰·재고·회계 데이터의 기준 시스템을 정하는 방법
맞춤형 업무관리시스템 개발, 엑셀 업무를 그대로 옮기면 안 되는 이유
ERP 데이터 이전, 거래처·상품·재고·미처리 주문을 정리하는 기준