ERP 구축 절차: 단계적 전환·데이터 이관·권한·안정화까지

ERP 구축이 끝났다는 말을 언제 할 수 있을까? 프로그램 설치가 끝났을 때, 데이터가 모두 들어갔을 때, 사용자가 로그인할 수 있을 때가 각각 후보일 수 있다. 그러나 현업 입장에서는 주문을 처리하고, 재고를 설명하고, 대금을 지급하고, 결산을 마칠 수 있어야 비로소 업무가 전환되었다고 느낀다.

그래서 ERP 구축은 화면을 만드는 프로젝트이면서 동시에 업무의 책임과 기준을 옮기는 프로젝트다. 이 글은 범위 결정 → 전환 방식 선택 → 데이터·권한 준비 → 테스트 → 오픈 → 안정화 순서로, 각 단계에서 무엇을 확인해야 다음 단계로 갈 수 있는지 설명한다. 특정 제품의 설치 매뉴얼이 아니라 구축을 이해하기 위한 안내이며, 숫자와 일정은 별도로 표시한 가상 예시다.

1. 첫 단계는 기능 목록보다 업무 범위를 정하는 일이다

'구매 모듈을 도입한다'는 문장은 범위로 쓰기에 아직 넓다. 구매 요청, 승인, 발주, 입고, 매입 확인, 지급 중 어디까지 새 시스템에서 처리할 것인지 정해야 한다. 해외 법인, 외주 창고, 반품, 긴급 구매 같은 예외도 포함 여부를 구분해야 한다.

좋은 범위 정의에는 업무의 시작과 끝, 담당 부서, 필요한 데이터, 외부 시스템과의 연결, 완료 기준이 함께 들어간다. 예를 들어 '국내 A사업장의 일반 원재료 구매를 요청부터 매입 전표까지 전환한다. 지급은 기존 금융 연계를 유지한다'처럼 경계가 드러나야 한다.

각 업무에는 현업 책임자도 필요하다. 구축업체가 프로그램을 설정했다고 해서 거래처 잔액의 정확성까지 대신 승인할 수는 없다. 전산 담당자는 데이터가 전달되는지 확인하고, 현업 담당자는 업무와 숫자의 의미가 맞는지 확인하며, 최종 의사결정자는 남은 위험을 보고 전환 여부를 결정한다.

이 단계의 결과물은 장문의 요구사항 목록만이 아니다. 주요 업무 흐름도, 기준정보 책임자 목록, 인터페이스 목록, 범위에서 제외한 항목을 남기면 이후의 '그 기능도 당연히 되는 줄 알았다'는 오해를 줄일 수 있다.

2. 빅뱅과 단계적 전환은 위험의 위치가 다르다

빅뱅 방식은 정한 범위를 한 시점에 새 ERP로 바꾸는 접근이다. 신·구 시스템의 병행 기간을 줄일 수 있지만 준비가 덜 된 영역의 문제가 여러 부서로 한꺼번에 퍼질 수 있다. 단계적 전환은 사업장이나 업무 범위를 나눠 바꾸는 방식이다. 먼저 배운 내용을 다음 단계에 반영할 수 있는 대신, 병행 기간의 연결과 대사를 관리해야 한다.

따라서 '단계적 전환이 언제나 안전하다'고 결론 내리면 안 된다. 업무가 강하게 얽혀 있는데 구매만 새 시스템으로 옮기면 입고·재고·회계 사이의 임시 연결이 오히려 복잡해질 수 있다. 반대로 독립적으로 운영되는 사업장이 있다면 먼저 전환해 보는 범위로 검토할 수 있다.

선택할 때는 시스템을 멈출 수 있는 시간, 업무 간 의존성, 데이터 규모, 현업의 테스트 여력, 병행 운영 비용을 비교한다. 단계적 전환을 선택했다면 '당분간 둘 다 쓴다'가 아니라 각 기간에 어느 시스템이 어떤 데이터의 기준인지 명시해야 한다. 같은 재고에 두 개의 기준이 생기면 책임이 모호해진다.

3. 데이터 이관은 추출·정제·매핑·검증의 연속이다

데이터를 한 번 복사해 넣는 것으로 이관이 끝나지는 않는다. 거래처·품목 같은 기준정보, 미결 주문과 미수·미지급 잔액 같은 진행 중 거래, 과거 이력을 구분해야 한다. 무엇을 새 ERP로 옮기고 무엇을 조회 가능한 별도 보관 영역에 남길지도 결정한다.

실무적으로는 다음 순서로 생각할 수 있다.

1. 원천 데이터와 기준시점을 정한다.
2. 중복 코드, 누락 값, 더 이상 사용하지 않는 항목을 정리한다.
3. 구 시스템의 필드·코드·단위를 새 시스템에 어떻게 대응시킬지 기록한다.
4. 시험 이관을 수행하고 오류와 처리 시간을 측정한다.
5. 수량·금액·상태를 대사하고 현업의 실제 업무 시나리오로 확인한다.
6. 최종 이관에서는 변경분과 중복 처리 방지 방법까지 관리한다.

이처럼 구성 데이터와 업무 데이터를 구분하고 이관을 준비하는 관점은 Microsoft의 데이터 이관 가이드에서도 다룬다. 제품별 기능은 달라도 '어떤 데이터를 누가 승인하는가'라는 질문은 따로 남는다.

가상 예시: 행 수가 다르면 실패일까?

구 시스템의 재고 자료가 두 행으로 되어 있다고 하자.

원천 행	창고	품목	수량	금액
1	A	P-01	60개	600,000원
2	A	P-01	40개	400,000원
합계	A	P-01	100개	1,000,000원

새 ERP에서 같은 조건의 두 행을 한 행으로 합치도록 설계했다면, 행 수가 2개에서 1개로 줄어도 수량 100개와 금액 1,000,000원이 일치하고 매핑 근거가 있으면 설명 가능한 변환이다. 반대로 전체 합계가 맞아도 A창고 물량이 B창고로 들어갔다면 업무상 오류다. 로트나 소유권처럼 합치면 안 되는 속성이 있다면 집계 자체를 허용해서도 안 된다.

대사는 전체 합계뿐 아니라 회사·창고·품목·거래처·통화 등 필요한 수준으로 내려가야 한다. 반올림 차이를 허용한다면 허용 기준과 원인을 사전에 합의하고, 큰 차이를 임의 조정 분개로 덮지 않는다. 이관 완료는 적재 성공 메시지가 아니라 현업이 신규 ERP에서 잔액과 진행 중 거래를 설명할 수 있다는 뜻이다.

4. 권한은 역할 이름보다 가능한 행동으로 검증한다

'구매 담당자'라는 역할을 만들었다고 권한 설계가 끝나지는 않는다. 누가 요청을 만들고, 누가 승인하며, 누가 거래처 정보를 바꾸고, 누가 지급을 확정하는지 행동 단위로 나눠야 한다. 조회 범위도 법인·사업장·부서 등에 따라 달라질 수 있다.

권한 테스트에는 허용과 차단을 모두 넣는다. 구매 담당자가 자기 업무의 발주를 만들 수 있는지 확인하는 동시에, 권한 밖의 회사 자료를 수정하거나 자신이 승인하면 안 되는 거래를 처리하지 못하는지도 확인한다. 테스트는 승인된 계정과 범위에서 수행하며 실제 운영 자료에 불필요한 변경을 만들지 않도록 계획한다.

관리자 권한을 일괄 배포하면 테스트가 잘되는 것처럼 보일 수 있지만 실제 운영 조건을 검증한 것은 아니다. 임시 지원 권한이 필요하다면 목적, 승인자, 만료 시점, 사용 기록을 정한다. 인사이동과 퇴사 시 누가 권한을 회수하는지도 운영 절차에 포함한다.

좋은 권한 체계는 사용자가 필요한 일을 제때 할 수 있으면서도 누가 어떤 정보를 바꾸고 승인했는지 설명할 수 있게 한다. 속도와 통제를 함께 설계해야 하는 이유다.

5. 테스트는 화면 하나가 아니라 거래의 끝까지 이어간다

단위 테스트에서는 개별 기능을 확인한다. 통합 테스트에서는 기능과 외부 시스템을 이어 본다. 사용자 인수 테스트에서는 실제 담당자가 자신의 업무를 수행하며 결과를 승인한다. 여기에 데이터 이관, 성능, 권한, 운영 지원 준비가 함께 필요하다. Microsoft의 오픈 준비 체크리스트

예를 들어 구매 발주가 저장되는지만 보면 테스트가 짧다. 일부 입고, 반품, 매입 확정, 지급 대상으로 이어지는 과정에서 수량과 금액이 어떻게 남는지 확인해야 한다. 판매도 주문에서 출고·청구·수금으로 이어지는 흐름을 검증한다. 취소, 중복 수신, 외부 연계 지연처럼 정상 경로 밖의 상황도 범위에 넣는다.

회계 담당자는 업무가 만든 전표를 보고, 물류 담당자는 실제 재고 상태를 확인해야 한다. 두 부서가 각자 화면은 정상이라고 말해도 서로의 결과가 맞지 않을 수 있다. ERP 구매·판매·회계 흐름을 함께 읽으면 테스트 범위를 거래 단위로 잡는 데 도움이 된다.

테스트의 증거는 '완료' 표시 하나보다 입력 조건, 기대 결과, 실제 결과, 결함 번호, 재검증 여부가 있는 기록이 좋다. 실패를 발견했을 때 같은 조건으로 다시 확인할 수 있어야 수정의 완료도 판단할 수 있다.

6. 오픈 승인은 일정이 아니라 증거를 보고 결정한다

최종 전환 계획에는 작업 순서와 소요시간, 책임자, 선행 조건, 검증 방법, 의사결정 시점을 적는다. 기존 입력을 언제 멈추는지, 마지막 변경분을 언제 추출하는지, 이관과 검증이 언제 끝나야 하는지 연결해서 계획해야 한다. 이런 전환 계획과 승인 기준의 중요성은 Microsoft의 컷오버 전략에서도 설명한다.

아래 항목은 프로젝트에 맞게 구체화할 출발점이다.

• 주요 업무 시나리오의 결과를 현업 책임자가 승인했는가?
• 핵심 데이터의 차이를 정해진 기준에 따라 모두 설명할 수 있는가?
• 업무를 중단시키는 결함이 남아 있는가? 남은 결함의 영향과 승인자는 누구인가?
• 실제 역할의 사용자 계정과 필요한 외부 연계가 준비되었는가?
• 교육, 문의 창구, 당일 지원 인력과 비상 연락망이 준비되었는가?
• 지연·실패 시 중단 또는 복구를 결정할 시점과 책임자가 정해져 있는가?

복구 계획은 단순히 백업을 복원한다는 한 줄로 끝나지 않는다. 새 ERP에서 이미 출고·청구·지급이 발생했다면 외부 시스템과 실제 업무 결과가 남는다. 그 거래를 어떻게 보존하고 재처리하며 중복을 막을지까지 포함해야 한다. 되돌릴 수 있는 구간과 추가 정리가 필요한 구간을 나눠 계획하자.

7. 오픈 이후에는 첫 결산까지 보면서 안정화한다

첫날 주문 한 건이 처리되었다고 안정화가 끝나는 것은 아니다. 주간 지급, 재고 실사, 반품, 첫 월말 결산처럼 주기가 다른 업무를 실제로 수행해야 발견되는 문제가 있다. 오픈 후에는 문의와 결함을 한 곳에 모으고 업무 영향, 긴급도, 담당자, 해결 예상 시점을 공유한다.

이슈를 모두 개발 결함으로 묶지 않는 것도 중요하다. 프로그램 오류, 잘못된 기준정보, 권한 문제, 업무 규칙 미합의, 사용자 교육 부족은 해결 방법이 다르다. 같은 문의가 반복된다면 사용자가 주의하도록 요청하는 것보다 화면 안내나 매뉴얼, 업무 정의를 개선해야 할 수 있다.

안정화 종료 기준도 정해야 한다. 예를 들어 주요 업무가 정해진 시간 안에 수행되고, 미해결 이슈가 운영 조직이 관리할 수준으로 줄었으며, 첫 결산 결과를 설명할 수 있는지 확인할 수 있다. 특정 기간이 지났다는 사실보다 이런 증거가 운영 인계의 근거가 된다.

8. 대시보드는 남은 문제를 다음 행동으로 연결한다

오픈 이후 지표는 'ERP를 사용한 사람 수'만으로 충분하지 않다. 승인 대기 시간, 실패한 연계 건수, 재고 차이, 기한이 지난 미결 거래처럼 업무가 막힌 위치를 보여줘야 한다. 각 지표에는 기준 시각과 담당자, 상세 내역으로 내려가는 경로, 확인 후 할 행동이 있어야 한다.

예를 들어 미처리 입고가 늘었다면 구매량이 증가한 것인지, 검수에서 멈춘 것인지, 외부 연계가 실패한 것인지 구분할 수 있어야 한다. 원인을 확인하지 않은 채 숫자만 빨간색으로 보여주는 화면은 문제를 발견하게 해도 해결을 돕지는 못한다.

ERP 운영 조직은 시스템 유지보수뿐 아니라 반복되는 업무 문제를 정리하고 개선 우선순위를 합의하는 역할로 이어져야 한다. 구축의 끝은 완벽한 화면이 아니라, 회사가 같은 데이터로 일하고 오류가 생겼을 때 원인과 책임을 따라갈 수 있는 상태다. 기초 구조가 궁금하다면 ERP와 기준정보의 관계로 돌아가 연결해서 읽어 보자.