지속적 개선에는 더 나은 데이터가 필요한 이유

지속적 개선은 시간이 지남에 따라 학습 효과가 누적되어야 합니다. 그러나 많은 공장에서 개선 작업은 여전히 워크숍, 스프레드시트, 개별 보고서, 그리고 이전 교대조에서 기억나는 내용에 크게 의존합니다. 카이젠 이벤트는 눈에 보이는 진전을 만들어낼 수 있지만, 몇 주 후에는 약간 다른 생산 조건에서 같은 손실이 다시 나타나는 경우가 많습니다. 문제는 항상 개선 아이디어의 품질에 있는 것이 아닙니다. 더 큰 문제는 팀이 대책이 실제로 효과가 있었는지, 어디에서 효과가 있었는지, 그리고 어떤 조건에서 효과가 중단되었는지를 입증하지 못하는 경우가 많다는 것입니다.

카이젠 개선이 사라지는 이유
워크숍은 며칠 동안 집중력을 만들어 냅니다. 팀은 공정을 매핑하고, 낭비를 식별하며, 조치를 배정하고, 도구를 옮기거나, 체크리스트를 변경하거나, 인계 절차를 조정합니다. 그러나 이후 일상적인 생산 압박이 다시 찾아옵니다. 감독자는 또 다른 긴급 주문을 맡고, 보전팀은 또 다른 고장을 처리하며, 계획팀은 작업 순서를 바꾸고, 품질팀은 또 다른 배치를 보류합니다. 개선 조치는 일상적인 운영 리듬의 일부가 되지 못한 채 엑셀 파일이나 프로젝트 트래커 어딘가에 남아 있게 됩니다. 따라서 중요한 질문은 조치가 완료되었는지가 아니라, 실제 생산 조건이 개선되었는지입니다.

PDCA에는 실제 점검 단계가 필요합니다
계획(Plan), 실행(Do), 점검(Check), 조치(Act)는 단순해 보이지만, 많은 조직은 사실상 계획, 실행, 그리고 다음으로 넘어가기(Move On)만 수행합니다. 계획 단계에서는 검증 가능한 문제, 현재 상태, 기대되는 개선, 그리고 대책의 가설을 정의해야 합니다. 실행은 실제 생산 조건에서 대책을 시험하며, 실제로 무슨 일이 일어났는지 이해할 수 있도록 충분한 맥락을 기록하는 것을 의미합니다. 점검은 기대 결과와 실제 생산 증거를 비교하는 것입니다. 조치는 증거가 뒷받침할 때 변경 사항을 표준화하거나, 그렇지 않을 경우 조정, 축소 또는 되돌리는 것을 의미합니다.
• 손실이 실제로 줄었는가?
• 문제가 단순히 다른 곳으로 옮겨 갔는가?
• 변경이 품질을 해치면서 가동률만 개선했는가?
• 다양한 제품, 작업조, 교대조에서 효과가 있었는가?
• 보전, 자재, 일정 계획 또는 다른 공정 변경이 결과에 영향을 주었는가?
단 한 번의 성공적인 생산 실행은 증명이 아닙니다. 지속적 개선은 반복 가능한 개선과 운 좋은 한 교대조를 구별할 수 있을 만큼 충분한 증거가 필요합니다.

현장(Gemba)과 데이터는 서로를 필요로 합니다
데이터가 현장을 대체하지는 않습니다. 작업자, 감독자, 기술자, 계획 담당자, 품질팀은 시스템이 포착하기 어려운 생산 조건을 이해하고 있습니다. 설비 기록에는 10분간의 정지만 나타날 수 있지만, 작업자는 부품의 느낌이 이상했거나, 정상적인 자재 경로가 막혔거나, 이전 교대조가 설비를 비정상적인 상태로 두고 갔기 때문에 정지가 발생했다는 것을 알 수 있습니다. 동시에 관찰만으로는 한 교대조, 한 사건, 또는 문제의 한 가지 버전만 보여줍니다. 연결된 운영 데이터는 관찰된 내용이 주문, 제품, 설비, 교대조, 자재 로트, 그리고 더 긴 기간에 걸쳐 반복되는지 검증할 수 있게 해줍니다.

현장은 팀이 어디를 살펴봐야 하고 어떤 질문이 중요한지 파악하는 데 도움을 줍니다. 운영 데이터는 그 질문을 실제 생산 패턴 전반에 걸쳐 검증하는 데 도움을 줍니다. 이후 표준작업은 학습 내용을 전달하여 다음 교대조가 처음부터 다시 시작하지 않도록 합니다.

개선 질문에서 시작하십시오
제조 분석에서 가장 큰 실수 중 하나는 가용한 데이터에서 출발하는 것입니다. 현대 생산 라인은 PLC, 센서, MES 시스템, ERP, 품질 시스템, 보전 애플리케이션, 스프레드시트에서 방대한 정보를 생성할 수 있습니다. 더 많은 데이터가 자동으로 더 나은 의사결정을 만들어 내지는 않습니다. 유용한 개선 프로세스는 팀이 실제로 답해야 하는 생산 질문에서 시작합니다.

“어떤 데이터가 있는가?”라고 묻는 대신 “우리가 답하고자 하는 생산 질문은 무엇인가?”라고 물으십시오. “段取り 시간이 너무 길다”는 진술은 여전히 지나치게 광범위합니다. 더 나은 질문은 다음과 같을 것입니다: 같은 라인에서 같은 제품군의 段취り 시간이 왜 크게 달라지는가? 이는 중요한 맥락을 즉시 정의하는 데 도움을 줍니다.
• 이전 제품
• 다음 제품
• 생산 오더
• 자원 또는 라인
• 도구 구성
• 자재
• 교대조 또는 작업조
• 段取り 시작
• 재가동 시간
• 첫 합격 제품
• 안정 생산
• 품질 결과
• 설비 알람
목표는 모든 것을 수집하는 것이 아닙니다. 목표는 개선 의사결정을 바꿀 수 있는 최소한의 사실 집합을 수집하는 것입니다.

ERP는 계획을 설명합니다
ERP는 생산을 둘러싼 상업적 및 계획적 맥락을 제공합니다. 계획 수량, 라우팅, 고객 약속, 자재 소요량, 오더 우선순위, 그리고 의도된 생산 순서를 보여줄 수 있습니다. 이 맥락은 생산 조건이 끊임없이 변하기 때문에 중요합니다. 대책이 段取り 시간을 실제로 줄였더라도, 생산 믹스가 바뀌거나 계획 담당자가 더 잦은 제품 전환을 도입했기 때문에 납기 성과는 여전히 악화될 수 있습니다.
따라서 ERP는 무엇이 어떤 순서로, 어떤 수요를 위해, 어떤 라우팅과 자재로 실행될 예정이었는지를 설명하는 데 도움을 줍니다. 그러나 ERP는 주로 의도를 설명합니다. 반드시 현장에서 실제로 무슨 일이 일어났는지를 설명하지는 않습니다.

MES는 실제로 무엇이 실행되었는지 설명합니다
제조실행시스템(MES)은 그 간극의 일부를 메웁니다. MES는 실제 공정 시작 및 종료, 생산 수량, 불량, 보류, 재작업, 자원, 작업자 트랜잭션, 자재 소비, 추적성, 사유 코드 등 오더 뒤에 있는 실행 이력을 제공할 수 있습니다. 이를 통해 개선 팀은 기억이나 일일 평균에 의존하지 않고, 손실을 실제 오더 및 공정과 연결할 수 있습니다.

MES 데이터는 여전히 해석이 필요합니다. 트랜잭션은 늦게 입력될 수 있고, 서로 다른 작업조가 사유 코드를 다르게 사용할 수 있으며, 타임스탬프는 실제 물리적 순간이 아니라 작업자가 무언가를 확인한 시점을 나타낼 수 있습니다. 시스템은 증거를 제공하지만, 그 증거에 의미를 부여하는 것은 프로세스입니다.

설비 및 IoT 데이터는 물리적 공정을 설명합니다
팀이 운영 내부에서 무슨 일이 일어났는지 이해해야 할 때 설비 데이터가 중요해집니다. PLC 및 IoT 신호는 설비 상태, 사이클 타임, 알람, 속도, 온도, 압력, 인터록, 모터 부하, 재가동 거동, 안정 생산까지의 시간을 드러낼 수 있습니다. MES는 특정 시점에 공정이 재가동되었음을 보여줄 수 있지만, 설비 데이터는 안정적인 생산량이 회복되기 전 몇 분 동안 무슨 일이 있었는지를 설명합니다.
• 반복되는 알람
• 재가동 후 속도 저하
• 온도 회복
• 수동 조정
• 인터록
• 불안정한 사이클 타임
생산 맥락 없이 설비 데이터만 있으면 여전히 오해를 불러일으킬 수 있습니다. 알람은 해당 사건을 둘러싼 작업 오더, 제품, 공정, 자원, 도구 상태, 자재, 품질 결과와 연결될 수 있을 때 훨씬 더 유용해집니다.

현장은 의미를 더합니다
작업자, 보전 기술자, 감독자, 품질팀은 자동화된 시스템이 채울 수 없는 공백을 메웁니다. “자재 문제”와 같은 사유 코드는 실제로는 매우 다른 상황을 설명할 수 있습니다. 자재가 늦게 도착했거나, 다르게 작동했거나, 잘못된 라벨이 붙었거나, 손상되었거나, 나중에야 드러나는 하류 문제를 일으켰을 수 있습니다.
구조화된 코드는 사건을 분류하는 데 도움을 줍니다. 인적 맥락은 그것을 설명하는 데 도움을 줍니다. 따라서 데이터 수집은 생산을 방해하지 않고 생산의 현실에 맞게 설계되어야 합니다. 유용한 질문은 작업자가 얼마나 많은 정보를 입력할 수 있느냐가 아니라, 다음 개선 의사결정을 더 낫게 만들 최소한의 인적 입력은 무엇이냐입니다.

공유된 공장 언어가 필요합니다
ERP, MES, 보전 시스템, 히스토리안, 스프레드시트는 모두 같은 생산 사건을 서로 다르게 기술할 수 있습니다. 한 시스템은 자원을 “Line 3”이라고 부르고, 다른 시스템은 “LINE03”을 사용할 수 있으며, 보전팀은 라인 내부의 여러 자산을 별도로 추적할 수 있고, 히스토리안은 여전히 오래된 PLC 태그를 사용할 수도 있습니다.