ERP 실패담을
너무 많이 들었습니다.

[시리즈 리드] 성장하는 회사는 아홉 개의 문 앞에 선다고 우리는 생각합니다. 규모의 문, 신뢰의 문, 진화의 문 – ACRAS가 8년의 현장에서 정리한 ‘성장의 9관문’을 한 편씩 해부합니다. 이번 편은 신뢰의 문 – 여섯 번째 문은 시스템의 문이 아니라 결정의 문입니다. 실패담이 그렇게 많은 이유부터 묻습니다.

우리가 들은 ERP 실패담은 하나도 같지 않았습니다. 오픈을 두 번 미룬 회사, 오픈은 했지만 마감을 다시 옛 방식으로 하는 회사, 파트너를 두 번 바꾼 회사, 핵심 인력이 프로젝트 도중 떠난 회사. 이유를 물으면 답도 다 다릅니다. 톨스토이가 『안나 카레니나』를 여는 문장이 여기에 그대로 맞습니다 – 행복한 가정은 모두 비슷하지만, 불행한 가정은 저마다의 이유로 불행하다. ERP 프로젝트도 그렇습니다. 실패는 저마다의 이유로 실패하고, 성공은 서로 닮았습니다.

이것이 새로 시작하는 회사의 첫 번째 고민이 됩니다. 실패담을 아무리 모아도 우리 상황과 같은 사례는 없고, 그래서 실패담은 회사를 준비시키는 대신 불안하게만 만듭니다. 불안한 회사가 하는 일은 정해져 있습니다. 더 두꺼운 제안요청서를 씁니다. 요구사항 항목이 수백 개로 늘고, 데모를 세 번 보고, 참조 고객을 두 곳 방문합니다. 실패를 피하려는 준비이지만, 실패담은 회사를 신중하게 만드는 것이 아니라 요구사항 목록을 길게 만들 뿐이고, 그 목록이 실패의 첫 장이 됩니다.

그래서 이 글은 실패의 원인을 나열하지 않습니다. 실패의 이유는 회사 수만큼 많지만, 성공한 프로젝트가 서로 닮은 이유는 몇 개 되지 않기 때문입니다.

새로 시작하는 회사가 물어야 할 것은 “무엇이 잘못될 수 있는가”가 아니라 “성공한 회사들은 무엇을 공통으로 갖추고 있었는가”입니다.

『더 골』로 알려진 엘리 골드랫(Eliyahu M. Goldratt)은 2000년, ERP 도입을 소재로 한 소설 『Necessary But Not Sufficient』를 썼습니다. 논지는 제목에 있습니다. 새 기술은 어떤 제약을 없애 주지만, 조직에는 그 제약을 견디기 위해 만들어진 규칙들이 있고, 규칙을 그대로 둔 채 기술만 들이면 기술은 필요조건에 머문다는 것. 그가 던진 질문은 넷입니다 – 이 기술의 힘은 무엇인가, 어떤 제약을 없애는가, 그 제약 때문에 우리가 만든 규칙은 무엇인가, 이제 어떤 규칙으로 바꿔야 하는가.

성공한 프로젝트가 서로 닮은 첫 번째 조건이 여기 있습니다 – 규칙을 바꿨다는 것. 두꺼운 요구사항 목록은 대부분 현재 규칙의 목록입니다. 관리수준이 각기 다른 법인을 통합하기보다는 분리하여 관리한다는 원칙, 월말에 여러 파일을 합쳐 마감하던 절차, 부서마다 다르게 붙이던 코드, 다섯 단계를 거치던 결재 – 그 규칙들은 이전 시스템의 제약을 견디기 위해 만들어졌고, 제약이 사라진 뒤에도 요구사항이라는 이름으로 살아남습니다. 새 시스템을 그 규칙에 맞추는 순간, 회사는 옛 제약을 새 시스템에 이식한 셈이 됩니다. 실패담의 주인공들은 게을렀던 것이 아닙니다. 규칙을 바꾸라는 질문을 계약 전에 받아 본 적이 없었을 뿐입니다.

두 번째 조건은 결정의 재료입니다. ERP 도입의 결정은 대개 세 가지 재료 위에서 내려집니다. 요구사항 목록은 우리 업무가 그렇게 돌아간다는 실무자의 기억이고, 제안서와 데모는 파트너가 보여주기로 고른 화면이며, 참조 고객의 이야기는 그 회사의 사정입니다. 셋 다 사실의 후보이지 사실이 아닙니다. 예전에는 이 후보들을 사실로 바꾸려면 프로젝트 기간 내내 고객과 우리가 온 힘을 쏟아 결과물을 직접 만들어 봐야 했고, 당시에는 그것이 유일한 방법이었습니다. 지금은 다른 길이 있습니다. 표준 시스템이 먼저 있으니, 계약 전에 우리 회사의 데이터로 우리 회사의 거래가 실제로 돌아가는 화면과 그 입력·출력 데이터를 확인하는 것 – 고객이 확인할 수 있는 사실은 이것 하나입니다. 그 화면을 계약 전에 보지 않은 회사는 세 종류의 후보 위에서 몇 년짜리 결정을 내리는 셈이고, 성공한 프로젝트들은 그 화면을 계약 전에 봤다는 점에서 닮아 있습니다.

세 번째 조건은 결정의 주체입니다. 규칙을 바꾸는 일은 실무자의 권한 밖입니다. 마감 절차를 바꾸고, 부서의 코드 체계를 통일하고, 결재 단계를 줄이는 결정은 경영진의 것입니다. 그런데 대부분의 프로젝트에서 이 결정은 실무 TF에 위임되고, TF는 자기 권한 안에서 할 수 있는 유일한 선택을 합니다 – 규칙을 그대로 두고 시스템을 바꾸는 것. 커스터마이징은 개발자의 선택이 아니라, 결정할 사람이 자리에 없을 때 조직이 내리는 기본값입니다.

요구사항 중심의 발주가 늘 틀린 것은 아니었습니다. 검증된 표준이 없던 시절, 시스템을 백지에서 만들어야 했을 때는 우리 업무를 빠짐없이 적는 것이 유일한 방법이었고 옳은 방법이었습니다. 지금은 순서가 뒤집혔습니다. 수천 개 회사의 업무를 거쳐 검증된 표준이 먼저 있고, 우리 회사가 그 뒤에 옵니다. 그런데 발주의 형식은 그대로입니다. 요구사항을 적고, 문서로 검토하고, 서명합니다. 표준이 먼저 있는 시대에 백지 시대의 형식으로 발주하는 것 – 실패담 대부분의 공통점은 이 시차입니다.

그래서 우리의 관점은 이렇습니다. 이 문은 도입을 결정하는 단계에 옵니다 – 사업은 검증됐고, 이제 그 사업을 돌릴 규칙을 다시 쓸 차례인 회사에게. 실패한 프로젝트는 구축 중에 실패한 것이 아니라, 발주 방식, 더 넓게는 DX(Digital Transformation)를 바라보는 인식 안에 실패가 먼저 들어 있었습니다. 규칙을 바꾸는 질문, 또는 그를 위한 고민이 계약 전에 이루어졌는가, DX의 과정에서 내려지는 결정이 확인된 사실 위에서 내려졌는가, 그 결정을 내릴 사람이 정해져 있었는가 – 규칙·사실·주체. 성공이 서로 닮은 이유는 이 셋을 다 갖췄기 때문이고, 실패가 제각각인 이유는 무엇이 빠졌느냐가 다르기 때문입니다.

거꾸로 말하면, 이 셋에 답한 회사는 실패담과 다른 길을 갑니다. 옛 규칙 대신 표준의 규칙을 회사의 새 기준으로 받아들인 회사에서는 커스터마이징이 예외가 되고, 데이터는 규칙의 예외가 아니라 규칙 그 자체로 쌓입니다. 이제 그 범위가 확장되었습니다. AX(AI Transformation)를 준비하는 회사에게는 표준 위에 토대, 그 위에 신뢰 데이터, 그 위에 AI – 이 순서가 필요하고, 이 순서를 지켜 왔는가가 실패담과 성공담을 가르는 기준이기도 합니다.

실패한 프로젝트는 구축 중에 실패한 것이 아니라, 발주 방식 안에 실패가 먼저 들어 있었습니다. 표준은 제약이 아니라, 미래의 선택지를 지키는 설계입니다.

‘표준’이라는 이름이 붙은 결과물도 기준을 세워 들여다보면 표준의 정도가 천차만별이고, 그 정도가 나중의 변경 비용을 정합니다. 나중에 바꾸려면 재구축이 되는 결정들을, 처음에 옳게 잡아야 합니다. 요구사항 목록이 개발 명세로 굳고 그 명세가 코드가 되면, 옛 규칙은 시스템의 일부가 되어 릴리스마다 회사의 발목을 잡습니다. 그 결정을 되돌리는 일은 수정이 아니라 재구축이 됩니다. 그래서 이 문의 시점은 프로젝트 킥오프가 아니라 그보다 앞, 발주 방식을 정하는 자리입니다.

우리 회사의 위치는 세 가지 질문으로 잴 수 있습니다. 우리 요구사항 목록에서 ‘왜 그렇게 하는가’에 답할 수 없는 항목이 몇 개인가. 우리 데이터로 돌아가는 화면을 계약 전에 볼 계획이 있는가. 규칙을 바꾸는 결정을 누가 내리기로 했는가 – 실무 TF인가, 경영진인가.

실패담을 충분히 들으셨다면, 이제 물을 것은 ‘무엇이 잘못될 수 있는가’가 아니라 ‘성공한 회사들은 무엇을 갖추고 시작했는가’입니다. 발주서에 서명하기 전에, 도입 전 진단으로 규칙·사실·주체의 답을 확인해 보세요.

우리 회사의 발주서에는 규칙·사실·주체가 있습니까. → ERP 도입 진단

참고 자료
· Leo Tolstoy, Anna Karenina, 1877 – 제1부 첫 문장.
· Eliyahu M. Goldratt, Eli Schragenheim & Carol A. Ptak, Necessary But Not Sufficient, North River Press, 2000.