Komunikacja z programem magazynowym na stanowisku operatora

Program magazynowy rozmawia z człowiekiem cały dzień: pokazuje zadanie, przyjmuje skan, odpowiada na błąd i wysyła alert do przełożonego. Jakość tej rozmowy decyduje o tym, czy nowy operator pracuje samodzielnie po kilku zmianach, czy dzwoni do działu IT po każdej pomyłce. Tekst dotyczy wyłącznie tej warstwy, czyli styku człowieka z systemem.

Wymiana danych między samymi systemami, na przykład między WMS a ERP, przebiega w tle i ma osobny opis w tekście o komunikacji systemu WMS z innymi systemami. Tutaj chodzi o to, co pracownik magazynu widzi i słyszy oraz co musi zrozumieć.

Komunikacja z programem magazynowym - kanały i odbiorcy

System ma do dyspozycji kilka kanałów, a każdy nadaje się do innej sytuacji. Ekran kolektora obsługuje bieżącą czynność. Sygnał dźwiękowy i kolor tła działają szybciej niż tekst. Powiadomienie poza stanowiskiem trafia do osoby, która nie stoi przy regale. Raport służy do oceny całej zmiany.

Podział na kanały ma konsekwencję projektową. Informacja pilna nie może trafić wyłącznie do raportu, a informacja o trendzie nie powinna przerywać pracy operatora. Reguły doboru kanału zapisuje się w konfiguracji systemu, a nie w procedurach szkolenia ustnego.

Dlaczego operator nie czyta długich komunikatów

Na hali pracownik ma zajęte ręce, więc nosi rękawice i patrzy na regał, a nie na ekran. Komunikat dłuższy niż jedno zdanie zostanie pominięty. Treść dzieli się więc na warstwy: krótki sygnał (kolor, dźwięk), jedno zdanie z przyczyną i jedno z instrukcją. Szczegóły techniczne trafiają do dziennika zdarzeń, który czyta administrator.

Komunikaty na ekranie i kody błędów

Dobry komunikat mówi, co się stało i dlaczego, a także co zrobić dalej. Kod błędu bez opisu nie spełnia żadnego z tych warunków, a opis bez instrukcji zostawia operatora bez wyjścia. Programista odpowiada za kod i poziom ważności, ale treść komunikatu powinna pochodzić ze słownika, który może poprawiać kierownik procesu.

Słownik komunikatów w bazie ma dwie zalety. Zmiana treści nie wymaga nowej wersji aplikacji, a każdy komunikat ma wersje językowe. Poniższy przykład w T-SQL pokazuje układ takiej tabeli. Nazwy i kody są przykładowe, a nie opisem schematu konkretnego produktu.

CREATE TABLE dbo.KomunikatSystemowy (
    Kod     varchar(20)   NOT NULL,
    Jezyk   char(2)       NOT NULL DEFAULT 'pl',
    Poziom  tinyint       NOT NULL,      -- 1 informacja, 2 ostrzezenie, 3 blad
    Tresc   nvarchar(200) NOT NULL,      -- co sie stalo
    Akcja   nvarchar(200) NULL,          -- co zrobic dalej
    CONSTRAINT PK_KomunikatSystemowy PRIMARY KEY (Kod, Jezyk)
);

INSERT INTO dbo.KomunikatSystemowy (Kod, Jezyk, Poziom, Tresc, Akcja) VALUES
 ('LOK_NIEZGODNA', 'pl', 3, N'Zeskanowano inną lokalizację niż wskazana.',
                             N'Zeskanuj etykietę na regale wskazanym na ekranie.'),
 ('TOWAR_NIEZGODNY', 'pl', 3, N'Towar nie zgadza się z zadaniem.',
                             N'Odczytaj indeks z etykiety i zeskanuj ponownie.'),
 ('PARTIA_BLOKADA', 'pl', 2, N'Partia jest zablokowana do decyzji działu jakości.',
                             N'Odłóż towar i powiadom kierownika zmiany.');

Kod błędu zgłasza procedura, a aplikacja na kolektorze pobiera treść według kodu i języka operatora. Procedura odpowiedzialna za skan zwraca więc tylko kod, na przykład LOK_NIEZGODNA. Dzięki temu logika biznesowa nie zawiera tekstów, a tłumaczenie interfejsu nie dotyka kodu.

Reguła: procedura zwraca kod komunikatu, a treść pochodzi ze słownika w wersji językowej operatora.

Kolor i dźwięk jako potwierdzenie skanu

Po skanie operator oczekuje odpowiedzi, zanim zdąży opuścić wzrok z etykiety. Zielone tło i krótki sygnał oznaczają poprawny odczyt. Czerwone tło i inny dźwięk oznaczają błąd. Ta sama para sygnałów musi obowiązywać w każdym module, bo inaczej pracownik uczy się interfejsu od nowa przy każdej zmianie ekranu.

Kolor nie może być jedynym nośnikiem informacji, ponieważ część osób nie odróżnia zieleni od czerwieni. Sygnał dźwiękowy oraz symbol razem ze słowem na ekranie tworzą redundancję, która działa także w hałasie i w słabym oświetleniu. Wybór urządzenia wpływa na jakość tej odpowiedzi, co opisuje tekst o programie magazynowym ze skanerem.

Alerty i powiadomienia poza stanowiskiem

Nie wszystkie zdarzenia dotyczą osoby, która akurat skanuje. Spadek zapasu poniżej minimum, brak wolnych miejsc w strefie albo zakończony spis kierują się do kierownika zmiany lub do planisty. System nie czeka wtedy, aż ktoś zajrzy do raportu. Wysyła wiadomość i sprawdza, czy została odebrana.

Architektura takiego mechanizmu opiera się na kolejce powiadomień w bazie danych. Zdarzenie dopisuje wiersz do tabeli, a osobne zadanie (na przykład w SQL Server Agent) odbiera nowe wiersze i wysyła je wybranym kanałem. Rozdzielenie zdarzenia od wysyłki chroni operację magazynową przed opóźnieniem, gdy serwer poczty nie odpowiada.

CREATE TABLE dbo.KolejkaPowiadomien (
    PowiadomienieId bigint        IDENTITY(1,1) PRIMARY KEY,
    Zdarzenie       varchar(30)   NOT NULL,
    Odbiorca        varchar(100)  NOT NULL,
    Kanal           char(4)       NOT NULL,      -- MAIL / SMS / PUSH
    Tresc           nvarchar(400) NOT NULL,
    Utworzono       datetime2(0)  NOT NULL DEFAULT SYSDATETIME(),
    Wyslano         datetime2(0)  NULL,
    Odczytano       datetime2(0)  NULL
);

CREATE INDEX IX_Kolejka_Nieodczytane
    ON dbo.KolejkaPowiadomien (Utworzono)
    INCLUDE (Zdarzenie, Odbiorca)
    WHERE Odczytano IS NULL;

DECLARE @MinutDoEskalacji int = 5;   -- parametr, nie stała w kodzie

SELECT PowiadomienieId, Zdarzenie, Odbiorca
FROM   dbo.KolejkaPowiadomien
WHERE  Kanal = 'PUSH'
  AND  Odczytano IS NULL
  AND  Utworzono < DATEADD(MINUTE, -@MinutDoEskalacji, SYSDATETIME());

Indeks filtrowany obejmuje tylko wiersze nieodczytane, więc pozostaje mały, choć tabela rośnie. Zapytanie na końcu wybiera powiadomienia bez potwierdzenia po zadanym czasie, które zadanie może przekazać wyżej, do przełożonego kierownika. Zasady definiowania takich indeksów opisuje dokumentacja Microsoft dotycząca instrukcji CREATE INDEX.

Zdarzenia, które wywołują alert

Lista zdarzeń jest krótka, bo każdy dodatkowy alert obniża uwagę odbiorcy. Najczęściej dotyczą one zapasu poniżej minimum, przekroczonego terminu realizacji zamówienia, błędu skanowania powtarzającego się na jednym stanowisku i braku miejsca w strefie składowania. Osobno traktuje się zakończenie procesu inwentaryzacji, które wymaga decyzji o zatwierdzeniu wyników.

Kanały wysyłki (e-mail i SMS) oraz zasady kolejkowania w innych systemach opisuje tekst o powiadomieniach w systemie ERP. Dla aplikacji na Androidzie powiadomienie ma odrębne parametry: priorytet i kanał, a także sposób wyświetlenia. Opisuje je dokumentacja platformy Android dotycząca powiadomień.

Ekran kolektora podczas pracy operatora

Dla większości pracowników program magazynowy jest ekranem kolektora, a nie komputera stacjonarnego. Na tym niewielkim ekranie odbywa się najintensywniejsza komunikacja, w rytmie wielu operacji na godzinę. Interfejs musi pozostać czytelny w rękawicach roboczych i przy słabym oświetleniu hali.

• Jedna czynność na ekranie - operator widzi lokalizację i ilość razem z numerem zlecenia, bez przewijania.
• Duże pola dotykowe - przyciski i pola wejściowe dostosowane do palca w rękawicy, a nie do rysika.

Podczas kompletacji ekran prowadzi operatora po kolejnych pozycjach listy pobrań. Po zeskanowaniu kodu system natychmiast potwierdza poprawność albo zgłasza błąd, a operator nie musi zapamiętywać kolejności. Ma to szczególne znaczenie przy dużej rotacji pracowników sezonowych, którzy nie znają jeszcze rozmieszczenia towaru. Sprzęt i aplikację na urządzeniach z Androidem opisują teksty o kolektorze danych z Androidem oraz o aplikacji magazynowej na Androida.

Odpowiedź systemu, gdy łączność zawodzi

Zasięg sieci bezprzewodowej w alejkach regałowych bywa nierówny. Aplikacja powinna jasno rozróżniać dwa stany: skan przyjęty przez serwer i skan czekający w kolejce na urządzeniu. Operator, który widzi tylko zielony ekran, nie wie, czy dane doszły. Wskaźnik stanu połączenia i licznik niewysłanych operacji zapobiegają założeniu, że wszystko zostało zapisane.

Widoki i uprawnienia dla różnych stanowisk

Nie każdy pracownik potrzebuje tych samych danych. Magazynier korzysta z listy zadań i mapy lokalizacji, natomiast administrator konfiguruje słowniki i uprawnienia. Rozdzielenie widoków zmniejsza liczbę pomyłek, bo operator nie przeklikuje się przez funkcje przeznaczone dla kogoś innego. Model ról opisuje tekst o rolach i użytkownikach w systemie WMS, a pierwszy kontakt z systemem, czyli logowanie, omawia tekst o logowaniu i autoryzacji.

W magazynach zatrudniających pracowników z różnych krajów przydaje się interfejs w kilku językach. Bariera językowa przestaje wtedy wpływać na tempo i poprawność operacji, a komunikaty pochodzą z tego samego słownika w wersjach językowych. Zakres opisuje tekst o wielojęzycznym programie magazynowym.

Raporty i pulpity dla kierownictwa

Poza obsługą bieżącą program komunikuje się z użytkownikiem w dłuższej perspektywie za pomocą raportów i pulpitów. Kierownik odczytuje na nich, czy proces przebiega zgodnie z planem, bez rozmowy z każdym operatorem. Ta sama informacja o niskim stanie zapasu jest prezentowana inaczej, zależnie od tego, kto ją czyta i jaką decyzję ma podjąć.

Raporty dla kierowników zmian dotyczą liczby zrealizowanych i zaległych zleceń oraz obciążenia stref. Dyrekcja przegląda średni czas realizacji zamówienia i liczbę reklamacji wynikających z błędów kompletacji. Raporty w serwerze SQL buduje się usługami raportowania, a wysyłkę cykliczną zapewniają subskrypcje, które omawia dokumentacja Microsoft dotycząca subskrypcji w Reporting Services.

Przykłady raportów RDL i wydruków opisuje tekst o narzędziu SQL Report Builder, a zestaw wskaźników procesu magazynowego zbiera tekst o raportowaniu w systemie WMS z wskaźnikami KPI.

Pulpit zmiany i odświeżanie w przeglądarce

Pulpit kierownika zmiany odświeża się bez przeładowania strony. Skrypt w przeglądarce odpytuje serwer o nowe alerty co kilka sekund i dopisuje je do listy. Poniższy fragment w jQuery pokazuje ten mechanizm. Interwał odpytywania jest parametrem przykładowym, a treść wstawia się jako tekst, aby zdarzenie nie mogło wstrzyknąć znaczników do strony.

var ostatniId = 0;

function pobierzAlerty() {
    $.getJSON('/api/alerty', { po: ostatniId })
        .done(function (lista) {
            lista.forEach(function (a) {
                $('<li>').addClass('alert alert--' + a.poziom)
                    .text(a.tresc)
                    .prependTo('#alerty');
                ostatniId = Math.max(ostatniId, a.id);
            });
        })
        .always(function () {
            setTimeout(pobierzAlerty, 10000);
        });
}

pobierzAlerty();

Odpytywanie z parametrem po zwraca tylko nowe wiersze, więc ruch sieciowy jest niewielki. Ponowne wywołanie ustawia się w bloku always, dzięki czemu przerwa w łączności nie zatrzymuje pulpitu na stałe.

Dziennik komunikatów i analiza powtarzających się błędów

Każdy komunikat błędu zapisany w dzienniku jest daną o jakości procesu. Jeśli ten sam kod pojawia się u jednego operatora, problem leży zwykle w szkoleniu. Jeśli pojawia się u wielu osób na tym samym stanowisku, przyczyną bywa nieczytelna etykieta, źle ustawiony skaner albo niejasny komunikat.

Poniższe zapytanie w T-SQL zestawia błędy z ostatnich siedmiu dni według stanowiska i kodu. Nazwy tabel są przykładowe. Warunek w klauzuli HAVING odcina pojedyncze zdarzenia, żeby lista pokazywała wzorce, a nie przypadki.

SELECT  s.StanowiskoKod,
        d.KodKomunikatu,
        COUNT(*)                     AS Wystapien,
        COUNT(DISTINCT d.OperatorId) AS Operatorow
FROM    dbo.DziennikKomunikatow AS d
JOIN    dbo.Stanowisko          AS s ON s.StanowiskoId = d.StanowiskoId
WHERE   d.Poziom = 3
  AND   d.Czas >= DATEADD(DAY, -7, SYSDATETIME())
GROUP BY s.StanowiskoKod, d.KodKomunikatu
HAVING  COUNT(*) >= 10
ORDER BY Wystapien DESC;

Kolumna z liczbą operatorów rozstrzyga diagnozę. Wartość bliska liczbie wystąpień oznacza błąd jednej osoby, a wartość wysoka przy wielu operatorach wskazuje na przyczynę po stronie stanowiska lub oznakowania. Wynik trafia do kierownika procesu przed kolejnym szkoleniem, a nie do archiwum.

Szkolenie operatora z komunikatów systemu

Nawet intuicyjny interfejs wymaga wprowadzenia nowego pracownika. Szkolenie obejmuje klawisze oraz znaczenie sygnałów i komunikatów, które operator zobaczy najczęściej. Przebieg wdrożenia operatora do samodzielnej pracy zapisuje poniższa tabela.

Zwykle pełne wdrożenie magazyniera do samodzielnej pracy zajmuje od kilku godzin do dwóch-trzech zmian, zależnie od złożoności procesów i wcześniejszego doświadczenia. Krótszy czas wynika najczęściej z prostego interfejsu, a nie ze skróconego programu szkolenia. Przygotowanie całego zespołu opisuje tekst o wdrożeniu systemu WMS i przygotowaniu zespołu.

Ogólny przegląd funkcji programu dostępny jest na stronie dotyczącej aplikacji magazynowej SoftwareStudio, a działanie komunikatów w praktyce można sprawdzić w wersji demonstracyjnej dostępnej w bloku pod artykułem.