Pierwsze pytanie nie brzmi, co da się zautomatyzować, tylko co powinno zostać przy człowieku. Czynność wymagająca oceny sytuacji zapisana jako reguła kończy się listą wyjątków dłuższą od samej reguły.
Kiedy reguła zastąpi decyzję
Automatyzacja zamienia decyzję człowieka na regułę wykonywaną przez system. Zamiana ma sens wtedy, gdy decyzja była w istocie mechaniczna, a osoba ją podejmująca za każdym razem rozumowała tak samo.
Cztery warunki poniżej sprawdza się przed wpisaniem czegokolwiek do konfiguracji. Brak jednego z nich zwykle oznacza, że czynność jeszcze się do tego nie nadaje.
- Powtarzalność - ten sam zestaw danych wejściowych prowadzi zawsze do tego samego wyniku.
- Częstotliwość - czynność występuje na tyle często, że nakład na regułę się zwróci.
- Jednoznaczność danych - wszystko, czego reguła potrzebuje, jest zapisane w systemie przed jej uruchomieniem.
- Koszt pomyłki - błąd ręczny kosztuje wystarczająco, by opłacało się go wyeliminować.
Trzeci warunek jest najczęściej pomijany. Reguła wyznaczająca długość obsługi na podstawie liczby palet nie zadziała, dopóki liczba palet nie trafia do zgłoszenia. Zakres danych zgłoszenia opisuje strona o danych do awizacji.
Proces, który najpierw wymaga poprawy
Automatyzacja utrwala to, co zastanie. Reguła odwzorowująca obieg dokumentów zbudowany przez lata przypadkowych decyzji sprawi, że ten obieg będzie wykonywany szybciej i trudniej go będzie zmienić.
Rozpoznanie takiej sytuacji jest proste. Gdy przy opisywaniu procesu pada zdanie, że tak się przyjęło, i nikt nie potrafi wskazać powodu, należy najpierw ustalić powód. Bywa, że krok znika w całości i nie ma czego automatyzować.
Kolejność pracy wygląda więc odwrotnie, niż podpowiada zapał wdrożeniowy: najpierw opis stanu faktycznego, potem usunięcie kroków bez uzasadnienia, dopiero na końcu reguła. Rolę systemu w porządkowaniu decyzji opisuje strona o roli systemu YMS.
Zautomatyzowany bałagan przestaje być widoczny, bo nikt już nie wykonuje tych czynności ręcznie i nikt się nad nimi nie zastanawia. Koszt zostaje, a możliwość zauważenia go znika.
Wyjątki i ich rosnący koszt
Reguła obsługuje przypadki standardowe, które stanowią zwykle większość ruchu. Reszta trafia do człowieka i to właśnie z resztą wiąże się najczęstsze rozczarowanie wdrożeniem.
Powód jest nieoczywisty. Obsługa wyjątku była wcześniej jedną z wielu podobnych czynności, więc personel miał w niej wprawę. Po automatyzacji przypadków standardowych zostają wyłącznie trudne, wykonywane rzadko i przez to wolniej niż przedtem.
Wniosek praktyczny dotyczy projektowania reguły. Ścieżka wyjątku wymaga zaprojektowania na równi ze ścieżką podstawową, razem z opisem, co ma zrobić osoba, która dostanie sprawę do rozpatrzenia. Pominięcie tego przenosi problem na zmianę nocną.
Drugi wniosek dotyczy miary. Odsetek zgłoszeń wymagających ręcznej interwencji jest wielkością, którą warto obserwować w czasie. Jego wzrost oznacza, że reguła przestała pasować do ruchu, zanim ktokolwiek to zauważy.
Wyzwalacz zdarzeniowy a zadanie cykliczne
Reguła uruchamia się na dwa sposoby i wybór między nimi zmienia zachowanie całego mechanizmu. Wyzwalacz zdarzeniowy reaguje w chwili wystąpienia zdarzenia, zadanie cykliczne wykonuje się o ustalonej porze niezależnie od tego, czy jest co robić.
Powiadomienie o zbliżającym się terminie dostawy należy do pierwszej grupy, bo musi wyjść w określonym odstępie przed zdarzeniem. Nocne przeliczenie wskaźników należy do drugiej, bo wykonuje się je raz na dobę na komplecie danych. Sposób definiowania zadań uruchamianych według rozkładu opisuje dokumentacja usługi SQL Server Agent w Microsoft Learn.
Częstym błędem jest obsłużenie zdarzenia zadaniem cyklicznym o krótkim okresie. Mechanizm sprawdzający co minutę, czy pojawiło się nowe zgłoszenie, działa poprawnie i obciąża bazę bez potrzeby, a przy tym wprowadza opóźnienie, którego nie da się usunąć.
Co w obsłudze transportu nadaje się najlepiej
Poniższe czynności spełniają wszystkie cztery warunki i zwykle dają efekt widoczny w pierwszym miesiącu. Każdej towarzyszy warunek, bez którego reguła nie zadziała.
| Czynność | Warunek | Co zostaje człowiekowi |
|---|---|---|
| Wyznaczenie długości okna | Rodzaj transportu i liczba jednostek w zgłoszeniu | Korekta przy dostawach nietypowych |
| Powiadomienie o zmianie terminu | Adres kontaktowy w kartotece przewoźnika | Rozmowa przy zmianie w ostatniej chwili |
| Nadanie numeru zgłoszenia | Ustalony wzorzec numeracji | Nic |
| Zwolnienie terminu po odwołaniu | Odwołanie zapisane w systemie, nie telefoniczne | Decyzja o wykorzystaniu zwolnionego okna |
Wiersz trzeci pokazuje wzorzec idealny: czynność w całości mechaniczna, przy której człowiek nie wnosi nic poza ryzykiem pomyłki. Wiersz czwarty jest trudniejszy, bo wymaga zmiany zwyczaju po stronie przewoźników. Zasady obsługi puli terminów opisuje strona o zarządzaniu awizacjami, a dobór parametrów okna - materiał o definiowaniu okien czasowych.
Rozpoznanie pojazdu jako wejście do reguły
Najdalej idącą postacią automatyzacji na terenie obiektu jest powiązanie zdarzenia fizycznego z zapisem w systemie bez udziału operatora. Odczyt tablicy rejestracyjnej przy wjeździe zestawia pojazd z oczekującym zgłoszeniem i zapisuje znacznik czasu.
Warunkiem jest poprawny numer rejestracyjny w zgłoszeniu, co przenosi wymaganie na etap rezerwacji. Zgłoszenie bez numeru albo z numerem wpisanym z pomyłką kończy się obsługą ręczną przy szlabanie, czyli sytuacją wyjściową.
Efektem ubocznym, często ważniejszym od samego wjazdu, jest komplet znaczników czasu zbieranych bez niczyjego wysiłku. Na nich opierają się późniejsze miary czasu obsługi. Zasady prowadzenia ruchu na bramie opisuje strona o kontroli wjazdu i wyjazdu pojazdów, a przebieg obsługi od zapowiedzi do zamknięcia - materiał o awizowaniu dostawy.
Sprawdzenie reguły przed uruchomieniem
Reguła włączona od razu na całym ruchu pokazuje swoje wady na żywych zgłoszeniach. Tańszy sposób polega na przeliczeniu jej wstecz, na danych z ostatniego miesiąca, i porównaniu wyniku z tym, co faktycznie zrobili ludzie.
Rozbieżności są tu materiałem najcenniejszym. Zgłoszenia, przy których reguła wyznaczyłaby inną wartość niż dyspozytor, dzielą się na dwie grupy: takie, gdzie człowiek działał odruchowo, i takie, gdzie uwzględnił coś, czego reguła nie zna. Pierwsze potwierdzają sens zmiany, drugie wskazują brakujący warunek.
Kolejnym etapem bywa praca w trybie cichym. System wylicza wartość i zapisuje ją obok, bez wpływu na obsługę, a obsługa pracuje jak dotychczas. Po dwóch tygodniach widać, czy propozycje mechanizmu zbiegają się z decyzjami.
Przed włączeniem warto też przygotować sposób wycofania. Zmiana konfiguracji zapisana z datą i autorem pozwala wrócić do stanu poprzedniego bez odtwarzania go z pamięci, co przy kilkunastu parametrach nigdy nie udaje się w całości.
Nadzór nad tym, co działa samo
Mechanizm działający poprawnie przestaje być zauważany. Właśnie dlatego jego awaria bywa wykrywana z opóźnieniem liczonym w dniach, zwykle przez kogoś z zewnątrz, kto zapyta, czemu nie dostał powiadomienia.
Zabezpieczeniem jest traktowanie braku zdarzeń jako zdarzenia. Zadanie, które co noc wysyłało kilkadziesiąt wiadomości i nagle wysłało zero, wymaga sprawdzenia, choć nie zgłosiło żadnego błędu.
Druga sprawa dotyczy widoczności skutków. Reguła zmieniająca dane bez śladu w historii utrudnia ustalenie, dlaczego zgłoszenie wygląda tak, a nie inaczej. Operacje automatyczne zapisuje się w rejestrze na tych samych zasadach co operacje użytkowników, z oznaczeniem wykonawcy.
Zestawienia pokazujące liczbę wykonań i liczbę wyjątków buduje się raz i czyta okresowo. Sposób ich przygotowania opisuje strona o usługach raportowych SQL Server, a rozkład ruchu między dni tygodnia - materiał o planowaniu dostaw.
Kolejność wprowadzania reguł
Projekt obejmujący wiele reguł naraz kończy się zwykle odwrotem, bo przy pierwszym problemie nikt nie wie, który mechanizm odpowiada za nieoczekiwane zachowanie. Wprowadzanie pojedynczo wydłuża harmonogram i skraca czas potrzebny na diagnozę.
Naturalna kolejność wynika z ryzyka. Zaczyna się od reguł, które wyłącznie informują, przechodzi do tych, które liczą, a na końcu wprowadza te, które zmieniają stan zgłoszenia bez udziału człowieka.
| Rodzaj reguły | Przykład | Skutek błędu |
|---|---|---|
| Informująca | Powiadomienie o zbliżającym się terminie | Wiadomość wysłana niepotrzebnie |
| Licząca | Wyznaczenie długości okna z liczby palet | Termin za krótki, korygowany ręcznie |
| Zmieniająca stan | Zwolnienie terminu po braku wjazdu | Utrata rezerwacji pojazdu w drodze |
| Blokująca | Odmowa wjazdu bez zgłoszenia | Pojazd zatrzymany przed bramą |
Ostatni wiersz wymaga największej ostrożności, bo skutek dotyka kogoś, kto stoi na miejscu i czeka. Reguły blokujące uruchamia się po okresie pracy w trybie ostrzegawczym, w którym system sygnalizuje naruszenie, a decyzję zostawia obsłudze.
Jakość danych na wejściu
Reguła jest tak dobra jak dane, na których pracuje. Mechanizm wyznaczający długość obsługi z liczby jednostek daje wynik poprawny dopiero wtedy, gdy liczba jednostek odpowiada rzeczywistości, a nie wartości wpisanej dla wygody.
Typowe zakłócenie wygląda tak samo w każdym wdrożeniu. Pole wymagane, którego nikt nie sprawdza, wypełnia się wartością domyślną, bo formularz inaczej nie przejdzie dalej. Po kilku tygodniach połowa zgłoszeń ma tę samą liczbę palet i reguła przestaje cokolwiek różnicować.
Zabezpieczeniem jest zestawienie rozkładu wartości w polu, które zasila regułę. Skupienie wyników wokół jednej liczby oznacza wpisywanie bez zastanowienia, a nie jednorodność ruchu.
Druga sprawa dotyczy jednostek. Ta sama pozycja opisana raz w paletach, raz w kartonach psuje każde obliczenie oparte na sumie. Uporządkowanie słowników jednostek poprzedza wprowadzenie reguł liczących, choć wygląda na pracę bez efektu.
Powiadomienia jako najtańszy początek
Automatyczna wysyłka informacji jest mechanizmem o najlepszym stosunku efektu do nakładu. Nie zmienia niczyjego stanu, nie wymaga zgody kontrahentów i daje się wyłączyć w minutę, gdyby okazała się uciążliwa.
Treść buduje się z szablonu z polami podstawianymi z danych zgłoszenia. Zmiana treści sprowadza się wtedy do poprawienia szablonu, bez udziału dostawcy i bez zmiany w programie.
Uwaga dotyczy liczby wiadomości. Powiadomienie o każdej zmianie pola kończy się tym, że odbiorca przestaje je czytać, a wtedy przestaje działać także to jedno ważne. Wysyła się informacje o zdarzeniach wymagających reakcji, a resztę zostawia do odczytu w systemie.
Dobór kanału zależy od pilności. Wiadomość elektroniczna służy potwierdzeniom i dokumentom, krótka wiadomość tekstowa - sytuacjom wymagającym reakcji w ciągu godziny. Zasady obiegu takich informacji opisuje strona o systemie do awizacji i powiadomieniach.
Wymiana danych zamiast przepisywania
Największe pojedyncze oszczędności czasu nie biorą się z reguł decyzyjnych, tylko z usunięcia ręcznego przenoszenia danych między systemami. Zamówienie wprowadzone w systemie sprzedaży i przepisane do rejestru dostaw istnieje dwa razy, z ryzykiem rozbieżności przy każdej korekcie.
Techniczna strona sprowadza się do ustalenia, który system jest źródłem danej wartości. Zamówienie pochodzi ze sprzedaży, termin obsługi z rejestru dostaw, a potwierdzenie przyjęcia z magazynowego. Każda wartość ma jednego właściciela i jeden kierunek przepływu.
Brak tego ustalenia prowadzi do sytuacji, w której dwa systemy nadpisują się wzajemnie, a użytkownicy uczą się, że jeden z nich kłamie. Naprawa polega wtedy na odebraniu prawa zapisu jednej ze stron, co zwykle budzi opór działu, który je miał.
Wymiana bywa uruchamiana etapami, zaczynając od kierunku dającego najwięcej. Zwykle jest to przesłanie planowanych dostaw do rejestru terminów, bo znosi przepisywanie kilkudziesięciu pozycji dziennie. Sposób przygotowania takich zestawień opisuje strona o logistyce dostaw.
Reguła a kalendarz pracy obiektu
Mechanizm liczący terminy musi znać czas, w którym obiekt pracuje. Bez tej wiedzy wyznaczy okno na trzecią w nocy albo w sobotę, formalnie poprawnie i praktycznie bezużytecznie.
Kalendarz obejmuje więcej niż godziny otwarcia. Składają się na niego dni wolne ustawowe, przerwy międzyzmianowe, planowane przeglądy urządzeń oraz okresy o ograniczonej obsadzie, na przykład skrócone piątki. Każda z tych pozycji zmienia dostępność inaczej.
Prowadzenie kalendarza wymaga dyscypliny, bo pozycja wpisana z opóźnieniem nie cofnie rezerwacji już przyjętych. Przegląd rampy zaplanowany na przyszły miesiąc wprowadza się w chwili ustalenia terminu, a nie w tygodniu jego wykonania.
Odrębnym zagadnieniem są wyjątki jednorazowe. Skrócenie pracy w dniu inwentaryzacji obsługuje się wyłączeniem terminów w tym dniu, bez zmiany reguły ogólnej, która obowiązuje przez resztę roku.
Zachowanie reguł przy szczycie ruchu
Parametry dobiera się zwykle na podstawie tygodnia przeciętnego, a sprawdzają się albo nie sprawdzają w tygodniu najtrudniejszym. Mechanizm zwalniający termin po trzydziestu minutach od niewykorzystania jest rozsądny przy luźnej siatce i dotkliwy, gdy każde okno ma oczekujących.
Podobnie zachowują się reguły wyznaczające czas obsługi. Wartość wyliczona przy normalnej obsadzie magazynu okazuje się za krótka w dniu, w którym połowa zespołu pracuje przy inwentaryzacji, a skutkiem jest narastające opóźnienie wszystkich kolejnych transportów.
Rozwiązaniem bywa powiązanie parametru z okresem zamiast ustawiania jednej wartości na stałe. Inna długość okna w sezonie i poza nim jest zmianą prostą do wprowadzenia, a znosi większość korekt wykonywanych ręcznie w miesiącach o wzmożonym ruchu.
Sprawdzenia dokonuje się przed sezonem, nie w jego trakcie. Przeliczenie reguł na danych z analogicznego okresu poprzedniego roku pokazuje, które z nich wymagają innego ustawienia, zanim zacznie to zauważać kolejka pod bramą.
Dokumenty powstające automatycznie
Część pracy ręcznej w obsłudze transportu dotyczy wytwarzania dokumentów, a nie podejmowania decyzji. Przepustka wjazdowa, potwierdzenie rezerwacji i zestawienie transportów dnia powstają z danych, które system już posiada.
Zysk polega na zgodności treści ze stanem. Dokument wygenerowany na żądanie zawiera wartości aktualne w chwili wydruku, podczas gdy wersja przygotowana wcześniej opisuje stan sprzed zmiany terminu.
Warunkiem jest przygotowanie wzoru obejmującego przypadki nietypowe. Zgłoszenie z dwoma pojazdami albo z pustym polem opcjonalnym musi dać dokument czytelny, a nie układ rozjechany po dodaniu wiersza.
Dokumenty wymagające podpisu zyskują dodatkowo na jednoznaczności numeracji. Każdy egzemplarz otrzymuje identyfikator powiązany ze zgłoszeniem, dzięki czemu okazany przy bramie wydruk daje się sprawdzić bez przeszukiwania rejestru po nazwisku kierowcy.
Jak wykazać efekt
Efekt automatyzacji bywa trudny do obrony, bo znika praca, której nikt wcześniej nie mierzył. Liczba telefonów o godzinę dostawy nie figuruje w żadnym zestawieniu, choć zajmowała dyspozytorowi część dnia.
Wielkość wyjściową trzeba więc zebrać przed uruchomieniem, choćby zgrubnie. Tydzień notowania liczby połączeń i czasu spędzonego na wprowadzaniu danych daje podstawę wystarczającą do porównania.
Po stronie wyniku liczy się dwie wielkości: udział zgłoszeń obsłużonych bez interwencji oraz czas od założenia zgłoszenia do jego potwierdzenia. Pierwsza mówi o zasięgu reguły, druga o tym, czy zmiana jest odczuwalna dla kontrahenta.
Pomiar warto powtórzyć po kwartale, bo pierwsze tygodnie zawsze wypadają gorzej. Personel uczy się nowej ścieżki, a reguła jest korygowana po napotkaniu przypadków, których nikt nie przewidział przy projektowaniu.
Zmiana zakresu pracy zespołu
Automatyzacja rzadko kończy się zmniejszeniem obsady. Znacznie częściej przesuwa zakres obowiązków w stronę spraw, na które wcześniej brakowało czasu, i ta zmiana wymaga przygotowania.
Dyspozytor zwolniony z ustalania godzin przez telefon zaczyna zajmować się przewoźnikami, którzy nie dotrzymują terminów, oraz analizą przyczyn opóźnień. Obie czynności wnoszą więcej niż odbieranie połączeń i obie wymagają innych umiejętności.
Zaniedbanie tej rozmowy prowadzi do oporu, który przyjmuje postać omijania systemu. Osoba przekonana, że narzędzie ma ją zastąpić, nie będzie pilnowała jakości danych, na których to narzędzie pracuje.
Pomocne bywa powierzenie części konfiguracji ludziom z operacji. Administrator wywodzący się z dyspozytury zmienia parametry szybciej i trafniej niż osoba znająca wyłącznie system. Zakres takich uprawnień opisuje strona o administrowaniu systemem awizacji.
Gdzie automatyzacja kończy się z założenia
Część decyzji w logistyce wymaga wiedzy spoza systemu. Zgoda na obsługę pojazdu bez rezerwacji zależy od stanu magazynu, od relacji z odbiorcą i od tego, czy dzień jest spokojny. Reguła zapisze tylko pierwszy z tych warunków.
Próba objęcia regułą wszystkiego kończy się konfiguracją, której nikt nie rozumie po roku. Rozsądniejsze jest ograniczenie automatyzacji do przypadków jednoznacznych i pozostawienie reszty osobie z uprawnieniem do decyzji, wraz z zapisem, kto i kiedy zdecydował.
Decyzja pozostawiona człowiekowi powinna być zapisana tak samo starannie jak wykonana przez system. Bez autora i czasu w rejestrze ustalenie po miesiącu, dlaczego wpuszczono pojazd bez rezerwacji, jest niemożliwe.
Trzeba przy tym odróżnić decyzję od jej wykonania. System może obsłużyć całą czynność techniczną, łącznie z nadaniem terminu i wydrukiem przepustki, pozostawiając człowiekowi wyłącznie zatwierdzenie. Taki podział zachowuje ocenę sytuacji tam, gdzie jest potrzebna, i zdejmuje pracę, która nie wymaga oceny.
Miarą dobrze postawionej granicy jest liczba sytuacji, w których użytkownik obchodzi system. Rosnąca liczba obejść oznacza regułę oderwaną od rzeczywistości, a nie brak dyscypliny po stronie personelu. Przebieg przyjęcia towaru opisuje strona o przyjmowaniu dostaw.