수량은 맞는데 출고가 막히는 이유
WMS 화면에는 1,000개가 있는데 막상 출고 지시를 내리면 피킹 리스트가 비어 있거나, 반대로 내보내면 안 되는 재고가 출고되는 일이 생깁니다. 대부분 수량은 정확하지만 상태가 관리되지 않아서 생기는 문제입니다.
예를 들어 총재고 1,000개 중 입고 검사 대기 120개, 고객 클레임으로 보류된 로트 30개, 파손 15개가 섞여 있다면 실제 출고 가능 수량은 835개입니다. 화주나 영업이 1,000개를 보고 주문을 받으면 165개만큼 결품이 생기고, 반대로 상태 구분 없이 할당하면 검사를 통과하지 않은 제품이 고객에게 나갑니다. "보유 재고"와 "출고 가능 재고"는 다른 숫자라는 점을 시스템이 알고 있어야 합니다.
재고 상태 체계 설계
상태 코드 정의 원칙
상태는 5~7개 이내로 유지하는 것이 좋습니다. 상태가 늘어날수록 현장에서 잘못 지정할 가능성이 커지므로, 세부 원인은 상태가 아니라 사유 코드로 분리합니다.
상태와 로케이션, 함께 쓸까 분리할까
불량·반품처럼 물리적으로 옮겨야 하는 재고는 격리 구역 로케이션과 상태를 연동하는 편이 안전합니다. 반면 보류는 랙에 그대로 둔 채 걸리는 경우가 많으므로 로케이션과 독립된 속성으로 관리해야 합니다. "로케이션만 보고 상태를 추정"하는 방식은 재고 이동이 잦은 센터에서 쉽게 무너집니다.
홀드(보류) 운영 규칙
홀드 단위와 해제 권한
홀드는 로트·SKU·로케이션·입고 건 단위로 걸 수 있어야 합니다. 리콜은 로트, 설비 결함 의심은 로케이션, 협력사 품질 문제는 입고 건 단위가 자연스럽습니다. 해제 권한은 거는 사람과 분리하는 것이 원칙입니다. 예를 들어 현장 관리자는 홀드를 걸 수 있지만, 해제는 품질 담당자만 할 수 있도록 설계합니다.
사유와 기한 관리
모든 홀드에는 사유 코드, 등록자, 예상 해제일을 필수로 남깁니다. 기한이 지난 홀드는 단계별로 알림을 보내는 것이 효과적입니다. 예를 들어 7일 경과 시 담당자, 14일 경과 시 팀장, 30일 경과 시 화주에게 알리는 식입니다. 장기 보류 재고는 공간을 차지하면서 재고 회전율 지표까지 왜곡하기 때문입니다.
할당·피킹 로직과의 연결
할당 엔진은 가용 상태만 대상으로 삼아야 합니다. 더 까다로운 경우는 이미 할당된 재고에 홀드가 걸릴 때입니다. 처리 방식은 단계별로 정해 둡니다.
모든 상태 변경은 변경 전·후 상태, 사유, 작업자, 시각을 이력으로 남겨야 합니다. 클레임이나 감사 때 "언제 누가 왜 이 로트를 풀었는가"에 답할 수 있어야 합니다.
ERP·화주 시스템과 재고 상태 동기화
외부에 공개할 수준을 정해야 합니다. 화주에게는 가용·보류·불량 3단계 합계만 보여주고, 세부 사유는 내부 데이터로 두는 방식이 일반적입니다. ERP와는 상태별 수량을 함께 전송해야 영업이 가용 수량 기준으로 주문을 받을 수 있습니다.
정산 분쟁은 주로 WMS에서는 불량인데 ERP에서는 정상 재고로 잡혀 있는 경우에 생깁니다. 상태 변경 이벤트를 즉시 전송하고, 하루 한 번 상태별 수량을 대사하는 이중 구조를 권장합니다.
적용 순서와 POLYGLOTSOFT의 지원
기존 WMS에 상태 체계를 덧붙일 때는 단계적으로 접근하는 것이 안전합니다.
POLYGLOTSOFT는 WMS 재고 상태 체계 설계부터 홀드 관리 화면, 할당 로직 개선, ERP·화주 시스템 인터페이스 구축까지 지원합니다. 현재 운영 중인 시스템을 교체하지 않고 필요한 기능부터 덧붙이는 방식으로 진행할 수 있으니, "재고는 있는데 출고가 안 되는" 문제를 겪고 계시다면 편하게 문의해 주시기 바랍니다.