Wdrożenie YMS Studio VSS.net trwa zwykle od 4 do 8 tygodni i obejmuje pięć etapów: analizę placu, konfigurację, integracje, testy i szkolenia. System działa w chmurze SoftwareStudio albo na serwerze klienta, a projekt zamyka start produkcyjny z asystą powdrożeniową.
Projekt wdrożenia YMS (Yard Management System) obejmuje cały plac, a nie tylko kalendarz rezerwacji: bramę, parking, rampy i wyjazd. Każdy z tych punktów ma w systemie własny status z godziną i autorem, dlatego przed konfiguracją trzeba ustalić, którędy biegnie ścieżka pojazdu i kto zmienia status na kolejnym etapie. Pełny zakres systemu opisuje strona o systemie YMS, a podział zadań między tymi systemami pokazuje zestawienie YMS, WMS, TMS i DMS.
Harmonogram poniżej pochodzi z projektów wdrożeniowych Studio VSS.net. Czas zależy od liczby bram i integracji oraz od gotowości danych po stronie klienta, a wiążące terminy podaje oferta po analizie przedwdrożeniowej. Zakres funkcji, które wchodzą do projektu, zestawia strona o funkcjonalnościach programu awizacyjnego, a pracę codzienną w systemie opisuje strona o programie do awizacji dostaw.
Analiza placu i procesów przed konfiguracją
Pierwszy etap trwa od 3 do 5 dni i kończy się mapą obiektu: ile jest bram, którędy jedzie pojazd od wjazdu do rampy i które punkty wymagają identyfikacji. Analizę prowadzi się razem z kierownikiem magazynu i ochroną, ponieważ każda z tych grup zmienia inne statusy. Wynik trafia do kartotek jako opis obiektów wraz z bramami i rampami.
| Obszar | Pytanie analizy | Wynik w systemie |
|---|---|---|
| Bramy i wjazdy | Ile jest punktów wjazdowych i czy przy bramie stoi kamera LPR lub kiosk | Rekordy bram w kartotekach i zakres modułu Brama |
| Rampy i strefy | Ile jest doków i gdzie stoi parking buforowy | Kalendarze z limitami ramp oraz strefy placu |
| Rodzaje transportu | Które pojazdy i ładunki wymagają osobnych zasad obsługi | Skorowidz rodzajów transportu i osobne kalendarze |
| Role użytkowników | Kto zakłada i zatwierdza awizację oraz kto obsługuje rampę | Role programowe z zakresem widoku i uprawnień |
| Systemy zewnętrzne | Skąd przychodzą zamówienia i dokąd wracają dokumenty przyjęć | Zakres wymiany danych przez REST API |
Z analizy wynika lista wymagań technicznych oraz zakres modułów. Obiekt z kilkoma magazynami albo bramami dostaje osobne kalendarze i uprawnienia, a przydział doków według rodzaju towaru opisuje strona o zarządzaniu dokami. Operator centrum logistycznego obsługujący wielu klientów ustawia dla kontrahentów indywidualne okna i wymagane dokumenty, co pokazuje strona o awizacji dostaw do centrum logistycznego.
Role użytkowników ustala się już w analizie, bo od nich zależy widok każdej osoby. Przewoźnik widzi tylko własne transporty, a ochrona listę pojazdów do odprawy; zasady nadawania uprawnień opisują role programowe.
Wybór modelu wdrożenia i hostingu
Studio VSS.net działa jako aplikacja webowa na dwóch platformach. Generacja ST pracuje na SQL Server i Windows Server, a pakiet awizacji MAW na platformie GT korzysta z .NET 10 i PostgreSQL 18 na Linuksie w kontenerach Docker. Obraz aplikacji jest ten sam niezależnie od miejsca uruchomienia, więc wybór dotyczy przede wszystkim tego, kto utrzymuje serwer.
| Model | Gdzie działa system | Co należy do klienta | Kiedy się sprawdza |
|---|---|---|---|
| Chmura SoftwareStudio | Serwery SoftwareStudio | Przeglądarki i konta użytkowników | Projekt ma ruszyć bez własnej infrastruktury |
| Serwer klienta | Maszyna wskazana przez klienta: Windows Server dla platformy ST, Linux z Dockerem dla GT | Utrzymanie serwera wraz z kopiami danych i dostępem administracyjnym | Polityka IT wymaga danych w sieci firmowej |
Chmura SoftwareStudio zdejmuje z klienta utrzymanie serwera, a instalacja lokalna zostawia dane i administrację w sieci firmowej. Różnice między tymi modelami w systemach magazynowych opisuje artykuł o skalowalnych systemach magazynowych w chmurze, a kryteria porównania ofert przewodnik jak wybrać system awizacji. Koszty obu modeli zestawia strona o kosztach systemu awizacji.
Niezależnie od modelu system przetwarza dane osobowe kierowców i pracowników przewoźników, więc umowa z dostawcą musi spełniać wymagania rozporządzenia 2016/679 (RODO): powierzenie przetwarzania oraz miejsce i czas przechowywania rejestrów wizyt. Dane przetwarza się w Europejskim Obszarze Gospodarczym, a zasady dla kierowców opisuje strona awizacja dostaw a RODO. Parametry usługi, w tym dostępność miesięczna i czasy reakcji, zawiera strona o wymaganiach technicznych systemu awizacji.
Reguły okien, brama i kolejka na placu
Reguły rezerwacji konfiguruje się w drugim etapie projektu. Przewoźnik wybiera wolne okno w portalu, a system blokuje podwójną rezerwację tej samej rampy w tym samym przedziale. Długość okna wynika z liczby palet w awizacji i z rodzaju pojazdu; zasady rezerwacji opisuje strona o oknach czasowych, a sposób liczenia długości okna artykuł o algorytmach długości okna czasowego. Definiowanie harmonogramów i rezerwacji opisuje artykuł o definiowaniu harmonogramów i rezerwacji.
Na bramie kierowca potwierdza przybycie kodem QR albo w kiosku samoobsługowym, a kamera LPR może rozpoznać pojazd po tablicy rejestracyjnej. Kamery BCS, Bosch, Dahua i Hikvision są wspierane natywnie, natomiast dostawa i montaż kamer oraz szlabanów pozostają po stronie klienta. Ustawienia bramy i odprawy opisuje strona o kontroli wjazdów i wyjazdów pojazdów.

Kalendarze awizacji - widok kafelkowy typów i obiektów
Ekran startowy sekcji kalendarzy w Studio VSS.net pokazuje trzy kategorie widoków. Sekcja Kalendarze ogólne zawiera kafelki Kalendarz ogólny i Zajętość ramp. Dwie pozostałe sekcje grupują kalendarze według obiektów i według magazynów kontrahenta demonstracyjnego. Kafelki prowadzą od razu do wybranego kontekstu planowania dostaw.
Kolejkę na placu wyznaczają statusy z godziną: oczekiwanie pod bramą system liczy od statusu 20 do 40, a obsługę przy rampie od 50 do 60. Dyspozytor przesuwa rezerwacje w aplikacji kalendarza awizacji, a pełną tabelę kodów zawiera strona o statusach w programie awizacyjnym. Godziny ze statusów zasilają raport KPI, w którym widać czas obsługi według rampy i kontrahenta. Mechanizm kolejki opisuje także artykuł o likwidowaniu kolejek przed magazynem.

KPI awizacji - raport transportów i obciążenia ramp
Ekran KPI awizacji w Studio VSS.net pokazuje raport w formie podglądu dokumentu (strona 1 z 2). Układ harmonogramowy grupuje transporty według godzin, a każdy blok zawiera dane kontrahenta demonstracyjnego, numer rejestracyjny pojazdu, kierowcę, numer Load Plan i asortyment. Kolor bloku oznacza stan realizacji, na przykład czerwony opóźnienie, a zielony transport zrealizowany. Raport można wydrukować albo zapisać jako plik PDF z paska narzędzi.
Integracje z ERP i WMS
Integracje realizuje się przez REST API, a w prostszych przypadkach przez import plików. Integracje z SAP i SAP EWM oraz z Symfonia ERP są wykonane, a Comarch ERP XL ma status deklarowanej; dla pozostałych systemów wymianę danych buduje projekt integracyjny przez REST API. Szczegóły zestawia strona o integracjach ze Studio VSS.net.
| Kierunek wymiany | Dane | Moment |
|---|---|---|
| ERP do Studio VSS.net | Kontrahenci i zamówienia z danymi do awizacji | Przy zakładaniu lub imporcie awizacji |
| Studio VSS.net do WMS | Zapowiedź przyjęcia z zawartością dostawy | Po potwierdzeniu awizacji |
| WMS do Studio VSS.net | Zamknięcie dokumentu przyjęcia | Po zakończeniu rozładunku |
| Studio VSS.net do ERP | Statusy i godziny wizyty pojazdu | Po zmianie statusu |
Zakres pól i częstotliwość wymiany ustala analiza, a przed startem produkcyjnym komplet scenariuszy przechodzi test na środowisku testowym. Połączenie z magazynem opisuje strona jak VSS łączy się z WMS i ERP, a ogólne zasady łączenia systemów artykuł integracja magazynu z systemem ERP. Z perspektywy WMS przebieg przyjęcia przedstawia strona o awizowaniu transportów po stronie WMS.
Komunikaty do przewoźników i kierowców idą e-mailem i SMS-em, a o zmianie rampy lub statusu informuje wiadomość w języku wybranym w awizacji. Zakres powiadomień opisuje strona o wiadomościach e-mail i SMS z poziomu programu.
Wdrożenie Studio VSS.net YMS etapami
Typowe wdrożenie systemu awizacji i YMS zamykamy w 4-8 tygodniach. Tabela pokazuje etapy z czasem trwania oraz tym, czego potrzebujemy od klienta w każdym z nich. Praktyczną listę przygotowań po podpisaniu umowy zawiera materiał o tym, jak przygotować magazyn do wdrożenia.
| Etap | Zakres prac | Po stronie klienta | Czas |
|---|---|---|---|
| 1. Analiza przedwdrożeniowa | Mapa obiektu i ról oraz ustalenie reguł okien czasowych | Plan obiektu i kontakt do ochrony oraz logistyki | 3-5 dni |
| 2. Konfiguracja | Kalendarze, okna czasowe, uprawnienia i szablony przepustek | Decyzje o regułach i lista użytkowników | 1-2 tygodnie |
| 3. Integracje | Wymiana danych z ERP lub WMS przez REST API albo plik | Dokumentacja interfejsu i opiekun systemu | 1-2 tygodnie |
| 4. Testy | Procesy awizacji i bramy oraz raporty na danych klienta | Akceptacja scenariuszy testowych | 3-5 dni |
| 5. Szkolenia | Szkolenia dla logistyki i ochrony oraz osobne szkolenie administratora | Udział użytkowników zgodnie z rolą | 2-3 dni |
| 6. Start i asysta | Uruchomienie produkcyjne i nadzór powdrożeniowy | Punkt kontaktowy po stronie obiektu | Start, potem asysta |

Kalendarze w kartotekach - kody i uprawnienia
Ekran przedstawia zestawienie kalendarzy w sekcji Kartoteki. Tabela ma kolumny Aktywne, Kod, Nazwa kalendarza i Domyślny sposób prezentacji danych oraz flagi uprawnień do dodawania i usuwania wydarzeń. Każdy kalendarz jest osobną konfiguracją: określa źródło danych, sposób filtrowania, widok domyślny i uprawnienia ról.
Wymagania infrastrukturalne
Wymagania zależą od platformy i modelu hostingu. W chmurze SoftwareStudio klient potrzebuje wyłącznie przeglądarek i dostępu do sieci, a na serwerze klienta obowiązuje zestaw z tabeli.
| Element | Wymaganie | Uwagi |
|---|---|---|
| System operacyjny | ST: Windows Server. GT: Linux z kontenerami Docker | Dotyczy instalacji na serwerze klienta; w chmurze SoftwareStudio utrzymuje go dostawca |
| Baza danych | ST: SQL Server. GT: PostgreSQL 18 | Platforma GT nie wymaga licencji Microsoft |
| Stanowiska użytkowników | Przeglądarka internetowa | Bez instalacji oprogramowania na komputerach |
| Połączenie z Internetem | Dostęp dla portalu przewoźnika i wiadomości SMS lub e-mail | Przewoźnicy rezerwują okna z własnych komputerów |
- Kamery LPR i kontroler szlabanu są opcjonalne i po stronie klienta, a oprogramowanie obsługuje je natywnie.
- Terminale z Androidem do aplikacji mobilnej dla ochrony i kierowców zapewnia klient.
- Logowanie przez Active Directory lub Entra ID jest dostępne w pakietach i wymaga uzgodnienia z działem IT.
- Kopie danych i replikację opisuje strona o wymaganiach technicznych systemu awizacji.
Co najczęściej opóźnia projekt wdrożenia
Większość opóźnień wynika z danych i decyzji po stronie obiektu, a nie z konfiguracji systemu. Tabela zbiera pięć sytuacji, które powtarzają się w projektach, wraz ze sposobem ich ograniczenia.
| Ryzyko w projekcie | Skutek | Jak je ograniczyć |
|---|---|---|
| Brak dokumentacji interfejsu ERP lub WMS | Etap integracji trwa dłużej niż 2 tygodnie | Przekazać dokumentację i wskazać opiekuna systemu już na etapie analizy |
| Niepełna lista kontrahentów | Część przewoźników nie ma konta na starcie | Zaimportować kartotekę z ERP, a brakujące firmy dodać ręcznie w pierwszych dniach |
| Zbyt krótkie okna czasowe | Rezerwacje nachodzą na siebie przy rampie | Zacząć od dłuższych okien i skracać je po zebraniu godzin ze statusów |
| Sprzęt bramowy nie jest gotowy | Test bramy i LPR przesuwa się na później | Zamówić kamery i szlabany równolegle z konfiguracją |
| Brak jednego decydenta po stronie klienta | Testy przeciągają się przez poprawki bez akceptacji | Wyznaczyć osobę akceptującą scenariusze i zakres |
Po starcie produkcyjnym zespół wdrożeniowy prowadzi asystę, a zmiany reguł, takie jak korekta długości okna na jednej rampie, wprowadza administrator i zapisują się one w historii z datą i autorem. Dokumenty potrzebne przed uruchomieniem zestawia strona wzory dokumentów awizacji.