Załącznik nr 1 Informacje szczegółowe dotyczące Systemu ... · 3. System Elektronicznego Obiegu Dokumentów (SEOD) Zaprojektowany przez Wykonawcę SEOD musi być kompleksowym

1

Załącznik nr 1

Informacje szczegółowe dotyczące Systemu Elektronicznego Obiegu Dokumentów (SEOD)

1. Zgodność z wymogami prawnymi

Zakres przedmiotowy projektu wymaga zapewnienia jego zgodności z obowiązującymi przepisami

prawa odnoszącymi się do zasad informatyzacji działalności jednostek administracji publicznej oraz do

zasad prezentacji informacji w Internecie. Zatem Wykonawca zapewni zgodność SEOD

z następującymi ustawami regulującymi wymianę i dostęp do informacji wytworzonych w ramach

działania Policji, za pomocą środków komunikacji elektronicznej:

1.1. Ustawa z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (Dz.U. z 2016r.

poz. 1579). Ustawa określa warunki stosowania podpisu elektronicznego, skutki prawne jego

stosowania, zasady świadczenia usług certyfikacyjnych oraz zasady nadzoru nad podmiotami

świadczącymi te usługi.

1.2. Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania

publiczne (tj. Dz. U. 2017 poz. 570 z późń. zm.) wraz z rozporządzeniami wykonawczymi do ustawy.

1.3. Rozporządzenie Rady Ministrów z dnia 8 stycznia 2002 r. w sprawie organizacji przyjmowania

i rozpatrywania skarg i wniosków. (Dz. U. 2002 r. nr 5 poz. 46).

1.4. Kodeks Postępowania Administracyjnego (tj. Dz. U. 2017 poz. 1257 z późń. zm.). Ustawa reguluje m.

in. załatwianie spraw z wykorzystaniem środków komunikacji elektronicznej.

1.5. Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej (tj. Dz. U. 2016 poz. 1764 z późn.

zm.).

1.6. Decyzja nr 38/2016 Komendanta Wojewódzkiego Policji w Lublinie z dnia 05.02.2016 roku w sprawie

szczególnych zasad i trybu wykonywania czynności kancelaryjnych w Komendzie Wojewódzkiej

Policji w Lublinie, Oddziale Prewencji Policji w Lublinie i podległych jednostkach organizacyjnych.

1.7. Ustawa z dnia 29 czerwca 1995r. o statystyce publicznej. (tj. Dz. U. z 2016r., poz. 1068, z późn. zm.).

1.8. Ustawa z dnia 29 sierpnia 1997r. o ochronie danych osobowych (tj. Dz. U. z 2016 r., poz. 922, z późn.

zm.).

1.9. Ustawa z dnia 14 lipca 1983r. o narodowym zasobie archiwalnym i archiwach (tj. Dz. U. z 2016r. poz.

1506., z późn. zm.).

1.10. Ustawa z dnia 20 lipca 2000r. o ogłaszaniu aktów normatywnych i niektórych innych aktów prawnych

(tj. Dz. U. z 2017r. poz. 1523, z późn. zm.).

1.11. Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012r. w sprawie Krajowych Ram

Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci

elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (tj. Dz. U. z 2017r.,

poz. 2247.).

2

1.12. Rozporządzenie Prezesa Rady ministrów z dnia 14 września 2011r. w sprawie sporządzania,

doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów

elektronicznych (tj. Dz. U. z 2015r. poz.971).

1.13. Rozporządzenie Prezesa Rady Ministrów z dnia 20 lipca 2011r. w sprawie podstawowych wymagań

bezpieczeństwa teleinformatycznego (Dz. U. z 2011r. Nr 159, poz. 948).

1.14. Rozporządzenie Ministra Cyfryzacji z dnia 5 października 2016 r. w sprawie zakresu i warunków

korzystania z elektronicznej platformy usług administracji publicznej (Dz. U. z 2016 r. poz. 1626).

1.15. Rozporządzenie Ministra Cyfryzacji z dnia 5 października 2016 r. w sprawie profilu zaufanego

elektronicznej platformy usług administracji publicznej (Dz. U. z 2016r. poz. 1633).

1.16. Rozporządzenie Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej,

jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania

archiwów zakładowych (Dz. U. z 2011 nr 14 poz. 67).

1.17. Rozporządzenie Ministra Cyfryzacji z dnia 5 października 2016 r. w sprawie szczegółowych

warunków organizacyjnych i technicznych, które powinien spełniać system teleinformatyczny służący

do uwierzytelniania użytkowników (Dz. U. z 2016r. poz. 1627).

1.18. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 18 stycznia 2007r. w sprawie

Biuletynu Informacji Publicznej (Dz. U. z 2007r. Nr 10, poz. 68).

1.19. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006r.

w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz. U. z 2006r. Nr 206,

poz. 1517).

1.20. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004r. w sprawie

dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim

powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych

osobowych (Dz. U. z 2004r. Nr 100, poz. 1024).

1.21. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006r. w sprawie

wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono

materiały archiwalne przekazywane do archiwów państwowych, (Dz. U. z 2006r. Nr 206, poz. 1519).

1.22. Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005r. w sprawie testów

akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz. U.

z 2005r. Nr 217, poz. 1836).

1.23. Rozporządzenie Prezesa Rady Ministrów z dnia 27 grudnia 2011r. w sprawie wymagań technicznych

dla dokumentów elektronicznych zawierających akty normatywne i inne akty prawne, dzienników

urzędowych wydawanych w postaci elektronicznej oraz środków komunikacji elektronicznej

i informatycznych nośników danych (Dz. U. z 2011r. Nr 289, poz. 1699).

1.24. Zarządzenie nr 5 Komendanta Głównego Policji z dnia 16 lutego 2017 r. w sprawie metod realizacji

projektów teleinformatycznych i telekomunikacyjnych w Policji (Dz. Urz. KGP z 2017 r. poz. 11).

3

1.25. Zarządzenie nr 920 Komendanta Głównego Policji z dnia 11 września 2008 r. w sprawie metody

i form wykonywania zadań w zakresie działalności archiwalnej w Policji (Dz. Urz. KGP z 2008 r., Nr

16 poz. 95 z późn. zm.).

1.26. Zalecenia dotyczące standardów technicznych, użytkowych i bezpieczeństwa stosowanych w Policji

w zakresie informatyki i łączności z dnia 23 kwietnia 2013r.

1.27. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016r. w sprawie

ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego

przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie

danych) (Dz.Urz.UE.L2016.119.1).

1.28. Dyrektywa Parlamentu Europejskiego i Rady (UE) 2016/680 z dnia 27 kwietnia 2016 r. w sprawie

ochrony osób fizycznych w związku z przetwarzaniem danych osobowych przez właściwe organy do

celów zapobiegania przestępczości, prowadzenia postępowań przygotowawczych, wykrywania

i ścigania czynów zabronionych i wykonywania kar, w sprawie swobodnego przepływu takich danych

oraz uchylająca decyzję ramową Rady 2008/977/WSiSW (Dz.Urz.UE.L2016.119.89).

2. Założenia techniczne

Zamawiający wymaga aby wdrożenie przez Wykonawcę Systemu Elektronicznego Obiegu Dokumentów

w lubelskim garnizonie Policji nastąpiło w wyniku realizacji powiązanych ze sobą działań:

a) w KWP w Lublinie powstanie główne centrum przetwarzania danych (GCPD) oraz zapasowe

centrum przetwarzania danych (ZCPD). Centra powstaną w dwóch różnych lokalizacjach

geograficznych. Centra będą przechowywać dane ze wszystkich jednostek.

b) w jednostkach podległych (KMP/KPP) znajdować się będą lokalne centra przetwarzania danych

(LCPD) tych jednostek,

c) dane pomiędzy LCPD a GCPD będą replikowane zgodnie z harmonogramem zapewniającym

odpowiednie wykorzystanie istniejących połączeń sieciowych między jednostkami podległymi,

a KWP w Lublinie,

d) portal udostępniający e-usługi oraz broker komunikacyjny posadowione będą w środowisku

wirtulizacyjnym Centralnych Systemów Internetowych Policji,

e) połączenie do systemu ePUAP/PZ realizowane będzie z wykorzystaniem dedykowanego kanału L2

Ethernet w sieci OST112.

3. System Elektronicznego Obiegu Dokumentów (SEOD)

Zaprojektowany przez Wykonawcę SEOD musi być kompleksowym systemem realizującym elektroniczny

obieg dokumentów oraz system obsługi i zarządzania procesami zachodzącymi w Policji, zawierającym:

a) moduł obsługi dokumentów,

b) moduł obsługi spraw,

4

c) moduł e-kancelarii,

d) moduł wsparcia procesów biznesowych (WorkFlow),

e) moduł analityczny,

f) moduł administracyjny,

g) moduł archiwum elektronicznego,

h) elektroniczne repozytorium dokumentów,

i) mechanizmy skanowania i przetwarzania danych,

j) bazę kontaktów,

k) pocztową książkę nadawczą,

l) szablony dokumentów.

Schemat SEOD przedstawia poniższy rysunek.

Elektroniczny System

Obiegu Dokumentów

Raporty

ewidencje

Upoważnieni

aUpoważnieni

aUpoważnieni

aUpoważnieni

aDokumenty

wychodzące

Delegowanie uprawnień

Procesy workflow

Relacje

Role i Dynamiczny przydział do zadań

Wersjonowanie

Mechanizmy

Bazy Danych Pracowników

Kadry/LDAP

Inne Systemy Informatyczne

Web Services

faksy

dokumenty

papierowe

nośniki

danych

formularze

elektroniczne

Email + PKI

FormsForms

Archiwum

System

Uwierzytelniania

Urzędowe

Poświadczenia Odbioru

SEOD musi posiadać narzędzia umożliwiające jego konfigurację poprzez graficzny interfejs.

3.1. SEOD musi spełniać wymagania narzucone Ustawą z dnia 29 sierpnia 1997 r. o Ochronie Danych

Osobowych (Dz. U. z 2016 r. poz. 922, z późn. zm.) oraz wydanym na jej podstawie Rozporządzeniem

MSWiA z dnia 29 kwietnia 2004 r. (Dz. U. z 2004 r. nr 100, poz. 1024) dla systemów

przetwarzających dane osobowe.

3.2. System będzie zgodny z Jednolitym Rzeczowym Wykazem Akt Policji (JRWAP).

5

3.3. Dokumenty papierowe będą trafiały do SEOD po zeskanowaniu w wyznaczonych do tego punktach.

W celu wykonywania pierwszej (zgrubnej) klasyfikacji dokumentu w sposób automatyczny, SEOD

będzie wyposażony w narzędzie klasy OCR (Optical Character Recognition - Optyczne

Rozpoznawanie Znaków).

3.4. Elementami procesowania w systemie oprócz dokumentów papierowych (skonwertowanych do

elektronicznych) będą również pliki multimedialne (np. pliki graficzne, nagrania audio, nagrania

video, etc.), powszechnie stosowane w Policji.

3.5. System zapewni możliwość spójnego procesowania sprawy przy udziale wielu jednostek

organizacyjnych w ramach KWP w Lublinie i/lub jednostek podrzędnych. W realizacji jednego

procesu będzie mogło brać udział wielu pracowników z różnych wydziałów i komórek, jednakże

każdy z nich tylko i wyłącznie w ramach własnych kompetencji, odpowiedzialności i przyznanych

uprawnień.

3.6. System zapewni możliwość dostosowania wyglądu aplikacji do własnych potrzeb i preferencji

(personalizacja).

3.7. System zapewni zaawansowane i wydajne mechanizmy wyszukiwania danych i informacji.

Mechanizmy te będą obejmować: wyszukanie danych w całym systemie (tzw. wyszukiwanie globalne,

w ramach dostępnych uprawnień), wyszukiwanie szybkie, wyszukiwanie zaawansowane (pozwalające

na definiowanie dowolnych kryteriów), wyszukiwanie pełnotekstowe informacji w bazie danych oraz

załączonych dokumentach, zapisywanie zdefiniowanych kryteriów wyszukiwania w celu ponownego

ich użycia w przyszłości. Ponadto mechanizm wyszukiwania powinien być odporny na literówki i brak

polskich znaków.

3.8. System będzie wyposażony w zestaw narzędzi dla administratorów. Konfiguracja systemu zarówno od

strony biznesowej (licencje, uprawnienia, itp.) jak też systemowej (ścieżki, logi, backupy, itp.) będzie

wykonywana przy pomocy tych narzędzi. Będą one obejmować także narzędzia dedykowane do

zarządzania jakością danych przechowywanych w SEOD (np. identyfikacja i usuwanie duplikatów,

scalanie danych, etc.).

3.9. Dostęp do narzędzi dla administratorów będzie możliwy po uwierzytelnieniu się użytkownika, przesył

danych będzie posiadał ochronę kryptograficzną co najmniej w zakresie ochrony danych

wykorzystywanych do uwierzytelniania. Wszystkie wykonane czynności będą zapisane w logu

aplikacji.

3.10. Poszczególne elementy SEOD zgodnie z obowiązującym prawem muszą zapewnić bezpieczeństwo

informacji przez co rozumie sie zachowanie poufności, integralności, dostępności, rozliczalności,

autentyczności, niezaprzeczalności i niezawodności.

4. Architektura SEOD i technologie

4.1. Z logicznego punktu widzenia system składa się z następujących komponentów:

a) aplikacji webowej stanowiącej interfejs pracy użytkownika i administratora aplikacji,

b) fizycznego repozytorium plików,

6

c) bazy danych,

d) usług serwisowych odpowiedzialnych za wzajemną integrację komponentów aplikacji oraz

realizację działań biznesowych,

e) procesów workflow,

f) usług workflow,

g) silnika OCR.

4.2. Z uwagi na techniczne wymagania poszczególnych komponentów, generowane obciążenie oraz

zapewnienie bezpieczeństwa w środowiskach produkcyjnych, poszczególne funkcje systemu rozłożone

zostaną na odrębnych serwerach/maszynach wirtualnych. Podział na serwery wirtualne wyglądał

będzie następująco:

a) wirtualna maszyna aplikacyjna – hosting aplikacji,

b) wirtualna maszyna bazodanowa – serwer bazy danych,

c) wirtualna maszyna usługowa – usługi systemu, OCR, repozytorium plikowe,

d) wirtualna maszyna workflow – hosting procesów workflow oraz usługi workflow.

Opisany wyżej podział tworzy zamkniętą strefę dla SEOD, w ramach której odbywa się komunikacja

pomiędzy komponentami systemu. Użytkownik systemu korzysta jedynie z przeglądarki internetowej,

która komunikuje się bezpośrednio ze strefą aplikacyjną i workflow za pomocą szyfrowanego

połączenia (HTTPS).

5. Ogólne wymagania jakie ma spełniać SEOD

5.1. Ma prezentować poszczególne etapy obiegu dokumentów.

5.2. Ma posiadać w pełni polskojęzyczny interfejs użytkownika.

7

5.3. Ma umożliwić rozproszoną rejestrację wszelkiej korespondencji każdego typu wpływającej do

Zamawiającego wraz załącznikami oraz jej automatycznym numerowaniem i oznaczaniem kodem

kreskowym oraz tworzeniem raportów.

5.4. Ma zapamiętywać profile pracy poszczególnych użytkowników i udostępniać je po zalogowaniu na

dowolnej stacji roboczej.

5.5. Ma umożliwić tworzenie ról oraz grup użytkowników.

5.6. Ma posiadać rozbudowany moduł bezpieczeństwa zarządzający dostępem użytkowników zarówno do

odpowiednich dokumentów, jak i funkcji systemu. Dostęp do określonych części/funkcjonalności (jak

rola, moduł) jest kontrolowany uprawnieniami nadanymi użytkownikowi końcowemu. System musi

wspierać możliwość nadawania uprawnień poszczególnym użytkownikom z dokładnością użytkownik,

grupa użytkowników.

5.7. Ma uwzględniać w kalendarzu imieniny oraz soboty, niedziele i święta.

5.8. Ma umożliwiać ustawienie przez administratora komunikatów wraz z określeniem czasu ich publikacji

oraz rodzaju użytkowników dla jakich mają być wyświetlone.

5.9. Działanie SEOD musi zależeć jedynie od przeglądarki w której jest uruchomiony, niezależnie od

systemu operacyjnego w którym jest ona zainstalowana.

5.10. SEOD musi poprawnie działać na aktualnych stabilnych wersjach przeglądarek: Firefox, Chrome,

Edge.

5.11. Ma zapobiegać zamknięciu karty przeglądarki (powinien wyświetlić się odpowiedni komunikat

z ostrzeżeniem) w przypadku gdy trwa jakaś czynność i przerwanie jej mogłoby spowodować utratę

wprowadzonych danych.

5.12. Na stronie domowej, część zasobów jest dostępne dla użytkowników również bez autoryzacji (wzory

pism, ogólne komunikaty dla użytkowników).

5.13. W przypadku awarii pojedynczego serwera lub komponentu fizycznego SEOD musi być nadal

dostępny dla użytkowników. Awaria pojedynczego serwera lub bazy danych nie może powodować

utraty dostępu do SEOD. Każda baza musi posiadać minimum dwie instancje rozproszone pomiędzy

dwoma ośrodkami przetwarzania (GCPD oraz ZCPD) replikowane mechanizmami SEOD.

Przełączenie pomiędzy bazami powinno być automatyczne i niezauważalne dla zalogowanych

użytkowników.

5.14. Musi spełniać wszystkie wskaźniki produktu projektu.

5.15. Musi posiadać mechanizmy zapobiegające powielania danej treści.

5.16. Musi umożliwiać generowanie raportów potrzebnych do sprawozdawczości dla Urzędu

Marszałkowskiego.

5.17. Musi poprawnie działać na Infrastrukturze Zamawiającego.

5.18. Musi posiadać centralną bazę użytkowników. Użytkownik na podstawie danych przechowywanych

w bazie SEOD po autoryzowaniu się zostanie przekierowany do odpowiedniego serwera

obsługującego jego konto i sesję.

8

5.19. Musi umożliwiać import użytkowników z plików wsadowych w formacie np.: Excel, CVS.

Wykonawca przygotuje dla Zamawiającego szablon Excel z walidacją danych umożliwiający

Zamawiającemu przygotować w tym celu odpowiednich plików wsadowych do SEOD. Szablon

powinien uwzględnić wszystkie dane które będzie można wprowadzić do SEOD dla danego

użytkownika (imię i nazwisko, identyfikator kadrowy, uprawnienia w systemie, przypisanie do danej

jednostki organizacyjnej itd.). Administrator przed zapisaniem danych do bazy musi mieć możliwość

podglądu, odpowiednio sformatowanych, importowanych danych. Importowane dane muszą być

również sprawdzane pod kontem ich poprawności. Funkcjonalność ta będzie dostępna tylko dla

administratora KWP.

5.20. Administracja SEOD musi uwzględniać obecnie istniejącą strukturę organizacyjną u Zamawiającego.

5.21. Musi posiadać scentralizowane zarządzanie dające możliwość konfiguracji grupowo jak również

i oddzielnie poszczególne centra przetwarzania danych. Z poziomu zarządzania administrator będzie

mógł zadecydować dla danej jednostki, które z modułów/funkcjonalności będą działały w LCDP

a które w GCPD. W skrajnym przypadku musi być możliwość wyłączenia danego LCPD którego

funkcje przejmie GCPD.

5.22. Certyfikat używany w SEOD do połączenia bezpiecznego musi być podpisany zaufanym organem

certyfikacji. Zamawiający dopuszcza także użycie do podpisu wewnętrznego certyfikatu urzędu

„Infrastruktura”, którym zarządza Komenda Główna Policji.

5.23. Musi posiadać ergonomiczny interfejs użytkownika, kontekstową pomoc, obsługiwać skróty

klawiszowe (użytkownik powinien móc w każdej chwili wyświetlić pomoc z informacją o skrótach

klawiszowych).

5.24. Musi umożliwiać obsługę wielokrotnie podpisanych cyfrowo dokumentów (np. w wyniku

procesowania sprawy która wymaga złożenia na dokumencie kilku podpisów).

5.25. W przypadku edycji podpisanego dokumentu musi ostrzegać użytkownika o tym, że unieważni to

złożony pod dokumentem podpis (po zapisaniu takiego dokumentu system wyraźnie oznacza

nieważność wcześniej złożonych podpisów cyfrowych).

5.26. Musi umożliwić podpisywanie wielu dokumentów elektronicznych jednocześnie.

5.27. Musi umożliwiać podpisanie dokumentu różnego rodzaju podpisami cyfrowymi naraz (np. referent

będzie mógł podpisać dokument za pomocą PZ/BTUU, a następnie kierownik jednostki będzie mógł

użyć podpisu kwalifikowanego).

5.28. Musi umożliwiać weryfikowanie podpisu cyfrowego jakim został podpisany dokument elektroniczny.

Dokument taki musi być odpowiednio oznaczony, oznaczenie wskazuje jakiego typu certyfikat został

użyty do podpisu dokumentu (kwalifikowany, PZ, BTUU) oraz czy użyty do podpisu certyfikat jest

ważny.

5.29. Musi umożliwiać zarządzania zmianami SEOD (wersjonowanie plików konfiguracyjnych, wersji

workflow itd.).

5.30. Musi zapewnić mechanizmy automatycznej aktualizacji wzorów dokumentów i formularzy z GCPD

do LCPD.

9

5.31. Wszędzie tam gdzie w systemie jest możliwość dodania pliku (dokumenty pakietu biurowego, pliki

graficzne, PDF itd.) SEOD musi dawać możliwość zrobienia tego za pomocą funkcji „Przeciągnij

i upuść” (ang. drag and drop) z dowolnego katalogu znajdującego się w komputerze użytkownika.

5.32. Musi umożliwić administratorowi SEOD sprawowanie kontroli nad rodzajami plików które można

dołączyć. Administrator systemu powinien móc zdefiniować listę plików które są potencjalnie groźne

(pliki wykonywalne, skrypty, makra itd.) i zadecydować czy danego typu pliki mogą być przesłane do

SEOD (powinny być między innymi możliwe akcje jak zezwolenie z lub bez komunikatu dla

użytkownika, blokada z lub bez komunikatu dla użytkownika).

5.33. Ma umożliwiać dopasowanie SEOD do przyjętej u Zamawiającego organizacji obiegu dokumentów:

a) Korespondencja odbierana z Poczty Specjalnej rejestrowana jest elektronicznie w kancelarii

ogólnej. Wersja papierowa odbierana jest przez pracowników sekretariatów, po uprzednim

potwierdzeniu odbioru w kancelarii, jest następnie skanowana w poszczególnych sekretariatach

komórek i następnie przekazywana zgodnie z dekretacją przełożonego poszczególnym

pracownikom.

b) Korespondencja adresowana bezpośrednio na wydziały, odbierana z Poczty Specjalnej,

rejestrowana i skanowana jest elektronicznie w sekretariatach poszczególnych komórek,

a w przypadku gdy komórka organizacyjna nie posiada wyodrębnionego sekretariatu kierownik

komórki organizacyjnej wyznacza pracownika do wykonywania prac kancelaryjnych w zakresie

elektronicznego obiegu dokumentów.

6. Minimalne wymagania funkcjonalne SEOD

System powinien posiadać następujące funkcjonalności:

6.1. Obsługa ePUAP:

a) odbieranie i wysyłanie pism,

b) obsługa Urzędowego Poświadczenie Doręczenia (UPD), Urzędowego Poświadczenia Odbioru

(UPO), Urzędowego Poświadczenia Przedłożenia (UPP),

c) możliwość odebrania pism na żądanie użytkownika systemu,

d) wykorzystanie podpisów elektronicznych kwalifikowanych dla kierownictwa komórek

organizacyjnych garnizonu lubelskiego Policji i użytkowników profilu zaufanego,

e) tworzenie dowolnej liczby skrytek na potrzeby komórek organizacyjnych z poziomu

administratora SEOD,

f) użytkownik SEOD powinien mieć możliwość pełnej komunikacji z ePUAP bez konieczności

logowania się na platformę ePUAP,

g) pismo odbierane z platformy ePUAP powinno trafić na listę dokumentów oczekujących na

rejestrację,

h) pola opisujące pismo powinny być uzupełnione automatycznie – na podstawie metadanych

zawartych w piśmie odbieranym z platformy ePUAP, powinny być to co najmniej pola opisujące

10

nadawcę dokumentu, system powinien również automatycznie oznaczać sposób dostarczenia

takiego pisma jako pismo pochodzące z ePUAP,

i) system automatycznie wyszukuje w swojej bazie podmiotów informacji czy dany podmiot nie

znajduje się już w bazie, jeżeli tak – dane opisujące nadawcę powinny być automatycznie

wypełnione na etapie rejestracji pisma,

j) podgląd pisma jest możliwy już podczas jego rejestracji, podgląd jest widoczny w tym samym

oknie co formularz służący do zarejestrowania pisma,

k) istnieje możliwość utworzenia sprawy na podstawie odebranego pisma a następnie wysłania

odpowiedzi do ePUAP bezpośrednio z systemu (np. z poziomu dokumentu lub sprawy),

odpowiedź (plik, formularz) jest akceptowana przez platformę ePUAP,

l) mechanizm integracji zapewnia, że załączniki znajdujące się w piśmie pochodzącym z ePUAP

będą widoczne w systemie również jako załączniki do zarejestrowanego pisma (np. pliki doc, txt,

odt, itd), użytkownik będzie miał możliwość pobrania samego załącznika,

m) integracja systemu z ePUAP umożliwia obsługę formularzy zdefiniowanych za pomocą edytora

formularzy ePUAP, powinno być możliwe odebranie tak wypełnionego formularza, rozpoznanie

przez system jego kategorii oraz automatyczne uzupełnienie metadanych identyfikujących

pismo/formularz do pól opisujących pismo w systemie,

n) możliwość wysłania odpowiedzi na wpływające z ePUAP pismo do wszystkich

zainteresowanych stron, w prowadzonej w systemie sprawie,

o) możliwe jest wysłanie do ePUAP pism podpisanych elektronicznie (podpisem kwalifikowanym

lub niekwalifikowanym), zarówno nowych jak i takich które są odpowiedzią na pismo odebrane

z ePUAP.

6.2. Obsługa e-usług udostępnionych on-line o wysokich stopniach dojrzałości np. 3 – dwustronna

interakcja, co najmniej 4 – transakcja oraz usług wewnątrzadministracyjnych.

6.3. Ma umożliwiać integrację z serwerem faksowym (wymagany zakres integracji/współpracy został

opisany w pkt 14).

6.4. Możliwość integracji z systemem poczty elektronicznej.

6.5. Posiadać „stronę domową” którą użytkownik otrzyma po zalogowaniu się do SEOD a która będzie

w pełni konfigurowalna przez użytkownika – będzie mogła zawierać elementy dostosowane do

preferencji użytkownika (przykładowo ostrzeżenia o upływających terminach dot. realizowanych

spraw). Autoryzowany użytkownik na stronie domowej będzie widział:

a) sprawy pilne, z upływającym terminem wyróżnione są kolorami,

b) informacje o zadaniach do wykonania, zbliżających się terminach,

c) wyświetlana informacja jest dostosowana do zajmowanego przez użytkownika miejsca

w hierarchii organizacji:

a) kierownictwo – podsumowanie stanu jednostki, sprawy do podpisu, możliwość śledzenia

wybranych spraw (np. oznaczonych jako ważne), monitorowanie terminowości załatwienia

sprawy, statystyki dla jednostki,

11

b) kadra zarządzająca – tak samo jak kierownictwo tylko w kontekście zarządzanej komórki

organizacyjnej,

c) referent prowadzący sprawę – tak samo jak kadra zarządzająca tylko w kontekście

prowadzonych przez siebie spraw.

d) w przypadku integracji z pocztą e-mail użytkownik ma informację o nowej poczcie oraz dostęp

do poczty służbowej.

6.6. Opis dokumentu w systemie:

a) dane teleadresowe,

b) oznaczenia komórki organizacyjnej (pole słownikowe),

c) kategoria dokumentu (pole słownikowe np.: faktura, skarga itd.)

d) status dokumentu,

e) nadawca,

f) odbiorca/adresat (możliwy do wpisania ręcznego lub wyboru z książki adresowej),

g) numer „r" przesyłki poleconej,

h) możliwość oznaczenia dokumentu jako pilny,

i) zewnętrzny znak dokumentu,

j) sposób dostarczenia (pole słownikowe np.: przesyłka złożona osobiście, list zwykły, list

polecony, paczka pocztowa, wiadomość poczty elektronicznej bez załącznika/z załącznikiem,

faks, ePUAP itd.),

k) lokalizacja fizyczna,

l) inne metadane (np.: daty wpływu, daty na kopercie, opis dokumentu).

Numer dokumentu jest generowany zgodnie z kolejnością wpływu. SEOD ma możliwość przekazania

odwzorowania cyfrowego do więcej niż jednego użytkownika bez konieczności jego powielania.

6.7. Możliwość digitalizacji dokumentów papierowych:

a) dołączanie skanów pojedynczo lub hurtowo,

b) możliwość edycji skanów (co najmniej obracanie o 90 stopni w dowolną stronę, wycinanie

dodawanie stron, zmiany kolejności stron),

c) opcję pokazywania miniatur stron w przypadku skanu wielostronicowego (w różnych układach

wiersze x kolumny np.: 3x3, 2x3, 3x1), każdy z układów oprócz miniatur strony zawiera również

informację o pliku zawierającą między innymi nazwę pliku, jego typ, wymiary/rozdzielczość,

informację o DPI, głębi koloru itd.,

6.8. OCR dokumentów na potrzeby indeksowania i wyszukiwania dokumentów w repozytorium oraz

doprowadzenia ich do postaci edytowalnej:

a) edycja otrzymanego tekstu,

b) wykorzystanie przy wyszukiwaniu treści,

c) obsługa podstawowych formatów plików: PNG, PDF, JPG/JPEG, GIF, TIFF.

d) obsługa wielostronicowych dokumentów.

6.9. Rodzaje rejestracji dokumentów:

12

a) pismo przewodnie,

b) pismo przewodnie z załącznikiem,

c) pismo przewodnie z załącznikiem, którego nie można wprowadzić do systemu (np. obraz),

d) rejestracja bez pliku.

6.10. Posiadać książkę adresową z możliwością wykorzystania danych TERYT, REGON i ich aktualizacji.

Dostęp do książki adresowej będzie wymagał przydzielenia odpowiednich uprawnień w SEOD. Zakres

danych przede wszystkim powinien zawierać wiarygodne określenie nadawcy i adresata przesyłki oraz

ilość nadanych przesyłek wraz z numerem nadawczym i datą ich nadania.

6.11. Rozróżnianie dokumentów:

a) przychodzących,

b) wychodzących.

6.12. Wysyłanie dokumentów:

a) do jednego odbiorcy,

b) do wielu ze wskazaniem komórki/osoby prowadzącej sprawę.

6.13. Umożliwienie generowania:

a) wykazu przesyłek poleconych,

b) wykazu przesyłek poleconych za zwrotnym potwierdzeniem odbioru,

c) wykazu przesyłek listów zwykłych,

d) wykazu przesyłek nadanych,

e) korespondencji seryjnej (pisma i koperty).

6.14. Zaawansowane wyszukiwanie dokumentów/spraw:

a) pełnotekstowe w dokumentach, w tym przeszukiwanie skanów dokumentów wykonanych przez

system,

b) przeszukiwanie metadanych,

c) uzyskanie informacji o: odbiorcy, powiązanych sprawach, nadanym numerze dziennika, znaku

sprawy.

6.15. Obsługę spraw:

a) tworzenie spraw przez użytkowników w tym z jednego dokumentu,

b) możliwość tworzenia spraw w ramach sprawy istniejącej,

c) dołączanie bądź odłączanie do spraw plików multimedialnych, graficznych, raportów, notatek,

innych,

d) zaawansowana obsługa spraw: łączenie z inna sprawą, dodawanie metadanych, nadawanie znaku

sprawy, określanie daty zakończenia,

e) możliwość wglądu do sprawy z poziomu dokumentu oraz wglądu do dokumentu z poziomu

sprawy (w tym przez przełożonych i osoby upoważnione),

f) możliwość nadania/zmiany znaku sprawy zakończonej, zmiany numeru archiwalnego,

g) dodawanie zadań do realizacji w ramach sprawy,

h) przypomnienie o terminie sprawy, zadaniach do wykonania,

13

i) możliwość akceptacji sprawy przez jednego lub wielu referentów (np. zapoznanie

z dokumentem),

j) przegląd historii zmian dokonanych w sprawie, metryczka sprawy.

6.16. Powiadamianie użytkowników o:

a) nowych sprawach,

b) nowych zadaniach,

c) opóźnieniach w realizacji,

d) zbliżających się terminach realizacji,

e) wglądu do spraw zarchiwizowanych (lista udostępnionych spraw i terminach zakończenia

udostępniania),

f) pismach do zapoznania,

g) zastępstwach,

h) komunikatach wewnętrznych.

6.17. Pilnowanie terminów realizacji zadań i spraw oraz terminów podjęcia zadań przekazanych do

realizacji.

6.18. Archiwizację spraw z zaawansowanym systemem udostępniania z archiwum, tworzenie paczek

w formacie XML.

6.19. Inne usługi zaimplementowane w systemie: np. poczta email, obsługa delegacji, kart urlopowych, itp.

6.20. Umożliwienie dekretacji dokumentu/sprawy (np. dyrektor/naczelnik przygotowuje pocztę i określa

adresata przesyłki).

6.21. Działanie na komputerach stacjonarnych i przenośnych w sieciach CWI, Internet poprzez dedykowany

kanał VPN.

6.22. Intuicyjność obsługi, czytelny, z możliwością zmiany szablonu (kontrast, kolor przycisków, itp.).

6.23. Mechanizm podpowiedzi - system wskazuje, że dany dokument/sprawa były wcześniej rejestrowane.

6.24. Możliwość funkcjonowania odrębnych numerów dla dziennika podawczego i korespondencyjnego.

6.25. Automatycznie uzupełnianie po rejestracji dokumentu/spawy zapisów w dzienniku podawczym

o numery nadane w dzienniku korespondencyjnym (ewentualnie wskazywanie referenta/komórki

realizującej sprawę; możliwość przejścia do książki adresowej po kliknięciu w referenta sprawy).

6.26. Potwierdzanie odbioru korespondencji drogą elektroniczną bez potrzeby prowadzenia, ewidencji

papierowej.

6.27. Umożliwianie wyszukiwania i generowania raportów analitycznych i syntetycznych na podstawie

danych zawartych w ewidencjach dotyczących zarejestrowanych spraw i dokumentów.

6.28. Kierownik komórki organizacyjnej powinien mieć możliwość podglądu spraw Referentów, system

powinien informować kierownika o sprawach pilnych i terminowych.

6.29. Umożliwianie przez system zarządzania bazami danych sprawnego przepisywania spraw z komórek

organizacyjnych, w których nastąpiła reorganizacja (utworzenie, likwidacja komórki, tworzenie

komórek tymczasowych).

6.30. Umożliwianie obsługi słowników systemowych.

14

6.31. Udostępnianie słownika nadawców.

6.32. Zapewnianie eksportu danych z danych zawartych w ewidencji i module e-kancelaria w formacie np.:

xml do zewnętrznych systemów (np. w celu zasilania rejestrów dziedzinowych).

6.33. Wspieranie obsługi podpisu elektronicznego (certyfikatu kwalifikowanego) w zakresie składania

i weryfikacji podpisu, jak również PZ oraz certyfikatów z systemu BTUU.

6.34. Umożliwianie wymiany danych z systemami zewnętrznymi (poprzez bezpieczne usługi elektroniczne),

w tym co najmniej: ePUAP , TERYT, REGON, BIP.

6.35. System powinien zapewnić tylko obsługę korespondencji jawnej. W przypadku zmiany klasyfikacji

dokumentu na niejawny, w systemie pozostają tylko informacje w dzienniku podawczym

i korespondencyjnym (metadane).

6.36. System powinien zapewnić rejestrowanie korespondencji / nowych spraw na podstawie niepełnych

danych n/t nadawcy (np. anonim, adres email itp.).

6.37. W przypadku pism, które wpływają od instytucji zewnętrznych i są doręczane, a kancelaria nie ma

możliwości otworzenia takiego pisma system powinien umożliwić rejestrację. Rejestracji podlegać

będzie nadawca, adresat oraz skan koperty.

6.38. System powinien zapewnić jeden centralny rejestr pism i spraw, niezależnie od lokalizacji ich wpływu

i obsługi.

6.39. System powinien uwzględnić możliwość ewidencjonowania dokumentów bez ich skanowania,

a następnie zeskanowania i załączenia ich na etapie późniejszym (np. w sekretariacie komórki).

6.40. System powinien umożliwić obsługę duplikatów pism w sprawie.

6.41. System zapewnia informację o duplikacie dokumentu po atrybutach: data wpływu, nadawca, numer

pisma nadawcy.

6.42. Pismo - odpowiedź do sprawy - automatycznie podpowiada adresata/referenta.

6.43. System powinien umożliwić dekretację, na każdym etapie realizacji.

6.44. System powinien umożliwić dekretowanie na różnych szczeblach organizacyjnych:

a) dekretacja do właściwej komórki,

b) może ona odbywać się w wielu krokach, które docelowo będą prowadzić do wskazania właściwej

komórki,

c) dekretacja na każdym kolejnym poziomie będzie odbywać się przez wskazanie kolejnego

szczebla dekretacji lub wskazanie właściwej komórki,

d) dekretacja w komórce,

e) w sytuacji skierowania sprawy do referenta dekretacja może odbywać się wielostopniowo.

6.45. W przypadku pisma, które wymaga zaangażowania kilku komórek, na etapie dekretacji, system

powinien zapewnić możliwość wskazania kilku komórek, w każdej z nich zostanie założona sprawa,

i będzie określony referent prowadzący.

6.46. System powinien zapewnić wycofanie/zmianę dekretacji dokumentu/sprawy.

15

6.47. System powinien umożliwiać powiadomienia. Będą one realizowane w sytuacjach przekazania akt -

Kancelaria powinna być powiadomiona o przekazaniu po etapie dekretacji i wskazaniu komórki

właściwej do załatwienia sprawy.

6.48. System powinien umożliwić wskazanie kilku referentów w tym jednego prowadzącego.

6.49. System powinien udostępnić mechanizm zastępstw w sytuacji nieobecności referenta. Zastępowanie

działa bez konieczności ujawniania hasła dostępu zastępowanego referenta.

6.50. System powinien zapewnić zapamiętywanie modyfikowanych danych.

6.51. System powinien uniemożliwić usunięcie zapisu o zarejestrowanym piśmie.

6.52. System powinien udostępnić rejestrację faktu dostarczenia akt bez pisma przewodniego.

6.53. System powinien umożliwić wystąpienia osób spoza Kancelarii lub Sekretariatu w roli Kancelarii lub

Sekretariatu, np. w sytuacji rejestracji korespondencji przez oficera dyżurnego.

6.54. System na poziomie Kancelarii powinien umożliwić:

a) wprowadzanie korekty przez pracownika Kancelarii lub osoby upoważnionej do Dziennika

Podawczego,

b) anulowanie przez pracownika Kancelarii wpisu w Dziennika Podawczego (przed ostatecznym

zapisem).

6.55. System powinien zapewnić uprawnionym pracownikom sekretariatu w wybranych jednostkach do

wskazania komórki docelowej.

6.56. W przypadku omyłkowo skierowanego pisma do komórki system powinien umożliwić komórce, która

otrzymała omyłkowo pismo, na przekazanie go do Kancelarii lub właściwej komórki. Jeśli pismo

zostanie przekazane do właściwej komórki, to tam jest zakładana sprawa lub pismo dokładane jest do

sprawy już założonej.

6.57. System na poziomie sekretariatu powinien umożliwić:

a) edytowanie wszystkich atrybutów za wyjątkiem numeru kolejnego. Korekty będzie mógł

dokonywać pracownik sekretariatu lub osoba upoważniona.

b) rejestrację pisma wychodzącego.

6.58. System powinien umożliwić referentowi na dokonywanie modyfikacji jedynie danych, które sam

wprowadził.

6.59. System powinien umożliwić potwierdzenie faktu odebrania dokumentów papierowych przez referenta

w sekretariacie danej komórki.

6.60. W sytuacji nie odebrania dokumentów papierowych system powinien uniemożliwić zamknięcie

sprawy.

6.61. System powinien umożliwić wyszukiwanie sprawy na podstawie: numeru sprawy, numeru dokumentu

w sprawie, nadawcy, odbiorcy, według dat, tematu, treści albo pozostałych atrybutów, metadanych.

6.62. System powinien zapewnić rejestrację pism wychodzących.

6.63. System na poziomie Kancelarii i Sekretariatu powinien umożliwić obsługę zwrotu korespondencji,

która nie dotyczy spraw Policji.

16

6.64. W ramach prowadzonej sprawy jedna komórka może wymagać opinii - decyzji innej komórki, w takiej

sytuacji system powinien, po wysłaniu pisma przewodniego, umożliwić rejestracje osobnej sprawy

w innej komórce oraz odesłanie odpowiedzi do właściwej komórki.

6.65. System powinien udostępnić grupowanie do teczki wszystkich spraw, które mają tą samą kategorię

archiwalną. Tworzony będzie wtedy automatycznie spis akt.

6.66. System powinien umożliwić nadawanie statusów teczek do prowadzenia sprawy jako: np.: otwarta,

zamknięta, itp.

6.67. System powinien zapewnić przełożonemu referenta zaakceptowanie faktu zarchiwizowania sprawy.

6.68. System powinien obsługiwać wgląd do dokumentów zarchiwizowanych. Wyznaczony pracownik

z archiwum będzie udostępniał wnioskującej osobie możliwość wglądu i/lub wydruku akt (w trybie

tylko do odczytu). Dostęp do spraw zarchiwizowanych będą mieli tylko pracownicy archiwum i osoby

z jednostki którym nadano uprawnienie.

6.69. System powinien zapewnić nadawanie uprawnień do udostępnienia akt, uprawnienia powinny być

nadawane czasowo i powinno zawierać przypomnienie o mijającym terminie.

6.70. System powinien umożliwić pracownikowi archiwum na generowanie raportów:

a) protokół skontrum,

b) raport ze stanu posiadanego zasobu archiwalnego,

c) rejestr udostępnień akt z archiwum,

d) rejestr spisów akt przekazanych do archiwum,

e) rejestr protokołów brakowania dokumentacji niearchiwalnej kategorii „b" i „be" archiwum,

f) protokół brakowania dokumentacji niearchiwalnej kategorii „b" i „be",

g) protokół oceny dokumentacji niearchiwalnej,

h) protokół zniszczenia dokumentacji niearchiwalnej,

i) protokół brakowania dokumentacji niearchiwalnej kategorii „be",

j) zgodnie z obowiązującymi przepisami z zakresu archiwizacji dokumentów.

6.71. Parametrem wejściowym będzie: data, kategoria archiwalna, metadane po wszystkich możliwych

parametrach itp.

6.72. System powinien umożliwić użytkownikowi zgodnie z posiadanymi uprawnieniami na generowanie

raportów po wszystkich możliwych parametrach.

6.73. Po zarchiwizowaniu spraw system zapewni wgląd do tych spraw jedynie dla pracowników archiwum

i osobom, którym zostały udostępnione.

6.74. Systemu powinien umożliwić przejmowanie materiałów archiwalnych i dokumentacji niearchiwalnej

przez archiwa i składnice akt Policji.

6.75. System powinien umożliwić kwalifikowanie akt do brakowania / zniszczenia na podstawie kategorii

archiwalnej B.

6.76. System powinien umożliwić brakowanie dokumentacji niearchiwalnej.

6.77. System powinien umożliwić korektę klasyfikacji archiwalnej nadanej wcześniej przez referenta.

17

6.78. System powinien umożliwić przedłużanie czasu przechowywania w archiwum dokumentacji

przeznaczonej do brakowania.

6.79. System powinien umożliwić tworzenie i prowadzenie rejestrów dzienników na podstawie przepisów

szczególnych bądź potrzeby służby.

6.80. System powinien wykonywać automatycznie backup danych.

6.81. Możliwość wygenerowania obciążenia sprawami na podstawie jednego lub wielu parametrów.

6.82. Sygnalizacja wpływu nowego dokumentu oraz potwierdzenie odebrania przez adresata.

6.83. Możliwość otworzenia/odczytania dokumentów nadesłanych drogą elektroniczną w każdym

dostępnym formacie a także nagrań audio i wideo.

6.84. Dane wprowadzone do systemu EOD powinny mieć możliwość ich zaimportowania do rejestru

skarg/wniosków (eksport danych w formacie xml).

6.85. Aplikacja na podstawie wprowadzonych danych wygeneruje zestawienia statystyczne i raporty na

podstawie jednego lub wielu parametrów (moduł analityczny). Generowanie informacji za każdy okres

(np. tygodniowe, miesięczne, kwartalne, roczne).

6.86. Wyszukiwanie wprowadzonych danych na podstawie jednego lub wielu parametrów w tym informacji

cząstkowych.

6.87. Alerty zbliżającego się końca wyznaczonego terminu.

6.88. Możliwość zastępstwa w prowadzeniu spraw.

6.89. Możliwość otworzenia/odczytania dokumentów nadesłanych drogą elektroniczną w każdym

dostępnym formacie a także nagrań audio i wideo.

6.90. Wskazywanie i zapisywanie kto i kiedy zapoznał się z dokumentami oraz czy wprowadził zmiany,

jeżeli tak to jakie.

6.91. Możliwość edycji metadanych przez osoby uprawnione.

6.92. Automatyczne generowanie informacji skargowej - miesięczna i kwartalna.

6.93. Możliwość wskazania do realizacji danej sprawy kilku organów, zgodnie z właściwością.

6.94. System powinien umożliwić wprowadzenie więcej niż jednego nadawcę składającego skargę.

6.95. Możliwość powiązania skarg dotyczących tej samej sprawy, a złożonych przez różnych nadawców.

6.96. Możliwość modyfikowania arkuszy globalnych.

6.97. Możliwość wskazania nowego terminu załatwienia sprawy (tzw. przedłużenie).

6.98. Możliwość zmiany referenta prowadzącego sprawę.

6.99. System powinien udostępniać edytowanie zarzutów oraz dopisywania zarzutów przez osobę

uprawnioną.

6.100. Po zamknięciu sprawy system powinien zapewnić dodawanie załączników /dokumentów do

sprawy.

6.101. Możliwość zaznaczenia i zmiany zarzutu dominującego w przypadku większej ilości zarzutów.

6.102. System w przypadku generowania pism do skarżącego powinien umożliwić wykorzystanie

danych osobowych, adresowych.

6.103. Możliwość wglądu do spraw zakończonych przed zarchiwizowaniem,

18

6.104. SEOD powinien umożliwiać przekazanie innym osobom tworzonego pisma które będą mogły

nanieść na nie swoje propozycje zmian oraz komentarze (odpowiednik trybu śledzenia zmian

w edytorze tekstu) – możliwość wyróżniania tekstu, nanoszenia propozycji zmian, dodania/usunięcia

komentarzy, akceptacji lub odrzucenia zmiany, itp. powinna być dostępna we wbudowanym edytorze

tekstu.

6.105. System powinien przewidzieć możliwość generowania potwierdzeń faktu zapoznania się

pracowników komórki z pismem bądź aktem prawnym.

7. Instalacja SEOD

Zgodnie z przyjętym założeniem, Wykonawca zainstaluje SEOD:

a) w KWP w Lublinie Główne Centrum Przetwarzania Danych (GCPD),

b) w KMP w Lublinie Zapasowego Centrum Przetwarzania Danych (ZCPD),

c) w KMP/KPP, w Lokalnych Centrach Przetwarzania Danych (LCPD) tych jednostek, dane z LCPD

będą replikowane do GCPD.

d) połączenie pomiędzy GCPD a ZCPD zostanie wykonane za pomocą co najmniej jednej pary

światłowodów. Zamawiający pomiędzy obiektami w których będą zainstalowane główne oraz

zapasowe centrum przetwarzania danych posiada własną infrastrukturę światłowodową której

długość wynosi około 7km.

7.1. KWP w Lublinie/KMP w Lublinie (GCPD/ZCPD)

Instalacja w środowisku klastra wirtualizacyjnego z zastosowaniem dodatkowych klastrów na

poziomie systemów operacyjnych w celu zapewnienia największego zabezpieczenia przed awarią

sprzętową oraz programową dla wdrażanego systemu. Środowisko będzie się składać z przynajmniej

czterech serwerów fizycznych połączonych w ramach klastra typu failover. Poszczególne węzły

fizyczne udostępnią maszyny wirtualne pracujące jako klastry NLB lub HA. Poszczególne hosty

fizyczne będą dysponować mocą obliczeniową pozwalającą na obsłużenie w skrajnym przypadku

wszystkich maszyn wirtualnych wchodzących w skład środowiska.

Ilość serwerów fizycznych 4 (min.)

Ilość maszyn wirtualnych 8

Ilość licencji system operacyjnego serwera 12

Ilość licencji bazy SQL 1 (4 pack)

Zastosowanie zewnętrznej przestrzeni dyskowej (NAS/macierzy dyskowej)

Tak

Klaster NLB Tak

Klaster HA Tak (na poziomie wirtualizatora i systemu operacyjnego)

7.2. KMP/KPP (LCPD)

Instalacja w środowisku wykorzystującym klastry stworzone na poziomie systemów operacyjnych.

Wykorzystane zostaną dwa serwery fizyczne do zapewnienia klastrów typu HA dla bazy danych oraz

19

repozytorium plikowego oraz NLB dla aplikacji i procesów workflow, stworzone na poziomie

systemów operacyjnych. Przy budowie środowiska wykorzystane zostaną udostępnione z zewnętrznej

przestrzeni dyskowej zasoby dyskowe do przechowania maszyn wirtualnych, dysków klastrowych.

Ilość serwerów fizycznych 2

Ilość maszyn wirtualnych 8

Ilość licencji system operacyjnego serwera 4

Ilość licencji bazy SQL 1 (4 pack)

Zastosowanie zewnętrznej przestrzeni dyskowej (NAS/macierzy dyskowej) Tak

Klaster NLB Tak

Klaster HA Tak

8. Minimalne parametry sprzętu serwerowego

8.1. KWP w Lublinie (GCPD) / KMP w Lublinie (ZCPD)

Ilość klastrów 2

Ilość węzłów w klastrze 4

Procesor Procesory min. dwunastordzeniowe dedykowane do pracy w serwerach. Stwierdzenie, czy zaoferowane procesory spełniają wymogi wydajności nastąpi na podstawie opublikowanych wyników testów na stronie „https://www.spec.org”. Zaoferowane procesory muszą posiadać takie właściwości, aby wynik testu oferowanego serwera w konfiguracji z 2 zainstalowanymi procesorami, dla testu SPECint_rate_base2006, był nie gorszy niż 1230. Równoważnie dla testu SPECrate2017_in_base wynik nie może być gorszy niż 130.

Liczba procesorów na węzeł Zainstalowane co najmniej dwa min. dwunastordzeniowe procesory o architekturze 64-bit osiągające dla testu SPECint_rate2006 wynik baseline nie gorszy niż 1230, równoważnie dla testu SPECrate2017_in_base wynik nie gorszy niż 130.

Caching SSD / węzeł 400 GB

Storage-RAW / węzeł 2 x 3.8 TB SSD

Karty sieciowe 2 x 10GbE RJ45

Zdalny monitoring Możliwość zdalnego monitoringu sprzętu (co najmniej: temperatura systemu, wentylatorów, zasilaczy), jego zarządzania (włączenie/wyłączenie serwera) jak i dokumentację (logowanie) zdarzeń. Funkcje te realizowane są niezależnie od systemu operacyjnego.

Każdy z serwerów klastra będzie wyposażony w minimum 256 GB pamięci RAM z możliwością

dalszego jej rozbudowy do 512 GB. Do współpracy z macierzą zostaną wykorzystane 2 karty FC 2

portowe 8Gb.

Przełączniki SAN FC (fiber channel) – zapewniające redundantne połączenie z macierzą wszystkich

serwerów oraz biblioteki taśmowej (opis minimalnych wymagań poniżej)

Element konfiguracji Wymagania minimalne przełącznika FC

Obudowa i zasilanie Musi mieć maksymalnie 1U i szerokość 19” oraz zapewniać techniczną możliwość montażu w szafie 19”.

20

Musi posiadać komponenty (szyny, śruby, itd.) niezbędne do instalacji dostarczonych przełączników w szafach typu rack 19”. Musi posiadać nadmiarowe zasilacze i wentylatory, których wymiana musi być możliwa w trybie „na gorąco” bez przerywania pracy przełącznika.

Wymagane porty Wyposażony w: - 12 modułów 8Gb - w ZCPD dodatkowe moduły do podłączenia biblioteki taśmowej Wszystkie porty aktywne i zalicencjonowane.

Technologia Musi być wykonany w technologii FC 16 Gb/s i posiadać możliwość pracy portów FC z prędkościami 16, 8, 4 Gb/s z funkcją autonegocjacji prędkości. Musi być wykonany w tzw. architekturze „non-blocking” uniemożliwiającej blokowanie się ruchu wewnątrz przełącznika przy pełnej prędkości pracy wszystkich portów.

Przepustowość Sumaryczna przepustowość musi wynosić minimum 384 Gb/s full duplex.

Diagnostyka Musi posiadać rozbudowaną diagnostykę minimalizującą przestoje.

Ilość - GCPD - 2 szt. - ZCPD - 2 szt.

Inne Powinny znajdować się na liście urządzeń zgodnych z dostarczoną macierzą (o ile producent macierzy taką listę publikuje).

8.2. KMP/KPP (LCPD)

Serwer

obudowa Umożliwiająca przystosowana do montaży w szafie rack 19”

płyta główna dedykowana do zastosowań serwerowych

2 gniazda procesorów

4 karty 1G lub 2 karty 10G

1 port RJ45

RAID 0/1 6GBit/s

Kontroler SAS / SATA

Redundantne wentylatory hot-plug

Redundantne zasilacze hot-plug

wyposażenie RAM: co najmniej 128 GB z korekcją błędów ECC

1 x port FC 8G

3 x HDD SAS 12G 1.2TB 10K 512n hot-plug 2.5”

1 x SSD SATA 6G 120GB hot-plug 2.5”

4 x port 1G

kontroler FC 8Gb/s 2 kanały

Procesor Procesory min. ośmiordzeniowe dedykowane do pracy w serwerach. Stwierdzenie, czy zaoferowane procesory spełniają wymogi wydajności nastąpi na podstawie opublikowanych wyników testów na stronie „https://www.spec.org”. Zaoferowane procesory muszą posiadać takie właściwości, aby wynik testu oferowanego serwera w konfiguracji z 2 zainstalowanymi procesorami, dla testu SPECint_rate_base2006, był nie gorszy niż 624. Równoważnie dla testu SPECrate2017_in_base wynik nie może być gorszy niż 73.

Liczba procesorów Zainstalowane co najmniej dwa min. ośmiordzeniowe procesory o architekturze 64-bit osiągające dla testu SPECint_rate2006 wynik baseline nie gorszy niż 624, równoważnie dla testu SPECrate2017_in_base wynik nie gorszy niż 73.

System operacyjny 64 bit, dedykowany do rozwiązań serwerowych, zawierający narzędzia do wirtualizacji

Zdalny monitoring Możliwość zdalnego monitoringu sprzętu (co najmniej: temperatura systemu,

21

wentylatorów, zasilaczy), jego zarządzania (włączenie/wyłączenie serwera) jak i dokumentację (logowanie) zdarzeń. Funkcje te realizowane są niezależnie od systemu operacyjnego.

Przełączniki SAN FC (fiber channel) – zapewniające redundantne połączenie z macierzą wszystkich

serwerów (opis minimalnych wymagań poniżej) – 2 szt.

Przełącznik FC

wyposażenie 24 porty FC

obsadzone: 8 SFP (8 GB/s)

Macierz

obudowa 12 x HDD slot

2 porty dla modułów kontrolera

2 x zasilacz hot-plug

przystosowana do montaży w szafie rack 19” wyposażenie HDD – 4 x 4 TB, 7200 rpm.

Cache 2 x 4 GB

port FC 8G – 2 szt.

8.3. Dostępna przestrzeń dyskowa serwerowni

Przestrzeń dyskowa serwerowni Systemu Elektronicznego Obiegu Dokumentów (SEOD) będzie

posiadała minimum 300 TB przestrzeni użytkowej dla danych (jest to łączna wartość w GCPD oraz

ZCPD dostępna po skonfigurowaniu RAID). Dostarczone rozwiązanie powinno być wyposażone w

SSD Caching o wielkości rekomendowanej przez producenta rozwiązania dla dostarczonego

rozwiązania. Dostępna w macierzy przestrzeń będzie zbudowana w oparciu o dwa rodzaje dysków.

Pierwsza część „wydajnościowa” będzie składać się z dysków SAS-3 (12Gb/s) o minimalnych

obrotach 10k obr/min, druga część „magazynowa” z dysków SAS-3 (12Gb/s) o minimalnych obrotach

7,2k obr/min (równoważnie z NL-SAS o tych samych parametrach przepustowości interfejsu oraz

prędkości obrotowej). W każdej z macierzy, część „wydajnościowa” będzie miała pojemność

użytkową nie mniejszą niż 58 TB zabezpieczonej mechanizmem RAID10 (2+2), natomiast część

„magazynowa” będzie miała pojemność użytkową nie mniejszą niż 92 TB zabezpieczonej

mechanizmem RAID5 (równoważnie RAID6). Dla obu części musi być dostępna dalsza rozbudowa o

co najmniej kolejne 20% użytkowej przestrzeni (przy zachowaniu tego samego poziomu RAID).

Będzie to zapewnione poprzez dostarczenie pustych półek które będą to umożliwiać. Wymagane jest

zastosowanie tych samych macierzy dyskowych dla GCPD oraz ZCPD – ten sam producent, model,

wyposażenie, pojemność.

W celu zapewnienia bezpieczeństwa składowych w systemie EOD danych będą one składowane w

macierzach dyskowych które spełniają następujące wymagania:

a) wsparcie dla dysków SSD, SAS, NL-SAS,

b) obsługa RAID 1/5/6/10,

22

c) definiowanie dysków zapasowych (ang. hot spare) lub odpowiedniej zapasowej przestrzeni

dyskowej, oferowana konfiguracja dyskowa musi zawierać rekomendowaną przez producenta

ilość dysków zapasowych lub odpowiednią zapasową przestrzeń dyskową – typy dysków oraz

ich ilość musi być dobrana odpowiednio dla jakiej części macierzy jest przeznaczona

(wydajnościowej czy magazynowej),

d) obsługa mechanizmu deduplikacji danych,

e) musi być wyposażone w minimum dwa symetryczne kontrolery pracujące w trybie active-

active,

f) zapytania I/O są sprzętowo rozkładane pomiędzy kontrolerami,

g) każdy kontroler macierzy musi mieć minimum 16 GB pamięci cache podtrzymywanej

bateryjnie (lub innej równoważnej technologii) pozwalającej, w przypadku awarii zasilania,

na ochronę zawartości pamięci cache przez okres minimum 72 h,

h) musi posiadać co najmniej 8 zewnętrznych portów FC 8 Gb/s (nie mogą być to porty

duplikowane),

i) wsparcie dla technologii wirtualizacji użytej w projekcie,

j) centralne zarządzanie i monitorowanie,

k) w macierzy kopie bezpieczeństwa będą zapisywane na odpowiednio dobrane do tego celu

dyski (tzw. część magazynowa),

l) możliwość aktualizacji oprogramowania sprzętowego (mikrokodu) bez przerywania pracy

systemu,

m) wszystkie krytyczne komponenty muszą być redundantne.

8.4. Serwerowy system operacyjny

Serwerowy system operacyjny musi posiadać następujące, wbudowane cechy:

1. Możliwość wykorzystania 320 logicznych procesorów oraz co najmniej 4 TB pamięci RAM

w środowisku fizycznym.

2. Możliwość wykorzystywania 64 procesorów wirtualnych oraz 1TB pamięci RAM i dysku

o pojemności do 64TB przez każdy wirtualny serwerowy system operacyjny.

3. Możliwość budowania klastrów składających się z 64 węzłów, z możliwością uruchamiania

7000 maszyn wirtualnych.

4. Możliwość migracji maszyn wirtualnych bez zatrzymywania ich pracy między fizycznymi

serwerami z uruchomionym mechanizmem wirtualizacji (hypervisor) przez sieć Ethernet, bez

konieczności stosowania dodatkowych mechanizmów współdzielenia pamięci.

5. Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany pamięci RAM bez

przerywania pracy.

6. Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany procesorów bez przerywania

pracy.

23

7. Automatyczna weryfikacja cyfrowych sygnatur sterowników w celu sprawdzenia, czy

sterownik przeszedł testy jakości przeprowadzone przez producenta systemu operacyjnego.

8. Możliwość dynamicznego obniżania poboru energii przez rdzenie procesorów

niewykorzystywane w bieżącej pracy.

9. Wbudowane wsparcie instalacji i pracy na wolumenach, które:

a. pozwalają na zmianę rozmiaru w czasie pracy systemu,

b. umożliwiają tworzenie w czasie pracy systemu migawek, dających użytkownikom

końcowym (lokalnym i sieciowym) prosty wgląd w poprzednie wersje plików

i folderów,

c. umożliwiają kompresję "w locie" dla wybranych plików i/lub folderów,

d. umożliwiają zdefiniowanie list kontroli dostępu (ACL).

10. Wbudowany mechanizm klasyfikowania i indeksowania plików (dokumentów) w oparciu o ich

zawartość.

11. Wbudowane szyfrowanie dysków przy pomocy mechanizmów posiadających certyfikat FIPS

140-2 lub równoważny wydany przez NIST lub inną agendę rządową zajmującą się

bezpieczeństwem informacji.

12. Możliwość uruchamianie aplikacji internetowych wykorzystujących technologię ASP.NET.

13. Możliwość dystrybucji ruchu sieciowego HTTP pomiędzy kilka serwerów.

14. Wbudowana zapora internetowa (firewall) z obsługą definiowanych reguł dla ochrony

połączeń internetowych i intranetowych.

15. Graficzny interfejs użytkownika.

16. Zlokalizowane w języku polskim, co najmniej następujące elementy: menu, przeglądarka

internetowa, pomoc, komunikaty systemowe.

17. Możliwość zmiany języka interfejsu po zainstalowaniu systemu, dla co najmniej 10 języków

poprzez wybór z listy dostępnych lokalizacji.

18. Mechanizmy logowania w oparciu o:

a. Login i hasło,

b. Karty z certyfikatami (smartcard),

c. Wirtualne karty (logowanie w oparciu o certyfikat chroniony poprzez moduł TPM).

19. Możliwość wymuszania wieloelementowej kontroli dostępu dla określonych grup

użytkowników.

20. Wsparcie dla większości powszechnie używanych urządzeń peryferyjnych (drukarek, urządzeń

sieciowych, standardów USB, Plug&Play).

21. Możliwość zdalnej konfiguracji, administrowania oraz aktualizowania systemu.

22. Dostępność bezpłatnych narzędzi producenta systemu umożliwiających badanie i wdrażanie

zdefiniowanego zestawu polityk bezpieczeństwa.

23. Pochodzący od producenta systemu serwis zarządzania polityką dostępu do informacji

w dokumentach (Digital Rights Management).

24

24. Wsparcie dla środowisk Java i .NET Framework 4.x – możliwość uruchomienia aplikacji

działających we wskazanych środowiskach.

25. Możliwość implementacji następujących funkcjonalności bez potrzeby instalowania

dodatkowych produktów (oprogramowania) innych producentów wymagających

dodatkowych licencji:

a. Podstawowe usługi sieciowe: DHCP oraz DNS wspierający DNSSEC,

b. Usługi katalogowe oparte o LDAP i pozwalające na uwierzytelnianie użytkowników

stacji roboczych, bez konieczności instalowania dodatkowego oprogramowania na

tych stacjach, pozwalające na zarządzanie zasobami w sieci (użytkownicy,

komputery, drukarki, udziały sieciowe), z możliwością wykorzystania następujących

funkcji:

i. Podłączenie do domeny w trybie offline – bez dostępnego połączenia

sieciowego z domeną,

ii. Ustanawianie praw dostępu do zasobów domeny na bazie sposobu logowania

użytkownika – na przykład typu certyfikatu użytego do logowania,

iii. Odzyskiwanie przypadkowo skasowanych obiektów usługi katalogowej

z mechanizmu kosza,

iv. Bezpieczny mechanizm dołączania do domeny uprawnionych użytkowników

prywatnych urządzeń mobilnych opartych o iOS i Windows 8.1.

c. Zdalna dystrybucja oprogramowania na stacje robocze,

d. Praca zdalna na serwerze z wykorzystaniem terminala (cienkiego klienta) lub

odpowiednio skonfigurowanej stacji roboczej,

e. Centrum Certyfikatów (CA), obsługa klucza publicznego i prywatnego)

umożliwiające:

i. Dystrybucję certyfikatów poprzez http,

ii. Konsolidację CA dla wielu lasów domeny,

iii. Automatyczne rejestrowania certyfikatów pomiędzy różnymi lasami domen,

iv. Automatyczne występowanie i używanie (wystawianie) certyfikatów PKI

X.509.

f. Szyfrowanie plików i folderów,

g. Szyfrowanie połączeń sieciowych pomiędzy serwerami oraz serwerami i stacjami

roboczymi (IPSec),

h. Możliwość tworzenia systemów wysokiej dostępności (klastry typu fail-over) oraz

rozłożenia obciążenia serwerów,

i. Serwis udostępniania stron WWW,

j. Wsparcie dla protokołu IP w wersji 6 (IPv6),

k. Wsparcie dla algorytmów Suite B (RFC 4869),

25

l. Wbudowane usługi VPN pozwalające na zestawienie nielimitowanej liczby

równoczesnych połączeń i niewymagające instalacji dodatkowego oprogramowania

na komputerach z systemem Windows,

m. Wbudowane mechanizmy wirtualizacji (Hypervisor) pozwalające na uruchamianie do

1000 aktywnych środowisk wirtualnych systemów operacyjnych. Wirtualne

maszyny w trakcie pracy i bez zauważalnego zmniejszenia ich dostępności mogą być

przenoszone pomiędzy serwerami klastra typu failover z jednoczesnym

zachowaniem pozostałej funkcjonalności. Mechanizmy wirtualizacji mają zapewnić

wsparcie dla:

i. Dynamicznego podłączania zasobów dyskowych typu hot-plug do maszyn

wirtualnych,

ii. Obsługi ramek typu jumbo frames dla maszyn wirtualnych,

iii. Obsługi 4-KB sektorów dysków,

iv. Nielimitowanej liczby jednocześnie przenoszonych maszyn wirtualnych

pomiędzy węzłami klastra,

v. Możliwości wirtualizacji sieci z zastosowaniem przełącznika, którego

funkcjonalność może być rozszerzana jednocześnie poprzez

oprogramowanie kilku innych dostawców poprzez otwarty interfejs API,

vi. Możliwości kierowania ruchu sieciowego z wielu sieci VLAN bezpośrednio

do pojedynczej karty sieciowej maszyny wirtualnej (tzw. trunk mode).

26. Możliwość automatycznej aktualizacji w oparciu o poprawki publikowane przez producenta

wraz z dostępnością bezpłatnego rozwiązania producenta serwerowego systemu operacyjnego

umożliwiającego lokalną dystrybucję poprawek zatwierdzonych przez administratora, bez

połączenia z siecią Internet.

27. Wsparcie dostępu do zasobu dyskowego poprzez wiele ścieżek (Multipath).

28. Możliwość instalacji poprawek poprzez wgranie ich do obrazu instalacyjnego.

29. Mechanizmy zdalnej administracji oraz mechanizmy (również działające zdalnie) administracji

przez skrypty.

30. Możliwość zarządzania przez wbudowane mechanizmy zgodne ze standardami WBEM oraz

WS-Management organizacji DMTF.

9. Wymagania wydajnościowe środowiska

Dla zapewnienia komfortowej pracy użytkownika końcowego z SEOD, Zamawiający wymaga aby

zaprojektowany oraz dostarczony SEOD cechował się dostateczną wydajnością żeby umożliwiać

prawidłową pracą nawet w trakcie występowania maksymalnego natężenia pracy użytkowników w SEOD.

W związku z tym platforma sprzętowa na której będzie uruchomione SEOD powinna mieć takie parametry

aby przy 50% przewidywanych w ramach projektu ilości użytkowników (minimum 5000) użycie

określonych parametrów środowiska serwerowego była na poziomie:

26

Pamięć operacyjna RAM: nie przekracza 45% użycia,

Procesory serwera: nie przekraczają 45% użycia,

Oczekiwane parametry wydajnościowe SEOD w zależności od wykonywanej operacji:

a. Logowanie - czas oczekiwania do 2 sekund,

b. Wyświetlanie formularzy – czas oczekiwania do 2 sekund,

c. Zapisywanie danych z formularzy - czas oczekiwania do 3 sekund,

d. Wyszukiwanie w bazie – czas oczekiwania do 4 sekund,

e. Generowanie prostych raportów (np. rejestr pism z danego dnia) – czas oczekiwania do 6

sekund.

Powyżej wymienione wartości powinny być spełnione gdy każdy z użytkowników jest zalogowany do

systemu SEOD i wykonuje w nim standardowe operacje związane z codzienną pracą. Dodatkowo

środowisko serwerowe powinno także zapewniać odpowiedni zapas mocy obliczeniowej umożliwiając

realizację operacji które mogą generować chwilowe skoki obciążenia (np. generowanie raportów, operacje

związane z przekazaniem spraw pomiędzy użytkownikami).

10. Portal e-usług

Portal na którym będą realizowane e-usługi wraz z brokerem komunikacyjnym zostaną przygotowane przez

Wykonawcę w postaci wirtualnych maszyn mogących pracować w środowisku wirtualizacyjnym

Centralnych Systemów Internetowych Policji. Rozwiązanie takie jest zgodne ze Strategią

Cyberbezpieczeństwa Rzeczypospolitej Polskiej na lata 2016 – 2020 w zakresie budowy jednolitego

i bezpiecznego styku instytucji administracji państwowej z publiczną siecią Internet. Wymagane jest, aby

przygotowane serwery były zgodne z platformą VMware vSphere w wersji 6.5. Udostępniony w publicznej

sieci Internet serwer udostępniający e-usługi, zlokalizowany zostanie w strefie KGP WAN DMZ a ruch IP

kierowany do niego poddany zostanie inspekcji SSL. Zgodnie z funkcjonującymi zasadami bezpieczeństwa

Centralnego Węzła Internetowego KGP, dane z przedmiotowego serwera w strefie KGP WAN DMZ nie

będą mogły być bezpośrednio przekazywane do strefy „Data Center DMZ” w obszarze sieci LAN CWI

w KWP Lublin. W celu przekazania przedmiotowych danych do strefy „Data Center DMZ” w KWP Lublin,

konieczne będzie zbudowanie dodatkowej maszyny wirtualnej umiejscowionej w strefie KGP LAN DMZ,

której rolą będzie „pobieranie danych” (inicjacja sesji IP) z serwera w strefie KGP WAN DMZ do strefy

KGP LAN DMZ a następnie przekazanie ich do strefy „Data Center DMZ” w KWP Lublin. Wymieniona

maszyna wirtualna będzie między innymi pełnić rolę brokera komunikacyjnego pomiędzy siecią chronioną

LAN CWI KGP i strefą „Data Center DMZ” KWP Lublin a siecią publiczną i strefą KGP WAN DMZ.

Ogólny schemat wymiany danych dla e-usług przedstawia poniższy rysunek.

27

Portal będzie składał się z dwóch części: ogólnodostępnej i dostępnej po zalogowaniu. Część dostępna dla

wszystkich użytkowników (nie wymagająca logowania) będzie działać zgodnie z zasadami otwartych

zasobów (udostępniania danych publicznych). Podstawowe narzędzia dostępne dla użytkowników będą

obejmować co najmniej możliwość wyszukiwania treści wg zdefiniowanych przez użytkownika kategorii.

Wymagana będzie również możliwość dostosowania interfejsu graficznego do preferencji użytkownika oraz

zapamiętania tych ustawień przy pomocy wbudowanych mechanizmów przeglądarki, w tym stosowania

mechanizmów dostępności treści zgodnych ze standardem WCAG 2.0. Portal będzie wykorzystywała SSO

(Single Sign-On - przekazywanie tożsamości) udostępnione przez mechanizm integracyjny platformy

ePUAP, zgodnie z wytycznymi opisanymi na stronach portalu ePUAP oraz udostępnionymi w dokumencie

„Wykorzystanie SAML 2.0 w systemie ePUAP”.

Wykonawca zbuduje portal w oparciu o technologie tworzenia serwisów WWW zgodne z aktualnymi

standardami i normami (np.: HTML5, CSS3, JavaScript, ISO, W3C, zastosowanie intuicyjnych rozwiązań,

projektowanie zorientowane na użytkownika) oraz wsparty systemem klasy CMS, co umożliwi spełnienie

wymagań dotyczących interoperacyjności wynikających z Krajowych Ram Interoperacyjności. Portal musi

także obsługiwać technikę projektowania RWD (ang. Responsive Web Design). Dzięki czemu wygląd

i układ portalu będzie automatycznie dostosowywał się do rozmiaru okna przeglądarki, na której jest

wyświetlany (monitor komputera/laptopa, tablet, smartfon). Portal będzie posiadał szatę graficzną

Wnioskodawcy.

28

Ważną częścią projektu jest utworzenie portalu e-usług która będzie spełniała zalecenia WCAG 2.0.

Sprawdzenie poziomu dostępności interfejsów i treści systemów informatycznych Wykonawca potwierdzi

przeprowadzonym audytem eksperckim specjalistów w zakresie dostępności stron. Wynikiem audytu będzie

lista elementów standardu WCAG 2.0, wskazanych w załączniku nr 4 do Rozporządzenia Rady Ministrów

z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności (tekst jedn. Dz. U. z 2016 r., poz.

113), wraz z określeniem poziomu spełnienia wymagań – muszą one być spełnione co najmniej na poziomie

wskazanym w ww. rozporządzeniu.

Przygotowane przez Wykonawcę wirtualne maszyny muszą pracować prawidłowo w środowisku

wirtualizacyjnym Centralnych Systemów Internetowych Policji. Wszystkie kwestie techniczne niezbędne do

prawidłowego wykonania usługi będą konsultowane z Biurem Łączności i Informatyki KGP za

pośrednictwem Zamawiającego. Wykonawca przy realizacji portalu e-usług oraz brokera komunikacyjnego

musi uwzględnić zalecenia Biura Łączności i Informatyki KGP.

10.1. Formularze elektroniczne

Z uwagi na obowiązujące regulacje prawne, obieg i archiwizacja informacji muszą opierać się na

dokumentach elektronicznych w formacie XML, tworzonych na bazie schematów XML

przechowywanych w repozytorium wzorów (szablonów) dokumentów elektronicznych.

Wymiana informacji pomiędzy systemami teleinformatycznymi, a także komunikacja pomiędzy

organizacjami i osobami fizycznymi wymaga uzgodnienia standardów umożliwiających łatwe

uzgodnienie interfejsów i jednolite rozumienie przekazywanych danych przez różne systemy

teleinformatyczne. Jedną z podstawowych zasad dla ustalenia tych standardów jest przyjęcie języka

komunikacji i standardu dla opisu struktur danych. Tym językiem jest XML, a standardem opisu są

schematy w postaci XSD.

Do stworzenia dokumentu elektronicznego, który będzie procesowany w garnizonie w formie sprawy

oraz jego archiwizacji niezbędne jest wykonanie następującego scenariusza:

29

Przewidywane są dwie metody procesowania informacji w zgodzie z obowiązującymi regulacjami:

1. oparcie się całkowicie o dokument elektroniczny XML (od jego utworzenia do archiwizacji),

2. oparcie się o papierowy dokument źródłowy załączony do pliku XML zawierającego jego opis.

Formularze elektroniczne powstałe na bazie schematów XML pozwolą na:

a) wypełnienie formularza ze wspomaganiem walidacji poszczególnych pól (o ile to możliwe),

b) zapisanie wypełnionego formularza w postaci dokumentu XML,

c) wizualizację ostatecznej postaci dokumentu,

d) podpisanie dokumentu profilem zaufanym lub podpisem elektronicznym.

W ramach projektu Wykonawca przygotuje formularze dostępne poprzez przeglądarkę internetową,

dostępne dla użytkowników wewnętrznych i zewnętrznych, dla następujących usług:

L.p. Nazwa usługi Rodzaj usługi Poziom dojrzałości

e-usługi

1 Stop agresji na drodze A2C 5

Usługa pozwala na dokonanie zgłoszenia sytuacji zagrożenia w ruchu drogowym. Możliwe są dwa kanały dostępu: serwis internetowy (możliwość zaznaczenia miejsca zdarzenia na mapie oraz dodania plików wideo, zdjęć) oraz aplikacja mobilna (usługa lokalizacji, wykonania nagrania lub zdjęć i przesłania bezpośrednio z urządzenia). Usługa wymaga autoryzacji oraz potwierdzenia warunków licencyjnych i prawnych. Użytkownik jest powiadamiany o statusie zgłoszenia jedną z wybranych przez siebie metod (e-mail, SMS, komunikat systemowy).

2 Wniosek o udzielenie informacji publicznej A2C 4

Formularz sys. ePUAP. Przekierowanie serwisu dostępowego. Pełna obsługa klienta drogą elektroniczną.

3 Wnioski o kontrolne sprawdzenie kwalifikacji oraz o cofnięcie

uprawnień do kierowania pojazdami A2A -

Poziom dojrzałości nie dotyczy usług A2A. Poziom dojrzałości nie dotyczy usług A2A.

4 Udzielenie informacji o przebiegu zdarzenia w ruchu

drogowym A2C/A2B 4

30

Formularz sys. ePUAP. Przekierowanie z serwisu dostępowego. Automatyczna dekretacja EZD. Możliwość śledzenia statusu sprawy.

5 Udzielenie informacji o przebiegu zdarzenia towarzystwom

ubezpieczeniowym A2B 5

Usługa pozwala na wyszukiwanie danych o kolizjach w ruchu drogowym wg podanych kryteriów (data, czas, obszar, nr rej. Pojazdu). W ramach usługi istnieje możliwość wygenerowania raportu wg kryteriów zdefiniowanych przez użytkownika. Usługa wymaga uwierzytelnienia oraz uzyskania poziomu dostępu do danych.

6 Platforma obsługi dostaw A2B 3

Usługa obejmuje obsługę wszystkich procesów dostaw towarów i usług dla jednostek Policji (garnizonu), w tym postępowań przetargowych, akcji elektronicznych (przekierowanie do serwisów zewnętrznych). Użytkownik ma możliwość dostosowania usługi do własnych potrzeb (np. kryteriów wyszukiwania), w tym generowania powiadomień o nowych zamówieniach. Platforma zapewnia również mechanizm komunikacji dwustronnej z dostawcami (po uwierzytelnieniu).

7 Konsultacje społeczne A2C 4

Usługa pozwala na zgłaszanie uwag i propozycji do programów poprawy bezpieczeństwa. Dostarcza również mechanizmu głosowania (np. wybór najlepszego projektu, zebranie opinii, etc.)

8 Złożenie skargi/wniosku A2C 4

Formularz sys. ePUAP. Przekierowanie z serwisu dostępowego. Automatyczna dekretacja EZD. Możliwość śledzenia statusu sprawy.

9 Pozwolenie na broń A2C/A2B 4

Usługa obejmuje realizację procesu uzyskania pozwolenia na broń do użytku osobistego lub w związku z prowadzoną działalnością gospodarczą. Usługa wymaga uwierzytelnienia i podpisu. Formularz ePUAP. Przekierowanie z serwisu dostępowego. Automatyczna dekretacja EZD. Możliwość śledzenia statusu sprawy. Decyzja o odmowie wydania pozwolenia lub powiadomienie o możliwości odebrania dokumentu.

10 Informacja o osobach objętych zakazem stadionowym A2B 4

Usługa pozwala na uzyskanie przez organizatorów imprez aktualnej listy osób objętych tzw. zakazem stadionowym. Usługa wymaga uwierzytelnienia i potwierdzenia poziomu dostępu.

11 Platforma rekrutacyjna (służba mundurowa) A2C 4

Usługa pozwala na prowadzenie pierwszego etapu rekrutacji kandydatów do służby w Policji. Po założeniu konta kandydat ma możliwość przesłania kwestionariusza, niezbędnych załączników, uzyskania informacji o prowadzonych naborach, otrzymywania powiadomień wg zdefiniowanych przez siebie kryteriów, śledzenia statusu sprawy, itd.

12 Platforma rekrutacyjna (służba cywilna) A2C 4

Usługa pozwala na prowadzenie rekrutacji pracowników cywilnych. Bez logowania umożliwia zapoznanie się z aktualnymi informacjami rekrutacyjnymi. Po założeniu konta możliwe jest złożenie podania o zatrudnienie, CV, uzyskanie terminu rozmowy kwalifikacyjnej, etc.

13 Programy praktyk zawodowych A2C 4

Usługa pozwala na kompleksową realizację praktyk zawodowych w Policji. Bez logowania dostępne są informacje o realizowanych programach praktyk. Kandydat ma możliwość weryfikacji przydatności do pracy Policji (test, autoocena). Po zalogowaniu istnienie możliwość złożenia podania, uzyskania informacji o wolnych miejscach (staż, praktyka) wg podanych kryteriów, uzyskania decyzji o przyjęciu na praktykę.

14 Statystyki przestępstw i wykroczeń A2C/A2B 5

Usługa pozwala na generowanie zestawień dotyczących przestępstw i wykroczeń na terenie woj. lubelskiego. Użytkownik ma możliwość pobrania wygenerowanych danych w postaci pliku XLS, CSV oraz określenia własnych kryteriów wyszukiwania i generowania danych (personalizacji).

15 Zgłoszenie zdarzenia dyżurnemu A2C 4

Usługa pozwala na dokonanie zgłoszenia zdarzenia. Możliwe są dwa kanały dostępu: serwis internetowy

31

(możliwość zaznaczenia miejsca zdarzenia na mapie) oraz aplikacja mobilna (usługa lokalizacji i przesłania bezpośrednio z urządzenia). Usługa wymaga autoryzacji oraz potwierdzenia warunków licencyjnych i prawnych. Użytkownik jest powiadamiany o statusie zgłoszenia jedną z wybranych przez siebie metod (e-mail, SMS, komunikat systemowy). Automatyczne przekierowanie do dyżurnego znajdującego się najbliżej miejsca zdarzenia.

16 Zgłoszenie zjawiska korupcji A2C/A2B 3

Usługa pozwala na "anonimowe" przesłanie informacji o zjawisku korupcji. Formularz zabezpieczony przed działaniem skryptów (robotów). Komunikat o przyjęciu zgłoszenia.

Dla poszczególnych procesów biznesowych związanych ze świadczeniem planowanych do wdrożenia

usług, została przeprowadzona analiza która uwzględnia ich stan aktualny i docelowy.

a) Stop agresji na drodze

Opis procesu – stan obecny

Proces Stop agresji na drodze

Cel procesu Przyjęcie zgłoszeń w zakresie wykroczeń w ruchu dorogowym

Właściciel procesu / jednostka org.

Zastępca Komendanta Wojewódzkiego Policji w Lublinie

Warunki wystąpienia / rozpoczęcia

Dokonanie skutecznego zgłoszenia

Opis wejścia Zgłoszenie telefoniczne, wiadomość e-mail

Opis procesu 1) przyjęcie zgłoszenia telefonicznego lub przez e-mail, 2) sporządzenie notatki, 3) powiadomienie osoby kierującej działaniami operacyjnymi

Dane wyjściowe notatka w formie papierowej

Czas obsługi /pracochłonność

15 min.

Wykorzystywane narzędzia Dokumentacja wewnętrzna, komputer, drukarka, materiały eksploatacyjne

Opis procesu – stan docelowy

Proces Stop agresji na drodze

Cel procesu Przyjęcie zgłoszeń w zakresie wykroczeń w ruchu dorogowym





Opis wejścia Formularz elektroniczny

Opis procesu 1) automatyczna rejestracja zgłoszenia sytuacji zagrożenia w ruchu drogowym, 2) powiadominie dyżyrnego, 3) przesłanie komunikatów o stanie zgłoszenia

Dane wyjściowe Informacja o stanie zgłoszenia


1 min.

Wykorzystywane narzędzia ePUAP, System EOD, portal dostępowy

Opis wprowadzonych zmian

Całość procesu realizowana drogą elektroniczą.

b) Wniosek o udzielenie informacji publicznej


32

Proces Wniosek o udzielenie informacji publicznej

Cel procesu Udzielenie informacji publicznej na wniosek




Wniosek o udzielenie informacji publicznej w trybie art. 2 ust. 1 ustawy o dostępie do informacji publicznej z dnia 6 września 2001 r.

Opis wejścia Wniosek w formie papierowej

Opis procesu 1) przyjęcie i rejestracja wniosku, 2) rozpoznanie sprawy, 3) przygotowanie odopowiedzi, 3) przygotowanie wymaganych informacji, 4) przesłanie odpoweidzi wraz z wymaganą informacją

Dane wyjściowe Informacja publiczna lub odmowa udzielenia informacji


14 dni



Proces Wniosek o udzielenie informacji publicznej

Cel procesu Udzielenie informacji publicznej na wniosek




Wniosek o udzielenie informacji publicznej w trybie art. 2 ust. 1 ustawy o dostępie do informacji publicznej z dnia 6 września 2001 r.


Opis procesu 1) automatyczne przyjęcie i rejestracja wniosku, 2) rozpoznanie sprawy, 3) przygotowanie odopowiedzi, 3) przygotowanie wymaganych informacji, 4) przesłanie odpowiedzi wraz z wymaganą informacją

Dane wyjściowe Odpowiedź drogą elektroniczną wraz z wymaganą informację lub odmowa udzielenia informacji publicznej


7 dni

Wykorzystywane narzędzia ePUAP, System EOD



c) Wnioski o kontrolne sprawdzenie kwalifikacji oraz o cofnięcie uprawnień do kierowania

pojazdami


Proces Wnioski o kontrolne sprawdzenie kwalifikacji oraz o cofnięcie uprawnień do kierowania pojazdami

Cel procesu Realizacja wniosku o sprawdzenie wkalifikacji oraz cofnięcie uprawnień do kierowania pojazdami na wniosek osoby uprawnionej




Wynik postępowania sprawdzającego

33

Opis wejścia Informacja o przekroczeniu dopuszczalnej ilości punktów karnych lub podejrzeniu utraty zdolności do kierowania pojazdem mechanicznym

Opis procesu 1) uzgodnienie informacji dot. wykroczeń, 2) ustalenie danych osobowych kierowcy, 3) ustalenie właściwego w sprawie organu decyzyjnego, 4) przygotowanie wniosku, 5) przesłanie wniosku

Dane wyjściowe Wniosek o kontrolne sprawdzenie kwalifikacji oraz o cofnięcie uprawnień do kierowania pojazdami do starosty/prezydenta miasta


7 dni



Proces Wnioski o kontrolne sprawdzenie kwalifikacji oraz o cofnięcie uprawnień do kierowania pojazdami

Cel procesu Realizacja wniosku o sprawdzenie wkalifikacji oraz cofnięcie uprawnień do kierowania pojazdami na wniosek osoby uprawnionej




Wywołanie automatyczne na podstawie rejestru wykroczeń drogowych

Opis wejścia Komunikat systemowy

Opis procesu 1) weryfikacja danych kierowcy, 2) generowanie wniosku, 3) przesłanie wniosku zgodnie z informacją meldunkową, 4) uzyskanie UPP

Dane wyjściowe Wniosek o kontrolne sprawdzenie kwalifikacji oraz o cofnięcie uprawnień do kierowania pojazdami do starosty/prezydenta miasta


15 min.

Wykorzystywane narzędzia ePUAP, System EOD, elektroniczne rejestry publiczne


Całość procesu realizowana drogą elektroniczą w sposób zautomatyzowany.

d) Udzielenie informacji o przebiegu zdarzenia w ruchu drogowym


Proces Udzielenie informacji o przebiegu zdarzenia w ruchu drogowym

Cel procesu Udzielenie informacji o przebiegu zadarzenia w ruchu drogowym na wniosek osoby fizycznej lub prawnej




Wniosek osoby uprawnionej


Opis procesu 1) przyjęcie i rejestracja wniosku, 2) rozpoznanie sprawy, 3) przygotowanie odpowiedzi, 3) przygotowanie wymaganych informacji, 4) przesłanie odpoweidzi wraz z wymaganą informacją

Dane wyjściowe Informacja o zadrzeniu w formie papierowej

34


7 dni



Proces Udzielenie informacji o przebiegu zdarzenia w ruchu drogowym

Cel procesu Udzielenie informacji o przebiegu zadarzenia w ruchu drogowym na wniosek osoby fizycznej lub prawnej







Dane wyjściowe Informacja o zdarzeniu w wersji elektronicznej


1 dzień




e) Udzielenie informacji o przebiegu zdarzenia towarzystwom ubezpieczeniowym


Proces Udzielenie informacji o przebiegu zdarzenia towarzystwom ubezpieczeniowym

Cel procesu Udostępnienie inforacji o ustalonym przebiegu zdarzeń na wniosek twarzystwa ubezpieczeniowego







Dane wyjściowe Informacja o zadrzeniu w formie papierowej


7 dni



Proces Udzielenie informacji o przebiegu zdarzenia towarzystwom ubezpieczeniowym

35

Cel procesu Udostępnienie inforacji o ustalonym przebiegu zdarzeń na wniosek twarzystwa ubezpieczeniowego







Dane wyjściowe Informacja o zdarzeniu w wersji elektronicznej


1 dzień




f) Platforma obsługi dostaw


Proces Platforma obsługi dostaw

Cel procesu Obsługa dostaw towarów i usług do jednostek policji


Koordynator Zespołu Zamówień Publicznych


Zgłoszenie zapotrzebowania przez jednostkę policji

Opis wejścia oferta postępowaniu przetargowym

Opis procesu 1) publikacja informacji o planie zakupów/dostaw, 2) prowadzenie korespondecji z oferentami i dostawcami

Dane wyjściowe Korespondencja w formie papierowej


2 dni



Proces Platforma obsługi dostaw

Cel procesu Obsługa dostaw towarów i usług do jednostek policji


Koordynator Zespołu Zamówień Publicznych


Zapotrzebowanie ze strony jednostek policji


Opis procesu 1) publikacja informacji w zakresie dostaw, 2) wymiana komuniacji z potencjalnymi dostawcami

Dane wyjściowe Informacja o dostawach

Czas obsługi 1 godz.

36

/pracochłonność




g) Konsultacje społeczne


Proces Konsultacje społeczne

Cel procesu Przeprowadzenie konsultacji społecznych




Ogłoszenie o wszczęciu procedury konsultacji publicznych

Opis wejścia Wniosek o uwzględnienie uwag w formie papierowej

Opis procesu 1) przyjęcie wniosku, 2) rozpoznianie wniosku, 3) publikacja uwag i decyzji o uwzględnieniu lub odrzuceniu wniosku

Dane wyjściowe Informacja o wynikach konsultacji publikowana na w serwisie WWW KWP w Lublinie


14 dni



Proces Konsultacje społeczne

Cel procesu Przeprowadzenie konsultacji społecznych




Ogłoszenie o wszczęciu procedury konsultacji publicznych


Opis procesu 1) przyjęcie wniosku, 2) rozpoznianie wniosku, 3) publikacja uwag i decyzji o uwzględnieniu lub odrzuceniu wniosku

Dane wyjściowe Informacja w formie elektronicznej


7 dni




h) Złożenie skargi/wniosku


Proces Złożenie skargi/wniosku

Cel procesu Przyjęcie skargi lub wniosku od osoby fizycznej lub prawnej

Właściciel procesu / Zastępca Komendanta Wojewódzkiego Policji w Lublinie

37

jednostka org.



Opis wejścia Wniosek/skarga w formie papierowej

Opis procesu 1) przyjęcie i rejestracja wniosku, 2) rozpoznanie sprawy, 3) przygotowanie odpowiedzi, 3) przygotowanie wymaganych informacji, 4) przesłanie odpoweidzi

Dane wyjściowe Odopowiedź na wniosk w wersji papierowej


14 dni



Proces Złożenie skargi/wniosku

Cel procesu Przyjęcie skargi lub wniosku od osoby fizycznej lub prawnej






Opis procesu 1) przyjęcie i rejestracja wniosku, 2) rozpoznanie sprawy, 3) przygotowanie odpowiedzi, 3) przygotowanie wymaganych informacji, 4) przesłanie odpowiedzi

Dane wyjściowe Odpowiedź w wersji elektronicznej


7 dni




i) Pozwolenie na broń


Proces Pozwolenie na broń

Cel procesu Wydanie pozwolenia na broń




Wniosek osoby fizycznej lub prawnej


Opis procesu 1) przyjęcie i rejestracja wniosku, 2) rozpoznanie sprawy, 3) przygotowanie odpowiedzi, 3) przesłanie informacji o terminie odbioru zezwolenia na broń lub decyzji odmownej

Dane wyjściowe Zezwolenie na posiadanie broni palnej lub decyzja odmowna


30 dni

38



Proces Pozwolenie na broń

Cel procesu Wydanie pozwolenia na broń




Wniosek osoby fizycznej lub prawnej


Opis procesu 1) przyjęcie i rejestracja wniosku, 2) rozpoznanie sprawy, 3) przygotowanie odpowiedzi, 3) przesłanie informacji o terminie odbioru zezwolenia na broń lub decyzji odmownej

Dane wyjściowe Informacja o terminie odnioru zezwolenia na posiadanie broni palnej lub decyzja odmowana przesłane drogą elektroniczną


14 dni

Wykorzystywane narzędzia ePUAP, System EOD



j) Informacja o osobach objętych zakazem stadionowym


Proces Informacja o osobach objętych zakazem stadionowym

Cel procesu Udostępnienie informacji o osobach objętych zakazem stadionowym






Opis procesu 1) przejęcie i rejetracja wniosku, 2) ustalenie informacji z rejestru osób objętych zakazem stadiownowym, 3) przygotowanie dopowiedzi

Dane wyjściowe Informacja o osobach objętych zakazem stadionowych w wersji papierowej


7 dni



Proces Informacja o osobach objętych zakazem stadionowym

Cel procesu Udostępnienie informacji o osobach objętych zakazem stadionowym





39


Opis procesu 1) automatyczne przyjęcie i rejestracja wniosku, 2) generowanie listy osób objętych zakazem stadionowym, 3) udostępnienie listy

Dane wyjściowe Lista osób objętych zakazem stadionowym w wersji elektronicznej


1 godz.




k) Platforma rekrutacyjna (służba mundurowa)


Proces Platforma rekrutacyjna (służba mundurowa)

Cel procesu Przeprowadzenie procesu rekrutacyjnego na stanowiska służby mundurowej w jednostkach policji






Opis procesu 1) przejęcie i rejetracja wniosku, 2) analiza treści wniosku 3) przygotowanie dopowiedzi

Dane wyjściowe Odpowiedź w wersji papierowej


7 dni



Proces Platforma rekrutacyjna (służba mundurowa)

Cel procesu Przeprowadzenie procesu rekrutacyjnego na stanowiska służby mundurowej w jednostkach policji









2 dni




40

l) Platforma rekrutacyjna (służba cywilna)


Proces Platforma rekrutacyjna (służba cywilna)

Cel procesu Przeprowadzenie procesu rekrutacyjnego na stanowiska służby cywilnej w jednostkach policji









7 dni



Proces Platforma rekrutacyjna (służba cywilna)

Cel procesu Przeprowadzenie procesu rekrutacyjnego na stanowiska służby cywilnej w jednostkach policji









2 dni




m) Programy praktyk zawodowych


Proces Programy praktyk zawodowych

Cel procesu Umożliwienie realizacji praktyk zawodowych w jenostkach policji







41



7 dni



Proces Programy praktyk zawodowych

Cel procesu Umożliwienie realizacji praktyk zawodowych w jenostkach policji









2 dni




n) Statystyki przestępstw i wykroczeń


Proces Statystyki przestępstw i wykroczeń

Cel procesu Zapewnienie dostępu do ISP z zakresu bezpieczeństwa publicznego (statystyki przestępstw i wykoroczeń)




Okresowe zestawienie danych statystycznych z działalności jednostek policji

Opis wejścia brak

Opis procesu 1) cykliczna publikacja informacji statsytcznych w serwisie KWP Lublin

Dane wyjściowe Informacja o publikowana na w serwisie WWW KWP w Lublinie


7 dni



Proces Statystyki przestępstw i wykroczeń

Cel procesu Zapewnienie dostępu do ISP z zakresu bezpieczeństwa publicznego (statystyki przestępstw i wykoroczeń)



42


Okresowe zestawienie danych statystycznych z działalności jednostek policji


Opis procesu 1) automatyczna publikacja informacji statsytcznych w serwisie KWP Lublin

Dane wyjściowe Informacja o publikowana na w serwisie WWW KWP w Lublinie


1 godz.




o) Zgłoszenie zdarzenia dyżurnemu


Proces Zgłoszenie zdarzenia dyżurnemu

Cel procesu Przyjęcie i obsługa zgłoszenia przez dyżurnego jednostki policji





Opis wejścia Zainicjowanie rozmowy telefonicznej, wizyta osobista w jednostce policji

Opis procesu 1) przyjęcie i rejestracja zgłoszenia, 2) przekazanie informacji osobie kierujacej działaniami operacyjnymi

Dane wyjściowe Informacja w formie papierowej i ustnej


15 min.



Proces Zgłoszenie zdarzenia dyżurnemu

Cel procesu Przyjęcie i obsługa zgłoszenia przez dyżurnego jednostki policji






Opis procesu 1) przyjęcie i rejestracja zgłoszenia, 2) przekazanie informacji osobie kierujacej działaniami operacyjnymi



2 min.




43

p) Zgłoszenie zjawiska korupcji


Proces Zgłoszenie zjawiska korupcji

Cel procesu Przyjęcie zgłoszenia podejrzenia wystąpienia zjawiska korupcji


I Zastępca Komendanta Wojewódzkiego Policji w Lublinie



Opis wejścia Przesyłka pocztowa, wiadmość e-mail

Opis procesu 1) przejęcie i rejetracja wniosku, 2) analiza treści wniosku 3) przekazanie informacji do komórki merytorycznej

Dane wyjściowe Informacja w formie papierowej


7 dni



Proces Zgłoszenie zjawiska korupcji

Cel procesu Przyjęcie zgłoszenia podejrzenia wystąpienia zjawiska korupcji


I Zastępca Komendanta Wojewódzkiego Policji w Lublinie




Opis procesu 1) przejęcie i rejetracja wniosku, 2) analiza treści wniosku 3) przekazanie informacji do komórki merytorycznej



2 dni

Wykorzystywane narzędzia System EOD, portal dostępowy



11. Aplikacja mobilna do obsługi e-usługi „Niebieska e-skrzynka”

Projekt zakłada zwiększenie stopnia dojrzałości dotychczasowej usługi dot. zgłaszania zdarzeń „Niebieska

e-skrzynka” do poziomu 5. Aby to osiągnąć Wykonawca przygotuje stosowną aplikację mobilną która

będzie spełniać następujące założenia.

Cele główne programu:

Umożliwienie stałego, nieskrępowanego dostępu młodzieży szkolnej do instytucji pomocowych oraz

Policji na terenie województwa lubelskiego.

Podniesienie poczucia bezpieczeństwa młodzieży na terenie szkoły i poza nią.

44

Zacieśnienie współpracy placówek oświatowych i instytucji zajmujących się problematyką młodzieży

z Policją w zakresie przeciwdziałania patologiom wśród młodzieży szkolnej.

Poprawa rozpoznania występującego wśród młodzieży szkolnej zagrożeń związanych z różnego rodzaju

patologiami społecznymi.

Wspieranie działań i inicjatyw służących wzrostowi poczucia bezpieczeństwa dzieci i młodzieży.

Aktywizacja podmiotów zajmujących się patologiami społecznymi do działania na rzecz programu.

11.1. Wymagania podstawowe:

a) interfejs aplikacji mobilnej powinien być dedykowany dla młodzieży szkolnej,

b) użytkownikiem aplikacji mobilnej może stać się osoba, która zaakceptowała regulamin

użytkowania aplikacji „Niebieska e-skrzynka”.

11.2. Wymagania funkcjonalne:

a) Użytkownik końcowy podczas pierwszego uruchomienia aplikacji mobilnej akceptuje regulamin

oraz podaje dane niezbędne do przeprowadzenia procesu weryfikacji np. (numer telefonu, adres

email, dane osobowe – opcjonalnie, miejsce wystąpienia/zaistnienia zdarzenia). Wprowadzone

dane zostają przesłane do weryfikacji.

b) Użytkownik końcowy przy użyciu dostępnych funkcji będzie miał możliwość przesłania

informacji w formie opisowej lub dołączyć plik w formacie JPEG, 3GP, AVI, MOV, WMV,

MP4 itp.

c) Przy użyciu opcji dołącz plik wymagane będzie wyrażenie zgody aby aplikacja „Niebieska

e-skrzynka” miała dostęp do zdjęć, multimediów i plików na urządzeniu mobilnym.

d) Moduł GPS będzie odpowiedzialny za przekazanie aktualnej lokalizacji urządzenia z którego

generowane jest zgłoszenie przez użytkownika końcowego, w celu wskazania ewentualnego

miejsca: np. lokalizacji najbliższego KMP/KPP/KP/PP. Obsługa Mapy Google i innych

podobnych aplikacji powinna być dostępna na platformie Android, iOS – jako usługa „prowadź

do...” (Zamawiający dopuszcza aby funkcjonalność ta była realizowana za pośrednictwem

aplikacji MSWiA „Moja Komenda”).

e) Moduł wysyłki zgłoszenia będzie odpowiedzialny za zbudowanie kompletnej informacji

i wysyłanie do właściwego adresata. Wysłana informacja musi zawierać wszystkie dane

wprowadzone przez użytkownika i prezentować je w sposób czytelny bez potrzeby dodatkowej

interpretacji na poziomie odbiorcy zgłoszenia w KWP/KMP/KPP/KP/PP.

Zgłoszenie/informacja/zapytanie powinno umożliwić bezpośrednie przysłanie wiadomości do

adresata (stanowisko dowodzenia na poziomie KWP/KMP/KPP), które następnie przesłanie

zostanie do komórki merytorycznie odpowiedzialnej za realizacje danego zgłoszenia oraz do

wiadomości Wydziału Prewencji KWP w Lublinie.

f) Użytkownik końcowy po zgłoszeniu sprawy otrzyma informację, że jego sprawa została

przekazana do komórki merytorycznie odpowiedzialnej za realizację powyższego zgłoszenia.

45

g) Obowiązek przesłania informacji zwrotnej użytkownikowi końcowemu będzie spoczywał na

osobie merytorycznej odpowiedzialnej za realizację zgłoszenia. Kopia odpowiedzi i podjęte

działania przez Policję przesyłane będą do użytkownika aplikacji na poziomie KWP (Wydział

Prewencji).

h) Po uruchomieniu aplikacji, może ona działać w tle oraz wyświetlać na telefonie użytkownika

powiadomienia/komunikaty.

i) Użytkownik końcowy może wybrać z jaką częstotliwością aplikacja będzie sprawdzała status

zgłoszenia, czy są nowe komunikaty dla użytkowników końcowych itp. (dostępne

w ustawieniach aplikacji w postaci np. suwaka z możliwością ustawienia przedziału czasowego

od 15 do 180 minut, ze skokiem co 15 minut).

j) Wyświetlane komunikaty powinny trafnie informować o statusie wykonanych operacji, statusie

zgłoszenia, o terminach udzielenia informacji lub kończącym się terminie udzielenia odpowiedzi

wynikającym z przepisów art. 35 Kodeksu Postępowania Administracyjnego itp. (synchronizacja

z kalendarzem), pełna informacja może być odczytana przy użyciu aplikacji lub innego

wybranego przez użytkownika końcowego kanału komunikacji np. wiadomość email, wiadomość

SMS).

k) Na poziomie Wydziału Prewencji KWP niezbędny jest pełny wgląd w historię zgłoszeń

i przesyłanych odpowiedzi do użytkowników przez osoby zajmujące się daną sprawą

w KWP/KMP/KPP/KP/PP:

Monitoring realizacji zgłoszenia (np. dane personalne, numer telefonu policjanta

zajmującego się danym zgłoszeniem, możliwość przesyłania informacji w ramach

aplikacji pomiędzy KWP – KMP/KPP/KP/PP).

Osoby zajmujące się zgłoszeniem będą zobowiązane wpisaniem informacji dot.

wykonanych zadań podjętych czynnościami w ramach realizacji zgłoszenia.

l) Projektowana aplikacja mobilna powinna prawidłowo funkcjonować zarówno dla telefonów, jak

i tabletów z dostępem do sieci GSM.

m) Aplikacja mobilna powinna być zaprojektowana z myślą o dalszej rozbudowie czy modyfikacji

oraz przygotowana do funkcjonowania na systemach Android oraz iOS.

n) Aplikacja mobilna swoją funkcjonalnością musi reprezentować piąty stopień dojrzałości usług

w e-administracji.

o) Aplikacja mobilna umożliwia realizację usługi „Stop agresji na drodze” zgodnie z opisem usługi

zamieszczonym w pkt 10.1 Załącznika nr 1 do Umowy.

12. System kopii bezpieczeństwa (backupu)

Dostarczony przez Wykonawcę system backupu obejmie wszystkie dane gromadzone w obrębie SEOD.

Umożliwi to odtworzenie danych oryginalnych w przypadku utraty lub uszkodzenia jak również

odtworzeniu środowiska po awarii. System backupu powinien spełniać minimum następujące wymagania:

46

a) musi umożliwiać bezprzerwowy backup systemów operacyjnych, baz danych, aplikacji

i środowisk wirtualnych,

b) musi wspierać wykonywanie kopii bezpieczeństwa wszystkich systemów operacyjnych

zainstalowanych w wirtualnych maszynach oraz samych maszyn wirtualnych,

c) musi umożliwiać odzyskiwanie całych maszyn wirtualnych z obrazów, oraz pojedynczych plików

z systemów plików znajdujących się wewnątrz maszyny wirtualnej,

d) współpracować z systemem zarządzania środowiskiem wirtualnym,

e) umożliwiać pracę w środowisku klastrowym,

f) rozwiązanie musi wspierać mechanizm VSS (Windows Volume Shadow Copy),

g) musi wpierać mechanizmy deduplikacji oraz kompresji danych,

h) umożliwiać rozbudowę procesu archiwizacji o dowolne skrypty stworzone i dołączone do zadań

archiwizacyjnych przez administratora,

i) musi posiadać centralną konsolę zarządzania całym środowiskiem backupu, który będzie posiadać

graficzny interfejs użytkownika (GUI) obsługiwany przez przeglądarkę WWW,

j) musi obsługiwać urządzenia taśmowe i dyskowe, służące do przechowywania kopii zapasowych

i archiwizacji danych,

k) powinien przechowywać informacje o wykonanych kopiach, harmonogramach oraz nośnikach

w relacyjnej bazie danych, którą system ze względów bezpieczeństwa powinien mieć możliwość

wykonania kopii lustrzanej dla tej bazy danych oraz mieć możliwość wykonania kopii zapasowej

na taśmy w trakcie pracy systemu bez konieczności ograniczania jego funkcjonalności,

l) proces tworzenia kopii zapasowych oraz odtwarzania danych powinien być procesem

transakcyjnym,

m) musi umożliwiać definiowanie w sposób centralny, polityki tworzenia kopii zapasowych,

n) musi umożliwiać realizowanie raz zdefiniowanej polityki backupu w sposób automatyczny - bez

konieczności ingerencji operatora,

o) powinien umożliwiać wykonywanie określonych akcji, na przykład: zatrzymanie procesów,

wykonanie kopii bezpieczeństwa i ponowne uruchomienie procesów,

p) wykonywać kopie zapasowe w sposób przyrostowy,

q) mieć możliwość zdefiniowania czasu ważności kopii zapasowych, tj. czasu w którym usunięte

dane są przechowywane na nośnikach taśmowych bądź dyskowych,

r) mieć możliwość jednoczesnego tworzenia kopii zapasowych na różnego rodzaju nośniki (taśmy,

dyski),

s) mieć możliwość wersjonowania realizowanych polityk kopii zapasowych,

t) mieć możliwość jednoczesnego wykonywania backupu wielu klientów na urządzenia dyskowe, jak

również powinien bez ingerencji operatora przenosić dane z dysków na taśmy,

u) posiadać możliwość odtworzenia kopii zapasowej z dowolnego punktu w czasie,

v) jeżeli z jakiegoś powodu odtwarzanie danych zostało przerwane, system powinien móc wznowić

czynność od miejsca w którym nastąpiła przerwa,

47

w) umożliwiać odtwarzanie danych w dowolne wskazane miejsce dyskowe.

Dane gromadzone w systemie backupu będą replikowane pomiędzy głównym oraz zapasowym centrum

przetwarzania danych.

Wykonywanie kopii zapasowych będzie realizowany w dwóch etapach. W pierwszym dane zostaną

zapisane na wydzielonej przestrzeni w macierzy dyskowej. W drugim dane zostaną zapisane w bibliotece

taśmowej. Biblioteka taśmowej będzie wyposażone w minimum w 34 taśmy LTO-7 oraz co najmniej w trzy

napędy LTO-7 (lub równoważną pojemnościowo ilość taśm LTO-8 oraz równoważną przepustowościowo

ilość napędów LTO-8), co umożliwi przechowywanie kopii zapasowych przez minimum 14 dni.

Wykonawca na potrzeby wdrażanego systemu opracuje i wdroży system backupu, który będzie

zaprojektowany z uwzględnieniem zaleceń „best practices” producenta danego rozwiązania. Wykonawca

musi jako jeden z testów systemu przeprowadzić próbę odzyskania danych z kopii bezpieczeństwa zarówno

z macierzy dyskowej jak i biblioteki taśmowej.

13. System bezpieczeństwa

Wymagane jest aby dostęp do wydzielonej sieci w której będzie znajdować się dane Systemu

Elektronicznego Obiegu Dokumentów (SEOD) chroniony był za pomocą rozwiązania Firewall

z funkcjonalnością Next Generation Intrusion Prevention System (NGIPS) zbudowanego w klastrze

zapewniającym wysoką wydajność i dostępność udostępnianych usług. Wdrożone przez Wykonawcę

rozwiązanie umożliwi zabezpieczenie SEOD przez zagrożeniami pochodzącymi spoza wydzielonej sieci

(np.: działanie szkodliwego oprogramowania, ataki typu DOS oraz DDOS, ataki typu SQL injection, ataki

polegające na przepełnieniu buforu). Ponieważ stanowiska dostępowe w sieci KWP CWI LAN nie posiadają

stałych nr IP system bezpieczeństwa strefy „Data Center DMZ” będzie skonfigurowany w taki sposób aby

przepuszczać ruch dla całych zakresów nr IP które przydzielane są stanowiskom dostępowym przez usługę

DHCP.

Minimalne wymagania dostarczonego przez Wykonawcę systemu bezpieczeństwa:

13.1. System bezpieczeństwa musi być rozwiązaniem Firewall z funkcjonalnością Next Generation Intrusion

Prevention System zbudowany w klastrze zapewniającym wysoką wydajność i dostępność

udostępnianych usług.

13.2. Wymagane jest, aby przedmiotowy system umożliwiał przesyłanie informacji o kontrolowanym ruchu

IP do systemu typu SIEM (Security Information and Event Management), umiejscowionego

w Centralnych Systemach Internetowych Policji.

13.3. Wydzielona sieć „Data Center DMZ” w której będą znajdować się GCPD oraz ZCPD musi być

odseparowana od reszty sieci. za pomocą przedmiotowego systemu bezpieczeństwa.

13.4. Replikacja danych pomiędzy GCPD a ZCDP musi odbywać się z pominięciem systemów

bezpieczeństwa.

13.5. Wydajność pojedynczego urządzenia wchodzącego w skład systemu bezpieczeństwa, przy aktywnym

firewallu wraz z IPS, nie może być mniejsza niż 1Gbps.

48

13.6. W celu uniknięcia powielania się ewentualnych luk w bezpieczeństwie, moduł ochrony antywirusowej

powinien używać innego silnika antywirusowego niż wykorzystywany na stacjach roboczych

u Zamawiającego (Check Point Endpoint Security).

13.7. Musi posiadać scentralizowane zarządzanie wszystkimi urządzeniami wchodzącymi w skład systemu.

13.8. Scentralizowane zarządzanie musi odbywać się na oddzielnym urządzeniu (jeżeli producent to

przewiduje to dopuszcza się zastosowanie do zarządzania odpowiednio przygotowanego środowiska

maszyny wirtualnej) i powinno posiadać interfejs graficzny.

13.9. Musi umożliwiać inspekcje SSL.

13.10. Musi posiadać rozbudowany system kontroli dostępu, który między innymi pozwala na

tworzenia kont mających wgląd w aktualną konfigurację systemu bez możliwości jej modyfikacji

(inspekcja konfiguracji systemu bezpieczeństwa).

13.11. Musi umożliwiać dostęp do SEOD z Internetu poprzez dedykowany kanał VPN.

13.12. Musi mieć możliwość wykorzystania zewnętrznych systemów identyfikacji użytkownika jak

LDAP, Active Directory, RADIUS.

Wdrożenie systemu bezpieczeństwa powinno przebiegać dwuetapowo. W pierwszym etapie system

bezpieczeństwa nie będzie blokował przesyłu danych a jedynie zbierał informacje na podstawie których

Wykonawca opracuje stosowne reguły/polityki systemu bezpieczeństwa. W drugim etapie nastąpi

wdrożenie opracowanych polityk a system bezpieczeństwa musi pracować w trybie to co nie jest dozwolone

jest zabronione. W tym aktywnym stanie system bezpieczeństwa musi blokować niepożądany ruch sieciowy

nie zakłócając przy tym prawidłowego działania SEOD.

Dostarczone przez Wykonawcę rozwiązanie, musi współpracować z systemami bezpieczeństwa BŁiI KGP.

Wszystkie kwestie techniczne niezbędne do prawidłowego wykonania usługi będą konsultowane z Biurem

Łączności i Informatyki KGP za pośrednictwem Zamawiającego. Uzyskane w ten sposób zalecenia dot.

wymagań zapewniających niezawodną współpracę uruchamianego systemu bezpieczeństwa z już istniejącą

w KGP infrastrukturą muszą być przez Wykonawcę uwzględnione przy realizacji projektu.

14. Integracja (współpraca) z serwerem faksowym

Równolegle do wdrożenia SEOD, Zamawiający planuje wdrożenie w lubelskim garnizonie Policji serwera

faksów, który zastąpi dotychczas stosowane urządzenia faksowe, pozwoli to na podniesienie poziomu

dostępności i niezawodności tej formy komunikacji, ograniczy ilość zużywanego papieru i czynności

związanych ze skanowaniem informacji przychodzących i wprowadzaniem ich do SEOD a także pozwoli

uniknąć kosztów napraw i wymiany zużytego sprzętu.

W związku z powyższym Wykonawca musi zapewnić aby SEOD współpracował poprawnie z serwerem

faksowym, umożliwiając integrację pomiędzy tymi systemami. Wymagane jest aby w SEOD było możliwe

między innymi:

a) Rejestrowanie faksów przychodzących oraz wychodzących.

49

b) Dla faksów wychodzących musi być dostępny dla użytkownika raport z transmisji zawierający:

a) identyfikator nadawcy i odbiorcy korespondencji faksowej (numery telefonów, nagłówki,

adresy e-email),

b) datę i godzinę wysłania,

c) potwierdzenie poprawności wysłania korespondencji,

d) ilość wysłanych stron,

e) czas realizacji transmisji.

c) Umożliwiać współpracę za pomocą poczty email (obsługa funkcji Fax2Mail i Mail2Fax), jak

również za pomocą udostępnionego przez serwer faksowy Web Service API.

d) Udostępniać użytkownikom SEOD sieciową książkę telefoniczno – adresową systemu

faksowego.

e) Umożliwiać wysyłanie faksów na podstawie książki telefonicznej systemu faksowego.

f) Umożliwiać wysyłanie faksów do wielu odbiorców (lista dystrybucyjna).

g) Umożliwiać przesłanie do serwera faksowego dokumenty w formatach PDF, TIFF, JPEG, PNG,

DOC, XLS (lista obsługiwanych formatów zależna od wybranego rozwiązania serwera

faksowego).

15. Środowisko szkoleniowo – testowe

Zmawiający wymaga aby, w lokalizacji GCPD, zostało uruchomione środowisko testowo – szkoleniowe

dla SEOD z uwzględnieniem portalu e-usług. Dla tego środowiska wymagane jest utworzenie odrębnej

instancji systemu. Zamawiający dopuszcza uruchomienie środowiska testowo - szkoleniowego

w środowisku wirtulizacyjnym GCPD, jednak wtedy Wykonawca musi uwzględniać to przy projektowaniu

tak żeby działanie środowiska testowego nie odbiło się negatywnie na działaniu środowiska produkcyjnego.

Jako system pamięci masowej, z tym samym jak powyżej zastrzeżeniem, można wykorzystać dostarczoną

przez Wykonawcę macierz dla GCPD. Środowisko to będzie wykorzystywane do testowania nowych

funkcjonalności systemu, przeprowadzania szkoleń oraz do testowania nowych procesów przygotowanych

przez projektantów procesów Zamawiającego. Przedmiotem dostawy są również serwerowe systemy

operacyjne, oprogramowanie w wersji analogicznej jak dostarczone do środowiska podstawowego oraz

wszystkie niezbędne licencje na środowisko testowo – szkoleniowe w ramach zakupu licencji

produkcyjnych.

16. Wskaźniki produktu oraz rezultatu

Zamawiający wymaga aby zaprojektowany i wdrożony przez Wykonawcę SEOD spełniał wszystkie

przewidziane w projekcie „Wdrożenie nowych e-usług oraz rozwiązań zwiększających stopień dostępności

lubelskiej policji dla obywateli” wartości docelowe wskaźników produktu a także zbierał dane

umożliwiające raportowanie wskaźników rezultatu.

Wskaźniki produktu

50

Lp. Nazwa wskaźnika Jednostka

miary (J.m.)

Wartość

docelowa

Źródło danych

do pomiaru

1.

Liczba aplikacji opartych na ponownym

wykorzystaniu informacji sektora publicznego i

e-usług publicznych [szt.]

szt. 1,00

Dokumentacja

techniczna,

protokół

odbioru

2. Liczba podmiotów, które udostępniły on-line

informacje sektora publicznego [szt.] szt. 21,00

3.

Liczba uruchomionych systemów

teleinformatycznych w podmiotach wykonujących

zadania publiczne [szt.]

szt. 2,00

4. Liczba usług publicznych udostępnionych on-line o

stopniu dojrzałości 3 – dwustronna interakcja [szt.] szt. 15,00

5. Liczba usług publicznych udostępnionych on-line o

stopniu dojrzałości co najmniej 4 – transakcja [szt.] szt. 13,00

6. Przestrzeń dyskowa serwerowni [TB] TB 300,00

Wskaźniki rezultatu

Lp. Nazwa wskaźnika

Jednostka

miary

(J.m.)

Wartość

bazowa Wartość

docelowa

Źródło danych

do pomiaru

1.

Liczba pobrań/odtworzeń dokumentów

zawierających informacje sektora

publicznego [szt./rok]

szt./rok 0,00 2297,00 Elektroniczny

rejestr

aktywności

użytkowników

poszczególnych

modułów

oprogramowania.

2.

Liczba pobrań/uruchomień aplikacji

opartych na ponownym wykorzystaniu

informacji sektora publicznego i e-usług

publicznych [szt./rok]

szt./rok 0,00 3692,00

17. Import danych z systemów dziedzinowych

Zamawiający wymaga przeprowadzenie przez Wykonawcę importu danych z systemu dziedzinowego

zawierającego informacje o protokołach brakowania oraz spisy akt przekazanych zdanych do archiwum w/g

Jednolitego Rzeczowego Wykazu Akt Policji. Przedmiotowy system dziedzinowy funkcjonuje w Archiwum

KWP w Lublinie i jest bazą danych Microsoft Access 2003.

18. Certyfikaty kwalifikowane

Zamawiający wymaga od Wykonawcy dostarczenia w trakcie trwania umowy 300 certyfikatów

kwalifikowanych (firmowych). Zamawiający będzie o nie występował w czasie trwania umowy zgodnie z

bieżącymi potrzebami w tym zakresie. Do pierwszych 150 kart muszą zostać dostarczone dedykowane im

czytniki zewnętrzne USB 2.0.

Documents

Załącznik nr 1 Informacje szczegółowe dotyczące Systemu ... · 3. System Elektronicznego Obiegu Dokumentów (SEOD) Zaprojektowany przez Wykonawcę SEOD musi być kompleksowym