- Panorama Consulting Group의 2024년 ERP 연구에서 ERP 구현 프로젝트 중 예산 초과의 주요 원인 1위로 요구사항 변경이 지목됐습니다. 요구사항이 구축 도중 바뀌는 것은 처음부터 확정되지 않았기 때문입니다.
- ERP는 현재 업무 프로세스를 반영합니다. 업무 프로세스가 문서화되지 않은 상태에서 ERP를 구축하면 개발자가 현장에서 담당자에게 하나씩 물어보며 프로세스를 역설계합니다. 그 과정에서 담당자마다 다른 답이 나오고 프로세스가 없던 일관성이 생기지 않습니다.
- ERP 구축 준비의 핵심은 소프트웨어 선정이 아닙니다. 조직 내에서 업무 프로세스를 정의하고 예외를 결정하는 권한이 누구에게 있는지를 먼저 확정하는 것입니다.
개발자가 현장에서 프로세스를 역설계하는 상황
식품 제조 중견기업이 기간 시스템 노후화를 이유로 ERP 전면 교체를 결정했습니다. 개발사와 계약 후 착수 미팅에서 개발사 PM이 요청했습니다. 영업 주문 접수부터 생산 계획, 출고까지의 업무 흐름을 문서로 주십시오. 담당팀이 제출한 것은 현행 시스템 화면 캡처와 구두 설명이었습니다. 문서화된 업무 프로세스가 없었습니다.
개발팀은 영업팀, 생산팀, 물류팀 담당자를 각각 인터뷰하며 프로세스를 파악했습니다. 세 팀이 설명한 주문 처리 프로세스는 각각 달랐습니다. 실제로는 담당자마다 다르게 처리해왔기 때문입니다. 개발팀은 세 가지 버전 중 하나를 선택해 개발했고, 테스트 단계에서 나머지 두 팀이 반발했습니다. 요구사항 변경이 시작됐습니다. 프로젝트 기간은 당초 8개월에서 14개월로 늘었습니다.
Panorama Consulting Group이 2024년 발표한 ERP 연구에서 조사 대상 기업의 절반 이상이 ERP 프로젝트 예산을 초과했고, 그 주요 원인 1위는 요구사항 변경이었습니다. 요구사항이 변경되는 이유의 대부분은 동일합니다. 구축 시작 전에 조직 내부에서 업무 프로세스에 대한 합의가 없었던 것입니다.
ERP가 반영하는 것은 현재 업무이지 이상적인 업무가 아닙니다
ERP 구축에서 흔한 오해가 있습니다. ERP를 도입하면서 업무도 함께 개선할 수 있다는 것입니다. 도입하면서 지저분한 프로세스를 정리할 수 있다고 생각합니다. 현실은 반대입니다. 업무 프로세스가 확정되지 않으면 ERP가 그 혼란을 시스템에 고정시킵니다. 일관성 없이 처리되던 예외 업무가 시스템 안에 예외 처리 로직으로 들어가고, 이후 그것을 바꾸는 비용이 훨씬 커집니다.
스탠디시 그룹(Standish Group)의 CHAOS 보고서는 IT 프로젝트 실패의 가장 큰 요인으로 요구사항 불완전성을 지속적으로 지목해왔습니다. ERP 프로젝트는 규모가 크고 기간이 길기 때문에 요구사항 불완전성의 영향이 더 크게 나타납니다. 요구사항을 완전히 만들려면 업무 프로세스가 먼저 정의되어야 합니다.
Ahn Partners 판단: ERP 구축 준비에서 소프트웨어 선정보다 먼저 해야 할 것이 있습니다. 조직 안에서 업무 프로세스를 정의하는 권한이 누구에게 있는지를 확정하는 것입니다. 영업팀과 생산팀의 프로세스가 충돌할 때 누가 최종 결정을 내리는가, 예외 처리를 어디까지 시스템에 담고 어디서부터는 수동으로 처리하는가를 결정할 수 있는 사람이 프로젝트 시작 전에 지정되어야 합니다.
ERP 전에 완료되어야 할 것
업무 프로세스 문서화는 모든 경우의 수를 완벽하게 정리하는 것이 목표가 아닙니다. 세 가지를 확인하는 것입니다. 첫째, 정상 흐름입니다. 가장 많이 발생하는 거래가 어떤 단계를 거치는지입니다. 둘째, 예외 유형입니다. 정상 흐름에서 벗어나는 경우가 얼마나 자주 발생하고 어떤 유형인지입니다. 셋째, 예외 처리 권한입니다. 예외가 발생했을 때 누가 어떤 기준으로 처리 방법을 결정하는지입니다.
이 세 가지가 문서로 존재하고 팀 간 합의가 완료된 상태라면 개발사에 전달할 수 있는 요구사항이 만들어집니다. 그 전에 개발사와 계약하면 개발사가 프로세스 설계 비용을 추가로 청구하거나, 개발팀이 임의로 선택한 프로세스로 시스템이 만들어집니다.
이번 주에 확인할 것은 이것입니다. ERP 구축을 계획하고 있다면 지금 조직 안에 업무 프로세스를 결정할 수 있는 권한이 있는 사람이 지정되어 있는가입니다. 없다면 소프트웨어 선정이 첫 번째 할 일이 아닙니다.
한 문장으로 정리하면
ERP 구축에서 요구사항이 바뀌는 이유는 시작 전에 업무 프로세스와 예외 처리 권한이 조직 내부에서 합의되지 않았기 때문이며, 이 준비가 소프트웨어 선정보다 먼저입니다.
점검 목록
- ERP 구축 전에 정상 흐름, 예외 유형, 예외 처리 권한의 세 가지가 팀 간 합의된 문서로 존재하는가
- 영업, 생산, 물류 등 부서 간 업무 충돌이 있을 때 최종 결정을 내릴 수 있는 사람이 프로젝트에 공식으로 지정되어 있는가
- 현재 담당자마다 다르게 처리하는 예외 업무 유형이 파악되어 있고, 그 중 어디까지 시스템에 담을지 결정된 상태인가