Załącznik nr 1 do SIWZ - Strona główna

Załącznik nr 1 do SIWZ
Opis przedmiotu zamówienia Spis treści 1 OGÓLNY OPIS PRZEDMIOTU ZAMÓWIENIA ......................................................................................................... 5 1.1 CELE WDROŻENIA SYSTEMU ......................................................................................................................................... 5 1.2 ZARYS KONCEPCJI SYSTEMU ........................................................................................................................................ 5 1.3 PRZEDMIOT ZAMÓWIENIA ............................................................................................................................................. 6 1.4 MIEJSCE REALIZACJI PRZEDMIOTU ZAMÓWIENIA .......................................................................................................... 7 1.5 SŁOWNIK POJĘĆ I AKRONIMÓW ..................................................................................................................................... 7 1.6 GŁÓWNE ELEMENTY DOCELOWEGO SYSTEMU ............................................................................................................ 17 1.6.1 Opis modułów komponentu ERP ........................................................................................................................... 19 1.6.2 Opis modułów komponentu EOD........................................................................................................................... 21 1.7 LICZBA UŻYTKOWNIKÓW W POSZCZEGÓLNYCH MODUŁACH ....................................................................................... 22 2 WYMAGANIA FUNKCJONALNE................................................................................................................................ 24 2.1 WYMAGANIA OGÓLNE ................................................................................................................................................ 24 2.2 WYMAGANIA DOTYCZĄCE KOMPONENTU ERP ........................................................................................................... 29 2.2.1 Wymagania dotyczące komponentu - Moduły wspólne .......................................................................................... 29 2.2.2 Wymagania dotyczące komponentu - Podsystem Zarzadzanie personelem ........................................................... 47 2.2.3 Wymagania dotyczące komponentu - Podsystem Finansowo-Księgowy................................................................ 75 2.2.4 Wymagania dotyczące komponentu - Podsystem Zarządzanie majątkiem ........................................................... 116 2.2.5 Wymagania dotyczące komponentu - Podsystem Zarządzanie sprzedażą ........................................................... 125 2.2.6 Wymagania dotyczące komponentu - Podsystem Zarządzanie zakupami ............................................................ 135 2.3 WYMAGANIA DOTYCZĄCE EOD ............................................................................................................................... 159 2.4 WYMAGANIA DOTYCZĄCE KOMPONENTU BI/EPM ................................................................................................... 182 2.4.1 Oczekiwania PAŻP dotyczące problemów do rozwiązania podczas wdrożenia Systemu .................................... 196 2.5 WYMAGANIA DOTYCZĄCE KOMPONENTU PORTAL.................................................................................................... 199 3 WYMAGANIA NIEFUNKCJONALNE ...................................................................................................................... 202 3.1 WYMAGANIA OGÓLNE .............................................................................................................................................. 202 3.2 WYMAGANIA DOT. ARCHITEKTURY SYSTEMU ........................................................................................................... 203 3.3 WYMAGANIA PRAWNE .............................................................................................................................................. 204 3.3.1 Wymagania prawne ogólne.................................................................................................................................. 204 3.3.2 Wymagania prawne specyficzne dla poszczególnych komponentów Systemu ..................................................... 206 3.3.2.1 3.3.2.2 3.3.2.3 Wymagania dla komponentu Elektroniczny Obieg Dokumentów ................................................................................. 206 Wymagania dla komponentu ERP – Zarzadzanie personelem....................................................................................... 206 Wymagania dla komponentów finansowo-księgowych ERP......................................................................................... 207 3.4 WYMAGANIA DOTYCZĄCE GWARANCJI I RĘKOJMI .................................................................................................... 209 3.4.1 Wymagania dotyczące części eksploatacyjnych i części zamiennych................................................................... 209 3.4.2 Wymagania dotyczące raportowania w okresie gwarancji.................................................................................. 209 3.4.3 Warunki pogwarancyjne ...................................................................................................................................... 209 3.5 NIEFUNKCJONALNE WYMAGANIA ORGANIZACYJNE .................................................................................................. 210 3.6 WYMAGANIA DOTYCZĄCE DOSTĘPNOŚCI, WYDAJNOŚCI I SKALOWALNOŚCI SYSTEMU ............................................. 212 4 WYMAGANIA TECHNICZNE .................................................................................................................................... 214 4.1 WYMAGANIA DLA INFRASTRUKTURY TECHNICZNEJ.................................................................................................. 214 4.1.1 Opis obecnej infrastruktury Zamawiającego ....................................................................................................... 214 Strona 2 z 285
4.1.2 4.1.3 Wymagania ogólne .............................................................................................................................................. 216 Wymagania dla sprzętu ........................................................................................................................................ 217 4.1.3.1 4.1.3.2 4.1.3.3 4.1.3.4 4.1.3.5 Serwery .......................................................................................................................................................................... 217 Macierz dyskowa ........................................................................................................................................................... 219 Biblioteka taśmowa (1szt.) ............................................................................................................................................ 220 Przełączniki 10 GbE ...................................................................................................................................................... 220 Inne elementy ................................................................................................................................................................ 221 4.1.4 Miejsce instalacji infrastruktury .......................................................................................................................... 222 4.2 WYMAGANIA DO OPROGRAMOWANIA STANDARDOWEGO ........................................................................................ 222 4.2.1 Wymagania ogólne .............................................................................................................................................. 222 4.2.2 Oprogramowanie Aplikacyjne ............................................................................................................................. 222 4.2.3 Systemy operacyjne .............................................................................................................................................. 222 4.2.4 Bazy danych, serwery aplikacji i inne .................................................................................................................. 222 4.3 WYMAGANIA DLA OPROGRAMOWANIA AUTORSKIEGO I INNYCH ELEMENTÓW AUTORSKICH .................................. 223 4.4 INTEGRACJA SYSTEMU Z INNYMI SYSTEMAMI ........................................................................................................... 223 4.4.1 Wymagania funkcjonalne w zakresie integracji ................................................................................................... 223 4.4.2 Wymagania niefunkcjonalne w zakresie integracji .............................................................................................. 224 4.5 WYMAGANIA DOTYCZĄCE BEZPIECZEŃSTWA I OCHRONY ......................................................................................... 225 5 WYMAGANIA ZWIĄZANE Z ZARZĄDZANIEM PROJEKTEM ......................................................................... 229 5.1 5.2 5.3 5.4 5.5 6 MIGRACJA DANYCH .................................................................................................................................................. 239 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 7 WYMAGANIA ORGANIZACYJNE ................................................................................................................................. 229 METODYKA PROWADZENIA PROJEKTU ..................................................................................................................... 231 ROZPOCZĘCIE REALIZACJI PROJEKTU ........................................................................................................................ 231 ETAPY REALIZACJI PROJEKTU ................................................................................................................................... 231 INFORMACJA NA TEMAT PRZEWIDYWANYCH ZALICZEK, TERMINÓW PŁATNOŚCI, HARMONOGRAMÓW PŁATNOŚCI ... 238 PROCES MIGRACJI DANYCH ....................................................................................................................................... 239 PODZIAŁ ODPOWIEDZIALNOŚCI W PROCESIE MIGRACJI .............................................................................................. 240 WERYFIKACJA POPRAWNOŚCI MIGRACJI DANYCH ..................................................................................................... 240 ZASADY POSTĘPOWANIA W PRZYPADKACH SZCZEGÓLNYCH ..................................................................................... 241 GWARANCJA DOTYCZĄCA PROCESU MIGRACJI DANYCH ........................................................................................... 242 LISTA PODSTAWOWYCH ŹRÓDEŁ DANYCH DO MIGRACJI ........................................................................................... 243 LISTA DODATKOWYCH ŹRÓDEŁ DANYCH DO MIGRACJI ............................................................................................. 245 POZOSTAŁE WYMAGANIA NIEFUNKCJONALNE DLA MIGRACJI DANYCH ..................................................................... 247 TESTY ............................................................................................................................................................................. 248 7.1 OGÓLNE ZASADY PRZEPROWADZANIA TESTÓW ........................................................................................................ 248 7.1.1 Obszary testowania, role i odpowiedzialności ..................................................................................................... 248 7.1.2 Ogólne zasady przebiegu procesu testowania ..................................................................................................... 248 7.1.2.1 7.1.2.2 7.1.2.3 Harmonogram testów..................................................................................................................................................... 250 Środowisko testowe ....................................................................................................................................................... 251 Dokumentacja testów..................................................................................................................................................... 251 7.2 OBSZARY TESTOWANIA............................................................................................................................................. 252 7.2.1 Testy urządzeń serwerowych................................................................................................................................ 252 7.2.2 Testy integracyjne ................................................................................................................................................ 253 7.2.3 Testy funkcjonalne ............................................................................................................................................... 254 7.2.4 Testy użyteczności ................................................................................................................................................ 254 7.2.5 Testy regresji ....................................................................................................................................................... 255 Strona 3 z 285
7.2.6 7.2.7 8 SZKOLENIA ................................................................................................................................................................... 257 8.1 8.2 8.3 8.4 9 Testy bezpieczeństwa ........................................................................................................................................... 255 Testy wydajnościowe............................................................................................................................................ 255 WYMAGANIA DOT. PRZYGOTOWANIA I PROWADZENIA SZKOLENIA ........................................................................... 257 WYMAGANE TYPY SZKOLEŃ ..................................................................................................................................... 258 LICZBA UCZESTNIKÓW DLA KOMPONENTU ERP ....................................................................................................... 260 POZOSTAŁE WYMAGANIA DOTYCZĄCE SZKOLEŃ ...................................................................................................... 261 WYMAGANIA DOTYCZĄCE DOKUMENTACJI ................................................................................................... 264 9.1 RODZAJE DOKUMENTACJI ......................................................................................................................................... 264 9.1.1 Dokumentacja zarządcza ..................................................................................................................................... 264 9.1.2 Dokumentacja techniczna projektowa ................................................................................................................. 264 9.1.2.1 9.1.2.2 9.1.2.3 9.1.3 Dokumentacja powykonawcza ...................................................................................................................................... 266 Dokumentacja eksploatacyjna ....................................................................................................................................... 266 Wymagania niefunkcjonalne dotyczące dokumentacji .................................................................................................. 267 Ogólne warunki odbioru dokumentacji................................................................................................................ 268 9.1.3.1 9.1.3.2 9.1.3.3 Terminy akceptacji w ramach odbioru dokumentacji .................................................................................................... 268 Procedura zgłaszania uwag w ramach odbioru dokumentacji ........................................................................................ 268 Prawa własności intelektualnej do dokumentacji........................................................................................................... 269 10 ZASADY ODBIORU PRODUKTÓW PROJEKTU.................................................................................................... 270 10.1 10.2 10.3 PROTOTYPY .............................................................................................................................................................. 273 TERMIN REALIZACJI PROJEKTU ................................................................................................................................. 274 NADZÓR NAD REALIZACJĄ PROJEKTU ....................................................................................................................... 274 11 PRACE DODATKOWE ................................................................................................................................................ 275 12 PRAWA WŁASNOŚCI INTELEKTUALNEJ ............................................................................................................ 276 13 INFORMACJA O KONIECZNOŚCI PRZETWARZANIA DANYCH OSOBOWYCH W RAMACH
REALIZACJI ZAMÓWIENIA .............................................................................................................................................. 277 14 PODWYKONAWSTWO ............................................................................................................................................... 278 15 WZORY PROTOKOŁÓW ............................................................................................................................................ 279 16 INFORMACJA O PRZEDSIĘBIORSTWIE – LISTA PROCESÓW ....................................................................... 280 16.1 OGÓLNA INFORMACJA O PRZEDSIĘBIORSTWIE........................................................................................................... 280 16.2 INFORMACJA O KLUCZOWYCH PROCESACH PAŻP PODLEGAJĄCYCH WSPARCIU PRZEZ SYSTEM ............................... 281 16.2.1 Informacja o procesie sprzedaży usług nawigacyjnych ................................................................................... 281 16.2.2 Informacja o procesie zarządzania kosztami ................................................................................................... 282 17 SPIS TABEL ................................................................................................................................................................... 284 18 MODYFIKACJE ........................................................................................ BŁĄD! NIE ZDEFINIOWANO ZAKŁADKI. Strona 4 z 285
1 Ogólny opis przedmiotu zamówienia
1.1
Cele wdrożenia systemu
Zamawiający wykonuje swoją statutową działalność wynikającą z ustawy o PAŻP z dnia 8.12.2006 (wraz z późniejszymi zmianami) polegającą na zapewnieniu bezpiecznej, ciągłej, płynnej i efektywnej żeglugi powietrznej w polskiej przestrzeni powietrznej przez wykonywanie funkcji instytucji zapewniającej służby żeglugi powietrznej, zarządzanie przestrzenia powietrzną oraz zarządzanie przepływem ruchu lotniczego zgodnie z przepisami międzynarodowymi i krajowymi, w oparciu o wymagane certyfikaty i model odzyskiwania kosztów, wynikający z Rozporządzeń Komisji (UE), poniesionych na wykonywanie swojej statutowej działalności. Sprostanie wymaganiom użytkowników przestrzeni powietrznej i oczekiwaniom stawianym przez Komisję Europejską w ramach inicjatywy „Single European Sky” sprawiły, że Zamawiający zdecydował o budowie Systemu realizującego w szczególności następujące cele: 1) zapewnienie możliwości najszybszej reakcji na zmieniające się warunki zewnętrzne, dzięki skróceniu czasu potrzebnego na wygenerowanie adekwatnych zintegrowanych informacji zarządczych; 2) wprowadzenie zarządzania przez koszty, a co za tym idzie umożliwienie pełnej i wybiórczej kontroli kosztów wraz ze stałym monitoringiem wpływu ich zmian na wysokość stawek jednostkowych opłat za usługi, wspieranym zaawansowanymi mechanizmami kalkulacji kosztów; 3) zautomatyzowanie nadzorowania kluczowych procesów w organizacji w celu określenia stopnia realizacji strategii Zamawiającego, kontroli efektywności kosztowej i oceny skuteczności działania odniesionej do konkurencji. 4) zapewnienie przejrzystości działania Zamawiającego, dzięki udostępnieniu pełniejszej informacji zarządczej (rozszerzenie obszaru sprawozdawczości o nowe informacje) oraz poprawieniu jakości/spójności danych w systemach transakcyjnych (między innymi poprzez jednokrotne wprowadzanie danych do Systemu); 5) optymalizację i automatyzację procesów biznesowych, prowadzącą do zmniejszenia ich pracochłonności, skrócenia czasu ich wykonywania oraz poprawy ich jakości, a w szczególności: a. zwiększenie skuteczności procesu planowania i monitorowania kosztów, nakładów i dochodów; b. zwiększenie skuteczności i efektywności kontroli wydatkowania środków budżetowych poprzez wprowadzenie automatycznych mechanizmów kontroli; c. umożliwienie wyliczania/przeliczania wskaźników kontrolujących przebieg i jakość procesów biznesowych (wprowadzenie mechanizmów monitorowania tychże wskaźników). 1.2
Zarys Koncepcji Systemu
Opis Przedmiotu Zamówienia jest wynikiem wcześniejszego opracowania Koncepcji Systemu, opartej o analizę dokumentów wewnętrznych PAŻP, aktów prawnych o kluczowym znaczeniu oraz wywiadu dokumentującego cele biznesowe, wymagania biznesowe, oczekiwania i wymagania użytkowników, a także w efekcie inwentaryzacji głównych procesów biznesowych. Zebrany materiał pozwolił na sformułowanie wymagań funkcjonalnych i niefunkcjonalnych, które następnie były weryfikowane i uzgadniane ze zgłaszającymi oraz osobami odpowiedzialnymi za poszczególne obszary. W trakcie weryfikacji badano zgodność wymagań użytkowników z wymaganiami biznesowymi oraz ze strategią, a także starano się wyeliminować redundancje i niejasności. Strona 5 z 285
Wymagania funkcjonalne zostały podzielone na grupy, odpowiadające najważniejszym obszarom działalności, a w ramach grup na podobszary odpowiadające modułom funkcjonalnym o charakterze ogólnym, starając się używać typowego nazewnictwa. Każda grupa jest przypisana do tego z komponentów, który w największym stopniu przyczynia się do realizacji wymagań. Niektóre wymagania, wymagające obsługi przez więcej niż jeden komponent umieszczone są w sposób zgodny z tą samą zasadą. Tym samym, umieszczenie wymagania w danej grupie nie przesądza o konieczności udzielenia dostępu do aplikacji o nazwie zgodnej z nazwą modułu, ani nawet w komponencie, gdyż produkty poszczególnych producentów różnią się od siebie. Zakłada się, że Dostawca w swoim rozwiązaniu dopasuje produkt do wymagań w sposób optymalny pod względem funkcjonalności i ekonomii. Wymagania niefunkcjonalne o charakterze organizacyjnym zostały uzupełnione o rozdział OPZ opisujący przedsiębiorstwo i te jego procesy, które są specyficzne dla działalności Agencji. Dla potencjalnego Dostawcy może być istotny fakt, że Agencja działa w środowisku podlegającym silnym regulacjom prawnym, przez co jest zmuszona do równie silnych regulacji wewnętrznych wynikających z trzech grup wymagań prawnych: regulacje dotyczące bezpieczeństwa ruchu lotniczego, regulacje dotyczące zasad finansowania, oraz regulacje dotyczące zamówień publicznych. Reprezentatywne zestawienie zostało zamieszczone w zapytaniu o informację rynkową i jest ogólnodostępne na stronie internetowej Agencji. Wymagania o charakterze technicznym zostały wstępnie wyskalowane dla zadanych ilości użytkowników, modułów i komponentów oraz ilości obecnych i przewidywanych operacji. Przedstawiono także możliwości wykorzystania istniejącej infrastruktury na potrzeby planowanego Systemu. 1.3
Przedmiot zamówienia
Przedmiotem zamówienia jest zaprojektowanie, dostawa i wdrożenie scentralizowanego, zintegrowanego i zunifikowanego systemu informatycznego o budowie modułowej definiowanego jako system wspierający zarządzanie przedsiębiorstwem oraz przepływ informacji, zapewniającego standaryzację działania oraz wymianę i integrację danych m.in. w obszarach: a) Zarządzanie personelem, b) Finanse i księgowość, c) Zarządzanie majątkiem, d) Zarządzanie sprzedażą, e) Zarządzanie zakupami, f) Planowanie i prognozowanie, g) Raportowanie. Zakres zadań do wykonania w ramach Zamówienia: 1. Wykonanie niezbędnych prac analitycznych i opracowanie dokumentu „Projekt Techniczny”. 2. Dostawa platformy sprzętowej (wraz z niezbędnym oprogramowaniem systemowym i pełną dokumentacją), jej instalacja i konfiguracja. 3. Przekazanie praw lub licencji na dostarczoną infrastrukturę sprzętową oraz zapewnienie gwarancji na dostarczone produkty. 4. Dostarczenie Oprogramowania Standardowego (aplikacyjnego, bazodanowego oraz pomocniczego) i Oprogramowania Autorskiego, instalowanego na serwerach, niezbędnego do funkcjonowania Systemu wraz z dokumentacja techniczną. 5. Przekazanie praw lub licencji na nieograniczone czasowo użytkowanie Systemu. Strona 6 z 285
6. Zaprojektowanie oraz wdrożenie środowiska testowo‐developerskiego Systemu, pozwalającego na prowadzenie prac rozwojowych oraz prowadzenie testów związanych z wprowadzeniem zmian i poprawek w docelowym środowisku produkcyjnym. 7. Przeprowadzenie testów. 8. Wykonanie integracji z innymi systemami użytkowanymi przez PAŻP. 9. Migrację danych z obecnie działających w PAŻP systemów. 10. Przeprowadzenie szkoleń dla wskazanej przez Zamawiającego grupy użytkowników i administratorów Systemu. 11. Uruchomienie środowiska produkcyjnego Systemu zgodnie z harmonogramem. 12. Opracowanie dokumentacji technicznej i użytkowej Systemu, w tym: a. Dokumentacji procesów biznesowych Agencji z uwzględnieniem ich wsparcia przez System, b. Dokumentacji opisującej procesy i procedury zarządzania Systemem, c. Dokumentacji przedstawiającej procesy i procedury zarządzania cyklem rozwoju i aktualizacji Systemu z wykorzystaniem środowiska testowego, d. Jednolitej i spójnej polityki oraz dokumentacji bezpieczeństwa systemu, zgodnie z wymaganiami normy PN‐ISO/IEC‐17799, e. Dokumentacji zawierającej opis struktury zbiorów danych wskazujących zawartość poszczególnych pól informacyjnych i powiązania między nimi oraz opis przepływu danych pomiędzy systemami. 13.Zapewnienie Gwarancji na System przez okres 12 miesięcy od dnia podpisania przez Strony Protokołu Odbioru Końcowego Systemu zgodnie z zapisami paragrafu 13 Istotnych Postanowień Umowy.. Zamawiający będzie prowadził Projekt zgodnie z metodyką PRINCE2. Wszelkie zawarte w niniejszym Opisie Przedmiotu Zamówienia wymagania są traktowane jako obligatoryjne o ile nie zostało to wyraźnie wskazane, że są wymaganiami opcjonalnymi. Zamawiający nie przewiduje podziału zamówienia na części. 1.4
Miejsce realizacji przedmiotu zamówienia
Miejscem realizacji przedmiotu zamówienia będzie siedziba Polskiej Agencji Żeglugi Powietrznej przy ul. Wieżowej 8, 02‐147 Warszawa. W razie konieczności prace związane z realizacją przedmiotu zamówienia mogą odbywać się w innych lokalizacjach należących do PAŻP lub będących w dyspozycji PAŻP, które zostaną wskazane w trakcie realizacji projektu. Prace nie wymagające obecności pracowników Wykonawcy na miejscu u Zamawiającego, mogą być realizowane w siedzibie Wykonawcy. Szczegółowe ustalenia w tym zakresie poczynione zostaną w etapie 5.0 i zawarte w Planie Projektu Wdrożenia. 1.5
Słownik pojęć i akronimów
Pojęcie ABC ABC/M ACC Administrator Bezpieczeństwa Opis Activity Based Costing. Rachunek kosztów działań. Metoda ewidencji i rachunku kosztów polegająca na przypisaniu kosztów do działań i ich produktów. Activity Based Costing / Management. Metoda zarządzania kosztami oparta o rachunek kosztów działań. Centrum kontroli obszaru lub kontrola obszaru. Osoba odpowiadająca za zapewnienie bezpieczeństwa fizycznego, technicznego i organizacyjnego danych osobowych przetwarzanych w systemach informatycznych. Do jego obowiązków należy:
Strona 7 z 285
Pojęcie Opis
a) Zapewnienie ochrony przed działaniem niepożądanego oprogramowania, b) Zapewnienie prawidłowego przebiegu i prawidłowej eksploatacji sprzętu komputerowego, c) Zapewnienie polityki zarządzania oprogramowaniem ze szczególnym uwzględnieniem polityki legalności oprogramowania, d) Zapewnienie polityki zarządzania dostępem użytkownika do systemów informatycznych (zarządzanie identyfikatorami, hasłami i uprawnieniami, kontrola poprawności uprawnień), e) Analizowanie poprawności systemu na podstawie kontrolowanych dzienników pracy,
f) Opiniowanie w zakresie bezpieczeństwa systemów i ochrony informacji przetwarzanych w postaci elektronicznej, g) Implementacja Polityki Bezpieczeństwa Informacji (opracowywanie wewnętrznych dokumentów i procedur dotyczących zabezpieczenia systemów, opracowywanie analizy ryzyka aplikacji oraz planów awaryjnych), h) Opracowanie okresowych ocen i sprawozdań, i) Realizacja zadań szkoleniowych i informacyjnych oraz inicjowanie i organizowanie działań profilaktycznych w zakresie ochrony informacji przetwarzanych elektronicznie. Administrator Osoba odpowiedzialna za parametryzację systemów i aplikacji tworzących rozwiązania Biznesowy biznesowe zaprojektowane przez Architekta Biznesowego. Administrator Danych Osoba, zespół lub komórka (zależnie od struktury organizacyjnej) odpowiedzialna za zarządzanie danymi w bazie danych (m.in.: wprowadzanie, usuwanie, modyfikację danych), w tym za jakość danych. Najczęściej funkcję tę pełni właściciel danych. Administrator Osoba zajmująca się zarządzaniem systemem informatycznym i odpowiadająca za jego Systemu sprawne i ciągłe działanie. Podstawowym zadaniem Administratora jest: nadzorowanie (Administrator) pracy powierzonych systemów, zarządzanie kontami i uprawnieniami użytkowników, konfiguracja systemów, instalowanie i aktualizacja oprogramowania, dbanie o bezpieczeństwo systemu i danych w systemach, nadzorowanie, wykrywanie i eliminowanie nieprawidłowości, asystowanie i współpraca z zewnętrznymi specjalistami przy pracach instalacyjnych, konfiguracyjnych i naprawczych, tworzenie dobrej dokumentacji zmian wprowadzanych w systemach itp. Administrator Systemu odpowiedzialny jest również za zarządzanie bazami danych. Administrator Osoba, zespół lub komórka (zależnie od struktury organizacyjnej) odpowiedzialny za Systemu Logów zbieranie, nadzór, analizowanie oraz przechowywanie logów. Agencja Polska Agencja Żeglugi Powietrznej – Zamawiający. AFTM Air Traffic Flow Management ‐ Zarządzanie przepływem ruchu lotniczego. AIS Aeronautical Information Service ‐ Służba Informacji Lotniczej ‐ odpowiedzialna za zbieranie i rozpowszechnianie informacji dla całego terytorium Polski i przestrzeni powietrznej nad otwartym morzem. AMC Airspace Management Cell ‐ Ośrodek Zarządzania Przestrzenią Powietrzną. Analityk Biznesowy Osoba odpowiedzialna za zbieranie i analizę wymagań użytkowników systemu, a także za dokumentację i analizę procesów biznesowych w podległych sobie obszarach działalności Agencji oraz za parametryzację, optymalizację i weryfikację poprawności tych procesów w Systemie i za zapewnienie ich spójności z regulacjami wewnętrznymi PAŻP. Osoba powinna znać dogłębnie jeden lub kilka obszarów merytorycznych. Analiza Patrz: Projekt Techniczny. Strona 8 z 285
Pojęcie przedwdrożeniowa ANSP Architekt Biznesowy Asysta ATM ATOM Audyt Audyt wewnętrzny Audyt ZSZ BI Błąd BPMN BREF Budżet Opis
Air Navigation Service Provider ‐ dostawca usług nawigacyjnych. Pojęcie odnoszące się do organizacji zarządzających ruchem lotniczym. Osoba odpowiedzialna za projektowanie lub weryfikację funkcjonalności systemu z punktu widzenia realizacji strategii, finansów, ryzyka i innych kryteriów istotnych dla Agencji. Architekt biznesowy nadzoruje prace analityków biznesowych. Asysta dostawcy przy samodzielnym wykonywaniu przez Zamawiającego następujących prac wdrożeniowych: konfiguracja raportów, konfiguracja pulpitów menedżerskich, konfiguracja mierników, konfiguracja obiegów, rejestrów dokumentów. Dostawca powinien pozostawać w gotowości asysty na żądanie przez cały czas trwania wdrożenia. Air Traffic Management ‐ Zarządzanie ruchem lotniczym. Pojęcie odnoszące się do wszelkich systemów służących do zarządzania ruchem lotniczym. ATOM‐System gromadzenia i analizy informacji o zdarzeniach, które występują w służbach technicznych PAŻP. Audytem nazywamy niezależne i obiektywne działanie, wspierające realizację celów i zadań jednostki przez systematyczną ocenę przebiegu procesów oraz kontroli zarządczej (w tym systemów zarządzania i zarządzania ryzykiem) oraz czynności doradcze. Ocena dotyczy w szczególności adekwatności, skuteczności i efektywności kontroli zarządczej (w tym systemów zarządzania i zarządzania ryzykiem) w jednostce. Audyt wewnętrzny w PAŻP prowadzi działania zgodnie z: ‐ Ustawą o finansach publicznych (audyt wewnętrzny) – merytoryczny zakres określa ustawa o finansach publicznych (Art. 48. 1. ustawy), proceduralnie prowadzony w oparciu o standardy IIA, ‐ Zintegrowanym Systemem Zarządzania (Audyt ZSZ), ‐ Normami ISO. Audyt wewnętrzny przeprowadzany jest dla potrzeb własnych PAŻP, może być planowy i pozaplanowy. Audyt prowadzony na podstawie wewnętrznych przepisów organizacji, zgodnie z postanowieniami norm ISO 9001, 14001 i PN‐N‐18001. Business Intelligence (analityka biznesowa) proces i narzędzia informatyczne przekształcania danych w informacje, a informacji w wiedzę, która może być wykorzystana do zwiększenia konkurencyjności przedsiębiorstwa. Patrz definicja w paragrafie 2 Istotnych Postanowień Umowy. Business Process Model and Notation. Obecna nazwa została wprowadzona w wersji 2.0. Wcześniej skrót BPMN był tłumaczony jako Business Process Modeling Notation. BPMN to standard, który stanowi narzędzie do specyfikowania procesów biznesowych. Często jest utożsamiany tylko z notacją, co jest pewnym uproszczeniem, choć w kontekście wykorzystania BPMN w Projekcie nie jest błędem. Jako notacja BPMN jest graficzną reprezentacją opisującą proces biznesowy. Baza statków powietrznych z przypisanymi MTOW (Maximum Take‐off Weight ‐ Maksymalna masa startowa) w relacji do klienta wykorzystywana do naliczeń opłat trasowych i terminalowych przez PAŻP. Wynikający z planu finansowego Agencji przydział limitów kosztów w okresach sprawozdawczych, według zakresów obowiązków wynikających z podziału pracy Agencji (w układzie np. MPK, zadań, komórek). Strona 9 z 285
Pojęcie CANSO Cel biznesowy CNS CRCO CRU Cykl audytu Część Systemu DMZ Doradca Dostawca Systemu EOD EPM ERKZ Etap Opis
Civil Air Navigation Services Organization – organizacja zrzeszająca dostawców usług nawigacyjnych z całego świata wymieniająca informacje oraz opracowująca nowe strategie w celu poprawy działania służb żeglugi powietrznej. Cel wdrożenia nowego Systemu z punktu widzenia wartości dodanych dla działalności biznesowej, zdefiniowany w ramach poszczególnych obszarów. Communication, navigation, surveillance ‐ łączność, nawigacja, dozorowanie. Pojęciem tym określa się zespół narzędzi wspomagających zarządzanie i monitoring statków powietrznych. Central Route Charges Office ‐ Centralne Biuro Opłat Trasowych ‐ biuro w strukturach EUROCONTROL zajmujące się odzyskiwaniem kosztów usług zarządzania ruchem lotniczym (ATM) dostępnych dla użytkowników przestrzeni powietrznej. Centralny Rejestr Umów. Czas, wyrażony w latach, w którym — odpowiednio przy niezmienionych zasobach osobowych Zespołu Audytów — zostałyby przeprowadzone zadania audytowe we wszystkich obszarach ryzyka. Wydzielona pod względem funkcjonalnym część Systemu, która będzie wdrażana łącznie (dopuszcza się możliwość wdrażania Systemu w częściach).
Demilitarized Zone ‐ strefa ograniczonego zaufania (zdemilitaryzowana) – strefa w architekturze Systemów teleinformatycznych, w której umieszcza się zwykle urządzenia świadczące usługi dla użytkowników/systemów zewnętrznych. Wybrana w przetargu firma Comarch Polska S.A. realizująca umowę z PAŻP obejmującą następujące usługi doradcze: a) opracowania Koncepcji Systemu i określenia sposobu wdrożenia Systemu wspomagającego zarządzenie PAŻP, b) wyboru Dostawcy Systemu, a tym samym Systemu, c) nadzoru nad wykonaniem i wdrożeniem Systemu przez Dostawcę Systemu. Wykonawca wybrany w wyniku niniejszego postępowania przetargowego, który wykona System i przeprowadzi jego wdrożenie. Elektroniczny Obieg Dokumentów. Rodzaj systemu informatycznego, który pozwala na przetwarzanie określonych dokumentów elektronicznych przez użytkowników przy wykorzystaniu zaawansowanych mechanizmów takich jak kontrola postępu prac, dostępu do danych, tworzenia meta danych dokumentów, przywiązanie dokumentów do procesów. Enterprise Performance Management ‐ obszar Business Intelligence umożliwiający kontrolę i zarządzanie wydajnością organizacji, mając na uwadze kluczowe wskaźniki efektywności (ang. Key Performance Indicators, KPI) takie jak zysk, zwrot z inwestycji, a także koszty operacyjne, obejmuje wszystkie praktyki, technologie, metodyki i miary używane do zbierania i zatwierdzania informacji. Systemy CPM posiadają takie moduły jak prognozowanie, budżetowanie czy planowanie, umożliwiają także dostęp do wizualnie przedstawionych zrównoważonych kart wyników, a także kokpitów managerskich przedstawiających w przejrzysty sposób każdą informację. Elektroniczny Raport Kierownika Zmiany. System ewidencji zdarzeń związanych z eksploatacją infrastruktury wspierającej działalność nawigacyjną Zamknięta część Projektu określona szczegółowo w rozdziale 5.4 oraz w Projekcie Technicznym – numeracja etapów dla niniejszego zamówienia uwzględnia fakt, że zamówienie to jest częścią prowadzonego w PAŻP projektu, dla którego realizacja Strona 10 z 285
Pojęcie Opis
zamówienia będzie stanowiła etap piąty, stąd numery etapów użyte w niniejszym Opisie Przedmiotu zamówienia zostały określone odpowiednio jako 5.1, 5.2, etc. EUROCONTROL Międzynarodowa organizacja zrzeszająca państwa europejskie w celu zapewnienia bezpieczeństwa, wydajności oraz ochrony środowiska przez dostawców usług nawigacyjnych w regionie europejskim. FACT Plik txt zawierający listę faktur wystawionych przez CRCO za usługi nawigacji trasowej. Billing Documents reflecting States portion ‐ szczegółowe zestawienie wszystkich dokumentów finansowych (faktur, not korygujących do faktur, not odsetkowych za spóźnione wpłaty i not korygujących noty odsetkowe za spóźnione wpłaty) wystawionych w danym okresie rozliczeniowym uwzględniających poprzednie okresy rozliczeniowe. FLBZ Plik generowany przez CRCO zawierający listę operacji lotniczych (na poziomie lotu). Flights Billed or Credited for a State ‐ szczegółowe zestawienie wszystkich usług wykonanych w danym okresie rozliczeniowym z uwzględnieniem usług korygowanych z poprzednich okresów rozliczeniowych. Gwarancja Jakości Patrz paragraf 13 Istotnych Postanowień Umowy. ICAO International Civil Aviation Organization ‐ Międzynarodowa Organizacja Lotnictwa Cywilnego. Organizacja ustalająca normy oraz przepisy bezpieczeństwa lotniczego. Infrastruktura IT Sprzęt komputerowy (stacje robocze, monitory, notebooki), oprogramowanie biznesowe, serwery związane z zastosowaniami ogólnymi i biznesowymi, i urządzenia peryferyjne (drukarki, skanery), z wyłączeniem: systemów informatycznych służących wsparciu zarządzania ruchem lotniczym (ATM/CNS) oraz sieci informatycznych. Inne Elementy Wszelkie inne niż Oprogramowanie Autorskie produkty wytworzone przez Dostawcę w Autorskie ramach projektu, do których Dostawca Systemu przeniesie na Zamawiającego autorskie prawa majątkowe, w szczególności: plany, dokumenty zarządcze, wszelka dokumentacja, definicje raportów (o ile nie są Oprogramowaniem Autorskim), scenariusze testów, materiały szkoleniowe, instrukcje, itp. KDK Karta działań korygujących. KDZ Karta działań zapobiegawczych. Kluczowy Użytkownik Osoba – użytkownik, który zna podległy sobie obszar Systemu i umie nauczyć w jego zakresie obsługi Systemu inną osobę – Użytkownika. Użytkownik wiodący w obszarze wybranego modułu funkcjonalnego zintegrowanego systemu informatycznego. Jego szczególna rola pojawia się na etapie wdrażania systemu informatycznego, kiedy w pierwszej kolejności poddawany jest szkoleniu z ogólnej funkcjonalności wdrażanego systemu, a następnie sam szkoli użytkowników końcowych. Odpowiedzialny jest także za przeprowadzenie szkoleń pozostałych Użytkowników Systemu, a w szczególności nowych pracowników. Komponent Wydzielony logicznie fragment Systemu obejmujący różne rozwiązania zintegrowane w ramach jednej platformy. Z uwagi na fakt, że różni producenci dostarczają różne pakiety oprogramowania realizujące podobne funkcje w ramach architektury funkcjonalnej przyjęto pojęcie komponentu, aby uniezależnić opis funkcjonalny od istniejących na rynku konkretnych rozwiązań. Kontrola wewnętrzna Działania wykonywane przez jednostkę organizacyjną wykonującą zadania kontrolne, na podstawie planu kontroli jak i na podstawie doraźnych zleceń kierownictwa, polegające na weryfikacji prowadzonych w organizacji działań pod katem ich zgodności z prawem i Strona 11 z 285
Pojęcie Opis
regulacjami wewnętrznymi oraz procedurami. KOSP Kompetencyjny Opis Stanowisk Pracy. Kostka OLAP (ang. OnLine Analytical Processing) – wielowymiarowa struktura danych pozwalająca na szybką analizę danych. Mapa docelowych Obraz przedstawiający wszystkie procesy biznesowe oraz ich powiązania, realizowane u procesów Zamawiającego w celu wytworzenia finalnych produktów bądź usług w wersji „jakie są”, biznesowych w wersji „jakie powinny być” oraz w wersji przyjętej do realizacji, wraz z opisem sposobu przejścia od procesów „jakie są” do procesów docelowych. Produktem wdrożenia będzie mapa procesów docelowych, które będą wspierane przez System (tj. w wersji optymalnego z uwagi na prowadzony biznes przebiegu procesów w nowym Systemie informatycznym). Mechanizm Przez mechanizm wyrównania ryzyka należy rozumieć: wyrównania ryzyka 1. metodę odzyskiwania salda wynikającego z niepełnego lub nadmiernego pokrycia kosztów w poprzednich latach zgodnie z Rozporządzeniem Komisji (WE) Nr 1794/2006 z dnia 6 grudnia 2006 r. ustanawiającego wspólny schemat opłat za korzystanie ze służb żeglugi powietrznej; 2. mechanizm podziału ryzyka związanego z ruchem, zgodnie z Art. 13 Rozporządzenia wykonawczego Komisji (UE) Nr 391/2013 z dnia 3 maja 2013 r. ustanawiającego wspólny system opłat za korzystanie ze służb żeglugi powietrznej; 3. mechanizm podziału ryzyka związanego z kosztami, o którym mowa w Art. 14 Rozporządzenia wykonawczego Komisji (UE) Nr 391/2013 z dnia 3 maja 2013 r. ustanawiającego wspólny system opłat za korzystanie ze służb żeglugi powietrznej. Migracja danych Jednorazowy proces mający na celu zasilenie bazy danych nowego Systemu danymi przechowywanymi w rejestrach elektronicznych dotychczasowego rozwiązania. Migracji nie należy mylić z konfiguracją systemu. W ramach konfiguracji czasami wykorzystuje się Migrację w celu zasilenia systemu w dane konfiguracyjne (słownikowe), których liczebność uniemożliwia ręczne wprowadzenie ich zapis po zapisie, a istnieje dla nich elektroniczna ewidencja. Migracja produkcyjna Jest to migracja danych, po której rozpoczyna się pracę produkcyjną w nowym Systemie (często w obszarach stosuje się pracę równoległą w nowym i starym systemie przez pewien czas). Migracja testowa Jest to migracja danych, której celem jest przetestowanie procedur eksportu/importu danych, procedur czyszczenia, uzupełniania, agregacji danych, procedur weryfikacji danych. Migracja testowa powinna być wykonywana na pełnych danych, jednak w obszarach, w których to nie jest wskazane z uwagi na duży nakład pracy związany z przygotowaniem pełnego zakresu danych do migracji lub nie jest to możliwe (np. w przypadku danych księgowych, które wymagają zamknięcia danych w starym systemie) zakłada się, że migracja testowa będzie wykonana na reprezentatywnej próbce danych. MIL Lot wojskowy. MIiR Ministerstwo Infrastruktury i Rozwoju, zastąpiło wcześniejsze MTBiGM. Moduł Patrz Moduł logiczny. Moduł logiczny Wydzielony logicznie zbiór funkcjonalności systemu powiązanych tematycznie ze sobą. Nie stanowi fizycznej aplikacji (modułu) programowej. MPK Miejsce Powstawania Kosztów. MTBF Mean Time Between Failures ‐ Czas bezawaryjnej pracy urządzeń. MTBiGM Ministerstwo Transportu Budownictwa i Gospodarki Morskiej. – występje wyłącznie w Strona 12 z 285
Pojęcie MTBO Nadzór Niezgodność NOTAM Obszar testowania Oblot Oprogramowanie Aplikacyjne Oprogramowanie Autorskie Oprogramowanie Standardowe OPZ OSL PAŻP PKBWL PKZP Plan audytu Plan Testów Opis
aktach prawnych, obecnie jego rolę przejęło Ministerstwo Infrastruktury i Rozwoju Mean Time Between Overhaul ‐ Czas ciągłej (bez przerw) pracy urządzeń. Nadzór pełniony przez Doradcę nad wykonaniem, dostawą i wdrożeniem Systemu przez wybranego Dostawcę Systemu. Niespełnienie wymagania. Wydawana na żądanie zwięzła depesza telekomunikacyjna Kierownictwa Lotów (ATM) rozpowszechniana za pomocą środków telekomunikacyjnych, zawierająca informacje (nt. ustanowienia, stanu lub zmian urządzeń lotniczych, służb, procedur, a także o niebezpieczeństwie), których znajomość we właściwym czasie jest istotna dla personelu związanego z operacjami lotniczymi. Konkretny rodzaj Testów akceptacyjnych. Usługa kontroli z powietrza lotniczych urządzeń zabezpieczenia ruchu lotniczego wykonywana przez samolot kontrolno‐pomiarowy należący do PAŻP. Oprogramowanie standardowe dostarczające typowe dla systemów ERP/BI/EPM funkcjonalności. Nie są Oprogramowaniem Aplikacyjnym systemy operacyjne, oprogramowanie antywirusowe, serwery aplikacji czy bazy danych. Patrz definicja w paragrafie 2 Istotnych Postanowień Umowy. Poprzez Oprogramowanie Autorskie rozumie się elementy oprogramowania wytworzone na potrzeby uruchomienia Systemu wraz z nośnikami, dokumentacją techniczną i kodami źródłowymi, do których Dostawca Systemu przenosi na Zamawiającego autorskie prawa majątkowe na warunkach opisanych w Umowie. Patrz definicja w paragrafie 2 Istotnych Postanowień Umowy. Oprogramowaniem Standardowym są wszelkie programy komputerowe w postaci kodu wynikowego, do których autorskie prawa majątkowe przysługują osobom trzecim, a na które Dostawca Systemu udzieli Zamawiającemu licencji lub sublicencji oraz nośniki, dokumentacje i aktualizacje takich programów komputerowych, niezbędne do działania Systemu, w tym: a) Oprogramowanie Aplikacyjne b) systemy operacyjne, c) oprogramowanie bazodanowe i narzędziowe. Opis Przedmiotu Zamówienia. Ośrodek Szkolenia Lotniczego. Polska Agencja Żeglugi Powietrznej – Zamawiający. Państwowa Komisja Badań Wypadków Lotniczych działająca przy Ministerstwie Transportu Budownictwa i Gospodarki Morskiej, do której zadań należy badanie wypadków i poważnych incydentów lotniczych w celu ustalenia ich okoliczności i przyczyn oraz przedsięwzięcia wszelkich środków dla zapobiegania wypadkom w przyszłości. Pracownicza Kasa Zapomogowo‐Pożyczkowa. Zestaw audytów, jednego lub większej ich liczby, zaplanowanych w określonych ramach czasowych i mających określony cel. Plan audytów przygotowywany jest raz w roku. Dokument opisujący zakres, metody, zasoby oraz harmonogram zamierzonych czynności testowych opracowany na podstawie i zgodnie z Ramowym Planem Testów zawartym w Projekcie Technicznym. Strona 13 z 285
Pojęcie Podetap Opis
Zamknięta część Etapu określona szczegółowo w rozdziale 5.4 oraz Projekcie Technicznym. Podsystem Logiczny podsystem obejmujący funkcjonalność modułów powiązanych tematycznie ze sobą.
Pojedynczy punkt Miejsce w Systemie lub jego komponent (sprzętowy), którego awaria powoduje awarii niedostępność Systemu lub podsystemu. Proces Biznesowy Uporządkowany zbiór czynności zainicjowanych przez jedno lub kilka zdarzeń wejściowych, w wyniku, których powstaje wartość dodana dla klientów PAŻP. Proces biznesowy, wykorzystując określone mechanizmy, transformuje zasoby w konkretny produkt końcowy. Proces ETL (ang. extraction, transformation, loading) ‐ ekstrakcja, transformacja i ładowanie danych) – proces zasilania hurtowni danych polegający na pobraniu danych i ich oczyszczeniu lub transformacji wg reguł biznesowych, a następnie „załadowaniu” do docelowej bazy danych. Procesor (x86) Pojedynczy Chip (układ elektroniczny zamknięty w hermetycznej obudowie posiadający rozbudowany system wyprowadzeń) wykonany zgodnie z architekturą x86 posiadający jedną lub więcej jednostek obliczeniowych (rdzeni (core)). Produkt Wynik realizacji określonych zadań w ramach projektu. Produkty dzieli się na zarządcze i specjalistyczne. Produktem może być dokument, element oprogramowania lub infrastruktury. Produktem może też być wynik prac np. realizacja testów lub szkoleń. Projekt W Agencji funkcjonują dwa znaczenia: 1. Całokształt działań, których celem jest wdrożenie Systemu. 2. Przedsięwzięcie inwestycyjne lub rozwojowe realizowane w trybie regulowanym przez rozporządzenia wewnętrzne PAŻP: KP‐INWEST i KP‐PEOJEKT. Projekt Techniczny Wynik prac etapu 5.1 opisany w rozdziale 9.1.2 oraz zdefiniowany w paragrafie 2 Istotnych Postanowień Umowy oraz ustęp 7 paragrafu 9 Istotnych Postanowień Umowy. Protokół Odbioru Dokument potwierdzający prawidłowe i rzetelne wykonanie prac określonych dla danego Etapu Etapu. Protokół Odbioru Dokument potwierdzający rzetelne, prawidłowe zrealizowanie całości przedmiotu Końcowego umowy. PRU Performance Review Unit – PRU jest kategorią planistyczną, określoną regulacjami EUROCONTROL, związaną z raportowaniem kosztów działalności nawigacyjnej Przypadek testowy Zbiór wejść, warunków początkowych oraz oczekiwanych wyników warunków końcowych niezbędnych do wykonania testu. QNT Obecnie funkcjonujący System kadrowo‐płacowy. QUINTIQ System planowania i rozliczania czasu pracy pracowników Agencji. Ramowy Plan Testów Element Projektu Technicznego definiujący metodykę procesu testowania, kategoryzację błędów wynikłych w procesie testowania i wszelkie elementy niezbędne do opracowania Planów Testów dla poszczególnych Obszarów Testowania. Raport z testów Dokument przedstawiający działania testowe i ich rezultaty dla każdego rodzaju przeprowadzonych testów. Zawiera także ocenę testowanych elementów pod względem zgodności z kryteriami wyjścia. Reprezentant Osoba wyznaczona ze strony Zamawiającego do reprezentowania przyszłych Strona 14 z 285
Pojęcie Obszaru Opis
użytkowników z danego obszaru funkcjonalnego PAŻP w określaniu wymagań, potrzeb i oczekiwań wobec przyszłego Systemu, a także do współpracy z Zespołem Projektowym Zamawiającego, Doradcą i Dostawcą Systemu podczas całego Projektu w szczególności w zakresie odbioru Produktów Projektu. RLUN Rejestr Lotniczych Urządzeń Naziemnych. ROT Remonty i Obsługa Techniczna. Rozszerzenie Funkcjonalności wykraczające poza typowe rozwiązania dostępne w oprogramowaniu standardowym ERP/BI/EPM etc., a wymagane do realizacji w ramach Projektu. Rozszerzenie może być zrealizowane przez Dostawcę jako Oprogramowanie Autorskie. RWZ Rejestr Wniosków Zakupowych ‐ aplikacja wykorzystywana przez Zamawiającego. Scenariusz testowy Zbiór kroków testowych, których wykonanie jest potrzebne do sprawdzenia poprawności działania określonych systemów. SIWZ Specyfikacja Istotnych Warunków Zamówienia. Skrypt testowy Nazwa specyfikacji procedury testowej, która pozwala na automatyzację przypadków testowych. System Patrz definicja w paragrafie 2 Istotnych Postanowień Umowy. Środowisko Sprzęt i oprogramowanie zainstalowane w siedzibie Zamawiającego, w którym System produkcyjne będzie używany. Środowisko Odpowiednio skonfigurowane i utrzymywane otoczenie (sprzęt i oprogramowanie), rozwojowe w którym System jest rozwijany. Środowisko testowe Odpowiednio skonfigurowane i utrzymywane otoczenie (sprzęt i oprogramowanie), zawierające dane testowe, w którym możliwe jest wykonanie testów w sposób powtarzalny i zarządzalny. Testy akceptacyjne Testy, których celem jest uzyskanie formalnego potwierdzenia wykonania Systemu bądź jego elementów odpowiedniej jakości. Na testy akceptacyjne składają się testy funkcjonalne, testy integracyjne, testy użyteczności, testy bezpieczeństwa. Jako testy akceptacyjne rozumiane są również testy sprzętu, testy regresji oraz testy wydajnościowe. Testy bezpieczeństwa Polegają na poszukiwaniu niezamierzonych skutków ubocznych, które przez luki w bezpieczeństwie stwarzają zagrożenie dla niezakłóconego działania Systemu. Testy funkcjonalne Testy, których celem jest sprawdzenie Systemu pod kątem wymagań funkcjonalnych i zweryfikowaniu czy aplikacja zachowuje się w oczekiwany sposób. Testy integracji Testy wykonywane w celu wykrycia błędów w interfejsach i interakcjach pomiędzy integrowanymi elementami. Testy regresji Powtarzalne testy na już przetestowanym programie, po modyfikacjach, w celu wykrycia innych defektów wprowadzonych lub nieodkrytych podczas "naprawy". Testy urządzeń Testy polegające na sprawdzeniu poprawności działania Urządzeń serwerowych, serwerowych stanowiących platformę sprzętową Systemu Testy użyteczności Testy mające na celu sprawdzenie ergonomii rozwiązania oraz jego estetyki pod kątem zgodności z odpowiednimi wymaganiami określonymi w rozdziale 2.1 Testy wydajnościowe Testy, których celem jest uzyskanie formalnego potwierdzenia spełnienia wymagań wydajnościowych przez System i jego elementy. ULC Urząd Lotnictwa Cywilnego. Uruchomienie Moment, w którym następuje uruchomienie całości bądź fragmentu funkcjonalności Strona 15 z 285
Pojęcie Opis
produkcyjne systemu Systemu rozumiane, jako umożliwienie korzystania przez Użytkowników Systemu z całości bądź fragmentu Systemu w środowisku produkcyjnym, w którym przetwarzane są rzeczywiste dane gospodarcze Zamawiającego. Na moment uruchomienia produkcyjnego System musi być w pełni skonfigurowany: posiadać założonych użytkowników z nadanymi uprawnieniami, dane powinny być całkowicie zmigrowane. Z reguły w początkowym okresie od uruchomienia Systemu (przyjmuje się 2‐3 miesiące) praca przebiega w dwóch systemach, starym i nowym, w celu uzgodnienia danych i potwierdzenia ostatecznie prawidłowego działania nowego Systemu. Uruchomienie produkcyjne uważa się za dokonane po pozytywnym zakończeniu uzgodnienia danych. Urządzenia Serwery, urządzenia sieciowe, macierze, szafy rack oraz okablowanie niezbędne do serwerowe prawidłowej pracy tych urządzeń. Użytkownik Osoba nie przypisana imiennie do licencji oprogramowania, która może korzystać z Jednoczesny danego oprogramowania w ramach dostępnej puli licencji. Użytkownik Nazwany Osoba przypisana imiennie do danej licencji oprogramowania. Użytkownik Kluczowy Patrz Kluczowy Użytkownik. Użytkownik Systemu Osoba pozostająca w interakcji z Systemem w celu umożliwienia jego działania oraz wykorzystania jego funkcji. Walidacja Potwierdzenie, poprzez przebadanie i dostarczenie oczywistego dowodu, że konkretne wymagania w stosunku do specyficznego, zamierzonego użycia są spełnione. Weryfikacja Potwierdzenie, poprzez przebadanie i dostarczenie oczywistego dowodu, że konkretne wymagania zostały spełnione. Właściciel Obszaru Osoba wyznaczona ze strony Zamawiającego do reprezentowania przyszłych użytkowników z podległych obszarów funkcjonalnych PAŻP oraz do podejmowania strategicznych decyzji co do zakresu i funkcji Systemu w podległych obszarach. Właściciel Obszaru zatwierdza wymagania i potrzeby w podległych obszarach wobec przyszłego Systemu, jak również odpowiada za eliminację sprzecznych wymagań, zapewnienie zasobów do współpracy z Zespołem Projektowym Zamawiającego, Doradcą i Dostawcą Systemu podczas całego Projektu, a także uczestniczy w odbiorze Produktów Projektu. Wykonawca Patrz Dostawca Systemu. Zadania audytowe Wszelkie zadania realizowane przez komórkę audytu wewnętrznego mające na celu ocenę prowadzonych działań i ich zgodności z określonymi normami regulującymi postępowanie w danym zakresie spraw, jak również mające na celu doprowadzenie działań do stanu zgodnego z normami lub utrzymanie takiego stanu, bądź podniesienie poziomu zgodności. Zadania audytowe w zależności od rodzaju wykonywanego audytu dzielimy na:
‐ zadania zapewniające, ‐ zadania doradcze, ‐ zadania sprawdzające. Zadania doradcze Doradztwo i pokrewne działania usługowe dla PAŻP, których charakter i zakres są uzgodnione z wnioskodawcą. Celem zadań doradczych jest przysporzenie wartości dodanej oraz usprawnienie procesów ładu organizacyjnego, zarządzania ryzykiem i kontroli funkcjonalnej z zachowaniem zasady, że audytor wewnętrzny prowadzący czynności doradcze nie przyjmuje na siebie odpowiedzialności kierownictwa. Przykładami takich usług są konsultacje, doradztwo, usprawnienie oraz szkolenia. Zadania inwestycyjne Zadania ujęte w Planie Inwestycyjnym PAŻP. Strona 16 z 285
Pojęcie Zadania sprawdzające (czynności sprawdzające) Zadania zapewniające ZSZ Opis
Zespół czynności, których celem jest ustalenie czy i w jakim stopniu podjęto kroki zmierzające do wprowadzenia w życie zaleceń zgłoszonych w wyniku przeprowadzonego audytu. Działanie obejmujące zebranie i obiektywną ocenę dowodów, dokonaną przez audytora wewnętrznego w celu dostarczenia niezależnej opinii lub wniosków w odniesieniu do jednostki, operacji, funkcji, procesu, systemu lub innego zagadnienia. Zintegrowany System Zarządzania (zgodny z normami: PN‐EN ISO 14001:2004, PN‐N 18001:2004 oraz PN‐EN ISO 9001:2008) wdrożony i funkcjonujący w PAŻP. Tabela 1 Słownik pojęć 1.6
Główne elementy docelowego Systemu
Niniejszy rozdział opisuje koncepcję architektury Systemu. Zakłada się, że architektura Systemu posiadać będzie budowę modułową, oznacza to między innymi, że struktura Systemu będzie składać się z logicznych komponentów, a w ich ramach modułów, realizujących zadane funkcjonalności. Należy zaznaczyć, że zawarty w Opisie Przedmiotu Zamówienia podział na moduły stanowi jedynie podział porządkowy. Zamawiający dopuszcza zaoferowanie przez Dostawcę Systemu rozwiązania, w którym wymagania przyporządkowane w niniejszym Opisie Przedmiotu Zamówienia do konkretnych modułów zawarte będą w innych modułach lub komponentach zaoferowanego Systemu. Zamawiający wymaga spełnienia wszystkich wyspecyfikowanych wymagań kategorii Wymagalne oraz wszystkich zaoferowanych przez Dostawcę wymagań Opcjonalnych. Szczegółowe przypisanie wymagań funkcjonalnych do modułów i komponentów nastąpi w etapie Analiza i Projekt Techniczny (etap 5.1). Dotyczy to określenia spełnienia wszystkich wymagań, a szczególnie tych spośród nich, których obsługa może być przypisana na wiele sposobów do różnych funkcji Systemu. W takim przypadku dostawca zobowiązany jest do przedstawienia w Projekcie Technicznym korzyści i różnic poszczególnych wariantów realizacji wymagań i uzasadnienia wykorzystania w danym przypadku mechanizmów wybranego komponentu. Zgodnie z punktem 8 paragrafu 9 Istotnych Postanowień Umowy, Zamawiający może po przedstawieniu Projektu Technicznego w celu odbioru etapu 5.1, zażądać dokumentacji Oprogramowania Standardowego potwierdzającej możliwość realizacji wybranego wymagania, lub zażądać prezentacji możliwości realizacji wybranego wymagania zarówno w przypadku Oprogramowania Standardowego, jak i w przypadku Oprogramowania Autorskiego – w formie prototypu lub makiety. Wymaga się, aby docelowy System składał się z następujących komponentów: Nazwa komponentu
Kategoria
Opis
ERP Wymagalny Komponent grupujący funkcjonalności przypisane do systemu klasy ERP. Szczegółowa architektura tego komponentu została opisana w ramach rozdziału 1.4.1. EOD Wymagalny Komponent grupujący funkcjonalności przypisane do systemu EOD (Elektroniczny Obieg Dokumentów). Szczegółowa architektura tego komponentu została opisana w ramach rozdziału 1.4.2. BI/EPM Wymagalny Komponent grupuje funkcjonalność systemów klasy BI oraz EPM. Stanowi pokrycie potrzeb raportowych Systemu w ramach funkcji raportowania zarządczego, jak również zawiera możliwość obsługi procesu planowania oraz kalkulacji stawek. Wyodrębnienie funkcji planowania i raportowania w logicznym komponencie Strona 17 z 285
BI/EPM nie wyklucza umiejscowienia narzędzi planowania i raportowania w pozostałych komponentach Systemu. Komponent BI/EPM obejmuje funkcjonalność rozwiązań zapewniających: a) Rozwiązanie klasy BI umożliwiające między innymi: a. elastyczne raportowanie zarządcze w oparciu o dane pochodzące z różnych źródeł, b. wielowymiarową i wielowariantową analizę opartą na hurtowni danych, c. tworzenie bibliotek raportów, d. tworzenie pulpitów zarządczych, e. zarządzanie wskaźnikami, f. zaawansowane techniki prezentacji danych; b) Rozwiązanie klasy EPM zapewniające: a. Planowanie krótkoterminowe i długoterminowe działalności Agencji. b. Kalkulację modelu baz kosztowych w oparciu o rachunek kosztów działań. c. Konsolidację planów operacyjnych na potrzeby tworzenia planu finansowego Agencji. d. Spójność, kompletność i walidację danych używanych w procesie planowania. e. Kontrole poprawności wykonania procedur w procesie planowania. f. Wsparcie planowania strategicznego i operacyjnego. g. Odpowiadającą potrzebom Zamawiającego dokładność i szczegółowość planowania. h. Prognozowanie i planowanie sprzedaży na podstawie prognoz CRCO i.
Planowanie pozostałej sprzedaży. j.
Zarządzanie rentownością i kosztami – poprzez dostarczenie szczegółowej informacji o kosztach w szczegółowym modelu wykraczającym poza linie produktów, obszary usług, i segmenty klientów; k. Tworzenie budżetów w układzie odpowiadającym strukturom odpowiedzialności. c) Hurtownię danych – baza danych przechowująca dane wielowymiarowe w układzie kostek OLAP wraz z narzędziami zapewniającymi zasilanie hurtowni z Systemu jak również z innych systemów funkcjonujących w PAŻP (procesy ETL). Strona 18 z 285
Portal pracowniczy Wymagalny Portal pracowniczy stanowi ważny komponent architektury funkcjonalnej przyszłego Systemu. Portal pracowniczy zapewni funkcjonalność dla: a) Procesu rekrutacji zewnętrznej – umożliwiając kandydatom składanie aplikacji, zapewniając kanał komunikacyjny służb kadrowych z kandydatem; b) Proces rekrutacji wewnętrznej – umożliwi kierownikom wnioskowanie o vacaty i zapewni wsparcie dla procesu rekrutacji wewnętrznej; c) Proces obsługi szkoleń – umożliwi pracownikom PAŻP dostęp do oferty szkoleniowej, obsługę zapotrzebowań na szkolenia, obsługę szkoleń wewnętrznych i zewnętrznych; d) Proces oceny okresowej – umożliwi sprawną obsługę procesu zarówno od strony służb kadrowych, jak i pracowników i ich przełożonych; e) Dostęp pracownika do jego własnych danych kadrowych, płacowych oraz świadczeń Zakładowego Funduszu Świadczeń Socjalnych; f) Wsparcie dla procesów wniosków urlopowych może mieć początek w Portalu, po czym dalsza obsługa może być wykonywana przez komponent EOD lub ERP w sposób zgodny z procedurami PAŻP; g) Zgłaszania delegacji krajowych i zagranicznych ‐ może mieć początek w Portalu, po czym dalsza obsługa może być wykonywana przez komponent EOD lub ERP w sposób zgodny z procedurami PAŻP; h) Udostępnianie publicznych danych w Intranecie (np. książki telefonicznej pracowników PAŻP). Tabela 2. Lista komponentów Systemu 1.6.1
Opis modułów komponentu ERP
W ramach komponentu ERP w poniższej tabeli przedstawiono logiczne Moduły funkcjonalne składające się na architekturę tego komponentu. Moduły te obejmują funkcjonalności używane często w wielu obszarach, tak więc zarówno ich umiejscowienie w strukturze komponentu ERP jak i nazwy wynikają z ogólnych standardów opisu logicznego systemów ERP. Szczegółowe wymagania funkcjonalne zostały opisane w rozdziale 2.2. Nazwa modułu
Kategoria
Opis
Moduły wspólne Moduł Administratora Wymagalny Moduł obejmujący funkcjonalność zarządzania użytkownikami i uprawnieniami oraz istotnymi parametrami konfiguracji Systemu. Kartoteka kontrahentów Wymagalny Moduł obejmujący funkcjonalność ewidencji danych kontrahentów (dostawców, odbiorców, itp.) zarówno osób fizycznych, osób prawnych jak i innych podmiotów, z którymi Agencja posiada rozrachunki, posiadała rozrachunki lub potencjalnie będzie posiadać rozrachunki. Moduł obejmie także funkcjonalność umożliwiającą synchronizację istniejących danych kontrahentów między Systemem, a rejestrem odbiorców, prowadzonym przez CRCO (baza BREF). Centralny Rejestr Umów Wymagalny Moduł obejmujący funkcjonalność ewidencji i zarządzania umowami z różnych obszarów funkcjonalnych za wyjątkiem umów o pracę oraz umów cywilno‐
prawnych funduszu bezosobowego. Struktura organizacyjna Wymagalny Moduł obejmujący funkcjonalność zarządzania strukturą organizacyjną Agencji Zarządzanie słownikami Wymagalny Moduł obejmujący funkcjonalność obsługi słowników wykorzystywanych w różnych miejscach Systemu. Projekty Wymagalny Moduł logiczny obejmujący funkcjonalności obsługi projektów, w tym Strona 19 z 285
w szczególności: planowania projektów, realizacji projektów oraz zarządzania projektami. Moduł musi być ściśle zintegrowany z modułem Inwestycje w zakresie zadań inwestycyjnych realizowanych projektowo. Raportowanie Wymagalny Moduł ten przeznaczony jest do wsparcia raportowania typu operacyjnego w procesach obsługiwanych przez poszczególne funkcje komponentu ERP. Składa się z zestawu raportów standardowych – oprogramowanych i dostarczanych wraz z instalacją Systemu, oraz z funkcjonalności generowania definiowalnych raportów i zestawień na podstawie danych dostępnych w systemie ERP. Zarządzanie Personelem Kadry Wymagalny Moduł zapewnia obsługę danych kadrowych pracowników oraz osób wynagradzanych w ramach funduszu bezosobowego. Ewidencja i zarządzanie danymi wymaganymi przepisami prawa, tzw. „twarda część HR”, zarządzanie czasem pracy i absencjami. Płace Wymagalny Moduł obejmuje obsługę algorytmów wyliczania składników wynagrodzeń, naliczanie list płac, korekty list płac, współpracę z bankiem, obligatoryjną sprawozdawczość, dane do podatku dochodowego od osób fizycznych, analizę wynagrodzeń w części obsługiwanej przez ERP. Zarządzanie personelem Wymagalny Moduł zapewnia funkcjonalność tzw. miękkiego HR i obejmuje zestaw funkcjonalności związanych z rozwojem personelu, w szczególności obsługę oceny okresowej. Sprawy socjalne Wymagalny Moduł zapewnia obsługę funduszu socjalnego i świadczeń socjalnych. Rekrutacja Wymagalny Moduł obejmuje funkcjonalności związane z obsługą procesów rekrutacji wewnętrznej i zewnętrznej. Szkolenia Wymagalny Moduł zapewnia wsparcie dla procesów szkoleń wewnętrznych i zewnętrznych. Finanse i Księgowość Księgowość Wymagalny Moduł obejmujący funkcjonalność zarządzania księgami rachunkowymi, okresami sprawozdawczymi, planem kont, dziennikiem księgowym, wymaganymi rejestrami oraz obsługujący wszystkie wymagane przepisami prawa operacje, raporty (np. zestawienie obrotów i sald, wydruk dziennika, karta kontowa, itp.). Rozrachunki Wymagalny Moduł obejmujący funkcjonalność zarządzania rozrachunkami (należnościami i zobowiązaniami) obsługę banku i kasy, oraz obsługę zaliczek, przedpłat, potwierdzeń sald, rozliczanie delegacji, finansową obsługę umów ubezpieczeniowych, rozrachunki z pracownikami. Podatki Wymagalny Moduł obejmujący funkcjonalność obsługi podatków dochodowych, akcyzowych, opłat celnych, podatków lokalnych oraz podatku od towarów i usług, prowadzenie wymaganych rejestrów i generowanie wymaganych deklaracji podatkowych. Windykacja Wymagalny Moduł obejmujący funkcjonalność generowania monitów i not odsetkowych jak również obsługę spraw windykacyjnych
Środki Trwałe Wymagalny Moduł obejmujący ewidencję księgową środków trwałych, wartości niematerialnych i prawnych, środków niskocennych oraz wyposażenia w wymaganym zakresie wraz z pełną obsługą (np. zmiany – dowody obrotowe, likwidacja, inwentaryzacja, naliczanie amortyzacji, inwentaryzacja, księgowanie operacji, itp.) Planowanie i Sprawozdawczość Wymagalny Moduł obejmujący funkcjonalność operacyjnego planowania finansowego i kontroli budżetu oraz sprawozdawczości, zwłaszcza sprawozdawczości wymaganej przepisami prawa. Zarządzanie Majątkiem Ewidencja Nieruchomości Wymagalny Ewidencja i zarządzanie nieruchomościami w powiązaniu z ewidencją środków trwałych, prowadzenie książki nieruchomości, zarządzanie opłatami związanymi z Strona 20 z 285
nieruchomościami.
Ewidencja Samochodów Wymagalny Ewidencja i zarządzanie pojazdami i ich wyposażeniem, gospodarka oponami, obsługa kart drogowych (rozliczanie paliwa i przejechanych kilometrów), obsługa polis ubezpieczeniowych.
Ewidencja infrastruktury technicznej Wymagalny Ewidencja infrastruktury w tym infrastruktury CNS/ATM, prowadzenie elektronicznych ksiąg urządzeń (obiektów), ewidencja zużycia mediów dla składników infrastruktury, obsługa technicznego forum dyskusyjnego. Remonty i Obsługa Techniczna Wymagalny Planowanie remontów, przeglądów i modernizacji składników majątkowych, rozliczanie remontów, szacowanie kosztów remontów, realizacja przeglądów, rejestracja i obsługa zdarzeń, awarii, szkód komunikacyjnych dla pojazdów, zarządzanie pomiarami, gwarancjami, zarządzanie częściami zamiennymi. Zarządzanie Sprzedażą Sprzedaż usług pozanawigacyjnych Wymagalny Obsługa sprzedaży, zarządzanie cennikami, rabatami, rozliczanie umów. System musi posiadać interfejsy pozwalające w przyszłości na jego integrację z aplikacją e‐
Sklepu. Sprzedaż usług nawigacyjnych Wymagalny Wydzielona funkcjonalność modułu Sprzedaż, obsługująca proces sprzedaży usług nawigacyjnych (trasowych i terminalowych), z uwagi na konieczność dostosowania do obsługi branżowej funkcjonalności i fakturowania z wykorzystaniem danych z CRCO. Rejestr Lotów Zwolnionych Wymagalny Dodatkowy rejestr lotów zwolnionych z opłat wydzielony jako moduł logiczny, funkcjonalność przygotowania wniosku o zwrot kosztów. Zamówienia obce Wymagalny Obsługa zamówień od odbiorców. Zarządzanie zakupami Zakupy Wymagalny Obsługa zleceń zakupu w powiązaniu z budżetem, obsługa Wniosku o udzielenie zamówienia (WOUZ), ewidencja faktur zakupowych, planowanie zakupów, realizacja zakupów w powiązaniu ze zleceniem umową, Wniosku o udzielenie zamówienia (WOUZ). Zamówienia własne Wymagalny Obsługa zamówień do dostawców w powiązaniu ze zleceniem zakupu, Wniosku o udzielenie zamówienia (WOUZ), umową. Gospodarka Magazynowa Wymagalny Obsługa gospodarki magazynowej na potrzeby zakupów, sprzedaży, remontów i obsługi technicznej oraz zarządzania infrastrukturą IT. Również, jako wsparcie zarządzania stanami odzieży roboczej. Inwestycje Wymagalny Planowanie, przygotowywanie, realizacja inwestycji oraz włączanie do pracy operacyjnej nowej infrastruktury. Powiązanie z funkcjonalnością modułu logicznego Projekty dla zadań inwestycyjnych realizowanych w trybie projektowym Tabela 3. Lista modułów funkcjonalnych Systemu 1.6.2
Opis modułów komponentu EOD
Poniższa tabela prezentuje logiczne moduły funkcjonalne komponentu EOD składające się na architekturę tego komponentu. Szczegółowe wymagania funkcjonalne zostały opisane w rozdziale 2.3. Nazwa modułu
Kategoria
Opis
Skrzynka podawcza Wymagalny Logiczny moduł obejmujący obsługę dokumentów wpływających do PAŻP. Jego częścią jest ESP (Elektroniczna Skrzynka Podawcza) Obsługa dokumentów Wymagalny Logiczny moduł obejmujący funkcjonalność obsługi obiegu dokumentów. Strona 21 z 285
Skrzynka nadawcza Wymagalny Logiczny moduł obejmujący obsługę dokumentów wypływających z PAŻP Obsługa Spraw i Zadań Wymagalny Moduł logiczny obejmujący obsługę obiegu i archiwizacji spraw oraz obsługę zadań w ramach obiegu dokumentów i spraw. Obsługa rejestrów Wymagalny Moduł logiczny obejmujący obsługę definiowanych rejestrów (definicja, prowadzenie i archiwizacja rejestrów). Repozytorium dokumentów Wymagalny Moduł logiczny zapewniający funkcjonalność obsługi rejestru dokumentów wraz z wersjonowaniem, katalogowaniem, obsługą adnotacji w powiązaniu z obiegiem dokumentów i spraw, funkcjonalnością rejestrów oraz stanowiący archiwum dokumentacji Agencji. Umożliwia odpowiadający potrzebom dostęp do dokumentów bieżących i archiwalnych.
Raportowanie Wymagalny Moduł logiczny obejmujący standardowe i definiowalne raporty oraz umożliwiający drukowanie dokumentów według zdefiniowanych szablonów, jak również drukowanie naklejek z kodem paskowym i adresowanie kopert w standardowych wymiarach. Definicja procesów Wymagalny Moduł obejmujący funkcjonalności definicji procesów obiegu spraw Definicja formularzy Wymagalny Moduł obejmujący funkcjonalności umożliwiające elektronicznych na potrzeby obiegu spraw. Definicja uprawnień Wymagalny Moduł logiczny zarządzania uprawnieniami i zastępstwami. definicję formularzy Tabela 4. Opis modułów komponentu EOD 1.7
Liczba użytkowników w poszczególnych modułach
Dostawca Systemu zobowiązany jest zapewnić taką liczbę i rodzaj licencji Oprogramowania Standardowego i taką konfigurację całego Systemu, aby możliwa była poprawna praca następującej liczby użytkowników poszczególnych komponentów oraz modułów: Liczba użytkowników, którzy muszą mieć dostęp do poszczególnych komponentów: Komponent
Liczba Użytkowników Nazwanych
Liczba Użytkowników Jednoczesnych
ERP 325 200 BI/EPM – BI 50 25 BI/EPM – EPM 55 25 EOD 1800 500 Portal 2000 300 Tabela 5. Liczba użytkowników poszczególnych komponentów W liczbie 55 nazwanych użytkowników modułu EPM uwzględniono: 
5 Zespół obsługi baz kosztowych 
10 Osoby wprowadzające plany cząstkowe służące do stworzenia planu finansowego 
40 Osoby odpowiadające za poszczególne obszary biznesowe. Strona 22 z 285
Zamawiający dopuszcza możliwość zmniejszenia ilości użytkowników w przypadku zmiany organizacji procesu planowania Agencji. Do realizacji wymagań dla modułów Szkolenia i Zarządzanie personelem, Zamawiający dopuszcza możliwość użycia Portalu i w wyniku tego częściowego zastąpienia dostępów do modułów Szkolenia i Zarządzanie personelem dostępami do Portalu. Strona 23 z 285
2 Wymagania funkcjonalne
2.1
Wymagania ogólne
Nr
wymagania
Wymaganie
Kategoria
wymagania
Wymagania podstawowe OG_001 System musi być zbudowany w architekturze minimum trójwarstwowej z warstwą prezentacji obsługiwaną w technologii cienkiego klienta poprzez przeglądarkę (konieczna współpraca z wszystkimi popularnymi przeglądarkami ‐ co najmniej Internet Explorer oraz FireFox). Wymagalne OG_002 System powinien zapewnić "Forum dyskusyjne" ‐ np. informacje techniczne od służb eksploatujących systemy CNS dot. awarii, zaobserwowanych problemów, wymiany plików itd. Komunikator wewnętrzny pozwalający na wymianę uwag i dokumentujący je jako bazę wiedzy dla przyszłego rozwiązywania problemów podobnych. Opcjonalne OG_003 System musi być rozwiązaniem zintegrowanym, w którym te same informacje są wprowadzane tylko raz i udostępniane we wszystkich miejscach systemu, w których są wymagalne bez konieczności przechodzenia pomiędzy rejestrami systemu w celu wyszukania informacji powiązanych. Wymagalne OG_004 Podstawową i wspólną bazą danych o kosztach, wyjściową dla wszystkich innych procesów: min. kalkulacji stawek, kalkulacji cenników, i wszelkich innych kalkulacji opartych o koszty, musi być analityczna ewidencja w systemie księgowym. Wymagalne OG_005 System musi obsługiwać pola dodatkowe konfigurowane dodatkowe definiowalne w Systemie przez administratora. Pola dodatkowe muszą być definiowane dla każdego obiektu biznesowego przechowywanego w Systemie. Wymagalne OG_006 Pola dodatkowe ‐ definiowalne muszą być dostępne dla systemu raportującego oraz przy wyszukiwaniu informacji. Wymagalne OG_007 Dla pól dodatkowych ‐ definiowanych administrator musi mieć możliwość wskazać w szczególności: ‐ Typ pola (np. znakowe, data, liczba), ‐ Zdefiniować nowy słownik, ‐ Listę wartości, ‐ Maskę formatu (dla daty i liczby), ‐ Wymagalność pola. Wymagalne OG_008 Dla pól dodatkowych system musi umożliwiać zdefiniowanie listy wartości w oparciu o istniejącą w Systemie ewidencję (np. dane obiektu biznesowego kontrahenta, pracownika, stanowiska kosztów, rejestr należności, rejestr zobowiązań, rejestr projektów, itp.).
Wymagalne OG_009 Dla pól dodatkowych system powinien umożliwiać zdefiniowanie reguł walidacji (np. długość tekstu, zakres wartości, zależność od innego pola definiowalnego, itp.). Opcjonalne OG_010 Parametryzacja systemu, definicja zawartości słowników, szablonów dokumentów, wzorce numeracji, wzorce dekretacji, struktura planu kont, itp., musi być możliwa do wykonania przez przeszkolonych administratorów systemu / zaawansowanych użytkowników w każdym momencie eksploatacji systemu. Wymagalne OG_011 System musi zapewniać wbudowaną pomoc kontekstową dla użytkownika dostępną z każdego ekranu w systemie. Pomoc kontekstowa musi być w języku polskim i zawierać wszystkie informacje potrzebne przeszkolonemu użytkownikowi w celu poprawnej pracy w Systemie. Wymagalne OG_012 Pomoc kontekstowa musi zawierać opisy pól formatki z instrukcjami ich wypełniania oraz określeniem sposobu pracy aplikacji przy polach zawierających parametry. Wymagalne Strona 24 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
OG_013 Pomoc kontekstowa musi zawierać odniesienie do procesu lub procedury którą wspiera. Wymagalne OG_014 System musi komunikować się z użytkownikiem za pomocą polskojęzycznych komunikatów ekranowych. W szczególności komunikaty błędów muszą być zrozumiałe dla użytkownika / administratora (w zależności od charakteru błędu/problemu).
Wymagalne OG_015 System musi być wyposażony w jednolity, polskojęzyczny, graficzny interfejs użytkownika oraz polskojęzyczne wartości danych przechowywanych w systemie (reprezentacja dat, liczb, znaki diakrytyczne). Wymagalne Dopuszcza się, aby osobne komponenty systemu miały interfejs wykonany w różnych standardach, jednak interfejs użytkownika w poszczególnych powinien mieć czytelną i uporządkowaną strukturę zapewniającą ergonomię pracy z systemem.
OG_016 System musi umożliwiać selekcję danych do przeglądania na ekranach za pomocą określania zakresów od‐do, z użyciem operatorów logicznych, relacji mniejszości, większości, zawierania lub wykluczania oraz poprzez wskazywanie ciągów znaków występujących w wartościach liczbowych i tekstowych. Wymagalne OG_017 Sortowanie oraz filtrowania oparte na danych tekstowych muszą być zgodne z zasadami obowiązującymi w języku polskim tzn. musi być zachowana właściwa kolejność znaków polskich podczas sortowania i podczas wykorzystywania operatorów porównania „<” , „>”. Wymagalne OG_018 Sortowanie oparte na danych numerycznych musi być zgodne z zasadami arytmetycznymi, to znaczy z zachowaniem kolejności prezentacji liczb rosnąco lub malejąco zgodnie z prezentowanymi wartościami. Wymagalne OG_019 System powinien umożliwiać dowolne sortowanie danych wyświetlanych na formularzach. Wymagalne OG_020 System powinien umożliwiać zapisywanie domyślnych ustawień sortowania i wyszukiwania dla użytkownika i ekranu. Wymagalne OG_021 Formatki ekranowe systemu powinny posiadać mechanizm definiowalnych filtrów pozwalających ograniczać zakres danych wyświetlanych na formularzach. System powinien umożliwić zdefiniowanie stałych filtrów przypisywanych wskazanym użytkownikom. Wymagalne OG_022 System musi posiadać mechanizmy szybkiego wyszukiwania danych na formatkach ekranowych, według wielu dostępnych kryteriów (jednocześnie), w tym według fragmentów nazw i zakresów (dat, numerów, tekstów). Wymagalne OG_023 System powinien umożliwiać jednoczesną aktywną pracę w kilku obszarach roboczych / funkcjonalnych bez konieczności uruchamiania kolejnej instancji systemu (np. w ramach interfejsu MDI lub równoważnego). Wymagalne OG_024 System musi zapewniać tworzenie menu użytkownika z najczęściej wykorzystywanymi funkcjami z różnych obszarów funkcjonalnych. Wymagalne OG_025 System musi zapewniać możliwość indywidualnego konfigurowania ekranów użytkownika. W szczególności musi umożliwiać: ‐ Zmianę wymagalności pól, ‐ Ukrywanie pól, ‐ Zmianę położenia, długości pól, ‐ Zmianę kolejności nawigacji, ‐ Zmianę etykiet pól, ‐ Wybór palety barw, w tym stonowanych nie powodujących zmęczenia użytkownika, ‐ Możliwość powiększania i zmniejszania ekranu,
Wymagalne OG_026 System powinien uniemożliwiać aktualizację danych słownikowych w czasie realizacji transakcji korzystającej z tych słowników. Opcjonalne Strona 25 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
OG_027 System musi weryfikować poprawność wprowadzanych danych pod kątem ich kompletności i spójności oraz zgodności ze zdefiniowanymi słownikami, wspomagać użytkownika poprzez oferowanie list wyboru i autotekstu przy wprowadzaniu danych, Wymagalne OG_028 System musi mieć wbudowanego klienta FTP lub zapewnić równoważną funkcjonalność. Wymagalne OG_029 System musi posiadać konsolę administratora umożliwiającą z jednego miejsca zarządzanie użytkownikami, uprawnieniami i konfiguracją systemu. Dopuszcza się aby w poszczególnych komponentach Systemu istniały osobne konsole administratora ‐ nie zmienia to konieczności integracji katalogu użytkowników z LDAP. Wymagalne OG_030 Wszystkie komponenty systemu muszą zapewniać obsługę funkcji jednokrotnego logowania (Single Sign On). Wymagalne OG_031 W ramach systemu muszą być dostępne funkcjonalności do monitorowania pracy elementów tego systemu, a w szczególności aplikacji systemu, systemu relacyjnej bazy danych i wykorzystywanego środowiska pracy systemu (np. serwerów aplikacyjnych). Wymagalne OG_032 System musi zabezpieczać dane przed przypadkowym usunięciem – generowanie ostrzeżenia o nieodwracalnym usunięciu danych. Wymagalne OG_033 System musi zapewniać jednoczesny dostęp do danych przez wielu użytkowników, z zapewnieniem ochrony tych danych przed modyfikacją, utratą spójności (integralnością) lub zniszczeniem (dostępnością). Wymagalne OG_034 System musi zapewniać integralność transakcji zapisywanych do bazy danych. Wymagalne OG_035 System musi zapewniać sprawdzanie poprawności danych wejściowych. Wymagalne OG_036 System powinien zapewniać potwierdzanie poprawności przetwarzania. Opcjonalne OG_037 System musi działać w taki sposób, aby dostęp do modyfikacji dokumentu miał w danym momencie wyłącznie ten użytkownik, który pierwszy zaczął go modyfikować. Pozostali użytkownicy powinni móc w tym czasie jedynie przeglądać ten dokument (bez możliwości jego zmiany) oraz mieć dostęp do wszystkich pozostałych dokumentów z możliwością ich zmiany. Wymagalne OG_038 System musi uniemożliwiać wyświetlanie hasła oraz poszczególnych jego znaków w trakcie wprowadzania. Może ukrywać wprowadzane znaki pod symbolami maskującymi. Wymagalne OG_039 Niedopuszczalne jest w Systemie przesyłania hasła poprzez sieć jawnym tekstem. Wymagalne OG_040 System musi zapewniać w ramach wszystkich komponentów możliwość konfigurowania powiadomień wysyłanych do konkretnych użytkowników lub grup użytkowników, których merytorycznie dotyczy powiadomienie. Powiadomienia muszą być generowane jako komunikaty systemowe, wiadomości e‐mail, sms w zależności od konkretnego przypadku powiadomienia. Powiadomienia muszą być generowane automatycznie na podstawie zdarzeń, których dotyczą. Wymagalne OG_041 System musi zapewniać możliwość generowania powiadomień jako: komunikaty systemowe, wiadomości e‐mail oraz sms. Wymagalne OG_042 Powiadomienia muszą być generowane do użytkowników systemu odpowiedzialnych merytorycznie za czynności, dla których generowane jest powiadomienie.
Wymagalne OG_043 W trakcie trwania inwestycji system powinien umożliwiać publikowanie wybranych danych w intranecie. Opcjonalne OG_044 Dostępne z systemu zestawienia dotyczące sprawozdawczości inwestycyjnej muszą mieć możliwość zapisu do pliku w formacie XLS. Wymagalne OG_045 Definiowanie przypomnień/alertów musi być dostępne dla administratora systemu ‐ bez potrzeby Wymagalne Strona 26 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
dodatkowych działań Dostawcy systemu. OG_046 System musi umożliwiać użycie funkcji kopiuj‐wklej podczas edycji danych na ekranie Wymagalne OG_047 System musi zapewnić jednoznaczną identyfikację użytkownika, wprowadzającego, edytującego i zatwierdzającego dane wykorzystywane we wszystkich procesach planowania PAŻP, bez względu na moduły i komponenty wykorzystywane w poszczególnych etapach procesu. Wymagalne Zarządzanie importem i eksportem plików OG_048 System musi umożliwiać eksport i import danych w zakresie wszystkich komponentów i modułów za pomocą plików XML, HTML, płaskich plików tekstowych (w tym również CSV), plików arkusza kalkulacyjnego (w tym co najmniej pakietu MS Office). Wymagalne OG_049 System musi umożliwiać definiowanie dowolnych formatów importu i eksportu plików oraz importowanie i eksportowanie dowolnego pliku zawierającego dane zgodne z danymi w systemie ERP. Wymagalne OG_050 System musi umożliwiać implementowanie reguł walidacji danych przed zaimportowaniem pliku txt do bazy systemu ERP. Wymagalne OG_051 System musi umożliwiać: import plików o dowolnej godzinie, możliwość ustawienia dowolnego cyklu powtarzania importu, możliwość uruchamiania importu w trybie ad‐hoc. Wymagalne OG_052 System musi umożliwiać importowanie pliku ze wskazanej lokalizacji w sieci wewnętrznej i na stacji roboczej. Wymagalne OG_053 System musi umożliwiać eksport pliku do wskazanej lokalizacji w sieci wewnętrznej i na stacji roboczej. Wymagalne OG_054 System musi zapewniać rejestrację operacji eksportu danych realizowanych przy pomocy funkcji eksportu, wraz ze wskazaniem użytkownika, daty oraz zakresu eksportowanych danych. Wymagalne OG_055 System powinien zapewniać możliwość eksportu pozycji każdego słownika oraz wskazanego zakresu pozycji słownika do pliku w formacie co najmniej XLS, XLSX, CSV, XML. Wymagalne Zarządzanie użytkownikami i uprawnieniami OG_056 System musi umożliwiać zdefiniowanie identyfikatora (loginu i hasła) jednoznacznie określającego użytkownika. Wymagalne OG_057 System musi zapewniać możliwość konfiguracji dostępu użytkowników do danych według ich rzeczywistych kompetencji i uprawnień. Każdy użytkownik, aby uzyskać dostęp do systemu musi być najpierw w nim zdefiniowany przez Administratora. Tworząc konto użytkownika administrator definiuje jego profil, poprzez nadanie mu uprawnień wynikających z roli i przypisuje go do określonej grupy.
Wymagalne OG_058 System musi umożliwiać definiowanie uprawnień na poziomie użytkowników i grup użytkowników. Wymagalne
OG_059 System musi obsługiwać hierarchiczne grupy użytkowników. Możliwość dołączania do grupy uprawnień innej grupy – uprawnienia są automatycznie dziedziczone w grupie nadrzędnej z grupy podrzędnej. Wymagalne OG_060 System musi umożliwiać wielokrotne zagnieżdżanie grup użytkowników bez ograniczeń. Wymagalne
OG_061 System musi zapewniać kopiowanie uprawnień z grupy do grupy.
Wymagalne
OG_062 System musi zapewniać możliwość blokowania konta użytkownika bez konieczności jego usuwania. Wymagalne
OG_063 System musi umożliwiać ustawianie daty ważności konta użytkownika. Wymagalne OG_064 System musi umożliwiać definiowanie uprawnień użytkownika do poszczególnych pozycji menu, zakładek, operacji. Wymagalne OG_065 System musi umożliwiać definiowanie uprawnień użytkownika do zakresu danych udostępnianych w poszczególnych formatkach ekranowych i raportach. Wymagalne Strona 27 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
OG_066 System musi umożliwiać ograniczenie uprawnień użytkownika do wybranej jednostki organizacyjnej. Wymagalne OG_067 System musi umożliwiać definiowanie osobnych uprawnień do tworzenia, akceptacji, modyfikacji, usunięcia i podglądu dokumentów (rekordów, danych). Wymagalne OG_068 System powinien umożliwiać konfigurowanie podwójnej autoryzacji dla wskazanych przez administratora operacji (mechanizm maker‐checker). Opcjonalne OG_069 Administrator systemu musi mieć możliwość wylogowania wszystkich użytkowników pracujących w systemie. Wymagalne OG_070 System musi zapewniać możliwość automatycznego zamykania nieaktywnych sesji użytkownika po przekroczeniu zdefiniowanego okresu braku aktywności. Wymagalne OG_071 Administrator systemu powinien mieć możliwość wysłania komunikatu do wszystkich zalogowanych użytkowników Opcjonalne OG_072 System powinien umożliwiać Administratorowi Dostępu nadawanie uprawnień na czas określony dla użytkowników systemu. Przez czas określony rozumie się przynajmniej datę nadania i wygaśnięcia uprawnienia. Wymagalne OG_074 System powinien umożliwiać Administratorowi Dostępu nadawanie uprawnień na czas określony dla użytkowników systemu. Przez czas określony rozumie się przynajmniej: ‐ wybrane dni tygodnia, ‐ wybrane dni miesiąca, ‐ okno godzinowe od‐do w ciągu dnia. Opcjonalne OG_074 Próby naruszeń nadanych ograniczeń czasowych powinny być w trybie ciągłym (on‐line) raportowane Administratorowi Bezpieczeństwa przynajmniej za pomocą e‐mail oraz sms. Opcjonalne OG_075 System powinien zapewniać możliwość czasowego odbierania uprawnień. Opcjonalne OG_076 Weryfikacja uprawnień musi odbywać się podczas każdej operacji realizowanej przez użytkownika w tym dostępu do samych danych. Wymagalne OG_077 System musi umożliwić skonfigurowanie wymaganych parametrów hasła użytkownika (różni użytkownicy mogą mieć różne reguły dotyczące hasła): a) Wymuszenie zmiany hasła co określoną przez administratora liczbę dni poprzedzone wcześniejszą informacją o konieczności zmiany hasła na n dni przed wygaśnięciem, b) określenie reguł silnego hasła, w szczególności: ‐ minimalna długość hasła, ‐ minimalna liczba małych liter, ‐ minimalna liczba dużych liter, ‐ minimalna liczba cyfr, ‐ minimalna liczba znaków specjalnych, ‐ hasło nie może zawierać n kolejnych identycznych znaków, ‐ hasło nie może zawierać znaków z listy ustalonej przez administratora, ‐ hasło nie może być identyczne z nazwą konta lub jego częścią, ‐ hasło nie może zawierać danych osobowych użytkownika (imienia, nazwiska, daty urodzenia), c) określenie jak często hasło nie może się powtarzać, d) hasło nie może zawierać wartości ze słownika określonego przez administratora e) blokowanie konta po n nieudanych próbach podania hasła. Wymagalne OG_078 Administrator musi mieć możliwość ustawiania w Systemie maksymalnej liczby jednoczesnych sesji użytkownika z jednej końcówki. Użytkownik nie może tworzyć w tym samym czasie sesji z różnych końcówek. Opcjonalne OG_079 System musi zapewnić nadanie uprawnień funkcjonalnych użytkownikowi dla roli administracyjnej, uprawniającej do operacji na harmonogramach pożyczek. Wymagalne Strona 28 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
OG_080 System musi zapewnić nadanie uprawnień funkcjonalnych użytkownikowi dla roli księgowej, uprawniającej do księgowania operacji w urządzeniach księgowych PKZP. Wymagalne OG_081 System musi zapewnić nadanie uprawnień funkcjonalnych użytkownikowi dla roli obserwatora, umożliwiającej podgląd stref administracyjnej i księgowej. Rola obserwatora będzie przydzielona Zarządowi PKZP oraz księgowości, która powinna widzieć operacje w strefie administracyjnej. Wymagalne Zarządzanie przez cele OG_082 System musi wspomagać zarządzanie przez cele, poprzez umożliwienie ich rejestracji i pomiaru. Wymagalne OG_083 System musi wspierać definiowanie celów organizacji (poziom strategiczny) poprzez ich ewidencję i wymiarowanie. Wymagalne OG_084 System musi umożliwiać określenie dat obowiązywania celów. Wymagalne OG_085 System musi umożliwiać określenie osób odpowiedzialnych za realizację celów. Wymagalne OG_086 System musi umożliwiać zdefiniowanie mierników celów: wartościowe, wyrażone w dowolnej jednostce miary, opisowe oraz wyliczeniowe. Wymagalne OG_087 System musi umożliwiać przypisanie miernika do celu organizacji. Wymagalne OG_088 System musi umożliwiać wprowadzenie przez uprawnione osoby oceny wartości mierników. Wymagalne OG_089 System musi umożliwiać rejestrowanie historii wartości mierników. Wymagalne OG_090 System musi posiadać możliwość zdefiniowania i dystrybucji celów organizacji na poszczególne komórki, stanowiska i pracowników (w module zarządzania personelem). Wymagalne OG_091 System musi automatycznie wyliczać mierniki wyliczeniowe w sposób właściwy dla danego miernika, w oparciu o dane dostępne w bazie Systemu. Wymagalne OG_092 System musi umożliwiać określenie granicznych wartości mierników. Wymagalne OG_093 Wartości graniczne muszą mieć określony czas obowiązywania wynikający z przyjętych planów. Wymagalne OG_094 System musi umożliwiać porównanie wartości aktualnej miernika z jego wartością graniczną. Wymagalne OG_095 System musi określić kryterium przekroczenia wartości granicznej odpowiednio dla wartości określonych jako minimalne, maksymalne, lub łącznie dla obu tych kryteriów. Wymagalne OG_096 System w przypadku mierników wyliczanych automatycznie system musi generować powiadomienia mailowe w przypadku przekroczenia poziomów granicznych. Wymagalne OG_097 System musi zapewniać planowanie w powiązaniu z celami strategicznymi poprzez konieczność określenia celów dla tworzonych w Systemie planów i ich pozycji. Wymagalne Tabela 6. Wymagania funkcjonalne ‐ ogólne 2.2
Wymagania dotyczące komponentu ERP
2.2.1
Wymagania dotyczące komponentu - Moduły wspólne
Nr
wymagania
Wymaganie
Kategoria
wymagania
Moduł Administratora Wymagania ogólne ADM_001 Komponent ERP musi zawierać moduł administratora umożliwiający zarządzania użytkownikami i uprawnieniami w sposób spójny z pozostałymi komponentami systemu. Wymagalne Strona 29 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ADM_002 System musi zapewnić możliwość pracy w module administratora wielu użytkowników z różnymi uprawnieniami (system nie powinien narzucać pracy w module administracyjnym za pomocą tylko jednego konta). Wymagalne ADM_003 Moduł administratora musi posiadać graficzny interfejs użytkownika. Wymagalne ADM_004 W module administratora musi być możliwość zablokowania logowania się do systemu wszystkich lub wybranych użytkowników (np. w trakcie prowadzonych prac konserwacyjnych). Wymagalne ADM_005 W module administratora musi być możliwość wylogowania wszystkich lub wskazanych użytkowników pracujących aktualnie w systemie. Wymagalne ADM_006 W module administratora wszystkie operacje (a w szczególności operacje zmiany konfiguracji, zmiany modelu uprawnień oraz zmiany uprawnień) muszą być audytowane na poziomie co najmniej kto, kiedy i co. Wymagalne ADM_007 Moduł administratora musi mieć możliwość planowania i harmonogramowania zadań administracyjnych z możliwością przypominania o zaplanowanych zadaniach za pomocą komunikatów systemowych i wiadomości poczty elektronicznej przesyłanych do osób odpowiedzialnych za poszczególne zadania. Wymagalne ADM_008 Moduł administratora musi posiadać narzędzia umożliwiające monitorowanie wydajności systemu (aplikacji biznesowych, serwerów aplikacyjnych oraz serwerów bazy danych). Wymagalne Monitorowanie pracy użytkowników ADM_009 Moduł administratora musi zapewniać monitorowanie aktywności użytkowników w systemie. Wymagalne ADM_010 Moduł musi wyświetlać listę aktualnie zalogowanych użytkowników z określeniem modułu, w którym aktualnie pracują. Wymagalne ADM_011 Moduł musi wyświetlać historię logowania użytkowników (czas od, do) wraz z określeniem modułu, w którym aktualnie pracowali. Wymagalne ADM_012 Moduł administratora musi umożliwiać wyświetlenie i filtrowanie historii operacji użytkowników co najmniej według kryteriów: ‐ czasu (okres od do), ‐ użytkownika (w tym wszystkich użytkowników), ‐ moduły (w tym wszystkich modułów), ‐ operacji, grupy operacji realizowanych przez użytkownika.
Wymagalne ADM_013 Moduł administratora musi umożliwiać wyświetlenie listy nieudanych prób logowania do systemu. Wymagalne
Raporty ADM_014 Moduł administratora musi zapewniać możliwość raportowania aktualnie przydzielonych uprawnień. Wymagalne
ADM_015 Moduł administratora musi mieć możliwość raportowania aktywności użytkowników na podstawie logów systemowych. Wymagalne ADM_016 Moduł administratora musi mieć możliwość raportowania konfiguracji systemu.
Wymagalne
ADM_017 Moduł administratora musi mieć możliwość raportowania aktywności administratorów (lista wykonanych operacji ‐ operacja, kiedy, przez kogo). Wymagalne ADM_018 Moduł administratora musi mieć możliwość konfigurowania własnych zestawień (lub powinien być zintegrowanych z narzędziami raportującymi umożliwiającymi przygotowywanie własnych zestawień) dotyczących uprawnień, konfiguracji systemu oraz aktywności użytkowników. Wymagalne ADM_019 Moduł administratora powinien mieć możliwość harmonogramowania generowanych raportów. System powinien generować raporty zgodnie z nakreślonym harmonogramem i automatycznie przesyłać zestawienia na wskazane adresy poczty elektronicznej. Opcjonalne Strona 30 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Kartoteka kontrahentów Wymagania ogólne KTH_001 System musi posiadać wspólny dla całości systemu rejestr kontrahentów. Jednorazowo wprowadzone dane kontrahenta muszą być widoczne w odpowiednich modułach, i być dostępne do wykorzystania do oznaczania nimi dokumentów i operacji w odpowiednich miejscach w systemie. Wymagalne KTH_002 System musi posiadać wspólną bazę dostawców i odbiorców. Dopuszcza się rozgraniczenie katalogu dostawców i odbiorców przy jednoczesnym zapewnieniu powiązania dostawcy i odbiorcy w przypadku, gdy jest to ten sam podmiot. System w takiej sytuacji nie może wymagać dwukrotnego wprowadzania tych samych danych ‐ do kartoteki odbiorców i dostawców. System w takiej sytuacji musi również zapewnić automatyczną synchronizację kartotek. Wymagalne KTH_003 System musi zapewniać możliwość wstępnej rejestracji kontrahenta na podstawie szczątkowych informacji (np. z wyciągu) z możliwością późniejszego uzupełnienia danych przez osobę zarządzającą bazą kontrahentów. Wymagalne KTH_004 System powinien zapewniać możliwość dodawania kontrahentów do kartoteki w trakcie rejestrowania dokumentu w innych modułach bez konieczności zapisywania danych i przechodzenia do funkcji wprowadzania kontrahenta np.: funkcja dodawania kontrahenta powinna być dostępna do wywołania z listy wyboru kontrahentów. Opcjonalne Zapewnienie spójności kartoteki KTH_005 System musi być wyposażony w mechanizm wykrywający dublowanie się podmiotów w kartotece w trakcie wprowadzania i modyfikowania danych. Mechanizm powinien: ‐ Weryfikować kontrahentów po powtarzającym się numerze NIP, REGON, PESEL, KRS. Przy przechowywaniu dostawców i odbiorców w osobnych bazach, poprzez blokadę należy rozumieć również blokadę wprowadzenia dostawcy przy istniejącym odbiorcy z tym samym NIP i na odwrót, ‐ Domyślnie wymagać dla podmiotu podania numeru identyfikacyjnego, ‐ Ostrzegać o tym, że w kartotece istnieje podmiot o takiej samej nazwie, nazwisku, adresie, numerze rachunku bankowego (ignorowanie wielkości liter i białych znaków. Wymagalne KTH_006 System musi umożliwić, dla obsługi wyjątkowych sytuacji (z wykorzystaniem specjalnych uprawnień), zdublowania kontrahenta z tym samym numerem NIP, REGON, PESEL. Wykorzystanie takiej opcji musi być monitorowane i sygnalizowane automatycznie do wskazanych użytkowników.
Wymagalne KTH_007 System musi zapewniać automatyczne sprawdzanie poprawności wprowadzanych do systemu danych typu NIP, PESEL, REGON razem ze sprawdzaniem sumy kontrolnej. Sprawdzanie poprawności numeru NIP dot. wszystkich krajów Unii Europejskiej. System musi być niewrażliwy na różne sposoby zapisu numerów NIP (np. z separatorami lub bez). Wymagalne KTH_008 System powinien zapewniać automatyczne sprawdzanie poprawności wprowadzanych do systemu numerów polskich dowodów osobistych, wraz ze sprawdzaniem sumy kontrolnej. Opcjonalne KTH_009 System musi zapewniać możliwość zmiany danych podmiotu z zachowaniem poprzednich danych w archiwum (wersjonowanie danych) w sposób niepowodujący zmian w dotychczasowych obiektach, do których przypisana była dana wersja z kartoteki podmiotów (w szczególności już wystawionych fakturach i zarejestrowanych umowach). Wymagalne KTH_010 Niezależnie od zapewnienia zapisu poprzednich danych kontrahenta w historii, system powinien mieć funkcję administracyjną umożliwiająca korektę danych bez zapisu w archiwum. Opcjonalne KTH_011 System powinien zapewnić przywracanie danych archiwalnych. Opcjonalne KTH_012 System powinien umożliwiać modyfikację i korektę określonych danych kontrahenta w oparciu o mechanizm uprawnień, dostępny do konfiguracji przez administratora systemu. Opcjonalne KTH_013 System powinien zapewniać mechanizmy scalania zdublowanych kontrahentów, uwzględniający odpowiednią obsługę wszystkich obiektów powiązanych ze zdublowanymi kontrahentami włączając Opcjonalne Strona 31 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
istniejące dokumenty i rozrachunki. KTH_014 System musi umożliwiać łączenia kontrahentów w grupy według różnych kryteriów i parametrów. Funkcjonalność musi zapewniać: ‐ prawidłowe przygotowywanie sprawozdania RB‐N, ‐ łatwiejsze wyszukiwanie kontrahentów, ‐ możliwość tworzenia różnego rodzaju analiz dla grup kontrahentów. Wymagalne KTH_015 System musi umożliwiać we wszystkich modułach i komponentach, wybór kontrahenta z listy wyboru po informacjach identyfikujących podmiot w sposób dokładny lub przybliżony (podanie fragmentu danych) ‐ w szczególności: nazwa, imię, nazwisko dla osób fizycznych, dane adresowe, numery identyfikacyjne NIP, REGON, PESEL. Wymagalne KTH_016 System musi umożliwiać wyszukiwanie grup kontrahentów oraz kontrahentów powiązanych. Wymagalne KTH_017 System musi umożliwiać dodawanie w rejestrze kontrahentów nowych pól przez administratora, włączając w to pola w rejestrach powiązanych. Wymagalne KTH_018 System musi umożliwiać dodawanie przez administratora nowych reguł walidacji wprowadzanych danych dla pól w rejestrze kontrahentów. Wymagalne Szczegółowe wymagania dotyczące danych kartoteki KTH_019 System musi umożliwiać rejestrowanie co najmniej następujących informacji o kontrahencie/pracowniku: ‐ numer podmiotu – nadawany automatycznie i niezmienny w systemie, ‐ nazwa skrócona, ‐ nazwa pełna, ‐ NIP , w tym numer NIP UE, ‐ REGON, ‐ PESEL – dla osób fizycznych, ‐ Numer KRS, ‐ imiona i nazwiska – dla osób fizycznych, ‐ płeć, data urodzenia – dla osób fizycznych, ‐ domyślne warunki zapłaty (sposób zapłaty, termin zapłaty), ‐ przypisanie do branży, ‐ informacje finansowe (dopuszczalny limit zadłużenia), ‐ powiązanie z użytkownikiem będącym opiekunem kontrahenta, ‐ status kontrahenta: aktywny, nieaktywny. Wymagalne KTH_020 System musi umożliwiać rejestrowanie dodatkowych danych kontrahenta. Wymagalne KTH_021 System musi zapewnić możliwość rejestrowania dla kontrahenta danych kontaktowych (właściciel kontaktu: imię, nazwisko, funkcja; telefony; adresy e‐mail; faksy i inne definiowalne np. nick skype, języki w jakich preferowany jest kontakt, itp.). Wymagalne KTH_022 System musi zapewnić możliwość rejestrowania dla kontrahenta nieograniczonej liczby adresów (typ adresu, kraj, miejscowość, ulica, kod pocztowy, poczta, nr doku, nr lokalu, województwo, itp.). Wymagalne KTH_023 System musi umożliwiać zapisywanie dla kontrahenta wielu siedzib wraz z podaniem typu siedziby (np. siedziba główna, adres do korespondencji, itp.). Wymagalne KTH_024 System musi umożliwiać rejestracji wielu rachunków bankowych krajowych i zagranicznych dla danego kontrahenta. Wymagalne KTH_025 System musi obsługiwać kontrolę poprawności numerów rachunków bankowych wg formatu IBAN oraz NRB. Wymagalne KTH_026 System musi zapewnić możliwość rejestrowania dla kontrahenta nieograniczonej liczby rachunków Wymagalne Strona 32 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
bankowych. KTH_027 System powinien posiadać słownik jednostek banków, możliwy do aktualizacji poprzez import z pliku oraz w sposób ręczny. Wymagalne KTH_028 W momencie wprowadzenia nr rachunku bankowego, system powinien automatycznie podpowiedzieć bank i jednostkę banku, w której prowadzony jest rachunek bankowy. Wymagalne KTH_029 System musi zapewnić możliwość oznaczenie dla kontrahenta domyślnego rachunku (na który mają być realizowane płatności, jeżeli nie określono ich na dokumencie). Wymagalne KTH_030 System musi zapewnić możliwość przypisanie dla kontrahenta rachunku Agencji, na który odbiorca powinien realizować płatności. Wymagalne KTH_031 System musi zapewniać prawidłową obsługę oddziałów kontrahentów: obsługiwać rejestrację umów oraz faktur zakupowych i sprzedażowych na oddziały. Faktury wprowadzone w komponencie EOD na poziomie oddziału muszą być przenoszone do komponentu ERP także na poziomie oddziału. Wymagalne KTH_032 Wymagalne W przypadku kontrahenta wielooddziałowego system musi prezentować wszystkie jego oddziały z kraju adresu siedziby głównej w postaci rekordów podrzędnych do rekordu danych klienta. KTH_033 System musi umożliwiać taka konfigurację, w której Kontrahent wielooddziałowy, którego wszystkie oddziały są zlokalizowane w tym samym Państwie, co siedziba główna, w bazie kontrahentów musi występować tylko 1 raz (z pominięciem sytuacji wyjątkowych, których wystąpienie możliwe jest tylko do wytworzenia przez użytkowników ze specjalnymi uprawnieniami). Wymagalne KTH_034 W przypadku Oddziału, który jest zlokalizowany w innym Państwie niż adres siedziby głównej kontrahenta – system musi umożliwiać jego rejestrację, jako osobnego kontrahenta, z możliwością powiązania go z rekordem danych kontrahenta, na którym zarejestrowany jest z siedzibą główną. Wymagalne KTH_035 System musi umożliwiać odznaczanie w danych kontrahenta informacji o posiadaniu certyfikatu rezydencji. Wymagalne KTH_036 System musi wykorzystywać znacznik dotyczący certyfikatu rezydencji do identyfikacji stanu, w którym występować będzie konieczność pobrania podatku dochodowego u źródła. Wymagalne KTH_037 System musi zapewnić możliwość rejestrowania dla kontrahenta obowiązkowych informacji dotyczących ochrony danych osobowych. Wymagalne KTH_038 System musi zapewnić możliwość rejestrowania dla kontrahenta danych reprezentantów podmiotu. Wymagalne KTH_039 System musi zapewnić możliwość rejestrowania dla kontrahenta informacji o ryzyku związanym z obsługą kontrahenta i o problemach przy realizacji umów z nim (zapis na „czarnej liście”). Wymagalne KTH_040 System musi zapewnić definiowanie powiązań między kontrahentami różnego typu (np. kontrahent będący osobą prowadzącą działalność gospodarczą jest równocześnie pracownikiem firmy będącej innym kontrahentem). Wymagalne Integracja KTH_041 System musi zapewnić automatyczną synchronizację istniejących danych kontrahentów między Systemem a rejestrem odbiorców, prowadzonym przez CRCO. Wymagalne KTH_042 Zmiana danych kontrahenta przez interfejs danych musi tworzyć nową wersję danych kontrahenta. System musi zapewnić niezmienności danych na historycznych dokumentach powiązanych z kontrahentami, generowanych z użyciem starszych wersji danych kontrahentów.
Wymagalne KTH_043 System musi zapewnić integrację bazy pracowników z kartoteką kontrahentów. W przypadku rozrachunków z pracownikiem jego dane muszą automatycznie trafić do kartoteki kontrahentów i zmiana danych pracownika w systemie kadrowym musi być automatycznie synchronizowana z Wymagalne Strona 33 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
kartoteką kontrahentów. KTH_044 System musi zapewnić powiązanie danych kontrahenta z umowami zapisanymi w centralnym rejestrze umów. Wymagalne KTH_045 System musi zapewnić automatyczne wykorzystanie informacji o rachunku bankowym Agencji, warunkach płatności przy wystawianiu dokumentu należności dla kontrahenta (o ile inne dane nie wynikają z umowy). Wymagalne Raporty KTH_046 System powinien posiadać raport prezentujący kontrahentów podejrzanych o zdublowanie w kartotece. Wymagalne Centralny Rejestr Umów Wymagania ogólne CRU_001 System musi umożliwiać prowadzenie wspólnego centralnego rejestru umów, za wyjątkiem umów o pracę oraz umów cywilno‐prawnych. Wymagalne CRU_002 System musi umożliwiać rejestrację umowy, na podstawie danych wcześniej wprowadzonych w procesie zarządzania umową tzn. automatyczne przejęcie danych i załączników z wniosku do umowy. Wymagalne CRU_003 System musi umożliwiać blokowanie rejestracji umów określonego rodzaju, jeżeli nie poprzedziła ich ścieżka akceptacji umowy. Wymagalne CRU_004 System powinien umożliwiać centralne i automatyczne generowanie unikalnych numerów umów w dowolnie definiowany sposób (w numerze zaszyta informacja o rodzaju umowy, symbolu komórki realizującej umowę, roku zawarcia umowy itp.). Wymagalne CRU_005 System musi umożliwiać grupowanie i filtrowanie umów wg zadanych kryteriów (np. rodzaju umowy, kontrahenta, roku zawarcia itd.). Wymagalne CRU_006 System musi umożliwiać na poziomie umowy gromadzenie informacji o zabezpieczeniach prawidłowego wykonania umowy, z zakresem danych umożliwiającym monitorowanie i alertowanie braków lub przekroczeń terminów, w szczególności: ‐ typ gwarancji, ‐ terminy obowiązywania, ‐ kwoty, ‐ wystawcę, ‐ numery zabezpieczeń, ‐ datę wystawienia, ‐ aktualny status (zwalnianie lub częściowe/całkowite przejmowanie na koniec okresu gwarancyjnego itp.). Wymagalne CRU_007 System musi umożliwiać gromadzenie danych o terminach związanych z harmonogramem dostaw, harmonogramem wykonania usług, harmonogramem płatności. Wymagalne CRU_008 W przypadku nie występowania w umowie dat bezwzględnych (określonych jako konkretny dzień), system musi umożliwiać wprowadzanie terminu w postaci opisu, oraz orientacyjnej daty (osobne pole niż data wynikająca z umowy). Wymagalne CRU_009 System musi umożliwiać gromadzenie danych o przewidywanych przychodach i kosztach z zawartych umów przychodowych. Wymagalne CRU_010 System musi umożliwiać definiowanie cennika oraz warunków rabatowych indywidulanie dla umowy. Wymagalne CRU_011 System na podstawie harmonogramu obciążeń danej umowy musi umożliwiać automatycznie i ręczne tworzenie obciążeń (faktur) kontrahentów tytułem zawartych umów przychodowych. Wymagalne CRU_012 W harmonogramie obciążeń danej umowy muszą być co najmniej następujące dane: ‐ kwota wynagrodzenia netto, VAT, brutto; ‐ nazwa usługi/towaru będącej przedmiotem umowy przychodowej (z odniesieniem do konkretnych Wymagalne Strona 34 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
indeksów), ilość, jednostka miary, stawka VAT dla towaru itd.; ‐ data sprzedaży, data wystawienia obciążeń (z góry, z dołu); ‐ terminy płatności. CRU_013 Na harmonogramie obciążeń musi być prezentowane powiązanie pozycji płatności z wystawioną fakturą. Wymagalne CRU_014 System musi umożliwić rejestrowanie wartość umowy oraz stopień jej realizacji. Wymagalne CRU_015 System musi umożliwiać gromadzenie na poziomie umowy danych o ubezpieczeniu działalności wykonawcy (warunki polisy ubezpieczeniowej od odpowiedzialności cywilnej), z zakresem danych umożliwiającym monitorowanie i alertowanie braków lub przekroczeń terminów, w szczególności: nr polisy, ubezpieczyciel, terminy obowiązywania, kwoty. Wymagalne CRU_016 System musi pozwalać na rejestrację umów wielostronnych (konsorcja), wraz z danymi wszystkich konsorcjantów i oznaczeniem podmiotu będącego liderem konsorcjum. Wymagalne CRU_017 System powinien pozwalać na wyszukiwanie umów po dowolnych rejestrowanych w systemie danych umowy. Opcjonalne CRU_018 System musi pozwalać na elastyczne wyszukiwanie umów po różnych parametrach. Wymagalne CRU_019 System musi przechowywać informacje o przedmiocie umowy, zarówno w postaci opisowej, jak i definiowanej poprzez wykorzystanie pól słowników. Wymagalne CRU_020 CRU_021 System musi umożliwiać gromadzenie na poziomie umowy danych o certyfikacie rezydencji Wymagalne podatkowej, z zakresem danych umożliwiającym monitorowanie i alertowanie braków lub przekroczeń terminów, w szczególności: nr zaświadczenia, terminy obowiązywania, kraj podatkowy. System musi umożliwiać gromadzenie danych o istotnych i specyficznych z punktu widzenia zapisach Wymagalne umów różnego rodzaju, w sposób umożliwiający ich późniejsze wykorzystanie w umowach danego typu: ‐ przychodowych (nawigacyjnych), ‐ przychodowych (pozanawigacyjnych, w tym najmu, dzierżawy, o dzieło, zlecenia, sprzedaży zbędnego majątku trwałego), ‐ kosztowych (realizowanych na podstawie PZP, w tym umów ubezpieczeniowych), ‐ kosztowych (realizowanych poza PZP), ‐ wewnętrznych z pracownikami (np. przekazania pojazdu służbowego do użytkowania), ‐ bez skutku finansowego ‐ np. porozumienia (bezkosztowe). CRU_022 System musi zapewnić funkcjonalność obsługującą wewnętrzną ocenę dostawców. Wymagalne CRU_023 System musi zapewnić monitoring faktur wystawionych przez dostawców. Wymagalne CRU_024 System musi zapewnić ewidencję umów związanych z wybranym dostawcą. Wymagalne CRU_025 System musi umożliwiać zapewnić sprawdzenie terminowości realizacji dostaw. Wymagalne CRU_026 System musi zapewnić ewidencję udzielonych kar dla dostawcy. Wymagalne Zarządzanie umowami CRU_027 System musi umożliwiać rejestrację i dostęp do podglądu określonych danych w rejestrze umów (np. danych finansowych ‐ wartość, harmonogramy fakturowań, szczegółowe warunki, itp..) z zastosowaniem mechanizmów uprawnień. Wymagalne CRU_028 System powinien umożliwiać modyfikację określonych danych, które nie wymagają procesowania aneksu do umowy, np. zmiana realizatora umowy, zmiana statusu umowy. Zmiany są możliwe tylko dla użytkowników posiadających odpowiednie uprawnienia. Opcjonalne CRU_029 System powinien umożliwiać: tworzenie dokumentu Aneksu łącznie z procedurą akceptacyjną (EOD), rejestrację Aneksu (ERP moduł CRU), aktualizację danych do fakturowania wynikających z Aneksu (ERP moduł sprzedażowy). Wymagalne Strona 35 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
CRU_030 Dostęp do aneksów umów powinien być sterowany mechanizmem uprawnień. Opcjonalne CRU_031 Mechanizm uprawnień w CRU musi być definiowany w oparciu o następujące elementy: ‐ struktura organizacyjna PAŻP (np. ograniczenie podglądu do wybranych działów; lub ograniczenie do wszystkich działów, przez które przebiegał obieg akceptacji danej umowy), ‐ identyfikator użytkownika (np. ograniczenie podglądu do konkretnych pracowników w przypadku umów o ograniczonej jawności; lub ograniczenie do wszystkich pracowników, przez których przechodziła ścieżka akceptacji danej umowy), ‐ rodzaj umowy (np. ograniczenie podglądu tylko do umów ubezpieczeniowych), ‐ inicjator umowy (np. udostepnienie podglądu zawsze dla inicjatora umowy + jego przełożonego), ‐ realizator umowy (np. udostepnienie podglądu zawsze dla realizatora umowy + jego przełożonego), ‐ wartość łączna umowy (np. dostęp do umów o określonym rodzaju, o ile ich wartość nie przekracza ustalonej kwoty), ‐ numer umowy (np. uprawnienia podglądu tylko do konkretnej umowy identyfikowanej po numerze), ‐ status umowy (np. uprawnienie podglądu tylko do umów czynnych, nie zakończonych). Wymagalne CRU_032 System powinien umożliwiać podgląd aneksowanych umów w postaci: scalonej (dane aktualne), przed/po aneksie (dane historyczne ‐ z oznaczeniem zmian wprowadzanych między kolejnymi wersjami). Opcjonalne CRU_033 System musi umożliwiać podgląd skanu umowy i jej załączników. Wymagalne CRU_034 Możliwość wydruku lub zapisania na nośniku danych powinna być zablokowana, lub ograniczona dla nieuprawnionych użytkowników poprzez automatyczne naniesienie na skan nieusuwalnych wyraźnych oznaczeń na wszystkich stronach, wskazujących o wydruku roboczym ‐ nie mający mocy umowy (wraz z informacją kto i kiedy pobrał/wydrukował skan). Opcjonalne CRU_035 System musi umożliwiać odzwierciedlenie stanu umowy w postaci statusów umowy (np. projekt umowy, zatwierdzona umowa, zawarta umowa, umowa do anulowana – umowa nie uzyskała wymaganych akceptacji, aktywna, aktywna ‐ okres gwarancyjny, aktywna w trakcie wypowiedzenia, zakończona, zawarta – nie weszła w życie itp.). Wymagalne CRU_036 Statusy umowy muszą być oparte o słownik i ścieżkę zmian statusów, definiowalną przed administratora systemu. Dopuszcza się możliwość wykorzystania funkcjonalności komponentu EOD pod warunkiem zapewnienia pełnej integracji.
Wymagalne CRU_037 System musi pozwalać na wiązanie umów ramowych z umowami wykonawczymi do nich, wraz z sygnalizowaniem prób przekroczenia określonych wartości (np. uniemożliwienie przekroczenia przez umowy wykonawczej łącznej wartości umowy ramowej) Wymagalne Umowy ubezpieczeniowe CRU_039 System powinien umożliwiać dla umów ubezpieczeniowych prowadzenie rejestru polis. Opcjonalne CRU_040 System powinien umożliwiać dla umów ubezpieczeniowych prowadzenie rejestru szkód. Opcjonalne CRU_041 System powinien umożliwiać dla umów ubezpieczeniowych prowadzenie rejestru rozliczeń. Opcjonalne CRU_042 Rejestr polis powinien przechowywać następujące informacje niezbędne w procesach realizacji oraz rozliczania umów ubezpieczenia. W szczególności powinien rejestrować następujące dane: ‐ nr obcy umowy ubezpieczenia (w powiązaniu z CRU), ‐ nr polisy/certyfikatu, ‐ przedmiot ubezpieczenia, ‐ rodzaj ubezpieczenia, ‐ początek okresu ubezpieczenia, ‐ koniec okresu ubezpieczenia, ‐ naliczona składka, ‐ kwota, ‐ nr i data faktury/faktur lub innego dokumentu/innych dokumentów, ‐ data zapłaty składki, Opcjonalne Strona 36 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐ nr i data dokumentu rozliczenie składki po zakończeniu umowy, ‐ kwota i data rozliczenia składki, ‐ informacja o harmonogramie płatności wynikającym z umowy / polisy, uwagi. CRU_043 Rejestr polis powinien rejestrować następujące zakres danych dla zdarzenia szkodowego: ‐ data powstania szkody, ‐ numer rejestracyjny i marka pojazdu lub przedmiot szkody(w powiązaniu z ewidencją majątku), ‐ numer referencyjny szkody, ‐ data zgłoszenia szkody, ‐ rodzaj ryzyka/wykorzystywanej polisy, ‐ wypłacone odszkodowanie, ‐ kwota odszkodowania, ‐ data wypłaty, ‐ podmiot upoważniony do odbioru, ‐ aktualna wysokość rezerwy, ‐ wysokość regresów, ‐ stan sprawy. Opcjonalne CRU_044 System musi umożliwiać podpięcie dokumentów i skanów w kontekście umowy ubezpieczeniowej, polisy, szkody (np. skan polisy, faktury, dowód rejestracyjny pojazdu, skany dokumentacji szkodowej, opis zdarzenia itp.). Opcjonalne CRU_045 System powinien umożliwiać rejestrację harmonogramu wystawiania polis przez ubezpieczyciela. Opcjonalne CRU_046 System powinien umożliwiać rozliczanie umowy ubezpieczenia po jej zakończeniu, poprzez: ‐ przygotowanie wniosku o rozliczenie składki, ‐ przeliczenie należnej składki z uwzględnieniem faktycznego okresu ubezpieczenia dla wybranych środków trwałych, ‐ rozliczanie operacji bankowych. Opcjonalne CRU_047 System powinien wyświetlać komunikat informujący o zaistnieniu przelewu, przy rozliczaniu dokumentu noty rozliczeniowej z przelewem środków w przypadku, gdy z rozliczenia ubezpieczenia wynika dopłata lub zwrot składki . Opcjonalne CRU_048 System powinien mieć raport dotyczący o nowych / istniejących umów dzierżawy wskazujących na lokalizację ubezpieczanej ruchomości oraz informacji o obcym majątku ruchomym użytkowanym na podstawie umów. Opcjonalne CRU_049 System powinien mieć możliwość przechowywania w zakresie lotów kabinowych co najmniej następujących informacji niezbędnych w procesach przygotowywania OPZ, realizacji umowy ubezpieczenia oraz rozliczenia składki po zakończeniu umowy: ‐ data zgłoszenia do ubezpieczenia (wymagana akcja systemowa ‐ komunikat np. e‐mail), ‐ nazwisko osoby delegowanej, ‐ imię osoby delegowanej, ‐ symbol komórki organizacyjnej, ‐ data planowanego lotu, ‐ kierunek wyjazdu, ‐ alternatywny kierunek wyjazdu, ‐ tel. do ubezpieczonego, ‐ uwagi (folder z możliwością przechowywania dokumentacji w różnych formatach, np. potwierdzenie wykorzystania lotu kabinowego, skany dokumentacji szkodowej, opis zdarzenia i in.). Opcjonalne Umowy serwisowe dotyczące infrastruktury IT CRU_050 System musi umożliwiać ewidencję informacji o wartości umów serwisowych. Wymagalne Strona 37 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
CRU_051 System musi udostępniać bieżące informacje o kosztach umów serwisowych. Wymagalne Inne umowy CRU_052 System musi umożliwiać prowadzenie ewidencji umów dotyczących wykorzystania pojazdów prywatnych do celów służbowych. Wymagalne Powiadomienia CRU_053 System musi generować powiadomienia o zbliżaniu się lub przekroczeniu terminów zawartych w umowie lub związanych z umową. Wymagalne CRU_054 System musi generować powiadomienia o kończącym się okresie gwarancyjnym. Wymagalne CRU_055 System musi generować powiadomienia o zbliżającym się terminie zakończenia realizacji danego zadania. Opcjonalne CRU_056 System musi generować powiadomienia o zmianie statusu umowy przez innego użytkownika). Wymagalne CRU_057 System powinien generować powiadomienia o wystąpieniu zdarzenia mającego związek z umową (np. zmiana aktualnych danych kontrahenta powiązanego z umową w rejestrze kontrahentów ‐ wskazujące na potencjalną potrzebę aneksowania umowy). Opcjonalne CRU_058 System musi generować powiadomienia o brakach lub przekroczeniach terminów na potrzeby zarządzania należytym zabezpieczeniem umowy. Wymagalne CRU_059 System na podstawie harmonogramu obciążeń danej umowy musi zapewniać przypominanie/alertowanie o zbliżającym się terminie fakturowania pozycji umowy. Wymagalne CRU_060 System powinien generować powiadomienia o braku przekazania oryginałów w określonym czasie od podpisania umowy. Opcjonalne CRU_061 System powinien generować powiadomienia informujące o zarejestrowaniu nowej szkody związanej z realizacją umowy ubezpieczeniowej. Opcjonalne Integracja CRU_062 System musi zapewnić mechanizm umożliwiający powiązanie umów z danymi i dokumentami rejestrowanymi w odpowiednich modułach komponentu ERP. Wymagalne CRU_063 System powinien zapewnić podgląd listy rekordów wszystkich obiektów powiązanych z umową, bezpośrednie przejście na wybrany obiekt powiązany z umową oraz przefiltrowywanie wszystkich rekordów obiektów, które mogą być powiązane z umową, tylko do tych gdzie takie powiązanie zostało utworzone. Opcjonalne CRU_064 System musi umożliwiać powiązanie umowy zakupu nieruchomości lub najmu/dzierżawy nieruchomości ze zobowiązaniami wynikającymi z faktu posiadania i utrzymywania tej nieruchomości (np. podatki gruntowe, media, koszenie trawy itd.).
Wymagalne CRU_065 System powinien umożliwiać gromadzenie na poziomie umowy danych o naliczeniu kar umownych i zawartych ugodach, z zakresem danych umożliwiającym wystawianie not obciążeniowych, w szczególności: tytuł kary/opis, kwota, data obciążenia lub ugody, numer noty (jeżeli została wystawiona) Opcjonalne CRU_066 System musi zapewnić automatyczne wykorzystanie informacji o rachunku bankowym Agencji, warunkach płatności zapisanymi z umową przy wystawianiu dokumentu należności/zobowiązania powiązanego z umową. Wymagalne Raporty i analizy CRU_067 System musi mieć możliwość udostępniania danych dostępnych na umowie (w tym harmonogramów) w postaci raportów w formacie Word i Excel, definiowanych w postaci szablonów raportów przez administratora systemu ‐ bez konieczności wsparcia dostawcy systemu. Wymagalne Strona 38 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
CRU_068 System powinien zapewniać możliwość wydruku pozycji rejestru umów. Opcjonalne CRU_069 Dostęp do generacji raportów musi być oparty o mechanizm uprawnień (analogiczny jak dla podglądu danych umowy). Wymagalne Struktura organizacyjna Wymagania ogólne ORG_001 System musi zapewnić ewidencję i zarządzanie strukturą organizacyjnej PAZP. Wymagalne ORG_002 System musi umożliwiać administrację strukturą organizacyjną w jednym miejscu dla całego systemu (nie tylko komponentu ERP). W przypadku, gdy w Systemie konieczne jest redundantne przechowywanie struktury w modułach / komponentach, System musi zapewniać, że modyfikacja struktury następuje tylko w jednym miejscu, a synchronizacja do pozostałych miejsc jest automatyczna, on‐line i synchroniczna. Wymagalne ORG_003 System musi umożliwiać tworzenia hierarchicznej struktury organizacyjnej w postaci rozwijanego drzewa. Wymagalne ORG_004 System musi umożliwiać graficzną prezentację struktury organizacyjnej w postaci drzewa. Wymagalne ORG_005 System musi umożliwiać tworzenia równoległych struktur organizacyjnych (np. struktura wg regulaminu organizacyjnego, struktura wg lokalizacji). Wymagalne ORG_006 System powinien umożliwiać przenoszenie, przez administratora lub użytkownika, jednostek organizacyjnych w ramach struktury wraz z obiektami powiązanymi np. pracownikami. W szczególności system powinien umożliwiać zautomatyzowane przenoszenie pracowników ze starej do nowej wersji struktury organizacyjnej. Opcjonalne ORG_007 System musi umożliwiać wersjonowanie struktury organizacyjnej historycznie. Każda wersja struktury musi mieć możliwość określenia czasu jej obowiązywania (od, do). System musi automatycznie prezentować strukturę aktualną na dany moment czasowy, wynikający z kontekstu. Wymagalne ORG_008 System musi umożliwiać utworzenie nowej wersji struktury organizacyjnej poprzez skopiowanie dotychczasowej i jej modyfikacje. Wymagalne ORG_009 System nie może mieć ograniczenia ilości poziomów w strukturze organizacyjnej. Wymagalne ORG_010 System musi zapewnić funkcjonalność pozwalającą użyć strukturę organizacyjną wg dowolnego punktu czasowego. Wymagalne ORG_011 System musi umożliwiać oznaczanie elementów struktury kodami/skrótami z użyciem liter i cyfr. Wymagalne ORG_012 System powinien umożliwiać nazywanie każdej pozycji w strukturze organizacyjnej w 2 językach równolegle (polski, angielski). Opcjonalne ORG_013 System musi zapewnić w szczególności możliwość przeprowadzenia zmian w strukturze organizacyjnej: ‐ Zmiana podporządkowania jednostki organizacyjnej w strukturze organizacyjnej, ‐ Zmiana symbolu i/lub nazwy jednostki, z zachowaniem danych historycznych, ‐ Likwidacja jednostki organizacyjnej z określoną datą i blokada używania tej jednostki (np. zatrudnienie nowego pracownika) powyżej podanej daty, ‐ Utworzenie nowej jednostki organizacyjnej. Wymagalne Raporty i analizy ORG_014 System powinien umożliwiać wydruk graficznej prezentacji struktury organizacyjnej. Opcjonalne Zarządzanie słownikami Wymagania ogólne Strona 39 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
SL_001 Słowniki w Systemie muszą być wspólne dla wszystkich modułów oraz komponentów. W przypadku, gdy w Systemie konieczne jest redundantne przechowywanie słowników w modułach / komponentach, System musi zapewniać, że modyfikacja słownika następuje tylko w jednym miejscu, a synchronizacja do pozostałych miejsc jest automatyczna, on‐line i synchroniczna. Wymagalne SL_002 Słowniki używane w systemie muszą zapewniać zmienność w czasie. Niewykorzystywane pozycje słowników powinny być archiwizowane i system powinien blokować ich użycie poza okresem obowiązywania. Wymagalne SL_003 System powinien zapewniać operacje grupowe umożliwiające grupową aktualizację danych, w których są wykorzystywane wskazane pozycje słownika. Opcjonalne SL_004 Wszędzie tam, gdzie jest to wymagane system musi umożliwiać definicję szczegółowych uprawnień dotyczących możliwości edycji słownika lub tylko jego przeglądania i używania jego pozycji. Wymagalne SL_005 System powinien zapewniać mechanizm podwójnego zatwierdzania wartości w kluczowych słownikach. Uprawniony użytkownik dokonywałby modyfikacji pozycji słownika, które byłyby wykorzystywane w systemie dopiero po zatwierdzeniu przez użytkownika z wyższymi uprawnieniami. System powinien zapewniać możliwość takiej konfiguracji poziomów zatwierdzania, aby użytkownik, który modyfikuje słownik nie mógł zatwierdzać zmian. Opcjonalne SL_006 System powinien dla każdego słownika umożliwiać jego uzupełnianie przez uprawnionego użytkownika w trakcie rejestracji danych wykorzystujących dane słownikowe. Opcjonalne SL_007 System musi zapewnić tworzenie słowników w wielu językach (co najmniej polski, angielski). Język, w którym wyświetlane są wartości słownika powinien być parametrem ustawianym przez użytkownika jako parametr ekranu lub raportu. Wymagalne Tworzenie nowych słowników SL_008 System musi umożliwiać tworzenie własnych słowników oraz zapewniać możliwość ich wykorzystania w systemie np. podpinanie ich pod pola formularzy. Wymagalne SL_009 System powinien umożliwiać definiowanie słowników hierarchicznych oraz zapewniać możliwość wykorzystania w systemie np. podpinania ich pod pola formularzy. Opcjonalne SL_010 System powinien umożliwiać dla definiowalnych słowników określenia formatu danych przechowywanych w słowniku, w tym co najmniej: wzorca dla kodu słownika ‐ automatyczne nadawanie kodu przez system, maksymalnej długości opisu słownika. Opcjonalne Słowniki finansowe SL_011 System musi mieć jeden wspólny słownik walut. Wymagalne SL_012 System musi umożliwiać ewidencjonowanie tabel kursów i kursów różnych banków. System musi mieć możliwość przechowywania w ramach słowników aktualnych i historycznych kursów NBP dla walut USD, EUR, CHF, CAD, GBP, wraz z numerem tabeli kursowej i datą jej publikacji. Wymagalne SL_013 System powinien mieć możliwość automatycznego, okresowego zaciągania kursów walut z wskazanej witryny lub serwisu (Obecnie PAŻP korzysta z witryny XTB). Umożliwi to wykorzystanie tabel kursowych do obserwacji zmian kursów walut, które są wykorzystywane do operacji wymiany waluty). W trakcie automatycznego importu system powinien zapewnić podstawowe kontrole poprawności danych. Opcjonalne SL_014 System musi mieć możliwość importu kursów walut z pliku o konfigurowalnym formacie (np. xml, csv, txt, xls) wraz z podstawową kontrolą poprawności importu.
Wymagalne SL_015 System powinien zapewnić automatyczne, okresowe aktualizowanie danych dot. wysokości stóp odsetkowych LIBOR, EURIBOR oraz WIBID z wybranego serwisu, np. Money.pl, Bankier.pl. Opcjonalne SL_016 System musi umożliwiać zarządzanie klasyfikacją budżetową w układzie zadaniowym poprzez: Wymagalne Strona 40 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐ dodawanie modyfikację i usuwanie / archiwizację elementów, ‐ przeglądanie elementów , ‐ definiowanie wielu poziomów hierarchii, ‐ obsługa zmiany hierarchii w czasie, ‐ określanie statusu poszczególnych elementów np. archiwalne, aktualne, nowe, ‐ określanie parametrów klasyfikacji zadań tj. kod / symbol, nazwa, opis, czas obowiązywania, typ, dodatkowe definiowalne parametry, ‐ mapowanie i dostęp do informacji o podpiętym do zadania mierniku, ‐ mapowanie i dostęp do informacji o podpiętym do zadania działaniu z baz kosztowych. Zdefiniowana klasyfikacja budżetowa zadaniowa musi być możliwa do wykorzystania również w innych obszarach systemu. SL_017 System musi umożliwiać zarządzanie klasyfikacją budżetową w układzie tradycyjnym (Część, Dział, Rozdział, Paragraf i inne) poprzez: ‐ dodawanie modyfikację i usuwanie / archiwizację elementów, ‐ przeglądanie elementów, ‐ definiowanie wielu poziomów hierarchii, ‐ obsługa zmiany hierarchii w czasie, ‐ określanie statusu poszczególnych elementów np. archiwalne, aktualne, nowe, ‐ określanie parametrów klasyfikacji zadań tj. kod / symbol, nazwa, opis, czas obowiązywania, typ, dodatkowe definiowalne parametry, ‐ mapowanie i dostęp do informacji o podpiętych do pozycji klasyfikacji tradycyjnej zdefiniowanych rodzajów kosztów. Zdefiniowana klasyfikacja zadaniowa musi być możliwa do wykorzystania również w innych obszarach systemu‐ określanie parametrów zadań tj. nazwa, opis, czas obowiązywania, typ (inwestycyjne, Zdefiniowana klasyfikacja zadaniowa musi być możliwa do wykorzystania również w innych obszarach systemu. Wymagalne SL_018 System musi umożliwiać elastyczne definiowanie przez użytkownika reguł wyliczeń w celu ich wykorzystania podczas konfigurowania arkuszy planistycznych i modelu planistycznego. System musi pozwalać na dowolne tworzenie reguł kalkulacyjnych. Wymagalne SL_019 System musi umożliwiać zarządzanie słownikiem MPK‐ów poprzez: ‐ dodawanie modyfikację i usuwanie / archiwizację elementów, ‐ przeglądanie elementów , ‐ definiowanie wielu poziomów hierarchii, ‐ obsługa zmiany hierarchii w czasie, ‐ określanie statusu poszczególnych elementów np. archiwalne, aktualne, nowe, blokada, ‐ określanie parametrów MPK tj. kod / symbol, nazwa, opis, czas obowiązywania, dodatkowe definiowalne parametry, Zdefiniowany słownik MPKów ma być możliwy do wykorzystania również w innych obszarach systemu. Wymagalne SL_020 System musi umożliwiać powiązanie elementów słownika MPK‐ów z elementami struktury organizacyjnej. System ma umożliwiać obsługę zmiany w czasie powiązania MPKów ze strukturą organizacyjną z zachowaniem dotychczasowych historycznych powiązań. Zdefiniowane mapowanie MPKów i struktury organizacyjnej ma być możliwe do wykorzystania również w innych obszarach systemu. Wymagalne SL_021 System musi umożliwiać zarządzanie mapowaniem pozycji klasyfikacji budżetowej w układzie tradycyjnym (Część, Dział, Rozdział, Paragraf i inne) do rodzaju kosztu. Zdefiniowane mapowanie ma być możliwe do wykorzystania również w innych obszarach systemu Wymagalne Strona 41 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Zarządzanie indeksami towarowymi i usługowymi SL_022 System musi zapewnić konfigurowanie procedury akceptacji dotyczącej zakładania nowego indeksu z wykorzystaniem zintegrowanego systemu EOD lub obiegu wewnętrznego o równoważnej funkcjonalności. Wymagalne SL_023 System musi umożliwiać zakładanie nowej pozycji magazynowej lub niemagazynowej przeznaczonej do sprzedaży jako produkt lub usługa. Wymagalne SL_024 System musi umożliwiać nadanie numeru indeksu zgodnego z zasadami indeksowania pozycji sprzedawanych i usług obowiązującymi w PAŻP (zasady te mogą się zmieniać w czasie). W przypadku udostępniania do sprzedaży pozycji indeksu już istniejącej jako magazynowa lub niemagazynowa, system musi zachować jej numerację. Wymagalne SL_025 System musi umożliwiać przypisanie szczegółowych parametrów pozycji indeksu przez uprawnioną osobę z właściwej komórki organizacyjnej odpowiednio do rodzaju działalności (cena, warunki sprzedaży, koszty dostawy, jednostki sprzedaży, dodatkowe informacje według): ‐ Parametry pozycji sprzedawanej działalności nawigacyjnej trasowej, ‐ Parametry pozycji sprzedawanej działalności nawigacyjnej terminalowej, ‐ Parametry pozycji sprzedawanej działalności pozanawigacyjnej. Wymagalne SL_026 System musi umożliwiać przypisanie szczegółowych parametrów pozycji przez uprawnioną osobę z właściwej jednostki organizacyjnej zależnie od rodzaju i charakteru pozycji: ‐ Parametry pozycji zakupowej, ‐ Parametry pozycji magazynowej, ‐ Parametry pozycji niemagazynowej, ‐ Parametry pozycji produkowanej. Wymagalne SL_027 System musi umożliwiać przypisanie, przez uprawnionego użytkownika, parametrów księgowych dla nowego indeksu po przypisaniu parametrów pozycji indeksu. Wymagalne SL_028 System musi umożliwiać akceptację wszystkich parametrów nowej pozycji indeksu przez uprawnionego użytkownika. Wymagalne SL_029 System musi umożliwiać udostępnienie pozycji indeksu do posługiwania się nią w ramach prowadzonej działalności po akceptacji uprawnionego użytkownika. Wymagalne SL_030 Zmiany w parametrach istniejących indeksów muszą być wprowadzane przez poszczególne osoby w takim sam sposób jak dla zakładania nowego indeksu i udostępniane do stosowania po akceptacji uprawnionego użytkownika. Wymagalne SL_031 W przypadku indeksów powiązanych z innymi indeksami magazynowymi poprzez strukturę produktową, system musi wspierać uzgadnianie parametrów w kartotekach pozostałych indeksów (wchodzących do struktury) w sposób właściwy dla procesów i procedur gospodarki magazynowej. Wymagalne Raporty SL_032 System powinien zapewniać możliwość wydruku zestawienia zawierającego pozycję każdego słownika aktualne na dany dzień. Opcjonalne Projekty Wymagania ogólne PRJ_001 System musi zapewnić ewidencjonowanie programów, projektów, etapów projektu, zadań i działań oraz powiązań między tymi obiektami tzn. projekty realizowane w ramach programów, projekt może być podzielony na etapy, zadania realizowane w ramach projektów lub etapów projektu itp. Wymagalne PRJ_002 System musi zapewnić prowadzenie ewidencji Programów Technicznych grupujących projekty i zadania inwestycyjne, z możliwością kontroli zaawansowania realizacji projektów i zadań. Wymagalne Strona 42 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
PRJ_003 System musi zapewnić zarządzanie projektami oraz kontrolowanie realizacji zadań wymagających zarządzania typu projektowego tzn.: zadania merytoryczne, projekty inwestycyjne, zadania wynikające z konieczności dochowania procedur Prawa Zamówień Publicznych, Ochrony Środowiska, Projektów IT, itp. Wymagalne PRJ_004 System musi umożliwić przypisywanie dat rozpoczęcia, zakończenia i czasu trwania ( w dniach, tygodniach, miesiącach i latach) do programu, projektów, etapów projektu i zadań, a także sumowanie czasów trwania zgodnie z powiązaniami między tymi obiektami. Wymagalne PRJ_005 System musi zapewnić możliwość tworzenia harmonogramów programów i projektów w formie tabelarycznej i wykresów Gantta. Wymagalne PRJ_006 System musi umożliwiać zmianę lub/i modyfikację harmonogramu projektu z zachowaniem harmonogramu bazowego. Wymagalne PRJ_007 Systemu musi umożliwić wersjonowanie harmonogramów projektów. Wymagalne PRJ_008 System musi umożliwiać porównanie wersji harmonogramu projektu w szczególności założonego harmonogramu bazowego z jego wykonaniem. Wymagalne PRJ_009 System musi umożliwić ręczną i automatyczną ewidencję opóźnień w realizacji programu, projektu, etapu projektu i zadania. Wymagalne PRJ_010 System musi zapewnić koordynację prac służb własnych oraz zewnętrznych przy urządzeniach i projektach własnych oraz obcych poprzez funkcjonalność zarządzania zasobami w ramach projektów i/lub portfolia projektów. Wymagalne PRJ_011 System musi zapewnić definiowanie zasobów zewnętrznych, które mogą być przypisane do projektu. Wymagalne PRJ_012 System musi pokazywać zestawienie tabelaryczne i graficzne zaangażowania poszczególnych pracowników oraz partnerów zewnętrznych w realizację projektów Wymagalne PRJ_013 System musi umożliwiać prezentację graficzną zaangażowania poszczególnych pracowników i zasobów zewnętrznych w projekty bezpośrednio w systemie. Wymagalne PRJ_014 System musi umożliwiać z zadanym wyprzedzeniem planowania zasobów o określonych kwalifikacjach Wymagalne PRJ_015 Funkcjonalność zarządzania projektami musi umożliwiać ewidencję projektu w podziale na etapy, zadania w sposób, pozwalający na włączenie Microsoft Project Server jako narzędzia pomocniczego za pomocą standardowych interfejsów Systemu. Wymagalne PRJ_016 W systemie muszą być odnotowywane poszczególne kroki realizacji projektu (m. in.: harmonogram, budżet, wykonanie, wykorzystanie zasobów ludzkich, możliwe do wystąpienia ryzyka). Wymagalne PRJ_017 System musi umożliwiać rejestrację w systemie wszystkich dokumentów związanych z przygotowywaniem uruchomienia projektu oraz jego realizacją.
Wymagalne PRJ_018 Uzgadnianie przygotowywanych w ramach projektu dokumentów powinno odbywać się w formie elektronicznej z wykorzystaniem Systemu Elektronicznego Obiegu Dokumentów lub z wykorzystaniem obiegu wbudowanego o równoważnej funkcjonalności. W uzasadnionych przypadkach powinno odbywać się w formie papierowej z możliwością wprowadzenia zeskanowanych dokumentów jako załączniki opracowywanego projektu Opcjonalne PRJ_019 System powinien zapewnić możliwość zdalnej pracy grupowej z dokumentem wraz z elektronicznymi alertami o zmianach dokonanych w dokumencie przez inne, uprawnione osoby (wykorzystanie komponentu EOD lub funkcji wbudowanych o równoważnej funkcjonalności. Opcjonalne PRJ_020 System w ramach funkcjonalności zarządzania projektami musi zapewnić możliwość korzystania z właściwej wersji powiązanych dokumentów. W tym celu System może wykorzystywać funkcjonalną integrację z komponentem EOD. Wymagalne PRJ_021 System musi zapewnić możliwość ewidencjonowania (m.in. określanie ich cech, wpływu na projekt, Wymagalne Strona 43 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
statusu ryzyka) i zarządzania ryzykami dla poszczególnych projektów w sposób zgodny z metodyką zarządzana projektami PRINCE2 lub równoważną zapewniającą co najmniej: ‐ przydział ryzyka konkretnemu zasobowi do zarządzania, ‐ alertowanie o przydziale nowego ryzyka, ‐ raportowanie działań związanych z neutralizacją wpływu ryzyka na realizację projektów, ‐ zatwierdzanie w/w raportów i dezaktywacja ryzyka. PRJ_022 System musi umożliwić tworzenie budżetu projektu i powiązanie tego budżetu z planami inwestycyjnymi. Wymagalne PRJ_023 System musi umożliwić tworzenie i zapamiętywanie wersji budżetu projektu. Wymagalne PRJ_024 System musi zapewnić ewidencję kosztów rzeczywistych projektu w powiązaniu z ewidencją księgową. Wymagalne PRJ_025 Systemu musi umożliwić powiązanie i kontrolowanie rzeczowej realizacji projektu z rzeczowym planem inwestycyjnym. Wymagalne PRJ_026 System musi umożliwiać kontrolę zaawansowania czasowego realizacji projektu względem wybranej wersji planu. Wymagalne PRJ_027 System musi umożliwiać kontrolę zaawansowania finansowego/kosztowego realizacji projektu względem wybranej wersji planu. Wymagalne PRJ_028 System musi umożliwiać kontrolę zaawansowania rzeczowego realizacji projektu względem wybranej wersji planu. Wymagalne Integracja PRJ_029 System musi zapewnić korelację danych finansowych i rzeczowych związanych z planowaniem i realizacją projektów z danymi planistycznymi i księgowymi. Wymagalne PRJ_030 System musi umożliwiać powiązanie pozycji faktury zakupowej z rozliczanym elementem projektu (etap, zadanie). Wymagalne PRJ_031 System musi mieć możliwość automatycznego przeksięgowania kosztów projektu na wybrane konto rozliczeniowe podczas zamknięcia projektu. Wymagalne PRJ_032 System musi mieć możliwość ręcznego przeksięgowania kosztów projektu na wybrane konto rozliczeniowe podczas zamknięcia projektu. Wymagalne PRJ_033 System powinien mieć możliwość zamknięcia podprojektu i przeksięgowania odpowiadającej mu części kosztów na wybrane konto rozliczeniowe podczas zamknięcia podprojektu. Opcjonalne PRJ_034 System musi mieć możliwość powiązania dokumentów kosztowych rejestrowanych i księgowanych w Systemie z projektem na poziomie działania.
Wymagalne PRJ_035 System musi mieć możliwość tworzenia zapotrzebowań zakupu produktów i usług z poziomu działania projektu. Wymagalne PRJ_036 System musi mieć możliwość tworzenia zamówień zakupu produktów i usług z poziomu działania projektu. Wymagalne PRJ_037 System musi obsługiwać listę osób, zgodną z kartoteką kadrową Agencji, uprawnionych do pełnienia funkcji w zespołach projektowych. Opcjonalne PRJ_038 System musi umożliwiać tworzenie list użytkowników ‐ członków zespołu dla danego projektu. Wymagalne PRJ_039 System musi umożliwiać przypisanie odpowiedzialności za projekt oraz poszczególne działania i zadania osobie wybieranej z listy członków zespołu danego projektu. Wymagalne PRJ_040 System musi umożliwiać automatyczne generowanie zadań inwestycyjnych, remontowych i serwisowych z poziomu projektu w podsystemie zarządzania majątkiem. Wymagalne Strona 44 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
PRJ_041 System musi umożliwiać automatyczne księgowanie kosztów działania w momencie raportowania ego zakończenia. Wymagalne PRJ_042 System musi umożliwiać konfigurację analitycznych zapisów księgowych dla całego projektu, oraz dla jego poszczególnych działań, jeśli są różne od zapisów właściwych całemu projektowi. Wymagalne PRJ_043 Przydział pracownika do działań i zadań w projekcie powinien aktualizować jego dostępność dla innych projektów. Opcjonalne PRJ_044 Przydział pracownika do działań i zadań w projekcie powinien aktualizować jego dostępność dla innych zadań i działań planowanych w Agencji. Opcjonalne PRJ_045 Raportowanie zakończenia zadań i działań w projekcie powinno generować zapisy do modułu płacowego w przypadku pracy zasobów osobowych. Opcjonalne Powiadomienia PRJ_046 System musi zapewniać generowanie powiadomień (w postaci komunikatów ekranowych, e‐maile, oraz smsów) dla zdefiniowanych użytkowników (np. osób odpowiedzialnych za projekt/etap projektu, osób odpowiedzialnych za przygotowanie raportów okresowych z projektu, itp.) o zbliżaniu się lub przekroczeniu terminów zawartych w projekcie oraz realizacji poszczególnych zadań. Wymagalne PRJ_048 System musi zapewniać generowanie powiadomienia o zbliżającym się końcu projektu/etapu projektu. Wymagalne PRJ_049 System powinien zapewniać generowanie powiadomienia o zbliżającym się terminie przygotowania raportu okresowego/końcowego projektu. Opcjonalne Raporty PRJ_050 System musi zapewnić szablon i generowanie końcowego raportu z realizacji projektu zawierającego m.in. nazwę projektu, etapy projektu, terminy realizacji projektu, opóźnienia w realizacji projektu, koszty realizacji itp.. Wymagalne PRJ_051 System musi umożliwić eksport końcowego raportu z realizacji projektu do formatu MS Word z możliwością dalszej edycji. Po ręcznym wprowadzeniu zmian i dodatkowych informacji System musi umożliwić wgranie tego raportu jako załącznik, na poziom projektu, którego dotyczy raport. Wymagalne PRJ_052 System powinien zapewnić akceptację raportu końcowego w ramach obiegu dokumentów. Opcjonalne PRJ_053 System powinien zapewniać możliwość tworzenia harmonogramu przygotowania raportów okresowych/końcowych w projekcie/etapie projektu wraz ze wskazaniem: rodzaju raportu, tematu raportu, daty przygotowania, osoby odpowiedzialnej. Opcjonalne PRJ_054 W ramach harmonogramu tworzenia raportów powinna być możliwość określenia daty przygotowania raportu bezwzględnie lub względem daty początku, zakończenia projektu/etapu projektu. Opcjonalne PRJ_055 System musi umożliwiać rozliczenie finansowe projektu poprzez porównanie zestawień planu projektu z jego wykonaniem. Zestawienia te zostaną skonfigurowane przez Zamawiającego. System musi zapewnić narzędzia umożliwiające konfigurowanie tych zestawień przez Zamawiającego. Wymagalne PRJ_056 System musi umożliwiać porównanie założonego planu finansowo‐rzeczowego projektu z faktycznym jego wykonaniem zarówno dla poszczególnych projektów jak i grup projektów. Zestawienia te zostaną skonfigurowane przez Zamawiającego. System musi zapewnić narzędzia umożliwiające konfigurowanie tych zestawień przez Zamawiającego. Wymagalne PRJ_057 System musi umożliwić kontrolę projektów poprzez porównanie założonego harmonogramu bazowego z jego wykonaniem zarówno dla poszczególnych projektów jak i grup projektów. Zestawienia te zostaną skonfigurowane przez Zamawiającego. System musi zapewnić narzędzia umożliwiające konfigurowanie tych zestawień przez Zamawiającego. Wymagalne PRJ_058 W systemie powinny być dostępne zestawienia zbiorcze dla wszystkich projektów oraz pogrupowanych Opcjonalne Strona 45 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
projektów według przyjętych kryteriów przez uprawnionego użytkownika. PRJ_059 System musi zapewnić tworzenie zestawień z realizacji wszystkich projektów w postaci tabelarycznych zestawień z informacjami o opóźnieniach i stopniu realizacji budżetu. Zestawienia te zostaną skonfigurowane przez Zamawiającego. System musi zapewnić narzędzia umożliwiające konfigurowanie tych zestawień przez Zamawiającego. Wymagalne PRJ_060 System musi zapewnić tworzenie zestawień o przewidywanym stopniu realizacji projektów w oparciu o gromadzone informacje o stopniu realizacji tych zamierzeń. Zestawienia te zostaną skonfigurowane przez Zamawiającego. System musi zapewnić narzędzia umożliwiające konfigurowanie tych zestawień przez Zamawiającego. Wymagalne PRJ_061 System musi zapewnić tworzenie zestawień obciążeń zadaniami poszczególnych zasobów dla wartości wykonanych i planowanych. Zestawienia te zostaną skonfigurowane przez Zamawiającego. System musi zapewnić narzędzia umożliwiające konfigurowanie tych zestawień przez Zamawiającego. Wymagalne Raportowanie Wymagania ogólne RAP_001 System musi umożliwiać tworzenie przez administratora schematów raportów zawierających definicję obiektów biznesowych wraz z atrybutami i powiązaniami między obiektami. Wymagalne RAP_002 W systemie musi być możliwe definiowanie uprawnień do schematów raportów z dokładnością do atrybutów. Wymagalne RAP_003 W systemie musi być możliwe definiowanie uprawnień do operacji tworzenia i uruchamiania raportów. Wymagalne RAP_004 System musi zapewni tworzenie raportów za pomocą kreatora. Wymagalne RAP_005 Raporty tworzone z poziomu użytkownika powinny wykorzystywać metodę „przeciągnij i upuść”. Opcjonalne RAP_006 System musi umożliwiać formatowanie danych na raporcie (ustalania szerokości kolumn; etykiet kolumn; podsumowań; maski formatu wyświetlania danych typu data, wartość numeryczna, waluta; itp.) Wymagalne RAP_007 System musi umożliwiać grupowanie danych na raportach. Wymagalne RAP_008 System musi wspierać tworzenie filtrów danych w oparciu o stałe i definiowane parametry uruchamiania raportów. Wymagalne RAP_009 System musi umożliwiać tworzenie szablonów dokumentów powiązanych z dowolnymi danymi w Systemie i uruchamianych z dowolnych rejestrów w Systemie
Wymagalne RAP_010 System musi zapewnić eksportowanie wartości wskaźników i raportów do plików zewnętrznych (Excel, Word, pdf, xml). Wymagalne RAP_011 System musi zapewnić prezentowanie wartości wskaźników i raportów przez przeglądarkę internetową i Wymagalne eksport do pliku html. RAP_012 System musi zapewnić prezentowanie wartości wskaźników i raportów na wykresach w zadanych przekrojach. Wymagalne RAP_013 System powinien zapewnić prezentację graficzną raportów, zestawień i udostępnianie w formie prezentacji dla szybszego przyswojenia przez adresata przekazywanej treści. Opcjonalne Raporty przekrojowe RAP_014 System musi zapewniać narzędzia i struktury, pozwalające na wydobywanie danych przekrojowych dot. umów i kontrahentów, do analiz na szczeblu zarządczym i kierowniczym. Zestawienia te zostaną skonfigurowane przez Zamawiającego. System musi zapewnić narzędzia Wymagalne Strona 46 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
umożliwiające konfigurowanie tych zestawień przez Zamawiającego. RAP_015 System musi posiadać możliwość tworzenia dowolnie modyfikowalnych zestawień z zakresu informacji kadrowych i płacowych (np. po Numer Umowy, Biuro, Komórka organizacyjna, MPK, MPK wraz z PRU, Organ ruchu lotniczego, Lokalizacja itp.) z uwzględnieniem danych historycznych. Zestawienia te zostaną skonfigurowane przez Zamawiającego. System musi zapewnić narzędzia umożliwiające konfigurowanie tych zestawień przez Zamawiającego. Wymagalne Powiadamianie na potrzeby Działu Bezpieczeństwa RAP_016 System musi generować powiadomienia w postaci wiadomości email o wyniku weryfikacji konieczności przeprowadzenia analizy bezpieczeństwa dla zmian wynikających z procesu zarządzania zmianą operacyjną, a także zmian planowanych w procesach związanych z obszarami: ‐ Inwestycji, ‐ Zakupów Remontów, ‐ Nieruchomości, ‐ Infrastruktury ATM/CNS, ‐ Projekty, ‐ Zarządzanie ZSZ, ‐ Szkolenia, ‐ Rozwój personelu. Opcjonalne Tabela 7. Wymagania funkcjonalne ‐ moduły wspólne 2.2.2
Wymagania dotyczące komponentu - Podsystem Zarzadzanie
personelem
Nr
wymagania
Wymaganie
Kategoria
wymagania
Kadry Wymagania ogólne EK_001 System musi zapewnić wyświetlanie danych kadrowych wybranego pracownika, w zakresie zgodnym z uprawnieniami użytkownika do dostępu do danych kadrowych. Wymagalne EK_002 System musi zgodnie z informować o tym, czy zostały wprowadzone wszystkie dane wymagalne do prowadzenia kartoteki. Wymagalne EK_003 System musi zapewnić możliwość zapisywania załączników (w szczególności dla pracownika, umowy). Wymagalne Dane kadrowe EK_004 System musi umożliwiać ewidencjonowanie danych pracowników. Wymagalne EK_005 System musi przechowywać dane osobowe pracowników (w tym drugie imię, imiona rodziców, nazwisko panieńskie matki, obywatelstwa (słownik)). Wymagalne EK_006 System musi przechowywać kompletne dane adresowe pracowników (co najmniej: stały, tymczasowy, korespondencyjny, do PIT). Wymagalne EK_007 System musi przechowywać dane identyfikacyjne (pesel, nip, dowód osobisty, nr paszportu, nr prawa jazdy wraz z kategoriami, musi być możliwość zapisania, że pracownik nie ma prawa jazdy, numer akt, numery przepustek). Dane mogą się zmieniać w czasie, system musi przechowywać historię zmian. Wymagalne EK_008 System musi weryfikować poprawność numerów PESEL i NIP (system musi weryfikować: zgodność z płcią, data urodzenia, liczbą znaków, liczbą kontrolną). Wymagalne EK_009 System musi przechowywać dane o Urzędzie Skarbowym, w którym rozlicza się pracownik. Wymagalne
Strona 47 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EK_010 System musi przechowywać dane o przynależności do oddziału NFZ. Wymagalne EK_011 System musi przechowywać dane wojskowe (nr książeczki wojskowej, WKU, stosunek do służby wojskowej, stopień, kategoria, uwagi). Wymagalne EK_012 System musi przechowywać informacje o warunkach szkodliwych na stanowisku pracy. Wymagalne EK_013 System musi przechowywać historię zmian danych osobowych. Wymagalne EK_014 System musi zapewnić obsługę zmiany/korekty danych identyfikacyjnych pracownika. Wymagalne EK_015 System musi zapewnić obsługę zmiany/korekty danych osobowych pracownika. Wymagalne EK_016 System musi zapewnić obsługę zmiany/korekty danych adresowych pracownika. Wymagalne EK_017 System musi przechowywać dane członków rodziny pracownika. Wymagalne EK_018 System musi zapewnić obsługę zmiany/korekty danych członków rodziny pracownika. Wymagalne EK_019 System musi umożliwiać przechowywanie danych o poprzednich miejscach zatrudnienia (nazwa zakładu pracy, data przyjęcia, data zwolnienia, przyczyna rozwiązania umowy, zaliczenie danego miejsca pracy do staży). Wymagalne EK_020 System musi umożliwiać przechowywanie danych o okresach nieskładkowych z poprzednich zakładów pracy. Wymagalne EK_021 System musi umożliwiać przechowywanie informacji o orzeczeniach o stopniu niepełnosprawności. Wymagalne EK_022 System musi zapewnić obsługę nabycia uprawnień z tytułu niepełnosprawności. Wymagalne EK_023 System musi automatycznie przeliczać dodatkowy wymiar urlopu wynikający z orzeczenia o niepełnosprawności. Wymagalne EK_024 System musi zapewnić rejestrację / zmianę uprawnień do renty/emerytury. Wymagalne Zatrudnienie EK_025 System musi zapewnić obsługę zatrudnienia pracownika (zarządzanie umowami o pracę, umowami cywilno‐prawnymi). Wymagalne EK_026 System musi umożliwić rejestrowanie daty zatrudnienia oraz daty zawarcia aneksów do umowy oraz datę rozwiązania umowy. Wymagalne EK_027 System musi umożliwić rejestracje stanowiska pracownika (słownik). Wymagalne EK_028 System musi umożliwiać definiowanie funkcji dodatkowej, (słownik) jaką pełni pracownik, np.: jest Członkiem zespołu projektowego, Audytorem wewnętrznym itp. Wymagalne EK_029 System musi umożliwić rejestrację wymiaru etatu (słownik umożliwiający definiowanie etatów w postaci ułamka zwykłego oraz ułamka dziesiętnego do dwóch miejsc po przecinku). Wymagalne EK_030 System musi umożliwić rejestrację wynagrodzenia zasadniczego pracownika. Wymagalne EK_031 System musi umożliwiać rejestrowanie kategorii zaszeregowania dla pracownika. Wymagalne EK_032 System musi umożliwić przypisanie pracownika do jednostki organizacyjnej. Wymagalne EK_033 System musi umożliwić rejestrację kodu wykonywanego zawodu (słownik). Wymagalne EK_034 System ma zapewniać obsługę pracowników zatrudnionych jednoczenie na podstawie umowy o pracę oraz umów cywilno‐prawnych. Wymagalne EK_035 System musi umożliwiać ponowne zatrudnienie zwolnionego pracownika. Musi istnieć możliwość wykorzystania wprowadzonych wcześniej danych. Wymagalne Strona 48 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EK_036 System musi umożliwić rejestrowanie zmian warunków umowy. Wymagalne EK_037 System musi umożliwić rejestrowanie zmian jednostki organizacyjnej pracownika. Wymagalne EK_038 System musi umożliwiać rejestrowanie informacji o oddelegowaniu pracownika do pracy w innej komórce. System musi rejestrować czas trwania oddelegowania oraz podległość do oceny. Wymagalne EK_039 System musi umożliwić rejestrowanie przedłużenia umowy pracownika. Wymagalne EK_040 System musi umożliwić rejestrację nabycia/zmiany uprawnień do stałych dodatków do wynagrodzenia (procentowych lub kwotowych). Wymagalne EK_041 System musi umożliwić rejestrację informacji o zakończeniu zatrudnienia pracownika. Wymagalne EK_042 System musi zapewnić wykonywanie operacji grupowych powodujących zmianę danych dla wybranej grupy pracowników. Przykładowo: ‐ Grupowa zmiana stawki na umowie, stawki zaszeregowania dla grupy pracowników. ‐ Grupowa zmiana dodatków na umowie np. dodatków instruktorskich za godziny pracy w locie, ‐ Grupowa zmiana dodatków płacowych np. z tytułu pracy w warunkach szczególnych, ‐ inne pracochłonne operacje dotyczące grupy pracowników. Wymagalne EK_043 System musi umożliwiać przypisanie pracownikowi organu kontroli ruchu lotniczego wraz z historią zmian. Wymagalne EK_044 System musi umożliwiać przypisanie pracownikowi obsługiwanej przez niego Lokalizacji wraz z historią zmian. Wymagalne EK_045 System musi umożliwiać przypisanie pracownikowi kilku Kategorii PRU z przypisaniem podziału procentowego dla każdej z nich wraz z historią zmian. Wymagalne EK_046 System musi przechowywać historię zmian Kategorii PRU. Wymagalne EK_047 System musi umożliwiać wprowadzenie planowanych zmian Kategorii PRU dla pracownika. Wymagalne Kwalifikacje EK_048 System musi wspomagać zarządzanie kwalifikacjami. Wymagalne EK_049 System musi umożliwiać ewidencję informacji o wykształceniu pracownika (m.in. szkoły, szkolenia, kursy, studia podyplomowe). Wymagalne EK_050 System musi umożliwiać ewidencję informacji o poziomie wykształcenia (słownik). Wymagalne EK_051 System musi umożliwiać ewidencję informacji o stopniu naukowym (słownik). Wymagalne EK_052 System musi umożliwiać ewidencję informacji o ukończonych szkołach (nazwa szkoły (słownik), nazwa wydziału, kierunek (słownik), specjalizacja (słownik), data rozpoczęcia, data ukończenia, uzyskany stopień naukowy, nr dyplomu, klasyfikacja wykształcenia, liczba lat do stażu) . Wymagalne EK_053 System musi umożliwiać ewidencję doświadczenia zawodowego (umiejętności pracy w danych obszarach). Wymagalne EK_054 System musi umożliwiać ewidencję znajomości języków obcych (podwójna nomenklatura w przypadku j. angielskiego). Poziomy znajomości języka według ICAO oraz Europejskiego Systemu Kształcenia Językowego. Wymagalne Ubezpieczenia ZUS (Płatnik) EK_055 System musi umożliwiać rejestrowanie wszystkich danych, jakie mogę być przekazywane do programu Płatnik tzn. nie powinno być konieczności uzupełnienia lub zmiany danych w programie Płatnik. Wymagalne EK_056 Na podstawie informacji wprowadzonych do Systemu, musi on automatycznie generować dokumenty do Płatnika. Wymagalne Strona 49 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EK_057 System musi zapewnić generowanie korekt, jeśli pojawi się taka potrzeba. Wymagalne EK_058 System musi zapewnić obsługę dokumentów przekazywanych do ZUS w związku z korektą absencji. Wymagalne EK_059 System musi obsługiwać generowanie dokumentów ZUA. Wymagalne EK_060 System musi obsługiwać generowanie dokumentów ZIUA. Wymagalne EK_061 System musi obsługiwać generowanie dokumentów ZWUA. Wymagalne EK_062 System musi obsługiwać generowanie dokumentów ZCNA. Wymagalne EK_063 System musi obsługiwać generowanie dokumentów ZZA. Wymagalne Absencje i limity absencji EK_064 System musi umożliwiać rejestrowanie planów urlopowych pracowników. Wymagalne EK_065 System musi zapewnić obsługę nabycia/zmiany uprawnień do urlopu wypoczynkowego. Wymagalne EK_066 System musi przeliczać wymiar urlopu w przepadku zmian, które mogą mieć wpływ na uzyskanie prawa do urlopu wypoczynkowego lub jego wymiar, np. rozwiązanie umowy o pracę, rejestracja ukończonej szkoły. Wymagalne EK_067 System musi zapewniać możliwość rejestrowania różnych rodzajów absencji pracownika. Wymagalne EK_068 System musi zapewnić obsługę świadczeń rehabilitacyjnych. Wymagalne EK_069 Rejestrowanie absencji może odbywać się bezpośrednio w Systemie jak również w przypadku urlopów poprzez portal samoobsługowy. Przy czym w drugim przypadku użytkownicy muszą mieć możliwość weryfikacji danych przed ich zapisaniem w systemie. Wymagalne EK_070 System musi uniemożliwiać rejestrowanie dwóch absencji na ten sam dzień. Wymagalne EK_071 System musi zapewniać kontrolę limitów absencji wynikających z przepisów prawa pracy i uniemożliwiać zapis danych, przekraczających te limity. W szczególności system powinien kontrolować limity urlopów (wypoczynkowego, dodatkowego, opieka nad zdrowym dzieckiem) oraz limity absencji chorobowych (opieka nad dzieckiem, opieka nad chorym członkiem rodziny). Wymagalne EK_072 Zakres rejestrowanych danych w Systemie musi co najmniej wystarczyć do rozliczania absencji w płacach, wygenerowania dokumentów do systemu Płatnik. Wymagalne EK_073 System musi zapewnić kontrolę okresu zasiłkowego. Wymagalne EK_074 System musi umożliwić wprowadzenie informacji o wykorzystanym urlopie w poprzednich miejscach pracy. Wymagalne EK_075 System musi umożliwić korekty absencji. Proces dotyczy przypadku korekty absencji w zakresie: ‐Stornowania wprowadzonej absencji, ‐Skrócenie okresu obowiązywania absencji, ‐Zmiana rodzaju absencji. Wymagalne EK_076 System musi wyliczać aktualny stan wykorzystania urlopów przez pracowników, w podziale na urlop bieżący, zaległy, wykorzystany, pozostały.
Wymagalne EK_077 System musi przenosić niewykorzystany urlop na kolejny rok (jako urlop zaległy).
Wymagalne
Czas pracy EK_078 System musi zapewnić obsługę planowania i rozliczania czasu pracy dla poszczególnych grup pracowników. Wymagalne EK_079 System musi umożliwiać planowanie i rozliczanie co najmniej następujących systemów (schematów) czasu pracy: Wymagalne Strona 50 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐ podstawowy oraz podstawowy zmianowy, ‐ równoważny, ‐ zadaniowy, ‐ przerywany. EK_080 System na podstawie zdefiniowanych systemów (schematów/szablonów) czasu pracy musi generować harmonogramy dla grup pracowników. Wymagalne EK_081 System musi zapewnić możliwość modyfikacji planów oraz harmonogramów na poziomie grupy pracowników. Wymagalne EK_082 System musi umożliwiać tworzenie harmonogramów czasu pracy dla pracownika na podstawie harmonogramu dla grupy. Wymagalne EK_083 System musi umożliwiać tworzenie harmonogramów czasu pracy również dla osób niepełnosprawnych, pracujących na część etatu oraz matek karmiących. Wymagalne EK_084 System musi zapewnić możliwość modyfikacji harmonogramu pracownika. Wymagalne EK_085 System musi umożliwiać planowanie i rozliczanie różnych typów godzin ‐ godziny nominalne, nadgodziny, praca w porze nocnej, praca w niedzielę i święta, oraz różnych kategorii typów godzin: dyżury, dyżury domowe, szkolenia, delegacje itp. Słownik typów godzin oraz kategorii typów godzin musi być zgodny z system Quintiq. Wymagalne EK_086 System musi umożliwić również obsługę planowania i rozliczania czasu pracy pracowników placówki służby zdrowia (lekarzy, pielęgniarki), działu szkoleń (wykładowców, trenerów, instruktorów). Wymagalne EK_087 System musi umożliwić rejestrację planów oraz rozliczenia dyżurów oraz dyżurów domowych związanych z obsługą infrastruktury CNS/ATM. System musi posiadać możliwość rejestracji informacji związanych z dyżurem: obsady (imiona, nazwiska, uwagi) oraz daty i czasu rozpoczęcia i zakończenia. Wymagalne EK_088 System powinien zapewnić wielopoziomową ewidencję czasu pracy ‐ system powinien mieć możliwość planowania harmonogramu czasu pracy na poziomie komórki organizacyjnej, weryfikacji na poziomie specjalistów czasu pracy w kadrach, potwierdzania na poziomie zarządczym. Wymagalne EK_089 System powinien umożliwiać wieloetapowe zatwierdzanie planów czasu pracy w okresach rozliczeniowych na poziomie zarówno pojedynczego pracownika jak i grupy pracowników. Wymagalne EK_090 System powinien zapewnić ewidencję czasu pracy zależnie od stanowiska i charakteru pracy. Wymagalne EK_091 System musi umożliwić przypisanie czasu pracy pracownika do procesu biznesowego, a tam gdzie to możliwe równolegle do zadania, zlecenia lub projektu. Wymagalne Staż pracy EK_092 System musi umożliwić automatyczne wyliczenie okresów stażowych na podstawie przebiegu zatrudnienie w poprzednich miejscach pracy, przebiegu zatrudnienie w PAZP, okresów nieskładkowych, ukończonych szkół). Wymagalne EK_093 W szczególności system musi wyliczać: ‐ staż pracy ogółem, ‐ staż do dodatku stażowego, ‐ staż pracy w PAŹP, ‐ staż do urlopu wypoczynkowego, ‐ staż do nagrody jubileuszowej, ‐ staż pracy do emerytury. Wymagalne Badania okresowe EK_094 System musi zapewnić rejestrację i obsługę badań lekarskich, badań lotniczo‐lekarskich. System musi obsługiwać różne rodzaje badań dla różnych grup pracowniczych, z uwzględnieniem warunków szkodliwych oraz daty ważności tych badań, Wymagalne Strona 51 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Pozostałe dane kadrowe EK_095 System musi zapewnić obsługę kar pracowniczych. System powinien umożliwiać rejestrowanie informacji o karach pracowników z możliwością ich całkowitego usunięcia z systemu przez użytkownika. Wymagalne EK_096 System musi umożliwiać ewidencję wniosków o przyznanie poświadczenia bezpieczeństwa (data złożenia wniosku, data rozpatrzenia wniosku, decyzja, uwagi). Wymagalne EK_097 System musi umożliwiać ewidencję informacji o posiadanych przez pracowników poświadczeniach bezpieczeństwa (nazwa certyfikatu, klauzula tajności, numer dokumentu, datę uzyskania, datę ważności). Wymagalne EK_098 System musi umożliwić ewidencjonowanie danych o upoważnieniach (numery, rodzaj czynności, zakres upoważnienia, data przyznanie, data ważności). Wymagalne EK_099 System musi umożliwiać ewidencjonowanie uprawnień Kontrolera Ruchu Lotniczego, w szczegółowości (nr licencji, daty uzyskania uprawnień, daty ważności uprawnień). System powinien przechować dane historyczne, bieżące i planowane. Wymagalne EK_100 System musi umożliwiać ewidencję informacji o uprawnieniach posiadanych przez pracownika np. do obsługi danego urządzenia czy systemu. System musi umożliwiać przechowywanie informacji o licencjach i ich ważności. Wymagalne EK_101 System musi umożliwiać definiowanie funkcji dodatkowej, jaką pełni pracownik, np.: jest Członkiem zespołu projektowego, Audytorem wewnętrznym itp. Wymagalne Delegacje (wyjazdy służbowe)* *UWAGA: Jeśli tego nie wskazano, wszystkie wymagania dotyczą zarówno wyjazdów służbowych krajowych i zagranicznych EK_102 System musi posiadać rejestr wniosków o realizację wyjazdu służbowego (krajowych i zagranicznych). Wymagalne EK_103 System musi umożliwiać obieg wniosków o realizację wyjazdu służbowego krajowego. Wymagalne EK_104 System musi umożliwiać obieg wniosków o realizację wyjazdu służbowego zagranicznego. Wymagalne EK_105 System powinien na etapie realizacji wniosku o realizację wyjazdu służbowego (kalkulacji kosztów) mieć możliwość automatycznego wyliczania przysługujących diet. Opcjonalne EK_106 System powinien mieć możliwość dokonania kalkulacji całkowitego kosztu wyjazdu zagranicznego w oparciu o aktualną tabelę kursów. Opcjonalne EK_107 System musi umożliwiać stworzenie specyfikacji kosztów wyjazdu służbowego i powiązanie z pozycją kosztów w budżecie komórki organizacyjnej. Wymagalne EK_108 System powinien umożliwiać potwierdzenie dostępności środków finansowych na realizację wniosku o realizację wyjazdu służbowego przez jednostkę organizacyjną odpowiedzialną za budżet. Opcjonalne EK_109 System musi umożliwić pracownikowi, który odbył wyjazd służbowy sporządzenie rozliczenia w systemie, w tym podpięcie odpowiednich kwot poniesionych kosztów (wymagania integracja z modułem księgowym i rozrachunkowym).
Wymagalne EK_110 System musi mieć możliwość informowania o anulowaniu wyjazdu służbowego, zarówno, gdy anulowanie powoduje i nie powoduje poniesienia kosztów (mogą wystąpić koszty odwołanego wyjazdu służbowego – np. koszt anulowania biletu). Wymagalne EK_111 System musi mieć możliwość przekazania informacji (np. poprzez mechanizm powiadomień) o anulowaniu wyjazdu służbowego do wskazanych komórek organizacyjnych, zgodnie z ustaloną ścieżką. Wymagalne EK_112 System musi umożliwiać sporządzenie sprawozdania z wyjazdu służbowego zagranicznego przez osobę delegowaną. Wymagalne EK_113 System musi umożliwić obieg sprawozdania z wyjazdu służbowego zagranicznego. Wymagalne Strona 52 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EK_114 System musi mieć możliwość powiadamiania przekroczenia terminów złożenia sprawozdania z wyjazdu służbowego zagranicznego (np. w terminie 30 dni od zakończenia wyjazdu). Wymagalne EK_115 System musi zapewnić dostęp pracownika do danych w zakresie jego wyjazdów służbowych oraz sprawozdań służbowych zagranicznych. Wymagalne EK_116 System powinien wymuszać wypełnienie wniosku o wykorzystanie samochodu prywatnego do celów służbowych, w przypadku, gdy pracownik wypełniając wniosek o wyjazd służbowy wybierze jako środek transportu – samochód prywatny. Opcjonalne EK_117 Wniosek o wykorzystanie samochodu prywatnego do celów służbowych powinien być powiązany z wyjazdem służbowym w ramach, którego będzie on wykorzystywany oraz z umową na użytkowanie samochodu prywatnego. Opcjonalne EK_118 System musi umożliwić wprowadzanie kilku wariantów kalkulacji kosztów wyjazdu służbowego w zależności od wyboru m.in. środka transportu, hotelu itp. oraz wskazywania wariantu obowiązującego. Wymagalne EK_119 System musi umożliwiać integrację modułu obsługującego wyjazdy służbowe z modułem kadrowym, w szczególności w zakresie nieobecności spowodowanych wyjazdem służbowym. Wymagalne EK_120 System powinien mieć możliwość sprawdzenia terminowości i rozliczenia poprzednich wyjazdów służbowych przed zatwierdzeniem kolejnego wniosku o wyjazd służbowy. Opcjonalne EK_121 System musi umożliwiać prowadzenie ewidencji wyjazdów służbowych zagranicznych, zawierającej w szczególności następujące dane: ‐ Nr wniosku, ‐ Nr spec., ‐ Symbol komórki organizacyjnej, ‐ Nazwisko Imię, ‐ Kategoria, ‐ Cel, ‐ Data wyjazdu, ‐ Data powrotu, ‐ Koszt biletu dla Działu Zarzadzanie i organizacja, ‐ Koszt całkowity, ‐ Firma, ‐ Sprawozdania. ‐ Inne dane potrzebne do kalkulacji diety i kosztów delegacji oraz prawidłowego rozliczenia delegacji. Wymagalne EK_122 System musi umożliwiać sporządzenie raportu z niezatwierdzonych sprawozdań z wyjazdów zagranicznych, zawierający w szczególności następujące dane: ‐ Lp. ‐ Symbol komórki organizacyjnej, ‐ Nazwisko Imię, ‐ Kraj, ‐ Miasto, ‐ Kategoria, ‐ Cel, ‐ Data wyjazdu, ‐ Data powrotu, ‐ koszt całkowity, ‐ Sprawozdania, ‐ Zalega dni. Wymagalne EK_123 System musi umożliwiać rejestrację co najmniej następujących danych w przypadku ewidencji zarezerwowanych biletów lotniczych: ‐ Lp., Wymagalne Strona 53 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐ Nr wniosku, ‐ Data wpływu, ‐ Symbol komórki organizacyjnej, ‐ MPK, ‐ Nazwisko Imię, ‐ Trasa przelotu, ‐ Data wyjazd, ‐ Data powrotu, ‐ Koszt biletu zakupionego w AAZ, ‐ Firma. EK_124 System musi umożliwiać rejestrację co najmniej następujących danych w przypadku rezerwacji hoteli: ‐ Lp., ‐ Dla kogo, ‐ W celu, ‐ Od, Do, ‐ Hotel, ‐ Miasto, ‐ Kraj, ‐ Osób, ‐ Dób, ‐ Inne, ‐ Razem bez innych, ‐ Dodał, ‐ Anulowano, ‐ Powód, ‐ Załączniki (pliki). Wymagalne EK_125 System powinien umożliwiać ewidencjonowanie Rocznego Planu służbowych wyjazdów zagranicznych. Wymagalne EK_126 System powinien umożliwiać ewidencjonowanie harmonogramu służbowego wyjazdu zagranicznego. Opcjonalne EK_127 System musi umożliwić kandydatowi wypełnienie na stronie internetowej formularza z danymi kandydata. Wymagalne EK_128 Funkcjonalność obsługi wyjazdów służbowych powinna być zintegrowana z modułem obsługującym realizacje szkoleń zewnętrznych w zakresie powiązanie szkolenia z wyjazdem służbowym. Wymagalne EK_129 System musi umożliwiać powiązanie modułu obsługującego wyjazdy służbowe z modułem planistycznym, w szczególności System musi wyliczać bieżące wykorzystanie budżetu przeznaczonego na wyjazdy służbowe. Wymagalne EK_130 Moduł obsługi wyjazdów służbowych musi być powiązany z modułem księgowym m.in. w zakresie: ‐ rozliczania zewnętrznych dokumentów finansowych, w przypadku rozliczania dokumentów wyjazdu służbowego oraz faktur za hotel, bilet za samolot, oraz innych wydatków związanych z wyjazdem służbowym, ‐ rozliczania wewnętrznych dokumentów finansowych, np. zaliczka na wyjazd służbowy. Wymagalne Powiadomienia EK_131 W przypadku zaistnienie określonych zdarzeń, System musi generować automatyczne powiadomienia do użytkowników odpowiedzialnych za dany obszar (zdarzenie) oraz jeżeli jest to konieczne również do osób, których dotyczy powiadomienie w formie komunikatów systemowych i / lub wiadomości e‐mail i / lub sms. Wymagalne EK_132 System powinien posiadać mechanizmy definiowania powiadomień związanych ze zdarzeniami, które mają wpływ na obowiązki czy uprawnienia pracownicze. Wymagalne EK_133 System musi generować powiadomienia związane z okresem trwania zwolnień lekarskich w celu kierowania pracowników na badania kontrolne. Wymagalne Strona 54 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EK_134 System musi generować powiadomienie o koniczności skierowania pracowników na badania okresowe. Wymagalne EK_135 System musi generować powiadomienia o konieczności uzyskania uprawnień dostępu do inf. niejawnej przy zatrudnianiu nowego pracownika. Wymagalne EK_136 System musi generować powiadomienia o konieczności uzyskania uprawnień dostępu do inf. niejawnej przy zmianie stanowiska przez pracownika PAŻP. Wymagalne EK_137 System musi generować powiadomienie o zbliżającym się terminie ważności poświadczeń bezpieczeństwa. Wymagalne EK_138 System musi generować powiadomienia o zbliżającym się terminie zakończenia umów na okres próbny oraz na czas określony. Wymagalne EK_139 System musi generować powiadomienia o zmianie wymiaru urlopu. Wymagalne EK_140 System musi generować powiadomienia o terminie nagrody jubileuszowej. Wymagalne EK_141 System musi generować powiadomienia o terminie osiągnięciu wieku emerytalnego. Wymagalne EK_142 System musi generować powiadomienia o zbliżającym się terminie wygaśnięcia certyfikacji. Wymagalne EK_143 System musi generować powiadomienia o konieczności rozliczenia delegacji. Wymagalne EK_144 System musi generować powiadomienia o konieczności rozliczenia zaliczki na delegację. Wymagalne Słowniki EK_145 System musi posiadać słownik rodzajów absencji zawierający wszystkie rodzaje absencji wynikające z przepisów prawa. Administrator musi mieć możliwość dopisywania nowych rodzajów absencji specyficznych dla PAŻP. Wymagalne EK_146 System musi umożliwiać ewidencjonowanie stanowisk pracy w przypisanie dat ważności stanowiska. Musi być możliwość przypisanie stanowiska do grupy np. kierownicze, robotnicze. Wymagalne EK_147 System musi umożliwiać rejestrację poziomów wykształcenia. Wymagalne EK_148 System musi umożliwiać rejestrację danych dotyczących kategorii PRU (Performance Review Unit – EUROCONTROL). Wymagalne Obiegi EK_149 System powinien umożliwić obieg wniosku dotyczącego zatrudnienia pracownika. Opcjonalne EK_150 System powinien umożliwić obieg wniosku dotyczącego nabycia uprawnień do dodatku funkcyjnego/specjalnego przez pracownika. Opcjonalne EK_151 System powinien umożliwić obieg wniosku o zmianę jednostki organizacyjnej pracownika. Opcjonalne EK_152 System powinien umożliwić obieg wniosków o awans pracownika. Awans to zmiana stawki zaszeregowania, zmiana kategorii, zmiana grupy, zmiana stanowiska. Opcjonalne EK_153 System powinien zapewnić obieg wniosku w sprawie przedłużenia umowy o pracę pracownika. Opcjonalne EK_154 System powinien umożliwić obieg wniosku o zwolnienie pracownika (rozwiązanie stosunku pracy). Opcjonalne EK_155 System musi umożliwić obieg wniosków urlopowych. Wymagalne Integracja EK_156 System musi umożliwiać przenoszenie danych kandydata z obszaru Rekrutacji do Kadr. Dane osobowe nowego pracownika powinny być przenoszone lub współdzielone z modułem rekrutacja i podlegać ewentualnie weryfikacji i uzupełnieniu.
Wymagalne EK_157 System musi współpracować z systemem Płatnik, w zakresie określonym w bloku "Ubezpieczenia ZUS Wymagalne
Strona 55 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
(Płatnik)". EK_158 System musi współpracować z systemem QUINTIQ. Dla części pracowników planowanie i wykonanie czasu pracy będzie rejestrowane w systemie Quintiq. Te dane będą przesyłane do Systemu. Z Systemu przesyłane będą dane kadrowe części pracowników dotyczące absencji, limitów absencji, badań lekarskich i uprawnień. Wymagalne Raportowanie EK_159 System musi umożliwić użytkownikom łatwe tworzenie za pomocą narzędzia raportującego szablonów dokumentów do edytora word lub system musi umożliwiać integrację z oprogramowaniem MS Office w zakresie generowania plików tekstowych, które będą zasilać mechanizm korespondencji seryjnej. System musi umożliwiać zdefiniowanie pól korespondencji seryjnej dla podstawowych danych pracownika, danych adresowych, danych z zatrudnienia, aby użytkownicy systemu mogli tworzyć własne szablony raportów uzupełniane następnie polami korespondencji seryjnej. Wymagalne EK_160 System musi umożliwić użytkownikom łatwe tworzenie za pomocą narzędzia raportującego raportów i zestawień ad hoc ze wszystkich danych Podsystemu Zarządzanie Personelem. Skonfigurowane przez Wykonawcę narzędzie raportujące musi zachować nazewnictwo stosowane w Systemie. Wymagalne Raporty kadrowe Związane z zatrudnieniem pracownika EK_161 System musi generować "Umowę o pracę" dla nowo zatrudnionego pracownika lub pracownika, z którym zawarto nową umowę po zakończeniu umowy na czas określony. Wymagalne EK_162 System musi umożliwiać wygenerowanie raportu "Informacje do Umowy o pracę". Wymagalne EK_163 System musi umożliwiać wydrukowanie dokumentu „Aneks do umowy". Przyczyną aneksu może być zmiana warunków umowy, np. wynagrodzenia zasadniczego, stanowiska, jednostki organizacyjnej, itp. Wymagalne EK_164 System musi generować "Wypowiedzenie umowy o pracę".
Wymagalne
EK_165 System musi generować "Świadectwo pracy".
Wymagalne
Dot. absencji i czasu pracy EK_166 System musi generować raport "Wykaz niewykorzystanych urlopów do rezerw na zaległy urlop wypoczynkowy".
Wymagalne EK_167 System musi generować raport "Absencje według rodzajów, terminów, komórek". Wymagalne EK_168 System musi generować raport "Zestawienie należnego, pozostałego urlopu wypoczynkowego i dodatkowego" . Wymagalne EK_169 System musi generować raport "Zestawienie planu dyżurów". Wymagalne EK_170 System musi generować raport "Zestawienie wykonanych dyżurów". Wymagalne Dot. kwalifikacji pracowników EK_171 System musi generować raport "Kwalifikacje pracowników" zawierający m. in. informacje o wykształceniu pracowników, znajomości języków obcych, ukończonych szkołach. Wymagalne Pozostałe EK_172 System musi generować raport "Lista pracowników posiadających dzieci". Raport zawiera również informacje o dzieciach pracownika. Wymagalne EK_173 System musi generować raport "Staże". Wymagalne EK_174 System musi generować raport "Wykazu osób posiadających uprawnienia do dostępu do informacji niejawnych". Wymagalne Strona 56 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EK_175 System musi generować raport "Lista osób, którym kończą się ważność poświadczenia bezpieczeństwa". Wymagalne EK_176 System musi generować raport "Lista osób, które powinny być skierowane na badania lekarskie". Wymagalne EK_177 System musi generować "Skierowanie na badania lekarskie". Wymagalne EK_178 System musi generować raport "Zestawienie zatrudnienie do ustalenia odpisu na ZFŚS". Wymagalne EK_179 System musi generować raport "Wykaz osób niepełnosprawnych". Wymagalne EK_180 System musi generować raport "Zestawienie rocznic stażu pracy (ogólnego stażu pracy i zakładowego stażu pracy". Wymagalne EK_181 System musi generować raport "Zestawienie nagród jubileuszowych". Wymagalne EK_182 System musi generować raport "Zestawienie uprawnień emerytalnych". Wymagalne EK_183 System musi generować raport "Zestawienie ważności kursów, uprawnień i badań", w tym uprawnień lotniczych, licencji lub świadectwa kwalifikacji, badań lotniczo‐lekarskich, świadectwa radio‐operatora oraz uprawnienia językowego. Wymagalne EK_184 System musi umożliwiać generowanie kart czasu pracy pracowników w ujęciu miesięcznym i rocznym. Wymagalne EK_185 System musi mieć możliwość generowania raportów (np. wyjazdy danej osoby/komórki org. z kosztami, kto wyjeżdżał na dane tematyczne spotkanie/szkolenie, etc.). Zakłada się, że raportów będzie 8. Szczegóły zostaną przekazane podczas analizy przedwdrożeniowej. Wymagalne EK_186 System musi generować "Zaświadczenie o zatrudnieniu i wynagrodzeniu". Wymagalne Sprawozdawczość zarządcza EK_187 System musi generować raport "Wykaz osób zatrudnionych w komórce organizacyjnej". Wymagalne EK_188 System musi generować raport "Zestawienia zmian warunków umowy: m.in. wynagrodzenia zasadniczego i składników wynagrodzenia, komórki organizacyjnej, stanowiska, system i wymiar czasu pracy". Wymagalne EK_189 System musi generować raport "Sprawozdanie z realizacji mierników wewnętrznych". Wymagalne EK_190 System musi generować raport "Stany zatrudnienia miesięczne, przeciętne, na dzień w etatach lub liczbie osób". Wymagalne Sprawozdawczość statystyczna EK_191 System musi generować sprawozdanie lub raport umożliwiający wypełnienie sprawozdania Z‐05 ‐ badanie popytu na pracę. Wymagalne EK_192 System musi generować sprawozdanie lub raport umożliwiający wypełnienie sprawozdania Z‐06 ‐ sprawozdanie o pracujących wynagrodzeniach i czasie pracy. Wymagalne EK_193 System musi generować sprawozdanie lub raport umożliwiający wypełnienie sprawozdania Z‐10 ‐ sprawozdanie o warunkach pracy. Wymagalne EK_194 System musi generować sprawozdanie lub raport umożliwiający wypełnienie sprawozdania Z‐12 ‐ sprawozdanie o strukturze wynagrodzeń według zawodów. Wymagalne Płace Wymagania ogólne PL_001 System musi zapewniać automatyczne rozliczenie wynagrodzeń na podstawie danych z modułu kadrowego. Wymagalne PL_002 System musi umożliwiać rozliczanie wynagrodzenia zasadniczego.
Wymagalne
Strona 57 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
PL_003 System musi automatycznie rozliczać dodatkowe składniki wynagrodzenia zgodnie z Regulaminem Wynagradzania. Wymagalne PL_004 System musi zapewniać rozliczanie dodatkowych świadczeń związanych z pracą zgodnie z Regulaminem Wynagradzania. Wymagalne PL_005 System musi automatycznie wyliczać kwotę nagrody jubileuszowej zgodnie z Regulaminem Wynagradzania. Wymagalne PL_006 System musi automatycznie wyliczać kwotę odprawy w związku z przejściem na rentę lub emeryturę zgodnie z Regulaminem Wynagradzania. Wymagalne PL_007 System musi automatycznie rozliczać potrącenie z wynagrodzenie m. in, wpłatę wkładu KZP, spłatę pożyczki PZP, komornika, składki na ubezpieczenia itp.. Wymagalne PL_008 System musi wspomagać rozliczanie wynagrodzenia po zmarłym pracowniku. Wymagalne PL_009 System musi automatycznie wyliczać kwotę ekwiwalentu za niewykorzystany urlop w przypadku rozwiązania umowy o pracę z pracownikiem. Wymagalne PL_010 System musi automatycznie wyliczać kwotę odprawy pośmiertnej w przypadku wygaśnięcia umowy o pracę z pracownikiem z powodu śmierci pracownika. Wymagalne PL_011 System musi automatycznie rozliczać czas pracy pracownika, w tym godziny nocne, pracę soboty i niedziele, dyżury domowe. Wymagalne PL_012 System musi posiadać możliwość rozliczania czasu pracy za dany miesiąc w kolejnym miesiącu. Wymagalne PL_013 System musi zapewnić automatyczne naliczanie nagrody jubileuszowej, odprawy w związku z przejściem na rentę lub emeryturę. Wymagalne Rachunki bankowe pracowników PL_014 System musi umożliwiać wprowadzenie wielu rachunków bankowych pracownika. Wymagalne PL_015 System musi umożliwiać zdefiniowanie sposobu wypłaty wynagrodzenia na rachunki bankowe pracownika lub w kasie. System musi umożliwiać określenie % wynagrodzenia lub kwoty, jaka powinna zostać wypłacona w kasie lub na dany rachunek bankowy pracownika. Wymagalne Rozliczanie absencji PL_016 System musi zapewniać rozliczanie absencji. Wymagalne PL_017 System musi posiadać możliwość rozliczania absencji w kolejnym miesiącu. Wymagalne PL_018 System musi posiadać możliwość korygowania absencji i automatycznego rozliczania skutków korekty. Wymagalne PL_019 System musi zapewnić automatyczne wyliczanie prawa do zasiłku z możliwością ręcznej modyfikacji. Wymagalne PL_020 System musi zapewnić automatyczne rozliczanie okresu zasiłkowego z możliwością ręcznej modyfikacji. Wymagalne PL_021 System musi zapewnić automatyczne naliczanie podstaw, w szczególności: wynagrodzenia za czas choroby, zasiłków, wynagrodzenia za urlop wypoczynkowy, ekwiwalentu za urlop wypoczynkowy. Wymagalne PL_022 System musi zapewniać możliwość obsługi zgłoszeń do ubezpieczeń pracowników przebywających na urlopach wychowawczych lub pobierających zasiłek macierzyński, prawidłowe rozliczanie składek finansowanych przez budżet państwa, automatyczne sporządzanie raportów rozliczeniowych. Wymagalne Obsługa składek na ubezpieczenie społeczne PL_023 System musi naliczać składki na ubezpieczenia społeczne, ubezpieczenie zdrowotne, Fundusz Emerytur Pomostowych. Wymagalne Strona 58 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
PL_024 System musi posiadać możliwość automatycznej obsługi przekroczenia rocznej podstawy składek emerytalno‐rentowych. Wymagalne PL_025 System musi posiadać możliwość wprowadzenia informacji o wysokości przychodów osiągniętych u innego pracodawcy w celu prawidłowego naliczenia składek na ubezpieczenie emerytalno‐rentowe. Wymagalne PL_026 System musi obsługiwać przychody zwolnione ze składek. Wymagalne PL_027 System musi umożliwiać obsługę zwolnienia z opłacania składki na FP dla pracowników powracających z urlopów macierzyńskich i wychowawczych. Wymagalne PL_028 System powinien umożliwiać automatyczną obsługę zwolnienia z opłacania składki na FP dla pracowników powracających z urlopów macierzyńskich i wychowawczych. Opcjonalne PL_029 System musi umożliwiać automatyczną obsługę zwolnienia z opłacania składki na FP dla osób wymienionych w art. 104 ust. 1 pkt 1‐3 ustawy o promocji zatrudnienia i instytucjach rynku pracy. Wymagalne Obsługa podatków PL_030 System musi umożliwiać wprowadzenie danych niezbędnych do prawidłowego naliczenia zaliczek na podatek dochodowy od osób fizycznych, z uwzględnieniem: prawa do ulgi, wysokości kosztów uzyskania przychodów, zaniechania poboru zaliczki, sposobu rozliczania, opcjonalnie wyboru progu podatkowego. Wymagalne PL_031 System musi naliczać zaliczki na podatek dochodowy od osób fizycznych. Wymagalne PL_032 System musi naliczać zryczałtowany podatek dochodowy. Wymagalne PL_033 System musi zapewniać obsługę przychodów zwolnionych od podatku dochodowego. Wymagalne Umowy cywilno‐prawne PL_034 System musi umożliwiać rejestrowanie osób, z którymi zawierane są umowy cywilnoprawne. Wymagalne PL_035 System musi ewidencjonować umowy cywilnoprawne i umożliwiać ich rozliczanie. Wymagalne PL_036 System musi posiadać możliwość ewidencji i rozliczania rachunków do umów cywilnoprawnych. Wymagalne PL_037 System musi wyliczać zaliczki na podatek dochodowy. Wymagalne PL_038 System musi wyliczać składki na ubezpieczenia społeczne i ubezpieczenie zdrowotne. Wymagalne PL_039 System musi zapewniać obsługę umów cywilnoprawnych zawieranych z własnym pracownikiem. Wymagalne Listy płac PL_040 System musi posiadać możliwość sporządzania wielu list wypłat w jednym miesiącu. Wymagalne PL_041 System musi wyliczać listy płac. Wymagalne PL_042 System musi zapewniać kontrolę kolejności i wysokości potrąceń z wynagrodzenia. Wymagalne PL_043 System musi zapewniać kontrolę kolejności i wysokości potrąceń z wypłat zasiłków. Wymagalne PL_044 System musi mieć możliwość konfigurowania przez administratora biznesowego algorytmów obliczania. poszczególnych składników płacowych, definiowanie nowych składników. W szczególności algorytmy te muszą: ‐ pobierać dane zapisane w bazie modułów Systemu (nie tylko modułu Kadrowego lub Płacowego) ‐ zapewniać możliwość definiowania instrukcji warunkowych, ‐ określać miesiąc (okres), z którego pochodzą dane (np. dotyczące absencji, wartości innych składników, itp.), ‐ pobierać dane (np. stałych stawek typu: wynagrodzenie minimalne, wartości progów podatkowych, dane kadrowe, dane płacowe, itp.) z okresu właściwego dla obliczanego składnika, ‐ posiadać definicje funkcji obliczających wartości niezbędne do wyliczenia wartości składnika (np. ilość Wymagalne Strona 59 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
godzin nadliczbowych w miesiącu, ilość dni harmonogramowych, wartość stawki umowy o pracę, itp.). ‐ posiadać możliwość definiowania własnych funkcji opartych o funkcje podstawowe. PL_045 System musi posiadać rejestr stawek (np. płaca minimalna, progi podatkowe, itp.). Stawki te powinny mieć możliwość definiowania okresów aktualności dla wartości (wartości zmieniają się w czasie). Wymagalne Ubezpieczenia ZUS (Płatnik) PL_046 System musi współpracować z programem Płatnik i automatyczne sporządzać raporty rozliczeniowe DRA, RCA, RZA i RSA na podstawie naliczonych list płac. Wymagalne PL_047 System musi współpracować z programem Płatnik i automatyczne sporządzać korekty raportów rozliczeniowych DRA, RCA, RZA i RSA na podstawie naliczonych list płac. Wymagalne PL_048 System musi uwzględniać przy generacji raportów rozliczeniowych osoby zatrudnione na umowy cywilno‐prawne. Wymagalne PL_049 System musi umożliwiać generowanie miesięcznego i rocznego raportu RMUA. Wymagalne PL_050 System musi umożliwiać generowanie deklaracji IWA. Wymagalne PL_051 System musi umożliwiać generowanie deklaracji dla osób na urlopach macierzyńskich/wychowawczych. Wymagalne PL_052 System musi wspomagać automatyczne rozliczenie zwrotu nadpłaty składek emerytalno–rentowych i składek na FEP. Wymagalne PL_053 System musi umożliwiać generowanie deklaracji zgłoszeniowych dla osób zatrudnionych na podstawie umowy cywilnoprawnej. Wymagalne Planowanie zatrudnienia (wymagania ogólne) PL_054 System musi umożliwiać udział różnych komórek organizacyjnych w procesie planistycznym. Wymagalne PL_055 System musi umożliwiać wykorzystanie obowiązujących słowników: MPK, Kategoria PRU, Organ Ruchu Lotniczego, Lokalizacja. Wymagalne PL_056 System musi umożliwiać modyfikowanie i wprowadzanie nowych wartości słowników: MPK, Kategoria PRU, Organ Ruchu Lotniczego, Lokalizacja.
Wymagalne PL_057 System musi umożliwiać wykorzystanie obowiązującej struktury organizacyjnej.
Wymagalne
PL_058 System musi umożliwiać modyfikowanie i wprowadzanie nowych jednostek w strukturze organizacyjnej. Wymagalne
PL_059 System musi umożliwiać wersjonowanie planów.
Wymagalne
Planowanie zatrudnienia (osoby). PL_060 System musi wspomagać tworzenie Planu Zatrudnienia w ujęciu osobowym (w etatach i osobach). Wymagalne
PL_061 System musi posiadać możliwość wprowadzenia, edycji, usuwania wakatów planowanych (formularze planistyczne zgodnie z harmonogramem prac planistycznych Procedury PP‐HRM‐01). Wymagalne PL_062 System musi w planowaniu zatrudnienia uwzględniać urlopy bezpłatne i wychowawcze z możliwością ich edycji przez użytkownika. Wymagalne PL_063 System musi w planowaniu zatrudnienia uwzględniać zmiany wymiaru czasu pracy, z możliwością ich edycji przez użytkownika. Wymagalne PL_064 System musi umożliwiać wprowadzenie informacji o planowanych zmianach Kategorii PRU poszczególnych pracowników. Wymagalne PL_065 Przy planowaniu zatrudnienia system musi umożliwiać wprowadzenie informacji o planowanym organie kontroli ruchu lotniczego poszczególnych pracowników. Wymagalne PL_066 Przy planowaniu zatrudnienia system musi umożliwiać wprowadzenie informacji o planowanej Wymagalne Strona 60 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Lokalizacji poszczególnych pracowników. PL_067 Przy planowaniu zatrudnienia system musi umożliwiać wprowadzenie informacji o planowanym MPK poszczególnych pracowników. Wymagalne PL_068 System musi posiadać możliwość utworzenia nowego parametru/atrybutu charakteryzującego określającego pracownika. Ten atrybut może być potem wymiarem w planowaniu. Wymagalne Planowanie zatrudnienia (kosztów pracy) PL_069 System musi umożliwiać tworzenie Planu Kosztów Pracy. Wymagalne PL_070 Dane zawarte w procesie planowania kosztów pracy muszą wynikać z procesu planowania zatrudnienia (osoby). Wymagalne PL_071 System musi umożliwiać planowanie kosztów pracy na poziomie pojedynczego pracownika. Wymagalne PL_072 System musi umożliwiać edycję danych aktualnych pracowników i możliwość dodawania i edytowania danych planowanych pracowników. Wymagalne PL_073 System musi umożliwiać ocenę w czasie rzeczywistym skutków decyzji dotyczących zasobów ludzkich. System musi umożliwiać prezentację prognoz zmian kosztów powstałych w wyniku symulowanych albo rzeczywistych decyzji dotyczących zasobów ludzkich, takich jak: przyjęcie nowego pracownika, zmiana wynagrodzenia pracownika czy zmiana wskaźnika dotyczącego większej liczby osób np. wysokości składki wypadkowej. Wymagalne PL_074 System musi umożliwiać planowanie kosztów pracy na podstawie danych kadrowych, wcześniejszego planowania zatrudnienia (osoby) i formuł tożsamych z tymi, które są wykorzystywane przy naliczaniu wynagrodzeń. Przykładowo, wynagrodzenie zasadnicze Kontrolerów Ruchu Lotniczego uzależnione jest od skomplikowania przestrzeni powietrznej i złożoności ruchu lotniczego, indywidualnego stopnia doświadczenia oraz od liczby operacji lotniczych, przy czym liczba operacji rejestrowana jest oddzielnie dla organów kontroli lotniska i radarowych organów kontroli zbliżania. Wymagalne PL_075 Przy wyliczeniu kosztów pracy system musi automatycznie uwzględniać aktualizację składowych wynagrodzeń pracowników na wszystkie planowane lata (np. dodatek za staż pracy).
Wymagalne PL_076 System musi zapewniać możliwość podziału procentowego (koszt wynagrodzenia, wybrane świadczenia na rzecz pracowników) w Kategorii PRU zgodnie z wytycznymi Eurocontrol. Wymagalne PL_077 System musi umożliwiać planowanie kosztów Funduszu Pracy z uwzględnieniem płci, daty urodzenia (wiek pracownika), daty urlopów wychowawczych i macierzyńskich zgodnie z przepisami ZUS. Wymagalne PL_078 System musi uwzględniać staż pracy w powiązaniu z planowaniem kosztów nagród jubileuszowych i odpraw emerytalnych (należny procent, data wydarzenia). Wymagalne PL_079 System musi umożliwiać planowanie kosztów pracy na każdą osobę, na każdy składnik według danych historycznych, np. średnia), przewidywanych, skorygowanych o wskaźnik, z możliwością uwzględnienia inflacji, na dowolnie wybrany okres (miesiąc, kwartał, rok, kwota, procent) według Regulaminu Wynagradzania, Regulaminu Pracy, przepisów ZUS. Wymagalne PL_080 System musi umożliwiać planowanie wynagrodzenia zasadniczego zgodnie z Regulaminem Wynagradzania, z umową o pracę (KRL – stopień doświadczenia, liczba operacji lotniska, uprawnienia KRL). Wymagalne PL_081 System musi umożliwiać planowanie kosztów bezosobowego funduszu płac wraz ze świadczeniami zgodnie z przepisami ZUS, w porozumieniu z kierownikiem MPK, (w przyszłości możliwość zastosowania Kategorii PRU). Wymagalne PL_082 System powinien uwzględniać system czasu pracy (kalendarz) w powiązaniu z nominałem czasu pracy (miesięczny i kwartalny) z możliwością modyfikacji za dowolne okresy. Wymagalne PL_083 System musi zapewniać możliwość planowania Funduszu Premiowego i Funduszu Nagród (kwota, procent). Wymagalne Strona 61 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
PL_084 System musi umożliwiać przekazywanie danych o planowanych kosztach wynagrodzeń do baz kosztowych (opłaty terminalowe, trasowe, pozostałe) . Wymagalne Integracja PL_085 System musi współpracować z systemem QUINTIQ. W systemie Quintiq będzie planowany czas pracu części pracowników. Obsługa interfejsu pobierania szczegółowych danych o planach i wykonaniu z systemu planistycznego. Wymagalne PL_086 System musi współpracować z platformą e‐deklaracje w zakresie przekazywania drogą elektroniczną informacji PIT‐11, PIT‐40 oraz deklaracji PIT‐4R i PIT‐8AR. Wymagalne PL_087 System musi umożliwiać generowanie plików z przelewami do systemu home banking. Wymagalne Raportowanie Ogólne PL_088 System musi umożliwiać sporządzenie i wydruk Karty Wynagrodzeń. Wymagalne PL_089 System musi umożliwiać sporządzenie i wydruk Karty Zasiłkowej. Wymagalne PL_090 System musi umożliwiać sporządzenie i wydruk raportu imienna lista płac. Wymagalne PL_091 System musi umożliwiać sporządzenie i wydruk raportu imienna lista płac do wypłaty w kasie. Wymagalne PL_092 System musi umożliwiać sporządzenie i wydruk raportu zbiorcza lista płac. Wymagalne PL_093 System musi umożliwiać sporządzenie i wydruk Karty podatkowej. Wymagalne PL_094 W systemie musi być dostępna imienna, zbiorcza lista płac za dowolny okres na każdy składnik z danymi historycznymi z możliwością wyboru wg określonych kryteriów. Wymagalne PL_095 System musi umożliwiać generowanie raportu dla potrzeb informacji zarządczej wg Kategorii PRU. Wymagalne PIT PL_096 System musi umożliwiać sporządzenie i wydruk deklaracji PIT‐4R. Wymagalne PL_097 System musi umożliwiać sporządzenie i wydruk deklaracji PIT‐8AR. Wymagalne PL_098 System musi umożliwiać sporządzenie i wydruk formularza PIT‐40. Wymagalne PL_099 System musi umożliwiać sporządzenie i wydruk informacji PIT‐11. Wymagalne PL_100 System musi umożliwiać sporządzenie i wydruk informacji PIT‐8C. Wymagalne PL_101 System powinien umożliwiać sporządzenie i wydruk informacji IFT‐1/IFT‐1R. Opcjonalne PL_102 System powinien umożliwiać sporządzanie i wydruk miesięcznego zestawienia do weryfikacji PIT‐4R. Opcjonalne PL_103 System powinien umożliwiać sporządzanie i wydruk miesięcznego zestawienia do weryfikacji PIT‐8AR. Opcjonalne PL_104 System powinien umożliwiać sporządzenie i wydruk oświadczenia PIT‐2. Opcjonalne PL_105 System powinien umożliwiać sporządzenie i wydruk oświadczenia PIT‐12. Opcjonalne GUS PL_106 System musi generować sprawozdanie lub raport umożliwiający wypełnienie sprawozdania PFRON DEK‐
I‐0. Wymagalne Planowanie PL_107 System musi generować raport "Plan Zatrudnienia". Wymagalne PL_108 System musi generować raport "Plan Kosztów Pracy". Wymagalne Strona 62 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
PL_109 System musi generować raport "Porównanie (wg wybranych kryteriów) poniesionych kosztów pracy z wybranego okresu do wybranej wersji planu kosztów pracy". Wymagalne PL_110 System musi generować raport "Plan zatrudnienia wg Kategorii PRU z uwzględnieniem Organu Ruchu Lotniczego i Lokalizacji" Wymagalne Zarządzanie personelem Struktura organizacyjna ZP_001 System musi umożliwiać wprowadzenie opisów komórek przez pryzmat celu ich funkcjonowania, podstawowych zadań, obowiązków, odpowiedzialności, mierników, KPI. Wymagalne ZP_002 System musi umożliwiać wprowadzanie opisów stanowisk pracy (nazwa stanowiska organizacyjna, nazwa stanowiska operacyjna, nazwa funkcji, kod stanowiska/funkcji (kod zawiera do 10 segmentów określających np. obszar, rodzaj służby, miejsce zatrudnienia, poziom stanowiska), cel stanowiska/funkcji, zadania i czynności, zakres uprawnień na stanowisku/funkcji, zakres odpowiedzialności na stanowisku/funkcji, wymagane kompetencje (wykształcenie, specjalność, szkolenia, uprawnienia, kompetencje miękkie), Kategoria PRU, Grupa, kat. zaszeregowania, wymagane etaty, czas pracy, forma zatrudnienia, czas trwania umowy, miejsce w strukturze organizacyjnej, podległość organizacyjna, podległość operacyjna, zastępstwa). Wymagalne ZP_003 System musi umożliwiać przypisanie liczby etatów do poszczególnych jednostek organizacyjnych. Wymagalne ZP_004 System musi umożliwiać wprowadzenie zadań na stanowisku wraz z określeniem istotności zadania (wag). Wymagalne ZP_005 System musi umożliwiać określenie czy stanowisko jest robotnicze, techniczne, administracyjne czy kierownicze. Wymagalne ZP_006 System musi umożliwiać wprowadzenie mierników, KPI na danym stanowisku. Wymagalne ZP_007 System musi umożliwiać wskazanie pracowników kierujących jednostkami organizacyjnymi w każdej z hierarchii struktur, bądź osób kierujących tymi jednostkami w zastępstwie w razie wakatu, bądź urlopu. Wymagalne ZP_008 System musi umożliwiać tworzenie i modyfikowanie hierarchii stanowisk pracy. Wymagalne ZP_009 System musi umożliwiać likwidację stanowiska pracy z określoną datą i związany z tym zakaz odwołania do tego stanowiska (np. zatrudnienie nowego pracownika) powyżej podanej daty. Wymagalne ZP_010 System musi umożliwiać przypisanie stanowiska pracy do jednostki w strukturze organizacyjnej. Wymagalne ZP_011 System musi umożliwiać wprowadzanie opisów funkcji w zakresie takim, jak opis stanowiska. Wymagalne Raportowanie struktury organizacyjnej ZP_012 System musi umożliwiać wygenerowanie raportu "Karta Zadań pracownika". Wymagalne ZP_013 System musi umożliwiać wygenerowanie raportu "Kadra rezerwowa " wskazującego na podstawie kompetencji pracownika, jakich innych stanowiskach (zgodnie z opisem tych stanowisk) może być zatrudniony pracownik. Wymagalne ZP_014 System musi zapewnić generowanie raportu „Nowozatrudnieni”. Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, stanowisko, data umowy od – do, komórka organizacyjna. Wymagalne ZP_015 System musi zapewnić generowanie raportu „Zmiany w zatrudnieniu”. Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, stanowisko, data umowy od – do, komórka organizacyjna. Wymagalne ZP_016 System musi zapewnić generowanie raportu „Powierzenie dodatkowych czynności”. Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, stanowisko, data umowy od – do, komórka Wymagalne Strona 63 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
organizacyjna, data powierzenia czynności, zakres czynności. ZP_017 System musi zapewnić generowanie raportu „Dodatkowe funkcje”. Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, nazw funkcji, data od – do. Wymagalne ZP_018 System musi zapewnić generowanie raportu „Brak karty zadań”. Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, stanowisko, komórka organizacyjna. Wymagalne ZP_019 System musi zapewnić generowanie raportu „Karty zadań na określonym stanowisku”. Raport musi zawierać pola: nazwa stanowiska pracy w tytule, nr ewidencyjny, imię i nazwisko pracownika, komórka organizacyjna, data podpisania karty zadań lub jej aneksu. Wymagalne ZP_020 System musi zapewnić generowanie raportu „Stan kart zadań w danej komórce lub jednostce”. Raport musi zawierać pola: nazwa komórki lub jednostki w tytule, nr ewidencyjny, imię i nazwisko pracownika, komórka organizacyjna, data podpisania karty zadań lub jej aneksu. Wymagalne Model kompetencyjny ZP_021 System musi wspomagać zarządzanie kompetencjami. Kompetencje są przypisywane do stanowiska pracy/funkcji. Wymagalne ZP_022 System musi umożliwiać tworzenie grupy kompetencji, np. menedżerskie, społeczne, zawodowe itp. Wymagalne ZP_023 System musi umożliwiać zarządzanie słownikiem rodzajów kompetencji. Wymagalne ZP_024 System musi umożliwiać przypisywanie kompetencji do grup kompetencji. Wymagalne ZP_025 System musi umożliwiać tworzenie mapy kompetencji w organizacji. Wymagalne ZP_026 System musi umożliwiać opisywanie kompetencji w oparciu o dostarczony model (nazwa kompetencji, definicja, kilkupoziomowy opis behawioralny) lub za zgodą PAZP powinna zostać przeprowadzona implementacja modelu dostawcy systemu. Ilość poziomów opisu behawioralnego nie może być ograniczona, obecnie jest wykorzystywanych 4 oraz 5 poziomów. Musi przy tym istnieć możliwość elastycznej przebudowy modelu kompetencji przez Administratora Biznesowego PAŻP. Wymagalne ZP_027 System musi umożliwiać zdefiniowanie kompetencji w kontekście realizowanych zadań. Do każdego zadania można przypisać kilka kompetencji.
Wymagalne ZP_028 System musi automatycznie dokonywać wyboru głównych kompetencji dla stanowiska na podstawie kompetencji zdefiniowanych do danego zadania. Główne kompetencji to takie, które są najczęściej wymagane do realizacji poszczególnych zadań na danym stanowisku. Wymagalne ZP_029 System musi umożliwiać dokonywanie ocen kompetencji pracowników (w ramach modułu ocena okresowa) według kluczy i wartości opartych na kryteriach kompetencyjnych zawartych w KOSP Wymagalne Obieg ZP_030 System musi umożliwiać obieg zatwierdzenie Kompetencyjnego opisu stanowiska pracy. System musi umożliwiać wprowadzenia uwag do opracowywanego dokumentu.. Wymagalne Raporty (ogólnie) ZP_031 System musi zapewnić generowanie raportu "Kompetencyjny Opis Stanowiska Pracy (wersja pełna)". Wymagalne ZP_032 System musi zapewnić generowanie raportu "Kompetencyjny Opis Stanowiska Pracy (wersja skrócona)". Wymagalne ZP_033 System musi zapewnić generowanie raportu "Kompetencyjny Opis Stanowiska Pracy (wersja PRIS)". Wymagalne ZP_034 System musi zapewnić generowanie raportu "Księga kompetencji na dzień lub od – do". Wymagalne ZP_035 System musi zapewnić generowanie raportu „Rozwiązanie umowy o pracę”. Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, stanowisko, data umowy od – do, komórka organizacyjna, przyczyna rozwiązania umowy o pracę. Wymagalne Zarządzanie przez cele Strona 64 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ZP_036 System musi wspomagać zarządzanie przez cele. Wymagalne ZP_037 System musi posiadać możliwość uzgadniania celów (ustalanie terminów oraz mierników realizacji celów między stronami oceny). Wymagalne ZP_038 System musi umożliwiać definiowanie celów organizacji (poziom strategiczny), w tym określenie dat obowiązywanie celów. Wymagalne ZP_039 System musi posiadać możliwość tworzenia map celów organizacji (określnie, jakie komórki organizacyjne i w jakim stopniu mają wpływ na realizacje celu) o dowolnym czasie ich realizacji. Wymagalne ZP_040 System musi umożliwiać wprowadzanie planu na poziomie strategicznym (na poziomie całej organizacji), taktycznym i operacyjnym. System musi umożliwiać powiązanie celów indywidualnych z nadrzędnymi celami organizacji. Wymagalne ZP_041 System musi posiadać możliwość zdefiniowania i dystrybucji celów organizacji na poszczególne komórki, stanowiska i pracowników. Wymagalne ZP_042 System musi umożliwiać dystrybucję celów głównych na niższe poziomy w strukturze organizacyjnej poprzez przypisanie celów szczegółowych (np. zadań dodatkowych) i mierników ściśle powiązanych z celami organizacji, poszczególnym jednostkom organizacyjny, stanowiskom oraz pracownikom. Wymagalne ZP_043 System musi umożliwić wyznaczanie przez kierowników (kadrę zarządzającą) celów indywidualnych skorelowanych ze strategicznym obszarem decyzyjnym (strategią PAŻP). Wymagalne ZP_044 System musi umożliwiać zdefiniowanie mierników celów: wartościowe, wyrażone w dowolnej jednostce miary, opisowe oraz wyliczeniowe. Wymagalne ZP_045 System musi wspomagać bieżącą kontrolę (poprzez moduł oceny okresowej) realizacji celów głównych i szczegółowych na wszystkich poziomach organizacji (kwartalna, półroczna, roczna) z możliwością modyfikacji częstotliwości. Wymagalne Ocena okresowa pracowników ZP_046 System musi umożliwiać za pomocą portalu samoobsługowego dokonywanie ocen kompetencji, efektywności i realizacji celów przez pracowników i kierowników. Wymagalne ZP_047 System musi umożliwiać PAŻP w przyszłości samodzielną: Wymagalne ‐ Modyfikację skali ocen, ‐ Modyfikację wyniku lub klucza oceny, ‐ Modyfikację wzorów stosowanych formularzy, ‐ Wprowadzenie zmian w przypadku zmian procedur SOP oraz PRiS. ZP_048 System musi posiadać możliwość elektronicznej oceny adaptacyjnej na dwa tygodnie przed końcem umowy o pracę na danym stanowisku pracy (np. po okresie próbnym) oraz okresowej, zadaniowej (zarządzania przez cele, efektywności według harmonogramu).
Wymagalne ZP_049 System musi umożliwiać dokonywanie ocen kompetencji pracowników ‐ metoda 180 stopni z możliwością rozbudowy do 360 stopni Wymagalne ZP_050 System musi umożliwiać dokonywanie oceny realizacji celów rozwojowych. Wymagalne ZP_051 System musi posiadać możliwość oceny wykonania zadań przypisanych do stanowiska pracy (wszystkich lub najważniejszych) tj. ocena efektywnościowa. Wymagalne ZP_052 System musi posiadać możliwość oceny pracownika, który pełni funkcje dodatkowe w PAŻP. Wymagalne ZP_053 System musi umożliwiać ocenę prowadzoną w formie samooceny i oceny przełożonego – 180 stopni. Wymagalne Strona 65 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
System musi umożliwiać wprowadzenie decyzji Komisji tj. akceptacje lub odrzucenie, złożenie odwołania przez pracownika oraz uzasadnienie decyzji Komisji. ZP_054 W przypadku oceny pracownika system musi umożliwiać zapis o oddelegowaniu do pracy w innej komórce. Wymagalne ZP_055 Oceniani pracownicy muszą mieć możliwość złożenia odwołania przy użyciu Systemu. Wymagalne ZP_056 System musi mieć możliwość dobru kryteriów ilościowych i jakościowych (mierniki oceny) z dostępnego słownika, na początku okresu oceny. Wymagalne ZP_057 System musi umożliwiać wprowadzanie oceny ogólnej poszczególnych kompetencji, oceny poszczególnych zadań oraz wniosków z oceny. System powinien umożliwić podanie wyniku oceny za pomocą zaimplementowanego wyniku oceny. Każda z ocen ma inny wynik oceny oraz inne jej skutki.
Wymagalne Ocena okresowa ‐ powiadomienia ZP_058 System musi umożliwiać wysyłanie powiadomień o rozmowie oceniającej. Wymagalne ZP_059 System musi umożliwiać wysyłanie powiadomień o wystawieniu oceny przez przełożonego. Wymagalne ZP_060 System musi umożliwiać wysyłanie powiadomień o akceptacji / złożonym odwołaniu oceny przez pracownika. System musi umożliwiać wysyłanie powiadomień zbliżającym się okresie zakończenia sesji oceniającej (dla ocen robionych on‐line). Wszystkie oceny pracownicze mają być robione on‐line.
Wymagalne ZP_061 Wymagalne Ocena okresowa ‐ raporty ZP_062 System musi zapewnić generowanie raportu "Indywidualny Formularz oceny okresowej (kompetencyjnej)". Wymagalne ZP_063 System musi zapewnić generowanie raportu "Formularz oceny adaptacyjnej". Wymagalne ZP_064 System musi zapewnić generowanie raportu "Formularz oceny ZPC (efektywnościowej)". Wymagalne ZP_065 System musi zapewnić generowanie raportu "Szkolenie wewnętrzne ‐ cel rozwojowy z oceny za wybrany okres". Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, cel rozwojowy. Wymagalne ZP_066 System musi zapewnić generowanie raportu "Szkolenie zewnętrzne krajowe ‐ cel rozwojowy z oceny za wybrany okres". Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, cel rozwojowy. Wymagalne ZP_067 System musi zapewnić generowanie raportu "Szkolenie zewnętrzne zagraniczne ‐ cel rozwojowy z oceny za wybrany okres". Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, cel rozwojowy. Wymagalne ZP_068 System musi zapewnić generowanie raportu "Samodoskonalenie ‐ cel rozwojowy z oceny za okres". Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, cel rozwojowy. Wymagalne ZP_069 System musi zapewnić generowanie raportu "Inne działania rozwojowe z oceny za wybrany okres". Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, cel rozwojowy. Wymagalne ZP_070 System musi zapewnić generowanie raportu „Indywidualny wynik oceny". Raport musi zawierać pola: nr ewidencyjny, imię i nazwisko pracownika, okres oceny, imię i nazwisko oceniającego, wykres dopasowania do stanowiska. Wymagalne ZP_071 System musi zapewnić generowanie raportu imiennego, zawierającego wszystkie informacje o pracowniku i jego przebiegu pracy w firmie, wszystkie oceny kompetencje, kursy, szkolenia poziom wykształcenia itp. Wymagalne ZP_072 System musi zapewnić generowanie raportu „Złożone odwołania”. Wymagalne ZP_073 System musi zapewnić generowanie raportu „Wynik oceny ‐ klasyfikacja", generowany dla każdego typu Wymagalne Strona 66 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
oceny (OK., OA, OE) i zadanego przedziału czasowego. Zarządzania rozwojem pracowników ZP_074 System musi wspomagać zarządzanie rozwojem pracowników. Wymagalne ZP_075 System musi umożliwiać zaplanowanie standardowej ścieżki rozwoju wg funkcjonujących w PAŻP ścieżek. Wymagalne ZP_076 System musi posiadać możliwość zaplanowania indywidualnej ścieżki rozwoju. Wymagalne ZP_077 System musi generować raport umożliwiać automatyczną identyfikację luk kompetencyjnych kompetencji poszczególnych pracowników, grup pracowniczych na danym stanowisku / obszarze. Wymagalne ZP_078 System musi posiadać możliwość ustalania celów rozwojowych w ocenie pracowniczej (adaptacyjnej i okresowej) na podstawie luki kompetencyjnej oraz możliwość wpisywania dodatkowych celów rozwojowych. Wymagalne ZP_079 System musi umożliwiać zaplanowanie procesu adaptacji dla stanowisk oraz pracowników. W ramach procesu adaptacji konieczne jest określnie terminu i zakresu szkoleń do ukończenie oraz egzaminów. Wymagalne Sprawy socjalne Wymagania ogólne SOC_001 System musi automatycznie naliczać odpis na Zakładowy Fundusz Świadczeń Socjalnych w wysokości określonej w ustawie o zakładowym funduszu świadczeń socjalnych oraz regulaminie zakładowego funduszu świadczeń socjalnych. Wymagalne SOC_002 System musi także w sposób automatyczny dokonywać korekty odpisu na koniec roku, zgodnie ze wskazanymi wyżej regulacjami. Wymagalne SOC_003 System musi umożliwić planowanie wydatków z ZFŚS. Opcjonalne SOC_004 System musi umożliwić tworzenie kolejnych wersji planów wydatków z ZFŚS. Opcjonalne SOC_005 System musi uwzględniać podczas planowania wydatków dane historyczne, umożliwiać analizę danych oraz przeprowadzenie różnych możliwych scenariuszy planu wydatków z ZFŚS.
Opcjonalne SOC_006 System musi w sposób automatyczny zarządzać katalogami osobowymi – osób uprawnionych do korzystania z ZFŚS (katalog powinien być na bieżąco automatycznie aktualizowany) i rzeczowymi (w zakresie katalogu możliwych świadczeń oraz możliwej wysokości dla danego rodzaju świadczeń). Wymagalne SOC_007 System musi uniemożliwiać wprowadzenie świadczeń nienależnych pracownikowi.
Wymagalne
Obieg SOC_008 System powinien umożliwiać obsługę spraw socjalnych przy wykorzystaniu elektronicznego obiegu dokumentów. System powinien posiadać zaimplementowane wzory i szablony dokumentów, które umożliwiałyby przeprowadzenie procesów w zakresie spraw socjalnych całkowicie w formie elektronicznej. Wzory i szablony winny być konfigurowalne tak, aby mogły być dostosowywane do zmieniających się regulacji w zakresie ZFŚS. Opcjonalne Raportowanie SOC_009 System musi umożliwiać przedstawienie danych związanych z działalnością socjalną, jak również umożliwiać użytkownikowi tworzenie wszelkiego rodzaju zestawień oraz definiowania i realizowania raportów na podstawie danych zawartych w systemie Wymagalne Rekrutacja Przygotowanie rekrutacji REK_001 System musi umożliwiać monitorowanie potrzeb kadrowych organizacji (etaty, niedobory etatów). Wymagalne Strona 67 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
REK_002 System musi umożliwiać obsługę trzech rodzajów rekrutacji, charakteryzujących się różną procedurą postępowania (różne są formularze, różny jest obieg dokumentów): ‐ Rekrutacja na kurs dla kandydatów na Kontrolera Ruchu Lotniczego, ‐ Rekrutacja wewnętrzna, ‐ Rekrutacja zewnętrzna. Wymagalne REK_003 System musi pozwalać użytkownikom na tworzenie Ofert pracy dla stanowisk, które są opisane w strukturze organizacyjnej lub nowych stanowisk. Wymagalne REK_004 System musi umożliwiać opis kwalifikacji kandydata z wykorzystaniem zaimplementowanych w systemie słowników, wspólnych dla całego systemu zarządzania personelem, które umożliwią dokonanie automatycznego przeglądu kwalifikacji i oceny dopasowania kandydata do opisanej w Systemie Oferty pracy. Wymagalne REK_005 System musi pozwalać użytkownikom na definiowanie i modyfikowanie Profilu Wymagań dla kandydata na podstawie utworzonych wcześniej profili stanowiska: zadań, kwalifikacji, szkoleń/uprawnień, kompetencji, predyspozycji psychospołecznych. Wymagalne REK_006 System musi umożliwić rejestrowanie składu komisji rekrutacyjnej . Wymagalne REK_007 System musi umożliwiać potencjalnym kandydatom wypełnienie na stronie internetowej formularza z danymi kandydata w odpowiedzi na wybraną Ofertę pracy za pośrednictwem przeglądarki internetowej. (3 formularze dla 3 rodzajów rekrutacji, każdy z formularzy powinien zawierać wbudowany słownik np. nazwy uczelni, poziom wykształcenia, specjalność). Wymagalne System musi umożliwiać tworzenie bazy kandydatów odpowiadających na wybraną Ofertę pracy na stronie internetowej poprzez przeglądarkę internetową a pracownik ALP powinien mieć możliwość dopisywania wyników z poszczególnych etapów selekcji oraz decyzji zespołu rekrutacyjnego o umieszczeniu na liście rekomendacji. REK_008 System musi umożliwić dołączanie wielu załączników ‐ np. dokumentów CV, listów motywacyjnych, dokumentów poświadczających kwalifikacje. Wymagalne REK_009 System musi umożliwiać publikację ogłoszeń na portalu samoobsługowym oraz stronie internetowej PAŻP i w intranecie. Wymagalne REK_010 Moduł rekrutacji musi umożliwiać współużytkowanie danych wprowadzonych w innych modułach: etaty, stanowiska, Lokalizacje, komórki organizacyjne, kompetencje wymagane do pełnienia odpowiednich funkcji, zadania określone dla stanowiska, wakaty, zapotrzebowania, dane o pracownikach. Wymagalne Realizacja REK_011 System musi umożliwiać selekcję i ocenę kandydatów na stanowisko według wszystkich przypisanych do niego kryteriów oraz innych dodatkowych: wywiadów, testów itd. Wymagalne REK_012 System musi umożliwiać opis poszczególnych etapów selekcji kandydatów wraz z podjętą decyzją. Wymagalne REK_013 System musi umożliwiać tworzenie list rankingowych kandydatów ‐ generowanie wyników uzyskanych w postępowaniu rekrutacyjnym. Wymagalne REK_014 System musi umożliwiać uczestnictwo w przebiegu procesu rekrutacji innym, zainteresowanym pracownikom Agencji. Wymagalne REK_015 System musi umożliwić rejestrowanie decyzji komisji rekrutacyjnej na każdym etapie selekcji kandydatów. Wymagalne REK_016 System musi umożliwiać przeglądanie i klasyfikację zgłoszeń złożonych przez kandydatów, zgodnie z ustalonym słownikiem. Wymagalne Obieg Strona 68 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
REK_017 System musi umożliwić obieg „Karty zapotrzebowania na pracownika”, przy wykorzystaniu EOD. Wymagalne REK_018 System musi umożliwiać obieg „Oferty pracy” (akceptacja ogłoszenia) Zlecającego nabór oraz Dyrektora AL, przy wykorzystaniu EOD. Wymagalne REK_019 System musi umożliwić obieg „Karty pozyskania kandydata” , przy wykorzystaniu EOD. Wymagalne REK_020 System musi umożliwić obieg „Kwestionariusza oczekiwań wobec kandydata” , przy wykorzystaniu EOD. Wymagalne REK_021 System musi umożliwić obieg „Profilu poszukiwanego kandydata” , przy wykorzystaniu EOD. Wymagalne REK_022 System musi umożliwić obieg „Karty selekcji” , przy wykorzystaniu EOD. Wymagalne REK_023 System musi umożliwić obieg „Listy rekomendacji” , przy wykorzystaniu EOD. Wymagalne REK_024 System musi umożliwić obieg „Raportu z przebiegu rekrutacji” , przy wykorzystaniu EOD. Wymagalne Powiadomienia REK_025 System musi generować powiadomienia dla kandydatów i pracowników PAZP zaangażowanych w postępowanie rekrutacyjne i selekcję, na każdym z etapów tych postępowań. Wymagalne Raportowanie REK_026 System musi umożliwić generowanie "Karty pozyskania kandydata". Wymagalne REK_027 System musi umożliwić generowanie „Kwestionariusza oczekiwań wobec kandydata”. Wymagalne REK_028 System musi umożliwić generowanie „Profilu poszukiwanego kandydata”. Wymagalne REK_029 System musi umożliwić generowanie „Karty selekcji”. Wymagalne REK_030 System musi umożliwić generowanie „Listy rekomendacji”. Wymagalne REK_031 System musi umożliwić generowanie „Raportu z przebiegu rekrutacji” (nazwa wakującego stanowiska wraz z miejscem w strukturze organizacyjnej, forma pozyskania kandydata, czas i miejsce publikacji ogłoszenia, ilość osób aplikujących, rodzaje selekcji, ilość osób biorących udział w poszczególnych etapach selekcji, wyniki kandydatów, rekomendacje itp.). Wymagalne REK_032 System musi umożliwić generowanie „Formularza z danymi kandydata” (3 formularze dla 3 rodzajów rekrutacji) Wymagalne Szkolenia Wymagania ogólne SZK_001 System musi umożliwiać rejestrowanie danych firm zewnętrznych organizujących szkolenia, konferencje, wyjazdy szkoleniowo‐integracyjne, wyjazdy sportowo‐rekreacyjne. Wymagalne SZK_002 System musi umożliwiać rejestrowanie umów z firmami zewnętrznymi realizującymi szkolenia. Umowy z będą rejestrowane w Centralnym Rejestrze Umów). Wymagalne SZK_003 System musi umożliwiać dokonanie rozliczeń z kontrahentami z tytułu realizacji szkoleń. Wymagalne SZK_004 System musi umożliwiać prowadzenie rejestru instruktorów, wykładowców, trenerów, pracowników PAŻP uprawnionych do prowadzenia szkoleń wewnętrznych PAŻP, pracowników PAŻP uprawnionych do prowadzenia egzaminów wewnętrznych do czasu przejścia na emeryturę. Wymagalne SZK_005 System musi umożliwiać obsługę szkoleń dla osób/firm niebędących pracownikami PAŻP. Wymagalne SZK_006 System musi zapewnić możliwość osobnej obsługi szkoleń zewnętrznych i wewnętrznych (inna konfiguracja procesów, inne uprawnienia, itp.). Wymagalne SZK_007 System musi umożliwiać załączanie dokumentów dotyczących szkoleń, uprawnień, kwalifikacji i badań w Wymagalne Strona 69 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
wersji elektronicznej (w postaci pliku). SZK_008 System musi umożliwić definiowanie uprawnień dostępu do danych dotyczących szkoleń na poziomie typów szkoleń (zewnętrzne/wewnętrzne) i szkoleń. Wymagalne Budżet szkoleń SZK_009 System musi posiadać możliwość planowania i budżetowania szkoleń zewnętrznych w podziale na jednostki organizacyjne, MPK, stanowisko i danego pracownika. Wymagalne SZK_010 System musi automatyzować czynności związane z wyliczeniami kosztów podróży służbowych związanych ze szkoleniami. W systemie musi być słownik limitów (zakwaterowanie, wyżywienie, transport) wynikający z przepisów krajowych i przepisów PAZP. Wymagalne SZK_011 System musi umożliwiać wersjonowania planów szkoleń. Wymagalne SZK_012 System musi przy tworzeniu planu szkoleń uwzględniać dostępności wykładowców i instruktorów oraz uczestników szkoleń. Wymagalne SZK_013 System musi umożliwiać automatyczne planowanie obowiązkowych szkoleń wewnętrznych na dany rok dla danego pracownika (np. szkolenia odświeżające dla kontrolerów ruchu lotniczego, szkolenia okresowe BHP). Wymagalne SZK_014 System musi monitorować budżet szkoleń, czyli zapewniać bieżącą kontrolę budżetu ‐ podgląd planu budżetowego dla danego MPK wraz z informacją o kwocie i środkach wykorzystanych dla danego MPK, o przeprowadzonych szkoleniach i dla kogo. Wymagalne SZK_015 System musi zapewniać monitorowanie budżetu szkoleń dla szkoleń zewnętrznych natomiast powinna być możliwość wyłączenia takiego monitorowania dla szkoleń wewnętrznych. Wymagalne SZK_016 System musi mieć możliwość sprawdzenia budżetu szkoleń w podziale na jednostki organizacyjne. Wymagalne SZK_017 System musi przewidywać takie rozwiązanie jak transfery środków (czyli wirtualne pożyczanie środków finansowych na zadania nieplanowane lub o wyższej wartości). Wymagalne Szczegółowe planowanie realizacji szkoleń SZK_018 System musi umożliwiać rejestrowanie szkoleń i programów szkoleniowych. Wymagalne SZK_019 System musi umożliwić rejestrowanie danych o zatwierdzonych i odbytych szkoleniach wewnętrznych i zewnętrznych, kosztach szkoleń, czasie trwania. Wymagalne SZK_020 System musi umożliwić łączenie szkoleń w wybrane grupy szkoleń. Wymagalne SZK_021 System musi umożliwiać budowanie harmonogramów szkoleń na podstawie Planu Szkoleń z uwzględnieniem wykładowców i instruktorów, sal, uczestników i programów szkoleniowych. Wymagalne SZK_022 System musi obsługiwać proces zarządzania szkoleniami realizowanymi przez podmioty zewnętrzne lub częściowo wewnętrznych (wewnętrzni instruktorzy, zewnętrzny ośrodek – sala szkoleniowa, nocleg, wyżywienie itp.).
Wymagalne SZK_023 System musi umożliwiać konsolidacje wpisanych wniosków z terminami szkoleń i tworzenie miesięcznych terminarzy (tak, aby automatycznie można było dokonać podglądu jakie i gdzie są szkolenia w ciągu danego miesiąca, dnia). Wymagalne SZK_024 System musi zapewniać zarządzanie sesjami i komisjami egzaminacyjnymi. Wymagalne SZK_025 System musi umożliwiać podział szkoleń na wewnętrzne i zewnętrzne z możliwością nadawania uprawnień użytkownikom do określonej grupy szkoleń. Pracownicy działu szkoleń zewnętrznych muszą mieć dostęp do szkoleń ze swojego obszaru, ale także do obszaru szkoleń wewnętrznych z uwagi na planowanie kosztów podróży służbowych związanych z realizacją szkoleń wewnętrznych. Wymagalne Strona 70 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
SZK_026 System musi obsługiwać proces zarządzania szkoleniami teoretycznymi i praktycznymi realizowanymi przez Ośrodek Szkolenia Lotniczego PAŻP z uwzględnieniem instrukcji i procedur wewnętrznych. Wymagalne SZK_027 System musi umożliwiać wprowadzanie, edycję, usuwanie, przetwarzanie danych dotyczących praktykantów ruchu lotniczego i praktykantów KRL wg szczegółowości: ‐data rozpoczęcia kursu; ‐planowana data zakończenia kursu; ‐data uzyskania licencji S‐ATCL planowana i rzeczywista; ‐data przeniesienia do AR (dotyczy PRU 3, 4) planowana i rzeczywista; ‐rodzaj uprawnień na jaki szkoli się praktykant w podziale na Organ Ruchu Lotniczego i Lokalizację. Wymagalne SZK_028 Dane w rejestrze szkoleń oraz uprawnień zawodowych poszczególnych członków licencjonowanego personelu ATM, muszą być przechowywane przez 50 lat. Wymagalne SZK_029 Po odbyciu szkolenia system musi powinien aktualizować uprawnienia, kwalifikacje i kompetencje pracownika, które zostały uzyskane przez pracownika podczas szkolenia. Wymagalne SZK_030 System musi umożliwiać ocenę szkoleń wewnętrznych i zewnętrznych przez uczestników szkolenia. Wymagalne SZK_031 System musi umożliwiać tworzenie ankiet dla uczestników szkoleń w zależności od szkolenia. System musi umożliwiać definiowanie różnych zestawów pytań dotyczących organizacji szkolenia, oceny prowadzącego szkolenie, oceny materiałów szkoleniowych, ogólnej oceny szkolenia, przydatności szkolenia w bieżącej pracy itp. Wymagalne SZK_032 System musi umożliwiać rejestrowanie informacji o hospitacji i wizytacji szkoleń w powiązaniu ze szkoleniem, którego dotyczy. Wymagalne SZK_033 System musi umożliwiać rejestrowanie umów szkoleniowych z pracownikiem. Wymagalne SZK_034 System powinien umożliwiać automatyczne wyliczanie zobowiązań pracowników, w przypadku zwolnienia z PAŻP. Opcjonalne SZK_035 System musi umożliwiać ewidencjonowanie informacji o szkoleniach bhp (rodzaj szkoleń, termin szkolenia, termin ważności szkoleń). Wymagalne SZK_036 System musi wyliczać planowane oraz wykorzystane osobogodziny szkoleń w celu przekazania danych do działu finansowego do baz kosztowych w cyklach kwartalnych i rocznych. Wymagalne Obieg SZK_037 System musi obsługiwać proces planowania szkoleń poprzez elektroniczne wypełnianie formatek z potrzebami w zakresie szkoleń przez kierowników (z uwzględnieniem Systemu Ocen Pracowniczych), akceptacja szkoleń przez poszczególnych dyrektorów biur i konsolidacja szkoleń w aplikacji działu szkoleń. Po akceptacji działu szkoleń, a następnie po zatwierdzeniu Planu przez Prezesa dane tylko finansowe muszą być przekazane automatycznie do jednostek odpowiedzialnych za planowanie. Wymagalne Powiadomienia SZK_038 System musi wysyłać powiadomienia do pracownika działu szkoleń, kierownika odpowiedniej komórki oraz pracownika o planowanych i zaplanowanych terminach szkoleń. Wymagalne SZK_039 System musi wysyłać powiadomienia o konieczności wypełnienia ankiety po odbytym szkoleniu. Wymagalne SZK_040 System musi wysyłać powiadomienia o konieczności odnowienia wymaganych szkoleń. Wymagalne SZK_041 System musi wysyłać powiadomienia o konieczności odnowienia wymaganych uprawnień. Wymagalne SZK_042 System musi wysyłać powiadomienia o konieczności dostarczenia zaświadczeń o przebiegu studiów i kursów językowych. Wymagalne SZK_043 System musi zapewnić informację o ważności certyfikacji dla danego stanowiska, planowanie odnowienia certyfikacji. Wymagalne Strona 71 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Raportowanie SZK_044 System powinien generować "Wniosek o skierowanie na szkolenie krajowe". Opcjonalne SZK_045 System powinien generować "Wniosek o skierowanie na wyjazd zagraniczny (szkoleniowy)". Opcjonalne SZK_046 System powinien generować "Wniosek o skierowanie na szkolenie specjalistyczne". Opcjonalne SZK_047 System powinien generować "Formularz oceny szkolenia". Opcjonalne SZK_048 System powinien generować "Wniosek o organizację wyjazdu szkoleniowo – integracyjnego". Opcjonalne SZK_049 System musi generować "Raport z realizacji planu dla poszczególnych MPK”. Wymagalne SZK_050 System musi generować "Zestawienie planowanych szkoleń na dany rok, w ujęciu na każdy MPK, na każde biuro, w ujęciu tematycznym, w ujęciu osób, w podziale na rodzaj szkoleń". Wymagalne SZK_051 System musi generować "Zestawienie wykonanych szkoleń w danym czasie, w danym MPKu, w danym biurze, przez daną osobę". Wymagalne SZK_052 System musi generować "Zestawienie pracowników przewidzianych do przeszkolenia z danego zakresu". Wymagalne SZK_053 System musi generować "Zestawienie planowanych i wykonanych osobogodzin, dni szkoleniowych w rozbiciu na MPKi, osoby, Biura, miesiące". Wymagalne SZK_054 System musi generować "Zestawienie należności na rzecz PAŻP od danego pracownika na dany dzień". Wymagalne SZK_055 System musi generować raport "Karta przebiegu szkolenia/pracy kontrolera ruchu lotniczego". Wymagalne SZK_056 System powinien generować raport "Harmonogram zajęć". Opcjonalne SZK_057 System powinien generować raport "Dziennik zajęć". Opcjonalne SZK_058 System powinien generować raport "Karta oceny praktyki (kontrola zbliżania proceduralna i kontrola lotniska)". Opcjonalne SZK_059 System powinien generować raport "Karta oceny praktyki (kontrola zbliżania radarowa)". Opcjonalne SZK_060 System powinien generować raport "Karta oceny praktyki (kontrola obszaru)". Opcjonalne SZK_061 System musi generować raport "Arkusz hospitacyjny". Wymagalne SZK_062 System powinien generować raport "Karta oceny przebiegu szkolenia". Opcjonalne SZK_063 System powinien generować raport "Protokół egzaminacyjny Symulator ‐ karta egzaminacyjna". Opcjonalne SZK_064 System powinien generować raport "Protokół z egzaminu teoretycznego do przedłużenia uprawnień lotniczych". Opcjonalne SZK_065 System powinien generować raport "Zaświadczenie o ukończeniu szkolenia lotniczego (teoria i/lub symulator)". Opcjonalne SZK_066 System powinien generować raport "Zaświadczenie o ukończeniu szkolenia lotniczego (praktyka)". Opcjonalne SZK_067 System musi generować raport " Harmonogram egzaminów ustnych". Wymagalne SZK_068 System musi generować raport "Zbiorcze zestawienie wyników egzaminów ustnych". Wymagalne SZK_069 System powinien generować raport "Harmonogram zajęć na symulatorze". Opcjonalne SZK_070 System powinien generować raport "Protokół oceny kompetencji". Opcjonalne SZK_071 System musi generować raport "Zestawienie planowanych szkoleń wewnętrznych na dany rok". Wymagalne SZK_072 System musi generować raport "Zestawienie wykonanych szkoleń wewnętrznych za dany okres". Wymagalne SZK_073 Na podstawie rejestru kwalifikacji, system musi generować zestawienie umożliwiające grupowanie Wymagalne Strona 72 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
pracowników na szkolenie w określonych przedziałach czasowych. SZK_074 System musi generować raport "Lista aktualnie dostępnych szkoleń wewnętrznych". Wymagalne SZK_075 System musi generować raport "Lista szkoleń wewnętrznych w trakcie realizacji w wybranym okresie czasu". Wymagalne SZK_076 System powinien generować raport "Lista szkoleń wewnętrznych zrealizowanych w wybranym okresie czasu". Opcjonalne SZK_077 System powinien generować raport "Lista uczestników zgłoszonych na poszczególne szkolenia". Opcjonalne SZK_078 System musi generować raport "Lista uczestników szkolenia". Wymagalne SZK_079 System powinien generować raport "Lista obecności /dziennik zajęć". Opcjonalne SZK_080 System musi generować raport "Wyniki egzaminów teoretycznych i praktycznych (symulator) dla poszczególnych kandydatów/pracowników". Wymagalne SZK_081 System powinien generować raport "Ankiety oceny szkolenia". Opcjonalne SZK_082 System powinien generować raport "Lista instruktorów, wykładowców i trenerów podlegających ESARR5 (obecna LIT)". Opcjonalne SZK_083 System powinien generować raport "Lista pracowników PAŻP uprawnionych do prowadzenia szkoleń (obecna LIP)". Opcjonalne SZK_084 System powinien generować raport "Lista dziedzin, w których PAŻP wykształciła instruktorów, trenerów i wykładowców". Opcjonalne SZK_085 System powinien generować raport "Lista personelu uprawnionego do przygotowywania i prowadzenia egzaminów wewnętrznych w PAŻP, egzaminów praktycznych i/lub teoretycznych LKE (Lotniczej Komisji Egzaminacyjnej)" Opcjonalne SZK_086 System powinien generować raport "Lista dziedzin, w których PAŻP dysponuje własnymi egzaminatorami (lista LIE)". Opcjonalne SZK_087 System musi generować raport "Imienne zestawienie terminu złożenia egzaminów komputerowych, terminu odbycia szkolenia odświeżającego z zakresu sytuacji szczególnych i niebezpiecznych, terminu złożenia egzaminów językowych, terminu upływu ważności orzeczenia lekarskiego, terminu upływu ważności blankietu licencji, terminów wznowienia posiadanych uprawnień krl, terminów wznowienia posiadanych uprawnień instruktora, terminów wykonania". Wymagalne SZK_088 System musi generować raport "Zbiorcza lista upływu terminów ważności uprawnień (kwartalnych, rocznych)". Wymagalne SZK_089 System powinien generować raport "Sprawozdanie z realizacji mierników wewnętrznych i celów jakościowych procesu". Opcjonalne SZK_090 System musi generować raport "Raport okresowy zawierający nazwiska osób skierowanych na szkolenie wewnętrzne". Wymagalne SZK_091 System musi generować "Zapotrzebowania na przeprowadzenie szkolenia wewnętrznego i/lub egzaminu po przeprowadzeniu szkolenia dla konkretnej jednostki wynikających złożonego" Zapotrzebowanie składane jest przez właściwego Dyrektora Biura. Wymagalne SZK_092 System powinien generować raport dotyczące zamówień (zgłoszeń) na przeprowadzenie szkolenia wewnętrznego i/lub egzaminy po przeprowadzeniu szkolenia dla konkretnej jednostki wynikających z: 1) przepisów (np. szkolenia odświeżające z zakresu sytuacji szczególnych i niebezpiecznych), 2) zapotrzebowania złożonego przez firmę lub firmy zewnętrzne. Opcjonalne PKZP Strona 73 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Wymagania ogólne KZP_001 System musi zachowywać zgodność kartoteki członków PKZP z kartoteką pracowników PAŻP. Kartoteka członków PKZP jest podzbiorem kartoteki pracowników PAŻP. Wymagalne KZP_002 System musi umożliwić założenie kartoteki w PKZP wyłącznie osobie posiadającej kartotekę w PAŻP. Wymagalne KZP_003 Kartoteka członka PKZP powinna zawierać co najmniej następujące informacje: dane podstawowe pracownika (imię, nazwisko), adres, nr rachunku bankowego, unikalny numer pracownika (nazywany również obecnie numerem umowy), adres korespondencyjny, nazwę komórki organizacyjnej, miejsce pracy, system pracy. Wymagalne KZP_004 Informacja o potrąceniach wkładów z wynagrodzenia pracownika lub z otrzymywanych zasiłków, na rzecz funduszu oszczędnościowo‐pożyczkowego PKZP powinna być udostępniana obszarowi płacowemu, gdzie w procesie rachuby listy płac, potrącenia te są uwzględniane. Wymagalne KZP_005 Wymaga się aby informacja o zrealizowanych potrąceniach wkładów, wymagana w procesie gromadzenia wkładów z uwagi na konieczność zaksięgowania wkładu na indywidualnym koncie członka PKZP, była dostępna bezpośrednio z obszaru płacowego w formie umożliwiającej jej wykorzystanie w procesie automatycznego księgowania wkładów. Wymagalne KZP_006 System musi przechowywać i udostępniać informację o wkładzie każdego członka PKZP. Wymagalne KZP_007 System musi przechowywać i udostępniać informację o ustalonym limicie pożyczek każdego członka PKZP. Wymagalne KZP_008 System powinien ostrzegać o przekroczeniu limitu podczas udzielania pożyczki. Wymagalne KZP_009 Do każdej udzielonej pożyczki System musi rejestrować harmonogram spłat. Wymagalne KZP_010 System będzie przechowywał historię zmian harmonogramów. Wymagalne KZP_011 System musi zapewnić uwzględnianie harmonogramu spłat pożyczek pracownika w procesie rachuby listy płac, ponieważ spłaty rat są w większości przypadków realizowane poprzez potrącenia z wynagrodzenia i zasiłków pracownika. Wymagalne KZP_012 System zapewni przekazanie z modułu obsługi rachuby płac informacji o potrąconych kwotach spłacanych rat do PKZP. Jest ona potrzebna w celu jej zaksięgowania na indywidualnych kontach członków PKZP. Wymagalne KZP_013 System zapewni przekazanie informacji z Rachuby Płac, iż ze względu na znaczna liczbę obciążeń wynagrodzenia Członka PKZP nie będzie potrącona rata pożyczki czy wkład. Wymagalne KZP_014 System powinien mieć możliwość rozróżnienia tytułu wpłaty z uwagi na operowanie różnymi produktami, np. pożyczka wakacyjna, pożyczka świąteczna, itp. Każdy taki produkt rozliczany jest oddzielnie. Harmonogram spłat rat pożyczki może być zmieniany. Wymagalne KZP_015 W przypadku braku wynagrodzenia (np. w trakcie urlopu wychowawczego, urlopu bezpłatnego), członek Wymagalne spłaca ratę bezpośrednio na konto bankowe PKZP. System powinien umożliwiać rozliczenie takiej wpłaty z należnościami wynikającymi z harmonogramu spłat rat. KZP_016 System zapewni potrącanie składek KKP z wynagrodzenia pracownika miesięcznie lub rocznie. Wymagalne KZP_017 System musi umożliwiać określenie rodzaju przyznanej zapomogi. Wymagalne KZP_018 Możliwość wprowadzania w systemie informacji o wielu poręczycielach pożyczki. Wymagalne KZP_019 Możliwość żyrowania pożyczki na poręczycieli (żyrantów). Wymagalne KZP_020 System zapewni ewidencję osób uprawnionych do świadczenia na wypadek śmierci członka PKZP. Wymagalne KZP_021 Elektronicznie przekazywać członkom PKZP powiadomienie o odrzuceniu wniosku o pożyczkę. Wymagalne Strona 74 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KZP_022 Elektronicznie przekazywać członkom PKZP powiadomienie o przyjęciu wniosku. Wymagalne KZP_023 Elektronicznie przekazywać członkom PKZP informację o dokonanej korekcie na jego indywidualnym koncie. Wymagalne KZP_024 Elektronicznie przekazywać członkom PKZP informację o odmowie wycofania wkładów. Wymagalne Tabela 8. Wymagania funkcjonalne ‐ Zarządzanie personelem 2.2.3
Wymagania dotyczące komponentu - Podsystem FinansowoKsięgowy
Nr
wymagania
Wymaganie
Kategoria
wymagania
Księgowość Wymagania ogólne KG_001 System musi zapewniać możliwość wprowadzania zapisów księgowych do bufora (tzw. księgowania próbnego), pozwalającego na opcjonalne uwzględnienie ich w obrotach i saldach na wszystkich zestawieniach. Ponadto system powinien umożliwiać symulację alokacji kosztów, uwzględniającą transakcje bufora. Do momentu zatwierdzenia i ostatecznego zaksięgowania zapisy te mogą być wycofane z księgowania próbnego i poprawiane. Wymagalne KG_002 System musi zapewnić możliwość definiowania rejestrów księgowych, do których trafiają poszczególne księgowane dowody. Wymagalne KG_003 System musi mieć możliwość definiowania rodzajów dokumentów pochodzących z różnych obszarów (np. rodzaje faktur sprzedaży, faktur zakupu, dokumentów kasowych, itp.). Wymagalne KG_004 System musi umożliwiać konfigurowanie specyficznej obsługi dla różnych rodzajów dokumentów (np. definicja uprawnień, schematów numeracji, obiegu, schematów dekretacji, pól dodatkowych, itp.). Wymagalne KG_005 System musi posiadać możliwość dodawania do dokumentu nowych pól, które będą mogły być użyte w definiowalnych raportach. Wymagalne KG_006 System musi posiadać możliwość dodawania do dokumentu nowych pól, które będą mogły być użyte w schematach dekretacji. Wymagalne KG_007 System musi zapewnić poprawną obsługę dokumentów korygujących w zakresie zarówno księgowań, jak i sprawozdawczości, szczególnie podatkowej, oraz wewnętrznej. Wymagalne KG_008 System musi mieć możliwość wprowadzania schematów księgowań dla każdego rodzaju dokumentu/dowodu księgowego, oraz kontroli poprawności dekretacji. Wymagalne KG_009 System musi zapewnić możliwość stosowania schematu księgowań przy wprowadzaniu dowodów księgowych. Wymagalne KG_010 System musi zapewnić elastyczność rozwiązania schematów dekretacji w sposób umożliwiający wykorzystywanie jako elementy wskazujące na sposób dekretacji danych, również spoza modułu księgowego, powiązanych z dokumentem, pochodzących z modułu w którym pierwotnie rejestrowane lub generowane jest zdarzenie podlegające księgowaniu. (np. MPK, kontrahent, zamówienie, umowa, nr zadania inwestycyjnego, specjalnego oznaczenia dla faktur unijnych, danych umowy, danych zlecenia sprzedaży, danych WOUZ, itp.). Wymagalne KG_011 System musi mieć możliwość zapisu na poziomie dekretu księgowego danych właściwych dla danej transakcji przewidzianych w Polityce Rachunkowości Agencji, zarejestrowanych w modułach, w których pierwotnie rejestrowany lub generowany jest danych zapis. Wymagalne KG_012 System powinien zapewnić możliwość powiązania danych z dokumentów rejestrowanych w komponencie EOD z informacją o tych dokumentach wykorzystywana w komponencie ERP. (np. nr MPK Wymagalne Strona 75 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
określone w komponencie EOD, nr zadania inwestycyjnego, specjalnego oznaczenia dla faktur unijnych, danych umowy, danych zlecenia sprzedaży, danych WOUZ, itp.). KG_013 System musi mieć możliwość wystornowania dokumentu (zarówno dekretów jak i rozrachunków). Wymagalne KG_014 System musi zapewniać prowadzenie dziennika w układzie chronologicznym. Wymagalne KG_015 System musi zapewniać możliwość tworzenia dzienników cząstkowych. Wymagalne KG_016 System musi zapewnić możliwość księgowania w bieżącym okresie, gdy poprzednie nie są jeszcze zamknięte. Wymagalne KG_017 System musi zapewnić możliwość blokowania księgowania w danym okresie bez potrzeby zamykania okresu. Wymagalne KG_018 System musi zapewnić możliwość odblokowania księgowania w zablokowanym okresie tylko dla wskazanych użytkowników. Wymagalne KG_019 System musi zapewniać możliwość prowadzenia dodatkowych ewidencji przeliczonych na inną walutę sprawozdawczą. Wymagalne KG_020 System musi zapewnić możliwość prowadzenia ksiąg w wielu walutach jednocześnie. Wymagalne KG_021 System musi mieć możliwość raportowania stanu kosztów / przychodów zamkniętych lat bez uwzględnienia przeksięgowania na wynik. Wymagalne KG_022 System musi zapewnić identyfikację każdego użytkownika tworzącego, modyfikującego, zatwierdzającego, usuwającego zapisy ksiąg rachunkowych z określeniem czasu wykonania operacji. Wymagalne Zmiana waluty na EURO KG_023 Po przystąpieniu Polski do strefy euro, System musi być dostosowany do pracy w walucie EURO bez ponoszenia przez Zamawiającego jakichkolwiek kosztów z tym związanych. Wymagalne KG_024 System musi być dostosowany do pracy w okresie przejściowym wprowadzania waluty EURO w sposób zgodny z przepisami okresu przejściowego bez ponoszenia przez Zamawiającego jakichkolwiek kosztów z tym związanych.
Wymagalne Okresy sprawozdawcze KG_025 System musi zapewnić możliwość wprowadzania kalendarza księgowego z większą lub mniejszą ilością okresów niż 12. Wymagalne KG_026 System musi zapewnić możliwość zdefiniowania okresów specjalnych, w którym rejestrowane są operacje korygujące zapisy roku obrotowego po zamknięciu ostatniego okresu zwykłego (tzw. 13 okres i więcej). Wymagalne KG_027 System musi zapewniać automatyczne generowanie bilansu zamknięcia. Wymagalne KG_028 System musi zapewniać automatyczne generowanie bilansu otwarcia na podstawie bilansu zamknięcia. Wymagalne KG_029 System musi zapewniać aktualizację bilansu otwarcia w przypadku wprowadzenia korekt mających wpływ na BO. Wymagalne KG_030 System musi zapewnić możliwość zdefiniowania schematów przeniesienia bilansu zamknięcia na bilans otwarcia w przypadku zmiany struktury planu kont w nowym roku obrotowym. Wymagalne KG_031 System musi zapewnić możliwość wielokrotnego zamykania i otwierania roku obrotowego przed zamknięciem ostatecznym. Wymagalne KG_032 System musi mieć mechanizm zabezpieczający przed zamknięciem ksiąg/okresów sprawozdawczych, dla których istnieją błędne dekretacje. Wymagalne KG_033 System musi mieć mechanizm zabezpieczający przed zamknięciem ksiąg/okresów sprawozdawczych, dla których istnieją niezatwierdzone dekretacje (w buforze). Wymagalne Strona 76 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KG_034 System musi mieć mechanizm zabezpieczający przed zamknięciem księgi głównej/okresów sprawozdawczych, jeżeli nie zostały zamknięte wszystkie księgi pomocnicze. Wymagalne Plan kont KG_035 System musi zapewniać możliwość tworzenia wielowymiarowego planu kont z rozbudowaną analityką. Wymagalne KG_036 System musi zabezpieczać przed możliwością niepoprawnych kombinacji segmentów analitycznych konta podczas dekretacji i zatwierdzania księgowania. Wymagalne KG_037 System musi zapewniać kontrolę bilansowania zapisów księgowych na kontach bilansowych i wynikowych (zasada podwójnego zapisu). Wymagalne KG_038 System musi zapewnić obsługę kont bilansowych i pozabilansowych. Wymagalne KG_039 System musi zapewnić obsługę kont wynikowych. Wymagalne KG_040 System musi zapewnić mechanizm uzgadniania zapisów na wskazanych kontach księgi głównej. Wymagalne KG_041 System powinien umożliwiać wprowadzanie kont o różnej ilości segmentów analitycznych dla różnych kont syntetycznych. Opcjonalne KG_042 System musi zapewnić możliwość modyfikacji struktury planu kont oraz danych powiązanych (np. schematów księgowania, definicji sprawozdań) w sposób umożliwiający ciągłość ewidencji księgowej. Wymagalne KG_043 System musi mieć możliwość przydzielenia poszczególnym typom kont księgowych atrybutów określających ich umiejscowienie w sprawozdaniu finansowym. Wymagalne KG_044 System musi mieć możliwość przydzielenia poszczególnym kontom księgowym atrybutów określających ich umiejscowienie w raportach. Wymagalne KG_045 System musi umożliwiać prowadzenie kont kosztowych zarówno w zespole 4 jak i 5 w celu umożliwienia sporządzenia sprawozdań zarówno w wariancie porównawczym jak i w wariancie kalkulacyjnym. Wymagalne KG_046 Przy rejestracji zapisów księgowych na kontach 4 i 5 oddzielnie wymagana jest możliwość włączenia kontroli kręgu kosztowego. Wymagalne KG_047 Przy rejestracji zapisów księgowych na kontach 4 i 5 jednocześnie wymagana jest możliwość włączenia kontroli kręgu kosztowego dla dowodu. Wymagalne Definiowanie uprawnień KG_048 Model uprawnień musi być spójny z wymaganiami ogólnymi dotyczącymi definiowania uprawnień w systemie. Wymagalne KG_049 System musi umożliwiać definiowanie szczegółowych uprawnień do operacji (w tym zatwierdzania, księgowania próbnego, księgowania, stornowania, zamykania/blokowania okresów sprawozdawczych) Wymagalne KG_050 System musi mieć możliwość definiowania szczegółowych uprawnień do dzienników księgowych. Wymagalne KG_051 System musi mieć możliwość definiowania szczegółowych uprawnień do rejestrów Wymagalne KG_052 System musi mieć możliwość do definiowania uprawnień do kont księgowych (osobno dla przeglądania danych osobo dla księgowania). Wymagalne KG_053 System powinien mieć możliwość do definiowania uprawnień do segmentów analitycznych kont księgowych (osobno dla przeglądania danych osobno dla księgowania).
Opcjonalne KG_054 System musi mieć możliwość definiowania uprawnień do rodzajów dokumentów i dowodów. Wymagalne
Obsługa sprzedaży i dokumentów należności
KG_055 System musi mieć możliwość obsługi sprzedaży, w tym obsługę księgową sprzedaży usług nawigacyjnych i pozanawigacyjnych. Wymagalne Strona 77 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KG_056 System musi mieć możliwość rejestracji faktur na oddziały kontrahenta. Wymagalne KG_057 System musi mieć możliwość zarejestrowania w rejestrze VAT faktur nie posiadających NIP‐u kontrahenta. Powinien obsługiwać kryterium poprawności dla takich faktur. Wymagalne KG_058 System musi mieć możliwość generowania faktur sprzedaży w różnych walutach. Wymagalne KG_059 System musi mieć możliwość wystawiania faktur zaliczkowych i automatyzować, oraz kontrolować proces ich rozliczania z fakturami końcowymi, z uwzględnieniem wymogów sprawozdawczości podatkowej. Wymagalne KG_060 System musi mieć możliwość wystawiania korekt do faktur pierwotnych i korygowanych. Wymagalne KG_061 System musi mieć możliwość wystawiania dokumentów przychodowych niebędących fakturami VAT oraz ich korygowania i wystawiania dokumentów korygujących. Wymagalne KG_062 System musi obsługiwać dokumenty niepodlegające VAT (np. noty obciążeniowe, rachunki) oraz ich korekty i dokumenty korygujące. Wymagalne KG_063 System musi automatycznie generować i wyświetlać komunikat o nierozliczonej przedpłacie w przypadku wprowadzenia dokumentu dla kontrahenta, który dokonał przedpłaty. Wymagalne KG_064 System musi zapewniać automatyczną numerację faktur sprzedaży z uwzględnieniem rodzaju sprzedaży (np. różne rodzaje usług, materiałów, towarów, itp.). Wymagalne KG_065 System musi zapewnić weryfikację pozycji faktur sprzedażowych z rodzajem sprzedaży przypisanym do faktury. Wymagalne KG_066 System musi umożliwiać zmianę kont do dekretacji należności w zależności od stanu należności (np. należność ze sprzedaży, sporna) i jej rodzaju. Wymagalne KG_067 System powinien umożliwić automatyczne tworzenie i rozwiązywanie rezerw dla tzw. należności wątpliwych w momencie zmiany ich statusu. Opcjonalne KG_068 System musi umożliwić tworzenie i rozwiązywanie rezerw dla tzw. należności wątpliwych w momencie zmiany ich statusu. Wymagalne KG_069 System powinien umożliwić rozróżnienie należności długoterminowych i krótkoterminowych zależnie od terminu wymagalności na zadany dzień raportowania. Wymagalne KG_070 System powinien umożliwić zmianę konta i przeksięgowanie należności długoterminowych i krótkoterminowych zależnie od terminu wymagalności na moment tworzenia sprawozdania bilansowego. Opcjonalne KG_071 System musi mieć możliwość stosowania dla jednej faktury kilku różnych kursów walut w zależności od potrzeb sprawozdawczych (inny kurs dla PDOP, inny dla VAT a jeszcze inny dla UE). Wymagalne Obsługa zakupów i dokumentów zobowiązań
KG_072 System musi zapewnić wprowadzanie dokumentów zobowiązań w sposób umożliwiający monitorowanie terminu płatności od chwili wpływu dokumentu do Agencji (w tym zakresie system musi zapewniać odpowiednią integrację z komponentem EOD).
Wymagalne KG_073 System powinien umożliwić rozróżnienie zobowiązań długoterminowych i krótkoterminowych zależnie od terminu wymagalności na zadany dzień raportowania. Wymagalne KG_074 System powinien umożliwić zmianę konta i przeksięgowanie zobowiązań długoterminowych i krótkoterminowych zależnie od terminu wymagalności na moment tworzenia sprawozdania bilansowego. Opcjonalne KG_075 System musi mieć możliwość rejestracji faktur na oddziały kontrahenta. Wymagalne KG_076 System musi mieć możliwość obsługi zobowiązań w różnych walutach. Wymagalne Strona 78 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KG_077 System musi obsługiwać dokumenty niepodlegające VAT (np. noty uznaniowe, rachunki) oraz ich korekty i dokumenty korygujące. Wymagalne KG_078 System musi automatycznie generować i wyświetlać komunikat o nierozliczonej przedpłacie w przypadku wprowadzenia dokumentu od kontrahenta, któremu udzielono przedpłaty. Wymagalne KG_079 System musi zapewniać automatyczną numerację dokumentów zobowiązań z uwzględnieniem ich rodzaju. Wymagalne KG_080 System musi zapewniać możliwość rejestracji nagłówka faktury i posłania jej w obieg przy zachowaniu możliwości uzupełnienia pozycji, dekretów, rozrachunków oraz rozliczenia faktury bez zakończonego obiegu. Wymagalne KG_081 System musi zapewnić jednoznaczności przypisania ponoszonych kosztów do podejmowanych działań i nośników kosztowych, zarówno podczas ewidencji działań, jak i sprawozdawczości oraz na potrzeby kontroli wykonania budżetów. Wymagalne KG_082 System musi umożliwiać automatyczne księgowanie odchyleń od cen ewidencyjnych w sposób właściwy dla przyjętej metody wyceny indeksów magazynowych. Wymagalne KG_083 System musi umożliwić poprawne księgowanie zwrotów do magazynu w sposób właściwy dla przyjętej metody wyceny indeksów magazynowych. Wymagalne Obsługa banku KG_084 System musi kontrolować ciągłość operacji na danym rachunku bankowym podczas rejestracji i zatwierdzania wyciągu bankowego. Wymagalne KG_085 System musi mieć możliwość obsługi operacji bankowych w zakresie rachunków bankowych złotowych i dewizowych. Wymagalne KG_086 System musi mieć możliwość obsługi operacji bankowych z udziałem interfejsów wymiany danych z systemami bankowości elektronicznej. Wymagalne KG_087 System musi mieć możliwość generowania płatności w różnych formatach przelewów w tym ZUS, Podatki. Wymagalne KG_088 System musi mieć możliwość automatycznego wprowadzania wyciągów bankowych do systemu z różnych konfiguracji plików wsadowych. Wymagalne KG_089 System powinien zapewniać możliwość polskich znaków dla przelewów krajowych przy użyciu interfejsu do banku. Wymagalne KG_090 System powinien zapewniać możliwość automatycznego generowania w module finansowo‐księgowym i przesyłania do systemu bankowego przelewów zagranicznych i walutowych.
Opcjonalne KG_091 System musi zapewniać automatyczne generowanie przelewów na osobiste rachunki bankowe pracowników w PLN oraz w walucie obcej przy rozliczeniu przelewem dokumentów finansowych z tytułu rozrachunków z pracownikami. Wymagalne KG_092 System musi zapewnić możliwość obsługi przelewów elektronicznych w partiach (paczkach) płatności oraz możliwość ich wydrukowania, odrębnie dla przelewów krajowych i zagranicznych. Wymagalne KG_093 System musi zapewnić generowanie płatności elektronicznych z systemu FK do banków na podstawie zadanych kryteriów (np. priorytet, termin zapłaty, przedział kwot, kontrahent, grupa kontrahentów, pracownik, grupa pracowników itp.). Wymagalne KG_094 System musi zapewnić automatyczne wczytywanie i rozksięgowywanie wyciągów bankowych. Wymagalne KG_095 System musi zapewniać możliwość korygowania i anulowania płatności z utworzonej partii przelewów przed wygenerowaniem pliku wsadowego do systemu bankowego. Wymagalne KG_096 System musi nadawać płatnościom (w tym elektronicznym) unikalne identyfikatory. Wymagalne Strona 79 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KG_097 System musi zapewnić generowanie przelewów krajowych i zagranicznych z uwzględnieniem weryfikacji prawidłowości numeru konta (np. IBAN, NRB). Wymagalne KG_098 System musi zapewniać możliwość automatycznego dekretowania linii wyciągów bankowych. Wymagalne KG_099 System musi dawać możliwość stosowania różnego rodzaju metod wyceny środków pieniężnych na rachunkach bankowych w zgodzie z przepisami prawa (w tym w szczególności rozliczanie rozchodu środków pieniężnych wg metody FIFO, kursu średnioważonego lub kursu użytkownika). Wymagalne KG_100 System musi zapewnić możliwość dodawania dodatkowych linii dekretów do wyciągu bankowego umożliwiających rozksięgowanie wyciągu w szyku rozwartym (np.: transakcja per saldo ujęta jako pełny przychód i koszt). Wymagalne KG_101 System musi umożliwić zadekretowanie jednej operacji na wyciągu bankowym wieloma zapisami księgowymi, w zależności od dekretowanej operacji. Wymagalne KG_102 System musi wspomagać rozliczanie należności za faktury w jednej walucie z zapłatą wychodzącą z rachunku w innej walucie. Wymagalne KG_103 System musi zapewniać możliwość automatycznego wybierania dokumentów dla danego pracownika przy tworzeniu partii płatności z dokumentów finansowych z tytułu rozrachunków z pracownikami płatnych przelewem. Wymagalne KG_104 System musi zapewniać możliwość wprowadzenia w danym dniu kilku partii płatności przez pracownika dokonującego rozliczenia dokumentów finansowych. Wymagalne KG_105 System powinien zapewniać możliwość anulowania i korygowania partii płatności utworzonych z dokumentów finansowych z tytułu rozrachunków z pracownikami płatnych przelewem. Wymagalne KG_106 System musi zapewnić prawidłową wycenę waluty w przypadku dokonywania transferów kasa‐bank, lub pomiędzy rachunkami bankowymi. Wymagalne Obsługa kasy KG_107 System musi obsługiwać wiele kas rozmieszczonych w różnych lokalizacjach geograficznych. Wymagalne KG_108 System musi mieć możliwość obsługi kas w jednostkach terenowych w trybie pracy on‐line. Wymagalne KG_109 System musi zapewnić kontrole ciągłości operacji kasowych danej kasy np. zgodności stanu salda zamknięcia kasy z saldem otwarcia kasy itp. Wymagalne KG_110 System musi automatycznie numerować raporty kasowe i ich pozycje, oraz umożliwiać ręczną ingerencję w numerację w numerację i datę sporządzenia raportów kasowych. Wymagalne KG_111 System musi zapewnić obsługę operacji kasowych złotowych i walutowych, w tym: ‐ obsługę rozliczeń gotówkowych z pracownikami, ‐ obsługę rozliczeń gotówkowych z kontrahentami, ‐ przyjmowanie i wypłacanie wadium.
Wymagalne KG_112 Dla każdej kasy system musi rejestrować operacje w ramach raportów kasowych.
Wymagalne
KG_113 System musi zapewnić obsługę raportów kasowych za różny okres, w tym dziennych, tygodniowych, dekadowych, miesięcznych. Wymagalne KG_114 System musi umożliwiać prowadzenie raportów kasowych w różnych walutach. Wymagalne KG_115 System musi zapewniać możliwość stosowania różnego rodzaju metod wyceny środków pieniężnych w raportach kasowych w zgodzie z przepisami prawa (w tym w szczególności rozliczanie rozchodu środków pieniężnych wg metody FIFO, kursu średnioważonego lub kursu użytkownika). Wymagalne KG_116 System musi zapewniać możliwość drukowania raportów kasowych oraz dokumentów KP, KW na zwyczajowo stosowanych szablonach. Wymagalne Strona 80 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KG_117 System musi zapewniać zrobienie inwentaryzacji w kasie, wraz z rejestracją posiadanych ilości nominałów. Wymagalne KG_118 System musi zapewniać, że tylko jeden kasjer ma dostęp do danego raportu kasowego, a inni kasjerzy nie mogą go zmieniać. Wymagalne KG_119 System musi umożliwić prowadzenie dla jednej kasy wielu raportów kasowych w jednym dniu, nawet w tej samej walucie. Wymagalne KG_120 System musi zapewniać możliwość wydruku dokumentu informującego o wypłacie zaliczki. Wymagalne OBSŁUGA PKZP KG_121 System musi prowadzić rejestry wyciągów bankowych rachunków PKZP. Wymagalne KG_122 System musi prowadzić rejestry raportów kasowych PKZP. Wymagalne KG_123 System musi prowadzić dzienniki księgowe PKZP. Wymagalne KG_124 System musi prowadzić księgę główną PKZP, jako wydzielona księgę rachunkową. Wymagalne KG_125 System musi prowadzić księgi pomocnicze rozrachunków z członkami PKZP oraz rozrachunków z podmiotami zewnętrznymi. Wymagalne KG_126 Dostęp do ksiąg PKZP musi być przydzielony wyłącznie uprawnionym osobom. Wymagalne KG_127 System musi umożliwiać prowadzenie ksiąg PKZP w sposób zgodny z wymaganiami Ustawy o rachunkowości. Wymagalne KG_128 System powinien udostępniać Zarządowi PKZP informację o obrotach na poszczególnych produktach pożyczkowych. Wymagalne KG_129 System musi zapewnić raport, stanowiący potwierdzenie salda pożyczki, obejmujący informacje o wartości zgromadzonego wkładu, wartości środków na KKP. Raport taki raz w roku lub na żądanie, przygotowywany jest członkowi PKZP. Wymagalne KG_130 System musi zapewnić raport ilościowy i kwotowy o udzielonych pożyczkach, zapomogach. Wymagalne KG_131 System musi zapewnić raport pokazujący świadczenia KKP w odniesieniu do różnych okresów czasu. Wymagalne KG_132 System musi zapewnić raport o planowanych spłatach rat pożyczek we wskazanym miesiącu. Wymagalne KG_133 System musi zapewnić raport: wykaz członków PKZP zlokalizowanych w wybranej komórce organizacyjnej lub w wybranym obiekcie PAZP. Wymagalne KG_134 System musi zapewnić raport różnic między harmonogramem spłat a faktycznymi spłatami. Wymagalne KG_135 System musi zapewnić raport: zestawienie obrotów i sald ksiąg PKZP. Wymagalne KG_136 System musi zapewnić raport: wydruk dowodu księgowego ewidencji PKZP. Wymagalne KG_137 System umożliwi ewidencję wypłat z funduszu KKP. Wymagalne KG_138 System zapewni obsługę księgową wpłat i wypłat środków z funduszu KKP. Wymagalne KG_139 System musi prowadzić ewidencję księgowa udzielonych zapomóg. Wymagalne KG_140 System musi zapewnić integrację z systemem bankowości elektronicznej. Wymagalne KG_141 Umożliwienie wydrukowania przelewów PKZP na szablonach zwyczajowo stosowanych dla dyspozycji przelewów. Wymagalne KG_142 Automatyczne generowanie dla PKZP w Systemie bilansu, zestawienia zmian w kapitale własnym, rachunek zysków i strat w przypadku zaistnienia operacji kosztowych.
Wymagalne KG_143 System musi umożliwiać obsługę funduszu oszczędnościowo‐pożyczkowego.
Wymagalne
Strona 81 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KG_144 System musi umożliwiać obsługę funduszu rezerwowego. Wymagalne KG_145 System musi umożliwiać obsługę funduszu zapomogowego. Wymagalne KG_146 System musi umożliwiać obsługę funduszu Koleżeńskiej Kasy Pogrzebowej. Wymagalne Automatyzacja procesów KG_147 System musi zapewniać rozliczanie kosztów w czasie, wraz z tworzeniem harmonogramu (nawet dla nieotwartych przyszłych okresów księgowych) ich rozliczania. Wymagalne KG_148 System musi zapewniać możliwość automatycznej weryfikacji rozliczonej/nierozliczonej części harmonogramu rozliczenia kosztów w czasie. Wymagalne KG_149 System musi zapewniać ewidencjonowanie harmonogramu rozliczeń międzyokresowych w postaci kwot do przeksięgowania w określonych terminach na określonych kontach księgowych. Wymagalne KG_150 Harmonogram musi być powiązany z dokumentem, na podstawie którego powstał, w celu umożliwienia zmian w harmonogramie rozliczeń międzyokresowych w przypadku korekty faktury. Wymagalne KG_151 Wymaga się, aby System wygenerował na podstawie harmonogramu przeksięgowań we właściwym terminie odpowiedni dowód. Wymagalne KG_152 System powinien zapewniać możliwość tworzenia harmonogramów rozliczeń międzyokresowych biernych. Tworząc rezerwy na przyszłe świadczenia pracownicze firma może odkładać środki na ten cel w okresach wcześniejszych, zaliczając je w koszty. Wymagalne KG_153 System musi zapewniać procedurę automatycznego przenoszenia sald kont wynikowych na konto wyniku finansowego. Wymagalne KG_154 System musi zapewniać możliwość tworzenia odpisów aktualizacyjnych powiązanych z dokumentami (dla poszczególnych dokumentów). Automatyczne przygotowanie noty księgowej wg zasad przyjętych w polityce rachunkowości oraz przygotowanie noty stornującej odpowiednie kwoty w przypadku uzyskania wpłat. Wymagalne KG_155 System musi umożliwiać zdefiniowanie określonych schematów księgowań operacji wykonywanych z danym kontrahentem w celu automatycznego ujęcia rozrachunku z kontrahentem na właściwych kontach planu kont. Wymagalne KG_156 System musi umożliwić tworzenie harmonogramów płatności dla danego dokumentu. Wymagalne KG_157 System musi umożliwić definiowania różnych rodzajów i poziomów alokowania przychodów, kosztów oraz innych pozycji aktywów i pasywów. Wymagalne KG_158 System musi zapewnić zintegrowanie procesu rozliczenia kosztów na MPK oraz według metody ABC/M z ewidencją księgową. Wymagalne KG_159 System musi umożliwiać wprowadzenie kluczy podziałowych do alokacji: w pełni ręcznie, z wykorzystaniem szablonów, dynamicznie, na podstawie danych zapisanych w księgach dla danego okresu i narastająco od początku roku. Wymagalne KG_160 System musi umożliwić alokowania przychodów, kosztów, rozrachunków na poszczególne segmenty działalności operacyjnej. Wymagalne KG_161 System musi umożliwiać obsługę księgową, w tym przeksięgowanie wpłaconego wadium na poczet należytego wykonania umowy na podstawie dyspozycji wykonawcy. Wymagalne KG_162 System musi umożliwiać obsługę księgową, w tym automatyczne przeksięgowanie wpłaconego wadium na poczet należytego wykonania umowy na podstawie dyspozycji wykonawcy.
Opcjonalne Wymagania z Zarzadzania płynnością finansową
Strona 82 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KG_163 System musi umożliwiać wiązanie zewnętrznych dokumentów finansowych z umową, będącą podstawą ich wystawienia w celu zapewnienia właściwego ujęcia umowy i faktur przypisanych do niej (zapobieganiu dublowania) w planie przepływów finansowych oraz możliwości kontroli poprawności terminu zapłaty z faktury. Wymagalne KG_164 Powiązanie zewnętrznych dokumentów finansowych z umową, będącą podstawą ich wystawienia, musi odbywać się w powiązaniu z elektronicznym obiegiem dokumentów i być trwale zapisywane w bazie danych. Wymagalne KG_165 Przypisanie faktury do umowy musi się odbywać bezpośrednio lub pośrednio poprzez zamówienie. Wymagalne KG_166 Informacja na temat powiązania zewnętrznych dokumentów finansowych z umową, będącą podstawą ich wystawienia, musi być dostępna w obszarze Zarządzanie płynnością finansową. Wymagalne KG_167 System powinien zapewniać informację o wymaganej dostępności środków pieniężnych na rachunku bankowym na moment planowanego przelewu przed jego zleceniem. Wymagalne KG_168 System powinien umożliwiać prognozowanie płynności finansowej na podstawie transakcji Wymagalne zarejestrowanych w systemie, w tym stanów rachunków bankowych, należności, zobowiązań, zamówień oraz innych planowanych przepływów środków finansowych. KG_169 System powinien umożliwić prognozę płynności finansowej z uwzględnieniem przewidywanych zmian kursów walut dla transakcji walutowych. Wymagalne KG_170 Na potrzeby zarządzania płynnością finansową system musi zapewnić możliwość pozyskiwania wymaganych danych z innych modułów i aplikacji. Wymagalne KG_171 System musi mieć możliwość generowania prognozy płynności finansowej przy zachowaniu następujących wymagań: ‐ szczegółowość: co do dnia, tygodnia, miesiąca, ‐ horyzont czasu: od dnia, przynajmniej do 3 miesięcy, ‐ prowadzona w walutach oryginalnych wpływów i wydatków oraz równolegle w PLN ‐ przeliczenie kwot w walucie po wskazanych kursach (w szczególności średnich NBP), ‐ informacje o planowanym stanie rachunków bieżących i lokat na koniec każdego prognozowanego dnia. ‐ dowolne określenie ram czasowych prognozowania, ‐ prezentacja danych szczegółowych oraz zgrupowanych do dnia.
Wymagalne KG_172 System musi zapewnić zintegrowanie funkcjonalności do planowania płynności z innymi obszarami (modułami) Systemu w taki sposób, aby mógł on pobierać z nich zawarte tam dane o planowanych wpływach i wydatkach, z uwzględnieniem ich wzajemnych powiązań (np. powiązania faktury zakupowej z umową). Wymagalne KG_173 System musi mieć możliwość ręcznego wprowadzania planowanych przepływów innych niż pobierane automatycznie z modułów Systemu, na potrzeby planowania i symulacji płynności finansowej. Wymagalne KG_174 System powinien mieć możliwość ręcznego uzupełniania informacji o przepływach finansowych. Opcjonalne KG_175 W szczególności system musi mieć możliwość wyeksportowania wyników prognozowania płynności finansowej do edytowalnego pliku w formacie MS Excel. Wymagalne Integracja KG_176 System musi integrować się z systemami gromadzącymi dane sprzedażowe stosowanymi w PAŻP (obecnie @RMS w przyszłości planowana jest wymiana systemu) w celu automatycznego przygotowywania dowodów księgowych w ewidencji finansowo‐księgowej. Wymagalne KG_177 System w zakresie obsługi finansowo‐księgowej musi być zintegrowany z systemem, który przechowuje informacje o sprzedaży usług trasowych (przekazywane do EUROCONTROL do zafakturowania) w celu przyspieszenia zaksięgowania przychodów z usług trasowych. Wymagalne Strona 83 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KG_178 System musi zapewnić rejestrowanie wszystkich rodzajów kosztów w sposób umożliwiających jednoznaczne przypisanie ich do poszczególnych produktów. Wymagalne KG_179 System musi zapewnić rejestrację przychodów na poziomie produktów AIS zgodnie z katalogiem produktów. Wymagalne KG_180 System musi wspierać i automatyzować proces parowania operacji na koncie rozliczeniowym z podpowiedziami pochodzącymi z powiązania dokumentów handlowych z dokumentami magazynowymi. Wymagalne KG_181 System musi zapewnić automatyczne wsparcie dla dekretacji i księgowania dokumentów pochodzących z innych modułów (np. z Płac, Środków Trwałych, Gospodarki Magazynowej, Rozrachunków, Podatków, Windykacji, Sprzedaży, Zakupów, itp.). Wymagalne KG_182 System musi zapewniać automatyczne rozliczanie zapisów na kontach rozliczeniowych na podstawie informacji o powiązaniu dokumentów (np. faktury i PZ‐tki). Wymagalne KG_183 Wszystkie etapy rozliczenia pracownika winny być tak zintegrowane, aby pozwoliły kontrolować obieg dokumentów i rozliczenie finansowo‐księgowe oraz aby stwarzały możliwości podglądu, wydrukowania danych niezbędnych do rozliczenia dokumentu od momentu rejestracji (wpływu) do końcowego rozliczenia. Wymagalne KG_184 System musi umożliwiać składanie sprawozdania RF‐01 elektronicznie poprzez platformę internetową GUS. Wymagalne KG_185 System musi umożliwiać składanie sprawozdania F‐01/I‐01 elektronicznie poprzez platformę internetową GUS. Wymagalne KG_186 System musi umożliwiać składanie sprawozdania DNU‐K elektronicznie poprzez platformę internetową GUS. Wymagalne KG_187 System musi umożliwiać składanie sprawozdania F‐02 elektronicznie poprzez platformę internetową GUS. Wymagalne KG_188 System musi umożliwiać składanie sprawozdania F‐03 elektronicznie poprzez platformę internetową GUS. Wymagalne KG_189 System musi umożliwiać składanie sprawozdania G‐01 elektronicznie poprzez platformę internetową GUS. Wymagalne KG_190 System musi umożliwiać składanie sprawozdania T‐02 elektronicznie poprzez platformę internetową GUS. Wymagalne KG_191 System musi umożliwiać składanie sprawozdania H‐01W elektronicznie poprzez platformę internetową GUS. Wymagalne KG_192 System powinien umożliwiać powiązanie operacji kasowych z obsługą delegacji krajowych i zagranicznych Opcjonalne Powiadomienia KG_193 System musi zapewnić generowanie komunikatów (komunikat systemowy, e‐mail, sms) przypominających o terminie płatności faktur (do użytkowników odpowiedzialnych za rozliczenie dokumentu). Wymagalne KG_194 System musi powiadamiać (komunikat systemowy, e‐mail, sms) o zbliżającym się upływie terminu płatności faktury, w przypadku gdy jest ona jeszcze w obiegu.
Wymagalne KG_195 System musi zapewniać możliwość wygenerowania i przesłania informacji mailowej do pracownika z powiadomieniem o zbliżającym się terminie rozliczenia zaliczki lub o nierozliczonej zaliczce. Wymagalne Strona 84 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KG_196 System powinien informować (komunikat systemowy, e‐mail, sms) o wystawionych fakturach zaliczkowych nierozliczonych z fakturami końcowymi. Opcjonalne KG_197 System powinien zapewniać możliwość automatycznego poinformowania (np. mail) pracownika o dokonaniu rozliczenia z jednoczesną informacją o kwocie do wypłaty lub wpłaty. Opcjonalne Raportowanie KG_198 System musi umożliwiać sporządzanie raportów wg wymagań użytkownika. Raporty muszą bazować na predefiniowanych schematach danych. Wymagalne KG_199 System musi umożliwiać generowanie raportów (wszystkich) z księgi głównej i ksiąg pomocniczych uwzględniających możliwość włączenia lub wyłączenia transakcji niezatwierdzonych ("w buforze"). Wymagalne KG_200 System musi mieć możliwość zdefiniowania sprawozdania w oparciu o salda oraz obroty okresu i obroty narastająco od początku roku dla wskazanych kont księgowych. Wymagalne KG_201 System musi zapewnić generowanie standardowych raportów i sprawozdań wymaganych przepisami prawa. W tym zestawienie obrotów i sald. Wymagalne KG_202 System musi zapewnić generowanie standardowych raportów i sprawozdań wymaganych przepisami prawa. W tym księgowania na kontach. Wymagalne KG_203 System musi zapewnić generowanie standardowych raportów i sprawozdań wymaganych przepisami prawa. W tym dzienniki księgowe. Wymagalne KG_204 System musi zapewnić generowanie standardowych raportów i sprawozdań wymaganych przepisami prawa. W tym karta kontowa. Wymagalne KG_205 System musi zapewnić generowanie standardowych raportów i sprawozdań wymaganych przepisami prawa. W tym bilans Wymagalne KG_206 System musi zapewnić generowanie standardowych raportów i sprawozdań wymaganych przepisami prawa. W tym rachunek wyników. Wymagalne KG_207 System musi zapewnić generowanie standardowych raportów i sprawozdań wymaganych przepisami prawa. W tym rachunek przepływów pieniężnych. Wymagalne KG_208 System musi zapewnić generowanie standardowych raportów i sprawozdań wymaganych przepisami prawa. W tym zmiany w kapitale własnym. Wymagalne KG_209 System musi zapewnić generowanie standardowych raportów i sprawozdań wymaganych przepisami prawa. W tym raport inwentaryzacji ksiąg. Wymagalne KG_210 System musi zapewnić przygotowanie sprawozdania z przepływów pieniężnych metodą bezpośrednią. Wymagalne KG_211 System musi zapewnić przygotowanie sprawozdania z przepływów pieniężnych metodą pośrednią. Wymagalne KG_212 System musi umożliwiać sporządzanie raportów w oparciu o gotowe zestawienia, które umożliwią w łatwy sposób wybranie informacji potrzebnych do zrealizowania sprawozdań lub przygotowanie gotowych sprawozdań budżetowych, związanych z ustawą o finansach publicznych.
Wymagalne KG_213 System musi umożliwiać sporządzanie raportów w oparciu o gotowe zestawienia, które umożliwią w łatwy sposób wybranie informacji potrzebnych do zrealizowania sprawozdań lub przygotowanie gotowych sprawozdań statystycznych na potrzeby GUS. Wymagalne KG_214 System musi umożliwiać sporządzanie raportów w oparciu o gotowe zestawienia, które umożliwią w łatwy sposób wybranie informacji potrzebnych do zrealizowania sprawozdań lub przygotowanie gotowych sprawozdań na potrzeby innych zewnętrznych podmiotów. Wymagalne KG_215 System musi umożliwiać sporządzanie raportów w oparciu o gotowe zestawienia, które umożliwią w łatwy sposób wybranie informacji potrzebnych do zrealizowania sprawozdań lub przygotowanie gotowych sprawozdań finansowych, wynikających z ustawy o rachunkowości oraz innych przepisów Wymagalne Strona 85 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
dotyczących rachunkowości w PAŻP. KG_216 System musi zapewniać raportowanie rozliczonych i nierozliczonych zapisów na danym koncie księgowym (np. na koncie rozliczenia zakupów). Wymagalne KG_217 System musi udostępnić raport pokazującego strukturę wiekową należności (z dokładnością do dokumentów i kontrahenta). Wymagalne KG_218 System musi mieć możliwość generowania raportu, który pokaże strukturę wiekową należności i zobowiązań, umożliwiającego dowolny podział czasookresów wiekowania oddzielnie dla należności / zobowiązań zapadłych (po terminie) i przyszłych, w szczególności możliwość generowania raportu, który pokaże strukturę wiekową kredytów inwestycyjnych. Wymagalne KG_219 System musi mieć możliwość stworzenia automatycznego raportu z wykonania Cash Flow (w odniesieniu do planów) metodą bezpośrednią. Wymagalne KG_220 System musi mieć możliwość stworzenia automatycznego raportu z wykonania Cash Flow (w odniesieniu do planów) metodą pośrednią. Wymagalne KG_221 System musi mieć możliwość stworzenia automatycznej prognozy Cash Flow (w oparciu o plany) metodą bezpośrednią. Wymagalne KG_222 System musi mieć możliwość stworzenia automatycznej prognozy Cash Flow (w oparciu o plany) Wymagalne KG_223 System powinien udostępnić możliwość pokazania kwot netto dokumentów z rejestru po kursie księgowym w celu oszacowania różnic między wyceną kwot dokumentów po kursie NBP‐1 (wycena dla PDOP) i po kursie Reuters (wycena dla VAT). Opcjonalne KG_224 System powinien umożliwiać konstruowanie szablonu sprawozdań finansowych w formacie MS Word z automatycznym wypełnianiem tabel z kwotami. Opcjonalne KG_225 System musi wykazywać niezapłacone dokumenty zewnętrzne (w tym określone dla zadanego okresu czasu, przeterminowane na zadany dzień i na więcej niż zadana ilość dni).
Wymagalne KG_226 System musi zapewnić możliwość modyfikacji szablonów deklaracji i sprawozdań w związku ze zmianami przepisów i uregulowań zewnętrznych z możliwością oddrukowania historycznych sprawozdań i deklaracji na szablonie obowiązującym w momencie ich tworzenia.
Wymagalne KG_227 System musi generować zestawienie wystawionych faktur zaliczkowych nierozliczonych z fakturami końcowymi. Wymagalne KG_228 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS, w tym DG‐1. Wymagalne KG_229 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS, w tym DNU‐K. Wymagalne KG_230 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS, w tym F‐01. Wymagalne KG_231 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS, w tym F‐02. Wymagalne KG_232 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS, w tym F‐03. Wymagalne KG_233 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS, w tym RF‐01. Wymagalne KG_234 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS, w tym G‐01. Wymagalne KG_235 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS, w tym H‐01W. Wymagalne KG_236 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS, w tym PU. Wymagalne KG_237 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS, w tym T‐02. Wymagalne KG_238 System musi zapewnić sporządzanie raportów na potrzeby sprawozdawczości GUS. Wymagalne KG_239 Dla następujących sprawozdań system powinien posiadać skonfigurowane raporty zgodne z obowiązującym wzorem: Wymagalne Strona 86 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐ Statystyczne sprawozdanie o aktywach i pasywach finansowych (RF‐01), ‐ Sprawozdanie o międzynarodowej wymianie usług (DNU‐K), ‐ Sprawozdanie o przychodach, kosztach i wyniku finansowym oraz o nakładach na środki trwałe (F‐01/I‐01), ‐ Statystyczne sprawozdanie finansowe sporządzone na dzień 31.12…. r. (F‐02), ‐ Sprawozdanie o stanie i ruchu środków trwałych (F‐03), ‐ Sprawozdanie o zużyciu i zapasach wybranych materiałów (G‐01), ‐ Sprawozdanie o usługach w transporcie i łączności (T‐02), ‐ Sprawozdanie o sieci handlowej (H‐01W). KG_240 Dla następujących sprawozdań system musi umożliwiać przygotowanie danych do sprawozdań skonfigurowanych w sposób umożliwiający ich wypełnienie zgodnie z obowiązującym wzorem: ‐ Statystyczne sprawozdanie o aktywach i pasywach finansowych (RF‐01), ‐ Sprawozdanie o międzynarodowej wymianie usług (DNU‐K), ‐ Sprawozdanie o przychodach, kosztach i wyniku finansowym oraz o nakładach na środki trwałe (F‐01/I‐01), ‐ Statystyczne sprawozdanie finansowe sporządzone na dzień 31.12…. r. (F‐02), ‐ Sprawozdanie o stanie i ruchu środków trwałych (F‐03), ‐ Sprawozdanie o zużyciu i zapasach wybranych materiałów (G‐01), ‐ Sprawozdanie o usługach w transporcie i łączności (T‐02), ‐ Sprawozdanie o sieci handlowej (H‐01W).
Wymagalne KG_241 System musi wspierać sporządzanie raportów na potrzeby sprawozdawczości resortowej w tym w szczególności: ‐ Rb‐Z, ‐ Rb‐N, ‐ Rb‐UN, ‐ Rb‐UZ. Wymagalne KG_242 Sprawozdania na potrzeby sprawozdawczości resortowej muszą być generowane i składane w formie pliku Excel aktualizowanego co kwartał na stronie ministerstwa, e‐mail oraz wersji papierowej. Wymagalne KG_243 System musi wspierać sporządzanie raportów na potrzeby innej zewnętrznej sprawozdawczości np. do NBP, PZ‐KRH, PZ‐POZ, AZ‐KRH. Zakłada się, że zestawienia zostaną skonfigurowane przez Zamawiającego za pomocą dostarczonych razem z Systemem narzędzi umożliwiających konfigurowanie zestawień. Wymagalne KG_244 System musi zapewniać sporządzanie sprawozdania finansowego wg MSR w układzie miesięcznym i rocznym (sprawozdanie z całkowitych dochodów, sprawozdanie z sytuacji finansowej (aktywa, pasywa), zestawienie zmian w kapitale własnym, sprawozdanie z przepływów pieniężnych) zarówno w wariancie porównawczym jak i w wariancie kalkulacyjnym. Wymagalne KG_245 System musi dostarczać i raportować dane w układzie ustawy budżetowej. Zakłada się, że zestawienia zostaną skonfigurowane przez Zamawiającego za pomocą dostarczonych razem z Systemem narzędzi umożliwiających konfigurowanie zestawień i raportów według w/w kategorii i innych na potrzeby własne, kontroli, itp. . Wymagalne KG_246 System musi zapewniać możliwość raportowania w różnych przekrojach danych dotyczących rozliczenia pracownika (np.: wg pracowników, symbolu komórki organizacyjnej, daty rozliczenia, daty wpływu dokumentu, rodzaju płatności itp.) Zakłada się, że zestawienia zostaną skonfigurowane przez Zamawiającego za pomocą dostarczonych przez Dostawcę razem z Systemem odpowiednich narzędzi umożliwiających Zamawiającemu konfigurowanie zestawień. Wymagalne KG_247 System musi generować raport pokazujący wysłane do banku, a niezrealizowane przelewy. Wymagalne KG_248 System musi generować raport pokazujący przygotowane, ale niewysłane do banku przelewy. Wymagalne Strona 87 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KG_249 System musi zapewnić, aby płatności, dla których wygenerowano przelewy niezrealizowane przez bank były w systemie raportowane jako nierozliczone. Wymagalne KG_250 System musi zapewnić raport rzeczywistych kosztów infrastruktury i usług telekomunikacyjnych tworzony na podstawie dokumentów zaksięgowanych z informacją analityczną wymaganą przez zakładowy plan kont. Funkcja ta musi umożliwić kontrolę zarówno kosztów ponoszonych przez komórki, ale również przez inne procesy, których koszty są związane z danym urządzeniem. Zakłada się, że zestawienia zostaną skonfigurowane przez Zamawiającego za pomocą dostarczonych razem z Systemem narzędzi umożliwiających konfigurowanie zestawień. Wymagalne KG_251 System musi zapewnić raport rzeczywistych kosztów zużycia energii elektrycznej tworzony na podstawie dokumentów zaksięgowanych z informacją analityczną wymaganą przez zakładowy plan kont. Opcja wymaga rejestracji bezpośredniej według wskazań licznika, lub pośrednio alokowanych w ramach procedur księgowej kalkulacji doliczeniowej. Raportowanie zapewnia możliwość planowania, budżetowania, a także sprawozdawczość wymaganą przez procesy związane z ochroną środowiska. Zakłada się, że zestawienia zostaną skonfigurowane przez Zamawiającego za pomocą dostarczonych razem z Systemem narzędzi umożliwiających konfigurowanie zestawień. Wymagalne KG_252 System musi zapewnić raportowanie kosztów paliwa oparte o informację zaksięgowaną analitycznie w systemie ERP. Zakłada się, że zestawienia zostaną skonfigurowane przez Zamawiającego za pomocą dostarczonych razem z Systemem narzędzi umożliwiających konfigurowanie zestawień. Wymagalne KG_253 System musi zapewnić miesięczny raport kosztów floty samochodowej. Zakłada się, że zestawienia zostaną skonfigurowane przez Zamawiającego za pomocą dostarczonych razem z Systemem narzędzi umożliwiających konfigurowanie zestawień. Wymagalne KG_254 System musi zapewnić informację o kosztach (z podziałem na kategorie) w powiązaniu ze zrealizowanymi zadaniami remontowymi i inwestycyjnymi. Zakłada się, że zestawienia zostaną skonfigurowane przez Zamawiającego za pomocą dostarczonych razem z Systemem narzędzi umożliwiających konfigurowanie zestawień. Wymagalne KG_255 System musi zapewniać możliwość przeliczenia sprawozdań finansowych na inną walutę po z góry podanym kursie waluty. Wymagalne KG_256 W ramach automatyzacji generacji danych w raportach sporządzanych na potrzeby sprawozdawczości GUS, sprawozdawczości resortowej, sprawozdania finansowego wg MSR, deklaracji podatkowej CIT‐8 system musi zapewnić: ‐ możliwość zdefiniowania struktur pól (źródeł danych) odpowiadających polom w raportach sporządzanych na potrzeby sprawozdawczości, ‐ możliwość zdefiniowania przypisań tych pól do kont oraz predefiniowanych algorytmów (np. saldo, obroty wn), ‐ automatyczna generacja danych do zdefiniowanych pól, ‐ możliwość analizy tak uzyskanych danych metodą od ogółu do szczegółu (drill‐down). Wymagalne Obieg dokumentów KG_257 System musi zapewnić obieg zewnętrznych dokumentów finansowych z wykorzystaniem zintegrowanego komponentu EOD lub za pomocą obiegu wbudowanego zapewniającego równoważną funkcjonalność, lub połączonego wykorzystania zaimplementowanych komponentów. Wymagalne KG_258 W ramach obiegu zewnętrznych dokumentów finansowych systemu musi zapewnić wsparcie dla następujących funkcjonalności: rejestracja dokumentu musi być możliwa w kancelarii oraz sekretariatach przez osoby nieposiadające wiedzy księgowej. Wymagalne KG_259 W ramach obiegu zewnętrznych dokumentów finansowych system musi zapewnić wsparcie dla następujących funkcjonalności: w zależności od rodzaju, kwoty, kontrahenta, terminu płatności, powiązania ze zleceniem zakupu lub WOUZ system musi pozwalać na zdefiniowanie alternatywnych Wymagalne Strona 88 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ścieżki obiegu dokumentu. KG_260 W ramach obiegu zewnętrznych dokumentów finansowych systemu musi zapewnić wsparcie dla następujących funkcjonalności: system musi wspierać monitorowanie terminu płatności dokumentu. Wymagalne KG_261 W ramach obiegu zewnętrznych dokumentów finansowych systemu musi zapewnić wsparcie dla następujących funkcjonalności: system musi zapewniać powiązanie dokumentu z zadaniem inwestycyjnym, projektem, umową, zleceniem zakupu, WOUZ, itp. Wymagalne KG_262 W ramach obiegu zewnętrznych dokumentów finansowych systemu musi zapewnić wsparcie dla następujących funkcjonalności: system musi umożliwić dekretację (opis) kosztową i merytoryczną dokumentu dokonywaną etapowo przez wielu uczestników obiegu z wykorzystaniem danych słownikowych. Wymagalne KG_263 W ramach obiegu zewnętrznych dokumentów finansowych systemu musi zapewnić wsparcie dla następujących funkcjonalności: system musi umożliwiać zdefiniowanie uprawnień do wglądu i modyfikacji informacji dotyczącej dokumentu w trakcie obiegu. Wymagalne KG_264 W ramach zdefiniowanych uprawnień systemu musi zapewnić wgląd w rejestr faktur poszczególnym jednostkom wraz z informacją dotyczącą rozliczenia dokumentu. Wymagalne KG_265 W ramach obiegu zewnętrznych dokumentów finansowych system musi zapewnić wsparcie dla następujących funkcjonalności: system musi zapewnić automatyczny transfer informacji powiązanej z dokumentem na etapie obiegu do systemu finansowo‐księgowego w sposób umożliwiający jej wykorzystanie przy rozliczaniu dokumentu, dekretacji dokumentu, rozliczaniu podatku VAT, itp. Wymagalne KG_266 W ramach obiegu System musi zapewnić wsparcie dla procesu monitorowania budżetu. Wymagalne KG_267 System powinien posiadać wbudowany obieg dla przygotowania sprawozdań i zestawień księgowych, finansowych, statystycznych lub wykorzystywać funkcjonalność komponentu EOD w zakresie automatyzacji przygotowania sprawozdań i zestawień. Opcjonalne Rozrachunki Wymagania ogólne ROZ_001 System musi zapewniać obsługę rozliczeń z tytułu rozrachunków z kontrahentami oraz pracownikami. Wymagalne ROZ_002 System musi automatyzować obsługę przypadku, kiedy z dokumentu powstaje rozrachunek na podmiot, który nie jest wystawcą dokumentu. Wymagalne ROZ_003 Wymagana jest możliwość wprowadzania dokumentów na wystawcę z możliwością rozliczenia zapłaty z innym podmiotem lub pracownikiem. System musi mieć możliwość zarejestrowania dokumentu w taki sposób, aby zapisana była na nim informacja odpowiednia dla rejestru VAT (np. siedziba centrali klienta) jak też dla otwarcia rozrachunku (np. oddział sprzedawcy lub pracownik) z możliwością dokonania rozliczenia zapłaty z innym podmiotem lub pracownikiem. Wymagalne ROZ_004 System musi zapewniać automatyczne łączenie wpłat i wypłat z rozliczanymi dokumentami. Wymagalne ROZ_005 System musi zapewniać automatyczne rozliczanie zapisów na takich samych kontach księgowych. Wymagalne ROZ_006 System musi umożliwić automatyczne powiązanie wpłat z fakturami sprzedaży z możliwością tworzenia na koncie klienta nadpłat oraz tworzenia nadpłat niezidentyfikowanych. Wymagalne ROZ_007 System musi zapewnić automatyczne powiązanie wpłat z fakturami sprzedaży na podstawie opisu wpłaty (zawierającego numer należności) z możliwością wybrania czy rozliczać tylko w przypadku rozliczenia całej kwoty czy również w przypadku rozliczenia częściowego.
Wymagalne ROZ_008 System musi umożliwiać również tworzenie nadpłaty na koncie klienta lub nadpłaty bez użycia nazwy klienta. Wymagalne Strona 89 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ROZ_009 System musi zapewnić rozliczanie rozrachunków gotówkowych (kasa) jak i bezgotówkowych (bank, kompensaty, cesje). Wymagalne ROZ_010 System musi obsługiwać kompensatę należności ze zobowiązaniami zarówno od strony należności jak i zobowiązań. Wymagalne ROZ_011 System musi obsługiwać kompensatę należności ze zobowiązaniami również wtedy, gdy są one wyrażone w różnych walutach. Wymagalne ROZ_012 System musi umożliwić rozliczania faktur z udzielonymi przedpłatami oraz korektami. Wymagalne ROZ_013 System musi zapewnić możliwość wprowadzenia faktury jednocześnie do ewidencji rozrachunków z pracownikami jak i z kontrahentami. Wymagalne ROZ_014 System musi zapewniać automatyczne przeksięgowanie należności spornej na konto należności wymagalnych w momencie parowania dokumentu należności z wpłatą za nią. Wymagalne ROZ_015 System musi mieć możliwość rejestracji w systemie zgody na kompensatę z kontrahentem. Wymagalne ROZ_016 System musi zapewnić generowanie potwierdzenia sald dla kontrahenta lub grupy kontrahentów na zadany dzień. Wymagalne ROZ_017 System musi umożliwiać tworzenie automatycznego powiadomienia wskazanej osoby o wprowadzeniu przedpłaty. Wymagalne Kartoteki kontrahentów ROZ_018 System powinien zapewniać informację o cenach i upustach dla towarów oferowanych przez dostawcę. Wymagalne ROZ_019 System powinien umożliwiać blokadę dostawcy znajdującego się w stanie upadłości. Wymagalne ROZ_020 System powinien przechowywać dane adresowe dostawcy. Wymagalne ROZ_021 System powinien informować o kraju dostawcy. Wymagalne ROZ_022 System powinien przechowywać numer rachunku bankowego do zapłat. Dla każdej waluty osoby numer. Wymagalne ROZ_023 System powinien informować o języku korespondencji z dostawcą. Wymagalne ROZ_024 System powinien umożliwiać przegląd umów zawartych z dostawcą. Wymagalne ROZ_025 System musi zapewnić formularz zawierający ustalony zakres pól dotyczących danych odbiorców wewnętrznych (komórka organizacyjna PAŻP wraz z osobą kontaktową) z możliwością dodawania nowych pól przez administratora włączając pola w rejestrach powiązanych, a także walidacja prowadzanych danych. Wymagalne ROZ_026 System musi zapewnić manualną rejestrację odbiorcy wewnętrznego na odpowiednim formularzu i automatyczne sprawdzenie czy klient jest w bazie odbiorców wewnętrznych, a także na tej podstawie automatyczną aktualizację danych lub dodanie nowego rekordu (niedopuszczenie pojawienia się duplikatów). Wymagalne Rozliczenia w kasie
ROZ_027 System musi zapewniać automatyczne rozliczanie operacji kasowych z dokumentami, za które jest operacja (w tym również rozliczenie z dokumentami płatniczymi, innymi typami dokumentów rozliczających wydatek oraz z dokumentami wpłaty (np. podpinanie pod dokument kasowy dokumentów rozliczeniowych pracownika)). Wymagalne ROZ_028 Przy wpłacie przez jedną osobę jednocześnie wielu pozycji w kasie system musi automatycznie wyliczać sumę kwoty do wpłaty lub wypłaty. Wymagalne ROZ_029 System musi zapewniać automatyczne wyliczanie kwoty do wypłaty lub do wpłaty wynikającej z rozliczenia dokumentów pracownika przy rozliczaniu gotówką rozrachunków pracownika. Wymagalne Strona 90 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ROZ_030 System powinien mieć możliwość wygenerowania dokumentu (dokumentów) rozliczenia w kasie na podstawie zarejestrowanych należności i zobowiązań pojedynczo i zbiorczo. Wymagalne ROZ_031 System musi mieć możliwość wydruku raportów kasowych i dokumentu "do wypłaty" i "do wpłaty" Wymagalne ROZ_032 System musi zapewnić możliwość powiązania dokumentów rozliczeniowych z dokumentem wypłaty lub wpłaty oraz automatycznego przekazania informacji do kasy o rozliczeniu pracownika tj. zestawienie dokumentów wypłaty i wpłaty (kompensowanie). Wymagalne ROZ_033 System musi zapewniać automatyczne wybieranie wypłaconej zaliczki przy rozliczaniu. Wymagalne Rozliczenia w banku ROZ_034 System musi zapewniać możliwość automatycznego rozliczania linii wyciągu bankowego z dokumentami płatniczymi. Wymagalne ROZ_035 System dla płatności za dokumenty obce musi automatycznie identyfikować zobowiązania do rozliczenia, które były opłacone dyspozycją przelewu. Wymagalne ROZ_036 System powinien zapewnić automatyczną obsługę wpłat dokonywanych kartami płatniczymi w przypadku pomniejszenia kwoty wpłaty o prowizję operatora. System powinien umożliwiać rozliczenie (sparowanie) takiej pozycji wyciągu bankowego z należnością ze skutkiem w postaci pełnego rozliczenia należnej kwoty oraz automatycznego wygenerowania zapisu obciążającego określone konto kosztowe kwotą różnicy. Opcjonalne ROZ_037 System musi zapewnić poprawną obsługę wpłat dokonywanych kartami płatniczymi w przypadku pomniejszenia kwoty wpłaty o prowizję operatora. Wymagalne ROZ_038 System musi zapewniać możliwość korygowania płatności z utworzonej partii przelewów przed wygenerowaniem pliku wsadowego do systemu bankowego. Wymagalne Rozliczanie delegacji i zaliczek ROZ_039 W kasie musi być zapewniona obsługa rozliczeń zaliczek pobranych przez pracownika. Wymagalne ROZ_040 System musi zapewniać rozliczenie zaliczek bieżących oraz delegacji krajowych i zagranicznych. Wymagalne ROZ_041 System musi automatyzować proces rozliczania zaliczek bieżących oraz delegacji zagranicznych według różnych kursów walut (zgodnie z przepisami) Wymagalne ROZ_042 Wpłaty i wypłaty związane z rozliczeniem zaliczek bieżących oraz delegacji muszą być realizowane zarówno w kasie jak i za pomocą przelewu bankowego. Wymagalne ROZ_043 System musi zapewniać możliwość wysyłania powiadomienia do pracownika o zakończeniu rozliczenia. Wymagalne ROZ_044 System musi zapewnić możliwość rozliczania zaliczek pobranych przez pracowników z dokumentami w walutach innych niż waluta pobranej zaliczki (może to być wiele walut). Wymagalne ROZ_045 System musi zapewnić rozliczenie dokumentów z pracownikami, których płatność dokonywana jest przy użyciu służbowych kart płatniczych. Wymagalne Rozliczenia walutowe ROZ_046 System musi zapewniać rozliczanie rozrachunków w różnych walutach (w tym również rozrachunków pracowniczych). Wymagalne ROZ_047 System musi automatycznie wyliczać, rozliczać i księgować zrealizowane różnice kursowe (dodatnie i ujemne). Wymagalne ROZ_048 System musi zapewniać automatyczne wyliczanie i rozliczanie różnic kursowych pomiędzy przeliczoną wartością faktury a przeliczoną wartością płatności z uwzględnieniem, czy różnice mają być rozliczane z wartością netto czy brutto faktury. Wymagalne Strona 91 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ROZ_049 System powinien zapewniać możliwość odwracalnego przeszacowywania rozrachunków na poszczególnych dokumentach księgowych lub sald kont księgowych według wskazanego typu kursu waluty. Wymagalne ROZ_050 System musi zapewniać wycenianie nierozliczonych rozrachunków wyrażonych w walutach obcych. Wymagalne ROZ_051 Faktura, której kwota netto wyrażona jest w walucie obcej, powinna być zaewidencjonowana w systemie w taki sposób, który umożliwi wycenę statystycznych różnic kursowych na koniec okresu wyłącznie od kwoty netto. Kwota VAT‐u powinna być pominięta z powodu tego, iż jest wyrażona wyłącznie w walucie krajowej. Wymagalne ROZ_052 System musi mieć możliwość zastosowania różnych kursów walut do rozliczania delegacji zagranicznych i innych dokumentów z tytułu rozliczeń z pracownikami. Wymagalne ROZ_053 System musi umożliwiać rozliczenie transakcji walutowej przy pomocy waluty innej niż waluta transakcji. Wymagalne Kontrola budżetu ROZ_054 System musi posiadać możliwość powiązania z pozycjami planu dokumentów rozliczeniowych związanych z dokonanym zakupem. Taka struktura powiązań jest niezbędna w celu zapewnienia kontroli przekroczenia planu. Wymagalne ROZ_055 System musi zabezpieczać przed przekroczeniem planu w poszczególnych liniach budżetowych kosztów operacyjnych w skali roku bieżącego lub kolejnych lat w których zakup ma być realizowany. Wymagalne ROZ_056 Każdy dokument rozliczający zakup poprzedzony musi być WOUZ lub zamówieniem zweryfikowanym z budżetem i posiadać ścisłe z nim powiązanie i pełną zgodność w każdym zakresie (elemencie segmentu linii planistycznej i czasu). Wymagalne ROZ_057 System musi zapewniać odpowiednią obsługę w przypadku, kiedy zakup nie jest zgodny ze zweryfikowanym WOUZ, tak aby nie dopuścić do przekroczenia planu. Wymagalne ROZ_058 Przekroczenie wartości wykonanych nad wartościami planowanymi musi być zablokowane. Wymagalne ROZ_059 W przypadku wystawiania zamówienia (WOUZ), kontrola przekroczenia budżetu powinna odbywać się na etapie zatwierdzania zamówienia (WOUZ). System powinien zablokować próbę zatwierdzenia zamówienia (WOUZ) w przypadku, gdy na powiązanym z zamówieniem MPK lub rodzajem kosztu, wykazane zostanie przekroczenie planu. Wymagalne ROZ_060 System powinien umożliwić ręczne odblokowanie transakcji przekraczającej budżet w uzasadnionym przypadku przez autoryzowaną osobę do tego uprawnioną.
Wymagalne Raportowanie ROZ_061 System musi generować raport prezentujący stan rozrachunków w walucie księgowej na dany dzień. Wymagalne
ROZ_062 System musi generować raport prezentujący stan rozrachunków w walucie rozrachunku i walucie księgowej na dany dzień. Wymagalne ROZ_063 System musi generować raport struktury wiekowej rozrachunków w sposób pozwalający na zadawanie co najmniej czterech przedziałów wiekowania. Wymagalne ROZ_064 System musi generować raport prezentujący rozrachunki i ich rozliczenie w różnych układach: ‐ według kontrahenta, ‐ według grupy kontrahentów, ‐ według daty wymagalności, ‐ według sposobu zapłaty, ‐ według konta księgowego, ‐ według umowy. Wymagalne ROZ_065 System musi generować raport analiza płatności. Wymagalne Strona 92 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ROZ_066 System musi generować raport przewidywane przychody i wydatki na podstawie zarejestrowanych rozrachunków. Wymagalne ROZ_067 System musi generować zestawienie największych dłużników. Wymagalne ROZ_068 System musi generować raporty z różnym poziomem szczegółowości: ‐ syntetycznie (bez wyszczególnienia szczegółowego rozrachunków i rozliczeń), ‐ analitycznie (z wyszczególnienie wszystkich rozrachunków i rozliczeń). Wymagalne ROZ_069 System dla wszystkich raportów musi mieć możliwość szczegółowego parametryzowania raportów w tym w szczególności: ‐ wskazania okresu sprawozdawczego (konkretny okres, wszystkie okresy), ‐ wskazania typu rozrachunków (należności, zobowiązania, wszystkie), ‐ uwzględniania statusu płatności (rozliczone, nierozliczone, wszystkie), ‐ kontrahent/pracownik (konkretny kontrahent/pracownik, wszyscy), ‐ grupa kontrahentów (konkretna grupa, wszyscy), ‐ okres według różnych dat (wymagalności, zapłaty, wystawienia, zaksięgowania, rozliczenia), ‐ umowa (konkretna, wszystkie), ‐ masa numeru dokumentu (maska numeru, wszystkie). Wymagalne Podatki Wymagania ogólne POD_001 System musi zapewniać obsługę podatków, których płatnikiem jest Agencja, zgodnie z przepisami prawa. Wymaga się, aby funkcjonalność systemu umożliwiała w przypadku zmiany przepisów prawa dostosowanie konfiguracji do nowych przepisów. Wymagalne POD_002 System powinien zapewniać wydruk deklaracji podatkowych na definiowalnym szablonie. Opcjonalne POD_003 System musi zapewniać ewidencję danych w sposób umożliwiający rozliczenie podatku i złożenie wymaganych prawem deklaracji. Wymagalne POD_004 System musi mieć słownik kodów podatkowych (lub równoważną funkcjonalność) umożliwiający automatyczne i prawidłowe ujęcie dokumentów w rejestrach podatkowych oraz deklaracjach podatkowy. Wymagalne Podatek VAT POD_005 System musi zapewniać ewidencję i rozliczanie podatku VAT.
Wymagalne
POD_006 System musi zapewnić tworzenie rejestrów zakupu i sprzedaży VAT wg wskazanego układu (dostępne układy rejestru zakupu i sprzedaży VAT powinny umożliwiać sprawne ich uzgodnienie z utworzonymi na ich podstawie deklaracjami). Wymagalne POD_007 System musi zapewniać możliwość automatyczne generowania rejestrów zakupów w układzie wynikającym z deklaracji VAT i VAT UE. Wymagalne POD_008 System musi zapewniać możliwość generowania rejestrów VAT w układzie pozwalającym na identyfikację transakcji dotyczących okresu bieżącego, wprowadzonych w bieżącym okresie dokumentów dotyczących okresów wcześniejszych jak i okresów przyszłych. Wymagalne POD_009 System musi zapewniać możliwość eksportu rejestrów VAT w formacie MS EXCEL (w tym eksport w postaci umożliwiającej dalsze opracowywanie go w arkuszu kalkulacyjnym). Wymagalne POD_010 System musi zapewnić wysłanie deklaracji VAT (wraz z załącznikami) do Urzędu Skarbowego w postaci elektronicznej. Wymagalne POD_011 System musi umożliwić przypisania faktur jednocześnie do rejestrów zakupu i sprzedaży w sposób zapewniający ich poprawne ujęcie na kontach księgowych oraz na wydrukach rejestrów. Wymagalne POD_012 System musi zapewniać możliwość obsługi faktur zbiorczych VAT w taki sposób, aby było możliwe Wymagalne Strona 93 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
utworzenie deklaracji VAT‐UE (obecnie PAŻP wystawia za usługi trasowe jedną fakturę zbiorczą wewnętrzną za cały miesiąc). POD_013 System musi zapewnić wersjonowanie rejestru zakupów VAT i rejestru sprzedaży VAT. Wymagalne POD_014 Każda korekta deklaracji VAT musi być sporządzona na podstawie nowej wersji rejestru zakupów lub sprzedaży VAT. Wymagalne POD_015 System musi zapewniać możliwość zamknięcia wstępnego i ostatecznego rejestrów VAT za dany okres. Wymagalne POD_016 System musi zapewniać możliwość ustalenia konta księgowego (kont księgowych) do dekretacji VAT. Wymagalne POD_017 System musi zapewniać możliwość dodawania nowych stawek VAT i eliminacji (archiwizacji) niepotrzebnych z listy aktualnych. Wymagalne POD_018 System musi zapewniać możliwość uwzględnienia na deklaracji wszystkich stawek VAT, które dotyczą dokumentów okresu (mogą się różnić od obowiązujących w okresie np. w użytkowaniu wieczystym lub duplikatach). Wymagalne POD_019 System musi rejestrować informację o posiadaniu certyfikatu rezydencji w celu automatycznego określenia sytuacji, w której konieczne jest zareagowanie odnośnie pobrania podatku dochodowego u źródła. Wymagalne POD_020 System musi umożliwiać korygowanie deklaracji VAT o faktury niezapłacone w terminie nakazanym ustawą i umożliwiać wydruk rejestru z uwzględnionych w korekcie faktur według określonego wzoru. Wymagalne Pozostałe podatki POD_021 System musi zapewniać szczegółowość zapisów księgowych w sposób umożliwiający rozliczenie podatku dochodowego. Wymagalne POD_022 System dla podatku od nieruchomości, rolnego i leśnego musi zapewniać szczegółową ewidencję księgową oraz ewidencję przedmiotów opodatkowania w powiązaniu z modułem Środków Trwałych oraz Ewidencji Nieruchomości w sposób umożliwiający rozliczenie tego podatku.
Wymagalne POD_023 System dla podatku od środków transportu musi zapewniać szczegółową ewidencję księgową oraz ewidencję przedmiotów opodatkowania w powiązaniu z modułem Środków Trwałych oraz Ewidencji Samochodów w sposób umożliwiający rozliczanie tego podatku.
Wymagalne POD_024 System powinien mieć możliwość składania deklaracji (wraz z załącznikami) podatków lokalnych w sposób elektroniczny o ile organ podatkowy udostępnia taką możliwość. Opcjonalne POD_025 System powinien mieć możliwość składania deklaracji (wraz z załącznikami) podatku PIT do urzędów skarbowych w sposób elektroniczny. Opcjonalne POD_026 System powinien mieć możliwość składania deklaracji (wraz z załącznikami) podatku CIT do urzędów skarbowych w sposób elektroniczny. Opcjonalne Raportowanie POD_027 System musi mieć możliwość definiowania szablonów wydruku deklaracji podatkowych. Wymagalne
POD_028 System powinien mieć możliwość wersjonowania deklaracji podatkowych w sposób umożliwiający automatyczne drukowanie deklaracji na wzorze obowiązującym dla okresu, którego dotyczy deklaracja. Opcjonalne POD_029 System musi mieć możliwość wersjonowania deklaracji podatkowych w sposób umożliwiający wybór przez użytkownika wersji obowiązującej w okresie, którego dotyczy deklaracja. Wymagalne POD_030 System musi zapewnić wydruk deklaracji i informacji VAT oraz ich korekt na obowiązującym szablonie. Wymagalne POD_031 System musi udostępnić raport pokazujący różnice w dokumentach między poszczególnymi wersjami w ramach rejestru zakupów VAT i w ramach rejestru sprzedaży VAT. To znaczy, żeby na wydruku Wymagalne Strona 94 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
kolejnego rejestru dokumenty, które weszły do niego po dacie złożenia pierwotnej deklaracji zgrupowane były w jednym miejscu np. na końcu rejestru lub na początku. POD_032 System musi umożliwiać udostępnianie raportu pokazującego w kontekście dokumentów z zadanego miesiąca, informację, w którym rejestrze VAT i w której jego wersji został dokument uwzględniony. Wymagalne POD_033 System musi sporządzać zestawienie w układzie deklaracji CIT‐8 wg ustawy o PDOP. Wymagalne POD_034 System musi zapewnić wydruk deklaracji CIT‐8. Wymagalne POD_035 System musi zapewnić wydruk deklaracji CIT‐8/O. Wymagalne POD_036 System musi zapewnić wydruk deklaracji CIT‐ST. Wymagalne POD_037 System musi zapewnić wydruk deklaracji CIT‐ST/A. Wymagalne POD_038 System musi zapewnić wydruk deklaracji IFT‐2R. Wymagalne POD_039 System powinien zapewnić wydruk deklaracji dla podatków i opłat lokalnych. Opcjonalne POD_040 System musi zapewnić zestawienia umożliwiające przygotowanie wymaganych przepisami prawa deklaracji podatkowych i deklaracji korygujących. Wymagalne POD_041 Deklaracje podatkowe generowane z systemu muszą być drukowane w sposób kompletny z systemu. Wymagalne POD_042 System musi mieć możliwość wydruku deklaracji korygujących. Wymagalne POD_043 System powinien zapewniać możliwość wydruku duplikatu deklaracji w sposób gwarantujący wydruk w sposób identyczny jak wydruk deklaracji pierwotnej. Opcjonalne Środki Trwałe Wymagania ogólne ST_001 System musi zapewniać ewidencję następujących kategorii elementów majątku: ‐ środków trwałych, ‐ wyposażenia, ‐ wartości niematerialnych i prawnych, ‐ środków niskocennych , ‐ niskocennych długotrwałego użytkowania, ‐ leasingowanych, ‐ finansowanych lub dotowanych (np. dotacja unijna). Wymagalne ST_002 System musi zapewnić centralną bazę danych środków trwałych która umożliwi jednoznaczną i pełną informację o składnikach majątku, informację kosztową, informację o lokalizacji oraz o podstawowej dokumentacji. Wymagalne ST_003 System musi umożliwiać prowadzenie kilku ewidencji księgowej środka, minimum 3: dla celów MSR (bilansowa), dla celów podatkowych (podatkowa), dla naliczenia amortyzacji nie kosztowej (dotacja). Wymagalne ST_004 System musi posiadać rejestr komórek organizacyjnych, miejsc powstawania kosztów, miejsc użytkowania i użytkowników wspólnych z resztą systemu.
Wymagalne ST_005 System musi posiadać rejestr kodów KST.
Wymagalne
ST_006 System powinien posiadać rejestr kodów KST z przypisaną domyślną stawką amortyzacji podatkowej. Opcjonalne ST_007 System powinien posiadać tabele (rejestr) ekonomicznej użyteczności środków, dla poszczególnych rodzajów środków. Opcjonalne ST_008 System musi posiadać rejestr środków trwałych, wraz z pełną historią zmian elementów majątku. Wymagalne ST_009 System musi umożliwiać automatyczne nadawanie numerów inwentarzowych, zgodnie ze Wymagalne Strona 95 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
zdefiniowanym wzorcem numeracji dla kategorii i rodzaju środka. ST_010 System musi umożliwiać zarejestrowanie w danych Środka Trwałego lub Wartości Niematerialnej i Prawnej wartości demontażu środka i wartości odsprzedaży (wartości rezydualnej), oraz możliwość ich wydruku na dokumencie OT, WN, RwN1. Wymagalne ST_011 System musi umożliwiać zarejestrowanie danych niezbędnych do naliczenia podatku od nieruchomości. Wymagalne ST_012 System musi wspierać naliczanie i księgowanie odpowiedniej kwoty podatku od nieruchomości. Wymagalne ST_013 System musi mieć możliwość podziału środka trwałego na kilka miejsc powstawania kosztów, kilku użytkowników i miejsc użytkowania. Wymagalne ST_014 System musi posiadać rejestr dokumentów wprowadzonych dla środków: ‐ OT (przyjęcie środka trwałego), ‐ MT (zmiana miejsca użytkowania), ‐ LT (likwidacji), ‐ PT (likwidacji), ‐ WN (przyjęcia wartości niematerialno‐prawnej), ‐ RwN1 (przyjęcia środka trwałego z magazynu), ‐ inne , wynikające z ewidencji i użytkowania środka . Wymagalne ST_015 System musi umożliwiać ewidencję rodzajów poszczególnych dokumentów rejestrujących operacje na środkach trwałych. Wymagalne ST_016 System musi umożliwiać konfigurowanie wzorców numeracji dla poszczególnych rodzajów dokumentów wykorzystujących do obliczania poszczególnych segmentów informacje z dokumentu oraz środka trwałego. Wymagalne ST_017 System musi posiadać możliwość wieloetapowego zatwierdzania dokumentów dotyczących środków trwałych. Wymagalne ST_018 System musi umożliwiać dodawanie załączników elektronicznych (plików) dotyczących środka trwałego. Wymagalne ST_019 System musi wspierać proces całkowitej likwidacji środka (LT), nieodpłatnego przekazania środka oraz umożliwiać częściową likwidację wraz z automatycznym obliczeniem wartości „zdejmowanego” umorzenia. Wymagalne ST_020 System musi obsługiwać sprzedaż środka pracownikom lub na zewnątrz. Wymagalne ST_021 System powinien wspierać utworzenie protokołu likwidacji – na podstawie obiegu dokumentów i historii procesu likwidacji z wykorzystaniem szablonów MS WORD lub równoważnego rozwiązania. Opcjonalne ST_022 System musi umożliwiać przeniesienie całości środka lub WNiP (lub tylko jego części) pomiędzy działami, użytkownikami, miejscami powstawania kosztów – z przeksięgowaniem odpowiedniej kwoty wartości zakupu i umorzenia. Wymagalne ST_023 System musi umożliwiać drukowanie naklejek z kodem kreskowym. Wymagalne ST_024 System powinien umożliwiać podział środka trwałego na nadrzędne i podrzędne środki według następujących zasad: ‐ środki nadrzędne posiadają numer inwentarzowy, który grupuje środki podrzędne w całość, ‐ wszystkie środki podrzędne są tej samej kategorii, mają tą samą grupę KŚT, ‐ mogą mieć natomiast różne numery inwentarzowe oraz róże kody KŚT, ‐ amortyzacja naliczana jest w ramach środków podrzędnych, ‐ na zestawieniach/wydrukach z modułu ST powinna być możliwość zaznaczenia, czy mają być pokazywane środki nadrzędne (zgrupowane wartości ), czy podrzędne. Wymagalne ST_025 System musi umożliwiać ewidencję składników środka trwałego. Wymagalne ST_026 System musi umożliwiać podział środka trwałego na osobne składniki (wydzielenie środka trwałego z Wymagalne Strona 96 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
innego środka). ST_027 System musi umożliwiać połączenie różnych środków oraz wyposażenia w jeden środek trwały. Wymagalne ST_028 System powinien umożliwiać wydzielenie wybranego elementu środka trwałego i automatyczne utworzenie z niego nowego środka z odpowiednim przeniesieniem historii ze starego na nowy (wartość początkowa i umorzenie) przy pomocy jednej operacji użytkownika w systemie. Opcjonalne ST_029 System powinien umożliwiać połączenie wybranych środków trwałych oraz wyposażenia i automatyczne utworzenie z niech nowego środka z odpowiednim przeniesieniem historii ze starego na nowy (wartość początkowa i umorzenie) przy pomocy jednej operacji użytkownika w systemie. Opcjonalne ST_030 System musi umożliwiać podgląd elektronicznego dokumentu faktury oraz zeskanowanej wersji faktury papierowej wraz ze wszystkimi załącznikami, wprowadzonej wcześniej o systemu, przez użytkowników działu Ewidencji Majątku. Wymagalne ST_031 System powinien umożliwiać grupową weryfikację i aktualizację okresów użytkowania wybranych środków. Opcjonalne ST_032 Zmiana taka okresu użytkowna musi być wprowadzona z zachowaniem historii poprzedniej wartości okresu używania. Zmiana okresu użytkowania dotyczy księgi (ścieżki) MSR środków. Zmiana taka może, ale nie musi mieć wpływu na stawkę amortyzacji w księdze podatkowej. Wymagalne ST_033 System musi umożliwiać zwiększenie okresu użytkowania dla środków trwałych, które osiągnęły wcześniej wartość „0”PLN i podlegają modernizacji, czyli zwiększeniu wartości. Wymagalne ST_034 System musi umożliwiać wykonanie „przeklasyfikowania” środka trwałego, czyli zmiany grupy KŚT lub kategorii środka Trwałego (również bez zmiany numeru inwentarzowego).
Wymagalne ST_035 System powinien umożliwiać dodawanie nowego środka na bazie już istniejącego poprzez funkcję kopiowania. Opcjonalne ST_036 System musi posiadać możliwość automatycznego naliczania miesięcznych amortyzacji zgodnie z wymogami MSR, oraz ustawy podatkowej (różne ścieżki amortyzacji). Operacja ta musi być wykonywana efektywnie, w sposób nie obciążający bieżącą pracę użytkownika (np. jako zadanie systemowe). Różnice pomiędzy amortyzacjami muszą być ujęte w postaci polecenia księgowego , aby można było przy ich pomocy wyliczyć amortyzacje podatkową. Wymagalne ST_037 System musi umożliwiać naliczenia amortyzacji metodą na n‐miesięcy (amortyzacja MSR – podany okres użytkowania w miesiącach). Wymagalne ST_038 System musi umożliwiać naliczenia amortyzacji metodą liniową lub degresywną (amortyzacja podatkowa). Wymagalne ST_039 System musi mieć łatwą możliwość wyłączenia środka trwałego z naliczenia amortyzacji (środek nieczynny), okresowego wyłączenia amortyzacji w danym okresie, lub amortyzacji tylko w wybranych miesiącach roku obrotowego. Wymagalne ST_040 System powinien umożliwiać automatyczne wyłączanie środka trwałego z naliczania amortyzacji (jednorazowo lub okresowo) w przypadku likwidacji lub czasowego wyłączenia z eksploatacji. Opcjonalne ST_041 System musi umożliwiać łatwe dokonywanie korekt amortyzacji poszczególnych środków trwałych na kilka lat wstecz od daty przyjęcia środka (Korekty amortyzacji wynikają ze zmian na środku, o których wiedza zaistniała dopiero po fakcie od kiedy zaczęły obowiązywać. Np. dotacja na zakup środka może być dopisana do środka dopiero po kilku latach jego używania i powinna mieć wpływ na wszystkie lata amortyzacji środka, od początku jego przekazania do użytkowania). Wymagalne ST_042 Korekta musi być podzielona na poszczególne miesiące, których zmiany dotyczą. Wymagalne ST_043 System musi umożliwiać zamianę stawki amortyzacji lub okresu użytkowania środka w ciągu roku obrachunkowego z automatycznym przeliczeniem planu amortyzacji (w tym również wstecz). Wymagalne Strona 97 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ST_044 System musi umożliwiać rejestrację dotacji unijnej dla środków objętych dotacją z możliwością podziału amortyzacji na część kosztową i nie kosztową (również wstecz). Wymagalne ST_045 System musi umożliwiać wyliczania prognoz (planu) amortyzacji na dowolną określoną liczbę okresów do przodu. Wymagalne ST_046 System powinien zapewniać automatyczne przeszacowania wskazanego podzbioru majątku trwałego z zachowaniem historii zmian. Opcjonalne ST_047 System powinien umożliwiać określenie jakie odpady i w jakiej ilości powstały w czasie procesu likwidacji środka. Opcjonalne Inwentaryzacja. ST_048 System musi umożliwiać inwentaryzację dla wszystkich składników majątku. Wymagalne ST_049 System musi umożliwiać inwentaryzację przy użyciu czytników kodów paskowych w połączeniu z bazą danych z możliwością wydzielenia szczegółowej lokalizacji np. na pokoje. Wymagalne ST_050 System musi umożliwiać wydruk arkuszy spisu inwentaryzacyjnego. Wymagalne ST_051 System musi umożliwiać wydruk arkuszy różnic. Wymagalne ST_052 System musi umożliwiać wydruk arkuszy niedoborów. Wymagalne ST_053 System musi automatycznie dokonywać księgowań dokumentów ST i amortyzacji, zgodnie ze zdefiniowaną dekretacją Wymagalne Ubezpieczenia ST_054 System musi umożliwiać rejestrowanie danych dotyczących ubezpieczenia, powiązanego z środkiem trwałym. Wymagalne ST_055 Procesy rejestrujące operacje zmiany w stanie majątku (zakup, sprzedaż/wycofanie z użytkowania, zwiększenie/zmniejszenie wartości środka trwałego – ewidencja magazynowa i środków trwałych), muszą udostępniać informacje o konieczności zarejestrowania, wznowienia lub skrócenia polisy ubezpieczeniowej. Wymagalne ST_056 System musi generować powiadomienia (mail, sms) w przypadku zmian w stanie majątku mających wpływ na polisy ubezpieczeniowe. Wymagalne ST_057 System musi umożliwiać zarejestrowanie i raportowanie informacji o majątku potrzebnych do zawarcia ubezpieczenia, obliczenia wartości/zakresu ubezpieczonego mienia, rozliczania składek, zgłaszania szkód do TU oraz egzekwowania likwidacji szkód przez TU: • nr ewidencyjny środka trwałego w bazie środków trwałych, • nazwa środka trwałego, • rodzaj środka trwałego (w podziale na grupy: Budowle, Budynki, N1, K1, Pozostałe ST, elektronika biurowa, laptopy), • lokalizacja/miejsce użytkowania środka trwałego, • komórka organizacyjna/osoba odpowiedzialna za nadzór nad środkiem trwałym, • aktualna wartość ewidencyjna, • historia zmian wartości ewidencyjnej (data dokonania zmiany wartości i kwota dokonanej aktualizacji wartości), • data przyjęcia do ewidencji (wymagana akcja systemowa‐komunikat np. e‐mail do AFFU), • nr zadania inwestycyjnego, w ramach którego dokonano zakupu, • data zbycia /wycofania z użytkowania, • folder z możliwością przechowywania dokumentacji w różnych formatach, np. skany faktur zakupu, dokumentacji fotograficznej, numery seryjne/fabryczne elementów składowych środka trwałego, zgłoszenia szkodowe, faktury sprzedaży i in. Dane te powinny być dostępne na dzień bieżący i historyczny. Wymagalne Strona 98 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ST_058 System powinien umożliwiać prowadzenie rejestru ubezpieczeń. Rejestr ubezpieczeń musi mieć możliwość przechowywania załączników dotyczących dokumentacji w różnych formatach, np. skany faktur zakupu, dokumentacji fotograficznej, numery seryjne/fabryczne elementów składowych środka trwałego, zgłoszenia szkodowe, faktury sprzedaży i in.. Opcjonalne ST_059 System musi mieć możliwość przechowywania informacji o dacie końca ubezpieczenia w ewidencji środków trwałych lub w rejestrze polis powiązanym z ewidencją środków trwałych. (Ma to znaczenie w przypadku tych środków trwałych, które są nabywane łącznie z ubezpieczeniem. Wymagalne ST_060 System musi umożliwiać rejestrację oraz okresową aktualizację w rejestrze środków trwałych wartości rynkowej środka trwałego (w szczególności środka transportu). Wymagalne Integracja ST_061 System musi automatycznie przekazywać dane dotyczące stanu środków trwałych i amortyzacji, jak również informacje o zmianach do procesów budżetowania i planowania. Wymagalne ST_062 System musi zapewnić informację o środku trwałym niezbędną do uwzględnienia danego środka jako zasobu w kalkulacji stawek nawigacyjnych w komponencie EPM. Wymagalne ST_063 System musi zapewnić automatyczne księgowanie operacji dotyczących środków trwałych oraz amortyzacji i naliczania podatków w module księgowym. Wymagalne ST_064 Musi istnieć możliwość definicji schematów dekretacji dokumentów dotyczących środków trwałych w oparciu o różne parametry środków, a także dzielenia wartości środka i umorzenia (amortyzacji) na część kosztową i nie kosztową. Wymagalne ST_065 System musi zapewniać definiowanie dekretacji dokumentów różne dla każdej z ksiąg/ścieżki amortyzacji i kategorii i grupy GUS (KST) środka. Wymagalne ST_066 System musi zapewnić automatycznie zgodność ewidencji środków trwałych z zapisami na kontach księgowych. Wymagalne ST_067 System powinien automatyzować operacje dotyczące środków trwałych w powiązaniu z operacjami magazynowymi. Opcjonalne ST_068 System musi zapewnić prowadzenie innych ewidencji, w tym w szczególności: ewidencją infrastruktury IT, ewidencją nieruchomości, ewidencją samochodów, ewidencją infrastruktury technicznej (w tym ATM i CNS) w powiązaniu z ewidencją środków trwałych. Wymagalne ST_069 Obszary, z których możliwe jest „pochodzenie” środka – powinny automatycznie inicjować proces rejestracji środka odpowiednim dokumentem, na podstawie którego zakładana jest kartoteka Środka Trwałego. Wymagalne ST_070 Wszystkie dane wprowadzone w tych obszarach, powinny być przeniesione do obszaru ST wraz z kolejnym krokiem procesu. Oprócz rejestru magazynowego są to : ‐ Utworzenie środka na podstawie faktury z wykorzystaniem danych zarejestrowanych w obszarze zarządzania infrastrukturą IT, ‐ Utworzenie środka na podstawie faktury z wykorzystaniem danych zarejestrowanych w obszarze zarządzania flotą samochodową, ‐ Utworzenie środka na podstawie faktury z wykorzystaniem danych zarejestrowanych w zarządzaniu infrastrukturą CSN/ATN, ‐ Utworzenie środka na podstawie dokumentów i danych zarejestrowanych w zarządzaniu nieruchomościami. Wymagalne ST_071 System musi udostępniać bieżące informację o kosztach nabycia oprogramowania w podziale na jednostki organizacyjne PAŻP. Wymagalne ST_072 System powinien uwzględniać współpracę rejestru środków trwałych z obszarem zakupów. Opcjonalne ST_073 System musi zapewnić integrowalność ewidencji środków trwałych w powiązaniu z operacjami i Wymagalne Strona 99 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
procesami remontowymi i inwestycyjnymi realizowanymi w innych modułach i komponentach systemu. Obiegi dokumentów ST_074 System powinien objąć elektronicznym obiegiem dokumentów operacje zatwierdzania dokumentów (OT, WN, MT, LT, PT i in.) (bez konieczności ich papierowego przekazywania z komórki do komórki). Opcjonalne ST_075 System Elektronicznego Obiegu Dokumentów powinien wspierać obieg dokumentów wymaganych w ramach tego procesu : wniosek kasacyjny z wyceną, faktura sprzedaży, protokół likwidacyjny, dokument LT i PT. Opcjonalne Raportowanie ST_076 System musi umożliwiać łatwy i efektywny sposób tworzenia przez użytkownika, dowolnych zestawień analitycznych na bazie środków trwałych, z wykorzystaniem danych historycznych i archiwalnych. Wymagalne ST_077 System musi zapewniać wydruk listy środków wg różnych kryteriów (np. lokalizacji, nazwy, opisu, kategorii, klucza). Wymagalne ST_078 System musi zapewniać wydruk zestawienie środków trwałych i ich okresów użytkowania wg. zaawansowania umorzenia, dla grupowej zmiany okresów użytkowania. Wymagalne ST_079 System musi zapewniać wydruk zestawienia majątku w podziale na gminy do naliczenia podatku od nieruchomości. Wymagalne ST_080 System musi zapewniać wydruk zestawienia do ubezpieczenia majątku PAŻP. Wymagalne ST_081 System musi zapewniać wydruk zestawienia LT do zmian w naliczeniu składki ubezpieczenia. Wymagalne ST_082 System musi zapewniać wydruk zestawienia majątku w podziale na pola spisowe, lokalizację. Wymagalne ST_083 System musi zapewniać wydruk zestawienie majątku danego typu (np. wg. grupy lub rodzaju KST np. tylko sprzętu IT). Wymagalne ST_084 System musi zapewniać wydruk zestawienia majątku dla poszczególnych komórek organizacyjnych. Wymagalne ST_085 System musi zapewniać wydruk zestawienia przeniesionych elementów majątku. Wymagalne ST_086 System musi zapewniać wydruk tabeli ruchu składników majątku (wykonane operacje na środku) ‐ przegląd historii operacji na środku. Wymagalne ST_087 System musi zapewniać wydruk naliczonej amortyzacji miesięcznie i narastająco, rocznie w układzie bilansowym (MSR) i podatkowym z wyspecyfikowaniem różnic dla poszczególnych grup środków trwałych. Wymagalne ST_088 System musi zapewniać wydruk raportów operacji na środkach: przyjętych, przeniesionych, zlikwidowanych, zwiększeń i zmniejszeń. Wymagalne ST_089 System musi zapewniać wydruk zestawienia środków w pełni umorzonych oraz wg zaawansowania umorzenia w procentach. Wymagalne ST_090 System musi zapewniać wydruk raportu z przeszacowania środków. Wymagalne ST_091 System musi zapewniać wydruk planowanej i nieplanowanej amortyzacji. Wymagalne ST_092 System musi zapewniać wydruk raportu dodawania środków trwałych wg miejsc powstawania kosztów. Wymagalne ST_093 System musi zapewniać wydruk przeglądu kont środków trwałych. Wymagalne ST_094 System musi zapewniać wydruk raportów wycofań (likwidacji) środków wg typu likwidacji oraz ogólnie. Wymagalne ST_095 System musi zapewniać wydruk raportu korekty wartości i umorzeń środków. Wymagalne ST_096 System musi zapewniać wydruk raportu umorzenia szczegółowego dla każdego środka oraz syntetycznego po grupach środków, z podsumowaniami w różnych grupach (np. grupowanie wg grupy Wymagalne Strona 100 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
KST, rodzaju , lokalizacji). ST_097 System musi zapewniać wydruk raportu środków nadrzędnych (posiadających elementy podrzędne). Wymagalne ST_098 System musi zapewnić możliwość raportowania środków wymagających zmian w polisach ubezpieczeniowych (przyjęcie środka ‐ zawarcie ubezpieczenia na nowy środek, sprzedaż środa ‐ skrócenie okresu ubezpieczenia). Wymagalne ST_099 Dane raportowane z bazy środków w celach ubezpieczeniowych muszą obejmować co najmniej: ‐ nr ewidencyjny środka trwałego w bazie środków trwałych, ‐ nazwa środka trwałego, ‐ rodzaj środka trwałego (w podziale na grupy np: Budowle, Budynki, N1, K1, Pozostałe ST, elektronika biurowa, laptopy), ‐ lokalizacja/miejsce użytkowania środka trwałego, ‐ komórka organizacyjna/osoba odpowiedzialna za nadzór nad środkiem trwałym, ‐ aktualna wartość ewidencyjna, ‐ historia zmian wartości ewidencyjnej (data dokonania zmiany wartości i kwota dokonanej aktualizacji wartości), ‐ data przyjęcia do ewidencji (wymagana akcja systemowa ‐ komunikat np. e‐mail do AFFU), ‐ nr zadania inwestycyjnego, w ramach którego dokonano zakupu, ‐ data zbycia /wycofania z użytkowania, ‐ inne informacje mające wpływ na realizację procesów dotyczących ubezpieczeń. Zakłada się, że zestawienia zostaną skonfigurowane przez Zamawiającego za pomocą dostarczonych razem z Systemem narzędzi umożliwiających konfigurowanie zestawień. Wymagalne ST_100 System musi zapewnić możliwość drukowania dokumentów ewidencji majątku (OT, WN, RwN1, MT, LT, PT i inne) na definiowalnych szablonach. Wymagalne ST_101 System powinien umożliwiać wydruk karty środka trwałego i wartości niematerialnej (szczegółowo z całą historią i syntetycznie‐stan aktualny) na specjalnie przygotowanych szablonach, dla każdej z kategorii środka. Opcjonalne ST_102 System musi umożliwiać z określonym wyprzedzeniem raportowania danych dotyczących środków, których okres amortyzacji dobiega końca. Wymagalne Windykacja Wymagania ogólne WN_001 W przypadku harmonogramu płatności dla danej faktury system musi naliczać odsetki od daty wymagalności każdej z rat harmonogramu. Wymagalne WN_002 System musi mieć możliwość naliczenia odsetek zarówno od dnia wymagalności do dnia zapłaty, jak też od dnia wymagalności do zadanej daty raportu, monitu lub wyciągu okresowego kontrahenta. Wymagalne WN_003 System musi przechowywać tabelę stawek odsetkowych z oznaczeniem czasu obowiązywania. Wymagalne WN_004 Kalkulacja odsetek musi uwzględniać zmiany wysokości obowiązujących stawek za cały okres naliczania. W każdym z okresów kwota odsetek powinna być naliczona według właściwej, obowiązującej w nim stawki. Wymagalne WN_005 System musi umożliwiać naliczanie odsetek według stawek ustawowych dla różnych rodzajów zobowiązań publiczno‐prawnych, oraz stawek właściwych dla umów i indywidualnych ustaleń z kontrahentami. Wymagalne WN_006 System musi umożliwiać monitorowanie stanu należności: w pierwszej kolejności wg wysokości sumy zaległości (od największej do najmniejszej), w drugiej wg terminów wymagalności (od najstarszych do najmłodszych), wyszukiwanie dłużników wg kryteriów określonych przez użytkownika. Wymagalne Strona 101 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
WN_007 System musi umożliwiać wystawianie trzech rodzajów monitów: wezwanie do zapłaty, drugie wezwanie do zapłaty oraz ostateczne wezwanie do zapłaty. Wymagalne WN_008 W Systemie musi istnieć możliwość skonfigurowania okresu od wystawienia pierwszego wezwania do zapłaty, po którym zostanie wystawione automatycznie drugie wezwanie w przypadku nieopłacenia należności. Wymagalne WN_009 W Systemie musi istnieć możliwość skonfigurowania okresu od wystawienia drugiego wezwania do zapłaty, po którym zostanie wystawione automatycznie ostateczne wezwanie w przypadku nieopłacenia należności. Wymagalne WN_010 W Systemie musi istnieć możliwość wystawienia wezwania po raz drugi, gdy w okresie czasu między kolejnymi wezwaniami, pojawi się wpłata zmniejszająca saldo zaległości lub gdy zostaną wystawione nowe faktury. Wymagalne WN_011 W Systemie musi istnieć możliwość automatycznego wystawiania monitów według opisanych wyżej zasad bazując na odpowiednich danych finansowo‐księgowych, prowadzonych w zintegrowanej bazie danych. Wymagalne WN_012 W Systemie musi istnieć możliwość wystawienia wezwania na poziomie II lub III, z pominięciem poprzednich poziomów, w przypadku pojawienia się okoliczności wskazujących na możliwość nieodzyskania zadłużenia. Wymagalne WN_013 W Systemie musi istnieć możliwość umieszczenia na wezwaniach wszystkich wymagalnych należności, nie tylko zaległych. Wymagalne WN_014 W Systemie musi istnieć możliwość prowadzenia dwóch rejestrów: Rejestru Monitów Krajowych i Rejestru Monitów Zagranicznych, w których powinny być rejestrowane wystawiane monity. Wymagalne WN_015 System musi zapewniać możliwość odnotowywania wystąpienia postępowania polubownego w procesie Wymagalne windykacyjnym, gdy dochodzi do ugody z dłużnikiem. WN_016 System musi zapewniać możliwość odnotowywania wystąpienia postępowania sankcyjnego w procesie windykacyjnym, gdy mimo III monitu dłużnik nie spłaca zaległości. Wymagalne WN_017 System musi zapewniać możliwość oznaczania należności jako nieściągalnych w przypadku niewielkich zaległości (np. do 120 zł) lub gdy przewidywane koszty windykacji przewyższyłyby wartość należności lub gdy zaległość stanowi niedopłatę spowodowaną prowizjami bankowymi, różnicami zaokrągleń, różnicami wynikającymi z przeliczeń walut.
Wymagalne WN_018 System musi zapewniać możliwość oznaczenia procesu windykacji należności jako zakończonego, gdy: ‐ windykowane zadłużenie zostaje spłacone, ‐ stwierdzi się bezskuteczność działań windykacyjnych, ‐ zapadnie decyzja o spisaniu należności, jako nieściągalnych. Wymagalne WN_019 System musi umożliwiać automatyczne generowanie not odsetkowych w stosunku do uregulowanych zaległości na podstawie ogólnie obowiązujących przepisów prawa, w tym AIP, lub na podstawie zapisów porozumień/ugód. Wymagalne WN_020 W Systemie powinna istnieć możliwość skonfigurowania dolnych limitów sumy odsetek dla kontrahentów krajowych i kontrahentów zagranicznych (noty są wystawiane wtedy, gdy suma odsetek wobec kontrahenta przekroczy kwotę np. 50 zł w przypadku kontrahentów krajowych i np. 150 złotych w przypadku kontrahentów zagranicznych). Opcjonalne WN_021 System musi umożliwiać wystawianie noty odsetkowej obejmującej wszystkie wymagalne należności kontrahenta w przypadku uzyskania informacji na temat wszczęcia postępowania upadłościowego. Wymagalne WN_022 System musi umożliwić użytkownikowi modyfikację dat wymagalności dla not odsetkowych po ich automatycznym wygenerowaniu z wartościami domyślnymi, przed ich zatwierdzeniem i wysyłką. Wymagalne WN_023 System powinien umożliwiać wystawianie korekty noty odsetkowej, w przypadku potrzeby zmiany Wymagalne Strona 102 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
wartości naliczonej w pierwotnej nocie odsetkowej. WN_024 System musi umożliwiać ponowne wystawienie noty odsetkowej i anulowanie poprzedniej w przypadku potrzeby zmiany wartości naliczonej w pierwotnej nocie odsetkowej. Wymagalne WN_025 System musi umożliwiać ręczne wprowadzenia noty odsetkowej w sytuacji, kiedy kontrahent ma uzgodnione w umowie indywidualne warunki wystawiania not oraz w przypadku porozumień, reklamacji. Wymagalne WN_026 System musi umożliwiać umarzanie sumy odsetek w przypadku nieprzekroczenia ustalonych limitów w trakcie roku obrachunkowego. Wymagalne WN_027 System powinien mieć możliwość wygenerowania I i II monitu w wersji elektronicznej oraz automatyczne rozsyłanie monitów do adresatów mailem, faksem bądź innym kanałem komunikacji elektronicznej. Opcjonalne WN_028 System musi mieć możliwość weryfikowania danych adresowych kontrahenta, w szczególności w trakcie wystawiania dokumentów windykacyjnych umożliwianie wglądu i aktualizacji danych teleadresowych kontrahenta zapisanych w kartotece kontrahenta. Wymagalne WN_029 System musi mieć możliwość ewidencjonowania jednej kwoty wpłaty z CRCO w podziale na wpłaty od każdego z kontrahentów na podstawie pliku tekstowego z ETNA CRCO ‐ ewidencjonowanie informacji o kwocie wpłaconej przez kontrahenta i tytule wpłaty (Kwoty uzyskanych przez CRCO wpłat przekazywane są do PAŻP cztery razy w miesiącu, bez specyfikacji wpłat poszczególnych kontrahentów. Możliwe jest uzyskanie z ETNA CRCO informacji o kwocie i tytule wpłaty od każdego kontrahenta). Wymagalne WN_030 System powinien mieć możliwość identyfikacji wpłacającego poprzez mechanizm indywidualnych rachunków bankowych. Opcjonalne WN_031 System musi umożliwiać konfigurowania parametrów generowania wezwań do zapłaty dla poszczególnych kontrahentów. Wymagalne WN_032 W Systemie musi istnieć możliwość włączenia / wyłączenia kontrahenta z generowania wezwań do zapłaty. Wymagalne WN_033 System musi zapewniać uwzględnienie progów kwot w procesie generowania wezwań do zapłaty w związku z pojawianiem się tzw. resztówek (np. w sytuacji, gdy klient wpłacił całą kwotę a bank pobrał opłatę, z czego wynika niewielkie saldo zadłużenia). System musi porównać zadłużenie z progiem kwoty i w przypadku nieprzekroczenia progu nie powinien wystawiać wezwań do zapłaty. Wymagalne WN_034 System powinien zapewniać uwzględnienie parametrów generowania not odsetkowych konfigurowanych w ramach parametrów umów bądź jako parametry określone dla danego kontrahenta. Opcjonalne WN_035 System powinien zapewniać możliwość prowadzenia rejestru czynności windykacyjnych i ustaleń poczynionych w trakcie ich wykonywania. Opcjonalne WN_036 System powinien pozwalać na prowadzenie rejestru czynności windykacyjnych, umożliwiając zapisanie informacji o wykonanych czynnościach: telefonach, wysłanych e‐mail do danego dłużnika. Opcjonalne WN_037 System musi pozwalać na przypisanie opiekunów dla kontrahentów. Wymagalne WN_038 System powinien pozwalać na wygenerowanie listy zadań dla opiekunów dla zaległych faktur, które nie spełniają jeszcze kryterium dla wygenerowania monitu. Opcjonalne WN_039 System powinien pozwalać zaplanować przyszłe zadanie np. sprawdzenie czy dłużnik dokonał obiecanej wpłaty zgodnie ustaleniami wraz z generowaniem powiadomienia o nadejściu terminu zadania. Opcjonalne WN_040 System powinien mieć możliwość prowadzenia w systemie rejestru spraw sądowych. Opcjonalne Powiadomienia WN_041 System musi umożliwiać na automatyczne okresowe rozsyłanie do pracowników (komunikat Wymagalne Strona 103 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
systemowy, e‐mail) informacji o przeterminowanych należnościach, potencjalnie wymagających podjęcia kroków windykacyjnych. WN_042 System powinien umożliwiać na automatyczne rozsyłanie do dłużników przypomnień o zbliżającym się terminie zapłaty e‐mailem, faksem bądź innym kanałem komunikacji elektronicznej. Opcjonalne WN_043 System powinien umożliwiać na automatyczne rozsyłanie do dłużników przypomnień o upływie terminu zapłaty i braku zaksięgowanej wpłaty e‐mailem, faksem bądź innym kanałem komunikacji elektronicznej. Opcjonalne WN_044 System powinien umożliwiać na konfigurowanie okresu przed terminem zapłaty, z jakim zostanie wygenerowane przypomnienie o obowiązku zapłaty należności. Opcjonalne Raportowanie WN_045 System musi zapewniać możliwość generowania raportów ukazujących w różnych układach salda Wymagalne zadłużenia kontrahentów oraz pozycje nierozliczonych dokumentów w rozbiciu na nawigacyjne trasowe, terminalowe i pozostałe oraz łącznie w ujęciu kontrahenta, składające się na salda. Zakłada się, że zestawienia zostaną skonfigurowane przez Zamawiającego za pomocą dostarczonych razem z Systemem narzędzi umożliwiających konfigurowanie zestawień. WN_046 System musi umożliwiać generowanie raportu należności kontrahenta, prezentującego numer kontrahenta, nazwę kontrahenta, numer faktury, datę wystawienia faktury, termin płatności, liczbę dni opóźnienia, walutę, wartość pierwotną faktury, saldo należności z faktury. Wymagalne WN_047 System musi umożliwiać generowanie raportu transakcji kontrahenta, prezentującego wszystkie operacje na koncie kontrahenta. Dodatkowo wymagane są na nim informacje o rodzaju dokumentu (np.: faktura, nota odsetkowa, płatność) i o dacie zaksięgowania.
Wymagalne WN_048 W wypadku, gdy kartoteka jednego kontrahenta jest rozdzielona pomiędzy kartoteki funkcjonalne (klient, dostawca, pracownik…) system musi umożliwiać łączne raportowanie rozrachunków. Wymagalne WN_049 System musi umożliwiać generowanie raportu windykacyjnego należności, prezentującego kod ICAO kontrahenta, kraj kontrahenta, nazwę kontrahenta, status kontrahenta (aktywny/w upadłości), numer kontrahenta w systemie FK, saldo należności, datę wymagalności najstarszej nieuregulowanej faktury, datę wymagalności najmłodszej nieuregulowanej faktury. Wymagalne WN_050 System musi zapewniać dla ww. raportów w szczególności: Wymagalne ‐ Definiowalne sortowanie (wybór z listy parametrów – poprzez podświetlenie wybranych lub wybór „od – do”), ‐ Podsumowanie kolumn liczbowych, ‐ Wyświetlanie stanu na dowolny dzień w przeszłości, odcinając skutki operacji mających miejsce po dacie na dzień (parametr raportu), ‐ Wyszukiwanie na gotowym raporcie, ‐ Eksportowanie danych do tabel MS Excel, ‐ Odfiltrowanie lub wybranie faktur wymagalnych, niewymagalnych, wszystkich lub dowolnie wybranych, ‐ Zawężanie raportów do wskazanych kontrahentów z możliwością podziału na kraj i zagranicę oraz z możliwością wiekowania należności przeterminowanych. WN_051 System powinien umożliwiać generowanie monitów z poziomu utworzonego raportu, poprzez wybranie z niego kontrahenta, a następnie przygotowanie właściwego monitu. Opcjonalne WN_052 System musi umożliwiać definiowanie szablonów, w oparciu, o które będą generowane wydruki monitów i not odsetkowych. Wymagalne WN_053 W Systemie musi istnieć możliwość definiowania szablonów wezwań/monitów w różnych językach (wszystkie teksty i dane stałe na szablonie, powinny być możliwe do przetłumaczenia na język obcy). Wymagalne WN_054 W Systemie musi istnieć możliwość definiowania dwujęzycznego szablonu wezwań/monitów (polskiego Wymagalne Strona 104 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
i angielskiego). WN_055 System powinien wybrać szablon wezwania/monitu/noty odsetkowej w języku obcym w przypadku, gdy adresatem wezwania lub noty jest osoba zagraniczna (Kraj adresata powinien determinować pojawienie się tekstów w odpowiednim języku) oraz umożliwić zmianę szablonu pracownikowi generującemu monity lub noty. Wymagalne WN_056 W Systemie musi istnieć możliwość dowolnego ustawiania wielkości czcionki na szablonach wezwań/monitów. Wymagalne WN_057 W Systemie musi istnieć możliwość formatowania fragmentów tekstu na szablonach wezwań/monitów (np: pogrubienie). Wymagalne WN_058 W Systemie musi istnieć możliwość skonfigurowania w szablonach wezwań/monitów logotypu PAŻP. Wymagalne WN_059 W Systemie musi istnieć możliwość przedefiniowywania przez użytkownika tekstów stałych wykorzystywanych w szablonach wezwań/monitów. Wymagalne WN_060 W Systemie powinna istnieć możliwość zastosowania kolorów w szablonach wezwań/monitów celem wyróżnienia szczególnie istotnych elementów. Opcjonalne WN_061 System musi umożliwiać konfigurowanie odrębnych szablonów monitów dla poszczególnych poziomów monitowania, umożliwienie wprowadzenia opisów właściwych dla poziomu monitowania. Wymagalne WN_062 System musi umożliwiać na seryjne i pojedyncze drukowanie wystawionych monitów i not odsetkowych. Wymagalne WN_063 System powinien mieć możliwość wygenerowania raportów prezentujących informacje o skuteczności Opcjonalne poszczególnych działań windykacyjnych, ocena skuteczności polega na wykazaniu rozliczonych zaległości po wystawieniu monitów I, II i ostatecznego wezwania do zapłaty. WN_064 System musi mieć możliwość prezentowania prognozowanych odsetek lub pominięcia tej informacji w zależności od parametru wydruku, na wydrukach monitów I i II stopnia.
Planowanie i sprawozdawczość Wymagania ogólne CTL_001 System musi posiadać narzędzia wspierające następujące procesy w organizacji: ‐ Planowanie i budżetowanie: * Plan finansowy, * Planowanie operacyjne, * Plan w układzie zadaniowym, * Plan w układzie wykonawczym (wg kształtu ustawy budżetowej), ‐ Proces raportowania i sprawozdawczości (raporty typy karty wyników, pulpity oraz formatowane w sposób zaawansowany sprawozdania finansowe wymagane prawem). Wymagalne CTL_002 System musi umożliwiać przenoszenie konfiguracji aplikacji ze środowiska testowo‐rozwojowego na środowisko produkcyjne. Wymagania dot. zarządzania cyklem życia aplikacji. Wymagalne CTL_003 System musi umożliwiać definicje wielopoziomowych list zadań planistycznych z przypisanymi regułami dostępowymi. Wymagalne CTL_004 System musi umożliwiać definicję dat wymagalności, daty alertowania (zbliżający się termin wymagalności, przekroczenie terminu wymagalności) pojedynczego zadania planistycznego. Wymagalne CTL_005 System musi zapewniać co najmniej następujące typy zadań planistycznych: ‐ Formularz/Formularze planistyczne do wprowadzania danych, ‐ Reguła biznesowa – zadanie polegające na uruchomieniu reguły biznesowej (kalkulacja, kopiowanie wersji, itp), ‐ Proces – zarządzanie procesem planistycznym, ‐ Raport, Wymagalne Wymagalne Strona 105 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐ Opisowe – otwierający ekran opisowy – np. instrukcja. CTL_006 Zadanie planistyczne musi być charakteryzowane instrukcją merytoryczną ułatwiającą użytkownikom pracę z narzędziem. Wymagalne CTL_007 System musi umożliwiać zsynchronizowanie zestawu raportów, formularzy, reguł kalkulacyjnych z wartościami parametrów globalnych systemu, np. wartość parametru RokBieżący = 2013 i tym samym uniknięcie modyfikacji raportów, formularzy oraz reguł i kalkulacji za każdym razem przy zmianie okresu planistycznego. Wymagalne CTL_008 System musi zapewniać możliwość audytu procesu planistycznego: ‐ Audyt jednostek planistycznych, ‐ Audyt zadań planistycznych, ‐ Audyt formularzy planistycznych, ‐ Audyt danych z dokładnością do: * Wprowadzonej wartości, * Wartości poprzedniej, * Czasu zapisu, * Nazwy użytkownika końcowego, * Listy elementów wymiarów, na których zapisano wartość. Wymagalne CTL_009 System musi umożliwiać definiowanie walidacji wprowadzanych danych w kontekście wartości metryk globalnych – np.: system nie powinien pozwolić na przedłożenie planu kosztów stanowiących więcej niż zadany procent kosztów poprzedniego roku jeżeli globalnie ustawiono taki parametr.
Wymagalne CTL_010 System musi umożliwiać zapis danych poprzez formularz, raport, arkusz excel, do bazy OLAP na dowolnym poziomie hierarchii oraz w dowolnym wymiarze planistycznym (w szczególności chodzi o zapis na tzw. agregatach bez specyfikacji zarządzania danymi). Wymagalne CTL_011 System musi umożliwiać tworzenie planów, których logika kalkulacji oparta jest jednocześnie o kalkulacje wykonywane w locie (on‐line) oraz/lub w trybie wsadowym. Kalkulacje powinny być dokonywane zgodnie z kalendarzem lub na żądanie użytkownika. Wymagalne CTL_012 System musi umożliwiać budowanie kalkulacji w pętlach, np.: kilkukrotne wykonanie obliczeń na tym samym zakresie danych. Wymagalne CTL_013 System musi zapewniać mechanizm powiadomień na wypadek zbliżających się przekroczeń terminów wymagalności etapów planistycznych oraz wystąpienia anomalii w danych (np. marża % <= 20% w jednostce x na produkcie y). Wymagalne CTL_014 System powinien posiadać graficzny edytor kalkulacji. Opcjonalne CTL_015 System musi zapewniać możliwość rozszerzenia pozycji planistycznych przechowywanych w definicji wymiaru o dowolne struktury (włącznie z logiką kalkulacyjną) bez fizycznej ingerencji użytkownika końcowego w twardą strukturę wymiaru. Wymagalne CTL_016 System musi umożliwiać tworzenie wielopoziomowych pozycji menu w formatkach planistycznych, których zadaniem powinno być np. otwarcie formularza do wypełnienia lub uruchomienie reguły lub otworzenie innego formularza planistycznego z zachowaniem kontekstu formularza pierwotnego, uruchomienie raportu. Wymagalne CTL_017 System musi umożliwiać tworzenie niesymetrycznych formularzy planistycznych (formularzy których układ planistyczny odbiega od układu sprawozdawczego) bez konieczności wykonywania prac programistycznych. Wymagalne CTL_018 System powinien umożliwiać tworzenie interaktywnych (odświeżanych cyklicznie lub na żądanie) arkuszy Excel, MS Word lub prezentacji PowerPoint zawierających dane z procesu planistycznego. Opcjonalne CTL_019 System musi umożliwiać poprzez formularze (przeglądarka internetowa, excel) zapis wartości numerycznych i nie‐numerycznych do bazy narzędzi danych planistycznego. Wymagalne Strona 106 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
CTL_020 System musi umożliwiać wykorzystanie reguł wyliczeń w celu definiowania podstawowych obliczeń na danych pochodzących z danego arkusza jak i innych arkuszy planistycznych. Wymagalne CTL_021 System musi umożliwiać edycję linii budżetowych w zależności od potrzeb danego okresu planistycznego z uwzględnieniem powiązania z wykonaniem w celu umożliwienia porównywania wskazanej wersji planu i wykonania. Linie budżetowe muszą mieć możliwość definiowania wielu segmentów pozwalających w wystarczający sposób sklasyfikować daną pozycję planu Definicja linii budżetowej musi być dostępna dla wszystkich obszarów systemu i stanowić element, według którego będzie realizowane porównywanie danych. Wymagalne CTL_022 System musi umożliwiać edytowanie arkuszy wraz z możliwością dopisania nowych pozycji podlegających planowaniu wybranym komórkom dla całej Agencji. Wymagalne CTL_023 W Systemie wymagane jest wprowadzanie blokad zapisu dla niekompletnych arkuszy planistycznych. Blokadę należy rozumieć, jako brak możliwości zatwierdzenia (zakończenia) procesu planowania w danej komórce odpowiedzialnej, aż do wypełnienia kwotami określonych wymaganych pól. Wymagalne CTL_024 Poszczególne plany, arkusze planistyczne i cały stworzony model muszą mieć określony status oraz unikalny/niepowtarzalny nadawany automatycznie numer wersji. Wymagalne CTL_025 W Systemie w procesie tworzenia planu wymagana jest możliwość wykorzystania zdefiniowanych arkuszy planistycznych (wraz z regułami obliczeń wykorzystanymi na tych arkuszach), danych poprzez nie wprowadzonych jak i danych historycznych. W systemie konieczny jest dostęp do wszystkich niezbędnych danych potrzebnych do stworzenia planu. Wymagalne CTL_026 Wymagane jest opracowanie planu kosztów operacyjnych OPEX w ujęciu wartościowym (z możliwością powiązania z rzeczowym uzasadnieniem planowanego kosztu przez osobę planującą powiązanego z celami strategicznymi), z uwzględnieniem struktury PAŻP (Biur, MPK‐ów), projektów, zadań inwestycyjnych. Wymagalne CTL_027 System musi umożliwiać osobom planującym koszty wprowadzenia komentarza zawierającego uzasadnienie rzeczowe przy pozycji planistycznej. Komentarz ten powinien być opcjonalnie pokazywany na wydruku planu. Wymagane jest również załączanie dowolnego dokumentu (np. pliki MS Word) do komórek formularzy, raportów. Wymagalne CTL_028 System musi posiadać możliwość tworzenia i zapisywania kolejnej wersji planu (plan roczny, plan na wybrany okres planistyczny) w zadanym horyzoncie czasu (najczęściej rok, 3 lata, 5 lat). Wymagalne CTL_029 Przy przygotowywaniu kolejnej wersji planu musi istnieć możliwości skopiowania przez użytkownika wartości z poprzedniej wersji planu za określone miesiące do kolumny plan na wskazane przez użytkownika okresy. Wymagalne CTL_030 Przy przygotowywaniu kolejnej wersji planu musi istnieć funkcjonalność skopiowania wartości z wykonania za określone miesiące do kolumny plan w tych samych miesiącach. Wymagalne CTL_031 System musi umożliwiać elektroniczną akceptację dla poszczególnych komórek organizacyjnych całych arkuszy planistycznych, planowanych wartości lub wybranych pozycji z zapisaniem informacji o osobie akceptującej / zmieniającej stan. Wymagalne CTL_032 System musi umożliwiać wprowadzanie centralnych korekt z uwzględnieniem dostępnych wymiarów. System powinien umożliwiać zmianę o zadany procentowo poziom kosztów we wskazanych pozycjach planu / liniach budżetowych. Wymagalne CTL_033 System musi umożliwiać elastyczne wprowadzanie zmian wynikających ze struktury organizacyjnej wraz z poprawną alokacją kosztów między jednostkami. Wymagana jest możliwość obsłużenia w przyszłym Systemie sytuacji, kiedy zapada decyzja np. o podzieleniu jednego MPK na kilka. W takim przypadku powstanie nowa zaktualizowana wersja planu będąca wynikiem tylko alokacji kosztów między MPK‐ami pod datą takiej decyzji system powinien Wymagalne Strona 107 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
umożliwić wprowadzenie nowej wersji planu, w której zostanie uwzględniona zmiana struktury organizacyjnej a ponadto koszty ze starego MPK‐a System rozłoży na nowe MPK‐i przy użyciu określonego klucza podziałowego lub kluczy podziałowych określonych osobno dla każdej pozycji rodzajowej kosztu. Ponadto System powinien umożliwić ręczne ustalenie kwot docelowych w planie. Dla operacji zmiany struktury obiektów planowania (MPK‐ów, rodzajów kosztów), niepociągających za sobą zmiany kwoty całego budżetu. System powinien zablokować zatwierdzenie nowej wersji budżetu kosztów, gdy sumarycznie różni się od poprzedniej. Suma planu kosztów przed zmianą i po musi być taka sama. CTL_034 System musi posiadać możliwość dokonywania przesunięć kosztów we wskazanych liniach budżetowych między jednostkami, MPK‐ami. Przesunięcia kosztów między MPK‐ami mogą występować jedynie po odpowiednich akceptacjach. System powinien umożliwić opracowanie arkuszy umożliwiających wprowadzenie zmian w planie, przesunięcie wartości między jednostkami przez jednostkę oddająca środki. System powinien zablokować zatwierdzenie nowej wersji budżetu kosztów, gdy sumarycznie różni się od poprzedniej. Suma planu kosztów w edytowanej linii przed zmianą i po musi być taka sama. Wymagalne CTL_035 System musi posiadać możliwość tworzenie scenariuszy planistycznych jak i prognoz realizacji planu na dany rok opartych o wykonanie i plan wskazanych okresów z opcjonalnym uwzględnieniem zatwierdzonych a niezrealizowanych wniosków zakupowych lub zakładając zmianę wybranego parametru, np. stopy inflacji, lub np. chcąc porównać wariant „tylko Polska” z wariantem „Polska + Litwa”. Wymagalne CTL_036 System musi posiadać możliwość automatycznej kontroli planu opartej o zatwierdzone wcześniej wnioski zakupowe już zrealizowane, niezrealizowane oraz skorygowane ich wartości. Weryfikacja dostępności środków powinna uwzględniać dotychczasowe wykonanie i wcześniejsze wnioski z uwzględnieniem okresów, dla których nastąpiło zatwierdzenie. Wymagalne CTL_037 Wymagana jest możliwość śledzenia postępu prac (EOD ‐ lub funkcjonalność równoważna) nad wybranym dokumentem WOUZ lub dokumentem rozliczeniowym poprzez określenie jego stanu i osoby / komórki, u której obecnie dokument oczekuje na przeprowadzenie dalszych czynności oraz podglądu historii zmian stanów. Wymagalne CTL_038 W Systemie musi umożliwiać jest wprowadzanie zakresów czasowych dla wybranych czynności planistycznych i automatyczne generowanie ponagleń do osób odpowiedzialnych za zaplanowanie kosztów. W systemie muszą być opracowane arkusze prezentujące informacje na temat terminów i osób akceptujących dokumenty finansowe oraz ścieżki akceptacji dokumentów. Wymagana jest funkcjonalność Systemu, która będzie umożliwiała monitorowanie procesu planowania poprzez ustalenie terminu oddania wypełnionego planu cząstkowego, którego zbliżanie się lub przekroczenie będzie automatycznie powodowało wygenerowanie komunikatu dla osoby odpowiedzialnej. Wymagalne CTL_039 Raporty okresowe, w tym Stan realizacji planu finansowego, muszą być generowane według zapisanego w systemie harmonogramu a następnie dystrybuowane do właścicieli MPK w ramach Systemu. Wymagalne CTL_040 System musi umożliwiać agregowanie danych, analizowanie i tworzenie planów z podziałem na okresy: ‐ miesięczne, ‐ kwartalne, ‐ roczne. Wymagalne CTL_041 System musi zapewniać inteligentne traktowanie wymiaru czasu – wbudowane reguły akumulacji wartości pozycji planistycznych w czasie (w zależności od szczegółowości planowania): ‐ Narastająco w roku, ‐ Narastająco w kwartale, ‐ Narastająco w miesiącu, ‐ itp. Wymagalne Strona 108 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
CTL_042 System musi obsługiwać łatwe kopiowanie wprowadzanych danych na następne okresy w kontekście danej pozycji lub wielu wskazanych pozycji. Musi również istnieć możliwość obsługi kopiowania wskazanych wielu wartości do wielu pól arkusza lub zakresów np. poprzez kombinację klawiszy CTRL+C, CTRL+V lub w równoważny sposób. Wymagalne CTL_043 System musi umożliwiać planowanie dowolną metodą, a w szczególności: ‐ planowanie z góry na dół jak i z dołu do góry oraz łączenia obu metod planowania, ‐ skomplikowane alokacje (pionowe, poziome, skośne, wielowymiarowe), ‐ planowanie przez nośniki lub kwotowo, wyceny standardowe, ceny transferowe itp., ‐ inne ‐ łączące w sobie charakterystyki powyższych. Wymagalne CTL_044 System powinien posiadać możliwość elektronicznej weryfikacji / akceptacji arkuszy i dokumentów dotyczącego danego obszaru przez użytkowników uprawnionych / odpowiedzialnych za dany poziom weryfikacji / akceptacji. Wymagalne CTL_045 System musi posiadać możliwość wprowadzenia przez użytkowników wyjaśnień do przekroczeń planu ponad limit dla danej pozycji planu / linii budżetowej. Wymagalne CTL_046 System powinien posiadać możliwość definiowania limitu przekroczenia planu dla danej pozycji planu / linii budżetowej, przy którym konieczne jest jego wyjaśnienie. Wymagalne CTL_047 System powinien umożliwiać pracę nad budżetem przez wielu użytkowników jednocześnie w ramach posiadanych uprawnień. Wymagalne CTL_048 System powinien umożliwiać jednoczesny dostęp do danych planu i wykonania przez dowolną liczbę uprawnionych użytkowników wraz z obsługą praw dostępu do danych dla określonych grup użytkowników lub komórki organizacyjnej. Wymagalne CTL_049 System powinien automatycznie informować użytkownika (mail, sms, wiadomość w systemie) o osiągnięciu zadanego poziomu wykorzystania planu (określonego jako procent wykorzystania planu lub jako zadana kwota). Opcjonalne CTL_050 W systemie musi istnieć obsługa planu dla roku bieżącego i projektowanie planu na lata następne. Wymagalne CTL_051 Sytemu musi w obszarze planowania pozwalać na wygenerowanie kolejnej wersji planu finansowego (w różnych wymaganych układach) na dane okresy. Wymagalne CTL_052 System musi posiadać możliwość planowania przepływu prac z udostępnianiem pozycji arkuszy planistycznych określonym osobom. Wymagalne CTL_053 System musi automatycznie informować o stanie prac nad procesem opracowywania planu finansowego w tym generować przypomnienia / ponaglenia do osób odpowiedzialnych za przygotowanie planów cząstkowych ich zatwierdzenie czy też korektę. Wymagalne CTL_054 System musi wygenerowane sprawozdania utrwalać w systemie oraz musi być możliwość ręcznej korekty danych poszczególnych pozycji. System musi umożliwiać śledzenie dokonanych zmian (kto, co i kiedy) Wymagalne CTL_055 System musi mieć możliwość udostępniania informacji o kwotach faktycznych kosztów poniesionych w poszczególnych okresach obrachunkowych w celu ich wykorzystania w procesach planowania i kontroli realizacji budżetu ubezpieczeń. Wymagalne CTL_056 System musi mieć możliwość wsparcia zgodnie z procedurą obowiązującą w Agencji planu kosztów ubezpieczeń w podziale na: Świadczenia na rzecz pracowników Ubezpieczenia osobowe Ubezpieczenie pracowników PAŻP ‐ kontrolerzy Ubezpieczenie pracowników PAŻP ‐ pozostali pracownicy Pozostałe koszty Ubezpieczenia majątkowe dot. pojazdów Wymagalne Strona 109 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Składka AC Składka OC Składka NW Ubezpieczenia majątkowe ‐ budynki i budowle Ubezpieczenia majątkowe ‐ wyposażenie i sprzęt Ubezpieczenia samolotów Ubezpieczenia pozostałe Ubezpieczenia majątkowe pozostałe Ubezpieczenia odpowiedzialności cywilnej (OC) PAŻP. CTL_057 System musi zapewnić sporządzanie planu budżetowego z możliwością wskazania priorytetów budżetowych dla zadań związanych z zapewnieniem ciągłości i bezpieczeństwa pracy urządzeń CNS/ATM. Wymagalne Integracja CTL_058 System musi mieć możliwość wymiany danych z zewnętrznymi systemami oraz innymi źródłami danych poprzez wbudowane narzędzie do ekstrakcji, transformacji oraz zasilania danych. Wymagalne CTL_059 System musi być zintegrowany z dedykowanymi aplikacjami obsługującymi poszczególne obszary: ‐ planowania kosztów operacyjnych, ‐ kalkulacji stawek i opłat, ‐ planowania inwestycji, ‐ opracowania i przekazania planu pozostałych przychodów operacyjnych, ‐ opracowania i przekazania sprawozdań z notami, ‐ opracowania planu przychodów pozalotniczych, ‐ opracowania i opublikowania założeń makroekonomicznych, ‐ oraz innych w których budowane są plany cząstkowe. Wymagalne CTL_060 System musi posiadać możliwość pozyskiwania informacji do zaplanowania pozycji przychodów z działalności operacyjnej. Pozyskanie powinno polegać na wygenerowaniu informacji na temat przychodów z działalności podstawowej poprzez wyliczenie ich na podstawie wymaganych parametrów, w tym z uwzględnieniem stawki usługi terminalowej i trasowej, wartości VFR, rozliczenia mechanizmu wyrównawczego oraz prognozy lotów (w podziale na loty zwolnione oraz płatne). Ponadto wymagane jest pozyskanie informacji o przychodach z działalności pozalotniczej, poprzez wyliczenie danych w oparciu o zdefiniowane struktury. Wymagalne CTL_061 System musi posiadać możliwość pozyskania informacji o wysokości planowanych kosztów operacyjnych w układzie rodzajowym. W przypadku amortyzacji w podziale na grupy klasyfikacyjne środków trwałych oraz wartości niematerialnych i prawnych. Wymagalne CTL_062 System musi posiadać możliwość pozyskania informacji do zaplanowania pozostałych przychodów i kosztów operacyjnych oraz przychodów i kosztów finansowych. Pozyskanie powinno odbyć się poprzez wygenerowanie tej informacji na podstawie danych planistycznych wprowadzonych w komórkach organizacyjnych odpowiedzialnych za ich przygotowanie oraz poprzez ich skalkulowanie. Wymaganie dotyczy w szczególności odpisów na należności, wartości amortyzacji sfinansowanej z planowanej do uzyskania dotacji z funduszy unijnych (POIiŚ), kosztów finansowania zewnętrznego oraz przychodów z tytułu lokat. Wymagalne CTL_063 System musi posiadać możliwości pozyskania informacji do zaplanowania pozycji bilansowych w zakresie środków trwałych, środków trwałych w budowie oraz wartości niematerialnych i prawnych na podstawie wprowadzonego do Systemu planu inwestycji oraz planu amortyzacji. Wymagany jest podział na grupy klasyfikacyjne z uwzględnieniem terminu oddania i okresu użytkowania. W planie inwestycji konieczne jest uwzględnienie wartości i terminów nakładów, dat i wartości oddań oraz dat i kwoty płatności z uwzględnieniem źródło finansowania (w podziale na własne i dofinansowanie unijne). Wymagalne CTL_064 System musi posiadać możliwość pozyskania informacji do zaplanowania pozostałych pozycji bilansowych na podstawie historycznych danych finansowych ze sprawozdań finansowych z Biura AG, planowanych wartości rozliczeń z przewoźnikami, kwoty planowanych rezerw aktuarialnych, Wymagalne Strona 110 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
skonfigurowanych reguł w modelu planistycznym. CTL_065 System musi posiadać możliwości pozyskania informacji umożliwiającej przygotowanie sprawozdawczości zarządczej oraz sprawozdawczości budżetowej. W Systemie musi być dostęp do danych finansowych niezbędnych do przygotowania odpowiednich raportów zarządczych oraz sprawozdawczości budżetowej (m.in. dane dotyczące baz kosztowych planistycznych oraz sprawozdawczych dane dotyczące wykonania oraz planu działań, dane z planu oraz wykonania kosztów operacyjnych, dane z planu oraz wykonania inwestycji, dane ze sprawozdań finansowych wraz z notami przygotowywanych przez Biuro AG). Wymagalne CTL_066 System musi posiadać i udostępniać informację o kosztach wynagrodzeń podzielonych wg kategorii PRU (podział wymagany przez EUROCONTROL). Wymagalne CTL_067 System musi umożliwić przygotowanie sprawozdań zarządczych i analiz na temat wartości planowanych vs wartości wykonanych (co wymaga systemowego powiązania ze sprawozdaniami finansowymi z AG oraz z planem finansowym na dany okres) . Wymagalne CTL_068 System musi posiadać możliwość pozyskania informacji o wykonaniu w podziale na działania na potrzeby przygotowania sprawozdań budżetowych z w układzie zadaniowym. Wymagalne CTL_060 System musi umożliwiać zakładanie reguł kalkulacyjnych umożliwiających generowanie wybranych wskaźników finansowych, techniczno‐ekonomicznych (w układzie ilościowo – wartościowym) oraz pozostałych analiz sprawozdawczości zarządczej. Wymagalne CTL_070 System musi umożliwiać zakładanie reguł kalkulacyjnych umożliwiających generowanie różnych analiz sprawozdawczości zarządczej w tym również pozyskiwania informacji o bieżącym wykonaniu. Wymagalne CTL_071 System musi posiadać możliwość pozyskania informacji do przygotowania raportów ze sprzedaży. System musi umożliwiać definiowanie własnych raportów na bazie danych finansowych i operacyjnych, odnośnie sprzedaży zafakturowanej w podziale na rodzaje usług, np. usługi pozalotnicze, sprzedaż towarów, dotacji z tytułu lotów zwolnionych z opłat, lotnicze – trasowe, terminalowe, loty z UE i poza UE, loty w ruchu krajowym i międzynarodowym, w podziale na poszczególnych kontrahentów krajowych i zagranicznych, dla konkretnych lotnisk krajowych w przypadku usług lotniczych. Wymagalne CTL_072 System musi posiadać możliwość aktualizacji prognoz o dotychczasowe wykonanie. Wymagalne CTL_073 System musi posiadać mechanizm umożliwiający import danych z arkuszy Excel, plików tekstowych, plików XML dotyczących baz kosztowych, które dostarczane są z zewnątrz, między innymi z IMGW. W zakres projektu nie wchodzi wykonanie interfejsów.
Wymagalne CTL_074 System musi posiadać możliwość eksportu danych (w postaci tabelarycznej) z systemu do PDF i Excela w szczególności z formularzy planistycznych, zestawień, raportów i sprawozdań. Wymagalne CTL_075 Wymagalne System musi posiadać zdolność do korzystania z baz kursów walut zapisanych w Systemie. Przy planowaniu używa się jednego kursu referencyjnego, jednak istotnym wymaganiem jest, aby była możliwość: • definiowania dowolnej listy walut planistycznych, raportowych, • definiowania dowolnej listy tablic kursowych, • zastosowania kursu z wybranej tabeli do translacji między walutą, w której prowadzony jest proces a docelową. CTL_076 System musi umożliwiać wykorzystanie definiowalnych i konfigurowalnych przez użytkownika reguł wyliczeń pozwalających na pobranie danych z różnych obszarów systemu, danych historycznych, danych planistycznych, danych z wykonania m. in.: ‐ wprowadzonych założeń makroekonomicznych (np.: kurs, stopa inflacji…). ‐ Informacji na temat nośników kosztów i cen jednostki nośnika (np. liczba telefonów stacjonarnych w Wymagalne Strona 111 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
jednostce do zaplanowania kosztów opłat za telefony stacjonarne poprzez przemnożenie przez limit rozmów na telefon). ‐ koszty operacyjne, ‐ sprawozdania finansowe z notami, ‐ amortyzacja, ‐inwestycje, ‐grupy klasyfikacyjne środków trwałych oraz wartości niematerialnych i prawnych, ‐dotacje unijne, ‐ przychody z działalności podstawowej ‐ przychody pozalotnicze, ‐ wartość VFR, ‐ prognoza ruchu lotniczego (w podziale na loty zwolnione oraz płatne), ‐ rozliczenie mechanizmu wyrównawczego, ‐ skalkulowane stawki opłat za usługi nawigacji trasowej oraz terminalowej, ‐ plan kosztów działań, ‐ baza kursów walut. CTL_077 System musi posiadać zdefiniowany zestaw raportów oraz możliwość definiowania nowych pozwalających określić stan realizacji planu finansowego PAŻP wykorzystujących różne źródła danych z możliwością wprowadzenia w definicjach raportów zmian z wykorzystaniem danych z planu i wykonania oraz zastosowanych elementów linii budżetowych.
Wymagalne CTL_078 System musi posiadać możliwość wykorzystania zdefiniowanej w systemie i zmiennej w czasie struktury organizacyjnej do przygotowania arkuszy planistycznych i raportowania. Wymagalne CTL_079 W procesie planowania konieczne jest umożliwienie wykorzystania list dla poszczególnych segmentów linii budżetowych w celu ułatwienia definiowania linii budżetowej i ograniczenia pomyłek przy tworzeniu tej definicji. Listy potrzebne też będą przy generowaniu raportów w momencie podawania parametrów raportu. Listy wykorzystywane w liniach budżetowych muszą być bezwzględnie powiązane z pozycjami wykonania a wykorzystywane elementy spójne we wszystkich obszarach funkcjonujących w systemie (m.in. FK). Wymagalne CTL_080 System musi posiadać możliwość dostępu do danych finansowo‐księgowych z wykonania w układzie możliwym do porównywania do danych z planu. Wymagalne CTL_081 System musi posiadać możliwość udostępniania danych o zatwierdzonych wnioskach WOUZ w układzie możliwym do porównywania do danych z planu. Wymagalne CTL_082 System musi posiadać możliwość dostępu do danych dotyczących planu / wykonania poszczególnych pozycji kosztów operacyjnych. Wymagalne CTL_083 Pożądana jest możliwość planowania off‐line poprzez otwarcie formularza planistycznego w arkuszu Excel, który można będzie wypełnić bez konieczności połączenia z systemem i następnie zaimportować dane do systemu. Opcjonalne CTL_084 Pożądanym jest, aby system umożliwiał podgląd z poziomu pozycji planu i / lub danego okresu dokumentów źródłowych (np.: wniosków, umów, faktur) realizujących budżet. Opcjonalne CTL_085 W systemie musi być możliwość dostępu do danych w systemie z różnych obszarów przy uwzględnieniu nadanych uprawnień dla użytkowników. Wymagalne Konfiguracja CTL_086 System musi posiadać możliwość stworzenia i elastycznej konfiguracji modelu planistycznego wraz z możliwością jego rekonfiguracji przez użytkownika w celu dostosowania do jego potrzeb. Model ten musi być oparty na danych z wypełnionych arkuszy planistycznych wykorzystujących definiowalne pozycje z możliwością wykorzystania definiowalnych reguł obliczeń z możliwością powiązania danych pomiędzy poszczególnymi arkuszami jak i poszczególnymi pozycjami. Analogiczne operacje na arkuszach planistycznych mają być również dostępne w modelu planistycznym. Wymagalne Strona 112 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Musi istnieć możliwość uzupełniania i aktualizacji danych w modelu poprzez wprowadzanie danych ręcznie przez użytkowników, pobieranie danych z różnych obszarów systemu w szczególności wykorzystując dane historyczne dotyczące m.in. ‐ wykonania zgodnego ze sprawozdaniem przygotowywanym przez księgowość. ‐ wykonania kosztów operacyjnych, ‐ wykonania inwestycji, ‐ raportu aktuariusza (dla rezerw na świadczenia pracownicze), ‐ wykonania przychodów pozalotniczych, ‐ wykonania ruchu lotniczego, ‐ wartości rozliczenia mechanizmu wyrównawczego (under/over recovery), ‐ obowiązujących na dany okres stawek opłat nawigacyjnych ‐ oraz innych wymaganych danych CTL_087 System musi posiadać możliwość elastycznego budowania struktur planowania oraz sprawozdawczości zarządczej i budżetowej: System ma umożliwiać dowolne budowanie, a następnie rozbudowywanie pozycji i arkuszy planistycznych i sprawozdawczych o nowe pozycje planistyczne i sprawozdawcze, których powodem może być zmiana regulacji prawnych lub otoczenia (np. nowy dostawca usług meteorologicznych lub kilku nowych dostawców).
Wymagalne CTL_088 System musi mieć możliwość konfiguracji modelu rachunku kosztów działań na potrzeby planowania i sprawozdawczości kosztów i stawek nawigacyjnych. (wymóg EUROCONTROL).
Wymagalne CTL_089 System musi posiadać możliwość tworzenia reguł przenoszenia danych między pozycjami planistycznymi różnych sprawozdań. Wymagalne CTL_090 System musi mieć możliwość definiowania ról osób biorących udział w procesie opracowywania planu finansowego, ich odpowiedzialności i kalendarza zadań w ramach każdego cyklu planistycznego. Wymagalne CTL_091 System musi posiadać możliwość definiowania sprawozdań zbiorczych na podstawie sprawozdań jednostkowych / cząstkowych wraz z możliwością automatycznego przeliczenia sprawozdania. Wymagalne CTL_092 System musi obsługiwać uaktualnianie szablonów wzorów sprawozdań zgodnie ze zmieniającymi się przepisami. Wymagalne CTL_093 System musi posiadać możliwość opracowywania elastycznych arkuszy do planowania m. in: ‐ kosztów operacyjnych z wykorzystaniem linii budżetowych składających się z wielu segmentów pozwalających w wystarczający sposób sklasyfikować daną pozycję planu definiowanych/przygotowywanych w innych obszarach ‐ sprawozdań finansowych, ‐ amortyzacji, ‐ inwestycji, ‐ dotacji unijnych, ‐ przychodów z działalności podstawowej ‐ przychodów poza lotniczych ‐ innych niezbędnych do opracowania modelu planistycznego zasilanych również w innych obszarach oraz umożliwiających opracowanie raportów i sprawozdań wg np.: MSR, ustawy budżetowej, z uwzględnieniem okresów planowania miesiąc, kwartał, rok. Tworzone arkusze planistyczne muszą wykorzystywać informację o aktualnej strukturze organizacyjnej. Arkusze planistyczne różnią się w zależności od kategorii planowanych kosztów, np. koszty bezosobowe szkoleń wraz z podróżami, koszty ubezpieczeń, koszty remontów w podziale na zadania remontowe powiązane z zasobami, koszty wynagrodzeń (wynikające m.in. z kosztów pracy poszczególnych pracowników w powiązaniu ze świadczoną służbą) wraz z pochodnymi, koszty realizowanych projektów, koszty amortyzacji powiązane ściśle z planem inwestycji oraz środkami już użytkowanymi. Wymagalne CTL_094 Dla utworzonych w Systemie arkuszy planistycznych musi istnieć możliwość nadawania uprawnień dla wybranych komórek organizacyjnych, użytkowników czy też grup użytkowników również w zależności od stanu danego planu czy arkusza planistycznego lub do wybranych linii budżetowych, pozycji. Wymagalne Strona 113 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
CTL_095 System musi dawać możliwość określania pól koniecznych do wypełnienia na zdefiniowanym arkuszu planistycznym. Wymagalne Raportowanie CTL_096 System musi posiadać możliwość agregowania danych z modelu planistycznego do postaci różnych układów w szczególności: ‐ układ sprawozdania finansowego, ‐ układ budżetu tradycyjnego, ‐ układ budżetu zadaniowego, ‐ a także inne zdefiniowane przez użytkownika. Wymagalne CTL_097 System musi udzielić wsparcia użytkownikowi przy generacji planu finansowego na dany rok w układzie sprawozdania finansowego zawierającego sprawozdanie z sytuacji finansowej, sprawozdanie z całkowitych dochodów oraz sprawozdanie z przepływów pieniężnych na podstawie stworzonego modelu planistycznego. Wymagalne CTL_098 System musi udzielić wsparcia użytkownikowi przy generacji planu finansowego na dany rok w układzie budżetu tradycyjnego na podstawie stworzonego modelu planistycznego W szczególności system ma rejestrować i wykorzystywać informację o mapowaniu pozycji planowanej do pozycji klasyfikacji tradycyjnej. Wymagalne CTL_099 System musi udzielić wsparcia użytkownikowi przy generacji planu finansowego na dany rok w układzie budżetu zadaniowego na podstawie stworzonego modelu planistycznego W szczególności system musi pobierać dane z procesu kalkulacji stawek, który dostarcza informacji o podziale planowanych kosztów na działania w układzie budżetu zadaniowego. Wymagalne CTL_100 System musi posiadać możliwość przygotowania sprawozdania z analizą kosztów pracowniczych PRU (analiza kosztów wynagrodzeń). Dane do tego sprawozdania muszą być zaciągane ze sprawozdania finansowego tworzonego przez Księgowość oraz z danych o kosztach wynagrodzeń podzielonych wg kategorii PRU (podział wymagany przez EUROCONTROL). Wymagalne CTL_101 System musi posiadać możliwość przygotowania sprawozdań budżetowych w układzie budżetu tradycyjnego. W szczególności system musi rejestrować i wykorzystywać informację o mapowaniu wykonania do pozycji klasyfikacji tradycyjnej. Wymagalne CTL_102 System musi posiadać możliwość przygotowania sprawozdań budżetowych w układzie budżetu zadaniowego. Układ budżetu zadaniowego wymaga powiązania sprawozdania z wykonaniem działań. Wymagalne CTL_103 System musi posiadać możliwość monitorowania stopnia realizacji: poniesionych kosztów oraz nakładów, uzyskanych przychodów oraz ich wpływu na plan finansowy. Oznacza to możliwość wygenerowania różnych wersji planu finansowego, biorąc pod uwagę faktyczne wykonanie kosztów, nakładów oraz uzyskanych przychodów itp., oraz porównanie do planu zatwierdzonego na dany okres. Wymagalne CTL_104 System musi posiadać możliwość pozyskiwania informacji o bieżącym wykonaniu z monitorowaniem stopnia realizacji planów Wymagalne CTL_105 System powinien posiadać możliwość uzyskania wydruku definicji sprawozdania, formularza planistycznego Opcjonalne CTL_106 Pożądane jest, aby pozycje planistyczne i sprawozdawcze można było opisać w dodatkowym języku. Wskazanym byłoby tworzenie raportów w języku angielskim. Przy raportowaniu planu System powinien posiadać parametr sterujący, którym decydowano by o tym, w jakiej wersji językowej mają być wyświetlone pozycje. Opcjonalne CTL_107 W Systemie wymagane jest rejestrowanie poszczególnych zmian wraz z identyfikacją użytkownika i wskazaniem dokonanej modyfikacji oraz możliwość śledzenia historii wprowadzanych zmian w wybranych wersjach planu, scenariuszach, arkuszach planistycznych a także ich pozycji oraz wartości. Wymagalne Strona 114 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
System musi umożliwiać podgląd aktualnego stanu jaki i historii zmiany stanów danego planu czy też arkusza planistycznego CTL_108 System musi umożliwiać określenie stanu realizacji prac nad planem poprzez raportowanie stanu poszczególnych arkuszy planistycznych wraz z informacją jakiej komórki organizacyjnej dotyczy arkusz. Wymagalne CTL_109 W Systemie wymagane jest tworzenie raportów dla wybranych segmentów pozycji linii planistycznych ułatwiających identyfikację wprowadzonych korekt w poszczególnych wersjach planów. System musi umożliwiać tworzenie raportów porównujących wskazane wersje planów, scenariuszy, prognoz lub wykonanie danego okresu dla wybranej pozycji. System musi dostarczać zestawienia umożliwiające porównywanie poszczególnych wersji planu, scenariuszy i prognoz między sobą z możliwością odfiltrowania, zmienionych pozycji oraz wskazaniem historii wprowadzonych zmian. Wymagalne CTL_110 System musi umożliwiać wykonanie wydruku raportów dotyczących planu kosztów w układzie wartościowym z opcjonalnym komentarzem stanowiącym rzeczowe uzasadnienie kosztu. Musi istnieć możliwość wyeksportowania danych z raportu do różnych formatów tj.: Excel, Word, PDF itp. Wymagalne CTL_111 System musi zapewnić powiązanie planu rzeczowego z budżetem dostępnym do jego wykonania. Informacja na poziomie analitycznym. System musi zapewnić wyszukiwanie pozycji budżetowych z podziałem na poszczególne zadania budżetowe danego MPK ( kryteria: nr zadania, kod MPK, rok budżetowania, status pozycji budżetowej /zrealiz., w trakcie realiz., itd. ). Wymagalne CTL_112 System musi zapewnić informacje o planie budżetowym z podziałem na MPK.
Wymagalne
CTL_113 System musi zapewnić sprawozdawczość porównawczą wskaźnika opóźnień trasowych w stosunku do kosztów jako metody realizacji celu osiągnięcia równowagi między kosztami poniesionym na zmniejszanie opóźnień a osiągnięciem celu dla wskaźnika opóźnień trasowych (KPA Pojemność). Aktualnie brak jest modelu prowadzenia takiej sprawozdawczości. Wymagalne CTL_114 System powinien zapewnić sprawozdawczość porównawczą przychodów z tytułu opłat za usługi nawigacyjne w stosunku do ponoszonych kosztów lotniskowych służb kontroli ruchu lotniczego, w podejściu wariantowym: • pełnych kosztów procesów KP‐TWR i KP‐RAD • pełnych kosztów komórek organizacyjnych AR i pozostałych, • kosztów pracy komórek organizacyjnych AR i pozostałych, itd., w podziale na poszczególne organy kontroli ruchu lotniczego (ACC/APP/TWR). Wymagalne CTL_115 System musi posiadać formatkę/kartę/panel zawierający informacje o budżecie w zakresie ochrony przeciwpożarowej. Wymagalne CTL_116 System musi umożliwiać wykonywanie analiz kosztów IT generowanych przez komórki organizacyjne PAŻP. Wymagalne CTL_117 System musi posiadać możliwość udostępnienia opracowanych raportów pozwalających określić stan realizacji planu finansowego dla osób odpowiedzialnych za obszary, w zakresie odpowiadającym odpowiedzialności obszaru wraz z zaznaczeniem konieczności wyjaśnień w przypadku przekroczenia limitu odchylenia. Wymagalne CTL_118 W Systemie wymagane jest stworzenie raportów zdefiniowanych i możliwość tworzenia raportów ad‐
hoc z uwzględnieniem wybranych linii, segmentów konta grupowanych w dowolny sposób dla wskazanych okresów. Wymagalne Tabela 9. Wymagania funkcjonalne ‐ Finanse i księgowość Strona 115 z 285
2.2.4
Wymagania dotyczące komponentu - Podsystem Zarządzanie
majątkiem
Nr
wymagania
Wymaganie
Kategoria
wymagania
Ewidencja nieruchomości Kartoteka nieruchomości NIE_001 System musi umożliwiać ewidencję danych dotyczących nieruchomości i obiektów technicznych własnych i obcych (użytkowanych lub zarządzanych przez PAZP), w jednym wspólnym repozytorium. W zakresie ewidencji znajdą się m.in. budynki, grunty, obiekty budowlane, pomieszczenia, maszyny robocze. Wymagalne NIE_002 System musi umożliwić ewidencję statusu nieruchomości wraz z dokumentami (w formie załączników) wymaganymi dla poszczególnych statusów nieruchomości. Wymagalne NIE_003 System musi umożliwiać ewidencję wyposażenia nieruchomości i obiektów technicznych np. meble, sprzęt RTV. Wymagalne NIE_004 System musi umożliwiać ewidencję historii zmian danych dotyczących nieruchomości, obiektów technicznych i wyposażenia. Wymagalne NIE_005 System musi umożliwiać ewidencję zmian wyposażenia pomiędzy nieruchomościami. Wymagalne NIE_006 System musi umożliwiać definiowanie i dodawanie atrybutów opisujących ewidencjonowane nieruchomości i obiekty techniczne dla każdej kategorii obiektu np. budynki, grunty, pomieszczenia. Wymagalne NIE_007 System musi umożliwiać ewidencję powiązań pomiędzy wyposażeniem, nieruchomościami i obiektami technicznymi i umożliwiać tworzenie hierarchicznych struktur np. pomieszczenie wchodzi w skład budynku. Struktury hierarchiczne elementów wyposażenia muszą posiadać datę obowiązywania. Wymagalne NIE_008 System musi umożliwiać grupowanie nieruchomości, obiektów technicznych i wyposażenia i ewidencjonowanie danych na poziomie grup. Wymagalne NIE_009 System musi umożliwiać ewidencję powiązań pomiędzy nieruchomościami i umożliwiać tworzenie hierarchicznych struktur tych obiektów, np. budynków z gruntami. Struktury hierarchiczne nieruchomości muszą posiadać datę obowiązywania. Wymagalne NIE_010 System musi umożliwiać z poziomu wybranej nieruchomości, obiektu technicznego lub wyposażenia podgląd wybranych zdarzeń związanych z tą nieruchomością, obiektem lub wyposażeniem, takich jak wykonywane remonty, zakres prac remontowych, daty przeglądy, protokoły i zalecenia z przeglądów, wykonywane zadania inwestycyjne, zgłoszone awarie. Wymagalne NIE_011 System powinien zapewnić elektroniczną ewidencję protokołu odbioru technicznego nieruchomości lub obiektu technicznego. Opcjonalne NIE_012 System powinien zapewnić elektroniczną ewidencję książki obiektu budowlanego.
Opcjonalne
NIE_013 System powinien zapewnić obieg protokołu odbioru technicznego nieruchomości lub obiektu technicznego. Opcjonalne NIE_014 System powinien zapewnić obieg książki obiektu budowlanego.
Opcjonalne
NIE_015 System musi umożliwiać podgląd zakresu wszystkich umów dotyczących eksploatacji w kontekście wybranej nieruchomości, obiektu technicznego lub wyposażenia.
Wymagalne NIE_016 System musi umożliwiać podgląd wszystkich dokumentów kosztowych związanych z zarządzaniem nieruchomością lub obiektem technicznym w kontekście wybranej nieruchomości lub obiektu. Wymagalne NIE_017 System musi umożliwiać wyszukiwanie danych nieruchomości, wyposażenia i obiektów technicznych po wszystkich atrybutach występujących w systemie. Wymagalne Eksploatacja nieruchomości Strona 116 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
NIE_018 System musi umożliwiać przypisywanie do nieruchomości i obiektów technicznych, pracowników przypisanych organizacyjnie do danej lokalizacji. Przypisanie zasobów musi posiadać okres obowiązywania. Wymagalne NIE_019 System musi umożliwiać przypisywanie do nieruchomości i obiektów technicznych, jednostek organizacyjnych przypisanych do danej lokalizacji. Przypisanie zasobów musi posiadać okres obowiązywania. Wymagalne NIE_020 System musi umożliwiać ewidencję terminów gwarancji i rękojmi dotyczącej nieruchomości, obiektów technicznych oraz wyposażenia Wymagalne NIE_021 System musi umożliwiać ewidencję opłat związanych z zarządzaniem nieruchomością lub obiektem technicznym np. z tytułu użytkowania wieczystego nieruchomości, najmu budynków, pomieszczeń i powierzchni użytkowych, koszty mediów itp. Wymagalne NIE_022 System musi z wyprzedzeniem generować powiadomienie do uprawnionych użytkowników o upływie terminu zakończenia umów związanych z zarzadzaniem nieruchomością lub obiektem technicznym np. informacja o kończącej się umowie na sprzątanie. Okres, sposób informowania (np. email, komunikat przy uruchomieniu systemu itp.) i zakres umów do których jest ustawione przypominanie muszą być konfigurowalne. Wymagalne NIE_023 System musi zapewnić obsługę nieruchomości zgodnie z wymaganiami modułu Remonty i Obsługa Techniczna (opisanymi w dalszej części specyfikacji). Wymagalne Budżetowanie NIE_024 System musi umożliwiać ewidencjonować zobowiązania i należności wynikające z faktu posiadania i utrzymywania nieruchomości lub obiektu technicznego (np. podatki gruntowe, media, koszenie trawy itd.) Wymagalne NIE_025 System musi umożliwić tworzenie budżetów na prace remontowe, w kontekście scentralizowanego procesu budżetowania. Wymagalne NIE_026 System musi umożliwiać planowanie kosztów przeprowadzenia remontu na różnych poziomach szczegółowości. Musi umożliwić zaplanowanie ogólnych kosztów przeprowadzenia remontów (wynikających z umów) i/lub w rozbiciu szczegółowym w oparciu o podstawowe kategorie kosztów: robocizna, materiały, usługi i inne koszty. Wymagalne NIE_027 System musi umożliwiać tworzenie predefiniowanych kalkulacji dla danego rodzaju i zakresu prac i/lub kategorii obiektu. Kalkulacje muszą być tworzone w rozbiciu szczegółowym w oparciu o podstawowe kategorie kosztów: robocizna, materiały, usługi i inne koszty. Wymagalne NIE_028 System musi umożliwiać planowanie kosztów wykonania remontu na podstawie stworzonej wcześniej predefiniowanej kalkulacji dla danego rodzaju i zakresu prac i/lub kategorii obiektu. Wymagalne NIE_029 System musi umożliwiać planowanie kosztów wykonania remontu na podstawie stworzonej wcześniej kalkulacji dla podobnego zakresu prac i/lub podobnego rodzaju obiektu. Wymagalne NIE_030 System podczas planowania kosztów wykonania remontów musi umożliwić kwalifikację kosztu: remont czy inwestycja. Domyślną kwalifikacją będzie remont.
Wymagalne NIE_031 System musi umożliwić rejestrowanie i kontrolowanie wykonania planów remontów i przeglądów w układzie miesięcznym kwartalnym i rocznym.
Wymagalne Integracja NIE_032 System musi umożliwiać wiązanie wybranych nieruchomości, obiektów technicznych i wyposażenia z ewidencją środków trwałych. Wymagalne Ewidencja samochodów (pojazdów) Strona 117 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Kartoteka pojazdów SAM_001 System musi zawierać szczegółowy spis wszystkich pojazdów wykorzystywanych przez PAZP w jednym wspólnym repozytorium bazodanowym. Repozytorium będzie zawierać informacje: ‐ ewidencyjne (np. nr rejestracyjny, nr silnika, nr nadwozia itp.), ‐ eksploatacyjne (np. rodzaj paliwa, normy spalania, części zamienne, przeglądy, itp.), ‐ organizacyjne (np. grupa pojazdów, kierowca domyślny, użytkownicy, jednostka organizacyjna, itp.). Wymagalne SAM_002 System musi umożliwiać ewidencję wyposażenia pojazdów takich jak GPS, radio, itp. Ewidencja wyposażenia musi umożliwiać zachowanie historii zmian. Wymagalne SAM_003 System musi zapewnić elektroniczną ewidencję karty pojazdu. Wymagalne SAM_004 System musi zapewnić obieg karty pojazdu. Wymagalne SAM_005 System musi umożliwiać ewidencję danych o pojazdach z zachowaniem historii zmian danych. Wymagalne SAM_006 System musi umożliwiać ewidencję polis ubezpieczeniowych. W ramach danych o polisie system musi umożliwiać ewidencję m.in. okresu ubezpieczenia, ubezpieczyciela, zakresu ubezpieczenia. Wymagalne SAM_007 System musi przechowywać historię modyfikacji danych dotyczących ubezpieczenia. Wymagalne SAM_008 System musi umożliwiać ewidencję użytkowników przypisanych do pojazdów. Lista użytkowników pojazdów musi być wybierana z listy pracowników. Przypisania użytkowników do pojazdów muszą obejmować okres użytkowania. Wymagalne SAM_009 System musi umożliwiać określenie miesięcznego limitu przejechanych km w kontekście wybranego pojazdu. Miesięczny limit przejechanych km musi być zmienny w czasie, z zachowaniem historyczności zmian. Wymagalne SAM_010 System musi umożliwiać ewidencję opon zawierająca m.in. dane o rodzaju (letnia, zimowa, uniwersalna), producencie, modelu, rozmiarze, dacie produkcji oraz stanie zużycia opony. Wymagalne SAM_011 System musi umożliwiać ewidencjonowanie przypisywania opon do pojazdów (montaż i demontaż) z zachowaniem historii zmian w czasie. Wymagalne SAM_012 System powinien zapewnić obiegi dokumentacji związanej z pojazdami i historią eksploatacji np.: karta pojazdu, protokoły z napraw i przeglądów. Wymagalne SAM_013 Moduł ewidencji pojazdów musi być zintegrowany z systemem kadrowym w zakresie danych o pracownikach, wymaganych badaniach i szkoleniach dotyczących uprawnień do prowadzenia pojazdów. Wymagalne SAM_014 System musi umożliwiać wiązanie pojazdów z ewidencją środków trwałych i przechowywać m.in.. historię środków trwałych i szkody w środkach trwałych. Wymagalne Eksploatacja pojazdów SAM_015 System musi umożliwiać ewidencję protokołów zdawczo odbiorczych pojazdów. W protokole muszą zawierać się m.in. informacje o pojeździe, pracowniku, dacie przekazania, opisie stanu pojazdu, wyposażeniu dodatkowym. Wymagalne SAM_016 System musi umożliwiać ewidencja zdarzeń i szkód komunikacyjnych. Rejestr musi umożliwiać określenie pojazdu, pracownika, daty wystąpienia, opisu szkody oraz opisowy zakres i koszt ewentualnych napraw. Wymagalne SAM_017 System musi umożliwiać ewidencję wykroczeń i mandatów w kontekście wybranego pracownika i pojazdu oraz z możliwością połączenia z zaewidencjonowanym zdarzeniem komunikacyjnym. Wymagalne SAM_018 System musi mieć możliwość ewidencji stawki za 1 km przebiegu w zależności od pojemności silnika. Stawka musi być zmienna w czasie, z zachowaniem historyczności zmian. Wymagalne SAM_019 System musi umożliwiać określenie tabel norm zużycia paliwa i umożliwić przypisanie tabeli norm do pojazdu. Wymagalne Strona 118 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Tabela norm musi być zmienna w czasie, z zachowaniem historyczności zmian. SAM_020 System musi posiadać rejestr kart rozliczeń użytkowania pojazdu służbowego. System musi umożliwiać bieżące rejestrowanie stanu licznika pojazdu, czasu pracy pracownika oraz umożliwiać ewidencję dokumentów kosztowych dotyczących tankowania i zużycia materiałów eksploatacyjnych w powiązaniu ze zleceniami i miejscem powstawania kosztów. Wymagalne SAM_021 System musi umożliwiać ewidencję dziennych przebiegów pojazdów, w podziale na kilometry służbowe i prywatne. Wymagalne SAM_022 System musi umożliwiać ewidencję skanów dokumentów kosztowych związanych z pojazdem dotyczących tankowań i zakupów pozostałych materiałów eksploatacyjnych Wymagalne SAM_023 System musi umożliwiać ewidencje skanów dokumentów kosztowych dotyczących eksploatacji pojazdu w powiązaniu ze zleceniami. Wymagalne SAM_024 System musi zapewnić ewidencję kosztów eksploatacyjnych w sposób umożliwiający podział tych kosztów pomiędzy jednostki organizacyjne i miejsca powstawania kosztów. Wymagalne SAM_025 System musi z wyprzedzeniem informować uprawnionych użytkowników o upływie okresu ubezpieczenia. Okres i sposób powiadamiania (np. email, komunikat przy uruchomieniu systemu itp.) muszą być konfigurowalne. Wymagalne SAM_026 System musi umożliwiać wyszukiwanie dokumentów związanych z pojazdami wg zadanych kryteriów, np. ‐ pojazd, ‐ koszty eksploatacji, ‐ użytkownik, ‐ termin przeglądu, ‐ termin ważności polisy ubezpieczeniowej.
Wymagalne SAM_027 System musi umożliwiać dostęp do historii użytkowania pojazdów.
Wymagalne
SAM_028 System musi zapewnić obsługę pojazdów zgodnie z wymaganiami modułu Remonty i Obsługa Techniczna (opisanymi w dalszej części specyfikacji). Wymagalne Integracja SAM_029 Moduł systemu ERP do obsługi gospodarki samochodowej musi być zintegrowany z systemem sprzedażowym w zakresie rozliczanie limitów kilometrów i fakturowania pracowników za przejechane ponadlimitowe kilometry. Wymagalne SAM_030 System musi zapewnić interfejsy wymiany danych z zewnętrznym systemem dostawcy kart flotowych ORLEN. Wymagalne Raporty SAM_031 System musi zapewnić raport zużycia paliwa uwzględniający rodzaj zużytego paliwa oraz normy EURO pojazdu. Wymagalne SAM_032 System musi zapewnić raport ilości i rodzaju zakupionego paliwa do pojazdów służbowych. Wymagalne SAM_033 System musi zapewnić raport eksploatacji pojazdów służbowych w podziale na zlecenia, jednostki organizacyjne i miejsca powstawania kosztów. Wymagalne SAM_034 System musi zapewnić raport bieżącego rozdysponowania pojazdów. Wymagalne Ewidencja infrastruktury technicznej Kartoteka urządzeń infrastruktury EIT_001 System musi zapewnić ewidencję urządzeń infrastruktury CNS/ATM (obiekty, urządzenia, systemy) w jednej centralnej bazie danych. Zakres ewidencjonowanych informacji musi zawierać informacje Wymagalne Strona 119 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
księgowe, operacyjne (konstrukcja, konfiguracja, przeznaczenie, typy urządzeń, anten, nadajników, moc, wysokość zawieszenia anten, częstotliwość pracy, informacja o strukturze technicznej urządzeń na potrzeby systemu remontowego, itp.) i dokumentację techniczną. EIT_002 System musi zapewnić wyszukiwanie urządzeń infrastruktury CNS/ATM po dowolnym polu z bazy danych. Wymagalne EIT_003 System musi zapewnić konfigurację oddzielnych zestawów parametrów dla każdego typu urządzenia. Wymagalne EIT_004 System musi zapewnić ewidencję urządzeń zasilania gwarantowanego (oznaczenie urządzeń zasilania awaryjnego i ich wyszukanie według osobnego kryterium). Wymagalne EIT_005 System musi umożliwiać ewidencję informacji o sposobie przeprowadzenia przeglądu okresowego i umożliwić opisanie dodatkowych warunków przeprowadzenia takiego przeglądu np. indywidualne charakterystyki wyłączeń obiektów z ruchu na czas przeglądu. Wymagalne EIT_006 System musi zapewnić rejestr wyników przeglądów planowanych dla każdego urządzenia CNS/ATM dostępny z poziomu jego kartoteki. Wymagalne EIT_007 System musi zapewnić rejestr wyników przeglądów doraźnych dla każdego urządzenia CNS/ATM dostępny z poziomu jego kartoteki. Wymagalne Kartoteka wyposażenia EIT_008 System musi posiadać moduł/bazę danych, w którym będą przechowywane dane o urządzeniach przeciwpożarowych i gaśnicach. Wymagalne EIT_009 System powinien zapewnić ewidencję wymagań odzieży ochronnej na danym stanowisku pracy. Opcjonalne EIT_010 System powinien zapewnić monitorowanie i generowanie powiadomień dotyczących terminów wydań odzieży ochronnej na danym stanowisku pracy. Opcjonalne Kartoteka infrastruktury IT EIT_011 System musi umożliwiać prowadzenie ewidencji danych natury finansowej o majątku IT. W szczególności musi umożliwiać ewidencję informacji o kosztach nabycia sprzętu/oprogramowania, stawkach amortyzacji, bieżącej wartości przedmiotu, wartości umów serwisowych Wymagalne Eksploatacja obiektów infrastruktury i wyposażenia EIT_012 System musi zapewnić spójny widok oraz możliwość ewidencji i edycji danych dotyczących infrastruktury CNS wraz ze wszystkimi informacjami powiązanymi z tymi obiektami (min. awarie, przestoje, zawieszenia, zdarzenia, przeglądy, raporty dotyczące zdarzeń, uwagi, opisy zdarzeń, dzienniki pracy załączniki). Wymagalne EIT_013 System musi zapewnić widok i możliwość edycji danych na dany dzień operacyjny zawierający informacje dotyczące zgłoszonych zdarzeń, urządzeń, do których zostały zgłoszone zdarzenia, uwagi, skład zespołu dyżurującego itd.). Wymagalne EIT_014 System musi umożliwiać rejestrację zdarzeń występujących w infrastrukturze CNS/ATM. Zdarzenie musi zawierać m.in. informację o obiekcie, którego dotyczy, datę i opis zdarzenia. Zarejestrowane zdarzenia muszą być widoczne w kontekście wybranego obiektu. Wymagalne EIT_015 System musi zapewniać jedną centralną bazę danych z częściami zamiennymi zawierającą m.in. dane dotyczące lokalizacji i dostępności części zamiennych.
Wymagalne EIT_016 System musi zapewnić wyszukiwanie części zamiennych m.in. według kryteriów: urządzenie/nazwa części/PN/lokalizacja magazynowa/dostępność. Wymagalne EIT_017 System musi zapewnić informację o infrastrukturze (dane fabryczne, wpisy do RLUN, wyniki Wymagalne
Strona 120 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
przeglądów, stan części zamiennych, wykryte usterki i stan prac naprawczych, statystyki, parametry). EIT_018 System musi zapewnić dzienne raporty stanu infrastruktury CNS/ATM. Wymagalne EIT_019 System musi zapewnić rozliczanie zużycia mediów z przypisaniem do urządzeń i obiektów. Wymagalne EIT_020 System musi umożliwić rejestrację zużycia paliwa w agregatach prądotwórczych na podstawie faktur paliwowych (ilość, koszy zakupu, daty), z przypisaniem do danego urządzenia lub obiektu. Wymagalne EIT_021 System musi zapewnić rejestrację zużycia energii elektrycznej na podstawie faktur za energię (ilości, koszty zakupu, daty), z przypisaniem do danego urządzenia lub obiektu. Wymagalne EIT_022 System musi zapewnić informowanie o kończącym się resursie urządzenia. Wymagalne EIT_023 System musi zapewnić informowanie o upływie ważności zezwolenia operacyjnego. Wymagalne EIT_024 System musi zapewnić ewidencję i generowanie powiadomień dotyczących terminów ważności certyfikatów urządzeń CNS. Wymagalne EIT_025 System musi generowanie powiadomienia o terminie przeprowadzenia przeglądu urządzeń CNS. Wymagalne EIT_026 System musi generować powiadomienia o zbliżającym się terminie końca pozwoleń radiowych. Wymagalne EIT_027 System musi generować powiadomienia o zbliżającym się terminie końca ważności legalizacji przyrządów pomiarowych. Wymagalne EIT_028 System musi generować powiadomienia o końcu okresu użytkowania urządzeń i systemów. Wymagalne EIT_029 System musi generować powiadomienia o końcu ważności badań środowiskowych, BHP i PPOŻ. Wymagalne EIT_030 System musi generować powiadomienia o zbliżającym się końcu amortyzacji sprzętu IT. Wymagalne EIT_031 System musi generować powiadomienia o zbliżających się terminach pomiarów z zadanym wyprzedzeniem. Wymagalne EIT_032 System musi umożliwiać raportowanie wymaganych terminów działań wynikających z przepisów BHP i Ochrony Środowiska w wybranym zakresie dat (mc, kw., rok). Wymagalne EIT_033 System powinien rejestrować informacje o planowanych przeglądach PPOŻ. Opcjonalne EIT_034 System musi zapewnić podgląd do aktualnie występujących zdarzeń dot. infrastruktury CNS/ATM, a także ruchu lotniczego pochodzących z systemu ERKZ. Dane z systemu ERKZ muszą być odświeżane raz na dobę. Wymagalne EIT_035 System musi zapewnić obsługę infrastruktury technicznej i wyposażenia zgodnie z wymaganiami modułu Remonty i Obsługa Techniczna (opisanymi w dalszej części specyfikacji).
Wymagalne Integracja EIT_036 System musi umożliwiać wiązanie obiektów infrastruktury z ewidencją środków trwałych. Wymagalne
EIT_037 System musi być zintegrowany z systemem ERKZ w zakresie potrzebnym do generowania sprawozdań analitycznych. Integracja na bazie importu‐eksportu plików płaskich. Wymagalne Raporty EIT_038 System musi zapewnić raport zużycia mediów pokazujący ilość i wartość mediów zużywanych wraz ze wskazaniem na urządzenie lub obiekt i rodzaj medium. Wymagalne EIT_039 System musi zapewnić sprawozdawczość usterek i niesprawności w zakresie statystycznej kontroli procesu i planowania gotowości służb remontowych, a także planowania przeglądów i działań profilaktycznych. Wymagalne EIT_040 System musi zapewnić sprawozdawczość pracy urządzeń w zakresie statystycznej kontroli procesu i planowania gotowości służb remontowych, a także planowania przeglądów i działań profilaktycznych. Wymagalne Strona 121 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EIT_041 System musi umożliwiać przygotowanie miesięcznych raportów ECP. Wymagalne EIT_042 System musi zapewnić raport dotyczący infrastruktury CNS w podziale na rodzaje, parametry i lokalizacje urządzeń. Raport musi umożliwiać analizowanie dowolnych danych dotyczących infrastruktury CNS dostępnych w Systemie. Wymagalne Remonty i Obsługa Techniczna Wymagania ogólne ROT_001 System musi zapewnić zarządzanie działaniami dotyczącymi nieruchomości, obiektów technicznych, wyposażenia, pojazdów oraz infrastruktury technicznej CNS/ATM włączając remonty, prace związane z usuwaniem awarii, diagnostyką i zapewnieniem funkcjonowania obiektów. Wymagalne ROT_002 System musi umożliwiać wyodrębnienie elementów majątku w zależności od obszaru wykorzystania (samochody, nieruchomości, wyposażenie, infrastruktura techniczna, itp.) i udostępniać je użytkownikom w zależności od nadanych uprawnień. Wymagalne Monitorowanie pracy urządzeń ROT_003 System musi zapewnić rejestrowanie informacji o F‐gazach, w powiązaniu z urządzeniem. Wymagalne ROT_004 System musi zapewnić rejestrację i przechowywanie pomiarów dotyczących Ochrony środowiska i BHP w jednej centralnej bazie i zapewnić sprawozdawczość obligatoryjną oraz wewnętrzną. Wymagalne ROT_005 System musi zapewnić rejestrację i monitorowanie stanu urządzeń infrastruktury ATM/CNS. Wymagalne ROT_006 System musi zapewnić obliczanie i bieżące monitorowanie wskaźnika niezawodnościowego dla urządzeń i systemów CNS/ATM : MTBO. Wymagalne ROT_007 System musi zapewnić obliczanie i bieżące monitorowanie wskaźnika niezawodnościowego dla urządzeń i systemów CNS/ATM : MTBF, Wymagalne ROT_008 System musi zapewnić obliczanie i bieżące monitorowanie wskaźnika niezawodnościowego dla urządzeń i systemów CNS/ATM : MTTR, Wymagalne ROT_009 System musi zapewnić obliczanie i bieżące monitorowanie wskaźnika niezawodnościowego dla urządzeń i systemów CNS/ATM : czas pracy, Wymagalne ROT_010 System musi zapewnić obliczanie i bieżące monitorowanie wskaźnika niezawodnościowego dla urządzeń i systemów CNS/ATM : czas awaryjny, Wymagalne ROT_011 System musi zapewnić obliczanie i bieżące monitorowanie wskaźnika niezawodnościowego dla urządzeń i systemów CNS/ATM : czas przeglądów Wymagalne ROT_012 System musi zapewnić obliczanie i bieżące monitorowanie wskaźnika niezawodnościowego dla urządzeń i systemów CNS/ATM : wskaźnik terminowości. Wymagalne ROT_013 System musi generować powiadomienie o każdej zmianie parametrów pracy, wyposażenia instalacji (struktury urządzeń) powodującej konieczność wykonania pomiarów poziomów pól elektromagnetycznych dla celów BHP i ochrony środowiska.
Wymagalne ROT_014 System musi zapewnić udostępnianie plików pdf z aktualnymi wynikami pomiarów urządzeń dla celów BHP i OŚ. Wymagalne Planowanie prac obsługowych i remontowych
ROT_015 System musi umożliwiać tworzenie rocznych i wieloletnich planów Remontów i Przeglądów. Wymagalne ROT_016 System musi umożliwiać weryfikację wykorzystanego budżetu na prace remontowe podczas budowania i zatwierdzania planu remontów. Wymagalne ROT_017 System musi umożliwiać planowanie zakupów, inwestycji, kosztów operacyjnych IT. W szczególności musi umożliwiać prognozowanie potrzeb w zakresie sprzętu (np. w oparciu o dobiegający końca Wymagalne Strona 122 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
amortyzacji sprzęt, który powinien być odpowiednio wcześnie zastąpiony nowym), usług (np. w oparciu o dobiegające końca umowy serwisowe, które wymagają przedłużenia lub odpowiednio wczesnej decyzji o zastąpieniu przez inne rozwiązania), zasobów (np. uruchomienie nowego systemu wymaga zasobów o określonych kwalifikacjach). ROT_018 System musi umożliwiać ewidencję częstotliwości dokonywania przeglądów technicznych i gwarancyjnych pojazdów zawierającą m.in. częstotliwości i czasy trwania. System musi umożliwiać automatyczną generację zdarzeń typu przegląd techniczny i/lub gwarancyjny pojazdów. Wymagalne ROT_019 System musi umożliwiać ewidencję częstotliwości przeglądów okresowych nieruchomości i obiektów technicznych zawierającą m.in. częstotliwości i czasy trwania. System musi umożliwiać automatyczną generację zdarzeń typu przegląd okresowy nieruchomości i obiektów technicznych. Wymagalne ROT_020 System musi umożliwiać wygenerowanie planu przeglądów okresowych na wybrany okres czasu na podstawie zaewidencjonowanej częstotliwości przeglądów okresowych nieruchomości i obiektów technicznych. Wygenerowane dane muszą zawierać planowany termin i czas trwania czynności oraz musza być uzależnione od daty poprzedniego wykonanego przeglądu oraz od daty przejęcia obiektu do zarządzania. Wymagalne ROT_021 System musi umożliwiać ewidencję wniosków do planu przeglądów okresowych nieruchomości i obiektów technicznych. Wniosek musi zawierać informacje jakiej nieruchomości lub obiektu technicznego dotyczy, wymaganego terminu przeglądu i opisu dodatkowych warunków wykonania przeglądu. Wymagalne ROT_022 System musi umożliwiać modyfikację stworzonego już planu przeglądów okresowych, uwzględniającą przesunięcia lub wykasowanie pozycji z planu przeglądów i zmianę zasobów osobowych. Wymagalne ROT_023 System musi zapewnić prowadzenie harmonogramu przeglądów systemów elektroenergetycznych wraz z powiadamianiem o terminach przeglądów.
Wymagalne ROT_024 System musi zapewnić prowadzenie harmonogramu przeglądów systemów klimatyzacyjnych i sanitarnych wraz z powiadamianiem o terminach przeglądów. Wymagalne ROT_025 System musi umożliwiać planowanie wybranych przeglądów w podziale na mniejsze zadania i kroki milowe. W ramach zadań musi umożliwiać ewidencję terminu wykonania, zakresu zadania, planowanie zasobów pracowniczych. Wymagalne ROT_026 System musi umożliwiać zgrupowanie kilku zadań przeglądowych w jedno zlecenie przeglądowe. Wymagalne ROT_027 System musi umożliwiać planowanie zasobów pracowniczych do zadań przeglądowych. Pracownik musi być wybierany z listy wyboru. Wymagalne ROT_028 System musi generować powiadomienia dla uprawnionych użytkowników o terminie przeglądu technicznego lub gwarancyjnego. Okres i sposób powiadamiania (np. email, komunikat przy uruchomieniu systemu itp.) muszą być konfigurowalne. Wymagalne ROT_029 System musi generować powiadomienia dla uprawnionych użytkowników o upływie terminu przeglądu okresowego. Okres i sposób powiadamiania (np. email, komunikat przy uruchomieniu systemu itp.) muszą być konfigurowalne. Wymagalne ROT_030 System musi zapewnić informowanie o terminie przeprowadzenia przeglądów urządzeń/ planowanych pomiarów z powietrza/kontroli ULC. Wymagalne ROT_031 System musi umożliwiać ewidencję wniosków do planu remontów. Wniosek musi zawierać informacje o obiekcie, którego dotyczy, proponowanym terminie wykonania (możliwa jest różna dokładność dat np. konkretna data lub wybrany kwartał roku), zakresie prac, powiązaniu z umową, dodatkowych warunkach wykonania remontu. Wymagalne ROT_032 System musi umożliwiać modyfikację stworzonego już planu remontów, uwzględniającą przesunięcia lub wykasowanie pozycji z planu remontów i zmianę zasobów osobowych. Wymagalne ROT_033 System musi umożliwiać planowanie wybranych remontów w podziale na mniejsze zadania i kroki Wymagalne Strona 123 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
milowe. W ramach zadań musi umożliwiać ewidencję terminu wykonania, zakresu zadania, planowanie zasobów pracowniczych. ROT_034 System musi umożliwiać podział zadań remontowych na remonty, awarie i konserwacje. Wymagalne ROT_035 System musi umożliwiać zgrupowanie kilku zadań remontowych w jedną realizację remontową oraz kilka przeglądów w jedno zlecenie przeglądowe. Wymagalne ROT_036 System musi umożliwiać planowanie zasobów pracowniczych do zadań remontowych. Pracownik przypisywany do przeglądu musi być wybierany z listy wyboru. Wymagalne ROT_037 System musi generować powiadomienia dla uprawnionych użytkowników o terminie zakończenia okresu gwarancji i rękojmi. Okres i sposób powiadamiania (np. email, komunikat przy uruchomieniu systemu itp.) muszą być konfigurowalne. Wymagalne ROT_038 System musi umożliwiać planowanie prac konserwacyjnych, remontów sprzętu i osprzętu IT wraz z określeniem terminów niedostępności, zasobów (np. o określonych kwalifikacjach), dodatkowych potrzeb (części zamienne, użycie zapasowych sprzętów). Wymagalne ROT_039 System musi zapewnić rejestrowanie informacji o odpadach i sposobie postępowania z nimi. Wymagalne Realizacja zadań obsługowych ROT_040 System musi zapewnić ewidencję danych o przeprowadzonych oraz planowanych przeglądach, konserwacjach i naprawach urządzeń przeciwpożarowych. Wymagalne ROT_041 System musi umożliwiać przydzielanie zadań do zasobów. Podczas przydziału zadań system musi zapewnić walidację aktualnych uprawnień, badań lekarskich i odbytych szkoleń, wymaganych do realizacji zadań a także musi zapewnić walidację dostępności do wykonania zadań w danym czasie. Wymagalne ROT_042 System musi umożliwiać ewidencję wszystkich zleceń czynności i wykonanych czynności obsługowych dotyczących nieruchomości i obiektów technicznych. Zlecenia i wykonania czynności muszą posiadać możliwość powiązania z obiektem technicznym, zarejestrowanym wcześniej zdarzeniem, posiadać osobę odpowiedzialną, datę realizacji i opisem wymaganych i wykonanych prac.
Wymagalne ROT_043 System musi umożliwiać ewidencję informacji o sposobie przeprowadzenia remontu i umożliwić opisanie dodatkowych warunków przeprowadzenia takiego remontu np. indywidualne charakterystyki wyłączeń obiektów z ruchu na czas remontu. Wymagalne ROT_044 System musi umożliwiać określanie statusu zadań remontowych i przeglądów. Wymagalne ROT_045 System musi umożliwiać raportowanie zakończenia instalacji i uruchomiania urządzenia / systemu CNS/ATM. Wymagalne ROT_046 System musi umożliwiać dokumentowanie i raportowanie zamknięcia zlecenia remontowego. Wymagalne ROT_047 System musi generować powiadomienia o opóźnieniach w realizacji zadań planowych. Wymagalne ROT_048 System musi zapewnić ewidencje i monitorowanie harmonogramu wzorcowania przyrządów pomiarowych. Wymagalne ROT_049 System musi zapewnić ewidencjonowanie informacji o aktualnym stanie napraw gwarancyjnych, a także różnicować naprawy gwarancyjne od innych rodzajów napraw. Wymagalne ROT_050 System musi zapewnić prowadzenie ewidencji zleceń w powiązaniu ze zużyciem materiałowym oraz rozliczeniem godzinowym przepracowanych przez poszczególnych pracowników. System musi zapewnić możliwość przypisania koszów bezpośrednich materiałowych oraz kosztów pracy w godzinach. Ewidencja musi zapewnić automatyczną dekretację w sposób zgodny z wymaganiami ewidencji kosztów do księgi głównej. Wymagalne Dokumentacja obsługowa i remontowa ROT_051 System musi zapewnić elektroniczną ewidencję protokołu z przeglądów technicznych. Wymagalne Strona 124 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ROT_052 System musi zapewnić obieg protokołu z przeglądów technicznych. Wymagalne ROT_053 System musi zapewnić elektroniczną ewidencję protokołu odbioru końcowego remontu wraz z załącznikami. Wymagalne ROT_054 System musi zapewnić obieg protokołu odbioru końcowego remontu wraz z załącznikami. Wymagalne ROT_055 System musi zapewnić elektroniczną ewidencję protokołu z napraw i przeglądów pojazdów. Wymagalne ROT_056 System musi zapewnić obieg protokołu z napraw i przeglądów pojazdów. Wymagalne Powiadomienia ROT_057 System musi umożliwiać dowolne konfigurowanie terminów powiadomień związanych z zarzadzaniem majątkiem. Wymagalne Raporty ROT_058 System musi generować raport pokazujący listę planowanych zadań remontowych. Wymagalne ROT_059 System musi generować raport porównujący koszty planowane i poniesione. Wymagalne ROT_060 System musi generować raport porównujący prace planowane i poniesione. Wymagalne ROT_061 System musi generować raport ze stanu zadań. Wymagalne ROT_062 System musi generować raport z wytworzonych odpadów i sposobie postępowania z nimi. Wymagalne Tabela 10. Wymagania funkcjonalne ‐ Zarządzanie majątkiem 2.2.5
Wymagania dotyczące komponentu - Podsystem Zarządzanie
sprzedażą
Nr
wymagania
Wymaganie
Kategoria
wymagania
Sprzedaż usług pozanawigacyjnych Wymagania ogólne sprzedaży (nie tylko usług pozanawigacyjnych) SP_001 System musi umożliwiać dostęp do wybranych dokumentów na stronach internetowych, t.j.: zamówienia sprzedaży, tabele kursów. Wymagalne SP_002 System musi wspomagać użytkownika w poprawnym wprowadzaniu danych, poprzez ich walidację z innymi, odpowiednimi danymi posiadanymi przez System, co umożliwi prawidłowe rozliczenie usług zapewnianych przez PAZP i zmniejszenie ilości reklamacji. Wymagalne SP_003 System musi zapewnić ewidencję zadań w ramach pracy grupowej w procesie sprzedaży. Wymagalne SP_004 System musi zapewnić raportowanie czasów realizacji zadań procesu sprzedażowego dot. zamówień pozanawigacyjnych w podziale na użytkownika/komórkę organizacyjną. Wymagalne SP_005 System musi wspomagać przeglądanie rejestrów danych prowadzonych w systemie w kontekście produktu/usługi: • rejestru ofert, • rejestru umów/aneksów, • rejestru faktur, • cenników i listy cenników, • kalkulacji i rejestru kalkulacji. Wymagalne Wymagania wspólne dotyczące fakturowania (nie tylko usług pozanawigacyjnych) SP_006 System musi umożliwiać wystawianie, rejestrację i obsługę rachunkową dokumentów: faktura, faktura korygująca, faktura proforma, paragon, zaliczka. Wymagalne Strona 125 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
SP_007 System musi umożliwiać wystawianie, rejestrację faktur zbiorczych na pracowników za paliwo, rozmowy telefoniczne, sprzedaż telefonów, innych pozycji majątku firmy. Wymagalne SP_008 System musi umożliwiać rejestrację szczegółowego spisu produktów/usług do pozycji zbiorczej faktury. Musi istnieć możliwość wydruku spisu jako załącznika do faktury. Wymagalne SP_009 System musi umożliwiać wystawianie, rejestrację faktury korygującej ze względu na zmiany ilościowe, wartościowe, a także stawki podatku VAT. Wymagalne SP_010 System musi umożliwiać powiązanie dokumentu sprzedaży pozycji magazynowej potwierdzającego jej sprzedaż z dokumentem magazynowym potwierdzającym jej wydanie. Wymagalne SP_011 System musi umożliwiać definiowanie wzorców numeracji dla faktur poprzez określenie zakresów numeracji. Wymagalne SP_012 System musi umożliwiać numerację faktur w różnych grupach indeksowych. Wymagalne SP_013 System musi umożliwiać wydruk faktur w językach obcych. Wymagalne SP_014 System musi umożliwiać pojedynczy i grupowy wydruk faktur. Wymagalne SP_015 System musi umożliwiać pojedynczy i grupowy wydruk korekt faktur. Wymagalne SP_016 System musi wspierać rozsyłanie faktur drogą elektroniczną w postaci załączników. Wymagalne Oferty SP_017 System musi prowadzić rejestr ofert. Wymagalne SP_018 System musi standaryzować oferty. Określony zostanie szablon/szablony oferty, a w nim określone części oferty, wymagane pola i informacje. Wymagalne SP_019 System musi wspomagać tworzenie ofert poprzez dostęp do danych zarejestrowanych w różnych obszarach Systemu. Podczas przygotowywania oferty system musi zapewnić dostęp do kartotek danych wykorzystywanych w ofertach: • kartoteki klientów (wybranie klienta do oferty, lub dodanie nowego klienta); • kartoteki towarów i usług (wybranie produktu/usługi);kartoteki ofert; • cenników (sprawdzenie ceny produktu/usługi); • kartoteki kalkulacji cenników; • kosztorysów. Wymagalne SP_020 System musi wspomagać tworzenie ofert poprzez dostęp do danych zarejestrowanych w różnych obszarach Systemu. Podczas przygotowywania oferty system musi zapewnić dostęp do danych porównawczych: • rejestru umów i aneksów (sprawdzenie innych umów z tym klientem, lub umów na podobne usługi), • historii sprzedaży produktu/ usługi, • historii sprzedaży, stanu rozliczeń i historii rozliczeń na zadany moment, terminowość płatności dla danego klienta. Wymagalne SP_021 System musi przechowywać historię ofert. Wymagalne SP_022 System musi umożliwiać przeglądanie i wyszukiwania ofert wg określonych kryteriów wyszukiwania np. data oferty, klient, produkt, usługa. Wymagalne SP_023 System musi umożliwiać przygotowanie ofert w wybranych walutach.
Wymagalne
SP_024 System musi umożliwiać tworzenie kosztorysów i ofert w języku angielskim.
Wymagalne
SP_025 System musi umożliwiać tworzenie ofert z użyciem wskazanych cenników/skalkulowanych cen usług. Wymagalne
Strona 126 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Kalkulacja cenników SP_026 System musi umożliwiać tworzenie wzorców kalkulacji w oparciu o analityczne dane kosztowe i zadane parametry. W kalkulacji system musi mieć możliwość wykorzystania co najmniej następujących danych i parametrów: • koszty osobowe komórek biorących udział w procesie wytworzenia produktu / świadczenia usługi (Wynagrodzenia + Ubezpieczenia społeczne i inne świadczenia z tytułu wynagrodzeń); • koszty urządzeń (amortyzacja – dzienna/miesięczna); • koszty zużytych produktów/półproduktów (np. zużycie paliwa, serwis urządzeń, koszty pobranych towarów z magazynu, koszty energii ); • koszty związane z podatkami i opłatami; • koszty usług obcych; • pozostałe koszty (np. ubezpieczenia majątkowe, koszty podróży służbowych); • koszty administracyjne; • marże (procentowe i/lub wartościowe). Wymagalne SP_027 System musi umożliwiać tworzenie kalkulacji na podstawie predefiniowanych wzorców kalkulacji. Wymagalne SP_028 Na podstawie już ustalonych i zatwierdzonych wzorców kalkulacji System na żądanie użytkownika musi aktualizować wartości kalkulacji, umożliwiać modyfikację wzorca kalkulacji poprzez zmianę jego parametrów (wartości składowych) i wartości parametrów. Wymagalne SP_029 Do kalkulacji muszą być dostępne dane z innych obszarów systemu, które określą wartości wymienionych parametrów. Wymagalne SP_030 System musi umożliwiać przeliczanie wyników kalkulacji (cenę produktu/usługi) na inną walutę. Wymagalne SP_031 System musi przechowywać historię zatwierdzonych kalkulacji (wynik kalkulacji, elementy składowe, data sporządzenia, okres obowiązywania). Wymagalne SP_032 Wygenerowane, zatwierdzone i przypisane do poszczególnych produktów/usług kalkulacje muszą pozwalać na posprzedażne rozliczenie kosztów rodzajowych tj. kosztów świadczonych usług w oparciu o kalkulacje i wielkość sprzedaży. Wymagalne SP_033 System musi umożliwiać tworzenie cenników dla produktu/usługi, oraz grup produktów/usług. Wymagalne Raportowanie SP_034 System musi umożliwiać dostęp do informacji na temat osiągniętych wielkości sprzedaży (m.in. ilość, wartość) danego produktu lub usługi oraz grup produktów w określonym przedziale czasowym. Wymagalne SP_035 System musi udostępniać mechanizmy pozwalające na analizy, czy dany produkt lub usługa zanotowały spadek lub wzrost sprzedaży w zadanej jednostce czasu.
Wymagalne SP_036 System musi umożliwiać analizę porównawczą wielkości uzyskiwanych przychodów w stosunku do poniesionych kosztów w zadanym segmencie produktów/usług (lub grup) dla klientów i grup klientów. Wymagalne SP_037 System musi umożliwiać analizę wielowymiarową wartości osiągniętych przychodów ze sprzedaży produktów/usług. System musi umożliwiać analizę tych danych w ujęciach dla : • produktów/usług lub grup produktów/usług, • kontrahentów lub grup kontrahentów, • rodzajów działalności, • umów/rodzajów umów, w określonym zakresie dat. Wymagalne SP_038 System musi umożliwiać analizę wielowymiarową zaległości w płatnościach za faktury pozanawigacyjne. System powinien umożliwiać analizę tych danych w ujęciach dla : • produktów/usług lub grup produktów/usług, • kontrahentów lub grup kontrahentów, • rodzajów działalności, Wymagalne Strona 127 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
• umów/rodzajów umów, w określonym zakresie dat. SP_039 Wspomaganie rozliczeń kosztów i przychodów. System musi w oparciu o przygotowane w nim kalkulacje oraz planowaną i rejestrowaną wielkość oraz wartość sprzedaży, umożliwiać wyodrębnienie kosztów i przychodów w poszczególnych rodzajach działalności pozanawigacyjnej. Wymagalne SP_040 System musi umożliwiać analizy przychodów i kosztów na podstawie kont księgowych, z podziałem na rodzaje działalności pozanawigacyjnej. Wymagalne SP_041 System musi umożliwiać dostęp do historii sprzedaży dla danego produktu/usługi, grupy produktów. Wymagalne SP_042 System musi udostępniać zestawienia dotyczące wartości osiągniętych przychodów ze sprzedaży produktów/usług. Wymagalne SP_043 System musi udostępniać zestawienia dotyczące wartości przychodów generowanych przez poszczególne umowy pozanawigacyjne. Wymagalne SP_044 System musi umożliwiać raportowanie sprzedaży z podziałem na rodzaje działalności pozanwigacyjnej. Wymagalne SP_045 System musi umożliwiać raportowanie sprzedaży z podziałem na okresy. Wymagalne SP_046 System musi umożliwiać wydruk cenników. Wymagalne Umowy sprzedaży SP_047 System musi zapewnić obsługę umów sprzedaży w powiązaniu z Centralnym Rejestrem Umów. Wymagalne SP_048 System musi oferować szablony umów/aneksów (określone części umowy, wymagane pola i informacje). Wymagalne SP_049 System powinien umożliwiać tworzenie, przez użytkownika, własnych szablonów umów. Wymagalne SP_050 System musi wspomagać przygotowywanie umowy/aneksu poprzez dostęp do danych zarejestrowanych w systemie. Podczas tworzenia umowy musi być zapewniony dostęp do danych z: • kartoteki klientów; • kartoteki produktów i usług; • cenników; • rejestru ofert; • rejestru umów. Należy również zapewnić dostępność danych tj. historia sprzedaży dla danego klienta, stan rozliczeń, terminowość płatności. Wymagalne SP_051 System musi zapewnić możliwość powiązania umowy z cennikiem i ofertą. Wymagalne SP_052 Funkcjonalność obsługi umowy musi umożliwiać zarejestrowanie produktów/usług, których ta umowa dotyczy. Wymagalne SP_053 System musi umożliwiać waloryzację ceny umowy, gdy takie rozwiązanie będzie w niej zapisane (waloryzacja o średnioroczny wskaźnik inflacji GUS). Wymagalne SP_054 System musi generować powiadomienie (alert) o konieczności aktualizacji umowy w przypadku zmiany (aktualizacji) ogólnego cennika na produkty/usługi, jak również w przypadku zmiany w danych kontrahenta (kartoteka kontrahentów). Wymagalne SP_055 System musi umożliwiać rejestrację i aktualizację podpisanych umów i zamówień przychodowych przez komórki merytoryczne w układzie umożliwiającym prawidłowe rozliczenie i zafakturowanie usług/towarów zgodnie z obowiązującymi przepisami VAT. Wymagalne SP_056 Komórka merytoryczna rejestrująca umowę musi mieć dostęp do informacji na temat wystawionych faktur do tej umowy i zrealizowanych płatnościach/należnościach. Wymagalne SP_057 System musi umożliwiać wymianę informacji z osobami w komórkach współpracujących za pomocą Wymagalne Strona 128 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
komunikatora. SP_058 System musi umożliwiać obsługę zarówno klientów zewnętrznych jak i wewnętrznych. Wymagalne SP_059 System musi umożliwiać wnoszenie poprawek wewnętrznych na korespondencji przed wysłaniem do klienta (dopisanie tekstu, uzupełnienie). Wymagalne SP_060 System musi zapewnić jednolite repozytorium umów, z odpowiednimi poziomami uprawnień do poszczególnych rodzajów umów i danych szczegółowych w ramach CRU. Wymagalne SP_061 System musi umożliwiać śledzenie historii zawieranych umów, oraz aneksów do umów. Wymagalne SP_062 System musi dostarczać informacje na temat stopnia realizacji poszczególnych umów i wspomagać monitorowanie realizacji umowy, w tym: faktur, płatności, dostaw, dokumentów i terminów. Wymagalne SP_063 System musi dostarczać informacje na temat stanu rozliczeń finansowych związanych z umową oraz klientem. Wymagalne SP_064 System musi informować o zbliżającym się końcu umowy. Wymagalne SP_065 System musi umożliwiać chronologiczne powiązanie aneksu umowy z wcześniej podpisaną umową, tak aby możliwe było prześledzenie zmian. Wymagalne SP_066 System musi umożliwiać dezaktywację/zamykanie umowy po zakończeniu okresu jej obowiązywania, lub zakończeniu realizacji umowy. Wymagalne SP_067 System musi zapewniać konfigurowalne poziomy dostępu do rejestru umów. Wymagalne SP_068 System musi zapewniać konfigurowalne poziomy dostępu do wspólnej bazy klientów. Wymagalne Katalog sprzedaży SP_069 System musi prowadzić otwartą kartotekę indeksów produktów i usług z możliwością grupowania wg. określonych rodzajów działalności. Wymagalne SP_070 System musi umożliwiać definiowanie przez użytkownika procesów tworzenia usług/produktów. Zdefiniowany proces tworzenia usługi/produktu musi być powiązany z wzorcem kalkulacji utworzonym dla danej usługi/produktu. Wymagalne SP_071 System musi umożliwiać dostęp do informacji o aktualnych stanach magazynowych. Poziom dostępu musi być konfigurowalny dla użytkowników.
Wymagalne SP_072 System musi zapewnić definiowanie nowo wprowadzanych produktów i grup produktów AIS wraz z ich cennikami i przenoszenia/wykorzystania tych informacji na poziom zamówienia, podczas dodawania/aktualizacji zamówienia. Wymagalne SP_073 Możliwość tworzenia dokumentów sprzedaży bez definiowania indeksu ale poprzez ręczne wstawianie opisu, który pojawi sie na fakturze jako asortyment. Wymagalne Cenniki SP_074 System musi umożliwiać tworzenie cenników dla klienta. Wymagalne SP_075 System musi umożliwiać tworzenie cenników dla grup klientów. Wymagalne SP_076 Cenniki muszą mieć definiowalne okresy obowiązywania. Wymagalne SP_077 System musi umożliwiać zarządzanie cennikami poprzez definiowanie poziomu dostępu dla poszczególnych użytkowników. Wymagalne SP_078 System musi umożliwiać aktywację i dezaktywację cennika przez uprawnionych użytkowników. Wymagalne SP_079 System musi umożliwiać konfigurację cenników dla tego samego indeksu/usługi, na poziomie ogólnym domyślnym, oraz na poziomie klienta indywidualnie. Wymagalne Strona 129 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
SP_080 System musi uniemożliwić aktywację więcej niż jednego cennika tego samego typu dla tej samej usługi/indeksu w tym samym zakresie czasu. Wymagalne SP_081 System musi informować użytkownika (alert) o próbie aktywacji w Systemie dwóch cenników dla tej samej usługi/indeksu w tym samym czasie na tym samym poziomie (ogólnym lub indywidualnym klienta). System po potwierdzeniu ostrzeżenia przez użytkownika musi umożliwić taką aktywację. Wymagalne SP_082 System musi przechowywać historię zatwierdzonych cenników. Wymagalne SP_083 System musi umożliwiać definiowanie rabatów procentowych i wartościowych dla: • produktów/usług • klientów. Wymagalne SP_084 System musi umożliwiać stosowanie rabatów do: umowy, zamówienia, pozycji faktury, faktury. Wymagalne Sprzedaż usług nawigacyjnych Wymagania ogólne SPN_001 Dane dotyczące klientów,dokumentów finansowych, operacji i statków powietrznych muszą być ze sobą powiązane. System musi udostępniać intuicyjny podgląd i poruszanie się po tych danych np. przechodzenie z klienta na operacje, z faktury na klienta itp. Wymagalne SPN_002 System musi zapewnić możliwość zmiany formuły wyliczania stawek jednostek trasowych i terminalowych na poziomie konfiguracyjnym przez lokalnego administratora. Wymagalne Fakturowanie sprzedaży nawigacyjnej SPN_003 System musi zapewnić automatyczny import pliku txt generowanego z systemu walidacyjno‐
sprawozdawczego, zawierającego informacje o operacjach lotniczych (informacje na poziomie lotu t.j.: kod klienta, rodzaj samolotu, rejestracja samolotu, data i godz. wlotu i wylotu, ilość kilometrów ortodromicznej długości lotu od punktu wejścia do punktu wyjścia ze strefy pobierania opłat, typ operacji, kod zwolnienia z opłat). Wymagalne SPN_004 System musi zapewnić automatyczny import pliku FACT, generowanego przez system CRCO/ETNA, w formacie txt. Plik zawiera listę dokumentów finansowych wystawionych przez CRCO, na usługi nawigacyjne, dla strefy pobierania opłat ‘FIR Warszawa’, za dany miesiąc rozrachunkowy, na poziomie klienta. Wymagalne SPN_005 System musi zapewnić automatyczny import pliku FLBZ, generowanego przez system CRCO/ETNA, w formacie txt. Plik zawiera wszystkie operacje (na poziomie lotu) wykonane w FIR Warszawa, za dany okres rozrachunkowy, z zakresem kolumn podobnych do pliku generowanego przez system walidacyjno‐sprawozdawczy. Wymagalne SPN_006 System musi łączyć dane z plików FACT i FLBZ po unikalnym kluczu utworzonym z odpowiedniego zestawu kolumn z tych plików i rozbijać te dane na poziom lotu.
Wymagalne SPN_007 System musi zapewnić automatyczny import pliku, generowanego przez system CRCO/ETNA, w formacie txt, zawierającego informacje o wpłatach za usługi trasowe. Wymagalne SPN_008 System musi utrzymywać bazę danych o wykonanych operacjach lotniczych w powiązaniu z dokumentami finansowymi w zakresie usług nawigacji trasowych i terminalowych i tzw. lotami objętych dotacją. Wymagalne SPN_009 System musi utrzymywać bazę danych z danymi z plików FACT, FLBZ z CRCO. Wymagalne SPN_010 System musi utrzymywać archiwum z zaimportowanymi plikami z CRCO. Wymagalne SPN_011 System musi generować dokumenty finansowe za usługi trasowe, na poszczególnych kontrahentów. Faktury te muszą być generowane i ewidencjonowane poza księgą główną tzw. "ślepe faktury", nie będą księgowane ani wysyłane do klientów. "Ślepe faktury" generowane będą na podstawie danych operacyjnych z systemu walidacyjno‐
Wymagalne Strona 130 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
sprawozdawczego. Funkcjonalność ta ma zapewnić gotowe rozwiązanie, wymagające jedynie włączenia w sytuacji, kiedy fakturowanie usług trasowych stałoby się zadaniem PAŻP, a nie tak jak obecnie EUROCONTROL. Ponadto kwoty ze „ślepych faktur” muszą być porównywane i sprawdzane pod kątem niezgodności z fakturami wystawianymi przez CRCO. SPN_012 System musi generować zbiorcze faktury wewnętrzne na podstawie danych z fakturowania w CRCO. Raz w miesiącu, zgodnie z wcześniej ustalonym harmonogramem, CRCO fakturuje i udostępnia pliki zawierające informacje o zafakturowanych usługach (FACT, FLBZ) w różnych ujęciach. Na ich podstawie system ERP musi wygenerować zbiorcze faktury wewnętrzne, na których wykazane będą pozycje zbiorcze w podziale na kod podatku. Wymagalne SPN_013 System musi umożliwiać automatyczną generację faktur wewnętrznych rejestrujących sprzedaż usług nawigacji trasowej na podstawie zaimportowanych danych z plików z systemu ETNA/CRCO z podziałem na kontrahenta. Aktualnie CRCO nie udostępnia informacji o wpłatach z podziałem na kontrahenta, jednak System musi być przygotowany na to, że takie dane będą udostępniane w przyszłości. W nowym Systemie musi istnieć możliwość generacji faktur wewnętrznych z podziałem na kontrahentów na podstawie plików FACT i FLBZ. Wymagalne SPN_014 System musi mieć funkcjonalność obliczania ilości trasowych jednostek usługowych zgodnie z opisem formuły zawartym w odpowiednim rozporządzeniu Komisji UE, na podstawie danych operacyjnych importowanych z systemu walidacyjno‐sprawozdawczego.
Wymagalne SPN_015 System musi umożliwiać automatyczne utworzenie faktur za usługi terminalowe na podstawie danych operacyjnych z systemu walidacyjno‐sprawozdawczego. Wymagalne SPN_016 System musi umożliwiać wygenerowanie lub zarejestrowanie faktury zbiorczej np. za cały miesiąc, za usługi nawigacji terminalowej. Na fakturze powinna się znaleźć pozycja zbiorcza dla danego typu usługi, a cały spis usług powinien być w załączniku. Wymagalne SPN_017 System nie może dopuszczać do sytuacji, gdy jakaś operacja zostanie podwójnie zafakturowana. Wymagalne SPN_018 System musi być tak zaprojektowany, aby móc obsługiwać procesy fakturowania usług nawigacyjnych w każdym z 4 wariantów: ‐ Rozrachunki terminalowe i trasowe są obsługiwane przez PAŻP, ‐ Rozrachunki terminalowe są obsługiwane przez PAŻP, a trasowe przez CRCO, ‐ Rozrachunki trasowe są obsługiwane przez PAŻP, a terminalowe przez CRCO, ‐ Rozrachunki terminalowe i trasowe są obsługiwane przez CRCO. Wymagalne SPN_019 System musi być tak zaprojektowany, aby przejście z obecnego wariantu do innego mogło się odbyć w sposób płynny, wyłącznie poprzez zmianę parametrów Systemu. Wymagalne Reklamacje sprzedaży SPN_020 System musi umożliwiać rejestrację reklamacji i prowadzić rejestr reklamacji. Wymagalne SPN_021 System musi umożliwiać wykonywanie analiz, wskaźników i zestawień reklamacji w zakresie faktur korygujących. Wymagalne Rozliczenie sprzedaży nawigacyjnej SPN_022 System musi umożliwiać automatyczne rozliczanie faktur wewnętrznych, na podstawie danych o wpłatach udostępnianych przez CRCO. (Raz w tygodniu, zgodnie z ustalonym harmonogramem, CRCO udostępnia informacje o wpłatach w podziale na okres wykonania usługi (miesiąc). Informacje te przekazywane są do księgowości, gdzie na ich podstawie rozliczane są wewnętrzne faktury zbiorcze. Dzięki temu wiadomo, jaka część operacji wykonanych w danym okresie została już zapłacona). Wymagalne SPN_023 System musi umożliwiać rozliczanie faktur wewnętrznych za usługi trasowe z wpłatami z podziałem na kontrahentów. (Aktualnie CRCO nie udostępnia informacji o wpłatach z podziałem na kontrahenta, jednak System musi Wymagalne Strona 131 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
być przygotowany na to, że takie dane będą udostępniane w przyszłości. W nowym Systemie musi istnieć możliwość rozliczania faktur wewnętrznych z wpłatami z podziałem na kontrahentów). Harmonogramowanie sprzedaży SPN_024 System musi umożliwiać definiowanie harmonogramów do umowy. Wymagalne SPN_025 System musi zapewnić funkcjonalność automatycznej generacji zamówień na podstawie harmonogramów zdefiniowanych do umowy. Wymagalne SPN_026 System musi weryfikować zgodność danych na zamówieniu i w harmonogramie. Wymagalne SPN_027 System musi informować o zbliżającym się terminie wystawienia faktury sprzedażowej zgodnie z harmonogramem. Wymagalne Raportowanie sprzedaży nawigacyjnej SPN_028 System musi umożliwiać zawężanie zestawień sprzedaży poprzez selekcję: ‐ określonego zakresu dat; ‐ produktów/usług; ‐ grup produktów/usług; ‐ rodzajów działalności; ‐ klientów/grup klientów. Wymagalne SPN_029 System musi umożliwiać wykonywanie zestawień z podziałem wg rodzaju świadczonych usług. Wymagalne SPN_030 System musi umożliwiać sortowanie i wyszukiwanie danych wg różnych kryteriów opartych o dane w umowie czy zamówieniu. Wymagalne SPN_031 System musi umożliwiać generację zestawień, raportów i analiz dla poszczególnych kontrahentów w różnych przekrojach na podstawie danych udostępnianych przez CRCO/ETNA oraz danych z systemu walidacyjno‐sprawozdawczego. Wymagalne SPN_032 System musi porównywać kwoty fakturowane przez CRCO z odpowiadającymi im fakturami tzw. "ślepymi" wystawionymi przez System ERP na poziomie klienta i lotu. W przypadku wykrycia różnicy o określony procent (parametr do konfigurowania) system poinformuje o tym określonego użytkownika (w formie alertu na pulpit lub email) i dalej przeanalizuje różnice na poziomie operacji, za które została wystawiona faktura i umożliwi podgląd do wyników tej analizy dla użytkownika (raport z informacjami na temat różnic w rekordach i ich przyczyn) za dany okres. Wymagalne SPN_033 System musi porównywać kwoty fakturowane przez CRCO z odpowiadającymi im fakturami tzw. "ślepymi" wystawionymi przez System ERP na poziomie klienta i lotu. System zapewni generowanie odpowiedniego raportu porównawczego z informacją na poziomie operacji, za które została wystawiona faktura na temat różnic w rekordach i ich przyczyn za dany okres. Wymagalne SPN_034 System musi umożliwiać automatyczne segregowanie operacji wykonanych w przestrzeniach oddelegowanych na podstawie zadanych kryteriów. Wymagalne SPN_035 System musi wspomagać wykonywanie zestawień z podziałem na porty lotnicze. Wymagalne Zarządzanie klientami Wymagania ogólne ZKL_001 System musi umożliwić oznakowanie kolorami różnic w analizie niezgodności danych dot. operacji lotniczych otrzymanych z CRCO i systemu walidacyjno‐sprawozdawczego.
Wymagalne ZKL_002 Przy wykonywaniu porównania operacji lotniczych otrzymanych z CRCO i systemu walidacyjno‐
sprawozdawczego, system ERP musi uwzględniać różne podejście do punktów geograficznych: PAŻP – z dokładnością do minut i sekund, CRCO – jako koordynaty z dokładnością tylko do minut. Wymagalne Strona 132 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ZKL_003 System musi umożliwiać rejestrację statków powietrznych wraz z parametrami w powiązaniu z bazą klientów. Wymagalne ZKL_004 System musi umożliwiać ręczną aktualizację kartotek klientów i statków powietrznych, za pośrednictwem formularza, przez uprawnionych użytkowników. Wymagalne ZKL_005 System musi zapewnić automatyczną aktualizację kartoteki klientów i statków powietrznych na podstawie danych z pliku generowanego przez system walidacyjno‐sprawozdawczy w przypadku zmiany danych, lub pojawienia się nowych klientów. Wymagalne Kontakty z klientem ZKL_006 System musi obsługiwać rejestr kontaktów z kontrahentem: • osobiste, • telefoniczne, • e‐mailowe, • korespondencja pisemna, • notatki z rozmów / wizyt, • kalendarium spotkań (planowanie wizyt), • przygotowywanie korespondencji seryjnej do klientów: e‐mail, faks, w sposób tradycyjny (możliwość nadruku na koperty). Wymagalne ZKL_007 System powinien wspomagać nadzór nad przebiegiem współpracy z portami lotniczymi. Porty lotnicze są traktowane jako kluczowi klienci. W systemie powinna istnieć możliwość ewidencjonowania informacji o planowanych rodzajach i terminach inwestycji kluczowych klientów (portów) oraz ich wpływie na plan inwestycyjny PAŻP w lokalizacji tym porcie. Informacje te powinny wspierać planowanie własnych inwestycji (w tym kolejność realizacji inwestycji oraz terminy) w kontekście planów portów. Opcjonalne Historia klienta ZKL_008 System będzie udostępniał bezpośredni dostęp do danych dotyczących klienta t.j: ‐ historia przygotowywanych ofert; ‐ historia zawieranych umów, oraz aneksów do umów; ‐ informacje na temat stopnia realizacji poszczególnych umów; ‐ informacje na temat stanu rozliczeń finansowych; ‐ informacje na temat terminowości płatności; ‐ informacje na temat historii sprzedaży. Wymagalne ZKL_009 System musi umożliwiać przeglądanie w kontekście klienta: ‐ rejestru ofert; ‐ rejestru umów/aneksów; ‐ rejestru zamówień; ‐ rejestru faktur. Wymagalne ZKL_010 System musi zapewnić automatyczną weryfikację (z możliwością ręcznej modyfikacji) na podstawie historii zleceń, czy odbiorca zamawia produkty niepłatne czy też produkty płatne. Wymagalne ZKL_011 System musi zapewniać: • możliwość śledzenia historii zawieranych umów, oraz aneksów do umów z danym portem • informacje na temat stopnia realizacji poszczególnych umów w porcie • rozliczenia finansowe z portem • wysokość przychodów z poszczególnych działalności w porcie • analizy liczby operacji lotniczych wykonywanych w porcie. Wymagalne Rejestr Lotów Zwolnionych Wymagania ogólne Strona 133 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
RLZ_001 System musi generować Rejestr Lotów Zwolnionych zgodnie z regułami skonfigurowanymi w Systemie przez użytkownika, wynikającymi z regulacji prawnych (w przypadku zmian regulacji prawnych musi być możliwość modyfikacji reguł). Rejestr lotów zwolnionych precyzuje Ustawa Prawo Lotnicze oraz ROZPORZĄDZENIE MINISTRA TRANSPORTU, BUDOWNICTWA I GOSPODARKI MORSKIEJ z dnia 13 sierpnia 2013 r. w sprawie sposobu i trybu rozliczania i dokumentowania kosztów związanych z zapewnieniem służb żeglugi powietrznej za loty zwolnione z opłat nawigacyjnych. Wymagalne RLZ_002 System musi automatycznie uzupełniać rejestr lotów zwolnionych na podstawie danych z systemu walidacyjno‐sprawozdawczego weryfikowanego z raportem z CRCO. Wymagalne RLZ_003 System musi wspomagać generację wniosku o zwrot kosztów za świadczenie usług nawigacyjnych dla lotów zwolnionych, poprzez tworzenie raportów lotów podlegających ‐zgodnie z Prawem lotniczym‐ zwolnieniu. Wymagalne RLZ_004 System musi archiwizować wszystkie operacje lotnicze, które podlegają zwolnieniu. Wymagalne RLZ_005 System musi archiwizować wszystkie wygenerowane wnioski o zwrot kosztów z tytułu świadczenia usługi nawigacji dla lotów zwolnionych. Wymagalne Raportowanie RLZ_006 System musi umożliwiać konfigurowanie różnego rodzaju zestawień na podstawie rejestru lotów zwolnionych. Wymagalne RLZ_007 System musi umożliwiać przypisywanie uprawnień do skonfigurowanych zestawień. Wymagalne RLZ_008 System musi zapewnić integrację z innymi komponentami, w zakresie raportowania dotyczącego lotów zwolnionych. Wymagalne Integracja RLZ_009 System musi zapewniać integrację informacji z rejestru lotów zwolnionych z komponentem w ramach którego będzie realizowana kalkulacja stawek opłat nawigacyjnych. Wymagalne Zamówienie obce – obsługa zamówień klientów ZO_001 System musi umożliwiać tworzenie zamówień sprzedaży i faktur na podstawie umowy lub zamówienia przychodowego. Podczas tworzenia zamówienia sprzedaży po wybraniu numeru umowy/zamówienia przychodowego, muszą się automatycznie podczytywać dane z umowy – tj. nazwa klienta, nr ZISZP, cennik, nazwa towaru/usługi z umowy, indeks, jm, ilości, daty sprzedaży, wystawienia faktury (z góry, z dołu), kwota netto, brutto, terminy płatności faktury.
Wymagalne ZO_002 Po wybraniu umowy na zamówieniu system musi automatycznie podpowiedzieć dane z umowy. Wymagalne
ZO_003 System musi zapewnić elektroniczną wersję (z możliwością wydruku) formularza F01‐KP‐AIM z listą zamówionych publikacji jako rejestr powiązany. Wymagalne ZO_004 System musi zapewnić sprawdzenie poprawności zamówienia wystawionego ręcznie na formularzu papierowym podczas rejestracji. Zamówienie takie system musi zarejestrować jako nowe i powiązać z odbiorcą. Wymagalne ZO_005 System musi dostarczać informacji na temat możliwości realizacji zamówienia (analiza dostępności indeksu na podstawie aktualnych stanów magazynowych i rezerwacji, oraz planowanych uzupełnień). Wymagalne ZO_006 System będzie przechowywał historię zamówień. Wymagalne ZO_007 System musi zapewnić dodawanie nowego zadania (min. opis zadania i planowana data realizacji, osoba odpowiedzialna za realizację) powiązanego z zamówieniem. Wymagalne Strona 134 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ZO_008 System musi umożliwiać automatyczne generowanie dokumentu magazynowego na podstawie dokumentu sprzedaży. Wymagalne ZO_009 System musi umożliwiać automatyczne generowanie dokumentu sprzedaży na podstawie dokumentu magazynowego. Wymagalne ZO_010 System musi zapewnić ręczną rejestrację statusu aktualnego etapu realizacji zamówienia (jaki etap np. zamówienie zweryfikowane i przyjęte do realizacji, oczekiwanie na wpłatę ‐ jeśli nie obowiązuje płatność odroczona, zamówienie do wysłania‐z potwierdzoną wpłatą, zamówienie przekazane do wysyłki, planowana data realizacji, osoba odpowiedzialna i inne). Wymagalne ZO_011 System musi zapewnić przypominanie o upływających planowanych datach realizacji zamówienia. Wymagalne ZO_012 System zapewnia utrzymywanie historii realizacji poszczególnych etapów. Wymagalne ZO_013 System musi zapewnić możliwość zdefiniowania warunków, których spełnienie spowoduje automatyczna zmianę statusu zamówienia np. zmiana na "zamówienie do wysłania" po potwierdzeniu wpłaty. Wymagalne ZO_014 System będzie umożliwiał sprawdzenie czy dla zamówienia została wystawiona faktura. Wymagalne ZO_015 System powinien zapewnić automatyczne przypisywanie zadań do osób lub zespołów odpowiedzialnych za wykonanie zgodnie z określonym obiegiem lub warunkami. Opcjonalne ZO_016 System musi zapewnić wydruk etykiet adresowych zgodnie z listą publikacji do wysyłki i na podstawie danych z bazy kontrahentów, Wymagalne ZO_017 System musi zapewnić rejestrowanie wysłania przesyłki i potwierdzenia doręczenia dla odbiorców zewnętrznych i rejestracja wydania zamówienia dla odbiorców wewnętrznych. Wymagalne Raportowanie ZO_018 System musi umożliwić generowanie zestawień dotyczących zamówień sprzedaży. Wymagalne ZO_019 System musi generować raport dotyczący stanu realizacji zamówień. Wymagalne Tabela 11. Wymagania funkcjonalne ‐ Zarządzanie sprzedażą. 2.2.6
Wymagania dotyczące komponentu - Podsystem Zarządzanie
zakupami
Nr
wymagania
Wymaganie
Kategoria
wymagania
Zakupy Wymagania ogólne ZAK_001 System musi zapewniać elektroniczne uzgadnianie umowy/zamówienia na dostawę towarów/usług/robót budowlanych (w trybie PZP lub poza PZP). W rym celu zapewniona zostanie integracja z komponentem EOD lub wbudowany obieg o równoważnej funkcjonalności. Wymagalne ZAK_002 System musi wspierać obsługę umowy w okresie gwarancyjnym: protokoły z wystąpienia usterek, przeglądy gwarancyjne, protokoły z usunięcia usterek, powiązanie dokumentów z umową. Wymagalne ZAK_003 Obsługa umów zakupowych musi być realizowana w powiązaniu z Centralnym Rejestrem Umów. Wymagalne ZAK_004 System powinien umożliwiać publikację ogłoszeń dla niektórych wniosków o udzielenie zamówienia na Opcjonalne Strona 135 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
usługę na stronach PAŻP dla trybu poza PZP. ZAK_005 Akceptacja dokumentów musi być realizowana elektronicznie np. poprzez wykorzystanie elektronicznego obiegu dokumentów (komponent EOD lub obieg wbudowany o równoważnej funkcjonalności). Wymagalne ZAK_006 W Systemie wymagane jest elektroniczne zatwierdzanie Wniosków u uruchomienie zamówienia (WOUZ). Wymagalne ZAK_007 W Systemie wymagane jest elektroniczne zatwierdzanie dokumentów rozliczeniowych (faktury) stanowiących podstawę wydatków realizacji kosztów i nakładów inwestycyjnych/realizacji planu. Wymagalne ZAK_008 System musi kontrolować zatwierdzanie WOUZ i dokumentów rozliczeniowych wraz z weryfikacją etapów akceptacji tych dokumentów. W przypadku negatywnej weryfikacji na każdym z poziomów wniosek musi być automatycznie skierowany do uzupełnienia braków lub dokonania stosowanych korekt. W przypadku braku środków w danej linii budżetowej system musi umożliwiać dokonanie przesunięć (po uzyskaniu akceptacji w EOD) między liniami budżetowymi (w okrojonym zakresie) nie zmieniając wartości planu Agencji. Wymagalne ZAK_009 System musi umożliwiać monitorowanie procesu zakupowego z poziomu formularzy oraz zestawień. System musi umożliwiać monitorowanie procesu zakupowego począwszy od wystawienia wniosku zakupowego/zapotrzebowania, przygotowania WOUZ (Wniosku o udzielenie zamówienia), wyłaniania dostawcy (PZP lub poza PZP) a skończywszy na realizacji zamówienia. Wymagalne ZAK_010 System musi zapewnić elektroniczną wersję (z możliwością wydruku) formularza F01‐KP‐AIM (Formularz zamówienia NOTAM) z listą zamówionych publikacji jako rejestr powiązany.
Wymagalne ZAK_011 System musi zapewnić ewidencję zadań w ramach pracy grupowej w procesie zakupowym. Wymagalne
ZAK_012 System musi zapewnić raportowanie czasów realizacji zadań procesu zakupowego w podziale na użytkownika/komórkę organizacyjną.
Wymagalne ZAK_013 System musi zapewniać w ramach obsługi procesów zakupu możliwość ewidencji przyczyny opóźnienia na podstawie wartości definiowanego słownika. Wymagalne ZAK_014 W systemie w ramach obsługi procesu zakupowego musi być prowadzony rejestr zdarzeń, które mają wpływ na terminowość realizacji postępowania zakupowego. (zakłada się możliwość konfiguracji funkcjonalności w ramach komponentu EOD.) Wymagalne Zarządzanie dostawcami ZAK_015 System powinien zapewniać informację o cenach i upustach dla towarów oferowanych przez dostawcę. Opcjonalne ZAK_016 System musi informować o historii zakupów dokonywanych przez PAŻP u danego dostawcy, oraz dostarczać statystyk terminowości i jakości dostaw. Wymagalne ZAK_017 System musi informować o osobie kontaktowej u dostawcy, jej danych kontaktowych (telefon, e‐mail, data aktualizacji danych kontaktowych). Wymagalne ZAK_018 System musi zawierać informację o warunkach handlowych dostawcy. Wymagalne Obsługa wniosków zakupowych ZAK_019 System musi zapewnić rejestr WOUZ (obecny RWZ). Wymagalne ZAK_020 System musi obsługiwać Zapotrzebowanie zakupu (WOUZ) realizowane w ramach procedury zakupowej, (obecnie wykorzystuje RWZ.) Wymagalne ZAK_021 System musi zapewniać zarządzanie wnioskami zakupowymi WOUZ różnych realizatorów. Wymagalne ZAK_022 System musi zapewnić wyszukiwanie wniosków zakupowych WOUZ będących w trakcie realizacji (kryteria: nr wniosku, przedmiot zamówienia). Wymagalne Strona 136 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ZAK_023 System musi zapewnić wsparcie realizacji zakupów przez "wyspecjalizowaną jednostkę wykonawczą" na podstawie planu zakupów poszczególnych komórek zestawionych i zatwierdzonych w bazie danych. Wymagalne ZAK_024 System musi umożliwiać planowanie zakupów na podstawie zapotrzebowań i WOUZ rejestrowanych w systemie poprzez poszczególne jednostki PAŻP Wymagalne ZAK_025 System podczas planowania zakupów musi umożliwiać wskazanie jakiego celu strategicznego zakup dotyczy. Wymagalne ZAK_026 System musi umożliwiać rejestracji zapotrzebowania zakupu przez każdą komórkę organizacyjną Agencji. Wymagalne ZAK_027 System musi umożliwiać przygotowanie wniosku zakupowego WOUZ na podstawie zapotrzebowania Wymagalne ZAK_028 System musi umożliwiać przygotowanie wniosku zakupowego WOUZ z pominięciem zapotrzebowania Wymagalne ZAK_029 W systemie musi istnieć powiązanie pozycji wniosku zakupowego WOUZ z pozycjami zapotrzebowań dla wniosków powstałych z zapotrzebowań. Wymagalne ZAK_030 System musi umożliwiać rejestrację wniosku zakupowego WOUZ oraz jego uzgadnianie w formie elektronicznej, z pominięciem formy papierowej. Wymagalne ZAK_031 Zatwierdzony wniosek zakupowy musi mieć określony tryb postępowania: PZP lub poza PZP. Wymagalne ZAK_032 System musi umożliwiać agregację wielu zapotrzebowań na zakup z wielu jednostek organizacyjnych na jeden wniosek zakupowy. Wymagalne ZAK_033 System musi umożliwiać tworzenie z jednego zapotrzebowania wielu wniosków zakupowych. Wymagalne ZAK_034 System musi umożliwiać odnotowanie powołania zespołu negocjacyjnego oraz rejestracje jego prac w powiązaniu z rozpatrywanym wnioskiem zakupowym. Wymagalne ZAK_035 System musi posiadać możliwość powiązania z pozycjami planu dokumentów związanych z dokonanym zakupem m.in. WOUZ, umowa, itp. Taka struktura powiązań jest niezbędna w celu zapewnienia kontroli przekroczenia planu. System musi zabezpieczać przed przekroczeniem planu w poszczególnych liniach budżetowych kosztów operacyjnych w skali roku. Wymagalne ZAK_036 Każdy dokument rozliczający zakup poprzedzony musi być WOUZ lub zamówieniem zweryfikowanym z budżetem i posiadać ścisłe z nim powiązanie i pełną zgodność w każdym zakresie (elemencie segmentu linii planistycznej i czasu).System musi zapewniać odpowiednią obsługę w przypadku kiedy zakup nie jest zgodny ze zweryfikowanym WOUZ, tak aby nie dopuścić do przekroczenia planu. Wymagalne ZAK_037 System musi posiadać możliwość zautomatyzowanej kontroli wykonania budżetu w oparciu o zatwierdzane wnioski zakupowe (z uwzględnieniem pozycji budżetowych, struktury, inwestycji, projektów) we wskazanym horyzoncie czasowym.
Wymagalne ZAK_038 System musi zapewniać kontrolę środków i komunikować odpowiednio w przypadku, gdy koszty na poziomie wnioski o uruchomienie zamówienia (WOUZ) lub zamówienia przekraczają budżet. Wymagalne ZAK_039 System musi blokować możliwość zatwierdzenia WOUZ w przypadku braku wolnych środków. W przypadku konieczności przesunięcia środków umożliwiających realizację zakupu niezbędna jest stosowna ścieżka akceptacji wprowadzonych zmian. Wymagalne ZAK_040 System powinien umożliwiać przygotowywanie Opisu przedmiotu zamówienia (OPZ) w jednym miejscu w Systemie, do którego miałyby dostęp wskazane osoby. Wymagalne Zapytania i oferty
ZAK_041 System powinien umożliwiać wysyłanie zapytań ofertowych do dostawców na podstawie danych na wniosku zakupowym oraz przygotowywanych w systemie szablonów zapytań ofertowych. Opcjonalne Strona 137 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ZAK_042 System musi umożliwiać definiowanie szablonów zapytań ofertowych przez uprawnionych pracowników. Wymagalne Zamówienia własne Obsługa zamówień ZW_001 System musi zapewniać obsługę procesu dostawy zarówno pozycji magazynowych jak i pozycji niemagazynowych. Wymagalne ZW_002 System musi umożliwiać rejestrację protokołu z dostawy oraz elektroniczne powiązanie protokołu z fakturą zakupową i ewentualnym dokumentem przyjęcia na magazyn. Wymagalne ZW_003 System musi umożliwiać pełne monitorowanie umowy lub zamówienia zakupu (musi być widoczne co jest kupowane, terminy dostaw, terminy realizacji wyodrębnionych etapów umowy, po których realizowana jest płatność, pilnowane zwalnianie zabezpieczenia należytego wykonania umowy, harmonogram płatności ‐ pilnowanie faktur by były płacone w terminie). Wymagalne ZW_004 System musi wspierać weryfikację faktury zakupowej za zgodność z umową (np. czy nie została przekroczona wartość umowy). Wymagalne ZW_005 System musi zapewnić sprawdzenie poprawności zamówienia i wpisanie danych z papierowego formularza jako nowe zamówienie w systemie i powiązanie z odbiorcą. Wymagalne ZW_006 System musi zapewnić ręczną zmianę statusu aktualnego etapu realizacji zamówienia (jaki etap np. zamówienie zweryfikowane i przyjęte do realizacji, oczekiwanie na wpłatę ‐ jeśli nie obowiązuje płatność odroczona, zamówienie do wysłania‐z potwierdzoną wpłatą, zamówienie przekazane do wysyłki, planowana data realizacji, osoba odpowiedzialna i inne). Wymagalne ZW_007 System musi zapewnić przypominanie o upływających planowanych datach realizacji i utrzymywanie historii realizacji poszczególnych etapów. Wymagalne ZW_008 System musi zapewnić możliwość zdefiniowania warunków, których spełnienie spowoduje automatyczna zmianę statusu zamówienia np. zmiana na "zamówienie do wysłania" po potwierdzeniu wpłaty. Wymagalne ZW_009 System musi zapewnić dodawanie nowego zadania (min. opis zadania i planowana data realizacji, osoba odpowiedzialna za realizację) powiązanego z zamówieniem. Wymagalne ZW_010 System powinien zapewnić automatyczne przypisywanie zadań do osób odpowiedzialnych za wykonanie zgodnie z określonym obiegiem lub warunkami. Opcjonalne ZW_011 Jednostka zamawiająca (Inicjator) musi mieć możliwość wglądu do informacji związanych z realizacją jej zamówienia (między innymi na jakim etapie jest postępowanie, jaka jest wartość zamówienia wynikająca z przeprowadzonego postępowania, kto jest dostawcą, kiedy planowana jest dostawa oraz innych parametrów w zależności od posiadanych uprawnień). Dane w zależności od posiadanych uprawnień muszą być dostępne na formularzach systemu oraz na zestawieniach. Wymagalne ZW_012 Obieg zamówień musi być realizowany za pomocą zintegrowanego komponentu EOD lub obiegu o równoważnej funkcjonalności wbudowanej w moduł. Wymagalne Gospodarka magazynowa Wymagania ogólne GM_001 System musi umożliwiać wycenę magazynu wg ceny średniej ważonej. Wymagalne GM_002 System musi umożliwiać wycenę magazynu wg metody FIFO. Wymagalne GM_003 System musi umożliwiać wycenę magazynu wg cen ewidencyjnych. Wymagalne GM_004 System musi umożliwiać definiowanie i obsługę dowolnej liczby magazynów o różnych typach. Wymagalne Strona 138 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
GM_005 System w zależności od posiadanych uprawnień musi umożliwiać dostęp do danych finansowych na poziomie magazyniera lub innego użytkownika modułu magazynowego (cena, wartość). Wymagalne GM_006 Po wprowadzeniu towaru na stany magazynowe przez Realizatora/Opiekuna Asortymentu, a następnie przyjęciu towaru do magazynu przez Magazyniera, system musi automatycznie powiadamiać kierowników jednostek o tym, że zamawiany przez nich asortyment jest już dostępny. Wymagalne GM_007 System powinien umożliwiać prowadzenie magazynów pozabilansowych. Na takich magazynach powinna istnieć możliwość ewidencji towarów z cenami i wartością oraz z pominięciem ceny i wartości. Opcjonalne GM_008 System powinien umożliwiać dla indeksów magazynowych przyporządkowanie kont księgowych oraz różnych stawek VAT. Wymagalne GM_009 System powinien umożliwiać prowadzenie ewidencji ilościowo – wartościowej operacji magazynowych w rzeczywistych cenach zakupu. Wymagalne Kartoteki magazynowe GM_010 System musi umożliwiać definiowanie wzorców indeksu magazynowego. Wymagalne GM_011 Wzorzec indeksu musi składać się z segmentów dla których musi istnieć możliwość określenia czy wpływa na numer kolejny. Wymagalne GM_012 Wzorzec indeksu musi składać się z segmentów dla których musi istnieć możliwość przyjmowania wartości alfa‐numeryczne o określonej długości. Wymagalne GM_013 Wzorzec indeksu musi składać się z segmentów dla których musi istnieć możliwość określenia listy wartości dla segmentu indeksu. Wymagalne GM_014 Wzorzec indeksu musi składać się z segmentów dla których musi istnieć możliwość uzależnienia segmentu od danych uzupełnianych na towarze podczas jego rejestracji np. czy jest to towar/opakowanie/usługa. Wymagalne GM_015 Słownik indeksów magazynowych musi funkcjonować w ramach globalnego słownika towarów i usług. Wymagalne GM_016 System musi umożliwiać przypisanie zatwierdzonych towarów do wybranych kartotek magazynowych (wybranych magazynów) lub do wszystkich magazynów w zależności od przyjętej konfiguracji systemu. Wymagalne GM_017 System musi umożliwiać powiązanie towaru z grupami towarowymi, które będą mogły zostać wykorzystane podczas filtrowania danych dla raportów lub grupowania danych na raportach. Wymagalne GM_018 System musi umożliwiać powiązanie towaru z kodem klasyfikacji PKWiU, CPP, CPV. Wymagalne GM_019 System powinien umożliwiać rejestrację indeksów, kodów EAN i nazw towarów funkcjonujących u dostawców wraz z powiązaniem ich z indeksami magazynowymi funkcjonującymi w PAŻP. Opcjonalne GM_020 System powinien umożliwiać przyjęcie towaru na magazyn na podstawie indeksu dostawcy powiązanego z indeksem funkcjonującym w PAŻP.
Opcjonalne GM_021 System powinien umożliwiać obsługę kodów kreskowych na magazynie podczas przyjęcia, wydania oraz inwentaryzacji magazynu. Opcjonalne GM_022 System musi zapewnić definiowanie nowo wprowadzanych produktów i grup produktów AIS wraz z ich cennikami i przenoszeni tych informacji na poziom zamówienia, podczas dodawania/aktualizacji zamówienia. Wymagalne GM_023 System powinien zawierać informację o dostawcach danego indeksu w przypadku pozycji zakupowej. Opcjonalne Planowanie zaopatrzenia GM_024 System musi posiadać mechanizm pozwalający na określenie minimalnych, dopuszczalnych stanów poszczególnych indeksów magazynowych. Wymagalne GM_025 System musi posiadać mechanizm pozwalający na określenie maksymalnych, dopuszczalnych stanów Wymagalne Strona 139 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
poszczególnych indeksów magazynowych. GM_026 System musi posiadać mechanizm wykrywania i raportowania przekroczenia stanów minimalnych przez wydania oraz dokonane rezerwacje magazynowe. Wymagalne GM_027 Po osiągnięciu wskazanego progu system musi informować wybraną osobę lub/i grupę osób odpowiedzialnych o zaistniałym fakcie (komunikat systemowy, e‐mail). Wymagalne GM_028 System musi zapewnić generowanie elektronicznego zamówienia na zasoby potrzebne do produkcji, na podstawie informacji o przekroczeniu stanów minimalnych. Wymagalne GM_029 System musi posiadać mechanizm ciągłej aktualizacji informacji o stanach magazynowych na podstawie rejestracji wszelkich operacji magazynowych dotyczących danego indeksu, w szczególności przyjęć, wydań, oraz rezerwacji. Wymagalne GM_030 System musi umożliwiać prowadzenie gospodarki magazynowej w ramach grup indeksów, takich jak materiały elektrotechniczne, materiały klimatyzacyjne. Wymagalne GM_031 System musi posiadać funkcjonalność automatycznego planowania potrzeb materiałowych na poziomie całej firmy, oraz na poziomie każdej lokalizacji magazynowej. Wymagalne GM_032 System musi umożliwiać prowadzenie ewidencji indeksów magazynowych w podziale na materiały, półprodukty i produkty gotowe. Wymagalne GM_033 System musi mieć możliwość określenia daty przydatności/ważności dla każdego indeksu magazynowego. Wymagalne GM_034 System musi mieć możliwość skonfigurowania mechanizmu powiadamiania o przekroczeniu progów ilościowych po zatwierdzeniu dokumentu przyjęcia/wydania. Wymagalne GM_035 System musi mieć możliwość wykonania mechanizmu powiadamiania o przekroczeniu progów ilościowych za pomocą zadania systemowego uruchamianego cyklicznie, np. raz dziennie o godzinie 06:00 ‐ lub rozwiązanie równoważne. Wymagalne GM_036 System musi mieć możliwość wyodrębnienia grupy środków na potrzeby wyszukiwania w systemie magazynowym. Wymagalne Operacje i dokumenty magazynowe GM_037 W ramach magazynów system musi umożliwiać obsługę dokumentów w ramach następujących kategorii: ‐ PZ ‐ przyjęcie zewnętrzne od dostawcy, ‐ WZ ‐ wydanie zewnętrzne na sprzedaż lub przekazanie odpadu, ‐ MM (MM‐, MM+) ‐ przesunięcie pomiędzy magazynami, ‐ RW ‐ wydanie wewnętrzne, ‐ PW ‐ przyjęcie wewnętrzne, ‐ BO ‐ bilans otwarcia, ‐ INW – inwentaryzacja, ‐ AS – arkusz spisowy, ‐ NAM – nadwyżki magazynowe, ‐ NIM – niedobory magazynowe, ‐ ZW – zwroty na magazyn, ‐ dokumenty korygujące (dla PZ, WZ, MM, RW, BO). Wymagalne GM_038 W ramach kategorii dokumentów musi istnieć możliwość definiowania dowolnej liczby rodzajów dokumentów. Wymagalne GM_039 W Systemie musi istnieć możliwość definiowania wzorców numeracji dla zdefiniowanych rodzajów dokumentów. Wymagalne Strona 140 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
GM_040 System powinien umożliwiać rejestrację oraz wykorzystanie przeliczników jednostek miar dla towarów. Np. powinna istnieć możliwość przyjęcia danego towaru do magazynu w kartonie a wydawania go zarówno w kartonach jak i w sztukach. Opcjonalne GM_041 Korekta dokumentu przychodowego musi powodować automatyczną korektę dokumentów związanych z rozchodem towarów z korygowanego dokumentu. Wymagalne GM_042 System musi umożliwiać konfigurację uprawnień do dokumentów magazynowych: ‐ możliwość wprowadzania, edycji dokumentu dla osób uprawnionych. Wymagalne GM_043 System musi mieć możliwość wielostopniowej akceptacji dokumentu magazynowego przez uczestników procesu magazynowego zgodnie z uprawnieniami. Wymagalne GM_044 System musi mieć możliwość tworzenia profili uprawnień użytkowników a następnie powiązania tych profili z użytkownikami. Wymagalne GM_045 Uprawnienia użytkownika muszą dotyczyć magazynu oraz rodzaju dokumentu w ramach danego magazynu. Wymagalne GM_046 System musi umożliwiać rejestrację oraz wydruk dodatkowych szczegółów dla dokumentu lub jego pozycji zidentyfikowanych oraz skonfigurowanych podczas konfiguracji oraz eksploatacji modułu magazynowego. Wymagalne GM_047 System musi umożliwiać rejestrację korekt dokumentów magazynowych pod kątem ilościowym lub/i wartościowym w zależności od posiadanych uprawnień oraz typu dokumentu. Wymagalne GM_048 Na dokumentach rozchodowych użytkownik musi mieć możliwość wyłącznie korekty ilości. Wymagalne GM_049 System musi umożliwiać generowanie poleceń wydań towaru z magazynu (RW) dla każdej komórki organizacyjnej na podstawie zapotrzebowań złożonych przez daną komórkę. Wymagalne GM_050 Uprawnione osoby (np. Kierownicy jednostek) muszą mieć możliwość akceptacji zapotrzebowań magazynowych, powodującej rezerwację danego indeksu w Systemie. Wymagalne GM_051 Uprawnione osoby (np.. Kierownicy jednostek) muszą mieć możliwość wprowadzenia w systemie dokumentu, który zarezerwowałby dla nich dany towar na magazynie. Wymagalne GM_052 System musi umożliwiać Realizatorowi/Opiekunowi Asortymentu lub komórce organizacyjnej (w przypadku zakupów samodzielnie realizowanych przez komórkę) alokowanie towaru na poszczególnych użytkowników (w ramach realizacji wniosków zakupowych, w momencie przyjęcia towaru na magazyn). Wymagalne GM_053 Po przyjęciu towaru na magazyn na podstawie wniosku zakupowego system musi na żądanie użytkownika lub/i na podstawie dodatkowej konfiguracji zapewnić możliwość alokowania zamówionego towaru dla jednostek, które go zamówiły. Alokacja będzie polegać na zarejestrowaniu przydziału konkretnych towarów znajdujących się na stanach magazynowych i jednoczesnym wysłaniu informacji do komórek, które go zamówiły. Na przydziale musi widnieć co najmniej informacja o komórce zamawiającej oraz dokumencie zamówienia z którego będzie wynikała realizacja wydania z magazynu. Wymagalne GM_054 System musi umożliwiać wprowadzanie zakupionych towarów na magazyny, każdej komórce organizacyjnej PAŻP (także w przypadku zakupów samodzielnie realizowanych przez komórkę). Wymagalne GM_055 System musi zapewnić spójność informacji pomiędzy modułem Gospodarka magazynowa i Ewidencja majątku. Wydanie z magazynu środka (środka nisko‐cennego lub środka trwałego) musi mieć ścisłe powiązanie z dokumentem przekazania Środka w Ewidencji majątku. Magazynier musi mieć możliwość wydruku lub/i elektronicznego potwierdzenie odbioru z magazynu dla/na obu dokumentów. Wymagalne GM_056 System musi zapewnić spójność informacji między modułami Gospodarka magazynowa i Księgowość. Dokumenty magazynowe przygotowywane i zatwierdzane w Module magazynowym muszą zawierać niezbędne parametry konieczne do prawidłowej dekretacji w module Księgowym. System musi umożliwiać stosowanie podpowiedzi przy wprowadzaniu dokumentów umożliwiających ich dekretację. Wymagalne Strona 141 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
GM_057 System musi mieć możliwość przypisanie pozycji budżetu do pozycji zamówienia/zapotrzebowania. Wymagalne GM_058 System musi mieć możliwość blokowania realizacji zamówień/zapotrzebowań bez przypisanej pozycji budżetowej. Wymagalne GM_059 Kod pozycji budżetowej pozycji zamówienia magazynowego musi być widoczny na dokumentach magazynowych związanych z realizacją zamówienia dla tej pozycji dla linii zamówienia z podziałem na MPK. Wymagalne GM_060 System musi ostrzegać przed akceptacją zapotrzebowania związaną przekroczeniem limitu budżetowego danej jednostki organizacyjnej. Wymagalne GM_061 Na dokumencie magazynowym musi istnieć możliwość wskazania osoby lub grupy osób, które będą mogły odebrać asortyment wskazany przez Realizatora. Wymagalne GM_062 W momencie wydania magazynier musi mieć możliwość odnotowywania informacji o osobie odbierającej asortyment. Wymagalne GM_063 System musi zapewnić spójność informacji między modułami: Gospodarka magazynowa oraz Zarządzania umowami. Musi istnieć możliwość automatycznego lub/i ręcznego powiązania z umową/zamówieniem na podstawie, której realizowane jest przyjęcie na magazyn. Musi istnieć możliwość powiązania zarówno pozycji jak i samego dokumentu z umową/zamówieniem. Wymagalne GM_064 System musi zapewnić spójność informacji między modułami: Gospodarka magazynowa i Zarządzanie zakupami. Podczas rejestracji przyjęcia oraz wydania z magazynu musi istnieć możliwość automatycznego lub/i ręcznego powiązania pozycji dokumentu z pozycją realizowanego zapotrzebowania lub/i pozycją wniosku zakupowego. Wymagalne GM_065 System musi umożliwiać rejestrację zwrotów wg wartości z wydania. System musi umożliwić rejestrację zwrotu polegająca na wskazaniu dokumentu, dla którego ma nastąpić zwrot, jego pozycji oraz wprowadzenia zwracanej ilości. Ceny oraz wartości muszą zostać podpowiedziane z dokumentu wydania. Musi również istnieć możliwość rejestracji zwrotu bez wskazania na dokument źródłowy. Wymagalne GM_066 System musi umożliwiać definiowanie wzorców numeracji dla dokumentów magazynowych oraz automatyczne nadawanie numerów dla dokumentów magazynowych podczas ich rejestracji. Wymagalne GM_067 System musi umożliwiać automatyczne powiązanie pozycji PZ (dokument przyjęcia na magazyn) z pozycją faktury zakupowej. Wymagalne GM_068 W systemie powinna być prowadzona cała ewidencja wytworzonych odpadów także odpadów wytworzonych poza Środkami Trwałymi, wraz z ich historią.
Opcjonalne Odzież robocza GM_069 System musi posiadać elektroniczną kartotekę przydziału odzieży i obuwia roboczego dla pracowników Wymagalne
GM_070 Elektroniczna kartoteka przydziału odzieży musi zawierać w szczególności: ‐ imię i nazwisko pracownika (dane z ewidencji kadrowej), stanowisko, ‐ listę asortymentu który się należy (powinna istnieć możliwość definiowania oraz podpowiadania listy asortymentu na podstawie stanowiska pracownika) , ‐ możliwość określenia do kiedy dany asortyment się należy (data graniczna np. związana zakończeniem umowy o pracę), ‐ dla poszczególnych pozycji asortymentu okres co jaki należy się dany asortyment (okres powinien podpowiadać się na podstawie stanowiska pracownika), ‐ dla poszczególnych pozycji asortymentu możliwość rejestracji rozmiarów pracownika oraz możliwość przechowywania historii zmian rozmiarów pracownika. Wymagalne GM_071 Elektroniczna kartoteka przydziału odzieży musi w szczególności umożliwiać: ‐ rozplanowane automatycznie daty wydań w przód na co najmniej 5 lat (system powinien dawać Wymagalne Strona 142 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
możliwość konfiguracji na jaki okres mają zostać rozplanowane wydania oraz uwzględniać ewentualną datę graniczną), ‐ automatyczne odnotowane faktycznej daty wydania, ‐ automatycznie przeliczone daty planowanych kolejnych wydań po faktycznym wydaniu, ‐ możliwość wstrzymania wydań w związku z rozwiązaniem umowy o pracę lub zmianą stanowiska pracy, ‐ możliwość wstrzymania wydań lub/i przesunięcia wydań w związku z długą nieobecnością w pracy, ‐ możliwość częściowej lub całkowitej zmiany asortymentu który się należy (przy zmianie system powinien usunąć pozycje z planu które nie będą już wydawane i automatycznie wstawić nowe pozycje planu) ‐ możliwość zmiany częstotliwości wydań z równoczesnym automatycznym przeliczeniem planów (zmiana częstotliwości może wynikać np. ze zmiany procedur wewnętrznych). GM_072 System musi automatycznie powiadamiać pracownika lub/i jego kierownika o konieczności odbioru odzieży w wyznaczonym terminie (za pomocą komunikatów systemowych lub/i za pomocą wiadomości e‐mail). Wymagalne GM_073 W przypadku braku odbioru odzieży w wyznaczonym terminie system musi wysyłać ponaglenia według zadanej w konfiguracji częstotliwości. Wymagalne GM_074 Po wydaniu przydziału dla pracownika (odzież i obuwie robocze) system musi automatycznie aktualizować datę faktycznego wydania w „Elektronicznej kartotece przydziału odzieży i obuwia roboczego” oraz aktualizować plany kolejnych wydań (daty kolejnych wydań).
Wymagalne GM_075 W ramach elektronicznej kartoteki wydań odzieży i obuwia roboczego muszą być dostępne następujące zestawienie: ‐ Planowany asortyment wydań w zadanym okresie (pracownik, stanowisko, asortyment, rozmiar). Wymagalne GM_076 W ramach elektronicznej kartoteki wydań odzieży i obuwia roboczego muszą być dostępne następujące zestawienie: ‐ Planowany budżet na asortyment w zadanym okresie (asortyment, ilość, cena jednostkowa na podstawie ostatniego wydania lub możliwość wprowadzenia ceny jeśli nie było jeszcze wydań, wartość). Wymagalne GM_077 W ramach elektronicznej kartoteki wydań odzieży i obuwia roboczego muszą być dostępne następujące zestawienie: ‐ Planowany asortyment wydań w zadanym okresie (pracownik, stanowisko, asortyment, rozmiar) pomniejszony o asortyment dostępny aktualnie na magazynie. Wymagalne Urządzenia IT GM_078 System musi przekazywać informacje służbie IT o przyjęciu sprzętu IT na magazyn (wraz z jego podstawowymi danymi i nr inwentarzowym – jeżeli jest już nadany). Wymagalne GM_079 System musi przekazywać informacje służbie IT o gotowości wydania sprzętu z magazynu – z przekazaniem jego podstawowych danych i nr inwentarzowym. Wymagalne Raportowanie GM_080 W Systemie musi być dostępne zestawienie pobrań danego asortymentu w zadanym okresie przez poszczególne osoby, z podaniem daty, ilości, ceny , wartości. Wymagalne GM_081 W Systemie musi być dostępne zestawienie pobrań danego asortymentu w zadanym okresie przez poszczególne komórki organizacyjne z podaniem ilości, ceny, wartości. Wymagalne GM_082 W Systemie musi być dostępne zestawienie obrotów magazynowych, syntetyczne i analityczne. Wymagalne GM_083 W Systemie musi być dostępne zestawienie stanów magazynowych bieżących. Wymagalne GM_084 W Systemie musi być dostępne zestawienie stanów magazynowych na zadany dzień. Wymagalne GM_085 W Systemie musi być dostępne zestawienie struktury wiekowej towarów. Wymagalne Strona 143 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
GM_086 W Systemie musi być dostępne zestawienie towarów zarezerwowanych. Wymagalne GM_087 W Systemie musi być dostępne zestawienie towarów dla których określono stany minimalne, maksymalne wraz ze wskazaniem aktualnego stanu i czy został osiągnięty wskazany próg. Wymagalne GM_088 Dla raportów modułu gospodarki magazynowej musi istnieć możliwość zawężania prezentowanych danych między innymi do ‐ dat/daty, ‐ towaru lub grupy towarowej, ‐ rodzaju dokumentu, ‐ osoby/osób pobierających, ‐ komórek organizacyjnych, ‐ miejsca powstawania kosztu, ‐ umowy/zamówienia, ‐ pozycji budżetowej. Wymagalne GM_089 System musi zapewnić dostęp do informacji o przyjęciach do ewidencji magazynowej towarów (materiałów, części zamiennych) lub do użytkowania tych składników majątku własnego lub składników użytkowanego mienia obcego, które mogą podlegać ochronie ubezpieczeniowej. Wymagalne Inwentaryzacja GM_090 System musi umożliwiać obsługę inwentaryzacji. Wymagalne GM_091 System musi umożliwiać wygenerowania arkuszy spisu inwentaryzacyjnego magazynów z systemu. Wymagalne GM_092 W ramach inwentaryzacji danego magazynu i inwentaryzacji musi istnieć możliwość wygenerowania wielu arkuszy spisowych. Wymagalne GM_093 System musi posiadać opcje generacji pozycji arkusza: ‐ wszystkie towary z kartoteki, ‐ wybrana grupa, ‐ wybrane towary. Wymagalne GM_094 Dla arkusza inwentaryzacyjnego musi istnieć możliwość dodatkowego zawężenia według jednego z kryteriów: ‐ wszystkie towary z kartoteki, ‐ dostępne aktualnie na magazynie, ‐ dostępne w magazynie oraz te które wykazywały ruch od daty [Data wprowadzona przez użytkownika]. Wymagalne GM_095 Dla wygenerowanego arkusza musi istnieć możliwość ręcznego dodawania dodatkowych pozycji lub usuwania istniejących. Wymagalne GM_096 System musi umożliwiać wprowadzanie danych ze spisów inwentaryzacyjnych do systemu i wygenerowanie różnic inwentaryzacyjnych. Wymagalne GM_097 Użytkownik musi mieć możliwość automatycznego uwzględnienia różnic inwentaryzacyjnych w stanie magazynowym. Wymagalne Zamówienia publiczne Wymagania ogólne ZAM_001 System powinien umożliwiać automatyczne i niezakłócone sortowanie i filtrowanie danych w Planie Zamówień Publicznych, z możliwością wprowadzenia zmiany ręcznie. Funkcjonalność może być realizowana poprzez umożliwienie dokonywania filtrowania danych wg. określonych przez operatora kryteriów. Kryteria filtrowania winny być definiowalne swobodnie spośród parametrów występujących w Planie Zamówień Publicznych (pola na formularzu), a samo filtrowanie winno odbywać się w module zamówień publicznych (na formatce). Użytkownik powinien mieć możliwość zapisywania ustawień filtrów w celu szybkiego i prostego wyboru kryteriów filtrowania w dowolnym momencie. Ustawienia wybranego filtru powinny być zapisywane dla użytkownika jako ustawienia domyślne wybierane Opcjonalne Strona 144 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
automatycznie przy uruchamianiu formularzy ekranowych dla użytkownika. Planowanie ZAM_002 System powinien zapewnić wyszukiwanie informacji o stanie realizacji zamówień publicznych dotyczących komórki organizacyjnej ( kryteria: Nazwa komórki organizacyjnej, nr zadania budżetowego. Opcjonalne ZAM_003 System powinien umożliwiać planowanie zamówień publicznych między innymi w oparciu o plan inwestycji, remontów, eksploatacji (kosztów). Zadania objęte planem zamówień publicznych powinny wynikać bezpośrednio z zadań przewidzianych do udzielenia ujętych w innych planach zaplanowanych rzeczowo i powiązanych z nimi dokumentów. Tworzenie planu powinno wiązać się z automatycznym zaciąganiem danych z pozostałych planów z możliwością ręcznej korekty. Pozycje wstępnie określone jako PZP pojawiając się w planie zamówień powinny zawierać wszystkie informacje, które będą mogły być brane pod uwagę w trakcie analizy planu. (System powinien uwzględniać planowane zamierzenia oraz rozpoczęte inwestycje i proponować je do umieszczenia w planie zamówień publicznych na dany rok). Opcjonalne ZAM_004 Plan zamówień publicznych w szczególności powinien funkcjonować jako rejestr zawierający co najmniej: ‐ rok planu i opis planu, ‐ informacje o kursie EUR służącym do przeliczenia wartości PLN na EUR, ‐ podział planu na plany cząstkowe z określeniem rodzaju w tym w szczególności: zakup usług, dostawy, roboty budowlane, ‐ pozycje planu – zadanie (przedmiot zamówienia), ‐ przypisanie pozycji planu do jednostek organizacyjnych, ‐ kody CPV, ‐ wartość pozycji w PLN i EUR, ‐ wymagany termin/terminy realizacji zadania, ‐ powiązanie planu zamówień publicznych z planem źródłowym (w szczególności: planem inwestycji, remontów, eksploatacji). ‐ powiązanie z budżetem i planem finansowym.
Opcjonalne ZAM_005 System powinien umożliwiać: ‐ wersjonowanie planu, ‐ podział pozycji planu na bardziej szczegółowe zadania (wielopoziomowy układ planu), ‐ tworzenie nowej wersji na podstawie poprzedniej wersji planu (kopiowanie), ‐ porównywanie wersji planu, ‐ łączenie, podział pozycji planu w kolejnych wersjach, ‐ generowanie planu na podstawie planów bazowych, ‐ drukowanie planu na definiowalnym szablonie (w tym drukowanie części planu na podstawie zdefiniowanych filtrów), ‐ informacje o realizacji planu (w tym w szczególności: powiązanie z WOUZ, postępowaniami, ofertami, zawartymi umowami). Opcjonalne ZAM_006 Tworzenie planu zamówień publicznych nie powinno wiązać się z ręcznym kopiowaniem danych pomiędzy różnymi formularzami systemu. Opcjonalne ZAM_007 Usunięcie danych z planu bazowego (np. planu inwestycji) powinno informować o konieczności aktualizacji planu zamówień publicznych. System powinien zapewnić spójność pomiędzy planami poprzez generowanie odpowiedniego komunikatu w module obsługującym zamówienia publiczne w przypadku dokonywania zmian w planach bazowych (np. planach inwestycji). Forma komunikatu powinna zależeć od konfiguracji. Powinna istnieć możliwość wysyłania komunikatów co najmniej w formie wiadomości e‐mail oraz w postaci komunikatów systemowych za pomocą mechanizmów wbudowanych w system ERP. Opcjonalne ZAM_008 System po zakończeniu planu zamówień publicznych powinien wskazywać zadania, które podlegają ogłoszeniu w formie wstępnych ogłoszeń informacyjnych o planowanych w terminie następnych 12 Opcjonalne Strona 145 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
miesięcy zamówieniach lub umowach ramowych oraz oznaczać zamówienia objęte porozumieniem w sprawie zamówień rządowych (GPA). ZAM_009 System powinien umożliwiać nanoszenia zmian wraz z historią i autoryzacją osoby nanoszącej zmianę. Opcjonalne ZAM_010 System powinien przesyłać automatycznie informacje o zbliżających się terminach i naruszeniu terminów wynikających z Planu Zamówień Publicznych oraz zbliżających się terminach ustawowych do uzgodnionych komórek organizacyjnych. Informacje systemowe winny mieć postać komunikatów ekranowych na formatce zamówień publicznych oraz wiadomości e‐mailowych. Pożądana jest możliwość definiowania terminów i zakresu komunikatów oraz czasu ich wysyłania, jak również zakresu osób, do których będą wysyłane komunikaty. Komunikaty powinny dotyczyć wszystkich terminów wynikających z ustawy – prawo zamówień publicznych oraz terminów założonych w planie. Opcjonalne ZAM_011 Uzgadnianie planu zamówień publicznych powinno odbywać się w sposób elektroniczny. System powinien uwzględniać obowiązującą u Zamawiającego procedurę uzgadniania planu oraz przesyłać komunikaty do kolejnych osób uczestniczących w procedurze uzgadniania planów. W przypadku obiegu dokumentów akceptacji podlegałaby wersja planu w postaci raportu systemowego będącego załącznikiem w obiegu. Uwagi do planu musiałyby być ręcznie naniesione w formularzu modułu zamówień publicznych. W przypadku obiegu wewnętrznego zmiany mogłyby być wprowadzane bezpośrednio na wersji planu podlegającego akceptacji. W takim przypadku powinna istnieć możliwość akceptacji bądź odrzucenie wprowadzonych zmian przez osobę akceptującą finalne zmiany w kolejnej wersji planu. System musi umożliwiać definiowanie przez użytkownika systemu ścieżki uzgadniania, szczególnie w przypadku zmiany procedur wewnętrznych Agencji. Opcjonalne ZAM_012 Akceptacja planu zamówień publicznych powinna odbywać się w sposób elektroniczny. System powinien uwzględniać obowiązującą u Zamawiającego procedurę zatwierdzania planu, przesyłać komunikaty do kolejnych osób uczestniczących w procedurze zatwierdzania planów. zgodnie ze zdefiniowaną (przez użytkownika) ścieżką akceptacji.
Opcjonalne Przetwarzanie zamówień publicznych
ZAM_013 System powinien umożliwiać obsługę każdego trybu zamówienia publicznego przewidzianego w ustawie Prawo zamówień publicznych w zakresie czynności przewidzianych Ustawą oraz regulacjami wewnętrznymi Agencji. Opcjonalne ZAM_014 System powinien obsługiwać procedurę: Przetarg nieograniczony. Opcjonalne ZAM_015 System powinien obsługiwać procedurę: Przetarg ograniczony. Opcjonalne ZAM_016 System powinien obsługiwać procedurę: Negocjacje z ogłoszeniem. Opcjonalne ZAM_017 System powinien obsługiwać procedurę: Negocjacje bez ogłoszenia. Opcjonalne ZAM_018 System powinien obsługiwać procedurę: Dialog konkurencyjny. Opcjonalne ZAM_019 System powinien obsługiwać procedurę: Zamówienie z wolnej ręki (zamówienie udzielane jest po negocjacjach z jednym wykonawcą). Opcjonalne ZAM_020 System powinien obsługiwać procedurę: Zapytanie o cenę (kierowane jest do wybranych wykonawców pytanie o cenę a następnie wykonawcy zapraszani są do składania ofert). Opcjonalne ZAM_021 System powinien obsługiwać procedurę: Licytacja elektroniczna. Opcjonalne ZAM_022 System powinien umożliwiać konfigurację innych trybów postępowania w przypadku zmiany prawa zamówień publicznych. Opcjonalne ZAM_023 System powinien zapewniać obsługę licytacji elektronicznej za pomocą formularza umieszczonego na stronie internetowej, umożliwiającego wprowadzenie niezbędnych danych w trybie bezpośredniego połączenia z tą stroną, przy pomocy której wykonawcy składają kolejne korzystniejsze oferty Opcjonalne Strona 146 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
podlegające automatycznej klasyfikacji. ZAM_024 System powinien umożliwiać archiwizację dokumentów związanych z posiedzeniami komisji przetargowej w ramach danego postępowania (regulamin, protokoły ze spotkań) Opcjonalne ZAM_025 System powinien posiadać moduł/formatkę adekwatną do każdego możliwego trybu postępowania. Opcjonalne ZAM_026 System powinien obsługiwać każdy krok postępowania Opcjonalne ZAM_027 System powinien posiadać szablony dokumentów generowanych na każdym etapie postępowania oraz automatycznie uzupełniać pola w tych szablonach na podstawie danych posiadanych przez System. Opcjonalne ZAM_028 System powinien przesyłać automatycznie komunikaty do osób/jednostek zaangażowanych w postępowanie z odpowiednim wyprzedzeniem dla wykonania każdego kolejnego kroku w procedurze. Opcjonalne ZAM_029 System powinien wykorzystywać funkcjonalność systemu obiegu dokumentów (lub wbudowanego obiegu o równoważnej funkcjonalności) w celu realizacji działań komisji przetargowej, raportowanie danych związanych z pracą komisji przetargowej za pomocą definiowalnych zestawień konfigurowanych przez użytkownika systemu. Opcjonalne ZAM_030 System powinien wspierać przygotowanie IPU. Opcjonalne ZAM_031 W ramach przygotowania IPU system w szczególności powinien: ‐ umożliwiać definiowanie szablonów umów (różne w zależności czego dotyczą: usługi, roboty budowlane, dostawy), ‐ umożliwiać uzupełnianie szablonów danymi z systemu, ‐ umożliwiać zapisanie szablonu uzupełnionego danymi w formacie umożliwiającym dalszą edycję dokumentu (MS WORD), ‐ umożliwiać elektroniczny obieg projektu umowy oraz jego edycję i akceptację przez osoby przypisane do danego zamówienia z wykorzystaniem systemu obiegu dokumentów lub wbudowanego obiegu o równoważnej funkcjonalności. Opcjonalne ZAM_032 System powinien wspierać procesy odwoławcze (Krajowa Izba Odwoławcza ‐ KIO) Odwołanie w KIO może być zainicjowane na każdym etapie postępowania, dla którego przewidziana prawem jest możliwość skorzystania ze środków ochrony prawnej w postaci złożenia odwołania. Proces wstrzymuje bieg procesu głównego, a jego rozstrzygnięcie może spowodować zmianę lub powtórzenie każdej czynności Zamawiającego, która została zaskarżona. Opcjonalne ZAM_033 System powinien posiadać Rejestr Środków Ochrony Prawnej (w którym będą rejestrowane wnoszone środki ochrony prawnej przez potencjalnych dostawców). Opcjonalne ZAM_034 System powinien zapewniać możliwość monitorowania i realizacji czynności wynikających z wniesionego odwołania. Opcjonalne ZAM_035 System powinien zapewniać możliwość monitorowania terminów związania ofertą i zabezpieczenia wadium z odpowiednim przeliczeniem terminów wynikających z ustawy i wstrzymania terminów w związku z odwołaniem. Opcjonalne ZAM_036 System powinien umożliwiać elektroniczne uzgadnianie opracowywanej spornej treści. Opcjonalne ZAM_037 System powinien umożliwiać wysyłanie (e‐mail) oraz publikację odpowiedzi do spornej treści w Internecie. Opcjonalne ZAM_038 Na żądanie użytkownika System powinien umożliwiać wstrzymanie biegu procesu głównego (elektroniczny obieg dokumentów) z możliwością kontynuacji lub powtórzenia zaskarżonej czynność w zależności od wyniku rozstrzygnięcia spornej treści. Opcjonalne ZAM_039 System powinien wykorzystywać funkcjonalność systemu obiegu dokumentów (lub wbudowanego obiegu o równoważnej funkcjonalności) dla wsparcia procesów odwoławczych. Opcjonalne ZAM_040 System powinien obsługiwać przyjmowanie oraz zwalnianie wadium. Opcjonalne ZAM_041 W ramach obsługi wadium w szczególności System: Opcjonalne Strona 147 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐ powinien posiadać rejestr wadiów, ‐ powinien posiadać ewidencję wpływających zarówno dokumentów wadialnych (jak polisy, gwarancje bankowe) z podziałem na rodzaj dokumentu jak również wadium wniesionego w pieniądzu, ‐ powinien przypisywać wadium do konkretnego oferenta i konkretnego postępowania, ‐ powinien wykorzystywać i wymieniać dane w tym zakresie z modułem finansowo – księgowym, ‐ powinien umożliwiać rejestrację dyspozycji, ‐ powinien zapewniać możliwość przeksięgowania wpłaconych wadium na poczet zabezpieczenia należytego wykonania umowy, na podstawie dyspozycji wykonawcy, ‐ powinien wskazywać dla danego postępowania uczestników, którzy nie złożyli wadium. ZAM_042 System powinien obsługiwać przygotowanie i uzgadnianie umowy w procesie udzielania zamówienia publicznego. System w szczególności powinien: ‐ umożliwiać definiowanie szablonów umów (różne w zależności czego dotyczą: usługi, roboty budowlane, dostawy), ‐ umożliwiać uzupełnianie szablonów danymi z systemu, ‐ umożliwiać zapisanie szablonu uzupełnionego danymi w formacie umożliwiającym dalszą edycję dokumentu (MS WORD), ‐ elektroniczne uzgadnianie umowy: umożliwiać autonomiczny obiegu (w module zamówień publicznych) lub wykorzystywać moduł obiegu dokumentów dla realizacji obiegu umowy w procesie udzielania zamówienia publicznego według możliwej do zdefiniowania dla każdego zamówienia ścieżki, ‐ wysyłać komunikaty (w tym e‐mailowe) do osób, do których zostaną przypisane kroki w procedurze przygotowania i uzgadniania umowy. Opcjonalne ZAM_043 System powinien wspierać proces publikacji wyników prac komisji przetargowej zarówno w trakcie jak i na zakończenie jej prac. System powinien przygotowywać i generować komunikaty o treści wymaganej przepisami prawa i regulacjami wewnętrznymi Agencji. Komunikaty powinny być generowane w formacie umożliwiającym ich bezpośrednią publikację na stronach urzędowych publikatorów przy wykorzystaniu interfejsów. Opcjonalne ZAM_044 System powinien umożliwiać uzgadniania dokumentów związanych z udzielaniem zamówienia publicznego w formie elektronicznej. System powinien posiadać autonomiczny obieg, lub wykorzystywać moduł elektronicznego obiegu dokumentów, w celu elektronicznego obiegu, uzgodnień i akceptacji wszelkich dokumentów tworzonych podczas procesu związanego z udzielaniem zamówienia publicznego. System powinien generować komunikaty (w tym e‐mailowe) dla osób, które uczestniczą w procesie informujące o konieczności podjęcia działań. System powinien umożliwiać zdefiniowanie ścieżki uzgodnień i akceptacji dla każdego dokumentu. Opcjonalne ZAM_045 System powinien umożliwiać przesyłanie ogłoszeń do Biuletynu Zamówień Publicznych (BZP) i Dziennika Urzędowego UE z wykorzystaniem aktualnych formularzy dostępnych na tych stronach. Opcjonalne ZAM_046 System powinien umożliwiać ewidencję wpłat wadium do konkretnego postępowania przetargowego. W szczególności system powinien: ‐ posiadać rejestr wadiów, ‐ przypisywać wpłacone wadium do konkretnego oferenta i konkretnego postępowania, ‐ wykorzystywać i wymieniać dane w tym zakresie z modułem finansowo – księgowym, ‐ umożliwiać rejestrację dyspozycji, ‐ zapewniać możliwość przeksięgowania wpłaconych wadium na poczet zabezpieczenia należytego wykonania umowy, na podstawie dyspozycji wykonawcy, ‐ wskazywać dla danego postępowania uczestników, którzy nie złożyli wadium. Opcjonalne ZAM_047 System powinien przesyłać automatycznie informacje o zbliżających się terminach i naruszeniu terminów wynikających z przepisów prawa i procedur wewnętrznych do określonych osób. Opcjonalne ZAM_048 System już od etapu przygotowywania Planów Zamówień Publicznych powinien umożliwiać rejestrację wymaganego terminu zainicjowania zadania wszczęcia procesu oraz przewidywanego okresu jego realizacji do momentu wyłonienia dostawcy/wykonawcy. Opcjonalne Strona 148 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
ZAM_049 Na etapie Zamówienia Publicznego powinna istnieć możliwość określania i monitorowania terminów rozpoczęcia i zakończenia zarówno procesowania pojedynczych dokumentów jak i również całych etapów np. przygotowywanie umowy, uzgadnianie umowy przez pojedyncze oraz wszystkie komórki związane z procesem uzgodnień. Opcjonalne ZAM_050 System powinien zapewniać możliwość tworzenia harmonogramów postępowania o udzielenie zamówienia publicznego: powiadamianie w sytuacjach zagrożeń, możliwość prezentacji wizualnej wraz z zaznaczeniem postępu działań, możliwość uprawnionej akceptacji (poziomej i pionowej) wraz z uwagami. Opcjonalne ZAM_051 System powinien wspierać pracę komisji przetargowej za pomocą elektronicznego obieg dokumentów. Obieg inicjowany wnioskiem o udzielenie zamówienia, efektem końcowym byłaby zarejestrowana umowa z wykonawcą. Opcjonalne ZAM_052 System obiegu dokumentów powinien umożliwiać monitorowanie i raportowania stanu zarówno pod kątem postępu prac komisji przetargowej (dotrzymywanie terminów) jak i udzielonych zamówień publicznych Opcjonalne ZAM_053 System powinien umożliwiać definiowanie przez użytkownika szablonów dokumentów przygotowywanych w procesie udzielania zamówienia publicznego. Szablon powinien umożliwiać umieszczenie w nim tekstu, treści graficznej oraz znaczników danych, które będą pobierane z systemu. Powinna istnieć możliwość umieszczania w szablonie znaczników pozwalających na pobieranie danych w formie tabelarycznej. Opcjonalne ZAM_054 System powinien umożliwiać automatyczne pobieranie i przenoszenie danych związanych z postępowaniem do przygotowanych szablonów dokumentów. Opcjonalne ZAM_055 Po scaleniu szablonu z danymi w systemie do dalszej edycji powinien być dostępny dokument zapisany w formacie umożliwiającym jego dalszą edycję w odpowiednio w MS WORD, PDF lub Excell. Po scaleniu szablonu z danymi powinna być możliwość dalszej edycji dokumentu i zapisaniu go w systemie. Zapisane w systemie dane powinny być automatycznie przenoszone w dokumenty powiązane (łącznie z ogłoszeniami) ww. odpowiednio wskazane miejsca np. wpisanie w specyfikacji istotnych warunków zamówienia danych tj. tytuł postępowania, tryb postępowania, numer postępowania, termin składania i otwarcia ofert, warunki udziału w postępowaniu, kryteria oceny ofert itd. powinny być automatycznie przenoszone w odpowiednie miejsca ogłoszenia o zamówieniu odpowiednio w BZP lub Dz.Urz.UE, protokół postępowania ZP, szablony pism itp. Opcjonalne ZAM_056 System powinien umożliwiać dystrybucję oraz publikację przygotowanych w systemie dokumentów związanych z zamówieniem publicznym. Użytkownik powinien mieć możliwość wysłania dokumentu bezpośrednio z systemu do zdefiniowanej wcześniej grupy odbiorców (za pomocą wiadomość e‐mail), do nie zdefiniowanego wcześniej odbiorcy, umieszczenia dokumentu na serwerze FTP, publikacji dokumentu w Intranecie. Każda z wymienionych operacji powinna zostać odnotowana w systemie po jej wykonaniu. Opcjonalne ZAM_057 Dla przetwarzania dokumentów System powinien wykorzystywać zintegrowany moduł obiegu dokumentów lub posiadać wbudowany obieg systemowy o funkcjonalności równoważnej z funkcjonalnością systemu obiegu dokumentów w zakresie co najmniej: definiowania obiegu, obsługi pracy grupowej na załącznikach (dokumentach), powiadamiania o zadaniach związanych z obiegiem, raportowania informacji o stanie obiegu, obiegu według zdefiniowanych procesów dla poszczególnych dokumentów, trybów postępowania, działań podejmowanych przez użytkowników, powiadamiania i przypominanie o zadaniach wynikających z obiegu, definiowaniu uprawnień i zastępstw oraz innych elementów wymaganych dla wsparcia procesu dystrybucji i publikacji dokumentów związanych z zamówieniami publicznymi. Opcjonalne ZAM_058 System musi podpowiadać terminy realizacji wybranych czynności, zadań. Np. podczas Opcjonalne Strona 149 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
przygotowywania Planu Zamówień Publicznych po wprowadzeniu daty proponowanego rozpoczęcia postępowania system powinien w oparciu o dodatkową konfigurację podpowiadać termin zakończenia postępowania. Podobnie powinna istnieć możliwość powiadania terminów zakończenia np. uzgadniania umowy przez poszczególnych uczestników tego procesu. System winien mieć wprowadzone wszystkie terminy wynikające z przepisów prawa (dot. prawa zamówień publicznych) oraz procedur wewnętrznych. Podczas każdej czynności w procesie zamówień publicznych, która ma oznaczony termin, zastosowany zostaje licznik odliczania czasu do jego upływu – w którym to czasie dana czynność musi zostać wykonana. Osoby odpowiedzialne za wykonanie tych czynności powiadamiane są z odpowiednim wyprzedzeniem np. mailem o zbliżającym się upływie czasu wykonania czynności. ZAM_059 System powinien zapewniać bezpośredni dostęp z systemu do elektronicznych formularzy Biuletynu Zamówień Publicznych, Dziennika Urzędowego WE itp. z jednoczesnym przenoszeniem wypełnianych danych i ewentualnych dokumentów między formularzem a wprowadzanymi danymi do aplikacji postępowania o udzielenie zamówienia publicznego. Opcjonalne ZAM_060 System powinien umożliwiać ewidencję kryteriów oceny wykonawcy/dostawcy. W szczególności system: ‐ powinien umożliwiać zdefiniowanie kryteriów oceny ofert dla danego postępowania, ‐ powinien umożliwiać wprowadzenie ofert (zarówno skan lub postać elektroniczna oferty jak również dane z oferty podlegające ocenie: klient, wartość, terminy itp), ‐ powinien automatyzować proces oceny ofert (automatycznie generować oceny cząstkowe i ocenę końcową na podstawie wprowadzonych składników oferty podlegających ocenie, ‐ powinien umożliwiać analizę oceny, ‐ powinien umożliwiać sortowanie wyników, ‐ umożliwiać przypisywanie wyników dla danej kategorii oceny. Opcjonalne ZAM_061 System powinien umożliwiać ewidencję ofert z uwzględnieniem wszelkich istotnych dla danego postępowania informacji o ofercie wynikających z przepisów prawa i wewnętrznych regulacji oraz potrzebnych do realizacji pozostałych wymagań obszaru. System powinien umożliwiać sortowanie ofert wg możliwych do zdefiniowania kryteriów. Opcjonalne ZAM_062 System powinien umożliwiać elektroniczną ewidencję załączników związanych z postępowaniem o udzielenie zamówienia. Opcjonalne Raportowanie ZAM_063 System powinien umożliwiać pozyskiwanie informacji zarządczych i generowanie sprawozdań/zestawień/raportów/analiz na każdym etapie planowania, udzielania i realizacji zamówień publicznych. W tym sprawozdań w ramach zdefiniowanej uprawnionej komórki ze stanu realizacji prac komisji i ewentualnych opóźnień wynikających z założonych realizacji w planie zamówień. Opcjonalne ZAM_064 System powinien zawierać standardowe zestawienia zawierające dane potrzebne do przygotowania raportów z wykonania zadań kwartalnych, rocznych (F03‐PP‐SPRAWOZ‐01) oraz rocznego sprawozdania o udzielonych zamówieniach do Urzędu Zamówień Publicznych. Opcjonalne ZAM_065 System powinien posiadać narzędzia umożliwiające przygotowanie zestawień, które po wyeksportowaniu z systemu w formacie XLS posłużą do tworzenia analiz i sprawozdań na każdym etapie planowania, udzielania i realizacji zamówień publicznych. Opcjonalne Inwestycje Wymagania ogólne INW_001 Faktura zakupowa w systemie musi być rejestrowana z dokładnością do pozycji towarowej/usługowej. Pojedyncza pozycja faktury przygotowywana do dekretacji musi mieć możliwość rozbijania na wiele nakładów lub/i kosztów. Pozycje faktury muszą mieć powiązanie z inwestycjami. Wymagalne INW_002 System musi posiadać jedną wspólną bazę kontrahentów dla wszystkich komórek organizacyjnych w PAŻP. Wymagalne INW_003 System musi mieć łatwą możliwość wglądu jaki kontrahent, w jakich zadaniach inwestycyjnych brał Wymagalne Strona 150 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
udział, jakie były dla niego wystawiane faktury, czy spóźniał się z realizacją, czy były naliczane dla niego kary umowne. INW_004 Wszystkie dokumenty związane z inwestycją począwszy od wniosku inicjującego, postępowania muszą mieć powiązanie z umowami. W umowach muszą być rejestrowane dane finansowo‐rzeczowe związane z realizowaną inwestycją lub zakupem. Wymagalne INW_005 System musi zawierać wspólny słownik nazw dla towarów, usług, lokalizacji, nazw inwestycji, nazw przyjmowanych środków trwałych. Wymagalne INW_006 System musi zapewniać możliwość przechowywania dokumentacji w różnych formatach, np. skany faktur zakupu, protokołów odbioru częściowego, dokumentacji projektowej, fotograficznej, numery seryjne/fabryczne elementów składowych zadania inwestycyjnego i in. Wymagalne INW_007 System musi zapewnić możliwość tworzenia harmonogramów w formie tabelarycznej i wykresów Gantta. Wymagalne Planowanie i budżetowanie inwestycji INW_008 System musi zapewnić planowanie inwestycji na podstawie planów 5‐letnich. Wymagalne INW_009 System musi zapewnić wsparcie realizacji inwestycji przy pomocy modułu zarządzania projektami. Wymagalne INW_010 System musi zapewnić automatyzację planowania inwestycji, budżetów, planów 5‐letnich, planów pracy. Wymagalne INW_011 System musi zapewnić planowanie inwestycji na podstawie informacji o urządzeniach i infrastrukturze centralnie dostępnej zarówno dla procesów remontowych jak i dla zarządzania projektami inwestycyjnymi. Wymagalne INW_012 System musi wspierać przygotowanie dokumentacji niezbędnej do umieszczenia inwestycji w planie inwestycyjnym. Wymagalne INW_013 System musi umożliwiać planowanie inwestycji w zakresie kosztów i nakładów.
Wymagalne
INW_014 System musi wspierać przygotowanie Planu Inwestycyjnego rocznego oraz pięcioletniego. Wymagalne INW_015 System musi umożliwiać rejestrację harmonogramu płatności dla inwestycji na podstawie którego księgowość zapewni źródło finansowania dla inwestycji.
Wymagalne INW_016 W celu minimalizacji różnic pomiędzy estymacją planu inwestycji a faktycznym wykonaniem planu, system musi umożliwiać wprowadzenie szablonu kosztorysu na podstawie zadań podobnych. Wymagalne INW_017 System musi umożliwiać tworzenie ogólnego planu inwestycji w ramach planów wieloletnich. Wymagalne INW_018 System musi umożliwiać tworzenia wersji (lub korektę) planu inwestycyjnego, które powinny wpływać na zmianę planu finansowego. Wymagalne INW_019 System musi umożliwiać rejestrację historii zmian planu inwestycyjnego (wraz z historią zmiany i identyfikacją osoby nanoszącej zmianę). Wymagalne INW_020 System musi wspierać planowanie inwestycji poprzez możliwość nadawania priorytetów planowanym zadaniom inwestycyjnym. Wymagalne INW_021 System musi umożliwiać powiązanie pozycji planu inwestycji z pozycjami planu finansowego oraz planu zamówień publicznych. Wymagalne INW_022 Przygotowywana inwestycja musi być rozbijana na możliwie dużą ilość zadań, na podstawie których będzie możliwa ocena stopnia ich realizacji. Wymagalne INW_023 System musi pozwalać na określenie % zaawansowania czasowego i kosztowego danej inwestycji. Wymagalne INW_024 Przygotowywanie i akceptacja dokumentacji niezbędnej do umieszczenia inwestycji w planie musi być realizowane elektronicznie. Wymagalne Strona 151 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
INW_025 Pozycje planu inwestycyjnego muszą mieć powiązanie z dokumentami wejściowymi (WZI). Wymagalne INW_026 System musi umożliwiać przenoszenie pozycji planów z lat ubiegłych do aktualnie tworzonych planów. Wymagalne INW_027 System musi umożliwiać tworzenie pozycji planu na podstawie uzgadnianych wniosków zamierzeń inwestycyjnych Wymagalne INW_028 System musi zapewniać możliwość wiązania pozycji planu inwestycyjnego z pozycjami budżetu. Wymagalne INW_029 System musi umożliwiać wiązanie pozycji planu z celami określonymi w strategii oraz ATM Master Plan i ESSIP, LSSIP. Wymagalne INW_030 System musi umożliwiać przygotowanie harmonogramu inwestycji wg którego będzie realizowana. Harmonogram inwestycji musi zawierać kluczowe elementy oraz przewidywane terminy ich rozpoczęcia oraz zakończenia. Musi ujmować między innymi następujące pozycje i zadania: ‐ Przygotowanie dokumentacji w tym technicznej umożliwiającej wystawienie WOUZ, ‐ Zasoby osobowe i czasowe niezbędne do realizacji inwestycji, ‐ Wnioski WOUZ, ‐ Pozyskanie gruntu (o ile nie został wcześniej pozyskany), ‐ Postępowanie w zakresie ochrony środowiska ‐ Wykonanie dokumentacji projektowej ‐ Uzyskanie stosownych pozwoleń, ‐ Przekazanie wykonawcy terenu budowy, ‐ Szkolenia zewnętrzne, ‐ Nadzór inwestorski, odbiory częściowe, ‐ Odbiór końcowy robót, ‐ Przekazanie do eksploatacji, ‐ Rozliczenie inwestycji, ‐ Przeglądy gwarancyjne. Wymagalne INW_031 System musi umożliwiać elektroniczne uzgadnianie dokumentów związanych z przygotowaniem inwestycji z pominięciem obiegu papierowego. System musi zapewniać elektroniczne uzgadnianie, akceptację, zatwierdzanie wniosków/dokumentów w systemie. Wszelkie ustalenia dotyczące planowania inwestycji muszą odbywać się w formie elektronicznej. Dokumenty PF, PFU, OPZ muszą być uzgadniane elektronicznie i stanowić załączniki do dokumentu WZI. Wymagalne INW_032 System musi umożliwiać prognozę planu amortyzacji na podstawie planu inwestycji. Wymagalne INW_033 System musi umożliwiać prognozę korekty amortyzacji wynikająca z dotacji na planowane środki trwałe. Prognoza musi być w postaci raportu. Parametry raportu: przedział czasowy na jaki należy wykonać naliczenie amortyzacji, podział na całą amortyzacje i oddzielnie dla ŚT i WNiP. Wyliczenie dla poszczególnych zadań inwestycyjnych zgodnie z miesiącem wpłat dotacji na zadania inwestycyjne w podziale na miesiące planu. Wymagalne INW_034 System musi umożliwiać prognozę amortyzacji od planowanych środków realizowanych w ramach inwestycji. Prognoza musi być dostępna w postaci raportu zawierającego: przedział czasowy na jaki należy wykonać naliczenie amortyzacji, podział na całą amortyzacje i oddzielnie dla ŚT i WNiP. Wyliczenie dla poszczególnych zadań inwestycyjnych zgodnie z miesiącem oddań w podziale na miesiące planu. Wymagalne INW_035 System w ramach planowania inwestycji musi umożliwiać planowanie terminu powstania środka trwałego ze wskazaniem, z których nakładów powstaje środek lub które nakłady wpływają na zwiększenie wartości środka trwałego. Wymagalne INW_036 Plan inwestycyjny musi zawierać plan oddań środków trwałych w poszczególnych latach. W planie muszą być również zawarte informacje które posłużą do wyliczenia planowanej amortyzacji. Jeśli dana inwestycja związana jest z rozbudową to dla poszczególnych fragmentów oddań rozbudowy musi istnieć możliwość wyliczenia amortyzacji. W ramach inwestycji może powstać środek trwały od zera lub Wymagalne Strona 152 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
nastąpić rozbudowa istniejącego. W trakcie trwania inwestycji do istniejącego środka mogą dochodzić kawałki od których liczony jest plan amortyzacji. Z punktu widzenia planowania amortyzacji nie jest istotne czy powstaje środek trwały czy następuje rozbudowa istniejącego (Wymagana jest rejestracja parametrów wykorzystywanych podczas liczenia amortyzacji np. okres użytkowania). INW_037 System musi umożliwiać rejestrację i wersjonowanie zadań i celów strategicznych PAŻP oraz ATM Master Plan i LSSIP, ESSIP. Wymagalne INW_038 Na poziomie zadań inwestycyjnych musi być możliwość powiązania z Zadaniem strategicznym PAŻP lub kilkoma zadaniami strategicznymi i możliwość przypisania % udziału w poszczególnych zadaniach strategicznych. Wymagalne INW_039 Na podstawie danych rzeczywistych system musi dokonywać projekcji wykonania planu inwestycyjnego Wymagalne w przyszłych okresach jego realizacji (wartościowo I rzeczowo). Np. w połowie roku system na podstawie bieżącego wykonania oraz ewentualnych zidentyfikowanych opóźnień lub przyspieszeń realizacji inwestycji musi dawać możliwość pokazania, jakie będzie wykonanie inwestycji na koniec roku. INW_040 System musi mieć możliwość zapisywania w Systemie harmonogramu spłat kredytów inwestycyjnych w celu wykorzystania tej informacji w prognozie płynności. Wymagalne Realizacja inwestycji INW_041 System musi umożliwiać dokumentowanie i raportowanie zamknięcia zadania inwestycyjnego CNS/ATM zgodnie z formalnymi procedurami AT. Wymagalne INW_042 System musi umożliwiać weryfikację stanu realizacji inwestycji ujętych w dotychczasowych Planach Inwestycji. Wymagalne INW_043 System musi umożliwiać opracowanie Wniosku Zamierzenia Inwestycyjnego, którego poziom szczegółowości musi zależeć od okresu planistycznego którego ma dotyczyć: pierwsze 2 lata lub kolejne lata. W obu przypadkach następuje przygotowanie Wniosku Zamierzenia Inwestycyjnego (WZI) którego pełna postać wraz z załącznikami musi zawierać: ‐ powiązanie ze strategią, ‐ odniesienie do Europejskiego Centralnego Planu ATM, ‐ wskazanie powiązań z innymi zadaniami inwestycyjnymi i projektami w PAŻP, ‐ porównanie nakłady/efekty, ‐ wielkość planowanych nakładów inwestycyjnych i kosztów, ‐ wstępny harmonogram rzeczowo‐finansowy, ‐ termin przekazania inwestycji do użytku, ‐ lokalizację inwestycji (miejscowość, obręb, numer, wielkość działki, ‐ opinie dotyczące pozyskania gruntu (stan prawny, możliwość pozyskania gruntu, sugerowany tryb pozyskania gruntu, szacunkowy koszt, czas potrzebny na pozyskanie gruntu, ‐ opinie dotyczące szkoleń (planowany koszt szkoleń, planowany zakres szkoleń, czas trwania szkoleń), ‐ przewidywany okres realizacji od zawarcia umowy. Wymagalne INW_044 Dla inwestycji planowanych w pierwszych dwóch latach okresu planistycznego do umieszczenia w planie konieczne jest przygotowanie: ‐ dla inwestycji budowlanych opracowanie PT ze wskazaniami lokalizacyjnymi oraz przygotowanie FPU na podstawie PT, ‐ dla zakupów opracowanie OPZ (nie dotyczy inwestycji cyklicznych). Wymagalne INW_045 WZI musi zawierać oszacowanie wartości zamówienia oraz wstępne określenie trybu postępowania zgodnie z PZP. Wymagalne INW_046 System powinien wspierać obsługę uzgodnień związanych z inwestycją, w tym między innymi: ‐ analizy bezpieczeństwa, ‐ analizy oddziaływania na środowisko, ‐ weryfikacja w zakresie szkoleń zewnętrznych związanych z planowaną inwestycją. Opcjonalne Strona 153 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
INW_047 System musi śledzić możliwość wystąpienia ryzyka/opóźnień w wykonywaniu inwestycji które zostaną określone przez zamawiającego na etapie wdrażania systemu. Przykładowym ryzykiem jest brak wystarczających zasobów do wykonania zaplanowanych zadań (zbyt duża ilość wniosków WOUZ w zadanym okresie). Wymagalne INW_048 System musi umożliwiać odnotowywanie rejestracji decyzji środowiskowych i wykonanych pomiarów emisji pól elektromagnetycznych. W procesie realizacji inwestycji musi zostać odnotowane w systemie: uzyskiwanie decyzji środowiskowych i wykonywanie pomiarów emisji pól elektromagnetycznych. Potwierdzenie wykonania zadania musi zawierać również kopię elektroniczną dokumentu (potwierdzenie wykonania ekspertyzy przez wykonawcę). Wymagalne INW_049 System musi umożliwiać powiązanie wniosku zakupowego z inwestycją Wymagalne INW_050 W systemie musi istnieć możliwość monitorowania poszczególnych kroków inwestycji, jak one przebiegają od momentu zapisania w Planie inwestycji. Gdzie powstają opóźnienia by w innych miejscach była możliwość przyspieszenia działania. Wymagalne INW_051 Na etapie realizacji inwestycji system musi umożliwiać śledzenie realizacji pod względem wykonawczym i finansowym, w tym generowanie raportów dotyczących zaawansowania rzeczowego i finansowego poszczególnych zadań inwestycyjnych w formie danych dostępnych na formularzach systemu oraz w postaci zestawień dostępnych w systemie. Wymagalne INW_052 W systemie musi być rejestrowany harmonogram inwestycji a dla poszczególnych jego kroków (zadań) musi być odnotowane wykonanie (rzeczywisty termin wykonania) oraz dokumenty związane z realizacją w postaci załączników w formie elektronicznej. Wymagalne INW_053 W trakcie trwania inwestycji system musi umożliwiać rejestrowanie, przekazywanie i archiwizowanie w formie elektronicznej dokumentów oraz opracowań związanych z realizowaną inwestycją. Wymagalne INW_054 W ramach harmonogramu inwestycji system musi umożliwiać rejestrację oraz wydruk protokołów oraz innych dokumentów związanych z realizacją inwestycji. Rejestracja danych rejestrowanych na protokołach/dokumentach umożliwi późniejszą ich analizę w systemie. Wymagalne INW_055 System musi umożliwiać identyfikację w czasie rzeczywistym miejsca generowania opóźnień realizacji inwestycji w stosunku do przyjętego harmonogramu w ujęciu rzeczowym i finansowym Wymagalne INW_056 Faktury zakupowe musza być rejestrowane z dokładnością do pozycji towarowej by było możliwe uzyskanie szczegółowych danych na zestawieniach dotyczących sprawozdawczości inwestycyjnej. Wymagalne INW_057 System musi identyfikować jednoznacznie wszystkie umowy składające się na zadania unijne (nie tylko umowy przetargowe). Wymagalne INW_058 System musi jednoznacznie identyfikować wszystkie wydatki składające się na zadania unijne. System musi identyfikować również inne wydatki związane z realizacją zadań unijnych, niewynikające z umowy. System musi zapewnić również identyfikowanie wydatków w ramach obiegu faktury zakupowej (w szczególności określanie kategorii wydatków). Musi istnieć możliwość sprawdzenia jakie rodzaje wydatków są ujmowane w systemie F‐K jako wydatki dotyczące danego zadania inwestycyjnego. Musi istnieć możliwość wygenerowania z systemu zestawienia zaksięgowanych kwot i zapłaconych wydatków w podziale na kategorie, które wcześniej zostały wskazana na wspomnianych załącznikach do faktury. Wymagalne INW_059 Zgodnie z Wytycznymi kwalifikowalności POIiŚ system musi identyfikować wydatki unijne poniżej 1000zł. System musi generować zestawienia z wydatkami netto do 1000PLN dotyczącymi zadań oznaczonych jako IU (obecne oznaczenie zadań unijnych). Wymagalne INW_060 System musi posiadać rejestr opóźnień dla planowanych lub/i realizowany inwestycji, którego zawartość można wykorzystać na zestawieniach dotyczących sprawozdawczości. Wpis w rejestrze może dotyczyć dowolnego punktu kontrolnego w planowanej/realizowanej inwestycji. Wymagalne Strona 154 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
INW_061 System musi zapewnić sprawny monitoring postępu realizacji zadań inwestycyjnych w ujęciu rzeczowym i finansowym. Wymagalne INW_062 System musi umożliwić monitorowanie stopnia zaawansowania rzeczowego i finansowego poszczególnych zadań inwestycyjnych w powiązaniu z modułem księgowym. Wymagalne INW_063 System musi umożliwić monitorowanie stopnia zaawansowania rzeczowego i finansowego poszczególnych zadań inwestycyjnych zarówno w formie danych dostępnych na formularzach systemu oraz w postaci zestawień dostępnych w systemie. Wymagalne INW_064 System musi identyfikować opóźnienia na wszystkich etapach realizacji inwestycji w stosunku do przyjętych harmonogramów, planu inwestycji oraz planu zamówień publicznych. Wymagalne INW_065 System musi zapewnić wgląd do stanu realizacji inwestycji: ‐ elementów majątku zakupionych, lecz nieprzekazanych do ewidencji środków trwałych (inwestycje w toku) w podziale na projekty, rodzaje, grupy i miejsca użytkowania ze wskazaniem nazwy i wartości, ‐ opisów szczegółowych, dokumentacji fotograficznej i innych ‐ na potrzeby realizacji procesów ubezpieczeniowych (zawieranie i/lub aktualizacja umów ubezpieczenia, postępowania w/s likwidacji szkód). Wymagalne INW_066 System musi mieć możliwość pozyskiwania danych z systemu monitorowania procesu inwestycyjnego na potrzeby zarządzania płynnością finansową. Wymagalne Raportowanie INW_067 System powinien mieć możliwość wykazania rozliczonych inwestycji na których wnioskodawca źle oszacował wartość inwestycji o zadaną kwotę lub % (np. inwestycje w których błąd estymacji wynosił 30 %) Opcjonalne INW_068 System musi umożliwiać wyciąganie danych, związanych z planowaniem i realizacją inwestycji do arkuszy EXCEL do dalszej analizy. Wymagalne INW_069 System musi wspierać przygotowanie zestawienia F‐01 w zakresie nakładów inwestycyjnych. Wymagalne INW_070 System musi wspierać przygotowanie zestawia F‐03 w zakresie nakładów inwestycyjnych. Wymagalne INW_071 System musi umożliwiać prezentację graficzną zaangażowania zasobów osobowych w poszczególnych zadaniach. Wymagalne INW_072 System musi umożliwiać monitoring zadania inwestycyjnego wg m.in. zasobów osobowych , poszczególnych zadań wyszczególnionych w harmonogramie. Wymagalne INW_073 W systemie musi być dostępne opisane poniżej zestawienie: Inwestycje (wszystkie inwestycje wraz z inwestycjami EU): ‐ Kontrahent, ‐ Opis inwestycji, ‐ Oznaczenie dla GUS, ‐ Nr faktury, ‐ Data wystawienia dokumentu, ‐ Nr systemowy, ‐ Nr umowy, ‐ Oznaczenie zadania inwestycyjnego wg numeru projektu, ‐ Nr zadania, ‐ Netto w PLN ( = Nakłady + koszty), ‐ Brutto w PLN, ‐ Nakłady, ‐ Konto 0801 (środki trwałe), ‐ Konto 0802 (oprogramowanie), ‐ Konto 0801N (niskocenne), ‐ Koszty (koszty szkoleń + pozostałe koszty), Wymagalne Strona 155 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐ Koszty szkoleń, ‐ Pozostałe koszty , ‐ Data KG (data księgowania), ‐ Data zapłaty, ‐ Termin płatności z umowy. INW_074 W systemie musi być dostępne opisane poniżej zestawienie: Nakłady rozliczone OT: ‐ Saldo konta 080 na 31.12 poprzedniego roku (=BO), ‐ Nakłady bieżącego roku, ‐ Nakłady rozliczone OT w bieżącym roku, ‐ Saldo końcowe bieżącego roku (=BZ), ‐ Zobowiązania na 31.12 bieżącego roku. Wymagalne INW_075 W systemie musi być dostępne opisane poniżej zestawienie: Zestawienie faktur do dokumentu OT ‐ Nr OT, ‐ Nr faktur składających się na OT, ‐ Nr systemowy, ‐ Nr zadania (inwestycyjnego), ‐ Nr projektu. Wymagalne INW_076 W systemie musi być dostępne opisane poniżej zestawienie: Projekty UE ‐ Opis zadania, ‐ Nr faktury, ‐ Nr systemowy, ‐ Data wystawienia dokumentu, ‐ Nr umowy z kontrahentem, ‐ Oznaczenie zadania inwestycyjnego wg numeru z planu inwestycyjnego projektu, ‐ Kategoria wydatku kwalifikowanego , ‐ Podkategoria wydatku kwalifikowanego , ‐ Wartość faktury w dewizach, ‐ Netto w PLN, ‐ Brutto w PLN, ‐ Przeliczenie do projektu UE faktur dewizowych , ‐ Kwota wydatku niekwalifikowana, ‐ Data KG (data księgowania), ‐ Data zapłaty, ‐ Potrącone kary umowne. Wymagalne INW_077 W systemie musi być dostępne opisane poniżej zestawienie: Płatności za wszystkie faktury zakupowe ‐ Nr faktury, ‐ Nr systemowy, ‐ Data KG (data księgowania), ‐ Data zapłaty, ‐ Termin płatności z umowy. Wymagalne INW_078 W systemie musi być dostępne opisane poniżej zestawienie: Lista planowanych zadań inwestycyjnych oznaczonych wstępnie jako unijne ‐ Nr zadania, ‐ Nazwa planu, ‐ Planowane koszty, ‐ Planowane nakłady. Wymagalne Strona 156 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
INW_079 W systemie musi być dostępne opisane poniżej zestawienie: Postępowanie WOUZ: ‐ Zarządzenie powołujące komisję przetargową (numer, data), ‐ Nazwa zamówienia (przedmiot), ‐ Rodzaj zamówienia (roboty budowlane/ usługi/ dostawy)) , ‐ Tryb udzielenia zamówienia , ‐ Szacunkowa wartość zamówienia (netto, PLN), ‐ Planowana daty: * ogłoszenia zamówienia (dziennik urzędowy UE lub BZP), * wszczęcia postępowania nie podlegającego ogłoszeniu w dzienniku urzędowym UE lub BZP, * podpisania umowy z wykonawcą, * podpisania aneksu do umowy z wykonawcą, ‐ Rzeczywiste daty: * ogłoszenia zamówienia (dziennik urzędowy UE lub BZP), * wszczęcia postępowania nie podlegającego ogłoszeniu w dzienniku urzędowym UE lub BZP, * data podpisania umowy z wykonawcą, * data podpisania aneksu do umowy z wykonawcą. Wymagalne INW_080 W systemie musi być dostępne opisane poniżej zestawienie: ‐ Wartość najkorzystniejszej oferty przed podpisaniem umowy z Wykonawcą (brutto, PLN) ‐ Nazwa wybranego Wykonawcy, ‐ Wartość zamówienia (PLN): * netto wg umowy z wykonawcą, * brutto wg umowy z wykonawcą, * netto wg aneksu do umowy z wykonawcą, * brutto wg aneksu do umowy z wykonawcą, ‐ Data zakończenia: * realizacji zamówienia wg umowy z wykonawcą, * realizacji zamówienia wg aneksu do umowy z wykonawcą (rrrr‐mm‐dd), ‐ Kontrole przeprowadzone przez Prezesa UZP, inne kontrole obejmujące zamówienia publiczne oraz audyty (numery oraz daty przeprowadzenia), ‐ Przyczyny ewentualnych opóźnień (na etapie postępowania: czego dotyczy, datę wpisu oraz opisu przyczyny opóźnienia). Wymagalne INW_081 W systemie musi być dostępne opisane poniżej zestawienie: ‐ osoba odpowiedzialna za realizację umowy w PAŻP (imię i nazwisko komórka organizacyjna), ‐ Wnioskodawca (imię i nazwisko, komórka organizacyjna), ‐ Dane WOUZ (numer, data wystawienia, data przyjęcia do realizacji, nr zadania inwestycyjnego), ‐ Data wszczęcia postępowania, ‐ Nr postępowania, ‐ Termin składania ofert w postępowaniu, ‐ Realizator (imię i nazwisko, komórka organizacyjna), ‐ Data powołania i skład komisji przetargowej, ‐ Data ogłoszenia o wszczęciu postępowania / zaproszenia do negocjacji. INW_082 W systemie musi być dostępne opisane poniżej zestawienie: Realizacja umowy dla WOUZ (Planowana realizacja rzeczowa w okresie + 1 kwartału) ‐ Zatwierdzenie projektu budowlanego (rrrr‐mm‐dd), ‐ Zatwierdzenie projektu wykonawczego (rrrr‐mm‐dd), ‐ Pozwolenie na budowę (pozwolenie na realizację inwestycji) (numer, rrrr‐mm‐dd), ‐ Przekazanie terenu budowy (rrrr‐mm‐dd), ‐ Dostawa/ Montaż (rrrr‐mm‐dd), ‐ Odbiór końcowy (rrrr‐mm‐dd), ‐ Pozwolenie na użytkowanie (numer, rrrr‐mm‐dd), ‐ Pozwolenie operacyjne (wpis RLUN w ULC/ wpis AIP PAŻP) (numer, rrrr‐mm‐dd), ‐ Przyczyny ewentualnych opóźnień (na etapie realizacji rzeczowej dane w systemie ERP mogą być Wymagalne Strona 157 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
pobierane na podstawie dodatkowego rejestru opóźnień, który powinien zawierać informacje: czego dotyczy, datę wpisu oraz opisu przyczyny opóźnienia). INW_083 W systemie musi być dostępne opisane poniżej zestawienie: Faktury/ rachunki przypisane do konkretnych umów ‐ Nr faktury/rachunku, ‐ Data wystawienia, ‐ Kwota, ‐ Waluta, ‐ Kwota PLN, ‐ Kontrahent, ‐ Nr umowy. Wymagalne INW_084 W systemie musi być dostępne opisane poniżej zestawienie: Zestawienie podróży służbowych dotyczących POIiŚ (hotele/ podróże służbowe) ‐ Nr delegacji, ‐ Nr faktury, ‐ Pracownik, ‐ Koszty, ‐ Umowa, ‐ Data delegacji od, ‐ Data delegacji do.
Wymagalne INW_085 W systemie musi być dostępne opisane poniżej zestawienie: Postęp realizacji zadań inwestycyjnych ‐ Numer i nazwa zadania, zgodnie z Planem Inwestycji, ‐ Wartość zadania zgodnie z Planem Inwestycji, ‐ Opis zadania zgodnie z Planem Inwestycji, ‐ Imię i nazwisko wnioskodawcy oraz realizatora oraz pion , w którym są oni zatrudnieni, ‐ Termin planowanego wszczęcia postępowania zgodnie z Planem Zamówień Publicznych na dany rok, ‐ Opis realizacji inwestycji (z uwzględnieniem przyczyn opóźnień w stosunku do przyjętego harmonogramu/ Planu Inwestycji / Planu Zamówień Publicznych w przypadku ich wystąpienia). Wymagalne INW_086 W systemie musi być dostępne zestawienie z danymi dotyczącymi WOUZ oraz postępowania: data wystawienia WOUZ, szacunkowa wartość WOUZ; data wyjścia WOUZ z działu Zamówień Publicznych; data wszczęcia postępowania; numer postępowania nadawany przez Dział Zamówień Publicznych; tryb udzielenia zamówienia; data powołania i skład komisji przetargowej; data ogłoszenia postępowania; termin składania ofert w postepowaniu: informacja nt. aktualnego stanu prac komisji przetargowej. Wymagalne INW_087 W systemie musi być dostępne zestawienie z danymi dotyczącymi umowy z wykonawcą/dostawcą; data zawarcia umowy i termin jej realizacji; wartość umowy netto i brutto; wartość i terminy płatności wynikających z umowy; wartość kosztów i nakładów zaksięgowanych na kontach poszczególnych zadań inwestycyjnych w określonym okresie sprawozdawczym; informacja o aktualnym stanie realizacji zadania po podpisaniu umowy z wykonawcą/dostawcą, w tym kluczowych etapów realizacji inwestycji o charakterze budowlanym: terminy zatwierdzenia projektów budowlanego i wykonawczego; otrzymania pozwolenia na budowę; przekazania terenu budowy; dostawy montażu urządzeń; terminu zakończenia prac budowlanych; odbioru końcowego, uzyskania pozwolenia na użytkowanie. Wymagalne INW_088 Na potrzeby rozliczania inwestycji współfinansowanych ze środków UE w systemie musi być dostępne zestawienie stanowiące podstawę do refundacji wydatków. Zestawienie musi zawierać następujące dane: ‐ Numer faktury zakupowej (będące potwierdzeniem wykonania usługi/dostawy towaru) ‐ Numer księgowy lub numer ewidencyjny, ‐ Data wystawienia dokumentu, ‐ Data zapłaty, ‐ Nazwa towaru lub usługi + numer umowy, ‐ Kwota dokumentu brutto, ‐ Kwota dokumentu netto, Wymagalne Strona 158 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐ Kwota wydatków kwalifikowanych, ‐ w tym VAT, Na wyżej wymienionej liście oprócz listy faktur musza widnieć dwie pozycje zbiorcze: koszty do 1000,00 zł oraz Inwestycje do 1000,00 zł. INW_089 System musi generować zestawienia obrazujące przypisanie kategorii wydatków kwalifikowanych do określonych wydatków. System musi mieć możliwość wygenerowania z systemu zestawienia zaksięgowanych kwot i zapłaconych wydatków w podziale na kategorie, które wcześniej zostały wskazana na wspomnianych załącznikach do faktury. Wymagalne INW_090 System na poziomie umowy musi umożliwiać rejestrację odpowiednich danych, które wraz z realizacją umowy (dane rejestrowane w innych miejscach systemu) pozwolą na wykrycie opóźnień w realizacji umowy. System musi wyłącznie powiadamiać o konieczności nałożenia kar umownych wybraną grupę klientów lub klienta bez konieczności wyliczenia wielkości naliczonej kary. Wymagalne INW_091 System musi umożliwić przechowywanie w bazie danych i raportowanie informacji dotyczących inwestycji, wymaganych przy procesach ubezpieczeniowych: ‐nr zadania inwestycyjnego w pozycji Planu Inwestycji, ‐ nazwa zadania inwestycyjnego, ‐ nazwa wykonawcy/dostawcy, ‐ kierownik projektu/koordynator, ‐ docelowa komórka organizacyjna/osoba odpowiedzialna za odbiór zadania inwestycyjnego oraz nadzór nad środkiem trwałym, ‐ wartość zadania inwestycyjnego z uwzględnieniem przewidywanej wartości środków trwałych (w podziale na grupy: Budowle, Budynki, N1, K1, Pozostałe ST, elektronika biurowa, laptopy); w przypadku modyfikacji planu inwestycji ‐ aktualizacje wartości, terminów wykonania (wymagana akcja systemowa ‐ komunikat np. e‐mail do AFFU), ‐ docelowa lokalizacja środków trwałych nabytych w ramach zadania inwestycyjnego, ‐ planowany harmonogram realizacji/ termin zakończenia realizacji zadania inwestycyjnego, ‐ aktualny stan zaawansowania prac/dostaw, ‐ rodzaj ubezpieczenia, nazwa ubezpieczyciela ze strony wykonawcy/dostawcy dla realizacji zadania inwestycyjnego, ‐ nr nazwa i data ważności polisy, ‐ suma ubezpieczenia, ‐ termin zakończenia ochrony ubezpieczeniowej gwarantowanej przez wykonawcę. Wymagalne INW_092 System musi umożliwiać monitoring wszystkich zadań inwestycyjnych jednocześnie (zestawienie zbiorcze) wg określonych kryteriów np. konkretny zasób osobowy, określony pkt krytyczny, konkretne działanie w ramach zadania. Wymagalne INW_093 System musi umożliwiać dokonywanie projekcji wykonania zadań inwestycyjnych ujętych w Planie Inwestycji w przyszłych okresach. Wymagalne Tabela 12. Wymagania funkcjonalne ‐ Zarządzanie zakupami 2.3
Wymagania dotyczące EOD
Nr
wymagania
Wymaganie
Kategoria
wymagania
Wymagania ogólne dla komponentu EOD Założenia ogólne EOD_001 Interfejs systemu musi działać poprzez dostępne na rynku przeglądarki internetowe ‐ co najmniej Wymagalne Strona 159 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Internet Explorer oraz FireFox. EOD_002 Użytkownik systemu musi mieć możliwość dostępu do swojego profilu z dowolnej stacji roboczej. Niezależnie, na której stacji roboczej użytkownik zaloguje się do systemu musi mieć dostęp do swoich dokumentów i zadań oraz widoków zdefiniowanych we własnym profilu lub w profilu grupy, do której jest przypisany. Wszystkie ustawienia użytkownika muszą być zapisywane na serwerze aplikacyjnym, a nie w ustawieniach stacji roboczej. Wymagalne EOD_003 Widoki ekranowe w systemie muszą być konfigurowalne przez użytkownika. Użytkownik musi mieć możliwość utworzenia i zapisu konfiguracji dowolnej liczby widoków (list spraw i dokumentów) definiując widoczne pola, zakres danych, sposób sortowania, szerokość pól, grupowanie, itp. Skonfigurowane przez użytkownika widoki powinny być w ergonomiczny sposób przełączane. Musi być możliwość udostępnienia konfiguracji widoków innym użytkownikom systemu oraz definiowanie widoków publicznych – dostępnych dla wszystkich użytkowników lecz z uwzględnieniem uprawnień w systemie. Wymagalne EOD_004 System powinien mieć możliwość eksportu i importu definicji formularza do XML. Opcjonalne EOD_005 System powinien wykorzystywać standard XML do wymiany danych, a także do opisu konfiguracji systemu. Opcjonalne EOD_006 System musi zapewnić możliwość automatycznej walidacji danych wprowadzonych w formularzach udostępnionych w systemie na podstawie zdefiniowanych reguł, co najmniej w zakresie: ‐ kompletności informacji (czy wszystkie wymagane pola zostały wypełnione), ‐ formatu wprowadzonych danych (np. format daty, NIP, itp.), ‐ poprawności danych (np. PESEL, NIP, REGON, data).
Wymagalne EOD_007 System musi być opatrzony polskojęzyczną instrukcją obsługi przeznaczoną dla użytkownika do oferowanej wersji (zwanej dalej instrukcją) oraz instrukcję dla administratora (w języku polskim lub angielskim) opisującą szczegółowo zarówno aspekty techniczne (instalację, konfigurację, wymagane komponenty do poprawnej pracy) oraz funkcjonalne wszystkich elementów. Wymagalne EOD_008 System powinien umożliwić integrację listy zadań z kalendarzem programu pocztowego (MS Outlook lub innym programem kalendarza obsługującym standard vCalendar) lub zapewnić wbudowaną funkcjonalność terminarza użytkownika. Opcjonalne EOD_009 System powinien umożliwiać rejestrowanie powiązań pomiędzy dokumentami Zintegrowanego Systemu Zarządzania (procedurami, instrukcjami, kartami procesów). Wymagalne EOD_010 System musi zapewnić jednoczesne wyświetlanie wielu dokumentów. Wymagalne EOD_011 System powinien zapewnić edytor schematów blokowych, algorytmów, rysunków technicznych itp. Opcjonalne EOD_012 System musi posiadać moduł uprawnień zarządzający dostępem użytkowników do odpowiednich modułów i funkcji systemu. Zarządzanie dostępem użytkowników do różnych rodzajów kategorii spraw, schematów numeracji oraz rejestrów. Wymagalne EOD_013 System musi posiadać mechanizm walidacji uprawnień do potwierdzania dokumentów w powiązaniu z Rejestrem pełnomocnictw. Wymagalne EOD_014 Administrator musi mieć możliwość wglądu we wszystkie uruchomione instancje (wersje przebiegu) procesów, dla których może: ‐ anulować instancje procesu, ‐ anulować bieżącą instancję procesu i uruchomić nową (być może w oparciu o nowy przebieg procesu). Wymagalne EOD_015 System musi zapewnić obsługę zastępstw. Administrator rejestrując zastępstwo podaje informację kogo zastępuje dany użytkownik oraz w jakim okresie (data od, do). W okresie zastępstwa użytkownik zastępujący uzyskuje automatycznie uprawnienia i role użytkownika zastępowanego bez konieczności logowania się na konto użytkownika zastępowanego. Wymagalne EOD_016 System musi umożliwiać ustawienie przez administratora wiadomości grupowych wraz z określeniem Wymagalne Strona 160 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
rodzaju użytkowników i jednostek organizacyjnych dla jakich mają być wyświetlone. Wiadomości grupowe mogą być konfigurowane dla poszczególnych użytkowników, grup użytkowników (np. wg komórki organizacyjnej lub roli pełnionej w procesie, wszystkich użytkowników przypisanych w procesie itp.). EOD_017 System musi umożliwiać uruchamianie instancji procesów. Po zmianie procesu uruchomione procesy muszą być realizowane według definicji obowiązującej w momencie ich rozpoczęcia. Wymagalne EOD_018 System musi zapewnić wsparcie prac biurowych i administracyjnych: komunikowanie, informowanie i kolejkowanie zadań. Wymagalne EOD_019 System musi zapewnić dekretację dokumentów i spraw w obiegu na użytkownika, stanowisko czy jednostkę organizacyjną. Wymagalne EOD_020 System musi zapewnić obsługę kancelarii zgodnie z instrukcją kancelaryjną. Wymagalne Integracja EOD_021 System musi udostępniać usługi umożliwiające automatyzację zmiany statusu spraw/dokumentów i podłączanie tych usług do operacji realizowanych w pozostałych komponentach i modułach systemu, informowanie innych uczestników procesu o zmianie jego statusu. Wymagalne EOD_022 System EOD musi umożliwiać wykorzystanie usług udostępnianych przez pozostałe moduły systemu w celu automatyzacji rejestracji operacji w tych modułach na podstawie operacji realizowanych w systemie EOD. Wymagalne EOD_023 Komponent EOD musi być rozwiązaniem zintegrowanym z pozostałymi częściami systemu: ERP, EPM, BI. Wymagalne W szczególności wymagana jest pełna integracja: kartoteki kontrahentów, bazy pracowników (użytkowników), struktury organizacyjnej, przepływu pracy, słowników współużytkowanych w poszczególnych obszarach i w systemie EOD używanych jako wartość metadanych lub opisów strukturalnych dokumentów (np. słownik MPK, słownik stawek VAT, itp.). EOD_024 System powinien umożliwiać wykorzystanie platformy ePUAP do komunikacji z innymi urzędami centralnymi i jednostkami administracji rządowej i samorządowej. Opcjonalne EOD_025 System musi posiadać wbudowanego klienta poczty elektronicznej, który zapewni integrację z systemem obsługi poczty email w zakresie: ‐ archiwizacji całych wiadomości e‐mail, ‐ archiwizacji załączników do wiadomości e‐mail, ‐ archiwizacji i odtwarzania folderów skrzynki pocztowej, ‐ dostarczania wybranych dokumentów oraz ich atrybutów jako załączników do wiadomości e‐mail, ‐ wysyłania wyników wyszukiwania (dokumentów lub folderów) pocztą elektroniczną z przeglądarki klienta, ‐ filtra antyspamowego. Wymagalne EOD_026 System powinien umożliwiać automatyczne importowanie faktur elektronicznych przesłanych pocztą elektroniczną do elektronicznego obiegu ze wskazanego adresu/adresów e‐mail ‐ zgodnie z obowiązującym prawem. Opcjonalne EOD_027 System elektronicznego obiegu dokumentów musi być powiązany z modułem urlopowym, tj. np. w procesie procedowania/akceptacji dokumentów wewnętrznych muszą być uwzględnione bieżące urlopy, zastępstwa osób decyzyjnych. Wymagalne EOD_028 System elektronicznego obiegu dokumentów musi być ściśle zintegrowany z pozostałymi komponentami systemu w zakresie umożliwiającym obsługę wszystkich dokumentów, rejestrów i spraw skonfigurowanych w ramach komponentu. Wymagalne EOD_029 System zapewni współdziałanie mechanizmów kontroli obiegu dokumentów komponentów ERP i EOD. Musi być możliwe uzależnienie wykonania operacji związanej z danym dokumentem w odpowiedniej funkcji komponentu ERP od statusu tego dokumentu w EOD. Wymagalne Strona 161 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_030 System zapewni współdziałanie mechanizmów kontroli obiegu dokumentów komponentów ERP i EOD. Musi być możliwe uzależnienie wykonania czynności w EOD od statusu operacji związanej z dokumentem w odpowiedniej funkcji komponentu ERP. Wymagalne EOD_031 System zapewni współdziałanie mechanizmów kontroli obiegu dokumentów komponentów EPM i EOD. Musi być możliwe uzależnienie wykonania operacji związanej z danym dokumentem w dowolnym module komponentu EPM od statusu tego dokumentu w EOD. Wymagalne EOD_032 System zapewni współdziałanie mechanizmów kontroli obiegu dokumentów komponentów EPM i EOD. Musi być możliwe uzależnienie wykonania czynności w EOD od statusu operacji związanej z dokumentem w dowolnym module komponentu EPM. Wymagalne Obsługa dokumentów EOD_033 System musi spełniać następujące wymagania dot. zabezpieczeń dokumentów w trakcie obiegu i w repozytorium: ‐ istnieje możliwość zapewnienia ochrony na poziomie użytkownika, grupy i typu dokumentów, ‐ obsługa zabezpieczeń stosowanych do wszystkich rodzajów obiektów zarządzanych przez system, w tym typów dokumentów, folderów, pojedynczych dokumentów, atrybutów, węzłów przepływu pracy, ‐ istnieje mechanizm obsługi pojedynczych użytkowników oraz grup/ról użytkowników, ‐ istnieje mechanizm regulujący uprawnienia poszczególnych użytkowników w zakresie czynności z dokumentami (wprowadzanie, usuwanie, modyfikowanie, wyszukiwanie, wyświetlanie, drukowanie), ‐ istnieje obsługa zabezpieczeń stosowanych do wszystkich rodzajów obiektów zarządzanych przez system, w tym zadań przepływu pracy, typów dokumentów, folderów, atrybutów, ‐ istnieje możliwość logicznego podziału systemu przez definiowanie domen administracyjnych, z których każda będzie miała własnego administratora i użytkowników z prawami dostępu ograniczonymi do tego konkretnego obszaru. Wymagalne EOD_034 System musi mieć możliwość budowania hierarchicznego modelu uprawnień. Wymagalne EOD_035 System musi zapewniać możliwość określenia dokładnych praw na poziomie pojedynczego użytkownika, pojedynczego dokumentu oraz pojedynczej funkcji systemu.
Wymagalne EOD_036 System musi umożliwiać definiowanie nowych (modyfikację istniejących) typów obsługiwanych dokumentów wraz z definicją formularzy służących do ich ewidencjonowania, obiegu, szablonów wydruku, numeracji i innych elementów konfiguracji.
Wymagalne EOD_037 System musi zapewnić przechowywanie dowolnego typu danych cyfrowych, w tym: dokumentów biurowych (MS Office), obrazów (dokumentów skanowanych), dokumentów tekstowych, plików dźwiękowych i filmowych, dokumentów XML i HTML, danych wyjściowych (raportów) generowanych przez aplikacje komputerowe, poczty elektronicznej, itp. Wymagalne EOD_038 System musi zawierać mechanizm opisywania dokumentów za pomocą atrybutów (metadanych). Wymagalne EOD_039 System musi umożliwiać definiowanie zestawów atrybutów dla poszczególnych typów dokumentów. Wymagalne EOD_040 System musi umożliwiać definiowanie i dodawanie własnych atrybutów. Wymagalne EOD_041 System musi umożliwiać automatyczne nadawanie zestawu metadanych w zależności od miejsca przechowywania dokumentu. Wymagalne EOD_042 System musi zapewnić odtwarzanie dokumentów w repozytorium danych z kopii zapasowych. Wymagalne EOD_043 System musi zapewnić pobieranie informacji o dokumentach i ich atrybutach. Wymagalne EOD_044 System musi zapewnić import i eksport dokumentów niezależnie od formatu pliku (fax, e‐mail) do lokalnego systemu plików w ramach posiadanych uprawnień. Wymagalne EOD_045 System musi zapewnić zamianę przypisania typu dokumentu bez konieczności jego ponownego skanowania lub importowania. Wymagalne EOD_046 System musi posiadać mechanizm subskrypcji ‐ powiadamiania e‐mail o zmianach danego dokumentu. Wymagalne Strona 162 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_047 System musi zapewnić funkcję pobierania dokumentu z repozytorium i zwracania do niego (check‐out, check‐in). Wymagalne EOD_048 System powinien zapewniać funkcjonalność dostępu do repozytorium (check‐in dokumentu, check‐out dokumentu, otwarcie kopii dokumentu, skopiowanie na lokalną stację roboczą) przez uprawnionych użytkowników przy pomocy techniki przeciągnij i upuść (ang. Drag and Drop). Opcjonalne EOD_049 System musi zapewnić możliwość obsługi dokumentów złożonych oraz obsługę struktur hierarchicznych dla relacji typu „podrzędny‐nadrzędny” oraz „każdy z każdym” między dokumentami i powiązanymi atrybutami indeksów. Wymagalne EOD_050 System musi zapewnić stosowanie powiązań atrybutów pomiędzy różnymi typami dokumentów. Wymagalne EOD_051 System musi zapewnić migrację dokumentów za pośrednictwem systemu zarządzania hierarchiczną pamięcią masową w celu automatycznej archiwizacji dokumentów na urządzeniach optycznej, taśmowej lub innej pamięci masowej, zgodnie z regułami biznesowymi i przepisami prawnymi dotyczącymi przechowywania dokumentów. Wymagalne EOD_052 System powinien umożliwiać przechowywanie dokumentów w wielu fizycznych repozytoriach różnego typu (w tym powinien posiadać wsparcie dla takich elementów jak systemy plików, bazy danych, inne systemy składowania treści). Konieczna jest możliwość automatycznego przypisania do repozytorium w zależności od atrybutów dokumentu. Opcjonalne EOD_053 System musi zapewnić powiększanie i pomniejszanie wyświetlanego obrazu lub dokumentu. Wymagalne EOD_054 System musi zapewnić obracanie obrazu na ekranie. Wymagalne EOD_055 System powinien zapewnić nawigowanie między stronami przy użyciu miniatur. Opcjonalne EOD_056 System musi posiadać następujące funkcje w zakresie drukowania dokumentów: ‐ drukowanie określonych zakresów stron, w tym bieżącej strony i wszystkich stron dokumentów, ‐ drukowanie wielu kopii, ‐ wykorzystanie drukarek sieciowych, ‐ współpraca z drukarkami zapewniającymi wydruk bezpieczny (zabezpieczony PIN). Wymagalne EOD_057 System powinien posiadać następujące funkcje w zakresie obsługi adnotacji: ‐ tworzenie, edytowanie, wyświetlanie, ukrywanie, zmiana rozmiaru położenia oraz usuwania adnotacji, ‐ zapisywanie elementów adnotacji osobno, z możliwością ich wyświetlania lub ukrywania przez użytkowników podczas przeglądania dokumentów, ‐ możliwość zastosowania narzędzi do znacznikowania, takich jak cyfrowe pieczątki, datowniki, wyróżnianie, notatki, pola tekstowe, okręgi, linie, strzałki itp., w celu dodawania adnotacji do dokumentów, ‐ drukowanie adnotacji, ‐ eksportowanie uwag i adnotacji w postaci osobnych plików. Opcjonalne EOD_058 System musi umożliwiać tworzenie przez inicjatora projektu dokumentu (np.: projekt pisma, pełnomocnictwa lub aktu normatywnego). Wymagalne EOD_059 System musi wykrywać duplikaty pism przychodzących. Wymagalne EOD_060 System powinien umożliwiać wydruk oznaczenia dokumentu kodem kreskowym (wydruk naklejki, wydruk na dokumencie papierowym) z automatycznym zapisaniem oznaczenia w metryce dokumentu. Opcjonalne EOD_061 System musi umożliwiać definiowanie i edytowanie szablonów pism wychodzących oraz udostępnianie ich użytkownikom. Wymagalne EOD_062 System powinien zapewniać możliwość przejścia z poziomu systemu bezpośrednio do edycji załącznika w odpowiedniej, przypisanej do danego formatu pliku aplikacji dostępnej na stacji roboczej. Wymagalne EOD_063 System musi zapewniać wyświetlanie dokumentów w ich rodzimych formatach, bądź posiadać możliwość uruchamiania, w razie potrzeby, rodzimych aplikacji lub przeglądarek. Wymagalne Strona 163 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_064 Pola dokumentów/formularzy muszą być automatycznie wypełniane przez system na podstawie danych przechowywanych w bazie danych. Wymagalne EOD_065 Dokumenty powinny być tworzone w ogólnodostępnym edytorze tekstu, a następnie wprowadzane do systemu zarządzania dokumentami i udostępniane według potrzeb także na ekranach funkcjonalnych aplikacji ERP. Opcjonalne Wyszukiwanie/przeglądanie dokumentów EOD_066 System musi zapewnić przechowywanie i wyszukiwanie pism (bieżących i archiwalnych) wchodzących i wychodzących do/z działu. Wymagalne EOD_067 System musi umożliwić kontekstowe wyszukiwanie informacji zawartej w dokumentach. Wymagalne EOD_068 System musi mieć wbudowaną wyszukiwarkę dokumentów i spraw umożliwiających wyszukanie dokumentu/sprawy w obiegu po każdym polu z metryki dokumentu oraz po fragmencie pola i kombinacji pól. Wymagalne EOD_069 System musi dostarczyć następujące sposoby wyszukiwania dokumentów i folderów w repozytorium: ‐ po atrybutach przypisanych do pliku dokumentu, nadanych przez użytkownika lub system, jak i w trybie pełnotekstowym po zawartości pliku dokumentu, a także w połączeniu obu tych metod (np. data, autor, temat, słowa kluczowe, fraza, znak sprawy), ‐ po nazwie folderu, ‐ wyszukiwanie wszystkich dostępnych wersji dokumentu, ‐ z zastosowaniem złożonych wyrażeń w zapytaniach z użyciem kombinacji operatorów logicznych, ‐ ze stronicowaniem wyników wyszukiwania, ‐ możliwość wyświetlania wyników wyszukiwania w osobnym oknie i możliwość jednoczesnego wyświetlania wielu zestawów wyników. Wymagalne EOD_070 System powinien umożliwiać wyszukiwanie dokumentu w wielu fizycznych repozytoriach. Opcjonalne EOD_071 System powinien umożliwiać pozycjonowanie wyników wyszukiwania w zależności od adekwatności i popularności dokumentów. Opcjonalne EOD_072 System musi umożliwiać przeglądanie spraw co najmniej w kontekście: ‐ RWA, ‐ jednostki organizacyjnej, ‐ referenta (pracownika odpowiedzialnego), ‐ statusu, ‐ wymaganych terminów realizacji. Wymagalne EOD_073 System musi umożliwiać wyszukiwanie dokumentów z wykorzystaniem oznaczenia kodem kreskowym. Wymagana jest integracja z czytnikami kodów paskowych w kancelarii i sekretariatach. Wymagalne Obieg dokumentów EOD_074 System musi zapewniać funkcjonalność pracy grupowej nad dokumentami ‐ wykorzystanie elektronicznego przepływu pracy (workflow w systemie). Wymagalne EOD_075 System musi zapewnić monitorowanie aktualnego zaawansowania prac nad dokumentem i jego procedowaniem zgodnie ze ścieżką obiegu dokumentów. Wymagalne EOD_076 System w każdym momencie musi zapewniać kontrolę stanu sprawy zgodnie ze zdefiniowanymi uprawnieniami. Wymagalne EOD_077 System musi zapewnić wyświetlanie zadań do wykonania wynikających z kroku procesu w jednolitym widoku zadań (łącznie z zadaniami wynikającymi z dekretacji ad‐hoc). Wymagalne EOD_078 System musi informować o zatwierdzeniu dokumentu przez przełożonych (kierownik/dyrektor/prezes) w formie komunikatu systemowego, maila. Wymagalne EOD_079 System musi umożliwiać, zarówno w systemie jak i za pomocą raportu, śledzenie przepływu Wymagalne Strona 164 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
dokumentów i pozwalać na określenie jednostek opóźniających ich przetwarzanie. EOD_080 System musi generować komunikaty (w ramach systemu oraz poprzez pocztę elektroniczną) do zdefiniowanych użytkowników w przypadku wystąpienia opóźnień w realizacji spraw i zadań. Wymagalne EOD_081 System musi mieć możliwość komunikowania (w ramach systemu oraz poprzez pocztę elektroniczną) osobom biorącym udział w procesie zatwierdzania/uzgadniania treści dokumentów konieczności akceptacji/zatwierdzenia dokumentów do nich przekazanych. System powinien również informować o przydzieleniu pisma (np. otrzymanego z kancelarii) przekazanego do danej osoby itd. Wymagalne EOD_082 W ramach elektronicznego obiegu dokumentów osoba, u której jest dokument musi być monitowana, np. poprzez pocztę elektroniczną, o zbliżaniu się terminu wykonania czynności na dokumentach. Wymagalne EOD_083 System musi mieć możliwość monitorowania spraw zakończonych i niezakończonych oraz przesyłania powiadomień do osób odpowiedzialnych o konieczności przekazania do archiwum spraw już zakończonych (np. w formie listy spraw). Wymagalne EOD_084 System musi umożliwić nadawanie atrybutów elektronicznym wersjom dokumentów (nazwa, status, opis zawartości, wybrane dane). Wymagalne EOD_085 System musi umożliwić podgląd elektronicznej wersji dokumentu, wersjonowanie i archiwizację oraz obsługę proceduralnych ścieżek obiegu. Wymagalne EOD_086 System musi obsługiwać definiowane procesy obiegu dokumentów. Musi umożliwiać zawieszanie i wznawianie procesu przepływu według określonej daty lub w oczekiwaniu na zdarzenie, zapewnić przesyłanie dokumentu do zainteresowanych komórek, a także zapewniać możliwość śledzenia miejsca dokumentu w obiegu. System musi zapewnić możliwość uruchamiania procesu obiegu dokumentów z widoku folderu. Wymagalne EOD_087 System musi obsługiwać obiegi dokumentów ad‐hoc dla typów dokumentów skojarzonych ze zdefiniowanym procesem, jak i dokumentów dekretowanych ręcznie.
Wymagalne EOD_088 System musi zapewniać alternatywne obiegi dokumentów w zależności od decyzji podejmowanych w obiegu oraz od wartości cech dokumentów/spraw. Wymagalne EOD_089 System musi zapewnić elektroniczny obieg dokumentów uwzględniając archiwizację, uprawnienia dostępu, pilnowanie ścieżek zatwierdzania i wersjonowania dokumentów. Wymagalne EOD_090 System powinien realizować obiegi dokumentów w oparciu o Silnik Procesów Biznesowych zgodny ze standardem BPMN 2.0. Opcjonalne EOD_091 System musi zapewnić możliwość obiegu i wypełniania ankiet umożliwiających ewidencjonowanie danych związanych z wyliczaniem wskaźników jakościowych. Wymagalne Wersjonowanie/archiwizacja wersji EOD_092 Dla wszystkich dokumentów przechowywanych w repozytorium systemu EOD wymagana jest obsługa wersji. Wymagalne EOD_093 System powinien zapewnić automatyczne zapisywanie kolejnej wersji załącznika plikowego po każdym zapisaniu operacji wykonanej przez użytkownika w aplikacji przypisanej do danego formatu. Opcjonalne EOD_094 System powinien zapewniać dziedziczenie wartości atrybutów dokumentu z wersji poprzednich. Opcjonalne EOD_095 System powinien zachowywać adnotacje w kolejnych wersjach. Opcjonalne EOD_096 System musi udostępniać archiwalne (poprzednie) wersje przechowywanych dokumentów. Wymagalne EOD_097 Wszystkie operacje dotyczące sprawy muszą być rejestrowane w historii wraz ze szczegółowymi danymi dotyczącymi operacji, użytkownika, daty i godziny wykonania operacji, adnotacji użytkownika. Wymagalne EOD_098 System musi wspomagać uzgadnianie treści pisma, nanoszenie zmian oraz wersjonowanie. Wymagalne EOD_099 W związku z tym, iż w PAŻP występują okresowo zmiany w strukturze organizacyjnej lub zakresie Wymagalne Strona 165 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
obowiązków, system musi mieć możliwość przechowywania historii zmian dotyczących przypisania dokumentów do komórek organizacyjnych. EOD_100 System powinien zapewniać sterowanie kontrolą wersji według typu dokumentu – nie każdy typ wymaga kontroli wersji. Opcjonalne Eksport danych z systemu EOD_101 System musi umożliwiać eksport dokumentów cyfrowych do różnych formatów plików (PDF, DOC, DOCX, ODT, RTF, TXT). Wszystkie programy obsługujące dokumentację powinny obsługiwać wymienione formaty bez konieczności zakupu dodatkowego oprogramowania dla plików typu tekstowego. Wymagalne EOD_102 System musi zapewnić eksport widoków danych (użytkownik musi mieć możliwość wyboru eksportowanych pól) do plików w formatach co najmniej: XLS, XLSX, CSV, PDF, HTML, RTF. Wymagalne Załączanie dokumentów EOD_103 Korespondencja obsługiwana w ramach systemu EOD musi mieć możliwość dołączania załączników elektronicznych (obsługa różnych formatów w szczególności: pliki graficzne, pliki pakietów biurowych, dokumenty skanowane, maile, faksy, pliki dźwiękowe). Wymagalne EOD_104 System musi zapewnić rejestrację uwag w powiązaniu z analizą bezpieczeństwa min. kto zgłasza uwagę, kiedy, treść i status. Wymagalne EOD_105 System musi umożliwiać zapisanie fizycznej lokalizacji oryginału załącznika papierowego i śledzenie jego obiegu niezależnie do obiegu dokumentów elektronicznych. Wymagalne EOD_106 System musi współpracować ze skanerami sieciowymi i lokalnymi w celu dodawania dokumentów do rejestru korespondencji. (Skanery sieciowe i lokalne nie są przedmiotem zamówienia.) Wymagalne EOD_107 System musi obsługiwać formaty pliku przy skanowaniu dokumentu zapewniające wielostronicowe skanowanie dokumentów. Wymagalne EOD_108 System powinien zapewnić automatyczne nadawanie nazwy skanowanym dokumentom według definiowalnych kryteriów. Opcjonalne EOD_109 Dla skanowanych dokumentów system musi umożliwiać optyczne rozpoznawanie tekstu OCR na dokumentach przechowywanych w formie graficznej i konwersję tych dokumentów do plików tekstowych. Wymagalne EOD_110 Wbudowany w system komponent OCR nie powinien ograniczać liczby użytkowników systemu. Opcjonalne EOD_111 System powinien zapewnić dostęp do map satelitarnych, topograficznych itp. Opcjonalne Obsługa korespondencji EOD_112 System musi zapewniać obsługę obiegu korespondencji wewnętrznej. Wymagalne EOD_113 System powinien umożliwiać również spersonalizowaną dystrybucję informacji o aktualizacji dokumentów ZSZ. Opcjonalne EOD_114 System musi zapewnić obsługę wielu sekretariatów w zakresie obsługi korespondencji przychodzącej i wychodzącej. Wymagalne EOD_115 Dokumenty rejestrowane w systemie muszą być opisane za pomocą metryki zawierającej najważniejsze informacje o danym dokumencie. Wymagalne EOD_116 Metryka korespondencji przychodzącej w szczególności musi zawierać następujące informacje: ‐ data wystawienia/utworzenia dokumentu, ‐ data wpływu (podpowiadana przez system, z możliwością jej modyfikacji dla uprawnionych użytkowników), ‐ typ dokumentu (wniosek, pismo, skarga, inny na podstawie zdefiniowanego słownika), Wymagalne Strona 166 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐ sposób dostarczenia (np. osobiście, pocztą, mailem, faksem, itp.), ‐ dane nadawcy/odbiorcy (powiązanie z centralną kartoteką kontrahentów), ‐ kod kreskowy, ‐ krótki opis korespondencji, streszczenie pisma, ‐ nr zawarty na piśmie (znak obcy pisma), ‐ numer ewidencyjny ‐ liczbę załączników do pisma, ‐ listę załączników elektronicznych, ‐ status w obiegu ‐ inne dane zależne od typu dokumentu (np. dla faktury zakupowej termin zapłaty i kwota). EOD_117 System musi generować do pliku dziennik korespondencji przychodzącej i wychodzącej. Wymagalne EOD_118 System musi zapewnić obsługę spraw w wielu definiowalnych rejestrach korespondencji. Wymagalne EOD_119 System musi zapewniać nadawanie kontrolki wpływu pism przychodzących. Wymagalne EOD_120 System musi zapewnić łączenie korespondencji ze sprawami, możliwość określenia typu i statusu korespondencji. Wymagalne EOD_121 System musi zapewnić obsługę korespondencji przychodzącej ‐ wprowadzenie dokumentu do systemu, skanowanie dokumentu, nadawanie kontrolki wpływu, dekretowanie, przesyłanie elektronicznej wersji dokumentu do osoby odpowiedzialnej, nadawanie numeru sprawy. Wymagalne EOD_122 Dla korespondencji przychodzącej w formie papierowej system musi umożliwiać skanowanie dokumentu i automatyczne załączanie w postaci załącznika do dokumentu zarejestrowanego w kancelarii/sekretariacie. Wymagalne EOD_123 Dla korespondencji przychodzącej w kancelarii i w sekretariatach system musi umożliwiać wydrukowanie potwierdzenia przyjęcia korespondencji.
Wymagalne EOD_124 System musi umożliwiać wstępną rejestrację pism, nadając numer w książce podawczej oraz umożliwiać późniejsze uzupełnienie pozostałych pól w trakcie pełnej rejestracji pisma. Wymagalne EOD_125 System musi umożliwiać automatyczną rejestrację korespondencji dostarczonej pocztą elektroniczną na skonfigurowane adresy e‐mail organizacji bądź komórki organizacyjnej i/lub poprzez formularze elektroniczne. Wymagalne EOD_126 System musi zapewnić obsługę korespondencji wychodzącej ‐ rejestracja dokumentu i dalsze procesowanie. Wymagalne EOD_127 System musi automatyzować prowadzenie książki nadawczej dla korespondencji wychodzącej (m.in. poprzez generowanie książki nadawczej w standardzie Poczty Polskiej) osobnej dla listów poleconych (z możliwością wydruku) i dla pozostałych listów. Wymagalne EOD_128 System musi mieć możliwość agregacji wszystkich form wejścia pisma, w szczególności: dostarczenie osobiste, list, list polecony, kurier, e‐mail, fax. Wymagalne EOD_129 System musi zapewnić możliwość rejestracji paczek przychodzących/wysyłanych z PAŻP wraz z możliwością powiadamiania adresata o nadejściu przesyłki. Wymagalne EOD_130 System musi mieć możliwość generowania raportu Kancelarii z całego dnia ‐ osobno dla korespondencji przekazanej do Prezesa i osobno dla pozostałej korespondencji. Wymagalne EOD_131 System musi mieć zdefiniowany słownik sposobów wysłania pisma do adresata (np. e‐mail, fax, poczta, itp.) i wspomagać elektroniczne wysyłanie pism w kancelarii. Wymagalne EOD_132 System musi obsługiwać dokumenty potwierdzające dostarczenie pisma adresatowi (tzw. zwrotki). Wymagalne Obsługa spraw EOD_133 Dla spraw obsługiwanych w systemie system musi umożliwić tworzenie wielu teczek i podteczek elektronicznych, w których są umieszczane sprawy. Wymagalne Strona 167 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_134 Klasyfikacja spraw w systemie musi być zgodna z JRWA. System musi również posiadać narzędzia importu eksportu struktur JRWA oraz jej wersjonowania. Wymagalne EOD_135 System musi zapewnić automatyczną dekretację spraw (według zdefiniowanego obiegu ‐ procesu). Wymagalne EOD_136 System musi zapewnić dekretację spraw/dokumentów wg klucza: ‐ adresat dekretacji (użytkownik, stanowisko, jednostka organizacyjna), ‐ dyspozycja, ‐ termin realizacji, ‐ priorytet. Wymagalne EOD_137 System musi zapewniać alternatywne obiegi spraw w zależności od decyzji podejmowanych w obiegu oraz od wartości cech dokumentów/spraw. Wymagalne EOD_138 Rejestr spraw w systemie musi być powiązany z rejestrem dokumentów. Wymagalne EOD_139 Dla zarejestrowanych spraw system musi mieć możliwość określania wymagalnych terminów realizacji poszczególnych zadań w ramach sprawy. Wymagalne EOD_140 System musi zapewnić możliwość zmiany referenta i jednostki organizacyjnej dla sprawy. Wymagalne EOD_141 System musi zapewnić obsługę spraw wieloletnich. W szczególności musi umożliwić przenoszenie spraw na kolejne lata wraz z możliwością zmiany numeru sprawy na aktualny rok i zachowania w historii numeru z poprzedniego roku. Wymagalne EOD_142 System musi umożliwiać przełożonemu zmianę dekretacji spraw podległych pracowników prowadzących sprawę. Wymagalne Wymagania dotyczące konfiguracji Konfiguracja formularzy EOD_143 System musi mieć wbudowany lub zintegrowany edytor formularzy elektronicznych, możliwych do wykorzystania do obsługi spraw i elektronicznego przepływu pracy (np. wypełnianie danych dla hurtowni danych, wyznaczanie wskaźników jakościowych nie liczbowych). Wymagalne EOD_144 Edytor formularzy powinien zapewniać graficzne modelowanie formularza metodą "przeciągnij i upuść" (drag and drop). Opcjonalne EOD_145 System musi zapewniać dostępność standardowych kontrolek HTML, co najmniej: ‐ listy wyboru, ‐ pola tekstowe, ‐ listy rozwijane, ‐ sekcje, ‐ sekcje powtarzalne ‐ możliwość tworzenia zakładek. Wymagalne EOD_146 System musi zapewnić możliwość tworzenia reguł walidacji pól formularza, co najmniej: ‐ zależności między polami w formularzu, ‐ integracja pól formularza z edytorem słowników, ‐ oznaczanie wymagalności pól formularza, ‐ dodawanie treści pomocy do dowolnych pól, ‐ zależność od wartości pól powiązanych dokumentów. Wymagalne Konfiguracja dokumentów, spraw i obiegów EOD_147 System musi mieć możliwość konfiguracji automatycznego numerowania dokumentów i spraw według zadanych kryteriów wykorzystujących informacje zarejestrowane w bazie danych. Wymagalne EOD_148 System musi umożliwiać definiowanie nowych procesów, modyfikację już istniejących procesów w przypadku zachodzenia zmian w strukturze organizacyjnej, strukturze zadań czy sposobie realizacji zadań w PAŻP. Wymagalne Strona 168 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_149 System musi umożliwiać zdefiniowanie dowolnej liczby procesów za pomocą wbudowanego edytora procesów, który pozwala na definiowanie nowych procesów (workflow) w powiązaniu z edytorem formularzy używanych do rejestracji i obsługi spraw. Ponad to system będzie posiadał interfejs graficzny do definiowania atrybutów, typów dokumentów, list prac, procesów przepływu pracy. Wymagalne EOD_150 Dla wybranych spraw/dokumentów system musi mieć możliwość konfigurowania strukturalnych informacji związanych z dokumentem i wykorzystania ich w innych modułach systemu (np. dekretacja kosztowa faktury zakupowej wykorzystywana w schematach dekretacji księgowej dokumentu). Wymagalne EOD_151 System musi mieć możliwość tworzenia i modyfikowania szablonów dokumentów w celu wykorzystania ich z poziomu aplikacji (np. dla pism wychodzących, wewnętrznych i innych dokumentów), z możliwością wstawiania do treści pisma znaczników, których zawartość jest automatycznie odczytywana z bazy danych dokumentów i interesantów. Wymagalne EOD_152 System musi mieć możliwość konfigurowania rodzajów, treści i terminów automatycznych powiadomień (komunikat systemowy, wiadomość e‐mail). Wymagalne EOD_153 Powinno być dostarczone narzędzie pozwalające na modelowanie i symulację procesów biznesowych wspierające pracę grupową w kontekście modelowania i symulacji procesów dotyczących obsługi spraw, zadań i dokumentów. Opcjonalne Konfiguracja rejestrów EOD_154 System musi mieć możliwość utworzenia nowego rejestru, zdefiniowania dla niego struktury oraz wartości domyślnych wybranych pól za pomocą graficznego edytora. Wymagalne EOD_155 System musi umożliwiać konfigurację rejestrów prowadzonych w systemie. Wymagalne EOD_156 System musi zapewnić konfigurowanie uprawnień dostępu (wstawianie, usuwanie, modyfikacja, przegląd) do poszczególnych rejestrów. Wymagalne EOD_157 System musi zapewniać możliwość określenia dla każdego pola w rejestrze: ‐ typu pola (co najmniej: tekst z możliwością zdefiniowania maski numeru, określenia maksymalnej długości; data; słownik – z możliwością zdefiniowania prostego słownika typu kod, opis; numer – z możliwością określenia maski formatu), ‐ wymagalność pola, ‐ reguły walidacji (np. minimalna, maksymalna długość, zakres wartości, zależność od wartości innego pola w rejestrze), ‐ uprawnienia do: widoczności pola, wprowadzania wartości do pola, modyfikacji wartości pola dla użytkowników lub grup użytkowników. Wymagalne Wymagania dotyczące obsługi rejestrów Wymagania ogólne EOD_158 System nie może mieć ograniczenia w liczbie tworzonych rejestrów. Wymagalne EOD_159 System musi mieć możliwość wyeksportowania do pliku (w jednym z formatów: .csv, .xls, .pdf, .html.) wybranego widoku rejestru (wybranych kolumn oraz wierszy). Wymagalne EOD_160 System powinien mieć możliwość importu danych do rejestrów z plików xls, xlsx, csv, txt, na podstawie zdefiniowanego mapowania kolumn na pola. Opcjonalne EOD_161 System musi zapewnić elastyczne wyszukiwanie danych w rejestrze według wartości każdego z pól rejestru lub jego fragmentu oraz kombinacji warunków dotyczących różnych pól. Wymagalne EOD_162 System musi umożliwiać użytkownikowi skonfigurowanie własnego widoku rejestru. Wymagalne Rejestry różne w Systemie EOD_163 System powinien zapewnić Rejestr pełnomocnictw. Opcjonalne Strona 169 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_164 System powinien zapewnić Rejestr zarządzeń. Opcjonalne EOD_165 System powinien zapewnić Rejestr decyzji. Opcjonalne EOD_166 System powinien zapewnić Rejestr komunikatów. Opcjonalne EOD_167 System powinien zapewnić Rejestr pism okólnych. Opcjonalne EOD_168 System powinien zapewnić Rejestr przesyłek kurierskich. Opcjonalne EOD_169 System powinien zapewnić Rejestr pism kierowanych do Prezesa PAŻP. Opcjonalne EOD_170 System powinien zapewnić Rejestr spisów zdawczo‐odbiorczych. Opcjonalne EOD_171 System powinien zapewnić Rejestr zaleceń PKBWL. Opcjonalne EOD_172 System powinien zapewnić Rejestr niezgodności ULC. Opcjonalne EOD_173 System powinien zapewnić Rejestr zleceń na usługi prawne. Opcjonalne EOD_174 System powinien zapewnić Rejestr pieczątek, zawierającego co najmniej dane: status, rodzaj, guma, data, znak sprawy AAZ, znak zlecenia, komórka, dla, nr, nazwa służby/działu/zespołu, stanowisko, ile, kolor, rozmiar, pdf). Opcjonalne EOD_175 System powinien zapewnić Rejestr stempli. Opcjonalne EOD_176 System powinien zapewnić Rejestr wizytówek służbowych, zawierającego co najmniej dane: status, data, znak spraw AAZ, znak zlecenia, komórka, dla, stanowisko, ile pol., ile ang., Druk 1/2 strony, pdf, zlecenie wydruku. Opcjonalne EOD_177 System powinien zapewnić Rejestr referentek. Opcjonalne EOD_178 System powinien zapewnić Rejestr pełnomocnictw w zakresie kontroli zewnętrznych w sekretariacie Prezesa PAŻP. Opcjonalne EOD_179 System powinien zapewnić Rejestr kontroli, zawierającego co najmniej informacje: czy jest to kontrola zewnętrzna/wewnętrzna, kto kontroluje, numer kontroli, daty, oraz danych indywidualnych dla każdego zalecenia (z jednej kontroli wiele zaleceń): treść zalecenia, termin realizacji, kto realizuje zalecenie (zgodnie ze strukturą PAŻP), status wykonania zalecenia. Opcjonalne EOD_180 System powinien zapewnić Rejestr‐słownik procesów i podprocesów oraz obszarów działalności, które nie zostały zdefiniowane w słowniku systemu ERP, a są wymagane dla prowadzenia analiz ryzyka oraz zadań audytowych. Opcjonalne EOD_181 System powinien zapewnić rejestry dotyczące ewidencjonowania danych związanych z wyliczaniem wskaźników jakościowych. Opcjonalne EOD_182 System powinien mieć możliwość prowadzenia rejestru ryzyk. Opcjonalne Prenumerata prasy EOD_183 System powinien zapewnić Rejestr prenumerowanej prasy. Opcjonalne EOD_184 System zapewnić Raport niedostarczonej prasy. Opcjonalne EOD_185 System powinien zapewnić Rejestr wniosków o prenumeratę prasy. Opcjonalne EOD_186 System powinien zapewnić Obieg wniosków o prenumeratę prasy po uprzednim wysłaniu powiadomienia przez dział odpowiedzialny za realizację prenumerat o możliwości wystawiania takiego wniosku na dany rok. Opcjonalne EOD_187 System powinien zapewnić Rejestr zapotrzebowań zbiorczych na prenumeratę prasy przez wszystkie komórki organizacyjne. Opcjonalne Wymagania dotyczące obsługi spraw, zadań i dokumentów Strona 170 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Sprawy różne EOD_188 System musi umożliwiać zdefiniowanie i prowadzenie rejestrów wszystkich typów dokumentów z zakresu działalności jednostki zgodnie z wymaganiami prawnymi dotyczącymi tych dokumentów (np. ewidencja decyzji, zaświadczeń itd.). W szczególności musi również zapewniać wsparcie dla obiegu: • dokumentów finansowych, • dokumentów pracowniczych, • spraw związanych z zarządzaniem audytami, • bezpieczeństwem, • Zintegrowanym Systemem Zarządzania (ZSZ), • dokumentów procesu zakupowego, dokumentów dotyczących tworzenia planów rzeczowych i finansowych, pozostałych typów dokumentów zdefiniowanych przez zamawiającego na etapie wdrożenia. Wymagalne EOD_189 System powinien zapewnić Rejestr aktów normatywnych oraz umożliwić wybór ścieżki akceptacji projektu danego dokumentu. Opcjonalne EOD_190 System powinien zapewnić Obieg wniosku o realizację wyjazdu służbowego zagranicznego. Opcjonalne EOD_191 System powinien zapewnić Obieg wniosku o realizację wyjazdu krajowego. Opcjonalne EOD_192 System powinien zapewnić Obieg Rocznego Planu wyjazdów zagranicznych . Opcjonalne EOD_193 System powinien zapewnić Obieg Harmonogramu podróży służbowej zagranicznej. Opcjonalne EOD_194 System powinien zapewnić Obieg Sprawozdania z podróży służbowej zagranicznej. Opcjonalne EOD_195 System powinien mieć możliwość utworzenia pozostałych obiegów związanych z realizacją wyjazdów służbowych (krajowych i zagranicznych). Opcjonalne EOD_196 System powinien zapewnić Rejestr zarezerwowanych biletów lotniczych. Opcjonalne EOD_197 System powinien zapewnić Obieg projektu dokumentu aktu normatywnego. Opcjonalne EOD_198 System powinien zapewnić Obieg projektu dokumentu pełnomocnictwa. Opcjonalne EOD_199 System powinien zapewnić Obieg dokumentów dotyczących wykorzystania samochodu prywatnego w celach służbowych. Opcjonalne EOD_200 System powinien zapewnić Obieg wniosku o wydanie pieczątek. Obieg dotyczy wszystkich rodzajów pieczątek ‐ imiennych, firmowych, datowników itp. Opcjonalne EOD_201 System powinien zapewnić Obieg wniosku o wydanie wizytówek. Opcjonalne EOD_202 System powinien zapewnić Obieg wniosku o wydanie stempli. Opcjonalne EOD_203 System powinien zapewnić Obieg wniosku o wydanie referentek. Opcjonalne EOD_204 System powinien zapewnić Rejestr umów w przygotowaniu. Opcjonalne EOD_205 System powinien zapewnić Obieg formularza akceptacji umowy (powiązany z obiegiem uzgodnienia umowy), na którym każda z akceptujących treść umowy osób potwierdza swoją akceptację. Ewentualne uwagi wnoszone są w tekście umowy/aneksu i powinny być widoczne dla innych uczestników procesu akceptacyjnego, włącznie z informacją o dacie wstawienia uwagi oraz o osobie, która ją wstawiła. Opcjonalne EOD_206 System powinien zapewnić Obieg formularza akceptacji aneksu (powiązany z obiegiem uzgodnienia aneksu), na którym każda z akceptujących treść umowy osób potwierdza swoją akceptację. Ewentualne uwagi wnoszone są w tekście umowy/aneksu i powinny być widoczne dla innych uczestników procesu akceptacyjnego, włącznie z informacją o dacie wstawienia uwagi oraz o osobie, która ją wstawiła. Opcjonalne Strona 171 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_207 System powinien zapewnić Obieg zgłaszania poprawek do umowy/aneksu w określonej kolejności. Opcjonalne EOD_208 System powinien zapewnić Obieg planu przeglądów technicznych, uwzględniającego edycję planu, modyfikację i zatwierdzanie planu przeglądów. Opcjonalne EOD_209 System powinien zapewnić Obieg wniosków dot. planu przeglądów technicznych. Opcjonalne EOD_210 System musi mieć Obieg planów remontów, uwzględniającego składanie wniosków, wielopoziomową weryfikację wniosków do planu (wstępna, formalna, finansowa), tworzenie planu i wielopoziomowe zatwierdzanie planu (zatwierdzenia przez dyrektora komórki remontowej, akceptacja prezesa). Wymagalne EOD_211 System powinien zapewnić Obieg wniosków o przydzielenie i korzystanie z pojazdu służbowego. Opcjonalne EOD_212 System powinien zapewnić Obieg kart rozliczeń kosztów eksploatacji pojazdów. Opcjonalne EOD_213 System musi mieć Obieg akceptacji cennika stawek. Wymagalne EOD_214 System powinien zapewnić Obieg zatwierdzania oferty. Opcjonalne EOD_215 System musi obsługiwać obieg sprawy dotyczącej przyjęcia nowego członka PKZP. Wymagalne EOD_216 System musi obsługiwać obieg sprawy dotyczącej udzielenia pożyczki członkowi PKZP. Wymagalne EOD_217 System musi obsługiwać obieg sprawy dotyczącej wypłaty zapomogi członkowi PKZP. Wymagalne Opinie prawne EOD_218 System powinien zapewnić Obieg wniosku zlecenia opinii prawnej do kancelarii zewnętrznej. Obieg powinien umożliwiać wypełnienie wniosku przez komórkę merytoryczną w zakresie zlecania opinii prawnej do kancelarii zewnętrznej, w tym przekazanie do akceptacji i realizacji zgodnie z ustaloną ścieżką akceptacyjną wraz z możliwością dołączania załączników. Opcjonalne EOD_219 System powinien zapewnić Obieg wysyłki zlecenia opinii prawnej do kancelarii. Opcjonalne EOD_220 System powinien zapewnić Obieg wysyłki otrzymanej od kancelarii opinii prawnej do komórki merytorycznej Agencji. Opcjonalne EOD_221 System powinien mieć możliwość integracji modułu obsługującego zlecenia do zewnętrznych kancelarii prawnych z modułem zarządzania umowami. W szczególności system powinien mieć możliwość monitorowania kosztów za daną opinię prawną w powiązaniu z umową oraz sygnalizowania zbliżającego się okresu zakończenia umowy z powodu wyczerpania środków finansowych, bądź terminu obowiązywania umowy. System musi umożliwiać podgląd umów z zewnętrznymi kancelariami prawnymi. Opcjonalne EOD_222 System powinien zapewnić integrację modułu obsługującego zlecenia do zewnętrznych kancelarii prawnych z modułem księgowym m.in. w zakresie rozliczania zewnętrznych dokumentów finansowych. Dotyczy to głównie faktur otrzymanych z zewnętrznych kancelarii prawnych za wykonane usługi za dany miesiąc w ramach podpisanych umów.
Opcjonalne EOD_223 System powinien umożliwiać automatyczne generowanie wiadomości e‐mail ze zleceniem do właściwej zewnętrznej kancelarii prawnej. Opcjonalne EOD_224 System powinien umożliwiać dołączanie pełnych opinii prawnych, wyroków sądowych w postaci załączników. Opcjonalne EOD_225 System powinien mieć możliwość wprowadzenia danych z otrzymanych raportów (dołączonych do faktur) do Rejestru zleceń na usługi prawne. Opcjonalne Sprawy pracownicze EOD_226 System powinien zapewnić Obieg wniosku o zatrudnienie pracownika. Opcjonalne EOD_227 System powinien zapewnić Obieg wniosku o zmianę warunków umowy. Opcjonalne Strona 172 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_228 System powinien zapewnić Obieg wniosku o zmianę/korektę danych identyfikacyjnych. Opcjonalne EOD_229 System powinien zapewnić Obieg wniosku o zmianę/korektę danych adresowych. Opcjonalne EOD_230 System powinien zapewnić Obieg wniosku o zmianę/korektę danych osobowych. Opcjonalne EOD_231 System powinien zapewnić Obieg wniosku o zgłoszenie członka rodziny. Opcjonalne EOD_232 System powinien zapewnić Obieg wniosku o nabycie uprawnień do renty/emerytury. Opcjonalne EOD_233 System powinien zapewnić Obieg wniosku o nabycie uprawnień z tytułu niepełnosprawności. Opcjonalne EOD_234 System powinien zapewnić Obieg wniosku o nabycie/zmianę uprawnień do urlopu wypoczynkowego. Opcjonalne EOD_235 System powinien zapewnić Obieg wniosku o zmianę jednostki organizacyjnej. Opcjonalne EOD_236 System powinien zapewnić Obieg wniosku o przedłużenie umowy. Opcjonalne EOD_237 System powinien zapewnić Obieg wniosku o oddelegowanie do pracy na inne stanowisko. Opcjonalne EOD_238 System powinien zapewnić Obieg wniosku o awans. Opcjonalne EOD_239 System powinien zapewnić Obieg wniosku o nabycie/zmianę uprawnień do dodatku funkcyjnego/specjalnego. Opcjonalne EOD_240 System powinien zapewnić Obieg wniosku o nabycie uprawnień do innych dodatków płacowych. Opcjonalne EOD_241 System powinien zapewnić Obieg wniosku o zakończenie zatrudnienia. Opcjonalne EOD_242 System powinien zapewnić możliwość konfiguracji w systemie różnorodnych obiegów dokumentów dotyczących dokumentacji OSL z zakresu szkoleń. Opcjonalne EOD_243 System powinien zapewnić Obieg informacji dotyczących przedłużania/braku uprawnień licencjonowanego personelu ATM. Opcjonalne EOD_244 System powinien zapewnić Obieg informacji dotyczących przedłużania/braku uprawnień nielicencjonowanego personelu PAŻP. Opcjonalne EOD_245 System powinien zapewnić Obieg Instrukcji OSL. Opcjonalne EOD_246 System powinien zapewnić Obieg Rocznego Planu Szkoleń. Wymagalne EOD_247 System powinien zapewnić Obieg wniosków szkoleniowych. Opcjonalne EOD_248 System powinien zapewnić Obieg rocznego Finansowego i Tematycznego Planu Szkoleń. Opcjonalne EOD_249 System powinien zapewnić Obieg 5‐letniego Finansowego i Tematycznego Planu Szkoleń. Opcjonalne Umowy dotyczące wykorzystania samochodu prywatnego EOD_250 System musi zapewnić Rejestr wniosków o wykorzystanie samochodu prywatnego do celów służbowych, co najmniej w zakresie imię i nazwisko wnioskodawcy, dane adresowe, uzasadnienie potrzeby wykorzystania prywatnego pojazdu do celów służbowych, termin wyjazdu, wysokość wnioskowanego limitu (opcjonalnie), marka pojazdu, pojemność skokowa silnika, pozycja budżetu i finansowanie, opinia przełożonego. Wymagalne EOD_251 System musi umożliwiać stworzenie przez pracownika szacunkowej analizy kosztów wykorzystania samochodu prywatnego do celów służbowych. Wymagalne EOD_252 System musi umożliwiać przygotowanie umowy do podpisu, w szczególności powinien zapewnić zaczytanie danych pracownika w odpowiednie pola umowy, a następnie po jej podpisaniu wprowadzenie do ewidencji pracowników korzystających z samochodów prywatnych do celów służbowych. Wymagalne Obsługa ubezpieczeń Strona 173 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_253 System powinien zapewnić Rejestr szkód. Opcjonalne EOD_254 System powinien zapewnić Obieg procesu rozliczenia szkody. Opcjonalne EOD_255 System powinien zapewnić Rejestr dokumentacji ubezpieczeniowej. Opcjonalne EOD_256 System powinien zapewnić Rejestr działań w zakresie likwidacji szkód. Opcjonalne EOD_257 System powinien zapewnić Rejestr wzorów dokumentów ubezpieczeniowych. Opcjonalne EOD_258 System powinien zapewnić Obieg procesu planowania finansowego w zakresie ubezpieczeń. Opcjonalne Obsługa audytów, kontroli i przeglądów bezpieczeństwa EOD_259 System powinien zapewnić Rejestr planów audytów. Opcjonalne EOD_260 System powinien zapewnić Obieg uzgodnienia planu audytów. Opcjonalne EOD_261 System powinien zapewnić Rejestr zadań audytowych. Opcjonalne EOD_262 System powinien zapewnić Rejestr osób wspomagających prowadzenie audytów. Opcjonalne EOD_263 System powinien zapewnić Obieg‐powiadomienia o temacie i terminie realizacji zadań z zatwierdzonego planu audytów (przesyłanie informacji do uczestników zadań). Opcjonalne EOD_264 System powinien zapewnić Obieg wniosków o przeprowadzenie zadania audytowego pozaplanowego. Opcjonalne EOD_265 System powinien zapewnić Obieg wniosków o przeprowadzenie zadania audytowego doradczego. Opcjonalne EOD_266 System powinien zapewnić Obieg wniosków o porozumienie (w przypadku zadań doradczych). Opcjonalne EOD_267 System powinien zapewnić Obieg wniosków upoważnień do audytów. Opcjonalne EOD_268 System powinien zapewnić Obieg uzgadniania programu zadania audytowego. Opcjonalne EOD_269 System powinien zapewnić Obieg zatwierdzania informacji związanych z prowadzonym audytem. Opcjonalne EOD_270 System powinien zapewnić Obieg zatwierdzania załączników związanych z audytem. Opcjonalne EOD_271 System powinien zapewnić Obieg zatwierdzania sprawozdań związanych z audytem. Opcjonalne EOD_272 System powinien zapewnić Rejestr analiz bezpieczeństwa, z możliwością dodawania nowych pól (np. adresaci, data wdrożenia, status, faza i inne) przez administratora włączając pola w rejestrach powiązanych, a także walidacja wprowadzanych danych. Opcjonalne EOD_273 System powinien zapewnić Rejestr przeglądów bezpieczeństwa, z możliwością dodawania nowych pól (np. adresaci, data wdrożenia, status, faza i inne) przez administratora włączając pola w rejestrach powiązanych, a także walidacja wprowadzanych danych. Opcjonalne EOD_274 System powinien zapewnić Obieg przypomnień o okresowych przeglądach bezpieczeństwa, co 3 lata, poprzez wysłanie email i powiadomienie wewnątrz systemu, do konfigurowalnej listy odbiorców. Opcjonalne EOD_275 System powinien zapewnić Rejestr rekomendacji po przeglądach bezpieczeństwa i pokontrolnych. Opcjonalne EOD_276 System powinien zapewnić Rejestr pozostałych spraw/dokumentów pokontrolnych nieujętych w pozostałych rejestrach, z możliwością dodawania nowych pól (np. adresaci, data wdrożenia, status, faza i inne) przez administratora włączając pola w rejestrach powiązanych, a także walidacja wprowadzanych danych. Opcjonalne EOD_277 System powinien zapewnić Obieg przypomnień o upływającej dacie wdrożenia rekomendacji i zaleceń bezpieczeństwa. Opcjonalne EOD_278 System powinien zapewnić Obieg‐powiadomienie na 120 dni przed upływem daty ważności wyznaczenia (certyfikatu wydawanego przez jednostkę zewnętrzną (np.: ULC) związane z oceną Opcjonalne Strona 174 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
bezpieczeństwa procedur wykonywanych przez PAŻP). EOD_279 System powinien zapewnić Rejestr kontroli ULC zgodnie z zatwierdzonym programem nadzoru bieżącego. System powinien wysyłać email i powiadomienie wewnątrz systemu, do konfigurowalnej listy odbiorców. Opcjonalne EOD_280 System powinien przechowywać informację o planowanych kontrolach ULC w celu konieczności przewidywania kontroli jako zadania angażującego zasoby pracownicze. Opcjonalne EOD_281 System powinien zapewnić manualną rejestrację niezgodności i zaleceń pokontrolnych ULC i PKBWL, analiz bezpieczeństwa, przeglądów bezpieczeństwa, rekomendacji po przeglądach bezpieczeństwa oraz zaleceń bezpieczeństwa w rozbiciu na poszczególne obszary kontrolowane PAŻP. Opcjonalne EOD_282 System powinien zapewnić wyszukiwanie niezgodności i zaleceń pokontrolnych ULC i PKBWL, analiz bezpieczeństwa, przeglądów bezpieczeństwa, rekomendacji po przeglądach bezpieczeństwa i zaleceń bezpieczeństwa, po dowolnym polu w bazie opisującym te dane. Opcjonalne EOD_283 System powinien zapewnić Obieg uzgodnienia i akceptacji rekordów niezgodności i zaleceń pokontrolnych ULC i PKBWL z uwzględnieniem struktury organizacyjnej PAŻP, w trybie automatycznym zgodnie ze zdefiniowaną ścieżką. Możliwe powinno być także warunkowe definiowanie przebiegu ścieżek w zależności od charakterystyki rekordów. Opcjonalne EOD_284 System powinien zapewnić Obieg uzgodnienia i akceptacji analiz bezpieczeństwa z uwzględnieniem struktury organizacyjnej PAŻP, w trybie automatycznym zgodnie ze zdefiniowaną ścieżką. Możliwe powinno być także warunkowe definiowanie przebiegu ścieżek w zależności od charakterystyki rekordów. Opcjonalne EOD_285 System powinien zapewnić Obieg uzgodnienia i akceptacji przeglądów bezpieczeństwa z uwzględnieniem struktury organizacyjnej PAŻP, w trybie automatycznym zgodnie ze zdefiniowaną ścieżką. Możliwe powinno być także warunkowe definiowanie przebiegu ścieżek w zależności od charakterystyki rekordów. Opcjonalne EOD_286 System powinien zapewnić Obieg uzgodnienia i akceptacji rekomendacji po przeglądach bezpieczeństwa Opcjonalne z uwzględnieniem struktury organizacyjnej PAŻP, w trybie automatycznym zgodnie ze zdefiniowaną ścieżką. Możliwe powinno być także warunkowe definiowanie przebiegu ścieżek w zależności od charakterystyki rekordów. EOD_287 System powinien zapewnić Obieg uzgodnienia i akceptacji zaleceń bezpieczeństwa z uwzględnieniem struktury organizacyjnej PAŻP, w trybie automatycznym zgodnie ze zdefiniowaną ścieżką. Możliwe powinno być także warunkowe definiowanie przebiegu ścieżek w zależności od charakterystyki rekordów. Opcjonalne EOD_288 System powinien zapewnić obieg, uzgodnienia i akceptację rekordów niezgodności i zaleceń pokontrolnych ULC i PKBWL, analiz bezpieczeństwa, przeglądów bezpieczeństwa, rekomendacji po przeglądach bezpieczeństwa i zaleceń bezpieczeństwa, z uwzględnieniem struktury organizacyjnej PAŻP w trybie manualnym tzn. użytkownik, zgodnie ze swoimi uprawnieniami, ręcznie decyduje o kolejnym kroku/krokach obiegu i użytkowniku/dziale odpowiedzialnym za wykonanie. Opcjonalne EOD_289 System powinien zapewnić Obieg powiadomień i dokumentów drogą email i wewnątrz systemu związanych z obiegiem rekordów z niezgodności i zaleceń pokontrolnych ULC i PKBWL, analiz bezpieczeństwa, przeglądów bezpieczeństwa, rekomendacji po przeglądach bezpieczeństwa i zaleceń bezpieczeństwa do zainteresowanych komórek. Opcjonalne EOD_290 System powinien zapewnić Obieg formularza F01‐KP‐SMS (Wydanie zalecenia bezpieczeństwa). Opcjonalne EOD_291 System powinien zapewnić monitorowanie i przypominanie o planowanej dacie realizacji zaleceń pokontrolnych ULC i PKBWL, a także umożliwiać wprowadzanie aktualnego statusu realizacji zalecenia (automatycznie kolorowane statusy) ‐ wysłanie email i powiadomienia wewnątrz systemu, do konfigurowalnej listy odbiorców. Opcjonalne Strona 175 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_292 System powinien zapewnić Obieg i akceptacji dowodów realizacji zaleceń przed wysłaniem ich do ULC lub PKBWL. Opcjonalne EOD_293 System powinien zapewnić Rejestr stanów analiz obsługiwanych w ramach obiegu. Przykładowe stany analiz to: nowa, w opracowaniu, w uzgodnieniach, zatwierdzona. Opcjonalne EOD_294 System powinien zapewnić Obieg formularza F01‐PP‐SMS‐04 (Opis systemu i środowiska dla analizy bezpieczeństwa). Opcjonalne EOD_295 System powinien zapewnić Obieg formularza F02‐PP‐SMS‐04 (Opis systemu i środowiska dla analizy bezpieczeństwa). Opcjonalne EOD_296 System powinien zapewnić Obieg formularza F07‐PP‐SMS‐04 (Raport FHA/PSSA/SSA). Opcjonalne EOD_297 System powinien zapewnić Obieg formularza F04‐PP‐SMS‐04 (Harmonogram bezpieczeństwa). Opcjonalne EOD_298 System powinien zapewnić Obieg formularza F01‐PP‐SMS‐07 (Raportu ze studium bezpieczeństwa). Opcjonalne EOD_299 System powinien zapewnić Obieg formularza F02‐PP‐SMS‐07 (Raportu ze studium bezpieczeństwa). Opcjonalne EOD_300 System powinien zapewnić Obieg zadań związanych z procedurą PP‐SMS‐04 (Ocena i analiza ryzyka incydentów i wypadków lotniczych). Opcjonalne EOD_301 System powinien zapewnić Obieg zadań związanych z procedurą PP‐SMS‐05 (Przeglądy bezpieczeństwa). Opcjonalne EOD_302 System powinien zapewnić Obieg formularza F01‐PP‐SMS‐05 (Planu przeglądów bezpieczeństwa na rok…). Opcjonalne EOD_303 System powinien zapewnić Obieg formularza F02‐PP‐SMS‐05 (Polecenie przeprowadzenia przeglądu bezpieczeństwa) Opcjonalne EOD_304 System powinien zapewnić Obieg formularza F03‐PP‐SMS‐05 (Plan przeglądu bezpieczeństwa). Opcjonalne EOD_305 System powinien zapewnić Rejestr certyfikatów ANSP wraz z przypomnieniem o dacie kończenia się certyfikatu ANSP i dacie ważności specyfikacji operacyjnych certyfikatu na 60 dni przed ‐ wysłanie email i powiadomienie wewnątrz systemu do konfigurowalnej listy odbiorców. Opcjonalne EOD_306 System powinien zapewnić Rejestr zadań związanych z uzyskaniem lub aktualizacją certyfikatów ANSP. Rejestr powinien zapewnić rejestrację (min. opis zadania i planowaną datę realizacji), aktualizację, dystrybucję po komórkach PAZP, monitorowanie wykonania (informacja zwrotna w postaci statusu zadania i daty gotowości do odbycia kontroli ULC) i eskalację zadań. Opcjonalne EOD_307 System powinien zapewnić Obieg‐powiadomienia o zadaniach związanych z uzyskaniem lub aktualizacją certyfikatów ANSP. Obieg powinien zapewniać dystrybucję zadań po komórkach PAZP, monitorowanie ich wykonania (informacja zwrotna w postaci statusu zadania i daty gotowości do odbycia kontroli ULC) i eskalację zadań.
Opcjonalne EOD_308 System powinien zapewnić Rejestr ryzyk.
Opcjonalne
EOD_309 System powinien umożliwiać wprowadzanie danych dotyczących oceny wpływu ryzyka (kategoryzacja wg zdefiniowanych przez PAZP wartości ratingowych) na badany obszar.
Opcjonalne EOD_310 System powinien umożliwiać wprowadzanie danych dotyczących oceny istotności ryzyka / Rating istotności ryzyka (kategoryzacja wg zdefiniowanych przez PAZP wartości ratingowych). Opcjonalne EOD_311 System powinien umożliwiać wprowadzanie danych dotyczących oceny adekwatności obecnej strategii zarządzania ryzykiem (wg zdefiniowanych przez PAZP wartości). Opcjonalne EOD_312 System powinien umożliwiać wprowadzanie danych dotyczących klasyfikacji czynników ryzyka. Opcjonalne EOD_313 System powinien umożliwiać przypisanie osób odpowiedzialnych za ryzyko i jego monitorowanie. Opcjonalne Procedura przepustkowa Strona 176 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_314 System powinien zapewnić Rejestr wniosków o wydanie przepustek zgodnie z instrukcją przepustkową. Opcjonalne EOD_315 System powinien zapewnić Obieg wniosków przepustkowych zgodnie z instrukcją przepustkową. Opcjonalne Wymagania dotyczące obsługi Archiwum i Repozytorium dokumentów Wymagania ogólne EOD_316 System musi zapewniać obsługę Archiwum Zakładowego PAŻP, zgodnie z obowiązującymi w tym zakresie przepisami. Wymagalne EOD_317 System musi umożliwiać stworzenie bazy archiwalnej (bazy dokumentów przechowywanych w Archiwum), zawierającej w szczególności następujące dane: m.in. co zostało przekazane do Archiwum, przez kogo, kiedy, ilość. Wymagalne EOD_318 System musi mieć wbudowane repozytorium dokumentów przechowujące załączniki spraw jak również dokumenty tworzone poza obiegiem dokumentów, a rejestrowane w repozytorium (Archiwum). Wymagalne EOD_319 Wymagalne System musi zapewnić następujące funkcje obsługi folderów dokumentów: ‐ tworzenie i usuwanie folderów, ‐ dodawanie dokumentów do folderów, przenoszenie do folderów i usuwanie z folderów, ‐ przechowywanie w folderach dokumentów o atrybutach różnych od atrybutów opisujących folder, ‐ przechowywanie dokumentów w folderach i podfolderach bez ograniczenia liczby poziomów folderów, ‐ stosowanie zagnieżdżonych folderów w celu zarządzania danymi cyfrowymi dowolnego rodzaju, ‐ tworzenie modelu umożliwiającego automatyczne przypisywanie dokumentów do folderów. EOD_320 Repozytorium dokumentów będące składnikiem systemu musi pozwalać na tworzenie teczek tematycznych z dokumentami. Jeden dokument może być przypisany do wielu teczek. Wymagalne EOD_321 Repozytorium dokumentów będące składnikiem systemu musi zapewniać, aby teczki tematyczne (abstrakcyjne obiekty w repozytorium zawierające fizyczne obiekty w repozytorium) mogły być opisane własnym zestawem metadanych. Wymagalne EOD_322 Repozytorium dokumentów będące składnikiem systemu musi zapewniać, aby teczki tematyczne mogły zawierać dowolną liczbę dokumentów dowolnego typu opisanych dowolnymi meta danymi. Wymagalne EOD_323 Repozytorium dokumentów będące składnikiem systemu musi pozwalać na logiczne łączenie dokumentów. System musi umożliwiać przejście z poziomu widoku dokumentu do innych, połączonych dokumentów. Wymagalne EOD_324 System musi umożliwiać pracownikom Archiwum wyszukiwanie danych (w sprawach przekazanych do Archiwum) z zastosowaniem odpowiednich filtrów dotyczących atrybutów sprawy i dokumentu oraz ich kombinacji i fragmentów wartości. Wymagalne EOD_325 System musi umożliwiać przeglądanie spisów zdawczo ‐ odbiorczych i wydzielanie materiałów na poszczególne kategorie. Wymagalne EOD_326 System musi zapewniać integrację modułu obsługującego Archiwum Zakładowe PAŻP z modułem obsługującym m.in. proces zakupy, w celu zawarcia umowy na zniszczenie akt z dostawca zewnętrznym. Wymagalne EOD_327 System musi obsługiwać integrację modułu obsługującego Archiwum Zakładowe PAŻP z modułem zarządzania umowami, m.in. w celu wglądu do umów nt. brakowania akt i opisania otrzymanej faktury. Wymagalne EOD_328 System powinien prezentować dla użytkownika domyślnie najbardziej aktualną wersję dokumentu, informować go o ilości wersji i umożliwiać zgodnie z uprawnieniami podgląd wcześniejszej wersji pliku wraz z informacją o dacie, autorze i opisie modyfikacji. Opcjonalne EOD_329 System musi być wyposażony w moduł dla systemu MS Windows umożliwiający bezpośredni dostęp do repozytorium dokumentów z aplikacji pakietu Biurowego i pocztowego Microsoft Wymagalne Wymagania szczegółowe Strona 177 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_330 System powinien zapewnić Rejestr przepisów wewnętrznych i zewnętrznych. Opcjonalne EOD_331 System powinien zapewnić Rejestr regulaminów i procedur, zapewniającego informację o zmianach istniejących/wprowadzeniu nowych procedur/instrukcji dot. poszczególnych komórek organizacyjnych, a także udostępniającego jedynie aktualne, zatwierdzone wersje regulaminów i procedur. Opcjonalne EOD_332 System musi posiadać Rejestr Kart udostępnienia akt. Wymagalne EOD_333 System musi umożliwiać wypełnianie Karty udostępniania akt w systemie przez komórkę merytoryczną, jej ew. korektę i uzupełnienie przez Archiwistę po udostępnieniu akt (sporządzenie protokołu). Wymagalne EOD_334 System musi posiadać Obieg wniosku (Karty udostępnienia akt) o udostępnienie materiałów z archiwum, zarówno w wersji papierowej, jak i udostępnienie skanu. Wymagalne Archiwizacja EOD_335 System musi zapewnić funkcjonalność archiwizowania dokumentów obsługiwanych poprzez system EOD. Archiwizowane powinny być wszelkie dokumenty związane ze sprawą (skany, dokumenty wytworzone w ramach obiegu, raporty, itp.). Wymagalne EOD_336 System musi mieć możliwość automatycznego generowania dokumentów wymaganych prawnie, niezbędnych do funkcjonowania archiwum (m.in. Załączniki do Procedury, Raporty, sprawozdania). Wymagalne EOD_337 System musi wspierać brakowanie akt. Wymagalne EOD_338 System musi mieć możliwość monitorowania akt do brakowania/przekazania do Archiwum Akt Nowych. Wymagalne EOD_339 System musi wspomagać przygotowywanie spisów zdawczo ‐ odbiorczych do przekazania do Archiwum Państwowego, w wymaganym przez Archiwum Państwowe formacie. Wymagalne EOD_340 System powinien zapewnić Rejestr wyników przeglądów urządzeń, a w szczególności dokumentacji i archiwizacji wyników przeglądów na potrzeby kontroli i analizy statystycznej. W ramach przechowywanej dokumentacji rejestr powinien także umożliwiać prowadzenie tabel pomiarowych urządzeń. Opcjonalne Wymagania dotyczące Raportowania Wymagania ogólne EOD_341 System musi być wyposażony w graficzny edytor raportów umożliwiający tworzenie raportów wbudowanych w system EOD lub zapewnić współpracę z generatorem raportów dostarczonym dla całego systemu. Wymagalne EOD_342 System musi spełniać następujące wymagania w zakresie generowania raportów: ‐ możliwość wygenerowania raportu za dowolny okres „od dnia do dnia” przy uwzględnieniu parametrów zdefiniowanych przez użytkownika (np. komórka organizacyjna, obszar certyfikowany, etc.), ‐ możliwość generowania raportów na żądanie, ‐ podgląd raportów zgodnie z nadanymi uprawnieniami dostępu. Wymagalne EOD_343 Wszystkie wygenerowane raporty powinny mieć możliwość trafienia jako dokumenty do repozytorium. Opcjonalne EOD_344 System powinien umożliwiać generowanie dowolnych raportów – na podstawie istniejących w systemie danych ‐ w formacie Word, Excel, PDF na każdym etapie procesu audytowego. Opcjonalne Raporty EOD_345 System musi posiadać Raport Pocztowa Książka Nadawcza. Wymagalne EOD_346 System musi posiadać Raport obłożenie zadaniami w jednostce organizacyjnej. Wymagalne EOD_347 System musi posiadać Raport terminowości pracowników. Wymagalne Strona 178 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_348 System musi posiadać Raport wydruk etykiet kopert o formatach C4, C5, C6. Wymagalne EOD_349 System musi posiadać Raport wydruk zwrotki. Wymagalne EOD_350 System musi posiadać Raport spis spraw. Wymagalne EOD_351 System musi posiadać Raport dynamika przetwarzanych spraw. Wymagalne EOD_352 System musi posiadać Raport pisma przychodzące. Wymagalne EOD_353 System musi posiadać Raport statystyki spraw rozpoczętych (z podziałem na rok, miesiąc, jednostkę, użytkownika). Wymagalne EOD_354 System musi posiadać Raport statystyki spraw zakończonych (z podziałem na rok, miesiąc, jednostkę, użytkownika). Wymagalne EOD_355 System zapewnić Raport liczba załatwionych spraw w jednostkach organizacyjnych i dla poszczególnych użytkowników. Opcjonalne EOD_356 System zapewnić Raport książka adresowa. Opcjonalne EOD_357 System zapewnić Raport informacja o obiegu zewnętrznym dokumentu finansowego. Opcjonalne EOD_358 System zapewnić Raport realizacji obiegów wg nazwisk. Opcjonalne EOD_359 System zapewnić Raport realizacji obiegów wg stanowisk. Opcjonalne EOD_360 System zapewnić Raport realizacji obiegów wg nazw komórek. Opcjonalne EOD_361 System zapewnić Raport koszt usług zewnętrznych kancelarii prawnych w układzie rocznym. Opcjonalne EOD_362 System zapewnić Raport koszt usług zewnętrznych kancelarii prawnych w układzie miesięcznym. Opcjonalne EOD_363 System zapewnić Raport koszt usług zewnętrznych kancelarii prawnych wg zleceń, umów. Opcjonalne EOD_364 System zapewnić Raport prawa dostępu użytkowników do określonych dokumentów. Opcjonalne EOD_365 System zapewnić Raport archiwisty i użytkownika, w szczególności raportu pokazującego jakie sprawy znajdują się w danej teczce aktowej. Opcjonalne EOD_366 System powinien umożliwiać przygotowanie zapotrzebowania zbiorczego na usługi kurierskie i usługi pocztowe przez wszystkie komórki organizacyjne oraz pracownika Działu Zarządzania i Organizacji. Opcjonalne EOD_367 System zapewnić Raport załącznik do wniosku na usługi kurierskie i pocztowe w zakresie prenumeraty. Opcjonalne EOD_368 System musi zapewnić Raport analizy ryzyka. Opcjonalne EOD_369 System musi zapewnić Raport analizy wyników raportów. Opcjonalne EOD_370 System musi zapewnić Raport analizy z raportowania okresowego z procesów audytów. Opcjonalne EOD_371 System musi zapewnić Raport analizy działań korygujących. Opcjonalne EOD_372 System musi zapewnić Raport analizy działań zapobiegawczych. Opcjonalne EOD_373 System musi zapewnić Raport plan audytów na rok. Opcjonalne EOD_374 System musi zapewnić Raport realizacja planu audytów. Opcjonalne EOD_375 System musi zapewnić Raport stan realizacji zaleceń poaudytowych/pokontrolnych. Opcjonalne EOD_376 System musi zapewnić Raport planowanie zasobów osobowych przy uwzględnieniu ilości dni pracujących w danym roku kalendarzowym wraz z podziałem na miesiące oraz godziny". Opcjonalne EOD_377 System musi zapewnić Raport planowanie zasobów osobowych przy uwzględnieniu ilości dni urlopu na konkretnego pracownika w zbliżającym się roku kalendarzowym. Opcjonalne Strona 179 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
EOD_378 System musi zapewnić Raport planowanie zasobów osobowych przy uwzględnieniu ilości zwolnień lekarskich oszacowana na podstawie danych historycznych. Opcjonalne EOD_379 System musi zapewnić Raport planowanie zasobów osobowych przy uwzględnieniu ilości audytorów wewnętrznych oraz osób wspomagających. Opcjonalne EOD_380 System musi zapewnić Raport planowanie zasobów osobowych przy uwzględnieniu wyliczenia czasu przypadającego na pracownika i czynności jakie wykonuje w ramach swoich obowiązków. Opcjonalne EOD_381 System musi zapewnić Raport oceny ryzyka. Opcjonalne EOD_382 System musi zapewnić Raport protokół z narady otwierającej. Opcjonalne EOD_383 System musi zapewnić Raport protokół z narady zamykającej. Opcjonalne EOD_384 System musi zapewnić Raport szkic sprawozdania. Opcjonalne EOD_385 System musi zapewnić Raport sprawozdanie z audytu. Opcjonalne EOD_386 System musi zapewnić Raport notatka służbowa. Opcjonalne EOD_387 System musi zapewnić Raport notatka informacyjna. Opcjonalne EOD_388 System musi zapewnić Raport karta działań korygujących. Opcjonalne EOD_389 System musi zapewnić Raport karta działań zapobiegawczych. Opcjonalne EOD_390 System musi zapewnić Raport rekomendacje. Opcjonalne EOD_391 System musi zapewnić Raport pozostałe dokumenty realizacji zadań audytowych". Opcjonalne EOD_392 System musi zapewnić Raport pracownicy komórki audytu i wspomagający. Opcjonalne EOD_393 System musi zapewnić Raport obszary ryzyka wykryte na etapie przygotowania planu audytu. Opcjonalne EOD_394 System musi zapewnić Raport obszary ryzyka, w których zakończono zadania zapewniające w roku sprawozdawczym. Opcjonalne EOD_395 System musi zapewnić Raport przypisanie ilości obszarów pokrytych każdym z zadań audytowych. Opcjonalne EOD_396 System musi zapewnić Raport cykl audytu (planowany) zawarty w planie audytu na rok sprawozdawczy. Opcjonalne EOD_397 System musi zapewnić Raport cykl audytu (zrealizowany) na koniec roku sprawozdawczego. Opcjonalne EOD_398 System musi zapewnić Raport podstawowe informacje o pracownikach komórki audytu wewnętrznego. Opcjonalne EOD_399 System musi zapewnić Raport przeprowadzone zadania audytowe w roku sprawozdawczym. Opcjonalne EOD_400 System musi zapewnić Raport istotne informacje o wynikach przeprowadzonych zadań audytowych. Opcjonalne EOD_401 System musi zapewnić Raport przeprowadzone czynności sprawdzającego w roku sprawozdawczym. Opcjonalne EOD_402 System musi zapewnić Raport niezrealizowane zaplanowane zadania audytowe Opcjonalne EOD_403 System musi zapewnić Raport organizacja pracy komórki audytu wewnętrznego. Opcjonalne EOD_404 System musi zapewnić Raport liczba zadań i suma osobodni wykorzystanych za zadania zapewniające. Opcjonalne EOD_405 System musi zapewnić Raport suma osobodni wykorzystanych na czynności doradcze w zależności od statusu wykonania Opcjonalne EOD_406 System musi zapewnić Raport liczba przeprowadzonych czynności sprawdzających i sumę osobodni wykorzystanych na czynności sprawdzające w zależności od statusu wykonania. Opcjonalne EOD_407 System musi zapewnić Raport liczba zadań i osobodni wykorzystanych na zadania ZSZ Opcjonalne EOD_408 System musi zapewnić Raport liczba wydanych zaleceń zawartych w sprawozdaniach poaudytowych Opcjonalne Strona 180 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
oraz zaleceń uznanych za zasadne dla zadań ZSZ planowanych i nieplanowanych. EOD_409 System musi zapewnić Raport zadania i wnioski poaudytowe. Opcjonalne EOD_410 System musi zapewnić Raport ilość rekomendacji audytu dla elementów kontroli zarządczej (zestawienie ilościowe i procentowe) w zależności od typu. Opcjonalne EOD_411 System musi zapewnić Raport ilość rekomendacji audytu za dany okres (zestawienie ilościowe i procentowe) w podziale rodzaje zadań audytowych z uwzględnieniem statusu wykonania. Opcjonalne EOD_412 System musi zapewnić Raport zestawienie ilościowe i procentowe wykonanych i niewykonanych KDK i KDZ. Opcjonalne EOD_413 System musi zapewnić Raport niezgodności i potencjalne niezgodności w podziale na rodzaje wymagań norm (np.: ISO 9001 (jakość), 18001 (BHP), 14001 (Środowisko)). Opcjonalne EOD_414 System musi zapewnić Raport szczegóły KDK i KDZ. Opcjonalne EOD_415 System musi zapewnić Raport przypisanie ilości zadań, rodzaju i funkcji w audycie dla poszczególnych audytorów. Opcjonalne EOD_416 System musi zapewnić Raport ocena jakości z poszczególnych zadań dla audytorów, sprawozdania, etc. z przypisaniem do audytora. Opcjonalne EOD_417 System powinien zapewnić Raport oceny audytów/audytorów. Opcjonalne Wymagania dotyczące Silnika Procesów Biznesowych Wymagania ogólne EOD_418 System musi zawierać narzędzie do modelowania procesów, ich analizy, optymalizacji oraz uruchamiania procesów. Powinno także zawierać elementy odpowiedzialne za monitorowanie procesów. Wymagalne EOD_419 Oprogramowanie musi pozwalać na modelowanie struktur organizacyjnych w powiązaniu z pozostałymi komponentami Systemu. Wymagalne EOD_420 Oprogramowanie musi posiadać interfejs graficzny, umożliwiający projektowanie procesów w postaci diagramów, uwzględniających aktorów biorących udział w procesie (role), opisujące typ realizowanej czynności, wykorzystywane aplikacje i dokumenty oraz zadania przez nich wykonywane. Wymagalne EOD_421 Oprogramowanie musi umożliwiać wprowadzanie opisu procesów, a w szczególności: Początku i końca procesu, celu procesu, w tym poprzez opis tekstowy, nazwy procesu, aktywnych łączników do innych modeli procesów, określenie osoby zarządzającej procesem. Wymagalne EOD_422 Oprogramowanie musi umożliwiać modelowanie w narzędziu hierarchii procesów i funkcji. Wymagalne EOD_423 Oprogramowanie musi umożliwiać budowanie w narzędziu map procesów przez zespół kilku osób równolegle. Wymagalne EOD_424 Oprogramowanie musi umożliwiać tworzenie w narzędziu hierarchicznych struktur danych. Wymagalne EOD_425 Oprogramowanie powinno umożliwiać przeprowadzenie w narzędziu symulacji zmian procesu pod kątem ilościowym np. skrócenie czasu obsługi procesu. Opcjonalne EOD_426 Oprogramowanie powinno umożliwiać przeprowadzenie w narzędziu symulacji zmian procesu pod kątem jakościowym np. usunięcie realizowanych czynności w procesie. Opcjonalne EOD_427 Oprogramowanie powinno umożliwiać wykorzystanie w narzędziu symulacji biorąc pod uwagę kalendarz pracy dla czynności systemowych. Opcjonalne EOD_428 Oprogramowanie powinno umożliwiać wykonanie w narzędziu symulacji w odniesieniu do utworzonych modeli procesów. Opcjonalne EOD_429 Oprogramowanie powinno umożliwiać przeprowadzenie w narzędziu symulacji polegających na: Opcjonalne Strona 181 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
weryfikacji czasochłonności procesu i jego poszczególnych etapów, wykonaniu analiz kosztowych procesu, wykonaniu analiz dotyczących zasobów (ludzkich/systemowych) w procesie. EOD_430 Oprogramowanie powinno umożliwiać prezentację w narzędziu/rozwiązaniu w formie graficznej (mapa np. w formacie: jpg) całego procesu. W przypadku procesów głównych i podprocesów, powinno umożliwiać prezentację wg podziału procesów i ich logicznego powiązania. Opcjonalne EOD_431 Oprogramowanie powinno umożliwiać importowanie do narzędzia/rozwiązania gotowych procesów z narzędzi do modelowania. Opcjonalne EOD_432 Oprogramowanie powinno umożliwić przekształcenie map procesów w postać możliwą do dalszej dystrybucji np. do postaci tabelarycznej procedury i eksportu jej do formatu MS Word lub PDF. Opcjonalne EOD_433 System musi umożliwiać obsługę procesów wymagających interakcji z użytkownikiem. Wymagalne EOD_434 System musi posiadać mechanizm notyfikacji użytkowników pozwalający powiadamiać odpowiednie osoby o zdarzeniach zachodzących w procesie. Wymagalne EOD_435 System powinien posiadać generator interfejsu użytkownika, powinien pozwalać na automatyczną generację formularzy na podstawie struktur danych przechowujących informacje w procesie. Opcjonalne EOD_436 System musi umożliwiać uruchamianie instancji procesów, zarządzanie ich realizacją wg definicji procesów. Wymagalne EOD_437 System musi umożliwiać określenie zbioru pól, które będą dostępne do edycji w krokach obiegu. Wymagalne EOD_438 System musi umożliwiać przypisanie do kroku obiegu akcji typu: zmiana kroku, zmiana osoby przypisanej bądź właściciela, zmiana pola formularza, wysłanie powiadomienia, wykonanie fragmentu kodu. Wymagalne EOD_439 System musi umożliwiać zapis i przeglądanie historii wykonywanych czynności wraz z rodzajem zmiany i osobą, która ją wykonała. Wymagalne EOD_440 System musi umożliwiać wyświetlanie zadań do wykonania wynikających z kroku procesu w jednolitym widoku zadań. Wymagalne Tabela 13. Wymagania funkcjonalne ‐ EOD 2.4
Wymagania dotyczące komponentu BI/EPM
Nr
wymagania
Wymaganie
Wymagania ogólne BI_001 System musi umożliwiać generowanie raportów.
Wymagalne
BI_002 System musi umożliwiać dostęp do kokpitów, funkcjonalności tworzenia raportów ad‐hoc i tworzenie raportów operacyjnych (tzw. pixel‐perfect) poprzez jeden spójny interfejs oparty o przeglądarkę internetową. Wymagalne BI_003 System musi zawierać stronę domową, na której użytkownik będzie miał dostęp do najczęściej używanych raportów, ostatnio używanych raportów, listy folderów z raportami. Wymagalne BI_004 System musi umożliwiać dodanie wybranych raportów do widoku „ulubione”. Raport oznaczony jako „Ulubiony” musi być wyraźnie wyróżniony graficznie na tle pozostałych raportów. Wymagalne BI_005 System musi umożliwiać definiowanie wierszy i kolumn wyliczanych na raportach. Wymagalne BI_006 System musi umożliwiać definiowanie wierszy i kolumn wyliczanych na formularzach do wprowadzania danych. Wymagalne BI_007 System musi umożliwiać zarządzanie biblioteką raportów i formularzy. Wymagalne Kategoria
wymagania
Strona 182 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
BI_008 System musi umożliwiać udostępnianie raportów innym użytkownikom za pomocą listy zadań z formularzami i raportami do procesowania. Wymagalne BI_009 System musi umożliwiać predykcję wykonalności lub osiągnięcia określonych wartości poszczególnych mierników (lub grupy mierników), wskaźników oraz KPA w oparciu o dane dostępne w bazie danych systemu ERP. Wymagalne BI_010 System musi umożliwiać analizy danych wielowymiarowych. Wymagalne BI_011 System musi umożliwiać użytkownikom wykonywanie operacji drążenia danych do danych bardziej szczegółowych (drill down) w przeglądarce internetowej. Wymagalne BI_012 System musi umożliwiać użytkownikowi na drążenie hierarchii wymiaru (tzw. ”drzewko”) a nie wyłącznie jego atrybutów. Musi być zapewniona możliwość generowania raportu opartego jednocześnie o hierarchię wymiarów i atrybuty. Wymagalne BI_013 System musi umożliwiać nawigację w obrębie domyślnych hierarchii wymiarów. Wymagalne BI_014 System musi umożliwiać nawigację warunkową, która w zależności od sytuacji może wskazywać użytkownikowi pewne biznesowo powiązane ścieżki analizy. Wymagalne BI_015 System musi umożliwić drążenie informacji pochodzących z wielu źródeł na jednym raporcie. Wymagalne BI_016 System musi umożliwiać śledzenie i rejestrację wykonywanych zapytań. Wymagalne BI_017 System musi umożliwiać użytkownikowi na sortowanie danych dowolnego wymiaru w porządku rosnącym lub malejącym w przeglądarce internetowej. Wymagalne BI_018 System musi umożliwiać użytkownikowi na sortowanie wyników raportu w postaci tabeli przestawnej po kolumnie i po wierszu. Wymagalne BI_019 System musi umożliwiać filtrowanie danych na podstawie warunków predefiniowanych i określanych ad‐hoc. Wymagalne BI_020 System musi umożliwiać tworzenie różnych przekrojów prezentowanych danych poprzez zestawienie swobodnie dobieranych wymiarów. Wymagalne BI_021 System musi umożliwiać obracanie wymiarami tabeli lub tabeli przestawnej bezpośrednio na raporcie bez konieczności przechodzenia do zaawansowanego trybu edycji raportu. Wymagalne BI_022 System musi umożliwiać tworzenie wykresów analizowanych danych. Wymagalne BI_023 System musi umożliwiać generowanie wykresów 2D i 3D dla raportów. Wymagalne BI_024 System musi rekomendować użytkownikowi odpowiedni sposób wizualizacji danych w zależności od danych zdefiniowanych w kryterium raportu tzw. data‐driven insight. Wymagalne BI_025 System musi wizualizować graficznie tzw. wyjątki tzn. wartości przekraczające wartości oczekiwane, nie mieszczące się w pewnych zakresach itp. Wymagalne BI_026 System musi umożliwiać wizualizację danych aktualnych, historycznych oraz trendu. Wymagalne BI_027 System musi umożliwiać, że tworzenie dodatkowego widoku danych nie może wymagać osobnego, nowego zapytania SQL. Wymagalne BI_028 System musi umożliwiać zmianę nazw kolumn na raporcie uruchomionym w przeglądarce internetowej, na dowolnie wybrane przez użytkownika nagłówki i etykiety. Wymagalne BI_029 System musi umożliwiać użytkownikom na zmiany wizualizacji danych na raporcie: pozioma i pionowa orientacja danych, ukrywanie etykiet wierszy i reguł agregacji danych na raporcie uruchamianym w przeglądarce internetowej. Wymagalne Strona 183 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
BI_030 System musi umożliwiać ukrywanie kolumn na raporcie. Wymagalne BI_031 System musi umożliwiać podgląd rezultatu/układu wygenerowanego raportu na etapie jego tworzenia bez potrzeby wcześniejszego zapisywania raportu. Wymagalne BI_032 System musi umożliwiać formatowanie warunkowe raportów. Wymagalne BI_033 System musi umożliwiać formatowanie warunkowe tabeli przestawnej. Wymagalne BI_034 System musi umożliwiać formatowanie hierarchii wymiaru tak, żeby każdy jej poziom mógł być reprezentowany w inny sposób (np. poprzez inny kolor). Wymagalne BI_035 System musi umożliwiać obsługę hierarchii niezbalansowanych. Wymagalne BI_036 System musi umożliwiać wykonywanie kalkulacji: matematycznych, statystycznych, znakowych, konwersji itp. Wymagalne BI_037 System musi umożliwiać tworzenie warunków wyliczanych, wykorzystywanych do filtrowania danych. Wymagalne BI_038 System musi umożliwiać definiowanie i tworzenie raportów w środowisku graficznym przez użytkowników biznesowych. Wymagalne BI_039 System musi umożliwiać prezentowanie danych pochodzących z wielu źródeł na jednym raporcie (nie na kokpicie menedżerskim). Wymagalne BI_040 System musi umożliwiać dynamiczne udostępnianie użytkownikom listy wartości wykorzystywanych do filtrowania danych na raporcie. Wymagalne BI_041 System musi umożliwiać tworzenie tzw. kaskadowych podpowiedzi (prompts) – przykładowo druga podpowiedź wyświetla tylko przefiltrowane ważne dla niej wartości bazując na wartościach zwróconych w pierwszej podpowiedzi. Wymagalne BI_042 System musi umożliwiać tworzenie raportów parametryzowanych. Wymagalne BI_043 System musi umożliwiać tworzenie tzw. sub‐filtrów np. użytkownik może wykorzystać rezultaty jednego raportu jako filtr drugiego raportu. Wymagalne BI_044 System musi zapewniać możliwość definiowania na raporcie obiektów wyliczanych poprzez łączenie dowolnych elementów z hierarchii danego wymiaru, jak i korzystanie z atrybutów wymiaru. Wymagalne BI_045 System musi umożliwiać tworzenie grup wyliczanych z uwzględnieniem struktury hierarchicznej wymiaru. Wymagalne BI_046 System musi umożliwiać wykorzystanie na raporcie kilku hierarchii wymiarów jednocześnie oraz możliwość umieszczenia w raporcie jednocześnie hierarchii wymiarów wraz z atrybutami wymiarów. Wymagalne BI_047 System musi umożliwiać zmianę parametrów i odświeżenie raportu bez konieczności uruchamiania narzędzia do projektowania raportów. Wymagalne BI_048 System musi umożliwiać natywną wizualizację danych analitycznych na mapach geograficznych. Wymagalne BI_049 System musi umożliwiać na tworzenie poprzez przeglądarkę internetową firmowego stylu (template) który raz stworzony może być dziedziczony przez wszystkie raporty.
Wymagalne BI_050 System musi umożliwiać udostępnienia raportu w postaci linku z zachowaniem praw dostępu odnośnie zawartej tam treści. Wymagalne BI_051 System powinien zapewniać dostępność mechanizmów do modyfikacji kolumn i wierszy raportów poprzez „Drag&Drop”. Wymagalne BI_052 System musi umożliwiać łączenie kilku obszarów tematycznych w ramach pojedynczego raportu z poziomu użytkownika. Wymagalne Strona 184 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
BI_053 System powinien umożliwiać wyszukiwanie raportów po słowach kluczowych z możliwością wykorzystania mechanizmu „full text search”. Wymagalne BI_054 System musi umożliwiać wykonanie fizycznego zapytania lub wywołanie funkcji bazy danych bezpośrednio na raporcie BI, przy czym raport może zawierać jednocześnie kolumny pochodzące z modelu metadanych serwera analitycznego BI jak i bezpośrednie odwołanie do zapytań/funkcji źródła danych. Wymagalne BI_055 System musi umożliwiać obsługę funkcji szeregów czasowych. Wymagalne BI_056 System musi umożliwiać wywołanie webservice bezpośrednio z raportu z możliwością przekazania parametrów raportu. Wymagalne BI_057 System musi umożliwiać wykonywanie dodatkowych obliczeń przed jak i po zgromadzeniu wyników zapytania przez serwer analityczny. Wymagalne BI_058 System musi umożliwiać ręczną modyfikację logicznego zapytania SQL wygenerowanego w trakcie tworzenia raportu ad‐hoc, w tym możliwość wykonania dodatkowych zapytań przed i po wykonaniu tegoż zapytania. Wymagalne BI_059 System musi umożliwiać wyświetlanie obiektów typu BLOB bezpośrednio na raporcie (w kolumnie raportu). Wymagalne BI_060 System musi wykorzystywać tabele agregatów w sposób transparentny dla użytkownika końcowego. Wymagalne BI_061 System musi umożliwiać historyzacji analiz i raportów w postaci migawek z możliwością tworzenia dokumentów PDF zawierających pełną historię zmian. Wymagalne BI_062 System powinien umożliwiać wyeksportowanie raportów do programu MS Excel i MS Power Point z możliwością automatycznego odświeżania zawartości raportów. Zawartość raportów powinna być automatycznie filtrowana zgodnie z uprawnieniami użytkownika. Opcjonalne BI_063 System nie może ograniczać możliwości wizualizacji danych na raportach ze względu na źródło pochodzenia danych. Wymagalne BI_064 System musi umożliwić dodawanie komentarzy do kokpitów menadżerskich i raportów. Wymagalne BI_065 System musi zapewniać możliwość tworzenia raportów o dokładnie określonym układzie (tzw. pixel‐
perfect formatting). Wymagalne BI_066 System musi umożliwiać wykorzystanie formularzy PDF Forms jako szablonów raportu. Wymagalne BI_067 System musi umożliwić automatyczną konwersję kokpitu menadżerskiego z raportami do raportu operacyjnego. Wymagalne BI_068 System musi umożliwiać generowanie raportów w formacie pdf , xls, xlsx, doc, docx, html, xml, rtf, csv, tab delimited format. Wymagalne BI_069 System powinien zapewniać środowisko projektowania i uruchamiania raportów dostępne za pośrednictwem przeglądarki internetowej bez konieczności instalacji aplikacji klienckiej. Opcjonalne Kokpity informacyjne BI_070 System musi posiadać zdefiniowane przykładowe kokpity informacyjne.
Wymagalne
BI_071 System musi umożliwiać tworzenie kokpitów informacyjnych (dashboards).
Wymagalne
BI_072 System musi umożliwiać personalizację kokpitów informacyjnych na poziomie użytkownika i grupy użytkowników. Wymagalne BI_073 System musi umożliwiać osadzenia w kokpitach informacyjnych treści z zewnętrznego serwisu internetowego. Wymagalne BI_074 System musi umożliwiać osadzenie w kokpicie informacyjnym dowolnej zawartości DHTML (HTML oraz Wymagalne Strona 185 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Java Script). BI_075 System musi umożliwiać tworzenie filtrów oraz podpowiedzi globalnych w ramach całej strony kokpitu, gdzie odbiorcami filtru może być wiele niezależnych raportów umieszczonych na stronie. Wymagalne BI_076 Użytkownik musi mieć możliwość cofnięcia wszelkich dostosowań (np. drążenie, przeniesienie kolumny etc.) wykonanych na kokpicie. Wymagalne BI_077 System musi umożliwiać bezpośrednie połączenie jednego raportu z kilkoma innymi w ramach jednego kokpitu menadżerskiego, tak aby kliknięcie na atrybucie raportu powodowało automatyczne filtrowanie danych na pozostałych raportach (tzw.master‐detail). Wymagalne BI_078 System musi umożliwiać tworzenie bezpośrednio z kokpitu zapytań analitycznych opartych o SQL w oparciu o model logiczny metadanych serwera BI i bezpośrednich struktur fizycznych podpiętych do serwera BI. Wymagalne BI_079 Systemu musi automatycznie dostarczać raporty dostępnych na kokpicie poprzez email lub w postaci alertów prezentowanych na kokpicie. Alerty będą generowane na podstawie zdefiniowanych warunków (z możliwością sekwencyjnego sprawdzenia warunków jeden po drugim) lub na podstawie z góry ustalonego harmonogramu. Wymagalne Praca mobilna i integracja z MS Office BI_080 System musi umożliwiać integrację raportów z dokumentami MS Word, Excel i Power Point. Wymagalne BI_081 System musi umożliwiać odświeżanie raportów z poziomu dokumentów MS Office. Wymagalne BI_082 System musi umożliwiać dostarczanie informacji, raportów, analiz na urządzenia mobilne (telefony komórkowe, tablety iPad itp.). Wymagalne Bezpieczeństwo, administracja, dystrybucja informacji. BI_083 System musi umożliwiać publikację raportów lub elementów raportów we współdzielonym repozytorium, z którego mogą korzystać inni użytkownicy.
Wymagalne BI_084 System musi umożliwiać nadawanie ról/uprawnień poszczególnym użytkownikom w sposób zapewniający odpowiednio ograniczony dostęp do danych.
Wymagalne BI_085 System musi umożliwiać tworzenie grup użytkowników i przypisywanie uprawnień na poziomie grup. Wymagalne
BI_086 System musi umożliwiać proces zewnętrznej identyfikacji użytkowników. Wśród wspieranych sposobów identyfikacji wymagane jest co najmniej identyfikacja na podstawie danych w źródle danych, wykorzystanie serwera LDAP oraz wykorzystanie rozwiązania Active Directory. Wymagalne BI_087 System musi dynamicznie przypisywać użytkownikom poziom bezpieczeństwa bazując na atrybutach przypisanych użytkownikowi w procesie identyfikacji. Wymagalne BI_088 System musi umożliwiać administratorowi podgląd kokpitu/raportu w kontekście wybranego użytkownika. Wymagalne BI_089 System musi automatycznie ograniczać zapytania wykonywane przez użytkowników, grupę użytkowników lub ze względu na źródło danych. Ograniczenia muszą dotyczyć: liczby zwracanych rekordów, długości czasu wykonywania raportu, czas pracy użytkownika (godziny, dni tygodnia). Wymagalne BI_090 System musi w sposób natywny wspierać śledzenie aktywności użytkowników poprzez identyfikator, grupę, rolę, dostarczając informacje m.in. o czasie wykonania raportu, nazwie raportu, wykorzystaniu pamięci cache w ramach raportu, statusie raportu (zakończony/nie zakończony). Wymagalne BI_091 System musi umożliwiać użytkownikom końcowym w sposób restryktywny na dostęp tylko do odpowiednich danych. System musi pozwalać na definiowanie autoryzacji dostępu do danych na poziomie metadanych biznesowych serwera BI. Wymagalne BI_092 System musi zapewniać przezroczystość zmian warstwy metadanych dla warstwy źródeł danych. Wymagalne Strona 186 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
BI_093 System musi dostarczać graficzne narzędzie administracyjne, które tworzy metadane w środowisku graficznym bez potrzeby ręcznego pisania SQL. Wymagalne BI_094 System musi zapewniać scentralizowaną konsolę do zarządzania systemem umożliwiająca min. Uruchomienie/Zatrzymanie poszczególnych komponentów systemu, konfigurację, mierzenie wydajności, diagnostykę systemu BI. Wymagalne BI_095 System musie umożliwić tworzenie skryptów do zarządzania systemem BI z wykorzystaniem JMX. Wymagalne BI_096 System musi umożliwić lokalizację struktury metadanych jak i warstwy prezentacji. Wymagalne BI_097 System musi umożliwiać użytkownikom planowanie wykonywania raportów o określonym czasie, cykliczności lub jednorazowo. Wymagalne BI_098 System musi umożliwiać użytkownikom na samodzielny dostęp do danych. Wymagalne BI_099 System musi pozwalać użytkownikom końcowym na samodzielne ustawianie harmonogramów wykonania ich zadań/raportów oraz zapytań. Wymagalne BI_100 W ramach automatycznej lub warunkowej dystrybucji informacji, system musi umożliwić użytkownika końcowego samodzielną subskrypcję do rozsyłanej informacji. Wymagalne BI_101 System musi zapewniać możliwość dystrybucji raportów w wybranym formacie i według zdefiniowanego harmonogramu do zewnętrznej listy odbiorców droga mailową. Wymagalne BI_102 Podczas dystrybucji, system musi umożliwiać zapis kopii załączników do pliku – np. jako PDF.. Wymagalne BI_103 System musi pozwolić na generowanie wielu wersji raportów z automatycznym podziałem informacji na podstawie jednego szablonu. Wymagalne BI_104 System musi umożliwiać alertowanie i dystrybucję warunkową zapewniającą automatyczny monitoring wartości z pomiarów, z uwzględnieniem przekroczenia progów predefiniowanych przez jednostki merytoryczne. Wymagalne BI_105 System musi umożliwiać alertowanie o zbliżających się przekroczeniach lub możliwych brakach osiągnięcia predefiniowanych wartości mierników. Wymagalne BI_106 System musi umożliwiać alertowanie o zbliżających się terminach uzupełnienia przez właściciela procesu danych w systemie EPM. Wymagalne BI_107 System musi umożliwiać alertowanie o zmianach wprowadzanych w algorytmach, nazwach, danych źródłowych, miejscach pomiarów, parametrach mierników/wskaźników. Wymagalne BI_108 System musi umożliwiać dostęp do kontekstowej pomocy dla użytkowników i administratorów. Wymagalne BI_109 System musi umożliwiać łatwą rozbudowę systemu pomocy przez zawansowanych użytkowników i administratorów. Wymagalne BI_110 System powinien umożliwiać administracji zapytaniami SQL z poziomu przeglądarki internetowej. Opcjonalne BI_111 System musi zapewniać dostępność graficznego narzędzie administracyjnego, które tworzy metadane oraz modele danych w środowisku graficznym bez potrzeby ręcznego pisania zapytań do bazy danych. Wymagalne BI_112 System musi umożliwiać konfigurowanie dostępu do określonych raportów, określonym grupom pracowniczym. Wymagalne Architektura systemu, integracja różnych źródeł danych. BI_113 System musi umożliwić dostęp do różnych źródeł danych: XML, Web Services, procedur składowanych, plików płaskich, baz relacyjnych, baz wielowymiarowych, itp. System powinien obsługiwać m.in. następujące źródła danych: Baza Oracle, Baza Microsoft SQL Server, Oracle OLAP option, Microsoft Analysis Services (MDX), ESSBASE. Wymagalne Strona 187 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
BI_114 System musi być oparty o jeden łatwo zarządzany, spójny model metadanych. Wymagalne BI_115 Definiowanie metadanych serwera BI musi być zapewnione przez intuicyjny interfejs graficzny a nie w oparciu o skrypty i kodowanie. Wymagalne BI_116 System musi umożliwiać automatyczną wersyfikacji modelu metadanych pod kątem potencjalnych błędów w projektowaniu metadanych. Wymagalne BI_117 System musi umożliwiać pracę grupową nad modelem metadanych serwera analitycznego z możliwością wersjonowania repozytorium metadanych. Wymagalne BI_118 System musi umożliwiać tworzenie patchy do uaktualnienia kolejnych wersji repozytorium. Wymagalne BI_119 System musi umożliwiać podgląd i drukowanie schematu fizycznego i biznesowego modelu metadanych. Wymagalne BI_120 System musi umożliwiać łączenie na raporcie i na poziomie modelu metadanych informacji pochodzących z różnych źródeł (np. fragmentacja danych, drążenie poprzez różne źródła danych) oparte o proste modelowanie graficzne i edycję obiektów metadanych. Wymagalne BI_121 System musi zapewniać możliwość integracji danych z różnych systemów hurtowni danych, hurtowni tematycznych, systemów transakcyjnych, gromadzonych danych operacyjnych. Wymagalne BI_122 System musi umożliwiać użytkownikowi lub administratorowi kompleksowe zamodelowanie różnych źródeł informacji biznesowej w prosty, zrozumiały (logiczny), jeden model biznesowy wykorzystywany przez wszystkie komponenty platformy systemu Business Intelligence (tylko jedna warstwa metadanych wykorzystywana przez wszystkie narzędzia BI). Wymagalne BI_123 System musi zapewniać możliwość zmiany nazw elementów warstwy fizycznej na pojęcia biznesowe, przyjazne użytkownikowi końcowemu. Wymagalne BI_124 System musi ukrywać złożoność struktur danych fizycznych oraz wszystkich aspektów związanych z ich dostarczeniem. Użytkownik musi posługiwać się pojęciami i elementami posiadającymi nazwy biznesowe oraz nie musi znać lokalizacji danych, na których pracuje. Wymagalne BI_125 System nie może wymagać od użytkownika końcowego znajomości połączeń oraz ich reguł w celu stworzenia raportu. Wymagalne BI_126 System musi pozwalać na prezentację wielu tabel jako folderu i ukrywać warstwę struktury danych np. znormalizowana postać wielu tabel może logicznie być widoczna jako jedna zdenormalizowana tabela jeśli ma to sens biznesowy dla użytkowników końcowych. Wymagalne BI_127 System musi natywnie wspierać wielojęzyczność przez mechanizmy wbudowane w rozwiązanie. Wielojęzyczność musi być wspierana w obrębie jednej warstwy metadanych i nie może wymagać dla każdego języka instalacji odrębnej warstwy metadanych lub ich części. Wymagalne BI_128 W celu osiągnięcia skalowania systemu musi być wykorzystywany mechanizm puli połączeń (“connection pooling”). Oznacza to, że pojedyncze połączenie do bazy danych jest wykorzystywane do wykonywania wielu zapytań. Wymagalne BI_129 System musi zapewniać narzędzie udostępnia otwarte biblioteki API do warstwy modelu biznesowego. Wymagalne BI_130 Rozwiązanie musi być oparte o architekturę trójwarstwową. Wymagalne BI_131 System musi mieć możliwość instalacji na platformie systemu operacyjnego MS Windows oraz Linux. Wymagalne BI_132 System musi umożliwiać tworzenie agregatów w relacyjnym źródle danych na podstawie logiki biznesowej warstwy metadanych, a następnie automatyczną obsługę tych agregatów (zarówno w postaci źródła danych zagregowanych jak i automatycznych odświeżeń). Automatyczne tworzenie agregatów musi być niezależne od źródeł danych warstwy metadanych i może opierać się na wielu różnych technologicznie źródłach danych. Wymagalne BI_133 System musi zapewniać możliwość dostępu do danych na poziomie warstwy biznesowej za pomocą Wymagalne Strona 188 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
sterownika ODBC. BI_134 System musi umożliwić klastrowanie środowiska BI. Wymagalne BI_135 System musi umożliwić wykonywanie analiz w oparciu o atrybuty i hierarchie wymiarów. Wymagalne BI_136 System musi umożliwić wykonanie analiz „write‐back”. Wymagalne BI_137 System musi dostarczać inteligentnego, wieloużytkownikowego mechanizmu cache. Wymagalne BI_138 System musi umożliwiać inteligentne wykorzystanie pamięci podręcznej cache serwera BI tzn. jeżeli w pamięci cache znajduje się niższy poziom agregacji danych niż wymagany na raporcie, wówczas raport zagreguje dane z pamięci cache i nie będzie generował zapytania fizycznego bezpośrednio do źródła danych. Wymagalne BI_139 System musi umożliwiać szybkie generowania analiz poprzez umieszczenia wybranego raportu w pamięci cache serwera analitycznego, na podstawie ustalonego wcześniej harmonogramu oraz zdefiniowanego wcześniej warunku lub grupy warunków. Wymagalne BI_140 System musi umożliwiać klastrowanie do operacji równoważenia obciążenia (load balancing) oraz operacji przełączania podczas awarii dla wielu instancji serwerów aplikacyjnych. Wymagalne BI_141 System musi umożliwiać realizację wielu równoległych zapytań SQL. Wymagalne BI_142 System musi wykorzystywać zalety architektury SMP (Symmetric Multi‐processing). Wymagalne BI_143 System musi umożliwiać wielowątkowość. Wymagalne BI_144 System musi umożliwiać wcześniejsze buforowanie wyników i wyliczeń niezbędnych do szybkiego dostarczenia raportu użytkownikowi końcowemu. Mechanizm musi posiadać możliwość ustalenia harmonogramu zasilania pamięci cache serwera analitycznego żądanymi wynikami. Wymagalne BI_145 System musi automatycznie optymalizować zapytania analityczne tzn. obliczenia zawarte w logicznym zapytaniu po stronie systemu BI mogą być w ramach optymalizacji całkowicie wykonane po stronie serwera BI, częściowo wykonane po stronie serwera BI i na bazie danych, całkowicie wykonane po stronie bazy danych. Wymagalne BI_146 System musi zapewniać możliwość konsolidacji informacji pochodzących z innych systemów informatycznych i aplikacji. Wymagalne BI_147 Narzędzie obsługujące integrację musi umożliwiać wydajne ładowanie danych do hurtowni danych, „data martów”, kostek OLAP i innego rodzaju docelowych składnic danych. Wymagalne BI_148 System musi obsługiwać w sposób przeźroczysty ładowanie przyrostowe, wymiary wolnozmienne, jednocześnie zapewniając integralność i spójność danych. Wymagalne BI_149 Narzędzie do integracji musi działać w architekturze SOA i musi posiadać usługi związane z integracją i transformacją danych, które mogą być swobodnie wykorzystywane w różnego rodzaju procesach biznesowych. Wymagalne BI_150 Narzędzie do integracji musi działać w architekturze E‐LT z możliwością wykonywanie transformacji danych tylko w docelowej lub źródłowej bazie danych. Wymagalne BI_151 System musi umożliwiać deklaratywne modelowanie transformacji danych. Wymagalne BI_152 System musi umożliwiać odczyt metadanych, pobierania danych, ładowanie danych, sprawdzanie jakości danych lub spójności danych. Wymienione funkcjonalności muszą być otwarte i modyfikowalne. Wymagalne BI_153 Narzędzie do integracji musi charakteryzować się podziałem na infrastrukturę fizyczną i logiczną z możliwość prostego przełączania kontekstu procesu ETL/E‐LT między deweloperskim, a produkcyjnym. Wymagalne BI_154 Narzędzie integrujące musi działać w heterogenicznych środowisku IT z możliwością współpracy ze wszystkimi popularnymi relacyjnymi bazami danych np. Oracle, Teradata, IBM DB2, Netezza, Sybase z plikami płaskimi, gotowymi systemami ERP/CM, repozytoriami LDAP, plikami XML i innymi. Wymagalne Strona 189 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
BI_155 System musi posiadać edytor graficzny dla administratora transformacji umożliwiający: • „reverse‐engineering” istniejących baz danych i aplikacji, • Tworzenie interfejsów i transformacji, • Wizualizację przepływu danych w ramach transformacji, • Automatyczne generowanie dokumentacji, • Łatwe dostosowanie generowanego kodu. Wymagalne BI_156 System musi zapewniać techniczną możliwość uruchomienia oprogramowania zarządzającego transformacjami i przepływami na różnych 64‐bitowych platformach systemowo‐sprzętowych: Linux (Procesory Intel/AMD), MS Windows (Procesory Intel/AMD). Wymagalne BI_157 System musi zapewniać techniczną możliwość uruchomienia oprogramowania deweloperskiego z interfejsem graficznym na różnych platformach systemowo sprzętowych: Linux (Procesory Intel/AMD), 32 i 64 bit, MS Windows (Procesory Intel/AMD) , 32 i 64 bit. Wymagalne BI_158 Funkcjonalność silnika transformacji na dostępnych platformach musi być identyczna. Wymagalne BI_159 System musi umożliwiać obsługę źródeł danych przy pomocy natywnych sterowników oraz technologii JDBC/ODBC, bazy danych, pliki tekstowe, xml, web services. Wymagalne BI_160 System ETL musi zapewnić graficzne środowisko projektowania zadań wsadowych. Wymagalne BI_161 System ETL musi posiadać funkcjonalność wykrywania zmian danych (ang. Change Data Capture) pozwalającą na publikację zdarzeń zmiany danych oraz subskrypcję zdarzeń. Wymagalne BI_162 System ETL musi umożliwiać definiowanie harmonogramu wykonania zadań. Wymagalne BI_163 Oprogramowanie modułu zarządzania harmonogramami musi obsługiwać harmonogramowanie zadań (wg określonej daty i czasu, jednokrotnie oraz powtarzalnie – codziennie, w wybrane dni tygodnia lub zdarzenia, np. pojawienie się pliku). Wymagalne BI_164 System ETL musi umożliwiać integrację danych w trybie wsadowym oraz w czasie rzeczywistym. Wymagalne BI_165 Aplikacja procesów ETL musi posiadać gotowe (predefiniowane) transformacje dostępne jako obiekty graficzne. Gotowe transformacje muszą mieć możliwość parametryzacji poprzez wypełnianie lub modyfikację wartości w kreatorach graficznych. Wymagalne BI_166 Aplikacja procesów ETL musi pozwalać na współdzielenie transformacji własnych pomiędzy użytkownikami. Wymagalne BI_167 Tworzenie procesów przetwarzania danych musi odbywać się w aplikacji procesów ETL za pomocą interfejsu graficznego poprzez łączenie ze sobą transformacji gotowych (predefiniowanych), transformacji własnych użytkownika oraz danych. Wymagalne BI_168 Aplikacja procesów ETL musi zawierać gotowe, parametryzowane transformacje realizujące przynajmniej takie operacje jak: ‐zaczytanie wejściowych plików tekstowych, ‐wygenerowanie zbiorów wynikowych w postaci plików tekstowych, ‐pobranie danych bezpośrednio z baz danych źródłowych, ‐poziome (na poziome rekordów) i pionowe (konkatenacja) łączenie tabel, ‐filtrowanie tabel, ‐sortowanie tabel, ‐agregację danych wraz z wyliczaniem statystyk dla danych zagregowanych, ‐generowanie kolumn wyliczanych, ‐zmianę formatu danych (numeryczne, tekstowe, daty), ‐transpozycję danych, ‐odwracanie macierzy, ‐zasilanie wymiarów wolnozmiennych typu 1 (SCD1), Wymagalne Strona 190 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
‐zasilanie wymiarów wolnozmiennych typu 2 (SCD2). BI_169 Aplikacja procesów ETL musi wspierać tworzenie i wykorzystanie tabel typu lookup (ang. lookup table), czyli tabel pomocniczych zawierających klucz wiążący z tabelą bazową oraz dodatkowych kolumn dołączanych do tabeli bazowej. Tabela typu lookup to tablica, która przechowuje pewną ilość przeliczonych wcześniej danych. Użycie tabeli typu lookup pozwala na oszczędzenie procesorowi obliczeń, tym samym przyspieszając wykonanie programu. Wymagalne BI_170 Aplikacja procesów ETL musi oferować pracę grupową poprzez umożliwienie pracy wielu użytkowników nad jednym procesem ETL. Wymagalne BI_171 Aplikacja procesów ETL musi wersjonować procesy przetwarzające dane (wersjonowanie kodu). Możliwe jest wycofanie wdrożonej już wersji i powrót do wcześniejszej, jak również uruchomienie wybranej przez operatora wersji procesu. Musi być dostępny również mechanizm, który zapewni weryfikację zgodności uruchamianej wersji procesu ze stanem struktur bazy danych, z której proces korzysta. Wymagalne BI_172 Wersjonowanie procesów musi być wspierane przez narzędzie do projektowania procesów. Musi być możliwość używania składników procesów o różnych wersjach w projekcie, jak również utrzymywania różnych wersji procesów. Edycja składnika procesu nie może zmieniać wersji całego procesu. Wymagalne BI_173 Narzędzie musi udostępniać funkcje porównania wersji procesów oraz wskazywania różnic w procesach i składnikach procesów Wymagalne BI_174 Aplikacja procesów ETL musi umożliwić obsługę plików i tabel danych odrzuconych (niespełniających kryteriów danego procesu ETL). Obsługa będzie polegać za umożliwieniu dodatkowej obróbki danych bez ponownego pobierania ich ze źródła.
Wymagalne BI_175 Oprogramowanie musi umożliwiać wybór procesowania danych wiersz po wierszu lub zbioru danych jako całość. Procesowanie wiersz po wierszu musi umożliwiać ponowne przetworzenie tylko rekordów odrzuconych (niespełniających kryteriów danego procesu ETL). Wymagalne BI_176 Oprogramowanie musi zapewnić automatyczną i aktywną sygnalizację kompletności ładowanych danych, błędów danych i błędów samego procesu ETL. Przez aktywną sygnalizację rozumie się automatyczne logowanie oraz generowanie powiadomień wysyłanych jako e‐mail lub SMS. Wymagalne BI_177 Oprogramowanie musi umożliwić monitoring zdarzeń, kompletności ładowania danych dla operatorów nieposiadających narzędzi deweloperskich ETL. Musi to być aplikacja online, umożliwiająca wgląd w statystyki i raporty przetwarzania. Wymagalne BI_178 Aplikacja procesów ETL musi posiadać funkcje raportowania przebiegu procesu w zakresie obejmującym co najmniej wystąpienie błędów, czas przetwarzania, ilości przetworzonych i odrzuconych rekordów. Wymagalne BI_179 Narzędzie wykonujące procesy ETL musi umożliwiać clustering i load balancing procesów przetwarzających dane. Przetwarzanie musi być wielowątkowe Wymagalne BI_180 Oprogramowanie ETL musi posiadać udokumentowane API i metadane całego systemu. API musi umożliwiać zdalne wywoływanie procesów z innych aplikacji. Wymagalne BI_181 Oprogramowanie ETL musi umożliwiać uruchamianie procesów na zdalnych serwerach, nie może być na trwale związane z jednym dedykowanym serwerem. Wymagalne BI_182 Oprogramowanie ETL musi umożliwiać dowolny wybór bazy danych, w którym będą tworzone i przechowywane obiekty tymczasowe, tworzone podczas procesu takie jak tabele. Pod znaczeniem dowolny wybór kryje się zarówno użyta technologia (mogą to być wszystkie obsługiwane bazy) jak i miejsce bazy danych w strukturze procesu – baza źródłowa, pośrednia, lub docelowa. Wymagalne BI_183 Oprogramowanie musi dostarczać metadane pozwalające na określenie analizy wpływu procesów ETL na dane, musi to być wystarczające dla raportowania przepływu danych od źródła do celu z określeniem szczegółowym tabel, transformacji i procesów. Wymagalne Strona 191 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
BI_184 Oprogramowanie musi umożliwiać generowanie dynamicznych transformacji gdzie podstawowe kategorie takie jak nazwa tabeli, nazwa procesu mogą być zmiennymi. Wymagalne BI_185 Oprogramowanie ETL musi wspierać prace zespołów deweloperskich i testowych, poprzez umożliwienie uruchamiania zaprojektowanych procesów na różnych serwerach bez konieczności modyfikacji składników procesu. Wymagalne BI_186 Oprogramowanie musi zapewniać możliwość importu i exportu procesów ETL ze środowisk produkcyjnych do testowych i deweloperskich. Wymagalne BI_187 Oprogramowanie musi dostarczać otwarty kod transformacji systemowych i procesów ładowania danych. Musi istnieć możliwość modyfikacji tych transformacji. Wymagalne BI_188 Oprogramowanie musi być integrowane z narzędziami do zarządzania jakością danych. Elementy procesu związane z jakością danych muszą być zintegrowanymi składnikami procesu ETL. Wymagalne BI_189 Oprogramowanie ETL musi udostępniać otwarty mechanizm repozytorium, umożliwiający wgląd w metadane. Wymagalne BI_190 System musi zapewniać możliwość wersjonowania planów finansowych z możliwością porównywania wersji. Wymagalne BI_191 System musi zapewniać możliwość kopiowania danych pomiędzy wymiarami. Wymagalne BI_192 System musi zapewniać współpracę z oprogramowaniem walidacyjno‐sprawozdawczym w obszarze ruchu lotniczego. Wymagalne BI_193 System musi wspierać proces zarządzania płynnością finansową. Wymagalne BI_194 System musi zapewnić przygotowanie danych o ilość zamówień za ostatni rok w podziale na poszczególne produkty AIS. Wymagalne BI_195 System musi umożliwiać integrację danych źródłowych do planowania kosztów ubezpieczeń z danymi wynikowymi w odpowiednich bazach ze względu na konieczność zapewnienia ich spójności oraz skrócenia procesów planistycznych, Informacje źródłowe, gromadzone w procesie planowania kosztów ubezpieczeń to: ‐ nr MPK, ‐ rodzaj ubezpieczenia/ryzyko, ‐ przedmiot ubezpieczenia, ‐ okres ubezpieczenia, ‐ planowana składka roczna, kwota, w podziale na miesiące/dni , ‐ nr W)UZ, ‐ nr postępowania PZP, ‐ nr umowy ubezpieczenia, ‐ nr polisy/certyfikatu, ‐ faktyczna składka roczna, kwota, w podziale na miesiące/dni, ‐ nr i data faktury lub innego dokumentu, kwota, ‐ data dokonania zapłaty składki, ‐ sposób rozksięgowania składki, ‐ uwagi. Wymagalne BI_196 System musi zapewnić definiowanie i wyliczanie mierników, raportów i analiz, a także elastyczne rozszerzanie możliwości wprowadzania danych wymaganych do ich wyliczenia. Wymagalne BI_197 System musi zapewnić Zestawienie ilości sprzedanych publikacji AIS wg rodzaju publikacji. Wymagalne BI_198 System musi zapewnić Zestawienie ilości rozdystrybuowanych publikacji z uwzględnieniem publikacji odpłatnych i nieodpłatnych. Wymagalne BI_199 System musi zapewnić Zestawienie ilości wydrukowanych egzemplarzy AIP (w podziale na AIP, AIP VFR i MIL AIP). Wymagalne Strona 192 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
BI_200 System musi zapewnić Zestawienie zamówień odpłatnych na publikacje AIS. Wymagalne BI_201 System musi zapewnić Zestawienie ilości map przekazanych do odsprzedaży w Biurach Odpraw Załóg. Wymagalne BI_202 System musi zapewnić Zestawienie kosztów i przychodów z działalności pozanawigacyjnej . Wymagalne BI_203 System musi zapewnić ‐ Zestawienie kosztów i przychodów z działalności pozanawigacyjnej vs. koszty i przychody PAŻP. Wymagalne BI_204 System musi zapewnić Zestawienie obowiązujących umów i porozumień dot. AIS. Wymagalne BI_205 System musi zapewnić Zestawienie planowanych kosztów w wybranym okresie. Wymagalne BI_206 System musi zapewnić Zestawienie ilości publikacji AIP rozdystrybuowanych bezpłatnie. Wymagalne BI_207 System musi zapewnić Raport o zużyciu materiałów. Wymagalne BI_208 System musi zapewnić Raport amortyzacji sprzętu. Wymagalne BI_209 System musi zapewnić Raport amortyzacji oprogramowania. Wymagalne BI_210 System musi zapewnić Raporty kadrowe. Wymagalne BI_211 System musi zapewnić Raport o odbytych i zaplanowanych szkoleniach personelu AIS. Wymagalne BI_212 System musi zapewnić Raport z wykonania mierników operacyjnych AIS w wybranym okresie. Wymagalne BI_213 System musi zapewnić Okresowy raport z pomiaru czynników ryzyka. Wymagalne BI_214 System musi zapewnić Raport stanu magazynowego produktów AIS. Wymagalne BI_215 System powinien mieć możliwość sprawnego raportowania z możliwością manipulacji układem wyświetlanych danych. Raportowanie musi obejmować bazy danych pojazdów, środków trwałych, zadań inwestycyjnych, zagranicznych delegacji służbowych (w tym lotów kabinowych), umów z Centralnego Rejestru Umów (najmu, dzierżawy), polis, szkód ubezpieczeniowych, rozliczeń do umów ubezpieczenia, planowania, budżetowania i rozliczania kosztów ubezpieczeń. Wymagalne BI_216 System musi zapewnić definiowanie parametrów segregowania /podziału / grupowania danych operacyjnych według regionów operacyjnych (np. TWR WA + TWR regiony lub TWR WA/KK/PO/GD/KT/WR + TWR) i zastosowanie tych parametrów do segregowania/podziału/grupowania danych operacyjnych. Wymagalne Kalkulacje stawek nawigacyjnych BI_217 W systemie musi zostać zaimplementowany model kosztowy oparty na rachunku kosztów działań, służący do rozliczania działalności nawigacyjnej i pozanawigacyjnej, przy zachowaniu wszystkich funkcjonalności obecnie używanego narzędzia, uaktualnionych i poprawionych. Wymagalne BI_218 Model kosztowy będzie obliczał stawki za operacje nawigacyjne na podstawie ustalonych algorytmów i najlepszych praktyk wypracowanych dotychczas, podlegających kontroli urzędowej z uwzględnieniem zmian w prawie, zgodnie z metodą zatwierdzoną przez Eurocontrol i CRCO. Wymagalne BI_219 Model kosztowy musi być odwracalny – czyli musi umożliwiać kalkulację stawek oraz kosztów, przy oczekiwanej wysokości stawek (odwracanie pracy modelu). Wymagalne BI_220 Model musi być wersjonowany. Kolejne wersje kalkulacji muszą być jednoznacznie identyfikowalne, dostępne w celach kontrolnych i porównawczych.
Wymagalne BI_221 System musi zapewniać współpracę z komórkami w zakresie wymiany danych do parametryzowania bazy kosztowej z uwzględnieniem automatyzacji.
Wymagalne BI_222 System musi umożliwić pracownikom PAŻP samodzielnie wprowadzenie odpowiednich parametryzacji modelu wraz ze zmieniającymi się parametrami otoczenia np. zmiana schematu organizacyjnego, utworzenie nowego lotniska. Wymagalne Strona 193 z 285
Nr
wymagania
Wymaganie
BI_223 System musi umożliwiać wprowadzenia systemu powiadomień o zbliżającym się terminie przygotowania Wymagalne odpowiednich danych na potrzeby bazy kosztowej – do wybranych komórek organizacyjnych. BI_224 System musi zapewniać szczegółową ewidencję kosztów (np. rozwinięta analityka), tak aby można było przypisać koszty do zasobów zdefiniowanych w modelu. Wymagalne BI_225 System musi zapewnić analizę scenariuszy, a nie wymagać budowy odrębnych modeli – zmiana jednej wartości w wersji roboczej planu z możliwością obserwacji wyników. Wymagalne BI_226 System musi zapewnić wymianę danych w zakresie amortyzacji i inwestycji. Wymagalne BI_227 System musi umożliwiać obliczanie parametrów do bazy kosztowej systemowo – automatycznie np. koszt kapitału, ujednolicenie amortyzacji (księgowość = bazy kosztowe) w podziale na środki trwałe i zasoby w bazie kosztowej. Wymagalne BI_228 System musi umożliwiać określenie poziomu analityki ZPK, do którego mają dostęp określone grupy pracowników. Wymagalne BI_229 System musi umożliwiać porównanie baz kosztowych i wskazywać różnice w kolejnych latach. Wymagalne BI_230 System musi wspomagać prognozowanie ruchu lotniczego. Wymagalne BI_231 System musi przygotowywać dane do tabel sprawozdawczych opłat nawigacyjnych, oraz informacji kosztowych na potrzeby KPSD. Wymagalne BI_232 System musi udostępniać zestawienia o ruchu planowanym i wykonanym w połączeniu z płatnościami. Wymagalne BI_233 System musi umożliwiać obliczanie i rozliczanie mechanizmu wyrównawczego. Wymagalne Wskaźniki, mierniki, pozostałe kalkulacje BI_234 System musi zapewniać możliwość definiowania mierników / wskaźników KPI (Key Performance Indicators) przy pomocy formuł matematycznych. Wymagalne BI_235 System musi zapewniać automatyczne wyliczanie wskaźników na podstawie danych przechowywanych w hurtowni danych. Wymagalne BI_236 System musi umożliwiać analizę odpowiedzi na ankiety dotyczące wskaźników jakościowych. Wymagalne BI_237 System musi zapewniać możliwość wizualizacji wskaźników KPI. Wymagalne BI_238 System musi zapewniać możliwość definiowania wartości wskaźników, dla których stosowane jest specjalne oznaczenie graficzne. Wymagalne BI_239 System musi zapewniać możliwość zapamiętywania wartości zdefiniowanych wskaźników i prezentowania ich zmiany w czasie. Wymagalne BI_240 System musi zapewniać możliwość zmiany formuł wskaźników w czasie (aktualność danej wersji wskaźnika obowiązuje w określonym okresie czasu). Wymagalne BI_241 System musi pozwalać na rejestrowanie i planowanie danych operacyjnych i finansowych, służących do automatycznego wyliczania historycznych i planowanych mierników/wskaźników (KPI) o charakterze ilościowym. Monitorowanie KPI poprzez automatyczne wyliczanie na podstawie danych dostępnych w ERP, hurtowni danych i innych systemach.
Wymagalne BI_242 System musi umożliwiać konfigurowanie algorytmów automatycznie wyliczających mierniki/wskaźniki wykorzystywane w PAŻP. Wymagalne BI_243 System musi umożliwiać konfigurowanie algorytmów wyliczających dane zgodnie ze specyfikacją Eurocontrol (Specification for Economic Information Disclosure V3.0 z grudnia 2012 i późniejsze/przyszłe wydania) oraz umożliwiać konfigurowanie algorytmów wyliczających dane zgodnie ze specyfikacją International Civil Aviation Organization (Statistics Programme: Form „L” [En‐route Services Traffic Statistics] oraz Form „K” [Air Navigation Services Financial Data] ). Wymagalne Kategoria
wymagania
Strona 194 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
BI_244 System musi umożliwiać gromadzenie i raportowanie informacji o wypełnieniu wymagań strategicznych konkretnymi działaniami inwestycyjnymi, projektowymi, bieżącej działalności. Wymagalne BI_245 System musi zapewnić wyliczanie wskaźników o zadanym algorytmie w trybie automatycznym, na podstawie zadanego cyklu (możliwość zdefiniowania dowolnej częstotliwości), a także w trybie ad‐hoc. Wymagalne BI_246 System musi zapewnić implementowanie i wyliczanie algorytmów dla wskaźników (jeśli pojawią się nowe lub zmieni się algorytm dla istniejących) na podstawie danych dostępnych w systemie ERP/BI lub budowy interfejsów danych do systemów zewnętrznych. Wymagalne BI_247 System musi umożliwić generowanie raportów, analiz, sprawozdań i mierników, także w postaci wykresów, z realizacji nadzoru bieżącego ULC, realizacji zaleceń PKBWL, stanu bezpieczeństwa (zgodnie z zestawieniami wykorzystywanymi w "Raporcie o stanie bezpieczeństwa w FIR EPWW"), kluczowych wskaźników efektywności dla procedury KP‐SMS. System musi umożliwić generowanie informacji zarządczej z baz ATOM (analogicznie po przeniesieniu funkcjonalności systemu atom do ERP), ERKZ, także z realizacji procesów analizy bezpieczeństwa, przeglądów, zaleceń i rekomendacji. Wymagalne BI_248 System musi zapewnić automatyzację pomiaru mierników operacyjnych procesu Zarządzanie informacją lotniczą. Wymagalne BI_249 System musi zapewnić monitorowanie efektywności i skuteczności działania poszczególnych komórek organizacyjnych poprzez kwartalne, z możliwością sparametryzowania częstszego generowania, wyliczanie wartości dla następujących wskaźników: patrz zakładka Wskaźniki (grupa "Mierniki procesowe"). Wymagalne BI_250 System musi zapewnić monitorowanie efektywności działania poszczególnych komórek organizacyjnych AR i biura AR w zakresie realizacji krajowego planu skuteczności działania. Dla planu skuteczności działania na 2012‐2014 system wyliczy wskaźniki dotyczące efektywności kosztowej w rozumieniu stawki jednostkowej (unit rate) wyrażonych w PLN i cenach z 2009. Patrz zakładka Wskaźniki. (oprócz mierników procesowych). Ilość mierników do przygotowania przez Dostawcę musi zawierać się przynajmniej w liczbie podanej w rozdziale Koncepcji Systemu dotyczącego "Rekomendacji w zakresie BI oraz Elektronicznego Obiegu Dokumentów".
Wymagalne BI_251 System musi zapewnić monitorowanie efektywności działania poszczególnych komórek organizacyjnych AR i biura AR w zakresie realizacji krajowego planu skuteczności działania. Dla planu skuteczności działania na roku 2015‐2019 system wyliczy wskaźniki dotyczące efektywności kosztowej (unit cost) wyrażonej w walucie narodowej, ochrony środowiska i bezpieczeństwa oraz ogólnie pojętej efektywności w zakresie TNC. Wymagalne BI_252 System musi zapewnić wyliczanie wskaźników dotyczących przepustowości (opóźnienia) na podstawie danych importowanych z systemu EUROCONTROL/DNM. Patrz zakładka Wskaźniki. (oprócz mierników procesowych). Wymagalne BI_253 System musi zapewnić historyzację wyników w ten sposób, że po wyliczeniu nowej wartości miernika, nadpisywana wartości powinna być odkładana w powiązanym rejestrze wraz z datą obowiązywania i innymi charakterystycznymi informacjami. Wymagalne BI_254 System powinien umożliwiać tworzenie analizy „co jeśli?” wykorzystujących nowe wersje (jeszcze niezatwierdzone) struktury organizacyjnej. Opcjonalne BI_255 System musi zapewnić raportowanie porównujące różne wersje struktury organizacyjnej. Wymagalne Planowanie i Controlling BI_256 System musi spełniać wymagania określone dla modułu FK ‐ Planowanie i sprawozdawczość. Wymagalne BI_257 System musi spełniać wymagania określone dla modułu OG ‐ Zarządzanie przez cele. Wymagalne BI_258 System musi spełniać wymagania określone dla modułu ZP ‐ Zarządzanie przez cele. Wymagalne Planowanie i prognozowanie Strona 195 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Wymagania ogólne PIP_001 System musi umożliwiać tworzenie planów sprzedaży ilościowo i wartościowo w definiowalnym, co najmniej 5‐letnim horyzoncie czasowym w podziale na miesiące. Wymagalne PIP_002 System musi pozwolić na oszacowanie przychodów i kosztów dla określonego zakresu usług. Wymagalne PIP_003 System musi umożliwiać uwzględnienie czynników waloryzacji, czasu obowiązywania zawartych umów oraz ich wielkości przychodów z nich wynikających. Wymagalne PIP_004 System musi umożliwiać tworzenie wariantowych prognoz sprzedaży produktów i usług pozanawigacyjnych dla zadanego okresu planowania (min. 5 lat). Wymagalne PIP_005 System musi zapewnić przygotowanie rocznych prognoz zapotrzebowania na mapy drukowane i AIP, na następny i kolejny rok, a także przygotowanie miesięcznych prognoz zapotrzebowania na zmiany w AIP, na następny i kolejny rok. System musi prognozować na podstawie iloczynu danych historycznych dot. zamówień z ostatniego roku i wskaźnika prognostycznego, a także zapewnić możliwość wykorzystania innych metod statystycznych. System musi uwzględnić to, że proces prognozowania odbywa się cyklicznie, raz w roku, w listopadzie. Wymagalne PIP_006 System musi zapewnić przygotowanie miesięcznych prognoz dot. zapotrzebowania na półprodukty i środki trwałe, na następny i kolejny rok. System musi prognozować na podstawie prognoz dot. produkcji publikacji w przeliczeniu na zasoby, a także musi zapewnić możliwość wykorzystania innych metod statystycznych. System musi uwzględnić to, że proces prognozowania odbywa się cyklicznie, raz w roku, w listopadzie. Wymagalne PIP_007 System musi zapewnić prognozowanie zapotrzebowania na produkty, półprodukty i zasoby na dwa lat do przodu tzn. prognoza przygotowywana pod koniec roku n, dotyczy roku n+1 i n+2, System, przy prognozowaniu w kolejnym okresie, musi korygować prognozę tzn. prognoza przygotowywana pod koniec roku n+1, musi dotyczyć roku n+2 i n+3. Przy prognozowaniu system musi uwzględniać aktualne stany magazynowe i rozpoczęte procedury zakupowe. Wymagalne PIP_008 System musi zapewnić zatwierdzanie wyniku prognozy przez kierownika i ręczne dostosowywanie prognozy. Wymagalne PIP_009 System musi wspomagać prognozowanie przychodów na podstawie danych operacyjnych. Wymagalne
Raportowanie PIP_010 System musi zapewnić raportowanie planów i prognoz według zadanych kryteriów selekcji informacji opartych o pozycje dostępne na danym raporcie.
Wymagalne PIP_011 System musi zapewnić raportowanie planów i prognoz według zadanych kryteriów grupowania informacji opartych o pozycje dostępne na danym raporcie.
Wymagalne Integracja PIP_012 System musi zapewnić integrację planowania sprzedaży z procesem planowania finansowego. Wymagalne PIP_013 System musi zapewnić integrację planowania sprzedaży z procesem kalkulacji stawek opłat nawigacyjnych Wymagalne Tabela 14. Wymagania funkcjonalne ‐ BI/EPM 2.4.1
Oczekiwania PAŻP dotyczące problemów do rozwiązania podczas wdrożenia
Systemu
Problemy do rozwiązania w trakcie implementacji Systemu. 1) Opracowanie i ujęcie koncepcji wdrożenia zagadnień zarządzania kosztami, przedstawionych poniżej: a) PAŻP oczekuje od przyszłego systemu możliwości szczegółowej ewidencji: Strona 196 z 285
kosztów pracy w podziale na każdego pracownika wraz z wykazem działań pozwalających na jednoznaczną alokację kosztów na usługi. W chwili obecnej PAŻP ewidencjonuje koszty w podziale na zdefiniowane miejsca ich powstawania (MPK). Ewidencja kosztów w podziale na każdego pracownika powinna umożliwić zarówno uzyskiwanie informacji o kosztach osobowych wybranej komórki organizacyjnej PAŻP, projektu realizowanego przez PAŻP (w którym są zaangażowani pracownicy różnych komórek organizacyjnych i MPK), świadczonej usługi (zarówno nawigacyjnej jak i pozanawigacyjnej), zdefiniowanych kategorii PRU (Performance Review Unit) jak i przygotowywanego produktu oraz w podziale na koszty bezpośrednie i pośrednie. ii) kosztów lotów zwolnionych – szczegółowa, powiązana z modelem biznesowym ewidencja w systemie księgowym kosztów świadczenia usług nawigacyjnych dla poszczególnych kategorii lotów zwolnionych z tych opłat (zgodnie z art. 130 ust.6 ustawy Prawo Lotnicze) jest niezbędna w celu określenia wielkości rzeczywistych kosztów ponoszonych przez PAŻP na obsługę tego rodzaju operacji lotniczych w poszczególnych okresach (miesiące, kwartały, lata) oraz uzyskania dotacji z MIiR na pokrycie tych kosztów. W szczególności chodzi o ewidencję kosztów ponoszonych na obsługę lotów VFR (Visual Flight Rules). iii) kosztów usług pozanawigacyjnych – zapisy ustawy o PAŻP jak również uzyskane decyzje MIiR dot. rozszerzenia działalności Agencji umożliwiają firmie dodatkowo prowadzanie kilku rodzajów działalności „pozanawigacyjnej. Te same przepisy nakładają na Agencję obowiązek wyodrębnienia kosztów tej działalności. Z tego powodu ewidencja kosztów w nowym systemie powinna być prowadzona w taki sposób, aby umożliwić wypełnienie tego wymagania. Dodatkowym utrudnieniem jest podział kosztów w sytuacji, gdy w tym samym czasie usługa świadczona jest na rzecz dwóch rodzajów działalności (nawigacyjnej i pozanawigacyjnej), co ma miejsce np. przy „oblotach”. Często podczas jednego lotu wykonywany jest oblot urządzeń należących do PAŻP i do Portu Lotniczego. iv) Kosztów usług nawigacyjnych – w podziale na trasowe i terminalowe, a także w podziale na poszczególne kontrolowane lotniska. System musi zapewniać zaplanowanie takiego układu kont, aby tak jak podano w powyższych przykładach można było prowadzić w systemie księgowym dokładną ewidencję kosztów i przychodów dla poszczególnych rodzajów działalności. Agencja jest zobowiązana to jednoznacznego i bezwzględnego rozdzielenia kosztów działalności nawigacyjnej trasowej i terminalowej (na każdy port lotniczy odrębnie) i od kosztów działalności pozanawigacyjnej. Zapisy księgowe będą podstawowym źródłem danych o rzeczywistych wielkościach kosztów i przychodów dla systemów sprawozdawczych i planistycznych, ze szczegółowością wymaganą przez PAŻP. Opracowanie dokumentacji procesów i działań pozwalającej na przypisanie im kosztów podlegających ewidencji księgowej i pozaksięgowej (np. kosztu kapitału), a także normatywów czasowych niezbędnych dla określenia wydajności zasobów. Dane te stanowić będą podstawę modelu bazy kosztowej wykorzystywanej w narzędziu EPM. Należy przy tym uwzględnić specyfikę pracy zasobów osobowych i technicznych pełniących tzw. dyżury ciągłe. PAŻP oczekuje zaprojektowania i wdrożenia modelu zarządzania kosztami tak, aby można było wykorzystywać je w trakcie zintegrowanego procesu kalkulacji kosztów Agencji, w tym stawek opłat nawigacyjnych zgodnie z wymaganiami i potrzebami PAŻP wynikającymi z przepisów prawa. PAŻP oczekuje rozwiązania pozwalającego na zapewnienie spójności planowania rzeczowego i finansowego. PAŻP oczekuje wsparcia procedur planowania i budżetowania zintegrowanego z kalkulacją stawek opłat działalności nawigacyjnej. Procedury te powinny pozwalać na wyliczenie stawek w oparciu o koszty, jak też na wyliczenie kosztów na potrzeby budżetowania przy zadanych stawkach, a także na potrzeby raportowania do EUROCONTROL, CANSO i budżetu zadaniowego. i)
b)
c)
d)
e)
f)
Strona 197 z 285
g) PAŻP oczekuje, że model rachunku kosztów i planowania uwzględni zasady Mechanizmu wyrównania ryzyka także dla nowopowstających portów lotniczych. h) PAŻP oczekuje, że zaproponowane rozwiązanie w zakresie planowania kosztów będzie pozbawione zjawiska nadwrażliwości wyników na niewielkie zmiany parametrów modelu, zwłaszcza na parametry dotyczące wielkości sprzedaży usług i pozostałych produktów. i) PAŻP oczekuje wsparcia planowania długoterminowego, uwzględniającego prognozy ruchu lotniczego oraz prognozy kosztów w perspektywie wieloletniej. Planowanie wieloletnie musi uwzględniać specyficzne dla Agencji pozycje: i) Koszty mechanizmu wyrównania ryzyka, ii) Koszty zatrudnienia i rekrutacji kontrolerów ruchu lotniczego. W tabeli poniżej znajduje się zestawienie dodatkowych wymagań wynikających z rekomendacji wdrożenia metody ABC/M w Agencji. Metoda zarządzania kosztami oparta o rachunek kosztów działań aczkolwiek rekomendowana jako rozwinięcie metody ABC obecnie stosowanej w Agencji do kalkulacji stawek, może zostać zastąpiona przez Dostawcę inną, równorzędną metodą pozwalającą na rozwiązanie przedstawionych problemów. Lp.
Wymaganie
ABCM_001 Baza zasobów ABCM_002 Ewidencja dostępności zasobów ABCM_003 Baza dostępności zasobów ABCM_004 Ewidencja normatywów użycia zasobów ABCM_005 Katalog kosztów bezpośrednich ABCM_006 Ewidencja normatywów kosztów bezpośrednich ABCM_007 Ewidencja nośników ABCM_008 Ewidencja struktur nośników ABCM_009 Ewidencja działań ABCM_010 Ewidencja kosztów Opis
System planowania musi dysponować bazą zasobów, zarówno technicznych jak osobowych, zgodną z odpowiednimi kartotekami systemu ERP (środki trwałe, Personel). Baza musi zawierać dane o zasobach aktualnie dostępnych oraz planowanych i przewidywanych do wykorzystania w przyszłości. System musi zapewnić ewidencję dostępności zasobów na potrzeby planowania, w tym porównania dostępności z zapotrzebowaniem, kalkulacji kosztów i planowaniu metodą ABC/M. Dla potrzeb planowania dane z podmodułów będą dostarczane do bazy EPM z modułów zasilających: HR, QUINTIQ, Zarządzanie Infrastrukturą i innych, w których będzie prowadzona ewidencja podstawowa. W wypadku braku możliwości ewidencji automatycznej konieczne ręczne wprowadzanie danych za pomocą odpowiedniego formularza systemu planowania. Moduł planowania musi dysponować bazą danych o dostępności zasobów, zawierającą kompletny katalog zasobów, których koszty utrzymania podlegają ewidencji i kalkulacji. Dane w tej bazie muszą uwzględniać planowaną dostępność zasobów obecnych oraz przyszłych, w horyzoncie czasowym zgodnym z horyzontem planowania. System zapewni ewidencję normatywów użycia zasobów technicznych i ludzkich dla działań na potrzeby metody ABC/M. Ewidencja będzie prowadzona w bazie modułu planowania. Baza zawierać będzie normatywne wartości użycia zasobów w działaniach związanych z wytworzeniem planowanych nośników. Wartości będą wprowadzane automatycznie z zaimplementowanych modułów Systemu, a w przypadku braku takiej możliwości przy pomocy formularzy. System zapewni prowadzenie katalogu kosztów bezpośrednich na poziomie zgodnym z ewidencją rodzajową kosztów i zgodnym z przyjętym modelem bazy kosztowej kalkulacji. Moduł
EPM ERP EPM EPM EPM System zapewni ewidencję normatywów kosztów bezpośrednich związanych z planowanymi EPM działaniami. System zapewni ewidencję nośników kosztów wynikających z działań koniecznych dla realizacji świadczonych przez Agencję usług, oraz pozostałych produktów. System zapewni ewidencję struktur nośników odpowiadających działaniom niezbędnym dla realizacji świadczonych przez Agencję usług i pozostałych produktów. Struktury będą używane do kalkulacji ilościowej zapotrzebowania na wytworzenie nośników, a poprzez powiązanie z działaniami pośrednio do kalkulacji zapotrzebowania na użycie zasobów. System zapewni prowadzenie katalogu działań niezbędnych dla wytworzenia planowanych nośników. Zakładowy plan kont Agencji zostanie dostosowany do potrzeb ewidencji kosztów na potrzeby rachunku kosztów działań tak, aby zapewnić ewidencję kosztów utrzymania zasobów. EPM EPM EPM ERP‐FK Strona 198 z 285
Lp.
Wymaganie
utrzymania zasobów ABCM_011 Zgodność księgowości z budżetami ABCM_012 Budżetowanie ABCM_013 Planowanie ABCM_014 Model bazy kosztowej ABCM_015 Ślad kontrolny danych planowania Opis
Moduł
Zakładowy plan kont zostanie dostosowany do takiego prowadzenia ewidencji księgowej, która ERP‐FK umożliwi porównanie realizacji z budżetami wynikającymi z planów. System zapewni synchronizację budżetów tworzonych w module planowania z odpowiednimi narzędziami księgowymi modułu ERP Rozwiązanie systemu planowania obejmie wykonanie poniższej wymienionych planów wskazanych jako wymagalne wraz z obiegami pozwalającymi na zastosowanie rachunku kosztów działań: 1) Plany funkcjonalne: a) Zasobów Ludzkich b) Czasu Pracy c) Kontroli ULC d) Przeglądów Okresowych e) Zamówień Publicznych f) Przeglądów PPOŻ g) Kontroli BHP h) Wydatków ZFŚS i) Audytów j) Zakupów 2) Plan finansowy, uwzględniający spójność rzeczowa i finansową, będący agregacją planów cząstkowych: a) Plan finansowy (skonsolidowany, uwzględniający wszystkie składniki) b) Plan przychodów (usługi trasowe, terminalowe, pozanawigacyjne, loty zwolnione, pozostałe) c) Plan inwestycji i dotacji unijnych d) Plan kosztów całkowitych e) Plan kosztów operacyjnych, tym m.in.: i) Plan amortyzacji ii) Plan kosztów wynagrodzeń iii) Plan remontów (infrastruktury, nieruchomości, pojazdów, pozostałe) iv) Plan szkoleń v) Plan wyjazdów służbowych vi) Plan pozostałych kosztów operacyjnych 3) W zakresie planów strategicznych a) Strategiczny plan rozwoju systemów komunikacyjnych na potrzeby ATM w FIR Warszawa b) Strategiczny plan rozwoju systemów dozorowania c) Strategiczny plan rozwoju infrastruktury nawigacyjnej d) Strategiczny plan rozwoju przestrzeni powietrznej FIR EPWW e) Strategiczny plan rozwoju obiektów PAŻP W Systemie zostanie zbudowany i sparametryzowany model bazy kosztowej, pozwalający na realizację zadań niezbędnych dla kalkulacji stawek opłat nawigacyjnych, planowania i prognozowania oraz budżetowania działalności Agencji. W procesie planowania zostanie zachowany ślad kontrolny dla potrzeb audytu zewnętrznego pozwalający zidentyfikować osobę wprowadzająca dane na każdym etapie, zarówno w komponencie EOD jak i EPM. Dane pomiędzy wykorzystywanymi komponentami muszą być przenoszone automatycznie, w sposób wykluczający ich nieautoryzowana modyfikację. INT EPM EPM EPM, EOD Tabela 15. Zestawienie wymagań dla metody zarządzania kosztami ABC/M 2.5
Wymagania dotyczące komponentu Portal
Strona 199 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
Portal samoobsługowy PRT_001 System musi posiadać możliwość logowania się na indywidualne konto przez każdego pracownika. Wymagalne PRT_002 System za pomocą przeglądarki internetowej musi umożliwiać każdemu pracownikowi wgląd do własnych informacji . Wymagalne PRT_003 System musi umożliwiać definiowanie uprawnień dostępu do danych w portalu w zależności od pełnionej funkcji np. dla: pracownika, bezpośredniego przełożonego. Bezpośredni przełożony musi widzieć dane podległych pracowników. Dyrektor jednostki musi widzieć dane bezpośrednich podwładnych lub wszystkich pracowników jednostki, w zależności od przydzielonych uprawnień. Wymagalne PRT_004 System musi umożliwiać pracownikowi dostęp do danych osobowych pracownika (np. imię, nazwisko, data urodzenia, miejsce urodzenia, dowód osobisty, PESEL, NIP) Wymagalne PRT_005 System musi umożliwiać pracownikowi dostęp do danych adresowych pracownika. Wymagalne PRT_006 System musi umożliwiać pracownikowi dostęp do danych o członkach rodziny pracownika. Wymagalne PRT_007 System musi umożliwiać pracownikowi dostęp do informacji o rachunkach bankowych pracownika i sposobie rozdysponowania wynagrodzenie w podziale na poszczególne rachunki bankowe. Wymagalne PRT_008 System powinien umożliwiać pracownikowi wprowadzenie i modyfikację danych o lokalizacji swojego miejsca pracy (centrala / oddział, miasto, budynek, nr pokoju) i telefonach służbowych (wewnętrzny, komórkowy, faks). Opcjonalne PRT_009 System powinien umożliwiać tworzenie książki adresowej pracowników. Powinna być możliwość wyszukiwania/przeglądania podstawowych danych teleadresowych pracowników (telefon, faks, telefon komórkowy, jednostka organizacyjna, stanowisko, lokalizacja). Opcjonalne PRT_010 System musi umożliwiać pracownikowi rejestrowanie planów urlopowych. Wymagalne PRT_011 System musi umożliwiać obieg planów urlopowych pracowników . Wymagalne PRT_012 Przy wprowadzaniu absencji lub przy wprowadzaniu osoby zastępującej, system musi wykrywać kolizję nieobecności osoby zastępującej i zastępowanej i wyświetlać stosowny komunikat. Wymagalne PRT_013 System musi umożliwiać pracownikowi dostęp do informacji o absencjach zarejestrowanych w systemie Wymagalne (typ, daty). System musi posiadać widok w formie kalendarza, poszczególne rodzaje absencji muszą być zaznaczone różnymi kolorami. PRT_014 System musi umożliwiać pracownikowi podgląd informacji o liczbie dni urlopu według typu: dostępnego, zaległego, wykorzystanego i pozostałego do wykorzystania. Wymagalne PRT_015 System musi umożliwiać pracownikowi zarejestrowanie wniosku urlopowego. Wymagalne PRT_016 System musi umożliwiać obieg wniosków urlopowych pracowników. Wymagalne PRT_017 System musi pokazywać pracownikowi statusu zatwierdzenia urlopu (złożony, anulowany, zaakceptowany przez bezpośredniego przełożonego, zaakceptowany przez dyrektora, zaakceptowany przez osobę zastępującą w razie nieobecności którejś z osób, zarejestrowano w kartotece urlopowej). Wymagalne PRT_018 System powinien posiadać możliwość rejestracji, podglądu (wraz z manualnym potwierdzeniem przeczytania) i usuwania uwag z poprzedniego/poprzednich dyżurów. Przy dodawaniu nowej uwagi, system powinien umożliwić wybranie dyżuru, do którego ma być przypisana uwaga, wpisanie daty i czasu (za pomocą kalendarza podręcznego) oraz tekstu uwagi. Opcjonalne PRT_019 System musi umożliwiać pracownikowi dostęp do informacji o świadczeniach ZFSŚ. Wymagalne PRT_020 System musi umożliwiać pracownikowi dostęp do informacji o badaniach lekarskich. Wymagalne PRT_021 System musi umożliwiać pracownikowi dostęp do danych płacowych poprzez możliwość wygenerowanie raportu „Pasek” z wynagrodzeniami z listy płac oraz PIT‐11. Wymagalne Strona 200 z 285
Nr
wymagania
Wymaganie
Kategoria
wymagania
PRT_022 System powinien umożliwiać pracownikowi dostęp do listy środków trwałych przypisanych do pracownika. Opcjonalne PRT_023 System powinien umożliwiać pracownikowi dostęp do listy środków trwałych przypisanych do pokoju pracownika. Opcjonalne PRT_024 System musi umożliwiać pracownikom dostęp do opisu stanowiska pracy. Wymagalne PRT_025 System musi umożliwiać publikowanie informacji o Ofertach pracy w ramach modułu rekrutacja. Wymagalne PRT_026 System musi umożliwiać przeszukiwanie bazy rekrutacji i zgłoszenia przez pracownika swojej kandydatury poprzez system wraz z wymaganymi informacjami i dokumentami. System musi automatycznie uzupełniać formularz, jeśli określone dane zostały zapisane w systemie. Wymagalne PRT_027 System powinien umożliwiać dokonanie ocen innych pracowników zgodnie z zasadami opisanymi w module Ocena okresowa. Opcjonalne PRT_028 System musi umożliwiać bezpośrednim przełożonym dostęp do historii ocen okresowych pracowników podległych. Wymagalne PRT_029 Systemu musi umożliwiać wyświetlanie przypomnień zdefiniowanych w innych modułach np. konieczności wykonania badania lekarskiego, wystąpienie o nowe poświadczenie bezpieczeństwa, konieczność dokonania oceny okresowej, konieczność odbycia szkolenia BHP itd. Wymagalne PRT_030 System musi umożliwiać kierownikowi działu generowanie raportu na temat stanu urlopów/nieobecności pracowników działu na koniec roku. Wymagalne PRT_031 System powinien umożliwiać publikowanie odpowiedzi na najczęściej zadawane pytania FAQ. Opcjonalne PRT_032 System musi umożliwiać pracownikom dostęp do danych o odbytych i planowanych szkoleniach. Wymagalne PRT_033 System musi umożliwiać pracownikom rejestrowanie się na szkolenia. Wymagalne PRT_034 System musi umożliwiać obieg zapisów na szkolenia. Wymagalne PRT_035 System musi umożliwiać imienne wypełnienie ankiety po odbytym szkoleniu. Wymagalne PRT_036 System musi umożliwiać anonimowe wypełnienie ankiety po odbytym szkoleniu. Wymagalne PRT_037 System musi umożliwiać konfigurację pytań występujących w ankiecie w zależności od szkolenia. Wymagalne PRT_038 System musi udostępniać członkom PKZP podstawowe dane na portalu, zawierające: • sumę wpłaconych składek (wkład), • historię wpłat / wypłat pracownika, • podstawowe informacje o pożyczkach z uwzględnieniem: o podziału pożyczek na produkty pożyczkowe, o informacji o spłaceniu / niespłaceniu pożyczki, o kwocie pozostałej do spłaty. Wymagalne Tabela 16 Wymagania dla komponentu Portal Strona 201 z 285
3 Wymagania niefunkcjonalne
3.1
Wymagania ogólne
NR
NF_OGL_1 Wymaganie
System musi być zbudowany w oparciu o Oprogramowanie Standardowe w zakresie: a) Oprogramowania Aplikacyjnego b) Serwerów aplikacji c) Oprogramowania bazodanowego d) Systemów operacyjnych Kategoria wymagania
Wymagalne NF_OGL_2 W zakresie Oprogramowania Aplikacyjnego, System musi być zbudowany w oparciu o Wymagalne Oprogramowanie Standardowe działające produkcyjnie w podmiocie niezależnym kapitałowo od Dostawcy i / lub od producenta Oprogramowania Standardowego, w środowisku teleinformatycznym podobnym do środowiska Zamawiającego tj. w organizacji wielooddziałowej posiadającej jednostki terenowe. NF_OGL_3 W zakresie Oprogramowania Aplikacyjnego, System musi być zbudowany w oparciu o Wymagalne Oprogramowanie Standardowe składające się z modułów / komponentów pochodzących maksymalnie od trzech producentów. NF_OGL_4 W zakresie Oprogramowania Aplikacyjnego, System musi być zbudowany w oparciu o Wymagalne Oprogramowanie Standardowe, które ma obowiązującą w Polsce gwarancję podmiotu posiadającego prawa autorskie do Oprogramowania Standardowego. NF_OGL_5 W zakresie Oprogramowania Aplikacyjnego, System musi być zbudowany w oparciu o Wymagalne Oprogramowanie Standardowe, które na rynku polskim, samodzielnie wdraża i serwisuje producent oprogramowania lub istnieją podmioty, które posiadają kompetencje niezbędne do wdrażania i serwisowania zgodnie z zaleceniami producenta. Jeśli Oprogramowanie Standardowe pochodzi od kilku producentów, wówczas warunek musi być spełniony dla każdego rodzaju oprogramowania. NF_OGL_6 W zakresie Oprogramowania Aplikacyjnego, System musi być zbudowany w oparciu o Wymagalne Oprogramowanie Standardowe dostępne na rynku w wersji COTS (commercial off‐the‐
shelf) przynajmniej od 3 lat, a w oferowanej wersji, co najmniej rok, ale nie dłużej niż 3 lata przed złożeniem oferty. NF_OGL_7 W zakresie Oprogramowania Aplikacyjnego, oferowane Oprogramowanie Standardowe Wymagalne powinno być objęte przez producenta tego oprogramowania gwarancją utrzymania dostępności wsparcia przez okres 5 lat od zakończenia wdrożenia. W przypadku zaprzestania wspierania przez producenta Oprogramowania Standardowego wsparcia w okresie 5 lat od zakończenia wdrożenia Dostawca Systemu zapewni bezpłatną migrację na Oprogramowanie Standardowe posiadające wsparcie producenta. NF_OGL_8 Sprzęt oraz oprogramowanie (wszelkiego typu) musi być nowe, pochodzić z oficjalnych kanałów sprzedaży producentów na teren Unii Europejskiej gwarantujących możliwość zakupu przedłużenia gwarancji/serwisu bezpośrednio u producentów lub ich autoryzowanych przedstawicieli po wygaśnięciu usług będących przedmiotem niniejszego postępowania. Tabela 17. Wymagania niefunkcjonalne ogólne Strona 202 z 285
3.2
Wymagania dot. architektury systemu
NR
Wymaganie
Kategoria wymagania
NF_TCH_1 Technologia, w której tworzony jest System musi być przez jej producenta aktualnie Wymagalne rozwijana oraz przynajmniej przez kolejne 5 lat od zakończenia wdrożenia. Dodatkowo, Dostawca Systemu w przypadku przerwania rozwoju tej technologii w tym okresie zapewni bezpłatną migrację na technologie aktualnie rozwijane. NF_TCH_2 System musi zapewniać mechanizmy migracji z jednego systemu operacyjnego na inny Wymagalne (każda z warstw systemu). NF_TCH_3 System musi posiadać mechanizmy umożliwiające poprawną aktualizację wersji Wymagalne komponentów Systemu niezależnie od źródła ich pochodzenia (od producenta Oprogramowania Standardowego, Dostawcy, czy też wprowadzone przez Zamawiającego). NF_TCH_4 System musi wykorzystywać system bazodanowy jednego producenta. NF_TCH_5 System musi zachować taką samą stabilność i wydajność pracy niezależnie od wzrostu Wymagalne liczby użytkowników poprzez skalowalność klastra serwerów bazodanowych i klastra lub farmy serwerów aplikacyjnych. NF_TCH_6 System musi być wielostanowiskowy, wielodostępowy – tzn. umożliwiać pracę wielu Wymagalne równoczesnych użytkowników w sieci komputerowej, w ramach licencji. System musi być dostępny z wyznaczonych komputerów działających w sieci PAŻP (jednocześnie nie dopuszcza się ograniczeń licencyjnych przypisujących użytkownika lub moduł systemu do stanowiska ‐ użytkownicy muszą mieć możliwość przenoszenia się między stanowiskami i zalogowania na dowolnym komputerze).
NF_TCH_7 System musi umożliwiać szybki dostęp do danych statystycznych / operacyjnych / innych Wymagalne związanych z działalnością firmy lub działu.
NF_TCH_8 Aplikacja kliencka, serwer aplikacyjny i powinny prawidłowo funkcjonować w środowisku Wymagalne 32 i 64‐bitowym. Serwer bazy danych powinien prawidłowo funkcjonować w środowisku przynajmniej 64‐bitowym NF_TCH_9 Eksploatacja systemu powinna zapewniać korzystanie z instalacji niezależnych środowisk Wymagalne – produkcyjnego, testowego i developerskiego (rozwojowego). NF_TCH_10 System musi posiadać wbudowane mechanizmy protokołowania i kontroli działania Wymagalne systemu. NF_TCH_11 System musi zapewniać dostęp przy wykorzystaniu protokołów szyfrowanych (na Wymagalne poziomie protokołu SSL lub równoważnego z kluczem min. 128 bit dla algorytmu symetrycznego). NF_TCH_12 System musi umożliwiać komunikację w zakresie uwierzytelnia i autoryzacji z Wymagalne rozwiązaniem stosowanym przez Zamawiającego (Microsoft Active Directory). NF_TCH_13 System musi posiadać zdolność do pracy systemu w sieci rozległej WAN. NF_TCH_14 System musi posiadać możliwość współpracy z urządzeniami pamięci masowej Wymagalne pochodzącymi od różnych producentów Wymagalne Wymagalne Tabela 18. Wymagania niefunkcjonalne dot. architektury systemu Strona 203 z 285
3.3
Wymagania prawne
W rozdziale zamieszczono wymagania niefunkcjonalne związane z wymogiem spełnienia określonych przepisów prawnych. Wymagania te podzielono na wymagania dotyczące całości systemu – wymagania o charakterze technicznym, wynikające z przepisów dotyczących wszelkich systemów teleinformatycznych używanych przez podmioty publiczne w Polsce. W podrozdziale tym pominięto kategoryzację wymagań ze względu na obligatoryjną konieczność całkowitej zgodności systemu z obowiązującymi przepisami prawa. Wskazane niżej przepisy (i wymagania zeń wynikające) są regulacjami obowiązującymi na moment tworzenia niniejszego dokumentu. System musi jednak zachowywać zgodność z regulacjami prawnymi obowiązującymi w momencie jego wdrożenia oraz przez cały okres obowiązywania umowy oraz z regulacjami wewnętrznymi obowiązującymi na dzień zakończenia etapu analizy i projektu (Etap 5.1). 3.3.1
Wymagania prawne ogólne
System – postrzegany jako kompletne rozwiązanie teleinformatyczne, musi zachowywać pełną zgodność z obowiązującymi przepisami prawa, ze szczególnym uwzględnieniem niżej wymienionych: NR
Wymaganie
NF_PRW_1 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 3 lipca 2002 r. Prawo lotnicze (tekst jednolity: Dz. U. 2012 r. poz. 933). NF_PRW_2 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 8 grudnia 2006 r. o Polskiej Agencji Żeglugi Powietrznej (Dz. U. 2006 r. Nr 249 poz. 1829)
NF_PRW_3 System musi być zgodny ze statutem Polskiej Agencji Żeglugi Powietrznej – załącznik do rozporządzenia Ministra Transportu z dnia 28 marca 2007 r. w sprawie nadania statutu Polskiej Agencji Żeglugi Powietrznej (Dz. U. 2007 r. Nr 56 poz. 378)
NF_PRW_4 System musi być zgodny z Regulaminem Organizacyjnym Polskiej Agencji Żeglugi Powietrznej – Zarządzenie Prezesa PAŻP. NF_PRW_5 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (tekst jednolity: Dz. U. 2013 r. poz. 235). NF_PRW_6 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. 2012 r. poz. 526). NF_PRW_7 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Prezesa Rady Ministrów z dnia 14 września 2011 r. w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz. U. 2011 r. Nr 206 poz. 1216). NF_PRW_8 System – w przypadku używania do identyfikacji użytkowników innych technologii niż kwalifikowany certyfikat, o którym mowa w ustawie o podpisie elektronicznym ‐ musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 21 kwietnia 2011 r. w sprawie szczegółowych warunków organizacyjnych i technicznych, które powinien spełniać system teleinformatyczny służący do identyfikacji użytkowników (Dz. U. 2011 r. Nr 93 poz. 545). NF_PRW_9 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (tekst jednolity: Dz. U. 2002 r. Nr 101 poz. 926), w szczególności zapewnić ochronę danych jak i warunki ich przetwarzania adekwatne do kategorii danych, w tym danych, o których mowa w art. 27 ustawy, tzw. danych wrażliwych. Kategoria wymagania
Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Strona 204 z 285
NR
Wymaganie
NF_PRW_10 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz. U. 2004 r. Nr 100 poz. 1024) NF_PRW_11 System musi posiadać pełną dokumentację wymaganą przez przepisy w zakresie ochrony danych osobowych, w szczególności Politykę Bezpieczeństwa Danych Osobowych oraz Instrukcję Zarządzania Systemem Informatycznym. NF_PRW_12 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (tekst jednolity: Dz. U. 2011 r. Nr 123 poz. 698 z późn. zm.). NF_PRW_13 System musi zapewnić spełnienie wymagań określonych w rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz. U. 2006 r. Nr 206 poz. 1519). NF_PRW_14 System musi zapewnić spełnienie wymagań określonych w rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz. U. 2006 r. Nr 206 poz. 1518). NF_PRW_15 System musi zapewnić spełnienie wymagań określonych w rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz. U. 2006 r. Nr 206 poz. 1517) w szczególności poprzez generowanie dokumentów zawierających odpowiednie metadane. NF_PRW_16 System musi zapewnić spełnienie wymagań określonych w Obwieszczeniu nr 4 Prezesa Urzędu Lotnictwa Cywilnego z dnia 4 czerwca 2009 r. w sprawie opłat trasowych (Dz.UrzULC. 2009 r. Nr 6 poz. 129 z późn. zm.) NF_PRW_17 System musi zapewnić spełnienie wymagań określonych w Rozporządzeniu Wykonawczym Komisji (UE) NR 390/2013 z dnia 3 maja 2013 r. ustanawiające system skuteczności działania dla służb żeglugi powietrznej i funkcji sieciowych (Dz. Urz. UE L 128/1).
NF_PRW_18 System musi zapewnić spełnienie wymagań określonych w Rozporządzeniu Wykonawczym Komisji (UE) NR 391/2013 z dnia 3 maja 2013 r. ustanawiające wspólny system opłat za korzystanie ze służb żeglugi powietrznej (Dz. Urz. UE L 128/31).
NF_PRW_19 System musi zapewnić spełnienie wymagań określonych w Rozporządzeniu Wykonawczym Komisji (UE) NR 409/2013 z dnia 3 maja 2013 r. w sprawie definicji wspólnych projektów, ustanowienia systemu zarządzania i określenia zachęt wspierających wdrożenie europejskiego centralnego planu zarządzania ruchem lotniczym (Dz. Urz. UE L 128/31). Kategoria wymagania
Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Tabela 19. Wymagania niefunkcjonalne – prawne o charakterze ogólnym, technicznym System musi gwarantować pełną zgodność z obowiązującymi przepisami prawa międzynarodowego dotyczącego PAŻP, ze szczególnym uwzględnieniem niżej wymienionych: NR
Wymaganie
NF_PRW_20 System musi być zgodny z wymaganiami wynikającymi z umowy wielostronnej w sprawie opłat trasowych, sporządzonej w Brukseli dnia 12 lutego 1981 r. (Dz. U. 2006 r. Nr 238 poz. 1725) NF_PRW_21 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Komisji (WE) nr 1034/2011 z dnia 17 października 2011 r. w sprawie nadzoru nad bezpieczeństwem w zarządzaniu ruchem lotniczym i służbach żeglugi powietrznej oraz zmieniającym rozporządzenie (UE) nr 691/2010 (Dz. Urz. UE L 271 z 18.10.2011) Kategoria wymagania
Wymagalne
Wymagalne
Strona 205 z 285
NR
Wymaganie
NF_PRW_22 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Komisji (WE) w sprawie ustanowienia wspólnych zasad w odniesieniu do przepisów lotniczych i operacyjnych dotyczących służb i procedur żeglugi powietrznej oraz zmieniające rozporządzenie wykonawcze (WE) nr 1035/2011 oraz rozporządzenia (WE) nr 1265/2007, (WE) nr 1794/2006, (WE) nr 730/2006, (WE) nr 1033/2006 i (UE) nr 255/2010 (923/2012/UE), (UE) nr 391/2013. Kategoria wymagania
Wymagalne
Wymagalne
NF_PRW_23 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Komisji (WE) Nr 2320/2002 Parlamentu Europejskiego i Rady Unii Europejskiej z dnia 16 grudnia 2002 r. ustanawiającym wspólne zasady bezpieczeństwa w lotnictwie cywilnym Tabela 20. Wymagania niefunkcjonalne ‐ prawne, wynikające z prawa międzynarodowego 3.3.2
Wymagania prawne specyficzne dla poszczególnych komponentów
Systemu
Dla poszczególnych komponentów systemu wyselekcjonowano i wskazano specyficzne wymagania wynikające z aktualnie obowiązujących regulacji prawnych dotyczących dziedziny realizowanej przez dany komponent Systemu. W zakresie każdej z tych dziedzin, System musi zachowywać pełną zgodność z wszelkimi obowiązującymi przepisami prawa, ze szczególnym uwzględnieniem wskazanych poniżej: 3.3.2.1
NR
Wymagania dla komponentu Elektroniczny Obieg Dokumentów
Wymaganie
NF_PRW_24 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz. U. 2011 r. Nr 14 poz. 67) Kategoria wymagania
Wymagalne
Wymagalne
NF_PRW_25 System musi być zgodny z wymaganiami wynikającymi z wewnętrznych regulacji PAŻP w zakresie obiegu dokumentów, z zastrzeżeniem możliwości dokonania zmian w tych regulacjach, uwzględniających zmianę formy dokumentów w porozumieniu z PAŻP. Wymagalne
NF_PRW_26 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz.U. 2002 r. Nr 144 poz. 1204). Wymagalne
NF_PRW_27 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Prezesa Rady Ministrów z dnia 29 września 2005 r. w sprawie warunków organizacyjno ‐ technicznych doręczania dokumentów elektronicznych podmiotom publicznym oraz formy urzędowego poświadczenia odbioru dokumentów w formie elektronicznej (Dz. U. z 2005r, Nr 200, poz. 1651) Wymagalne
NF_PRW_28 System musi zapewnić funkcjonalność zgodną z zapisami normy ISO 9001:2009 pkt 4.2 "Wymagania dotyczące dokumentacji" Tabela 21. Wymagania niefunkcjonalne – prawne o charakterze szczegółowym dla komponentu EOD 3.3.2.2
NR
Wymagania dla komponentu ERP – Zarzadzanie personelem
Wymaganie
NF_PRW_29 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 26 czerwca 1974 r. Kodeks pracy (tekst jednolity: Dz. U. 1998 r. Nr 21 poz. 94 z późn. zm.) NF_PRW_30 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Pracy i Polityki Socjalnej z dnia 28 maja 1996 r. w sprawie zakresu prowadzenia przez pracodawców dokumentacji w sprawach związanych ze stosunkiem pracy oraz sposobu prowadzenia akt osobowych pracownika (Dz. U. 1996 r. Nr 62 poz. 286)
Kategoria wymagania
Wymagalne
Wymagalne
Strona 206 z 285
NR
Wymaganie
NF_PRW_31 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Pracy i Polityki Socjalnej z dnia 15 maja 1996 r. w sprawie szczegółowej treści świadectwa pracy oraz sposobu i trybu jego wydawania i prostowania (Dz. U. 1996 r. Nr 60 poz. 28). NF_PRW_32 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Pracy i Polityki Społecznej z dnia 29 stycznia 2013 r. w sprawie należności przysługujących pracownikowi zatrudnionemu w państwowej lub samorządowej jednostce sfery budżetowej z tytułu podróży służbowej (Dz. U. 2013 r. poz. 167) NF_PRW_33 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Pracy i Polityki Socjalnej z dnia 8 stycznia 1997 r. w sprawie szczegółowych zasad udzielania urlopu wypoczynkowego, ustalania i wypłacania wynagrodzenia za czas urlopu oraz ekwiwalentu pieniężnego za urlop. (Dz. U. 1997 r. Nr 2 poz. 14) NF_PRW_34 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 13 października 1998 r. o systemie ubezpieczeń społecznych (tekst jednolity: Dz. U. 2009 r. Nr 205 poz. 1585). NF_PRW_35 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Pracy i Polityki Społecznej z dnia 16 grudnia 2009 r. w sprawie określenia szczegółowych informacji przekazywanych do Zakładu Ubezpieczeń Społecznych przez instytucje obsługujące wpłaty składek na ubezpieczenia społeczne w zleceniu płatniczym oraz formatu zlecenia płatniczego w formie dokumentu elektronicznego (Dz. U. 2009 r. Nr 219 poz. 1711). NF_PRW_36 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Pracy i Polityki Społecznej z dnia 23 października 2009 r. w sprawie określenia wzorów zgłoszeń do ubezpieczeń społecznych i ubezpieczenia zdrowotnego, imiennych raportów miesięcznych i imiennych raportów miesięcznych korygujących, zgłoszeń płatnika, deklaracji rozliczeniowych i deklaracji rozliczeniowych korygujących, zgłoszeń danych o pracy w szczególnych warunkach lub o szczególnym charakterze oraz innych dokumentów (Dz. U. 2009 r. Nr 186 poz. 1444) NF_PRW_37 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Pracy i Polityki Społecznej z dnia 2 lutego 2001 r. w sprawie określenia wzoru informacji o zasiłkach, świadczeniach lub wynagrodzeniach z tytułu niezdolności do pracy, wypłaconych przez płatników składek, oraz sposobu jej sporządzania, przekazywania i korygowania (Dz. U. 2001 r. Nr 10 poz. 81) NF_PRW_38 Dane zawarte w procesie planowania zatrudnienia i wynagrodzeń muszą być zgodne z procedurami wewnętrznymi PAŻP. NF_PRW_39 System musi umożliwiać naliczanie wynagrodzeń zgodnie z obowiązującymi przepisami prawa zewnętrznego i wewnętrznego obowiązującego w PAŻP. NF_PRW_40 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Transportu, Budownictwa i Gospodarki Morskiej z dnia 12 kwietnia 2013 w sprawie licencji i świadectw kwalifikacji personelu służb ruchu lotniczego (Dz. U. 2013 r. poz. 471) Kategoria wymagania
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Tabela 22. Wymagania niefunkcjonalne ‐ prawne o charakterze szczegółowym dla podsystemu ZP 3.3.2.3
NR
Wymagania dla komponentów finansowo-księgowych ERP
Wymaganie
NF_PRW_41 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz. U. 2009 r. Nr 157 poz. 1240) NF_PRW_42 System musi być zgodny z wymaganiami wynikającymi z komunikatu Ministra Finansów z dnia 20 maja 2011 r. w sprawie standardów audytu wewnętrznego dla jednostek sektora finansów publicznych (Dz. Urz. MF. 2011 r. Nr 5 poz. 23) NF_PRW_43 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 29 września 1994 r. o rachunkowości (tekst jednolity: Dz. U. 2013 r. poz. 330) Kategoria wymagania
Wymagalne
Wymagalne
Wymagalne
Strona 207 z 285
NR
Wymaganie
NF_PRW_44 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 26 lipca 1991 r. o podatku dochodowym od osób fizycznych (tekst jednolity: Dz. U. 2012 r. poz. 361) NF_PRW_45 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Finansów z dnia 14 listopada 2011 r. w sprawie określenia wzorów rocznego obliczenia podatku oraz zeznań podatkowych obowiązujących w zakresie podatku dochodowego od osób fizycznych (Dz. U. 2011 r. Nr 252 poz. 1518) NF_PRW_46 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 15 lutego 1992 r. o podatku dochodowym od osób prawnych (tekst jednolity: Dz. U. 2011 r. Nr 74 poz. 397) NF_PRW_47 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Finansów z dnia 25 listopada 2011 r. w sprawie określenia wzorów deklaracji, zeznania, oświadczenia oraz informacji podatkowych obowiązujących w zakresie podatku dochodowego od osób prawnych (Dz. U. 2011 r. Nr 265 poz. 1575) NF_PRW_48 System musi być zgodny z wymaganiami wynikającymi z ustawy z dnia 11 marca 2004 r. o podatku od towarów i usług (tekst jednolity: Dz. U. 2011 r. Nr 177 poz. 1054) NF_PRW_49 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Finansów z dnia 28 marca 2011 r. w sprawie zwrotu podatku niektórym podatnikom, wystawiania faktur, sposobu ich przechowywania oraz listy towarów i usług, do których nie mają zastosowania zwolnienia od podatku od towarów i usług (Dz. U. 2011 r. Nr 68 poz. 360) NF_PRW_50 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Finansów z dnia 20 grudnia 2012 r. w sprawie przesyłania faktur w formie elektronicznej, zasad ich przechowywania oraz trybu udostępniania organowi podatkowemu lub organowi kontroli skarbowej (Dz. U. 2012 r. poz. 1528) NF_PRW_51 System musi być zgodny z wymaganiami wynikającymi z rozporządzenia Ministra Transportu z dnia 15 maja 2007 r. w sprawie opłat nawigacyjnych (Dz. U. 2007 r. Nr 92, poz. 619) NF_PRW_52 System musi sporządzać sprawozdania finansowe zgodnie z wymaganiami obowiązujących PAŻP przepisów prawa polskiego jak i Międzynarodowymi Standardami Rachunkowości, Międzynarodowymi Standardami Sprawozdawczości Finansowej oraz związanymi z nimi interpretacjami zawartymi w rozporządzeniach Komisji Europejskiej. Kategoria wymagania
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
Wymagalne
W szczególności zgodnie z następującymi Międzynarodowymi Standardami Rachunkowości: a) MSR 1 – Prezentacja Sprawozdań Finansowych, b) MSR 2 – Zapasy, c) MSR 7‐ Sprawozdanie z przepływów pieniężnych, d) MSR8 – Zasady ( polityka) rachunkowości, zmiany wartości szacunkowych i korygowanie błędów, e) MSR 10 – Zdarzenia po zakończeniu okresu sprawozdawczego, f) MSR 12 – Podatek dochodowy, g) MSR 16 – Rzeczowe aktywa trwałe, h) MSR 17 – Leasing, i) MSR 18 ‐ Przychody, j) MSR 19 – Świadczenia pracownicze, k) MSR 20 – Dotacje rządowe oraz ujawnienie informacji na temat pomocy rządowej, l) MSR 21 – Skutki zmian kursów wymiany walut obcych, m) MSR 23 – Koszty finansowania zewnętrznego, n) MSR 26 – Rachunkowość i sprawozdawczość programów świadczeń emerytalnych, o) MSR 32 – Instrumenty finansowe: prezentacja, p) MSR 36 ‐ Utrata wartości aktywów, q) MSR 37 – Rezerwy, zobowiązania warunkowe i aktywa warunkowe, r) MSR 38 – Aktywa niematerialne, s) MSR 39‐ Instrumenty finansowe: ujmowanie i wycena. t) MSSF 8 Segmenty operacyjne Strona 208 z 285
NR
Wymaganie
NF_PRW_53 System musi być zgodny z wymaganiami wynikającymi z Rozporządzenia Ministra Transportu, Budownictwa i Gospodarki Morskiej z dnia 13 sierpnia 2013 r. w sprawie sposobu i trybu rozliczania i dokumentowania kosztów związanych z zapewnieniem służb żeglugi powietrznej za loty zwolnione z opłat nawigacyjnych (Dz. U. 2013 r. poz. 1009). Kategoria wymagania
Wymagalne
Tabela 23. Wymagania niefunkcjonalne ‐ prawne o charakterze szczegółowym dla podsystemu FK 3.4
Wymagania dotyczące gwarancji i rękojmi
Wymagania Zamawiającego dotyczące Gwarancji Jakości i rękojmi określone zostały w rozdziale 13 Istotnych Postanowień Umowy. 3.4.1
Wymagania dotyczące części eksploatacyjnych i części zamiennych
Wymagania Zamawiającego dotyczące części eksploatacyjnych i części zamiennych w zakresie koniczności wymiany uszkodzonych nośników danych reguluje ustęp 27 paragrafu 13 Istotnych Postanowień Umowy. 3.4.2
Wymagania dotyczące raportowania w okresie gwarancji
Wykonawca w trakcie trwania Gwarancji Jakości, zobowiązany jest do przedkładania Zamawiającemu comiesięcznych raportów zawierających w szczególności liczbę i kategoryzację przyjętych i obsłużonych zgłoszeń wraz ze statystyką dotyczącą czasu ich obsługi. Szczegółowe wymagania dotyczące tych raportów określa ustęp 39 paragrafu 13 Istotnych Postanowień Umowy. 3.4.3
Warunki pogwarancyjne
Zamawiający nie przewiduje żadnych zobowiązań Wykonawcy związanych ze świadczeniem serwisu pogwarancyjnego po upływie okresu Gwarancji Jakości i rękojmi. Strona 209 z 285
3.5
Niefunkcjonalne wymagania organizacyjne
NR
Wymaganie
Kategoria wymagania
NF_ORG_1 Dostawca Systemu w Etapie 5.1 wykona analizę procesów biznesowych pod kątem Wymagalne implementacji Systemu i uwzględni rezultat w Projekcie Technicznym. NF_ORG_2 W Systemie w momencie uruchomienia produkcyjnego muszą być skonfigurowane Wymagalne algorytmy automatycznie wyliczające 100 wskaźników/mierników m.in. wskaźniki zgodne ze specyfikacją Eurocontrol oraz algorytmy wyliczające dane zgodnie ze specyfikacją raportowania danych statystycznych dla Organizacji Międzynarodowego Lotnictwa Cywilnego (International Civil Aviation Organization), formularze „K” (Air Navigation Services Financial Data) oraz „L” (En‐route Services Traffic Statistics). Szczegóły specyfikacji dostępne na stronie internetowej: a) www.eurocontrol.int, b) www.icao.int W związku z założeniem wykonywania części prac przez Zamawiającego, oprócz wykonania ww. 100 mierników Dostawca Systemu udzieli asysty przy samodzielnym wykonywaniu mierników przez Zamawiającego. NF_ORG_3 Zamawiający, podczas analizy w ramach Etapu 5.1 dokona wyboru dziesięciu raportów, Wymagalne spośród zgłoszonych ze statusem „opcjonalne” które zostaną wykonane przez Dostawcę w ramach prac implementacyjnych. Zakłada się, że będą to raporty dedykowane dla działalności Agencji, najistotniejsze dla niej, wybrane spośród zgłoszonych jako wymagania użytkownika w trakcie analizy przedwdrożeniowej. Liczba ta nie dotyczy standardowych raportów zawartych w dostarczanym oprogramowaniu, takich jak np. zestawienie obrotów i sald, zestawienie obrotów magazynowych, lista płac, czy wydruki z kartotek danych oraz operacji. W związku z założeniem wykonania części prac w obszarze raportowania przez Zamawiającego, oprócz wykonania wszystkich raportów o statusie „wymagalny” oraz wybranych 10 raportów o statusie „opcjonalny”, Dostawca Systemu udzieli asysty przy samodzielnym wykonywaniu raportów przez Zamawiającego. Strona 210 z 285
NR
Wymaganie
Kategoria wymagania
NF_ORG_4 W związku z założeniem wykonania części prac w obszarze raportowania przez Wymagalne Zamawiającego, Dostawca Systemu dostarczy w sposób zgodny z zakresem określonym w wymaganiach funkcjonalnych przynajmniej następujące produkty podczas prac implementacyjnych: 3 panele informacji zarządczej (dashboard, pulpit menedżerski). Pulpit taki zawiera zestawienia informacji z określonych obszarów, udostępnia możliwości raportowania i symulacji, a w zależności od implementacji posiada elementy systemu powiadomień i wymiany komunikatów pomiędzy użytkownikami. Panel taki po zdefiniowaniu i skonfigurowaniu podlegałby procedurze autoryzacji dostępu do funkcji i danych odpowiednio do ról pełnionych przez użytkownika w organizacji, w różnych jej obszarach. Dotyczy to następujących paneli obszarowych: a)
Panel strategiczny. Zawiera informacje o celach strategicznych i ich parametrach operacyjnych, powiązaniu z celami operacyjnymi, a także umożliwia wykonywanie analiz strategicznych w zakresie określonym przez dane i zdefiniowane modele analityczne. b)
Panel finansowy. Zawiera z reguły zestawienie informacji finansowych i powiązanych z nimi informacji rzeczowych, w tym plany, budżety, wskaźniki, analizy i raporty. Celem utworzenia takiego panelu jest zebranie w jednym miejscu dostępnych informacji, oraz narzędzi wsparcia decyzyjnego niezbędnych dla zapewnienia bezpieczeństwa finansowego Agencji. c)
Panel operacyjny. Zawiera informacje oparte o dane operacyjne, w wypadku PAŻP byłyby to dane o zadaniach i przedsięwzięciach, oraz o odchyleniach ich realizacji. Celem utworzenia takiego panelu jest zebranie w jednym miejscu narzędzi analitycznych i informacji decyzyjnych w wybranym obszarze. Panele operacyjne powinny być skonfigurowane dla poszczególnych obszarów operacyjnych PAŻP, uzgodnionych podczas wdrożenia. Oprócz wykonania wybranych trzech paneli Dostawca Systemu udzieli asysty przy samodzielnym wykonywaniu paneli przez Zamawiającego. NF_ORG_5 Zamawiający, podczas analizy w ramach Etapu 5.1 dokona wyboru dziesięciu obiegów Wymagalne spraw różnych typów spośród zgłoszonych ze statusem „opcjonalne”, które zostaną wykonane przez Dostawcę (oprócz skonfigurowania obiegu ogólnego (ad‐hoc)). Ponieważ część zadań dotyczących zarządzania obiegiem dokumentów i procedurami jest wbudowana w architekturę aplikacji ERP, obiegi mogą być realizowane w sposób kompleksowy, wykorzystujący zarówno mechanizmy aplikacji ERP, jak i mechanizmy aplikacji EOD, każdy we właściwym dla danego obiegu miejscu. Ze względu na specyfikę działalności Dostawca Systemu zdefiniuje co najmniej obiegi spraw zapewniających wykonanie kluczowych procedur Agencji: a) Procedura zakupowa z uwzględnieniem PZP (od wniosku aż po rozliczenie faktury, w powiązaniu z ERP), b) Procedura planowania stawek opłat nawigacyjnych i budżetowania (w powiązaniu z EPM), c) Procedura obiegu wybranej sprawy związanej z analizą bezpieczeństwa Procedury ogólnej. d) Procedura inwestycyjna z uwzględnieniem projektów W związku z założeniem wykonania części prac w obszarze obiegów przez Zamawiającego, oprócz wykonania wszystkich obiegów o statusie „wymagalny” oraz wybranych 10 obiegów spraw o statusie „opcjonalny”, Dostawca Systemu udzieli asysty przy samodzielnym wykonywaniu obiegów przez Zamawiającego. Strona 211 z 285
NR
Wymaganie
Kategoria wymagania
NF_ORG_6 Zamawiający, podczas analizy w ramach Etapu 5.1 dokona wyboru dziesięciu rejestrów Wymagalne dokumentów spośród zgłoszonych ze statusem „opcjonalne”, które zostaną wykonane przez Dostawcę. Dostawca Systemu w ramach wdrożenia wykona konfigurację tzw. edytora rejestrów oraz konfigurację wybranych rejestrów. W związku z założeniem wykonania części prac w obszarze rejestrów przez Zamawiającego, oprócz wykonania wszystkich rejestrów o statusie „wymagalny”, oraz wybranych 10 rejestrów o statusie „opcjonalny”, Dostawca Systemu udzieli asysty przy samodzielnym wykonywaniu rejestrów przez Zamawiającego. Tabela 24. Wymagania niefunkcjonalne – organizacyjne 3.6
Wymagania dotyczące dostępności, wydajności i skalowalności
Systemu
Przedmiotem oferty jest System jako kompletna całość, nie zaś poszczególne jego części składowe. Zgodność poszczególnych części składowych systemu z ofertą lub Opisem Przedmiotu Zamówienia nie zwalnia Dostawcy z obowiązku zapewnienia realizacji wymagań wydajnościowych zdefiniowanych dla systemu jako całości w Opisie Przedmiotu Zamówienia. NR
Wymaganie
NF_WYD_1 System musi być dostępny całodobowo, 7 dni w tygodniu z zastrzeżeniem warunków Wymagalne gwarancji określonych w paragrafie 13 Istotnych Postanowień Umowy. Wymagalne Komponenty ERP oraz EOD muszą charakteryzować się minimum 99,0% dostępnością w skali roku liczoną w godzinach dostępności systemu z zastrzeżeniem warunków gwarancji określonych w paragrafie 13 Istotnych Postanowień Umowy. Wymagalne Komponent BI /EPM musi charakteryzować się minimum 98% dostępnością w skali roku liczoną w godzinach dostępności systemu. NF_WYD_2 NF_WYD_3 NF_WYD_4 NF_WYD_5 Kategoria wymagania
System musi osiągać zakładane parametry wydajnościowe podczas pracy użytkowników Wymagalne w liczbie określonej w rozdziale 1.7. System musi osiągać zakładane parametry wydajnościowe i pojemnościowe przy Wymagalne zakładanym wolumenie danych: a) w chwili startu systemu – 550 GB b) roczny przyrost – 64 GB Podczas skalowania przestrzeni dyskowej należy zakładać 10‐letni przyrost danych. NF_WYD_6 System musi być sprzętowo przygotowany do działania z zakładana wydajnością w okresie 5 lat (Zamawiający przewiduje, iż ilość użytkowników nie ulegnie zmianie). NF_WYD_7 Dostawca Systemu w ramach dostarczonej mocy obliczeniowej wyskaluje: a) środowisko produkcyjne b) środowisko testowo‐developerskie (łącznie nie mniej jak 25% mocy środowiska produkcyjnego) NF_WYD_8 Środowisko produkcyjne musi być oddzielone od środowiska testowo‐developerskiego w sposób fizyczny tzn. środowisko produkcyjne musi funkcjonować na innych serwerach fizycznych niż środowisko testowo‐developerskie. NF_WYD_9 Środowisko testowe musi być oddzielone od środowiska developerskiego przynajmniej na poziomie logicznym. Wymagalne Wymagalne Wymagalne Wymagalne Strona 212 z 285
NF_WYD_10 Dla środowiska testowo‐developerskiego nie wymaga się budowy układów wysokiej dostępności w zakresie nadmiarowości serwerów. NF_WYD_11 Komponenty ERP oraz EOD muszą pracować w układzie wydajnościowo‐
niezawodnościowym tj: a) serwery baz danych – układ Active‐Active, b) serwery aplikacyjne – układ klastra lub farma. NF_WYD_12 Moc obliczeniowa przewidziana dla komponentów ERP oraz EOD musi być tak dobrana, aby awaria dowolnego elementu układu niezawodnościowego (tam gdzie jest on wymagany) nie powodowała spadku wydajności system poniżej parametrów minimalnych opisanych w OPZ NF_WYD_13 Opóźnienie wyświetlania poszczególnych ekranów systemu, formatek, zapisywanie danych dla operacji wykonywanych w ramach rutynowej pracy codziennej użytkowników systemu, nie może przekroczyć 5 sekund przy pełnym obciążeniu systemu (parametr mierzy się jako średnia z 10 rzeczywistych zadań, które zostaną zdefiniowane w Projekcie Technicznym) – powyższy parametr stosuje się dla komunikacji z użyciem sieci LAN o przepływności min. 1Gbps. NF_WYD_14 W przypadku awarii pojedynczego elementu (np. serwera, dysku, kontrolera) dla podsystemów działających w układach klastrowych oraz posiadających architekturę nadmiarową typu Active‐Active zakłada się: a) Czas przestoju musi być bliski „0” sek. – nie dotyczy podsystemów BI/EPM. b) Aktualność danych zapisanych w momencie wystąpienia awarii NF_WYD_15 Wykonanie pełnej kopii zapasowej bazy danych nie może trwać dłużej jak 1 godzinę. Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Tabela 25. Wymagania dotyczące dostępności, wydajności i skalowalności Szczegółowe sposoby weryfikacji parametrów zdefiniowanych w powyższej tabeli zostaną określone w Projekcie Technicznym. Strona 213 z 285
4 Wymagania techniczne
4.1
Wymagania dla infrastruktury technicznej
4.1.1
Opis obecnej infrastruktury Zamawiającego
Zamawiający posiada nowoczesną infrastrukturę techniczną, którą Dostawca Systemu może wykorzystać na potrzeby realizacji Projektu. W ramach Infrastruktury Zamawiający udostępni: a) pomieszczenie (serwerownię zlokalizowaną w siedzibie Zamawiającego) z miejscem na instalację dwóch szaf teletechnicznych o wysokości 42 RU; b) moc zasilania do 20kW (trzy niezależne źródła zasilania jednofazowego). c) moc chłodzenia 10kW (jeżeli zapas mocy chłodzenia przewidzianej na potrzeby realizacji projektu okaże się niewystarczający, wówczas Wykonawca zobowiązany jest wykonać odpowiednią rozbudowę systemu klimatyzacji. Opis warunków rozbudowy znajduje się w rozdziale 4.1.3.5 niniejszego dokumentu); d) redundantną sieć WAN o przepływności 12 Mbps łączącą centralę z oddziałami (Gdańsk, Poznań, Kraków, Katowice) oraz 8 Mbps łączącą centralę z oddziałami (Szczecin, Wrocław, Rzeszów, Łódź, Bydgoszcz); e) redundantną sieć LAN z rdzeniem sieci wyposażonym w przełączniki dysponujące portami 10 GbE (Zamawiający udostępni 2 porty 10GbE per przełącznik rdzeniowy) – jeśli ilość portów przewidzianych przez Zamawiającego na potrzeby realizacji projektu okaże się niewystarczająca to dostarczenie odpowiedniego rozwiązania zapewniającego odpowiednią przepustowość (ilość portów) leży po stronie Dostawcy; f) redundantną sieć SAN z przełącznikami wyposażonymi w porty 8 GbFC (Zamawiający udostępni 10 portów 8 GbFC per przełącznik) – jeśli ilość portów przewidzianych przez Zamawiającego na potrzeby realizacji projektu okaże się niewystarczająca to dostarczenie odpowiedniego rozwiązania zapewniającego odpowiednią przepustowość (ilość portów) leży po stronie Dostawcy; g) serwer HP Superdome 2 wyposażony zgodnie z poniższą tabelą: Ilość
Numer kat.
Opis
1 AF002A HP Universal Rack 10642 G2 Shock Rack 1 AF002A 001 BASE RACKING 1 AH352A HP Superdome 2 ‐ 8s Server 1 AH352A 005 HP SD2 ‐ 5 wire Int'l 3 Phase PDU 1 AH352A 0D1 Factory integrated 1 AH389A HP Superdome 2 ‐ 8s Power Boost Pack 1 AH389A 0D1 Factory integrated 2 AT084A HP Integrity 10GbE Pass‐Thru Module
2 AM253A HP CB900s i2 Itanium 9350 8c Blade
8 AH340A HP DDR3 16GB (4x4GB) Memory Module 1 BA927AA HP‐UX 11i v3 BOE Media 1 BA927AA AJR DVD media 1 BA927AA A53 HP‐UX 11i Version 3 1 BA927AA ABA U.S. ‐ English localization 1 BA927AC HP‐UX 11i v3 Base OE LTU 1 BA927AC B01 Include with complete system Strona 214 z 285
4 BA927AC 484 PSL HP‐UX 11i Integrity 8Skt/4Core LTU 1 AH338A HP Superdome 2 Iox Enclosure 1 AD337A HP PCIe 2‐port 1000Base‐T Card 2 AD339A HP PCIe 4‐port 1000Base‐T Gigabit Adptr 2 AH401A HP PCIe 2‐port 8Gb FC SR (Qlogic) HBA
1 AH338A HP Superdome 2 Iox Enclosure 1 AH338A 002 HP SD2 ‐ 5 wire Int'l Single Phase PDU 1 AD337A HP PCIe 2‐port 1000Base‐T Card 2 AD339A HP PCIe 4‐port 1000Base‐T Gigabit Adptr Tabela 26. Wyposażenie serwera HP Superdome 2 Serwer jest wykorzystywany przez obecnie eksploatowany System klasy ERP. W ramach realizacji Projektu Zamawiający dopuszcza wykorzystanie obecnego serwera oraz jego rozbudowę przez doinstalowanie dodatkowych cel procesorowych oraz modułów I/O (o ile będzie to konieczne). Dostawca Systemu kalkulując wykorzystanie serwera Superdome 2 musi uwzględnić okres wdrożeniowy, w którym będą musiały pracować oba systemy. Wykorzystanie serwera Superdome 2 na potrzeby Projektu nie może ograniczać dostępu do danych w obecnie eksploatowanym systemie jeżeli dane te nie zostaną zmigrowane do nowego Systemu oraz nie zakończy się praca równoległa. h) licencje technologiczne; PAŻP w swoich zasobach posiada licencje, które Dostawca Systemu może wykorzystać przy wdrożeniu Systemu bez ponoszenia dodatkowych kosztów. Poniżej przedstawiono listę licencji, będących w posiadaniu Agencji. Lp.
Opis
Liczba
licencji
1. Licencje dla wybranych modułów oprogramowania Oracle 200 na EBS: Użytkowników Nazwanych a) Oracle Advanced Collections b)
Oracle Advanced Pricing c)
Oracle Configurator d)
Oracle Enterprise Asset Management e)
Oracle Financials f)
Oracle Financials & Sales Analyzers g)
Oracle Financials Intelligence h)
Oracle Inventory Management i)
Oracle iProcurement j)
Oracle Order Management k)
Oracle Procurement Intelligence l)
Oracle Project Contracts Uwagi
Licencje Oracle EBS, mogą być wykorzystane pod warunkiem ich upgrade’u Systemu EBS do najnowszej wersji. m) Oracle Project Costing n)
Oracle Project Resource Management Strona 215 z 285
2. o)
Oracle Projects Intelligence p)
Oracle Purchasing q)
Oracle Sales Contracts r)
Oracle Service Contracts s)
Oracle Supply Chain & Order Management Intelligence. Licencje Oracle E‐business Suite (OeBS) dla wybranych 600 modułów podsystemu Zarządzania Personelem: pracowników a)
Oracle Human Resources b)
Oracle Self‐Service Human Resources c)
Oracle Advenced Benefits d)
Oracle Payroll e)
Oracle HR Intelligence 3. Licencje SAP Business Objects Profitability, służące do 1 kalkulacji stawek: a) Business Objects Activity Analysis XI Windows (Serwer per 4‐CPU), Licencje SAP, mogą być wykorzystane pod warunkiem ich upgrade’u do najnowszej wersji. 4. Licencje SAP Business Objects Profitability, służące do 2 kalkulacji stawek. a) Profit Model Builder XI Windows Named User Licencje SAP, mogą być wykorzystane pod warunkiem ich upgrade’u do najnowszej wersji. 5. Licencje SAP Business Objects Profitability, służące do 3 kalkulacji stawek. a) Profit Application User XI Windows Named User. Licencje SAP, mogą być wykorzystane pod warunkiem ich upgrade’u do najnowszej wersji. 6. Licencje Oracle na bazę danych Na cztery procesory 7. Licencje Oracle na serwer aplikacyjny /Liczba licencji do określenia przez PAŻP/ Tabela 27. Lista licencji będących w posiadaniu Zamawiającego 4.1.2
NR
INF_1 Wymagania ogólne
Wymaganie
Kategoria wymagania
Architektura techniczna systemu musi być zbudowana w sposób skalowany tzn. musi być Wymagalne zapewniona możliwość rozbudowy systemu w okresie przynajmniej 5 lat (od dnia zakończenia wdrożenia) o nowe komponenty techniczne, których zadaniem będzie sprostanie zmieniającym się potrzebom wydajnościowym i pojemnościowym. W celu umożliwienia rozbudowy przy jednoczesnym zachowaniu neutralności technologicznej system musi zostać zbudowany w oparciu o: a) Sprzęt (hardware) dostępny na rynku w dniu składania ofert, na który producent nie ogłosił końca sprzedaży/produkcji (nie dotyczy sprzętu już posiadanego przez PAŻP, a wykorzystanego w projekcie) b) Sprzęt (hardware) dostępny na rynku u producentów w stosunku, do których nie ogłoszono upadłości (nie dotyczy sprzętu już posiadanego przez PAŻP, a wykorzystanego w projekcie) Strona 216 z 285
c)
INF_2 INF_3 INF_4 INF_5 INF_6 Sprzęt (hardware) oparty o rozwiązania implementowane przez wielu producentów w oparciu o otwarte standardy (kompatybilność w zakresie wykonywanego kodu maszynowego) (nie dotyczy sprzętu już posiadanego przez PAŻP i jego rozbudowy, a wykorzystanego w projekcie) d) Oprogramowanie Standardowe dostępne na rynku w dniu składania ofert, na które producent nie ogłosił końca sprzedaży/produkcji/wsparcia (nie dotyczy oprogramowania już posiadanego przez PAŻP, a wykorzystanego w projekcie) e) Oprogramowanie Standardowe dostępne na rynku u producentów w stosunku, do których nie ogłoszono upadłości (nie dotyczy oprogramowania już posiadanego przez PAŻP, a wykorzystanego w projekcie). System musi zostać zbudowany z zachowaniem zasad pozwalających na zachowanie poufności oraz integralności danych: a) Dostęp do Systemu (również z poziomu Administratora) będzie wymagał logowania z wykorzystaniem centralnego serwera logowania (Microsoft Active Directory). b) System będzie zbierał logi o aktywności użytkowników c) System będzie zapewniał jednoznaczną identyfikację osób wykonujących operacje administracyjne. d) Każdy z użytkowników będzie miał dostęp tylko do modułów i danych Systemu jakie są mu niezbędne dla wykonywania obowiązków służbowych. e) Dane będą udostępniane innym systemom tylko w zakresie jaki jest im niezbędny. f) System będzie umożliwiał oddzielenie roli Administratora danych od Administratora Systemu a także innych ról tak jak np. oddzielenie roli Administratora Biznesowego od roli Analityka Biznesowego.
Wszystkie urządzenia muszą mieć jednofazowy system zasilania. Wszystkie urządzenia danej kategorii (np. serwery) muszą pochodzić od jednego producenta. Wszystkie urządzenia aktywne muszą posiadać zgodność w zakresie wymaganych przepisami norm (w szczególności posiadać znak CE) oraz być wyprodukowane zgodnie z normą ISO 9001:2008 lub równoważną. Dostarczane urządzenia muszą być nowe, wyprodukowane nie wcześniej niż 12 miesięcy liczone od daty dostawy do Zamawiającego oraz pochodzić z oficjalnych kanałów sprzedaży producentów na teren Unii Europejskiej gwarantujących możliwość zakupu przedłużenia gwarancji/serwisu bezpośrednio u producentów lub ich autoryzowanych przedstawicieli po wygaśnięciu usług wynikających z niniejszego projektu Gwarancja producenta sprzętu nie może być w toku w momencie dostawy do Zamawiającego. Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Tabela 28. Wymagania ogólne dotyczące infrastruktury 4.1.3
Wymagania dla sprzętu
4.1.3.1
Serwery
Zamawiający wymaga dostarczenia mocy obliczeniowej w postaci odpowiedniej liczby serwerów w celu spełnienia wymagań wydajnościowych Systemu. Dostawca Systemu będzie zobowiązany do wykonania skalowania (określenia wymaganych zasobów w celu spełnienia wymagań wydajnościowych) we własnym zakresie, jednak niezależnie od uzyskanych wyników skalowania musi dostarczyć minimalną (wymienioną w OPZ) moc obliczeniową. NR
Wymaganie
Kategoria wymagania
MCOB_01 Dostawca Systemu dostarczy i zainstaluje serwery o łącznym wyniku osiągniętym w teście Wymagalne SPECint_rate2006 (baseline) opublikowanym na stronie internetowej http://www.spec.org nie mniejszym jak 4680 pkt. Sposób wyliczania: a) wynik łączny jest sumą arytmetyczną wyników poszczególnych serwerów. b) wyniki poszczególnych serwerów powinny być rzeczywiste (dostępne na stronie spec.org) i zgodne z serwerami oferowanymi w projekcie.* Dodatkowo wynik uzyskiwany przez pojedynczy rdzeń procesora (x86) nie może być Strona 217 z 285
mniejszy niż 39 pkt. Przykład obliczania pkt per rdzeń: Serwer 2x Procesor 8 rdzeni fizycznych, wynik w teście SPECint2006 Rate (baseline) ‐ 656 pkt Obliczenia: 656/16 = 41 pkt na rdzeń W celu potwierdzenia wymagań Dostawca Systemu dostarczy wynik testu Spec.org dla każdego z rodzajów zastosowanych procesorów (x86) zgodnie z oferowana platformą serwerową.* Jeżeli Dostawca Systemu w ramach realizacji Projektu wykorzysta posiadany przez Zamawiającego serwer Superdome2 (ewentualnie go rozbuduje) należy stosować przelicznik: 1 rdzeń procesora Itanium wykorzystanego w projekcie = 39 pkt *Jeżeli oferowany model serwera z oferowanym procesorem(x86) nie został przetestowany (nie ma wyniku testu na stronie http://www.spec.org wówczas do kalkulacji należy przyjąć najniższy (najgorszy) wynik z publikowanych na stronie http://www.spec.org dla zastosowanego procesora/procesorów MCOB_02 Dostawca Systemu dostarczy i zainstaluje serwery o łącznej ilości pamięci RAM nie Wymagalne mniejszej jak 1024 GB MCOB_03 Jeżeli Dostawca Systemu w ramach realizacji Projektu przewiduje stosować wirtualizację Wymagane należy przewidzieć dodatkowy zapas mocy obliczeniowej (zgodne z MCOB.01) oraz pamięci RAM na potrzeby obsługi mechanizmów wirtualizacji w ilości nie mniejszej jak 15% mocy obliczeniowej/pamięci przewidzianej na obsługę Systemu (zgodnie z MCOB.01 i MCOB.02) SERW_01 Dostarczone rozwiązanie serwerowe musi być rozwiązaniem w architekturze blade Wymagalne (kasetowej). SERW_02 System musi być zbudowany w oparciu o dowolną kombinację serwerów (kaset) jedno i/lub dwuprocesorowych (x86) (nie dopuszcza się stosowania serwerów 4‐ro procesorowych (x86) i serwerów o większej liczbie procesorów (x86)). SERW_03 Dostarczone rozwiązanie serwerowe nie może zajmować więcej przestrzeni w szafach Wymagalne technicznych jak 24 RU SERW_04 Każdy z serwerów (kaseta) musi posiadać możliwość komunikacji w ramach sieci SAN w Wymagalne postaci min dwóch portów 8GbFC. Porty SAN muszą być wyprowadzone z obudowy za pomocą przełącznika SAN wyposażonego w przynajmniej 8 portów zewnętrznych 8 GbFC każdy. Ilość przełączników SAN (przynajmniej 2) oraz sposób ich konfiguracji musi zapewniać redundancję podłączenia każdego z serwerów do sieci SAN tak, aby awaria portu w serwerze lub przełącznika nie spowodowała przerwy w pracy Systemu SERW_05 Każdy z serwerów (kaseta) musi posiadać możliwość komunikacji w ramach sieci LAN w Wymagalne postaci min dwóch portów 10GbE (każdy z portów 10GbE musi pozwalać na wykreowanie min. 4 portów wirtualnych (widzianych przez system operacyjny jako porty fizyczne)). Porty LAN myszą być wyprowadzone z obudowy za pomocą przełącznika LAN wyposażonego w przynajmniej 4 porty zewnętrzne 10 GbE każdy. Ilość przełączników LAN (przynajmniej 2) oraz sposób ich konfiguracji musi zapewniać redundancję podłączenia każdego z serwerów do sieci LAN tak, aby awaria portu w serwerze lub przełącznika nie spowodowała przerwy w pracy Systemu. Przełączniki muszą wspierać technologię VLAN (przynajmniej 256 sieci). SERW_06 System serwerowy musi być wyposażony w układ zasilania nadmiarowego. Układ Wymagalne zasilaczy musi zapewniać poprawną pracę urządzenia w przypadku awarii połowy z nich Strona 218 z 285
lub w przypadku awarii/odłączenia z przyczyn technicznych /konserwacyjnych jednego ze źródeł zasilania. Niezależnie od ilości zastosowanych kaset serwerowych, każda z dostarczonych obudów na kasety musi być wyposażona w komplet (ilość maksymalną przewidzianą przez Producenta) zasilaczy oraz wentylatorów. SERW_07 System serwerowy musi być zasilany jednofazowo z sieci prądu zmiennego 230V 50Hz, z Wymagalne dwóch niezależnych źródeł zasilania i pracować poprawnie przy czasowym braku jednego z nich. SERW_08 System serwerowy musi być wyposażony w system zarządzania i monitoringu działający Wymagalne poniżej systemu operacyjnego. SERW_09 Serwery muszą być certyfikowane (posiadać na oficjalnej liście wsparcia) wszystkie Wymagalne systemy operacyjne oraz narzędzia do wirtualizacji z jakich zamierza korzystać Dostawca. Tabela 29. Wymagania dotyczące serwerów 4.1.3.2
Macierz dyskowa
Zamawiający wymaga dostarczenia zasobów dyskowych w postaci macierzy dyskowej spełniającej wymagania wydajnościowe i pojemnościowe Systemu. Dostawca Systemu będzie zobowiązany do wykonania skalowania (określenia wymaganych zasobów w celu spełnienia wymagań wydajnościowych i pojemnościowych) we własnym zakresie, jednak niezależnie od uzyskanych wyników skalowania musi dostarczyć jedną macierz dyskową spełniającą wymagania minimalne OPZ. Jeżeli Dostawca Systemu uzna, iż dla realizacji Systemu potrzebna jest macierz o większej pojemności wówczas w dalszym ciągu dostarczy jedną macierz zgodną z poniższym opisem, ale o odpowiednio większej pojemności. NR
Wymaganie
Kategoria wymagania
MACR_01 Dostarczona macierz dyskowa musi posiadać przestrzeń dla danych min 30 TB (przestrzeni Wymagalne RAW). Przestrzeń dyskowa musi być realizowana w oparciu o dyski SAS lub FC o prędkości obrotowej nie mniejszej jak 15k RPM (nie dotyczy SSD) oraz pojemności nie większej jak 600 GB. MACR_02 Macierz musi być rozwiązaniem redundantnym wyposażonym w nadmiarowy (przynajmniej Wymagalne 2) układ kontrolerów, zasilaczy i wentylatorów. MACR_03 Macierz musi być wyposażona w przynajmniej 2 porty FC 8 GbE per kontroler oraz Wymagalne przynajmniej 24 GB pamięci cache (łącznie). MACR_04 System pamięci masowej musi być wyposażony w układ zasilania nadmiarowego. Układ Wymagalne zasilaczy musi zapewniać poprawną pracę urządzenia w przypadku awarii połowy z nich lub w przypadku awarii/odłączenia z przyczyn technicznych /konserwacyjnych jednego ze źródeł zasilania. MACR_05 System pamięci masowej musi być zasilany jednofazowo z sieci prądu zmiennego 230V Wymagalne 50Hz, z dwóch niezależnych źródeł zasilania i pracować poprawnie przy czasowym braku jednego z nich MACR_06 Macierz musi wspierać poziomy RAID przynajmniej dla typów 0,1,5,6. MACR_07 Macierz musi być dostarczona z kompletem licencji pozwalających na wdrożenie Wymagalne rozwiązania Wymagalne Tabela 30. Wymagania dotyczące macierzy dyskowej Strona 219 z 285
4.1.3.3
Biblioteka taśmowa (1szt.)
Zamawiający na potrzeby systemu kopii zapasowych wymaga dostarczenia biblioteki taśmowej. Dostawca Systemu będzie zobowiązany do wykonania skalowania (określenia wymaganych zasobów w celu spełnienia wymagań wydajnościowych i pojemnościowych) we własnym zakresie, jednak niezależnie od uzyskanych wyników skalowania musi dostarczyć bibliotekę taśmową spełniającą wymagania minimalne OPZ. Jeżeli Dostawca Systemu uzna, iż dla realizacji Systemu potrzebna jest biblioteka o większej pojemności lub z większą ilością napędów wówczas w dalszym ciągu dostarczy jedną bibliotekę zgodną z poniższym opisem, ale o odpowiednio większej pojemności i większej liczbie napędów. NR
Wymaganie
Kategoria wymagania
BIBL_01 Biblioteka taśmowa musi być wyposażona w przynajmniej dwa napędy taśmowe o prędkości Wymagalne przesyłu danych min. 1,4 TB/h (liczone dla pojedynczego napędu) pracujące jednocześnie. BIBL_02 Biblioteka musi mieć możliwość rozbudowy do min 4 napędów. BIBL_03 Bibliotek musi być wyposażona w interfejsy FC 8Gb (przynajmniej 2 na każdy napęd Wymagalne taśmowy). BIBL_04 Biblioteka musi posiadać przynajmniej 48 slotów na kasety (Dostawca Systemu dostarczy Wymagalne kasety zgodne z oferowanym napędem w ilości wymaganej dla obsadzenia wszystkich wolnych slotów z uwzględnieniem taśmy czyszczącej). BIBL_05 Biblioteka taśmowa musi być wyposażony w układ zasilania nadmiarowego. Układ zasilaczy Wymagalne musi zapewniać poprawną pracę urządzenia w przypadku awarii połowy z nich lub w przypadku awarii/odłączenia z przyczyn technicznych /konserwacyjnych jednego ze źródeł zasilania. BIBL_06 Biblioteka taśmowa musi być zasilana jednofazowo z sieci prądu zmiennego 230V 50Hz, z Wymagalne dwóch niezależnych źródeł zasilania i pracować poprawnie przy czasowym braku jednego z nich Wymagalne Tabela 31. Wymagania dotyczące biblioteki taśmowej 4.1.3.4
Przełączniki 10 GbE
W ramach doposażenia infrastruktury LAN (Data Center) Dostawca Systemu dostarczy dwa przełączniki spełniające wymagania minimalne: Identyfikator
Wymaganie
Kategoria wymagania
SWLN_01 Min. 16 portów 1/10GbE definiowanych za pomocą wkładek SFP+/SFP. Wymagalne SWLN_02 Wydajność matrycy przełączającej pozwalająca na pracę jednoczesną wszystkich portów Wymagalne z pełną szybkością. SWLN_03 Wsparcie dla mechanizmów/protokołów: VLAN, QoS, SNMPv3, STP. Wymagalne SWLN_04 Nadmiarowy układ wentylatorów. Wymagalne SWLN_05 Układ zasilania nadmiarowego. Układ zasilaczy musi zapewniać poprawną pracę Wymagalne urządzenia w przypadku awarii połowy z nich lub w przypadku awarii/odłączenia z przyczyn technicznych /konserwacyjnych jednego ze źródeł zasilania. SWLN_06 Przełącznik musi być zasilany jednofazowo z sieci prądu zmiennego 230V 50Hz, z dwóch Wymagalne niezależnych źródeł zasilania i pracować poprawnie przy czasowym braku jednego z nich Strona 220 z 285
SWLN_07 Przełącznik musi współpracować z rozwiązaniami posiadanymi przez Zamawiającego w Wymagalne zakresie uwierzytelniania i autoryzacji ‐ Cisco ACS (w zakresie protokołów TACACS+ i RADIUS). Tabela 32. Wymagania dotyczące przełączników 4.1.3.5
Inne elementy
Dostawca Systemu w ramach wdrożenia Systemu dostarczy i zainstaluje wszelkie inne elementy sprzętowo‐
programowe konieczne do uruchomienia oraz optymalnego funkcjonowania rozwiązania, a w szczególności: a) Szafy techniczne (2 szt.) z panelami wentylacyjnymi oraz z niezbędnym wyposażeniem (panele krosownicze, listwy zasilające itp.), aby podłączyć wszystkie zainstalowane urządzenia, b) Okablowanie połączeniowe (światłowodowe i miedziane) w zakresie podłączenia nowych elementów dostarczonych przez Dostawcę do obecnej infrastruktury, c) Wkładki interfejsów (np.: moduły SFP) w ilości i rodzaju niezbędnym do wykonania wszystkich połączeń w układzie redundantnym, d) O ile będzie to konieczne rozbuduje system klimatyzacji. Z uwagi na obecnie zainstalowane urządzenia chłodzące, a w szczególności brak miejsca na instalację nowych wymienników ciepła konieczny jest demontaż jednej z zainstalowanych jednostek i zastąpienie jej jednostką o większej mocy. Wykonawca jako nowe rozwiązanie zastosuje system VRF z dwoma jednostkami kasetonowymi wewnętrznymi o mocy 14kW każda oraz jedną jednostką zewnętrzną na dachu budynku o mocy chłodniczej 28 kW z wyrzutem powietrza do góry. W celu uzyskania miejsca na nowe urządzenia Wykonawca zdemontuje jedną z istniejących jednostek typu split o mocy 14 kW z sali i dachu budynku. Nowe jednostki muszą spełniać/posiadać parametry/funkcjonalności: 
sygnały cyfrowe do systemu BMS (stan pracy, stan alarmu, sygnał zewnętrzny załączenia). 
Jednostka zewnętrzna: 

Moc cieplna min 28 kW 
Współczynnik efektywności energetycznej (EER) ‐ 4,12 lub lepszy 
Zasilanie 380V/50Hz 
Wydajność wentylatora (m3/min) – min 140 
Wymiary(mm), (szer/wys/gł) ‐ max 885/1700/770 
Waga (kg) – max 190 
Zakres temperatury pracy (chłodzenie) (C) – (‐15 do 45) Jednostka wewnętrzna: 
Moc cieplna min 14 kW 
Zasilanie 220V/50Hz 
Wydajność wentylatora (m3/min) – min 29 
Poziom ciśnienia akustycznego na najwyższym biegu wentylatora (dB(A)) – max 45 
Waga (kg) – max 19 
Pompa skroplin – wbudowana Ponad powyższe Wykonawca dostarczy wszelkie niezbędne elementy konieczne do prawidłowego montażu i uruchomienia klimatyzatorów. Strona 221 z 285
e) Wszelkie inne elementy techniczne niezbędne do instalacji oraz prawidłowego działania Systemu. 4.1.4
Miejsce instalacji infrastruktury
Dostarczane w ramach wdrożenia Systemu Urządzenia będą zainstalowane w siedzibie Polskiej Agencji Żeglugi Powietrznej przy ul. Wieżowej 8, 02‐147 Warszawa, lub w razie konieczności w innych lokalizacjach należących do PAŻP lub będących w dyspozycji PAŻP, które zostaną wskazane w trakcie realizacji projektu. Szczegółowe miejsce instalacji każdego z elementów infrastruktury sprzętowej zostanie ustalone w etapie 5.1 i wpisane do Projektu Technicznego. 4.2
4.2.1
Wymagania do Oprogramowania Standardowego
Wymagania ogólne
Zamawiający wymaga, aby zakres nabywanych przez Zamawiającego licencji, w szczególności w zakresie nabywanych funkcjonalności oraz liczby użytkowników, był wystarczający do wykonania i korzystania z Systemu, bez dodatkowych kosztów po stronie Zamawiającego. Dostawca Systemu dostarczy Zamawiającemu warunki licencyjne Oprogramowania Standardowego najpóźniej w dniu dostarczenia Oprogramowania Standardowego. Zamawiający wymaga, aby licencje Oprogramowania Standardowego: a) były nieograniczone czasowo i terytorialnie, b) były przenaszalne (niezwiązane ze sprzętem), c) pokrywały całość „stosu technologicznego” Systemu (tj. zapewniały poprawną pracę Systemu we wszystkich warstwach – danych, aplikacji i prezentacji) oraz zapewniały funkcjonowanie kompatybilnego z systemem środowiska (systemy operacyjne, zapewnienie bezpieczeństwa, kopii zapasowych, redundancji, etc) zgodnie z wymaganiami niniejszego Opisu Przedmiotu Zamówienia. 4.2.2
Oprogramowanie Aplikacyjne
Zamawiający wymaga, aby licencje Oprogramowania Aplikacyjnego: a) zapewniały poprawną pracę w poszczególnych modułach systemu liczby użytkowników wskazanej w niniejszym Opisie Przedmiotu Zamówienia, b) gwarantowały poprawną współpracę pomiędzy poszczególnymi komponentami systemu. 4.2.3
Systemy operacyjne
Dostawca dostarczy serwerowe systemy operacyjne w ilości i rodzaju niezbędnym do realizacji projektu, kompatybilne z Oprogramowaniem Aplikacyjnym oraz oferowanym sprzętem (znajdujące się na oficjalnych listach certyfikacyjnych/kompatybilności). 4.2.4
Bazy danych, serwery aplikacji i inne
Dostawca Systemu dostarczy oprogramowanie bazodanowe i serwerów aplikacji w ilości i rodzaju niezbędnym do realizacji projektu, kompatybilne z oprogramowaniem aplikacyjnym oraz oferowanym sprzętem (znajdujące się na oficjalnych listach certyfikacyjnych/kompatybilności). Strona 222 z 285
Dostawca Systemu dostarczy oprogramowanie do wykonywania kopii zapasowych obsługujące wszystkie systemy operacyjne stosowane w ramach Systemu, dostarczoną bibliotekę taśmową oraz pozwala na wykonywanie kopii wszystkich elementów Systemu. Dostawca Systemu dostarczy oprogramowanie do monitorowania oraz zarządzania dostarczonymi elementami infrastruktury technicznej. Dostawca Systemu dostarczy także wszelkie inne Oprogramowanie Standardowe niezbędne do poprawnej realizacji wymagań zapisanych w Opisie Przedmiotu Zamówienia. 4.3
Wymagania dla
Elementów Autorskich
Oprogramowania
Autorskiego
i
Innych
Poprzez Oprogramowanie Autorskie rozumie się elementy oprogramowania wytworzone na potrzeby uruchomienia Systemu wraz z nośnikami, dokumentacją techniczną i kodami źródłowymi, do których Dostawca Systemu przenosi na Zamawiającego autorskie prawa majątkowe na warunkach opisanych w Umowie. Oprogramowaniem Autorskim mogą być w szczególności samodzielne programy komputerowe, a także nakładki, rozszerzenia, skrypty, makra, modyfikacje Oprogramowania Standardowego. Inne Elementy Autorskie to wszelkie inne produkty wytworzone przez Dostawcę Systemu w ramach Projektu, do których Dostawca Systemu przeniesie na Zamawiającego autorskie prawa majątkowe, w szczególności: plany, dokumenty zarządcze, wszelka dokumentacja, definicje raportów (o ile nie są Oprogramowaniem Autorskim), scenariusze testów, materiały szkoleniowe, instrukcje, itp. Zamawiający wymaga, aby Dostawca Systemu przeniósł na Zamawiającego autorskie prawa majątkowe do Oprogramowania Autorskiego i Innych Elementów Autorskich zgodnie z zapisami zawartymi w Umowie. 4.4
Integracja Systemu z innymi systemami
Agencja wykorzystuje moduły oprogramowania, które nie będą zastępowane przez nowy System lub są systemami zewnętrznymi użytkowanymi przez PAŻP. Wymaga to integracji nowego rozwiązania z takimi modułami lub systemami zewnętrznymi, na poziomie zapewniającym skuteczność obsługi procesów oraz spełnienie kryteriów poprawnego rozwiązania informatycznego takich jak zasada jednokrotnego wprowadzania danych, czy zasady bezpieczeństwa. Wszystkie wymienione w zestawieniu wymagań moduły mają charakter komplementarny wobec Systemu. 4.4.1
Wymagania funkcjonalne w zakresie integracji
Nr
Wymaganie
Kategoria wymagania
Kalendarze, poczta i serwisy zewnętrzne INT_001 System powinien zapewnić integrację wspólnego harmonogramu z kalendarzami w Opcjonalne systemie pocztowym. INT_002 System musi zapewnić integrację z klientem poczty wewnętrznej i zewnętrznej. INT_003 System powinien posiadać wbudowany system organizacji / kalendarza z Opcjonalne możliwością synchronizacji z programami pocztowymi.
INT_004 System powinien umożliwiać przechowywanie plików w strukturze systemu plików Opcjonalne różnych systemów. Wsparcie wymiany informacji i plików dla wszystkich procesów i funkcjonalności.
System przepustkowy INT_005 System musi zapewnić wypełnianie wniosku o wydanie przepustki w formie Wymagalne Wymagalne Strona 223 z 285
Nr
Wymaganie
Kategoria wymagania
elektronicznej bezpośrednio w systemie, przez uprawnionych użytkowników. Wniosek musi być automatycznie, wstępnie wypełniany danymi z ujednoliconej i wspólnej dla całego PAŻP bazy danych kadrowych dot. pracowników lub danymi z ujednoliconej i wspólnej dla całego PAŻP bazy danych o kontrahentach. INT_006 System musi współdziałać z systemem nadającym uprawnienia dostępu do stref Wymagalne ewidencji przepustek osobowych i samochodowych w zakresie wypełniania instrukcji przepustkowej. INT_007 W systemie musi być utworzona i będzie aktualizowana baza stref dostępu, która Wymagalne będzie wspólna dla systemu ERP i systemu przepustowego. We wnioskach o wydanie przepustki strefy dostępu musza być wybierane jako połączenie z rekordami z tej bazy. CRCO INT_008 System musi posiadać funkcjonalność umożliwiającą synchronizację istniejących Wymagalne danych kontrahentów między Systemem a rejestrem odbiorców, prowadzonym przez CRCO. Synchronizacja musi odbywać się automatycznie, przy czym zmiana danych będzie tworzyć nową wersję danych kontrahenta, w celu zachowania niezmienności danych na historycznych dokumentach, generowanych z użyciem starszych wersji danych. Zgodność platform INT_009 System powinien zapewnić możliwość wykorzystywania funkcjonalności platformy Opcjonalne e‐GIODO poprzez generowanie plików w formacie zgodnym z wymaganiami tej platformy. INT_010 System powinien posiadać interfejs w standardzie umożliwiającym współpracę z Opcjonalne SIPR (System Informatyczny Powiadamiania Ratunkowego). Tabela 33. Wymagania funkcjonalne w zakresie integracji 4.4.2
NR
Wymagania niefunkcjonalne w zakresie integracji
Wymaganie
Kategoria wymagania
NF_INT_1 System musi zapewniać nowoczesną technologię integracji ‐ rozumianą jako udostępnienie co Wymagalne najmniej następujących funkcjonalności: a) API umożliwiającego integrację, b) usług WebService udostępnianych innym systemom, c) możliwości skonfigurowania klienta usług WebService udostępnianych przez inne systemy, d) wsparcia integracji w architekturze SOA. Wymagalne NF_INT_2 System musi umożliwiać ścisłą integrację pomiędzy modułami zapewniającą wymianę danych on‐line, ich integralność oraz zasadę jednokrotnego wprowadzania do Systemu. Wymagalne NF_INT_3 System musi mieć utworzone interfejsy z poszczególnymi systemami wykorzystywanymi w służbach operacyjnych, umożliwiających przekazanie do BI/EPM (hurtownii danych) danych źródłowych niezbędnych do wyliczeń stawek oraz mierników/wskaźników, raportowania zgodnego ze specyfikacją Eurocontrol (Specification for Economic Information Disclosure V3.0 z grudnia 2012 i późniejsze/przyszłe wydania) oraz International Civil Aviation Organization (Statistic Programme: From „L” (En‐route Services Trafiic Statistics) oraz Form „K” (Air Navigation Services Financial Data). Wymagalne NF_INT_4 System musi posiadać interfejsy do aplikacji funkcjonalnych, które nie będą zastąpione lub są systemami zewnętrznymi użytkowanymi przez PAŻP, w szczególności Strona 224 z 285
NR
Wymaganie
a)
Karty flotowe. Interfejsy wymiany danych z zewnętrznym systemem dostawcy kart flotowych (aktualnie jest to ORLEN). Informacja o transakcjach zaciągana z systemu zewnętrznego na potrzeby rozrachunku z dostawcą kart flotowych oraz rozliczeń wewnętrznych. b)
e‐deklaracje. System musi współpracować z platformą e‐deklaracje w zakresie przekazywania drogą elektroniczną wszystkich deklaracji dostępnych w platformie e‐
Deklaracje, do których sporządzania jest obowiązana Agencja. c)
Płatnik. System musi współpracować z systemem Płatnik, w zakresie określonym w bloku "Ubezpieczenia ZUS (Płatnik)". d)
QUINTIQ. System musi współpracować z systemem QUINTIQ (planowanie i wykonanie czasu pracy). System zaciąga informację o planowaniu i wykonaniu harmonogramu czasu pracy, integruje kartoteki zasobów. e)
@RMS lub odpowiednik. System musi integrować się z systemami gromadzącymi dane sprzedażowe stosowanymi w PAŻP. Planuje się zastąpienie obecnie używanego systemu gromadzenia szczegółowych danych o świadczonych usługach nawigacyjnych przez inne oprogramowanie. Wycena powinna uwzględnić tylko jeden z tych programów wskazany przez Agencję na etapie analizy wdrożeniowej (etap 5.1). f)
ERKZ. System musi być zintegrowany z systemem ERKZ (Elektroniczny Raport Kierownika Zmiany – własny system ewidencji zdarzeń związanych z eksploatacją infrastruktury wspierającej działalność nawigacyjną) w zakresie potrzebnym do generowania sprawozdań analitycznych. Integracja na bazie importu‐eksportu plików płaskich. g)
System przepustkowy. System musi zapewnić wypełnianie wniosku o wydanie przepustki w formie elektronicznej bezpośrednio w systemie, przez uprawnionych użytkowników. h)
Banki. Interfejsy z dwoma wskazanymi przez Agencję systemami bankowymi w zakresie przesyłania plików transferów przelewów z aplikacji do banku oraz akceptacji wyciągów bankowych z banku do aplikacji. i)
Ponadto musi zostać wykonany interfejs zasilania danych z systemu CRCO. Kategoria wymagania
Tabela 34. Wymagania niefunkcjonalne w zakresie integracji 4.5
Wymagania dotyczące bezpieczeństwa i ochrony
NR
Wymaganie
Kategoria wymagania
NF_BEZ_1 System musi posiadać mechanizmy automatycznego tworzenia kopii zapasowych Wymagalne danych umożliwiające współpracę z zewnętrznym systemem archiwizowania. NF_BEZ_2 System musi umożliwiać codzienne wykonywanie kopii przyrostowej oraz kopii pełnej Wymagalne raz na tydzień, przy wykorzystaniu narzędzi wbudowanych w oprogramowanie. Tworzenie kopii zapasowych powinno obejmować wszystkie komponenty Systemu, aby posiadając archiwum dało się odtworzyć z niego pełnosprawny System wraz zachowaniem informacji niezbędnych do analizy poprzedniej wersji, na tej samej lub nowej (zgodnej z oryginalną) infrastrukturze przy minimalnych dodatkowych działaniach administracyjnych, ograniczonych do zmian związanych bezpośrednio z cechami infrastruktury (np. adresowanie).
Strona 225 z 285
NR
Wymaganie
Kategoria wymagania
NF_BEZ_3 Każda kopia zapasowa musi obejmować spójny stan Systemu – oprogramowania, Wymagalne konfiguracji i danych. NF_BEZ_4 Każda kopia zapasowa musi być w trakcie procesu jej tworzenia weryfikowana, czy Wymagalne uda się poprawnie odtworzyć z niej stan Systemu. NF_BEZ_5 Oprócz mechanizmów tworzenia kopii zapasowych muszą być uruchomione Wymagalne mechanizmy tworzenia logów odtwarzania bazy danych tak, aby uzyskać możliwość odtworzenia stanu Systemu. NF_BEZ_6 System musi umożliwiać wykonywanie kopii zapasowych danych bez konieczności Wymagalne wylogowania użytkowników, z możliwością odtworzenia backupu z wykonanych wcześniej kopii zapasowych. NF_BEZ_7 System musi zapewniać wykonywanie kopii zapasowej jak i odtworzenie po Wymagalne ewentualnej awarii w całości w zgodzie z reżimem dostępności Systemu. NF_BEZ_8 System musi zapewniać tworzenie dziennika audytu, w którym będą rejestrowane Wymagalne działania użytkowników oraz zdarzenia związane z bezpieczeństwem informacji. NF_BEZ_9 System musi udostępniać Administratorowi narzędzie do analizy logów pracy Wymagalne Systemu (np. śledzenia zmian w wybranych rekordach). Musi być zapewniona możliwość śledzenia (logowania) zapisów, zmian i wszelkich ruchów, operacji wykonywanych w Systemie (minimum: data, godzina, minuta, użytkownik, wartość przed zmianą, wartość po zmianie). Musi być zapewniona pełna identyfikacja osób wprowadzających i modyfikujących dane w Systemie. NF_BEZ_10 System musi rejestrować logi błędów występujących podczas pracy Systemu. NF_BEZ_11 Wymagalne Dziennik audytu musi zapewniać możliwość monitorowania następujących zdarzeń: a) Uzyskanie uprawnionego dostępu, b) Wykonanie procesu zgodnie z posiadanymi uprawnieniami (uprawnione działania), c) Wykonanie uprzywilejowanych operacji (np. korzystanie z uprzywilejowanych kont root, administrator, zatrzymanie i uruchomienie Systemu, podłączenie lub odłączenie urządzeń wejściowych, wyjściowych) d) Próba uzyskania nieuprawnionego dostępu do systemu, e) Próba wykonania nieautoryzowanych operacji, f) Alarmy systemowe i awarie. NF_BEZ_12 Dziennik audytu musi być tworzony na każdym z poziomów działania Systemu, tj. na Wymagalne poziomie systemu operacyjnego, bazy danych oraz aplikacji. NF_BEZ_13 System musi udostępniać narzędzia umożliwiające monitorowanie działań Wymagalne użytkowników w Systemie, zarówno z poziomu aplikacji jak i innych programów i narzędzi audytu (w szczególności z poziomu narzędzia serwera danych). NF_BEZ_14 System musi zapewniać możliwość monitorowania i udokumentowania historii Wymagalne czynności Administratorów i ich dostępów do zasobów. NF_BEZ_15 System musi umożliwiać bezterminowe przechowywanie logów pracy w Systemie i Wymagalne posiadać mechanizm transportowania i składowania kopii zapasowych logów Systemu w innej lokalizacji NF_BEZ_16 System musi zapewnić szyfrowane przechowywanie haseł użytkowników z mocą Wymagalne kryptograficzną przyjętą dla zastosowań cywilnych, przy czym hasło musi być przechowywane w postaci skrótu kryptograficznego w wewnętrznej bazie użytkowników lub weryfikowane w zewnętrznym źródle danych. Wymagalne Strona 226 z 285
NR
Wymaganie
Kategoria wymagania
NF_BEZ_17 System musi rejestrować dane o każdym wykonanym raporcie, w tym m.in. dane Wymagalny takie jak: typ raportu i parametry wykonania, czas i godzina wprowadzenia zlecenia oraz użytkownik zlecający wykonanie raportu. NF_BEZ_18 Wszystkie zmiany ustawień Systemu (w szczególności zmiany konfiguracji Systemu Wymagalne oraz polityki retencji) wykonywane przez Administratora systemu powinny być automatycznie rejestrowane i raportowane przez System w trybie on‐line Administratorowi bezpieczeństwa, chyba, że administrator nie ma możliwości zmian polityki retencji. NF_BEZ_19 System musi charakteryzować się elastyczną konfiguracją umożliwiającą Wymagalne dostosowanie Systemu do zmian w organizacji Zamawiającego. NF_BEZ_20 System musi zapewnić możliwość monitorowania wydajności poszczególnych Wymagalne komponentów architektury (elementów infrastruktury, platform oprogramowania, aplikacji) w sposób zautomatyzowany. System monitorujący musi umożliwiać generowanie powiadomień o przekroczeniu bezpiecznych wartości parametrów mających wpływ na działanie Systemu. Informacje o zaistniałych zagrożeniach powinny być zapisywane w logach aplikacji monitorującej. NF_BEZ_21 System musi zapewniać możliwość bezpośredniego dostępu do danych bazy danych Wymagalne przez Administratorów Systemu. NF_BEZ_22 System musi zapewniać zabezpieczenie przed awariami dzięki odpowiedniemu Wymagalne poziomowi redundancji elementów fizycznych Systemu (brak pojedynczego miejsca awarii skutkującego niedostępnością całości lub części Systemu).
NF_BEZ_23 System musi posiadać mechanizmy minimalizujące ryzyko wystąpienia Wymagalne nieprzewidzianych przerw w pracy, a w razie wystąpienia przerw minimalizujące ich rozmiar i skutki. NF_BEZ_24 Wszelkie operacje transmisji danych poza System (szczególnie za pośrednictwem Wymagalne sieci publicznych) powinny być chronione kryptograficznie – szyfrowane przy wykorzystaniu powszechnie stosowanych rozwiązań algorytmów strumieniowych (IPSec, https, sftp, VPN) z mocą kryptograficzną przyjętą dla zastosowań cywilnych. NF_BEZ_25 Awaria Systemu lub któregokolwiek z jego elementów nie może prowadzić do utraty Wymagalne danych bądź utraty integralności danych. System bazy danych musi zapewniać spójność informacji w razie awarii/zawieszenia komputera/sesji użytkownika. NF_BEZ_26 Konstrukcja Systemu musi zapewniać odporność na typowe, świadome ataki na Wymagalne System (np. DoS, DDoS). NF_BEZ_27 System musi umożliwiać niezależne uruchamianie i zarządzanie zabezpieczeniami w Wymagalne każdej z warstw (transferu danych, aplikacji). NF_BEZ_28 Mechanizm tworzenia i składowania kopii zapasowych musi dawać możliwość Wymagalne transportowania i składowania kopii zapasowych Systemu w innej lokalizacji. Strona 227 z 285
NR
Wymaganie
Kategoria wymagania
NF_BEZ_29 Wymagane jest dostarczenie dokumentacji opisującej procedury eksploatacyjne Wymagalne Systemu, w tym procedury eksploatacyjne określające szczegółowe instrukcje wykonywania zadań w odniesieniu do: a) tworzenia kopii zapasowych, b) wymagań szeregowania zadań, uwzględniających współzależności z innymi systemami, najwcześniejsze czasy rozpoczęcia i najpóźniejsze czasy zakończenia zadań, c) instrukcji obsługi błędów lub wyjątków, które mogą powstać w czasie wykonywania zadań, obejmujących także ograniczenia korzystania z narzędzi systemowych, d) procedury ponownego uruchamiania i odtwarzania Systemu na wypadek awarii, e) zarządzania śladem audytowym oraz systemowymi dziennikami zdarzeń. NF_BEZ_30 System musi zapewnić kontrolowanie zmian parametrów systemowych – Wymagalne automatyczne prowadzenie dziennika systemu. NF_BEZ_31 W przypadku wprowadzania zmian w Systemie Dostawca Systemu musi dostarczyć Wymagalne procedury przywracania Systemu do stanu sprzed zmian (na wypadek niepomyślnych zmian lub nieprzewidzianych zdarzeń).
NF_BEZ_32 Dostawca Systemu musi zapewnić, że instalacja Systemu nie będzie miała Wymagalne negatywnego wpływu na istniejące systemy, szczególnie w okresach największego obciążenia np. na koniec miesiąca Tabela 35. Wymagania niefunkcjonalne – bezpieczeństwa i ochrony Strona 228 z 285
5 Wymagania związane z zarządzaniem Projektem
5.1
Wymagania organizacyjne
Zamawiający dysponuje zorganizowaną strukturą projektową do realizacji projektu przedstawioną poniżej. Po dokonaniu wyboru Dostawcy Systemu jego zespół projektowy zostanie włączony do przestawionej struktury. Zasady pracy Rady Projektu regulują odrębne zapisy regulaminu pracy, który zostanie udostępniony po podpisaniu umowy. Projekt zorganizowany jest według poniższej struktury projektowej, opisanej w „Planie Projektu” przygotowanym przez Doradcę w oparciu o zasady realizacji projektów zgodnie z metodyką PRINCE2: Rysunek 1 Schemat struktury zespołu projektowego
Rada projektu Rada Projektu jest to ciało nadrzędne w strukturze organizacyjnej Projektu powołane Zarządzeniem Prezesa Polskiej Agencji Żeglugi Powietrznej (PAŻP). W skład Rady Projektu wchodzą przedstawiciele Zamawiającego oraz Doradcy, a po podpisaniu umowy dołączą przedstawiciele Dostawcy Systemu, upoważnione do podejmowania decyzji związanych z realizacją postanowień Umowy oraz strategią Projektu. W posiedzeniach Rady Projektu będzie uczestniczyć Kierownictwo Projektu. W posiedzeniach tych mogą brać również udział inne osoby zapraszane przez Przewodniczącego Rady Projektu. Strona 229 z 285
Kierownictwo Projektu Kierownictwo Projektu jest to zespół koordynujący i zarządzający w trybie operacyjnym i merytorycznym pracami podległych zespołów projektowych. Kierownictwo Projektu jest odpowiedzialne za realizację celów i produktów projektu. Członkowie Kierownictwa Projektu są ze sobą w stałym kontakcie. Z częstotliwością określoną w Planie Projektu Wdrożenia, a także na dzień przed posiedzeniem Rady Projektu opracowują dokument „Status projektu”. Za dostarczenie tego raportu do Rady Projektu, po uzgodnieniu go ze wszystkim członkami Kierownictwa Projektu, odpowiada Kierownik Projektu ze strony Zamawiającego. Kierownikiem Projektu ze strony Zamawiającego jest osoba wyznaczona ze strony Zamawiającego, jako odpowiedzialna za kontakty z Dostawcą Systemu oraz Doradcą, nadzór nad realizacją Przedmiotu Umowy oraz odpowiedzialna za prawidłowe wykonywanie zobowiązań Zamawiającego określonych w Umowie, w tym upoważniona do podpisywania Protokołów Odbioru Etapu i Protokołu Odbioru Końcowego. Kierownikowi Projektu ze strony Zamawiającego, podlega Zespół Projektowy, w skład którego wchodzą Koordynatorzy Projektu, odpowiadający za komunikację i bieżącą współpracę z poszczególnymi Reprezentantami i Właścicielami Obszarów, zgodnie z Zarządzeniem Prezesa PAŻP dot. powołania Zespołu Projektowego. Koordynatorzy Projektu odpowiadają za koordynację prac projektowych w obrębie przydzielonych obszarów. Ze struktur Dostawcy zostanie powołany Koordynator Dostawcy (Kierownik Projektu po stronie Dostawcy), który we współpracy z Kierownikiem Projektu PAŻP, będzie zarządzał realizacją zadań wynikających z zakresu niniejszego Zamówienia. Zespół projektowy Zespół projektowy Dostawcy zostanie podzielony na Grupy Robocze według merytorycznego zakresu prac do wykonania. Zakłada się, że każda Grupa Robocza będzie miała swojego Kierownika, nadzorującego prace danej Grupy Roboczej. Ze strony Zamawiającego funkcjonują Koordynatorzy Projektu z przydzielonymi im Obszarami (każdy obszar posiada Reprezentanta i Właściciela Obszaru), którzy mają za zadanie współpracować zarówno z Kierownikiem Projektu Zamawiającego, jak i Dostawcą, w zakresie określonym w Planie Projektu oraz koordynować i nadzorować ze strony Zamawiającego prace w przydzielonych obszarach. Koordynatorzy Projektu ze strony Zamawiającego organizują i koordynują właściwą współpracę przydzielonych Obszarów z Dostawcą Systemu. Kierownicy Grup Roboczych ze strony Dostawcy są odpowiedzialni za właściwe wykonanie prac danej Grupy Roboczej oraz za przeprowadzenie procesu uzgodnień z osobami ze strony Zamawiającego wskazanymi przez Zamawiającego przed przekazaniem produktu do formalnego odbioru Zamawiającemu. Wykonawca przedstawi Zamawiającemu skład zespołu projektowego wraz z dokumentami poświadczającymi spełnienie wymagań Zamawiającego. Skład zespołu projektowego wymaga akceptacji Zamawiającego. W czasie trwania Umowy Zamawiający ma prawo zażądać wymiany członka zespołu Wykonawcy na osobę o analogicznych kompetencjach. Strona 230 z 285
5.2
Metodyka prowadzenia Projektu
NR
Wymaganie
Kategoria wymagania
NF_JAK_1 Zamawiający realizuje Projekt zgodnie z metodyką PRINCE 2. Realizacja Umowy będzie Wymagalne odbywać się zgodnie z metodyką PRINCE2. NF_JAK_2 Opracowania procedur projektowych dot. zarządzania zmianą, jakością, ryzykiem oraz Wymagalne przygotowanie wstępnych planów projektu, testów, czy migracji muszą być zgodne z przyjętą metodyką projektową. NF_JAK_3 Modelowane procesy biznesowe oraz wymagania systemowe muszą zostać Wymagalne wprowadzone dodatkowo do narzędzia przeznaczonego do zarządzania nimi. Narzędzie to zostanie uzgodnione z Zamawiającym przed przystąpieniem do wytwarzania tej dokumentacji. Tabela 36. Wymagania niefunkcjonalne – metodyka prowadzenia Projektu 5.3
Rozpoczęcie realizacji Projektu
W ramach rozpoczęcia realizacji projektu Dostawca Systemu zobowiązany będzie do podjęcia z Kierownikiem Projektu PAŻP wszelkich ustaleń koniecznych do poprawnej realizacji projektu (etap 5.0 Projektu). Zostanie zorganizowane spotkanie otwierające projekt (tzw. kick‐off meeting). W terminie 15 dni roboczych Dostawca Systemu opracuje i przedstawi do akceptacji dokument Plan Projektu Wdrożenia, zawierający: a) Opis sposobu zarządzania projektem, b) Plan komunikacji w projekcie zawierający opisy ról w projekcie, c) Strukturę organizacyjną projektu, d) Plan jakości projektu, zawierający elementy zarządzania konfiguracją i ryzykiem, e) Szczegółowy harmonogram prac w Etapie 5.1 i ramowy harmonogram kolejnych Etapów. 5.4
Etapy realizacji Projektu
Wykonawca jest zobowiązany do: 1. Zaprojektowania, wybudowania i wdrożenia Systemu spełniającego wymagania opisane szczegółowo niniejszym dokumencie, 2. Świadczenia usług gwarancyjnych na warunkach opisanych w paragrafie 13 Istotnych Postanowień Umowy, 3. Wykonania zleconych przez Zamawiającego prac dodatkowych w wymiarze nie przekraczającym 500 dni roboczych, zlecanych formie „Wniosków o zmianę” zgodnie z wymaganiami punktu 3 ustępu 3 paragrafu 3 Istotnych Postanowień Umowy oraz ustępie 18 paragrafu 9 Istotnych Postanowień Umowy, 4. Wykonywania prac, które będą musiały być wykonywane w siedzibie Zamawiającego – wyłącznie w godzinach podstawowego czasu pracy Zamawiającego, zgodnie z Regulaminem Pracy obowiązującym u Zamawiającego, (tj. poniedziałek‐piątek 7.00‐15.00) lub innych terminach i godzinach uzgodnionych z Zamawiającym. Prace będą realizowane w następujących etapach:  Etap 5.0 – (do 15 dni roboczych od podpisania Umowy) Rozpoczęcie projektu (patrz rozdział 5.3),  Etap 5.1 – (do 6 miesięcy od podpisania Umowy) Analiza i Projekt Techniczny, których wynikiem będzie opracowanie dokumentu Projekt Techniczny, Strona 231 z 285
 Etap 5.2 – (do 8 miesięcy od podpisania Umowy) Dostawa sprzętu i licencji na Oprogramowanie Standardowe,  Etap 5.3 – (do 16 miesięcy od podpisania Umowy) Realizacja I części Systemu, zgodnie z dokumentem Projekt Techniczny, Etap ten będzie składał się z Podetapów, szczegółowo określonych w dokumencie Projekt Techniczny,  Etap 5.4 – (do 24 miesięcy od podpisania Umowy) Realizacja II części Systemu, zgodnie z dokumentem Projekt Techniczny, Etap ten będzie składał się z Podetapów, szczegółowo określonych w dokumencie Projekt Techniczny. Etap 5.0 (Rozpoczęcie projektu) będzie obejmował przygotowanie przez Dostawcę i przedstawienie do akceptacji Zamawiającego dokumentu Plan Projektu Wdrożenia, zawierającego: a) Harmonogram Projektu Wdrożenia b) szczegółowy harmonogram prac w Etapie 5.1, c) opis sposobu zarządzania Projektem, d) plan komunikacji w Projekcie zawierający opisy ról w Projekcie, e) strukturę organizacyjną Projektu, f) plan jakości zawierający elementy zarządzania konfiguracją i ryzykiem. Etap 5.1 (Analiza i Projekt Techniczny) będzie obejmował: a) Przeprowadzenie Analizy (Analizy Przedwdrożeniowej), w tym: i.
Przeprowadzenie analizy wymagań użytkowników, ii.
Przeprowadzenie analizy wymagań funkcjonalnych i niefunkcjonalnych z dokumentacji przetargowej, Uszczegółowienie ww. wymagań, iii.
iv.
Uwzględnienie nowych wymagań/zmian wymagań wynikających ze zmian przepisów prawa, v.
Przeprowadzenie analizy konfiguracji Systemu, vi.
Przeprowadzenie analizy Rozszerzeń, vii.
Przeprowadzenie analizy migracji danych, viii.
Przeprowadzenie analizy przyszłych Użytkowników Systemu i uprawnień, ix.
Przeprowadzenie analizy procesów biznesowych i opracowanie mapy docelowych procesów (mapy optymalnego z uwagi na prowadzony biznes przebiegu procesów w nowym systemie informatycznym, wraz z opisem przejścia od procesów „jakie są” do procesów docelowych). b) Opracowanie dokumentu Projekt Techniczny. Szczegółowy zakres dokumentu Projekt Techniczny określony został w ustępie 7 paragrafu 9 Istotnych Postanowień Umowy oraz w rozdziale 9 „Wymagania dotyczące dokumentacji”. Etap 5.2 będzie zawierał dostarczenie Sprzętu oraz licencji Oprogramowania Standardowego. Zakłada się, że wdrożenie Systemu w Etapie 5.3 i Etapie 5.4 będzie następowało w dwóch częściach. Szczegółowy opis zadań w ramach Etapu 5.3 i Etapu 5.4 zostanie określony w dokumencie Projekt Techniczny. Zakres ten może ulegać zmianom i przesunięciom, jednak zmiany te nie mogą powodować zmian wysokości wynagrodzenia za poszczególne Etapy przekraczających limity ustalone w ofercie Wykonawcy i Umowie. Etap 5.3 będzie obejmował realizację I części Systemu, zgodnie z dokumentem Projekt Techniczny, Etap ten będzie składał się z podetapów, szczegółowo określonych w dokumencie Projekt Techniczny. Strona 232 z 285
Proponuje się, aby uruchomienie I części Systemu obejmowało: 1. Komponent ERP w następującym zakresie: 1.1. Moduły wspólne: 1.1.1.Moduł Administratora, 1.1.2.Kartoteka kontrahentów, 1.1.3.Centralny Rejestr Umów, 1.1.4.Struktura organizacyjna, 1.1.5.Zarządzanie słownikami, 1.1.6.Raportowanie, 1.2. Moduły podsystemu Zarządzanie Personelem: 1.2.1.Kadry, 1.2.2.Płace, 1.2.3.PKZP. 1.3. Moduły podsystemu Finanse i Księgowość: 1.3.1.Rozrachunki, 1.3.2.Windykacja, 1.3.3.Podatki, 1.3.4.Środki Trwałe, 1.3.5.Księgowość, 1.4. Moduły podsystemu Zarządzanie Sprzedażą: 1.4.1.Sprzedaż usług nawigacyjnych, 1.4.2.Rejestr Lotów Zwolnionych, 1.4.3.Sprzedaż usług pozanawigacyjnych, 1.4.4.Zamówienia obce, 1.5. Moduły podsystemu Zarządzanie Zakupami: 1.5.1.Zakupy, 1.5.2.Zamówienia własne, 1.5.3.Gospodarka Magazynowa, 2. Komponent EOD w następującym zakresie: 2.1. Obsługa faktur, 2.2. Obsługa Wniosku o udzielenie zamówienia (WOUZ), 3. Komponent BI/EPM 3.1. Realizacja modelu kalkulacji baz kosztowych 4. Komponent Interfejsy – w zakresie niezbędnym do uruchomienia I części Systemu, 5. Migracja danych niezbędna do uruchomienia I części Systemu. Etap 5.4 będzie obejmował realizację II części Systemu, zgodnie z dokumentem Projekt Techniczny, Etap ten będzie składał się z Podetapów, szczegółowo określonych w dokumencie Projekt Techniczny. Proponuje się, aby uruchomienie II części Systemu obejmowało: 1. Komponent ERP w następującym zakresie: 1.1. Moduły wspólne: 1.1.1.Projekty, 1.2. Moduły podsystemu Zarządzanie Zakupami: 1.2.1.Inwestycje, 1.3. Moduły podsystemu Zarządzanie Personelem: 1.3.1.Zarządzanie personelem, Strona 233 z 285
2.
3.
4.
5.
6.
1.3.2.Rekrutacja, 1.3.3.Szkolenia, 1.3.4.Sprawy socjalne, 1.4. Moduły podsystemu Zarządzanie Majątkiem: 1.4.1.Ewidencja Nieruchomości, 1.4.2.Ewidencja Samochodów, 1.4.3.Ewidencja infrastruktury technicznej, 1.4.4.Ewidencja i Zarządzanie infrastrukturą IT, 1.4.5.Remonty i Obsługa Techniczna, Komponent EOD ‐ pozostała część, Komponent BI/EPM: 3.1. Budowa hurtowni danych, 3.2. Raportowanie, 3.3. Planowanie i prognozowanie, 3.4. Budżetowanie, Komponent Portal, Komponent Interfejsy – w zakresie niezbędnym do uruchomienia II części Systemu, Migracja danych niezbędna do uruchomienia II części systemu. Proponowany podział Harmonogramu Wdrożenia Systemu na Etapy i Podetapy: Nr Etapu 5.0 Nazwa Opis Rozpoczęcie projektu •
•
•
5.1 Analiza i Techniczny •
•
•
Projekt •
•
•
•
•
•
Główne Produkty Powołanie zespołów roboczych, Kick‐off meeting, Przygotowanie Planu Projektu Wdrożenia i Harmonogramu Projektu Wdrożenia. Przeprowadzenie analizy wymagań Uszczegółowienie ww. wymagań, Uwzględnienie nowych wymagań/zmian wymagań wynikających ze zmian przepisów prawa, Przeprowadzenie analizy konfiguracji Systemu, Przeprowadzenie analizy rozszerzeń, Przeprowadzenie analizy migracji danych, Przeprowadzenie analizy przyszłych Użytkowników Systemu i uprawnień. Opracowanie dokumentu Projekt Techniczny, uwzględniającego jego dostosowanie do potrzeb Zamawiającego (w tym projektu technicznego ERP, hurtowni danych, konfiguracji narzędzi BI/EPM, procesu transformacji danych, warstwy metadanych, projektu technicznego EOD, szczegółowego projektu migracji danych, szczegółowego projektu modelu uprawnień w Systemie, szczegółowego projektu integracji z systemami zewnętrznymi i interfejsów), Stworzenie projektu konfiguracji części gotowej, •
•
•
Plan Projektu Wdrożenia, Harmonogram Projektu Wdrożenia. Dokument Projekt Techniczny zawierający: o
wyniki prac analitycznych i rekomendacje projektowe o
wyniki prac projektowych opartych o przeprowadzoną analizę, w tym:  Projekt architektury funkcjonalnej Systemu,  Projekt realizacji wymagań funkcjonalnych (projekt konfiguracji części gotowej, projekt techniczny rozszerzeń),  Szczegółowy opis sposobu spełnienia wymagań niefunkcjonalnych,  Mapa zoptymalizowanych procesów biznesowych Zamawiającego objętych Systemem wraz z modelem procesów w notacji BPMN,  Księga raportów – obejmująca specyfikację i projekt raportów w Systemie,  Projekt architektury Strona 234 z 285
•
•
5.2 Dostawa sprzętu i licencji •
•
•
•
•
5.3 5.3.1 5.3.2 5.3.3 Stworzenie projektu technicznego rozszerzeń, Ustalenie zakresu prototypów Systemu, Konfiguracja gotowej części Systemu zgodnie z ustaleniami opisanymi w dokumencie Projekt Techniczny, Prezentacja prototypu I (tj. gotowej części Systemu skonfigurowanej zgodnie z ustaleniami wynikającymi z Analizy oraz Projektu Technicznego). Dostawa niezbędnej infrastruktury sprzętowej oraz licencji niezbędnego oprogramowania narzędziowego, Instalacja sprzętu oraz oprogramowania, Testy sprzętu. technicznej Systemu, Projekt migracji danych,1 Projekt integracji z istniejącymi systemami wraz z projektem interfejsów,  Projekt środowiska analitycznego,  Projekt modelu zasilania hurtowni danych z Systemu oraz innych zidentyfikowanych źródeł wraz z projektem procesów ETL, warstwy przejściowej,  Szczegółowy projekt modelu uprawnień w Systemie,  Zakres prototypów,
Prototyp I – standardowa wersja Systemu skonfigurowana zgodnie z ustaleniami opisanymi w dokumencie Projekt Techniczny. Dostarczone i udostępnione przez Dostawcę Systemu niezbędne elementy infrastruktury sprzętowej dla środowiska: • rozwojowego, • produkcyjnego, • testowego (wykorzystywanego również jako środowisko szkoleniowe) wraz z licencjami oprogramowania narzędziowego (bazy danych, oprogramowania ETL, narzędzia BI/EPM). 

Uruchomienie I części Uruchomienie I części Systemu Systemu Implementacja rozszerzeń I • Dostosowanie Systemu do potrzeb I część Systemu dostosowana do potrzeb części Systemu Zamawiającego w zakresie I części Systemu Zamawiającego ‐ stworzenie prototypu: • Prototyp II – wersja z wymaganymi – przygotowanie prototypu II, • Instalacja i konfiguracja w zakresie I części modyfikacjami programowymi w Systemu, zakresie I części Systemu • Prezentacja prototypu II. przedstawiona do akceptacji Zamawiającego. • Poprawnie przeniesione dane, Migracja testowa I części • Weryfikacja projektu migracji danych w • Raport z przeprowadzonej migracji, Systemu zakresie I części Systemu, • Protokoły testów (weryfikacji migracji). • Przeprowadzenie i uzgodnienie migracji w zakresie I części Systemu:  Przygotowanie skryptów migrujących,  Przygotowanie danych testowych zgodnie z ustalonymi w projekcie migracji formatami danych,  Weryfikacja danych testowych,  Wykonanie migracji testowej,  Weryfikacja i odbiór migracji testowej. Testy I części Systemu • Przygotowanie Planu Testów, Dokumenty powstające w ramach testów • Przeprowadzenie testów akceptacyjnych: funkcjonalnych, integracyjnych, użyteczności,  Przeprowadzenie testów bezpieczeństwa: • Plan Testów, funkcjonalnych, integracyjnych, 1 Projekt migracji danych musi również uwzględniać utworzenie archiwum danych, które podlegają migracji. Strona 235 z 285
• Scenariusze Testowe, użyteczności, bezpieczeństwa, • Raport z Wykonania Testów Przeprowadzenie testów Akceptacyjnych, wydajnościowych, • Protokół Testów Akceptacyjnych,  Przeprowadzenie testów rozwiązania BI/EPM (w tym testy inicjalnego Dokumenty powstające w ramach testów zasilania hurtowni danych, testy wydajnościowych: • Plan Testów, przyrostowego zasilania hurtowni • Scenariusze Testowe, danych, testy warstwy metadanych, • Raport z Wykonania Testów testy raportów) Akceptacyjnych Wydajnościowych, • Usuwanie błędów zgłoszonych w trakcie • Protokół Testów Akceptacyjnych. poszczególnych testów. • Przygotowanie Planu Szkoleń, • Plan Szkoleń, • Przygotowanie dokumentacji użytkownika, • Dokumentacja szkoleniowa, • Przygotowanie dokumentacji szkoleniowej,
• Dokumentacja użytkownika, • Przeprowadzenie szkoleń, • Protokoły potwierdzające wykonanie • Przeprowadzenie egzaminu ze szkoleń. szkoleń, • Ankiety Szkoleniowe, • Zaświadczenia dla uczestników szkoleń. • Poprawnie przeniesione dane, • Weryfikacja projektu migracji danych w zakresie I części Systemu, • Raport z przeprowadzonej migracji, • Przeprowadzenie migracji w zakresie I • Protokoły testów (weryfikacji migracji). części Systemu – migracja produkcyjna danych wymaganych do pracy w I części Systemu, • Testy migracji. • Uruchomiona produkcyjnie i odebrana • Uruchomienie produkcyjne I części I część Systemu. Systemu, • Praca równoległa w I części Systemu (praca równoległa w systemie dotychczas funkcjonującym i nowym), • Odbiór I części Systemu. • Przygotowanie dokumentacji • Dokumentacja administratora administratora, technicznej i (administratora systemowego, eksploatacyjnej. bezpieczeństwa i biznesowego), • Dokumentacja techniczna (dokumentacja infrastruktury technicznej Systemu), • Dokumentacja eksploatacyjna (procedury administracyjne), w tym:  Procedury instalacji,  Procedury archiwizacji danych,  Procedury awaryjne,  Procedury administracji Systemem. Uruchomienie II części Systemu 
5.3.4 Szkolenia Systemu 5.3.5 Migracja produkcyjna danych wymaganych do pracy w I części Systemu 5.3.6 Wdrożenie Systemu 5.3.7 Przygotowanie dokumentacji I Systemu 5.4 5.4.1 z I I części części części Uruchomienie II części Systemu Implementacja rozszerzeń II części Systemu •
•
•
5.4.2 Migracja testowa II części Systemu •
•
Dostosowanie Systemu do potrzeb II część Systemu dostosowana do potrzeb Zamawiającego w zakresie II części Zamawiającego ‐ stworzenie prototypu: • Prototyp III – wersja z wymaganymi Systemu – przygotowanie prototypu III, Instalacja i konfiguracja w zakresie II części modyfikacjami programowymi w Systemu, zakresie II części Systemu Prezentacja prototypu III. przedstawiona do akceptacji Zamawiającego. Weryfikacja projektu migracji danych w • Poprawnie przeniesione dane, zakresie II części Systemu, • Raport z przeprowadzonej migracji, Przeprowadzenie i uzgodnienie migracji w • Protokoły testów (weryfikacji migracji). zakresie II części Systemu: Strona 236 z 285


5.4.3 Testy II części Systemu 5.4.4 Testy regresyjne Systemu Przygotowanie skryptów migrujących, Przygotowanie danych testowych zgodnie z ustalonymi w projekcie migracji formatami danych,  Weryfikacja danych testowych,  Wykonanie migracji testowej,  Weryfikacja i odbiór migracji testowej. • Przygotowanie Planu Testów, • Przeprowadzenie testów:  Przeprowadzenie testów funkcjonalnych, integracyjnych, użyteczności, bezpieczeństwa,  Przeprowadzenie testów wydajnościowych, • Usuwanie błędów zgłoszonych w trakcie poszczególnych testów. •
•
•
Przygotowanie Planu Testów, Przeprowadzenie testów – przeprowadzenie testów całego Systemu (całości procesów w Systemie) w oparciu o Scenariusze Testowe wytworzone w ramach testów I i II części Systemu, Usuwanie błędów zgłoszonych w trakcie poszczególnych testów. 5.4.5 Szkolenia Systemu części •
•
•
•
•
Przygotowanie Planu Szkoleń, Przygotowanie dokumentacji użytkownika, Przygotowanie dokumentacji szkoleniowej,
Przeprowadzenie szkoleń, Przeprowadzenie egzaminu ze szkoleń. 5.4.6 Migracja produkcyjna danych wymaganych do pracy w II części Systemu •
Weryfikacja projektu migracji danych w zakresie II części Systemu, Przeprowadzenie migracji w zakresie II części Systemu – migracja produkcyjna danych wymaganych do pracy w II części Systemu, Testy migracji. Uruchomienie produkcyjne II części Systemu, Praca równoległa w II części Systemu (praca równoległa w systemie dotychczas funkcjonującym i nowym), Odbiór II części Systemu, Odbiór całego Systemu. Przygotowanie dokumentacji administratora, technicznej i 5.4.7 Wdrożenie Systemu z II II części •
•
•
•
5.4.8 Przygotowanie dokumentacji II •
•
•
części Dokumenty powstające w ramach testów funkcjonalnych, integracyjnych, użyteczności, bezpieczeństwa: • Plan Testów, • Scenariusze Testowe, • Raport z Wykonania Testów Akceptacyjnych, • Protokół Testów Akceptacyjnych, Dokumenty powstające w ramach testów wydajnościowych: • Plan Testów, • Scenariusze Testowe, • Raport z Wykonania Testów Akceptacyjnych Wydajnościowych, • Protokół Testów Akceptacyjnych.
Dokumenty powstające w ramach testów regresyjnych: • Plan Testów, • Raport z Wykonania Testów Regresyjnych, • Protokół Testów Regresyjnych, Dokumenty powstające w ramach testów regresyjnych wydajnościowych: • Plan Testów, • Raport z Wykonania Testów Regresyjnych Wydajnościowych, • Protokół Testów Regresyjnych. • Plan Szkoleń, • Dokumentacja szkoleniowa, • Dokumentacja użytkownika, • Protokoły potwierdzające wykonanie szkoleń, • Ankiety Szkoleniowe, • Zaświadczenia dla uczestników szkoleń. • Poprawnie przeniesione dane, • Raport z przeprowadzonej migracji, • Protokoły testów (weryfikacji migracji). •
•
•
Uruchomiona produkcyjnie i odebrana II część Systemu, Dokumentacja (administratora administratora systemowego, Strona 237 z 285
Systemu eksploatacyjnej •
•
•
bezpieczeństwa i biznesowego), Dokumentacja techniczna (dokumentacja infrastruktury technicznej Systemu), Dokumentacja eksploatacyjna (procedury administracyjne), w tym:  Procedury instalacji,  Procedury archiwizacji danych,  Procedury awaryjne,  Procedury administracji Systemem. Odebrany cały System. Tabela 37. Proponowany podział Harmonogramu Wdrożenia Systemu na Etapy i Podetapy Przyjęto następujące założenia (stanowiąc jedne z warunków zaakceptowania przez Zamawiającego Harmonogramu Etapów 5.3 i 5.4) dotyczące kolejności wdrażania modułów funkcjonalnych Systemu: a) Wdrożenie i uruchomienie produkcyjne modułów podsystemu Finanse i Księgowość powinno nastąpić od początku roku tak, aby możliwe było zamknięcie roku w części finansowo‐księgowej w nowym Systemie, b) Wdrożenie i uruchomienie produkcyjne tzw. „twardego HR” (tj. modułów Kadry, Płace, Sprawy socjalne,) powinno nastąpić przed wdrożeniem tzw. „miękkiego HR” (tj. modułów Zarządzanie personelem, Rekrutacja, Szkolenia), c) Razem z wdrożeniem i uruchomieniem produkcyjnym modułów podsystemu Finanse i Księgowość powinno nastąpić wdrożenie i produkcyjne uruchomienie Komponentu EOD w części dotyczącej obsługi faktur tak, aby możliwe było przeprowadzenie pełnej obsługi faktur w nowym Systemie, d) Wdrożenie i uruchomienie produkcyjne części modułów wspólnych (Moduł Administratora, Kartoteka kontrahentów, Centralny Rejestr Umów, Struktura organizacyjna, Zarządzanie słownikami, Raportowanie) powinno nastąpić od początku wdrożenia Systemu, ponieważ ich wdrożenie wymagane jest do rozpoczęcia pracy w pozostałych modułach Systemu, e) Wdrożenie i uruchomienie produkcyjne modułu Projekty (wchodzącego w skład modułów wspólnych) powinno następować równolegle z wdrożeniem modułu Inwestycje (wchodzącego w skład podsystemu Zarządzanie Zakupami), f) Wdrożenie i uruchomienie produkcyjne każdego z modułów: Ewidencja Nieruchomości, Ewidencja Samochodów, Ewidencja infrastruktury technicznej (wchodzącego w skład podsystemu Zarządzanie Majątkiem) powinno następować równolegle z wdrożeniem modułu Remonty i Obsługa Techniczna. 5.5
Informacja na temat przewidywanych zaliczek, terminów
płatności, harmonogramów płatności
Płatności będą dokonywane zgodnie z zapisami paragrafu 5 Istotnych Postanowień Umowy. Strona 238 z 285
6 Migracja danych
6.1
Proces migracji danych
Wymagane jest koordynowanie procesu migracji danych przez Dostawcę zgodnie z następującymi krokami: 1. Przygotowanie projektu migracji danych ‐ ustalenie zakresu danych do migracji, sposoby i zakres danych do poprawienia, struktury pośrednich, sposobu przekazania danych, sposobów weryfikacji i innych szczegółów potrzebnych do prawidłowej migracji wszystkich danych wymaganych przez Zamawiającego. 2. Poprawa danych w systemach źródłowych – czynność polega na manualnym lub automatycznym (za pomocą skryptów lub mechanizmów wbudowanych w system) poprawianiu danych (np.: usuwanie błędnych danych, uzupełnianie, łączenie, filtrowanie i inne). W procesie ta czynność może być powtarzana w przypadku odnalezienia niepoprawnych danych źródłowych tzn. dane są poprawiane w systemie źródłowym i ponownie dostarczane do migracji. 3. Przekazanie danych w strukturach pośrednich – czynność dotyczy przygotowania uzgodnionych na etapie 5.1 Analiza i Projekt Techniczny struktur pośrednich (np. pliki tekstowe, arkusze kalkulacyjne, baza danych, pliki xml i inne) i eksportu danych do tych struktur. 4. Poprawianie danych w strukturach pośrednich 5. Weryfikacja poprawności danych w strukturach pośrednich – weryfikacja poprawności danych w strukturach pośrednich, która w razie potrzeby, może wymagać przygotowania i zastosowania skryptów do automatycznej weryfikacji. 6. Ustalenie przyczyny błędu – w przypadku wystąpienia problemów (błędów) przy weryfikacji danych w strukturach pośrednich, ustalana jest przyczyna błędu. Jeżeli przyczyna leży w złym przeniesieniu danych do struktur pośrednich proces wraca do kroku Przekazanie danych w strukturach pośrednich. Jeżeli problem dotyczy błędu danych należy poprawić dane źródłowe i proces wraca do kroku Poprawa danych w systemach źródłowych. W przypadku błędu danych po uzgodnieniu z Zamawiającym, dopuszcza się poprawianie danych w strukturach pośrednich, wtedy proces wraca do kroku Poprawianie danych w strukturach pośrednich. 7. Przeniesienie danych do struktur docelowych – w przypadku braku stwierdzonych problemów w trakcie wstępnej weryfikacji danych w strukturach przejściowych następuje przeniesienie danych do nowego Systemu. 8. Wstępna weryfikacja poprawności zmigrowanych danych – po przeniesieniu danych wykonywana jest weryfikacja danych w strukturach docelowych. W przypadku wystąpienia problemów proces wraca do kroku Ustalenie przyczyny błędu. 9. Weryfikacja poprawności zmigrowanych danych – końcowa weryfikacja danych poprzez wykonanie testów poprawności migracji (walidacji danych po migracji). Pozytywny wynik kończy proces migracji danych, negatywny przenosi proces do kroku Ustalenie przyczyny błędu. Proces migracji danych musi uwzględniać wymagania wynikające z zakończenia procesów w starym Systemie np. przeniesienie danych księgowych w postaci bilansu otwarcia jest możliwe po zamknięciu (a przynajmniej po uzgodnieniu) ostatniego okresu księgowego w starym Systemie. Ponadto w procesie migracji muszą być uwzględnione daty rozpoczęcia pracy w nowym Systemie, narzucane przez specyfikę procesów biznesowych np. w obszarze Finansowo‐Księgowym, naturalnym momentem rozpoczęcia pracy (czasami jedynym możliwym – np. w przypadku istotnej zmiany struktury kont wynikowych) jest dzień 1 stycznia. Opisany proces migracji będzie wykonany dwukrotnie tzn.: Strona 239 z 285
a) Migracja testowa – celem migracji testowej jest przetestowanie procedur eksportu/importu danych, procedur czyszczenia, uzupełniania, agregacji danych, procedur weryfikacji danych. Migracja testowa powinna być wykonywana na pełnych danych, jednak w obszarach, w których to nie jest wskazane z uwagi na duży nakład pracy związany z przygotowaniem pełnego zakresu danych do migracji lub nie jest to możliwe (np. w przypadku danych księgowych, które wymagają zamknięcia danych w starym systemie) zakłada się, że migracja testowa będzie wykonana na reprezentatywnej próbce danych, po wcześniejszym ustaleniu z Zamawiającym b) Migracja produkcyjna– właściwa migracja, po której rozpoczyna się produkcyjną pracę w nowym Systemie. W obszarach wytypowanych podczas analizy, która będzie przeprowadzana w etapie 5.1 Projektu, może być zastosowana praca równoległa w nowym i starym systemie przez pewien czas. Zamawiający zakłada i dopuszcza możliwość migracji przyrostowej, w przypadkach, w których nie można dokonać migracji wszystkich danych przez startem produkcyjnym, nastąpiły opóźnienia w weryfikacji migracji testowej, pracy równoległej, itp. 6.2
Podział odpowiedzialności w procesie migracji
Odpowiedzialność w procesie migracji danych będzie podzielona miedzy Zamawiającym a Dostawcą w następujący sposób: 1. Poprawa danych w systemach źródłowych – za tę fazę odpowiada Zamawiający,. 2. Przekazanie danych w strukturach pośrednich ‐ za tę fazę odpowiada Dostawca. Zamawiający udostępni Dostawcy:  dane z systemu źródłowego,  dokumentację opisującą struktury danych systemu źródłowego, a jeżeli takiej nie posiada zapewni wsparcie dostawcy starego rozwiązania. W przypadku systemów, które zostały wytworzone przez PAŻP i co za tym idzie nie są dostępne w ofercie rynkowej, brak możliwości dostarczenia jednego z powyższych elementów powoduje, że Zamawiający staje się odpowiedzialnym za czynność eksportu danych z takich systemów. 3. Poprawianie danych w strukturach pośrednich – za tę fazę odpowiada Dostawca. 4. Weryfikacja poprawności danych w strukturach pośrednich ‐ za tę fazę odpowiada Dostawca. 5. Ustalenie przyczyny błędu ‐ za tę fazę odpowiada Dostawca. 6. Przeniesienie danych do struktur docelowych ‐ za tę fazę odpowiada Dostawca. 7. Wstępna weryfikacja poprawności zmigrowanych danych ‐ za tę fazę odpowiada Dostawca. 8. Weryfikacja poprawności zmigrowanych danych – za tę fazę odpowiada Zamawiający. Wymaga się, aby Dostawca Systemu dostarczył narzędzia i asystę do tej weryfikacji. Jeżeli po zakończeniu migracji i rozpoczęciu pracy produkcyjnej pojawią się wcześniej nie zidentyfikowane błędy w danych powstałe na w trakcie migracji powodujące błędne działanie systemu to, jeśli: a) błąd dotyczył danych źródłowych to odpowiedzialność za usunięcie błędu pozostanie po stronie Zamawiającego, b) migracja niepoprawnych danych wynika z błędnie działających procedur weryfikacji i przygotowania danych odpowiedzialność za usunięcie błędów spoczywa na Dostawcy. 6.3
Weryfikacja poprawności migracji danych
Metody weryfikacji danych, w krokach „Wstępna weryfikacja poprawności danych”, „Weryfikacja danych” i „Weryfikacja poprawności migrowanych danych” procesu migracji, opisanego w rozdziale 6.1, muszą być szczegółowo wyspecyfikowane przez Dostawcę Systemu w ramach Projektu Technicznego, który będzie opracowany w etapie 5.1 Projektu, dla każdego migrowanego obszaru. Dostawca Systemu musi również zaprojektować i zaimplementować narzędzia (skrypty i raporty) umożliwiające zastosowanie wyspecyfikowanych Strona 240 z 285
metod weryfikacji danych, a także przeprowadzić weryfikację zgodnie z podziałem odpowiedzialności zapisanym w podrozdziale 6.2. Wymaga się, aby Dostawca Systemu dla każdego migrowanego zbioru ustalił z Zamawiającym sposoby weryfikacji danych: 1. Szczegółowa weryfikacja zapis po zapisie, 2. Porównania przy użyciu skryptów SQL, 3. Wyrywkowa kontrola danych przez użytkowników, 4. Porównanie raportów starych systemów PAŻP oraz nowego Systemu, 5. Weryfikacja statystyczna. Poniżej krótko opisano każdy ze sposobów: 1. Szczegółowa weryfikacja zapis po zapisie Jest możliwa tylko jeżeli zbór migrowanych danych nie jest liczny i polega na porównaniu danych w starym rozwiązaniu oraz w nowym Systemie zapis po zapisie. Dla ułatwienia tego porównania Dostawca Systemu może w niektórych przypadkach przygotować zestawienia tabelaryczne danych z nowego systemu eksportowanie do arkusza kalkulacyjnego lub wydrukowane. Wtedy porównanie polega na zaznaczeniu każdego poprawnego zapisu na wydruku lub w arkuszu. 2. Porównanie skryptami SQL Weryfikacja polegająca na uruchomieniu napisanych wcześniej skryptów porównujących dane znajdujące się w nowym Systemie z danymi źródłowymi zapisanymi w tabelach przejściowych i źródłowych (o ile istnieje do nich dostęp z bazy docelowej). W takim przypadku raport niezgodności może być automatycznie wygenerowany. 3. Wyrywkowa kontrola danych przez użytkowników Weryfikacja przeprowadzana przez użytkowników docelowych Systemu, mających dostęp do nowego Systemu oraz poprzednich systemów. Polega na wyszukaniu wybranych danych w jednym i drugim systemie oraz ich porównaniu. Należy założyć odpowiednio liczną próbkę, jednak taką, dla której możliwe jest porównanie zapisów w skończonym czasie. 4. Porównanie raportów starych systemów PAŻP oraz nowego Systemu Polega na uruchomieniu i porównaniu wybranych standardowych raportów wygenerowanych z nowego Systemu oraz poprzednich systemów (np. obroty na wybranych kontach, rejestr VAT, lista płac, dane podatkowe, itp.) 5. Weryfikacja statystyczna Polega na stworzeniu kryteriów poprawności każdego migrowanego modułu oraz sposobu raportowania umożliwiającego stwierdzenie poprawności migracji, a następnie na wykonaniu weryfikacji migracji według przyjętej metody i kryteriów. 6.4
Zasady postępowania w przypadkach szczególnych
Zasady postępowania w przypadkach szczególnych dotyczą sytuacji, w której automatyczna migracja nie jest możliwa z uwagi na: a) brak elektronicznej ewidencji danych w ramach starego rozwiązania (w tym również istnienie ewidencji elektronicznej niestrukturalnej np. w ramach plików edytora teksów – MS WORD); b) ewidencja elektroniczna zawiera niekompletne zapisy lub dane o zbyt małym stopniu szczegółowości, aby możliwe było przeniesienie ich w pełni automatycznie do nowego Systemu, a nie można ich uzupełnić w starym rozwiązaniu. Strona 241 z 285
W takim przypadku przy migracji danych do nowego Systemu powinna być wykorzystana jedna z opisanych poniżej metod: 1. Zasilenie danych ręcznie przez użytkowników poprzez wpisanie ich do nowego Systemu z wykorzystaniem standardowego interfejsu użytkownika nowego rozwiązania. 2. Zasilenie danych ręcznie przez użytkowników poprzez wpisanie ich do nowego Systemu z wykorzystaniem dedykowanego dla migracji interfejsu użytkownika. Metoda ta jest wykorzystywana w przypadku, gdy standardowy interfejs uniemożliwia lub utrudnia rejestrację danych migrowanych (przykładowo oprócz wpisania danych trzeba wykonać szereg zatwierdzeń wynikających z procesu). Przy takiej metodzie Dostawca Systemu musi zapewnić wdrożenie dedykowanego dla migracji interfejsu użytkownika. 3. Przeniesienie danych niekompletnych do struktur przejściowych i zbudowanie przez Dostawcę algorytmu uzupełniającego brakujące informacje. 4. Przeniesienie danych niekompletnych do struktur przejściowych i przeniesienie ich do nowego systemu z neutralną informacją w brakujących szczegółach, a następnie umożliwienie poprawy tych neutralnych wartości albo przez użytkownika w standardowym lub dedykowanym interfejsie użytkownika lub za pomocą dedykowanych skryptów. Przy takiej metodzie Dostawca Systemu musi zapewnić wdrożenie dedykowanego dla migracji interfejsu użytkownika i/lub skryptów. 5. Przeniesienie danych niekompletnych do struktur przejściowych i uzupełnienie ich w strukturach przejściowych przez użytkownika (np. w arkuszu EXCEL lub w przejściowej bazie danych za pomocą dedykowanego dla tej bazy interfejsu użytkownika). Metody takie wskazuje Dostawca Systemu w porozumieniu z Zamawiającym. Każdorazowo wymagana jest szczegółowa analiza problemu i zgoda Zamawiającego na zastosowanie innej niż standardowa metody migracji. Przypadki szczególne to również konieczność migracji z kilku źródeł (np. w PAŻP jest to ewidencja środków trwałych). Dane w tych źródłach mogą być sprzeczne, w części mogą się dublować w części mogą się uzupełniać. W takim przypadku Dostawca Systemu musi zaproponować i uzgodnić z Zamawiającym procedury postępowania z takimi danymi obejmujące m.in.: a) dla każdej migrowanej informacji wybranie rejestru referencyjnego, którego dane będą wiodące w przypadku konfliktów, b) dla każdego rejestru opracowanie zasady jednoznacznej identyfikacji danych (wiązania danych w różnych rejestrach), c) dla każdego rejestru opracowania algorytmów ostrzegających o możliwym powieleniu danych, dla których nie da się przeprowadzić jednoznacznej identyfikacji (np. dla kontrahentów, dla których nie ma jednoznacznego identyfikatora, to powtórzenie adresu, numeru rachunku, nazwy), d) sposób raportowania, weryfikowania i poprawiania niezgodności i przypadków wątpliwych. Do czynności związanych z postępowaniem w przypadkach szczególnych opisanych w tym rozdziale mają także zastosowanie pozostałe zapisy z rozdziału 6.1 związane z procesem migracji danych. 6.5
Gwarancja dotycząca procesu migracji danych
Dostawca Systemu ponosi odpowiedzialność za poprawność danych migrowanych do nowego Systemu i jest zobowiązany bez zbędnej zwłoki usunąć wszelkie skutki wynikające z błędów migracji i dokonać naprawy danych i działania Systemu. Strona 242 z 285
6.6
Nazwa
systemu
@ARMS Lista podstawowych źródeł danych do migracji
Domyślna
metoda
dostarczenia
danych
Poprzez pliki tekstowe, pośrednią bazę danych lub bezpośrednio z bazy Czasowy zakres
migracji danych
Ilościowy
zakres
migracji
danych
Jakość
danych2
Ostatnie 5 lat 240GB Wysoka Zwalidowane operacje lotnicze obsłużone przez PAŻP Wysoka Zdarzenia w infrastrukturze CNS, a także wszystkie powiązane dane włączając m.in.:  słownik urządzeń i podzespołów  dane nie będące zdarzeniami np. przeglądy i konserwacje, działania służb technicznych  notatki i raporty z dyżurów  pliki (załączniki)  słowniki zdarzeń, działań i działów Wysoka Kontrahenci, umowy i aneksy do umów ATOM Poprzez pośrednią bazę danych Ostatnie 3 lata Około 1,5 GB, roczny przyrost 500 MB CRU Poprzez pliki tekstowe Wszystkie dane łącznie z historią Kilka tysięcy rekordów, około 1 GB Oracle EBS Zależnie od systemu docelowego Czasowy zakres danych zostanie ustalony przez Zamawiającego podczas projektu wdrożeniowego na podstawie walidacji dostępnych danych. Możliwe są dwa scenariusze: Około 270 GB wszystkie dane łącznie z danymi PPL lub tylko dane od dnia startu Systemu. Scenariusz zostanie wybrany podczas analizy przedwdrożeniowej Ogólny zakres migracji
 Dane kontrahentów pozanawigacyjnych i nawigacyjnych (w tym dane BREF)  Środki trwałe i wartości niematerialno‐prawne włączając amortyzację  Nakłady inwestycyjne Dane dot. umów z aktywnymi kontrahentami  Zamówienia sprzedaży  Dokumenty księgowe (faktury, korekty, noty, monity, PK‐i, wezwania) Wysoka 











Słownik bram FIR Polska Cenniki, stawki indeksy Porty lotnicze Słownik MPK Katalog towarów/usług Bilans otwarcia kont księgowych (w walucie podstawowej i przeliczalnej) Nierozliczone rozrachunki i płatności z kontrahentami i pracownikami Słowniki wykorzystywane przy planowaniu (np. nośniki kosztów, zasoby, działania, itp. (jeśli są.) Klasyfikacja budżetowa tradycyjna i zadaniowa Polisy Magazyn o Stany magazynowe wraz z danymi zapewniającymi prawidłową wycenę rozchodów Budżety kosztów operacyjnych z 2 Jakość danych rozumiana jako wynik subiektywnej oceny jakości danych przeznaczonych do migracji Strona 243 z 285


EPM QNT QREZUS Poprzez pliki xls Poprzez pliki tekstowe lub pośrednia baza danych Poprzez pliki tekstowe lub QUINTIQ3 bezpośrednio z bazy danych Wszystkie dane łącznie z historią Około 900 MB per model. 20 Dobra modeli historycznych. Wszystkie dane łącznie z historią Około 2,3 GB Wysoka Wszystkie dostępne dane z zakresu do migracji Około 1 GB Wysoka Rejestry AB i ABB Poprzez pliki tekstowe Wszystkie dane łącznie z historią Kilka tysięcy rekordów, około 2GB Wysoka RWZ Poprzez pliki tekstowe lub Wszystkie dane łącznie z historią Kilkanaście tysięcy Wysoka 




uwzględnieniem wszystkich segmentów konta obowiązujących na moment migracji danych Wszystkie wersje planów budżetowych Wersje planów kosztów operacyjnych z uwzględnieniem ich statusu (zamrożony, otwarty i bieżący) lub innych obowiązujących na dzień migracji danych Zasoby Działania Katalog usług (produktów) Klucze podziałowe  Tabele sprawozdawcze wyliczania podstaw kosztowych  Relacje pomiędzy powyższymi obiektami  Historyczne dane: mechanizm wyrównania ryzyka, koszt kapitału, rozliczenie roku.  Dane dot. pracowników  Dane związane z zatrudnieniem  Dane kadrowe związane z ZUS (np. kody zgłoszeń do ZUS, warunki szczególne)  Specyfikacja i definicje składników kadrowych  Struktura organizacyjna  Kartoteki wynagrodzeń i zasiłków pracowników  Składniki płacowe pracowników oraz dane informacyjne związane z wypłatą wynagrodzenia (rachunki bankowe, zajęcia wynagrodzeń, potrącenia)  Dane podatkowe i związane z ZUS  Dane związane z Bezosobowym Funduszem Płac  Dane dotyczące Pracowniczej Kasy Zapomogowo‐Pożyczkowej  Dane związane z Zakładowym Funduszem Świadczeń Socjalnych  Harmonogramy pracy służb ruchu lotniczego  Wykonane harmonogramy czasu pracy przez służby ruchu lotniczego  Zmiany dot. bezpieczeństwa  Szczegóły zmian do monitoringu (cel i wymagania bezpieczeństwa)  Zalecenia PKBWL  Niezgodności ULC  Rekomendacje  Zalecenia bezpieczeństwa  Uwagi  Załączniki  Wnioski zakupowe  Wszczęte postępowania 3 Dane systemu QUINTIQ podlegają migracji do komponentu EPM w zakresie historycznym na potrzeby analiz i metod statystycznych planowania. Ponadto dane bieżące trafiają do Systemu dzięki integracji. Strona 244 z 285
pośrednią bazę danych ERKZ Poprzez pośrednią bazę danych Microsoft Project Server Odzielne pliki Ms Project Baza środków trwałych Baza Ms Access  Pracownicy  Struktura organizacyjna rekordów, około 100‐
200 MB
Wszystkie dane historyczne. System działa od 3 lat. Dostępne pliki mpp, Agencja określi które trwające projekty zostaną przeniesione, a które pominięte. Wszystkie dane łącznie z historią Około 0,5 GB Wysoka Zgłoszenia ATM Około 200 plików mpp Dobra  Zadania i harmonogramy projektów  Dane inwestycji i projektów (w tym również harmonogram, zasoby, plany)  Załączniki Brak danych Dobra  Środki trwałe i dane powiązane Dane dotyczące kompetencyjnego opisu stanowisk pracy wraz z wszystkim powiązanymi danymi m.in.: KOSP Relacyjna baza danych w formacie paradox Plan Pliki MS Excel finansowy Wszystkie dane łącznie z historią. Około 50 MB. Zawiera 369 plików. Wysoka Dane aktualne Około 10 MB Dobra  Opisy profili stanowisk np. nazwa funkcji, organizacyjna nazwa stanowiska pracy, operacyjna nazwa stanowiska pracy, nazwa służby, kod stanowiska, miejsce w strukturze, daty (np. opracowania, uzgodnienia, zatwierdzenia, przeniesienia do archiwum), status profili, cel stanowiska, Grupa wg zaszeregowania (1,2,3) i inne  Odpowiedzialność, uprawnienia, kompetencje, wykształcenie, szkolenia, praktyka zawodowa, specjalność, znajomość jeżyka angielskiego  Ścieżki rozwoju i przypisane,  PRU,  Dodatkowe składniki wynagradzania,  Inne warunki pracy,  Zadania i czynności,  Kontakty służbowe wewnętrzne i zewnętrzne,  Uwagi Plan finansowy na lata 2014‐2019 Tabela 38. Lista podstawowych źródeł danych do migracji Ponieważ Zamawiający nie zna docelowego Systemu oferowanego przez Dostawcę powyższą listę danych do migracji należy traktować wstępnie. Wymagania jest migracja danych umożliwiająca poprawną, ergonomiczną i wydajną pracę w nowym Systemie, dlatego jeżeli w etapie 5.1 (w trakcie Analizy przedwdrożeniowej) zostanie zidentyfikowana potrzeba migracji jeszcze innych informacji niż wymienione Dostawca Systemu jest zobowiązany dokonać takiej migracji zgodnie z opisanymi procedurami. 6.7
Lista dodatkowych źródeł danych do migracji
W uzupełnieniu do podstawowych źródeł danych, zmigrowane muszą być także następujące zbiory danych, przy czym migracja może być przeprowadzona przez pracowników Zamawiającego, pod warunkiem, że Dostawca Strona 245 z 285
Systemu dostarczy narzędzia dostępne z poziomu aplikacji umożliwiające taką migrację i zapewni niezbędne wsparcie dla Zamawiającego. W przeciwnym razie za migracje poniższych zbiorów danych odpowiedzialny jest Dostawca. W Analizie przedwdrożeniowej zostanie określone, czy i które z poniższych zbiorów zostaną przeniesione, a które pozostaną w dotychczasowych systemach w celach dokumentacyjnych i dowodowych. Dodatkowe zbiory danych
Rodzaj zbioru
Dane ewidencyjne i opisowe budynków i budowli Ms Excel Harmonogram przeglądów innych niż infrastruktury CNS Ms Excel Harmonogram remontów innych niż infrastruktury CNS Ms Excel Umowy związane z remontami i przeglądami innymi niż infrastruktury CNS Ms Excel Dane ewidencyjne nieruchomości i wyposażenia Ms Excel Umowy związane z eksploatacją nieruchomości Ms Excel Dane ewidencyjne pojazdów i wyposażenia Ms Excel Ewidencja opon Ms Excel Harmonogram przeglądów, badań technicznych, okresów ubezpieczenia. Ms Excel Umowy przekazania pojazdów pracownikom Ms Excel Protokoły zdawczo odbiorcze pojazdów Ms Excel Zestawienie egzemplarzy map przekazanych do odsprzedaży w Biurach Odpraw Załóg Ms Excel Dane o przepustowości (opóźnieniach) Pliki z EUROCONTROL Dziennik korespondencji Intranet (baza My SQL) Ewidencja dokonanych rezerwacji hotelowych i biletów lotniczych Intranet (baza My SQL) Ewidencja sprawozdań z wyjazdów zagranicznych Intranet (baza My SQL) Ewidencja wyjazdów zagranicznych i krajowych Intranet (baza My SQL) Rejestr decyzji Intranet (baza My SQL) Rejestr komunikatów Intranet (baza My SQL) Rejestr korespondencji przychodzących/ wychodzących Intranet (baza My SQL) Rejestr pełnomocnictw Intranet (baza My SQL) Rejestr pism kierowanych do Prezesa Intranet (baza My SQL) Rejestr pism okólnych Intranet (baza My SQL) Rejestr zarządzeń Intranet (baza My SQL) Zleceń prawnych Intranet (baza My SQL) Ewidencja prasy Ms Excel Rejestr faktur Ms Excel Rejestr pieczątek i wizytówek Ms Excel Rejestr umów dotyczących wykorzystania prywatnego samochodu do celów służbowych Ms Excel Rejestr ryzyk Ms Excel Plan inwestycyjny Ms Excel Dane OSL Ms Excel Tabela 39. Lista dodatkowych źródeł danych do migracji Strona 246 z 285
6.8
Pozostałe wymagania niefunkcjonalne dla migracji danych
NR
Wymaganie
Kategoria wymagania
NF_MIG_001 System musi przechowywać dane historyczne, stanowiące podstawę do wyliczeń Wymagalne długoletnich, za okres minimum 6 lat wstecz. Zakres danych analogiczny jak dane źródłowe dla wyliczeń mierników/wskaźników. Dane historyczne mogą być przechowywane w hurtowni danych. NF_MIG_002 Dostawca Systemu zapewni migrację danych z zastępowanych rozwiązań do nowego Wymagalne systemu zgodnie z wstępnym projektem migracji danych zaproponowanym przez Doradcę. Dostawca Systemu dokona migracji wszystkich danych potrzebnych do prawidłowego działania systemu. NF_MIG_003 Ponieważ nie wszystkie moduły Systemu będą uruchamiane jednocześnie proces Wymagalne migracji musi uwzględniać wzajemne powiązania danych i wszędzie tam, gdzie będzie to zasadne zaplanować migrację przyrostową. NF_MIG_004 Migracja musi być przeprowadzona w dwóch turach – najpierw migracja testowa, a po Wymagalne poprawnej weryfikacji migracji testowej migracja produkcyjna. NF_MIG_005 Dostawca Systemu ponosi odpowiedzialność za poprawność danych migrowanych do Wymagalne nowego systemu i jest zobowiązany bez zbędnej zwłoki usunąć wszelkie skutki wynikające z błędów migracji i dokonać naprawy danych i działania Systemu.
Tabela 40. Pozostałe wymagania niefunkcjonalne dla migracji danych Strona 247 z 285
7 Testy
7.1
Ogólne zasady przeprowadzania testów
7.1.1
Obszary testowania, role i odpowiedzialności
Ze względu na złożoność Systemu i konieczność zapewnienia jego stabilności, wydajności, zgodności ze zdefiniowanymi uprzednio wymaganiami użytkownika i specyfikacją, a także bezpieczeństwa zakresem testowania muszą zostać objęte w kolejności testy: a) urządzeń serwerowych b)
c)
d)
e)
integracyjne, funkcjonalne, użyteczności, regresji, f) bezpieczeństwa, g) wydajnościowe, W rozdziale tym określone zostały także zakresy odpowiedzialności po stronie Zamawiającego, Doradcy oraz Dostawcy Systemu. Podmioty te zobowiązane są do realizacji następujących podstawowych zadań: 1. Dostawca Systemu odpowiedzialny jest za: a) Zarządzanie procesem przeprowadzenia testów, b) Opracowanie dokumentacji testowej m.in. Planu testów, Scenariuszy testowych, c) Aktywny udział w testach, d) Zapewnienie na czas testów wszelkich niezbędnych narzędzi umożliwiających przeprowadzenie testów. 2. Zamawiający odpowiedzialny jest za: a) Weryfikację dokumentacji testowej dostarczonej przez Dostawcę Systemu, przy wsparciu Doradcy b) Przeprowadzenie testów przy współudziale Dostawcy, c) Zgłaszanie Niezgodności. 3. Doradca odpowiedzialny jest za: a) Aktywny udział w przeprowadzanych testach Systemu oraz nadzór nad poprawnością ich przeprowadzania, b) Ocenę scenariuszy testów dostarczonych przez Dostawcę Systemu pod kątem ich kompletności, adekwatności i wykonalności, c) Sporządzanie raportów z testów zawierających ocenę testów. Zespół testowy będą stanowić pracownicy Zamawiającego, Dostawcy Systemu oraz Doradcy. 7.1.2
Ogólne zasady przebiegu procesu testowania
W celu prawidłowego przeprowadzenia testów oprogramowania konieczne jest przeprowadzenie następujących czynności: 1. Dostawca Systemu przed rozpoczęciem testów przedstawi Zamawiającemu do akceptacji Ramowy Plan Testów, Scenariusze testowe oraz Przypadki testowe, które będą znajdować się w dokumencie Projekt Techniczny. Strona 248 z 285
2. Poszczególne testy zostaną wykonane zgodnie z Planem Testów dla danego Obszaru Testowania, przygotowanym na podstawie Ramowego Planu Testów wchodzącego w skład dokumentu Projekt Techniczny (w zgodzie z zawartą tam metodyką) i przy użyciu narzędzi do przeprowadzenia testów, weryfikujących spełnienie wymagań opisanych w Projekcie Technicznym. 3. W Ramowym Planie Testów w Projekcie Technicznym ‐ w ramach opisu szczegółowej metodyki przeprowadzenia testów, zostanie ustalona kategoryzacja błędów wynikłych w procesie testowania, a także terminy dokonywania poszczególnych czynności w procesie testowania. 4. W ramach testów funkcjonalnych dla funkcjonalności, które zostały zrealizowane z wykorzystaniem elementów wykraczających poza Oprogramowanie Standardowe przeprowadzone zostaną testy użyteczności, których celem jest ocena dostosowywanego fragmentu Systemu pod względem ergonomii, obsługi systemu, jego przejrzystości oraz intuicyjnej obsługi. 5. Testy będą polegały na przeprowadzeniu Scenariuszy testowych. 6. Każdy Scenariusz zostanie podzielony na przypadki i kroki testowe. Przypadek testowy zakończy się wynikiem pozytywnym, gdy zostanie osiągnięty założony w nim cel, oraz gdy podczas jego wykonywania nie wystąpią błędy. Scenariusz testowy zostanie zakończony pozytywnie, gdy wszystkie przypadki testowe zakończą się wynikiem pozytywnym. 7. Kryterium pozytywnego zakończenia testów jest 100% uzgodnionych Scenariuszy testowych zakończonych wynikiem pozytywnym (brak jakichkolwiek błędów). 8. Każda faza testów będzie składała się z iteracji, pomiędzy którymi Dostawca Systemu będzie dokonywał poprawek błędów wykrytych w trakcie iteracji: a) Pierwsza iteracja będzie polegała na przeprowadzeniu wszystkich uzgodnionych przypadków testowych z wyłączeniem tych, których przeprowadzenie nie będzie możliwe ze względu na występujące błędy; b) Kolejna iteracja odbędzie się, jeśli w poprzedniej iteracji zostały wykryte błędy i będzie polegała na: a.
b.
c.
weryfikacji usunięcia błędów wykrytych podczas wykonywania Scenariuszy testowych w poprzedniej iteracji, wykonaniu testów regresyjnych dla funkcjonalności, na które poprawki mogły mieć wpływ oraz przeprowadzeniu przypadków testowych, których przeprowadzenie nie było możliwe w poprzedniej iteracji ze względu na występujące błędy. 9. W celu przeprowadzenia kolejnych iteracji testów Dostawca Systemu przekazywać będzie każdorazowo do Zamawiającego nowe wydanie Oprogramowania, które nie będzie zawierało wskazanych we wcześniejszych iteracjach błędów. Przekazanie tego produktu zostanie potwierdzone podpisanym przez obie strony Protokołem zgłoszenia gotowości do odbioru. 10.Każda iteracja testów dokumentowana będzie Raportem z testów, w którym poszczególne zgłoszenia zostaną skategoryzowane zgodnie z zapisami Projektu Technicznego zasady postępowania z okolicznościami zawartymi w Raporcie z testów zostaną określone w Ramowym Planie Testów wchodzącym w skład Projektu Technicznego. 11.W przypadku braku możliwości dojścia do porozumienia w zakresie ustalenia w Raporcie z testów ostatecznej listy i rodzaju Niezgodności strony spisują Protokół rozbieżności, który podlega rozpatrzeniu przez Kierownictwo Projektu. W razie braku możliwości uzgodnienia stanowiska na poziomie Kierownictwa Projektu, ostateczną decyzję podejmuje Rada Projektu. Szczegółowa metodyka oraz terminy postępowania z okolicznościami zawartymi w Raporcie z testów, w razie wystąpienia pozycji, co do których strony maja odmienne stanowiska zostaną określone w Ramowym Planie Testów. Strona 249 z 285
12.Błąd krytyczny ujawniony w trakcie wykonywania scenariusza testowego będzie przerywał dalsze wykonywanie tego scenariusza testowego do czasu przekazania przez Dostawcę Systemu poprawki wykrytego błędu lub do czasu umożliwienia kontynuowania tego scenariusza (zastosowanie obejścia). 13.Szczegółowa procedura zgłaszania problemów zostanie ustalona przez zespół projektowy (przedstawicieli Zamawiającego, Dostawcy Systemu oraz Doradcy) w Ramowym Planie Testów. 14.Jeżeli Dostawca Systemu dysponuje systemem zgłoszeniowym, wykryte Niezgodności mogą być na bieżąco zgłaszane przez członków zespołu testowego ze strony Zamawiającego za pośrednictwem systemu zgłoszeniowego udostępnionego przez Dostawcę Systemu. Każdy Niezgodność powinna być opisana następującymi atrybutami: a) Nr Niezgodności (numer wg ustalonego klucza lub nadawany automatycznie), b) Osoba zgłaszająca, c) Data zgłoszenia, d)
e)
f)
g)
Treść Niezgodności (opis problemu), Nr scenariusza, którego dotyczy, Krok scenariusza, Kategoria zgłoszenia (wg ustalonej w Projekcie Technicznym metodyki). 15.Warunkiem wykorzystania systemu zgłoszeniowego Dostawcy Systemu do zgłaszania Niezgodności w trakcie testów jest: a) Wcześniejsze (z minimum tygodniowym wyprzedzeniem) zaprezentowanie Zamawiającemu i Doradcy systemu zgłoszeniowego, b) uzyskania zgody Zamawiającego na wykorzystanie systemu zgłoszeniowego, c) stworzenie i przekazanie Zamawiającemu przez Dostawcę Systemu jasnej i intuicyjnej dokumentacji użytkownika systemu zgłoszeniowego. d) zapewnienie dostępu do szkolenia e‐learningowego z systemu zgłoszeniowego (opcjonalne), e) zapewnienie Zamawiającemu bieżącego wsparcia merytorycznego Dostawcy Systemu oraz Doradcy w trakcie korzystania z systemu, f) zapewnienie na wniosek Zamawiającego przeszkolenia wskazanych przez Zamawiającego osób z zakresu korzystania z systemu zgłoszeniowego (Zamawiający może wnioskować o przeszkolenie maksymalnie 15 osób a maksymalny czas przeznaczony na szkolenie to 1 dzień) zakres i plan szkolenia podlegać będzie zatwierdzeniu przez Zamawiającego. 16.Z chwilą rozpoczęcia testów środowisko, na którym będą prowadzone testy bezpieczeństwa zostanie “zamrożone” co oznacza, iż do momentu zakończenia testów nie będą wprowadzane żadne modyfikacje Systemu (w szczególności testowanych elementów). Dopuszcza się możliwość zaistnienia sytuacji wyjątkowej, w której System będzie modyfikowany w czasie trwania testów, przy czym Zamawiający zostanie powiadomiony o propozycji modyfikacji i musi wyrazić zgodę na jej wykonanie. 17.Zakończenie testów zostanie udokumentowane podpisaniem Protokołu testów akceptacyjnych w momencie usunięcia wszystkich zgłoszonych przez Zamawiającego Niezgodności. 7.1.2.1
Harmonogram testów
Dostawca w dokumencie Projekt Techniczny przedstawi wszystkie proponowane Scenariusze testowe realizowane w kolejnych Podetapach w których przewidziane zostały testy, wraz ze szczegółowym harmonogramem (Ramowym Planem Testów) realizacji dla każdego z określonych rodzajów testów. Strona 250 z 285
Harmonogram uwzględni testowanie modelu biznesowego i jego wsparcia przez System pod kątem wykonalności, zgodności ze strategią, a także ograniczeniami wynikającymi z przepisów prawa. 7.1.2.2
Środowisko testowe
Dostawca Systemu ma obowiązek zapewnienia w ramach dostarczanej infrastruktury środowiska testowego potrzebnego do realizacji danego Podetapu w którym przewidziane zostały testy, które musi być identyczne jak środowisko produkcyjne. Dla testów integracyjnych, funkcjonalnych, użyteczności oraz regresji dopuszczalne jest odchylenie parametrów związanych z wydajnością oraz przestrzenią dyskową, które nie może powodować przekroczenia parametrów minimalnych wymaganych dla wdrażanego rozwiązania. Dostawca Systemu odpowiedzialny jest za kompletność infrastruktury sprzętowo‐operacyjnej, a w szczególności za: dostarczenie sprzętu, oprogramowania, licencji, instalację, konfigurację, wdrożenie i uruchomienie. Sposób licencjonowania nie może nakładać ograniczeń na liczbę oraz zakres funkcjonalności uruchamianych w środowisku testowym. Dla systemów integrowanych w ramach prac wdrożeniowych, które to systemy nie posiadają dedykowanych środowisk rozwojowych ani testowych, wymagane jest przygotowanie makiet (symulatorów) tych systemów. Makiety powinny pozwalać na przeprowadzenie testów funkcjonalnych oraz akceptacyjnych zgodnie z zdefiniowanymi w Etapie 5.1 Scenariuszami testów. Testy mogą być prowadzone z wykorzystaniem zarówno na danych rzeczywistych jak i na danych spreparowanych sztucznie, zastosowanie określonego rodzaju danych zostanie każdorazowo opisane w scenariuszu testowym. Informacje odnośnie danych (w tym: słowników oraz danych migrowanych) potrzebnych do uruchomienia środowiska testowego zamieszczone będą w dokumencie Projekt Techniczny. Wszystkie zmiany w zakresie danych środowisk testowych przeprowadzane będą przez zespół projektowy Dostawcy Systemu. Administracja środowiskiem testowym spoczywa w całości po stronie Dostawcy w trakcie wszystkich testów. 7.1.2.3
Dokumentacja testów
Wymagane jest przygotowanie następującej dokumentacji specjalistycznej: 1. Plan testów – będzie zawierać informację o terminach i przebiegu realizacji wyszczególnionych rodzajów testów. Plany Testów będą opisywać: a) specyfikację scenariuszy testowych i przypadków testowych, b) kryteria akceptacji wyników testów, c) wymagania operacyjne do przeprowadzenia testów, d) szczegółowy harmonogram testów, e) specyfikację środowisk testowych dla realizacji testów, f) specyfikację danych testowych koniecznych dla realizacji testów, g) opis ról i odpowiedzialności w procesie testowania. 2. Scenariusz testowy – będzie odzwierciedlać każdy przypadek użycia systemu uwzględniony w specyfikacji Systemu. W ramach scenariusza testowego wykonywany będzie szereg tzw. kroków sprawdzających działanie programu dla różnych wariantów wprowadzanych danych (poprawne i błędne). 3. Raport z wewnętrznego przeglądu jakości – będzie prezentować wyniki testów przeprowadzonych przez Dostawcę Systemu w jego siedzibie przy użyciu jego infrastruktury oraz wyposażenia. 4. Raport z testów – będzie zawierać co najmniej: Strona 251 z 285
a) podsumowanie przeprowadzonych testów wraz z opisem oczekiwanych rezultatów w zestawieniu z osiągniętymi wynikami, b) opis wykonanych Scenariuszy testowych oraz ich wyniki, c) zestawienie ilościowe Niezgodności oraz problemów testowych zarówno poprawionych, jak i rozwiązanych poprzez obejście oraz nierozwiązanych. W przypadku Niezgodności nierozwiązanych lub rozwiązanych poprzez obejście w dokumencie powinien znajdować się ich szczegółowy opis wraz z terminem ich rozwiązania, d) ocenę Scenariuszy testowych oraz przebiegu testów. 5. Protokół z testów wewnętrznych ‐ będzie zawierał listę przeprowadzonych przez Dostawcę Systemu Scenariuszy testowych wraz z podaniem ilości Niezgodności każdej kategorii dla każdego Scenariusza odrębnie. Przekazany materiał każdorazowo będzie dotyczył części Systemu poddawanej odbiorowi w danej turze. 6. Protokół zgłoszenia gotowości do testów – będzie zawierał listę gotowych do przeprowadzenia testów modułów/funkcjonalności zrealizowanych w ramach wymagań funkcjonalnych i niefunkcjonalnych systemu. 7. Protokół z testów – będzie sporządzany dla każdego przeprowadzonego testu na postawie Scenariusza testowego i służy dokumentowaniu przebiegu testu i jego zgodności z Planem testów oraz Scenariuszem testowym. W przypadku zaistnienia niezgodności ze wspomnianymi dokumentami należy w protokole opisać tę niezgodność, jej wpływ na przebieg testów oraz przyczynę jej zaistnienia. 8. Protokół testów akceptacyjnych – będzie zawierał listę przetestowanych i zaakceptowanych przez Zamawiającego części Systemu poddawanych odbiorowi w danej turze. 9. Protokół rozbieżności – będzie zawierał listę Niezgodności, co do których w ramach procesu oceny Raportu z testów strony nie będą w stanie uzgodnić spójnego stanowiska co do kategoryzacji Niezgodności, ich przyczyny lub innych zagadnień związanych z wynikłymi w trakcie testów problemami. Protokół rozbieżności podlegać będzie rozpatrzeniu przez Kierownictwo Projektu. W razie braku możliwości uzgodnienia stanowiska na poziomie Kierownictwa Projektu, ostateczną decyzję podejmie Rada Projektu. Projekty poszczególnych dokumentów, wchodzących w skład wyżej wymienionych grup dokumentacji, muszą zostać uzgodnione z Zamawiającym i Doradcą w ramach opracowania Projektu Technicznego i mają one stać się załącznikami do Projektu Technicznego. Powinny być one zgodne z formatami dokumentów Zintegrowanego Systemu Zarządzania Zamawiającego. Terminy dostarczenia dokumentacji będą określone w Projekcie Technicznym. 7.2
7.2.1
Obszary testowania
Testy urządzeń serwerowych
Testy akceptacyjne Urządzeń Serwerowych będą oparte o testy statyczne polegające na sprawdzeniu zgodności parametrów sprzętu z wymaganiami OPZ oraz podstawowej weryfikacji działania. 1. Rozpoczęcie testów zostanie poprzedzone zgłoszeniem sprzętu/urządzenia jako gotowego do odbioru (dostawy) z wykorzystaniem Protokołu zgłoszenia gotowości do odbioru. 2. Pracownicy Zamawiającego dokonają odbioru dostawy w terminie i miejscu określonym w Projekcie Technicznym. 3. Odbiór dostawy będzie polegał na sprawdzeniu zgodności konfiguracji fizycznej z wymaganiami OPZ, ofertą Dostawcy, zapisami Projektu Technicznego, ogólnych oględzinach stanu fizycznego urządzeń (np.: czy nie ma uszkodzeń fizycznych, mechanicznych, transportowych itp.), a także sprawdzeniu autentyczności sprzętu, daty produkcji oraz weryfikacji czy sprzęt jest nowy oraz pochodzi z autoryzowanego kanału sprzedaży producenta. Strona 252 z 285
4. W przypadku odbioru dostawy zakończonego wynikiem negatywnym Dostawca Systemu niezwłocznie usuwa braki i zgłasza urządzenia ponownie do odbioru. 5. W przypadku odbioru dostawy zakończonego wynikiem pozytywnym następuje podpisanie Protokołu odbioru urządzeń serwerowych. 6. Dostawca Systemu (w terminach zgodnych z harmonogramem zawartym w Projekcie Technicznym) przystępuje do instalacji fizycznej urządzeń oraz instalacji i konfiguracji podstawowego oprogramowania (systemy operacyjne, baza danych, aplikacje narzędziowe i inne konieczne do poprawnej pracy Systemu) – dokładna lista programów/aplikacji przewidziana podczas testów urządzeń serwerowych zostanie ustalona w ramach przygotowywania Scenariuszy testowych oraz Planu Testów i przedstawiona wraz z Projektem Technicznym Systemu. 7. Dostawca Systemu zgłasza urządzenia serwerowe jako gotowe do odbioru (testowania) instalacji i konfiguracji z wykorzystaniem Protokołu zgłoszenia gotowości do odbioru. 8. Pracownicy Zamawiającego oraz Doradcy rozpoczną testy w określonym w Projekcie Technicznym terminie po zgłoszeniu przez Dostawcę Systemu sprzętu/urządzenia jako gotowego do przeprowadzenia testów. 9. Na koniec każdego dnia testów zostanie wygenerowane (w miarę możliwości z systemu zgłoszeniowego) lub opracowane (w przypadku, gdy system zgłoszeniowy nie będzie wykorzystywany) zestawienie zgłoszonych wad i podpisane przez Kierowników zespołów testowych (po stronie Dostawcy Systemu, Doradcy i Zamawiającego). 10.Testy będą dokumentowane Raportem z testów, który będzie procedowany zgodnie z metodyką ustaloną w Ramowym Planie Testów. 11.Zakończenie testów zostanie udokumentowane podpisaniem Protokołu testów akceptacyjnych w momencie usunięcia wszystkich zgłoszonych przez Zamawiającego błędów. 7.2.2
Testy integracyjne
1. Szczegółowa procedura prowadzenia testów integracyjnych, w odniesieniu do poszczególnych integrowanych systemów, z uwzględnieniem zakresu wykorzystania interfejsów poszczególnych systemów i zakresu wykorzystania makiet (zaślepek), zostanie udokumentowana w Projekcie technicznym. 2. Testy integracyjne będą przeprowadzone przez inżynierów systemowych ze strony Dostawcy przy ewentualnym udziale administratorów ze strony Zmawiającego. 3. Realizacja testów rozpocznie się po zgłoszeniu gotowości do przeprowadzenia testów Systemu, bądź fragmentu Systemu, przez Dostawcę systemu. Zgłoszenie gotowości będzie zrealizowane przy wykorzystaniu Protokołu zgłoszenia gotowości do testów. 4. Testy rozpoczną się w następnym dniu roboczym po zgłoszeniu gotowości do testów Systemu (lub jego elementu) lub w terminie wcześniej uzgodnionym z Zamawiającym. 5. Zespół testowy będzie przeprowadzał testy zgodnie z Planem Testów oraz Scenariuszami testowymi z uwzględnieniem warunku przerwania testów opisanego niżej. 6. Na koniec każdego dnia testów zostanie wygenerowane (w miarę możliwości z systemu zgłoszeniowego) lub opracowane (w przypadku, gdy system zgłoszeniowy nie będzie wykorzystywany) zestawienie zgłoszonych Niezgodności i podpisane przez Kierowników zespołów testowych (po stronie Dostawcy Systemu, Doradcy i Zamawiającego). 7. Testy będą dokumentowane Raportem z testów, który będzie procedowany zgodnie z metodyką ustaloną w Ramowym Planie Testów.. W Raporcie z testów możliwe jest zgłoszenie przez Zamawiającego dodatkowego scenariusza testów, który po pozytywnej akceptacji Dostawcy zostanie wprowadzony do kolejnej tury testów. Strona 253 z 285
8. Raport z testów będzie procedowany zgodnie z metodyką ustaloną w Ramowym Planie Testów. Zakończenie testów zostanie udokumentowane podpisaniem Protokołu testów akceptacyjnych. Warunkiem pozytywnego odbioru testów integracyjnych jest wyeliminowanie przez Dostawcę wszystkich zgłoszonych Niezgodności. 9. Zakończenie testów może nastąpić w przypadkach, gdy: a) Testy zostają przerwane w sytuacji, gdy wystąpi zdarzenie na tyle poważne, że nie można go obejść i uniemożliwia on przeprowadzenie pozostałych zaplanowanych w Planie Testów scenariuszy, b) Testy zostają zakończone podpisaniem Protokołu testów akceptacyjnych w momencie usunięcia wszystkich zgłoszonych przez Zamawiającego błędów. Dopiero po podpisaniu takiego protokołu można zgłosić system lub jego część do odbioru. 7.2.3
Testy funkcjonalne
1. Testy funkcjonalne wykonywane będą na zasadach “czarnej skrzynki” przez osobę, która nie tworzyła aplikacji (nie zna kodu źródłowego Systemu) w oparciu o scenariusze testowe. Procedura testowa będzie poległa na podaniu zbioru danych wejściowych, a następnie na obserwacji zbioru wyjściowego i porównaniu go z pożądanym/spodziewanym (zgodnie ze scenariuszem). 2. Realizacja testów rozpocznie się po zgłoszeniu gotowości do testów Systemu, bądź fragmentu Systemu, przez Dostawcę systemu i będzie przebiegać w ten sam sposób, co testy integracyjne. Zgłoszenie gotowości będzie zrealizowane przy wykorzystaniu Protokołu zgłoszenia gotowości do odbioru. 3. Testy będą dokumentowane Raportem z testów, który będzie procedowany zgodnie z metodyką ustaloną w Ramowym Planie Testów. 4. Zakończenie testów zostanie udokumentowane podpisaniem Protokołu testów akceptacyjnych w momencie usunięcia wszystkich zgłoszonych przez Zamawiającego błędów. 7.2.4
Testy użyteczności
1. Zespół testowy rozpocznie testy w terminie określonym w Planie Testów. Zgłoszenie gotowości będzie zrealizowane przy wykorzystaniu Protokołu zgłoszenia gotowości do odbioru. 2. Testy będą przeprowadzane osobiście przez pracowników Zamawiającego w oparciu o przygotowane Scenariusze Testowe. 3. W trakcie testów użyteczności zbierane będą informacje służące m.in. do oceny systemu pod względem ergonomii obsługi systemu, jego przejrzystości oraz intuicyjnej obsługi. 4. Zamawiający otrzyma ocenę systemu wynikającą z testów użyteczności (analiza uwag Obserwatorów, ankiety wypełnione przez Testerów) i przy współpracy z Dostawcą Systemu dokona analizy wyników oraz porównania ich z parametrami użyteczności warunkującymi pozytywny wynik testów użyteczności (kryteriami odbioru). 5. Testy będą dokumentowane Raportem z testów, który będzie procedowany zgodnie z metodyką ustaloną w Ramowym Planie Testów. 6. Zakończenie testów zostanie udokumentowane podpisaniem Protokołu testów akceptacyjnych w momencie usunięcia wszystkich zgłoszonych przez Zamawiającego błędów. Strona 254 z 285
7.2.5
Testy regresji
1. Testy regresji, ze względu na swój charakter powinny być przeprowadzone po wykonaniu pozytywnych testów funkcjonalności, procesów wdrażanych w ramach danego Etapu, dla każdego Podetapu, w którym udostępniana jest nowa funkcjonalność. 2. Realizacja testów rozpocznie się po zgłoszeniu gotowości do testów Systemu, bądź fragmentu Systemu, przez Dostawcę systemu i będzie przebiegać w ten sam sposób, co testy integracyjne. Zgłoszenie gotowości będzie zrealizowane przy wykorzystaniu Protokołu zgłoszenia gotowości do odbioru. 3. Testy będą dokumentowane Raportem z testów, który będzie procedowany zgodnie z metodyką ustaloną w Ramowym Planie Testów. 4. Zakończenie testów zostanie udokumentowane podpisaniem Protokołu testów akceptacyjnych w momencie usunięcia wszystkich zgłoszonych przez Zamawiającego błędów. 7.2.6
Testy bezpieczeństwa
1. Zespół testowy rozpocznie testy w następnym dniu roboczym po zgłoszeniu przez Dostawcę Systemu (lub jego elementu) jako gotowego do przeprowadzenia testów. 2. Testy będą przeprowadzane w oparciu o Scenariusze Testowe zatwierdzone na Etapie 5.1 (Projektu Technicznego). 3. W trakcie testów bezpieczeństwa zbierane będą informacje do oceny Systemu pod kątem występowania potencjalnych błędów bezpieczeństwa spowodowanych niewłaściwą konfiguracją, lukami w oprogramowaniu lub sprzęcie, słabościami w technicznych lub proceduralnych środkach zabezpieczeń, a nawet niewystarczającą świadomością użytkowników. 4. Zamawiający otrzyma ocenę Systemu wynikającą z testów bezpieczeństwa i przy współpracy z Dostawcą Systemu dokona analizy wyników oraz porównania ich z parametrami bezpieczeństwa warunkującymi pozytywny wynik testów bezpieczeństwa (kryteriami odbioru) zatwierdzonymi w Projekcie Technicznym. 5. Testy będą dokumentowane Raportem z testów, który będzie procedowany zgodnie z metodyką ustaloną w Ramowym Planie Testów. 6. Zakończenie testów zostanie udokumentowane podpisaniem Protokołu testów akceptacyjnych w momencie usunięcia wszystkich zgłoszonych przez Zamawiającego błędów. Środowisko testowe dla testów bezpieczeństwa będzie docelowym środowiskiem produkcyjnym w związku z tym niezależnie od wyniku testów Dostawca Systemu usuwa Produkty testów (np.: wpisy bazy danych) z elementów działających produkcyjnie wdrażanego Systemu. 7.2.7
Testy wydajnościowe
Testy wydajnościowe będą polegały na dostarczeniu do Systemu, za pomocą automatów testujących dużej (jednoczesnej) ilości danych wejściowych i/lub jednoczesnym uruchomieniu wielu procesów (lub wielokrotnym jednego procesu). Bazą dla stworzenia testów wydajnościowych będą Scenariusze testowe używane podczas testów funkcjonalności. Pojedynczy test będzie się składał z kombinacji kilku Scenariuszy testowych. 1. Testy wydajności będą realizowane zgodnie z zaakceptowanym przez strony Planem testów. Zgłoszenie gotowości zostanie zrealizowane z wykorzystaniem Protokołu zgłoszenia gotowości do odbioru. 2. Na czas wykonywania testów zostanie zapewnione narzędzie i automaty testujące niezbędne do przeprowadzenia testów wydajnościowych oraz nagrane skrypty (na podstawie Scenariuszy testowych). Strona 255 z 285
3. Zespół testowy rozpocznie testy w następnym dniu roboczym od zgłoszenia przez Dostawcę Systemu (lub jego elementu) jako gotowego do przeprowadzenia testów. 4. Testy będą przeprowadzane w sposób zautomatyzowany, co oznacza, iż sam test będzie przeprowadzony przez automat testowy wykonujący nagrane wcześniej skrypty w oparciu o Scenariusze testowe. 5. W trakcie testów wydajnościowych zbierane będą statystyki, zawierające między innymi czasy odpowiedzi na zapytania przy zdefiniowanym obciążeniu. 6. Zamawiający oraz Doradca otrzymają statystyki z testów (wydruk z automatu testującego) i przy współpracy z Dostawcą Systemu dokonają analizy wyników oraz porównania ich z parametrami wydajnościowymi warunkującymi pozytywny wynik testów wydajnościowych (kryteriami odbioru). 7. Testy będą dokumentowane Raportem z testów, który będzie procedowany zgodnie z metodyką ustaloną w Ramowym Planie Testów. 8. Zakończenie testów zostanie udokumentowane podpisaniem Protokołu testów akceptacyjnych w momencie usunięcia wszystkich zgłoszonych przez Zamawiającego błędów. Środowisko testowe dla testów wydajnościowych będzie docelowym środowiskiem produkcyjnym w związku z tym niezależnie od wyniku testów Dostawca Systemu usuwa Produkty testów (np.: wpisy bazy danych) z elementów działających produkcyjnie wdrażanego Systemu. Strona 256 z 285
8 Szkolenia
8.1
Wymagania dot. przygotowania i prowadzenia szkolenia
1) Przed rozpoczęciem szkolenia (w trakcie przygotowania szkolenia) Dostawca uwzględni następujące elementy: a) Przygotowanie i przedstawienie Zamawiającemu do akceptacji przed rozpoczęciem szkoleń Planu Szkoleń zgodnego z wymaganiem NF_SZK_4 z rozdziału 8.4 . b) Przygotowanie agendy szkolenia dla uczestników i przedstawienie jej Zamawiającemu do akceptacji przed rozpoczęciem szkolenia, zgodnie z wymaganiem NF_SZK_5. c) Przekazanie materiałów szkoleniowych uczestnikom szkolenia w formie elektronicznej (w formacie .doc lub .pdf) i papierowej, zgodnie z wymaganiami NF_SZK_7 i NF_SZK_8 z rozdziału 8.4 d) Przygotowanie Systemu do szkoleń zgodnie z docelową konfiguracją uzgodnioną z Zamawiającym w trakcie Etapu 5.1 (Analiza i Projekt Techniczny), e) Przygotowanie danych do szkoleń, f) Przygotowanie kont dostępowych umożliwiających zalogowanie do Systemu dla każdego uczestnika szkolenia 2) We wstępnej części szkolenia Dostawca uwzględni następujące elementy: a) Przedstawienie się wykładowcy, b) Zapoznanie się wykładowcy z uczestnikami szkolenia, c) Ustalenie organizacji szkolenia (czas trwania, przerw), d) Omówienie celu i programu szkolenia, 3) W głównej części szkolenia Dostawca uwzględni następujące elementy: a) Wykład ‐ powinien służyć przede wszystkim wyjaśnieniu zasad pracy w danym oprogramowaniu, wyjaśnieniu pojęć oraz powinien być używany jako wstęp do ćwiczeń praktycznych, w zależności od adresatów szkolenia wykład powinien prezentować niezbędny dla osiągnięcia celu szkolenia poziom szczegółowości, b) Prezentacja multimedialna – może być wykorzystywana podczas wykładu dla podkreślenia szczególnie ważnych elementów szkolenia, c) Ćwiczenia praktyczne ‐ wszystkie omawiane na zajęciach tematy powinny być wykorzystywane w ćwiczeniach praktycznych podczas pracy na komputerze. Jest to element szkolenia, na który należy zwrócić szczególną uwagę. Ćwiczenia powinny być kontrolowane przez prowadzącego. Mogą mieć one różną formę: ćwiczenia ustalane przez wykładowcę, ćwiczenia zawarte w materiałach szkoleniowych, d) Analiza przypadku ‐ analizowanie problemu wybranego przez wykładowcę lub grupę,, e) Podsumowania materiału (po poszczególnych partiach materiału), f) Pytania i odpowiedzi ‐ wytłumaczenie wszystkich niejasności z danego tematu, przeważnie związane z podsumowaniem materiału. 4) W końcowej części szkolenia Dostawca uwzględni następujące elementy: a) Podsumowanie materiału (końcowe), b) Odpowiedzi wykładowcy na ewentualne pytania dodatkowe kursantów, c) Przeprowadzenie testu, Strona 257 z 285
d) Zebranie ankiet szkoleniowych, e) Rozdanie certyfikatów. Sprawdzanie wiadomości uczestników szkolenia będzie prowadzone dwuetapowo w następującej formie: 1. Ćwiczenia praktyczne wykonywane samodzielnie przez uczestników szkolenia i sprawdzane przez wykładowcę, 2. Test wykonywany na zakończenie szkolenia oceniany przez wykładowcę, będący podstawą wystawienia certyfikatu ukończenia szkolenia. Ocenie będzie podlegać również szkolenie i wykładowca w formie ankiety szkoleniowej wypełnianej przez uczestników na zakończenie szkolenia. 8.2
Wymagane typy szkoleń
W ramach szkoleń, które mają zostać zapewnione przez Dostawcę w ramach przedmiotu Zamówienia, zrealizowane zostaną następujące typy szkoleń: Typ szkolenia
Szkolenie danych z Certyfikat
Opis
Rodzaj
Liczba osób
do
przeszkolenia
bazy Zewnętrzny Szkolenie z zakresu administracji bazą danych, Dla Administratorów 6 obejmujące m.in.: Systemu  instalację i konfigurację bazy danych,  system uprawnień,  zarządzanie strukturami danych,  monitorowanie bezpieczeństwa i wydajności,  sposoby tworzenia kopii zapasowych i ich odtwarzania,  problemy, które mogą pojawić się w czasie użytkowania. Szkolenie z systemów Zewnętrzny Szkolenie umożliwiające zapoznanie z zasadami Dla Administratorów 6 operacyjnych działania i konfiguracji systemu operacyjnego, Systemu pozwalające na zdobycie wiedzy i umiejętności potrzebnych do codziennej pracy z systemem i udzielania wsparcia technicznego użytkownikom pracującym z tą wersją systemu. Szkolenie z Dostawcy administracji komponentem ERP Szkolenie obejmujące funkcjonalność zarządzania Dla Administratorów 27 użytkownikami i uprawnieniami oraz istotnymi Systemu parametrami konfiguracji Systemu. i Administratorów Biznesowych Szkolenie z Dostawcy administracji komponentem EOD Szkolenie z administracji komponentem EOD, obejmujące m.in.:  definiowanie ścieżek obiegu spraw,  definiowanie formularzy elektronicznych na potrzeby obiegu spraw,  zarządzanie uprawnieniami i zastępstwami,  archiwizację spraw, udostępnianie dokumentów archiwalnych.
Szkolenie z Dostawcy administracji komponentem BI/EPM Szkolenie z zakresu administracji komponentem Dla Administratorów 6 BI/EPM, obejmujące m.in.: Systemu i Administratorów  Administrację hurtownią danych, Biznesowych  Zasilanie hurtowni danych, Dla Administratorów 10 Systemu i Administratorów Biznesowych Strona 258 z 285
 Konfigurowanie warstwy metadanych,  Definiowanie raportów,  Zarządzanie uprawnieniami. Szkolenie z Dostawcy administracji Portalem Samoobsługowym Szkolenie z zakresu administracji Portalem. Dla Administratorów 10 Systemu Szkolenie z zakresu Dostawcy obsługi komponentu ERP z Szkolenie z zakresu obsługi podsystemów Dla Kluczowych Zgodnie rozdziałem 8.3 komponentu ERP, obejmujące funkcjonalności Użytkowników, przeznaczone dla Użytkowników Systemu. Architektów Biznesowych, Analityków Biznesowych oraz pozostałych Użytkowników Systemu Szkolenie z zakresu Dostawcy obsługi komponentu EOD Szkolenie z zakresu obsługi komponentu EOD, Dla Kluczowych 30 obejmujące funkcjonalności przeznaczone dla Użytkowników, Użytkowników Systemu Architektów Biznesowych, Analityków Biznesowych oraz pozostałych Użytkowników Systemu (metodą Train the trainers) Szkolenie z zakresu Dostawcy obsługi BI Szkolenie z zakresu obsługi BI, obejmujące m.in.:  Definiowanie raportów,  Udostępnianie raportów innym użytkownikom,  Eksport danych do pliku xls,  Graficzną prezentację danych, Szkolenie z zakresu Dostawcy obsługi EPM Szkolenie z zakresu obsługi planów obsługi przez Kluczowych użytkowników planów tworzonych w EPM. Użytkowników, Architektów Biznesowych, Analityków Biznesowych oraz pozostałych Użytkowników Systemu Szkolenie z zakresu Dostawcy obsługi EPM – bazy kosztowe Szkolenie z zakresu zmiany parametrów modelu bazy Dla Administratorów 6 kosztowej, np. dodanie nowego lotniska, zmiany Biznesowych przepisów dot. sprawozdawczości Szkolenie z języka SQL Dostawcy w zakresie odpowiadającym wdrażanemu Oprogramowaniu Standardowemu Szkolenie z języka SQL i jego użycia do pobierania Dla Kluczowych 30 danych z Systemu, w zakresie niezbędnym do Użytkowników, samodzielnego definiowania raportów z Systemu Architektów Biznesowych, Analityków Biznesowych Dla Kluczowych 50 Użytkowników, Architektów Biznesowych, Analityków Biznesowych oraz pozostałych Użytkowników Systemu 55 Tabela 41. Wymagalne typy szkoleń do przeprowadzenia w ramach projektu Strona 259 z 285
Gdzie poszczególne elementy tabeli oznaczają: Certyfikat – Przeszkoleni Administratorzy, Użytkownicy i trenerzy otrzymają potwierdzenie ukończenia szkolenia stwierdzające, że osiągnęli oni wiedzę niezbędną do pracy z Systemem:  Dostawcy – opisywany typ szkolenia wymaga certyfikatu wystawionego przez Dostawcę,  Zewnętrzny – opisywany typ szkolenia wymaga certyfikatu zewnętrznej instytucji certyfikującej lub certyfikatu wystawionego w imieniu zewnętrznej instytucji certyfikującej. Opis – krótki opis typu szkolenia, Rodzaj – sposób przeprowadzenia szkolenia:  Dla administratorów ‐ szkolenie dla Administratorów/Analityków/Architektów,  Dla użytkowników – szkolenie wszystkich Użytkowników,  Train the trainers – szkolenia dla trenerów, którzy będą szkolić końcowych Użytkowników Systemu. 8.3
Liczba uczestników dla komponentu ERP
W ramach obsługi komponentu ERP Dostawca przeszkoli następującą liczbę osób: Lp.
Moduł
1 Kadry 193
2 Płace 86
3 Zarządzanie personelem 4 Sprawy socjalne 303
51
5 Rekrutacja
166
6 Szkolenia 325
7 Księgowość 78
8 Rozrachunki 182
9 Podatki 10 Windykacja 11 Środki Trwałe 12 Ewidencja Nieruchomości 36
48
124
45
13 Ewidencja Samochodów (pojazdów) 42
14 Ewidencja infrastruktury technicznej 180
15 Remonty i Obsługa Techniczna
205
16 Sprzedaż usług pozanawigacyjnych 125
17 Sprzedaż usług nawigacyjnych 92
18 Rejestr Lotów Zwolnionych 13
19 Zamówienia obce 57
20 Zakupy 306
21 Zamówienia własne 243
22 Gospodarka Magazynowa 23 Inwestycje Liczba osób obsługujących
funkcjonalności modułu
84
194
Strona 260 z 285
Lp.
Moduł
Liczba osób obsługujących
funkcjonalności modułu
24 Moduł Administratora 27
25 Kartoteka kontrahentów 193
26 Centralny Rejestr Umów 231
27 Struktura organizacyjna 101
28 Zarządzanie słownikami 67
29 Projekty 187
30 Raportowanie 244
Tabela 42. Liczba osób obsługujących poszczególne moduły komponentu ERP 8.4
Pozostałe wymagania dotyczące szkoleń
NR
Wymaganie
Kategoria
wymagania
NF_SZK_1 Dostawca musi przeprowadzić szkolenia dla Administratorów Systemu, które zapewnią umiejętności i wiedzę niezbędną do samodzielnego administrowania wszystkimi modułami/elementami Systemu, środowiska Systemu i platformy sprzętowo‐
programowej. Wymagalne NF_SZK_2 Dostawca musi przeprowadzić szkolenia dla: NF_SZK_3 
Kluczowych Użytkowników Systemu, które zapewnią umiejętności i wiedzę niezbędną do właściwej i samodzielnej obsługi poszczególnych funkcjonalności Systemu oraz umiejętności potrzebne do realizacji w przyszłości szkoleń Użytkowników Systemu (szkolenia metodą train the trainers), 
Architekta Biznesowego, Analityka Biznesowego, oraz Administratora Biznesowego, zapewniające wiedzę niezbędną do poprawnego wdrożenia Systemu, a także do zarządzania rozwiązaniem po jego wdrożeniu. Szkolenia te będą rozszerzone o elementy wiedzy o biznesowym wykorzystaniu możliwości oferowanego Systemu.
Dostawca musi przeprowadzić szkolenia dla Użytkowników Systemu, które zapewnią umiejętności i wiedzę niezbędną do właściwej i samodzielnej obsługi poszczególnych funkcjonalności Systemu. Wymagalne Wymagalne Strona 261 z 285
NR
Wymaganie
NF_SZK_4 Dostawca musi przygotować i przedstawić Zamawiającemu do akceptacji minimum na dwa tygodnie przed rozpoczęciem szkoleń Plan Szkoleń zawierający: a) Konspekt szkoleń określający cele i zakres szkoleń oraz informację o osobach prowadzących szkolenie wraz z opisem ich doświadczenia, b) Parametry oceny szkoleń, w tym:  wykorzystanie Ankiety Szkoleniowej do oceny szkolenia przez uczestników,  warunki weryfikacji efektywności szkoleń i podstawy ich akceptacji. c) Metoda, forma szkoleń, d) Szablon materiałów szkoleniowych, zawierający spis treści oraz opis ćwiczeń realizowanych podczas szkoleń, ilustrujących sposób obsługi procesów w Systemie, e) Miejsce przeprowadzenia szkoleń, f) Lista uczestników szkoleń, g) Szczegółowy harmonogram szkoleń (podział na grupy, czas szkolenia, zakres i poziom szkolenia), h) Wymagania dotyczące środowiska szkoleniowego, i) Wymagania dotyczące infrastruktury szkoleniowej, j) Obowiązki Dostawcy Systemu i Zamawiającego w zakresie organizacji szkoleń, k) Forma zakończenia szkolenia (lista obecności, certyfikat wystawiony przez Dostawcę, certyfikat wystawiony przez lub w imieniu instytucji certyfikującej). Plan szkoleń podlegać będzie akceptacji Zamawiającego. Tryb zgłaszania uwag i akceptacji Planu Szkoleń musi zostać określony w Projekcie Technicznym. NF_SZK_5 Dostawca musi przygotować agendę szkolenia dla uczestników szkoleń i przedstawić ją Zamawiającemu do akceptacji przed rozpoczęciem szkoleń. NF_SZK_6 Dostawca musi przeprowadzić szkolenia w języku polskim. NF_SZK_7 Dostawca musi przygotować materiały szkoleniowe dla szkoleń użytkowników w języku polskim w oparciu o uzgodniony z Zamawiającym szablon materiałów szkoleniowych i przedstawić je do akceptacji Zamawiającego przed rozpoczęciem szkoleń. Kategoria
wymagania
Wymagalne Wymagalne Wymagalne Wymagalne Dostawca musi dostarczyć materiały szkoleniowe dla szkoleń administratorów w języku polskim. NF_SZK_8 Dostawca musi przekazać materiały szkoleniowe uczestnikom szkolenia przed rozpoczęciem szkolenia w formie elektronicznej (w formacie .doc i .pdf) i papierowej. NF_SZK_9 Dostawca musi przeprowadzić ocenę szkolenia po zakończeniu każdej sesji szkoleniowej w formie Ankiety Szkoleniowej, dostarczonej przez Dostawcę, zaakceptowanej przez Zamawiającego i wypełnianej przez uczestników szkolenia. Warunkiem odbioru danego szkolenia będzie: a) uzyskanie na podstawie Ankiet Szkoleniowych średniej oceny szkolenia co najmniej 3,75 w skali pięciopunktowej (w przypadku nie osiągnięcia wymaganej średniej Dostawca powtórzy szkolenie w terminie uzgodnionym z Zamawiającym), b) spełnienie warunków weryfikacji efektywności szkoleń i podstawy ich akceptacji określonych w Planie Szkoleń. NF_SZK_10 Dostawca musi przeprowadzić na koniec każdego szkolenia test sprawdzający wiedzę zdobytą w trakcie szkolenia (test imienny z koniecznością złożenia podpisu po zakończeniu testu), dokonać oceny prawidłowości realizacji testu oraz przekazać Zamawiającemu wyniki oceny. Wymagalne Wymagalne Wymagalne Warunkiem odbioru Etapu w skład, którego wchodzić będą szkolenia będzie uzyskanie pozytywnego wyniku z testu przez wszystkich uczestników szkoleń (w przypadku braku uzyskania wyniku pozytywnego ‐ umożliwienie uczestnikowi szkolenia powtórzenia testu w uzgodnionym terminie). Strona 262 z 285
NR
Wymaganie
NF_SZK_11 Dostawca musi przekazać każdemu uczestnikowi, który uzyska ocenę pozytywną z przeprowadzonego testu, zaświadczenie potwierdzające zdobycie wiedzy Administratora lub Użytkownika Systemu z określonego zakresu. NF_SZK_12 Dostawca musi udostępnić infrastrukturę sprzętową niezbędną do przeprowadzenia szkoleń o ile wcześniej nie zostanie zrealizowana instalacja i konfiguracja środowiska testowego u Zamawiającego. NF_SZK_13 Dostawca musi przygotować środowisko szkoleniowe w ramach środowiska testowego, dane wymagane do przeprowadzenia szkoleń. Dane szkoleniowe powinny uwzględniać specyfikę organizacji Zamawiającego. NF_SZK_14 Dostawca musi przygotować do szkoleń System zgodny z docelową konfiguracją uzgodnioną z Zamawiającym w Projekcie Technicznym. NF_SZK_15 Wszystkie szkolenia zostaną przeprowadzone w formie tradycyjnej, tzn. z wykorzystaniem Systemu i oddzielnych stanowisk szkoleniowych dla każdego z uczestników. Dopuszcza się odstępstwa od tej zasady za uprzednią zgodą Zamawiającego przy odpowiednim uzasadnieniu. W szczególności, za uprzednią zgodą Zamawiającego, dopuszcza się prowadzenie szkoleń w formie e‐learningu. NF_SZK_16 Dla szkoleń e‐learningowych Dostawca musi zapewnić Zamawiającemu dostępy do oprogramowania wykorzystywanego do przeprowadzania takich szkoleń. NF_SZK_17 Dostawca zobowiązany jest przeprowadzić szkolenia w trakcie tygodnia roboczego od poniedziałku do piątku w godzinach od 7.30 do 15.30 (nie przewiduje się możliwości przeprowadzenia szkoleń w dni ustawowo wolne od pracy lub weekendy). Dopuszcza się odstępstwa od tej zasady za uprzednią zgodą Zamawiającego przy odpowiednim uzasadnieniu. NF_SZK_18 Maksymalna liczebność grupy szkoleniowej nie może przekroczyć 20 osób. NF_SZK_19 Dostawca zapewni prowadzenie szkoleń przez wykwalifikowana kadrę. Osoby przeprowadzające szkolenia powinny posiadać co najmniej dwa lata doświadczenia w prowadzeniu szkoleń z dziedziny, do której zostały przypisane w Planie Szkoleń. Lista osób prowadzących szkolenia będzie częścią Planu Szkoleń i podlega akceptacji przez Zamawiającego. NF_SZK_20 Szkolenia certyfikowane przez Dostawcę muszą być przeprowadzone w siedzibie Zamawiającego, inne miejsca przeprowadzenia szkoleń wymagają zgody Zamawiającego. NF_SZK_21 Wykonawca ma obowiązek prowadzenia ewidencji osób, które odbyły szkolenie w formie list obecności ze wskazaniem instytucji, imienia i nazwiska oraz stanowiska służbowego danej osoby oraz wystawienia certyfikatu potwierdzającego udział w szkoleniu. NF_SZK_22 Wykonawca ma obowiązek przekazania Zamawiającemu w terminie 14 dni od daty przeprowadzenia ostatniego szkolenia, ostatecznego raportu, zawierającego pełną analizę szkoleń. Kategoria
wymagania
Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Wymagalne Tabela 43. Pozostałe wymagania dotyczące szkoleń Strona 263 z 285
9 Wymagania dotyczące dokumentacji
9.1
Rodzaje dokumentacji
Dostawca Systemu zobowiązany jest do dostarczenia następujących rodzajów dokumentacji:  Dokumentacji zarządczej,  Dokumentacji technicznej projektowej,  Dokumentacji powykonawczej,  Dokumentacji eksploatacyjnej. Projekty poszczególnych dokumentów, wchodzących w skład ww. grup dokumentacji, muszą zostać uzgodnione z Zamawiającym i Doradcą. Projekty dokumentów powinny być zgodne z formatami dokumentów ZSZ. Terminy dostarczenia dokumentacji powinny zostać określone w Harmonogramie Projektu Wdrożenia. 9.1.1
Dokumentacja zarządcza
Dokumentacja zarządcza będzie zawierała w szczególności: 1) Plan Projektu Wdrożenia– zawierający szczegółowy opis formuły realizacji projektu, w szczególności: a) Szczegółową listę Produktów planowanych do dostarczenia w ramach Zamówienia, b) Zasady współpracy, c) Plan Komunikacji, d) Opis Struktury Organizacyjnej Projektu, w szczególności ról poszczególnych osób po stronie Dostawcy ich odpowiedzialności, dane kontaktowe członków zespołu, e) Wymagania w stosunku do Zamawiającego, f) System Zarządzania Jakością, g) System Zarządzania Ryzykiem, h) System Zarządzania Zmianą, i) System Zarządzania Konfiguracją, j) zasady współpracy z Zamawiającym i Doradcą, k) szczegółowe wymagania dotyczące pozostałej dokumentacji zarządczej wytwarzanej w trakcie realizacji Projektu, l) Inne procedury konieczne do współpracy z Zamawiającym wg. Dostawcy. 2) Harmonogram Projektu Wdrożenia, 3) Szczegółowy Harmonogram każdego Etapu, 4) Rejestr Ryzyka, 5) Rejestr Zagadnień, 6) Rejestr Jakości, 7) Protokoły sporządzane w trakcie trwania Projektu. Zamawiający zastrzega, że dopuszcza połączenie części lub wszystkich wymienionych powyżej dokumentów w jeden dokument pod warunkiem zachowania zakresu merytorycznego. 9.1.2
Dokumentacja techniczna projektowa
W ramach dokumentacji technicznej powinna zostać wytworzona m.in. następująca dokumentacja: 1) Projekt Techniczny – będący wynikiem prac prowadzonych w ramach Etapu 5.1, zawierający co najmniej: Strona 264 z 285
a) Wynik analizy przedwdrożeniowej Systemu – zawierający dokumentację wymagań, która jednoznacznie wskazuje w jaki sposób spełnione są poszczególne wymagania SIWZ, na zasadzie tzw. cross‐reference zawierający co najmniej: i) Koncepcję systemu (architektura biznesowa i logiczna systemu, kluczowe wymagania biznesowe, złożenia modelu bazy kosztowej i jego funkcjonowania), ii) Analizę otoczenia Systemu (diagram kontekstowy, interfejsy z innymi systemami), iii) Szczegółowy, pogłębiony opis wymagań funkcjonalnych zawartych w dokumentacji przetargowej oraz ofercie Dostawcy, iv) Szczegółowy, pogłębiony opis wymagań niefunkcjonalnych zawartych w dokumentacji przetargowej oraz ofercie Dostawcy, v) Założenia i opis interfejsu Użytkownika z uwzględnieniem wymagań Zamawiającego określonych w SIWZ oraz uwag zebranych w trakcie Etapu 5.1 (Analizy i Projektu Technicznego), vi) Projekt Scenariuszy Testowych dla poszczególnych funkcjonalności Systemu, vii) Opis i charakterystykę wszystkich Produktów w Projekcie, viii) Diagram Struktury Produktów i Diagram Następstwa Produktów, ix) Diagram przepływu danych i informacji, b) Projekt architektury funkcjonalnej Systemu, c) Projekt realizacji wymagań funkcjonalnych (projekt konfiguracji części gotowej, projekt techniczny rozszerzeń), d) Szczegółowy opis sposobu spełnienia wymagań niefunkcjonalnych, e) Mapa docelowych procesów biznesowych Zamawiającego objętych Systemem wraz z modelem procesów w notacji BPMN oraz z opisem przejścia od procesów „jakie są” do procesów docelowych, f) Księga raportów – obejmująca specyfikację i projekt raportów w Systemie, g) Projekt architektury technicznej Systemu – w tym określenie miejsca instalacji poszczególnych składników infrastruktury, h) Projekt migracji danych (musi również uwzględniać utworzenie archiwum danych, które podlegają migracji), i) Projekt integracji z istniejącymi systemami wraz z projektem interfejsów, j) Projekt modelu zasilania hurtowni danych z Systemu oraz innych zidentyfikowanych źródeł wraz z projektem procesów ETL, warstwy przejściowej, k) Szczegółowy projekt modelu uprawnień w Systemie, l) Zakres prototypów, m) Inne dokumenty ustalone przez Zamawiającego i Dostawcę, 2) Plan migracji danych, 3) Ramowy Plan Testów, 4) Scenariusze testowe, 5) Wzory protokołów wymaganych w ramach procesu testowania, 6) Plan szkoleń, 7) Materiały szkoleniowe, 8) Plan Asysty Personalnej, 9) Plan wsparcia w okresie gwarancji, utrzymania i rozwoju Systemu, 10) Plan zarządzania konfiguracją oprogramowania. Zamawiający zastrzega, że dopuszcza połączenie wybranych wyżej wymienionych dokumentów w jeden dokument pod warunkiem zachowania zakresu merytorycznego. Strona 265 z 285
9.1.2.1
Dokumentacja powykonawcza
Dokumentacja powykonawcza powinna zawierać opis rozwiązań przyjętych w ramach Projektu, w tym m.in.: 1) Dokumentację użytkownika ‐ będzie przeznaczona dla Użytkowników i powinna umożliwić im samodzielne korzystanie z Systemu. Dokumentacja Użytkownika będzie zawierać między innymi: a) dokładny opis realizowanej funkcjonalności, w tym kolejność czynności wykonywanych przez Użytkownika, b) opis elementów znajdujących się na poszczególnych ekranach, c) opis błędów oraz innych komunikatów generowanych przez System, 2) Dokumentację administratora ‐ będzie przeznaczona dla Administratorów Systemu i powinna zawierać między innymi: a) procedury instalacji oraz konfiguracji poszczególnych składników Systemu, b) procedury administrowania Systemem na każdym z poziomów: Oprogramowania Systemowego, Bazodanowego, Narzędziowego oraz Aplikacyjnego, c) procedury tworzenia kopii bezpieczeństwa Systemu oraz archiwizowania danych, d) procedury naprawcze mające na celu przywrócenie stanu normalnej pracy Systemu po wystąpieniu awarii np. opis procedury przywrócenia kopii awaryjnej Systemu i restartu (wznowienia poprawnej pracy Systemu), e) inne istotne informacje konieczne do prawidłowego administrowania Systemem takie jak: wykorzystywane porty komunikacyjne, funkcje importu/eksportu danych, inne procedury dotyczące bezpieczeństwa Systemu, 3) Dokumentację techniczną powykonawczą (dokumentacja infrastruktury technicznej Systemu) – zawierającą co najmniej następujące dokumenty: a) struktura baz danych wraz z opisem przeznaczenia tabel i pól, b) architektura Systemu ze wszystkimi szczegółami, c) dokumentacja interfejsu Użytkownika, d) dokumentację parametryzacji Oprogramowania Standardowego, 4) Dokumentację struktury i architektury bazy danych – zawierającą co najmniej: a) listy pakietów i klas w poszczególnych pakietach, b) hierarchię klas w pakiecie, c) model zależności między klasami dla całego zbioru pakietów, d) opis dla każdego pakietu, klasy, interfejsu lub metody z jej parametrami wraz z możliwymi zastosowaniami oraz przykładami użycia, e) alfabetyczny indeks wszystkich klas, konstruktorów, pól i metod. Zamawiający zastrzega, że dopuszcza połączenie części lub wszystkich wymienionych powyżej dokumentów w jeden dokument pod warunkiem zachowania zakresu merytorycznego. 9.1.2.2
Dokumentacja eksploatacyjna
Dokumentacja eksploatacyjna powinna zawierać procedury administracyjne, w tym m.in.: 1) Procedury instalacji, 2) Procedury archiwizacji danych, 3) Procedury awaryjne, 4) Procedury administracji Systemem. Każda procedura powinna zawierać w szczególności następujące informacje: o Identyfikator procedury, o Nazwa procedury, o Rodzaj procedury, Strona 266 z 285
Data utworzenia, data zatwierdzenia, wersja, Cel i zakres, Warunki początkowe uruchomienia procedury, Oczekiwany rezultat, Działania, które należy wykonać, aby osiągnąć oczekiwany rezultat, w tym określenie ról, które powinny wykonywać poszczególne działania. Zamawiający zastrzega, że dopuszcza połączenie części lub wszystkich wymienionych powyżej dokumentów w jeden dokument pod warunkiem zachowania zakresu merytorycznego. o
o
o
o
o
9.1.2.3
Wymagania niefunkcjonalne dotyczące dokumentacji
NR
Wymaganie
Kategoria wymagania
NF_DOK_1 Dokumentacja projektowa wytworzona przez Dostawcę Systemu w ramach realizacji Wymagalne Projektu musi spełniać następujące wymagania w zakresie jakości: a) czytelna i zrozumiała struktura poszczególnych kompletnych Opracowań; b) spójna struktura, forma i sposób prezentacji treści poszczególnych Opracowań; c) kompletność danego opracowania (dokumentu), rozumiana jako pełne przedstawienie omawianego problemu, a w szczególności jednoznaczne i wyczerpujące przedstawienie wszystkich zagadnień; d) spójność danego Opracowania, rozumiana jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w Opracowaniu oraz brak logicznych sprzeczności pomiędzy informacjami we wszystkich przekazanych Opracowaniach oraz we fragmentach tego samego Opracowania. NF_DOK_2 Dokumentacja projektowa musi być regularnie aktualizowana w dalszych Etapach Wymagalne Projektu, tak by jej zapisy były stale aktualne w trakcie oraz w momencie zakończenia Projektu. NF_DOK_3 Dokumentacja zarządcza, techniczna, projektowa, powykonawcza i eksploatacyjna musi Wymagalne być przygotowana w języku polskim. Dokumentacja powinna zostać dostarczona:  W wersji elektronicznej umożliwiającej edycję w formacie .doc i .pdf (na płycie CD/DVD),  W wersji papierowej w jednym egzemplarzu. Za zgodą Zamawiającego Wykonawca może wybrane elementy dokumentacji przekazać wyłącznie w wersji elektronicznej lub wyłącznie w wersji papierowej. NF_DOK_4 System musi mieć opracowaną kompletną i łatwą w interpretowaniu dokumentację Wymagalne użytkownika i dokumentację techniczną. NF_DOK_5 Dostawca musi zapewnić zgodność dokumentacji systemowej z aktualną wersją Systemu Wymagalne oraz możliwość uzyskania jednoznacznych wyjaśnień i interpretacji dotyczących zapisów w dokumentacji. NF_DOK_6 Dokumentacja powykonawcza musi być aktualizowana i dostarczana wraz z każdą Wymagalne dostawą nowej wersji Systemu. NF_DOK_7 Osobny fragment Dokumentacji Użytkownika musi stanowić opis Systemu Wymagalne informatycznego w zakresie obsługi obszaru finansów i księgowości (w tym księgowości budżetowej), zawierający wykaz programów, procedur lub funkcji wraz z opisem algorytmów i parametrów oraz programowych zasad ochrony danych przygotowany zgodnie z art.10 ust 1 pkt 3 lit. c ustawy z dnia 29 września 1994r. o rachunkowości (t.j. Dz.U. z 2002 Nr 76 poz. 694). Strona 267 z 285
NR
Wymaganie
Kategoria wymagania
NF_DOK_8 Polityka Bezpieczeństwa Danych Osobowych jest dokumentem wymaganym zgodnie z Wymagalne przepisami prawa w zakresie ochrony danych osobowych, stąd winna zostać dostarczona razem z systemem informatycznym. PAŻP posiada Politykę Bezpieczeństwa Danych Osobowych. Dokument należy dostosować do zmian, które wynikną z wprowadzenia systemu informatycznego. NF_DOK_9 Modelowane procesy biznesowe oraz wymagania systemowe powinny zostać Wymagalne wprowadzone dodatkowo do narzędzia przeznaczonego do zarządzania nimi. Narzędzie to zostanie uzgodnione z Zamawiającym przed przystąpieniem do wytwarzania tej dokumentacji. NF_DOK_10 Dostawca Systemu określi w Planie Projeku Wdrożenia metodę wersjonowania Wymagalne dokumentacji, która zostanie zatwierdzona przez Zamawiającego. NF_DOK_11 Terminy dostarczenia dokumentacji powinny zostać określone w Harmonogramie Wymagalne Projektu Wdrożenia. Tabela 44. Wymagania niefunkcjonalne dotyczące dokumentacji 9.1.3
Ogólne warunki odbioru dokumentacji
Wytwarzanie dokumentacji będzie odbywać się zgodnie z następującymi zasadami: a) Dostawca Systemu uszczegóławia i wypełnia treścią Szablony Dokumentacji, które zostaną uzgodnione i zaakceptowane przez Zamawiającego, b) Uzupełnione dokumenty zostają przekazane Zamawiającemu i Doradcy do weryfikacji, c) Po uzgodnieniu ostatecznej wersji dokumentacji, zostaje ona odebrana przez Zamawiającego. W ramach weryfikacji i odbioru dokumentacji Zamawiający oraz Doradca dokonają:  Weryfikacji ilościowej przekazanej dokumentacji, zgodnie zakresem oraz ustaloną przez Strony formą.  Weryfikacji jakościowej tj. przeglądu dokumentacji pod kątem kompletności, spójności, zgodności z przyjętymi standardami dla dokumentacji przygotowywanej w ramach Projektu. Formą odbioru poszczególnych dokumentów wytwarzanych w ramach Projektu będzie ich zatwierdzenie przez Kierownika Projektu ze strony Zamawiającego w formie Protokołu Odbioru Produktu. Dostawca wraz z Zamawiającym ustalą, które z dokumentów będą wymagały formalnego odbioru w postaci Protokołu Odbioru Produktu. 9.1.3.1
Terminy akceptacji w ramach odbioru dokumentacji
Odbiór dokumentacji będzie odbywał się jako część procesu odbioru Podetapu/Etapu, w którym dana dokumentacja musi (zgodnie z zapisami rozdziału 5.4 oraz Projektu Technicznego) zostać wytworzona i przedstawiona do odbioru. Szczegółowe zasady odbioru produktów opisuje rozdział 10. 9.1.3.2
Procedura zgłaszania uwag w ramach odbioru dokumentacji
Procedura zgłaszania uwag do dokumentacji jest identyczna jak warunki odbioru pozostałych produktów Projektu. Dokumentacja będzie podlegała odbiorowi w ramach odbioru odpowiednich podetapów zgodnie z zasadami określonymi w paragrafie 9 Istotnych Postanowień Umowy. Strona 268 z 285
9.1.3.3
Prawa własności intelektualnej do dokumentacji
Wraz z podpisaniem Protokołu Odbioru Końcowego, Wykonawca przeniesie na Zamawiającego autorskie prawa majątkowe do całości dokumentacji dotyczącej realizacji niniejszej Umowy, w szczególności: dokumentacji powykonawczej, dokumentacji środowiska, scenariuszy testowych, wszelkich instrukcji, materiałów szkoleniowych. Strona 269 z 285
10
Zasady odbioru produktów projektu
Produkty projektu dzielą się na zarządcze oraz specjalistyczne. Poniższa tabela prezentuje podział przestawionej w rozdziale 5.8 dokumentacji na ww. kategorie produktów: Produkty zarządcze
Produkty specjalistyczne
plany, harmonogramy, itp. sprzęt, Oprogramowanie Standardowe, Oprogramowanie Autorskie, Dokumentacja, definicje raportów (o ile nie są Oprogramowaniem Autorskim), scenariusze testów, materiały szkoleniowe, instrukcje, itp. Tabela 45. Kategorie produktów Dostawca zobowiązany jest w ramach Struktury Podziału Produktów, Opisu Produktów i Diagramu Następstwa Produktów na poszczególnych Etapach projektu uwzględnić co najmniej następujące główne produkty: 1) Plan Projektu Wdrożenia, 2) Harmonogram Projektu Wdrożenia, 3) Dokument Projekt Techniczny Systemu zawierający wyniki prac projektowych opartych o przeprowadzoną analizę, 4) Prototyp I – standardowa wersja Systemu skonfigurowana zgodnie z ustaleniami wynikającymi z Projektu Technicznego, 5) Dostarczone i udostępnione przez Dostawcę Systemu niezbędne elementy infrastruktury sprzętowej dla środowiska: a) rozwojowego, b) produkcyjnego, c) testowego (wykorzystywanego również jako środowisko szkoleniowe) ‐ wraz z licencjami oprogramowania narzędziowego (bazy danych, oprogramowania ETL, narzędzia BI/EPM), 6) Prototyp II – wersja z wymaganymi modyfikacjami programowymi w zakresie I części Systemu przedstawiona do akceptacji Zamawiającego, 7) Poprawnie przeniesione dane migracji testowej, 8) Raport z przeprowadzonej migracji testowej, 9) Protokoły testów (weryfikacji migracji testowej), 10) Dokumenty powstające w ramach i na potrzeby testów funkcjonalnych, integracyjnych, bezpieczeństwa: a) Plan Testów, b) Scenariusze Testowe, c) Raport z Wykonania Testów Akceptacyjnych, d) Protokół Testów Akceptacyjnych, 11) Dokumenty powstające w ramach i na potrzeby testów wydajnościowych: a) Plan Testów, b) Scenariusze Testowe, c) Raport z Wykonania Testów Akceptacyjnych Wydajnościowych, d) Protokół Testów Akceptacyjnych. 12) Plan Szkoleń, 13) Dokumentacja szkoleniowa, 14) Dokumentacja użytkownika, Strona 270 z 285
15)
16)
17)
18)
19)
20)
21)
22)
23)
24)
25)
26)
27)
28)
29)
30)
31)
32)
33)
34)
35)
36)
37)
38)
39)
40)
41)
42)
Protokoły potwierdzające wykonanie szkoleń, Ankiety Szkoleniowe, Zaświadczenia dla uczestników szkoleń, Poprawnie przeniesione dane migracji w zakresie I części Systemu, Raport z przeprowadzonej migracji w zakresie I części Systemu, Protokoły testów (weryfikacji migracji w zakresie I części Systemu), Uruchomiona produkcyjnie i odebrana I część Systemu, Dokumentacja administratora (administratora systemowego, bezpieczeństwa i biznesowego), Dokumentacja techniczna (dokumentacja infrastruktury technicznej Systemu), Dokumentacja eksploatacyjna (procedury administracyjne), w tym: a) Procedury instalacji, b) Procedury archiwizacji danych, c) Procedury awaryjne, d) Procedury administracji Systemem, Prototyp III – wersja z wymaganymi modyfikacjami programowymi w zakresie II części Systemu przedstawiona do akceptacji Zamawiającego, Poprawnie przeniesione dane migracji testowej w zakresie II części Systemu, Raport z przeprowadzonej migracji testowej w zakresie II części Systemu, Protokoły testów (weryfikacji migracji testowej w zakresie II części Systemu), Dokumenty powstające w ramach i na potrzeby testów funkcjonalnych, integracyjnych, bezpieczeństwa: a) Plan Testów, b) Scenariusze Testowe, c) Raport z Wykonania Testów Akceptacyjnych, d) Protokół Testów Akceptacyjnych, Dokumenty powstające w ramach i na potrzeby testów wydajnościowych: a) Plan Testów, b) Scenariusze Testowe, c) Raport z Wykonania Testów Akceptacyjnych Wydajnościowych, d) Protokół Testów Wydajnościowych, Dokumenty powstające w ramach i na potrzeby testów regresyjnych: a) Plan Testów, b) Raport z Wykonania Testów Regresyjnych, c) Protokół Testów Regresyjnych, Dokumenty powstające w ramach i na potrzeby testów regresyjnych wydajnościowych: a) Plan Testów, b) Raport z Wykonania Testów Regresyjnych Wydajnościowych, c) Protokół Testów Regresyjnych, Plan Szkoleń w zakresie II części Systemu, Dokumentacja szkoleniowa w zakresie II części Systemu, Dokumentacja użytkownika w zakresie II części Systemu, Protokoły potwierdzające wykonanie szkoleń w zakresie II części Systemu, Ankiety Szkoleniowe w zakresie II części Systemu, Zaświadczenia dla uczestników szkoleń w zakresie II części Systemu, Poprawnie przeniesione dane migracji w zakresie II części Systemu, Raport z przeprowadzonej migracji w zakresie II części Systemu, Protokoły testów (weryfikacji migracji w zakresie II części Systemu), Uruchomiona produkcyjnie i odebrana II część Systemu, Strona 271 z 285
43)
44)
45)
46)
Odebrany cały System, Dokumentacja administratora (administratora systemowego, bezpieczeństwa i biznesowego), Dokumentacja techniczna (dokumentacja infrastruktury technicznej Systemu), Dokumentacja eksploatacyjna (procedury administracyjne), w tym: a) Procedury instalacji, b) Procedury archiwizacji danych, c) Procedury awaryjne, d) Procedury administracji Systemem. Zakładane przypisanie produktów do Etapów zawiera rozdział 5.4. Odbiorowi będą podlegały poszczególne Etapy projektu. Dokonanie czynności odbioru zostanie potwierdzone sporządzeniem i podpisaniem Protokołu Odbioru Etapu. Podstawą dokonania Odbioru będzie zgodność przestawionych produktów opisanych w Projekcie Technicznym jako produkty przedstawianego do odbioru podetapu/etapu z wymaganiami wynikającymi z SIWZ, OPZ, Istotnych Postanowień Umowy, Projektu Technicznego i pozostałej dokumentacji, przy czym co najmniej:  Odbiór Etapu 5.0 jest uzależniony od odbioru Planu Projektu Wdrożenia i uaktualnionej wersji Harmonogramu Projektu Wdrożenia,  Odbiór Etapu 5.1 jest uzależniony od odbioru dokumentu Projekt Techniczny,  Odbiór Etapu 5.2 jest uzależniony od poprawnego dostarczenia i zainstalowanie sprzętu oraz licencji Oprogramowania Standardowego oraz przeprowadzenia prezentacji Prototypu I,  Odbiór Etapów 5.3 i 5.4 jest uzależniony od odebrania wszystkich ich podetapów i wszystkich produktów tych podetapów. Szczegółowe zasady odbioru określone są w paragrafie 9 Istotnych Postanowień Umowy. Podczas wdrożenia Systemu muszą być zachowane następujące warunki bezwzględne: 1. Okres wdrożenia Systemu wynosi 24 miesiące, 2. Wdrożenie i uruchomienie produkcyjne podsystemu Finanse i Księgowość powinno nastąpić w pierwszej kolejności i od początku roku tak, aby możliwe było zamknięcie roku w części finansowo‐księgowej w nowym Systemie, 3. Dostarczenie sprzętu i pomyślne przeprowadzenie testów akceptacyjnych I części Systemu musi nastąpić w terminie umożliwiającym rozpoczęcie wdrożenia podsystemu Finanse i Księgowość od początku roku, 4. Odbiór I części Systemu (Etap 5.3) (zakończenie równoległej pracy w tej części w systemie dotychczas funkcjonującym i nowym) może nastąpić pod warunkiem: 4.1. Pomyślnego przeprowadzenia testów akceptacyjnych I części Systemu, 4.2. Poprawnego wyliczenia listy płac przez 3 kolejne miesiące, 4.3. Poprawnego przeniesienia danych płacowych do Płatnika przez 3 kolejne miesiące, 4.4. Poprawnego zamknięcia miesiąca w części finansowo‐ księgowej przez 3 kolejne miesiące, 4.5. Poprawnego wygenerowania miesięcznych sprawozdań w części finansowo‐ księgowej przez 3 kolejne miesiące, 4.6. Przekazania dokumentacji powykonawczej do I części Systemu: 4.6.1.Dokumentacji szkoleniowej, 4.6.2.Dokumentacji użytkownika, 4.6.3.Dokumentacji administratora, 4.6.4.Dokumentacji technicznej (dokumentacji infrastruktury technicznej Systemu), 4.6.5.Dokumentacji eksploatacyjnej (procedury administracyjne), Strona 272 z 285
4.7. Przeprowadzenia szkoleń dla użytkowników i administratorów z I części Systemu, 5. Odbiór II części Systemu (Etap 5.4) (zakończenie równoległej pracy w tej części w systemie dotychczas funkcjonującym i nowym) może nastąpić pod warunkiem: 5.1. Pomyślnego przeprowadzenia testów akceptacyjnych II części Systemu, 5.2. Pomyślnego przeprowadzenia testów regresyjnych Systemu, 5.3. Poprawnego wykonania przez 3 kolejne miesiące kluczowych operacji wskazanych przez Reprezentantów obszarów ze strony Zamawiającego na etapie Analizy w Etapie 5.1 i wpisanych do Projektu Technicznego, 5.4. Przekazania dokumentacji powykonawczej do II części Systemu: 5.4.1.Dokumentacji szkoleniowej, 5.4.2.Dokumentacji użytkownika, 5.4.3.Dokumentacji administratora, 5.4.4.Dokumentacji technicznej (dokumentacji infrastruktury technicznej Systemu), 5.4.5.Dokumentacji eksploatacyjnej (procedury administracyjne), 5.5. Przeprowadzenia szkoleń dla użytkowników i administratorów z II części Systemu. Szczegółowa procedura odbioru przedmiotu zamówienia i Etapów została opisana w paragrafie 9 Istotnych Postanowień Umowy. Procedury odbioru poszczególnych produktów Etapów 5.2, 5.3 i 5.4 zostaną określone w Projekcie Technicznym. 10.1
Prototypy
Zamawiający wymaga od Dostawcy Systemu, aby w ramach realizacji Projektu zostały przygotowane trzy prototypy. Szczegółowy zakres prototypów zostanie uzgodniony w dokumencie Projekt Techniczny, przy następujących założeniach:  Prototyp I zostanie zrealizowany na początku Etapu 5.2 na środowisku zapewnionym przez Dostawcę Systemu i będzie miał na zaprezentowanie uzgodnionej lub będącej przedmiotem uzgodnienia w dokumencie Projekt Techniczny konfiguracji Oprogramowania Standardowego dostarczanego przez Dostawcę. W szczególności, prezentacje funkcjonalności, o których mowa w ustępie 7 paragrafu 9 Istotnych Postanowień Umowy, będą wykonywane w oparciu o Prototyp I.  Prototyp II zostanie zrealizowany w Etapie 5.3 na środowisku testowym, które Dostawca dostarczy Zamawiającemu zgodnie z zapisami Opisu przedmiotu Zamówienia. Prototyp II obejmie swoim zakresem wersję Oprogramowania Standardowego i Autorskiego z wymaganymi modyfikacjami programowymi w zakresie I części Systemu. Szczegółowy zakres Prototypu II zostanie zdefiniowany w dokumencie Projekt Techniczny.  Prototyp III zostanie zrealizowany w Etapie 5.4 na środowisku testowym, które Dostawca dostarczy Zamawiającemu zgodnie z zapisami Opisu przedmiotu Zamówienia. Prototyp III obejmie swoim zakresem wersję Oprogramowania Standardowego i Autorskiego z wymaganymi modyfikacjami programowymi w zakresie II części Systemu. Szczegółowy zakres Prototypu III zostanie zdefiniowany w dokumencie Projekt Techniczny. Strona 273 z 285
10.2
Termin realizacji Projektu
Termin realizacji wdrożenia Systemu wynosi 24 miesiące od daty podpisania Umowy. Zamawiający wymaga dotrzymania następujących terminów pośrednich:  Etap 5.0 zostanie zrealizowany w ciągu 15 dni roboczych od podpisania Umowy,  Etap 5.1 zostanie zrealizowany w ciągu 6 miesięcy od podpisania Umowy,  Etap 5.2 zostanie zrealizowany w ciągu 8 miesięcy od podpisania Umowy,  Etap 5.3 zostanie zrealizowany w ciągu 16 miesięcy od podpisania Umowy,  Etap 5.4 zostanie zrealizowany w ciągu 24 miesięcy od podpisania Umowy. 10.3
Nadzór nad realizacją Projektu
W ramach nadzoru Zamawiającego nad realizacją Przedmiotu Zamówienia czynności związane z nadzorem nad procesem wykonania i wdrożenia Systemu realizowane będą przez Doradcę na podstawie odrębnej Umowy z PAŻP. Zamawiający ma także prawo powołać audytora, który będzie realizował w imieniu Zamawiającego wszelkie uprawnienia kontrolno – nadzorcze wobec Dostawcy. Strona 274 z 285
11
Prace dodatkowe
Ponadto, zgodnie z paragrafem 3 ustęp 3 punkt 3 Istotnych Postanowień Umowy, Dostawca Systemu jest zobowiązany do wykonania zleconych przez Zamawiającego prac dodatkowych w wymiarze nie przekraczającym 500 osobodni, zlecanych w formie „Wniosków o zmianę” – prace te realizowane będą w trakcie trwania Etapów 5.2, 5.3, 5.4 i rozliczane będą kwartalnie jako iloczyn stawki za dzień roboczy i ilości dni na realizacje tych prac. Tryb zlecania i rozliczania tych prac jest określony w ustępie 18 paragrafu 9 Istotnych Postanowień Umowy. Zamawiający nie jest w żaden sposób zobligowany do zlecenia Wykonawcy jakichkolwiek prac dodatkowych. Prace dodatkowe będą mogły dotyczyć prac w zakresie:  programowania,  zadań wdrożeniowych,  zadań konfiguracyjnych,  szkoleń,  konsultacji, pozostających w związku z zakresem opisanym w OPZ. Strona 275 z 285
12
Prawa własności intelektualnej
Szczegółowe wymagania dotyczące praw własności intelektualnej dotyczących Oprogramowania Autorskiego, Oprogramowania Standardowego i Innych Elementów Autorskich uregulowane są w paragrafie 11 Istotnych Postanowień Umowy. Szczególne wymaganie dotyczące praw własności intelektualnej do dokumentacji reguluje punkt 15 paragrafu 9 Istotnych Postanowień Umowy. Strona 276 z 285
13
Informacja o konieczności przetwarzania
danych osobowych w ramach realizacji zamówienia
Wykonawca będzie przetwarzał dane osobowe uczestników szkoleń. Zamawiający w odrębnej umowie upoważni Wykonawcę do tego przetwarzania. Szczegółowe zapisy w tym zakresie reguluje paragraf 14 Istotnych Postanowień Umowy. Wzorzec umowy o przetwarzanie danych osobowych stanowi załącznik do Istotnych Postanowień Umowy. Strona 277 z 285
14
Podwykonawstwo
Zamawiający dopuszcza powierzenie wykonania zamówienia podwykonawcom. W przypadku powierzenia wykonania zamówienia lub jego części podwykonawcom, Wykonawca zobowiązany jest do podania w ofercie części zamówienia, której wykonanie powierzy podwykonawcom. Strona 278 z 285
15
Wzory protokołów
Wzór protokołu odbioru określony został w załączniku 3 do Istotnych Postanowień Umowy. Strona 279 z 285
16
16.1
Informacja o przedsiębiorstwie – lista procesów
Ogólna informacja o przedsiębiorstwie
Ogólnodostępne informacje o Agencji znajdują się na stronie: www.pansa.pl Ogólnodostępne informacje o EUROCONTROL znajdują się na stronie: www.eurocontrol.int Działalność Agencji jest określona w Ustawie o PAŻP (Ustawa z dnia 8 grudnia 2006 r. o Polskiej Agencji Żeglugi Powietrznej, opublikowana w Dz. U. z dnia 29 grudnia 2006 r. Nr 249, poz. 1829) i w podstawowym zakresie polega na świadczeniu usług kontroli ruchu lotniczego nad terytorium RP. Ponadto kontrola ruchu lotniczego jest prowadzona w ścisłej współpracy w ramach Unii Europejskiej z organizacją EUROCONTROL. Aktualnie w PAŻP jest zatrudnionych ok. 1800 osób, z czego:  ok. 700 stanowi personel operacyjny służb kontroli ruchu lotniczego,  ok. 300 stanowi administracja,  ok. 800 stanowi personel pomocniczy. 16.1
Lp.
1)
Obszar -- proces
Obszar Zarządzania Zasobami Ludzkimi
a)
b)
c)
d)
e)
f)
g)
h)
i)
Kadry Płace Zarządzanie BHP Obsługa spraw socjalnych Rekrutacja personelu Szkolenia wewnętrzne Szkolenia zewnętrzne Rozwój personelu Kasa Zapomogowo Pożyczkowa a)
b)
c)
d)
e)
f)
Zarządzanie ZSZ (zarządzanie procesami) Audyty Kontrola wewnętrzna Ochrona lotnictwa cywilnego, danych osobowych i informacji niejawnych
Zarządzanie bezpieczeństwem ruchu lotniczego i certyfikacja ANSP Zarządzanie i organizacja a)
b)
c)
d)
e)
Inwestycje Projekty i przedsięwzięcia badawczo‐rozwojowe Zarządzanie Zamówieniami Publicznymi Zakupy Gospodarka magazynowa i zaopatrzenie a)
b)
c)
d)
e)
f)
Ewidencja majątku Remonty Zarządzanie nieruchomościami Gospodarka samochodowa Zarządzanie infrastrukturą CNS/ATM Zarządzanie infrastrukturą IT 2)
Obszar Zarządzania Organizacją
3)
Obszar Zarządzania Zakupami
4)
5)
Zestawienie obszarów zarządzania i odpowiadających im procesów biznesowych Obszar Zarządzania Majątkiem
Obszar Zarządzania Sprzedażą
Strona 280 z 285
a)
b)
c)
d)
e)
f)
Kalkulacja stawek opłat (bazy kosztowe)
Polityka sprzedaży i realizacja umów pozanawigacyjnych Walidacja danych ruchowych Obsługa sprzedaży usług nawigacyjnych i pozanawigacyjnych Windykacja należności Zarządzanie informacją lotniczą a)
b)
c)
d)
e)
Budżetowanie (OPEX – koszty utrzymania) i monitorowanie budżetu
Zarządzanie płynnością finansową Analizy finansowe i ubezpieczenia Księgowość Zarządzanie umowami a)
b)
c)
d)
e)
Planowanie i analizy strategiczne Planowanie finansowe, controlling i sprawozdawczość Sprawozdawczość inwestycyjna Informacja zarządcza Biura Służb Ruchu Lotniczego Analiza wynagrodzeń 6)
Obszar Finansów i Księgowości
7)
Obszar Informacji Zarządczej
Tabela 46. Obszary zarządzania i główne procesy biznesowe 16.2
Informacja o kluczowych procesach PAŻP podlegających
wsparciu przez System
16.2.1
Informacja o procesie sprzedaży usług nawigacyjnych
Proces sprzedaży usług nawigacji trasowej opiera się na informacjach/danych o ruchu lotniczym, jakie są rejestrowane w ramach kontroli przestrzeni powietrznej przez systemy PAŻP. Informacje te w części dotyczącej świadczenia usług nawigacji trasowej przekazywane są do CRCO (Centralne Biuro Opłat Trasowych‐ Central Route Charges Office –EUROCONTROL). Tam są przetwarzane i na ich podstawie wystawiane są faktury za świadczenie usługi nawigacji trasowej dla kontrahentów, którzy następnie wnoszą opłaty do organizacji EUROCONTROL. Raz w tygodniu EUROCONTROL dokonuje przelewu zgromadzonych wpłat na konto Agencji. Opłaty nawigacji trasowej naliczane są aktualnie wg poniższego wzoru: Opłata nawigacji trasowej = stawka jednostkowa opłaty nawigacji trasowej * współczynnik wagi statku powietrznego w nawigacji trasowej * współczynnik odległości Gdzie:  informacja o odległości pochodzi z systemu kontroli ruchu lotniczego (flown distance),  informacja o stawce obowiązującej w danym roku rozrachunkowym pochodzi z podlegającego zewnętrznej kontroli systemu kalkulacji stawek PAŻP. Ze względu na różnice w standardach ewidencji ruchu lotniczego PAŻP i EUROCONTROL mogą powstawać rozbieżności pomiędzy informacją o usługach będącą w dyspozycji PAŻP, a wielkościami fakturowanymi przez EUROCONTROL. Uzasadnia to konieczność wystawiania tzw. „ślepych faktur” przez PAŻP w celu weryfikacji ew. różnic. Zgodnie z określonym przez użytkownika progiem tolerancji, część z nich zostanie uznana za dopuszczalne, a część podlegać będzie weryfikacji i ewentualnej reklamacji. CRCO fakturuje raz w miesiącu i także raz w miesiącu, zgodnie z dostarczonym do PAŻP harmonogramem, udostępnia pliki FACT i FLBZ zawierające informacje o zafakturowanych, na rzecz PAŻP, usługach. Udostępnianie są także w systemie ETNA ‐ Extranet To National Administrations (po zalogowaniu się) dodatkowe informacje i raporty. Udział EUROCONTROL w fakturowaniu usług nawigacji trasowej i przepływie środków może w przyszłości ulec zmianie na rzecz bezpośredniej obsługi tych działań przez PAŻP. Na taką sytuację System PAŻP powinien być również przygotowany w ramach planowanego przedsięwzięcia. Strona 281 z 285
Działalność świadczenia usługi nawigacji terminalowej jest aktualnie rozliczana bezpośrednio przez PAŻP. W związku z tym nie występuje konieczność emisji tzw. „ślepych faktur” i właściwej wyłącznie dla nawigacji trasowej procedury kontroli opłat. Nie można jednak wykluczyć, że w przyszłości i ten typ usług będzie rozliczany przez CRCO. Ewidencja świadczonych usług nawigacji terminalowej opiera się na danych z systemu kontroli lotów, tak jak w przypadku ewidencji usług nawigacji trasowej. Opłata nawigacji terminalowej = stawka jednostkowa opłaty nawigacji terminalowej * współczynnik wagi statku powietrznego w nawigacji terminalowej Gdzie:  informacja o stawce obowiązującej w danym roku rozrachunkowym pochodzi z podlegającego zewnętrznej kontroli systemu kalkulacji stawek PAŻP. Świadczone usługi nawigacji lotniczej dla lotów zwolnionych ujętych w Rejestrze Lotów Zwolnionych, refundowane są z budżetu Państwa i rozliczane zgodnie z rozporządzeniem Ministra Transportu, Budownictwa i Gospodarki Morskiej z dnia 13 sierpnia 2013 r. w sprawie sposobu i trybu rozliczania i dokumentowania kosztów związanych z zapewnieniem służb żeglugi powietrznej za loty zwolnione z opłat nawigacyjnych (Dz. U. 2013 r. poz. 1009). Ich ewidencja opiera się także na danych uzyskanych z systemu kontroli lotów PAŻP. Obejmuje ona zarówno usługi nawigacji trasowej i terminalowej, jak również obsługę lotów VFR. Wszystkie dane operacyjne o świadczonych usługach pobierane są obecnie z systemu bazodanowego PAŻP (@rms) i wgrywane do okna przejściowego (interfejs @rms), gdzie następuje „dopinanie” klienta i statku powietrznego (MTOW, typ) do poszczególnej operacji. Tak uzupełnione dane operacyjne (podlegające stosownym importom) umożliwiają naliczenie opłat trasowych i terminalowych oraz zafakturowanie usług zgodnie z cennikiem zawartym w AIP Polska4. 16.2.2
Informacja o procesie zarządzania kosztami
Stawki opłat nawigacyjnych używanych w procesie sprzedaży są kalkulowane w wieloletniej perspektywie czasowej. Na ich podstawie tworzony jest plan przychodów. Do kalkulacji baz kosztowych używane są plany kosztów wszystkich obszarów działalności Agencji, natomiast do kalkulacji konkretnych stawek uwzględnia się koszty tylko w zakresie, w jakim koszty te są związane z działalnością nawigacyjną. Związek kosztów z usługą nawigacyjną podlega kontroli. Wynika stąd konieczność bardzo precyzyjnej ewidencji kosztów, wykluczającej możliwość włączenia w procesie kalkulacji stawek jakichkolwiek innych kosztów, niż te, uzasadnione koniecznością ich poniesienia dla świadczenia konkretnej usługi. Tworzone są plany roczne oraz pięcioletnie. Stawki zgodne z planami podlegają zatwierdzeniu i są stosowane przez zadeklarowany okres. Precyzja planowania stawek, z uwzględnieniem prognoz ruchu lotniczego ma zasadnicze znaczenie dla rozliczeń finansowych Agencji wynikających z mechanizmu podziału ryzyka. Prognozowane przychody powinny pokryć planowane koszty działalności, co wynika wprost z Ustawy o PAŻP. Z zapisów regulacji zewnętrznych, wytycznych organizacji EUROCONTROL, wynika konieczność systematycznego obniżania stawek do zadanego poziomu, co wymusza konieczność stworzenia systemu sprawnego zarządzania kosztami. Potrzeby w tym zakresie zostały zgłoszone jako problemy do rozwiązania podczas wdrożenia. Działalność pozanawigacyjna Agencji stanowi stosunkowo niewielką jej część. Zasadniczo polega na sprzedaży map nawigacyjnych dla klientów o charakterze ogólnym. Mapy te powstają jednak przy okazji prowadzenia 4 AIP Polska‐ zbiór Informacji Lotniczych publikowany przez PAŻP obejmujący m.in. informacje dot. dróg lotniczych w polskiej przestrzeni powietrznej, lotnisk oraz m.in. zasady naliczania opłat nawigacyjnych, lotniskowych itp. Strona 282 z 285
działalności nawigacyjnej, przy wykorzystaniu specjalizowanej infrastruktury. Problemem jest rozdzielenie kosztów wykorzystania tej infrastruktury dla usług nawigacyjnych i pozanawigacyjnych. Problem pojawia się tylko, gdy mapa, która i tak powstaje na potrzeby działalności nawigacyjnej, jest dodatkowo sprzedana w ramach działalności pozanawigacyjnej. Źródła problemów przy kalkulacji stawek:  Konieczność precyzyjnej alokacji kosztów w złożonym procesie i fakt wspólnego wykorzystania zasobów w tym samym czasie na rzecz produktów lub usług wymagających szczegółowej kontroli i raportowania.  Niedoskonałość używanych obecnie narzędzi i procedur wspierających proces planowania Obecnie proces planowania ma charakter iteracyjny i polega w uproszczeniu na integracji planów z różnych obszarów Agencji, kalkulacji stawek, wykorzystaniu informacji ze sprawozdań finansowych, wprowadzaniu korekt i końcowym zatwierdzaniu. Stworzony plan finansowy wykorzystywany jest również przy sporządzaniu budżetu zadaniowego. Strona 283 z 285
17
Spis tabel
Tabela 1 Słownik pojęć ............................................................................................................................................... 17 Tabela 2. Lista komponentów Systemu ...................................................................................................................... 19 Tabela 3. Lista modułów funkcjonalnych Systemu ..................................................................................................... 21 Tabela 4. Opis modułów komponentu EOD ............................................................................................................... 22 Tabela 5. Liczba użytkowników poszczególnych komponentów ................................................................................ 22 Tabela 6. Wymagania funkcjonalne ‐ ogólne ............................................................................................................. 29 Tabela 7. Wymagania funkcjonalne ‐ moduły wspólne .............................................................................................. 47 Tabela 8. Wymagania funkcjonalne ‐ Zarządzanie personelem ................................................................................. 75 Tabela 9. Wymagania funkcjonalne ‐ Finanse i księgowość ..................................................................................... 115 Tabela 10. Wymagania funkcjonalne ‐ Zarządzanie majątkiem ............................................................................... 125 Tabela 11. Wymagania funkcjonalne ‐ Zarządzanie sprzedażą. ............................................................................... 135 Tabela 12. Wymagania funkcjonalne ‐ Zarządzanie zakupami ................................................................................. 159 Tabela 13. Wymagania funkcjonalne ‐ EOD ............................................................................................................. 182 Tabela 14. Wymagania funkcjonalne ‐ BI/EPM ........................................................................................................ 196 Tabela 15. Zestawienie wymagań dla metody zarządzania kosztami ABC/M .......................................................... 199 Tabela 16 Wymagania dla komponentu Portal ........................................................................................................ 201 Tabela 17. Wymagania niefunkcjonalne ogólne ...................................................................................................... 202 Tabela 18. Wymagania niefunkcjonalne dot. architektury systemu ........................................................................ 203 Tabela 19. Wymagania niefunkcjonalne – prawne o charakterze ogólnym, technicznym ...................................... 205 Tabela 20. Wymagania niefunkcjonalne ‐ prawne, wynikające z prawa międzynarodowego ................................. 206 Tabela 21. Wymagania niefunkcjonalne – prawne o charakterze szczegółowym dla komponentu EOD ................ 206 Tabela 22. Wymagania niefunkcjonalne ‐ prawne o charakterze szczegółowym dla podsystemu ZP ..................... 207 Tabela 23. Wymagania niefunkcjonalne ‐ prawne o charakterze szczegółowym dla podsystemu FK ..................... 209 Tabela 24. Wymagania niefunkcjonalne – organizacyjne ........................................................................................ 212 Tabela 25. Wymagania dotyczące dostępności, wydajności i skalowalności ........................................................... 213 Tabela 26. Wyposażenie serwera HP Superdome 2 ................................................................................................. 215 Tabela 27. Lista licencji będących w posiadaniu Zamawiającego ............................................................................ 216 Tabela 28. Wymagania ogólne dotyczące infrastruktury ......................................................................................... 217 Tabela 29. Wymagania dotyczące serwerów ........................................................................................................... 219 Tabela 30. Wymagania dotyczące macierzy dyskowej ............................................................................................. 219 Tabela 31. Wymagania dotyczące biblioteki taśmowej ........................................................................................... 220 Tabela 32. Wymagania dotyczące przełączników .................................................................................................... 221 Tabela 33. Wymagania funkcjonalne w zakresie integracji ...................................................................................... 224 Tabela 34. Wymagania niefunkcjonalne w zakresie integracji ................................................................................. 225 Tabela 35. Wymagania niefunkcjonalne – bezpieczeństwa i ochrony ..................................................................... 228 Tabela 36. Wymagania niefunkcjonalne – metodyka prowadzenia Projektu .......................................................... 231 Tabela 37. Proponowany podział Harmonogramu Wdrożenia Systemu na Etapy i Podetapy ................................ 238 Tabela 38. Lista podstawowych źródeł danych do migracji ..................................................................................... 245 Tabela 39. Lista dodatkowych źródeł danych do migracji ........................................................................................ 246 Tabela 40. Pozostałe wymagania niefunkcjonalne dla migracji danych .................................................................. 247 Tabela 41. Wymagalne typy szkoleń do przeprowadzenia w ramach projektu ....................................................... 259 Tabela 42. Liczba osób obsługujących poszczególne moduły komponentu ERP ..................................................... 261 Tabela 43. Pozostałe wymagania dotyczące szkoleń ............................................................................................... 263 Tabela 44. Wymagania niefunkcjonalne dotyczące dokumentacji .......................................................................... 268 Strona 284 z 285
Tabela 45. Kategorie produktów .............................................................................................................................. 270 Tabela 46. Obszary zarządzania i główne procesy biznesowe ................................................................................. 281 Strona 285 z 285