ERP란 무엇인가: 통합 시스템·기준정보·프로세스 표준화 이해하기

ERP를 단순한 회계 프로그램이 아니라 조직의 공통 데이터와 업무 흐름을 연결하는 시스템으로 설명합니다. 기준정보, 표준화, 변화관리, 단일 지표의 의미를 함께 다룹니다.

이 종합 가이드는 WIKIWIKI에 각각 기록해 둔 관련 지식 꾸러미를 하나의 학습 순서로 다시 편집한 글입니다. 개별 개념을 따로 외우기보다 서로 어떤 관계를 맺는지 따라가며 읽을 수 있도록 구성했습니다.

ERP는 회계 프로그램이 아니라 공통 데이터 시스템이다

ERP의 핵심은 부서별 업무를 하나의 거래 흐름과 공통 데이터로 연결하여 같은 사실을 같은 기준으로 보게 만드는 데 있다.

ERP를 회계 전표를 입력하는 프로그램으로만 이해하면 도입 효과가 제한된다. ERP는 영업, 구매, 생산, 물류, 회계가 같은 거래를 서로 다른 단계에서 이어받는 통합 운영 체계다.

ERP가 연결하는 흐름

1. 영업 주문은 수요와 출하 계획이 된다.
2. 출하는 재고 감소와 매출 인식으로 이어진다.
3. 구매 입고는 재고 증가와 매입 채무를 만든다.
4. 생산 실적은 원재료, 완제품, 원가에 동시에 영향을 준다.

ERP의 가치는 화면 수가 아니라 데이터가 한 번 발생해 다음 업무로 자연스럽게 이어지는 데 있다. 부서마다 별도 엑셀로 숫자를 다시 만들고 있다면 시스템은 통합됐어도 운영은 아직 분리된 것이다.

따라서 ERP 개선은 기능 추가보다 거래가 어디서 시작되고 어떤 기준으로 다음 단계에 전달되는지를 점검하는 일에서 출발해야 한다.

기준정보가 ERP 품질을 결정한다

품목·거래처·계정·조직 같은 기준정보가 정확하고 일관되어야 거래 데이터와 보고서도 신뢰할 수 있다.

ERP에서 기준정보는 반복적으로 참조되는 업무의 공통 언어다. 품목 코드, 거래처, 창고, 계정과목, 조직, 단위가 제각각이면 입력은 가능해도 결과를 비교하거나 합산하기 어렵다.

좋은 기준정보의 조건

• 같은 대상을 중복 코드로 만들지 않는다.
• 코드 생성과 변경 책임자를 명확히 둔다.
• 필수 속성과 사용 가능한 값을 제한한다.
• 더 이상 쓰지 않는 코드는 삭제보다 사용 중지로 이력을 보존한다.
• 변경이 구매·생산·회계에 미치는 영향을 함께 검토한다.

보고서 숫자가 맞지 않을 때 거래 전표만 추적하기 쉽지만, 원인은 잘못된 품목군이나 계정 매핑일 수 있다. 기준정보 오류는 한 번의 실수가 여러 거래로 복제된다는 점에서 더 위험하다.

ERP 운영 품질을 높이려면 월별 오류 수정뿐 아니라 중복률, 미사용 코드, 필수값 누락처럼 기준정보 자체의…

ERP 맞춤개발보다 프로세스 표준화가 먼저다

기존 업무를 그대로 시스템에 복제하기 전에 그 절차가 정말 필요한지 검토해야 ERP 복잡성과 유지비를 줄일 수 있다.

ERP 구축에서 현업의 모든 요구를 맞춤개발로 해결하면 초기 만족도는 높아 보일 수 있다. 하지만 예외 로직이 늘수록 업그레이드, 테스트, 교육, 장애 대응 비용이 계속 커진다.

요구사항을 판단하는 질문

1. 법규나 핵심 경쟁력 때문에 반드시 필요한가?
2. 과거 시스템의 한계를 우회하던 절차는 아닌가?
3. 표준 기능의 설정이나 업무 변경으로 해결할 수 있는가?
4. 예외가 발생하는 빈도와 금액은 얼마나 되는가?
5. 개발 후 누가 소유하고 검증할 것인가?

표준화는 현업을 시스템에 억지로 맞추는 일이 아니다. 여러 부서가 서로 다른 방식으로 처리하던 거래를 비교해 가장 단순하고 통제 가능한 공통 흐름을 정하는 과정이다.

맞춤개발은 표준 프로세스로 해결할 수 없는 명확한 사업 가치가 있을 때 선택해야 한다. 그래야 ERP가 낡은 관행을 굳히는…

ERP 프로젝트가 실패하는 세 가지 축: 사람·프로세스·데이터

기술만 준비해서는 ERP가 정착하지 않으며 역할 변화, 업무 설계, 데이터 정비가 함께 움직여야 한다.

ERP 프로젝트의 문제를 프로그램 오류로만 보면 근본 원인을 놓친다. 시스템은 설계된 프로세스와 입력된 데이터를 실행할 뿐이며 실제 변화는 사람이 만든다.

세 축의 실패 신호

• 사람: 의사결정자가 없고 교육이 화면 사용법에 그친다.
• 프로세스: 부서별 목표가 충돌하고 예외 처리 기준이 없다.
• 데이터: 코드 소유자가 없고 이관 검증을 마지막에 몰아서 한다.

세 축은 서로 연결된다. 책임이 모호하면 기준정보가 방치되고, 프로세스가 정리되지 않으면 예외 데이터가 늘어나며, 데이터가 신뢰받지 못하면 사용자는 다시 엑셀로 돌아간다.

프로젝트 계획에도 개발 진척률만 두지 말고 프로세스 확정률, 데이터 정제율, 사용자 시나리오 통과율, 현업 의사결정 지연 건수를 함께 넣어야 한다. ERP 성공은 오픈 날짜가 아니라 실제 업무가 시스템 안에서 안정적으로…

단일 진실 공급원은 화면 하나를 뜻하지 않는다

여러 분석 화면이 존재해도 원천 거래와 지표 정의가 일관되면 조직은 같은 사실을 기준으로 판단할 수 있다.

단일 진실 공급원, 즉 Single Source of Truth는 모든 사용자가 같은 화면만 보아야 한다는 뜻이 아니다. 영업과 재무는 같은 거래를 보더라도 필요한 관점과 집계 수준이 다르다.

중요한 것은 숫자의 출처와 정의다. 매출, 재고, 수주잔고 같은 지표가 어느 거래를 포함하고 어떤 시점을 기준으로 하는지 합의되어야 한다. 보고서마다 필터와 계산식이 다르면 ERP 안에서도 여러 진실이 생긴다.

일관성을 만드는 장치

• 원천 거래의 책임 시스템을 정한다.
• 핵심 지표의 정의서와 담당자를 둔다.
• 수작업 보정은 사유와 승인 이력을 남긴다.
• 보고서 간 차이를 정기적으로 대사한다.
• 분석용 복제 데이터의 갱신 시점을 표시한다.

ERP는 데이터를 중앙에 모으는 것에서 끝나지 않는다. 같은 숫자가 왜 같은지, 다르다면 왜 다른지를 설명할 수…

전체 흐름 정리

이 글의 권장 읽기 흐름은 ERP는 회계 프로그램이 아니라 공통 데이터 시스템이다 → 기준정보가 ERP 품질을 결정한다 → ERP 맞춤개발보다 프로세스 표준화가 먼저다 → ERP 프로젝트가 실패하는 세 가지 축: 사람·프로세스·데이터 → 단일 진실 공급원은 화면 하나를 뜻하지 않는다 순서입니다. 먼저 앞의 개념으로 기준을 세운 뒤 뒤의 사례와 응용으로 이동하면 각 지식이 따로 흩어지지 않습니다. 읽으면서 자신의 경험이나 기존 메모와 연결되는 지점을 한 줄로 덧붙이면, 이 가이드는 단순한 정보 모음이 아니라 다시 활용할 수 있는 개인 지식망의 출발점이 됩니다.