Załącznik nr 1 do SIWZ Opis Przedmiotu Zamówienia na Wdrożenie

Załącznik nr 1 do SIWZ
Opis Przedmiotu Zamówienia
na
Wdrożenie i funkcjonowanie systemów informatycznych wraz z zakupem sprzętu komputerowego
i urządzeń oraz usługą wsparcia technicznego, szkoleń i konsultacji eksperckich
w ramach projektu ,,Internetowy urząd”
1. Wstęp
Niniejszy dokument stanowi załącznik nr 1 do SIWZ na zamówienie polegające na wdrożeniu
i funkcjonowaniu systemów informatycznych w ramach projektu ,,Internetowy urząd” wraz dostawą sprzętu
komputerowego i urządzeń oraz usługą wsparcia technicznego. Dokument opisuje przedmiot zamówienia
wskazując zadania jakie Wykonawca musi zrealizować w ramach projektu.
2. Określenie Przedmiotu Zamówienia
2.1. Zadanie nr 1:
1. Zakup sprzętu komputerowego i urządzeń,
2. Opracowanie i wdrożenie Gminnego Systemu Komunikacji On-line (GSKO) w 5 urzędach gmin, w
tym opracowanie specyfikacji interface'u wejścia danych do systemu GSKO z systemów
dziedzinowych oraz integracja GSKO z istniejącymi systemami dziedzinowymi firmy RADIX Systemy
Komputerowe w 4 urzędach gmin,
3. Wdrożenie Elektronicznego Zarządzania Dokumentów w 3 urzędach gmin (Łasin, Płużnica,
Wąbrzeźno), w tym integracja wdrażanego systemu GSKO z wdrażanym systemem EZD,
4. Integracja systemu EZD firmy E-Studio Software Sp. J. z wdrażanym systemem GSKO w 1 urzędzie
gminy (Grudziądz),
5. Przygotowanie 25 formularzy wniosków na platformę e-PUAP,
6. Przygotowanie i przeprowadzenie szkoleń z zakresu użytkowania i administrowania GSKO,
e-PUAP i EZD,
7. Konsultacje eksperckie,
w urzędach gmin Partnerów projektu: Gminie Płużnica, Gminie Wąbrzeźno, Gminie Unisław, Gminie
Grudziądz, Mieście i Gminie Łasin.
2.2. Zadanie nr 2:
Integracja GSKO z istniejącymi systemami dziedzinowymi firmy LogicSynergy Sp. z o.o. w Urzędzie Gminy
Grudziądz.
2.3. Zadanie nr 3:
Integracja GSKO z istniejącymi systemami dziedzinowymi firmy Sygnity w Urzędzie Gminy Grudziądz.
2.4. Zadanie nr 4:
Integracja GSKO z istniejącymi systemami dziedzinowymi firmy Vulcan w Urzędzie Giny Grudziądz.
2.5. Zadanie nr 5:
Integracja GSKO z istniejącymi systemami dziedzinowymi firmy Zakład Systemów Informatycznych SIGID
w Urzędzie Gminy Unisław.
2.6. Zadanie nr 6:
Integracja GSKO z istniejącymi systemami dziedzinowymi firmy Anko System Sp. z o.o. w Urzędzie Gminy
Unisław.
3. Wymagania prawne
Oferowane przez Wykonawcę rozwiązania muszą być na dzień odbioru zgodne z aktami prawnymi
regulującymi pracę urzędów administracji publicznej oraz usług urzędowych realizowanych drogą
elektroniczną (e-usług). Oferowane rozwiązania muszą być zgodne w szczególności z następującymi
przepisami:
1. 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 (t. j. Dz. U. 2011 r. Nr 14 poz. 67 z późn. zm.).
2. Ustawa z dnia 14 czerwca 1960 r. Kodeks postępowania administracyjnego (t. j. Dz. U. 2013 r.
poz. 267).
3. Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (t. j. Dz. U. 2011 r.
Nr 123 poz. 692 z późn. zm.).
4. Rozporządzenie Ministra Kultury z dnia 16 września 2002 r. w sprawie postępowania
z dokumentacją, zasad jej klasyfikowania i kwalifikowania oraz zasad i trybu przekazywania materiałów
archiwalnych do archiwów państwowych (Dz. U. 2002 r. Nr 167 poz. 1375).
5. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r.
w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz. U. 2006 r. Nr 206 poz.
1517).
6. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r.
w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz. U. 2006 r. Nr 206
poz. 1518).
7. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r.
w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których
utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz. U. 2006 r. Nr 206 poz.
1519).
8. Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (t. j. Dz. U. 2002 r. Nr 101
poz. 926 z późn. zm.).
9. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r.
w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych
i organizacyjnych, jakim muszą odpowiadać urządzenia i Systemy informatyczne służące do
przetwarzania danych osobowych (Dz. U. 2004 r. Nr 100 poz. 1024).
10. Ustawa z dnia 22 stycznia 1999 o ochronie informacji niejawnych (t. j. Dz. U. 2005 r. Nr 196
poz. 1631 z późn. zm.)
11. Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej (Dz. U. 2001 r. Nr 112
poz. 1198 z późn. zm.).
12. Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 18 stycznia 2007 r.
w sprawie Biuletynu Informacji Publicznej (Dz. U. 2007 r. Nr 10 poz. 68).
13. Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (t. j. Dz. U. 2013 r. poz.262).
14. Rozporządzenie Rady Ministrów z dnia 7 sierpnia 2002 r. w sprawie określenia warunków technicznych i
organizacyjnych dla kwalifikowanych podmiotów świadczących usługi certyfikacyjne, polityk certyfikacji
dla kwalifikowanych certyfikatów wydawanych przez te podmioty oraz warunków technicznych dla
bezpiecznych urządzeń służących do składania i weryfikacji podpisu elektronicznego (Dz. U. 2002 r. Nr
128 poz. 1094).
15. Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz. U. 2013 r.
poz. 1422).
16. Ustawa z dnia 17 lutego 2005 r. o informatyzacji podmiotów realizujących zadania publiczne
(Dz. U. 2013 r. poz.235).
17. Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu
udostępniania danych zgromadzonych w rejestrze publicznym (Dz. U. 2005 r. Nr 205 poz. 1692).
18. Ustawa z dnia 10 stycznia 2014 r. o zmianie ustawy o informatyzacji działalności podmiotów
realizujących zadania publiczne oraz niektórych innych ustaw (Dz. U. 2014 poz. 183).
4. Opracowanie i wdrożenie Gminnego Systemu Komunikacji Online (GSKO)
Zakres przedmiotu zamówienia obejmuje opracowanie i wdrożenie Gminnego Systemu Komunikacji Online
na warunkach określonych w niniejszej Specyfikacji Istotnych Warunków Zamówienia.
4.1 Wymagania ogólne
1. System ma stanowić tzw. „pojedynczy punkt kontaktowy" (front-office) dla klientów (interesantów)
jednostek samorządu terytorialnego, partnerów projektu, pełniąc w powiązaniu z systemami
dziedzinowymi zainstalowanymi u partnerów projektu, platformą EZD rolę systemu Gminnego Systemu
Komunikacji Online.
2. System musi posiadać bezpieczną i wiarygodną wymianę dokumentów elektronicznych między
klientem/Interesantem a Urzędem oraz z podmiotami publicznymi za pośrednictwem powszechnie
dostępnej sieci teleinformatycznej.
3. System musi umożliwiać bezpieczne świadczenie interesantom usług publicznych drogą elektroniczną.
4. System musi być zintegrowany z Elektroniczną Skrzynką Podawczą i umożliwiać za jej pośrednictwem
wysyłanie i odbieranie dokumentów elektronicznych.
5. Elektroniczna Skrzynka Podawcza musi spełniać Standard Elektronicznej Skrzynki Podawczej
opublikowany na ePUAP przez ministra właściwego do spraw informatyzacji opublikował, na podstawie
art. 16 ust 1a ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących
zadania publiczne (Dz. U. z 2013 r. poz. 235 oraz Dz. U. z 2014 r. poz. 183).
6. Architektura rozwiązania systemu GSKO powinna zapewnić pracę jednocześnie 500 użytkowników dla
jednego urzędu.
4.2. Wymagania techniczne
1. System musi być zbudowany w architekturze co najmniej trójwarstwowej. Rozdzielone muszą być:
warstwa prezentacji, logiki biznesowej oraz bazy danych.
2. Interfejs aplikacji musi być dostępny za pomocą przeglądarki internetowej (Internet Explorer 8.0 i
nowsze, Firefox 10.0 i nowsze, Chrome 21.0 i nowsze, Opera 12.10 i nowsze, Safari 6.0 i nowsze)
pracującej w dowolnym systemie operacyjnym (MS Windows, Linux oraz Mac OS X), jeśli dana
przeglądarka jest dostępna dla danego systemu operacyjnego.
3. System będzie zainstalowany na 5 serwerach w 5 urzędach, w tym na 2 serwerach zmodernizowanych i
3 serwerach dostarczonych przez wykonawcę.
4. W ramach zamówienia wykonawca dostarczy i zainstaluje na serwerach wszelkie niezbędne do
działania wdrażanych systemów oprogramowanie (w tym relacyjne bazy danych na 5 serwerach i
systemy operacyjne na 3 dostarczanych komputerach).
5. System musi posiadać interfejsy komunikacyjne w postaci usług sieciowych.
6. Interfejsy komunikacyjne Systemu muszą być oparte na standardach SOAP, WSDL i XML lub HTTP
zgodne z REST.
7. System musi wspierać otwarte standardy, w szczególności opracowane przez W3C, OASIS, WAI, co
najmniej w zakresie określonym przez przepisy wydane na podstawie art. 18 ustawy z dnia 17 lutego
2005 ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne.
8. System ma być zbudowany w architekturze opartej na usługach.
9. Wykonane oprogramowanie aplikacyjne nie będzie ograniczało możliwości skalowalności infrastruktury
sprzętowej.
10. Wykorzystana technologia oraz rozwiązania konstrukcyjne muszą zapewniać otwartość w zakresie
dalszego rozwoju portalu.
11. Wymagana jest responsywność tworzonej aplikacji – GSKO.
12. System GSKO musi być dostępny i prawidłowo wyświetlany na urządzeniach mobilnych wyposażonych
w przeglądarkę HTML oraz możliwość instalacji Flash Playera.
13. System musi działać z wykorzystaniem tzw. przyjaznych adresów internetowych.
14. System musi działać w oparciu o kodowanie UTF-8.
15. System musi posiadać funkcjonalności wspierające rozwiązania oparte na WEB 2.0.
16. System musi posiadać rozwiązania umożliwiające zmianę rozmiaru czcionki (trzy różne rozmiary
czcionki).
17. Zmiana rozmiaru czcionki następuje dla wszystkich elementów, które w projekcie graficznym zostaną
ustalone, jako elementy tekstowe (nie dotyczy elementów graficznych).
18. Zmiana rozmiaru czcionki nie jest wymagana dla elementów nawigacji i elementów funkcjonalnych np.
nazwy przycisków, zawartość list rozwijanych itp.
4.3 Wymagania funkcjonalne
1. Istotą GSKO jest udostępnienie zarejestrowanym klientom poszczególnych urzędów gminy wybranych
danych dotyczących danego klienta przechowywanych w systemach dziedzinowych.
2. Użytkownikami GSKO będą klienci poszczególnych Urzędów, którzy założą sobie konto na GSKO i
potwierdzą rejestrację profilem zaufanym lub podpisem kwalifikowanym. Zakładanie konta będzie
odbywało się za pomocą formularza rejestracyjnego (wszystkie wymagane dane na jednej stronie).
3. W ramach interfejsu Użytkownik musi posiadać możliwość korzystania ze wszystkich funkcjonalności,
które są dla niego udostępnione zgodnie z przypisanymi mu uprawnieniami.
4. Skrytka/konto Interesanta musi być spersonalizowanym, wymagającym uwierzytelniania, interfejsem
dostępu Interesanta do usług publicznych GSKO przez przeglądarkę WWW (Internet Explorer 8.0 i
nowsze, Firefox 10.0 i nowsze, Chrome 21.0 i nowsze, Opera 12.10 i nowsze, Safari 6.0 i nowsze).
5. System musi zapewniać realizację pełnej ścieżki komunikacji Urząd < -- > Interesant.
6. Interfejs użytkownika musi być w pełni polskojęzyczny (włączając w to menu, podmenu, formularze,
pomoc kontekstową, teksty podpowiedzi, teksty komunikatów).
7. Instrukcja obsługi musi być zintegrowana z interfejsem w formie pomocy kontekstowej odnoszącej się do
zawartości okna wyświetlanego w danym czasie na ekranie użytkownika systemu.
8. System musi uniemożliwiać wpisywanie nieprawidłowych danych, w szczególności system musi, tam
gdzie jest to możliwe, weryfikować poprawność formatu wprowadzonych danych (np. poprawności pola
dla osób fizycznych PESEL, dla firm NIP). W przypadku wpisania niewłaściwych danych system musi
zaznaczać te dane i informować użytkownika o błędzie. Katalog danych podlegających walidacji:
PESEL, NIP i nr konta bankowego.
9. System musi posiadać hierarchię uprawnień oraz granulację dostępu do zasobów systemu.
10. System musi umożliwiać dwojaką możliwość zakładania konta interesanta: samodzielna rejestracja
potwierdzona linkiem aktywacyjnym oraz wprowadzanie pełnych informacji przez uprawnionego
użytkownika systemu.
11. System musi posiadać mechanizm pozwalający na automatyczne usuwanie konta użytkownika po 12
miesiącach braku aktywności.
12. System GSKO musi pozwalać na uwierzytelnianie interesantów i urzędników za pomocą identyfikatora i
hasła.
13. System musi pozwalać na potwierdzanie konta interesantów i urzędników za pomocą profilu zaufanego
ePUAP lub podpisem kwalifikowanym. Dostęp interesantów i urzędników do danych z systemów
dziedzinowych możliwy jest dopiero po potwierdzeniu konta profilem zaufanym.
14. System musi rejestrować wszystkie próby uwierzytelniania oraz gromadzić i przechowywać następujące
informacje:
a) pełną datę i godzinę
b) nazwę konta, które zostało poddane uwierzytelnianiu
c) adres IP, z którego wykonane było uwierzytelnianie
d) rezultat uwierzytelniania (powodzenie/niepowodzenie).
15. System musi mieć zaimplementowane narzędzia pozwalające na wprowadzenie do systemu zasad
polityki zarządzania hasłami: ustalenie minimalnej/maksymalnej długości haseł, ustalenie wymagania
przynajmniej jednej lub wielu liczb/znaków specjalnych/wielkich liter.
16. System musi umożliwiać uzyskanie przez interesanta informacji na temat etapu realizacji spraw, które
zostały przez niego założone w urzędzie zarówno drogą elektroniczną jak i tradycyjną (papierową). Dane
o etapie realizacji powinny być pobrane z EZD.
17. System musi umożliwiać interesantowi wgląd w stan sprawy na każdym poziomie jej procesowania w
urzędzie. Użytkownik w GSKO ma mieć informację o postępach w załatwianiu sprawy (rejestracja w
EZD, spawa w toku, sprawa zakończona, itp.) oraz podgląd zgromadzonych w wersji elektronicznej w
danej sprawie dokumentów.
18. System musi umożliwiać urzędnikowi kontakt z interesantem celem wezwania go do uzupełnienia
dokumentów niezbędnych do załatwienia sprawy.
19. System musi umożliwiać interesantowi wgląd i pobranie wydanej decyzji administracyjnej.
20. Zalogowany interesant musi mieć możliwość:
a) przeglądania zgromadzonych w jego Profilu Interesanta,
b) wypełnienie dowolnego spośród udostępnionych e-formularzy, dołączenie załączników i wysłania ich
do EZD,
c) zachowania częściowo wypełnionego danymi formularza i powrotu do edycji w późniejszym czasie
(w trakcie trwania sesji),
d) podpisania wysyłanych dokumentów podpisem elektronicznym weryfikowanym przez ePUAP lub
podpisem kwalifikowanym,
e) odebrania dokumentu UPO potwierdzającego złożenie wniosku,
f) dokonania płatności elektronicznej dla składanego wniosku elektronicznego,
g) sprawdzenia stanu sprawy,
h) odebrania dokumentów elektronicznych przesłanych przez Urząd, w tym decyzji administracyjnej
(jeżeli będzie wydana) lub pisma wystosowanego w realizowanej sprawie,
i) włączenia modułu newslettera i zdefiniowania tematyki wiadomości jakie będzie chciał otrzymywać z
Urzędu,
j) zarządzanie ustawieniami skrzynki w zakresie:
 zmiany hasła
 wprowadzenie i zmiana danych osobowych (dane te będą wykorzystane do automatycznego
wypełnienia pół formularzy wniosków)
 wprowadzenie i zmiana adresu poczty elektronicznej
 uzyskania informacji o zdarzeniach, które zaszły w związku z jego wnioskami złożonymi w
urzędach, pozwalających na śledzenie stanu
realizacji sprawy, podgląd dokumentów
wysłanych przez urząd do interesanta.
zamówienia automatycznego przesłania powiadomienia o zmianie statusu sprawy na podany
przez siebie adres e-mail.
Zastosowany system płatności elektronicznych musi spełniać minimum następujące wymagania:
a) Obsługiwać popularne banki w Polsce
b) Umożliwiać wnoszenie płatności za pomocą popularnych kart płatniczych
System uprawnień administracyjnych musi być hierarchiczny, tak by było możliwe powoływanie przez
głównego administratora innych administratorów i nadawania im części posiadanych przez siebie
uprawnień.
System umożliwia pracownikom z poziomu GSKO przeglądania i eksportu do PDF wypełnionych przez
interesanta dokumentów oraz wysyłania wiadomości do interesantów.
System musi posiadać ikony graficzne dla najpopularniejszych rozszerzeń plików - dla min. 8 (.pdf, .xls
.xlsx, .doc .docx, .zip, .rar, .txt).
Każda czynność wykonywana w systemie musi być zapisywana, tak aby możliwa była identyfikacja
osoby wykonującej czynność, obiektów których dotyczyła czynność oraz czasu wykonania czynności.

21.
22.
23.
24.
25.
4.4. Bezpieczeństwo systemu
1. Oferowany System musi posiadać możliwość tworzenia kopii bezpieczeństwa bazy danych. Dostarczone
narzędzia muszą posiadać możliwość definiowania harmonogramów automatycznego wykonywania
kopii. Kopie bezpieczeństwa mają zapewnić możliwość odzyskania danych i przywrócenia całego
Systemu do stanu normalnej pracy po ewentualnej awarii sprzętowej lub programowej.
2. Poufność danych w odniesieniu do komunikacji z użytkownikiem publicznym zapewniona będzie przez
wykorzystanie protokołu SSL (HTTPS). Część informacyjna mająca charakter publiczny, może być
obsługiwana poprzez protokół HTTP bez stosowania szyfrowania. Wykonawca zapewni certyfikat SSL
na potrzeby szyfrowania połączenia na okres 5 lat od momentu podpisania końcowego protokołu
odbioru.
3. Aplikacje webowe muszą być zabezpieczone przed atakami typu "SQL injection". Aplikacje webowe
zapisujące dane w bazie muszą unieszkodliwiać niedozwolone znaki w danych wejściowych do bazy.
4. Aplikacje webowe muszą być odporne na ataki Cross-site scripting (XSS) i Cross-site request forgery
(XSRF). Wykonawca musi zaprojektować aplikacje webowe tak by były odporne na takie ataki, czyli
muszą spełniać następujące warunki:
a) nie można na stronie zamieszczać odnośników do skryptów znajdujących się na innych serwerach;
b) jeśli strona jest udostępniana po protokole HTTPS, to ważne akcje zmiany danych w portalu (np.
zapisanie danych) muszą wymagać dodatkowego potwierdzenia (np. captcha, ponowne
zalogowanie się do portalu).
5. Formularz rejestracji nowego użytkownika musi być zabezpieczony za pomocą mechanizmu CAPTCHA
przed robotami rejestrującymi masowo konta.
6. Rejestracja użytkownika wymaga podania adresu e-mail. System musi być zaprojektowany tak, by daną
wymaganą podczas rejestracji był ważny adres e-mail, na który zostanie wysłana wiadomość z linkiem
aktywującym konto.
7. W systemie musi być przechowywany skrót hasła wyliczony za pomocą bezpiecznej do zastosowań
kryptograficznych jednokierunkowej funkcji mieszającej. Hasło użytkownika utrwalone w bazie danych
nie może być zapisane otwartym tekstem. System musi przechowywać postać hasła po przetworzeniu
algorytmem bezpiecznej do zastosowań kryptograficznych jednokierunkowej funkcji mieszającej (np.
MD5 lub SHA).
8. System musi posiadać dodatkowe mechanizmy bezpieczeństwa w zakresie nieautoryzowanego dostępu
do danych poprzez:
a) automatyczne blokowanie loginu użytkownika przy przekroczeniu “x” nieudanych prób logowania,
b) automatyczne blokowanie aplikacji po “x” nieudanych prób logowania w przypadku, gdy nie został
nigdy użyty w aplikacji, czyli jest nieznany,
c) automatyczne wymuszenie zmiany hasła użytkownika po upływie “x” dni, wartość “x” rozumiane są
jako wartości całkowite wprowadzane niezależnie dla każdego elementu przez administratora
systemu.
9. Wykonawca musi zabezpieczyć portal przed nieautoryzowanym definiowaniem uprawnień przez
użytkowników. Tylko zalogowani administratorzy mogą definiować uprawnienia.
10. Wykonawca musi skonfigurować serwery aplikacji tak, by automatyczne zamykały sesję zalogowanego
użytkownika po definiowalnym przez administratora czasie nieaktywności.
11. System musi posiadać mechanizmy rejestrujący zmiany w ustawieniach administracyjnych (dla
administratora).
4.5. Szczegółowy opis funkcjonalności GSKO
1. Szczegółowy opis funkcjonalności GSKO zawiera załącznik nr 1.
2. Opisana w załączniku koncepcja systemu jest autorskim opracowaniem Zamawiającego.
3. Zamawiający dopuszcza modyfikację układu prezentacji danych opisanego w koncepcji jeśli uzna, że
proponowane zmiany są korzystne dla zamawiającego z punktu widzenia funkcjonalności i prostoty
obsługi systemu przez interesantów, a wykonawca potwierdzi techniczną możliwość ich wprowadzenia.
4.6. Szablony wiadomości systemowych
1. System musi pozwalać uprawnionemu pracownikowi na dowolne zarządzanie treścią następujących
wiadomości e-mail - systemowych powiadomień:
a) Wiadomość o aktywacji konta,
b) Wiadomość dotycząca sposobu zmiany hasła.
2. W treści wiadomości musi być możliwość osadzenia obiektów, pod które system umieszcza:
a) Link do aktywacji konta,
b) Linku do zmiany hasła .
4.7. Formularze elektroniczne
1. System ma wbudowane formularze 41 spraw, których wzory stanowią załącznik nr 2. Zamawiający po
podpisaniu umowy dostarczy wykonawcy wykaz pól obowiązkowych i innych danych, które będą
podlegały walidacji przez system.
2. Istnieje możliwość zmiany spraw, dla których mają być opracowane formularza, za zgodą Wykonawcy,
jeśli zmiana ta jest korzystna dla Zamawiającego.
3. System musi umożliwiać edycję dostępności dla klienta poszczególnych formularzy (formularz
dostępny/formularz niedostępny).
4. Przy wypełnianiu formularza przez interesanta istnieje możliwość komunikacji z urzędnikiem
odpowiedzialnym za dany zakres spraw, za pomocą wbudowanego chatu. Funkcje tą można wyłączyć z
poziomu panelu administratora GSKO.
4.8. Ewidencja opłat i płatności
1. System GSKO umożliwia:
a) Pobranie informacji o wysokości opłat przez pozostałe komponenty systemu poprzez udostępnione
interfejsy.
b) Zarejestrowanie faktu pojawienia się należności w systemie poprzez udostępnione interfejsy.
c) Zarejestrowanie faktu dokonania wpłaty poprzez udostępnione interfejsy.
d) Możliwość dokonania płatności jednocześnie ze składanym wnioskiem.
e) Możliwość dokonania płatności za wskazaną przez użytkownika należność widoczną na jego koncie
jako oczekująca do zapłacenia.
f) Udostępnienie użytkownikowi informacji o stanie rozliczenia należności.
2. System musi umożliwiać ograniczenie czasowe płatności, tzn. określić datę, po której wymaganie
wniesienia opłaty wygaśnie.
4.9 Elektroniczna Skrzynka Podawcza
1. System musi być wyposażony w Elektroniczną Skrzynkę Podawczą (ESP). Wykonawca może
wykorzystywać funkcjonalności ESP udostępnionej na ePUAP.
2. ESP musi obsługiwać zarówno korespondencję kierowaną do Urzędu, jak i korespondencję wysyłaną
przez Urząd do skrzynki Interesanta.
4.10. Wykaz wniosków
1. W ogólnodostępnej części GSKO zamieszczony zostanie wykaz wniosków, które można złożyć w
Urzędzie za pomocą GSKO. Wnioski będą podzielone na kategorie, a do każdego dołączony będzie
krótki opis przygotowany przez zamawiającego oraz link do formularza w systemie (dostępnego jedynie
dla zarejestrowanych użytkowników systemu) oraz formularza do wydrukowania (w formacie pdf).
2. Stronę z wykazem spraw będzie można modyfikować w panelu administratora.
4.11. Integracja z systemem EZD
1. System musi zapewniać współpracę z systemem Elektronicznego Zarządzania Dokumentami w
zakresie przekazywania dokumentów elektronicznych oraz przekazywania do Interesanta
wydanych decyzji/odpowiedzi.
2. System musi udostępniać możliwość przesyłania informacji zwrotnej dotyczącej danej sprawy w
postaci publikacji statusu sprawy automatycznie generowanego w systemie EZD na każdym
etapie procesu rozpatrywanej sprawy.
3. System musi zapewniać możliwość przesłania dodatkowych dokumentów dotyczących danej
sprawy.
4. System musi umożliwiać dostęp Interesanta do informacji na temat statusu każdej realizowanej przez
niego sprawy urzędowej na każdym etapie jej procesowania w EZD.
4.12. Integracja z systemami dziedzinowymi
1. W poszczególnych urzędach gmin wykorzystywane są następujące systemy dziedzinowe:
1) Urząd Gminy Wąbrzeźno:
▪ RADIX Systemy Komputerowe: WIP+ (w tym opłata adiacencka), GOK+, NDM+, POGRUN+,
POST+, ELUD+, FKB+,
2) Urząd Miasta i Gminy Łasin:
▪ RADIX Systemy Komputerowe: WIP+, GOK+, NDM+, POGRUN+, ELUD+, FKB+,
3) Urząd Gminy w Płużnicy
▪ RADIX Systemy Komputerowe: WIP+, GOK+, NDM+, POGRUN+, POST+, EKO+, ELUD+, FKB+,
4) Urząd Gminy Grudziądz:
▪ RADIX Systemy Komputerowe: WIP+, NDM+, POGRUN+, ELUD+
▪ LogicSynergy Sp. z o.o: ECOSANIT (odpady)
▪ LogicSynergy Sp. z o.o: TP Media (woda)
▪ Sygnity: DM (dodatki mieszkaniowe)
▪ Vulcan: optimum (księgowość)
5) Urząd Gminy Unisław:
▪ Producent: Zakład Systemów Informatycznych SIGID: Podatek od nieruchomości dla osób
prawnych, Podatek od środków transportowych, Podatek rolny/leśny/nieruchomości dla osób
fizycznych, Podatek rolny/leśny dla osób prawnych, Inne opłaty
▪ Producent: Anko System Sp. z o.o.: Hydrosoft (woda i ścieki).
2. W ramach Zadania nr 2 przedmiotowego zamówienia, Wykonawca w czterech urzędach gmin dokona
integracji GSKO z istniejącymi systemami dziedzinowymi firmy RADIX Systemy Komputerowe,
wymienionymi w punkcie 4.12.1.
3. W ramach Zadania nr 3 przedmiotowego zamówienia, Wykonawca w jednym urzędzie gminy dokona
integracji GSKO z istniejącymi systemami dziedzinowymi firmy LogicSynergy Sp. z o.o. wymienionymi w
punkcie 4.12.1.
4. W ramach Zadania nr 4 przedmiotowego zamówienia, Wykonawca w jednym urzędzie gminy dokona
integracji GSKO z istniejącymi systemami dziedzinowymi firmy Sygnity wymienionymi w punkcie 4.12.1.
5. W ramach Zadania nr 5 przedmiotowego zamówienia, Wykonawca w jednym urzędzie gminy dokona
integracji GSKO z istniejącymi systemami dziedzinowymi firmy Vulcan wymienionymi w punkcie 4.12.1.
6. W ramach Zadania nr 6 przedmiotowego zamówienia, Wykonawca w jednym urzędzie gminy dokona
integracji GSKO z istniejącymi systemami dziedzinowymi firmy Zakład Systemów Informatycznych
SIGID wymienionymi w punkcie 4.12.1.
7. W ramach Zadania nr 7 przedmiotowego zamówienia, Wykonawca w jednym urzędzie gminy dokona
integracji GSKO z istniejącymi systemami dziedzinowymi firmy Anko System Sp. z o.o. wymienionymi w
punkcie 4.12.1.
8. Posiadaczem autorskich praw majątkowych oraz kodów źródłowych poszczególnych systemów
dziedzinowych są firmy wymienione w punkcie 4.12.1.
9. Uzyskanie wszelkich zgód i dodatkowych licencji niezbędnych do integracji systemów należy do
Wykonawcy i Wykonawca pokryje wszystkie ewentualne koszty związane z ich uzyskaniem.
10. Wykonawca w ramach zamówienia pokryje również koszty ewentualnych dodatkowych modułów i
modyfikacji niezbędnych do integracji systemów dziedzinowych z GSKO.
5. System Elektronicznego Zarządzania Dokumentami
Zakres przedmiotu zamówienia obejmuje dostawę wraz z wdrożeniem Systemu Elektronicznego
Zarządzania Dokumentami na warunkach określonych w niniejszej Specyfikacji Istotnych Warunków
Zamówienia.
5.1 Wymagania ogólne dla EZD
1. System Elektronicznego Zarządzania Dokumentami (EZD) ma pełnić istotną rolę w realizacji
codziennych zadań pracowników Partnerów projektu. W EZD mają być gromadzone i przetwarzane
wszystkie pisma, które za pośrednictwem dokumentów elektronicznych oraz tradycyjnych kancelarii
wpływają codziennie do urzędu. EZD ma wspierać proces rozpatrywania spraw zapewniają
mechanizmy przekazywania dokumentów pomiędzy komórkami i pracownikami. W EZD mają być
także rejestrowane pisma wychodzące i wewnętrzne powstające w codziennej pracy. System ma
zapewnić sprawny obieg od momentu przyjęcia aż po archiwizację.
2. System EZD będzie w pełni zintegrowany z GSKO. Dostęp do funkcjonalności obu systemów będzie się
odbywał za pomocą jednego logowania. Pisma przychodzące z GSKO będą rejestrowane i dekretowane
w EZD. Pisma generowane i podpisywane za pomocą GSKO będą wysyłane za pośrednictwem systemu
EZD.
3. System EZD ma umożliwiać obsługę dokumentów wg następującego schematu:
1) Wybór rodzaju pisma. Na tej podstawie wyświetlony zostanie odpowiedni formularz rejestracyjny oraz
przyjęta ścieżka obiegu dokumentu.
2) Wypełnienie formularza rejestracyjnego i opisanie go metadanymi zgodnie z rozporządzeniem, o
którym mowa w pkt. 3.1.
3) Dokonanie dekretacji.
4) Założenie sprawy i nadanie jej numeru zgodnie z JRWA. Założenie teczki lub podteczki sprawy.
5) Dołączanie dokumentów do sprawy.
6) Przygotowanie projektu pisma. Pismo może być utworzone w EZD, GSKO lub w zewnętrznym
procesorze tekstu.
7) Zatwierdzenie projektu przez osobę upoważnioną.
8) Wydruk lub podpis elektroniczny pisma.
9) Przygotowanie pisma do wysyłki – wybór rodzaju przesyłki, określenie kosztu przesyłki, wydruk
etykiety adresowej i ZPO.
10) Zatwierdzenie przesyłki w kancelarii, odnotowanie sposobu jej wysłania i przygotowanie jej do
nadania – wydruk książki nadawczej, wydruk dziennika korespondencji.
11) Wprowadzenie do systemu podpisanego przez adresata ZPO lub zwrotu przesyłki.
12) Zamknięcie sprawy.
13) Wydruk metryki sprawy oraz spisu spraw.
4. System ma umożliwić również kadrze zarządzającej monitorowanie terminowości załatwiania spraw oraz
generowania raportów, o których mowa w rozporządzeniu, o którym mowa w pkt. 3.1.
5.2 Wymagania techniczne
1. System musi być zbudowany w architekturze trójwarstwowej. Rozdzielone muszą być: warstwa
prezentacji, logiki biznesowej oraz bazy danych.
2. Interfejs aplikacji musi być dostępny za pomocą przeglądarki internetowej (min. Internet Explorer 8.0
i nowsze, Firefox 10.0 i nowsze, Chrome 21.0 i nowsze, Opera 12.10 i nowsze, Safari 6.0 i nowsze)
pracującej w dowolnym systemie operacyjnym (MS Windows, Linux oraz Mac OS X). Zamawiający nie
dopuszcza rozwiązania, w którym to część administracyjna i moduł archiwizacji dostępny będzie
w technologii desktopowej.
3. W ramach zamówienia wykonawca dostarczy i zainstaluje na serwerach wszelkie niezbędne do
działania wdrażanych systemów oprogramowanie (system operacyjny, relacyjna baza danych).
4. System musi pracować w oparciu o relacyjną bazę danych.
5. System musi wspierać komunikację sieciową za pośrednictwem technologii WebServices.
5.3 Wymagania funkcjonalne
1. EZD musi obsługiwać rejestrację przesyłek przychodzących w formie papierowej i elektronicznej,
dostarczanych osobiście przez klientów urzędu, operatora pocztowego i przekazywanych za
pośrednictwem e-mail, platformy ePUAP, GSKO lub doręczanych na nośniku informatycznym.
2. Podczas procesu rejestracji przesyłek przychodzących w formie papierowej EZD musi umożliwiać
skanowanie z wykorzystaniem skanera zgodnego z TWAIN (z poziomu interfejsu aplikacji)
poszczególnych dokumentów, wchodzących w skład przesyłki. Interfejs do skanowania musi posiadać,
co najmniej narzędzia do edycji obrazu ze skanera poprzez: obrót o dowolny kąt, zmianę kolejności
stron, zapis do PNG i PDF, zmiany kontrastu.
3. EZD musi umożliwiać odebranie poczty elektronicznej za pomocą wbudowanego klienta pocztowego
POP3 oraz SMTP i umożliwić rejestrację w rejestrze przesyłek wpływających lub bezpośrednie
dołączenie wiadomości z załącznikami do akt sprawy.
4. Wbudowany klient poczty powinien składać się co najmniej z następujących elementów:
1) Skrzynka odbiorcza
2) Kopie robocze
3) Wysłane
4) Usunięte
5) Spam
6) Książka adresowa
5. EZD musi umożliwiać opatrywanie przesyłek przychodzących metadanymi zgodnie z instrukcją
kancelaryjną oraz dowolne rozszerzenie zbioru metadanych w oparciu o rodzaj rejestrowanego
dokumentu.
6. System musi umożliwiać generowanie potwierdzenia przyjęcia przesyłki wpływającej przez punkt
kancelaryjny, opatrzonego kodem kreskowym odpowiadającym kodowi kreskowemu przesyłki.
Potwierdzenie przyjęcia wygenerowane przez EZD musi być konfigurowalne i umożliwiać
zamieszczenie, co najmniej daty wpływu, oznaczenia graficznego jednostki, nazwy jednostki.
7. EZD musi umożliwiać rejestrację zwrotów przesyłek w przypadku ich niedoręczenia oraz pocztowych
potwierdzeń odbioru (zwrotek).
8. EZD musi umożliwiać zarządzanie zakresem zawartości słowników systemowych. Minimalna lista
słowników to: JRWA, Gońcy,
Kody pocztowe, Rodzaje dokumentów, Sposoby dostarczania
korespondencji, Sposoby wysyłania korespondencji, Statusy spraw, Sposoby płatności.
9. System musi posiadać możliwość definicji zespołów roboczych złożonych z dowolnych użytkowników.
10. EZD musi umożliwiać edycję poszczególnych kategorii JRWA z uwzględnieniem kategorii archiwalnych.
11. EZD musi umożliwiać wczytanie nowego JRWA z pliku np. CSV. Musi umożliwiać wprowadzenie kilku
JRWA z możliwością wybrania, który wykaz używany jest jako domyślny.
12. EZD musi umożliwiać prowadzenie wielu punktów kancelaryjnych w zakresie rejestracji przesyłek.
13. EZD musi umożliwiać użytkownikom dekretującym wskazanie jednej lub kilku komórek lub osób
merytorycznych - odpowiedzialnych za prowadzenie i zakończenie sprawy. W przypadku wyboru kilku
osób, możliwe jest wskazanie osoby odpowiedzialnej za ostateczne załatwienie sprawy.
14. System musi umożliwiać na etapie dekretacji przekazanie polecenia dotyczącego sposobu rozpatrzenia
danego pisma. System musi pozwalać na wprowadzenie polecenia kierowanego do wszystkich
adresatów dekretacji i indywidualnego polecenia dla każdego adresata.
15. Dla każdego rodzaju sprawy System musi umożliwić określenie liczby dni potrzebnych na jej rozpatrzenie.
Ponadto, każdy z użytkowników musi mieć możliwość określenia liczby dni, przed wyznaczonym
terminem zakończenia sprawy, w trakcie których sprawa będzie oznaczana przez system jako zagrożona
przekroczeniem terminu, a po ich przekroczeniu – jako przeterminowana.
16. System musi posiadać mechanizm zapamiętywania zapisanych wartości formularza rejestracyjnego
pozwalający na szybkie wprowadzenie informacji dla kolejnego pisma np. tego samego nadawcy.
17. System musi posiadać wbudowany mechanizm pozwalający sprawdzić czy pismo już nie zostało
zarejestrowane. Mechanizm ten musi weryfikować co najmniej znak dokumentu oraz dane nadawcy.
18. System musi pozwalać na wycofanie błędnej dekretacji lub jeśli pozwalają na to dodatkowe uprawnienia
– przekazanie przez użytkownika pisma do właściwej komórki organizacyjnej.
19. Dla każdego pisma i sprawy System musi umożliwiać podgląd historii dekretacji (z zapisami
poszczególnych dekretacji oraz związanych z nimi poleceń lub typów) oraz historii dokumentu,
zawierającej operacje na nim wykonywane (np. rejestracja pisma, anulowanie, zakończenie sprawy itp.).
System musi również odnotowywać każdą zmianę stanu i statusu sprawy oraz ewentualnej zmiany
planowanego terminu zakończenia sprawy.
20. System musi wyróżniać co najmniej sprawy: bieżące, nierozpoczęte, zakończone, zamknięte,
wstrzymane, wznowione, do wiadomości.
21. EZD musi umożliwić odróżnienie oraz jednoznaczną identyfikację i odrębne przetwarzanie
poszczególnych dokumentów, przechowywanych w postaci odwzorowań cyfrowych wchodzących w
skład przesyłki, przy zachowaniu ich powiązania z przesyłką.
22. EZD musi umożliwić dodawanie przez użytkownika informacji opisujących poszczególne dokumenty,
przesyłki lub sprawy w postaci notatek, zgodnie z instrukcją kancelaryjną.
23. Dla dokumentów papierowych nie podlegających skanowaniu oraz dokumentów na nośnikach
elektronicznych nie podlegających kopiowaniu do systemu EZD, system musi umożliwić sporządzenie
metryki, zawierającej podstawowe informacje o dokumencie (co najmniej – tytuł, identyfikator, notatka).
24. EZD musi być zintegrowane z platformą elektronicznych usług publicznych ePUAP w zakresie co
najmniej:
1) Możliwości automatycznego odbierania oraz wysyłania dokumentów na platformę ePUAP
bezpośrednio z poziomu systemu,
2) Automatycznego dołączania UPO do odebranych/wysłanych dokumentów (bez konieczności
rejestracji z RKP).
3) Podpisania dokumentów profilem zaufanym,
4) Automatycznego dodawania interesanta z pisma otrzymanego z ePUAP do bazy interesantów lub
scalenie z istniejącym jeżeli takowy istnieje.
25. EZD musi posiadać wbudowany edytor tekstu WYSYWIG służący do tworzenia dokumentów wewnątrz
systemu, bez konieczności używania zewnętrznych aplikacji. Edytor powinien posiadać podstawowe
funkcjonalności edytora tekstu służące redagowaniu dokumentów.
26. EZD musi umożliwiać tworzenie szablonów dokumentów na bazie wbudowanego edytora tekstu
WYSWIG co najmniej w zakresie:
1) możliwości zdefiniowania szablonu dokumentu lokalnego i globalnego (wspólnego),
2) możliwość opracowywania i zatwierdzania szablonów (wzorów) dokumentów,
3) prowadzenia repozytorium szablonów, które umożliwia zarządzanie szablonami,
4) możliwości ograniczania wyświetlania szablonów do kategorii JRWA, właściciela, komórki
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
organizacyjnej,
5) możliwości wstawiania znaczników do szablonu. Minimalny zakres znaczników:
a) dane nadawcy,
b) dane adresata (min. imię, nazwisko, adres, nazwa instytucji),
c) kod kreskowy,
d) pełne dane pracownika prowadzącego sprawę,
e) znak pisma/sprawy,
f) adresaci pisma,
g) data pisma,
h) każdy z osobna element metryki dokumentu tworzonego z wykorzystaniem szablonu,
i) każdy z osobna elementy metryki sprawy w ramach, której wystawiany jest dokument z
wykorzystaniem szablonu,
j) lista stron sprawy,
k) elementy pozwalające na sterowaniem zawartością dokumentu np. znacznik nowej strony,
6) możliwości wykorzystania
zdefiniowanego szablonu przy tworzeniu pism wychodzących z
autouzupełnianiem zawartości w/w znaczników,
7) możliwości podglądu pisma przed wysłaniem,
8) możliwości generowania korespondencji seryjnej.
EZD musi umożliwić generowanie i drukowanie nalepek z kodami kreskowymi na dokumenty papierowe
oraz nośniki i odnajdywanie na podstawie zeskanowanej nalepki odwzorowania cyfrowego bądź metryki
danego dokumentu.
EZD musi zapewniać drukowanie kopert, zwrotek, książki pocztowej.
System musi umożliwiać stworzenie dowolnej liczby typów wydruków dostępnych w stosunku do pism
wychodzących, w tym umożliwia wydruk ZPO i kopert, których liczba i kształt będzie dowolnie
dostosowywana do indywidualnych potrzeb użytkowników.
System musi pozwalać na hurtowy wydruk danego rodzaju dokumentu dla wielu przesyłek jednocześnie,
np. wydruk ZPO dla listów poleconych.
System musi pozwalać na łączenie wielu przesyłek wychodzących w jedną kopertę, w przypadku gdy
użytkownik stwierdzi, iż dotyczą one tego samego adresata.
System umożliwia oznaczanie kopert z przesyłkami kodami kreskowymi, poprzez generowanie
odpowiednich etykiet, których zawartość może być regulowana przez administratora.
System nie może preferować żadnego operatora pocztowego, więc musi umożliwiać tworzenie własnych
cenników przesyłek uwzględniających formę wysyłki, wagę i gabaryt.
System musi pozwalać na obsługę doręczania korespondencji przez gońców.
EZD musi umożliwić rejestrację obiegu (lokalizacja, czas przemieszczenia, użytkownik) dokumentów
papierowych (dla których istnieje odwzorowanie cyfrowe oraz dla których nie zostało ono wykonane)
oraz nośników.
EZD musi umożliwić sporządzanie odwzorowań cyfrowych dokumentów poprzez skanowanie dostępne
z poziomu systemu, zgodnie z wymaganiami określonymi w instrukcji kancelaryjnej.
EZD musi umożliwić wszczynanie, prowadzenie i załatwianie spraw, przechowywanie akt sprawy
i prowadzenie spisów spraw zgodnie z obowiązującymi przepisami. System automatycznie musi
nadawać znak sprawy i zapewnia jego zgodność z wymogami instrukcji kancelaryjnej.
EZD musi umożliwić prowadzenie rejestrów kancelaryjnych, w tym rejestru przesyłek wpływających,
wychodzących oraz pism wewnętrznych.
EZD musi umożliwić numerację i klasyfikację spraw w oparciu o JRWA zgodnie z instrukcją
kancelaryjną.
EZD musi umożliwiać grupowanie dynamiczne spraw w projekty, określenie członków grupy projektowej
oraz praw dostępu do projektu.
EZD musi zapewniać funkcjonalność organizowania spotkań w ramach projektów.
EZD musi zapewniać kontrolę poszczególnych spraw wchodzących w skład projektów.
EZD musi umożliwiać udostępnianie spraw innym użytkownikom, udostępnianie musi odbywać się
bezpośrednio z poziomu sprawy. Użytkownik prowadzący sprawę powinien posiadać możliwość
różnicowania poziomu uprawnień do sprawy co najmniej w zakresie:
1) Udostępnianie sprawy:
a) pracownik może udostępniać sprawę,
b) pracownik nie może udostępniać sprawy.
2) Zmiana statusu:
a) pracownik może zmieniać status sprawy,
b) pracownik nie może zmieniać status sprawy.
3) Pracownik widzi:
a) innych pracowników mających dostęp do sprawy,
b) dokumentację roboczą nie tworzącą akt sprawy,
44.
45.
46.
47.
48.
49.
50.
51.
c) komentarze do sprawy.
4) Pracownik może dodawać:
a) przesyłki wpływające,
b) przesyłki wychodzące,
c) akta sprawy, nie będące przesyłką,
d) faktury
e) dokumentację roboczą,
f) komentarze.
EZD musi posiadać możliwość wglądu do spraw z poziomu dokumentu oraz wglądu do dokumentów
z poziomu spraw.
EZD musi posiadać moduł nadzoru, który umożliwi przełożonym pełen wgląd do dokumentów, spraw
pracowników podległych.
EZD musi posiadać moduł koordynatora umożliwiający przydzielanie użytkownikom dostępu do
poszczególnych kategorii JRWA:
1) koordynator musi posiadać możliwość przydzielenia wybranym użytkownikom puli kategorii JRWA,
w których użytkownik może tworzyć spawy. Koordynator musi mieć wgląd w aktualnie przydzielonej
puli kategorii JRWA jak również musi mieć możliwość wglądu oraz przywrócenia archiwalnej puli
kategorii JRWA,
2) koordynator musi posiadać możliwość koordynacji teczek i spraw, w ramach, której koordynator
posiada wgląd do teczek i spraw przypisanych do danej kategorii JRWA, koordynator posiada wgląd
do teczek i spraw, nie może mieć jednak dostępu do danych interesanta oraz treści dokumentów
prowadzonych w teczkach i sprawach.
3) Koordynator musi posiadać możliwość ograniczana dostępu to wybranych, wcześniej
zdefiniowanych rodzajów spraw.
EZD musi posiadać moduł raportów umożliwiający:
1) utworzenie raportu oraz zestawień na podstawie dowolnych danych przechowywanych w systemie,
2) prezentowanie danych w formie tabelarycznej, wykresów słupkowych oraz wykresów kołowych,
3) wstawianie wpisów interaktywnych, hiperłączy oraz drążenie danych,
4) wyświetlanie spisu treści do danych zawartych w raporcie,
5) eksport danych do plików CSV,
6) eksport raportu co najmniej do następujących formatów: doc, docx, xls, xlsx, ppt, pptx, odp, ods, odt,
pdf,
7) definiowanie grup raportów.
Parametry i dane raportu możliwe do zdefiniowania muszą obejmować, co najmniej:
1)
Dane z metryk spraw i dokumentów,
2)
Dane dotyczące czasów rozpatrywania spraw,
3)
Statusy spraw,
4)
Dane pracowników prowadzących sprawę,
5)
Zawężenie spraw wg struktury organizacyjnej, czyli dla dowolnej komórki organizacyjnej.
System musi udostępniać zestaw raportów niezbędnych do pracy urzędu. Użytkownik musi mieć
możliwość określenia podstawowych parametrów raportów (okres za jaki raport będzie generowany,
sposób sortowania ). System musi umożliwiać wygenerowanie co najmniej następujących raportów:
1) Pocztowa książka nadawcza.
2) Raport dekretacji.
3) Raport z książki doręczeń.
4) Raport pism przychodzących.
5) Raport pism przychodzących przekazanych.
6) Dzienniki korespondencji na poziomie każdej komórki organizacyjnej.
7) Raport pism wychodzących.
8) Raport statusów doręczeń dokumentów wysyłanej w każdej sprawie.
9) Raport dotyczący kosztów wysyłek dokumentów.
10) Raporty przeznaczone dla kierownika (w tym statystyka, sprawy przeterminowane, sprawy w toku,
sprawy zakończone).
11) Rejestr zwrotów.
12) Spis spraw.
System musi udostępniać szczegółowe informacje statystyczne dotyczące rozpatrywania spraw,
uwzględniające w szczególności czas rozpatrywania spraw, komórki organizacyjne, wybrane dowolnie
hasła z wykazu JRWA, wątki dekretacji, liczbę wydanych dokumentów, przepływ dokumentów pomiędzy
dowolnymi komórkami.
EZD musi umożliwiać oddzielną rejestrację dokumentów nietworzących akt sprawy, w szczególności:
1) rejestru faktur - wyposażonego w opcję wieloetapowego zatwierdzania faktury i potwierdzania
płatności faktury przez uprawnionych użytkowników wraz z mechanizmem wizualnego oznaczania
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
faktur przeterminowanych,
2) definiowania z dowolnego rejestru poprzez:
a) definicję pól i typów pól dokumentów wchodzących w skład rejestru,
b) definicję pól wchodzących w skład wydruku rejestru,
c) możliwość definiowania masek wprowadzanego tekstu w tekstowych polach rejestru.
d) definiowanie uprawnień (podglądu, edycji) na poziomie całego rejestru oraz jego pojedynczych
kolumn
EZD musi posiadać rejestr pism wewnętrznych nietworzących akt sprawy.
EZD musi umożliwiać przeprowadzenie wielopoziomowego procesu akceptacji pism wewnętrznych nie
tworzących akt sprawy oraz ich późniejsza wysyłkę do interesanta. Musi istnieć możliwość umieszczania
komentarzy w pismach, komentarze mogą być udostępniane wszystkim użytkownikom uczestniczącym
w procesie akceptacji jak i ograniczone dla wybranych użytkowników.
EZD musi posiadać funkcjonalność tzw. Rozdzielnika. Odebranie przez adresata korespondencji
wewnętrznej, polecenia itd. musi być automatycznie odnotowane i przechowywane w systemie,
a informacja o tym fakcie musi być łatwo dostępna dla nadawcy.
EZD musi umożliwiać wielostopniowy proces akceptacji dokumentów (zgodnie z instrukcją kancelaryjną
podmiotu), z możliwością parametryzacji wymagalności akceptacji dla dokumentu przed jego wysłaniem
do interesanta lub założeniem z niego sprawy. Użytkownik powinien mieć możliwość swobodnego
definiowania ścieżek akceptacji (wskazania konkretnych osób oraz liczby pozytywnych zatwierdzeń dla
każdego etapu akceptacji), co najmniej:
1) akceptację przez jednego użytkownika – element jest zaakceptowany tylko do jednego użytkownika
(np.: jeden z jeden)
2) przesłanie dokumentu do wielu i akceptację przez jednego z nich – element jest zaakceptowany gdy
tę operację wykona jeden z grupy użytkowników (np.: jeden z trzech)
3) przesłanie i akceptacje przez wielu użytkowników – element jest zaakceptowany gdy tę operację
wykona większość użytkowników (np.: dwóch z trzech)
4) przesłanie i akceptację przez wszystkich – element jest zaakceptowany gdy te operację wykonają
wszyscy użytkownicy (np.: trzech z trzech)
EZD musi umożliwić zapis projektów pism przekazywanych pomiędzy użytkownikami lub komórkami w
trakcie załatwiania sprawy, a także zamieszczanie komentarzy odnoszących się do projektów pism.
EZD musi zapewnić prowadzenie, podgląd oraz wydruk metryki sprawy zgodnie z obowiązującymi
przepisami.
EZD musi umożliwić opisywanie spraw i akt sprawy metadanymi zgodnie z obowiązującymi przepisami.
EZD musi umożliwić odnotowanie wysyłki przesyłek wychodzących w rejestrze i opatrzenie ich
metadanymi zgodnie z przepisami.
EZD musi zapewnić przydzielanie spraw i korespondencji, przekazanych na dane stanowisko,
konkretnym użytkownikom, pracującym na tym stanowisku.
EZD musi umożliwić podgląd historii sprawy, ścieżki obiegu sprawy.
System musi być wyposażony w mechanizm informowania pracowników i przełożonych o zbliżającym
się terminie załatwienia sprawy. Sprawy bliskie przeterminowania oraz przeterminowane muszą być
specjalnie wyróżniane w Systemie.
System musi pozwalać na zawieszenie biegu terminu rozpatrywanie sprawy oraz jej kontynuacji, a także
zmianę terminu zakończenia sprawy przez uprawnionych pracowników.
EZD musi posiadać funkcjonalność obsługi kalendarzy. Każdy z użytkowników powinien posiadać
dostęp do własnego kalendarza z możliwością dodawania do niego dowolnych zdarzeń. Użytkownik
powinien mieć możliwość określenia typu zdarzenia oraz jego opisu. Użytkownik powinien mieć również
możliwość definiowania zdarzeń całodniowych i dłuższych oraz cyklicznych. System ma umożliwiać
przeglądanie kalendarzy podwładnych. Kalendarz musi umożliwiać dodawanie i edycję wpisów za
pomocą mechanizmu „przeciągnij i upuść”.
EZD musi umożliwiać zarządzanie zasobami poprzez ustalanie rezerwacji zasobów. System musi
umożliwić definiowanie dowolnych zasobów. Każdy zasób musi być powiązany ze „swoim” terminarzem,
w którym to uprawnieni użytkownicy mają wgląd. Ponadto tylko uprawnieni użytkownicy mogą
rezerwować zasoby, a jej fakt jest odnotowywany w terminarzu zasobu. Musi również istnieć możliwość
grupowania zasobów (np. grupa „pojazdy” zwierająca pojazdy, którymi dysponuje Zamawiający). Funkcja
rezerwacji musi posiadać mechanizm weryfikujący nakładające się terminy oraz proponujący najbliższy
wolny termin z dokładnością do 15 minut.
EZD musi posiadać funkcjonalność pozwalającą na zbiorcze podejrzenie dostępności rezerwowanych
zasobów i innych użytkowników. System musi umożliwiać rezerwację czasu innych użytkowników (jako
współuczestników zdarzenia).
EZD musi pozwalać każdemu użytkownikowi swobodnie decydować o tym kto i w jakim zakresie ma
dostęp do jego terminarza.
Każdy terminarz musi być możliwy do przeglądania w trybie dziennym, tygodniowym, miesięcznym.
69. EZD musi posiadać funkcjonalność planowania i raportowania spotkań, co najmniej w zakresie:
1) Opracowywanie agendy spotkania.
2) Zapraszanie uczestników.
3) Wyszukiwanie spotkań
4) Pisanie raportów ze spotkań na podstawie agendy (również przy jej braku).
5) Zakładanie kolejnych spraw/zleceń na podstawie protokołu za spotkania.
70. EZD musi posiadać funkcję umożliwiającą synchronizację terminarzy z Google Calendar.
71. EZD musi być wyposażony w funkcjonalność komunikatora tekstowego. Komunikator musi być
wewnętrznym oprogramowaniem dla urzędu i nie może umożliwiać komunikacji z zewnętrznymi
komunikatorami dostępnymi publicznie. Komunikator musi być wyposażony w system powiadomień
o istnych zdarzeniach systemowych co najmniej w zakresie:
1) powiadomienia o przekazaniu dokumentów,
2) powiadomienia o przekazaniu dokumentu do akceptacji,
3) powiadomienia o zaakceptowaniu dokumentu,
4) powiadomienia o dekretacji dokumentu.
72. EZD musi umożliwić użytkownikowi podgląd przypisanych do niego spraw i korespondencji,
z możliwością sortowania, filtrowania i przeszukiwania.
73. EZD musi umożliwiać podpisywanie dokumentów przy pomocy profilu zaufanego i kwalifikowanego
podpisu elektronicznego i znakowanie etykietami czasowymi.
74. EZD musi umożliwić wprowadzanie zmian kadrowych, urlopów i zastępstw. Umożliwia przekazanie
osobie zastępującej części lub całości uprawnień osoby zastępowanej. Uprawnienia muszą być
przekazane na określony czas dat lub bezterminowo.
75. EZD musi posiadać moduł urlopów umożliwiający co najmniej:
1) przypisywanie pracownikom dni urlopowych, naliczanie urlopu miesięczne lub roczne, przenoszenie
niewykorzystanych dni urlopowych na kolejny rok,
2) obsługę wniosków urlopowych umożliwiający złożenie wniosku przez pracownika oraz późniejszą
akceptację przez kierownika oraz ostateczne zatwierdzenie przez kadrową,
3) wyznaczanie zastępstw na podstawie udzielonych urlopów,
4) integracje funkcjonalności urlopów z kalendarzem systemowym co najmniej w zakresie widoku
planowanych urlopów uzależnionego od posiadanych uprawnień tj., pracownik widzi swoje urlopy,
kierownik widzi urlopy swoje jak i pracowników podległych, kadrowa widzi urlopy wszystkich
pracowników,
5) informowanie w momencie dekretacji o nieobecności pracownika, na którego dekretowany jest
dokument.
76. EZD musi umożliwiać definiowanie zastępstw na czas nieobecności polegających na udzieleniu
pełnomocnictwa innemu użytkownikowi do wykonywania czynności w imieniu użytkownika nieobecnego.
Pełnomocnictwo powinno być definiowane w określonym przedziale czasu. Dostęp do danych
nieobecnego użytkownika powinien być kontrolowany przez System i odbierany wraz z upłynięciem daty
końcowej. W trakcie trwania zastępstwa w systemie jest prezentowana informacja o zastępowaniu jednej
osoby przez drugą. Wszystkie operacje wykonywane w zastępstwie powinny być zapisane w sposób
umożliwiający jednoznaczne określenie, kto wykonał daną operację.
77. System EZD powinien wyróżniać wszystkie elementy, na których zastępca wykonał jakiekolwiek
operacje i zapisywać je w postaci rejestru, by zastępowany mógł je zidentyfikować po podjęciu pracy po
nieobecności.
78. EZD musi posiadać wewnętrzny edytor, służący do sporządzania notatek, załączanych do akt sprawy.
79. EZD musi posiadać interfejsy komunikacyjne z następującymi systemami:
1) GSKO – co najmniej w zakresie publikacji informacji o stanie spraw, przeglądania w GSKO
dokumentów zgromadzonych w sprawie oraz publikowania rejestrów definiowalnych,
2) Platformą usług publicznych ePUAP – w zakresie dwukierunkowej integracji z usługą Elektronicznej
Skrzynki Podawczej dostępną na ePUAP.
80. EZD musi umożliwić dokumentowanie wyjęcia dokumentacji ze składu chronologicznego lub ze składu
informatycznych nośników danych oraz wydrukowanie karty zastępczej dla wypożyczanego nośnika.
Procedura obsługi składów powinna być realizowana w następujący sposób: pracownik sprawdza
dostępność nośnika a następnie składa wniosek o wypożyczenie, osoba obsługująca skład akceptuje
wniosek i wypożycza nośnik, zwrot nośnika również jest potwierdzany przez osobę obsługującą skład.
81. System musi umożliwiać pełen wgląd do archiwum spraw, prowadzonych w systemie.
82. EZD musi zapewnić automatyczne przejmowanie dokumentacji przez archiwum zakładowe po upływie
okresu przewidzianego w instrukcji kancelaryjnej. Przejęcie dokumentacji musi polegać na przekazaniu
archiwiście uprawnień do tej dokumentacji w systemie EZD oraz ograniczeniu uprawień komórki
merytorycznej, zgodnie z instrukcją kancelaryjną.
83. EZD musi posiadać dedykowane funkcje do udostępniania i wycofywania dokumentacji elektronicznej
z archiwum zakładowego.
84. EZD musi umożliwiać wypożyczanie spraw z archiwum, podgląd informacji o sprawie oraz zmianę
kategorii archiwalnej sprawy przechowywanej w archiwum
85. EZD musi posiadać funkcje wspierające proces porządkowania dokumentacji w archiwum zakładowym
(wskazanie dokumentacji wymagającej uzupełnienia).
86. EZD musi realizować brakowanie akt elektronicznych oraz przekazanie akt do archiwum państwowego
oraz sporządzenie i przechowywanie odpowiedniej dokumentacji.
87. EZD musi wspierać pracę archiwisty poprzez automatyczne typowanie dokumentacji do brakowania lub
przekazania do archiwum państwowego (po upływie terminów związanych z danymi kategoriami
archiwalnymi).
88. EZD musi wspomagać użytkownika w przygotowywaniu paczki archiwalnej dla Archiwum Państwowego
poprzez przygotowywanie automatycznych spisów zdawczo-odbiorczych, wykazu akt, oraz zapisanie
spraw w strukturze wymaganej przez Archiwum Państwowe. Po skutecznym przekazaniu spraw do
Archiwum Państwowego System powinien automatycznie usunąć dane spraw na podstawie
potwierdzenia z Archiwum Państwowego.
89. EZD musi umożliwiać obsługę repozytorium dokumentów elektronicznych, w szczególności
wytworzonych w pakietach MS Office, OpenOffice i LibreOffice poprzez integrację z protokołem
WebDav.
90. EZD musi umożliwiać obsługę dokumentów MS Office, OpenOffice i LibreOffice poprzez protokół
WebDav, w sposób umożliwiający bezpośrednie ich zapisywanie na serwerze z poziomu aplikacji np. MS
Word (przycisk zapisz).
91. EZD musi umożliwiać integrację z pakietem MS Office, OpenOffice i LibreOffice co najmniej w zakresie:
1) musi istnieć możliwość edycji dokumentów wychodzących (pisma, arkusze) dołączanych przez
użytkowników do spraw bezpośrednio w pakiecie MS Office, OpenOffice i LibreOffice,
2) musi istnieć możliwość edycji szablonów z poziomu repozytorium szablonów bezpośrednio w MS
Office, OpenOffice i LibreOffice,
3) musi istnieć możliwość dodawania dokumentów do spraw za pośrednictwem pakietu MS Office,
OpenOffice i LibreOffice.
92. EZD musi umożliwiać sporządzenie pocztowej książki nadawczej dostosowanej do zróżnicowanych
wymagań występujących w różnych urzędach pocztowych (konfiguracja domyślna dla Jednostki
powinna być ustawiana przez administratora).
93. EZD musi posiadać wbudowany mechanizm powiadomień, informujący o istotnych zdarzeniach
związanych z jego aktywnością w systemie. Minimalny zbiór powiadomień powinien obejmować
informowanie o: zadekretowaniu dokumentu na pracownika, przekazaniu dokumentu do akceptacji,
akceptacji dokumentu, udostępnieniu dokumentu pracownikowi, odczytaniu udostępnionego dokumentu
przez innego użytkownika, przekroczenie terminu realizacji sprawy.
94. EZD musi posiadać mechanizm parafowania dokumentów oraz podpisywania ich profilem zaufanym
i kwalifikowanym podpisem elektronicznym. W przypadku dokumentów podpisanych – istnieje możliwość
weryfikacji złożonego podpisu.
95. EZD musi posiadać własne centrum certyfikacji, umożliwiające generowanie certyfikatów
niekwalifikowanych dla użytkowników systemów, które mogą być wykorzystywane do parafowania
dokumentów.
96. EZD musi posiadać mechanizm definiowania procesów biznesowych w oparciu o rodzaj dokumentu lub
kategorię RWA. Modelowanie odbywa się w graficznym narzędziu i nie wymaga znajomości technik
programistycznych. Umożliwia określenie zadań, warunków łącznych i rozłącznych, podprocesów oraz
zakończeń. Proces przed publikacją powinien wymagać poprawnej walidacji.
97. EZD musi posiadać wbudowany moduł Workflow umożliwiający co najmniej:
1) wersjonowanie ścieżek przepływu pracy,
2) definiowanie ścieżek przepływu pracy w oparciu o strukturę organizacyjną jednostki,
3) procedowanie i dekretację spraw oraz pism z wykorzystaniem mechanizmu procedowania według
definiowalnych ścieżek (mechanizm przepływu pracy - workflow) w pełni zgodnie z instrukcją
kancelaryjną,
4) wpinanie w istniejące ścieżki przepływu pracy zewnętrznych interfejsów integracyjnych (usług
sieciowych),
5) definiowanie tzw. mapper’ów umożliwiających modyfikowanie danych pomiędzy kolejnymi zadaniami
przepływu pracy,
6) łatwa integracja istniejącego procesu (definicji) z wyglądem formularzy (przypisanymi do
konkretnego zadania),
7) możliwość dynamicznej modyfikacji osób / grup przydzielonych do zadania bez potrzeby
redefiniowania całego procesu z wykorzystaniem zakładowych rejestrów nieobecności i zastępstw
8) możliwość wysyłania zdefiniowanych powiadomień mailowych w dowolnym momencie w procesie
98. EZD musi posiadać wbudowany edytor formularzy:
1) możliwość tekstowego redagowania i podglądu formularzy
2) możliwość powiązania formularzy z danymi procesu workflow oraz bazą użytkowników – np.
ograniczanie widoczności pól formularza
3) możliwość rozszerzania funkcjonalności formularzy (własne skrypty)
99. EZD musi zapewniać wersjonowanie dokumentów wraz z zaznaczaniem różnic pomiędzy kolejnymi
wersjami.
100. System musi posiadać mechanizm inteligentnego wyszukiwania pism i spraw po wielu kryteriach,
a także umożliwiać łączenie wielu kryteriów w jednym kroku wyszukiwania. Wyszukiwanie powinno
odbywać się w oparciu o podane poszukiwane wartości wybranych atrybutów.
5.4 Administracja systemu EZD i warunki techniczne
1. EZD musi umożliwić modelowanie wielopoziomowej struktury organizacyjnej instytucji, która umożliwi
przypisanie pracowników do odpowiednich stanowisk.
2. System musi być tak zaprojektowany, aby umożliwił definiowanie i modelowanie struktury organizacyjnej,
a w przypadku zmian organizacyjnych w Zakładzie, łatwo definiować te zmiany i aktualizować strukturę
w systemie EZD, z zachowaniem poprzednich struktur, a także powiązań między nimi.
3. EZD musi umożliwić definiowanie uprawnień do poszczególnych funkcji systemu oraz grupowanie
uprawnień w role w celu ułatwienia administracji systemem.
4. EZD musi umożliwiać delegowanie części lub całości posiadanych uprawnień.
5. System musi posiadać wyodrębniony moduł administracyjny. Dostęp do tego modułu mogą uzyskać
jedynie użytkownicy z odpowiednimi uprawnieniami.
6. System musi udostępniać administratorowi funkcję globalnego zablokowania dostępu użytkowników
do Systemu, np. na czas wykonywania czynności administracyjnych lub konserwacyjnych. Zablokowanie
systemu powinno zostać poprzedzone wysłaniem odpowiedniego komunikatu do aktualnie
zalogowanych użytkowników oraz ich automatyczne wylogowanie po upływie określonego czasu.
7. System musi umożliwiać wprowadzanie kont użytkowników o tymczasowej ważności, po której konto
to jest automatycznie blokowane przez system.
8. System musi umożliwiać przyspieszenie procesu dodawania użytkowników poprzez możliwość
tworzenia nowego użytkownika na podstawie użytkownika wcześniej zdefiniowanego w Systemie. W
takim wypadku, nowotworzony użytkownik musi posiadać takie same uprawnienia jak użytkownik
wzorcowy. Ponadto system musi pozwalać na import użytkownik poprzez ustandaryzowany plik CSV.
9. EZD musi posiadać rozbudowany rejestr zdarzeń rejestrujący akcje użytkowników na obiektach
systemowych, udane i nieudane próby logowania oraz typowe błędy aplikacji. Rejestr umożliwia również
wskazywanie kont nieużywanych przez użytkowników.
10. EZD umożliwi zarządzanie uprawnieniami w oparciu o grupy uprawnień i grupy zasobów, jakich dotyczą.
System uprawnień musi być zdolny do odzwierciedlenia uprawnień i odpowiedzialności poszczególnych
pracowników wynikający z Instrukcji Kancelaryjnych oraz struktury stanowisk.
11. Hasła w EZD muszą być przechowywane w systemie w formie zaszyfrowanej - nie może być możliwości
ich odtworzenia, lecz jedynie zresetowania. Po zresetowaniu hasła użytkownika przez administratora
system musi wymagać od użytkownika zdefiniowania nowego hasła przy pierwszym logowaniu.
12. System musi umożliwiać użytkownikom samodzielną zmianę hasła bez ingerencji administratora
systemu.
13. EZD musi umożliwiać swobodne definiowanie polityki uwierzytelniania i blokowania kont w oparciu o
następujące parametry:
1) Minimalna długość nazwy użytkownika i hasła
2) Ilość dużych liter, cyfr, znaków specjalnych w haśle,
3) Długość cyklu wymuszania zmiany hasła (w miesiącach),
4) Ilość nieudanych prób logowania, po których następuje blokada konta,
5) Czas blokady konta po przekroczeniu liczby nieudanych prób logowania
14. Zakres wartości w słownikach prowadzonych przez system powinien być konfigurowalny przez
administratora lub pochodzić z rejestrów centralnych (np. TERYT).
15. EZD musi posiadać Bazę Interesantów, musi istnieć możliwość scalania zdublowanych wpisów, Musi
istnieć możliwość aktualizacji oraz korekty wpisów.
16. Dostęp do Bazy Interesantów ma być również możliwy z GSKO.
17. EZD musi posiadać możliwość stworzenia listy „Moi Interesanci”.
18. EZD musi posiadać możliwość wprowadzania grup cech, które poszerzą standardowy formularz do
wprowadzania danych interesantów.
19. EZD musi umożliwiać odnotowywanie historii kontaktów z osobą lub firmą (notatka, spotkanie, list,
rozmowa telefoniczna).
20. EZD musi umożliwiać podgląd informacji o ilości spraw aktualnie prowadzonych dla osoby lub firmy.
21. Musi istnieć możliwość generowania raportów udostępnienia danych osobowych interesanta jak
również dokumentów interesanta, dokumentów wysłanych do interesanta, prowadzonych spraw
dotyczących interesanta.
22. EZD musi umożliwić nadawanie i ograniczanie uprawnień do danych osobowych interesantów – osób
fizycznych, zapewniając ochronę tych danych zgodnie z ustawą o ochronie danych osobowych (Dz.U. z
2004 r. nr 100, poz. 1024).
23. EZD musi rejestrować wszystkie czynności dostępu do usług i zasobów w systemie, w tym informacje o:
1) operacjach na dokumentach,
2) operacjach na danych osobowych,
3) zmianach haseł,
4) zdarzeniach uwierzytelniania (udane logowanie, wylogowanie, nieudane logowanie);
5) zdarzeniach autoryzacji (nieudane/udane operacje);
6) zdarzeniach administracyjnych.
24. Zapisywanie danych identyfikujących musi obejmować:
1) adres IP i nazwę maszyny, z której wykonano daną czynność;
2) identyfikator/nazwa użytkownika, który wykonał daną czynność;
3) czas wystąpienia.
25. System musi posiadać możliwość personalizacji ustawień dotyczących:
1) widoku i kolejności wyświetlania kolumn na listach spraw oraz dokumentów,
2) sortowania elementów w poszczególnych kolumnach,
3) konfiguracji terminarza w zakresie wyświetlanych godzin, w których można dodawać terminy oraz
skali czasookresu w jakim można dodawać terminy.
26. EZD musi posiadać mechanizm automatycznego backupu danych z możliwością określenia okresów
czasowych w jakich ma być wykonywany backup.
27. EZD musi posiadać mechanizm informujący użytkownika o wprowadzonych zmianach w aplikacji.
28. EZD musi umożliwiać integrację z systemem powiadomień SMS, w wyniku której po wykupieniu
odpowiedniego pakietu SMS, możliwe będzie przesyłanie automatycznych powiadomień o rejestracji
pisma, rozpoczęciu sprawy, oraz jej zakończeniu.
5.4 Narzędzia komunikacji
1.
2.
3.
4.
5.
6.
System musi dostarczać narzędzia komunikacji asynchronicznej pomiędzy użytkownikami portalu, np. w
formie wiadomości tekstowych.
System musi dostarczać narzędzia tekstowej komunikacji synchronicznej pomiędzy użytkownikami
portalu, np. w formie modułu czat.
System musi dostarczać mechanizmy komunikacji synchronicznej i asynchronicznej pomiędzy
użytkownikami systemu EZD oraz GSKO, umożliwiające np. odbywanie zdalnych konsultacji.
System musi posiada mechanizmy powiadomień dla użytkowników o nowo nadesłanych do nich
komunikatach.
System musi umożliwiać przeglądanie wszystkich rozmów archiwalnych, prowadzonych przez danego
użytkownika – zarówno w formie synchronicznej, jak i asynchronicznej.
System musi posiadać możliwość przypisywania rozmów tekstowych do konkretnych spraw.
6. Integracja systemu EZD firmy E-Studio Software Sp. J. z wdrażanym systemem GSKO
1.
2.
3.
4.
Zakres przedmiotu zamówienia obejmuje integrację posiadanego przez Urząd Gminy Grudziądz
Systemu Elektronicznego Obiegu Dokumentów firmy E-Studio Software Sp. J. z wdrażanym systemem
GSKO.
Firma E-Studio jest jedynym posiadaczem autorskich praw majątkowych oraz kodów źródłowych
Systemu Elektronicznego Obiegu Dokumentów. Licencja na system udzielona Gminie Grudziądz na
podstawie umowy z dnia 31 sierpnia 2011 r. przyznaje jej prawo do korzystania z oprogramowania na
następujących polach eksploatacji:
a) Instalacja programu na 1 serwerze sieciowym w sieci LAN Licencjonobiorcy (wersja produkcyjna)
oraz do jednej instalacji testowej (środowisko testowe) w sieci LAN Licencjonobiorcy;
b) Używania tj. wyświetlania (uruchamiania) i korzystania z programu na stacjach roboczych
w siedzibie Licencjonobiorcy;
c) Czasowego zwielokrotnienia programu komputerowego w celu sporządzania kopii bezpieczeństwa
programu;
d) Odtwarzania danych z kopii bezpieczeństwa programu w celu przywrócenia programu.
Zgodnie z oświadczeniem firmy E-Studio Software Sp. J. z siedzibą przy Al. Racławickich 8 lok. 22
w Lublinie wszelkie ingerencje w kod źródłowy programu tj. np. zmiana kodu, kompilowanie, zmiana
przeznaczenia programu, adaptowanie programu do innych celów wymaga pisemnego upoważnienia.
Zakres integracji obejmuje wymagania dotyczące integracji EZD i GSKO wskazane w punktach 4 i 5
(łącznie z podpunktami) niniejszego dokumentu.
7. Przygotowanie 25 formularzy wniosków na platformę e-PUAP
Zakres przedmiotu zamówienia obejmuje przygotowanie i wdrożenie na platformie e-PUAP dla pięciu
urzędów gmin następujących formularzy wniosków:
1. Podanie o wydanie odpisu (skróconego, zupełnego) z ksiąg stanu cywilnego;
2. Wniosek o wydanie dowodu osobistego;
3. Deklaracja o wysokości opłaty za gospodarowanie odpadami komunalnymi;
4. Oświadczenie o kompostowaniu bioodpadów;
5. Wniosek o usunięcie drzew i krzewów;
6. Wniosek o wydanie decyzji o warunkach zabudowy;
7. Wniosek o wydanie zaświadczenia o przeznaczeniu gruntów;
8. Wniosek o wypis i wyrys z miejscowego planu zagospodarowania przestrzennego i Studium;
9. Wniosek o wydanie decyzji ustalającej lokalizację inwestycji celu publicznego;
10. Wniosek o wydanie warunków technicznych przyłączenia obiektu budowlanego do zewnętrznej sieci
wodociągowej i/lub kanalizacji sanitarnej;
11. Wniosek o wydanie warunków technicznych montażu dodatkowego wodomierza;
12. Wniosek o zwrot podatku akcyzowego zawartego w cenie oleju napędowego;
13. Wniosek o wydanie zaświadczenia o niezaleganiu w podatkach lub stwierdzającego stan zaległości;
14. Informacja w sprawie podatku od nieruchomości – dla osób fizycznych;
15. Deklaracja na podatek od nieruchomości;
16. Deklaracja na podatek leśny;
17. Deklaracja na podatek rolny;
18. Wniosek o udzielenie ulgi z tytułu nabycia gruntów;
19. Wniosek o udzielenie ulgi inwestycyjnej;
20. Wniosek o umorzenie podatku lub odroczenie terminu spłaty;
21. Wniosek o wydanie decyzji o środowiskowych uwarunkowaniach na realizacje przedsięwzięcia;
22. Wniosek o dofinansowanie kosztów kształcenia młodocianych pracowników;
23. Wniosek o wydanie karty dużej rodziny;
24. Wniosek o wpisanie wyborcy do rejestru wyborców;
25. Deklaracja na podatek od środków transportowych.
8. Licencje
W ramach realizacji przedmiotu Projektu Wykonawca będzie zobowiązany do dostarczenia lub udzielania
(dotyczy produktów własnych Wykonawcy) licencji bezterminowych wymienionych w tabeli poniżej.
Tabela: Zestawienie wymaganych licencji oprogramowania
Nazwa produktu
Licencja Gminnego Systemu Komunikacji
Online
Licencja systemu Elektronicznego
Zarządzania Dokumentów
Liczba
5
3
Typ licencji
Licencja na urząd bez limitu użytkowników
Licencja na urząd na następującą liczbę
użytkowników:
 Urząd Gminy w Płużnicy: 24
 Urząd Gminy Wąbrzeźno: 31
 Urząd Miasta i Gminy Łasin: 32
1. Wymagania ogólne w zakresie licencji:
1) Licencjobiorcą jest Zamawiający;
2) Licencje muszą być udzielone na czas min. 15 lat;
3) Licencje muszą umożliwiać przeniesienie ich na partnerów projektu lub umożliwiać użytkowanie
produktów przez partnerów, czyli gminy.
4) Licencje muszą uwzględniać prawo do bezpłatnej instalacji udostępnianych przez producenta
uaktualnień i poprawek krytycznych i opcjonalnych, a także uaktualnień.
5) Wymagane jest zapewnienie możliwości korzystania z wcześniejszych wersji zamawianego
oprogramowania i korzystania z kopii zamiennych (możliwość kopiowania oprogramowania na wiele
urządzeń przy wykorzystaniu jednego standardowego obrazu uzyskanego z nośników dostępnych w
programach licencji grupowych), z prawem do wielokrotnego użycia jednego obrazu dysku w procesie
instalacji i tworzenia kopii zapasowych.
2. W zakresie wszystkich wymienionych klas Oprogramowania Zamawiający wymaga dostarczenia:
1) Pisemnych licencji na oprogramowanie;
2) Dokumentów pozwalających na stwierdzenie legalności zakupionego oprogramowania dla celów
inwentaryzacyjnych i audytowych;
3) Innych niezbędnych informacji, narzędzi, kluczy aktywacyjnych, instrukcji pozwalających na
przeprowadzenie przez Zamawiającego samodzielnie instalacji systemu.
3. Zamawiający dostarczy parametry techniczne niezbędne do konfiguracji sprzętu
i oprogramowania dedykowane dla każdego z partnerów projektu wynikające z lokalnej specyfiki sieci.
4. Sprzęt komputerowy będący przedmiotem zamówienia Wykonawca dostarczy i zainstaluje bezpośrednio
w siedzibie każdego z partnerów projektu.
9. Sprzęt komputerowy i urządzenia
9.1. Wymagania ilościowe
Tabela: Wymagania ilościowe dla produktu Urządzenia
Nazwa urządzenia
Serwer
Modernizacja serwera
Zasilacz awaryjny
Skaner w zestawie z czytnikiem kodów kreskowych
Szafa rakowa
Drukarka z duplexem
Zestawy komputerowe (komputer PC i monitor)
Ilość
3
1
4
3
1
3
12
9.2 Wymagania ogólne
1. Wdrożenie systemu EZD i GSKO wymaga dostarczenia, zainstalowania i skonfigurowania urządzeń
z oprogramowaniem.
2. W zakresie wszystkich wymienionych urządzeń Zamawiający wymaga:
1) Urządzenia muszą być fabrycznie nowe,
2) Urządzenia muszą posiadać co najmniej 5-letnią gwarancję,
3) Elementem dostawy i instalacji powinno być oprogramowanie niezbędne do utworzenia/zintegrowania
systemu GSKO i EZD o wymaganej funkcjonalności,
4) Wszystkie urządzenia będą wyposażone w niezbędne kable zasilające i połączeniowe,
5) Bezterminowych licencji na użytkowanie zamawianego oprogramowania.
6) Urządzenia muszą zostać skonfigurowane, dostarczone i zainstalowane w miejsca wskazane przez
Zamawiającego.
3. Wykaz sprzętu stanowi załącznik nr 3.
9.3 Instalacja sprzętu, oprogramowania i konfiguracja sprzętu
1. Wykonawca zamontuje wszystkie dostarczone do poszczególnych urzędów urządzenia, za pomocą
elementów montażowych i przewodów zapewnionych przez Wykonawcę.
2. Wykonawca podłączy serwery do sieci energetycznej i sieci logicznej w siedzibie Partnera. Partner
zobowiązany jest wskazać dokładne miejsce instalacji.
3. Wykonawca zainstaluje wszelkie niezbędne oprogramowanie do działania dostarczanych systemów.
10. Analiza przedwdrożeniowa
1. Przed przystąpieniem do wdrożeń Wykonawca przeprowadzi analizę przedwdrożeniową
w siedzibie każdego Partnera. Sposób wykonania analizy i termin Wykonawca uzgodni
z Zamawiającym.
2. Wykonawca musi w procesie analizy przedwdrożeniowej, uzyskać od Zamawiającego wszystkie
niezbędne informacje umożliwiające mu sprawne przeprowadzenie procesu wdrożenia
i parametryzacji systemu. Analiza przedwdrożeniowa musi zawierać wszystkie niezbędne informacje
umożliwiające ustalenie na spotkaniu przedwdrożeniowym z Partnerami całego procesu wdrożenia w ich
jednostce. Do tego celu Wykonawca oddeleguje odpowiedni zespół osób posiadający odpowiednie
kwalifikacje i doświadczenie w prowadzeniu wdrożeń w JST i znający specyfikę działalności JST.
3. Wykonawca zorganizuje w siedzibie Zamawiającego spotkanie przedwdrożeniowe, którego celem będzie
omówienie i ustalenie przebiegu wdrożenia z koordynatorami ze strony Zamawiającego.
4. W wyniku analizy przedwdrożeniowej powstanie między innymi:
1) Harmonogram wdrożenia,
2) Zasady współpracy,
3) Warunki techniczne i organizacyjne rozpoczęcia wdrożeń,
4) Listę zaleceń i czynności koniecznych do wykonania przez Partnerów przed wdrożeniem,
5. Wykonawca podpisze z Zamawiającym umowę o zachowaniu poufności oraz umowę regulującą zdalnym
dostępie do zainstalowanych systemów Partnerów projektu.
6. Ponadto analiza przedwdrożeniowa obejmie:
1) Analizę zakresu informacyjnego dostarczonych formularzy wniosków.
2) Określenie reguł walidacyjnych dla poszczególnych atrybutów formularzy wniosków.
3) Dostarczenie przez Zamawiającego wykazu opłat obowiązujących w sprawach, dla których w
ramach projektu zostaną przygotowane formularze wniosków elektronicznych.
11. Wdrożenie GSKO i EZD
1. Wykonawca oddeleguje do realizacji wdrożeń zespół oraz wyznaczy osobę odpowiedzialną
za przebieg wdrożenia - Kierownika Projektu Wykonawcy.
2. Planowanie i monitorowanie wdrożeń będzie realizowane z użyciem harmonogramu wdrożenia.
3. Wykonawca przygotuje i przedstawi szczegółowy harmonogram wdrożenia przedstawi go do akceptacji
Zamawiającemu.
4. Zamawiający może wnioskować o wprowadzenie zmian w harmonogramie.
5. Wykonawca i Zamawiające będą wspólnie dążyć do terminowej realizacji przedmiotu zamówienia.
6. Konfiguracja systemu odbędzie się zgodnie z metodyką przyjętą przez Wykonawcę i ustaloną
z Zamawiającym.
7. Wykonawca dokona implementacji projektu szaty graficznej zatwierdzonej przez Zamawiającego.
8. Wykonawca musi przeprowadzić wszelkie czynności prowadzące do uruchomienia w pełni
skonfigurowanego systemu, przygotowanego do jego użytkowania.
12. Odbiór systemów
1. Sprawdzenie przez Zamawiającego zainstalowanego Systemu pod względem jego zgodności z
wymaganiami SIWZ oraz jego poprawności działania, w tym jego poprawności działania w zakresie
wykonanych procesów integracyjnych.
2. Sprawdzenie przez Partnerów projektu poprawności wprowadzonych danych konfiguracyjnych dla
Partnera i Użytkowników końcowych oraz prawidłowości działania wykonanych formularzy wniosków
elektronicznych.
3. Sprawdzenie przez Zamawiającego poprawności wprowadzenia danych inicjalnych.
4. Po podpisaniu przez partnera protokołu odbioru w zakresie czynności wykonanych na jego rzecz,
dokumenty przesyłane są do Zamawiającego w celu podpisania ostatecznego protokołu odbioru.
5. Protokoły odbioru po stronie partnerów podpisywane są przez osoby upoważnione przez kierownika
danej jednostki.
6. Wykonawca zobowiązuje się do tworzenia modyfikacji systemu w szczególności jego integracji z innymi
systemami przez okres 15 lat od dnia odbioru systemu. Modyfikacje tworzone będą na podstawie
odrębnych zleceń.
13. Przeznaczenie Serwisu Powdrożeniowego
1. Przedstawione wymagania na produkt świadczenia Usługi Wsparcia Technicznego należy traktować,
jako minimalny standard wymagań związanych z zapewnieniem eksploatacji wdrożonych systemów w
wymaganej jakości.
2. Wsparcie techniczne zapewniać ma gwarantowaną pomoc w eksploatacji oprogramowania, sprzętu
komputerowego jak też innych urządzeń udzielaną użytkownikowi przez producenta, dostęp do
aktualizacji oraz poprawek oprogramowania. Szczegółowe warunki świadczenia usługi znajdują się w
Załączniku nr 3 do umowy „Warunki gwarancji".
3. System i usługa serwisu w okresie 5 lat od daty podpisania ostatniego protokołu odbioru:
1) Zapewnienie, żeby system był eksploatowany w zakresie wymaganej jakości,
2) Usunięcie wszystkich usterek, które ujawnią się w okresie eksploatacji,
3) Doraźne udzielanie pomocy w zakresie bieżącej obsługi systemów.
4. Zamawiający zapewni możliwość zgłaszania nieprawidłowości poprzez udostępnienie kontaktu
telefonicznego oraz adresu e-mailowego, na który użytkownik zgłaszać będzie nieprawidłowości
związane z eksploatacją systemów oraz inne zapytania. Obsługa zgłoszenia może polegać na udzieleniu
porady lub w przypadku błędu systemów na:
1) Dokonaniu doraźnych napraw przywracającej funkcjonowanie na zasadzie obejścia,
2) Analizy przyczyny błędu,
3) Usunięcie przyczyny błędu,
4) Usunięcie skutków błędu.
5. Usługa wsparcia technicznego musi byś świadczona przez okres (minimum 60 miesięcy) (słownie:
sześćdziesiąt miesięcy) liczony od dnia odebrania Przedmiotu Umowy na zasadach określonych w
Umowie.
14. Gwarancja
1. Wykonawca zobowiązany będzie świadczyć usługi serwisu gwarancyjnego w zakresie wdrożonego
Systemu od dnia zakończenia realizacji projektu, stwierdzonego obustronnym podpisaniem przez Strony
Protokołu Odbioru ostatniego Etapu prac, przez okres minimum 60 miesięcy (słownie: sześćdziesiąt
miesięcy). Wykonawca zobowiązuje się świadczyć usługi gwarancyjne w zakresie całości wdrożonego
systemu.
2. Jeżeli w okresie objętym gwarancją wyjdą na jaw wady wyłączające lub ograniczające przydatność
dostarczonego w ramach przedmiotowego zamówienia oprogramowania, Wykonawca dokona na swój
koszt naprawy gwarancyjnej przez usunięcie wad.
3. Serwis gwarancyjny świadczony będzie zdalnie lub w miejscu instalacji oprogramowania (u
Zamawiającego lub partnerów).
4. Wszelkie koszty naprawy, w tym koszt transportu, instalacji i ponownego uruchomienia Systemu ponosi
Wykonawca.
5. Wykonawca, po konsultacji z Zamawiającym, zaproponuje procedury obsługi awarii, uwzględniające
sposoby ich zgłaszania, usuwania oraz dokumentowania. Procedury obsługi będą podlegały akceptacji
ze strony Zamawiającego, a w szczególnym przypadku mogą być one przez niego określone.
6. W celu klasyfikacji rodzajów zgłoszeń wprowadza się następujące pojęcia:
­ Nieprawidłowość - stan Systemu, spowodowany wadami dostarczonego przez Wykonawcę
oprogramowania, w którym część Systemu wdrożonego przez Wykonawcę nie funkcjonuje zgodnie z
dokumentacją, mogący skutkować lub skutkujący ograniczeniem bądź brakiem realizacji dowolnej
funkcji Systemu;
▪ Kategoria nieprawidłowości A (sytuacja krytyczna) - wystąpił problem, którego skutki
spowodowały całkowite zatrzymanie Systemu
▪ Kategoria nieprawidłowości B - wystąpił problem, stwarzający istotne ograniczenie w działaniu
Systemu
▪ Kategoria nieprawidłowości C - oznacza działanie dostarczonego przez Wykonawcę
oprogramowania w sposób niezgodny z dostarczoną dokumentacją.
­ Rozwiązanie - zmiana wykonana, dostarczona lub zalecona w dostarczonym przez Wykonawcę
oprogramowaniu, której skutkiem jest eliminacja Nieprawidłowości poprzez przywrócenie Systemowi
funkcjonalności w pełni zgodnej z aktualną dokumentacją. W szczególności zmiana wykonana w
kodzie dostarczonego przez Wykonawcę oprogramowania, zmiana parametrów lub porada
usuwająca przyczyny zgłoszenia Problemu, skutkująca prawidłowym działaniem Systemu.
­ Obejście - tymczasowe Rozwiązanie Nieprawidłowości, nieeliminujące całkowicie przyczyny jego
powstania, ale zmniejszające Kategorię Nieprawidłowości.
7. Zgłoszenia problemów będą realizowane przez system helpdesk Wykonawcy lub telefonicznie
w godzinach pracy Zamawiającego.
8. Terminy realizacji usług:
1) Jeżeli Nieprawidłowość dotyczyć będzie części Systemu wytworzonej przez Wykonawcę,
obowiązywać będą następujące terminy realizacji usług:
Kategoria
Nieprawidłowości
Maksymalny
czas reakcji
A
B
C
6 godzin
1 dzień roboczy
1 dzień roboczy
Maksymalny czas
usunięcia
Nieprawidłowości
1 dzień roboczy
5 dni roboczych
10 dni roboczych
2) Jeżeli Nieprawidłowość dotyczyć będzie oprogramowania dostarczonego, ale nie wytworzonego
przez Wykonawcę, terminy realizacji usług będą za każdym razem ustalane z Zamawiającym.
15. Szkolenia GSKO, e-PUAP, EZD
1.
2.
3.
Wykonawca zobowiązany jest do przygotowania i przeprowadzenia 225 godzin szkoleń stacjonarnych
w formie ćwiczeń praktycznych na komputerach dla 61 osób.
Szkolenia skierowane są do pracowników:
 Urzędu Gminy w Płużnicy, 87-214 Płużnica;
 Urzędu Gminy Wąbrzeźno, ul. Mickiewicza 21, 87-200 Wąbrzeźno;
 Urzędu Gminy Unisław, ul. Parkowa 20, 86-260 Unisław,
 Urzędu Gminy Grudziądz, ul. Wybickiego 38, 86-300 Grudziądz
 Urzędu Miasta i Gminy Łasin, ul. Radzyńska 2, 86-320 Łasin.
Miejsce prowadzenia szkoleń: sale szkoleniowe wskazane przez wyżej wymienione Urzędy.
4.
Zajęcia będą odbywać się w czasie pracy w/w Urzędów, w dniach od poniedziałku do piątku dla
wyodrębnionych grup szkoleniowych. Harmonogram szkoleń zostanie ustalony z Wykonawcą po
podpisaniu umowy.
5. Zamawiający zapewni salę szkoleniową wyposażoną w stoły i krzesła.
6. Wykonawca zapewnia odpowiednią liczbę komputerów (jeden komputer na uczestnika) niezbędną do
prowadzenia zajęć, projektor multimedialny, ekran oraz flipchart.
7. Wymaga się, aby każdy uczestnik szkolenia dysponował w trakcie całego czasu szkolenia komputerem
wraz z urządzeniami peryferyjnymi, jakie zostały dostarczone przez Wykonawcę, a których będzie
używał na swoim stanowisku pracy. Komputer ten powinien umożliwiać dostęp do szkoleniowej instancji
GSKO i EZD.
8. Po ukończeniu szkoleń uczestnicy mają w szczególności:
1) umieć posługiwać się systemami GSKO, EZD i ePUAP odpowiednio do swojej roli,
2) znać i rozumieć różnice pomiędzy pracą bez systemu EZD, z systemem EZD w roli wspomagającej
system tradycyjny prowadzenia czynności kancelaryjnych oraz pracy w systemie EZD,
3) rozumieć, czym jest dokument elektroniczny i podpis elektroniczny, a także znać i rozumieć
procedury postępowania związane z dokumentem elektronicznym.
9. Szkolenie „Obsługa platformy e-PUAP I GSKO”:
 Uczestnicy: 61 osób (5 grup);
 Liczba godzin: 2 dni szkoleń x 7,5 godziny = 15 godzin dla każdej grupy;
 Łączna liczba godzin szkoleń stacjonarnych: 5 grup x 15 godzin = 75 godzin.
 Termin do 31.08.2015 r.
10. Szkolenie „Praca z Elektronicznym Obiegiem Dokumentów”:
 Uczestnicy: 36 osób (5 grup);
 Liczba godzin: 5 dni szkoleń x 6 godzin = 30 godzin dla każdej grupy;
 Łączna liczba godzin szkoleń stacjonarnych: 5 grup x 30 godzin = 150 godzin;
 Termin do 31.08.2015 r.
16. Konsultacje eksperckie dotyczące wdrożonych systemów informatycznych
1.
2.
3.
4.
5.
Konsultacje eksperckie będą świadczone w dni robocze od poniedziałku do piątku w godzinach 7.30 –
15.30 w urzędach gmin Partnerów lub zdalnie, na podstawie zleceń dokonanych przez poszczególnych
partnerów i zatwierdzonych przez koordynatora projektu „Internetowy urząd”.
Wykonawca zobowiązany będzie do prowadzenia i dostarczenia Zamawiającemu Kart Czasu Pracy
zrealizowanych godzin konsultacji eksperckich na koniec każdego miesiąca, jednak nie później niż do 5
dnia następnego miesiąca.
Liczba godzin: średnio 18 godzin x 5 gmin;
Łączna liczba godzin: 90 godzin;
Termin do 31.08.2015 r.
17. Zastrzeżenie równoważności rozwiązań
1.
2.
3.
W niniejszym dokumencie przedstawione są wymagania funkcjonalne dotyczące zamawianego
oprogramowania i usług. Z uwagi na to, że art. 30 ust. 5 ustawy prawo zamówień publicznych wyraźnie
wskazuje na Wykonawcę, jako tego, który jest zobowiązany wykazać, że rozwiązanie równoważne
spełniają wymagania postawione przez Zamawiającego, Zamawiający zastrzega sobie, w przypadku
jakichkolwiek wątpliwości, prawo sprawdzenia pełnej zgodności oferowanych produktów z wymogami
specyfikacji.
Sprawdzenie to, będzie polegać na przeprowadzeniu testów w warunkach produkcyjnych na sprzęcie
Zamawiającego, z użyciem urządzeń peryferyjnych Zamawiającego, na arkuszach, bazach danych
i plikach Zamawiającego.
Zamawiający może w każdym momencie realizacji projektu zażądać zaprezentowania wszystkich
funkcjonalności wymaganych w SIWZ i zaoferowanych w ofercie, w terminach wymagalnych
wynikających z przyjętego harmonogramu. Prezentacja i akceptacja funkcjonalności wersji systemu
będzie
wykonana
w
miejscu
wskazanym
przez
Zamawiającego.