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

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

ERP를 이해하려면 기능 목록보다 한 건의 거래가 부서를 넘어가는 과정을 보는 편이 좋습니다. 이 글은 품목 단위 오류와 부서별 지표 차이를 예로 들어 공통 데이터와 업무 규칙이 왜 필요한지 설명합니다.

아래 수치와 업무 상황은 설명을 위한 가상 사례입니다. 실제 화면·전표·계획 결과는 ERP 제품, 설정, 계약 및 적용 회계기준에 따라 달라질 수 있습니다.

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

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

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

ERP가 연결하는 흐름

1. 영업 주문은 수요와 출하 계획이 된다.
2. 출하는 재고 감소와 청구의 근거가 되고, 계약상 수익 인식 요건에 맞춰 회계와 연결된다.
3. 구매 입고는 재고와 입고 미청구 등의 기록으로 이어지고, 송장 확인과 채무 확정 단계로 연결된다.
4. 생산 실적은 원재료, 완제품, 원가에 동시에 영향을 준다.

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

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

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

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

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

좋은 기준정보의 조건

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

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

ERP 운영 품질을 높이려면 월별 오류 수정뿐 아니라 중복률, 미사용 코드, 필수값 누락처럼 기준정보 자체의 품질도 관리해야 한다. 다만 숫자만 낮추려고 과거 코드를 삭제하면 거래 이력이 손상될 수 있다. 중복은 대표 코드와의 매핑, 적용일, 기존 문서 처리 방침을 정해 해소한다. 기준정보의 반복 사용과 일관성 문제는 SAP의 MDM 설명에서도 확인할 수 있다.

단위 하나가 재고와 원가를 바꾸는 사례

같은 볼트를 구매팀은 BOX, 창고는 EA로 관리하며 1 BOX = 100 EA라고 하자. 10 BOX 입고는 1,000 EA여야 한다. 단위 환산이 빠져 10 EA로 전송되면 실제 수량과 장부 수량이 990 EA 차이 난다. 총 매입금액이 100만원이라면 실제 개당 원가는 1,000원이지만, 잘못된 수량 10으로 나누면 10만원으로 보인다.

해결은 재고 수량만 990개 늘리는 것으로 끝나지 않는다. 원래 발주 단위, 기본 재고 단위, 단위 환산, 가격 단위를 확인하고 해당 거래 및 이후 영향까지 추적해야 한다.

기준정보	확인할 핵심 속성	책임 역할 예시
품목	기본 단위, 구매 단위, 환산, 품목군	자재·생산 담당과 승인자
거래처	고유 식별 정보, 지급 조건, 계좌 변경 이력	구매·영업 등록자와 별도 검토자
계정·조직	전표 매핑, 책임 부서, 적용 기간	회계·관리 담당
창고	실물 위치, 재고 상태, 사용 가능 여부	물류 담당

책임 역할은 회사에 맞게 정하되 생성·변경·승인을 한 사람이 무제한 처리하지 않도록 위험을 검토한다.

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

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

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

요구사항을 판단하는 질문

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

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

맞춤개발은 표준 프로세스로 해결할 수 없는 명확한 사업 가치가 있을 때 선택해야 한다. 그래야 ERP가 낡은 관행을 굳히는 도구가 아니라 공통 업무를 유지하는 기반이 된다.

예를 들어 부서마다 다른 '긴급 구매' 화면을 각각 개발하기 전에 요청 → 예산 확인 → 발주 → 검수 → 송장 → 지급이라는 공통 흐름을 정한다. 긴급 상황에서는 어느 승인을 사후 보완할 수 있는지, 누가 언제까지 근거를 남길지 명시한다. 표준 흐름과 예외 흐름 모두를 실제 거래 한 건으로 테스트해야 표준화가 문서에만 남지 않는다.

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

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

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

세 축의 실패 신호

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

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

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

테스트 역시 '발주 저장 성공' 한 건으로 끝내지 않는다. 부분 입고, 주문 취소, 반품, 계좌 변경, 마감 후 수정처럼 경계를 넘는 시나리오를 넣는다. 오류가 생기면 화면 담당자만 지정하지 말고 업무 결정권자, 데이터 수정 담당자, 재검증자를 나눠 기록한다.

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

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

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

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

일관성을 만드는 장치

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

ERP는 데이터를 중앙에 모으는 것에서 끝나지 않는다. 같은 숫자가 왜 같은지, 다르다면 왜 다른지를 설명할 수 있어야 비로소 통합 운영이 된다.

영업과 회계의 숫자가 다른데 둘 다 맞을 수 있다

월말 주문 1,000만원 중 고객에게 통제가 이전되어 수익 인식 요건을 충족한 금액이 700만원, 수금한 금액이 500만원이라고 하자. 영업의 수주 1,000, 회계의 매출 700, 자금의 수금 500은 서로 다른 질문에 답한다. 이를 모두 '매출'로 표시하면 불필요한 오류 논쟁이 생긴다.

따라서 지표 정의서에는 이름, 원천 문서, 인식 기준일, 포함·제외 상태, 취소·반품 처리, 세금 포함 여부, 통화와 갱신 시각을 남긴다. 정의를 맞춘 뒤에도 차이가 있으면 미전송 거래, 중복 전송, 마감 시각 차이와 수작업 보정을 순서대로 추적한다.

첫 개선 대상으로 거래 한 건을 고르자

ERP 전체를 한 번에 고치기 어렵다면 오류가 자주 생기는 주문이나 구매 한 건을 골라 발주서부터 입고·청구·회계 전표까지 문서 번호를 따라가 보자. 같은 품목과 거래처를 쓰는지, 상태가 누락되지 않았는지, 금액 차이를 설명할 수 있는지 적는다.

그 결과를 '기준정보 오류', '업무 규칙 미합의', '연계 누락', '권한·승인 문제'로 나누면 무조건 개발부터 하는 일을 줄일 수 있다. ERP의 통합성은 데이터베이스가 하나인지보다 한 거래의 전후 관계를 설명할 수 있는지에서 드러난다.

숫자가 회계에 도달하는 구체적인 과정은 ERP 구매·지급·매출·수금 가이드, 생산 자재 계산은 MRP·BOM·재고 가이드로 이어서 읽을 수 있다.