Dane do modelu symulacyjnego: skąd pochodzą i jaka powinna być ich jakość

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 · 2026-11-11

Dane do modelu symulacyjnego pochodzą z systemów, pomiarów i od ekspertów. Poznaj źródła, typowe luki w jakości i to, jak dobre muszą być dane wejściowe symulacji.

Automatically translated with AI from the original post. Read the English original

Dane do budowy modelu symulacyjnego pochodzą z trzech miejsc: systemów biznesowych i produkcyjnych, bezpośrednich pomiarów oraz osób, które znają linię. To, jak dobre muszą być, zależy od pytania, a nie od ogólnego standardu. Ten przewodnik jest przeznaczony dla kierowników ds. ciągłego doskonalenia, którzy proszeni są o dostarczenie danych do symulacji fabryki. Dowiesz się, czego potrzebuje model, skąd pochodzi każda pozycja, co zwykle idzie nie tak, zobaczysz przykład z liczbami oraz sześciokrokowy plan pozyskania wystarczająco dobrych danych.

Najważniejsze punkty

• Model symulacyjny potrzebuje produktów i marszrut, czasów procesowych, zasobów, postojów, zleceń oraz zasad obsady; każda pozycja pochodzi z systemu, pomiaru lub od eksperta.
• Dane pochodzą ze źródeł pierwotnych, takich jak badania z stoperem i obserwacja, oraz ze źródeł wtórnych, takich jak systemy ERP, MES i CAD oraz prognozy.
• Typowe luki to domyślne czasy z ERP różniące się od rzeczywistych, zduplikowane rekordy, dane opóźnione względem rzeczywistości oraz brak zmienności.
• Dane wejściowe muszą być wystarczająco dobre dla danego pytania: sprawdź, które z nich najbardziej zmieniają wynik, i skup na nich swoje wysiłki.
• Używaj rozkładów i rzeczywistych zapisów, a nie tylko średnich, ponieważ to zmienność generuje czas oczekiwania, który chcesz przetestować.

Dane do budowy modelu symulacyjnego: czego potrzebuje model

Model przepływu linii wymaga sześciu rodzajów danych wejściowych. Ta lista jest naszym własnym podsumowaniem typowych praktyk, a nie normą.

• Produkty i marszruty. Który produkt przechodzi przez które stanowisko i w jakiej kolejności.
• Czasy. Czas procesowy na produkt i stanowisko, czasy przezbrojeń oraz zmienność obu tych wartości.
• Zasoby. Maszyny, narzędzia i ludzie, ich zdolność produkcyjna i dostępność, w tym awarie i planowane postoje.
• Zlecenia i popyt. Wielkości zleceń, miks produktów i wzorzec napływu, z portfela zamówień lub z prognozy.
• Zasady. Model zmianowości, przerwy, reguły kolejności i partiowania oraz sposób przemieszczania się operatorów między stanowiskami.
• Jakość. Wskaźniki braków i poprawek oraz miejsca, w których wykrywane są wady.

Model nie potrzebuje każdej liczby z zakładu. Potrzebuje tych liczb, od których zależy pytanie, oraz zmienności, ponieważ to ona generuje oczekiwanie, które chcesz symulować i testować. Model może przewidywać tylko to, na co pozwalają jego dane.

Skąd pochodzą dane wejściowe do symulacji: zbieranie danych w praktyce

Artykuł Mai Bärring i współpracowników na konferencji Winter Simulation Conference 2018 opisuje źródła w dwóch grupach, za wcześniejszymi pracami Andersa Skooghа i współpracowników.

• Dane pierwotne są gromadzone na potrzeby badania: pomiary, badania z stoperem i obserwacja na linii.
• Dane wtórne już istnieją. Obejmują zewnętrzne źródła referencyjne, takie jak normy branżowe i eksperci dziedzinowi, korporacyjne systemy biznesowe, takie jak ERP, MES, PDM i CAD, oraz dane projektowe, takie jak prognozy wielkości produkcji.

Z perspektywy kierownika ds. ciągłego doskonalenia gromadzenie danych wygląda w praktyce tak. System wykonawczy produkcji (MES) przechowuje rzeczywiste czasy cykli, zdarzenia postojów i ilości według stanowisk. System ERP przechowuje zamówienia, marszruty i czasy planowane. System CAD lub PDM przechowuje strukturę produktu. Plany zmian należą do planowania lub działu kadr. Czasy przezbrojeń i rzeczywisty sposób pracy operatorów często da się poznać tylko przez obserwację i rozmowy z brygadzistami.

Dlaczego dane często nie są wystarczająco dobre

Bärring i współpracownicy przebadali dwie firmy, z pięcioma respondentami, więc wyniki mają charakter orientacyjny, a nie ogólny. W przypadku, gdy dane zbierano ręcznie z ERP i arkuszy kalkulacyjnych, opisali problemy, które wielu zakładom będzie znajomych:

• Zamiast rzeczywistych czasów używano wartości domyślnych z ERP, więc nie było wiadomo, których czasów użyć.
• Ta sama pozycja była zapisana zarówno w systemie ERP, jak i w arkuszach kalkulacyjnych.
• Oznaczenia były niespójne, a działy stosowały różne nazewnictwo.
• Rzeczywistość się zmieniła, a system nie.

Autorzy zwracają też uwagę, że systemy ERP kładą nacisk na wartości deterministyczne zamiast stochastycznych, więc brakuje zmienności, której potrzebuje symulacja. W drugim przypadku automatyczne pozyskiwanie danych pozwoliło uniknąć pięciu z ośmiu wyzwań, które wymieniają. Artykuł zaleca m.in. przypisanie odpowiedzialności za dane poszczególnym funkcjom w firmie. Badanie Skooghа, Pererы i Johanssona opublikowane w Simulation Modelling Practice and Theory wykazało, że około 80 procent użytkowników symulacji nadal polega na wysoce ręcznych procedurach przygotowania danych wejściowych.

Marszruta i zestawienie materiałów w symulacji

Dwa rodzaje danych bazowych często sprawiają kłopoty. Marszruta określa, jakie operacje są potrzebne danemu produktowi, w jakiej kolejności, na jakim zasobie i w jakim czasie. Zestawienie materiałów określa, jakie części wchodzą w skład produktu. Przy modelu przepływu marszruta zwykle stanowi szkielet, a zestawienie materiałów ma znaczenie, gdy brakuje części albo gdy stanowisko czeka na podzespół.

Marszruty w ERP to często wartości planistyczne, ustawiane raz i rzadko aktualizowane, co jest problemem opisanym przez Bärringa i współpracowników. Zanim załadujesz marszrutę do modelu, porównaj jej czasy z rzeczywistymi czasami z MES dla tego samego produktu i stanowiska. Sprawdź, czy kolejność operacji nadal odpowiada rzeczywistości na hali, i czy zestawienie materiałów pokazuje warianty, które faktycznie wytwarzasz. Nie wypełniaj luk danymi symulowanymi, czyli tzw. danymi syntetycznymi, i nie zapomnij ich oznaczyć.

Jaka jakość danych symulacyjnych jest wystarczająca?

Odpowiedź brzmi: wystarczająca do podjęcia decyzji. Averill Law w artykule o pułapkach w modelowaniu symulacyjnym domaga się zapisu rozkładów wejściowych i walidacji oraz zaleca gromadzenie danych o wszystkich możliwych źródłach losowości w systemie, o ile to możliwe. Ostrzega przed dwoma błędami: zastąpieniem losowego wejścia jego średnią, co w jego przykładzie całkowicie usuwa kolejkę, oraz wyborem rozkładu normalnego z przyzwyczajenia, co w jednym z jego przykładów dało błąd wyniku na poziomie 39 procent.

Praktyczny sposób ustalenia, ile wysiłku włożyć, to uszeregowanie danych wejściowych według ich wpływu i niepewności każdego parametru. Law zaleca także analizę wrażliwości, aby sprawdzić, które czynniki najbardziej wpływają na mierniki wydajności. Poniższa klasyfikacja jest naszym własnym narzędziem planistycznym, a nie standardem:

1. Ocena A: zmierzone i sprawdzone. Stosuj ją do danych wejściowych, które najmocniej wpływają na wynik, na przykład czasu cyklu na wąskim gardle i wzorca postojów przed nim.
2. Ocena B: pobrane z systemu i sprawdzone na próbce. Stosuj ją do danych o średnim wpływie.
3. Ocena C: opinia ekspercka. Stosuj ją do danych o niewielkim wpływie i zapisz przyjęte założenie.

Na koniec sprawdź cały zestaw walidacją: czy model odtwarza wynik rzeczywistej linii? Jeśli nie, najpierw przyjrzyj się danym wejściowym oceny A.

Przykład: czas z marszruty a czas rzeczywisty

To przykład ilustracyjny z przyjętymi założeniami liczbowymi, a nie opis zmierzonego przypadku. Linia wytwarza jeden produkt. Marszruta w ERP podaje 42 sekundy na sztukę na stanowisku wąskiego gardła. MES pokazuje medianę rzeczywistego czasu cyklu wynoszącą 47 sekund w ciągu czterech tygodni.

• Wydajność na godzinę według czasu z marszruty: 3 600 ÷ 42 = 85,7 sztuki.
• Wydajność na godzinę według czasu rzeczywistego: 3 600 ÷ 47 = 76,6 sztuki.
• Routing zawyża wydajność o 85,7 ÷ 76,6 = około 12 procent. W ośmiogodzinnej zmianie daje to około 686 zamiast 613 detali, czyli różnicę 73 detali.

Model zasilony danymi z routingu przewidywałby wynik, którego linia nigdy nie osiągnęła, a każda poprawa mierzona względem tego modelu wyglądałaby gorzej, niż jest w rzeczywistości.

Ta sama logika dotyczy postojów. Załóżmy, że MES rejestruje siedem postojów trwających 2, 3, 3, 4, 5, 6 i 40 minut. Suma wynosi 63 minuty, więc średnia to 9 minut, a mediana to 4 minuty. Model ze stałym postojem 9 minut nigdy nie uwzględni postoju 40-minutowego, który opróżnia bufor, a jednocześnie pokaże więcej średnich postojów, niż linia faktycznie ma. Wykreśl zarejestrowane czasy trwania, oblicz ich rozrzut i użyj ich bezpośrednio albo rozkładu statystycznego dopasowanego do nich. Parametry tego rozkładu oszacuj na podstawie zapisów.

Dobre wykorzystanie danych: plan w sześciu krokach

1. Sporządź listę pytań. Pytanie decyduje o tym, jakich danych wejściowych potrzebujesz.
2. Wypisz elementy z sześciu wymienionych wyżej grup i zaznacz te, od których pytanie zależy najbardziej.
3. Określ źródło i właściciela każdego z nich, na przykład MES dla postojów, ERP dla zleceń, obserwator dla przezbrojeń.
4. Porównaj źródła. Sprawdź czasy z routingu z danymi z MES oraz upewnij się, że identyfikatory i jednostki są zgodne między systemami.
5. Zmierz luki metodą na poziomie A dla danych wejściowych, które mają znaczenie, a założenia dla pozostałych zapisz.
6. Zweryfikuj i utrzymuj dane. Porównaj model z rzeczywistą linią, zapisz zbiór danych z datą i wyznacz właściciela odpowiedzialnego za jego aktualizację.

Częste błędy

• Wczytanie routingu z ERP bez sprawdzenia. Wartości planowane nie są wartościami rzeczywistymi.
• Posługiwanie się wyłącznie średnimi. Każde dane wejściowe to zmienna o pewnym rozrzucie, a nie pojedyncza liczba. To zmienność tworzy czas oczekiwania, a średnia ją eliminuje.
• Zbieranie wszystkiego. Wysiłek bez pytania marnuje czas, którego projekt nie ma, a nadmiar danych przesłania to, co naprawdę istotne.
• Mieszanie definicji. Postój, przezbrojenie czy cykl mogą oznaczać co innego w różnych systemach.
• Brak właściciela. Dane, których nikt nie utrzymuje, są nieaktualne przy kolejnej zmianie.
• Pominięcie walidacji. Bez porównania z rzeczywistą linią nie wiesz, czy dane wejściowe są wystarczająco dobre.

Jak może pomóc oprogramowanie

Graf wiedzy łączący produkty, etapy procesu i zasoby może ograniczyć duplikaty i sprzeczne dane, ponieważ każdy fakt jest zapisany tylko raz. Polaris Designer firmy iFAKT to moduł iFAKT Polaris, który buduje graf wiedzy produkt-proces-zasób (PPR) jako jedyne źródło prawdy o produktach, etapach procesu i zasobach. Nie zastępuje on jednak porównania z rzeczywistymi czasami, wyznaczania właścicieli ani walidacji modelu. Niezależnie od narzędzia zapytaj, jak importuje dane z ERP i MES oraz jak śledzone są zmiany.

Następny krok

Wybierz stanowisko wąskiego gardła jednej linii i porównaj czas routingu w ERP z rzeczywistym czasem cyklu w MES za ostatnie cztery tygodnie. Jeśli się różnią, znalazłeś pierwszą lukę w danych do budowy modelu symulacyjnego i wiesz, od czego zacząć.