구축은 끝났는데 현장은 그대로다

시스템을 새로 들였는데, 팀장은 여전히 엑셀을 열고 있습니다.

오픈 전날 밤까지 데이터를 이관하고, 개발사 담당자와 수십 번 통화했고, 검수도 끝냈습니다. 그런데 막상 오픈 다음 날 사무실을 보면 — 바이어는 자기 엑셀 파일을 업데이트하고 있고, 물류팀은 카카오톡으로 재고를 확인하고 있습니다. 시스템은 켜져 있지만, 아무도 쓰고 있지 않습니다.

이 장면이 낯설지 않다면, 이 글은 당신을 위한 글입니다.

왜 시스템은 켜져 있는데 현장은 그대로일까

많은 브랜드가 ERP나 운영 시스템 도입을 기술 프로젝트로 접근합니다. 요구사항을 정의하고, 개발사를 선정하고, 일정을 맞추고, 검수를 통과하면 프로젝트가 끝났다고 생각합니다. 그런데 현실에서 시스템 도입의 절반은 기술이고, 나머지 절반은 사람과 습관입니다. 후자를 계획에 넣지 않으면, 아무리 잘 만든 시스템도 6개월 후 유령 소프트웨어가 됩니다.

"불편한데 익숙한 것"이 항상 이깁니다

엑셀은 느리고 오류가 많습니다. 하지만 팀원들은 10년 동안 그 파일의 구조를 몸으로 익혔습니다. 어느 셀에 뭘 입력해야 하는지, 어떤 탭에 이번 시즌 발주가 있는지 — 눈 감고도 압니다. 새 시스템은 더 정확하고 빠를 수 있지만, 처음 한 달은 반드시 느립니다. 그 한 달의 마찰을 버티지 못하면 팀은 익숙한 방식으로 돌아갑니다.

이건 의지의 문제가 아닙니다. 인간의 뇌가 작동하는 방식입니다.

도입 예산의 80%가 기술에, 20%가 사람에 쓰입니다

현실적인 숫자를 보겠습니다. 연매출 80억 원 규모의 패션 브랜드가 운영 시스템을 구축하는 데 5,000만 원을 투자했다고 가정합니다. 이 중 개발·서버·라이선스에 약 4,000만 원이 들어갑니다. 교육, 온보딩, 프로세스 재설계에는 많아야 500만 원이 배정됩니다. 나머지 500만 원은 예비비입니다.

그런데 시스템이 현장에 정착하지 못해 6개월 후 다시 이중 관리 체계로 돌아가면, 그 5,000만 원의 실질 ROI는 0에 가깝습니다. 오히려 기존 엑셀 관리 비용에 새 시스템 유지비까지 더해지는 최악의 시나리오가 됩니다. 중견 브랜드에서 이 패턴이 반복되는 이유는 예산 배분 구조 자체에 있습니다.

현장 정착을 막는 세 가지 구체적인 원인

1. 슈퍼유저가 없습니다

시스템을 가장 잘 아는 사람이 개발사 담당자뿐이면, 오픈 이후 현장 질문들은 갈 곳을 잃습니다. "이 화면에서 반품 처리는 어떻게 해요?"라는 질문에 팀장이 대답하지 못하면, 팀원은 다음 날부터 예전 방식으로 처리합니다. 내부에 시스템을 충분히 이해하는 슈퍼유저 1~2명을 지정하고, 이들이 오픈 전 한 달 동안 실제 업무 시나리오를 기준으로 시스템을 직접 테스트해야 합니다. 매뉴얼을 읽는 것과 실제로 써보는 것은 완전히 다릅니다.

2. 교육이 기능 설명으로 끝납니다

"이 버튼을 누르면 발주서가 생성됩니다" — 이건 기능 설명이지 교육이 아닙니다. 현장 팀원에게 필요한 건 자신의 하루 업무 흐름이 시스템 안에서 어떻게 바뀌는지를 직접 경험하는 것입니다. 예를 들어, 매주 월요일 바이어가 하는 재고 현황 확인 → 발주 검토 → 팀장 승인 요청의 루틴이 새 시스템에서는 어떤 화면 순서로 이루어지는지를 실제 데이터로 연습해야 합니다. 기능 중심 교육은 팀원을 혼란스럽게 만들고, 업무 중심 교육은 팀원을 안심시킵니다.

3. 프로세스 재설계 없이 시스템만 바뀝니다

이것이 가장 근본적인 문제입니다. 기존에 엑셀로 하던 방식을 그대로 시스템에 옮기면, 시스템의 장점이 반감됩니다. 예를 들어, 기존에 주 1회 수기로 집계하던 매장별 재고 현황을 새 시스템에서도 주 1회 수동으로 확인하도록 프로세스를 설계하면 — 실시간 재고 가시성이라는 핵심 가치를 전혀 활용하지 못합니다. 시스템 도입 전에 "지금 이 업무를 왜 이렇게 하고 있는가"를 한 번 물어야 합니다. 그 질문 없이 구축된 시스템은 디지털 엑셀에 불과합니다.

정착률을 높이는 실질적인 접근법

오픈 후 30일이 전부입니다

시스템이 현장에 뿌리를 내리느냐, 유령이 되느냐는 대부분 오픈 후 첫 30일에 결정됩니다. 이 기간 동안 팀원들이 시스템 안에서 실제 업무를 완수하는 경험을 쌓으면, 그 이후에는 관성이 작동합니다. 반대로 이 기간에 "일단 엑셀로 처리하고 나중에 시스템에 옮기자"는 패턴이 자리 잡으면, 그 습관은 6개월 후에도 그대로입니다.

이 30일을 설계하는 것이 개발 일정을 맞추는 것만큼 중요합니다. 구체적으로는 다음과 같습니다.

• 주 2회 짧은 체크인: 30분씩, 어떤 기능에서 막혔는지, 어떤 업무를 아직 시스템 밖에서 처리하고 있는지 확인합니다.
• 이중 관리 금지 선언: 같은 데이터를 엑셀과 시스템 두 곳에 동시에 입력하는 것을 명시적으로 금지합니다. 이중 관리를 허용하는 순간, 팀원은 시스템을 부수적인 것으로 인식합니다.
• 작은 성공 경험 설계: 복잡한 기능보다 팀원이 매일 반복하는 업무 하나를 완전히 시스템으로 이전하는 것에 집중합니다. 그 경험이 다음 기능으로의 확장을 자연스럽게 만듭니다.

대표 또는 MD가 먼저 씁니다

조직 문화에서 가장 강력한 신호는 리더의 행동입니다. 대표나 MD가 주간 회의에서 시스템 화면을 직접 열어 데이터를 보여주면, 팀원들에게 "이건 선택이 아니다"라는 메시지가 전달됩니다. 반대로 리더가 여전히 팀원에게 "엑셀로 정리해서 보내줘"라고 하면, 시스템은 그날부터 장식품이 됩니다.

이건 기술의 문제가 아닙니다. 리더십의 문제입니다.

구축 비용보다 정착 비용을 먼저 계획하세요

시스템을 도입하기로 결정했다면, 개발 예산을 확정하기 전에 한 가지 질문을 먼저 해야 합니다. "이 시스템이 실제로 쓰이게 만드는 데 얼마를 쓸 것인가?"

교육, 슈퍼유저 지정, 프로세스 재설계, 오픈 후 30일 집중 지원 — 이 항목들은 개발 계약서에 자동으로 포함되지 않습니다. 별도로 요청하거나, 별도로 예산을 잡아야 합니다. 이 비용을 아끼면, 개발 비용 전체가 낭비될 수 있습니다.

좋은 시스템 파트너는 오픈일을 목표로 삼지 않습니다. 팀이 시스템 없이는 일하기 불편해지는 날을 목표로 삼습니다. 그 차이가 프로젝트의 실질적인 성패를 가릅니다.

시스템이 현장에 뿌리내리지 못하는 가장 흔한 이유는 기능이 부족해서가 아니라, 오픈 후 30일을 아무도 설계하지 않았기 때문입니다. → 문의하기