ZAŁĄCZNIK NR 2 OPIS PRZEDMIOTU ZAMÓWIENIA DOTYCZĄCY ZAKUPU I WDROŻENIA SYSTEMU WSPIERAJĄCEGO ROZLICZENIA MIEDZYNARODOWE(SWRM) 1. PRZEDMIOT ZAMÓWIENIA Przedmiotem zamówienia jest dostarczenie i wdrożenie systemu informatycznego do obsługi rozliczeń międzynarodowych (w dalszej części dokumentu zwany Systemem ), udzielenie licencji na korzystanie z tego Systemu oraz świadczenie usług serwisowych w zakresie tego Systemu. 1. Przygotowanie koncepcji rozwiązania zgodnie z ogólnymi wymaganiami Zamawiającego (opis funkcjonalny) oraz projektu technicznego (opis techniczny) Systemu, podlegających ostatecznemu zatwierdzeniu przez Zamawiającego. Ogólne wymagania w zakresie Systemu opisane są w dalszej części niniejszego dokumentu. 2. Prace deweloperskie (wykonanie), utrzymanie i rozwój Systemu. 3. Instalacja i uruchomienie Systemu w środowisku informatycznym Zamawiającego. 4. Przeprowadzenie szkoleń z obsługi Systemu dla administratorów i użytkowników. Wymagania w zakresie szkoleń opisane są w dalszej części niniejszego dokumentu. 5. Dostarczenie dokumentacji Systemu. Wymagania w zakresie dokumentacji Systemu opisane są w dalszej części niniejszego dokumentu. 6. Udzielenie licencji na korzystanie z Systemu i przeniesienie na Zamawiającego praw autorskich w zakresie utworów (w rozumieniu ustawy o prawie autorskim i prawach pokrewnych). Wymagania w powyższym zakresie opisane są w dalszej części niniejszego dokumentu. 7. Świadczenie usług wsparcia w zakresie Systemu. Wymagania dotyczące usług wsparcia opisane są w dalszej części niniejszego dokumentu. 2. TERMIN REALIZACJI Oczekiwany termin realizacji: - Prace związane z przeprowadzaniem analizy i przygotowaniem koncepcji rozwiązania powinny zakończyć się w ciągu 1 miesiąca od daty podpisania umowy. - Wdrożenie produkcyjne systemu prace określone w punkcie 1 dokumentu ust. 2 do 5 - zalecany termin to 31.12.2016 - Świadczenie usług wsparcia w zakresie Systemu przez okres 3 lat od zakończenia wdrożenia tj. odbioru prac określonych w punkcie 1 dokumentu, ust.2 do 5 z możliwością przedłużania o kolejne okresy roczne, przy czym przedłużenie może nastąpić maksymalnie dwa razy. 3. WYMAGANIA I. Ogólne wymagania w zakresie Systemu 1. Elementy Systemu System będzie wspierał procesy rozliczeniowe transakcji w komunikacji międzynarodowej sprzedanych w ramach usług transportowych oraz transakcji wynikających z wzajemnych 1
świadczeń pomiędzy kolejowymi przedsiębiorstwami przewozowymi. Dodatkowo w systemie będzie prowadzona ewidencja druków ścisłego zarachowania. System musi posiadać interfejs graficzny użytkownika (GUI) umożliwiający wyszukiwanie, przeglądanie, modyfikacje, usuwanie transakcji sprzedażowych jak również transakcji będących wynikiem rozliczeń. Dane z transakcjami będą gromadzone i przetwarzane w wewnętrznej bazie danych dedykowanej dla tego systemu. W skład systemu wejdzie również platforma ETL do pozyskiwania danych z zewnętrznych źródeł. Do obsługi ETL przez administratora wymagany jest interfejs graficzny. 2. Uproszczony schemat procesu, jaki ma być wspierany przez System W ramach pracy w systemie będą wspierane poniższe procesy: Rozliczanie sprzedaży biletów Rozliczanie sprzedaży rezerwacji 2
Rozliczanie usług świadczeń granicznych 3
Rozliczanie usług użytkowania wagonów 4
Rozliczanie wpływów i rozchodów w kasach 5
Ewidencja druków ścisłego zarachowania. 6
3. Wymagania funkcjonalne Pobieranie transakcji sprzedażowych 1. Pobieranie transakcji bezpośrednio z systemów źródłowych (bazy oracle). a. Możliwość mapowania danych w procesie importu. b. Łączenie pojedynczych importów w zadania. c. Możliwość kolejkowania zadań. d. Uzależnienie uruchomienia zadania od statusu zakończenia się poprzedniego zadania. e. Automatyczne uruchamianie o danej godzinie. f. Możliwość ręcznego uruchomienia zadania. g. Alerty w przypadku zakończenia zadania z błędem. h. Statystyka pobranych transakcji. i. Weryfikacja po polach kluczach czy dana transakcja jest nowa czy to aktualizacja już istniejącej transakcji. 2. Pobieranie transakcji z plików a. Czytanie formatów txt, csv, xls. b. Możliwość zdefiniowania specyfikacji importu. c. Pobieranie danych ze zdefiniowanych folderów z plikami. d. Łączenie pojedynczych importów w zadania. 7
e. Możliwość kolejkowania zadań. f. Uzależnienie uruchomienia zadania od statusu zakończenia się poprzedniego zadania. g. Automatyczne uruchamianie o danej godzinie. h. Możliwość ręcznego uruchomienia zadania i. całego procesu. ii. wybranego pliku z podaniem ścieżki do pliku (wpisanie lub przez drzewo explorera). i. Alerty w przypadku zakończenia zadania z błędem. j. Statystyka pobranych transakcji. k. Oznaczanie przetworzonych plików aby nie wczytać ich ponownie w następnych zadaniach. l. Weryfikacja po polach kluczach czy dana transakcja jest nowa czy to aktualizacja już istniejącej transakcji. 3. Wprowadzanie danych za pośrednictwem interfejsu graficznego a. Alertowanie o konieczności wprowadzenia pól obowiązkowych. b. Weryfikacja poprawności wypełnienia wybranych pól (np. weryfikacja długości, zgodność danych z typem pola, itp.). c. Wybór z listy zdefiniowanych wartości dla danego pola. d. Możliwość tworzenia transakcji na bazie kopii już istniejącej transakcji. e. Weryfikacja po polach kluczach czy dana transakcja już istnieje w bazie danych. 4. Modyfikacja danych z pozycji interfejsu graficznego a. Możliwość ograniczenia pól do modyfikacji. b. Odkładanie historii zmian. 5. Aktualizacja danych a. Możliwość definiowania reguł dla aktualizacji. b. Odkładanie historii zmian. Słowniki 1. Słowniki będą definiowane z pozycji interfejsu graficznego. 2. Zasilanie słowników możliwe z interfejsu graficznego lub przez pliki wsadowe. 3. Atrybuty mogą być zmienne w czasie, nie będą nadpisywane tylko będzie tworzona nowa wersja atrybutu z nowa wartości i datą jej obowiązywania. Struktura sprzedaży 1. Struktura sprzedawców hierarchiczna w relacji podwładny przełożony. 2. Struktura odbiorców jw. 3. Struktura wersjonowana w czasie (zmiana relacji, zmiana atrybutów). 4. Możliwość przejścia od sprzedawcy do wszystkich jego transakcji i od jednej transakcji do sprzedawcy (jedna transakcja jeden sprzedawca). 5. Możliwość przejścia od odbiorcy do wszystkich jego transakcji i od jednej transakcji do odbiorcy (do jednej transakcji może należeć kilku odbiorców). Rozliczanie transakcji i tworzenie podsumowań 1. Wycena per transakcja z wykorzystaniem słownika z cennikiem. 2. Możliwość stosowania rabatu % i wartościowego lub mnożnika per sprzedawca. 3. Możliwość stosowania rabatu % i wartościowego lub mnożnika per odbiorca. 4. Jedna transakcja może posiadać kilka rekordów rozliczeniowych. 5. Transakcje rozliczane wg typu i/lub podtypu transakcji. 8
6. Wycena transakcji w więcej niż jednej walucie. 7. Tworzenie podsumowań per sprzedawca, per odbiorca z możliwością wylistowania szczegółów wchodzących w skład tego podsumowania (drilldown). 8. Tworzenie podsumowań na każdym poziomie hierarchii sprzedawców/odbiorców. 9. Tworzenie agregatów wykorzystywanych w budowie kluczy i statystyk. 10. Użycie w regułach liczących mechanizmów kontrolnych (sumy kontrolne). 11. Liczba transakcji do rozliczenia w miesiącu do 500 tysięcy. Interfejs graficzny 1. Dostęp do różnych zestawów ekranów interfejsu graficznego dla różnych poziomów uprawnień. 2. Ekrany z możliwościami definiowania warunków wyszukiwania/filtrowania rekordów zarówno transakcji jak i rekordów rozliczeniowych. 3. Przechodzenie z ekranu z wynikami wyszukiwania do ekranu ze szczegółami dla pojedynczej transakcji. 4. Przechodzenie od transakcji sprzedaży do jej odpowiedników w transakcjach rozliczonych i na odwrót. 5. Możliwość definiowania pod przyciskami własnych funkcji. 6. Możliwość wywoływania innych aplikacji z przekazaniem w wywołaniu parametrów wyszukiwania. 7. Wyświetlanie danych pobranych ad-hoc z innej bazy danych. 8. Możliwość ograniczenia dostępu do wybranych pól na interfejsie graficznym wg zdefiniowanych reguł (dla różnych uprawnień użytkownika, lub dla specyfiki ekranu ekran do wprowadzania nowych rekordów i ekran z możliwością modyfikacji istniejącego już rekordu dla transakcji). 9. Podział na panel administratora i użytkownika. 10. W panelu administratora dostęp do reguł rozliczeniowych, importu, raportów z możliwością zmian w tych regułach. Raportowanie 1. Dostęp z różnym poziomem uprawnień. 2. Generowanie raportów w formacie txt, csv, xls, doc, pdf. 3. Generowanie raportów z wynikiem na interfejsie graficznym z możliwością zapisania wyniku raportu do pliku. 4. Tworzenie raportów txt wg zdefiniowanych specyfikacji i odpowiedniego układu danych z automatycznym zachowaniem raportu w zdefiniowanym folderze. 5. Tworzenie raportów wg wzoru dokumentu (faktura, polecenie księgowe) z automatycznym zachowaniem raportu w zdefiniowanym folderze. 6. Możliwość zmian w raportach z poziomu użytkownika. 7. Generowanie raportów dla jednego sprzedawcy/odbiorcy lub dla wielu. 8. Generowanie raportów na życzenie lub tworzenie zbiorczych zadań i zarządzanie nimi. 9. Parametryzowanie generowanych raportów. 4. Przewidywane poziomy uprawnień a) 2 administratorów technicznych Systemu, b) 2 administratorów merytorycznych i biznesowych Systemu (zarządzających uprawnianiami nadawanie loginów, haseł, definiowanie poziomu uprawnień, modyfikacja reguł i funkcji wykorzystywanych w rozliczeniach), 9
c) 10 użytkowników Systemu po stronie PKP Intercity, 5. Wymagania techniczne a) Możliwość instalacji i prawidłowego korzystania z Systemu w środowisku informatycznym Zamawiającego, tj. na infrastrukturze IT - infrastruktura wirtualna oparta o Vmware w wersji 5.5 i wyżej, - systemy operacyjne Windows Server w wersji 2012 R2 lub Linux (CentOS w wersji 6 i wyżej lub Debian w wersji 7 i wyżej), - bazy danych MS SQL 2014 lub Postgres 9.1 lub wyższa lub MySQL 5.5 i wyżej, na sprzęcie użytkownika IT - systemy operacyjne od Windows XP do Windows 10, - rozdzielczość ekranu min 1024x768, - przeglądarki internetowe: Internet Explorer min. 8, Mozilla Firefox 20.0 lub wyższa,, Chrome. - Wyłączenie opcji blokowania wyskakujących okienek dla adresu aplikacji; - Aktywne połączenie sieciowe; - Pozostałe wymagania systemowe jak dla wybranej przeglądarki internetowej b) Dostęp Klientów do Systemu przez Internet; przeglądarki Internetowe: Internet Explorer min. 8, Mozilla Firefox, Chrome. c) Centralne administrowanie Systemem przez Zamawiającego d) Centralne nadawanie uprawnień użytkownikom przez Administratora ze strony Zmawiającego. e) Możliwość nadawania uprawnień do poszczególnych modułów/ danych. II. Wymagania w zakresie szkoleń Przeprowadzenie szkoleń w Warszawie dla: - 2 administratorów technicznych Systemu, - 2 administratorów merytorycznych i biznesowych Systemu (zarządzających uprawnianiami, modyfikacja reguł i funkcji wykorzystywanych w rozliczeniach), - 10 użytkowników Systemu po stronie PKP Intercity, III. Wymagania w zakresie dokumentacji Systemu 1) Dokumentacja Systemu - będzie zawierać: a) Projekt techniczny na podstawie, którego będzie realizowanie wdrożenie, w tym: - opis architektury logicznej Systemu (systemy operacyjne, bazy, aplikacje, połączenia między nimi), - opis architektury technicznej Systemu (ilości serwerów w odpowiednich rolach aplikacyjne, bazodanowe itp., wymagania sprzętowe CPU, RAM, dyski itd.), - opis procesów, przepływy danych w Systemie, diagramy sieciowe (czyli jakie adresy po jakich portach się komunikują). b) Mapa procesu obsługi rozliczeń międzynawowych u Zamawiającego przy użyciu Systemu, w tym minimum: 10
- zadanie, jednostka organizacyjna je realizująca, zadanie poprzedzające, dane wejściowe, zadanie następne, dane wyjściowe, wynik zadania. c) Dokumentację projektowo-wdrożeniową, w tym: - harmonogram projektu-wdrożenia, - plan testów, d) Dokumentację administratora technicznego Systemu Dokumentacja administratora Systemu powinna zawierać szczegółowy opis wszelkich cech i właściwości dostarczonego Systemu, pozwalający na poprawną instalację, konfigurację i administrację aplikacji (lub zespołu aplikacji) zgodnie z jej przeznaczeniem. Powinna ona zawierać w szczególności: - Metrykę dokumentu (kto przygotował, kto akceptował, wersje itp.) - Definicje użyte w dokumentacji - Ogólny\Skrócony opis Systemu - Szczegółowy opis roli oraz zadań administratorów Systemu (bieżących, okresowych) : Technicznych Aplikacyjnych - Szczegółową dokumentację techniczną Systemu zawierającą minimum opis: Konfiguracji / Wymagań systemowych Konfiguracji / Wymagań sieciowych Konfiguracji / Wymagań backupu Konfiguracji / Wymagań dyskowych Wymagań antywirusa (możliwa dodatkowa konfiguracja) Dostępności struktury bazy danych z opisem Wymagań konfiguracji firewall a Wymagań monitoringu takie jak: komponenty, logi, funkcje Systemu, dostępność, Opis poszczególnych elementów Systemu i relacji między nimi Przepływu danych w formie diagramu między elementami Systemu i poza Systemowymi (interfejsy), Integracji z AD jeżeli ma zastosowanie, Skryptów startowych lub zatrzymujących aplikację Administracji kontami użytkowników, tworzenia ról, przydzielania dostępów do poszczególnych funkcji lub grup funkcji w aplikacji Parametryzacji i konfiguracji aplikacji Instalacji, aktualizacji, rozwoju aplikacji lub jej komponentów Opis instalacji polskiej lokalizacji Kart błędów standardowych innych (specyficznych dla dostarczanego rozwiązania) - Procedurę Disaster Recovery Plan (DRP) Jeżeli dokumentacja składa się z kilku elementów, to w każdym z nich powinna znaleźć się specyfikacja (wyszczególnienie) pozostałych elementów, np. spis załączników. e) Dokumentację użytkownika Systemu Dokumentacja użytkownika Systemu powinna zawierać szczegółowy opis wszelkich cech i właściwości dostarczonego Systemu, pozwalający na poprawne użytkowanie aplikacji (lub zespołu aplikacji) zgodnie z jej przeznaczeniem. Powinna ona zawierać w szczególności: - opis interfejsu użytkownika oraz opis zasad dialogu z użytkownikiem, - opis specyficznych elementów konfiguracji interfejsu dostępnych dla użytkownika 11
(np. personalizacja interfejsu) - jeśli takie występują, - instrukcję/instrukcje obsługi wszystkich zasadniczych funkcjonalności biznesowych. Jeżeli dokumentacja składa się z kilku elementów, to w każdym z nich powinna znaleźć się specyfikacja (wyszczególnienie) pozostałych elementów, np. spis załączników. f) Materiały szkoleniowe, w tym: - dedykowane dla administratorów technicznych Systemu, - dedykowane dla administratorów merytorycznych Systemu (zarządzających uprawnianiami), - dedykowane dla użytkowników Systemu po stronie PKP Intercity, - dedykowane dla użytkowników Systemu z ramienia Klientów. g) Dokumentację powdrożeniową, tj. Projekt techniczny zaktualizowany o zmiany, które nastąpiły w trakcie wdrożenia. 2) Dokumentacja Systemu będzie sporządzona w języku polskim, dostarczona Zamawiającemu w formie papierowej w 5 egzemplarzach, w formie elektronicznej na płycie CD w 5 egzemplarzach; za wyjątkiem materiałów szkoleniowych, które będą dostarczone w liczbie egzemplarzy odpowiadającej liczbie uczestników szkoleń + 5. IV. Wymagania w zakresie licencji i przeniesienia autorskich praw majątkowych 1) Licencja na korzystanie z Systemu a) Zamawiającemu zostanie udzielona licencja uprawniająca do korzystania z Systemu przez 12 użytkowników jednoczesnych pracowników Zamawiającego. W ramach wyżej wymienionej puli Zamawiający będzie mógł administrować Systemem, w tym dokonywać zmiany użytkowników. b) Oczekiwane licencje na następujące instancje Systemu: - produkcyjną, - developerską (w przypadku możliwości modyfikacji systemu przez Zamawiającego), - testową, - szkoleniową. c) Udzielona licencja będzie obejmować również przyszłe modyfikacje Systemu. d) Udzielona licencja będzie obejmować również nowe wersje Systemu dostarczane przez Wykonawcę w ramach świadczenia usług wsparcia. e) Licencja zostanie udzielona na czas nieoznaczony. f) Zamawiający będzie miał możliwość rozszerzania puli użytkowników określonej w pkt a) poprzez zamawianie u Wykonawcy w razie potrzeby dodatkowych licencji. 2) Przeniesienie autorskich praw majątkowych Wykonawca przeniesie na Zamawiającego autorskie prawa majątkowe do Utworów (w rozumieniu ustawy o prawie autorskim i prawach pokrewnych) innych niż System, w szczególności do dokumentacji opracowanej dla Zamawiającego. V. Wymagania dotyczące usług wsparcia 1) Zapewnienie dostarczania aktualizacji/ nowych wersji Systemu uwzględniających poprawki i rozwój Systemu przez producenta. 12
2) Zapewnienie wsparcia powdrożeniowego w zakresie Systemu tj. udzielania porad dla administratorów i użytkowników Systemu przez 3 miesiące od zakończenia wdrożenia Sytemu, w godzinach 9:00 17:00 w dni robocze (z wyłączeniem dni ustawowo wolnych od pracy). 3) Zapewnienie wsparcia serwisowego Systemu tj. usuwania usterek i awarii Systemu oraz udzielania porad technicznych w dni robocze (z wyłączeniem dni ustawowo wolnych od pracy) w godzinach biurowych. Błędy krytyczne (tj. nie działający system, lub nie działająca część systemu uniemożliwiająca prawidłową realizację procesu) muszą być usunięte w czasie 8h lub w przypadku przygotowania obejścia czas ten wydłuża się do 48h. Błędu niekrytyczne (tj. nie działająca część systemu umożliwiająca realizację procesu ale powodująca utrudnienia w jego realizacji) muszą być usunięte w czasie 24h lub w przypadku przygotowania obejścia czas ten wydłuża się do 72h. W pozostałych przypadkach czas usunięcia usterki nie może przekroczyć 7 dni. 4) Zapewnienie modyfikacji Systemu tj. realizacji modyfikacji funkcjonalności Systemu na podstawie odrębnych zamówień składanych przez Zamawiającego. 13