Załącznik nr 1 do SIWZ Opis Przedmiotu Zamówienia na Wdrożenie
Transkrypt
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.