컨베이어 OEE: WCS 데이터에서 진짜 다운타임 원인을 찾기

결론부터. 컨베이어 OEE는 세 숫자를 곱한 것—가동률 × 성능효율 × 품질률. 공식은 자명하지만, 어려운 건 각 숫자에 WCS의 어떤 필드를 넣을지, 시간 창을 어떻게 자를지, 그리고 다운타임의 매 1분을 누구 책임으로 잡을지다. 똑같은 실패를 세 번 봤다. 세 창고, 같은 컨베이어 구성, 같은 달—OEE는 91%, 74%, 63%로 나왔다. 설비가 달랐던 게 아니다. 정의가 달랐다.

태그 하나 뽑기 전에 정의를 완전히 고정해라.

가동률 = 실제 가동 시간 / 계획 생산 시간. 계획 생산 시간 = 시프트 길이 − 계획 정지. 컨베이어에는 금형 교체가 없지만, 웨이브 전환 시 라인 클리어, 정기 점검, 식사 휴식은 있다—이건 계획 정지이므로 분모에서 제외, 패널티 없다.

성능효율 = 실제 유닛 수 / (실제 가동 시간 × 이론 택트 능력). 이론 택트는 제조사의 최신 사양에서 가져온다. 확신이 없으면 연속 7개 시프트 동안 목표를 달성한 실측 피크의 90%를 써서 문서화하고, 전원이 같은 숫자를 쓰게 한다.

품질률 = 초회 통과 유닛 수 / 실제 유닛 수. 컨베이어에서 "불량"이란 엄밀히 세 가지를 말한다. 스캔 실패, 중량 이상, 분류 불량. 이 셋뿐이다. 재시도 후 재스캔에서 통과한 유닛은 초회 통과에 카운트하지 않는다—그건 재작업이다.

왜 WCS가 유일한 진실이어야 하는가. WMS는 웨이브가 몇 건의 주문을 출고했고 제시간에 출고했는지는 안다. 라인이 왜 47분이나 멈춰 있었는지는 모른다. WCS는 모터 기동/정지 이벤트, 포토아이 카운트, 스캔 헤드 판독, 알람 코드를 갖고 있다—다운타임 귀인 분석의 생데이터는 전부 WCS에 있다. WMS의 일은 정의를 정하는 것이다. 시프트를 어떻게 자를지, 웨이브 시작을 언제로 볼지, 어떤 정지를 계획 정지로 할지. 나는 WMS 컨설턴트인데 어느 현장이든 이렇게 말한다. OEE 숫자가 맞지 않을 때 열에 아홉은 정의의 문제이지 설비의 문제가 아니다.

플레이북, 4단계로.

1단계. WCS 데이터 추출 목록. 먼저 이 여섯 데이터 구분을 맞추라. 하나라도 빠지면 그 아래는 전부 추정치다.

1. 설비 상태 이벤트. 모터 기동/정지, 드라이브 알람을 초 단위 타임스탬프로. 서브초는 과잉, 분 단위는 너무 성기다.
2. 포토아이와 카운터 데이터. 핵심 지점에서의 유닛 카운트—최소 인피드, 디스차지, 그리고 모든 다이버트에서. 구간별 카운트가 없으면 어느 구간이 멈췄는지 특정할 수 없다.
3. 스캔 데이터. 바코드 판독 성공/실패 기록과 실패 사유 코드. 이건 품질률의 분자이자 분모다.
4. 알람 코드 맵. WCS 알람 코드 → 평이한 의미 → 귀인 카테고리. 이 표는 자본 자산이다—한 번 만들어 3년 쓰고, 변경은 프로세스로 한다.
5. 시프트 캘린더. 시프트 시작/종료, 계획 정지(식사, 정비, 웨이브 전환 클리어). WMS에서 유지 관리하고, WCS에서는 읽기 전용으로 둔다.
6. 속도와 택트 설정. 현재 라인 속도, 이론 택트. 성능효율의 분모는 여기서 나온다.

2단계. 다운타임 귀인 분류체계. 모든 정지는 먼저 계획-비계획 게이트를 통과한다. 비계획 정지는 여섯 버킷으로 들어간다.

그레이존에는 문서화된 규칙이 필요하다. 내 건 세 가지다. 첫째, 5분 미만이고 알람 코드가 없는 정지는 전부 마이크로 스톱에 넣는다. 독립 카테고리로 추적하고, "설비 고장"으로 억지로 넣지 않는다. 똑같은 실패를 세 번 봤다—마이크로 스톱이 "설비 고장"으로 번져서 정비팀이 한 달을 기계를 고치는데 OEE는 1포인트도 안 움직인다. 둘째, 인피드가 비어 있고 WMS에 웨이브 릴리스가 있으면 공급 부족이다. 인피드가 비어 있는데 웨이브 릴리스가 없으면 WMS 웨이브 계획의 문제—별도로 추적하고 설비 OEE에는 부과하지 않는다. 셋째, 같은 알람 코드가 24시간 안에 3회 이상이면 반복 고장으로 격상해 별도 추적한다.

3단계. WMS와 WCS 정의를 일치시킨다. 네 항목. 이게 끝나기 전엔 OEE를 신뢰할 수 없다.

1. 시간 기준 하나. WCS 이벤트 타임스탬프와 WMS 웨이브 시간을 같은 타임존, 같은 NTP 소스로 맞춘다. 7분 빨라진 WCS를 본 적이 있다—시프트를 가로지르는 정지가 전부 잘못된 시프트로 귀인됐다.
2. 시프트 정의 하나. WMS 시프트 시작/종료 = WCS 계획 생산 창. 자정을 넘기는 야간 시프트에는 엄격한 규칙—시작 시간 기준으로 귀인하고 전원이 지킨다.
3. 계획 정지 목록 하나, 한 곳에서 유지한다. WMS가 소유하고 WCS가 읽는다. 목록이 두 개면 언젠가 엇갈린다. 시간문제다.
4. 초회 통과 정의를 문서화한다. 스캔에 실패하고 재시도에서 통과한 유닛은 WMS에서 예외 처리로 마감하고, WCS의 초회 통과에는 카운트하지 않는다.

4단계. OEE를 계산하고 병목을 찾는다. 산출물 세 가지. OEE 추세 표(시프트 단위), 다운타임 파레토(카테고리 × 분), 마이크로 스톱 목록(5분 미만 전 이벤트). 순서대로 읽는다. 먼저 가동률의 가장 큰 조각을 찾고, 다음에 성능효율을 본다. 경험칙. 컨베이어 OEE가 안 움직일 때 문제의 70%는 가동률에 숨어 있다—그리고 가동률 문제의 70%는 마이크로 스톱과 대기다.

케이스 1. 아무도 못 본 47분. 2024년 11월, 중국 동부의 대형 이커머스 물류센터, 하루 약 80,000건의 주문을 처리했다. 메인 소터의 OEE가 3주 연속 71–73%에 박혀 있었다. 정비팀은 아무것도 고장 나지 않았다고 단언했고 데이터도 동의했다—3분을 넘는 정지가 하나도 없었다. 그래서 WCS 이벤트를 셌다. 하루 120회 이상의 마이크로 스톱, 합계 47분, 전부 "슈트 풀 → 다운스트림 인력이 제시간에 못 치움 → 라인 정지 → 치움 → 재기동". 하나도 고장으로 안 잡혔지만, 매일 거의 1시간의 계획 생산 시간을 잡아먹었다. 대책에 설비비는 제로. 슈트 풀 경고 포토아이 추가와 슈트 청소 전담 작업자 1명 배치뿐이었다. 2주 뒤 OEE는 83%가 됐다.

케이스 2. 한 달간의 정의 싸움. 2025년 3월, 중국 남부의 3PL 창고. WMS는 웨이브 정시 완료율 98%를 보고했고, WCS는 컨베이어 OEE 62%를 보고했다. 두 팀이 한 달을 다퉜다. 근본 원인. WMS 시프트는 8:00–20:00으로 돌았지만, WCS 계획 생산 창은 1시간 점심과 15분 웨이브 전환 클리어 2회를 제외하고 있었다. 게다가 WMS는 웨이브 릴리스 지연을 생산 시간에 포함했다. 정의 일치 후 OEE는 79%로 재계산됐고, 진짜 병목은 11:30과 16:00 웨이브 전환 때의 공급 부족—컨베이어 문제가 아니라 WMS 웨이브 계획의 문제였다.

돈 계산. 시간당 6,000 유닛 능력의 라인에서 풀 로드 분류 비용이 유닛당 약 $0.11(인건비 + 설비 감가상각, 개략)이면.

마이크로 스톱은 건당 가장 무해해 보이고, 합계로는 가장 비싸다. 그래서 2단계에서는 마이크로 스톱을 독립 버킷에 두는 것이다. 목록에 올리지 않으면 평균 속에 영원히 숨어 있다.

직관에 반하는 판단, 세 가지. 첫째, OEE가 85%를 넘어도 자동으로 좋은 소식은 아니다. 컨베이어는 시스템의 한 고리일 뿐이다. 한 라인이 95%라는 건, 상류가 네 숫자를 지키려고 화물을 쌓아두고 있다는 뜻일 수 있다—배치가 다 차야 유닛을 풀어주고, 라인은 멋져 보이고, 주문 리드타임이 희생된다. OEE는 반드시 웨이브 정시 완료율과 함께 읽어라. 단독이면 자기기만이다. 둘째, 성능효율이 몇 주째 100%에 박혀 있는 건 라인이 좋은 게 아니라 이론 택트가 너무 낮다는 뜻이다. 건강한 성능효율은 90%에서 95% 사이에서 흔들린다. 영구 만점은 목표가 없다는 뜻이다. 셋째, 컨베이어에서 최적화 가치가 가장 낮은 비율은 품질률이다. 스캔 실패를 2%에서 1%로 낮추는 것보다 마이크로 스톱을 10분 줄이는 게 효과가 크다. 병목을 돌아라, 예쁜 숫자를 쫓지 마라.

마무리 전에 흔한 실패 지점. 첫째, 수기로 적은 정지 사유가 WCS 이벤트와 모순된다. 시프트 리더는 "설비 고장"이라고 쓰고, WCS는 슈트 풀을 보여준다. 대책. 1차 원인은 WCS 이벤트가 정한다. 수기 메모는 보조일 뿐이다. 둘째, 메인 라인만 재고 시스템은 안 잰다. 소터 OEE는 88%인데 인피드 라인은 매일 공급 부족이다. OEE는 시스템 레벨에서 계산하라—메인 라인 + 인피드 + 포장을 함께다. 셋째, 알람 코드 맵이 낡는다. 새 스캔 헤드가 가동되고 그 코드가 맵에 안 들어가고, 3개월 뒤 귀인 표가 "알 수 없음"으로 채워지고 OEE 추세가 깨진다. 맵 변경은 변경 프로세스로 한다. 넷째, 월평균 OEE로 작업팀을 평가한다. 평균은 마이크로 스톱을 삼킨다. 마이크로 스톱 건수 + 귀인 마감률로 평가하고, OEE는 추세 참조용으로만 써라.

OEE는 벽에 붙이는 숫자가 아니다—다음 절감을 어디에 넣을지 정하는 것이다. WCS가 생데이터를 주고, WMS가 정의를 주고, 둘이 합쳐지면 다운타임은 숨을 곳이 없어진다.

Lin Xiao, WMS 구현 컨설턴트 지음

영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.