ERP PI 컨설팅은 왜 먼저 할까? ERP를 ‘다시 설계’하는 진짜 이유

많은 기업들이 ERP를 다시 설계한다.
이미 시스템이 있는데도 PI(Process Innovation)를 먼저 한다.

 

왜일까?

 

ERP는 단순 도입이 아니다.
운영 구조를 바꾸는 일이다.

 

그래서 ERP 프로젝트의 앞단에는 거의 항상 ERP PI 컨설팅이 붙는다.
PI는 “구축 전 설계”이며, 더 정확히 말하면 경영 운영 모델을 재정의하는 단계다.

---

1️⃣ ERP PI는 무엇을 하는가

ERP PI는 보통 아래 3단계로 설명된다.

• Discovery → 현실 진단
• Envisioning(To-Be) → 목표 운영 모델 설계
• Planning → 실행 가능한 계획(숫자)으로 전환

겉으로는 3단계지만, 실제로는 내부 작업이 훨씬 깊다.
그리고 이 3단계를 어떻게 품질 있게 연결하느냐가 PI의 성패를 가른다.

---

2️⃣ 1단계 – Discovery: “현실을 구조로 바꾸는 단계”

Discovery의 목적은 명확하다.
현재 상태(As-Is)를 진단하고 개선 방향을 도출하는 것.

 

이 단계에서 일반적으로 수행하는 작업은 다음과 같다.

1. 경영 환경 분석
2. 사례 및 벤치마킹 분석
3. 경영진/부서장/현업 인터뷰
4. As-Is 프로세스 분석
5. 기준정보 및 시스템 구조 분석
6. 주요 이슈 도출
7. 개선 방향 정의 워크숍

 

Discovery의 핵심은 Top-down과 Bottom-up을 동시에 보는 것이다.

• 경영진은 “전략”을 말한다.
• 현업은 “불편”을 말한다.

두 시각은 자주 충돌한다.
그래서 PI는 결국 의견을 ‘구조’로 바꾸는 정리 작업이다.

Discovery 산출물(예시)

• 내·외부 환경 분석서
• 인터뷰 결과서
• As-Is 프로세스 분석서
• 주요 현안 및 개선 방향 정의서

 

여기까지는 비교적 부드럽다.
진짜 난이도는 다음 단계에서 시작된다.

---

3️⃣ 2단계 – Envisioning(To-Be): “그림을 그리는 단계”

Envisioning은 단순히 이상론을 말하는 단계가 아니다.
실제로 돌아가는 운영 모델(To-Be)을 설계하는 단계다.

 

구체적으로는 아래 작업들이 진행된다.

1. 개선과제 정의
2. To-Be 프로세스 체계 수립(L1~L5 구조화)
3. 업무 흐름도 및 Activity 정의
4. E2E 시나리오 정립
5. 기능요건 정의
6. SAP 표준 기준 Fit & GAP 분석
7. 적용 솔루션 방향성 정리
8. To-Be 시스템 아키텍처 정의
9. 인터페이스 및 개발 목록 도출

 

여기서 반드시 던지는 질문이 있다.

“표준에 맞출 것인가, 기존 방식을 유지할 것인가?”

 

ERP PI의 핵심은 이 선택이다.

• 표준(Fit)을 따르면 운영은 단순해진다. 그러나 현업 저항이 커질 수 있다.
• 기존 방식을 유지(Gap 확장)하면 저항은 줄지만 혁신은 약해지고 유지보수 부담이 커질 수 있다.

여기서 Gap이 발생한다.

• 설정(Config)으로 해결
• 개발 필요(RICEF/W 등)
• 프로세스 변경 필요
• 조직 구조 변경 필요

 

예를 들어 아래 같은 항목은 단순 IT 이슈가 아니다.

• Company Code 재설계
• Profit Center 체계 정비
• 원가 구조 변경
• 마스터 데이터 통합

권한과 KPI가 바뀌기 때문에 합의가 어렵다.
그리고 이 단계 산출물은 이후 ERP 전체를 지배한다.

Envisioning 산출물(예시)

• To-Be 프로세스 맵
• 기능요건 정의서
• Fit & GAP 분석서
• 인터페이스 목록
• 개발 대상 리스트
• To-Be 아키텍처 정의서

 

여기서 잘못 정하면 구축 단계에서 반드시 되돌아온다.

---

4️⃣ 3단계 – Planning: “실행 가능한 숫자로 바꾸는 단계”

설계가 끝나면 현실이 시작된다.
Planning은 좋은 그림을 실행 가능한 계획으로 바꾸는 단계다.

1. 추진 범위 확정
2. 단계별 로드맵 수립
3. 일정 및 방법론 정의
4. 공수 산정
5. 예산 산정
6. ROI 분석
7. 마이그레이션 전략 수립

이때 가장 많이 나오는 말은 대체로 같다.

• “이 예산으로 가능한가?”
• “이 일정이 현실적인가?”

설계는 이상적이고 예산은 현실적이다.
이 지점에서 긴장이 발생한다.

---

5️⃣ ERP PI 컨설팅의 구조적 한계

PI 프로세스는 체계적이다.
하지만 한계도 명확하다.

(1) 사람 중심 분석 구조

• 인터뷰 기반
• 워크숍 기반
• 합의 기반

요구사항 정의는 사람의 언어에 의존한다.
경험 많은 컨설턴트일수록 결과물이 정교하지만, 표준화는 어렵다.

(2) 문서 중심 산출물

수십 개 문서가 나온다.
프로세스 맵, 요건 정의서, GAP 목록…

 

문서는 완성된다.
하지만 실행은 별개의 문제다.
문서가 행동을 바꾸지는 않는다.

(3) 조직 변화 저항

ERP는 시스템 교체가 아니다.
권한 구조와 책임을 재정의한다.

• SoD 강화
• 승인 체계 변경
• 조직 단위 통합

이건 정치적 이슈다.
보고서로 해결되지 않는다.

(4) 데이터 현실을 과소평가

PI 단계에서는 데이터 이슈가 “리스크 항목”으로 정리된다.
하지만 실제 프로젝트에서는 데이터가 가장 큰 변수다.

 

마스터 데이터 품질이 낮으면 To-Be는 작동하지 않는다.

(5) 실행 단계와의 단절

PI는 설계를 잘한다.
하지만 구축은 또 다른 세계다.

• 현업 리소스 부족
• 추가 요구사항 발생
• 일정 압박
• 예산 제약

설계와 실행 사이에 온도 차가 생긴다.
이 간극이 반복된다.

---

그래서 ERP PI에 AI가 들어가면 무엇이 달라질까?

ERP PI는 필요하다. 구조를 정리해준다.
하지만 여전히 사람 중심이고, 회의 중심이며, 수작업 분석이 많다.

 

수백 개 기능, 수천 건 데이터, 수많은 프로세스 연결을
사람이 모두 관리하는 방식은 한계가 명확하다.

 

그래서 질문이 남는다.

ERP PI 과정에 데이터 기반 분석과 AI가 들어가면, 무엇이 달라질까?

 

ERP는 거대한 시스템이고, AI는 거대한 데이터 처리 엔진이다.
둘의 결합은 생각보다 자연스럽다.

 

다음 글에서는 ERP PI 단계에 AI를 접목하는 구조를 구체적으로 다뤄보겠다.
여기서부터가 진짜 이야기다.