안녕하세요, 비즈니스 혁신 파트너 BSG입니다.
SAP ERP 전환 프로젝트는 왜 이렇게 자주 삐걱거릴까요?
일정이 늘어지고, 예산이 초과되고, 오픈 직후 현업에서 "이전이 더 편했어요"라는 말이 나옵니다.
컨설턴트가 문제일까요? 제품이 문제일까요?
현장에서 수많은 SAP 프로젝트를 가까이서 보다 보면, 실패하는 프로젝트에는 놀랍도록 비슷한 패턴이 있습니다.
오늘은 성공과 실패를 가르는 그 패턴들을 PMO 관점에서 솔직하게 정리해드립니다.실패 패턴 1. 경영진이 킥오프 이후 사라진다
프로젝트 시작할 때는 경영진이 전폭적인 지지를 선언합니다.
킥오프 행사도 성대하게 합니다.
그런데 한 달쯤 지나면 경영진은 일상 업무로 돌아가고, 프로젝트는 실무 IT팀과 컨설턴트 몇 명이 끌어가게 됩니다.
문제는 SAP 전환 과정에서 부서 간 프로세스 조율, 데이터 기준 통일, 업무 방식 변경 같은 결정들이 반드시 나온다는 겁니다.
이런 결정들은 실무 담당자 선에서 해결되지 않습니다. 결정권자가 없으면 이슈가 쌓이고, 쌓인 이슈는 오픈 직전에 한꺼번에 터집니다.
체크포인트: 경영진이 격주 혹은 월 1회 이상 프로젝트 현황을 직접 챙기는 구조가 있는가?
IT팀과 컨설턴트가 설계를 다 해놓고, 오픈 2~3개월 전에 현업을 불러서 교육시키는 방식으로 진행하는 프로젝트가 있습니다.
결과는 거의 예외 없이 같습니다.
현업이 "이건 우리 업무 방식이랑 다른데요?"라고 말합니다.
그 시점에 설계를 바꾸는 건 이미 너무 늦었거나, 바꾸더라도 엄청난 비용이 발생합니다.
SAP 전환은 IT 프로젝트가 아니라 업무 변화 프로젝트입니다.
현업이 설계 단계부터 참여해서 "이 프로세스는 왜 이렇게 됐는지" 이해하고 수용해야 나중에 저항이 없습니다.
체크포인트: 영업, 재무, 구매, 물류 등 핵심 현업 담당자가 설계 단계(Blueprint)부터 참여하고 있는가?
"데이터는 나중에 이관하면 되겠지"라는 생각으로 프로젝트 후반부에 데이터 작업을 몰아서 하는 경우가 많습니다.
막상 해보면 현실이 기대와 다릅니다.
수십 년간 쌓인 마스터 데이터에는 중복된 거래처가 수백 개, 기준이 제각각인 자재 코드, 담당자가 바뀌면서 의미를 잃어버린 필드들이 가득합니다.
이걸 오픈 한 달 전에 정제하려고 하면 결국 두 가지 중 하나입니다.
일정을 미루거나, 더러운 데이터를 그대로 올리거나. 둘 다 좋은 선택이 아닙니다.
체크포인트: 데이터 정제 작업이 프로젝트 초반(설계 완료 직후)에 시작되어 있는가?
"이것도 되면 좋겠는데요", "저 기능도 이번에 넣으면 안 되나요?"
현업의 요구는 프로젝트가 진행될수록 늘어납니다.
컨설턴트 입장에서도, 내부 IT팀 입장에서도 거절하기가 쉽지 않습니다.
이른바 Scope Creep(범위 확산) 입니다.
처음 계획한 범위가 20~30% 늘어나면 일정은 두 배가 됩니다.
그런데 예산과 기간은 그대로입니다.
결국 품질이 희생됩니다.
체크포인트: 범위 변경을 공식 프로세스(Change Request)를 통해서만 수용하는 통제 구조가 있는가?
오픈 일정에 쫓기다 보면 테스트가 부실해집니다.
담당자가 간단히 클릭해보고 "됩니다"라고 확인하는 수준으로 끝나는 경우가 있습니다.
문제는 실제 업무는 훨씬 복잡하다는 겁니다.
한 달에 한 번 처리하는 특수 케이스, 연말 결산 시나리오, 특정 조건에서만 발생하는 예외 상황 — 이런 것들이 테스트에서 빠지면 오픈 직후에 에러로 터집니다.
체크포인트: 테스트 시나리오가 실제 현업 업무 흐름(End-to-End) 기준으로 작성되어 있는가? 현업 담당자가 직접 테스트에 참여하고 있는가?
Go-Live(오픈) 당일, 컨설턴트들이 현장에 와서 긴장하며 지켜봅니다.
큰 문제 없이 오픈이 되면 모두 안도합니다.
그리고 2주 후, 컨설턴트들이 프로젝트를 마무리하고 빠져나갑니다.
그때부터 진짜 문제가 시작됩니다.
현업 담당자들은 아직 새 시스템에 익숙하지 않고, 질문은 넘쳐나는데 답해줄 사람이 없습니다.
내부 Key User가 제대로 육성되지 않았다면, 현업의 불만은 빠르게 쌓입니다.
체크포인트: Go-Live 이후 최소 1~3개월의 안정화 지원 계획이 프로젝트 계획에 포함되어 있는가? 내부 Key User가 충분히 육성되었는가?
| 체크 항목 | 확인 |
|---|---|
| 경영진이 정기적으로 프로젝트를 직접 챙기는가 | ☐ |
| 현업이 설계 단계부터 참여하고 있는가 | ☐ |
| 데이터 정제가 프로젝트 초반에 시작되었는가 | ☐ |
| 범위 변경을 공식 프로세스로 통제하고 있는가 | ☐ |
| End-to-End 테스트에 현업이 직접 참여하는가 | ☐ |
| Go-Live 이후 안정화 지원 계획이 있는가 | ☐ |
SAP 전환이 실패하는 이유는 대부분 기술 문제가 아닙니다.
의사결정 구조, 현업 참여, 데이터 준비, 변화 관리 — 사람과 프로세스의 문제입니다.
위 체크리스트에서 체크되지 않는 항목이 많을수록, 프로젝트 리스크는 높아집니다.
지금 진행 중인 프로젝트라면 지금 확인하는 것이, 오픈 후에 수습하는 것보다 훨씬 쌉니다.
SAP 전환 프로젝트의 설계부터 안정화까지, BSG가 함께합니다.
출처 : SAP 공식 문서 — SAP Activate 방법론 및 프로젝트 관리 가이드 (https://www.sap.com/korea/products/erp/s4hana-erp/sap-activate.html)
기획 : 도예원