Skip to content
Tiatra, LLCTiatra, LLC
Tiatra, LLC
Information Technology Solutions for Washington, DC Government Agencies
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact
 
  • Home
  • About Us
  • Services
    • IT Engineering and Support
    • Software Development
    • Information Assurance and Testing
    • Project and Program Management
  • Clients & Partners
  • Careers
  • News
  • Contact

칼럼 | ERP 구축 실패의 원흉은 벤더가 아니다

커리어 초반, 필자는 한 중견 제조기업이 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


Read More from This Article: 칼럼 | ERP 구축 실패의 원흉은 벤더가 아니다
Source: News

Category: NewsJune 9, 2026
Tags: art

Post navigation

PreviousPrevious post:9일간 46만 번 AI 호출…AI 사용량 집착이 낳는 역효과NextNext post:AI 시대의 CISO, 반드시 답해야 할 15가지 어려운 질문

Related posts

6 new rules of IT leadership — and what they replace
July 6, 2026
Playing to win at the AI casino
July 6, 2026
AI doesn’t eliminate inefficiency. It amplifies it
July 6, 2026
시스코, 사내 AI 비서로 ‘섀도 AI’ 차단…직원당 주 5~6시간 업무 절감
July 6, 2026
벤더 종속 vs 빠른 구축…MS·AWS FDE 도입 전 따져볼 것들
July 6, 2026
채용·출장비 줄인 SAP, AI 투자 재원 확보 나서
July 6, 2026
Recent Posts
  • 6 new rules of IT leadership — and what they replace
  • Playing to win at the AI casino
  • AI doesn’t eliminate inefficiency. It amplifies it
  • 시스코, 사내 AI 비서로 ‘섀도 AI’ 차단…직원당 주 5~6시간 업무 절감
  • 벤더 종속 vs 빠른 구축…MS·AWS FDE 도입 전 따져볼 것들
Recent Comments
    Archives
    • July 2026
    • June 2026
    • May 2026
    • April 2026
    • March 2026
    • February 2026
    • January 2026
    • December 2025
    • November 2025
    • October 2025
    • September 2025
    • August 2025
    • July 2025
    • June 2025
    • May 2025
    • April 2025
    • March 2025
    • February 2025
    • January 2025
    • December 2024
    • November 2024
    • October 2024
    • September 2024
    • August 2024
    • July 2024
    • June 2024
    • May 2024
    • April 2024
    • March 2024
    • February 2024
    • January 2024
    • December 2023
    • November 2023
    • October 2023
    • September 2023
    • August 2023
    • July 2023
    • June 2023
    • May 2023
    • April 2023
    • March 2023
    • February 2023
    • January 2023
    • December 2022
    • November 2022
    • October 2022
    • September 2022
    • August 2022
    • July 2022
    • June 2022
    • May 2022
    • April 2022
    • March 2022
    • February 2022
    • January 2022
    • December 2021
    • November 2021
    • October 2021
    • September 2021
    • August 2021
    • July 2021
    • June 2021
    • May 2021
    • April 2021
    • March 2021
    • February 2021
    • January 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020
    • August 2020
    • July 2020
    • June 2020
    • May 2020
    • April 2020
    • January 2020
    • December 2019
    • November 2019
    • October 2019
    • September 2019
    • August 2019
    • July 2019
    • June 2019
    • May 2019
    • April 2019
    • March 2019
    • February 2019
    • January 2019
    • December 2018
    • November 2018
    • October 2018
    • September 2018
    • August 2018
    • July 2018
    • June 2018
    • May 2018
    • April 2018
    • March 2018
    • February 2018
    • January 2018
    • December 2017
    • November 2017
    • October 2017
    • September 2017
    • August 2017
    • July 2017
    • June 2017
    • May 2017
    • April 2017
    • March 2017
    • February 2017
    • January 2017
    Categories
    • News
    Meta
    • Log in
    • Entries feed
    • Comments feed
    • WordPress.org
    Tiatra LLC.

    Tiatra, LLC, based in the Washington, DC metropolitan area, proudly serves federal government agencies, organizations that work with the government and other commercial businesses and organizations. Tiatra specializes in a broad range of information technology (IT) development and management services incorporating solid engineering, attention to client needs, and meeting or exceeding any security parameters required. Our small yet innovative company is structured with a full complement of the necessary technical experts, working with hands-on management, to provide a high level of service and competitive pricing for your systems and engineering requirements.

    Find us on:

    FacebookTwitterLinkedin

    Submitclear

    Tiatra, LLC
    Copyright 2016. All rights reserved.