패션 브랜드 창고 입고 검수 기준을 시스템에 반영하기 전에 정할 것

패션 브랜드 창고 운영에서 입고 검수 기준을 시스템에 반영하려 할 때 가장 먼저 부딪히는 문제는 기준 자체가 문서화되어 있지 않다는 점이다. 담당자마다 판단이 다르고, 오랫동안 구두로 전달되어 온 규칙이 시스템 설정 단계에서 처음으로 명문화를 요구받는다. 이 시점에 기준을 충분히 정리하지 않으면 시스템은 만들어지지만 실제 검수 업무는 여전히 사람의 기억에 의존하게 된다.

시스템 반영 전에 정해야 할 항목

검수 대상 범위

전수 검수와 샘플 검수 중 어느 쪽을 기본으로 할지, 품목이나 거래처에 따라 방식을 달리할지 먼저 정한다. 샘플 검수를 선택한다면 샘플 비율과 추출 방식도 규칙으로 남겨야 한다. 시스템은 이 선택을 입고 유형별로 구분해 저장하므로, 기준이 없으면 모든 입고를 같은 방식으로 처리하거나 담당자가 매번 수동으로 선택해야 한다.

불량 판정 기준과 등급 구분

어떤 상태를 불량으로 볼 것인지, 불량 중에서도 반품 처리할 것과 할인 입고할 것을 어떻게 나눌 것인지 정한다. 패션 상품은 오염, 봉제 불량, 치수 오차, 택 누락, 포장 불량 등 불량 유형이 다양하다. 유형별로 처리 방식이 다르다면 시스템에 불량 코드와 처리 경로를 각각 설정해야 한다. 이 구분이 없으면 불량 입고 데이터가 쌓여도 원인 분석이 어렵다.

수량 차이 허용 범위

발주 수량과 입고 수량이 다를 때 어느 범위까지 자동 승인하고 어느 시점부터 담당자 확인을 요청할지 정한다. 예를 들어 발주 대비 ±3% 이내는 자동 입고 처리하고 초과분은 보류 상태로 두는 식이다. 이 규칙이 없으면 시스템은 수량 불일치를 오류로 처리하거나 그냥 통과시키는 두 가지 중 하나만 선택하게 된다.

색상, 사이즈 단위 검수 여부

박스 단위로 수량만 확인할지, 색상과 사이즈별로 낱개 수량을 모두 확인할지 정한다. 후자를 선택하면 바코드 스캔 또는 RFID 기반 검수 프로세스가 필요하고, 시스템에 SKU 단위 입고 처리 기능이 있어야 한다. 브랜드에 따라 시즌 초반에는 SKU별 검수를 하고 보충 입고에서는 박스 단위로만 확인하는 경우도 있다. 이런 예외 규칙도 사전에 정리해야 시스템 설정에 반영할 수 있다.

검수 완료 기준과 입고 확정 권한

누가 검수를 완료 처리할 수 있는지, 불량이 발견되었을 때 입고를 보류하거나 부분 입고를 확정할 권한이 누구에게 있는지 정한다. 시스템에서 입고 확정은 재고 수량에 직접 반영되므로, 권한 없이 확정이 가능하면 재고 오류가 발생한다. 반대로 권한이 지나치게 집중되면 검수 완료 처리가 지연되어 후속 출고 업무에 영향을 준다.

기준이 불명확할 때 생기는 시스템 문제

검수 기준이 정리되지 않은 상태에서 시스템을 구축하면 몇 가지 패턴의 문제가 반복된다.

첫째, 불량 입고 데이터가 단일 코드로 몰린다. 불량 유형을 구분하지 않으면 담당자들이 가장 쉬운 코드 하나에 모든 불량을 기록한다. 나중에 거래처별 불량률을 분석하거나 반품 정산 근거를 찾으려 해도 데이터가 의미 없는 상태가 된다.

둘째, 수량 차이 처리가 담당자마다 달라진다. 허용 범위 규칙이 없으면 어떤 담당자는 1개 차이도 보류 처리하고, 다른 담당자는 10개 차이도 그냥 입고 확정한다. 재고 정확도가 낮아지고 나중에 실사를 해도 원인을 추적하기 어렵다.

셋째, 검수 완료 처리 시점이 불일치한다. 물리적 검수가 끝났지만 시스템 입력이 다음 날 이루어지거나, 반대로 물건이 도착하기 전에 입고 확정이 먼저 처리되는 경우가 생긴다. 재고 수량과 실물 위치가 맞지 않으면 피킹 오류로 이어진다.

기존 시스템 활용과 신규 구축 판단 기준

검수 기준을 정리한 뒤에는 현재 사용 중인 시스템으로 반영이 가능한지 먼저 확인한다. 많은 경우 기존 WMS나 ERP에 검수 설정 항목이 있지만 초기 도입 시 기본값으로만 설정해 두고 실제 업무 규칙을 반영하지 않은 상태로 운영 중이다. 이때는 시스템 교체보다 설정 변경과 업무 규칙 문서화가 먼저다.

기존 시스템으로 처리하기 어려운 경우는 주로 두 가지다. 하나는 SKU 단위 바코드 검수가 필요한데 현재 시스템이 박스 단위 입고만 지원하는 경우다. 다른 하나는 불량 유형별 처리 경로가 복잡해서 현재 시스템의 불량 코드 구조로 담기 어려운 경우다. 이 두 상황에서는 연동 개발이나 별도 검수 모듈 도입을 검토할 수 있다.

연동 개발을 선택할 때는 검수 결과 데이터가 재고 시스템에 어떤 형식으로 전달되어야 하는지, 오류 발생 시 재처리 방식은 무엇인지를 사전에 정의해야 한다. 이 정의 없이 개발을 시작하면 인터페이스 명세가 업무 규칙이 아니라 개발자의 판단으로 채워진다.

시스템 반영 전 준비 체크리스트

아래 항목을 문서로 정리한 뒤 시스템 설정이나 개발 요건 정의를 시작하는 것이 좋다.

• 입고 유형별 검수 방식 (전수 / 샘플, 샘플이면 비율과 추출 방식)
• 불량 유형 목록과 유형별 처리 경로 (반품 / 할인 입고 / 폐기)
• 수량 차이 허용 범위와 초과 시 처리 절차
• SKU 단위 검수 여부와 예외 조건
• 검수 완료 처리 권한자와 부분 입고 확정 규칙
• 검수 결과 데이터 보존 기간과 정산 연계 방식

이 목록이 완성되지 않은 상태에서 시스템 설정을 시작하면 설정 도중에 결정을 내려야 하는 상황이 반복된다. 그 결정이 업무 담당자가 아닌 시스템 구축 담당자의 판단으로 채워지면, 나중에 업무 규칙과 시스템 동작이 맞지 않는다는 민원이 생긴다.

검수 기준 정리는 시스템 구축 프로젝트의 선행 과제가 아니라 운영 업무 자체의 과제다. 시스템이 없어도 이 기준은 있어야 하고, 시스템은 그 기준을 구현하는 도구다.