ERP 프로젝트가 지연되거나 예산을 초과했을 때, 원인을 따져보면 기술적인 문제보다 “누가 무엇을 하기로 했는지”가 애초에 명확하지 않았던 경우가 많습니다.
구축회사는 “고객사에서 요구사항을 늦게 확정해줬다”고 말하고, 고객사는 “구축회사가 알아서 챙겨줄 줄 알았다”고 말하는 상황은 흔히 발생합니다.
이러한 갈등은 계약 전 단계에서 고객사의 PM(프로젝트 매니저)과 PI(Process Innovator), 그리고 구축회사의 역할과 책임을 구체적으로 합의해두지 않았기 때문입니다.
이번 글에서는 ERP 구축 역할과 각 주체가 실제로 맡아야 할 책임을 정리하고, 역할 분담이 흐트러졌을 때 생기는 문제와 예방법을 살펴보겠습니다.
왜 ERP 구축 역할과 책임 구분이 프로젝트 성패를 좌우하는가
ERP 구축은 단순한 소프트웨어 설치가 아닙니다. 회사의 업무 프로세스를 시스템 위에 다시 설계하는 거대한 작업입니다.
이 과정에서 구축회사는 시스템을 만들고 이식하는 기술적 역할을, 고객사는 요구사항을 정의하고 검증하는 역할을 맡습니다. 어느 한쪽만으로는 프로젝트가 완성되지 않는 구조입니다.
문제는 이 역할 구분이 계약서에는 대략적으로만 적혀 있고, 실제 실무 단계로 내려오면 모호해지는 경우가 많다는 점입니다.
특히 고객사 내부에서 PM과 PI의 역할이 겹치거나, 아무도 맡지 않는 영역이 생기면 구축회사가 임의로 판단하게 되어 나중에 대대적인 재작업으로 이어집니다.
고객사 PM의 역할과 책임
고객사 PM은 프로젝트 전체를 대표해 구축회사와 소통하는 창구이자, 내부적으로는 각 부서의 협조를 이끌어내는 조율자입니다.
일정과 예산을 총괄 관리하고, 부서별 요구사항이 충돌할 때 우선순위를 결정하며, 구축회사의 산출물을 검토하고 승인하는 역할을 맡습니다.
- 의사결정 지연 최소화: ERP 프로젝트는 화면 설계, 권한 체계 등 끊임없는 결정이 필요합니다. 이 결정이 미뤄지면 전체 개발 일정이 밀리게 됩니다.
- 리소스 확보 및 조정: 현업 담당자가 본업과 프로젝트 업무를 병행하느라 지치지 않도록, 내부 참여 인력의 업무 시간을 확보해 주어야 합니다.
고객사 PI(핵심 사용자)의 역할과 책임
PI는 각 업무 영역(영업, 구매, 생산, 회계 등)에서 현재 프로세스를 가장 잘 이해하고 있는 실무자입니다.
PM이 프로젝트 전체를 관리하는 관리자라면, PI는 자기 업무 영역의 ‘기술 자문’ 겸 ‘최종 검수자’에 가깝습니다.
- 예외 상황 공유: 현재 업무 프로세스를 구축회사에 정확히 설명하고, 비정기적인 특수 처리 케이스까지 빠짐없이 전달해야 설계 누락을 막을 수 있습니다.
- 설계안 피드백 및 검증: 구축회사가 제시하는 화면과 프로세스 설계안을 검토하고, 실제 업무 흐름에 맞는지 꼼꼼하게 피드백합니다.
- 테스트 및 사내 교육: 실제 데이터로 시스템을 최종 검증하고, 오픈 이후에는 부서 내 다른 직원들에게 사용법을 전파하는 사내 강사 역할을 수행합니다.
💡 핵심 팁: PI 업무는 본업과 병행되는 경우가 많아 시간 확보가 어렵습니다. 프로젝트 시작 전 이들의 본업 부담을 반드시 일부 조정해 주어야 시스템의 완성도가 올라갑니다.
구축회사의 역할과 책임
구축회사는 고객사가 정리한 요구사항을 시스템으로 구현하고, 프로젝트 방법론에 따라 일정과 산출물을 관리하는 주체입니다.
요구사항 분석, 시스템 설계, 개발 및 커스터마이징, 데이터 이관 지원, 테스트, 교육, 오픈 이후 안정화까지 전 과정의 기술적 책임을 집니다.
구축회사 PM은 일정 리스크를 조기에 알리고, 고객사가 제때 의사결정을 내릴 수 있도록 필요한 정보를 미리 요청하는 능력이 중요합니다.
또한, 표준 기능으로 해결 가능한 영역과 반드시 커스터마이징이 필요한 영역을 명확히 구분해 주어야 향후 유지보수 비용을 줄일 수 있습니다.
역할이 불분명할 때 흔히 생기는 문제
역할 구분이 흐트러지면 몇 가지 치명적인 문제가 반복적으로 나타납니다.
- 임의 개발과 재작업: 요구사항 확정 주체가 불분명하면 구축회사가 임의로 개발을 진행하고, 이후 고객사가 전면 수정을 요구하게 됩니다.
- 검증 누락: PI가 형식적으로만 참여하면, 시스템 오픈 직전이나 오픈 이후에야 실제 업무와 맞지 않는 심각한 결함이 발견됩니다.
- 대기 비용 발생: PM이 부서 간 이견을 조율하지 못해 의사결정이 지연되면, 구축회사 투입 인력의 대기 비용이 고스란히 예산 낭비로 이어집니다.
역할 분담을 명확히 하는 실무적 방법
가장 확실한 방법은 프로젝트 착수 단계에서 RACI 표(RACI Matrix)와 같은 역할 분담표를 작성해 문서화하는 것입니다.
RACI 모델이란? 각 업무와 산출물에 대해 실행 책임자(Responsible), 최종 승인자(Accountable), 자문 제공자(Consulted), 결과 통보 대상자(Informed)를 지정하는 글로벌 표준 역할 분배 프레임워크입니다. (참고: 위키백과 RACI 모델 설명)
또한, 주간 정기 회의를 통해 지연 리스크를 상시 점검하고, 모든 요구사항 변경 이력은 구두가 아닌 서면(문서)으로 남겨 분쟁을 예방해야 합니다.
- 관련 글 추천: ERP 도입 전 반드시 체크해야 할 예산 수립 가이드는 [ERP 도입 비용 예산 짜는 법]에서 확인하실 수 있습니다. (※ 실제 운영 중인 내부 링크 삽입 영역)
프로젝트 착수 전 점검하면 좋은 질문들
- 고객사 PM과 PI의 역할이 문서로 구분되어 있고, 두 역할을 겸임하는 인원은 없는가?
- 부서별 PI가 선정되어 있고, 해당 인원의 본업 업무 부담이 일부 조정되었는가?
- 요구사항 및 설계 산출물에 대한 최종 승인 권한이 누구에게 있는지 명확한가?
- 요구사항 미확정 시 구축회사가 의사결정을 요청하는 공식 절차가 계약서에 있는가?
- 주요 의사결정과 요구사항 변경 사항을 문서로 남기는 프로세스가 마련되어 있는가?
정리하며
성공적인 ERP 구축의 핵심은 기술력 자체보다, 고객사와 구축회사가 서로의 ERP 구축 역할을 얼마나 명확히 이해하고 실행하느냐에 달려 있습니다.
프로젝트 착수 전 역할 분담표를 구체화하고 정기적인 점검 체계를 갖춤으로써, 흔히 발생하는 일정 지연과 갈등의 상당 부분을 예방하시기 바랍니다.
IT나라(ITNARA) | Odoo ERP/MES 구축 전문 기업 위고솔루션(wegosolution) 공식 IT 지식 블로그
대표: 최성남 | 홈페이지: www.wegosolution.co.kr