Załącznik nr 3 do SIWZ Załącznik nr 3 Opis Przedmiotu Zamówienia Projekt elektroniczna administracja (e-administracja) 1. Wstęp Niniejszy dokument stanowi załącznik nr 3 do SIWZ na zamówienie polegające na dostawę i wdrożenie elektronicznej administracji (e-administracja) wraz z dostawą licencji na oprogramowanie, szkoleniem, dostawą urządzeń oraz usługą wsparcia technicznego w ramach projektu Infostrada Kujaw i Pomorza usługi w zakresie e-administracji i Informacji Przestrzennej. Dokument opisuje przedmiot zamówienia wskazując produkty, które Wykonawca musi dostarczyć w ramach projektu. 2. Określenie Przedmiotu Zamówienia Przedmiotem zamówienia jest dostawa i wdrożenie elektronicznej administracji (dalej: e-administracja) wraz z dostawą licencji na oprogramowanie, szkoleniami, dostawą urządzeń oraz 1
usługą wsparcia technicznego u Partnerów projektu Infostrada Kujaw i Pomorza usługi w zakresie e-administracji i Informacji Przestrzennej. W celu potwierdzenia, że oferowane przez Oferenta oprogramowanie odpowiada wymaganiom Zamawiającego, Oferent obowiązkowo przedstawi w ofercie: wykaz platform systemowych i programistycznych, które zostaną wykorzystane przy realizacji zamówienia. 2.1. Produkt: Oprogramowanie e-administracja Opis wymaganego oprogramowania niezbędnego do budowy e-administracji, licencji niezbędnych do korzystania z oprogramowania, najważniejszych wymagań technicznych, funkcjonalnych, a także ilościowych. W ramach projektu realizowane będą następujące moduły: elektroniczny obieg dokumentów (EOD), wojewódzka platforma wymiany informacji wraz z elektroniczną skrzynką podawczą (e-urząd), portal regionalny (wrota regionalne CMS), regionalny biuletyn informacji publicznej (RBIP), regionalne centrum certyfikacji i autoryzacji (RCCiA), 2.2. Produkt: Urządzenia e-administracja Opis urządzeń potrzebnych do eksploatacji oprogramowania e-administracja, najważniejszych wymagań technicznych i funkcjonalnych, a także ilościowych. 2.3. Produkt: Wdrożenie e-administracja Opis wdrożenia wraz z instruktażem w zakresie użytkowania e-administracji na różnym poziomie, kryteria jakości i akceptacji. 2.4. Produkt: Szkolenia e-administracja Opis wymaganych szkoleń dla e-administracji, kryteriów jakości oraz kryteriów akceptacyjnych. 2.5. Produkt: Dokumentacja e-administracja Opis wymaganej dokumentacji technicznej dla e-administracji, kryteriów jakości oraz kryteriów akceptacyjnych. 2.6. Produkt: Usługa wparcia Technicznego Opis sposobu sprawowania obsługi utrzymaniowej systemów po zakończeniu projektu. 3. Oprogramowanie e-administracja 3.1. 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: 2
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). 3
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). 3.2. Liczba licencji 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 Liczba Typ licencji Licencja elektronicznego obiegu dokumentów dla urzędu Licencja na urząd bez limitu 115 (EOD) użytkowników Licencja na portal wojewódzka platforma wymiany informacji (e-urząd) 1 Bez limitu użytkowników Licencja na portale regionalny (CMS) 1 Bez limitu użytkowników Bez limitu użytkowników z możliwością tworzenia Licencja na Regionalny Biuletyn Informacji Publicznej 1 nielimitowanej ilości (RBIP) instancji dla Partnerów i ich jednostek podległych Zestaw umożliwiający złożenie podpisu elektronicznego weryfikowanego certyfikatem kwalifikowanym 482 Użytkownik Oprogramowanie PKI w ramach RCCiA 482 Użytkownik System zarządzania cyklem życia karty inteligentnej PKI w ramach RCCiA 1 Licencje serwerowe System operacyjny dla systemów na poziomie regionalnym 6 Licencje serwerowe Serwer relacyjnej bazy danych dla systemów na poziomie regionalnym 2 Licencje serwerowe 3.3. Wymagania ogólne Wymagania ogólne w zakresie licencji: a) Licencjobiorcą jest Zamawiający; b) Licencje muszą być udzielone na czas nieoznaczony; c) Licencje muszą umożliwiać przeniesienie ich na partnerów projektu lub umożliwiać użytkowanie produktów przez partnerów, czyli gminy i powiaty oraz ich jednostki podległe. d) Licencje muszą uwzględniać prawo do bezpłatnej instalacji udostępnianych przez producenta uaktualnień i poprawek krytycznych i opcjonalnych, a także uaktualnień e) 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. W zakresie wszystkich wymienionych klas Oprogramowania Zamawiający wymaga dostarczenia: 4
a) Po 1 szt. kompletu nośników z systemem EOD dla każdego Partnera Projektu; b) Po 1 szt. kompletu nośników oprogramowania PKI w ramach RCCiA oraz oprogramowania pozwalającego na składanie podpisu elektronicznego, weryfikację podpisu elektronicznego oraz zarządzanie kartą kryptograficzną dla każdego użytkownika, któremu wydano zestaw pozwalający na składanie podpisu elektronicznego z użyciem certyfikatu kwalifikowanego. c) Pisemnych licencji na oprogramowanie; d) Dokumentów pozwalających na stwierdzenie legalności zakupionego oprogramowania dla celów inwentaryzacyjnych i audytowych; e) Innych niezbędnych informacji, narzędzi, kluczy aktywacyjnych, instrukcji pozwalających na przeprowadzenie przez Zamawiającego samodzielnie instalacji systemu. 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. Sprzęt komputerowy będący przedmiotem zamówienia Wykonawca dostarczy bezpośrednio do siedziby każdego z 150 partnerów projektu określonych w Załączniku nr 6 do umowy będącej załącznikiem nr 6 do SIWZ. 3.4. Zastrzeżenie równoważności rozwiązań W dalszej części 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. 3.5. Elektroniczny obieg dokumentów (EOD) Zakres przedmiotu zamówienia obejmuje dostawę wraz z wdrożeniem Systemu Elektronicznego Obiegu Dokumentów na warunkach określonych w niniejszej Specyfikacji Istotnych Warunków Zamówienia. 3.5.1. Wymagania ogólne dla EOD System Elektronicznego Obiegu Dokumentów (EOD) ma pełnić istotną rolę w realizacji codziennych zadań pracowników Partnerów projektu. W EOD mają być gromadzone wszystkie pisma, które za pośrednictwem dokumentów elektronicznych oraz tradycyjnych kancelarii wpływają codziennie do urzędu. EOD ma wspierać proces rozpatrywania spraw zapewniając mechanizmy przekazywania dokumentów pomiędzy komórkami i pracownikami. W EOD 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ę. 5
System EOD musi umożliwiać wymianę elektronicznej korespondencji między osobami pracującymi w różnych lokalizacjach. System EOD musi umożliwiać wymianę korespondencji elektronicznej pomiędzy poszczególnymi jednostkami (Partnerami), w sposób spełniający wymagania prawa w tym zakresie. Wymiana powinna odbywać się z wykorzystaniem Elektronicznej Skrzynki Podawczej (ESP) oraz urządzenia do generowania Urzędowego Potwierdzenia Odbioru (HSM) w celu zapewnienia zgodności z prawem (w zakresie przepisów dotyczących doręczania i wysyłania dokumentów w sposób elektroniczny). System musi pozwalać na dzień składania ofert umożliwiać pracę zarówno w systemie EZD jak i w systemie tradycyjnym, o których mowa w Rozporządzeniu Prezesa Rady Ministrów z dnia 18 stycznia 2011r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych. 3.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 lub nowszej oraz Firefox 10 lub nowszej) 3. System musi mieć możliwość pracy, co najmniej pod kontrolą systemów opartych na technologii MS Windows 2000 lub wyższych oraz Linux w zakresie serwera bazy danych i serwera aplikacyjnego. 4. System w warstwie klienckiej realizuje wszystkie czynności przez przeglądarkę internetową i umożliwia poprawną pracę w systemach MS Windows XP i nowszych oraz w systemach z rodziny Linux. 5. System musi pracować w oparciu o relacyjną bazę danych. Ze względu na możliwość dalszego rozwoju oraz planowany przyrost danych System musi umożliwiać pracę z wykorzystaniem zarówno komercyjnej np. Oracle, jak i darmowej bazy danych np. Postgresql. a. Zaproponowany motor bazy danych obsługuje: b. Kontrolę spójności referencyjnej danych c. Wbudowane języki proceduralne d. Rozbudowane indeksy e. Klucze obce f. Sekwencje g. Kursory h. Widoki i. Definiowane typy 6. Migracja danych pomiędzy bazami danych (komercyjna -> darmowa oraz darmowa-> komercyjna) nie może powodować utraty żadnej części danych. Migracja danych pomiędzy wskazanymi dwoma rodzajami baz danych nie jest przedmiotem niniejszego zamówienia. 7. Ze względu na bezpieczeństwo danych, wszystkie dane przetwarzane przez System muszą być przechowywane w bazie danych i chronione przez mechanizmy zabezpieczeń silnika bazy danych. Przechowywanie danych związanych ze sprawą poza bazą danych dopuszczalne jest jedynie po zakończeniu procesu archiwizacji danej sprawy oraz w stosunku do plików. W przypadku przechowywania plików poza bazą danych, jego repozytorium jest ściśle powiązane z danymi zawartymi w bazie danych poprzez odpowiednie wskazania na pliki oraz 6
co najmniej zabezpieczone poprzez obliczanie sumy kontrolnej z zawartości każdego pliku i przechowywanie jej w bazie danych wraz z mechanizmem każdorazowego sprawdzania zawartości pliku na wypadek podmiany jego zawartości. 8. 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. Sposób obsługi mechanizmu musi być szczegółowo opisany w Dokumentacji Użytkowej dla administratorów. 9. System musi posiadać interfejsy komunikacyjne w postaci metod WebServices. 10. Interfejsy komunikacyjne Systemu muszą być zgodne ze standardami SOAP, WSDL i XML oraz wykorzystywać zabezpieczony protokół HTTPS szyfrowany zgodnie ze standardem SSL. Zakup certyfikatów na okres dwóch lat w jednym z autoryzowanych przez popularne przeglądarki internetowe centrów certyfikacji leży po stronie Wykonawcy. 3.5.3. Zarządzanie systemem i danymi 1. System musi posiadać wyodrębniony moduł administracyjny. Dostęp do tego modułu mogą uzyskać jedynie użytkownicy z odpowiednimi uprawnieniami. 2. System musi obsługiwać logowanie na podstawie identyfikatora i hasła. System musi być wyposażony w mechanizm wymuszenia zmiany hasła, co określony okres, sprawdzania czy nowowprowadzane hasło nie jest jednym z wcześniej wprowadzonych oraz sterowaniem poziomem skomplikowania hasła. System musi sprawdzać złożoność hasła zgodnie z wymaganiami ustawy o ochronie danych osobowych. Ponadto musi być możliwe włączenie dla dowolnego użytkownika logowania za pomocą certyfikatu. Certyfikatem logowania może być zarówno certyfikat kwalifikowany jak i niekwalifikowany, a także pochodzący z RCCiA. Certyfikaty te mogą być przechowywane zarówno na kartach kryptograficznych jak i w magazynie Windows. 3. System musi zapamiętywać profile pracy poszczególnych użytkowników i udostępniać je po zalogowaniu na dowolnej stacji roboczej. Dostęp do modułu administracyjnego musi być zdefiniowany przynajmniej w postaci dwóch ról administracji globalnej oraz administracji lokalnej. Użytkownik posiadający uprawnienia do administracji globalnej będzie mógł zmieniać wszystkie parametry Systemu. Administrator z uprawnieniami lokalnymi musi posiadać możliwość modyfikacji tylko parametrów dotyczących komórek struktury organizacyjnej, dla których ma przypisane uprawnienie administratora. 4. Moduł administracyjny musi umożliwiać zarządzanie słownikami Systemowymi, w zakresie dodawania, usuwania oraz modyfikacji wpisów w słownikach. 5. System musi uniemożliwić usuwanie oraz edycję wpisów/ustawień/konfiguracji niezbędnych do jego prawidłowego działania lub wynikających z obowiązujących przepisów prawa. 6. W przypadku usuwania wpisów ze słownika, nie może zostać naruszona integralność bazy danych. Usuwanie wpisów słownika powinno być logiczne (poprzez ustawienie odpowiedniej flagi). Dopuszcza się usuwanie fizyczne pozycji słownikowych jedynie w przypadku, gdy dana pozycja słownika nie została jeszcze wykorzystana w Systemie przez użytkowników. 7. System musi udostępniać przynajmniej następujące słowniki: a. słownik rodzajów spraw (RWA), b. słownik rodzajów pism, c. słownik kategorii archiwalnych, d. słownik typów dekretacji, 7
e. słownik związany z danymi adresowymi słownik miast, gmin, powiatów, województw oparty do słownik TERYT publikowany przez Główny Urząd Statystyczny, f. słownik kodów pocztowych powiązany jednoznacznie ze słownikiem TERYT, g. słownik użytkowników, h. słownik struktury organizacyjnej (komórek organizacyjnych), i. słownik stanowisk ściśle powiązany ze słownikiem struktury organizacyjnej, j. słownik sposobów wysyłki/rodzajów przesyłek wychodzących, k. centralny słownik interesantów ściśle powiązany z słownikami danych adresowych oraz kodów pocztowych, l. słownik poleceń dekretacyjnych centralny oraz indywidualny dla każdego użytkownika, m. słownik atrybutów dla spraw, system musi pozwalać na oznaczenie sprawy statusem prywatnym, powodujących brak widoczności sprawy przez innych użytkowników, n. w pełni zarządzany cennik przesyłek wychodzących ściśle powiązany ze słownikiem sposobów wysyłek dokumentów, o. słownik gońców, ściśle powiązany ze słownikiem sposobów wysyłek dokumentów, p. słownik relacji dla spraw i dokumentów, pozycje słownika muszą wyróżniać kierunek ustanowienia relacji. 8. System musi na bazie odpowiednich danych adresowych (po wybraniu miejscowości, ulicy i nr domu) automatycznie określić przyporządkowany kod pocztowy oraz pocztę. Słownik musi posiadać funkcjonalność pozwalającą administratorowi na rozszerzanie jego zakresu, a ponadto w ramach aktualizacji systemu Wykonawca będzie dostarczał zaktualizowane wartości słowników. 9. System musi umożliwiać wiązanie rodzajów pism z rodzajami spraw (i odwrotnie) w celu zwiększenia ergonomii pracy użytkowników, poprzez inteligentne ograniczanie listy rodzajów udostępnianych użytkownikowi w kontekście wybranych wcześniej danych (np. ograniczenie listy rodzajów pism w kontekście rodzaju sprawy, w której tworzone jest pismo) 10. System musi umożliwiać tworzenie dowolnej liczby relacji wyróżniających kierunek wiązania np. dokument jest kopią innego dokument ma kopię. 11. System musi posiadać wbudowane bądź zintegrowane narzędzia do optycznego rozpoznawania tekstu OCR. Rozpoznawanie odbywa się w sposób zautomatyzowany (dla każdego dokumentu dołączanego będącego obrazem) bądź na żądanie użytkownika zależnie od decyzji administratora systemu. 12. 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. 13. System musi umożliwiać wyznaczania czasów dla każdego z kolejnych kroków w procesie realizującym sprawę. Ponadto system musi zapewniać pełną ewidencję czasów planowanych w procesie dla każdej sprawy oraz ewidencję rzeczywistego czasu realizacji sprawy oraz jej poszczególnych kroków. 14. System musi umożliwiać definiowanie rodzajów pism przychodzących i wychodzących. 15. System musi umożliwiać tworzenie szablonów pism wychodzących. Powinna istnieć możliwość tworzenia szablonów w formacie RTF oraz za pomocą niezależnego od aplikacji zewnętrznych wbudowanego edytora szablonów. W szablonie pisma powinna być możliwość zdefiniowania 8
znaczników/zmiennych, które będą automatycznie zamieniane na wartości znajdujące się w Systemie podczas generowanie pisma z szablonu. Wymagalny zakres znaczników to: a. Dane nadawcy, b. Dane adresata (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 sterowanie zawartością dokumentu, w tym znacznik nowej strony. 16. System musi pozwalać tak skonfigurować każdy szablon dokumentu, przed zapisaniem w systemie dokumentu wygenerowanego na podstawie szablonu, użytkownik mógł w pełni modyfikować treść dokumentu. 17. System musi pozwalać na wykorzystywanie szablonów poza sprawami. 18. System musi posiadać możliwość współpracy z edytorem Microsoft Office w wersji 2003 lub nowszej w zakresie podglądu oraz tworzenia pism wychodzących. 19. Dla każdego rodzaju sprawy System musi umożliwiać definiowanie dowolnych statusów powiązanych ze stanem sprawy. Przesyłanie informacji o stanie i statusie danej sprawy jest przedmiotem integracji systemu z wojewódzka platformą wymiany informacji (e-urząd). 20. System musi umożliwiać definiowanie i przechowywanie informacji o powiązaniu formularzy elektronicznych z poszczególnymi rodzajami spraw, oraz przechowywanie informacji o komórkach organizacyjnych, do których może trafić dany rodzaj formularza. 21. System musi umożliwiać rozpoczęcie pracy w ciągu roku, z zachowaniem kontynuacji dotychczasowej numeracji pism, spraw, spisów zdawczo-odbiorczych oraz numerów kancelaryjnych, poprzez możliwość zdefiniowania wartości początkowych przez administratora Systemu. 22. System musi umożliwiać zdefiniowanie formatu znaku teczki, sprawy, pisma oraz rejestru, wyłącznie z elementów dopuszczalnych przez Instrukcję Kancelaryjną. 23. System musi umożliwiać definiowanie słownika Rzeczowego Wykazu Akt z określeniem granicznych dat jego obowiązywania oddzielnie dla każdego hasła klasyfikacyjnego. System musi umożliwiać również przeglądanie RWA obowiązującego w dowolnym dniu w przeszłości. 24. System musi umożliwiać definiowanie dowolnej ilości rejestrów dodatkowych. Rejestry muszą umożliwiać gromadzenie pism lub spraw danego rodzaju wg konfiguracji dokonanej przez administratora dla każdego z nich. 25. System musi umożliwiać tworzenie rejestrów ręcznych oraz automatycznych. W przypadku rejestrów ręcznych, użytkownik sam będzie wskazywał dokumenty, które muszą trafić do rejestru. Zawartość rejestrów automatycznych powinna być kontrolowana i aktualizowana przez System. Każdy rejestr może być automatycznie zasilany danymi wg zaprojektowanego układu danych dla określonych dokumentów lub spraw. Układ danych w rejestrze może obejmować 9
dowolne elementy metryk (atrybutów) spraw i dokumentów, a ponadto system musi pozwalać na wskazanie przez administratora kolumn rejestru uzupełnianych ręcznie przez użytkownika. 26. Każdy rejestr musi być skojarzony z określonymi procesami. System musi uniemożliwiać (także w przypadku ręcznego dodawania wpisu do rejestru) powiązywania wpisu z procesem, który nie został wskazany w konfiguracji rejestru. System musi uniemożliwiać ponadto dodawanie wielokrotne wpisów dotyczących tego samego obiektu w systemie (dokumentu lub sprawy). 27. System musi pozwalać na wskazanie administratorowi kolumny rejestru przekazywane i publikowane w BIP. 28. System musi umożliwiać tworzenie raportów z podaniem zakresu dat dokumentów, które się w nim znajdą. W przypadku tworzenia raportów z datami przeszłymi System musi umożliwić automatyczne uzupełnienie raportu odpowiednimi dokumentami. 29. 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. 30. System musi umożliwiać definiowanie struktury organizacyjnej, zgodnej ze schematem organizacyjnym Zamawiającego lub Partnera. Struktura organizacyjna może składać się z dowolnej liczby komórek i stanowisk w komórkach z zachowaniem i prezentacji podległości służbowych. Do każdej z komórek może zostać przypisana dowolna liczba stanowisk, a do stanowiska, co najmniej 1 użytkownik. 31. System zawiera hierarchiczną ewidencję struktury organizacyjnej urzędu, zawierającą w szczególności: a. jako główny element struktury urząd (Partner, Zamawiający), b. informację o podległościach poszczególnych komórek organizacyjnych i stanowisk, c. informację o pracownikach przypisanych do poszczególnych komórek organizacyjnych i stanowisk, d. nazwę oraz symbol komórki wykorzystywany do generowania znaku sprawy, e. nazwę, typ oraz symbol stanowiska, w tym co najmniej informację o szefie komórki organizacyjnej, f. informację o uprawnieniach i konfigurację poszczególnych stanowisk, g. informację o danych adresowych poszczególnych elementów struktury i samego urzędu. 32. System musi umożliwiać przeniesienie wszystkich pism i spraw znajdujących się w danej komórce na inną komórkę, a także z jednego stanowiska na inne stanowisko. 33. System musi umożliwić zdefiniowanie dowolnej liczby kancelarii tj. stanowisk obsługujących pisma przychodzące i wychodzące z urzędu. Tworzenie kancelarii nie jest w żaden sposób uzależnione od struktury organizacyjnej tzn. stanowisko kancelaryjne tworzy się tylko i wyłącznie poprzez przypisanie odpowiednich uprawnień i w każdym momencie możliwe jest przydzielenie takich uprawnień dowolnemu stanowisku ze struktury całego urzędu. 34. System musi umożliwiać zarządzanie użytkownikami, poprzez tworzenie, usuwanie, blokowanie oraz przypisywanie użytkowników do wielu stanowisk, w tym stanowisk w różnych komórkach organizacyjnych. W przypadku przypisania użytkownika do wielu stanowisk w tym samym czasie, po zalogowaniu się w systemie musi mieć on możliwość dowolnego przełączania się pomiędzy przypisanymi mu stanowiskami bez konieczności ponownej autoryzacji w systemie. 10
35. System musi umożliwiać sprawne i szybkie dokonywanie zmian w strukturze organizacyjnej co najmniej w zakresie następujących zmian: a. Zmiany podległości komórek i stanowisk, b. Podziału komórek na nowe komórki organizacyjne, c. Łączenie komórek/stanowisk w jedną komórkę organizacyjną. 36. System musi zapamiętywać pełną historię zmian w strukturze organizacyjnej i umożliwiać zaprezentowanie struktury organizacyjnej na dowolny moment historyczny tj. zapewniać możliwość wyświetlenia struktury organizacyjnej ważnej w dowolnym dniu. 37. System umożliwia prezentację zmian związanych z danym elementem struktury organizacyjnej, w tym minimum historię przydzielanych użytkowników, historię przydzielanych uprawnień. 38. Użytkownik może pełnić w systemie różne role, wynikające z uprawnień przypisanych różnym stanowiskom i ich umiejscowieniu w strukturze organizacyjnej przypisanych do użytkownika. Nie dopuszcza się jednoczesnego dziedziczenia uprawnień przez użytkownika ze wszystkich zajmowanych stanowisk. Podczas pracy użytkownika na danym stanowisku, ten korzysta z uprawnień i ustawień przypisanych wyłącznie do danego stanowiska, natomiast po rozpoczęciu pracy na innym przypisanym stanowisku, użytkownik traci uprawnienia wynikające z pierwszego stanowiska a zyskuje wynikające z drugiego stanowiska. Uprawnienia i ustawienia wynikające z przydziału użytkownika do różnych stanowisk nie mogą się łączyć. 39. System musi posiadać możliwość tworzenia nieformalnych elementów struktury organizacyjnej, nie wynikających z obowiązującej struktury organizacyjnej Zamawiającego lub Partnera. 40. System musi posiadać mechanizm hurtowego wprowadzania wielu stanowisk na bazie (z użyciem konfiguracji) jednego wzorcowego stanowiska. 41. System musi pozwalać na tworzenie dowolnej liczby grup uprawnień ról, składających się z uprawnień jednostkowych. 42. System musi umożliwiać przypisywanie użytkownikom ról oraz uprawnień do teczek RWA (minimum w zakresie wyszukiwania i rejestrowania spraw) i rejestrów. 43. System musi umożliwiać definiowanie grup użytkowników oraz przypisywanie im uprawnień. Uprawnienia przypisane grupie użytkowników (komórce) muszą być dziedziczone przez użytkowników należących do danej grupy. 44. System musi umożliwiać wprowadzanie kont użytkowników o tymczasowej ważności, po której konto to jest automatycznie blokowane przez system. 45. W celu ułatwienia zarządzania System musi umożliwiać szybkie wyszukiwanie użytkowników i komórek w strukturze organizacyjnej poprzez zawężanie listy dostępnych rekordów w miarę wpisywania kolejnych znaków imienia, nazwiska użytkownika lub nazwy komórki. System musi również umożliwiać ograniczenie listy wyświetlanych danych do listy samych komórek lub samych użytkowników. 46. 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 pliku CSV. 47. System musi pozwalać na ewidencjonowanie oraz śledzenie w każdym momencie liczby dni urlopu pozostałego do wykorzystania przez pracownika systemu. 48. System musi umożliwiać przypisanie każdemu użytkownikowi jego adresu email wraz z możliwością zdefiniowania szczegółowych parametrów do wysyłania/odbierania maili z jego 11
konta. W celu ułatwienia administracji, w przypadku, gdy wszyscy użytkownicy korzystają z tego samego serwera poczty, powinna istnieć możliwość globalnego zdefiniowania parametrów serwera pocztowego. 49. System 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 ustawione z dokładnością do minimum godziny. Dostęp do danych nieobecnego użytkownika musi 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ą np. na liście stanowisk, do których dekretowane jest pismo prezentowana jest informacja w postaci Jan Kowalski zastępuje Kazimierza Malinowskiego. System musi posiadać funkcjonalność logowania zmian wykonanych podczas zastępstwa. Powinna istnieć możliwość przeglądania zmian wprowadzonych przez osobę zastępującą z dokładnością do edytowanych przez nią pól, oraz wartości poprzedniej oraz wprowadzonej. Osoba zastępowana nie powinna móc zalogować się w systemie. 50. System musi umożliwiać definiowanie zastępstw stałych, z których korzystanie wynika z posiadanych przez użytkownika kompetencji. Tzn. w każdej komórce organizacyjnej uprawniona osoba może wyznaczyć możliwość pełnienia zastępstwa dowolnej osoby przez drugą w każdym momencie bez ustanawiania zastępstwa na określony czas. Zastępstwo jest uruchamiane przez zastępującego w dowolnym momencie, jeśli zachodzi taka konieczność (np. w przypadku nieoczekiwanej krótkotrwałej nieobecności). Ponadto w systemie musi być możliwość zdefiniowania wielu zastępujących dla jednej osoby oraz udzielenie tego rodzaju uprawnienia na dowolny czas, w tym czas nieograniczony. Wszystkie akcje wykonane w zastępstwie są odpowiednio logowane z informacją o wykonaniu ich podczas zastępstwa. Dla każdego rodzaju pisma i sprawy System musi umożliwiać definiowanie dowolnych dodatkowych atrybutów zgodnie z potrzebami użytkowników metrykę obiektu. System musi umożliwiać tworzenie atrybutów, z co najmniej następujących typów pól: a. Pole tekstowe, b. Data i czas, c. pole wyboru (checkbox), d. obszarów tekstowych, e. pola wielokrotnego wyboru, f. lista rozwijalna, g. lista słownikowa lokalna (słownik tworzony tylko na poziomie danej metryki) oraz globalna (wykorzystująca słownik systemowy), h. adres URL, i. Słowniki epuap. 51. Dla każdego atrybutu administrator musi móc przypisać etykietę tekstową, określić jego obligatoryjność, położenie, kolejność prezentacji, wartość domyślną, określić regułę walidacji dla wprowadzanych danych oraz typ przechowywanych danych (co najmniej data, tekst, liczba). Ponadto system musi zapewnić wersjonowanie definicji metryk. 52. System musi umożliwiać eksport i import definicji metryki obiektu (zestawu atrybutów) do pliku np. XML, tak aby istniała możliwość przenoszenia ich pomiędzy instancjami systemu. 53. System musi umożliwiać definiowanie szablonów pism wychodzących w postaci formularzy elektronicznych udostępnianych użytkownikom Systemu. Formularz elektroniczny musi być 12
tworzony za pomocą odpowiedniego kreatora, prowadzącego administratora przez proces tworzenia zakresu funkcjonalnego, struktury formularza oraz wizualizacji jego postaci wynikowej. Administrator musi mieć możliwość definiowania dowolnych struktur danych, wykorzystania dostępnych w systemie struktur oraz definiowania stałych bloków tekstu. Pola formularza muszą być wypełniane przez użytkowników lub automatycznie przez System na podstawie danych przechowywanych w bazie danych. 54. Formularze elektroniczne w strukturze XML muszą pozwalać na wygenerowanie dokumentu elektronicznego. Edytor musi pozwalać minimum na: tworzenie wzorów, import/eksport wzorów do i z pliku XML, definiowanie pól słownikowych (w tym z wykorzystaniem słowników systemu epuap), zamieszczanie dowolnych elementów tekstowo-graficznych oraz treści pomocy kontekstowej w ramach wzoru dokumentu, definiowanie reguł walidacji pól wzoru dokumentu, tworzenie list rozwijanych, pól wielokrotnego wyboru etc. 55. System musi automatycznie logować wszystkie wykonywane przez użytkowników operacje. W szczególności System musi logować zdarzenia typu otwarcie dokumentu/sprawy, podgląd załącznika, edycja dokumentu itp. W zakresie działań administracyjnych System musi logować wszystkie zdarzenia w szczególności modyfikację pozycji słowników z zachowaniem początkowej i końcowej wartości. System nie może umożliwiać edycji zawartości logów. 56. System musi umożliwić podgląd logów w danym okresie w kontekście użytkownika (np. wszystkie operacje wykonywane przez użytkownika X w okresie od do ) oraz w kontekście obiektu pisma lub sprawy (np. wszystkie operacje wykonane na piśmie o numerze kancelaryjnym XYZ w okresie od do ). System musi umożliwiać wydruk logów w postaci raportu. 57. System musi umożliwiać cechowanie spraw atrybutem prywatna, który to powoduje, że nie jest ona dostępny żadnemu innego użytkownikowi. 58. System musi umożliwiać korzystanie z definicji procesów WorkFlow. Administrator musi posiadać możliwość wiązania definicji procesu z rodzajem sprawy. 59. System w centralnym słowniku interesantów musi wyróżniać minimum osoby fizyczne, prawne/instytucje oraz jednostki samorządu terytorialnego współpracujące w ramach platformy e-urząd, do których to można za pomocą e-urząd kierować pisma w postaci elektronicznej. 60. Dane interesanta muszą być opisane, co najmniej przez: imię, nazwisko, nazwę, nazwę skróconą, ulicę, nr budynku, nr lokalu, kod pocztowy, pocztę, miejscowość, adres do korespondencji, dane kontaktowe, identyfikator interesanta w skrzynce podawczej (min. epuap oraz e-urząd, za wyjątkiem sytuacji, w której wykonawca do celów przesyłania pism w postaci elektronicznej nie wymaga przechowywania identyfikatorów), pole uwag, a także identyfikatory słownika TERYT. Dane interesantów muszą być zapisywane w postaci pozwalającej na automatyczne ich wykorzystanie jako metadane w strukturze XML. 61. Ewidencja interesantów urzędu zawiera ponadto: a. możliwość określenia więcej niż jednego adresu z zaznaczeniem, który jest adresem korespondencyjnym, b. możliwość określenia osoby reprezentującej klienta (imię, nazwisko, stanowisko, dział, telefony, faksy, e-mail), c. możliwość określenia oddziałów (jednostek podległych) interesanta, d. informację o chęci/żądaniu otrzymywania korespondencji drogą elektroniczną, e. System musi umożliwiać rozszerzenie listy atrybutów opisujących interesanta przez administratora. 13
62. Na żądanie interesanta System musi umożliwiać wygenerowanie raportu z jego danymi osobowymi oraz w razie potrzeby modyfikację danych osobowych przechowywanych w systemie. Raport musi odpowiadać wymaganiom wytycznych GIODO w tym zakresie. Ponadto system musi umożliwiać odnotowania sprzeciwu wobec przetwarzania danych osobowych w celach innych niż wynikających z przepisów prawa (na podstawie, których dane są przetwarzane), a jeśli taki sprzeciw nie został wyrażony ewidencjonować przekazywanie/udostępniania tych danych. 63. Modyfikacja danych każdego interesanta (nie tylko osób fizycznych) musi być możliwa w dwojaki sposób: korekta danych w przypadku, gdy dane są wpisane niepoprawnie oraz aktualizacja danych w przypadku zmiany danych interesanta np. w związku ze zmianą adresu. 64. System musi pozwalać na odnajdywanie danych dotyczących tego samego interesanta i jeśli jest taka konieczność scalania ich w jeden właściwy wpis. 65. System musi umożliwiać odnalezienie wszystkich obiektów w systemie powiązanych z dowolnym interesantem. 66. System umożliwia eksport danych interesantów do pliku CSV, XLS, PDF. 67. System musi pozwalać na wprowadzanie wyciągów z JRWA dla każdej komórki organizacyjnej oraz dla każdego stanowiska. Stanowiska muszą dziedziczyć wyciągi z JRWA przypisane komórkom, do których należą. System pozwala na założenie znaku sprawy tylko z użyciem hasła klasyfikacyjnego wynikającego z wyciągu z JRWA. 68. System musi posiadać wbudowane narzędzie do tworzenia predefiniowanych raportów w trybie WYSIWYG. Musi istnieć możliwość udostępniania możliwości generowania określonych szablonów raportów przez uprawnionych do tego użytkowników. Ponadto system musi posiadać możliwość automatycznego generowania raportów cyklicznie, co zaplanowany okres czasu i zapisywania ich trwale w systemie. 69. Szablon raportu musi pozwalać na stworzenie dowolnego wykazu spraw i dokumentów przetwarzanych przez system. Narzędzie musi pozwalać na dowolne sterowanie zawartością i układem informacyjnym wykazu obiektów, określania zasad grupowania danych oraz sumowania wartości liczbowych, a także zawierać zdefiniowane parametry możliwe do dookreślenia przez użytkownika wykonującego raport np. określającego przedział dat. 70. Parametry i dane raportu możliwe do zdefiniowania musza obejmować, co najmniej: a. Dane z metryk spraw i dokumentów, b. Dane dotyczące czasów rozpatrywania spraw, c. Statusy spraw, d. Dane pracowników prowadzących sprawę, e. Dane dotyczące procesów za pomocą, których procedowane sprawy, f. Zawężenie spraw wg struktury organizacyjnej, czyli dla dowolnej komórki organizacyjnej, 71. System musi umożliwiać eksport danych raportu do formatów XLS, DOC, PDF. 72. System musi udostępniać szczegółowe informacje statystyczne dotyczące rozpatrywania spraw, uwzględniające w szczególności czas rozpatrywania spraw, wykorzystywane procesy, 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. 73. System musi pozwalać na eksport danych statystycznych do pliku bądź przedstawić je w formie graficznej. 74. System musi pozwalać na tworzenie wzorów wydruków. System pozwala na dowolne tworzenie nieograniczonej liczby wydruków do wykorzystania w różnych miejscach w systemie. W 14
przypadku istnienia dla danego typu wydruku (np. etykieta z kodem kreskowym) większej liczby dostępnych wydruków system umożliwia użytkownikowi wskazanie jednego z nich. 75. Konfigurowalne wzory dostępne są co najmniej dla następujących obiektów (w dowolnej liczbie wzorów): a. Przesyłki przychodzące wstępna rejestracja (co najmniej: etykieta z kodem kreskowym oraz identyfikatorem, potwierdzenie wpływu przesyłki, pokwitowanie przekazania dokumentu), b. Przesyłki przychodzące pełna rejestracja (co najmniej: etykieta z kodem kreskowym oraz identyfikatorem, potwierdzenie wpływu przesyłki, pokwitowanie przekazania dokumentu), c. Przesyłki wychodzące (co najmniej: nalepka adresowa na kopertę, koperta, zwrotne potwierdzenie odbioru), d. Sprawy, e. Pozycje rejestrów (obiekty zarejestrowane), f. Pozycje dzienników korespondencyjnych (obiekty w dzienniku korespondencyjnym), g. Poszczególne etapy procesu, h. Pozycje słownika interesantów (interesanci) 76. Dla każdego wydruku system pozwala na określenie nazwy, wymiarów, marginesów, zawartości wydruku z użyciem danych dostępnych w systemie (dane analogiczne dla w szablonach pism) tworzonej w edytorze WYSIWYG. 77. System musi pozwalać administratorowi na zdecydowanie o tym czy przed skierowaniem go do wydruku może on być modyfikowalny. 78. System zapewnia monitorowanie dostępu do zasobów poprzez rejestrowania czynności wykonywanych w logach systemu. System musi rejestrować wykonane czynności z jednoznacznym wskazaniem obiektu w systemie, którego ta czynność dotyczy, adresem IP komputera, nazwą użytkownika oraz czasem operacji. 3.5.4. Obsługa kancelaryjna 1. System musi umożliwiać rejestrację pism wpływających do urzędu. Użytkownik musi mieć możliwość podania takich atrybutów pisma jak: temat pisma, znak nadany przez instytucję zewnętrzną, znak nadany przez operatora pocztowego, daty wpływu, liczba załączników, szczegółowe dane nadawcy pisma. System musi pozwalać na klasyfikację korespondencji zgodnie z właściwością. W celu uniknięcia nadużyć System musi automatycznie zapisywać datę rejestracji pisma na podstawie daty systemowej bez możliwości modyfikacji. W przypadku pism pochodzących z formularzy elektronicznych pobranych z elektronicznej skrzynki podawczej data rejestracji powinna być tworzona na podstawie daty pobranej z dokumentu Urzędowego Potwierdzenia Odbioru (UPO) lub Urzędowego Potwierdzenia Przedłożenia (UPP). 2. System pozwala na rejestrowanie pism przychodzących niezależnie od kanału wpływu, w tym minimum przesłane/doręczone w formie papierowej, przesłane pocztą elektroniczną, faksem, przesłane na skrytkę epuap bądź na e-urząd, a także doręczone na nośniku elektronicznym, automatyczne urządzenie przyjmowania dokumentów. 3. System umożliwia rejestrację korespondencji złożonej w postaci papierowej do kancelarii urzędu oraz przetworzenie jej do postaci wtórnego dokumentu elektronicznego (odwzorowania cyfrowego). 4. System umożliwia rejestrację dokumentów elektronicznych złożonych na nośnikach elektronicznych do kancelarii urzędu, zgodnie z wymaganiami Instrukcji kancelaryjnej 15
5. System umożliwia automatyczne rozpoznawanie tekstu (OCR) zeskanowanych dokumentów (zależnie od konfiguracji) wraz z dołączeniem w systemie wyniku przetwarzania w momencie skanowania lub na żądanie operatora. 6. System musi posiadać narzędzie pozwalające na dowolne zarządzanie liczbą i zakresem danych formularza rejestracyjnego pisma przychodzącego składającego się minimum z: pól tekstowych, obszarów tekstowych, list rozwijalnych, pól daty itd. 7. System musi umożliwiać stworzenie dowolnej liczby formularzy rejestracyjnych dla pism różnego rodzaju. 8. System musi posiadać mechanizm zapamiętywania zapisanych wartości formularza pozwalający na szybkie wprowadzenie informacji dla kolejnego pisma np. tego samego nadawcy. 9. 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. 10. System musi pozwalać na ocechowanie danych każdego interesanta kodami TERYT. 11. System musi udostępniać mechanizm pozwalający na weryfikację podpisu elektronicznego w przypadku złożenia pisma w postaci elektronicznej, niezależnie od tego czy pismo jest składane poprzez epuap, e-urząd czy też doręczone na nośniku elektronicznym. 12. System musi pozwalać na zarejestrowanie znaku sprawy, której pismo dotyczy, skutkujące automatycznym wskazaniem przez system właściwej teczki sprawy. 13. System musi umożliwiać wydruk listy dokumentów z rejestru pism wychodzących. Wydruk musi przewidywać kolumnę przeznaczoną na miejsce pozwalające na złożenie podpisu potwierdzającego przejęcie dokumentu. Zestawienie jak i wydruk można generować za dowolny okres czasu, oddzielnie dla każdej komórki organizacyjnej do której pismo przekazano, zarejestrowane przez konkretnego użytkownika. 14. System musi wspomagać obsługę dokumentów typu zwrotne potwierdzenie odbioru oraz zwrot (przesyłka niedoręczona), które po zarejestrowaniu trafiają przynajmniej do pracownika prowadzącego sprawę. System musi pozwolić na taką konfigurację która po okresie wdrożenia pozwoli na bezpośrednio dołączanie zwrotek oraz zwrotów bezpośrednio do dokumentu w teczce sprawy. 15. System musi umożliwiać rejestrację i obsługę pism wewnętrznych. 16. System musi umożliwić szybką rejestrację pism polegającą na podaniu tylko podstawowych danych (adresat, liczba załączników) zakończoną automatycznym nadaniem numeru kancelaryjnego i możliwością dokonania wydruku etykiety z kodem kreskowym i/lub potwierdzenia złożenia pisma w urzędzie. System musi pozwolić na wykonanie pozostałych czynności związanych z rejestracją pisma w późniejszym czasie lub przez innego użytkownika. System musi wspomagać rejestrowania korespondencji przychodzącej w trybie EZD, tzn. pozwalać na skanowanie dokumentu opatrzonego kodem kreskowym wygenerowanym przez system. 17. System musi przetwarzać metadane co najmniej w zakresie, o którym mowa w załączniku nr 1 do instrukcji kancelaryjnej dla przesyłek wpływających, przesyłek wychodzących, elementów akt sprawy. 18. System umożliwia znakowanie każdego pisma unikalnym kodem kreskowym wygenerowanym przez system podczas rejestracji. Kod kreskowy musi być generowany przez system w momencie rejestracji. Procedura rejestracji musi umożliwiać naniesienie kodu kreskowego na odwzorowanie cyfrowe, bez konieczności edycji odwzorowania cyfrowego. 16
19. System musi pozwalać na dodawanie załączników do pism. Załączniki muszą być dodawane w formie plików pobieranych z systemu plików stacji roboczej, bezpośrednio ze skanera, bądź bezpośrednio z wiadomości email. 20. System musi umożliwiać opisanie każdego załącznika nazwą. W przypadku plików z pobieranych z systemu plików System musi automatycznie zaproponować nazwę wynikającą z nazwy pliku. 21. System musi umożliwiać dodawanie załączników w postaci skanów dokumentów. Obsługa procesu skanowania nie może powodować konieczności uruchamiania żadnych dodatkowych aplikacji. Moduł do skanowania musi być integralną częścią Systemu. 22. Moduł do skanowania musi umożliwiać wykonywanie przynajmniej następujących czynności: a. Wykorzystanie jako domyślnych parametrów skanowania zdefiniowanych przez administratora w szablonach skanowania, z możliwością zmiany każdego z parametrów określonego w szablonie. Liczba i rodzaj szablonów skanowania ma być zgodna z tabelą z załącznika nr 2 do Instrukcji kancelaryjnej. b. Określanie rozdzielczości skanu. c. Określanie trybu kolorów (kolor, czarno-biały, skala szarości) oraz głębi kolorów d. Określanie typu pliku wynikowego, oraz stopnia/algorytmu kompresji. e. Obracania zeskanowanego obrazu. f. Zaznaczanie dowolnego obszaru podlegającemu zapisowi po zaskanowaniu (eliminacja pustych części stron). g. Dowolne sortowanie stron po zeskanowaniu. h. Wstawianie między zeskanowanego strony dowolnego obrazka w tym także z dysku (np. w przypadku uprzedniego zeskanowania poza systemem). 23. System musi pozwalać na automatycznie usuwanie stron, które uznane są za puste. System musi pozwalać na ustawienie minimalnego stopnia zaczernienia strony jak nie jest uznawana za pustą nie zawierającą treści. 24. System musi pozwalać na tworzenie dowolnej liczby profili skanowania, czyli predefiniowanych, nazwanych zestawów parametrów skanowania przydatnych dla określonych rodzajów dokumentów. 25. System musi obsługiwać skanery z automatycznym podajnikiem oraz automatycznym duplexem. System musi wspomagać skanowanie dwustronne i wielostronicowe przy wykorzystaniu skanerów nie posiadających takich funkcji, aby jak najbardziej wspomóc użytkownika. 26. System umożliwia w momencie rejestracji przesyłki przychodzącej oraz kierowania do wysyłki przesyłki wychodzącej, jednoczesne zarejestrowanie jej w wielu różnych rejestrach, wskazanych przez użytkownika z listy dostępnych. 27. System umożliwia powiązywanie z przesyłkami przychodzącymi odpowiednich interesantów (klientów) ze słownika interesantów w dowolnej liczbie na etapie wypełniania formularza opisującego przesyłkę przychodzącą. 28. System umożliwia konfigurację i obsługę składów chronologicznych przesyłek przychodzących z możliwością odnotowania stopnia odwzorowania przesyłek papierowych. 29. System umożliwia konfigurację i obsługę składów nośników informatycznych, z możliwością odnotowywania stopnia wprowadzenia przesyłek w formie elektronicznej. 30. System umożliwia jednoczesną konfigurację i obsługę wielu składów chronologicznych i składów nośników informatycznych. 31. Funkcjonalność składów chronologicznych i nośników informatycznych umożliwia odnotowywanie wypożyczeń i zwrotów dokumentacji ze składów (z określeniem kto, kiedy, 17
komu i co wypożyczył ze składu), co pozwala na tworzenie historii obiegu natywnych form przesyłek, a także wygenerowanie odpowiedniego wydruku karty zastępczej zawierającego co najmniej w/w dane. 32. System umożliwia wygenerowanie listy przesyłek, dla których stopień odwzorowania pism papierowych oraz stopień wprowadzenia przesyłek w formie elektronicznej jest niepełny lub go brak. 33. System umożliwia rejestrację przesyłek, jako dokumentacji nie tworzącej akt sprawy zarówno już na etapie kancelarii, jak i u pracownika merytorycznego w wydziale. 34. Rejestracja przesyłek jako dokumentacji nie tworzącej akt sprawy ma co najmniej: a. Wymuszać lub proponować przyporządkowanie przesyłki do symbolu JRWA. b. Wymuszać lub proponować przyporządkowanie przesyłki do kategorii archiwalnej (zgodnej z symbolem JRWA). c. Pozwalać na umieszczenie dodatkowego opisu tekstowego w stosunku do każdej przesyłki. d. Nadawać przesyłce unikalne w obrębie całego systemu oznaczenie dokumentacji nie tworzącej akt sprawy, zawierające w sobie wskazanie dotyczące: rocznika rejestracji przesyłki, przyporządkowanego symbolu JRWA, symbolu komórki organizacyjnej w której zarejestrowano przesyłkę. 35. System umożliwia wyszukiwanie przesyłki stanowiące dokumentację nie tworzącą akt sprawy co najmniej wg wyżej opisanych oznaczeń i opisów tekstowych. 36. Sposób rejestracji przesyłek przychodzących umożliwia użytkownikowi rejestrującemu przesyłkę naniesienie na rejestrowaną przesyłkę identyfikatora przesyłki w systemie (wygenerowanego automatycznie przez system) wraz z odpowiednim kodem kreskowym, przed wykonaniem odwzorowania cyfrowego przesyłki. Zakłada się, że wytworzenie i dołączenie odwzorowania cyfrowego przesyłki do formularza opisującego przesyłkę zostanie wykonane na etapie rejestracji przesyłki przychodzącej. 37. System musi obsługiwać rejestrację spraw z wykorzystywaniem Jednolitego Rzeczowego Wykazu Akt zgodna z Instrukcją Kancelaryjną. 38. System musi pozwalać na rejestrację sprawy na podstawie pisma. Ponadto musi pozwalać na dołączanie i odłączanie pism od sprawy. 39. System musi automatycznie podpowiadać rodzaj sprawy na podstawie określonego rodzaju pisma oraz udostępniać funkcję automatycznego założenia sprawy na żądanie użytkownika 40. System musi umożliwiać tworzenie spraw bez konieczności wskazania pisma wiodącego. 41. System musi umożliwiać kopiowanie pism. System musi udostępniać pełną informację na temat liczby egzemplarzy każdego pisma i miejscem przechowywania każdej kopii z poziomu każdego z nich. 42. System musi pozwalać na anulowanie pism. System musi również umożliwiać oznaczanie pism swobodnych jako załatwione bez konieczności rejestracji sprawy. Możliwość obsługi pism swobodnych powinna być konfigurowalna z możliwością wyłączenia jej przez administratora systemu. 43. System pozwala na dołączanie jako dokumenty pliki z dysku oraz wygenerowane/stworzone w ramach systemu. 44. System w stosunku do każdego dokumentu musi pozwalać na jego wersjonowanie. W ramach wersjonowania dokumentów system pozwala na przeglądanie poprzednich wersji dokumentu oraz rejestruje pełną historię ich zmiany z możliwością przywrócenia przez uprawnionych użytkowników wersji uprzednich. 18
45. System musi umożliwiać tworzenie korespondencji seryjnej z użyciem szablonów w przypadku tworzenia dokumentów o tej samej treści (za wyjątkiem adresata) adresowanych do wielu odbiorców. Sposób generowania korespondencji seryjnej nie może blokować możliwości edycji wykorzystanego przez użytkownika szablonu korespondencji do momentu zatwierdzenia jego treści. 46. System musi posiadać wbudowany edytor tekstu, z funkcjonalnością WYSIWYG. Edytor ten musi pozwalać na sprawdzenie poprawności pisowni polskiej. 47. System musi umożliwiać wprowadzanie dokumentów o statusie robocze/tymczasowe, które nie są widoczne dla innych osób przeglądających sprawę. W dowolnym momencie właściciel sprawy może zmienić status dokumentu na widoczny bądź przeprowadzić go przez ścieżkę akceptacji. 48. System musi posiadać wbudowany mechanizm akceptacji oraz zatwierdzania dokumentów. Ścieżka akceptacji może być wieloetapowa każdy akceptujący musi mieć możliwość skierowania dokumentu do dalszej akceptacji. Akceptacja musi być możliwa do wykonania w sposób hurtowy (tj. wiele dokumentów jednocześnie, w tym także w różnych sprawach) a ponadto system musi umożliwiać akceptację dokumentu poprzez złożenie podpisu elektronicznego pod nim. 49. System musi umożliwiać dołączanie do sprawy oraz wysyłanie dokumentów w postaci dokumentów elektronicznych utworzonych na podstawie wzorów opublikowanych w CRD. 50. System w stosunku do każdej sprawy umożliwia wydruk tzw. metryki sprawy, której mowa w art. 171a Ordynacji podatkowej oraz art. 66a Kodeksu postępowania administracyjnego. 51. System musi pozwalać na wprowadzenie dowolnej dodatkowej treści dotyczącej podejmowanej czynności w sprawie w sytuacji, gdy czynność ta nie ma swojego odzwierciedlenia w systemie. 52. System musi obsługiwać (wysyłanie i przyjmowanie) korespondencji pocztą elektroniczną i za pomocą faksu w oparciu o protokoły SMTP i POP3. System umożliwia również obsługę poczty elektronicznej w oparciu o protokół IMAP. System musi umożliwiać obsługę dowolnej liczby kont e-mail 53. System musi automatycznie ustawiać stan sprawy na podstawie akcji wykonywanych przez użytkownika. Dla każdego ze stanów sprawy, administrator może określić dowolną liczbę statusów, które mogą zostać wybrane przez użytkownika. System musi posiadać interfejsy umożliwiające eksport informacji o stanach i statusach spraw do wojewódzkiej platformy wymiany informacji (e-urząd). System musi być również wyposażony w możliwość eksportu informacji o stanach i statusach spraw do BIP. 54. System musi pozwalać na dekretację pism i spraw w oparciu o strukturę organizacyjną. System musi umożliwiać dekretowanie do rozpatrzenia, wskazanie komórki/stanowiska współpracującego lub przekazywanie pisma do wiadomości. 55. W trakcie dekretacji system musi umożliwić użytkownikowi dodanie opisu lub wybranie sposobu dekretacji ze zdefiniowanego słownika. System musi pozwalać na hurtowe dekretowanie dowolnej liczby korespondencji. 56. System musi pozwalać na jednoczesną dekretację na dowolną liczbę stanowisk, do dowolnej liczby komórek (z możliwością uwzględnienia komórek podrzędnych), a także przekazanie kopii pisma w przypadku wątpliwości do innej osoby w komórce posiadającej uprawnienie do dekretacji. 57. System musi przewidywać wyznaczenie co najmniej 1 stanowiska w każdej komórce spełniającego rolę sekretariatu komórki przyjmującego wszelkie kierowane do tejże pisma. 19
58. 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, indywidualnego polecenia dla każdego adresata, a także wyznaczenia czasu wykonania każdego z poleceń dekretacyjnych. System ponadto pozwala na określenie priorytetu dla sprawy oraz dla każdego polecenia oddzielnie. 59. System pozwala na wskazanie dowolnej liczby adresatów merytorycznych dekretacji (dla których system winien przekazać kopię pisma) oraz dla każdej pary adresat merytoryczny-kopia pisma, dowolnej liczby komórek organizacyjnych/stanowisk współpracujących w danej sprawie, którym to system winien przekazać tylko udostępnienie sprawy bez możliwości założenia oddzielnej sprawy. 60. System musi pozwalać na potwierdzanie dekretacji podpisem elektronicznym. 61. System musi umożliwiać hurtowe dekretowanie dowolnie wybranego zestawu dokumentów oczekujących na zadekretowanie. 62. System musi wspomagać określanie polecenia dekretacyjnego z wykorzystaniem słownika centralnego poleceń dekretacyjnych oraz indywidualnego stworzonego do potrzeb własnych użytkownika. 63. 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. 64. 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. 65. System musi umożliwiać pracę grupową polegającą na możliwości wglądu do danej sprawy przez wielu użytkowników i dołączania przez nich dowolnych pism. Użytkownik będący inicjatorem pracy w grupie musi mieć możliwość w dowolnym momencie zebrania efektów dotychczasowych prac i odebrania pozostałym użytkownikom dostępu do sprawy. 66. Każda zmiana treści pisma przez kolejnych użytkowników powinna powodować utworzenie nowej wersji treści. System musi umożliwiać tworzenie nowych wersji, przeglądanie wersji poprzednich oraz w razie potrzeby oznaczenie dowolnej z wersji treści jako wersji aktualnej. 67. System musi umożliwiać prowadzanie pełnych akt sprawy w postaci elektronicznej lub odnotowywanie informacji o dokumentach nie przetworzonych na postać elektroniczną. 68. System musi pozwalać na dowolne wiązanie spraw i dokumentów poprzez wiązanie ich relacjami. Z poziomu każdego dokumentu system musi udostępniać informację o istniejących powiązaniach dokumentu/sprawy. 69. System musi umożliwiać udostępnianie pism/spraw do wiadomości innym użytkownikom. Właściciel sprawy może zdecydować o zakresie udostępnienia oraz o akcjach możliwych do wykonania w sprawie, którą udostępnił. 70. Dane opisujące sprawę (metryka) muszą zawierać co najmniej atrybuty o których mowa w Instrukcji kancelaryjnej. 71. System musi wyróżniać co najmniej sprawy: bieżące, nierozpoczęte, zakończone, zamknięte, wstrzymane, wznowione, do wiadomości. 72. System musi umożliwiać użytkownikom dostęp do zawartości spraw i grup spraw, do których mają nadane uprawnienia. 20