Plan produkcji może być aktualny w biurze i nieaktualny przy stanowisku. Wystarczy opóźniona dostawa, niedostępne narzędzie albo zlecenie, które wymaga poprawki. Aplikacja na produkcji powinna pomagać zobaczyć tę zmianę w czasie potrzebnym do działania. Jeśli informacja pojawia się dopiero w raporcie po zakończeniu zmiany, opisuje historię. Historia też jest potrzebna, ale nie zastąpi rozmowy o tym, co zrobić z zatrzymaną pracą teraz.
Zanim wybierzecie ekran hali, ustalcie, kto podejmuje decyzję na podstawie danych. Operator potrzebuje wiedzieć, co wykonać i gdzie zgłosić problem. Lider zmiany może potrzebować przyczyny zatrzymania oraz dostępności zasobów. Planista patrzy na zależności między zleceniami. Jeden wspólny widok nie musi obsługiwać wszystkich tych potrzeb. Ważniejsze jest, aby informacje przechodziły między rolami bez ponownego przepisywania i niejasnych statusów.
Status powinien prowadzić do następnego działania
Samo „w toku” niewiele wyjaśnia, gdy zlecenie od kilku godzin nie posuwa się dalej. Warto ustalić stany, które mają znaczenie dla pracy, oraz osobę odpowiedzialną za reakcję. Powód zatrzymania powinien być możliwy do wskazania bez długiego opisywania sytuacji na stanowisku. Nie oznacza to tworzenia słownika obejmującego każdą możliwą historię. Kategorie mają pomagać rozpoznać potrzebę, a nie wymuszać wybór najbliższej przypadkowej odpowiedzi.
Późniejszy dashboard produkcyjny będzie tak dobry, jak znaczenie tych zapisów. Jeżeli pracownicy inaczej rozumieją „awarię”, „brak materiału” albo „oczekiwanie”, liczby nie dadzą wspólnego obrazu. Uzgodnijcie definicje na przykładach z hali. Czasem trzeba zmienić nazwę kategorii, czasem cały sposób rejestrowania zdarzenia. Wykres nie naprawi sytuacji, w której najważniejsza informacja od początku trafia do pola „inne”.
Wprowadzanie danych musi pasować do stanowiska
Małe przyciski, długie listy i obowiązkowy komentarz do każdej czynności mogą sprawić, że aplikacja przegra z kartką. Nie dlatego, że zespół nie lubi technologii. Dlatego, że narzędzie wymaga uwagi w niewłaściwym momencie. Sprawdźcie dostępne urządzenia, warunki oświetlenia i sposób używania. Informacja o zakończeniu zadania powinna być prosta do zapisania, ale nadal zawierać elementy potrzebne osobie, która odbiera wynik.
Przydatny będzie test prototypu z operatorami. Poproście o wykonanie krótkiej sekwencji na docelowym stanowisku. Zobaczcie, czy użytkownik potrafi znaleźć właściwe zlecenie i wrócić do niego po przerwie. Nie oceniajcie samego wyglądu. Jeśli do poprawnego użycia ekranu potrzebny jest stały instruktor, projekt interfejsu nie został jeszcze domknięty, nawet gdy na dużym monitorze w sali spotkań wygląda znakomicie.
Połączenie z planem wymaga właściciela danych
Aplikacja może pobierać zlecenia z obecnego systemu, ale potrzebuje jasnego podziału odpowiedzialności. Gdzie zmienia się ilość? Kto potwierdza zakończenie? Czy korekta planu może nadpisać informację z hali? Zagadnienia integracji systemów trzeba rozstrzygnąć przed uruchomieniem, ponieważ sprzeczne zapisy utrudniają zarówno pracę bieżącą, jak i późniejszą analizę. Dwa ekrany nie powinny po cichu opowiadać dwóch wersji tego samego zlecenia.
Jeżeli firma ma kilka zakładów, porównajcie też lokalne reguły. Wspólny system dla wielu oddziałów nie musi oznaczać identycznego przebiegu przy każdej linii. Potrzebuje natomiast wspólnych pojęć oraz świadomie opisanych różnic. Warto oddzielić plan, wykonanie i powód odstępstwa. Dzięki temu można porównywać dane bez zmuszania wszystkich miejsc do udawania, że korzystają z tych samych urządzeń i mają te same ograniczenia.
Zacznij od obiegu, który da się sprawdzić na zmianie
Ustalcie, do czego będą używane przyczyny postojów i kto zobaczy szczegółowe zapisy. Jeśli pracownik spodziewa się, że każde zgłoszenie problemu stanie się zarzutem wobec niego, jakość danych może ucierpieć. Narzędzie powinno pomagać rozwiązywać sytuację oraz prowadzić do właściwej reakcji. Cel rejestrowania informacji trzeba więc wyjaśnić zespołowi przed uruchomieniem aplikacji.
Pierwszy zakres może obejmować wybraną linię lub typ zlecenia. Powinien jednak pozwalać przyjąć zadanie, zobaczyć zmianę stanu i odebrać rezultat. Przed startem ustalcie, jak zespół będzie działał przy przerwie w dostępie do aplikacji. Narzędzie do informacji operacyjnej nie powinno być mylone z systemem sterowania maszyną; jeśli projekt dotyczy również sterowania, wymaga osobnego rozpoznania technicznego i odpowiedzialności. Granica zastosowania musi być jasna dla wszystkich uczestników.
Do testów odbiorowych włączcie zwykłe zlecenie, postój, korektę oraz przekazanie pracy między zmianami. Archifutura pomaga projektować rozwiązania dla produkcji i przemysłu na podstawie takich scenariuszy. Jeśli chcesz omówić aplikację dla hali, przygotuj przykład zlecenia, które niedawno wymagało wyjaśnień. Pokaże miejsca, w których informacja traci ciągłość, i pozwoli zaplanować zmianę przydatną zarówno operatorowi, jak i osobie układającej plan.
