YMS24 - producent, technologia i sposób pracy

Autor: Adam Siemiątkowski, SoftwareStudio Group Sp. z o.o.

Produkt, nie osobne wdrożenie

Oprogramowanie dla logistyki bywa budowane na dwa sposoby. Pierwszy polega na pisaniu od nowa dla każdego klienta, drugi na rozwijaniu jednego produktu z konfiguracją dopasowaną do obiektu. YMS24 powstaje w tym drugim układzie i wynikają z tego konkretne konsekwencje.

Poprawka wprowadzona raz trafia do wszystkich instalacji, a nie wyłącznie tam, gdzie problem zgłoszono. Funkcja zamówiona przez jednego odbiorcę staje się dostępna dla pozostałych. W zamian zakres zmian możliwych do wykonania bez naruszenia pozostałych wdrożeń jest węższy niż przy rozwiązaniu pisanym na zamówienie.

Granica przebiega przy konfiguracji. Długości okien, rodzaje transportu, role i uprawnienia, szablony powiadomień oraz układ wydruków ustawia się per obiekt. Logika procesu pozostaje wspólna, bo to ona podlega poprawkom i testom.

st.programdemo.pl/DefaultLeftMenu.aspx

Środowisko demonstracyjne: te same funkcje co w instalacjach produkcyjnych

Na czym system pracuje

Aplikacja działa w przeglądarce, na serwerze aplikacji z bazą SQL Server. Po stronie stanowisk nie ma czego instalować, więc komputer na bramie może być dowolnym urządzeniem z dostępem do sieci.

Umieszczenie reguł zasobów w bazie, a nie w warstwie interfejsu, jest decyzją projektową o praktycznych skutkach. Kontrola dostępności okna czasowego działa wtedy również dla zgłoszeń przychodzących z importu i z wymiany danych, a nie wyłącznie dla formularza. Mechanizm ten opisuje strona o kalendarzu rezerwacji wobec arkusza.

Środowisko demonstracyjne

Publicznie dostępna instalacja pokazuje te same funkcje, które pracują w obiektach produkcyjnych, z danymi przykładowymi. Służy dwóm celom: pozwala ocenić rozwiązanie przed rozmową o wdrożeniu oraz stanowi materiał odniesienia przy szkoleniu.

Zrzuty ekranu w tym serwisie pochodzą właśnie z tego środowiska. Nie zawierają danych rzeczywistych kontrahentów ani przewoźników, bo informacje o wdrożeniach objęte są zobowiązaniem do poufności. Sam zakres funkcji widać natomiast w całości - dostęp do wersji demonstracyjnej opisuje strona demo.

Ocena systemu na podstawie prezentacji prowadzonej przez dostawcę jest niepełna, bo przechodzi ścieżką, która działa. Wartość diagnostyczną mają odstępstwa: rezerwacja zajętego terminu, zmiana numeru pojazdu w zatwierdzonym zgłoszeniu, wjazd poza harmonogramem.

Jak powstają zmiany

Kierunek rozwoju wyznaczają zgłoszenia z wdrożeń, bo to one opisują sytuacje, których nie da się przewidzieć przy projektowaniu. Zmiana przechodzi przez środowisko demonstracyjne, zanim trafi do instalacji produkcyjnych.

• Zgłoszenie z wdrożenia - opis sytuacji, której obecny zakres nie obsługuje.
• Sprawdzenie na środowisku - czy zmiana nie narusza pozostałych obszarów.
• Wydanie wersji - z opisem zmian i możliwością wycofania.
• Aktualizacja instalacji - w oknie serwisowym uzgodnionym z obiektem.

Czwarty punkt nie jest automatyczny. Obiekt pracujący w ruchu ciągłym wymaga przygotowania trybu zastępczego na bramie, więc termin ustala się osobno. Tryby wprowadzania zmian opisuje strona o wersjach i aktualizacjach.

Co obejmuje rozwiązanie

Zakres układa się w dwie warstwy. Ewidencyjna prowadzi rejestr wizyt pojazdów wraz ze znacznikami czasu i autorem każdej zmiany. Planistyczna obsługuje siatki okien czasowych, limity zasobów i powiadomienia.

Do tego dochodzą moduły placowe dla obiektów z parkingiem buforowym i ruchem wewnętrznym oraz warstwa sprawozdawcza z zestawieniami i wydrukami. Wdrożenie może objąć samą ewidencję albo komplet, zależnie od tego, o które zasoby ktoś realnie się spiera. Podział ten opisuje strona o ewidencji wizyt pojazdów, a moduły placu - materiał o programie klasy Yard Management System.

Podejście do danych klientów

Rejestr wizyt zawiera dane osób fizycznych: kierowców i osób kontaktowych u kontrahentów. Zakres zbieranych informacji ustala się przy wdrożeniu, tak by ograniczał się do potrzebnego przy kontroli wjazdu, a okres przechowywania wynikał z ustalonej retencji.

Kopie danych produkcyjnych przenoszone na środowiska pomocnicze podlegają tym samym zasadom albo przechodzą anonimizację przed skopiowaniem. Obowiązki w tym zakresie porządkuje strona o awizacji a przepisach o ochronie danych, a decyzję o miejscu instalacji - materiał o chmurze i instalacji lokalnej.

Zakres kompetencji zespołu

Budowa systemu obsługującego ruch pojazdów wymaga wiedzy z dwóch obszarów, które rzadko występują razem. Pierwszy to wytwarzanie oprogramowania: baza danych, warstwa aplikacji, interfejs. Drugi to procesy logistyczne, bez których powstaje narzędzie poprawne technicznie i nieprzydatne przy rampie.

Drugi obszar buduje się na kontakcie z obiektami, a nie na literaturze. Wiedza o tym, że kierowca obsługuje ekran w rękawicach, że tablica zagraniczna wymaga dopasowania częściowego i że rampa zwalnia się z opóźnieniem, pochodzi z wdrożeń i wraca do produktu jako zmiana w kodzie.

Poza wytwarzaniem zespół prowadzi także wdrożenia: analizę przedwdrożeniową, konfigurację, szkolenia i wsparcie po uruchomieniu. Zakres tych czynności opisuje strona o wsparciu po uruchomieniu.

Jak wygląda współpraca przy projekcie

Projekt zaczyna się od rozmowy o procesie, nie o funkcjach. Pytania dotyczą liczby transportów, rozkładu przyjazdów w godzinach, liczby stanowisk i tego, gdzie obecnie powstaje kolejka. Odpowiedzi wyznaczają zakres bardziej niż lista życzeń.

Etap następny to analiza z pomiarem. Dwa tygodnie obserwacji na bramie dają rozkład czasów obsługi, bez którego siatka okien powstaje z deklaracji. Na tej podstawie ustala się zakres pierwszego etapu i parametry startowe.

Ostatni wiersz bywa niedoceniany i decyduje o powodzeniu. Przewoźnicy dowiadujący się o zmianie od dostawcy oprogramowania reagują inaczej niż ci, którzy dostali informację od swojego odbiorcy. Przebieg takiego projektu opisuje strona o wdrożeniu oprogramowania do awizowania dostaw.