시뮬레이션 모델 데이터: 출처와 필요한 품질 수준
Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.
By Mirko Peters ·
시뮬레이션 모델의 데이터는 시스템, 측정, 그리고 전문가에게서 나옵니다. 데이터 출처, 흔히 발생하는 품질 격차, 그리고 시뮬레이션 입력 데이터가 어느 정도 정확해야 하는지 살펴봅니다.
Automatically translated with AI from the original post. Read the English original
시뮬레이션 모델 구축에 필요한 데이터는 세 곳에서 나옵니다. 비즈니스 시스템과 현장 시스템, 직접 측정, 그리고 라인을 잘 아는 사람들입니다. 필요한 품질은 일반적인 기준이 아니라 던지는 질문에 따라 달라집니다. 이 가이드는 공장 시뮬레이션에 필요한 데이터를 제공하도록 요청받은 지속적 개선 관리자를 위한 것입니다. 모델에 무엇이 필요한지, 각 항목을 어디에서 얻는지, 무엇이 자주 잘못되는지, 수치를 사용한 실제 예시, 그리고 충분한 품질의 데이터를 얻기 위한 여섯 단계 계획을 다룹니다.
핵심 요약
- 시뮬레이션 모델에는 제품과 라우팅, 공정 시간, 자원, 정지, 주문, 인력 규칙이 필요하며, 각 항목은 시스템, 측정 또는 전문가에게서 얻습니다.
- 데이터는 스톱워치 연구와 관찰 같은 1차 출처와, ERP, MES, CAD 시스템 및 예측 자료 같은 2차 출처에서 나옵니다.
- 흔한 격차에는 ERP의 사전 설정 시간이 실제 시간과 다른 경우, 중복 레코드, 실제 상황을 뒤따르지 못하는 데이터, 그리고 변동 정보의 누락이 있습니다.
- 입력은 질문에 충분한 수준이어야 합니다. 결과를 가장 크게 바꾸는 입력이 무엇인지 확인하고 노력을 그곳에 집중하십시오.
- 평균만이 아니라 분포와 실제 기록을 사용하십시오. 테스트하려는 대기 시간은 변동에서 생기기 때문입니다.
시뮬레이션 모델 구축을 위한 데이터: 모델에 필요한 것
라인의 흐름 모델에는 여섯 종류의 입력이 필요합니다. 이 목록은 일반적인 실무를 우리가 정리한 것이며, 표준이 아닙니다.
- 제품과 라우팅. 어떤 제품이 어떤 스테이션을 어떤 순서로 거치는지.
- 시간. 제품별, 스테이션별 공정 시간과 교체 시간, 그리고 두 시간의 변동.
- 자원. 기계, 공구, 인력과 그 용량 및 가용성, 고장과 계획된 정지를 포함합니다.
- 주문과 수요. 주문 규모, 혼합 비율, 도착 패턴으로, 수주 잔량이나 예측에서 얻습니다.
- 규칙. 교대 모델, 휴식 시간, 순서 및 배치 규칙, 작업자가 스테이션 간에 이동하는 방식.
- 품질. 스크랩 및 재작업 비율과 불량이 발견되는 지점.
모델에 공장의 모든 수치가 필요한 것은 아닙니다. 질문이 좌우하는 수치가 필요하며, 시뮬레이션하고 테스트하려는 대기가 변동에서 생기므로 변동 정보도 반드시 필요합니다. 모델은 데이터가 허용하는 범위 안에서만 예측할 수 있습니다.
시뮬레이션 입력 데이터의 출처: 실무에서의 데이터 수집
Maja Bärring 외 연구진이 2018 Winter Simulation Conference에서 발표한 논문은 Anders Skoogh 외 연구진의 앞선 연구를 따라, 출처를 두 그룹으로 나누어 설명합니다.
- 1차 데이터는 연구를 위해 직접 수집됩니다. 측정, 스톱워치 연구, 라인 관찰이 여기에 해당합니다.
- 2차 데이터는 이미 존재합니다. 여기에는 산업 표준과 도메인 전문가 같은 외부 참고 자료, ERP, MES, PDM, CAD 같은 기업 비즈니스 시스템, 그리고 생산량 예측 같은 프로젝트 관련 데이터가 포함됩니다.
지속적 개선 관리자 입장에서 실제 데이터 수집은 대략 다음과 같습니다. 제조 실행 시스템에는 스테이션별 실제 사이클 타임, 정지 이벤트, 수량이 기록됩니다. ERP에는 오더, 공정 순서(라우팅), 계획 시간이 있습니다. CAD 또는 PDM 시스템에는 제품 구조가 있습니다. 교대 계획은 생산 계획 또는 인사 부서가 관리하는 경우가 많습니다. 전환(changeover) 시간과 작업자가 실제로 일하는 방식은 대개 현장 관찰과 교대 리더에게 직접 물어보는 방법으로만 파악할 수 있습니다.
데이터가 충분하지 않은 이유
Bärring 등은 두 개의 사례 기업을 다루었고 인터뷰 대상은 다섯 명이었습니다. 따라서 이 결과는 참고용이며 일반화할 수 있는 결론은 아닙니다. ERP와 스프레드시트에서 데이터를 수작업으로 수집한 사례에서 많은 공장이 공감할 만한 문제들이 보고되었습니다.
- 실제 시간 대신 ERP의 기본값(사전 설정값)이 사용되어, 어떤 시간을 써야 할지 불분명했습니다.
- 같은 품목이 ERP 시스템과 스프레드시트에 중복 저장되어 있었습니다.
- 레이블이 일관되지 않았고, 부서마다 기준이 달랐습니다.
- 현실은 바뀌었지만 시스템은 그대로였습니다.
저자들은 또한 ERP 시스템이 확률적 값보다 결정적 값을 중시하기 때문에, 시뮬레이션에 필요한 변동성이 자주 빠진다고 지적합니다. 두 번째 사례에서는 자동 데이터 수집을 도입해 저자들이 제시한 여덟 가지 과제 중 다섯 가지를 피할 수 있었습니다. 이 논문은 무엇보다도 데이터의 소유권을 회사 내 부서에 배정할 것을 권장합니다. Skoogh, Perera, Johansson이 Simulation Modelling Practice and Theory에 게재한 설문에서는 시뮬레이션 사용자의 약 80%가 여전히 입력 데이터를 매우 수작업에 의존하는 절차로 준비하는 것으로 나타났습니다.
시뮬레이션에서의 라우팅과 자재명세서(BOM)
문제를 자주 일으키는 마스터 데이터는 두 가지입니다. 라우팅은 제품에 필요한 공정이 무엇인지, 어떤 순서로, 어떤 리소스에서, 어떤 시간으로 진행되는지를 정의합니다. 자재명세서(BOM)는 제품에 어떤 부품이 들어가는지를 정의합니다. 흐름 모델에서는 보통 라우팅이 뼈대가 되며, 부품이 빠질 수 있거나 스테이션이 조립품을 기다리는 경우에는 BOM이 중요해집니다.
ERP의 라우팅은 계획용 값인 경우가 많고, 한 번 설정된 뒤 거의 갱신되지 않습니다. 이것이 Bärring 등이 지적한 문제입니다. 라우팅을 모델에 불러오기 전에, 같은 제품과 스테이션에 대해 라우팅의 시간을 MES의 실제 시간과 비교하십시오. 공정 순서가 여전히 현장과 일치하는지, 그리고 BOM이 실제로 생산하는 변형 제품(variant)을 보여 주는지 확인하십시오. 빈 부분을 합성 데이터(synthetic data)라고도 하는 시뮬레이션 데이터로 채워 놓고 그 사실을 표시하지 않는 일은 피하십시오.
시뮬레이션 데이터 품질은 어느 정도여야 할까요?
답은 "의사결정에 충분한 수준이면 된다"입니다. Averill Law는 시뮬레이션 모델링의 함정에 관한 논문에서 입력 분포의 기록과 검증을 요구하며, 가능하다면 시스템 무작위성의 모든 원천에 대한 데이터를 수집할 것을 권장합니다. 그는 두 가지 오류를 경고합니다. 하나는 무작위 입력을 평균값으로 대체하는 것인데, 그의 예에서는 이 때문에 대기열이 완전히 사라졌습니다. 다른 하나는 습관적으로 정규분포를 선택하는 것인데, 그의 한 예시에서는 이로 인해 출력 오차가 39%에 달했습니다.
데이터 준비에 얼마나 공을 들일지 정하는 실용적인 방법은 입력값을 영향도와 각 매개변수의 불확실성에 따라 순위를 매기는 것입니다. Law는 또한 어떤 요인이 성과 지표에 가장 큰 영향을 미치는지 확인하기 위해 민감도 분석을 권장합니다. 아래의 등급 구분은 표준이 아니라 저희가 계획을 세울 때 쓰는 보조 도구입니다.
- A등급: 측정되었고 검증됨. 결과에 가장 큰 영향을 주는 입력값에 사용합니다. 예를 들어 병목 공정의 사이클 타임과 그 앞 공정의 정지 패턴이 여기에 해당합니다.
- B등급: 시스템에서 가져왔고 샘플로 검증됨. 영향도가 중간인 입력값에 사용합니다.
- C등급: 전문가 판단. 영향도가 작은 입력값에 사용하며, 가정한 내용을 반드시 기록합니다.
마지막으로 검증을 통해 전체 데이터 세트를 점검하십시오. 모델이 실제 라인의 출력을 재현하는지 확인합니다. 재현하지 못한다면 먼저 A등급 입력값부터 살펴보십시오.
예시: 라우팅 시간과 실제 시간 비교
이것은 가정된 수치를 사용한 예시이며, 실측 사례가 아닙니다. 한 라인에서 제품 한 종류를 생산합니다. ERP 라우팅에는 병목 스테이션에서 부품당 42초로 되어 있습니다. MES에서는 4주간 실제 사이클 타임의 중앙값이 47초로 나타납니다.
- 라우팅 시간 기준 시간당 생산량: 3,600 ÷ 42 = 85.7개.
- 실제 시간 기준 시간당 생산량: 3,600 ÷ 47 = 76.6개.
- 라우팅은 생산율을 약 12퍼센트(85.7 ÷ 76.6 ≈ 12%) 과대평가합니다. 8시간 교대 기준으로 보면 약 686개 대 613개 부품이 되어, 73개 차이가 납니다.
라우팅 데이터를 넣어 학습한 모델은 라인이 실제로 도달한 적 없는 예측을 하게 되며, 이 기준으로 측정한 개선 효과는 실제보다 나쁘게 보이게 됩니다.
같은 논리가 정지 시간에도 적용됩니다. MES에 정지 7건이 기록되어 있고, 지속 시간이 각각 2, 3, 3, 4, 5, 6, 40분이라고 가정해 보겠습니다. 합계는 63분이므로 평균은 9분이지만, 중앙값은 4분입니다. 정지 시간을 9분으로 고정한 모델은 버퍼를 비우는 40분짜리 정지를 전혀 보여 주지 못하고, 실제 라인보다 중간 길이 정지를 더 많이 보여 줍니다. 기록된 지속 시간을 그래프로 그리고 산포를 계산한 뒤, 그 값을 직접 사용하거나 이에 맞춘 통계 분포를 사용하십시오. 분포의 모수는 기록 데이터에서 추정하십시오.
데이터를 잘 활용하는 여섯 단계 계획
- 질문을 정리합니다. 질문에 따라 필요한 입력값이 결정됩니다.
- 위의 여섯 개 그룹에 있는 항목을 나열하고, 질문이 가장 크게 의존하는 항목을 표시합니다.
- 각 항목에 대해 출처와 담당자를 지정합니다. 예를 들어 정지는 MES, 주문은 ERP, 품종 전환은 관찰자를 지정할 수 있습니다.
- 출처를 비교합니다. 라우팅 시간을 MES와 대조하고, 시스템 간에 식별자와 단위가 일치하는지 확인합니다.
- 중요한 입력값에 대해서는 A등급 방법으로 차이를 측정하고, 나머지 항목은 가정을 기록합니다.
- 데이터를 검증하고 유지합니다. 모델을 실제 라인과 비교하고, 데이터 세트를 날짜와 함께 저장하며, 이를 업데이트할 담당자를 지정합니다.
흔한 실수
- 검증 없이 ERP 라우팅을 적재하는 것. 계획된 값은 실제 값이 아닙니다.
- 평균값만 사용하는 것. 각 입력값은 단일 숫자가 아니라 산포를 가진 변수입니다. 변동이 대기 시간을 만들어 내는데, 평균은 이 변동을 지워 버립니다.
- 모든 데이터를 수집하는 것. 질문 없이 쏟는 노력은 프로젝트에 주어지지 않은 시간을 낭비하며, 방대한 양은 정작 중요한 것을 가려 버립니다.
- 정의를 혼용하는 것. 정지, 품종 전환, 사이클은 시스템마다 다른 의미를 가질 수 있습니다.
- 담당자가 없는 것. 아무도 관리하지 않는 수치는 다음 변경 시점에 이미 오래된 값이 됩니다.
- 검증을 건너뛰는 것. 실제 라인과 비교하지 않으면 입력값이 충분히 좋은지 알 수 없습니다.
소프트웨어가 도움이 되는 방법
제품, 공정 단계, 자원을 연결하는 지식 그래프는 각 사실을 한 번만 저장하므로 중복되거나 상충하는 데이터를 줄일 수 있습니다. iFAKT의 Polaris Designer는 iFAKT Polaris의 모듈로, 제품, 공정 단계, 자원에 대한 단일 진실 공급원(single source of truth)으로서 제품-공정-자원(PPR) 지식 그래프를 구축합니다. 이것이 실제 시간과의 대조, 담당자 지정, 모델 검증을 대신하지는 않습니다. 어떤 도구를 사용하든 ERP와 MES에서 데이터를 어떻게 가져오는지, 그리고 변경 사항을 어떻게 추적하는지 확인하십시오.
다음 단계
한 라인의 병목 공정(스테이션)을 골라, 지난 4주간 ERP의 라우팅 시간과 MES의 실제 사이클 타임을 비교해 보십시오. 차이가 있다면, 시뮬레이션 모델 구축을 위한 데이터의 첫 번째 격차를 찾은 것이며, 어디서부터 시작해야 할지도 알게 된 것입니다.