Sąd Apelacyjny we Wrocławiu€¦ · Web viewKorelacja jest wrażliwa na zmiany – jeśli w...

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


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.


Wymagane

4 Synchronizacja zmodyfikowanych atrybutów HCM do systemów informatycznych, np. zmiana nazwiska


Wymagane

5 Możliwość centralnego resetu/zmiany hasła oraz dystrybucja hasła produkcyjnego do systemów informatycznych


Wymagane

6 Zarządzanie uprawnieniami w SI w oparciu o role


Wymagane

7 Możliwość definiowania ról biznesowych grupujących role techniczne SI


Wymagane

8 Przyznanie podstawowych ról biznesowych dla MSS/LSO, AD, Exchange dla wszystkich użytkowników SZT


Wymagane

9 Obsługa procesu akceptacji workflow dla przypisania ról


Wymagane

10 Obsługa procesu akceptacji workflow dla tworzenia i modyfikacji ról biznesowych


Wymagane

11 Obsługa portalu samoobsługi do celów zarządzania tożsamością


Wymagane

12 Dostęp do portalu samoobsługi poprzez przeglądarkę internetową


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)


Wymagane

15 Możliwość uruchomienia zadania identyfikacji naruszeń Separation of Duties na poziomie użytkowników


Wymagane

16 Możliwość uruchomienia zadania identyfikacji naruszeń Separation of Duties na poziomie ról


Wymagane

17 Interfejs portalu samoobsługi SZT oraz systemu akceptacji dostępny w języku polskim i angielskim


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


Wymagane

19 Możliwość weryfikacji przez właściciela roli, tożsamości do niej przypisanych


Wymagane

str. 8

20 Możliwość usunięcia przypisanie roli do użytkownika poprzez właściciela roli


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)


Wymagane

22 Możliwość przypisania ryzyka do wybranej roli (wysokie, średnie, niskie)


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


Wymagane

26 Możliwość porównania stanu przypisania ról do użytkownika w repozytorium tożsamości i systemie informatycznym


Wymagane

27 Automatyczne nadawanie ról w oparciu o określone reguły lub stanowisko w strukturze HCM


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


Wymagane

29 Możliwość czasowego przenoszenia uprawnień pomiędzy użytkownikami


Wymagane

30 Wsparcie procesu nadawania uprawnień administracyjnych w sytuacjach kryzysowych


Wymagane

31 Możliwość weryfikacji czynności wykonanych przy użyciu uprawnień uprzywilejowanych


Wymagane

32 Wsparcie procesu okresowej recertyfikacji uprawnień


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.


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


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


Wymagane

38 Dostępność co najmniej dwóch wersji obszaru roboczego portalu dedykowanych dla użytkownika i administratora


Wymagane

39 Obsługa powiadomień sms dla systemu akceptacji


Wymagane

40 Obsługa powiadomień email dla systemu akceptacji


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]


Wymagane

43 Możliwość wyświetlenie struktury organizacyjnej


Wymagane

44 Wysyłanie powiadomień o upływającym okresie ważności kont w SI (AD, Exchange, ESS/MSS/LSO)


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


Wymagane

50 Możliwość centralnego resetu hasła Funkcjonalność interfejsu administratora portalu samoobsługi

Wymagane

51 Możliwość podglądu statusu procesów workflow


Wymagane

52 Możliwość publikowania komunikatów i dokumentów dla użytkowników


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


Wymagane

56 Możliwość weryfikacji statusu procesu workflow


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)


Wymagane

66 Dostępność konektora dla SAP Netweaver ABAP wykorzystującego SAP API


Wymagane

67 Możliwość tworzenia nowego konektora w przypadku braku obecności standardowego wsparcia dla danego typu integrowanego systemu informatycznego


Wymagane

68 Dostępność konektora dla SAP HCM - jako źródła tożsamości dla systemu zarządzania tożsamością


Wymagane

69 Możliwość obsługi błędów i konfliktów synchronizacji


Wymagane

70 Obsługa powiadomień dla błędów synchronizacji pomiędzy systemami


Wymagane

71 Możliwość przeglądu dziennika synchronizacji wraz z statusem rekordów (zreplikowany prawidłowo, zreplikowany z ostrzeżeniem, niezreplikowany)


Wymagane

72 Możliwość modyfikacji atrybutów podlegających synchronizacji oraz kierunku synchronizacji (jedno, dwukierunkowa)


Wymagane

73 Możliwość replikacji struktury organizacyjnej HCM


Wymagane

74 Możliwość inicjalnego załadowania do SZT użytkowników istniejących w SI


Wymagane

75 Możliwość inicjalnego załadowania do SZT ról istniejących w SI wraz z przypisaniem do użytkowników


Wymagane

76 Możliwość dwukierunkowej synchronizacji przypisania ról do użytkowników pomiędzy SZT a SI


Wymagane

77 Możliwość dwukierunkowej synchronizacji kont użytkowników pomiędzy SZT a SI


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


Opcjonalne

str. 11

80 Możliwość powiadomienia właściciela polityki w przypadku wystąpienia odstępstw


Opcjonalne

81 Proces obsługi odnalezionych odstępstw audytowych poprzez czasową bądź stałą akceptację


Wymagane

82 Definiowanie poziomów ryzyka dla poszczególnych zagrożeń weryfikowanych przez polityki audytu


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


Wymagane

85 Dostępność raportu procesów akceptacji (workflow)


Wymagane

86 Dostępność raportu historii zmian na użytkowniku wraz z osobą wykonującą zmianę


Wymagane

87 Dostępność raportu logowania do portalu samoobsługi


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ą


Wymagane

90 Dostępność raportu użytkowników uprzywilejowanych


Wymagane

91 Dostępność raportu kont na SI niezgodnych z stanem w SZT np.: przyznane niezgodne uprawnienia


Wymagane

92 Dostępność raportu użytkowników zablokowanych


Wymagane

93 Dostępność raportów wydajnościowych kluczowych komponentów oraz raportów pokazujących dostępność Systemu w określonym zakresie czasu


Opcjonalne

3.1.2. Wymagania techniczneNr

wymagania


ś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


Wymagane

96 Repozytorium pozwala na przechowywanie danych (dokumenty doc, pdf, zdjęcia) w postaci BLOB (ang. binary large object)


Wymagane

str. 12

97 Repozytorium pozwala na przechowanie struktury organizacyjnej


Wymagane

98 Repozytorium musi posiadać wydajność pozwalającą na obsługę co najmniej 52500 tożsamości użytkowników


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)


101 Możliwość szyfrowanej komunikacji z systemami informatycznymi


102 Możliwość anonimizacji wybranych danych przy wykonywaniu kopii systemu produkcyjnego na system testowy


103 Szyfrowana transmisja pomiędzy warstwą aplikacji a repozytorium tożsamości


104 Warstwa aplikacji komunikując się z repozytorium sięga bezpośrednio do danych w bazie danych tożsamości


105 Możliwość odebrania uprawnień dla konta administratora bazy (konto z pełnymi uprawnieniami) oraz dystrybucji uprawnień do innych kont


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#


Opcjonalne

108 Dostarczenie narzędzi deweloperskich do rozwoju workflow


Wymagane

109 Możliwość eksportu/importu workflow Wymagania dotyczące narzędzi deweloperskich

Opcjonalne

110 Dostępność narzędzi umożliwiających wersjonowanie kodu


Opcjonalne

111 Możliwość modelowania workflow w trybie graficznym za pomocą obiektów graficznych


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


Wymagane

115 Możliwość odtworzenia bazy danych tożsamości SZT do wybranego punktu w czasie


Wymagane

116 Możliwość szyfrowania kopii zapasowej bazy danych SZT


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


ś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


Wymagane

122 System umożliwia uruchomienie mechanizmu zapewniającego wysoką dostępność - HA


Wymagane

3.1.4. Wymagania wydajnościoweNr

wymagania


ś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


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)


3.1.5. Wymagania infrastrukturalneNr

wymagania


ś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


ś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





Operator systemu

Pracownik HelpDesk

Użytkownik SZT

Menadżer



Audytor


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





Operator systemu

Pracownik HelpDesk

Użytkownik SZT

Menadżer



Audytor


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


SO DB11 Środowisko produkcyjnej bazy danych (lokalizacja podstawowa)

Zainstalowane: MS SQL Server


SO APP21 Środowisko zapasowe produkcyjnych serwerów aplikacyjnych (lokalizacja zapasowa)

Zainstalowane: 2 serwery aplikacyjne Tomcat, SailPoint IIQ


SO DB21 Środowisko zapasowej bazy danych (lokalizacja zapasowa)


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)


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 sekundy


3 sekundy


5 sekund

Oczekiwanie na wyświetlenie ekranu akceptacji wybranego wniosku workflow


3 sekundy


3 sekundy


5 sekund

Odpowiedź systemu na wysłanie formularza wniosku o przyznanie roli


3 sekundy


3 sekundy


5 sekund

Oczekiwanie na raport systemowy


10 minut

str. 37


10 minut


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


Dostarczenie rozwiązania równoważnego do testów


Pozytywne przeprowadzenie testów rozwiązania równoważnego


Wdrożenie przedprodukcyjne rozwiązania równoważnego


Wdrożenie produkcyjne rozwiązania równoważnego


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

Sąd Apelacyjny we Wrocławiu€¦ · Web viewKorelacja jest wrażliwa na zmiany – jeśli w...

Documents

Transcript of Sąd Apelacyjny we Wrocławiu€¦ · Web viewKorelacja jest wrażliwa na zmiany – jeśli w...