Większość zgłoszeń po wdrożeniu nie dotyczy błędów, tylko zmian w procesie. Nowa rampa, inne godziny pracy, kolejny przewoźnik - obsługa tych spraw decyduje o tym, czy system nadąża za organizacją, czy zaczyna ją ograniczać.
Co trafia do wsparcia
Strumień zgłoszeń po uruchomieniu ma przewidywalny skład i warto go rozdzielić, bo każdy rodzaj wymaga innego trybu obsługi i innego czasu reakcji.
| Rodzaj | Przykład | Oczekiwana reakcja |
|---|---|---|
| Zatrzymanie pracy | Brak dostępu do aplikacji, zatrzymana brama | Natychmiastowa, poza godzinami też |
| Utrudnienie | Nie działa wydruk przepustki, wolne zestawienie | W godzinach pracy, tego samego dnia |
| Zmiana konfiguracji | Nowa rampa, inne godziny obiektu | Uzgodniony termin, zwykle kilka dni |
| Rozwój zakresu | Nowy raport, kolejna integracja | Planowane, z wyceną i harmonogramem |
Rozdzielenie dwóch pierwszych wierszy od dwóch pozostałych ma znaczenie praktyczne. Zgłoszenie zmiany konfiguracji obsługiwane w trybie awaryjnym odbiera czas od spraw rzeczywiście pilnych, a zgłoszenie awarii obsługiwane w trybie planowym oznacza zatrzymany ruch.
Pierwsze tygodnie po uruchomieniu
Natężenie zgłoszeń jest wtedy najwyższe i ma inny skład niż później. Przeważają pytania o obsługę, nie usterki: gdzie znaleźć zestawienie, jak cofnąć błędny status, co zrobić z pojazdem, który przyjechał dzień wcześniej.
Większość z nich powtarza się, więc opłaca się je zbierać i po miesiącu przerobić na krótką instrukcję dla danej roli. Operator na bramie potrzebuje opisu czterech czynności, a nie podręcznika obejmującego całą aplikację.
Drugą grupą są wnioski o zmianę parametrów, zgłaszane po pierwszych dniach pracy na siatce okien. Warto je przyjmować, ale wprowadzać po jednej zmianie naraz, bo równoczesne skrócenie okna i podniesienie limitu daje wynik, którego nie da się przypisać do żadnej z decyzji.
Zgłoszenie opisane słowami „system nie działa" kosztuje dwa dodatkowe pytania, zanim ktokolwiek zacznie je rozwiązywać. Numer zgłoszenia awizacyjnego, godzina zdarzenia i nazwa użytkownika skracają czas reakcji bardziej niż jakakolwiek umowa.
Zmiany konfiguracji wymuszone przez proces
Organizacja zmienia się szybciej niż oprogramowanie i to jest stan normalny. Dochodzi rampa, magazyn przechodzi na dwie zmiany, pojawia się nowy asortyment o innym czasie rozładunku. Każde z tych zdarzeń wymaga korekty ustawień.
- Zmiana godzin pracy obiektu - przelicza siatkę na przyszłość, bez ruszania potwierdzonych rezerwacji.
- Nowy rodzaj transportu - dopisanie pozycji w skorowidzu wraz z długością okna.
- Dodanie rampy albo bramy - zmiana strukturalna, sprawdzana najpierw poza produkcją.
- Korekta limitów - po zmianie obsady albo pojemności strefy przyjęć.
Trzecia pozycja jest jedyną w tym zestawie, która wymaga ostrożności. Pozostałe da się wprowadzić w trakcie pracy, o ile zapisze się poprzednią wartość parametru. Tryby wprowadzania zmian opisuje strona o wersjach i aktualizacjach systemu.
Przegląd cykliczny
Poza reakcją na zgłoszenia sensowny jest przegląd wykonywany z własnej inicjatywy, raz na kwartał. Obejmuje cztery rzeczy, z których żadna nie zgłosi się sama.
Pierwsza to konta bez aktywności, zwykle po osobach, które zmieniły stanowisko albo odeszły z firmy. Druga to duplikaty w kartotekach przewoźników, łatwiejsze do scalenia zanim przypnie się do nich historia. Trzecia to parametry siatki porównane z rzeczywistym rozkładem czasów obsługi. Czwarta to rozmiar rejestru i czas wykonania raportów okresowych.
Ostatni punkt prowadzi zwykle do decyzji o archiwizacji zamkniętych wizyt, gdy tabela urosła na tyle, że zestawienia zwalniają. Zakres tych czynności opisuje strona o architekturze oprogramowania YMS.
Rozwój zakresu wraz z organizacją
Najczęstszym kierunkiem rozszerzenia jest kolejny obiekt. Przebiega szybciej niż pierwsze wdrożenie, bo słowniki i zasady są już ustalone, ale parametry siatki trzeba wyznaczyć z pomiaru w nowym miejscu, a nie skopiować.
Drugim kierunkiem jest portal dla firm zewnętrznych, uruchamiany zwykle po ustabilizowaniu harmonogramu. Trzecim integracje z systemem handlowym, wchodzące po pierwszym pełnym kwartale pracy. Czwartym raporty analityczne, budowane wtedy, gdy rejestr zawiera już dane z reprezentatywnego okresu.
Kolejność ta nie jest przypadkowa: każdy etap korzysta z danych zebranych w poprzednim. Odwrócenie jej prowadzi do konfiguracji opartej na założeniach, którą potem trzeba przerabiać. Przebieg pierwszego projektu opisuje strona o wdrożeniu oprogramowania do awizowania dostaw, a kryteria doboru zakresu - materiał o programie YMS.
Utrzymanie wiedzy po stronie klienta
Konfiguracja znana jednej osobie jest ryzykiem niezależnym od jakości wsparcia. Przy zmianie na stanowisku administratora trzeba ją odtwarzać przez oglądanie ustawień, co zajmuje więcej czasu niż spisanie na bieżąco.
Zakres, który realnie się przydaje, obejmuje zapis decyzji parametrycznych wraz z uzasadnieniem oraz instrukcje dla poszczególnych ról. Uzasadnienie jest przy tym ważniejsze niż wartość: parametr bez powodu zostaje zmieniony przy pierwszej okazji przez osobę, która nie wie, że wynikał z pomiaru. Sposób prowadzenia dokumentacji opisuje strona o cyklu życia wdrożenia, a zakres pracy na bramie - materiał o stanowisku ochrony.
Szkolenie prowadzone rolami
Szkolenie obejmujące całą aplikację dla wszystkich użytkowników jest najczęstszym marnotrawstwem przy wdrożeniu. Operator na bramie wykonuje cztery czynności i nie potrzebuje wiedzy o kartotekach ani raportach, a nadmiar materiału sprawia, że nie zapamiętuje tego, co faktycznie robi.
Podział na role skraca szkolenie kilkukrotnie i podnosi jego skuteczność. Ochrona uczy się obsługi wjazdu, rejestracji pojazdu bez zgłoszenia i wydania przepustki. Magazyn przypisania rampy, zmiany statusu i zamknięcia obsługi. Dyspozytura pełnego obiegu zgłoszenia wraz z decyzjami wyjątkowymi.
Formą, która działa lepiej niż prezentacja, jest praca na środowisku demonstracyjnym z danymi przykładowymi. Uczestnik wykonuje czynność samodzielnie, a błędny wpis nie trafia do rejestru produkcyjnego, z którego trzeba by go potem usuwać.
Drugie szkolenie, po miesiącu pracy, przynosi zwykle więcej niż pierwsze. Pytania są wtedy konkretne, bo wynikają z sytuacji, które faktycznie wystąpiły, a nie z wyobrażeń o tym, co może się zdarzyć.
Wsparcie techniczne a procesowe
Zgłoszenia dzielą się na dwie kategorie obsługiwane przez różne kompetencje. Pierwsza dotyczy działania oprogramowania: błąd przy zapisie, wolne zestawienie, brak dostępu. Druga dotyczy procesu: jak ustawić siatkę dla nowego asortymentu, co zrobić z przewoźnikiem, który nie dotrzymuje terminów.
Mieszanie ich w jednym kanale powoduje, że pytania procesowe czekają w kolejce za technicznymi albo odwrotnie. Rozdzielenie nie wymaga osobnych umów, wystarczy oznaczanie zgłoszeń przy przyjęciu i kierowanie ich do właściwej osoby.
Po stronie klienta odpowiednikiem tego podziału są dwie role: administrator odpowiadający za konta i konfigurację techniczną oraz osoba odpowiadająca za parametry procesu, zwykle kierownik magazynu. Obie powinny być wskazane imiennie, bo zgłoszenie bez właściciela po stronie zamawiającego wraca po tygodniu w tej samej postaci.
Zmiana infrastruktury
Przeniesienie instalacji na nowy serwer albo zmiana modelu z lokalnego na usługowy zdarza się raz na kilka lat i wymaga przygotowania proporcjonalnego do skutków błędu.
Kolejność, która się sprawdza, zaczyna się od uruchomienia kopii w nowym miejscu i sprawdzenia jej działania przy wyłączonym ruchu produkcyjnym. Potem następuje przeniesienie danych z okresu między kopią a przełączeniem, wykonywane w oknie serwisowym. Na końcu przełączenie adresu i obserwacja przez pierwszą dobę.
Elementem, o którym najłatwiej zapomnieć, są integracje. Wymiana danych z systemem handlowym odwołuje się do adresu, który po migracji się zmienia, więc konfiguracja po drugiej stronie wymaga korekty w tym samym oknie. Kryteria wyboru miejsca instalacji zbiera strona o chmurze i instalacji lokalnej.