Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
ZAŁĄCZNIK NR 1
OPIS PRZEDMIOTU ZAMÓWIENIA
1 Spis treści
1. Skróty i definicje............................................................................................................................4
2. Wprowadzenie...............................................................................................................................6
3. Opis systemu wykorzystywanego przez Zamawiającego..............................................................6
3.1. Funkcjonalność systemu SZT.....................................................................................................6
3.1.1. Ogólne funkcjonalności systemu...........................................................................................6
3.1.2. Wymagania techniczne........................................................................................................11
3.1.3. Wymagania niezawodnościowe..........................................................................................12
3.1.4. Wymagania wydajnościowe................................................................................................12
3.1.5. Wymagania infrastrukturalne..............................................................................................12
3.1.6. Wymagania licencyjne.........................................................................................................13
3.1.7. Oprogramowanie dedykowane...........................................................................................13
3.1.7.1. Synchronizacja atrybutów prostych z HCM do AD..........................................................13
3.1.7.2. Dodawanie pracowników lub innych osób zatrudnionych do grupy w AD....................14
3.1.7.3. Tryb symulacji provisioningu dla wskazanych jednostek................................................14
3.1.7.4. Mechanizm dystrybucji haseł inicjalnych i resetu haseł..................................................14
3.1.7.5. Rozszerzenie mechanizmu korelacji po AD.....................................................................14
3.1.7.6. Zakładanie skrzynki pocztowej dla użytkowników poza centralnym Exchange.............15
3.1.7.7. Zmiana mechanizmu eskalacji.........................................................................................15
3.1.7.8. Tryb symulacji provisioningu dla wskazanych jednostek................................................15
3.2. Architektura wykorzystywanego rozwiązania.........................................................................15
3.2.1. Środowisko pracy SZT..........................................................................................................15
3.2.2. Architektura logiczna SZT....................................................................................................16
3.2.3. Integracja z systemami informatycznymi Zamawiającego..................................................16
3.2.4. Role dostępowe zdefiniowane w SZT..................................................................................20
3.2.5. Podstawowe procesy workflow zdefiniowane w SZT.........................................................23
3.2.6. Architektura sprzętowa.......................................................................................................23
3.2.7. Systemy operacyjne.............................................................................................................24
str. 1
3.2.8. Konfiguracja wirtualizacji i HA.............................................................................................26
3.2.9. Konfiguracja sieciowa HyperV.............................................................................................26
3.2.10. Specyfikacja baz danych......................................................................................................26
3.2.11. Wysoka dostępność.............................................................................................................26
3.2.12. Specyfikacja serwerów fizycznych.......................................................................................27
3.2.13. Komponenty infrastruktury rozwiązania Zamawiającego..................................................27
3.2.14. Anonimizacja danych...........................................................................................................28
4. Zobowiązania Wykonawcy..........................................................................................................28
4.1. Dostawa licencji dla użytkowników Systemu Zarządzania Tożsamością................................28
4.2. Zapewnienie wsparcia gwarancyjnego i serwisowego dla Systemu Zarządzania Tożsamością28
4.3. Rozwój funkcjonalności SZT – Modyfikacje Systemu..............................................................29
4.4. Migracja systemu do wersji 7..................................................................................................31
4.5. Testy.........................................................................................................................................31
4.5.1. Testy poprawności procesu migracji do nowej wersji oprogramowania SailPoint............31
4.5.2. Testy nowych funkcjonalności Modyfikacji Oprogramowania Dedykowanego.................32
4.5.3. Cykliczne testy wydajnościowe...........................................................................................32
4.5.4. Cykliczne testy niezawodnościowe......................................................................................33
4.5.5. Kryteria akceptacji testów...................................................................................................34
4.5.6. Scenariusze testowe............................................................................................................34
4.6. Dostawa /rozbudowa platformy sprzętowej..........................................................................34
4.7. Poziom i zasady udzielanego wsparcia technicznego i serwisu (SLA).....................................34
4.7.1. Procedura realizacji zgłoszeń...............................................................................................37
4.7.2. Klasyfikacja zgłoszeń............................................................................................................38
4.7.3. Konsultacje...........................................................................................................................41
4.8. Dokumentacja projektowa......................................................................................................42
4.8.1. Aktualizacja dokumentacji projektowej..............................................................................42
4.8.2. Dokumentacja Modyfikacji Oprogramowania Dedykowanego..........................................42
4.8.3. Zasady aktualizacji dokumentacji projektowej...................................................................42
5. Wymagania dla rozwiązania równoważnego..............................................................................43
5.1. Równoważne kryteria funkcjonalne........................................................................................43
5.2. Kryterium ciągłości działania systemu.....................................................................................43
5.3. Wymagania techniczne............................................................................................................43
5.4. Wymagania niezawodnościowe..............................................................................................43
5.5. Wymagania wydajnościowe....................................................................................................44
5.6. Wymagania infrastrukturalne.................................................................................................44
str. 2
5.7. Wymagania licencyjne.............................................................................................................44
5.8. Wymagania dotyczące realizacji wdrożenia rozwiązania równoważnego..............................44
5.8.1. Analiza wymagań i Projekt Biznesowo-Techniczny.............................................................44
5.8.2. Wdrożenie przedprodukcyjne..............................................................................................45
5.8.3. Wdrożenie produkcyjne.......................................................................................................46
5.8.4. Poziom i zasady udzielanego wsparcia technicznego i serwisu (Rozwiązanie Równoważne)48
5.9. Szkolenia..................................................................................................................................48
5.10. Dokumentacja projektowa..................................................................................................52
5.10.1. Aktualizacja dokumentacji projektowej systemu SZT.........................................................52
5.10.2. Zasady aktualizacji dokumentacji projektowej...................................................................52
5.10.3. Wymagania dotyczące dokumentacji projektowej rozwiązania równoważnego...............53
5.10.3.1. Analiza wymagań.............................................................................................................53
5.10.3.2. Plan Projektu....................................................................................................................53
5.10.3.3. Projekt Biznesowo-Techniczny........................................................................................54
5.10.3.4. Plan Testów......................................................................................................................54
5.10.3.5. Materiały na potrzeby szkoleń e-learningowych............................................................55
5.10.3.6. Dokumentacja powykonawcza........................................................................................56
5.10.3.7. Dokumentacja użytkownika............................................................................................57
5.11. Testy.....................................................................................................................................58
5.11.1. Testy rozwiązania równoważnego.......................................................................................58
5.11.2. Testy nowych funkcjonalności Modyfikacji Oprogramowania...........................................58
5.11.3. Cykliczne testy wydajnościowe...........................................................................................58
5.11.4. Cykliczne testy niezawodnościowe......................................................................................58
5.11.5. Kryteria akceptacji testów...................................................................................................59
5.11.6. Scenariusze testowe............................................................................................................59
5.12. Harmonogram ramowy dla rozwiązania równoważnego...................................................59
6. Załączniki......................................................................................................................................61
6.1. Formularz wniosku o Modyfikację..........................................................................................61
6.2. Protokół Odbioru Rozwiązania Równoważnego.....................................................................63
6.3. Protokół Odbioru Rozwiązania Równoważnego.....................................................................65
6.4. Lista dystrybucyjna..................................................................................................................66
str. 3
1. Skróty i definicje
Pojęcie Znaczenie
Konektor Oprogramowanie służące do wymiany informacji między centralnym repozytorium, a podłączonym systemem informatycznych
MS Ministerstwo Sprawiedliwości
Proces Zarządzania Tożsamością, PrZT
Proces zarządzania kontami użytkowników, prawami dostępu do zasobów informacyjnych oraz ich nadzorowania.
System Zarządzania Tożsamością/ SZT/ System
Ogół procesów, procedur i systemów informacyjnych biorących udział w procesie zarządzania tożsamością użytkowników systemów informatycznych.
Tożsamość Podstawowy obiekt SZT definiujący pracownika lub inną osobę zatrudnioną w organizacji, który posiada przypisane atrybuty oraz prawa dostępowe do Systemów Informatycznych.
Oprogramowanie Gotowe
Oprogramowanie IdentytyIQ wersja 6.4 firmy SailPoint będące w posiadaniu Zamawiającego
Oprogramowanie Dedykowane
Oprogramowania wykonane i dostarczone w wyniku realizacji wdrożenia SZT w sądach powszechnych, do którego Zamawiający posiada kody źródłowe oraz
str. 4
autorskie prawa majątkowe.
Użytkownik wewnętrzny/ pracownik etatowy
Osoba zatrudniona na podstawie umowy o pracę w dowolnym sądzie powszechnym w Polsce.
Użytkownik zewnętrzny
Osoba dla której tworzone jest dedykowane konto w SI, świadcząca usługi dla Zamawiającego lub sądów powszechnych na innej podstawie niż umowa o pracę.
Rola Zestaw uprawnień w ramach jednego lub więcej SI, które powinny być przydzielone użytkownikowi. Użytkownik może być członkiem wielu ról, o ile nie jest to sprzeczne z zasadami podziału obowiązków. W takim przypadku użytkownik ma przydzielone uprawnienia będące sumą ról, których jest członkiem.
Rola techniczna
Rola obejmująca zestaw uprawnień w ramach pojedynczego SI, niezbędnych do realizacji określonych zadań w SI dla tej roli.
Rola biznesowa
Rola wynikająca z funkcji, stanowiska, działu lub innych atrybutów tożsamości użytkownika, na ogół obejmująca uprawnienia w więcej niż w jednym systemie informatycznym.
SI System Informatyczny objęty procesem zarządzania tożsamością.
Uprawnienie Czynność bądź niepodzielny zestaw czynności, które może wykonać użytkownik w SI. Lista uprawnień, do których użytkownik może być autoryzowany określona jest dla każdego SI.
Autentykacja Czynność, dzięki której SI może potwierdzić tożsamości użytkownika. Uwierzytelnienie dokonuje się na podstawie metody wybranej dla danego SI.
Użytkownik Osoba uprawniona do korzystania z Systemów Informatycznych, niezależnie od formy zatrudnienia, tj. pracownik albo inne osoby zatrudnione przez Zamawiającego lub sądy powszechne,, w rozumieniu
str. 5
art. 1 ustawy z dnia 27 lipca 2001 r. Prawo o ustroju sądów powszechnych (Dz. U. z 2016 r. poz. 2062 ze zm.).
str. 6
2. Wprowadzenie
System Zarządzania Tożsamością (SZT) został wdrożony w sierpniu 2016 r. w sądach powszechnych apelacji wrocławskiej i białostockiej, a w kwietniu 2017 r. we wszystkich pozostałych sądach powszechnych w Polsce. Celem wdrożenia było zapewnienie spójnych i bezpiecznych zasad zarządzania tożsamością użytkowników systemów informatycznych, w szczególności:
zapewnienie adekwatności przyznanych uprawnień do pełnionych obowiązków i funkcji oraz ich zgodność z obowiązującym prawem i regulacjami wewnętrznymi,
usprawnienie i przyspieszenie procesów związanych z cyklem życia tożsamości poprzez automatyzację i wykorzystanie do tego celu narzędzi informatycznych,
zapewnienie rozliczalności posiadanych przez użytkowników uprawnień i procesu ich przyznawania.
Wdrożony i wykorzystywany przez Zamawiającego System został zbudowany w oparciu o rozwiązanie Identity IQ producenta SailPoint. i wykorzystuje obecnie 52.500 licencji dla Użytkowników Wewnętrznych.
3. Opis systemu wykorzystywanego przez Zamawiającego
3.1. Funkcjonalność systemu SZT
Niniejszy rozdział opisuje funkcjonalność SZT wykorzystywaną przez Zamawiającego z podziałem na ogólne funkcjonalności systemu, funkcjonalności dedykowane, do których Zamawiający posiada autorskie prawa majątkowe, techniczne, niezawodnościowe, wydajnościowe, infrastrukturalne i licencyjne. System SZT spełnia poziom wymagalności dla poszczególnych funkcjonalności, zgodnie ze wskazaną poniżej specyfikacją.
3.1.1. Ogólne funkcjonalności systemu
Nr wymag
ania
Opis wymagania kategoria wymagań Poziom wymagalno
ści spełniany
przez system
1 Zarządzanie cyklem życia tożsamości: tworzenie, modyfikacja, blokowanie kont
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
2 Tworzenie/przechowywanie/usuwanie informacji o tożsamościach użytkowników w SZT na podstawie danych HCM i replikacja kont użytkowników do obligatoryjnych
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
str. 7
systemów AD, Exchange, ESS/MSS/LSO3 Blokowanie kont i dezaktywacja uprawnień w
przypadku wystąpienia odpowiedniego zdarzenia w systemie HCM oraz manualnie z poziomu portalu samoobsługi SZT. Blokowanie i dezaktywacja musi posiadać dodatkowy atrybut określający przyczynę wyłączenia konta.
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
4 Synchronizacja zmodyfikowanych atrybutów HCM do systemów informatycznych, np. zmiana nazwiska
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
5 Możliwość centralnego resetu/zmiany hasła oraz dystrybucja hasła produkcyjnego do systemów informatycznych
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
6 Zarządzanie uprawnieniami w SI w oparciu o role
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
7 Możliwość definiowania ról biznesowych grupujących role techniczne SI
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
8 Przyznanie podstawowych ról biznesowych dla MSS/LSO, AD, Exchange dla wszystkich użytkowników SZT
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
9 Obsługa procesu akceptacji workflow dla przypisania ról
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
10 Obsługa procesu akceptacji workflow dla tworzenia i modyfikacji ról biznesowych
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
11 Obsługa portalu samoobsługi do celów zarządzania tożsamością
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
12 Dostęp do portalu samoobsługi poprzez przeglądarkę internetową
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
13 Możliwość synchronizacji haseł pomiędzy SI Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
14 Możliwość definiowania reguł wykluczających się uprawnień (tzw. Separation of Duties)
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
15 Możliwość uruchomienia zadania identyfikacji naruszeń Separation of Duties na poziomie użytkowników
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
16 Możliwość uruchomienia zadania identyfikacji naruszeń Separation of Duties na poziomie ról
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
17 Interfejs portalu samoobsługi SZT oraz systemu akceptacji dostępny w języku polskim i angielskim
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
18 Możliwość określenia właściciela roli, który kontroluje proces przypisania roli do użytkowników. Kontrola ta realizowana jest m.in. poprzez uczestnictwo właściciela w workflow w roli akceptującego przypisanie uprawnień lub roli
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
19 Możliwość weryfikacji przez właściciela roli, tożsamości do niej przypisanych
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
str. 8
20 Możliwość usunięcia przypisanie roli do użytkownika poprzez właściciela roli
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
21 Możliwość kontroli uprawnień użytkowników w ramach wybranej struktury organizacyjnej (raport musi obejmować zestawienie przypisanych systemów oraz uprawnień przypisanych użytkownikom, uprawnień technicznych, ról biznesowych, ról w SI)
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
22 Możliwość przypisania ryzyka do wybranej roli (wysokie, średnie, niskie)
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Opcjonalne
23 Możliwość wprowadzenia opisu dla każdej roli Ogólne funkcjonalności dotyczące zarządzania tożsamości
Opcjonalne
24 Możliwość czasowego przypisania roli Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
25 Możliwość weryfikacji ról przypisanych użytkownikowi w repozytorium tożsamości
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
26 Możliwość porównania stanu przypisania ról do użytkownika w repozytorium tożsamości i systemie informatycznym
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
27 Automatyczne nadawanie ról w oparciu o określone reguły lub stanowisko w strukturze HCM
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
28 Możliwość tworzenia kont dla użytkowników, którzy nie są zdefiniowani w systemie HCM np.: zewnętrznych konsultantów oraz użytkowników technicznych
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
29 Możliwość czasowego przenoszenia uprawnień pomiędzy użytkownikami
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
30 Wsparcie procesu nadawania uprawnień administracyjnych w sytuacjach kryzysowych
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
31 Możliwość weryfikacji czynności wykonanych przy użyciu uprawnień uprzywilejowanych
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
32 Wsparcie procesu okresowej recertyfikacji uprawnień
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
33 Blokowanie wybranych kanałów dostępu do systemu Exchange per użytkownik. Na przykład blokowanie dostępu z urządzeń mobilnych lub wybranych komputerów.
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Opcjonalne
34 System umożliwia zdefiniowanie automatycznego zadania usuwającego tożsamości z systemu, które spełniają określone kryteria wyboru, np. konta przedawnione
Ogólne funkcjonalności dotyczące zarządzania tożsamości
Wymagane
35 Dostępność portalu samoobsługi w wersji desktop (zwany dalej Portal desktop) powinien być dostępny z poziomu przeglądarek internetowych. Wspierane najnowsze wersje przeglądarek: Chrome lub Firefox lub Internet Explorer.
Funkcjonalność interfejsu aplikacji
Wymagane
36 Dostępność wersji mobilnej portalu Funkcjonalność interfejsu Opcjonalne
str. 9
samoobsługi. Wspierane urządzenia: iOS, Android.
aplikacji
37 Możliwość personalizacji interfejsu portalu samoobsługi
Funkcjonalność interfejsu aplikacji
Wymagane
38 Dostępność co najmniej dwóch wersji obszaru roboczego portalu dedykowanych dla użytkownika i administratora
Funkcjonalność interfejsu aplikacji
Wymagane
39 Obsługa powiadomień sms dla systemu akceptacji
Funkcjonalność interfejsu aplikacji
Wymagane
40 Obsługa powiadomień email dla systemu akceptacji
Funkcjonalność interfejsu aplikacji
Wymagane
41 Konfigurowalne treści powiadomienia Funkcjonalność interfejsu aplikacji
Opcjonalne
42 Obsługa autentykacji SSO do interfejsu aplikacji[1]Obsługa autentykacji SSO do interfejsu aplikacji[1]
Funkcjonalność interfejsu aplikacji
Wymagane
43 Możliwość wyświetlenie struktury organizacyjnej
Funkcjonalność interfejsu aplikacji
Wymagane
44 Wysyłanie powiadomień o upływającym okresie ważności kont w SI (AD, Exchange, ESS/MSS/LSO)
Funkcjonalność interfejsu aplikacji
Wymagane
45 Możliwość wyszukiwania tożsamości Funkcjonalność interfejsu administratora portalu samoobsługi
Wymagane
46 Możliwość tworzenia/usuwania tożsamości Funkcjonalność interfejsu administratora portalu samoobsługi
Wymagane
47 Możliwość blokowania/odblokowania tożsamości
Funkcjonalność interfejsu administratora portalu samoobsługi
Wymagane
48 Możliwość tworzenia/edycji ról biznesowych Funkcjonalność interfejsu administratora portalu samoobsługi
Wymagane
49 Możliwość dodawania/usuwania ról dla wybranej tożsamości
Funkcjonalność interfejsu administratora portalu samoobsługi
Wymagane
50 Możliwość centralnego resetu hasła Funkcjonalność interfejsu administratora portalu samoobsługi
Wymagane
51 Możliwość podglądu statusu procesów workflow
Funkcjonalność interfejsu administratora portalu samoobsługi
Wymagane
52 Możliwość publikowania komunikatów i dokumentów dla użytkowników
Funkcjonalność interfejsu administratora portalu samoobsługi
Opcjonalne
53 Możliwość edycji atrybutów własnej tożsamości
Funkcjonalność interfejsu użytkownika portalu samoobsługi
Wymagane
54 Możliwość centralnego resetu hasła Funkcjonalność interfejsu użytkownika portalu samoobsługi
Wymagane
55 Możliwość wnioskowania o przyznanie ról biznesowych
Funkcjonalność interfejsu użytkownika portalu samoobsługi
Wymagane
56 Możliwość weryfikacji statusu procesu workflow
Funkcjonalność interfejsu użytkownika portalu samoobsługi
Wymagane
57 Możliwość akceptacji kroków workflow (dla Funkcjonalność interfejsu WymaganeObsługa autentykacji SSO do interfejsu aplikacji[1]
str. 10
managerów) użytkownika portalu samoobsługi
58 Dostępność pomocy technicznej Funkcjonalność interfejsu użytkownika portalu samoobsługi
Wymagane
59 Dostępność konektora dla MS Active Directory
Funkcjonalności dotyczące konektorów
Wymagane
60 Dostępność konektora dla MS Exchange Funkcjonalności dotyczące konektorów
Wymagane
61 Dostępność konektora dla OpenLdap Funkcjonalności dotyczące konektorów
Wymagane
62 Dostępność konektora dla PostgreSQL Funkcjonalności dotyczące konektorów
Wymagane
63 Dostępność konektora dla IBM DB2 Funkcjonalności dotyczące konektorów
Wymagane
64 Dostępność konektora dla MSSQL Funkcjonalności dotyczące konektorów
Wymagane
65 Dostępność konektora dla SAP NW Portal poprzez mechanizm Central User Administration (CUA)
Funkcjonalności dotyczące konektorów
Wymagane
66 Dostępność konektora dla SAP Netweaver ABAP wykorzystującego SAP API
Funkcjonalności dotyczące konektorów
Wymagane
67 Możliwość tworzenia nowego konektora w przypadku braku obecności standardowego wsparcia dla danego typu integrowanego systemu informatycznego
Funkcjonalności dotyczące konektorów
Wymagane
68 Dostępność konektora dla SAP HCM - jako źródła tożsamości dla systemu zarządzania tożsamością
Funkcjonalności dotyczące konektorów
Wymagane
69 Możliwość obsługi błędów i konfliktów synchronizacji
Funkcjonalności dotyczące konektorów
Wymagane
70 Obsługa powiadomień dla błędów synchronizacji pomiędzy systemami
Funkcjonalności dotyczące konektorów
Wymagane
71 Możliwość przeglądu dziennika synchronizacji wraz z statusem rekordów (zreplikowany prawidłowo, zreplikowany z ostrzeżeniem, niezreplikowany)
Funkcjonalności dotyczące konektorów
Wymagane
72 Możliwość modyfikacji atrybutów podlegających synchronizacji oraz kierunku synchronizacji (jedno, dwukierunkowa)
Funkcjonalności dotyczące konektorów
Wymagane
73 Możliwość replikacji struktury organizacyjnej HCM
Funkcjonalności dotyczące konektorów
Wymagane
74 Możliwość inicjalnego załadowania do SZT użytkowników istniejących w SI
Funkcjonalności dotyczące konektorów
Wymagane
75 Możliwość inicjalnego załadowania do SZT ról istniejących w SI wraz z przypisaniem do użytkowników
Funkcjonalności dotyczące konektorów
Wymagane
76 Możliwość dwukierunkowej synchronizacji przypisania ról do użytkowników pomiędzy SZT a SI
Funkcjonalności dotyczące konektorów
Wymagane
77 Możliwość dwukierunkowej synchronizacji kont użytkowników pomiędzy SZT a SI
Funkcjonalności dotyczące konektorów
Wymagane
78 Możliwość definiowania polityk audytu pozwalających na przeszukiwanie repozytorium tożsamości w celu identyfikacji sytuacji stanowiących potencjalne zagrożenie
Funkcjonalność audytu systemowego
Wymagane
79 Możliwość określenia właściciela polityki audytu
Funkcjonalność audytu systemowego
Opcjonalne
str. 11
80 Możliwość powiadomienia właściciela polityki w przypadku wystąpienia odstępstw
Funkcjonalność audytu systemowego
Opcjonalne
81 Proces obsługi odnalezionych odstępstw audytowych poprzez czasową bądź stałą akceptację
Funkcjonalność audytu systemowego
Wymagane
82 Definiowanie poziomów ryzyka dla poszczególnych zagrożeń weryfikowanych przez polityki audytu
Funkcjonalność audytu systemowego
Wymagane
83 Możliwość ekstrakcji danych raportowych do plików opartych o otwarte formaty danych (np. plik CSV) gwarantujących dalsze przetwarzanie tych danych w aplikacjach zewnętrznych, w tym oprogramowaniu MS Excel
Wymagania dotyczące systemu raportowego
Wymagane
84 Możliwość tworzenia dowolnych raportów systemowych opartych na danych repozytorium tożsamości
Wymagania dotyczące systemu raportowego
Wymagane
85 Dostępność raportu procesów akceptacji (workflow)
Wymagania dotyczące systemu raportowego
Wymagane
86 Dostępność raportu historii zmian na użytkowniku wraz z osobą wykonującą zmianę
Wymagania dotyczące systemu raportowego
Wymagane
87 Dostępność raportu logowania do portalu samoobsługi
Wymagania dotyczące systemu raportowego
Wymagane
88 Dostępność raportu zmian na roli biznesowej Wymagania dotyczące systemu raportowego
Wymagane
89 Dostępność raportu tożsamości posiadających wybraną rolę biznesową
Wymagania dotyczące systemu raportowego
Wymagane
90 Dostępność raportu użytkowników uprzywilejowanych
Wymagania dotyczące systemu raportowego
Wymagane
91 Dostępność raportu kont na SI niezgodnych z stanem w SZT np.: przyznane niezgodne uprawnienia
Wymagania dotyczące systemu raportowego
Wymagane
92 Dostępność raportu użytkowników zablokowanych
Wymagania dotyczące systemu raportowego
Wymagane
93 Dostępność raportów wydajnościowych kluczowych komponentów oraz raportów pokazujących dostępność Systemu w określonym zakresie czasu
Wymagania dotyczące systemu raportowego
Opcjonalne
3.1.2. Wymagania techniczneNr
wymagania
Opis wymagania kategoria wymagań Poziom wymagalno
ści spełniany
przez system
94 Repozytorium tożsamości znajduje się w relacyjnej bazie danych lub usłudze LDAP
Wymagania dotyczące architektury repozytorium tożsamości
Wymagane
95 Repozytorium zapewnia możliwość transferu danych z środowiska produkcyjnego do testowego wraz z anonimizacją danych
Wymagania dotyczące architektury repozytorium tożsamości
Wymagane
96 Repozytorium pozwala na przechowywanie danych (dokumenty doc, pdf, zdjęcia) w postaci BLOB (ang. binary large object)
Wymagania dotyczące architektury repozytorium tożsamości
Wymagane
str. 12
97 Repozytorium pozwala na przechowanie struktury organizacyjnej
Wymagania dotyczące architektury repozytorium tożsamości
Wymagane
98 Repozytorium musi posiadać wydajność pozwalającą na obsługę co najmniej 52500 tożsamości użytkowników
Wymagania dotyczące architektury repozytorium tożsamości
Wymagane
99 System umożliwia uruchomienie mechanizmu szyfrowania protokołem SSL dla portalu samoobsługi SZT
Wymagania bezpieczeństwa Wymagane
100 Możliwość szyfrowania wybranych danych repozytorium tożsamości lub wszystkich (opcja konfiguracyjna wybierana przez Administratora)
Wymagania bezpieczeństwa Wymagane
101 Możliwość szyfrowanej komunikacji z systemami informatycznymi
Wymagania bezpieczeństwa Wymagane
102 Możliwość anonimizacji wybranych danych przy wykonywaniu kopii systemu produkcyjnego na system testowy
Wymagania bezpieczeństwa Wymagane
103 Szyfrowana transmisja pomiędzy warstwą aplikacji a repozytorium tożsamości
Wymagania bezpieczeństwa Wymagane
104 Warstwa aplikacji komunikując się z repozytorium sięga bezpośrednio do danych w bazie danych tożsamości
Wymagania bezpieczeństwa Wymagane
105 Możliwość odebrania uprawnień dla konta administratora bazy (konto z pełnymi uprawnieniami) oraz dystrybucji uprawnień do innych kont
Wymagania bezpieczeństwa Wymagane
106 Dostarczenie narzędzi deweloperskich do rozwoju konektorów
Wymagania dotyczące narzędzi deweloperskich
Wymagane
107 Możliwość tworzenia konektorów w oparciu o język Java lub C lub C++ lub C#
Wymagania dotyczące narzędzi deweloperskich
Opcjonalne
108 Dostarczenie narzędzi deweloperskich do rozwoju workflow
Wymagania dotyczące narzędzi deweloperskich
Wymagane
109 Możliwość eksportu/importu workflow Wymagania dotyczące narzędzi deweloperskich
Opcjonalne
110 Dostępność narzędzi umożliwiających wersjonowanie kodu
Wymagania dotyczące narzędzi deweloperskich
Opcjonalne
111 Możliwość modelowania workflow w trybie graficznym za pomocą obiektów graficznych
Wymagania dotyczące narzędzi deweloperskich
Wymagane
112 System ma umożliwiać skalowalność rozwiązania do maksymalnej liczby 100 tys. użytkowników wraz z zachowaniem wskaźników wydajnościowych zakładając że może to wymagać skalowania przez rozbudowę systemu o dodatkowe komponenty sprzętowe, programowe lub licencyjne
Wymagania dotyczące skalowalności
Wymagane
113 Możliwość wykonania pełnej kopii zapasowej bazy danych tożsamości SZT
Wymagania dotyczące kopii zapasowych
Wymagane
114 Możliwość wykonania kopii przyrostowej bazy danych tożsamości SZT
Wymagania dotyczące kopii zapasowych
Wymagane
115 Możliwość odtworzenia bazy danych tożsamości SZT do wybranego punktu w czasie
Wymagania dotyczące kopii zapasowych
Wymagane
116 Możliwość szyfrowania kopii zapasowej bazy danych SZT
Wymagania dotyczące kopii zapasowych
Opcjonalne
117 Dostępność powiadomień sms lub email do Wymagania dotyczące Wymagane
str. 13
wybranych alarmów, ostrzeżeń, zdarzeń systemowych
monitorowania
118 Dostępność statusu podstawowych komponentów SZT
Wymagania dotyczące monitorowania
Wymagane
119 System powinien posiadać możliwość zintegrowania z systemem monitoringu posiadanymi przez Zamawiającego tj. MS SCOM lub zapewniać własne narzędzia monitoringu
Wymagania dotyczące monitorowania
Wymagane
3.1.3. Wymagania niezawodnościoweNr
wymagania
Opis wymagania kategoria wymagań Poziom wymagalno
ści spełniany
przez system
120 Praca systemu w trybie ciągłym 24h / dobę / 7 dni w tygodniu / 365 dni w roku
Wymagania niezawodnościowe
Wymagane
121 Dostępność portalu samoobsługi 24h/ dobę / 7 dni w tygodniu / 365 dni w roku
Wymagania niezawodnościowe
Wymagane
122 System umożliwia uruchomienie mechanizmu zapewniającego wysoką dostępność - HA
Wymagania niezawodnościowe
Wymagane
3.1.4. Wymagania wydajnościoweNr
wymagania
Opis wymagania kategoria wymagań Poziom wymagalno
ści spełniany
przez system
123 Czas odpowiedzi systemu na dowolną akcję użytkownika podczas bieżących operacji transakcyjnych systemu poniżej 3 sekund zgodnie z wymaganiami testów wydajnościowych
Wymagania wydajnościowe Wymagane
124 Maksymalny czas generowania raportów poniżej 10 minut przy założeniu, że raport dla wszystkich tożsamości nie obejmie okresu dłuższego niż miesiąc
Wymagania wydajnościowe Wymagane
125 Maksymalny czas trwania procesu aktualizacji przez SZT wszystkich tożsamości w SI poniżej 30 minut (wymaganie nie obejmuje czasu przetwarzania po stronie SI)
Wymagania wydajnościowe Wymagane
3.1.5. Wymagania infrastrukturalneNr
wymagania
Opis wymagania kategoria wymagań Poziom wymagalno
ści spełniany
przez system
126 Dostarczenie sprzętu serwerowego Wymagania infrastrukturalne
Wymagane
str. 14
127 Dostarczenie licencji na bazy danych Wymagania infrastrukturalne
Wymagane
128 Dostarczenie licencji na systemy operacyjne Wymagania infrastrukturalne
Wymagane
129 Dostarczenie licencji na rozwiązania wirtualizacyjne
Wymagania infrastrukturalne
Opcjonalne
130 Dostarczenie licencji na rozwiązania wysokiej dostępności (HA)
Wymagania infrastrukturalne
Opcjonalne
3.1.6. Wymagania licencyjneNr
wymagania
Opis wymagania kategoria wymagań Poziom wymagalno
ści spełniany
przez system
131 Dostarczenie licencji do SZT pozwalających na połączenie 52500 użytkowników końcowych.
Wymagania licencyjne Wymagane
132 Dostarczenie licencji na wymagane konektory Wymagania licencyjne Wymagane
3.1.7. Oprogramowanie dedykowane
Niniejszy rozdział opisuje funkcjonalności Oprogramowania Dedykowanego, zaimplementowane w systemie SZT, do których Zamawiający posiada autorskie prawa majątkowe.
3.1.7.1. Synchronizacja atrybutów prostych z HCM do AD
Następujące atrybuty z SZT są synchronizowane do AD:1. Przełożony:
a. Pole w AD: manager,b. Pole w SZT: „Bezpośredni przełożony” wyznaczany przez SZT zgodnie z
dotychczasową logiką, zapisywana informacja to wartość pola „distinguishedName”
2. Numer telefonu:a. Pole w AD: telephoneNumber, mobileb. Pole w SZT: „Telefon służbowy” (HCM.PA0105.USTRY=020), „Telefon
komórkowy” (HCM.PA0105.USTRY=025)3. Nazwa sądu:
a. Pole w AD: companyb. Pole w SZT: „Jednostka gospodarcza” (na podstawie kodu
HCM.PA0001.BUKRS, nazwa pobierana ze słownika xml utrzymywanego w SZT)
4. Nazwa oddziału:a. Pole w AD: departmentb. Pole w SZT: „Wydział”, „Jednostka organizacyjna” – zgodnie z logiką:
o IF (Wydział = NULL) THEN department = NULL
str. 15
o IF (Wydział ≠ Jednostka organizacyjna) THEN department = Wydział | Jednostka organizacyjna
IF (Wydział = Jednostka organizacyjna) THEN department = Wydział
3.1.7.2. Dodawanie pracowników lub innych osób zatrudnionych do grupy w AD
Każdej przetwarzanej tożsamości SZT nadaje domyślną rolę „ Użytkownik Active Directory”. Każdej nowej tożsamości, dla której uruchomiony zostanie proces zatrudnienia nadana zostanie rola „Profil Exchange Basic”, której nadanie będzie skutkować dodaniem konta AD do grupy „SG-2007_ExchangeProfilBasic”.
3.1.7.3. Tryb symulacji provisioningu dla wskazanych jednostek
Dla wskazanych jednostek organizacyjnych, przełączenie SZT w tryb symulacji, w którym zmiany propagowane do systemów zarządzanych nie będą w nich zapisywane. Przełączanie będzie się odbywać poprzez wskazanie w pliku xml jednostek, dla których wyniki nocnego przetwarzania nie zostaną zapisane do systemów zarządzanych (provisioning do systemów zarządzanych dla tych jednostek nie wykona się i zakończy się zapisem do logów audytu). Wyniki symulacji dostępne będą jako operacje o nazwie SymulacjaProvisioningu w audyt logu. Aby wyłączyć tryb symulacji, należy usunąć z pliku konfiguracyjnego xml jednoski i ponownie uruchomić nocne przetwarzanie.
3.1.7.4. Mechanizm dystrybucji haseł inicjalnych i resetu haseł
1. SZT umożliwia samodzielną zmianę hasła zalogowanemu użytkownikowi:a. Na dowolne, zgodne z obecną polityką hasło w przypadku AD (brak
zmiany – funkcjonalność tak jak dotychczas)b. Na dowolne zgodne z obecną polityką hasło oznaczone jako hasło
inicjalne w przypadku CUA c. SZT umożliwia reset hasła z poziomu panelu głównego SZT dla
innego użytkownika. Reset jest realizowany poprzez wybór przycisku „Resetuj hasło użytkownika.”
d. Przełożony ma prawo resetować hasło dla swoich podwładnych,e. Lokalny informatyk ma prawo resetować hasło dla wszystkich
pracowników lub innych osób zatrudnionych w jednostkach, którymi zarządza.
f. Funkcjonalność jest dostępna dla zastępców „przełożonego” wyznaczonych zgodnie z obecnie zaimplementowaną logiką zastępstw (tzn. z użyciem funkcjonalności SZT „Czasowe przeniesienie uprawnień”).
2. Podczas procesu zatrudnienia bądź inicjalnego zasilenia (włączenia do SZT) system wysyła do przełożonego e-mail z informacją o loginie
str. 16
nowozatrudnionego użytkownika oraz do nowowłączonego w zakres użytkownika e-mail z linkiem do funkcjonalności zmiany hasła inicjalnego do CUA
3.1.7.5. Rozszerzenie mechanizmu korelacji po AD
SZT korelując tożsamość z kontem w HCM/CUA uwzględnia jako parametr korelacyjny również adres e-mail konta AD. Parametr ten jest sprawdzany w ostatnim etapie szukania korelacji dla konta CUA.Jako nadrzędny SZT traktuje adres e-mail konta AD. W przypadku zmiany adresu e-mail w AD zmiana ta jest propagowana również na konto CUA, jednak nie powoduje rozkorelowania konta CUA z tożsamością w przypadku braku loginu w IT105 w HCM.
3.1.7.6. Zakładanie skrzynki pocztowej dla użytkowników poza centralnym Exchange
Dla nowych tożsamości w jednostkach, w których nie jest wdrożony centralny Exchange, SZT wysyła mailowe powiadomienie:
Na adres administratorów przypisanych do obsługi jednostki, w której dokonano zatrudnienia
CC: helpdesk@ (adres I linii wsparcia). Reply-To: helpdesk@ (adres I linii wsparcia).
W przypadku braku adresu e-mail na tożsamości SZT, nie zakłada konta w CUA, dopóki adres e-mail na tożsamości nie jest wypełniany.
3.1.7.7. Zmiana mechanizmu eskalacji
SZT nie sprawdza czy pracownik lub inna osoba zatrudniona, do którego trafia wniosek jest AKTYWNY i W ZAKRESIE. SZT jednak sprawdza, czy pracownik lub inna osoba zatrudniona, do którego trafił wniosek jest Pracujący lub Delegowany w SAP HCM. W konsekwencji, wnioski trafiają do pracowników, którzy nie są w zakresie przetwarzania.
3.1.7.8. Tryb symulacji provisioningu dla wskazanych jednostek
Dla wskazanych jednostek organizacyjnych możliwe jest przełączenie SZT w tryb symulacji, w którym zmiany propagowane do systemów zarządzanych nie są w nich zapisywane.
str. 17
3.2. Architektura wykorzystywanego rozwiązania
3.2.1. Środowisko pracy SZT
System Zarzadzania Tożsamością działa w środowisku, które składa się w szczególności z:elementów dostarczonych przez wykonawcę wdrożenia:
serwerów stanowiących podstawę wdrożenia i eksploatacji SZT systemów operacyjnych baz danych aplikacji oprogramowania narzędziowego
oraz zapewnianych przez Zamawiającego platformy sprzętowej (tj. urządzeń magazynujących, urządzeń sieciowych) dwóch lokalizacji Centrów Obliczeniowych znajdujących się w odrębnych
lokalizacjach routerów w każdej z lokalizacji instalacji systemu. rozwiązań Hardware Load Balancer, wykorzystywanych do równoważenia
połączeń klienckich do systemu SZT, szaf typu Rack do instalacji serwerów. urządzeń pamięci masowej (macierz dyskowa). łączy WAN pomiędzy lokalizacjami przeznaczonymi dla serwerów SZT o
przepustowości 1Gbps. łączy WAN pomiędzy lokalizacjami serwerów SZT a sądami podlegającymi
wdrożeniu, o transferze od 2Mbps do 100Mbps.Szczegółowa specyfikacja wszystkich elementów tworzących SZT zawarta jest w Projekcie Biznesowo-Technicznym, będącym w posiadaniu Zamawiającego.
3.2.2. Architektura logiczna SZT
str. 18
Architektura logiczna systemu SZT została przedstawiona na rysunku poniżej:
3.2.3. Integracja z systemami informatycznymi Zamawiającego
Centralnym elementem systemu jest SailPoint IdentityIQ dostarczający funkcjonalności:
repozytorium tożsamości, portal użytkownika, silnik do obsługi procesów workflow moduł zarządzania uprawnieniami w systemach informatycznych moduł raportowy moduł recertyfikacji uprawnień.
Zakres integracji SZT z SI przedstawiony jest poniżej:
str. 19
Active Directory Do integracji został wykorzystany standardowy konektor do Active Directory dostarczany przez producenta. System SZT obsługuje jedną centralną domenę Active Directory.W ramach realizacji procesów zarządzania tożsamością w domenie Active Directory system SZT realizuje następujące operacje na obiektach w Active Directory:
Konta użytkownikówo Pobranie kont użytkowników wraz z ich atrybutamio Pobranie wybranego konta wraz z jego atrybutamio Modyfikacja wybranego konta poprzez zmianę atrybutówo Zmiana hasła dla wybranego kontao Włączenie kontao Wyłączenie kontao Odblokowanie kontao Utworzenie nowego konta
Grupyo Pobranie wybranej grupy wraz z atrybutamio Pobranie wszystkich grup wraz z atrybutamio Nadanie członkostwa w grupie dla wybranego kontao Odebranie członkostwa w grupie dla wybranego konta
str. 20
Serwer pocztowy Microsoft Exchange Zarządzanie skrzynkami pocztowymi pracowników lub innych osób zatrudnionych realizowane jest za pomocą konektora do domeny Active Directory.Zakres integracji obejmuje następujące operacje na skrzynkach pocztowych użytkowników:
Tworzenie nowej skrzynki, generowanie nowego adresu e-mail Modyfikacja aliasów pocztowych i adresu głównego Wyłączanie skrzynki dla użytkownika zwolnionego Włączanie skrzynki dla użytkownika ponownie zatrudnionego.
SAP CUA (Error: Reference source not found)Integracja z aplikacjami SAP ESS/MSS/LSO (moduł programu SAP służący do samoobsługi pracowniczej, menadżerskiej oraz moduł szkoleń e-learningowych) realizowane jest poprzez połączenie z SAP CUA (moduł programu SAP do zarządzania kontami i uprawnieniami użytkowników) za pomocą standardowo dostępnego w aplikacji IdentityIQ konektora do systemu SAP CUA. Konektor komunikuje się z systemem SAP CUA z wykorzystaniem wywołań metod ABAP oraz odczytywania danych z tabel.Zakres integracji z aplikacjami ESS/MSS/LSO poprzez SPA CUA obejmuje następującą funkcjonalność konektora:
Konta użytkownikówo Pobranie kont użytkowników wraz z ich atrybutamio Pobranie wybranego konta wraz z jego atrybutamio Modyfikacja wybranego konta poprzez zmianę atrybutówo Zmiana hasła dla wybranego konta (tylko dla samego CUA)o Włączenie kontao Wyłączenie kontao Utworzenie nowego konta (z hasłem inicjalnym dla CUA i wszystkich
mandantów: ESS/MSS/LSO) Grupy (Role w SAP CUA)
o Pobranie wybranej grupy wraz z atrybutamio Pobranie wszystkich grup wraz z atrybutamio Nadanie członkostwa w grupie dla wybranego kontao Odebranie członkostwa w grupie dla wybranego konta
SAP HCM Integracja z SAP HCM (moduł kadrowy programu SAP) ma na celu zasilenie systemu SZT informacjami o umowach (kontraktach) pracowników etatowych i rekordach dotyczących pracowników pozaetatowych (kontraktorach, stażystach itp.) oraz informacją o aktualnej strukturze organizacyjnej sądów powszechnych.Konektor komunikuje się z systemem SAP HCM z wykorzystaniem CPI-C, RFC, BAPI.
str. 21
Konektor do systemu SAP HCM pracuje w trybie „do odczytu”.Pobierane są informacje o:
pracownikach etatowych i pozaetatowych w formie rekordów stanowiących kontrakty z informacjami o danych pracowniczych,
strukturze organizacyjnej dotyczącej:o drzewa jednostek organizacyjnycho listy jednostek gospodarczycho listy stanowisk finansowycho struktury menadżerskiej opartej o stanowiska i stanowiska wirtualne
SZT działa w dwóch trybach: Wnioski (nadanie, odebranie uprawnień, blokada administracyjna)
realizowane są online Zasilanie SZT danymi, przetwarzania ich oraz przenoszenie do systemów
realizowane są w cyklu dobowym w ramach przetwarzania nocnego
Korelacja kont jest realizowana jako proces łączenia tożsamości z informacjami z innych systemów (kontami, umowami, etc.). Korelacja jest wrażliwa na zmiany – jeśli w systemie zmienią się dane używane do korelacji, co powoduje, że konto przestaje pasować do tożsamości. SZT odpina takie konto od tożsamości. Wyjątkiem są konta utworzone przez SZT, ponieważ dla nich korelacja jest realizowana na podstawie wewnętrznego identyfikatora.
str. 22
3.2.4. Role dostępowe zdefiniowane w SZT
Rola dostępowa definiuje zakres uprawnień tożsamości w portalu samoobsługowym SZT. Rola realizowana jest z wykorzystaniem standardowego obiektu roli w systemie SZT. Rola dostępowa agreguje systemowe obiekty Capabilities oraz Scope definiujące uprawnienia w portalu SZT.Poniżej przedstawiona został sposób implementacji ról dostępowych dla użytkowników SZT z podziałem na pełnione przez nich funkcje i realizowane zadania.
Administrator systemu SZT Rola super administratora aplikacji IdentityIQ. Rola daje wgląd do wszystkich funkcjonalności systemu, oraz umożliwia dokonywania w nich dowolnych zmian / tworzenia nowych obiektów itp. Rola wyłącza wszystkie ograniczenia mechanizmu zakresów (scoping). Rola nadawana poprzez wnioskowanie lub będąca częścią roli przypisywanej automatycznie.Użytkownik posiadający rolę Administratora systemu SZT może dokonywać dowolnych zmian w atrybutach obiektów w repozytorium tożsamości z pominięciem mechanizmów walidacji zaimplementowane w procesach workflow.Administrator tożsamości Rola daje możliwość przeglądu, wyszukiwania i modyfikacji: atrybutów (tylko modyfikowalnych) wszystkich tożsamości, grup roboczych tożsamości, przeglądu ryzyk tożsamości. Pozwala na ręczną korelację kont, oraz na przenoszenie kont pomiędzy kostkami tożsamości. Rola nadawana poprzez wnioskowanie lub będąca częścią roli automatycznej.Operator systemu Rola reprezentująca administratora integracji z systemami zarządzanymi i źródłowymi oraz nadzorcę nad zadaniami agregacji, odświeżania tożsamości. Rola daje możliwość przeglądu, wyszukiwania i modyfikacji obiektów w repozytorium tożsamości. Umożliwia dostęp do przeglądu i zarządzania katalogiem uprawnień. Rola nadawana poprzez wnioskowanie lub będąca częścią roli automatycznej.Pracownik HelpDesk Rola daje możliwość wnioskowania o uprawnienia/modyfikacje kont/ rejestracje tożsamości dla innych tożsamości oraz pozwala na przegląd statusów wniosków. Rola nadawana poprzez wnioskowanie lub będąca częścią roli automatycznej.Użytkownik SZT Rola reprezentująca zwykłego użytkownika systemu. Rola daje możliwość wnioskowania o uprawnienia dla siebie, zarządzania kontami / hasłami własnymi. Rola automatycznie przypisywana każdej tożsamości autorytatywnej (mającej źródło w systemie kadrowym lub zarejestrowanej ręcznie) w SZT.Menadżer Rola reprezentująca przełożonego pracownika lub innej osoby zatrudnionej. Rola daje możliwość wnioskowania o uprawnienia dla siebie, bezpośrednio podległych pracowników oraz innych podległych osób, zarządzania
str. 23
kontami / hasłami własnymi, bezpośrednio podległych pracowników lub innych podległych osób. Menadżerem jest każdy kto ma zidentyfikowanych podwładnych. Rola nadawana automatycznie.Oficer bezpieczeństwa Rola reprezentująca audytora oraz administratora certyfikacji. Rola daje możliwość tworzenia oraz nadzorowania kampanii certyfikacji uprawnień i ról, generowania raportów z naruszeń oraz z przebiegu certyfikacji oraz podglądu ról. Nadaje uprawnienia do zarządzania politykami bezpieczeństwa. Rola nadawana poprzez wnioskowanie lub będąca częścią roli automatycznej.Audytor Rola nadaje możliwość generowania raportów oraz podglądu: ról, repozytorium tożsamości, wniosków oraz aktywności. Rola nadawana poprzez wnioskowanie lub będąca częścią roli automatycznej.
Poniższe zestawienie przestawia podstawowy model ról i uprawnień zaimplementowany w SZT:
Model ról podstawowych w systemie SZTDostępne
funkcjonalności / Nazwa roli - opis
Administrator systemu SZT
Administrator tożsamości
Operator systemu
Pracownik HelpDesk
Użytkownik SZT
Menadżer
Właściciel roli SZT
Oficer bezpieczeństwa
Audytor
Właściciel systemu integrowanego
Panel kontrolny: ✓
Edytuj mój panel
kontrolny ✓
Edytuj moje preferencje ✓
Skrzynka odbiorcza ✓
Skrzynka nadawcza ✓
Przypisane zadania (moje) ✓
Zakładka 'Definiuj': ✓ ✓ ✓ ✓
Aplikacje ✓ ✓
Role ✓ ✓ ✓ ✓(1) ✓ (1)
Tożsamości ✓ ✓ ✓ ✓ (1) ✓ (1) ✓
Katalog Uprawnień ✓ ✓
✓
Grupy (populacje i
grupy robocze) ✓ ✓ ✓
Polityki bezpieczeństw
a (definicja) ✓ ✓ (2) ✓ (1)
Model ryzyka Tożsamości
(konfiguracja) ✓
Model ryzyka aplikacji
(konfiguracja) ✓
str. 24
Model ról podstawowych w systemie SZTDostępne
funkcjonalności / Nazwa roli - opis
Administrator systemu SZT
Administrator tożsamości
Operator systemu
Pracownik HelpDesk
Użytkownik SZT
Menadżer
Właściciel roli SZT
Oficer bezpieczeństwa
Audytor
Właściciel systemu integrowanego
Procesy biznesowe ✓
Zdarzenia Lifecycle Manager ✓
Zakładka 'Monitoruj': ✓ ✓ ✓ ✓
Certyfikacje ✓ ✓ ✓ (3)
Zadania (systemowe, np. agregacja
kont) ✓ ✓
Zakładka 'Analizuj': ✓ ✓ ✓ ✓ ✓ ✓ ✓
Rozszerzone analizy
✓ (4) ✓ (7) ✓ (8) ✓ (9) ✓ (10) ✓ (11) ✓ (11)
Raporty ✓ (4) ✓ (7) ✓ (8) ✓ (10) ✓ (11) ✓ (11)
Zakładka 'Zarządzaj': ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Moje przeglądy dostępów (zadania
certyfikacji) ✓ ✓ ✓ ✓ (5)
Wnioski o dostęp ✓ (4) ✓ (4) ✓ (4) ✓ (5)
Zadania (Zlecenia do wykonania) ✓ ✓ ✓ ✓ (5)
Naruszenia polityk
bezpieczeństwa ✓ (4) ✓ (4) ✓ (4) ✓ (5) ✓ (6) ✓ (4) ✓ (4)
Wyniki ryzyk Tożsamości ✓ ✓ ✓ ✓
Wyniki ryzyk aplikacji ✓ ✓ ✓
Korelacja kont Tożsamości ✓ ✓ ✓
Wnioski wsadowe ✓ ✓
Wnioskowanie: Edycja/Tworzenie roli ✓ ✓ ✓
Wnioskowanie: Rejestruj nową Tożsamość ✓ ✓ ✓ ✓
Wnioskowanie: Edytuj Tożsamość ✓ ✓ ✓ ✓
Wnioskowanie: Przeglądaj Tożsamości: ✓ ✓ ✓ ✓ ✓ ✓
Dla mnie ✓ ✓ ✓ ✓ ✓ ✓
str. 25
Model ról podstawowych w systemie SZTDostępne
funkcjonalności / Nazwa roli - opis
Administrator systemu SZT
Administrator tożsamości
Operator systemu
Pracownik HelpDesk
Użytkownik SZT
Menadżer
Właściciel roli SZT
Oficer bezpieczeństwa
Audytor
Właściciel systemu integrowanego
Dla innych ✓ ✓ ✓ ✓ (6)
Wnioskowanie: Wnioskuj o dostęp: ✓ ✓ ✓ ✓ ✓ ✓
Dla mnie ✓ ✓ ✓ ✓ ✓ ✓
Dla innych ✓ ✓ ✓ ✓ (6) ✓(12)
Wnioskowanie: Zarządzaj kontami: ✓ ✓ ✓ ✓ ✓ ✓
Dla mnie ✓ ✓ ✓ ✓ ✓ ✓
Dla innych ✓ ✓ ✓ ✓ (6)
Wnioskowanie: Zmień/Resetuj hasło: ✓ ✓ ✓ ✓ ✓ ✓
Dla mnie ✓ ✓ ✓ ✓ ✓ ✓
Dla innych
Sekcja DEBUG ✓
Zakładka 'Ustawienia systemu' ✓
3.2.5. Podstawowe procesy workflow zdefiniowane w SZT
Proces workflow Zakres procesuZatrudnienie pracownika Proces inicjowany jest dla wszystkich pracowników (kontraktów w
systemie SAP HCM).Dla pracowników nie objętych zakresem wdrożenia tworzone są nieaktywne obiekty tożsamości i nie są tworzone konta użytkowników w Active Directory i w innych systemach informatycznych.Dla pracowników objętych zakresem wdrożenia tworzone są aktywne obiekty tożsamości oraz tworzone inicjalne konta w Active Directory oraz nadawane inicjalne uprawnienia w systemach informatycznych wynikające z automatycznego przypisania ról w zależności od umiejscowienia pracownika w strukturze organizacyjnej bądź innych atrybutów tożsamości.Do utworzenia inicjalnych kont oraz nadania uprawnień wykorzystywany jest jako podproces Proces wykorzystuje jako jeden z elementów (podproces) Proces automatycznego przypisywania ról (patrz: Proces: Automatyczne przypisywanie ról).Inicjalne hasło do nowego konta w Active Directory zakładanego dla pracownika przekazywane jest do bezpośredniego przełożonego pracownika.
Automatyczne przypisywanie ról
Proces inicjowany jest dla wszystkich pracowników objętych wdrożeniem systemu SZT. Role, które mogą być podmiotem procesu wymagają oznaczenia jako role przypisywane automatyczne oraz posiadania zdefiniowanych reguł przypisania.Proces nadaje pracownikom nowe role spełniające warunki
str. 26
przypisania.Proces odbiera pracownikom role nie spełniające warunków przypisania.
Inicjalna dystrybucja hasła do konta Active Directory
Proces inicjowany jest w przypadku automatycznego zakładania przez SZT nowego konta użytkownika w Active Directory dla zatrudnianych pracowników.
Zwalnianie pracownika Działanie procesu obejmuje tożsamości pracowników objętych wdrożeniem systemu SZT.
Administracyjne blokowanie/odblokowywanie tożsamości
Proces umożliwia administracyjne zablokowanie dowolnej tożsamości w SZT.Proces umożliwia administracyjne odblokowanie wyłącznie tożsamości zablokowanych administracyjnie.Automatycznie blokowane są dostępy do kont użytkownika w systemach zintegrowanych z SZT.
Wnioskowanie o role i uprawnienia
Status tożsamości pracownika dla którego składany jest wniosek jest „Objęty Wdrożeniem” oraz „Aktywny”.
Proces czasowego przeniesienia uprawnień
Przenoszenie uprawnień realizowane jest wyłącznie dla pracowników będących w tej samej jednostce organizacyjnej.
Zmiana hasła Zmiana hasła dostępny jest dla pracowników objętych zakresem wdrożenia
Reset hasła do konta Active Directory
Proces obejmuje swoim zakresem tworzenie tożsamości pracowników nie objętych zakresem wdrożenia – tożsamości pozaetatowe, dla których w wyniku braku danych o PESEL w SAP HCM nie zostaną utworzone tożsamości autorytatywne.
Modyfikacja tożsamości Użytkownicy, których tożsamości zostały utworzone na podstawie danych z kontraktu głównego z SAP HCM mogą modyfikować własną tożsamość w zakresie atrybutów:• Numer telefonu komórkowego• Numer telefonu stacjonarnego
3.2.6. Architektura sprzętowa
Poniżej przedstawiony został diagram implementacji rozwiązania SZT w architekturze sprzętowej z podziałem na lokalizację podstawową, zapasową oraz środowisko dewelopersko testowe.
str. 27
Lokalizacje, w jakich zaimplementowane są komponenty systemu SZT:Opis
Lokalizacja podstawowa / Ośrodek podstawowy - dla produkcyjnego środowiska SZT oraz środowiska DEV/TEST
Lokalizacja zapasowa / Ośrodek zapasowy - dla produkcyjnego środowiska SZT
3.2.7. Systemy operacyjne Jako system operacyjny wykorzystany jest MS Windows Server 2012 r2 x64.
str. 28
Serwer fizyczny Wirtualizacja Serwer wirtualny Opis
PROD1 (MS W2012R2x64) HyperV1
SO APP11 Środowisko produkcyjnych serwerów aplikacyjnych (lokalizacja podstawowa)
Zainstalowane: 2 serwery aplikacyjne Tomcat, SailPoint IIQ
PROD2 (MS W2012R2x64) HyperV2
SO DB11 Środowisko produkcyjnej bazy danych (lokalizacja podstawowa)
Zainstalowane: MS SQL Server
PROD3 (MS W2012R2x64) HyperV3
SO APP21 Środowisko zapasowe produkcyjnych serwerów aplikacyjnych (lokalizacja zapasowa)
Zainstalowane: 2 serwery aplikacyjne Tomcat, SailPoint IIQ
PROD4 (MS W2012R2x64) HyperV4
SO DB21 Środowisko zapasowej bazy danych (lokalizacja zapasowa)
Zainstalowane: MS SQL Server
DEV1 (MS W2012R2x64) HyperV DEV1
SO APPDEV1 Środowisko testowego serwera aplikacyjnego DEV/TEST (lokalizacja podstawowa)
Zainstalowane: serwer aplikacyjne Tomcat, SailPoint IIQ
SO DBDEV1 Środowisko testowej bazy danych DEV/TEST
(lokalizacja podstawowa)
Zainstalowane: MS SQL Server
Rozwiązanie korzysta z następującego oprogramowania:Nazwa Producenta Produkt Opis
Sailpoint Sailpoint IdentityIQ 6.4 Centralny komponent system zarządzania tożsamością (SZT)
Microsoft
Hyper-V 3.0 Technologia wirtualizacjiWindows Server 2012 r2 System operacyjny
Microsoft SQL Server 12 System zarządzania relacyjną bazą danych
Apache Apache Tomcat Serwer aplikacyjnyApache Subversion (SVN) System do wersjonowania kodu
str. 29
Nazwa Producenta Produkt Opis
Oracle Oracle Java 7 Środowisko uruchomieniowe Java
3.2.8. Konfiguracja wirtualizacji i HAJako platforma wirtualizacyjna został wykorzystany Microsoft Hyper-V 2012 R2 w pełnej wersji (z graficznym interfejsem użytkownika). Dostęp do hostów realizowany jest tylko w odseparowanej sieci zarządzającej poprzez połączenie RDP. Do zapewnienia wysokiej dostępności wykorzystywana jest funkcjonalność klastrowania hostów (Failover Cluster).
3.2.9. Konfiguracja sieciowa HyperVKonfigurację sieciową HyperV przedstawia poniższy rysunek:
Każdy z serwerów fizycznych, których rolą jest wirtualizacja jest wyposażony w cztery gigabitowe porty sieciowe.
3.2.10. Specyfikacja baz danychJako baza danych został wykorzystany MS SQL Server 2012 na dwóch serwerach produkcyjnych baz danych, po jednym w każdej z lokalizacji. Dane z lokalizacji podstawowej (DB01) są replikowane w czasie rzeczywistym do instancji w lokalizacji zapasowej. Zastosowano replikację bazującą na transakcjach (Database Mirroring). Dodatkowo, w lokalizacji podstawowej zainstalowano środowisko dewelopersko-testowe, a w jego ramach, również serwer baz danych MS SQL 2012.
Nazwa OpisDB PROD11 Podstawowa baza danych MS SQL dla środowiska produkcyjnego
DB PROD21 Redundantna baza danych MS SQL dla środowiska zapasowego
str. 30
Nazwa OpisDB DEV1 Baza danych MS SQL dla systemu DEV/TEST
3.2.11. Wysoka dostępnośćDla zwiększenia dostępności został wykorzystany mechanizm dublowania bazy danych do instancji zapasowej (Database Mirroring). Mirroring bazy danych utrzymuje dwie kopie wybranej bazy danych na różnych instancjach serwera SQL. Jedna instancja serwera bazy danych obsługuje połączenia od klientów (serwer główny). Druga instancja działa w trybie czuwania (serwer lustrzany). Na instancję zapasową kopiowane są na bieżąco transakcje SQL.
3.2.12. Specyfikacja serwerów fizycznychSerwery w poniższej specyfikacji zapewniają możliwość ewidencji w Repozytorium co najmniej 52500 tożsamości.
Nazwa Opis
«server» DEVTEST1
HP DL360 Gen9 8SFF, 2USN: CZJ6010FKY
«server» PROD1
HP DL360 Gen9 8SFF, 2USN: CZJ60109CN
«server» PROD2
HP DL360 Gen9 8SFF, 2USN: CZJ60109CM
«server» PROD3
HP DL360 Gen9 8SFF, 2USN: CZJ60109CP
«server» PROD4
HP DL360 Gen9 8SFF, 2USN: CZJ60109CL
3.2.13. Komponenty infrastruktury rozwiązania Zamawiającego
Poniżej wymieniono dodatkowe komponenty infrastruktury rozwiązania zapewnione przez Zamawiającego:
Nazwa OpisHardware Load Balancer 1
Load Balancer realizujący dostęp http/https do aplikacji SZT w lokalizacji podstawowej
Hardware Load Balancer 2
Load Balancer realizujący dostęp http/https do aplikacji SZT w lokalizacji zapasowej
Macierz1 Macierz dyskowa dla wszystkich serwerów SZT umieszczonych w lokalizacji podstawowej. Wymagana przestrzeń danych do uruchomienia wszystkich
str. 31
Nazwa Opismaszyn wirtualnych oraz składowania danych z bazy danych.
Macierz2 Macierz dyskowa dla wszystkich serwerów SZT umieszczonych w lokalizacji zapasowej. Wymagana przestrzeń danych do uruchomienia wszystkich maszyn wirtualnych oraz składowania danych z bazy danych.
«router» Router1 Urządzenia sieciowe w lokalizacji podstawowej, umożliwiające dostęp sieciowy użytkowników końcowych do środowiska produkcyjnego
«router» Router2 Urządzenia sieciowe w lokalizacji zapasowej, umożliwiające dostęp sieciowy użytkowników końcowych do środowiska produkcyjnego
«router» RouterDT Urządzenia sieciowe umożliwiające dostęp sieciowy użytkowników końcowych do środowiska DEV/TEST
3.2.14. Anonimizacja danych
W ramach wdrożenia systemu SZT zostało dostarczone narzędzie umożliwiające anonimizację danych w repozytorium tożsamości w przypadku wykonywania eksportu danych ze środowiska produkcyjnego oraz ich importu do środowiska testowego lub deweloperskiego.Anonimizacja danych polega na wykonaniu eksportu danych ze źródłowego systemu SZT do pliku XML, uruchomieniu narzędzia anonimizującego a następnie zaimportowaniu zanonimizowanego pliku wynikowego w środowisku docelowym.Anonimizacja swoim zakresem obejmuje dane w repozytorium SZT.Anonimizacji nie podlegają dane źródłowe w zintegrowanych systemach:
SAP HCM Active Directory Exchange SAP CUA (ESS/MSS/LSO)
4. Zobowiązania Wykonawcy
4.1. Dostawa licencji dla użytkowników Systemu Zarządzania Tożsamością
W zakres zobowiązań Wykonawcy wchodzą: dostawa dodatkowych 3.500 licencji zapewniających zarządzanie kontami
pracowników etatowych oraz dostawa 4.000 licencji pozwalających na zarządzanie kontami
Użytkowników Zewnętrznych dla systemu posiadanego przez Zamawiającego lub równoważnych zgodnie z zasadami równoważności opisanymi w rozdziale 5.
str. 32
Dostawy licencji dla pracowników etatowych oraz dla Użytkowników Zewnętrznych powinny zostać zrealizowane w terminach przewidzianych w harmonogramie ramowym.
4.2. Zapewnienie wsparcia gwarancyjnego i serwisowego dla Systemu Zarządzania Tożsamością
W zakres zobowiązań Wykonawcy wchodzi zapewnienie: wsparcia producenta Oprogramowania Gotowego dla użytkowanych przez
Zamawiającego 52.500 licencji. Obowiązujące wsparcie producenta Oprogramowania Gotowego zakończyło się w czerwcu 2017 r.
wsparcia producenta Oprogramowania Gotowego dla dostarczonych przez Wykonawcę dodatkowych 3.500 licencji dla pracowników etatowych,
wsparcia producenta Oprogramowania Gotowego dla dostarczonych przez Wykonawcę 4.000 licencji dla Użytkowników zewnętrznych,
wsparcia dla Oprogramowania Dedykowanego, wykorzystywanego przez Zamawiającego,
wsparcia dla infrastruktury na bazie której działa produkcyjnie SZT, składającej się z:
o serwerów stanowiących podstawę wdrożenia i eksploatacji SZT. Specyfikacja urządzeń zawarta jest w rozdziale 3.2.12 Specyfikacja serwerów fizycznych.
o systemów operacyjnych. Specyfikacja systemów zawarta jest w rozdziale 3.2.7 Systemy operacyjne
o baz danych. Specyfikacja baz danych zawarta jest w rozdziale 3.2.10 Specyfikacja baz danych
Wymagane terminy zapewnienia wsparcia zostały określone w rozdziale Error:Reference source not found Error: Reference source not found - dla zapewnienia wsparcia wobec systemu SZT, użytkowanego przez Zamawiającego oraz w rozdziale 5.12 Harmonogram ramowy dla rozwiązaniarównoważnego.
4.3. Rozwój funkcjonalności SZT – Modyfikacje Systemu
W związku z uruchomieniem i produkcyjnym wykorzystaniem systemu SZT zidentyfikowano potrzeby w zakresie wprowadzenia modyfikacji oraz rozwoju funkcjonalności Systemu Zarządzania Tożsamością.
Przedmiotem zamówienia jest również dostosowanie SZT, posiadanego przez Zamawiającego do potrzeb biznesowych lub technicznych. Zamawiający zakłada możliwość zlecania analiz biznesowo-technicznych oraz Modyfikacji w Systemie Zarządzania Tożsamością w ramach puli godzin
str. 33
rozwojowych. Pod pojęciem Modyfikacji Systemu Zamawiający rozumie się w szczególności dodanie nowych funkcjonalności, zmiany kodu źródłowego inne niż wynikające z usługi wsparcia i serwisu. Zamawiający może zlecić Wykonawcy Modyfikacje systemu, których pracochłonność liczona jest w wymiarze ……… godzin roboczych w okresie trwania usługi wsparcia technicznego i serwisu. Stawka godzinowa powinna określać uśrednioną wartość godziny roboczej dla niżej wymienionych czynności:
zarządzanie projektem, analiza potrzeb w zakresie nowych funkcjonalności SZT, rozbudowa systemu, testowanie aplikacji, opracowanie oraz aktualizacja dokumentacji projektowej w tym szkoleń
elearningowych udzielanie konsultacji merytorycznych.
Zmiany w zakresie funkcjonalności SZT będą zlecane przez Zamawiającego na podstawie dokumentów stanowiących wynik analizy przeprowadzonej przez Wykonawcę dla danej funkcjonalności. Analiza powinna zawierać w szczególności: specyfikację wymagania, proponowane scenariusze rozwiązania, oszacowanie czasochłonności realizacji zadania, zasoby niezbędne do realizacji zadania, harmonogram prac, szacowaną oraz faktycznie zrealizowaną czasochłonność analizy biznesowo-technicznej.Przeprowadzenie analizy w ramach rozwoju funkcjonalności systemu oraz udokumentowanie jej wyników będzie przedmiotem odbioru akceptacyjnego przez Zamawiającego i będzie podstawą rozliczenia godzin wykorzystanych na prace analityczne. Wykonawca ma obowiązek przystąpić do analizy w terminie nie późniejszym niż 3 dni robocze od daty zlecenia analizy przez Zamawiającego.Dokument analizy będzie każdorazowo podstawą dla Zamawiającego do zlecenia Modyfikacji Systemu na następnie do rozliczenia prac Wykonawcy. Wzór formularza, na podstawie którego zlecane będą zadania analityczne stanowi Załącznik 6.1 Formularz wniosku o Modyfikację
Procedura zgłaszania zleceń Modyfikacji oraz kanały komunikacji.a. Zgłoszenia Modyfikacji wykonywane będą za pośrednictwem:
i. systemu zgłoszeniowego udostępnionego przez Zamawiającego (podstawowy).
ii. za pośrednictwem innego systemu zgłoszeniowego wskazanego przez Zamawiającego (dodatkowy).
Dodatkowe kanały komunikacji wykorzystywane będą po uzgodnieniu z Wykonawcą, w tym w przypadku niedostępności kanału podstawowego.
str. 34
b. Strony ustalają w drodze porozumienia pracochłonność i termin wykonania Modyfikacji. Od momentu przedstawienia opisu Modyfikacji Wykonawca zobowiązany jest w ciągu nie więcej niż pięciu dni roboczych przedstawić szacowaną wycenę co do pracochłonności realizacji prac oraz terminu wykonania pod rygorem naliczenia kar umownych opisanych szczegółowo w Umowie. Za czas potrzebny do wyceny Modyfikacji Wykonawcy nie przysługuje odrębne wynagrodzenie
c. Zamawiający potwierdza zlecenie Modyfikacji lub rezygnuje z niego.d. Potwierdzenie zlecenia Modyfikacji Systemu oznacza uzgodnienie
przez strony terminu wykonania Modyfikacji oraz jej pracochłonności. Datą od której jest liczony termin realizacji Modyfikacji jest datą potwierdzenia zlecenia. Zamawiający może wstrzymać wykonanie Modyfikacji ze względu na pojawienie się innych priorytetowych modyfikacji lub ustanie potrzeby wykonania tej modyfikacji.
e. Przed przystąpieniem do wykonania Modyfikacji Systemu, Wykonawca przedstawia Zamawiającemu do akceptacji projekt zmian z elementami wskazanymi przez Zamawiającego. Zamawiający dokona akceptacji projektu zmian lub zgłosi uwagi w terminie nie dłuższym niż 2 dni robocze od dnia przedstawienia projektu. W przypadku zgłoszenia uwag, Wykonawca przedstawi ponownie projekt do akceptacji w terminie nie dłuższym niż 2 dni robocze.
f. Wykonawca przystępuje do wykonania Modyfikacji po akceptacji projektu zmian przez Zamawiającego.
g. Po wykonaniu Modyfikacji Wykonawca przeprowadza testy zmian funkcjonalnych a następnie przedstawia Zamawiającemu nową wersję aplikacji Systemu i/lub środowiska technologicznego systemu wraz ze stosowną dokumentacją.
h. Na podstawie scenariuszy testowych i zgodnie z kryteriami określonymi w rozdziale nr 4.5 Testy, Zamawiający weryfikuje przekazaną wersję sprawdzając, czy w zmodyfikowanej nowej wersji aplikacji systemu zostały uwzględnione wymagania określone na formularzu zgłoszenia oraz w zaakceptowanym przez Zamawiającego projekcie zmian, a także czy przekazana wersja nie zawiera błędów i dokumentacja jest kompletna.
i. Wyniki weryfikacji Zamawiający przekazuje Wykonawcy drogą elektroniczną w postaci raportu z testowania wersji.
j. W przypadku zgłoszenia zastrzeżeń przez Zamawiającego względem dostarczonej Modyfikacji, Wykonawca dokona stosownych poprawek. Po ponownym dostarczeniu przez Wykonawcę Modyfikacji zostanie przeprowadzony jej odbiór zgodnie z procedurą opisaną w pkt. g – i. Terminowa realizacja Modyfikacji będzie dochowana pod warunkiem, że bezusterkowy odbiór nastąpi w terminie ustalonym zgodnie z pkt. b.
k. W przypadku braku błędów uniemożliwiających poprawną i zgodną z określonymi kryteriami jakościowymi eksploatację zmodyfikowanej aplikacji Zamawiający dokonuje odbioru nowej wersji aplikacji.
str. 35
l. Prawidłowość wykonania Modyfikacji zostanie potwierdzona podpisanym bez zastrzeżeń przez obie Strony Protokołem odbioru Modyfikacji.
4.4. Migracja systemu do wersji 7
Wykonawca odpowiedzialny będzie za przeprowadzenie aktualizacji wersji systemu SailPoint 6.4 , obecnie użytkownej przez Zamawiającego do wersji 7 przy zachowaniu wszystkich funkcjonalności oraz danych zgromadzonych w systemie i zapewnieniu ciągłości działania wykorzystywanego systemu. W ramach aktualizacji Wykonawca przedstawi do akceptacji Zamawiającemu plan przeprowadzenia tego procesu wraz z opisem planu migracji, rejestrem ryzyk, zakresem działań niezbędnych do podjęcia przez Wykonawcę oraz Zamawiającego oraz scenariuszami testów wymaganych do potwierdzenia poprawności przeprowadzenia procesu aktualizacji wersji.
4.5. TestyW ramach przedmiotu niniejszego postępowania Zamawiający oczekuje przeprowadzenia następujących testów:
4.5.1. Testy poprawności procesu migracji do nowej wersji oprogramowania SailPoint
Testy poprawności procesu aktualizacji wersji systemu będą realizowane w środowisku testowym, na podstawie scenariuszy przedstawionych przez Wykonawcę i zaakceptowanych przez Zamawiającego. Pozytywny wynik testów jest warunkiem koniecznym przeprowadzenia aktualizacji wersji systemu w środowisku produkcyjnym.Odbiór poprawności przeprowadzenia aktualizacji wersji systemu nastąpi pod warunkiem:
uzyskania pozytywnych wyników testów akceptacyjnych, realizowanych na środowisku testowym oraz dodatkowo
pod warunkiem braku błędów krytycznych w okresie miesiąca kalendarzowego od uruchomienia nowej wersji systemu na środowisku produkcyjnym.
4.5.2. Testy nowych funkcjonalności Modyfikacji Oprogramowania Dedykowanego
Testy poprawności procesu migracji wersji systemu będą realizowane w ramach Modyfikacji Oprogramowania, zlecanych przez Zamawiającego.
str. 36
Pozytywny wynik testów potwierdzony przez Zamawiającego, jest warunkiem koniecznym do uzyskania akceptacji produkcyjnego wdrożenia nowej wersji Oprogramowania Dedykowanego, zawierającej nową funkcjonalność lub pakiet nowych funkcjonalności.
4.5.3. Cykliczne testy wydajnościowe
Rozbudowa systemu o nowe funkcjonalności oraz o przetwarzanie dodatkowych 4 tysięcy kont technicznych musi zapewniać wydajność systemu SZT, spełniającą kryteria zdefiniowane w rozdziale 3.1.4 Wymagania wydajnościowe. Wymagania te zostaną zrealizowane i potwierdzone przez wykonawcę testami wydajnościowymi w terminach zleconych przez zamawiającego, nie częściej niż jeden raz w roku.
Testy wydajnościowe zostaną przeprowadzone przy wykorzystaniu narzędzia pozwalającego na przeprowadzenie symulacji pracy realnych użytkowników końcowych. Poniżej przedstawione zostały wymagane scenariusze testowe:
Scenariusz testowy Ilość iteracji
Warunki symulacji Maksymalny czas oczekiwania
Oczekiwanie na wyświetlanie formularza edycji atrybutów tożsamości
3 100 użytkowników równoległych
3 sekundy 500 użytkowników
równoległych3 sekundy
2000 użytkowników równoległych
5 sekund
Oczekiwanie na wyświetlanie formularza resetu hasła
3 100 użytkowników równoległych
3 sekundy
500 użytkowników równoległych
3 sekundy
2000 użytkowników równoległych
5 sekund
Oczekiwanie na wyświetlenie ekranu akceptacji wybranego wniosku workflow
3 100 użytkowników równoległych
3 sekundy
500 użytkowników równoległych
3 sekundy
2000 użytkowników równoległych
5 sekund
Odpowiedź systemu na wysłanie formularza wniosku o przyznanie roli
3 100 użytkowników równoległych
3 sekundy
500 użytkowników równoległych
3 sekundy
2000 użytkowników równoległych
5 sekund
Oczekiwanie na raport systemowy
3 10 użytkowników równoległych
10 minut
str. 37
20 użytkowników równoległych
10 minut
50 użytkowników równoległych
20 minut
Oczekiwanie na replikację zmian wykonanych na atrybutach HCM do docelowego SI
3 100 wykonanych zmian atrybutów HCM
30 minut
500 wykonanych zmian atrybutów HCM
30 minut
2000 wykonanych zmian atrybutów HCM
45 minut
Wynik testów wydajnościowych uznaje się za pozytywny jeśli 100% odpowiedzi serwera aplikacyjnego jest poprawnych, a 95% odpowiedzi jest lepszych od progu akceptacji określonego w Tabeli powyżej w kolumnie Maksymalny czas oczekiwania.
4.5.4. Cykliczne testy niezawodnościowe
Zamawiający trzykrotnie w czasie obowiązywania Umowy przeprowadzi ocenę spełnienia przez SZT kryteriów niezawodnościowych, zdefiniowanych w rozdziale 3.1.3 Wymagania niezawodnościowe.Wynik testów niezawodności uznaje się za pozytywny, gdy występuje zgodność oczekiwanego wyniku ze Scenariusza testów stworzonego przez Wykonawcę z faktycznym stanem po zakończeniu danego przypadku testowego.
4.5.5. Kryteria akceptacji testów
Wynik testów funkcjonalnych dla funkcjonalności realizowanych w ramach Modyfikacji Systemu uznaje się za pozytywny, gdy występuje zgodność opisu oczekiwanego wyniku ze Scenariusza testów stworzonego przez Wykonawcę, z faktycznym stanem po zakończeniu danego przypadku testowego, w warunkach określonych w danym przypadku testowym.
Wynik testów funkcjonalnych uznaje się za negatywny, gdy którykolwiek ze składowych wyników rzeczywistych określonych w scenariuszu testów, stworzonym przez Wykonawcę, różni się od oczekiwanego.
str. 38
4.5.6. Scenariusze testoweW zakresie testów nowych funkcjonalności, przed rozpoczęciem testów, obowiązkiem wykonawcy jest opracowanie szczegółowych scenariuszy testowych i przedstawienie ich do akceptacji Zamawiającego.
Scenariusze testów podlegają procesowi odbioru i akceptacji przez Zamawiającego, którego kryterium jest ocena merytoryczna dokumentu. Zamawiający przekazuje uwagi Wykonawcy niezwłocznie (jednak w terminie nie dłuższym niż 7 dni), Wykonawca jest zobowiązany je uwzględnić w terminie 3 dni roboczych.
4.6. Dostawa /rozbudowa platformy sprzętowej
Przedmiot zamówienia nie obejmuje dostawy lub rozbudowy infrastruktury systemowej.W przypadku Modyfikacji Systemu, zleconej Wykonawcy przez Zamawiającego Wykonawca jest odpowiedzialny za wskazanie w ramach analizy przedwdrożeniowej, koniecznej rozbudowy infrastruktury, w zakresie niezbędnym do spełnienia wymagań wydajnościowych i niezawodnościowych o ile taka rozbudowa będzie konieczna.
4.7. Poziom i zasady udzielanego wsparcia technicznego i serwisu (SLA)
Zakres udzielanego wsparcia technicznego obejmuje wszystkie wykryte podczas eksploatacji Systemu błędy tj. uszkodzenia, wady i nieprawidłowości w funkcjonowaniu Systemu.W zakresie klasyfikacji błędów Systemu, ewidencji zgłoszeń, procedur odbioru, czasu realizacji zgłoszeń, odbioru usług, naliczania kar umownych mają zastosowanie zapisy OPZ i Umowy. W przypadku zmian w Systemie wynikających z instalacji nowych wersji na skutek naprawy błędów lub Modyfikacji, Wykonawca dokona na żądanie Zamawiającego aktualizacji dokumentacji, w tym dokumentacji użytkowej.
Zasady realizacji usługi wsparcia technicznego i serwisu:1. Wykonawca świadczy usługę wsparcia technicznego i serwisu Systemu
Zarządzania Tożsamością dla Zamawiającego. 2. Usługa wsparcia technicznego i serwisu obejmuje:
1) wszystkie komponenty oprogramowania i sprzętu wykorzystywane przez Wykonawcę w ramach Systemu, w tym opisane w Rozdziale 3.2 Architektura wykorzystywanego rozwiązania
2) systemy operacyjne, w oparciu o które funkcjonuje System,
str. 39
3) zadania administracji wszystkimi komponentami Systemu w architekturze dwuośrodkowej niezawodnościowo-wydajnościowej, w tym systemami operacyjnymi,
4) obsługa kopii zapasowych baz danych Systemu i ich odtwarzania zgodnie z procedurami zabezpieczeń (backup’owe) dostarczonymi w ramach Procedur Administracyjnych i Utrzymaniowych znajdujących się w dokumentacji systemu,
5) usuwanie awarii SZT oraz skutków awarii systemu, sprzętu i oprogramowania, a także wszelkich negatywnych skutków spowodowanych korzystaniem z błędnie działających wersji systemu we wszystkich lokalizacjach funkcjonowania Systemu,
6) usuwanie błędów w oprogramowaniu Systemu,7) dostosowanie Systemu do zmieniających się wersji przeglądarek
internetowych zapewniając ciągłą zgodność Systemu z ostatnią i przedostatnią wersją poniższych przeglądarek:a. Internet Explorer,b. Mozilla Firefox, c. Google Chrome.
8) realizację konfiguracji Systemu,9) wytworzone Modyfikacje,10) zadania optymalizacji funkcjonowania Systemu w uzgodnieniu z
Zamawiającym, obejmujące optymalizację kodu źródłowego Systemu, systemu baz danych w infrastrukturze centralnej, serwerów aplikacyjnych. Kryterium optymalizacji jest wydajność Systemu.
11) odtworzenie Systemu i przywrócenie do pełnej funkcjonalności w tym po katastrofie, pod pojęciem katastrofy Zamawiający rozumie uszkodzenie lub całkowite zniszczenie większości istniejącej infrastruktury systemowej, kiedy do przywrócenia sprawności Systemu niezbędne są działania związane z odtwarzaniem zniszczonych zasobów sprzętowych i danych,
12) monitorowanie i rekomendowanie Zamawiającemu konieczność zainstalowania poprawek i nowych wersji, na poszczególnych elementach Systemu dla środowisk technologicznych w infrastrukturze centralnej, takich jak oprogramowania:
sieciowych systemów operacyjnych, aplikacyjne, bazodanowe, oraz pozostałego oprogramowania technologicznego
i narzędziowego będącego w posiadaniu Zamawiającego, a niezbędnego do bezpiecznego działania Systemu, a następnie ich wdrożenie na wszystkich środowiskach wskazanych przez Zamawiającego lub na podstawie zgłoszeń instalacji poprawek żądanych do aktualizacji przez Zamawiającego wraz przygotowaniem dokumentacji instalacyjno – konfiguracyjnej (wdrożeniowej) jak i instalacji nowych środowisk na poziomie infrastruktury centralnej we wszystkich środowiskach
str. 40
Zamawiającego (produkcyjnych, testowych) oraz aktualizacji tych instrukcji przy każdej istotnej zmianie.
13) monitorowanie infrastruktury w zakresie prawidłowości działania, dostępności i wykorzystania zasobów procesów i usług oraz udostępnienie monitoringu Zamawiającemu,
14) wymiarowanie systemu i przygotowywanie rekomendacji w celu uniknięcia spadku wydajności i błędów i awarii,
15) przeprowadzania testów wydajnościowych systemu, 16) wykonanie i aktualizowanie dokumentacji utrzymaniowej systemu,17) wsparcie serwisowe zapewniane dla platformy bazodanowej 18) Realizacja usługi wsparcia technicznego i serwisu będzie
wykonywana w sposób niezakłócający normalnego funkcjonowania Użytkownika Końcowego pomiędzy godziną 6:00 a 16:00 w dni robocze. Wszelkie planowe działania ograniczające dostępność, responsywność i funkcjonalność systemu mogą być prowadzone w dni robocze godzinach od 22:00 do 6:00 i w dni wolne od 06:00 do 12:00 po uprzednim wyznaczeniu przez Zamawiającego okna serwisowego. W szczególnych przypadkach Zamawiający może wyznaczyć inne okno serwisowe. Okno serwisowe wyznacza się min. na 14 dni przed planowanymi pracami. W szczególnych przypadkach Zamawiający może zaakceptować skrócenie czasu na wyznaczenie okna serwisowego.
19) Realizacja usługi wsparcia technicznego i serwisu będzie wykonywana z należytą starannością, zgodnie z wytworzoną w ramach realizacji i utrzymania systemu dokumentacją (w szczególności dokumentacją techniczną i eksploatacyjną) oraz zasadami współczesnej wiedzy technicznej.
20) Wykonawca zapewnia obsługę niemożliwych do zdiagnozowania i usunięcia w sposób zdalny (za pośrednictwem łącza VPN lub telefonicznie) błędów na miejscu u Zamawiającego przez specjalistę ze strony Wykonawcy.
21) Zamawiający zastrzega sobie prawo do modyfikacji Systemu przez Zamawiającego lub przez podmiot trzeci. Zamawiający każdorazowo po wprowadzeniu modyfikacji poinformuje Wykonawcę o wykonanych zmianach i przekaże aktualny kod źródłowy Systemu do wdrożenia przez Wykonawcę.
Wykonawca musi zapewnić poziom wsparcia technicznego i serwisowego dla wykorzystywanych funkcjonalności oraz planowanego rozwoju SZT spełniając wymagania określone w poniższej tabeli oraz kryteria określone w rozdziale 4.7.2 Klasyfikacja zgłoszeń.
Opis wymagania kategoria wymagań
Poziom wymagalności
spełniany przez system
Świadczący serwis posiada autoryzację Producenta do Serwis/ Wymagane
str. 41
świadczenia serwisu dla oferowanego Systemu lub jest autoryzowanym partnerem Producenta oprogramowania SZT
Wsparcie
Wykonawca zapewni dostęp do aktualizacji programów, poprawek i ostrzeżeń o zagrożeniach bezpieczeństwa udostępnianych przez Producenta Systemu
Serwis/Wsparcie
Wymagane
Wykonawca zapewni aktualizacje programów, poprawek i ostrzeżeń o zagrożeniach bezpieczeństwa udostępnianych przez Producenta Systemu
Serwis/Wsparcie
Wymagane
Wykonawca będzie świadczył na rzecz Zamawiającego usługi wsparcia , które muszą zapewniać Zamawiającemu usuwanie awarii, usterek i wad urządzeń oraz awarii i błędów programistycznych w oprogramowaniu wg. warunków i ram czasowych określonych w poniższej procedurze:
4.7.1. Procedura realizacji zgłoszeń
a. Zamawiający przewiduje następujące kanały komunikacji:a. za pośrednictwem zgłoszenia w aplikacji Service Desk
udostępnionej przez Zamawiającego,b. w przypadku zgłoszeń typu Awaria, dodatkowo telefonicznie
na numer wskazany przez Wykonawcę,b. Zgłoszenie przesłane przez Zamawiającego lub Użytkownika po
godz. 16.30 w dniu roboczym Wykonawca przyjmuje do realizacji następnego dnia roboczego o godz. 7.30 z wyłączeniem Awarii, które przyjmuje się do realizacji niezwłocznie po zarejestrowaniu zgłoszenia.
c. Za moment zgłoszenia uznaje się datę i godzinę zarejestrowania zgłoszenia w aplikacji Service Desk.
d. Zamawiający kategoryzuje zgłoszenia na formularzu zgłoszenia zgodnie z kwalifikacją określoną w tabeli zawierającej rodzaje kwalifikacji zgłoszeń. Wykonawca może zmienić kategorię zgłoszenia za uprzednią zgodą Zamawiającego.
e. Zamawiający określa które Błędy powinny być realizowane w pierwszej kolejności. Określenie Zamawiającego jest wiążące dla Wykonawcy.
f. Prawidłowa realizacja zgłoszenia, musi być zweryfikowana i potwierdzona w testach akceptacyjnych przez Zamawiającego. Czas poświęcony na weryfikację zgłoszenia nie jest wliczany w czas jego realizacji przez Wykonawcę.
g. Wykonawca zobowiązuje się świadczyć usługi gwarancyjne względem urządzeń w miejscu ich użytkowania z możliwością naprawy w serwisie Wykonawcy, jeżeli naprawa urządzeń w miejscu użytkowania okaże się niemożliwa. W przypadku braku możliwości dokonania naprawy w miejscu użytkowania urządzeń i konieczności jego dostarczenia do punktu serwisowego wskazanego przez Wykonawcę, koszty dostarczenia uszkodzonego sprzętu do punktu serwisowego oraz z punktu serwisowego do miejsca użytkowania pokrywa Wykonawca. Pod pojęciem „urządzenia” lub „sprzęt”
str. 42
należy rozumieć komponenty sprzętowe wchodzące w skład Infrastruktury sprzętowej.
h. Wykonawca ponosi wszelkie koszty naprawy urządzeń, w tym kosztów transportu, instalacji i uruchomienia Sprzętu.
i. Nośniki informacji takie jak np. dyski twarde, pamięci flash, mogą być naprawiane jedynie w miejscu ich użytkowania, a w przypadku konieczności wymiany uszkodzonych nośników na nowe, wolne od wad, nośniki informacji nie podlegają zwrotowi do Wykonawcy. W przypadku konieczności dokonania naprawy sprzętu wyposażonego w nośniki informacji poza miejscem użytkowania, nośniki pozostają w siedzibie Zamawiającego.
j. Wykonawca dostarczy Zamawiającemu dane niezbędne do autoryzacji na stronie producenta sprzętu w celu pobierania nowych wersji oprogramowania urządzeń, poprawek, korzystania z bazy wiedzy, instrukcji obsługi itp. W terminach określonych w harmonogramie ramowym.
k. Wykonawca zobowiązuje się, że nie będzie dokonywał żadnych modyfikacji sprzętu bez wcześniejszego uzgodnienia ich z Zamawiającym. Zamawiający zastrzega sobie prawo do samodzielnej rozbudowy sprzętu i dokonywania zmian w konfiguracji.
l. W przypadku gdy przewidywany czas naprawy komponentów sprzętowych Infrastruktury informatycznej będzie dłuższy niż 24 godziny, Wykonawca najpóźniej następnego dnia po upływie tego czasu dostarczy na własny koszt zastępcze komponenty sprzętowe o co najmniej takich samych parametrach i funkcjach użytkowych jak komponent naprawiany.
m. W przypadku wystąpienia awarii tego samego elementu po wykonaniu 3 napraw w okresie obowiązywania umowy, Wykonawca zobowiązuje się na pisemne wezwanie Zamawiającego do wymiany tego elementu sprzętu na sprawny, tego samego producenta i tego samego typu o parametrach nie gorszych niż element wymieniany w terminie 30 dni od dnia otrzymania wezwania do wymiany.
n. Wykonawca jest zobowiązany do odbioru i utylizacji sprzętu podlegającego wymianie, z wyjątkiem nośników informacji, które w każdym przypadku pozostają u Zamawiającego.
o. Zamawiający ma prawo do wykonania rozbudowy lub relokacji urządzeń przez podmioty trzecie, posiadające stosowne uprawnienia producenta bez utraty prawa do usług gwarancyjnych oraz wsparcia eksperckiego dla urządzenia, z zastrzeżeniem, że Wykonawca nie ma obowiązku świadczenia usług serwisu dla dokonanej rozbudowy (taki obowiązek będzie ciążył na podmiocie trzecim, który ją wykonał).
4.7.2. Klasyfikacja zgłoszeń
1. Awaria (błąd krytyczny) – oznacza sytuację, w której nie jest możliwe prawidłowe używanie przez Zamawiającego SZT, zarówno z
str. 43
powodu uszkodzenia elementów sprzętowych, oprogramowania, jak również uszkodzenia lub utraty kodu programu, struktur danych oraz zawartości baz danych.Awaria to również usterka, która uniemożliwia użytkowanie SZT w zakresie jego podstawowej funkcjonalności, które prowadzi do:
zatrzymania eksploatacji SZT jako całości lub jego istotnej części, zatrzymania eksploatacji pojedynczego lub kilku elementów
wchodzących w skład SZT, utraty danych lub naruszenia ich spójności.
w wyniku czego niemożliwe jest prowadzenie przez Zamawiającego normalnej działalności z użyciem SZT, a w szczególności dokonywanie bieżącej obsługi zarządzania tożsamościami użytkowników przez Zamawiającego.
2. Błąd – oznacza działanie powtarzalne, pojawiające się w tym samym elemencie SZT (w urządzeniach lub oprogramowaniu), prowadzące w każdym przypadku do otrzymania błędnych lub niepełnych wyników działania; pomimo, iż SZT nadal funkcjonują to usunięcie Błędu wymaga ingerencji pracowników serwisu Wykonawcy.
3. Konserwacja – oznacza usługę polegającą na dostępie Wykonawcy do SZT w celu wykonania zadań własnych i zleconych przez Zamawiającego, dotyczących elementów tworzących SZT wynikającą ze względu na zmiany prawa w tym w szczególności: Zarządzenia Ministra Sprawiedliwości z dnia 12 grudnia 2003 r. w sprawie organizacji i zakresu działania sekretariatów sądowych oraz innych działów administracji sądowej (Dz. Urz. MS. nr 5, poz. 22 ze zm.), ustawy z dnia 23 kwietnia 1964 r. Kodeks cywilny (t.j. Dz. U. z 2014 r. poz. 121 ze zm.), ustawy z dnia 17 listopada 1964 r. Kodeks postępowania cywilnego (t.j. Dz. U. z 2014 r., poz. 101 ze zm.), ustawy z dnia 6 czerwca 1997 r. Kodeks karny (Dz. U. Nr 88, poz. 553, ze zm.), ustawy z dnia 6 czerwca 1997 r. Kodeks postępowania karnego (Dz. U. Nr 89, poz. 555, ze zm.), ustawy z dnia 6 czerwca 1997 r. Kodeks karny wykonawczy (Dz. U. Nr 90, poz. 557, ze zm.), ustawy z dnia 24 sierpnia 2001 r. Kodeks postępowania w sprawach o wykroczenia (t.j. Dz. U. z 2013 r., poz. 395 ze zm.), ustawy z dnia 26 października 1982 r. o postępowaniu w sprawach nieletnich
Usługa ta, wraz z usługą Administracji świadczona za pomocą dedykowanego i zabezpieczonego łącza telekomunikacyjnego (zestawianego i utrzymywanego na koszt Wykonawcy), na warunkach ustalonych z Zamawiającym po zawarciu Umowy.
L.P. Pojęcie Ramy Uwagi
str. 44
czasowe / Ilość
1. Przyjmowanie zgłoszeń:
Pn-Pt (dni robocze)7:30-16:30
Wykonawca ma dostęp do aplikacji Service Desk 24/365.
A Awaria (błąd krytyczny)
Incydent zgłoszony do godziny 12:00, powinien być poprawiony najpóźniej do godziny 17:00 tego samego dnia.Incydent zgłoszony po godzinie 12:00, powinien być poprawiony najpóźniej do godziny 12:00 następnego dnia. Po udostępnieniu rozwiązania czasowego pozwalającego na realizację błędnie działającej usługi (wdrożeniu obejścia) Awaria (błąd krytyczny) staje się Błędem.
Czas liczony od momentu przesłania przez Zamawiającego „Zgłoszenia Serwisowego” do momentu usunięcia/rozwiązania Awarii (błędu krytycznego).
B. Błąd 2 dni robocze Czas liczony w dniach roboczych od momentu przesłania przez Zamawiającego „Zgłoszenia Serwisowego” do momentu usunięcia błędu.
2. Konsultacja Pn-Pt (dni robocze)8:00-16:00
Świadczone w trybie zdalnym na jego żądanie przez wykwalifikowany personel Wykonawcy według potrzeb zgłoszonych przez Zamawiającego w zleceniu konsultacji. Zlecenie konsultacji będzie wysyłane drogą elektroniczną na adres podany przez Wykonawcę lub za pośrednictwem aplikacji Service Desk;
3. Konserwacja 24/7/365 Usługa świadczona w trybie
str. 45
w terminie ustalonym przez Zamawiającego w porozumieniu z Wykonawcą, w przypadku braku porozumienia Stron, termin realizacji zostanie ustalony samodzielnie przez Zamawiającego
ciągłym w okresie od dnia podpisania przez Zamawiającego Końcowego Protokołu Odbioru Produktu do dnia, w którym upłynie 12 miesięcy od daty zakończenia realizacji Umowy.
Do czasu rozwiązywania incydentów (awarii oraz błędów) przez Wykonawcę nie wlicza się: a/ czasu udzielania odpowiedzi przez Zamawiającego przy czym do Zamawiającego należy ocena czy pytania kierowane przez Wykonawcę są zasadne i spełniają kryterium braku wiedzy Wykonawcy w tym zakresie.Ilość wniosków o udzielenie odpowiedzi ograniczona jest maksymalnie do dwóch.Fakt przesłania pytania przez Wykonawcę musi być udokumentowany w systemie zgłoszeń Zamawiającego na bazie którego zgłaszane są incydenty.b/ czasu realizacji zadań związanych z danym zgłoszeniem a zależnych od Zamawiającego, w szczególności zadań związanych z przeprowadzaniem testów poprawek dostarczonych przez Wykonawcę.c/ czasu wstrzymania zgłoszenia przez Zamawiającego w przypadku konieczności przeprowadzenia pogłębionej analizy przyczyny zgłoszonych incydentów.
4.7.3. Konsultacje
Konsultacja – oznacza usługę świadczoną przez Wykonawcę polegającą na:
bieżącym udzielaniu Zamawiającemu wyjaśnień (wskazówek) problemów powstałych w związku z użytkowaniem SZT,
bieżącej pomocy w rozwiązywaniu zaistniałych problemów, w czasie umożliwiającym SZT poprawne i terminowe wykonywanie prac.
Wykonawca zapewni pracownikom i innym osobom zatrudnionym Zamawiającego wsparcie merytoryczne w postaci Konsultacji zlecanych i rozliczanych w ramach puli godzin rozwojowych. Przez „pracowników lub inne osoby zatrudnione” Zamawiający rozumie pracowników Zamawiającego świadczących usługi w ramach I i II linii wsparcia użytkowników końcowych lub
str. 46
członków zespołu projektowego. Zamawiający przewiduje następujące kanały komunikacji:
za pośrednictwem zgłoszenia w aplikacji Service Desk udostępnionej przez Zamawiającego,
drogą elektroniczną na e-mail wskazany przez Wykonawcę.
Konsultacje udzielane będą w dni robocze w godzinach 8:00-16:00
Konsultacje świadczone będą w trybie zdalnym lub bezpośrednio w siedzibie Zamawiającego na jego żądanie, przez wykwalifikowany personel Wykonawcy według potrzeb zgłoszonych przez Zamawiającego w zleceniu konsultacji.
W związku z planowanym rozwojem systemu, Zamawiający - ramach konsultacji - może zlecić Wykonawcy przeprowadzenie transferu wiedzy, w łącznym wymiarze 4 dni roboczych, w drodze wideokonferencji lub bezpośrednio w siedzibie Zamawiającego. Transfer wiedzy, obejmujący zakres wdrożonych zmian oraz zaleceń odnośnie działań utrzymaniowo-administracyjnych, adresowany będzie do maksymalnie 10 osób jednocześnie uczestniczących w transferze wiedzy to jest do administratorów systemu SZT oraz administratorów Systemów Integrowanych. W przypadku zlecenia przez Zamawiającego przeprowadzenia transferu wiedzy w siedzibie Zamawiającego, koszty zakwaterowania i pobytu pracownika Wykonawcy, prowadzącego transfer wiedzy, ponosi Wykonawca.
Rejestr udzielonych konsultacji prowadzony będzie w aplikacji Service Desk Zamawiającego. Za moment zgłoszenia potrzeby konsultacji uznaje się datę i godzinę zarejestrowania zgłoszenia w aplikacji Service Desk.
4.8. Dokumentacja projektowa
4.8.1. Aktualizacja dokumentacji projektowej
W ramach realizacji przedmiotu Umowy, objętego niniejszym postępowaniem, Wykonawca ma obowiązek aktualizacji dokumentacji, będącej w posiadaniu Zamawiającego, obejmującej:
Projekt Biznesowo-Techniczny, Dokumentację użytkownika Procedury utrzymaniowo-administracyjne, Procedury ministerialne, Szkolenia e-learningowe.
str. 47
Aktualizacja dokumentacji zostanie przeprowadzona dwukrotnie w czasie trwania Umowy, w terminie ustalonym przez Zamawiającego z Wykonawcą przy czym stanowisko Zamawiającego jest w tym zakresie wiążące.
4.8.2. Dokumentacja Modyfikacji Oprogramowania Dedykowanego
Wykonawca ma obowiązek sporządzania dokumentacji Modyfikacji funkcjonalności SZT poprzez:
dokumentowanie analizy w odniesieniu do zmian funkcjonalności, obejmującej aspekty biznesowo-techniczne,
oszacowanie czasochłonności prac niezbędnych do wykonania, wskazanie terminu realizacji zmiany, wyspecyfikowanie czynności będących w obowiązku Zamawiającego, wskazanie ryzyk, związanych z analizowaną zmianą, zdefiniowanie korzyści z wprowadzanych zmian.
Dokumentowanie i aktualizacja zmian odbywać się będzie z wykorzystaniem Formularza Wniosku o Modyfikację, stanowiącego Załącznik nr 6.1 Formularz wniosku o Modyfikację.
4.8.3. Zasady aktualizacji dokumentacji projektowej
Dokumentowanie zmian w ramach Modyfikacji Systemu oraz aktualizacja dokumentacji projektowej podlegają procesowi odbioru i akceptacji przez Zamawiającego, którego kryterium jest ocena merytoryczna dokumentu. Zamawiający przekazuje Wykonawcy uwagi niezwłocznie (jednak w terminie nie dłuższym niż 5 dni roboczych), Wykonawca jest zobowiązany je uwzględnić w terminie 5 dni roboczych. W przypadku braku uwag w wyżej wymienionym terminie, dokumenty uznaje się za odebrane i zaakceptowane bez zastrzeżeń. Ewentualne uwagi Zamawiającego obsługiwane będą w następujący sposób:
Uwagi Zamawiającego mogą dotyczyć wyłącznie zaktualizowanych fragmentów dokumentów (ewentualnie braku aktualizacji fragmentu, który dotyczy zmodyfikowanej przez Wykonawcę w ramach przedmiotu aneksu funkcjonalności)
Podczas pierwszej iteracji zgłaszania uwag Zamawiającemu przysługuje prawo do zgłoszenia uwag do całości lub poszczególnych części odbieranego dokumentu;
Po wprowadzeniu poprawek przez Wykonawcę i przekazaniu ponownie dokumentu do odbioru tj. podczas drugiej iteracji zgłaszania uwag do dokumentu Zamawiającemu przysługuje prawo do zgłoszenia uwag wyłącznie w odniesieniu
str. 48
do tych obszarów, które ulegały zmianie i tylko w aspekcie tego, czy zmiany zostały dokonane zgodnie ze wskazanymi uwagami.
Druga iteracja jest powtórzeniem powyższego kroku i zamyka procedurę odbiorową.
5. Wymagania dla rozwiązania równoważnego
W przypadku zaoferowania przez Wykonawcę rozwiązania równoważnego Zamawiający oczekuje spełnienia przez Wykonawcę oraz przez oferowane rozwiązanie następujących kryteriów i wymagań:
5.1. Równoważne kryteria funkcjonalne
Oferowany system musi spełniać kryteria funkcjonalne określone w rozdziale 3.1.1 Ogólne funkcjonalności systemu zgodnie z oznaczonym poziomem wymagalności oraz zapewniać realizację procesów biznesowych zdefiniowanych w rozdziale 3.1.7 Oprogramowanie dedykowane
5.2. Kryterium ciągłości działania systemuWymaganiem Zamawiającego jest zapewnienie ciągłości działania dla wdrożonego i wykorzystywanego systemu, rozumiane jako konieczność zapewnienia wsparcia serwisowego i gwarancyjnego dla systemu użytkowanego przez Zamawiającego do czasu produkcyjnego uruchomienia rozwiązania równoważnego. Wymagany poziom serwisu i wsparcia został określony w rozdziale 4.7 Poziom i zasady udzielanego wsparcia technicznego iserwisu (SLA)
5.3. Wymagania techniczneRozwiązanie równoważne musi spełniać wymagania techniczne zdefiniowane w rozdziale 3.1.2 Wymagania techniczne.
5.4. Wymagania niezawodnościoweRozwiązanie równoważne musi spełniać wymagania niezawodnościowe zdefiniowane w rozdziale 3.1.3 Wymagania niezawodnościowe.
str. 49
5.5. Wymagania wydajnościoweRozwiązanie równoważne musi spełniać wymagania wydajnościowe zdefiniowane w rozdziale 3.1.4 Wymagania wydajnościowe.
5.6. Wymagania infrastrukturalneRozwiązanie równoważne musi spełniać wymagania infrastrukturalne zdefiniowane w rozdziale 3.1.5 Wymagania infrastrukturalne.
5.7. Wymagania licencyjneRozwiązanie równoważne musi spełniać wymagania licencyjne zdefiniowane w rozdziale 3.1.6 Wymagania licencyjne.
5.8. Wymagania dotyczące realizacji wdrożenia rozwiązania równoważnego
Zamawiający wymaga by wdrożenie rozwiązania równoważnego zawierało następujące etapy:
Przeprowadzenie szczegółowej analizy wymagań Zamawiającego oraz przygotowanie Projektu Biznesowo- Technicznego,
Dostarczenie rozwiązania równoważnego do testów, Przeprowadzenie testów, Wdrożenie przedprodukcyjne, Opracowanie i przeprowadzenie szkoleń, Wdrożenie produkcyjne, Przygotowanie dokumentacji systemu.
Poniżej przedstawiono szczegółowe wymagania dla poszczególnych etapów.
5.8.1. Analiza wymagań i Projekt Biznesowo-Techniczny
Przygotowanie założeń ogólnych projektu zawierających: Cel projektu Zakres projektu Podejście do problemu Proponowane rozwiązania Planowany harmonogram wdrożenia Struktura zarządzania projektem Wymagane zasoby
str. 50
Przygotowanie założeń szczegółowych w zakresie: Budowy konektorów do wymaganych SI Mechanizmów szyfrowania danych Implementacji procesów biznesowych Struktury raportów oraz mechanizmów audytu Budowy interfejsu portalu samoobsługi
Projekt Biznesowo-Techniczny musi spełniać wymagania określone w rozdziale 5.10.3.3 Projekt Biznesowo-Techniczny.
5.8.2. Wdrożenie przedprodukcyjne
Etap obejmuje przeprowadzenie wdrożenia przedprodukcyjnego rozwiązania równoważnego w sposób niezakłócający działania systemu SZT, użytkowanego przez Zamawiającego a w szczególności:
Przygotowanie infrastruktury technicznej środowiska produkcyjnego składające się z instalacji i konfiguracji serwerów,
Przygotowanie infrastruktury technicznej środowiska testowego, składające się z instalacji, konfiguracji systemów operacyjnych,
Przygotowanie infrastruktury oprogramowania, a w szczególności: instalacji bazy danych systemu, instalacji centralnego repozytorium tożsamości, instalacji portalu samoobsługi.
Wykonanie integracji z systemem SAP HCM poprzez przygotowanie ekstraktora danych HCM. Ekstraktor musi umożliwiać replikację danych HCM oraz umożliwiać obsługę błędów ekstrakcji.
Przygotowanie konektorów do systemów: ESS/MSS/LSO , domeny AD i serwera pocztowego Exchange.
Wykonanie inicjalnego ładowania wszystkich pracowników z systemu HCM do centralnego repozytorium tożsamości oraz powiązania ich z istniejącymi użytkownikami ESS/MSS/LSO , domeny AD i serwera pocztowego Exchange. Dane HCM dostępne na systemie DEV/TST muszą zostać poddane procesowi anonimizacji.
Wykonanie inicjalnego ładowania ról z SI oraz zbudowanie podstawowej roli biznesowej, nadawanej wszystkim pracownikom, składającej się z uprawnień dostępowych do:
ESS/MSS/LSO, Domeny AD Serwera poczty Exchange
Wykonanie konfiguracji portalu samoobsługi oraz związanej z tym budowy katalogu ról dostępowych oraz użytkowników testowych,
str. 51
Udostępnienie portalu samoobsługi dla wszystkich sądów powszechnych objętych wdrożeniem, zgodnie z Listą Dystrybucyjną (Załącznik nr 6.4 do OPZ).
Implementacja mechanizmu SSO w postaci autentykacji domenowej dla portalu samoobsługi SZT,
Konfiguracja mechanizmu raportowania oraz budowa raportów zgodnie z przeprowadzoną analizą wymagań.
Implementacja mechanizmu workflow dla co najmniej 5 procesów biznesowych.
Wykonanie tzw. hardeningu wszystkich komponentów software’owych systemu, w tym: systemów operacyjnych, baz danych, serwerów aplikacyjnych, aplikacji, konfiguracja mechanizmów szyfrowania.
Przeprowadzenie testów zgodnie z Planem Testów.
5.8.3. Wdrożenie produkcyjne
Etap obejmuje przeprowadzenie wdrożenia produkcyjnego rozwiązania równoważnego, a w szczególności:
Przygotowanie infrastruktury technicznej środowiska produkcyjnego, składające się z instalacji i konfiguracji serwerów.
Przygotowanie infrastruktury technicznej środowiska testowego, składające się z instalacji i konfiguracji systemów operacyjnych.
Przygotowanie infrastruktury oprogramowania systemu, a w szczególności: instalacji bazy danych systemu, instalacji centralnego repozytorium tożsamości, instalacji portalu samoobsługi.
Wykonanie integracji z systemem SAP HCM poprzez przygotowanie ekstraktora danych HCM. Ekstraktor musi umożliwiać replikację danych HCM oraz zapewniać narzędzie do obsługi błędów ekstrakcji.
Przygotowanie konektorów do systemów: ESS/MSS/LSO, domeny AD i serwera pocztowego Exchange.
Wykonanie inicjalnego ładowania wszystkich pracowników z systemu HCM do centralnego repozytorium tożsamości oraz powiązania ich z istniejącymi użytkownikami ESS/MSS/LSO, domeny AD i serwera pocztowego Exchange. Wykonanie inicjalnego ładowania ról z SI oraz zbudowanie podstawowej roli biznesowej, nadawanej wszystkim pracownikom, składającej się z uprawnień dostępowych do:
ESS/MSS/LSO, Serwera poczty Exchange
str. 52
Wykonanie konfiguracji portalu samoobsługi SZT oraz związanej z tym budowy katalogu ról dostępowych oraz użytkowników testowych.
Udostępnienie portalu samoobsługi dla wszystkich sądów powszechnych, objętych wdrożeniem, zgodnie z Listą Dystrybucyjną (Załącznik nr 6.4 do OPZ ).
Implementacja mechanizmu SSO w postaci autentykacji domenowej dla portalu samoobsługi SZT,
Implementacja mechanizmu wysokiej dostępności HA dla środowiska produkcyjnego.
Konfiguracja mechanizmu raportowania oraz budowa raportów zgodnie z przeprowadzoną analizą wymagań.
Implementacja mechanizmu workflow dla co najmniej 5 procesów biznesowych.
Wykonanie tzw. hardeningu wszystkich komponentów software’owych systemu, w tym: systemów operacyjnych, baz danych, serwerów aplikacyjnych, aplikacji, konfiguracja mechanizmów szyfrowania.
Przeprowadzenie testów zgodnych z Planem Testów.
str. 53
5.8.4. Poziom i zasady udzielanego wsparcia technicznego i serwisu (Rozwiązanie Równoważne)
Wykonawca wdrożenia rozwiązania równoważnego zobowiązany jest zapewnić wsparcie:
dla systemu SZT, wykorzystywanego przez Zamawiającego, do czasu produkcyjnego uruchomienia rozwiązania równoważnego a następnie
dla rozwiązania równoważnego – w okresie obowiązywania umowy,na zasadach określonych w rozdziale 4.7 Poziom i zasady udzielanegowsparcia technicznego i serwisu (SLA).
5.9. Szkolenia
W celu wdrożenia rozwiązania równoważnego wymagane jest przeprowadzenie szkoleń dla administratorów, w zakresie i wymiarze opisanym poniżej. Zakres i wymiar szkoleń jest tożsamy z zakresem szkoleń przeprowadzonych przez Wykonawcę wdrożenia Systemu Zarządzania Tożsamością, wykorzystywanego przez Zamawiającego.
Szkolenia - specyfikacja wymagań:Wykonawca zorganizuje i przeprowadzi 5-dniowe szkolenie stacjonarne, zwane dalej "Szkoleniem", dla 10 uczestników – administratorów rozwiązania równoważnego. Uczestnikami szkoleń będą pracownicy sądów - administratorzy rozwiązania równoważnego, skierowani przez kierowników oddziałów informatycznych na szkolenia. Łącznie wymaganych do przeszkolenia w trybie stacjonarnym jest 10 osób.Szkolenie zostanie przeprowadzone w siedzibie Zamawiającego - Sądu Apelacyjnego we Wrocławiu (ul. Namysłowska 8, 50-304 Wrocław). Zamawiający udostępni Wykonawcy bez potrzeby ponoszenia dodatkowych opłat na potrzeby szkolenia sale konferencyjne o odpowiednich wymiarach wyposażone w rzutnik i ekran oraz miejsce dla Trenera, pozwalające przeprowadzić przedmiotowe Szkolenie. Zamawiający zapewni również przerwy kawowe w trakcie Szkolenia. Szkolenie polegać ma na przeprowadzeniu wykładów oraz warsztatów dla Administratorów, uzupełnionych prezentacjami multimedialnymi, odpowiedziami na pytania uczestników sesji szkoleniowych. Szkolenie ma obejmować w szczególności przeprowadzenie wykładów teoretycznego dla Administratorów uzupełnionych prezentacjami multimedialnymi oraz przeprowadzeniu warsztatów praktycznych na rozwiązaniu równoważnym. Wykonawca zapewnieni każdemu uczestnikowi wyłączny dostępu do komputera z dostępem do rozwiązania równoważnego w konfiguracji takiej jak u Zamawiającego.
str. 54
Wykonawca w porozumieniu z Zamawiającym ustali termin szkolenia. W razie wątpliwości dotyczących ustalenia kwestii, o których mowa powyżej, za wiążące uznaje się stanowisko Zamawiającego.Zamawiający przedstawi Wykonawcy imienną listę osób uczestniczących w szkoleniu na 5 dni roboczych przed rozpoczęciem Szkolenia. Wszystkie Szkolenia przeprowadzone mają być w języku polskim, oraz zapewnione mają być materiały szkoleniowe dla uczestników. Wykonawca przedstawi do akceptacji Zamawiającemu zakres merytoryczny Szkoleń. Zamawiający w terminie 14 dni dokonuje akceptacji zakresu merytorycznego szkoleń, w szczególności warsztatów lub zgłasza do niego uwagi. Wykonawca zobowiązany jest do uwzględnienia uwag Zamawiającego w terminie 7 dni od dnia ich otrzymania. Po szkoleniu zostanie sporządzona przez Wykonawcę lista obecności z podpisem każdego obecnego uczestnika szkolenia. Wzór listy obecności zostanie opracowany przez Wykonawcę i przekazany do zatwierdzenia przez Zamawiającego.Wykonawca obowiązany jest do przedłożenia Zamawiającemu imiennej listy obecności obejmującej co najmniej imiona i nazwiska osób uczestniczących, datę i miejsce szkolenia, Sąd, do którego należą uczestnicy oraz podpis uczestników.Lista obecności podpisana przez wszystkich obecnych na szkoleniu uczestników szkolenia jest jednym z warunków pozytywnego odbioru szkolenia i podpisania Protokołu Odbioru przez Zamawiającego w zakresie Szkoleń.Wykonawca odpowiada za zapewnienie 10 noclegów dla uczestników Szkolenia:Obiekt musi znajdować w granicach administracyjnych miasta Wrocław, w odległości do 5 km w linii prostej od siedziby Zamawiającego (ul. Namysłowska 8, 50-304 Wrocław).Obiekt nie może być w trakcie prac remontowych w czasie trwania szkolenia.Wykonawca zapewnia wszystkie miejsca noclegowe w sposób zapewniający samodzielny pobyt w pokoju (Zamawiający dopuszcza zakwaterowanie samodzielne jednego uczestnika w pokoju dwuosobowym, przy czym cena noclegu w pokoju dwuosobowym jest równa cenie za nocleg w pokoju jednoosobowym), Każdy z pokoi noclegowych z łazienką, TV, łącze internetowe (Wi-Fi) posiadających otwierane okna lub działającą klimatyzację.Obiekt co najmniej *** (trzy gwiazdki), w rozumieniu przepisów § 2 ust. 2 pkt 1 rozporządzenia Ministra Gospodarki i Pracy z dnia 19 sierpnia 2004 r. w sprawie obiektów hotelarskich i innych obiektów, w których są świadczone usługi hotelarskie (Dz. U. z 2006 r., Nr 22, poz. 169 ze zm.). Na każde żądanie Zamawiającego Wykonawca obowiązany jest okazać kopię decyzji właściwego Marszałka Województwa o nadaniu kategorii hoteli na podstawie art. 38 ust.1 i art. 42 ustawy z dnia 29 sierpnia 1997 r. o usługach turystycznych (t.j. Dz. U. z 2014 r., poz. 196 ze zm.),
str. 55
W koszt noclegu musi być wliczone śniadanie dla każdego z uczestników w formie stołu szwedzkiego.Szkolenie powinno być przeprowadzone przez trenera posiadającego doświadczenie i kwalifikacje, we wskazanych poniżej tematach i zakresie czasowym:
Temat szkolenia Minimalna liczba dni Szkolenia
1. Zarządzanie użytkownikami oraz rolami2. Zarządzanie strukturą organizacyjną 2
4. Obsługa konektorów do systemów podłączonych5. Wykorzystanie narzędzi developerskich do tworzenia / modyfikowania procesów6. Rekoncyliacja danych z zewnętrznych źródeł
2
8. Czynności utrzymaniowe systemu zarządzania tożsamością9. Rozwiązywanie problemów związanych z funkcjonowaniem systemu zarządzania tożsamością
1
Wymagania szczegółowe dotyczące Szkolenia: a) Szkolenie 5-dniowe dla administratorów rozwiązania równoważnego w siedzibie Zamawiającego,b) Liczba godzin szkolenia: 6 godzin szkoleniowych dziennie (1 godz. szkoleniowa – 45 min), przy czym część praktyczna (tzw. warsztaty) nie może być krótsza, niż 3 godziny dziennie;c) Szkolenia odbywa się w godzinach: 9.00-15.30 (wraz z 2 przerwami kawowymi po 15 min. każda; godziny przerw ustalane indywidualnie pomiędzy Trenerem i uczestnikami Szkolenia)Dokładny termin Szkolenia zostanie ustalony z Zamawiającym.
Zakres szkolenia powinien zawierać, co najmniej zagadnienia opisane w tabeli powyżej tj.: Zarządzanie użytkownikami oraz rolami; Zarządzanie strukturą organizacyjną; Obsługa konektorów do systemów podłączonych; Wykorzystanie narzędzi developerskich do tworzenia / modyfikowania procesów; Rekoncyliacja danych z zewnętrznych źródeł; Czynności utrzymaniowe systemu zarządzania tożsamością; Rozwiązywanie problemów związanych z funkcjonowaniem systemu zarządzania tożsamością;
str. 56
Po zakończeniu szkolenia Wykonawca przygotuje i następnie rozda uczestnikom do wypełnienia imienne ankiety ewaluacyjne. Ankieta powinna zawierać minimum następujące elementy:a) imię i nazwisko,b) program szkolenia,c) ocenę zastosowanych metod szkoleniowych, d) ocenę wiedzy zdobytej przez uczestnika, e) ocenę przydatności szkolenia, f) ocenę kompetencji Wykładowcy/Trenera, g) ocenę stopnia realizacji programu, h) inne elementy wpływające na jakość szkolenia,i) uwagi dotyczące szkolenia.Wszystkie oceny w skali szkolnej od 1 do 6, przy czym 1 – ocena niedostateczna, 6 – ocena celująca.
Wzór ankiety zostanie opracowany przez Wykonawcę i przekazany do zatwierdzenia przez Zamawiającego przed rozpoczęciem szkoleń (nie później niż na 14 dni roboczych przed szkoleniem). W terminie 7 dni od dnia przedstawienia, Zamawiający zgłosi uwagi lub dokona akceptacji. Wykonawca przedstawi także raport ewaluacyjny zawierający pełną analizę ocen przeprowadzonego szkolenia przez uczestników nie później niż 10 dni roboczych po przeprowadzeniu szkolenia. Raport ewaluacyjny ze średnią ocen ze wszystkich ankiet równą lub wyższą od 4.0 (liczone następującym sposobem: A = suma punktów z pytań punktowych dla każdej ankiety; B = suma liczby punktów z wszystkich ankiet; C = liczba ankiet; D = średnia ocen ze wszystkich ankiet liczona zgodnie z równaniem B/C=D)jest jednym z warunków odbioru pozytywnego szkolenia. Załącznikiem do raportu ewaluacyjnego są oryginały ankiet ewaluacyjnych wypełnione przez uczestników szkoleń.
Przedmiot zamówienia obejmuje także wyposażenie uczestników szkolenia w odpowiednie materiały szkoleniowe, które po zakończeniu Szkolenia przejdą na ich własność. Na materiały szkoleniowe składają się: drukowane materiały edukacyjne obejmujące co najmniej slajdy z prezentacji multimedialnych wyświetlanych w trakcie szkolenia, długopisy i notesy po jednym dla każdego uczestnika.
Wykonawca wyda uczestnikom szkoleń imienne zaświadczenia potwierdzające uczestnictwo w szkoleniach. Zaświadczenie będzie obejmowało: nazwę szkolenia, datę szkolenia i miejsce szkolenia. Projekt zaświadczenia zostanie opracowany przez Wykonawcę i przekazany do zatwierdzenia przez Zamawiającego przed rozpoczęciem szkoleń (nie później niż na 14 dni przed datą szkolenia). W terminie 7 dni od dnia przedstawienia, Zamawiający zgłosi uwagi lub dokona akceptacji. W razie wątpliwości
str. 57
dotyczących ustalenia kwestii, o których mowa powyżej, za wiążące uznaje się stanowisko Zamawiającego.
Odbiór Zaświadczenia oraz materiałów szkoleniowych zostanie potwierdzony przez uczestników Szkoleń na protokole odbioru materiałów szkoleniowych i zaświadczenia, który stanowi załącznik do Protokołu Odbioru Rozwiązania Równoważnego. Protokół będzie zawierał minimum: imię i nazwisko uczestnika, datę szkolenia, miejsce i tytuł szkolenia oraz własnoręczne podpisy uczestników szkolenia potwierdzające odbiór poszczególnych produktów. Oryginał Protokołu Odbioru materiałów szkoleniowych i zaświadczenia Wykonawca przekaże Zamawiającemu wraz z Raportem Ewaluacyjnym.
Wykonawca zapewni także osobę do koordynacji szkoleń odpowiadającą za przygotowanie szkolenia, która będzie pozostawała w kontakcie telefonicznym i mailowym co najmniej na 14 dni roboczych przed szkoleniem, w trakcie jego trwania i do momentu odbioru usługi Szkolenia. Wykonawca jest odpowiedzialny za zapewnienie Trenerowi noclegu i wyżywienia. Wykonawca jest zobowiązany do przygotowania, powielenia i dystrybucji pomiędzy uczestników materiałów szkoleniowych wraz z przyborami biurowymi (długopis, notes).
Brak pozytywnego odbioru szkolenia poprzez: nieuzyskanie w raporcie ewaluacyjnym średniej co najmniej 4.0 ze wszystkich ankiet ewaluacyjnych, brakiem dostarczenia lub dostarczeniem nieprawidłowo wypełnionych: listy obecności, protokołu odbioru materiałów szkoleniowych i protokołu odbioru zaświadczeń oraz oryginałów ankiet ewaluacyjnych skutkuje powtórzeniem Szkolenia na koszt Wykonawcy. Wykonawca z tego tytułu nie będzie sobie rościł praw do dodatkowego wynagrodzenia. Termin powtórnego szkolenia zostanie ustalony z Zamawiającym.
5.10. Dokumentacja projektowa
5.10.1. Aktualizacja dokumentacji projektowej systemu SZT
W przypadku dokonania przez Wykonawcę rozwiązania równoważnego zmian w systemie SZT, użytkowanym przez Zamawiającego, , Wykonawca ma obowiązek aktualizacji dokumentacji, będącej w posiadaniu Zamawiającego w zakresie i według zasad opisanych w rozdziale 4.8 Dokumentacja projektowa.
str. 58
5.10.2. Zasady aktualizacji dokumentacji projektowej
Dokumentowanie zmian w ramach Modyfikacji Systemu oraz aktualizacja dokumentacji projektowej podlegają procesowi odbioru i akceptacji przez Zamawiającego, którego kryterium jest ocena merytoryczna dokumentu. Zamawiający przekazuje Wykonawcy uwagi niezwłocznie (jednak w terminie nie dłuższym niż 5 dni roboczych), Wykonawca jest zobowiązany je uwzględnić w terminie 5 dni roboczych. W przypadku braku uwag w wyżej wymienionym terminie, dokumenty uznaje się za odebrane i zaakceptowane bez zastrzeżeń. Ewentualne uwagi Zamawiającego obsługiwane będą w następujący sposób:
Uwagi Zamawiającego mogą dotyczyć wyłącznie zaktualizowanych fragmentów dokumentów (ewentualnie braku aktualizacji fragmentu, który dotyczy zmodyfikowanej przez Wykonawcę w ramach przedmiotu aneksu funkcjonalności)
Podczas pierwszej iteracji zgłaszania uwag Zamawiającemu przysługuje prawo do zgłoszenia uwag do całości lub poszczególnych części odbieranego dokumentu;
Po wprowadzeniu poprawek przez Wykonawcę i przekazaniu ponownie dokumentu do odbioru tj. podczas drugiej iteracji zgłaszania uwag do dokumentu Zamawiającemu przysługuje prawo do zgłoszenia uwag wyłącznie w odniesieniu do tych obszarów, które ulegały zmianie i tylko w aspekcie tego, czy zmiany zostały dokonane zgodnie ze wskazanymi uwagami.
Druga iteracja zamyka procedurę odbiorową.
5.10.3. Wymagania dotyczące dokumentacji projektowej rozwiązania równoważnego
W przypadku wdrożenia rozwiązania równoważnego Wykonawca zobowiązany jest do opracowania dokumentacji projektowej w zakresie i według zasad określonych poniżej.Dokumentacja projektowa powinna być prowadzona w postaci repozytorium elektronicznego.
Po zakończeniu realizacji Projektu, Wykonawca ma obowiązek całą dokumentację zgromadzoną w repozytorium elektronicznym przekazać Zamawiającemu.
Dokumentacja projektowa powinna zawierać następujące elementy, sporządzone przez Wykonawcę i akceptowane przez Zamawiającego:
Dokument analizy wymagań (w tym notatki ze spotkań) Projekt Biznesowo - Techniczny Plan testów Dokumentacja powykonawcza Dokumentacja użytkownika
str. 59
Poniżej przedstawiono wymagania dla poszczególnych elementów dokumentacji:
5.10.3.1. Analiza wymagań
W ramach przeprowadzonej analizy wymagań w dokumencie muszą być zawarte:
Wprowadzenie zawierające proponowanie rozwiązanie, szczegółowy harmonogram wdrożenia, strukturę zarządzania projektem.
Definicja wymagań, która zawiera: integrację pomiędzy komponentami, integrację z poszczególnymi systemami informatycznymi, strukturę raportów, procesy biznesowe, elementy interfejsów użytkownika portalu samoobsługi systemu,
Szczegółowe zestawienie systemów, procesów oraz grup użytkowników objętych projektem wdrożenia
Lista członków zespołu projektowego Zamawiającego oraz Wykonawcy
5.10.3.2. Plan Projektu
W przypadku planowania wdrożenia rozwiązania równoważnego Wykonawca w terminie 30 dni od zawarcia Umowy przedstawi Zamawiającemu do akceptacji Plan Projektu zawierający w szczególności:
szczegółowy opis i zakres prac niezbędnych do realizacji wdrożenia, niezbędne zasoby realizacyjne i harmonogram prac.
5.10.3.3. Projekt Biznesowo-Techniczny
Projekt Biznesowo-Techniczny podlega procesowi odbioru i akceptacji przez Zamawiającego, którego kryterium jest ocena merytoryczna dokumentu. Zamawiający przekazuje Wykonawcy uwagi niezwłocznie (jednak w terminie nie dłuższym niż 7 dni), Wykonawca jest zobowiązany je uwzględnić w terminie 3 dni roboczych.Zamawiający dokona 4 przeglądów Analizy wymagań i Projektu Biznesowo-Technicznego przygotowanego przez Wykonawcę w trybie śledzenia zmian i wprowadzania komentarzy. Dokumentacja będzie weryfikowana w następujących etapach zaawansowania prac nad dokumentem:
25% - struktura dokumentu i najważniejsze decyzje projektowe 75% - dokument zawierający wszystkie ogólne elementy projektu 95% - dokument zawierający szczegółowe założenia
str. 60
99% - wersja finalna zawierająca wszelkie uzupełnienia zgłaszane ze strony Zamawiającego
Zamawiający decyduje, czy dany etap zaawansowania prac został osiągnięty.
Dokument projektu technicznego rozwiązania równoważnego powinien zawierać:
Wprowadzenie zawierające podejście do rozwiązania problemu i wybrane rozwiązania
Architekturę systemu – szczegółowa specyfikacja wszystkich elementów tworzących system, w tym wszystkie elementy tworzące środowisko produkcyjne i dewelopersko/testowe, opis komponentów funkcjonalnych rozwiązania, ich wzajemne powiązania oraz kierunki przepływu informacji.
Konfigurację centralnego repozytorium tożsamości: informacje dotyczące modelu oraz struktury danych w repozytorium, w których będą przechowywane tożsamości oraz przechowywany atrybutów
Projekt ról biznesowych Projekt konfiguracji portalu użytkownika Projekt konfiguracji konektorów do poszczególnych systemów
zintegrowanych z rozwiązaniem równoważnym, Projekt implementacji workflow Projekt raportów
5.10.3.4. Plan Testów
Plan testów akceptacyjnych musi obejmować następujące obszary: testy funkcjonalne – weryfikacja realizowanych funkcjonalności
pod kątem wymagań opisanych w dokumencie analizy wymagań testy niezawodności – potwierdzające zakładane parametry
niezawodności (HA) testy bezpieczeństwa – potwierdzające zakładany poziom
bezpieczeństwa informacji testy procedur – weryfikacja realizowanych funkcjonalności pod
kątem procedur opisanych w dokumencie analizy wymagań testy wydajnościowe – potwierdzające zakładane parametry
wydajnościowe.
str. 61
5.10.3.5. Materiały na potrzeby szkoleń e-learningowych
1. Wykonawca zobowiązany jest do przygotowania materiałów szkoleniowych dla użytkowników końcowych i administratorów systemu w formie szkoleń e-learning na platformie SAP LSO.
2. Materiały szkolenia e-learningowego wykonane mają być w języku polskim w postaci elektronicznej w formacie SCORM 2004/4.
3. Dla szkoleń e-learningowych Wykonawca zapewni profesjonalne Materiały szkoleniowe, zawierające część teoretyczną oraz ćwiczenia pozwalające na aktywne zdobywanie wiedzy w zakresie:
praca z portalem użytkownika, obsługa wniosków i formularzy, delegowanie zadań i uprawnień, monitorowanie statusu zadań, czynności wykonywane przez administratorów lokalnych (sądów
powszechnych).4. Materiały szkoleniowe muszą być dostępne w polskiej wersji językowej w
postaci elektronicznej.5. Wykonawca z terminie 30 dni od zawarcia Umowy przedstawi
Zamawiającemu do akceptacji projekt Materiałów szkoleniowych. W terminie 14 dni od dnia przedstawienia, Zamawiający zgłosi uwagi lub dokona akceptacji. W terminie 7 dni od dnia zgłoszenia uwag przez Zamawiającego, Wykonawca poprawi projekt Materiałów szkoleniowych. Wykonawca zobowiązany jest do uwzględnienia uwag Zamawiającego. Warunkiem przystąpienia do realizacji Materiałów szkoleniowych jest akceptacja projektu przez Zamawiającego.
6. Projekt powinien zawierać co najmniej:a. informacje o sposobie przekazania wiedzy, b. plan szkolenia, c. podział na bloki tematyczne, d. informacje o formie sprawdzenia i utrwalenia wiedzy, e. informacje o wykorzystanych funkcjach i dodatkach (np.
zdjęcia, zapisy audio lub audio-wideo), które mają przyczynić się do uatrakcyjnienia szkolenia,
f. informacje o formie sprawdzenia nabytej wiedzy, g. informacje o sposobie stylizacji slajdów, h. projekt wizualno-funkcjonalny szkolenia w postaci
reprezentatywnych ekranów szkolenia (prototyp szkolenia zawierający do kilkunastu ekranów szkolenia ujmujący wszystkie typy ekranów i formy dydaktyczne zaplanowane w szkoleniu oraz umożliwiające prezentację nawigacji i narracji),
i. wkład merytoryczny (wszelkie treści dydaktyczne, które będą składały się na przygotowane szkolenia w postaci tekstowej gotowe do przetworzenia na postać szkolenia e-learningowego).
str. 62
7. W przypadku zmian w Systemie wynikających z instalacji nowych wersji na skutek naprawy błędów, Wykonawca dokona aktualizacji materiałów dla usługi szkoleń e-learningowych, każdorazowo w terminie 30 dni kalendarzowych od wprowadzenia jakichkolwiek zmian.
5.10.3.6. Dokumentacja powykonawcza
Wykonawca zaktualizuje dokumentację zgodnie z zaakceptowanymi przez Zamawiającego standardami w dziedzinie dokumentowania określonymi w Planie Projektu.
Wykonawca zobowiązuje się do opracowania dokumentacji w języku polskim w jednym wydrukowanym egzemplarzu oraz w wersji elektronicznej w formacie DOC i formacie PDF w przypadku dokumentów tekstowych oraz innych formatach w przypadku diagramów oraz schematów drogą elektroniczną.
Wszystkie dokumenty tworzone w ramach realizacji przedsięwzięcia charakteryzowały się będą wysoką jakością, na którą będą miały wpływ, takie czynniki jak:
Czytelna i zrozumiała struktura zarówno poszczególnych dokumentów jak i całej dokumentacji z podziałem na rozdziały, podrozdziały i sekcje
Zachowanie standardów, a także sposób pisania, rozumianych jako zachowanie jednolitej i spójnej struktury, formy i sposobu prezentacji treści poszczególnych dokumentów oraz fragmentów tego samego dokumentu jak również całej dokumentacji.
Kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego zagadnienia. Oznacza to w szczególności jednoznaczne i wyczerpujące przedstawienie wszystkich zagadnień w odniesieniu do systemu.
Spójność i niesprzeczność dokumentu, rozumianych jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu.
Dokumentacja musi być przekazana w formatach umożliwiających jej późniejszą edycję.
W przypadku zmian w Systemie wynikających z instalacji nowych wersji lub na skutek naprawy błędów, których konsekwencją jest konieczność
str. 63
aktualizacji dokumentacji, Wykonawca dokona aktualizacji dokumentacji Systemu.
Cała dokumentacja, o której mowa powyżej, podlegała będzie akceptacji Zamawiającego.
Dokumentacja powykonawcza wdrożenia rozwiązania równoważnego musi zawierać obszary:
Architekturę systemu: opis poszczególnych komponentów technicznych, logicznych oraz aspekty niezawodnościowe
Opis ról biznesowych Opis konfiguracji portalu użytkownika Opis konfiguracji konektorów do poszczególnych systemów
zintegrowanych z SZT Opis implementacji workflow Opis raportów Procedury eksploatacyjne Procedury awaryjne
5.10.3.7. Dokumentacja użytkownika
Dokumentacja użytkownika projektu SZT musi zawierać obszary: Opis interfejsu portalu samoobsługi SZT Opis przebiegu poszczególnych procesów akceptacyjnych
Dokumentacja podlega procesowi odbioru i akceptacji przez Zamawiającego, którego kryterium jest ocena merytoryczna dokumentu. Zamawiający przekazuje Wykonawcy uwagi niezwłocznie (jednak w terminie nie dłuższym niż 7 dni), Wykonawca jest zobowiązany je uwzględnić w terminie 3 dni roboczych.Zamawiający dokona 2 przeglądów projektu dokumentacji przygotowanego przez Wykonawcę w trybie śledzenia zmian i wprowadzania komentarzy. Dokumentacja będzie weryfikowana w następujących etapach zaawansowania prac: 50% - struktura dokumentu, projekty wszystkich obszarów
dokumentacji, 100% - wersja finalna zawierająca wszelkie uzupełnienia zgłaszane
ze strony Zamawiającego
str. 64
5.11. Testy
W ramach przedmiotu niniejszego postępowania Wykonawca rozwiązania równoważnego przeprowadzi:
5.11.1. Testy rozwiązania równoważnego
Warunkiem koniecznym wdrożenia rozwiązania równoważnego jest pozytywny wynik testów, potwierdzający spełnienie kryteriów w odniesieniu do wymagań określonych w rozdziałach od 3.1.1 Ogólne funkcjonalności systemu do 3.1.7 Oprogramowanie dedykowane włącznie.
5.11.2. Testy nowych funkcjonalności Modyfikacji Oprogramowania
Pozytywny wynik testów potwierdzony przez Zamawiającego, jest warunkiem koniecznym do uzyskania akceptacji produkcyjnego wdrożenia nowej wersji Oprogramowania Dedykowanego rozwiązania równoważnego,, zawierającej nową funkcjonalność lub pakiet nowych funkcjonalności. Testy te będą realizowane w ramach Modyfikacji Oprogramowania, zlecanych przez Zamawiającego.
5.11.3. Cykliczne testy wydajnościowe
Rozbudowa systemu równoważnego o nowe funkcjonalności oraz o przetwarzanie dodatkowych 4 tysięcy kont technicznych musi zapewniać wydajność systemu SZT, spełniającą kryteria zdefiniowane w rozdziale 3.1.4 Wymaganiawydajnościowe. Wymagania te zostaną potwierdzone testami wydajnościowymi i będą realizowane w terminach zleconych przez Zamawiającego, nie częściej niż jeden raz w roku 2018 i jeden raz w roku 2019.
Testy wydajnościowe zostaną przeprowadzone przy wykorzystaniu narzędzia pozwalającego na przeprowadzenie symulacji pracy realnych użytkowników końcowych według scenariusza określonego w rozdziale 4.5.3 Cykliczne testywydajnościowe.
5.11.4. Cykliczne testy niezawodnościoweZamawiający dwukrotnie w czasie obowiązywania Umowy przeprowadzi ocenę spełnienia przez rozwiązanie równoważne kryteriów niezawodnościowych, zdefiniowanych w rozdziale 3.1.3 Wymagania niezawodnościowe.
str. 65
5.11.5. Kryteria akceptacji testów
Wynik testów funkcjonalnych dla funkcjonalności wdrażanego rozwiązania równoważnego oraz testów funkcjonalnych realizowanych w ramach Modyfikacji Systemu uznaje się za pozytywny, gdy występuje zgodność opisu oczekiwanego wyniku ze Scenariusza testów stworzonego przez Wykonawcę, z faktycznym stanem po zakończeniu danego przypadku testowego, w warunkach określonych w danym przypadku testowym.
Wynik testów funkcjonalnych uznaje się za negatywny, gdy którykolwiek ze składowych wyników rzeczywistych określonych w scenariuszu testów, stworzonym przez Wykonawcę, różni się od oczekiwanego.
Wynik testów niezawodności uznaje się za pozytywny, gdy występuje zgodność oczekiwanego wyniku ze Scenariusza testów stworzonego przez Wykonawcę z faktycznym stanem po zakończeniu danego przypadku testowego.
Wynik testów wydajnościowych uznaje się za pozytywny jeśli 100% odpowiedzi serwera aplikacyjnego jest poprawnych, a 95% odpowiedzi jest lepszych od progu akceptacji określonego w Tabeli powyżej w kolumnie Maksymalny czas oczekiwania.
5.11.6. Scenariusze testoweSzczegółowe Scenariusze testowe muszą zostać stworzone przez Wykonawcę SZT i zaakceptowane przez Zamawiającego. Scenariusze testowe powinny obejmować następujące obszary:Testy funkcjonalności rozwiązania równoważnego,Testy wydajności,Testy niezawodności.Scenariusze testów podlegają procesowi odbioru i akceptacji przez Zamawiającego, którego kryterium jest ocena merytoryczna dokumentu. Zamawiający przekazuje uwagi Wykonawcy niezwłocznie (jednak w terminie nie dłuższym niż 7 dni), Wykonawca jest zobowiązany je uwzględnić w terminie 3 dni roboczych.
5.12. Harmonogram ramowy dla rozwiązania równoważnego
Harmonogram ramowy dla rozwiązania równoważnego został przedstawiony w poniższej tabeli.
str. 66
Nr etapu
Termin realizacji Zadania
Etap I do 4 tygodni od dnia zawarcia Umowy
Dostarczenie Planu Projektu wdrożenia rozwiązania równoważnego
do 12 tygodni od dnia zawarcia Umowy
Przygotowanie Analizy Wymagań i Projektu Biznesowo-Technicznego dla rozwiązania równoważnego
do 16 tygodni od dnia zawarcia Umowy
Dostarczenie rozwiązania równoważnego do testów
do 20 tygodni od dnia zawarcia Umowy
Pozytywne przeprowadzenie testów rozwiązania równoważnego
do 22 tygodni od dnia zawarcia Umowy
Wdrożenie przedprodukcyjne rozwiązania równoważnego
do 24 tygodni od dnia zawarcia Umowy
Wdrożenie produkcyjne rozwiązania równoważnego
do 24 tygodni od dnia zawarcia Umowy
Dostawa szkolenia e-learningowego dla administratorów i przeprowadzenie szkolenia
Etap II do 2 tygodni od podpisania przez Strony bez zastrzeżeń Protokołu Odbioru Rozwiązania Równoważnego
Dostawa 56 000 licencji dla rozwiązania równoważnego dla Użytkowników wewnętrznych
do 2 tygodni od podpisania przez Strony bez zastrzeżeń Protokołu Odbioru Rozwiązania Równoważnego
Dostawa 4 000 licencji dla rozwiązania równoważnego dla Użytkowników zewnętrznych
do 2 tygodni od podpisania przez Strony bez zastrzeżeń Protokołu Odbioru Rozwiązania Równoważnego
Dostawa Dokumentacji dla rozwiązania równoważnego
Etap III 36 miesięcy, liczone od pierwszego dnia kolejnego miesiąca po podpisaniu Umowy
Świadczenie usług utrzymania odpowiednio dla rozwiązania posiadanego przez Zamawiającego/Rozwiązania Równoważnego
str. 67
Etap IV 36 miesięcy, liczone od pierwszego dnia kolejnego miesiąca po podpisaniu Umowy lub do wykorzystania limitu modyfikacji w wysokości 5 000 roboczogodzin
Świadczenie usług Modyfikacji odpowiednio dla rozwiązania posiadanego przez Zamawiającego/Rozwiązania Równoważnego
str. 68
6. Załączniki
6.1. Formularz wniosku o Modyfikację
Nr zmiany
Nazwa zmiany
CZĘŚĆ A
ZLECENIE ANALIZY
Priorytet zmiany wg Zamawiającego
*) Priorytet W-wysoki, S-średni, N-niski
Przyczyna zmiany
Szacowana czasochłonność analizy
*)w godzinach roboczych Warunki realizacji
*) Warunki/zasoby niezbędne do realizacji zmiany
Uwagi dodatkowe
AKCEPTACJA/ODRZUCENIE ANALIZY data i podpis Zlecającego
FAKTYCZNA CZASOCHŁONNOŚĆ ANALIZY
CZĘŚĆ B
OPIS ZMIANY - WYNIK
str. 69
ANALIZY
Specyfikacja Wymagania/ opis zmiany:
Zakres zmiany (zmiana obejmie):
Proponowane scenariusze rozwiązania:
Korzyści i ryzyka wynikające z wdrożenia lub zaniechania realizacji zmiany
Zasoby niezbędne do realizacji zadania
Szacowana czasochłonność realizacji (prace po stronie Wykonawcy) *)w godzinach roboczych
Harmonogram prac Uzgodnienia prowadzono z:
AKCEPTACJA/ODRZUCENIE OPISU ZMIANY - WYNIKU ANALIZY *)
*) zatwierdzenie kompletności i jakości opisu zmiany
ZLECENIE/ODRZUCENIE REALIZACJI ZMIANY data i podpis Zlecającego
CZĘŚĆ C
PODSUMOWANIE ZMIANY
Opis i zakres wprowadzonych zmian
*) załącznik w postaci dokumentacji zmian zrealizowanych w ramach Modyfikacji Systemu
Faktyczna czasochłonność zmiany
str. 70
str. 71
6.2. Protokół Odbioru Rozwiązania Równoważnego
Protokół Odbioru Rozwiązania Równoważnego
ZAMAWIAJĄCYSąd Apelacyjny we Wrocławiu53-330 Wrocław, ul. Energetyczna 4
WYKONAWCA…………………………………………….…………………………………………….
Data zgłoszenia do odbioru: ………………….Data odbioru: ………………….
Strony potwierdzają, że:
a) Wykonawca dostarczył Plan Projektu Wdrożenia dla rozwiązania równoważnego w dniu …
b) Wykonawca dostarczył Analizę Wymagań i Projekt Biznesowo-Techniczny dla rozwiązania \
c) równoważnego w dniu …d) Wykonawca dostarczył rozwiązanie równoważne do testów w dniu …e) Zamawiający potwierdził pozytywne przeprowadzenie testów dla
rozwiązania równoważnego f) w dniu …g) Wykonawca wdrożył przedprodukcyjne rozwiązanie równoważne w dniu …h) Wykonawca wdrożył produkcyjne rozwiązanie równoważne w dniu …i) Wykonawca dostarczył szkolenia e-learningowe w dniu …Wykonawca
przeprowadził szkolenie w dniach … Załącznikiem do niniejszego protokołu odbioru są listy obecności na tym szkoleniuWykonawca wydał następującym uczestnikom szkolenia zaświadczenia oraz materiały szkoleniowe:
…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….
str. 72
Strony potwierdzają, że:Wykonanie powyższych zadań nastąpiło zgodnie z Umową; TAK/NIE*;Strony stwierdzają, że wykonanie powyższych zadań nastąpiło z opóźnieniem. TAK/NIE*. [Jeśli zaznaczono tak, terminy opóźnień należy wpisać w uwagach]
Uwagi: …………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….
Załączniki:…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….
/czytelne podpisy i pieczątki/
Podpis za WYKONAWCĘ: Podpis za ZAMAWIAJĄCEGO:
*Niepotrzebne skreślić
str. 73
6.3. Protokół Odbioru Rozwiązania Równoważnego
Protokół Odbioru Licencji i Dokumentacji (RR)
ZAMAWIAJĄCYSąd Apelacyjny we Wrocławiu53-330 Wrocław, ul. Energetyczna 4
WYKONAWCA…………………………………………….…………………………………………….
Data zgłoszenia do odbioru: ………………….Data odbioru: ………………….
Strony potwierdzają, że:
a) Wykonawca dostarczył 56 000 licencji dla Użytkowników wewnętrznych w dniu …
b) Wykonawca dostarczył 4 000 licencji dla Użytkowników zewnętrznych w dniu …
c) Wykonawca dostarczył Dokumentację dla rozwiązania równowaznego w dniu …
Strony potwierdzają, że:Wykonanie powyższych zadań nastąpiło zgodnie z Umową;TAK/NIE*;Strony stwierdzają, że wykonanie powyższych zadań nastąpiło z opóźnieniem. TAK/NIE*. [Jeśli zaznaczono tak, terminy opóźnień należy wpisać w uwagach]
Uwagi: …………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….…………………………………………………………………………………………………….
/czytelne podpisy i pieczątki/
Podpis za WYKONAWCĘ: Podpis za ZAMAWIAJĄCEGO:
str. 74
*Niepotrzebne skreślić
6.4. Lista dystrybucyjna
LP nazwa sądu1 Sąd Apelacyjny Warszawa2 Sąd Apelacyjny Katowice3 Sąd Apelacyjny Gdańsk4 Sąd Apelacyjny Poznaniu5 Sąd Apelacyjny Kraków6 Sąd Apelacyjny Wrocław7 Sąd Apelacyjny Łódź8 Sąd Apelacyjny Rzeszów9 Sąd Apelacyjny Białystok
10 Sąd Apelacyjny Lublin11 Sąd Apelacyjny Szczecin12 Sąd Okręgowy w Jeleniej Górze13 Sąd Okręgowy w Legnicy14 Sąd Okręgowy w Opolu15 Sąd Okręgowy w Świdnicy16 Sąd Okręgowy we Wrocławiu17 Sąd Okręgowy w Białymstoku18 Sąd Okręgowy w Łomży19 Sąd Okręgowy w Olsztynie20 Sąd Okręgowy w Suwałkach21 Sąd Okręgowy w Bydgoszczy22 Sąd Okręgowy w Elblągu23 Sąd Okręgowy w Gdańsku24 Sąd Okręgowy w Słupsku25 Sąd Okręgowy w Toruniu26 Sąd Okręgowy we Włocławku27 Sąd Okręgowy w Bielsku-Białej28 Sąd Okręgowy w Częstochowie29 Sąd Okręgowy w Gliwicach30 Sąd Okręgowy w Katowicach31 Sąd Okręgowy w Kielcach32 Sąd Okręgowy w Krakowie33 Sąd Okręgowy w Nowym Sączu34 Sąd Okręgowy w Tarnowie35 Sąd Okręgowy w Lublinie36 Sąd Okręgowy w Radomiu37 Sąd Okręgowy w Siedlcach38 Sąd Okręgowy w Zamościu39 Sąd Okręgowy w Kaliszu40 Sąd Okręgowy w Łodzi41 Sąd Okręgowy w Piotrkowie Tryb.
str. 75
42 Sąd Okręgowy w Sieradzu43 Sąd Okręgowy w Koninie44 Sąd Okręgowy w Poznaniu45 Sąd Okręgowy w Zielonej Górze46 Sąd Okręgowy w Krośnie47 Sąd Okręgowy w Przemyślu48 Sąd Okręgowy w Rzeszowie49 Sąd Okręgowy w Tarnobrzegu50 Sąd Okręgowy w Gorzowie Wlkp.51 Sąd Okręgowy w Koszalinie52 Sąd Okręgowy w Szczecinie53 Sąd Okręgowy w Ostrołęce54 Sąd Okręgowy w Płocku55 Sąd Okręgowy w Warszawie56 Sąd Okręgowy Warszawa - Praga57 Sąd Rejonowy w Jeleniej Górze58 Sąd Rejonowy w Legnicy59 Sąd Rejonowy w Głogowie60 Sąd Rejonowy w Kędzierzynie-Koźlu61 Sąd Rejonowy w Kluczborku62 Sąd Rejonowy w Nysie63 Sąd Rejonowy w Opolu64 Sąd Rejonowy w Kłodzku65 Sąd Rejonowy w Świdnicy66 Sąd Rejonowy w Wałbrzychu67 Sąd Rejonowy Wrocław-Fabryczna68 Sąd Rejonowy Wrocław-Krzyki69 Sąd Rejonowy Wrocław-Śródmieście70 Sąd Rejonowy w Oleśnicy71 Sąd Rejonowy w Lubinie72 Sąd Rejonowy w Dzierżoniowie73 Sąd Rejonowy w Oławie74 Sąd Rejonowy w Środzie Śląskie75 Sąd Rejonowy w Trzebnicy76 Sąd Rejonowy w Bolesławcu77 Sąd Rejonowy w Zgorzelcu78 Sąd Rejonowy w Złotoryi79 Sąd Rejonowy w Brzegu80 Sąd Rejonowy w Prudniku81 Sąd Rejonowy w Strzelcach Opolskich82 Sąd Rejonowy w Ząbkowicach83 Sąd Rejonowy w Białymstoku84 Sąd Rejonowy w Bielsku Podlaskim85 Sąd Rejonowy w Sąd Okręgowykółce86 Sąd Rejonowy w Łomży87 Sąd Rejonowy w Bartoszycach
str. 76
88 Sąd Rejonowy w Giżycku89 Sąd Rejonowy w Kętrzynie90 Sąd Rejonowy w Olsztynie91 Sąd Rejonowy w Szczytnie92 Sąd Rejonowy w Ostrołęce93 Sąd Rejonowy w Ostrowi Mazow.94 Sąd Rejonowy w Przasnyszu95 Sąd Rejonowy w Wyszkowie96 Sąd Rejonowy w Augustowie97 Sąd Rejonowy w Ełku98 Sąd Rejonowy w Olecku99 Sąd Rejonowy w Suwałkach
100 Sąd Rejonowy w Bydgoszczy101 Sąd Rejonowy w Inowrocławiu102 Sąd Rejonowy w Świeciu103 Sąd Rejonowy w Braniewie104 Sąd Rejonowy w Elblągu105 Sąd Rejonowy w Iławie106 Sąd Rejonowy w Ostródzie107 Sąd Rejonowy Gdańsk - Południe108 Sąd Rejonowy Gdańsk - Północ109 Sąd Rejonowy w Gdyni110 Sąd Rejonowy w Kartuzach111 Sąd Rejonowy w Kwidzynie112 Sąd Rejonowy w Malborku113 Sąd Rejonowy w Sąd Okręgowypocie114 Sąd Rejonowy Starogard Gdański115 Sąd Rejonowy w Tczewie116 Sąd Rejonowy w Wejherowie117 Sąd Rejonowy w Chojnicach118 Sąd Rejonowy w Człuchowie119 Sąd Rejonowy w Lęborku120 Sąd Rejonowy w Słupsku121 Sąd Rejonowy w Brodnicy122 Sąd Rejonowy w Grudziądzu123 Sąd Rejonowy w Toruniu124 Sąd Rejonowy w Lipnie125 Sąd Rejonowy we Włocławku126 Sąd Rejonowy w Bielsku-Białej127 Sąd Rejonowy w Cieszynie128 Sąd Rejonowy w Żywcu129 Sąd Rejonowy w Częstochowie130 Sąd Rejonowy w Myszkowie131 Sąd Rejonowy w Zawierciu132 Sąd Rejonowy w Gliwicach133 Sąd Rejonowy w Jastrzębiu-Zdroju
str. 77
134 Sąd Rejonowy w Raciborzu135 Sąd Rejonowy w Rudzie Śląskiej136 Sąd Rejonowy w Rybniku137 Sąd Rejonowy w Tarnowskich Górach138 Sąd Rejonowy w Wodzisławiu Śląskim139 Sąd Rejonowy w Zabrzu140 Sąd Rejonowy w Żorach141 Sąd Rejonowy w Będzinie142 Sąd Rejonowy w Bytomiu143 Sąd Rejonowy w Chorzowie144 Sąd Rejonowy w Dąbrowie Górniczej145 Sąd Rejonowy w Jaworznie146 Sąd Rejonowy w Katowicach Wsch.147 Sąd Rejonowy w Katowicach Zach.148 Sąd Rejonowy w Mikołowie149 Sąd Rejonowy w Mysłowicach150 Sąd Rejonowy w Pszczynie151 Sąd Rejonowy w Siemianowicach Śl.152 Sąd Rejonowy w Sąd Okręgowysnowcu153 Sąd Rejonowy w Tychach154 Sąd Rejonowy w Busku Zdroju155 Sąd Rejonowy w Jędrzejowie156 Sąd Rejonowy w Kielcach157 Sąd Rejonowy w Końskich158 Sąd Rejonowy w Ostrowcu Świętokrz.159 Sąd Rejonowy w Sandomierzu160 Sąd Rejonowy w Skrażysku-Kamiennej161 Sąd Rejonowy w Starachowicach162 Sąd Rejonowy w Chrzanowie163 Sąd Rejonowy dla Krakowa-Krowodrzy164 Sąd Rejonowy dla Krakowa-Nowej Huty165 Sąd Rejonowy dla Krakowa-Podgórza166 Sąd Rejonowy dla Krakowa-Śródmieśc.167 Sąd Rejonowy w Myślenicach168 Sąd Rejonowy w Olkuszu169 Sąd Rejonowy w Oświęcimiu170 Sąd Rejonowy w Wadowicach171 Sąd Rejonowy w Wieliczce172 Sąd Rejonowy w Gorlicach173 Sąd Rejonowy w Limanowej174 Sąd Rejonowy w Nowym Sączu175 Sąd Rejonowy w Nowym Targu176 Sąd Rejonowy w Zakopanem177 Sąd Rejonowy w Bochni178 Sąd Rejonowy w Brzesku179 Sąd Rejonowy w Tarnowie
str. 78
180 Sąd Rejonowy w Białej Podlaskiej181 Sąd Rejonowy w Chełmie182 Sąd Rejonowy w Kraśniku183 Sąd Rejonowy Lublin-Wschód184 Sąd Rejonowy Lublin-Zachód185 Sąd Rejonowy w Łukowie186 Sąd Rejonowy w Puławach187 Sąd Rejonowy w Radzyniu Podl.188 Sąd Rejonowy w Grójcu189 Sąd Rejonowy w Kozienicach190 Sąd Rejonowy w Radomiu191 Sąd Rejonowy w Garwolinie192 Sąd Rejonowy w Mińsku Maz.193 Sąd Rejonowy w Siedlcach194 Sąd Rejonowy w Węgrowie195 Sąd Rejonowy w Biłgoraju196 Sąd Rejonowy w Hrubieszowie197 Sąd Rejonowy w Tomaszowie Lub.198 Sąd Rejonowy w Zamościu199 Sąd Rejonowy w Kaliszu200 Sąd Rejonowy w Ostrowie Wlkp.201 Sąd Rejonowy w Kutnie202 Sąd Rejonowy w Łowiczu203 Sąd Rejonowy dla Łodzi-Śródmieścia204 Sąd Rejonowy dla Łodzi-Widzewa205 Sąd Rejonowy w Pabianicach206 Sąd Rejonowy w Skierniewicach207 Sąd Rejonowy w Zgierzu208 Sąd Rejonowy w Bełchatowie209 Sąd Rejonowy w Opocznie210 Sąd Rejonowy w Piotrkowie Tryb.211 Sąd Rejonowy w Radomsku212 Sąd Rejonowy w Tomaszowie Maz.213 Sąd Rejonowy w Ciechanowie214 Sąd Rejonowy w Mławie215 Sąd Rejonowy w Płocku216 Sąd Rejonowy w Płońsku217 Sąd Rejonowy w Sąd Okręgowychaczewie218 Sąd Rejonowy w Żyrardowie219 Sąd Rejonowy w Łasku220 Sąd Rejonowy w Sieradzu221 Sąd Rejonowy w Wieluniu222 Sąd Rejonowy w Zduńskiej Woli223 Sąd Rejonowy w Koninie224 Sąd Rejonowy w Kole225 Sąd Rejonowy w Turku
str. 79
226 Sąd Rejonowy w Gnieźnie227 Sąd Rejonowy w Lesznie228 Sąd Rejonowy w Pile229 Sąd Rejonowy Poznań Grunwald Jeżyce230 Sąd Rejonowy Poznań Nw Miasto Wilda231 Sąd Rejonowy Poznań Stare Miasto232 Sąd Rejonowy w Szamotułach233 Sąd Rejonowy w Trzciance234 Sąd Rejonowy w Wągrowcu235 Sąd Rejonowy w Krośnie Odrzańskim236 Sąd Rejonowy w Nowej Sąd Okręgowyli237 Sąd Rejonowy w Świebodzinie238 Sąd Rejonowy w Zielonej Górze239 Sąd Rejonowy w Żaganiu240 Sąd Rejonowy w Żarach241 Sąd Rejonowy w Jaśle242 Sąd Rejonowy w Krośnie243 Sąd Rejonowy w Lesku244 Sąd Rejonowy w Sanoku245 Sąd Rejonowy w Jarosławiu246 Sąd Rejonowy w Przemyślu247 Sąd Rejonowy w Dębicy248 Sąd Rejonowy w Łańcucie249 Sąd Rejonowy w Rzeszowie250 Sąd Rejonowy w Mielcu251 Sąd Rejonowy w Stalowej Woli252 Sąd Rejonowy w Tarnobrzegu253 Sąd Rejonowy w Gorzowie Wlkp.254 Sąd Rejonowy w Słubicach255 Sąd Rejonowy w Białogardzie256 Sąd Rejonowy w Drawsku Pomorskim257 Sąd Rejonowy w Kołobrzegu258 Sąd Rejonowy w Koszalinie259 Sąd Rejonowy w Szczecinku260 Sąd Rejonowy w Wałczu261 Sąd Rejonowy w Goleniowie262 Sąd Rejonowy w Gryficach263 Sąd Rejonowy w Gryfinie264 Sąd Rejonowy w Myśliborzu265 Sąd Rejonowy w Stargardzie Szczec.266 Sąd Rejonowy Szczecin Centrum267 Sąd Rejonowy Szczecin Praw i Zachód268 Sąd Rejonowy w Świnoujściu269 Sąd Rejonowy w Grodzisku Maz.270 Sąd Rejonowy w Piasecznie271 Sąd Rejonowy w Pruszkowie
str. 80
272 Sąd Rejonowy dla m.st. Warszawy273 Sąd Rejonowy dla Warszawy Mokotowa274 Sąd Rejonowy dla Warszawy Śródm.275 Sąd Rejonowy dla Warszawy Woli276 Sąd Rejonowy dla Warszawy Żoliborza277 Sąd Rejonowy w Legionowie278 Sąd Rejonowy w Nowym Dworze Maz.279 Sąd Rejonowy w Otwocku280 Sąd Rejonowy dla Warszawy Pragi Pd.281 Sąd Rejonowy dla Warszawy Pragi Pn282 Sąd Rejonowy w Wołominie283 Sąd Rejonowy w Gostyninie284 Sąd Rejonowy w Pułtusku285 Sąd Rejonowy w Grajewie
286Sąd Rejonowy w WySąd Okręgowykiem Mazowieckiem
287 Sąd Rejonowy w Zambrowie288 Sąd Rejonowy w Piszu289 Sąd Rejonowy w Nakle n. Notecią290 Sąd Rejonowy w Tucholi291 Sąd Rejonowy w Działdowie292 Sąd Rejonowy w Kościerzynie293 Sąd Rejonowy w Opatowie294 Sąd Rejonowy w Staszowie295 Sąd Rejonowy w Suchej Beskidzkiej296 Sąd Rejonowy w Dąbrowie Tarnowskiej297 Sąd Rejonowy w Opolu Lubelskim298 Sąd Rejonowy w Rykach299 Sąd Rejonowy w Sąd Okręgowykołowie Podlaskim300 Sąd Rejonowy w Krasnymstawie301 Sąd Rejonowy w Jarocinie302 Sąd Rejonowy w Krotoszynie303 Sąd Rejonowy w Pleszewie304 Sąd Rejonowy w Brzezinach305 Sąd Rejonowy w Łęczycy306 Sąd Rejonowy w Rawie Mazowieckiej307 Sąd Rejonowy w Sierpcu308 Sąd Rejonowy w Słupcy309 Sąd Rejonowy w Chodzieży310 Sąd Rejonowy w Gostyniu311 Sąd Rejonowy w Grodzisku Wlkp.312 Sąd Rejonowy w Kościanie313 Sąd Rejonowy w Nowym Tomyślu314 Sąd Rejonowy w Obornikach315 Sąd Rejonowy w Rawiczu316 Sąd Rejonowy w Śremie
str. 81
317 Sąd Rejonowy w Środzie Wielkopolskiej318 Sąd Rejonowy w Wolsztynie319 Sąd Rejonowy w Złotowie320 Sąd Rejonowy we Wrześni321 Sąd Rejonowy w Przeworsku322 Sąd Rejonowy w Leżajsku323 Sąd Rejonowy w Nisku324 Sąd Rejonowy w Strzelcach Krajeńskich325 Sąd Rejonowy w Choszcznie326 Sąd Rejonowy w Kamiennej Górze327 Sąd Rejonowy w Lwówku Śląskim328 Sąd Rejonowy w Oleśnie329 Sąd Rejonowy we Wschowie330 Sąd Funkcjonalny w Biskupcu331 Sąd Funkcjonalny w Lidzbarku Warmińskim332 Sąd Funkcjonalny w Nidzicy333 Sąd Funkcjonalny w Pińczowie334 Sąd Funkcjonalny we Włoszczowie335 Sąd Funkcjonalny w Miechowie336 Sąd Funkcjonalny w Mogilnie337 Sąd Funkcjonalny w Żninie338 Sąd Funkcjonalny w Nowym Mieście Lubawskim339 Sąd Funkcjonalny w Bytowie340 Sąd Funkcjonalny w Miastku341 Sąd Funkcjonalny w Golubiu - Dobrzyniu342 Sąd Funkcjonalny w Wąbrzeźnie343 Sąd Funkcjonalny w Radziejowie344 Sąd Funkcjonalny w Rypinie345 Sąd Funkcjonalny w Włodawie346 Sąd Funkcjonalny w Lipsku347 Sąd Funkcjonalny w Szydłowcu348 Sąd Funkcjonalny w Zwoleniu349 Sąd Funkcjonalny w Janowie Lubelskim350 Sąd Funkcjonalny w Ropczycach351 Sąd Funkcjonalny w Brzozowie352 Sąd Funkcjonalny w Lubaczowie353 Sąd Funkcjonalny w Kolbuszowej354 Sąd Funkcjonalny w Ostrzeszowie355 Sąd Funkcjonalny w Sulęcinie356 Sąd Funkcjonalny w Sławnie357 Sąd Funkcjonalny w Kamieniu Pomorskim358 Sąd Funkcjonalny w Łobzie359 Sąd Funkcjonalny w Jaworze360 Sąd Funkcjonalny w Głubczycach361 Sąd Funkcjonalny w Miliczu362 Sąd Funkcjonalny w Strzelinie
str. 82
363 Sąd Funkcjonalny w Wołowie364 Sąd Funkcjonalny w Międzyrzeczu365 Sąd Funkcjonalny w Kępnie366 Sąd Funkcjonalny w Mrągowie367 Sąd Rejonowy w Szubinie368 Sąd Funkcjonalny w Chełmnie369 Sąd Funkcjonalny w Aleksandrowie Kujawskim370 Sąd Funkcjonalny w Przysusze371 Sąd Rejonowy w Strzyżowie372 Sąd Rejonowy w Lubartowie373 Sąd Rejonowy w Lubaniu374 Sąd Rejonowy w Lublińcu374 Sąd Funkcjonalny w Łańcucie
str. 83