산업 현장 운영에서 ERP 도입이 실패하는 이유

Gartner는 2027년까지 최근 도입된 ERP 이니셔티브의 70% 이상이 원래의 비즈니스 목표를 완전히 달성하지 못할 것으로 전망합니다. Panorama Consulting의 2026년 ERP 리포트는 25% 이상의 조직이 예산을 초과했다고 밝혔습니다. Godlan의 2026년 분석(Infor 파트너사이므로 방향성 참고 자료로 취급)에 따르면 제조업 ERP 실패율은 73%, 평균 초과 비용은 215%에 달합니다.

항만, 야드, 광산, 또는 현장 중심의 운영을 담당하고 있다면 이 수치들도 낮게 느껴질 것입니다. 실패율은 프로젝트 관리의 문제가 아닙니다. 구조적인 문제입니다. 사후에 들여다본 모든 프로젝트에서 동일한 다섯 가지 문제가 동일한 순서로 발생합니다.

요약

• Gartner: 2027년까지 최근 ERP 프로젝트의 70% 이상이 원래의 비즈니스 목표를 놓칠 것.
• Panorama: ERP 도입의 25% 이상이 추가 기술 요구사항으로 예산을 초과.
• Godlan: 개별 제조업 ERP 프로젝트의 73%가 목표 달성에 실패, 비용 초과율 215%.
• 산업 현장 프로젝트에서 다섯 가지 실패 패턴이 반복: 템플릿 불일치, OT 통합 부채, 도입 절벽, 파일럿에서 프로덕션으로의 전환 실패, 매몰 비용에 의한 고착.
• Hershey(미이행 주문 1억 달러), Lidl(5억 유로 손실 처리), Revlon(1분기 6,400만 달러 매출 손실)이 이 패턴을 규모 있게 보여줌.
• 운영 현실의 약 60%는 무전, WhatsApp, 교대 노트 등 ERP가 결코 확인하지 못하는 시스템 밖에 존재.

ERP 도입 실패에 관한 통계 스냅샷

아래 섹션의 모든 수치에는 출처가 있습니다. 이 표는 빠른 참조를 위해 핵심 근거 자료를 한곳에 모은 것입니다.

출처	주요 결과
Gartner	2027년까지 최근 도입된 ERP 이니셔티브의 70% 이상이 원래 비즈니스 목표를 놓침
Panorama Consulting 2026	ERP 프로젝트의 25% 이상이 추가 기술 요구사항으로 예산 초과
Godlan 2026	제조업 ERP 프로젝트의 73%가 목표 달성 실패, 평균 비용 초과율 215%
CIO의 Hershey 관련 기사	서둘러 진행한 SAP 가동 이후 1999년 할로윈 주문의 약 1억 달러가 미이행 처리됨
Handelsblatt의 Lidl 관련 기사	7년에 걸친 SAP 프로젝트가 무산된 후 약 5억 유로가 손실 처리된 것으로 보도됨
Dolfing의 Revlon 관련 기사	SAP 이전 이후 2018년 1분기 주문 6,400만 달러를 이행하지 못함
Revlon 2018년 10-K	연차 보고서에 공시된 2018 회계연도 순손실 2억 9,420만 달러

위에서 참조한 원자료:

ERP 프로젝트가 산업 현장 운영에서 실패하는 다섯 가지 방식

다섯 가지 패턴이 계속 반복됩니다. 운영 현장과 벤더에 따라 서로 다른 조합으로 나타납니다. 제가 검토한 실패한 도입 사례는 예외 없이 이 중 최소 세 가지 패턴에 해당합니다. 아래에서 각 패턴을 하나씩 다룹니다.

1. 범용 템플릿으로 인한 범위 확장

모든 주요 ERP는 프로세스 템플릿을 기반으로 구축됩니다. 구매 주문을 모델링하는 표준 방식이 있고, 표준 작업 지시서가 있습니다. 표준 재고 레코드도 있습니다. 이러한 템플릿은 가능한 한 폭넓은 고객군을 대상으로 설계되었습니다.

그 고객군에 맞는 정도는, 프리 사이즈 의류가 실제 사람의 체형에 맞는 정도와 비슷합니다.

도입 팀은 고객의 프로세스를 템플릿에 매핑합니다. 맞지 않는 부분이 있으면 선택해야 합니다. 시스템을 커스터마이징하거나, 프로세스를 바꾸거나. 커스터마이징은 비용이 많이 들고 영구적인 기술 부채를 만듭니다. 프로세스를 바꾸는 것은 오퍼레이터에게 익숙한 방식과 다르게 일하라고 요구하는 것입니다.

실제로는 둘 다 동시에 일어납니다. 커스터마이징을 감당하기 위해 범위가 확장됩니다. 그럼에도 오퍼레이터는 적응하라는 지시를 받습니다. 가동 전에 구축 비용이 상당히 늘어납니다. 결과물은 깔끔한 템플릿도 아니고, 워크플로우를 충실히 재현한 것도 아닙니다.

맞춤 제작 소프트웨어는 벤더 템플릿이 아니라 당신의 워크플로우에서 출발합니다. 운영이 실제로 돌아가는 방식과 시스템이 기대하는 방식 사이에 번역 계층이 존재하지 않습니다.

2. OT 통합 부채

운영 기술(OT)이란 SCADA, PLC, MES, 텔레매틱스, 센서 네트워크를 의미합니다. 이는 물리적 운영을 구동하지만, ERP의 언어로 말하지 않습니다.

ERP 시스템은 거래, 레코드, 승인 같은 비즈니스 데이터를 위해 만들어졌습니다. OT는 대부분의 ERP 데이터 모델이 처리하도록 설계되지 않은 규모로 실시간 신호를 생성합니다.

일반적인 해법은 커넥터입니다. 미들웨어가 OT 신호를 ERP에 맞는 레코드로 변환하며, 커넥터는 데모에서는 잘 작동합니다. 프로덕션 환경에서는 그 자체가 다년간 이어지는 유지보수 프로젝트가 되어 버립니다.

특정 PLC 펌웨어용으로 만든 커넥터는 해당 PLC가 업데이트되면 깨집니다. 초당 100건의 이벤트에 맞춰 튜닝된 커넥터는 초당 10,000건을 감당하지 못합니다. 6개월짜리 통합 백로그는 2년이 지나도 여전히 미해결 상태입니다. 연결된 시스템이 실제로 연결되어 있는 시간이 약 60%에 불과하기 때문에, 운영팀은 스프레드시트로 병행 프로세스를 돌립니다.

항만과 야드 곳곳의 운영 현장에서 이 패턴을 목격해 왔습니다. 커넥터 자체가 나쁜 소프트웨어는 아닙니다. 문제에 맞지 않는 아키텍처일 뿐입니다.

맞춤 제작 소프트웨어는 나중에 덧붙이는 미들웨어가 아니라, 첫날부터 OT를 1급 요구사항으로 취급합니다. 통합 계층이 SCADA, PLC, 텔레매틱스를 네이티브 데이터 스트림으로 처리하면, 쌓여갈 커넥터 부채 자체가 존재하지 않습니다.

3. 도입 절벽

도입 절벽은 시스템을 매일 사용하는 사람들, 터미널 오퍼레이터, 교대 감독자, 디스패처, 정비 크루가 그것을 배우기보다 무시하는 편이 더 생산적이라고 판단할 때 발생합니다.

이는 비합리적인 행동이 아닙니다. 교대 근무를 한 번도 해본 적 없는 프로젝트 팀이 회의실에서 설계한 시스템에 대한 합리적인 반응입니다.

이 절벽은 가동 후 90일 이내에 나타납니다. 프로젝트 팀은 이미 떠난 상태입니다. 운영팀은 정말 중요한 의사결정에는 WhatsApp, 무전, 스프레드시트로 되돌아갑니다. ERP는 재무팀이 요구하는 보고서를 위해서만 사용됩니다.

시스템 오브 레코드가 컴플라이언스 시스템으로 전락한다.

도입은 교육의 문제가 아니다. 나쁜 워크플로우에 대한 교육을 더 한다고 해서 나쁜 워크플로우가 아니게 되지는 않는다. 도입은 설계의 문제다. 실제로 그 시스템을 사용할 사람들은 워크플로우가 설계될 때 그 자리에 없었다.

맞춤 제작 소프트웨어는 현장을 배우는 것에서 시작한다. 실제로 교대 근무를 운영하는 사람들과 함께 앉아, 실제 예외 상황과 엣지 케이스를 매핑하고, 그들이 이미 할 줄 아는 방식을 중심으로 워크플로우를 구축한다.

그 결과는 업무에 맞는 시스템이 되고, 그래서 오퍼레이터들이 실제로 사용하게 된다. 라이브 오퍼레이션 뷰가 실제 오퍼레이션과 닮아 보이는 이유는 바로 그 오퍼레이션으로부터 만들어졌기 때문이다.

4. 파일럿에서 프로덕션으로 갈 때의 이탈

ERP 파일럿은 성공한다. PoC(개념 증명)는 깨끗하고 정제된 데이터, 그리고 소수의 코칭받은 사용자 그룹으로 진행된다. 구현팀이 다룰 줄 아는 좁은 범위의 프로세스 세트로 진행된다.

임원 스폰서가 데모를 본다. 프로젝트는 승인되고, 전체 배포가 시작된다.

프로덕션은 전혀 다른 존재다. 마이그레이션 전에 한 번도 완전히 정리된 적 없는 지저분한 레거시 데이터가 있다. 파일럿이 건드린 적 없는 엣지 케이스가 있다. 비표준 BOL 포맷을 쓰는 캐리어. 포함되지 않은 시스템에 정비 이력이 남아 있는 장비. 늘 그래왔듯 무전과 WhatsApp으로 진행되는 교대 인수인계도 있다.

깨끗한 파일럿 환경과 실제 라이브 프로덕션 환경은 같은 곳이 아니다.

이탈은 단순히 데이터 문제가 아니다. 단순화된 버전의 현실로 파일럿을 진행한 뒤, 시스템을 조정하지 않은 채 전체 버전의 현실에 배포할 때 발생하는 일이다.

맞춤 제작 소프트웨어는 오프시스템 데이터를 포함해 오퍼레이션이 실제로 어떻게 동작하는지에 맞춰 검증된다. 스테이터스 캡처 레이어는 구조화된 통합을 통해 들어오는 것뿐 아니라 무전, WhatsApp, 이메일로 들어오는 것도 처리한다. 프로덕션 환경이 곧 설계 환경이다.

5. 매몰비용에 의한 록인

산업 조직이 ERP 라이선싱, 컨설팅, 커스터마이징에 200만 달러에서 500만 달러를 이미 지출했다면, 발을 빼는 것은 정치적으로 불가능해진다.

CFO가 그 금액을 승인했다. 이사회가 그 프레젠테이션을 봤다. 초기에 우려를 제기했던 오퍼레이터들은 묵살당했다. 시스템이 제 역할을 하지 못할 것이 분명해질 즈음이면, 조직은 이미 18개월째 진행 중이다.

그 투자를 손실 처리로 규정하는 메모에 서명하고 싶은 사람은 아무도 없다.

그래서 조직은 더 밀어붙인다. 커스터마이징을 더 하고, 컨설팅을 더 하고, 체인지 매니지먼트를 더 한다. 총비용은 늘어나고, 고, 라이브 시점은 밀린다. 결국 출시되는 시스템은 그 누구도 교체할 권한이 없는 타협의 산물이다.

나는 오퍼레이션 팀들이 몇 년씩 병행 시스템을 운영하는 것을 지켜봤다. 컴플라이언스용 ERP, 그리고 정작 중요한 일은 WhatsApp과 스프레드시트로.

맞춤 제작 소프트웨어는 이 리스크 모델을 뒤집는다. 시스템이 작동하는지 알기도 전에 200만 달러를 쓸 필요가 없다. 당신이 직접 선택한 문제에 대해, 당신의 데이터로 실제 작동하는 솔루션을 먼저 확인하고, 그것이 제 값을 한다고 판단할 때만 비용을 지불한다. 첫 번째 리스크는 우리가 진다.

ERP 실패가 대규모로 벌어지는 양상

다음 세 가지 사례는 문서로 기록된 실패이며, 실제 수치다. 실명이 공개된 조직들이다. 각각은 앞서 다룬 패턴 중 하나 이상에 해당한다.

Hershey, 1999년. Hershey는 1999년 여름 SAP, Manugistics, Siebel을 동시에 라이브 전환했다. 할로윈 시즌에 맞추기 위해 일정을 약 6개월 단축했다. 할로윈 주문이 쏟아지는 시점에 시스템이 라이브로 전환됐다. 약 1억 달러 규모의 Kisses와 Jolly Rancher 제품을 제때 납품하지 못했다. Hershey 주가는 하루 만에 약 8% 하락했다. 원인은 1억 달러 규모에서 벌어진 파일럿에서 프로덕션으로의 이탈이었다.

Lidl, 2018년. 약 7년, 추정 5억 유로의 지출 끝에 Lidl은 SAP 구현을 포기했다. Handelsblatt 보도에 따르면 근본 문제는 데이터 모델의 불일치였다. SAP의 표준 리테일 재고 모델은 판매가 기준으로 동작한다. Lidl의 오퍼레이션은 매입가 기준으로 동작한다. Lidl은 자사 프로세스를 바꾸길 거부했고, 대신 SAP를 커스터마이징했다. 그 커스터마이징은 가치를 만들어내지 못한 채 수년간 이어졌다. Lidl과 SAP 어느 쪽도 보도된 수치를 공식적으로 확인해주지 않았다. 5억 유로 규모에서 벌어진, 범용 템플릿에서 비롯된 스코프 크리프다.

Revlon, 2018년. Revlon이 노스캐롤라이나주 옥스퍼드 시설에서 진행한 SAP 마이그레이션은 1분기 출하에 차질을 빚었다. 회사는 1분기에만 약 6,400만 달러 규모의 주문을 이행하지 못했다. 이 수치는 실적 공시 자료를 근거로 한 투자자 집단소송 서류에서 드러났다. Revlon은 연차보고서(10-K)에서 2018년 전체 순손실이 2억 9,420만 달러였다고 밝혔다. 6,400만 달러 수치는 링크드인 등에서 이후 Revlon 파산의 원인이 된 30억 달러 규모의 부채 부담과 종종 혼동된다. 이 둘은 서로 다른 사건이다. 2018년 ERP 실패는 OT 통합과 프로덕션 준비 실패였다.

공통된 맥락은 이렇다. 이 사례들 중 어느 것도 기술 문제가 아니었다. 아키텍처와 검증의 문제였다. 모든 조직이 통제된 환경에서는 작동하지만 실제 오퍼레이션 앞에서는 무너지는 시스템을 배포했다.

세 번째 길

위에 나열한 실패 목록에는 두 가지 뻔한 대응이 있다.

첫 번째는 사내에서 직접 구축하는 것이다. 엔지니어링 팀을 채용하고, 요구사항을 처음부터 명세하고, 오퍼레이션에 정확히 맞는 소프트웨어를 만든다. 가끔은 성공한다. 하지만 다년간의 엔지니어링 투입, 대부분의 오퍼레이터가 갖고 있지 않은 기술 리더십, 그리고 만든 것을 유지보수하기 위한 지속적인 투자가 필요하다.

핵심 업무가 항만, 야드, 광산을 운영하는 것이라면, 소프트웨어를 사내에서 직접 만드는 것은 본업에서 벗어난 일이다.

두 번째는 더 나은 ERP나 좀 더 전문화된 버티컬 SaaS를 사서, 구현 과정을 더 신중하게 관리하는 것이다. 이는 더 나은 프로젝트 거버넌스로 같은 베팅을 다시 거는 것에 불과하다. 프로젝트 매니저가 더 경험이 많다고 해서 구조적인 문제가 사라지지는 않는다.

세 번째 길은 정도의 차이가 아니라 종류가 다르다. 맞춤 제작 소프트웨어, 당신의 구체적인 목표를 위해 만들어지고, 당신의 구체적인 시스템과 데이터에 연결되며, 당신의 오퍼레이션이 실제로 동작하는 방식에 맞춰 검증된다. 그리고 라이프사이클 전반에 걸쳐 계속 운영되고 개선된다.

이는 우리가 이전에 다룬 세 번째 길이다. 실패 패턴을 증상이 아니라 근본 원인에서 다룬다.

Opsima는 산업 운영을 위한 AI 네이티브 소프트웨어 팩토리입니다. 귀사의 운영이 실제로 돌아가는 방식에 맞춰, CMMS, TMS, TOS, EAM, ERP, 설비 모니터링, 문서 처리 소프트웨어를 맞춤 제작합니다.

두 가지 서비스 모드가 있습니다. (1) 기존 스택(SAP, Maximo, MainPac, Navis, Priority, JDE, AS400) 위에서 리플레이스 없이 맞춤 구성하거나, (2) 레거시 시스템이 한계에 다다른 경우 완전 신규 소프트웨어를 처음부터 구축합니다. 몇 주 안에 배포됩니다. 성과가 확인된 후에만 비용을 지불하십시오.

Opsima 모델은 이를 구체적으로 구현한다. 우리는 엣지 케이스를 포함해 오퍼레이션이 실제로 어떻게 돌아가는지를 배운다. 그 워크플로우에 맞춰 설계된 소프트웨어를 만든다. 이미 사용 중인 ERP, EAM, TMS, TOS, WMS를 교체하는 대신 통합한다. 우리는 시스템 오브 레코드에 결코 도달하지 못하는 데이터, 즉 무전 통화, WhatsApp 스레드, 손으로 쓴 교대 노트를 다룬다. 이는 내가 다녀본 대부분의 현장에서 오퍼레이션 현실의 약 60%에 해당한다.

그런 다음 라이브로 전환하고, 실제 프로덕션 동작에 맞춰 검증하며, 오퍼레이션이 변화함에 따라 시스템을 계속 운영하고 개선한다.

상업적 모델은 이 리스크 역전을 그대로 반영한다. 시스템이 작동하는 것을 보기도 전에 수백만 달러 규모의 라이선싱 계약에 커밋할 필요가 없다. 우리는 당신이 선택한 문제에 대해, 당신의 데이터로, 당신의 인프라 위에서 실제 작동하는 솔루션을 만든다. 당신은 그것이 돌아가는 것을 본다. 당신의 오퍼레이션에 대비해 평가한 뒤, 그때 결정한다.

자세한 내용은 프라이싱 페이지에 있다. 요약하면, 첫 번째 리스크는 우리가 진다는 것이다.

케이스 스터디는 이것이 실제로 어떤 모습인지 보여준다. 그중 하나가 PNCT다.

제대로 작동할 때의 모습

Port Newark Container Terminal은 100대가 넘는 스트래들 캐리어 플릿으로 연간 약 165만 TEU를 처리한다. 이 플릿은 하루 24시간, 주 7일 가동된다. 스트래들 캐리어 가용성이 제약 요인이다. 캐리어 한 대가 멈추면 처리량이 떨어진다. 계획되지 않은 다운타임 한 시간 한 시간이 실제 비용이다.

PNCT가 Opsima에 가져온 문제는 특이한 것이 아니었다. 장비 데이터, 정비 이력, 오퍼레이션 로그가 서로 소통하지 않는 시스템들에 나뉘어 있었다. 기술자들은 불완전한 정보로 정비 판단을 내렸다. 고장은 예측된 것이 아니라 반응적으로 대응하는 것이었다.

Opsima는 PNCT가 이미 운영 중인 시스템에 연결된 솔루션을 구축했다. 텔레메트리, 정비 기록, 오퍼레이션 데이터를 정비팀이 실제로 사용할 수 있는 라이브 오퍼레이션 레이어로 끌어왔다.

결과는 스트래들 캐리어 플릿 가용성 +5%, 계획되지 않은 고장 약 15% 감소였다.

100대 규모의 플릿에서 가용성 5%는 매 교대마다 약 5대의 추가 유닛이 가동된다는 뜻이다. 그 5대는 신규 장비 구매를 필요로 하지 않는다. 신규 자본 지출도 필요 없다. 신규 인력도 필요 없다. 더 나은 정보를 통해 기존 플릿에서 회수한 처리 용량이다.

PNCT 팀은 이렇게 명확히 말했다. “당신들은 그저 또 하나의 대형 소프트웨어 벤더가 아니었다. 이미 콘셉트를 가지고 왔고, 할 수 있다는 태도로 임했다.”

그것이 바로 천 개의 고객을 위해 만들어진 시스템과 당신을 위해 만들어진 시스템의 차이다.

범위가 정해진 문제 하나, 그리고 출시된 시스템 하나. 몇 년이 아니라 몇 주다.

ERP 적합성 진단 10문항

ERP 구현을 결정하기 전에, 또는 현재 사용 중인 시스템이 최선의 선택이라고 받아들이기 전에, 다음 10가지 질문에 솔직하게 답해보라. 각 질문은 위에서 다룬 5가지 실패 패턴 중 하나에 대응한다.

템플릿 적합성에 대해:

1. 귀사의 운영팀은 ERP가 커스터마이징이나 우회 없이 설계된 그대로 처리하는 워크플로우를 하나라도 설명할 수 있는가?
2. 현장에서 프로세스가 바뀌었을 때, 그 변경사항이 시스템에 반영되기까지 얼마나 걸리는가? 몇 시간인가, 몇 주인가, 몇 달인가?

OT 통합 관련:

1. 귀사의 SCADA 및 PLC 피드는 1급 데이터로 취급되는가, 아니면 핵심 아키텍처 밖에서 커넥터를 통해 수집되는가?
2. 귀사의 통합 프로젝트가 6개월 넘게 “거의 완료” 상태에 머물러 있지는 않은가?

도입 관련:

1. 귀사의 교대 근무를 운영하는 인력이 워크플로우 설계에 실질적인 의견을 제시했는가? 아니면 설계가 확정된 후 UAT 단계에서야 참여했는가?
2. 실제 운영 의사결정 중 시스템 안에서 이루어지는 비율은 얼마이고, 무전, WhatsApp, 스프레드시트 등 시스템 밖에서 이루어지는 비율은 얼마인가?

파일럿에서 프로덕션으로의 전환 관련:

1. 귀사의 파일럿은 정제되고 선별된 데이터셋으로 실행되었는가, 아니면 실제 운영 데이터의 실시간, 지저분한 스냅샷으로 실행되었는가?
2. 해당 시스템은 표준 케이스뿐 아니라 예외 케이스도 잘 처리하는가? 비표준 운송업체, 불완전한 정비 이력, 무전 인수인계 같은 경우 말이다.

상업적 리스크 관련:

1. 지출을 확정하기 전에 귀사의 데이터로 작동하는 솔루션을 실제로 확인했는가? 아니면 벤더 데이터로 돌아가는 벤더 데모만 보고 결정했는가?
2. 가격 책정은 해당 시스템이 귀사의 운영에서 실제로 작동하는지 여부에 따라 달라지는가, 아니면 벤더는 결과와 무관하게 대가를 받는가?

세 개 이상의 질문에 “아니오”라고 답했다면, 이는 ERP 적합성의 문제가 아니다. 맞춤 제작 소프트웨어가 필요한 문제다.

결론

산업 현장의 운영에서 ERP 구축이 실패하는 데는 구조적인 이유가 있으며, 그 이유는 반복적으로 나타난다.

범용 템플릿은 운영을 억지로 맞추게 만들고, OT 통합 부채는 계속 쌓인다. 운영을 실제로 담당하는 사람들이 워크플로우 설계 과정에 없었다면 도입은 무너진다. 파일럿은 정제된 데이터에서는 성공하지만 실제 운영 환경에서는 실패한다. 매몰비용 때문에 방향을 바꾸는 것이 정치적으로 불가능해진다.

대안은 귀사의 운영을 중심으로 만들어진 소프트웨어다. 귀사의 워크플로우, 귀사의 시스템, 귀사의 데이터에 맞춘 소프트웨어. 한번 넘겨주고 끝나는 것이 아니라, 수명주기 내내 계속 운영되고 개선된다.

귀사의 워크플로우를 위해 만들어지고, 가치를 확인한 후에야 비용을 지불하는 맞춤 제작 소프트웨어. 그것이 바로 ERP가 원래 약속했던 모습이다.

더 이상 손대기를 포기한 프로세스를 알려달라. 저희는 귀사가 선택한 문제를 대상으로, 귀사의 데이터를 기반으로 실제 작동하는 솔루션을 만들어드린다. 제 역할을 해낼 때만 비용을 지불하면 된다. 귀사의 운영을 중심으로 만들어진 맞춤 제작 소프트웨어로 다음 구축의 리스크를 낮추려면, Opsima와 워킹 세션을 예약하라.