패션 브랜드 ERP, 내부 합의가 먼저다

ERP 프로젝트가 시작된 지 6개월이 지났는데, 아직도 "우리 프로세스가 어떻게 돌아가는지" 회의가 끝나지 않는다면 — 그건 개발사 문제가 아닙니다.

패션 브랜드의 ERP 도입이 예산을 초과하거나 오픈 일정이 밀리는 가장 흔한 이유는 기술적 난이도가 아닙니다. 개발이 시작된 이후에야 내부 의견 충돌이 수면 위로 올라오기 때문입니다. MD는 시즌 기준으로 재고를 보고 싶고, 물류팀은 입출고 단위로 시스템을 쓰고 싶고, 경영진은 매출 대시보드가 먼저라고 합니다. 이 세 가지 요구가 서로 충돌한다는 사실을 아무도 미리 정리하지 않은 채 개발이 시작됩니다.

결과는 예측 가능합니다. 요구사항 변경이 반복되고, 개발 범위가 늘어나고, 비용은 초기 견적의 1.5~2배로 불어납니다. 그리고 가장 뼈아픈 손실은 돈이 아닙니다. 시스템이 오픈되고도 아무도 제대로 쓰지 않는 상황 — 그게 진짜 실패입니다.

ERP 실패의 숨겨진 비용: "다 만들었는데 왜 안 써?"

연매출 80억 원 규모의 패션 브랜드가 ERP를 도입한다고 가정해 봅시다. 개발 비용으로 1억 2천만 원을 투입했습니다. 오픈 후 3개월이 지났는데 MD팀은 여전히 엑셀로 시즌 플랜을 관리하고, 물류팀은 시스템과 현장 장부를 병행하고 있습니다.

이 경우 실질적인 손실을 계산해 보면:

• 개발 비용 낭비: 실제로 활용되지 않는 기능에 투입된 비용 추정 30~40%
• 운영 이중화 비용: 엑셀과 ERP를 동시에 관리하는 인력 시간, 주당 팀 전체 기준 10~15시간
• 의사결정 지연: 재고 현황이 시스템과 실물이 달라 발주 타이밍을 놓치는 케이스, 시즌당 2~3회
• 재개발 비용: 요구사항을 다시 정리하고 기능을 수정하는 데 드는 추가 비용, 초기 개발비의 20~50%

ERP 도입 실패의 비용은 개발비가 아니라 "쓰이지 않는 시스템을 유지하는 비용"에서 발생합니다. 그리고 그 시작점은 거의 항상 같습니다. 내부 합의 없이 개발을 시작했다는 것.

합의가 없으면 요구사항이 흔들린다

누가 "진짜 결정권자"인지 먼저 정하세요

ERP는 회사 전체의 운영 방식을 바꾸는 프로젝트입니다. 그런데 많은 브랜드에서 ERP 도입의 실무 담당자는 IT 담당자 1명이거나, 운영팀 과장급입니다. 이 사람이 MD팀장, 물류팀장, CFO의 요구를 조율하는 구조가 되면 — 실무자는 모든 요구를 다 담으려 하고, 결국 범위는 걷잡을 수 없이 커집니다.

프로젝트 시작 전에 "이 시스템의 최종 우선순위를 결정하는 사람"을 단 한 명 지정해야 합니다. 대표이사가 직접 하거나, 실질적인 권한을 위임받은 COO급이어야 합니다. 이 사람이 없으면 개발사는 모든 요구를 다 받아야 하는 상황에 놓이고, 프로젝트는 표류합니다.

부서별 요구가 충돌하는 지점을 미리 지도로 그리세요

패션 브랜드에서 ERP 요구사항이 가장 많이 충돌하는 지점은 세 곳입니다.

① 재고 단위: MD는 색상·사이즈 단위(SKU)로 재고를 보고 싶어 합니다. 물류팀은 박스·팔레트 단위로 입출고를 처리합니다. 경영진은 스타일 단위로 매출을 봅니다. 이 세 가지 뷰가 하나의 시스템 안에서 어떻게 연결되는지 미리 합의하지 않으면, 개발 중간에 데이터 구조를 뒤엎어야 하는 상황이 생깁니다.

② 시즌 기준: MD 팀은 S/S, F/W 시즌 기준으로 데이터를 정리합니다. 재무팀은 분기와 회계연도 기준입니다. ERP 안에서 두 기준을 어떻게 병행할지 미리 정하지 않으면 리포트 하나를 뽑을 때마다 기준이 달라 혼선이 생깁니다.

③ 발주·생산 프로세스: 직수입 브랜드와 자체 생산 브랜드는 발주 프로세스가 완전히 다릅니다. 두 구조가 혼재하는 브랜드라면 어느 쪽을 기준으로 시스템을 설계할지 먼저 결정해야 합니다.

개발 전에 해야 할 "내부 합의 3단계"

1단계: 현재 프로세스를 있는 그대로 기록하세요

많은 브랜드가 ERP 도입을 "프로세스 개선"의 기회로 삼으려 합니다. 맞습니다. 하지만 순서가 중요합니다. 지금 어떻게 돌아가는지를 먼저 정확히 기록하지 않으면, 무엇을 개선해야 하는지도 알 수 없습니다.

현재 엑셀 파일이 몇 개인지, 누가 어떤 데이터를 어떤 주기로 업데이트하는지, 어디서 병목이 생기는지를 부서별로 인터뷰해서 문서화하세요. 이 작업만 제대로 해도 개발 범위의 30%는 줄어듭니다. "사실 그 기능은 지금도 잘 되고 있었다"는 걸 발견하게 되기 때문입니다.

2단계: "꼭 있어야 하는 것"과 "있으면 좋은 것"을 분리하세요

ERP 요구사항 회의를 하면 항상 위시리스트가 나옵니다. 자동 발주, AI 수요 예측, 실시간 매장 재고 조회, 인플루언서 연동... 이 모든 것이 언젠가는 필요할 수 있습니다. 하지만 1차 오픈 범위에 다 담으려 하면 프로젝트는 반드시 실패합니다.

"이게 없으면 오픈 자체가 불가능한 기능"과 "오픈 후 3개월 안에 추가해도 되는 기능"을 명확히 분리하세요. 이 분리 작업을 결정권자가 직접 승인해야 합니다. 실무자에게 맡기면 모두가 자기 기능을 "필수"라고 주장합니다.

3단계: 개발사에 넘기기 전에 내부 문서를 완성하세요

개발사에 RFP를 보내기 전에 내부적으로 완성해야 할 문서가 있습니다:

• 프로세스 현황 문서: 부서별 현재 운영 방식, 사용 중인 파일/도구 목록
• 우선순위 확정 기능 목록: 결정권자 서명이 들어간 1차 오픈 범위
• 데이터 기준 합의서: 재고 단위, 시즌 기준, 코드 체계 등 핵심 데이터 정의
• 프로젝트 의사결정 구조: 변경 요청이 생겼을 때 누가 승인하는지

이 네 가지가 없는 상태에서 개발을 시작하면, 이 작업들이 개발 중간에 이루어지게 됩니다. 그리고 그 비용은 고스란히 일정 지연과 추가 개발비로 돌아옵니다.

합의에 투자한 시간이 개발 비용을 아낍니다

내부 합의 작업은 보통 2~4주가 걸립니다. 대표나 COO가 직접 참여해야 하고, 부서장들의 시간이 필요합니다. 바쁜 시즌 중에 이 시간을 내기가 쉽지 않다는 걸 압니다.

하지만 이렇게 생각해 보세요. 합의에 쓰는 2주는 개발 중간에 요구사항이 바뀌어 발생하는 2개월의 지연을 막습니다. 그리고 그 2개월의 지연은 단순히 일정 문제가 아닙니다. 시즌 오픈에 맞춰 시스템을 쓰지 못하면, 그 시즌의 재고 운영은 다시 엑셀로 돌아갑니다. 그 비용은 개발비보다 훨씬 큽니다.

패션 브랜드의 ERP는 기술 프로젝트가 아닙니다. 조직의 운영 방식을 바꾸는 프로젝트입니다. 그리고 조직의 변화는 항상 내부 합의에서 시작합니다.

좋은 개발사는 여러분의 내부 합의를 대신해줄 수 없습니다. 하지만 합의가 완성된 상태라면, 훨씬 빠르고 정확하게 시스템을 만들어낼 수 있습니다.

ERP 도입 전 내부 합의 구조가 아직 정리되지 않았다면, 그 단계부터 함께 검토하는 것이 가장 빠른 시작입니다. → 문의하기