Decyzje powtarzalne o jednoznacznym kryterium przechodzą do reguł, decyzje wymagające oceny sytuacji zostają przy człowieku. Próba zautomatyzowania tych drugich kończy się obchodzeniem systemu, a nie oszczędnością czasu. Pozostałe teksty o tym, co rozstrzyga system YMS, a co zostaje przy człowieku, stoją na stronie przeglądowej kategorii.
Które decyzje nadają się do zamiany w regułę
Kryterium jest proste i rzadko stosowane: decyzja przechodzi do systemu wtedy, gdy da się ją zapisać w postaci warunku bez odwołania do oceny sytuacji. Sprawdzenie, czy okno na danej rampie jest wolne, spełnia ten warunek. Rozstrzygnięcie, czy wpuścić pojazd bez zgłoszenia, nie spełnia go nigdy.
Mieszanie tych dwóch kategorii jest źródłem większości nieudanych wdrożeń. System, który próbuje decydować o wyjątkach, generuje odmowy obchodzone przez uprawnienia administracyjne, a po kwartale połowa ruchu idzie ścieżką omijającą regułę.
| Decyzja | Kto podejmuje | Dlaczego |
|---|---|---|
| Dostępność okna czasowego | Reguła w bazie | Warunek jednoznaczny, sprawdzalny przy zapisie |
| Przekroczenie limitu palet | Reguła w bazie | Wartość liczbowa porównywana z limitem |
| Wjazd pojazdu bez zgłoszenia | Operator z uprawnieniem | Wymaga oceny skutków odesłania |
| Kolejność przy spiętrzeniu | Operator według reguły | Reguła podpowiada, decyzja zostaje przy człowieku |
Czwarty wiersz opisuje układ pośredni, najczęściej spotykany w praktyce. System porządkuje kolejkę według ustalonych kryteriów, a operator może ją zmienić z zapisem powodu. Zapis powodu jest tu istotniejszy niż sama możliwość zmiany, bo pozwala policzyć, jak często reguła nie pasuje do rzeczywistości.
Co zostaje przy człowieku na stałe
Trzy rodzaje rozstrzygnięć nie przejdą do systemu niezależnie od jego zaawansowania, bo wymagają wiedzy spoza rejestru.
Pierwszy to ocena skutków odstępstwa. Odesłanie pojazdu z surowcem wstrzymującym produkcję kosztuje więcej niż przyjęcie go poza kolejnością, a system nie zna harmonogramu produkcji. Drugi to negocjacja z kontrahentem, bo jej wynik zależy od relacji handlowej, nie od danych o transporcie.
Trzeci to rozstrzygnięcie sporu. Rejestr dostarcza faktów - kto i o której - ale decyzja o obciążeniu przestojem zależy od umowy i od tego, jak strony chcą prowadzić współpracę dalej. Zasady rozliczania opisuje strona o koszcie przestoju pojazdu.
Reguła, którą operatorzy obchodzą codziennie, jest gorsza niż jej brak. Daje złudzenie kontroli, a równocześnie zapełnia rejestr wpisami wykonanymi na obejście, przez co dane przestają opisywać rzeczywisty proces.
Gdzie reguła musi być egzekwowana
Miejsce sprawdzania warunku przesądza o jego skuteczności. Walidacja wykonana wyłącznie w formularzu przeglądarki działa dla użytkownika klikającego zgodnie z przewidywaniami i nie działa dla niczego innego.
- Reguła w bazie - skuteczna dla formularza, importu i integracji; jedyna, która naprawdę ogranicza.
- Reguła w warstwie aplikacji - obejmuje wszystkie ścieżki przez serwer, ale nie zapis bezpośredni.
- Walidacja w przeglądarce - podpowiedź dla użytkownika, nie zabezpieczenie.
- Zapis w procedurze - obowiązuje dopóty, dopóki ktoś jej przestrzega.
Kontrola dostępności okna należy do pierwszej kategorii, bo zgłoszenia przychodzą nie tylko z formularza, lecz także z importu i z wymiany danych. Mechanizm transakcyjny stojący za tym sprawdzeniem opisuje strona o kalendarzu rezerwacji wobec arkusza.
Decyzje oparte na danych
Trzecia kategoria to rozstrzygnięcia, których system nie podejmuje, ale bez niego nie dałoby się ich podjąć. Długość okna czasowego, liczba osób na zmianie i rezerwa na ruch nieplanowany wynikają z rozkładów zmierzonych w rejestrze.
Przed wdrożeniem parametry te ustala się z przeczucia kierownika zmiany, po wdrożeniu z danych. Różnica bywa znaczna i widać ją dopiero po pierwszym kwartale, gdy zebrany rozkład czasów obsługi okazuje się szerszy, niż ktokolwiek zakładał. Metodę liczenia porządkuje strona o wskaźnikach OTIF.
Jak zmienia się praca po wdrożeniu
Oczekiwanie, że system zdejmie pracę, sprawdza się połowicznie. Ubywa czynności powtarzalnych: przepisywania danych z dokumentów, odpowiadania na pytania o status, ustalania telefonicznie, kto kiedy przyjedzie. Przybywa natomiast decyzji podejmowanych świadomie, bo wcześniej zapadały przypadkiem.
Dyspozytor, który dotąd wpuszczał pojazdy w kolejności przyjazdu, musi teraz rozstrzygać o pierwszeństwie. Kierownik, który utrzymywał stałą obsadę, widzi rozkład obciążenia i musi zdecydować, czy go wyrównać. Obie sytuacje są korzystne, ale nie polegają na zmniejszeniu odpowiedzialności. Przebieg dnia na stanowisku opisuje strona o zarządzaniu awizacjami.
Dobór zakresu do organizacji
Liczba reguł, które warto uruchomić, zależy od tego, ile osób będzie je stosować. Obiekt obsługiwany przez dwie osoby na zmianę nie potrzebuje rozbudowanego systemu uprawnień, bo obie i tak wiedzą wszystko. Obiekt z kilkunastoma stanowiskami i rotacją wymaga odwrotnego podejścia.
Zasada jest przy tym stała niezależnie od skali: reguła bez osoby, która ją stosuje i pilnuje, przestaje działać w ciągu kwartału. Kryteria doboru zakresu zbiera strona o programie YMS, a podział modułów placowych - materiał o programie klasy Yard Management System.
Informowanie jako czynność przejęta w całości
Obszarem, w którym system zastępuje człowieka bez zastrzeżeń, jest przekazywanie informacji o zmianie stanu. Wiadomość wysłana automatycznie przy przesunięciu okna dociera szybciej niż telefon i nie zależy od tego, czy ktoś zdążył ją wykonać przed końcem zmiany.
Zdarzeń wyzwalających powiadomienie jest kilka i warto ograniczyć się do tych, na które odbiorca faktycznie reaguje. Potwierdzenie przyjęcia zgłoszenia, przesunięcie terminu, prośba o uzupełnienie brakujących danych oraz odwołanie rezerwacji pokrywają praktycznie całą komunikację z przewoźnikiem.
Nadmiar wiadomości działa odwrotnie do zamierzenia. Powiadomienie o każdej zmianie statusu wewnętrznego sprawia, że odbiorca przestaje je czytać, a wtedy przepada również ta jedna ważna. Zakres zdarzeń ustala się więc przy wdrożeniu i przegląda po kwartale, licząc, na które przewoźnicy odpowiadają.
Adresatów wyznacza rola, nie lista nazwisk. Zmiana osoby planującej transport u kontrahenta nie powinna wymagać edycji konfiguracji, a tak kończy się przypisanie po adresach wpisanych ręcznie.
Co zmienia się po stronie kontrahentów
Wdrożenie przesuwa część pracy na zewnątrz organizacji i to jest najtrudniejszy element do uzgodnienia. Przewoźnik, który dotąd dzwonił, ma teraz założyć zgłoszenie, uzupełnić dane pojazdu i pilnować terminu. Z jego perspektywy przybyło obowiązków.
Argument, który działa, dotyczy czasu spędzanego pod bramą. Kierowca czekający trzy godziny kosztuje przewoźnika więcej niż pięć minut spedytora poświęcone na rezerwację. Rachunek ten warto przedstawić liczbami z rejestru, a nie ogólnym zapewnieniem o usprawnieniu.
Drugim argumentem jest dowód. Znaczniki czasu z bramy rozstrzygają spór o postój na korzyść tej strony, która ma rację, a nie tej, która głośniej protestuje. Dla przewoźnika obsługującego kilkudziesięciu odbiorców bywa to wartość większa niż sam harmonogram. Sposób wyceny opisuje strona o koszcie przestoju pojazdu.
Dochodzenie do pełnego zakresu
Uruchomienie wszystkich reguł naraz przeciąża zespół i utrudnia przypisanie efektu. Kolejność, która się sprawdza, zaczyna się od rejestru wizyt, bo dostarcza danych do ustawienia wszystkiego pozostałego.
Drugim etapem jest siatka okien z parametrami wyznaczonymi z zebranego rozkładu czasów obsługi. Trzecim portal dla firm zewnętrznych, czwartym limity i pule dla kontrahentów, gdy okaże się, że dostęp do terminów wymaga rozdzielenia.
Integracje i raporty analityczne wchodzą na końcu, gdy struktura zgłoszenia jest stabilna. Wcześniejsze ich uruchomienie oznacza, że każda korekta procesu pociąga zmianę po obu stronach wymiany danych. Przebieg takiego projektu opisuje strona o wdrożeniu oprogramowania do awizowania dostaw.
Każdy etap warto zamknąć pomiarem, zanim zacznie się kolejny. Bez tego po roku wiadomo, że jest lepiej, ale nie wiadomo, która zmiana to sprawiła, a to przesądza o tym, czy da się powtórzyć efekt w kolejnym obiekcie.