V. Wymagania dla wsparcia projektu oraz nadzoru eksploatacyjnego... 6

Transkrypt

1 ZAŁĄCZNIK NR 5 Postępowania nr EU/12/ZI/ZZ/2011o udzielenie zamówienia w trybie przetargu nieograniczonego na: Opracowanie, wykonanie i wdrożenie SYSTEMU BOOKINGÓW DLA LINII ŻEGLUGOWYCH SPECYFIKACJA TECHNICZNA PRZEDMIOTU ZAMÓWIENIA Spis treści: I. Wymagania ogólne dla Systemu Bookingowego... 2 II.Cel projektu... 2 III.Wymagania projektu... 2 IV.Zakres funkcjonalności bookingowej w BCT. Minimalna specyfikacja Złożenie pełnych kontenerów Złożenie pustych kontenerów Podjęcie kontenerów pełnych Podjęcie kontenerów pustych Transakcje kolejowe... 5 V. Wymagania dla wsparcia projektu oraz nadzoru eksploatacyjnego

2 I. I. Wymagania ogólne dla Systemu Bookingowego Przedmiotem zamówienia jest implementacja systemu bookingowego obejmującego wprowadzenie w systemie zarządzania terminalem kontenerowym TOS dodatkowo procesu składania zleceń przeładunkowych w oparciu o bookingi Linii Żeglugowych. Zmianom ulegną procedury operacyjne, wprowadzona zostanie dodatkowa funkcjonalność obsługi bram terminala, system TOS w części operacyjnej i aplikacji internetowych dla klientów oraz wprowadzenie obsługi nowych komunikaty EDI COPARN i COREOR g. standardów UN/EDIFACT. II. Cel projektu Celem projektu jest odpowiedź na zapotrzebowanie Linii Żeglugowych dotyczące modyfikacji systemu TOS działającego w oparciu o bookingi żeglugowe. Obrót kontenerów i danych w systemie bookingowym pozwala na szybszy i bardziej sprawny obrót kontenerów i danych w terminalu kontenerowym. Obecny system BCT zorientowany w dużej części na przyjmowanie zleceń od spedytorów (logika tak zwanych numerów spedycji) - zostanie równolegle zachowany. III. Wymagania projektu 1. Analiza procesów przeładunkowych w terminalu i zaproponowanie zmian w funkcjonującym w BCT systemie TOS w części operacyjnej i dostępnej dla klientów zewnętrznych w tym Służb Celnych, Służb Państwowych, Przewoźników Lądowych, Spedytorów, Linii Żeglugowych oraz Agentów. 2. Przebudowa funkcjonalności aplikacji i reguł bramowych wg zaproponowanej koncepcji, przy zachowaniu obecnie funkcjonującej logiki zorientowanej na awizacji spedytorskiej i numerze wizyty. 3. Przebudowa aplikacji internetowej dla klientów terminala kontenerowego w tym modułu dostępowego dla Służb Celnych, Służb Państwowych, Spedytorów, Przewoźników Lądowych, Linii Żeglugowych oraz Agentów wg zaproponowanej koncepcji. 4. Przeprojektowanie i dodanie funkcjonalności do systemu TOS w części operacyjnej dla pracowników terminala kontenerowego wg zaproponowanej koncepcji. 5. Przeprojektowanie mechanizmów generowania transakcji bilingowych do systemów zewnętrznych. Stworzenie mechanizmu fakturowania transakcji blokingowych na podstawie kontraktów z Liniami Żeglugowymi oraz mechanizmu dystrybucji danych do systemu księgowego wykorzystywanego w BCT. 6. Wprowadzanie obsługi komunikatów EDI (UN/EDIFACT) związanych z logiką blokingu COREOR, COPARN. 7. Przygotowanie dokumentacji w języku polskim i angielskim. 2

3 8. Wsparcie projektu i nadzór eksploatacyjny Wsparcie użytkowników (Helpdesk) Okresowa aktualizacja systemu Utrzymywanie oprogramowania zgodnego z uaktualnieniami systemów operacyjnych. IV. Zakres funkcjonalności bookingowej w BCT. Minimalna specyfikacja 1. Złożenie pełnych kontenerów a) Przed przyjazdem samochodu z kontenerem do Terminalu, Linia Żeglugowa musi stworzyć Booking, zawierający następujące dane: numer kontenera, nazwę statku, numer podróży, porty załadunku, wyładunku i przeznaczenia, wagę, numery plomb, numer bookingu, nazwę Przewoźnika Lądowego lub Spedytora, numer spedycji, typ i rozmiar kontenera. Booking może zostać utworzony na dwa sposoby: W wyniku przetworzenia standardowego komunikatu EDI (Coprar). Linia może go utworzyć ręcznie, wpisując wszystkie niezbędne dane do TOS. b) Po utworzeniu Bookingu, jego numer przekazywany jest Przewoźnikowi Lądowemu / Spedytorowi, który z kolei przekazuje ten numer kierowcy. c) Po przyjeździe kierowcy na parking przed Terminalem, weryfikowane są dane zawarte w Bookingu, poprzez kontrolę w przenośnym RF przez pracownika BCT. d) Kierowca po weryfikacji udaje się na stanowisko kontrolne gdzie po rejestracji identyfikatora i podaniu numeru bookingu kończy weryfikacje. e) Pomyślne zakończenie weryfikacji skutkuje wydaniem zezwolenia na wjazd do BCT, po uprzedniej wymianie danych z systemem TOS. f) Na bramie ponownie weryfikowane są dane wcześniej wprowadzone do systemu. Pomyślne zakończenie weryfikacji umożliwia wjazd samochodu do Terminalu. g) Po złożeniu kontenera kierowca podjeżdża do bramy wyjazdowej w celu ostatniej weryfikacji danych wcześniej wprowadzonych do systemu. W przypadku pomyślnego zakończenia procesu, wizyta zostaje zakończona. 3

4 2.Złożenie pustych kontenerów Proces złożenia kontenerów pustych odbywa się analogicznie do złożeń kontenerów pełnych. 3.Podjęcie kontenerów pełnych a) Przed przyjazdem samochodu po kontener do Terminalu, Linia Żeglugowa musi stworzyć Booking, zawierający dane identyczne, jak w przypadku złożeń kontenerów. Proces tworzenia Bookingu jest również identyczny, jak w przypadku złożeń (za pomocą EDI, bądź ręcznie w TOS). b) Przed podjęciem kontenera przez Spedytora / Przewoźnika Lądowego, Linia Żeglugowa przypisuje mu poszczególne kontenery przekazując numery PIN wygenerowane po przetworzeniu standardowego komunikatu EDI (Coreor). Przypisanie kontenera do Spedytora / Przewoźnika Lądowego może odbyć się również w wyniku przetworzenia innego komunikatu EDI (Coparn), bądź ręcznie, bezpośrednio w TOS. Użycie pliku Coparn wymaga jednak ujednolicenia kodów klientów pomiędzy Linią, a Terminalem. c) Numer PIN przekazywany jest następnie kierowcy, który przyjedzie po konkretny kontener. W przypadku nie stosowania numerów PIN, kierowca na bramie musi podać numer wizyty. d) Po przyjeździe kierowcy na parking, weryfikowane są podstawowe dane, wraz z numerem PIN/numerem kontenera, dane osobowe kierowcy są weryfikowane za pomocą identyfikatora. e) Po pomyślnej weryfikacji, wydane będzie zezwolenie na wjazd, na podstawie którego kierowca wjedzie do Terminalu. Na zezwoleniu podane będzie miejsce na placu, na które kierowca ma się udać. f) Po załadowaniu kontenera na samochód, przy bramie wyjazdowej odbywa się kontrola stanu technicznego kontenera, weryfikacja plomb, oraz ponowne porównanie ww. danych z numerem PIN/numerem wizyty. g) Po pomyślnej weryfikacji samochód z kontenerem opuszcza Terminal. 4

5 4.Podjęcie kontenerów pustych a) Przed przyjazdem samochodu po kontener, Linia Żeglugowa powinna wprowadzić w systemie Booking następujące dane: numer kontenera, nazwę statku, numer podróży, porty załadunku, wyładunku i przeznaczenia, nazwę towaru, klasę IMO, wagę, numery plomb, numer bookingu, nazwę Spedytora / Przewoźnika Lądowego, numer spedycji, typ i rozmiar kontenera. Podobnie, jak powyżej Booking tworzony jest za pomocą EDI (Coprar), bądź ręcznie. W miejsce Bookingu może zostać utworzony numer EDO (Equipment Delivery Order, różniący się od Bookingu brakiem numeru statku/podróży i portu wyładunku. b) Numer Bookingu, bądź EDO przekazywany jest Spedytorowi / Przewoźnikowi Lądowemu, który udostępnia go kierowcy. Przypisanie kontenera do Spedytora odbywa się na podstawie przetworzenia pliku Coparn, bądź ręcznie. c) Kierowca po rejestracji identyfikatora i po podaniu numeru bookingu kończy weryfikację wstępną. d) Na parkingu weryfikowane są dane zawarte w Bookingu, bądź EDO. Poprawna weryfikacja skutkuje wydaniem zezwolenia na wjazd, do BCT. e) Po załadowaniu kontenera na samochód, przy bramie wyjazdowej odbywa się kontrola stanu technicznego kontenera, weryfikacja plomb oraz porównanie ww. danych z numerem Bookingu, lub EDO. f) Po pomyślnej weryfikacji samochód z kontenerem opuszcza Terminal. 5.Transakcje kolejowe Złożenie a) Przed przyjazdem wagonu z kontenerem do Terminalu, Linia Żeglugowa musi stworzyć Booking, zawierający następujące dane: numer kontenera, nazwę statku, numer podróży, porty załadunku, wyładunku i miejsce przeznaczenia, wagę, numery plomb, nazwę Spedycji / Przewoźnika Lądowego, numer spedycji, typ i rozmiar kontenera. Booking może zostać utworzony na dwa sposoby: W wyniku przetworzenia standardowego komunikatu EDI (Coprar). Linia może go utworzyć ręcznie, wpisując wszystkie niezbędne dane do TOS. b) Spedytor / Przewoźnik Lądowy po uzyskaniu Bookingu przypisuje go do utworzonego przez pracownika BCT pociągu 5

6 c) Po wtoczeniu pociągu na teren BCT ponownie weryfikowane są dane wcześniej wprowadzone do systemu. Pomyślne zakończenie weryfikacji umożliwia wprowadzenie do kolejek realizacji pociąg w systemie TOS. d) Po wykonaniu operacji przeładunkowych obsługa pociągu jest zakończona w systemie TOS. Podjęcie a) Przed wyładunkiem kontenera ze statku na Terminal, Linia Żeglugowa musi stworzyć Booking, zawierający dane identyczne, jak w przypadku złożeń kontenerów z wagonów, z dodaniem relacji w jakiej kontener ma wyjechać z Terminala. Proces tworzenia Bookingu jest również identyczny, jak w przypadku złożeń (za pomocą EDI, bądź ręcznie w TOS). b) Przypisanie kontenera do Spedytora / Przewoźnika Lądowego może odbyć się również w wyniku przetworzenia innego komunikatu EDI (Coparn), bądź ręcznie, bezpośrednio w TOS. Użycie pliku Coparn wymaga jednak ujednolicenia kodów klientów pomiędzy Linią, a Terminalem. c) Spedytor / Przewoźnik Lądowy przypisuje kontenery (lub Booking) do stworzonego przez pracowników BCT pociągu. d) Po pomyślnej weryfikacji, kontenery są przekazywane w systemie TOS do realizacji. e) Po załadowaniu kontenera na wagon, przy bramie wyjazdowej odbywa się rejestracja stanu technicznego kontenera, weryfikacja plomb oraz ponowne porównanie danych. f) Po pomyślnej weryfikacji wagony z kontenerami opuszczają Terminal V. Wymagania dla wsparcia projektu oraz nadzoru eksploatacyjnego 1. Wykonawca jest zobowiązany do świadczenia na rzecz Zamawiającego (w ramach wynagrodzenia za przedmiot umowy) w okresie min 12 miesięcy wsparcia technicznego systemu oraz nadzoru eksploatacyjnego, który polegać będzie na: usuwaniu awarii oprogramowania uniemożliwiającej eksploatację systemu w max. czasie 48 godzin od jej zgłoszenia przez 365 dni w roku i 24 godziny na dobę, udzielaniu odpowiedzi na pytania w sprawie działania oprogramowania telefonicznie, przez WWW lub pocztę elektroniczną w max. czasie 48 godz. przez 365 dni w roku i 24 godziny na dobę, dostarczanie materiałów opisowych i technicznych dotyczących systemu 6

7 nieodpłatne dostosowanie oprogramowania do zmian w przepisach prawnych, wprowadzonych po zainstalowaniu oprogramowania i dotyczących obszaru zastosowania oprogramowania, uzyskanie nowych wersji oprogramowania w ramach corocznej opłaty serwisowej wraz z niezbędną dokumentacją, rozumianych jako dostęp do produktu, zgodnie z kolejnymi edycjami. 7