커리어 초반, 필자는 한 중견 제조기업이 ERP(전사적자원관리) 시스템 구축에 18개월을 투입하고도 결국 정상 가동에 실패하는 과정을 지켜본 적이 있다. 이 기업은 당초 예산의 몇 배에 달하는 비용을 지출했지만 프로젝트는 끝내 성공하지 못했다. 프로젝트 종료 후 진행된 평가에서는 예상대로 벤더가 주요 책임자로 지목됐다. 소프트웨어는 지나치게 복잡하다는 비판을 받았고, 구축 파트너는 지원이 부족했다는 이유로 비난받았다. 해당 프로젝트는 업계의 대표적인 실패 사례로 남았다.
필자는 제조업, 금융 서비스, 헬스케어, 연방 정부 계약 분야에서 25년 넘게 엔터프라이즈 소프트웨어 구축 프로젝트를 이끌어 왔다. 그 과정에서 비슷한 장면을 셀 수 없을 만큼 많이 목격했다. ERP 프로젝트가 실패하면 책임은 늘 조직 외부로 향했다.
이 같은 통념에 의문을 갖기 시작한 것은 월든대학교(Walden University) 박사 과정에서 소규모 기업의 ERP 구축 전략을 연구하면서부터다. ERP 구축 실패율은 이미 널리 알려져 있다. 업계 분석가들은 ERP 프로젝트의 50~75%가 당초 목표를 달성하지 못한다고 추정한다. 나이키는 ERP 구축 실패로 1억 달러(약 1,370억 원) 이상의 손실을 입었고, 웨이스트 매니지먼트(Waste Management)의 프로젝트 실패는 5억 달러(약 6,850억 원)가 넘는 비용을 초래했다. 하지만 이러한 실패 사례를 분석한 연구 대부분은 대기업에 초점을 맞추고 있다. 실수의 여지가 적고 회복 수단도 제한적인 소규모 기업은 상대적으로 연구 대상에서 소외돼 왔다.
이에 필자는 충분히 연구되지 않았던 환경에서 답을 찾고자 했다. 그리고 그 과정에서 ERP 프로젝트의 성공과 실패 원인에 대해 기존에 갖고 있던 거의 모든 가정이 흔들리는 결과를 마주했다. 동시에 단순한 경고 사례를 넘어, 실제로 ERP 구축에 성공한 조직들이 무엇을 했는지 보여주는 명확한 근거도 발견할 수 있었다.
연구가 밝혀낸 사실
박사 논문 연구를 위해 필자는 최근 5년 이내 ERP 시스템을 성공적으로 구축한 경험이 있는 펜실베이니아 중부 지역 소규모 기업의 IT 관리자 6명을 심층 인터뷰했다. 또한 프로젝트 헌장, 구축 계획서, 교육 기록, 변경 관리 로그, 구축 후 평가 자료 등을 검토했다. 목적은 성공적인 ERP 프로젝트를 구분 짓는 공통 패턴을 찾는 것이었다.
분석 결과, 모든 사례에서 세 가지 공통 주제가 반복적으로 나타났다. 바로 구축 준비, 구축 방식, 그리고 범위 관리였다. 이는 크게 놀라운 결과는 아니었다. 진짜 의외였던 점은 참가자들에게 자신들이 통제할 수 없는 외부 요인에 대해 질문했을 때 드러났다.
6명 가운데 단 한 명도 벤더를 지목하지 않았다.
필자는 각 관리자에게 벤더와의 관계, 벤더 지원 수준, 규제 환경, 시장 상황 등 외부 요인이 프로젝트에 어떤 영향을 미쳤는지 구체적으로 물었다. 답변은 모두 비슷했다. 프로젝트 결과를 좌우한 요인이 무엇이었는지를 묻자 모든 관리자가 조직 내부를 바라봤다. 변화 관리, 전략적 정렬, 준비 수준, 그리고 범위 관리가 핵심 요인이라는 것이다.
이 같은 결과는 벤더 관계와 외부 환경을 ERP 프로젝트의 주요 위험 요소로 규정하는 기존 연구와는 다소 다른 시각을 보여준다. 그러나 인터뷰 대상 관리자들에게 외부 요인은 거의 영향을 미치지 않았거나, 강력한 내부 관리 체계를 통해 사실상 무력화됐다. 결국 프로젝트의 성패에 대한 책임은 조직 내부에 있었던 셈이다.
ERP 성패를 좌우하는 3가지 핵심 요소
분명히 해두고 싶은 점이 있다. 필자는 벤더에게 책임이 전혀 없다고 주장하는 것이 아니며, 외부 요인이 중요하지 않다고 말하는 것도 아니다. 이번 연구가 진행된 지역적·산업적 환경은 비교적 안정적인 벤더 관계와 낮은 규제 복잡성을 제공했을 가능성이 있다. 따라서 규제가 엄격한 산업이나 시장 변동성이 큰 환경에 있는 조직은 다른 결과를 경험할 수도 있다.
다만 이번 연구는 많은 중소·중견 기업에서 ERP 성공 여부를 결정하는 핵심 요인이 조직 내부에 있다는 사실을 보여준다. 실제 사례를 통해 드러난 핵심 요소는 다음과 같다.
• 준비가 모든 것의 출발점이다. 모든 참가자는 철저한 사전 준비를 성공의 기반으로 꼽았다. 여기서 말하는 준비는 단순한 계획 수립이 아니다. ERP 프로젝트를 시작하기 전에 조직의 전략적 목표와 ERP 도입 목적을 명확히 연결하고, 이를 측정 가능한 비즈니스 성과와 연계하는 작업을 의미한다. 또한 적극적인 경영진 후원이 필요했다. 단순히 승인만 하는 것이 아니라 경영진이 프로젝트에 직접 참여하고 중요성을 지속적으로 알리며 부서 간 책임 이행을 관리해야 했다. 도입 전략 선택도 중요한 요소였다. 인터뷰에 참여한 관리자 6명 중 5명은 전 기능을 한 번에 전환하는 ‘빅뱅(Big Bang)’ 방식 대신 단계적 구축 방식을 선택했다. 기능을 순차적으로 도입한 조직일수록 시스템 전환 과정이 원활했고 사용자 수용률도 높았다. 데이터 마이그레이션 역시 실제 운영 직전에 뒤늦게 해결할 문제가 아니라 프로젝트 첫날부터 핵심 업무로 관리됐다.
• 무엇을 계획하느냐만큼 어떻게 실행하느냐도 중요하다. 구축 방식과 관련해 가장 눈에 띄는 발견은 역할 기반의 부서별 맞춤 교육이었다. 참가자 6명 중 5명은 이를 성공의 필수 요소로 꼽았다. ERP를 효과적으로 활용하려면 단순한 시스템 소개 교육만으로는 부족하다. 직원들은 ERP가 자신의 일상 업무와 어떻게 연결되는지 이해해야 한다. 이처럼 직무와 역할에 맞춘 교육에 투자한 관리자들은 일관되게 높은 사용자 수용률과 낮은 내부 저항을 경험했다고 답했다. 교육 외에도 강력한 거버넌스 체계, 프로젝트 전 과정에 걸친 적극적인 변화 관리, 그리고 과도한 커스터마이징을 지양하고 표준 기능 활용을 우선하는 운영 원칙이 중요한 성공 요인으로 확인됐다.
• 범위 관리는 타협할 수 없는 요소다. 인터뷰에 참여한 6명의 관리자 모두 예외 없이 범위 관리를 핵심 성공 요인으로 꼽았다. 이번 연구에서 가장 강하게 공통적으로 나타난 주제이기도 하다. 범위 확장(scope creep)은 대개 눈에 띄지 않게 진행된다. 한 이해관계자가 추가 보고서를 요청하고, 특정 부서는 표준 설정으로 처리할 수 없는 방식의 프로세스를 요구한다. 각각의 요청만 놓고 보면 충분히 합리적으로 보인다. 하지만 이런 요구가 누적되면 프로젝트 복잡성은 증가하고 일정은 늘어나며 예산은 빠르게 소진된다. 성공한 관리자들은 공식적인 범위 기준선을 유지했고, 모든 커스터마이징 요청에 대해 서면 비즈니스 근거를 제출하도록 했다. 또한 모든 변경 요청을 당초 프로젝트 목표와 비교 검토한 뒤 승인 여부를 결정했다. 이 같은 규율은 프로젝트 진행 속도를 늦추기 위한 것이 아니다. 프로젝트 범위에 추가되는 모든 요소가 비용과 영향을 충분히 이해한 상태에서 의도적으로 결정되도록 하기 위한 것이다. 그렇지 않으면 개별적으로는 타당해 보이는 수많은 결정이 쌓여 프로젝트가 원래 달성하려던 목표 자체를 서서히 바꿔버릴 수 있다.
다음 ERP 프로젝트를 이끄는 방식이 중요한 이유
필자는 ERP 프로젝트가 실패했을 때 벤더를 탓하는 이야기가 왜 끊이지 않는지 오랫동안 고민해 왔다. 그 이유 중 하나는 그것이 더 쉽기 때문이라고 생각한다. 벤더가 실패의 원인이라면 문제는 조직의 통제 범위 밖에 있다. 그러면 배울 것도 없고, 다음에는 무엇을 달리해야 할지 고민할 필요도 없으며, 스스로 책임을 돌아볼 이유도 사라진다.
하지만 이번 연구 결과가 맞다면, 그리고 필자는 그렇다고 믿는다. ERP 프로젝트가 실패한 뒤 IT 리더들이 스스로에게 들려주는 이야기가 오히려 다음 실패를 막을 수 있는 교훈을 가리는 요인이 될 수 있다.
필자는 이러한 상황을 양쪽 모두에서 경험했다. 경영진이 적극적으로 참여하고, 프로젝트 범위가 철저히 관리되며, 실제 업무 방식을 반영한 교육이 제공된 조직에서는 ERP 구축이 성공적으로 이뤄졌다. 반면 유능한 벤더와 우수한 소프트웨어를 도입했음에도 어려움을 겪은 프로젝트도 있었다. 변화 관리를 전략적 과제가 아닌 단순한 커뮤니케이션 업무로 취급했거나, 개별적으로는 합리적으로 보이는 수십 건의 의사결정이 누적되면서 프로젝트 범위가 조금씩 확대된 경우였다.
기술 자체가 문제인 경우는 드물다. ERP 프로젝트의 성패는 리더십과 계획 수립, 그리고 이해관계자들의 요구로부터 프로젝트를 보호할 수 있는 규율에 달려 있다. 필자는 지금까지 실패 원인이 진정으로 소프트웨어 자체였던 ERP 프로젝트를 거의 보지 못했다. 대신 소프트웨어가 설정되기도 훨씬 전에 내려진 의사결정 때문에 실패한 사례는 수없이 목격했다.
ERP 프로젝트를 준비하고 있거나, 이미 진행 중인 프로젝트가 방향을 잃고 있다면 문제가 발생할 때 조직 외부에서 원인을 찾으려는 본능을 경계해야 한다.
프로젝트 준비 상태를 점검하라. 범위 기준선(scope baseline)을 다시 살펴보라. 교육 프로그램이 단순히 교육 실시 여부를 채우는 수준인지, 아니면 실제 업무 역량을 키우고 있는지 평가하라. 프로젝트 후원자인 경영진이 적극적으로 참여하고 있는지, 아니면 이름만 올려놓은 상태인지도 확인해야 한다.
프로젝트 결과는 일반적인 사후 평가가 암시하는 것보다 훨씬 더 조직의 통제 범위 안에 있다. 그리고 그 사실을 인정하는 것이 결과를 바꾸기 위한 첫걸음이다.
dl-ciokorea@foundryco.com