- Komercyjne oprogramowanie symulacyjne ma sens przy dużych, powtarzalnych wdrożeniach, nie zawsze przy jednorazowym projekcie u jednego klienta
- Symulację da się zbudować jako samodzielną aplikację webową w React, bez licencji, z linkiem do udostępnienia klientowi
- Modele językowe przyspieszają pisanie kodu symulacji, ale nie zastępują znajomości procesu i logiki zdarzeniowej
- Każdy wariant modelu trzeba zweryfikować z realnymi pomiarami z hali, inaczej symulacja tylko ładnie wygląda
Pierwsze pytanie, jakie zwykle pada przy projekcie reorganizacji linii, brzmi: w czym to policzymy. Gotowe programy symulacyjne to sprawdzone narzędzia, ale mają dwie cechy, które przy jednorazowym projekcie dla jednego klienta bywają problemem. Licencja kosztuje, a nauka obsługi zajmuje tygodnie, zanim pokaże się klientowi cokolwiek konkretnego.
Przy projekcie reorganizacji jednego stanowiska w układzie one piece flow zamiast sięgać po gotowe oprogramowanie, zbudowałem symulator od zera, jako aplikację w przeglądarce.
React jako silnik symulacji, nie tylko strona
React kojarzy się ze stronami internetowymi, ale równie dobrze nadaje się jako warstwa wizualna dla logiki zdarzeniowej napisanej w zwykłym JavaScripcie. Model liczy, co dzieje się z każdą sztuką na linii krok po kroku: kiedy trafia na kolejne stanowisko, ile tam czeka, kiedy zwalnia narzędzie. React tylko to pokazuje: suwaki do zmiany parametrów, animację przepływu, wykresy obciążenia stanowisk.
Całość działa jako pojedynczy plik HTML, bez instalacji i bez serwera. Można go wysłać na telefon klienta albo otworzyć na spotkaniu offline, tak samo jak zwykłą stronę.
Klient nie musi umieć obsługiwać symulatora. Wystarczy, że kliknie „start" i zobaczy, co się dzieje na linii, zanim zmieni się cokolwiek fizycznie.
Rola modeli językowych w budowie symulatora
Tu do gry wchodzi drugie narzędzie: modele językowe, takie jak Claude, jako pomoc przy pisaniu i przebudowywaniu kodu. Model procesu rzadko jest gotowy za pierwszym razem. Kolejne wizyty na hali przynoszą nowe dane, zmieniają założenia, czasem odwracają wcześniejsze wnioski o wąskim gardle.
Ręczne przepisywanie logiki symulacji przy każdej takiej zmianie jest czasochłonne. Opisanie modelu w naturalnym języku i wygenerowanie albo przebudowanie kodu przez model językowy skraca ten cykl z godzin do minut. Inżynier nadal definiuje logikę procesu i ocenia, czy wynik ma sens, model językowy tylko przyspiesza samo pisanie kodu.
Model, który wygląda dobrze na ekranie, ale nie zgadza się z tym, co zmierzono stoperem na hali, jest bezużyteczny. Każdą wersję symulatora trzeba zweryfikować z realnymi danymi z gemba, zanim pokaże się ją klientowi jako rekomendację.
Komercyjne oprogramowanie czy własny kod
Sprawdza się przy dużych, powtarzalnych wdrożeniach i złożonych sieciach procesów.
- Koszt licencji
- Krzywa nauki narzędzia
- Gotowe biblioteki obiektów
Sprawdza się przy jednorazowym projekcie, szytym pod jeden konkretny proces klienta.
- Zero licencji, jeden plik HTML
- Model językowy przyspiesza kod
- Łatwo wysłać i pokazać na telefonie
Jak to wygląda krok po kroku
- Pomiar na hali: realne czasy operacji, stoper i arkusz, nie szacunki zza biurka
- Model zdarzeniowy: logika przepływu w React, odwzorowująca kolejność i zależności operacji
- Iteracje: poprawki modelu w miarę napływu nowych danych z kolejnych wizyt
- Warianty: testowanie obsady, podziału zadań i progów uruchamiania kolejnych etapów, w modelu, nie na produkcji
- Prezentacja: żywa symulacja zamiast statycznego raportu, klient sam klika „start"
Podejście to nie jest zamiennikiem gemba ani wiedzy inżynierskiej o procesie. Model liczy tylko to, co się w niego wpisze, a wpisać trzeba dane zebrane na hali, nie założenia. To, co zmienia się dzięki React i modelom językowym, to koszt i czas zbudowania narzędzia do przetestowania tych danych, zanim ktokolwiek przestawi choć jedno stanowisko.