안돈 대응 순환: 이상 호출부터 복기 개선까지

안돈은 등이 아니라 이벤트 상태 사슬입니다

전통적인 표시등은 이상을 신속하게 알리는 데 적합하지만, 이후의 접수와 처리, 종결 기록이 없다면 '누군가 보았을 수 있다'는 것만 증명합니다. 순환형 안돈은 매 호출을 고유한 이벤트로 생성하고, 발생 위치와 설비, 작업 지시 또는 제품 맥락, 호출 유형, 현재 책임자를 함께 연결합니다.

상태 설계는 실제 현장을 반영해야지 상태 수를 늘리는 것이 목적이 되어서는 안 됩니다. 미접수, 접수됨, 처리 중, 협업 대기, 복구됨, 종결됨 같은 상태는 명확한 진입 조건이 있어야 하며, 임시 복구와 근본 원인 종결은 반드시 구분해야 합니다. 그렇지 않으면 이벤트 종결이 단지 타이머 정지에 불과할 수 있습니다.

이상 분류는 책임에 대응해야지 코드를 쌓는 것이 아닙니다

이상 분류는 현장에서 실제로 자주 일어나는 시나리오를 우선적으로 다뤄야 합니다. 예를 들어 설비, 품질, 자재, 공정, 인원, 안전 관련 호출입니다. 각 유형에는 기본 책임 그룹과 선택적 협업 그룹, 에스컬레이션 조건이 있어야 하며, 색상 구분만으로는 부족합니다.

자동 설비 알람과 수동 안돈 호출도 구분해야 합니다. PLC 고장 코드는 이벤트를 트리거할 수 있지만 업무상 원인은 여전히 현장 확인이 필요합니다. 하나의 근본 원인이 여러 설비 신호를 만들 수 있는데, 이는 분석 단계에서 연동·통합해야지 여러 알림이 서로 다른 사람을 중복 출동시키게 놓아두어서는 안 됩니다.

대응 시간은 의미를 먼저 정의하고 속도를 논하기

흔한 시간 측정으로는 호출부터 접수, 호출부터 도착, 도착부터 복구, 호출부터 종결이 있으며, 각각 인수, 대응, 처리, 근본 원인 관리를 반영합니다. 총 소요 시간 하나만 남기면 병목이 인력 배치인지, 부품 대기인지, 기술 처리인지, 승인인지 판단할 수 없습니다.

타이머 정지에는 엄격한 규칙이 있어야 합니다. 부품 대기나 품질 판정 대기는 독립 상태가 될 수 있지만, 대응 지표를 미화하려고 마음대로 써서는 안 됩니다. 교대 간, 야간, 무인 운영 시간대에도 책임 이전 여부를 명확히 해야 하며, 원본 타임스탬프는 상태 수정으로 덮어쓸 수 없습니다.

• 발생 시간: 설비 또는 시스템 이벤트 시간을 우선 사용하고, 수동 호출은 입력 시간을 보존합니다.
• 접수 시간: 메시지가 일괄 발송된 시점이 아니라 구체적인 책임 역할이 인수를 확인한 시점입니다.
• 도착 시간: 현장 작업 또는 승인된 원격 대응이 실제로 시작된 시점이며, 기준은 일관되어야 합니다.
• 복구 시간: 라인 또는 설비가 규정 기능을 회복했음을 확인한 시점으로, 영구 수리를 의미하지 않습니다.
• 종결 시간: 처리 기록과 필요한 원인 확인이 완료된 시점이며, 후속 개선은 별도 과제로 만들 수 있습니다.

에스컬레이션이 다루는 것은 리스크와 자원이지 재촉이 아닙니다

에스컬레이션 조건은 이벤트 등급, 지속 시간, 영향 범위, 반복 발생 여부를 종합할 수 있습니다. 조건에 도달하면 시스템은 이벤트를 기존 처리 맥락과 함께 격상해야 새 책임자가 모든 정보를 다시 묻지 않아도 됩니다. 에스컬레이션은 원 책임자가 즉시 면책되는 것을 의미하지 않습니다.

알림 채널은 공장 네트워크와 단말 조건에 맞아야 하며, 현장 경광등, LED, 웹 화면 또는 승인된 모바일 메시지를 사용할 수 있습니다. 중요한 것은 채널 수가 아니라 전달과 인수, 실패 시 대체 수단이 검증 가능한지이며, 메시지 발송 성공을 사람의 대응과 동일시할 수 없습니다.

SCADA, OEE, 정비 프로세스와의 연결 방식

SCADA는 설비 상태와 원본 알람을 제공하고, 안돈은 이상을 사람의 대응 프로세스로 보내며, OEE는 일관된 정지 이벤트로 효율 손실을 분석하고, 정비 프로세스는 추가 수리나 개선이 필요한 과제를 받습니다. 넷은 이벤트 식별자를 공유할 수 있지만 각각의 주된 책임과 종결 조건은 다릅니다.

인터페이스 설계는 양방향 덮어쓰기를 피해야 합니다. 설비 리셋이 안돈 처리 기록을 자동으로 삭제해서는 안 되고, 안돈 종결도 OEE 원본 상태를 자동으로 고쳐 쓰지 않아야 합니다. 정비 시스템이 이미 있다면 안돈은 규칙에 따라 과제를 생성하거나 연결하면 되지, 별도의 독립 TPM 제품을 기본적으로 새로 구축하는 것이 아닙니다.

• 설비 이벤트는 사실만 서술하고, 업무상 원인은 권한 있는 역할이 보충합니다.
• 안돈과 OEE는 시작·종료·원인 매핑을 공유하되 각자의 분석 기준을 유지합니다.
• 수리가 필요한 이벤트는 설비, 고장 모드, 처리, 부품 등 정보와 연결합니다.
• 반복 이상은 개선 목록으로 들어가고, 대책 검증 후에 표준과 임계값을 갱신합니다.

실제 이상 훈련으로 단계적 출시

구현 시에는 먼저 한 구역과 소수의 빈발 이상을 선택해 호출부터 복구까지의 전 과정을 검증한 뒤, 자동 트리거와 모바일 알림, 분석으로 확장합니다. 출시 전에 정상 작업, 무인 접수, 협업 대기, 교대, 네트워크 단절, 반복 알람 등 시나리오를 각각 연습해야 합니다.

복기 지표는 수량과 대응 사슬, 재발, 개선 실행을 함께 다뤄야지 평균 소요 시간만으로 평가하지 않아야 합니다. 평균값은 극단 이벤트를 가리고 조기 종결을 유도할 수 있습니다. 실제 이벤트 분포와 주요 손실 원인으로 돌아가야 효과적인 개선이 만들어집니다.

• 이상 목록화: 동일 의미 유형을 통합하고 각 유형의 책임과 기본 처리 입구를 명확히 합니다.
• 상태 정의: 접수, 도착, 복구, 종결에 관찰 가능한 판단 기준을 작성합니다.
• 시나리오 통합 테스트: 설비, 사람, 네트워크, 기존 시스템이 비정상일 때의 동작을 검증합니다.
• 조 시운전: 호출이 쉬운지, 알림이 정확한지, 기록이 불필요한 부담을 만들지 않는지 점검합니다.
• 정기 복기: 순위만 통보하는 것이 아니라 반복 문제를 닫고 라우팅과 표준을 조정합니다.