OPIS PRZEDMIOTU ZAMÓWIENIA ESZD Kraków, dn: 04.08.2014 Spis treści 1. Definicje. 3 2. Przedmiotem zamówienia jest dostawa ESZD. 3 3. Sposób realizacji wszelkich czynności ESZD 3 4. ESZD musi spełniać następujące warunki.. 3 4.1 Architektura ESZD. 3 4.2 Zasada działania ESZD. 4 4.2.1 Użytkownicy 4 4.2.2 Struktura organizacyjna.. 4 4.2.3 Uprawnienia.. 5 4.2.4 Procesy.. 5 4.3 Konfiguracja i administracja ESZD.. 5 4.3.1 Struktura organizacyjna.. 5 4.3.2 Użytkownicy 6 4.3.3 Szablony wydruków i dokumentów.. 6 4.3.4 Raporty.. 7 4.3.5 Rejestry.. 8 4.3.6 Słowniki ESZD. 8 4.3.6.1 Słowniki adresowe 8 4.3.6.2 Słownik JRWA.. 8 4.3.6.3 Słowniki systemowe 8 4.3.6.4 Słownik relacji.. 9 4.3.6.5 Słownik dekretacji. 9 4.3.6.6 Słownik sposobów dostarczenia. 9 4.3.7 Uprawnienia 9 4.3.8 Procesy 10 4.3.9 Skanery 10 4.3.10 Dokumentacja 10 4.3.11 Personalizacja. 11 4.3.12 Dziennik zdarzeń aplikacji (logi). 11 4.4 Funkcjonalności ESZD.. 12 4.4.1 Zarządzanie dokumentacją gromadzoną i przetwarzaną przez ZIKiT.. 12 4.4.1.1 Gromadzenie dokumentacji 12 4.4.1.2 Przesyłki przychodzące 13 4.4.1.3 Przekazywanie dokumentacji. 15 4.4.1.4 Przesyłki wychodzące.. 17 4.4.1.5 Powiązanie z zadaniami budżetowymi. 18 4.4.2 Zarządzanie sprawami prowadzonymi w ZIKiT. 18 4.4.2.1 Zakładanie spraw. 19 4.4.2.2 Prowadzenie spraw 19 1
4.4.2.3 Wystawianie dokumentacji. 20 4.4.2.4 Kierowanie dokumentacji do wysyłki.. 20 4.4.3 Obsługa rejestrów.. 21 4.4.4 Generacja statystyk i raportów.. 21 4.4.5 Baza interesantów 22 4.4.6 Współzależności i współpraca użytkowników.. 23 4.4.7 Narzędzia pomocnicze.. 24 4.4.8 Zewnętrzne udostępnianie statusu sprawy (umożliwienie podglądu spraw dla petentów).. 28 4.4.9 Pozostałe 29 4.5 Zarządzanie finansami jednostki.. 29 4.5.1 Wstęp (wymagania w zakresie zadań budżetu) 29 4.5.2 Planowanie budżetu. 30 4.5.3 Realizacja budżetu. 31 4.5.4 Rejestry i słowniki budżetowe 33 5. Gwarancja i asysta techniczna 34 5.1 Warunki gwarancji dla systemu ESZD. 34 5.2 Asysta techniczna i opieka serwisowa 35 2
1. Definicje: 1.1. ZIKiT Zarząd Infrastruktury Komunalnej i Transportu w Krakowie. 1.2. ESZD Elektroniczny System Zarządzania Dokumentacją. 1.3. ESP Elektroniczna skrzynka podawcza ZIKiT obsługiwana przez serwis epuap. 2. Przedmiotem zamówienia jest dostawa ESZD, zgodnego z poniższym opisem. 3. Sposób realizacji wszelkich czynności w ESZD musi być zgodny z obowiązującymi przepisami prawa, w szczególności: 3.1. Ustawa z dnia 14 lipca 1983r. o narodowym zasobie archiwalnym i archiwach wraz z aktami wykonawczymi, w tym Instrukcją kancelaryjną dla JST oraz JRWA ZIKiT. 3.2. Ustawa o finansach publicznych wraz z aktami wykonawczymi. 3.3. Ustawa z dnia 14 czerwca 1960 r. Kodeks postępowania administracyjnego wraz z aktami wykonawczymi. 3.4. Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne wraz z aktami wykonawczymi. 3.5. Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym wraz z aktami wykonawczymi. 3.6. Ustawa z dnia 29 sierpnia 1997 r o ochronie danych osobowych wraz z aktami wykonawczymi. 4. ESZD musi spełniać następujące warunki: 4.1. Architektura ESZD. ESZD musi być aplikacją internetową typu klient-serwer przeznaczoną do jednoczesnego wykorzystywania przez wielu użytkowników, o strukturze opartej na modelu trójwarstwowym, tj. warstw: interfejsu użytkownika (prezentacji), aplikacji (logiki biznesowej) i bazy danych. Niedopuszczalne jest, aby operacje na obiektach i zdarzeniach przetwarzanych w ESZD były częściowo wykonywane w warstwie interfejsu użytkownika a następnie ich wyniki przekazywane do warstwy aplikacji lub bazy danych wszelkie tego typu operacje muszą być wykonywane w warstwie aplikacji. Warstwa interfejsu użytkownika musi być w pełni oparta o przeglądarki internetowe i nie może wykorzystywać innych aplikacji zainstalowanych lokalnie na stacjach klienckich, za wyjątkiem wirtualnej maszyny Java (dla obsługi uruchomionych przez przeglądarkę internetową apletów). Warstwa interfejsu użytkownika musi prawidłowo działać, co najmniej w następujących przeglądarkach internetowych w pełnym zakresie funkcjonalnym ESZD: Internet Explorer 9-10, Firefox 24, Chrome 30 oraz w ich wyższych wersjach. Ponadto warstwa interfejsu użytkownika musi wykorzystywać technologie przyspieszające komunikację między stacją kliencką a serwerem aplikacji (np. AJAX). Warstwy aplikacji oraz bazy danych muszą pracować w środowisku Linux. Warstwa bazy danych musi być oparta o bazę SQL na darmowej i otwartej licencji (np. Postgresql, MySQL), które będą pracować w środowisku Linux-, oraz być zorganizowana w taki sposób, aby wszelkie opisowe parametry dotyczące obiektów i zdarzeń przetwarzanych w ESZD były przechowywane w strukturze bazy danych i być chronione mechanizmami silnika bazy danych, natomiast wszelkie pliki dotyczące obiektów i zdarzeń przetwarzanych w ESZD były 3
przechowywane w strukturze katalogowej pamięci masowej serwera obsługującego warstwę bazy danych, przy jednoczesnym zachowaniu spójności i bezpieczeństwa obu typów danych (co najmniej poprzez mechanizm przechowywania odcisków plików w strukturze bazy danych). Warstwy aplikacji i bazy danych muszą wykorzystywać mechanizmy transakcji dla każdej operacji związanej z zapisem danych. Współpraca ESZD z urządzeniami (skanerami, drukarkami, czytnikami kodów graficznych itp.) oraz innymi aplikacjami musi się odbywać za pośrednictwem systemu operacyjnego stacji klienckiej lub serwera. Komunikacja ESZD z innymi aplikacjami musi wykorzystywać interfejsy komunikacyjne WebServices, zgodne ze standardami SOAP, WSDL. Konfiguracja komunikacji z innymi aplikacjami musi pozwalać na wykorzystanie protokołów HTTP albo szyfrowanego HTTPS z możliwością zmiany w każdej chwili przez Zamawiającego bez udziału Wykonawcy. Architektura wewnętrzna oraz interfejs użytkownika ESZD muszą być spójne i nie mogą zmuszać użytkowników do wielokrotnego wprowadzania tych samych danych, w szczególności Zamawiający nie dopuszcza dostarczenia rozwiązania składającego się z aplikacji pochodzących od różnych producentów. Mając na uwadze przeznaczenie i użytkownika (wprowadzanie i przetwarzanie danych przede wszystkim liczbowych, służby finansowo-budżetowe) system musi zachowywać wysoką jakość użytkową oraz musi posiadać przejrzysty i czytelny interfejs. Ponadto w związku z dużą ilością terminów i określeń finansowo-budżetowych system musi dysponować dostępną w każdej funkcjonalności pomocą kontekstową. 4.2. Zasada działania ESZD. 4.2.1. Użytkownicy. ESZD pozwala użytkownikom oddziaływać na przetwarzaną w aplikacji dokumentację, sprawy, inwestycje tylko i wyłącznie poprzez zajmowane stanowiska i dzięki uprawnieniom przypisanym do zajmowanych stanowisk. Wszelka dokumentacja, sprawy, inwestycje są przypisane do stanowisk, a nie do użytkowników. Każdy użytkownik może jednocześnie zajmować wiele stanowisk, a do każdego stanowiska może być przypisany naraz (za wyjątkiem zastępstw) tylko jeden użytkownik. Uprawnienia użytkowników dotyczące obiektów i zdarzeń przetwarzanych w ESZD wynikające z przypisania do danego stanowiska nie łączą się z uprawnieniami wynikającymi z przypisania do innego stanowiska użytkownik pracując w kontekście danego stanowiska dysponuje uprawnieniami tylko i wyłącznie danego stanowiska, a zmieniając stanowisko pracy traci poprzednie uprawnienia i zyskuje te przypisane do bieżącego stanowiska. Użytkownicy mogą zastępować innych użytkowników (np. w wypadku nieobecności) poprzez przydzielenie im stanowiska zwykle zajmowane przez zastępowanego użytkownika i w takim wypadku pracując w kontekście stanowiska zastępowanego użytkownika, użytkownik dysponuje jedynie uprawnieniami przypisanymi do tegoż stanowiska. 4.2.2. Struktura organizacyjna. Struktura organizacyjna jest zorganizowana hierarchicznie, uwzględniając relacje między elementami struktury (co najmniej podległość komórek organizacyjnych i 4
przypisania stanowisk do komórek organizacyjnych). Każde stanowisko musi należeć tylko i wyłącznie do jednej komórki organizacyjnej. ESZD musi zachowywać historyczne układy i konfigurację struktury organizacyjnej, w szczególności: wzajemne relacje między elementami struktury, użytkownicy przypisani do stanowisk, uprawnienia przypisane do stanowisk i komórek, konfigurację i statusy obiektów struktury. Jest to niezwykle istotny element z uwagi na zachodzące zmiany w strukturze organizacyjnej i konieczność analizy procedowanych spraw w kontekście zmian organizacyjnych. ESZD pozwala tworzyć i wykorzystywać tymczasowe zespoły zadaniowe użytkowników, poza regularną strukturą organizacyjną. Użytkownicy przypisani do takiego zespołu są sobie równorzędni, a poprzez wskazanie zespołu wskazuje się przypisanych doń użytkowników. 4.2.3. Uprawnienia. ESZD musi posiadać spójny i jednolity system uprawnień. Uprawnienia użytkownika to suma logiczna przypisanych mu poprzez stanowisko uprawnień cząstkowych do funkcjonalności, obiektów, akcji. Zamawiający dopuszcza działanie ESZD w jednym z dwóch wariantów, tj. Pierwszy: stanowiska domyślnie nie posiadają żadnych uprawnień a zmiana odbywa się poprzez przydzielanie mu kolejnych uprawnień cząstkowych; Drugi: stanowisko domyślnie posiada pełnię uprawnień a zmiana odbywa się poprzez odbieranie mu kolejnych uprawnień cząstkowych. Zamawiający nie dopuszcza, aby ESZD wykorzystywał oba warianty. Uprawnienia cząstkowe mogą być przypisywane do stanowisk i do komórek organizacyjnych. ESZD pozwala definiować zbiory uprawnień, grupujące uprawnienia cząstkowe w celu ułatwienia zarządzania. Przypisanie stanowisku lub komórce organizacyjnej zbioru uprawnień oznacza przypisanie wszystkich uprawnień cząstkowych grupowanych zbiorem. ESZD nie pozwala na dziedziczenie uprawnień cząstkowych z wyższych elementów struktury przez niższe (np. uprawnienia przypisane do komórki nadrzędnej nie są dziedziczone przez komórkę podrzędną), za wyjątkiem dziedziczenia przez stanowiska uprawnień z komórki do której je przypisano. 4.2.4. Procesy. ESZD zapewnia szczególny sposób obsługi procesów, tj. wszystkie instancje procesu, które zostały uruchomione przed zmianą definicji ścieżki procesu, są do ich zakończenia procedowane zgodnie ze starą ścieżką, dopiero nowe instancje procesu, które zostały uruchomione po zmianie definicji ścieżki procesu, są procedowane zgodnie z nową definicją ścieżki procesu. 4.3. Konfiguracja i administracja ESZD. 4.3.1. Struktura organizacyjna. ESZD musi umożliwić odzwierciedlenie struktury organizacyjnej Zamawiającego wraz z podległością komórek organizacyjnych oraz stanowisk. Musi być możliwość opisania każdej komórki organizacyjnej co najmniej: nazwą, symbolem, danymi adresowymi, umiejscowieniem w strukturze, przypisanymi stanowiskami, przypisanymi uprawnieniami cząstkowymi, symbolami JRWA. 5
Musi być możliwość opisania każdego stanowiska co najmniej: nazwą, symbolem, przypisanym użytkownikiem, przypisanymi uprawnieniami cząstkowymi i zbiorami uprawnień, wskazaniem roli stanowiska w komórce (co najmniej: dyrektor, sekretariat,kierownik, pracownik), dostępny obszar poszukiwań oraz zakres informacji o odnalezionych obiektach. ESZD musi umożliwiać (na żądanie administratora) zaprezentowanie struktury organizacyjnej dla dowolnej daty z przeszłości, prezentację zmian związanych z danym elementem struktury organizacyjnej, w tym co najmniej historię przydzielanych użytkowników, historię przydzielanych uprawnień cząstkowych i zbiorów uprawnień. ESZD musi umożliwiać modyfikowanie struktury organizacyjnej, co najmniej w następującym zakresie: dodawanie, edytowanie, usuwanie, zmiana umiejscowienia w hierarchii (podległości) elementów struktury (w tym mechanizmem drag&drop), zmianę statusu elementu. ESZD musi umożliwiać hurtowe dodawanie wielu stanowisk (w dowolnej określonej liczbie) na bazie (o zbliżonych parametrach) wskazanego stanowiska. Definiowanie zespołów zadaniowych musi być dostępne dla użytkownika posiadającego szczególne uprawnienie i sprowadza się do zdefiniowania nazwy oraz wskazania przypisanych użytkowników. ESZD musi umożliwiać przypisanie do każdego elementu struktury organizacyjnej zestawu haseł JRWA, pochodzących z centralnego słownika JRWA, które stanowisko (lub stanowiska w komórce) może wykorzystywać w pracy z dokumentacją i sprawami. Narzędzie do zarządzania strukturą organizacyjną musi umożliwiać wyszukiwanie komórek organizacyjnych stanowisk i przypisanych użytkowników, a także filtrować strukturę organizacyjną wg statusu elementów struktury (aktywne, nieaktywne, usunięte). 4.3.2. Użytkownicy. Słownik użytkowników pracujących w ESZD musi być oddzielony od struktury organizacyjnej. Musi być możliwość opisania każdego użytkownika, co najmniej: loginem, hasłem dostępu, symbolem pracownika, imieniem, nazwiskiem, adresem e-mail, nr telefonu, typem (ze zdefiniowanego przez administratora słownika), datą ważności konta (po upływie której konto jest automatycznie blokowane), metodą autoryzacji (co najmniej uwierzytelnienie hasłem, certyfikatem niekwalifikowanym), przypisanym certyfikatem niekwalifikowanym, statusem (co najmniej aktywny, zablokowany, usunięty). Administrator musi mieć możliwość tworzenia nowego, zablokowania lub odblokowania, edycji i usunięcia użytkownika w dowolnym momencie. Ponadto musi być możliwość hurtowego importu z plików XML albo CSV użytkowników z pełnym opisem (w strukturze przedstawionej przez Wykonawcę). W narzędziu do zarządzania słownikiem użytkowników, musi być dostępna informacja o zajmowanych przez użytkowników stanowiskach, przynależności do komórek organizacyjnych i stanie zalogowania i terminie ostatniego logowania, w kontekście każdego użytkownika z osobna. 6
Narzędzie do zarządzania słownikiem użytkowników pozwala na wyszukiwanie użytkowników oraz filtrowanie wg statusu. 4.3.3. Szablony wydruków i dokumentów. ESZD musi umożliwiać administratorowi definiowanie i zarządzanie szablonami generowanych wydruków oraz dokumentów. Zarządzanie musi obejmować, co najmniej dodawanie, usuwanie, edycję. Musi być możliwość definiowania dowolnej liczby szablonów wydruków dla danego obiektu np. dowolnej liczby wersji wydruku nalepki adresowej. Zdefiniowanie szablonu wydruku musi być możliwe, co najmniej dla przesyłek przychodzących, przesyłek wychodzących, spraw, pozycji rejestrów (zarejestrowanych obiektów), etapów procesów, interesantów, dokumentacji finansowej. Każdy szablon wydruku musi być opisany co najmniej parametrami: obiektem do którego się odnosi, nazwą, wymiarami ogólnymi, zawartością tj. zestawem elementów stałego tekstu, zmiennych (wartości tekstowych, liczbowych, graficznych) udostępnianych przez aplikację, w dowolnym (zdefiniowanym przez administratora) układzie rozmieszczenia. Definiujący szablon wydruku musi mieć możliwość użycia, co najmniej następujących zmiennych: kod graficzny zawierający identyfikator obiektu (którego dotyczy wydruk), zestaw danych opisujących obiekt w systemie, dane adresowe urzędu, nazwę urzędu, dane stanowiska i użytkownika wykonującego wydruk, bieżące datę i czas, dane interesanta (w tym dane adresowe), sprawy, dokumentacji, stanowiska lub użytkownika powiązanych z obiektem. Generacja wydruku będzie sprowadzać się do wygenerowania pliku możliwego do wydruku, zgodnego ze zdefiniowanym szablonem, gdzie w miejsce zmiennych zostaną podstawione wartości przezeń udostępniane. Przed wygenerowaniem wydruku aplikacja musi udostępniać gotowy dokument do edycji. Musi być możliwość definiowania szablonu dla każdego zdefiniowanego procesu dokumentu. Każdy szablon dokumentu musi być opisany co najmniej parametrami: wskazaniem procesu dokumentu do którego się odnosi, zawartością tj. zestawem elementów stałego tekstu, zmiennych (wartości tekstowych, liczbowych, graficznych) udostępnianych przez aplikację, w dowolnym (zdefiniowanym przez administratora) układzie rozmieszczenia. Definiujący szablon dokumentu musi mieć możliwość użycia, co najmniej następujących zmiennych: kod graficzny zawierający identyfikator dokumentu, zestaw danych opisujących dokument w systemie, zestaw danych opisujących sprawę do której przynależy dokument, dane adresowe urzędu, nazwę urzędu, dane stanowiska i użytkownika generującego dokument, bieżące datę i czas, dane interesanta (w tym dane adresowe), stanowiska i użytkownika powiązanych z dokumentem. Generacja dokumentu będzie sprowadzać się do wygenerowania pliku dokumentu, zgodnego ze zdefiniowanym szablonem, gdzie w miejsce zmiennych zostaną podstawione wartości przezeń udostępniane. Administrator musi mieć możliwość zdefiniowania szablonów wydruków i dokumentów we wbudowanym edytorze WYSIWYG lub zewnętrznej aplikacji generującej plik szablonu w formacie RTF i zaimportowania go do ESZD. 4.3.4. Raporty Administrator musi mieć możliwość definicji i konfiguracji dowolnej liczby raportów. Funkcjonalność musi umożliwiać, co najmniej zdefiniowania układu treści, źródła 7
danych, kryteriów generacji raportów oraz określenia, które stanowiska mają prawo wygenerować raport. Definicja każdego raportu sprowadza się do określenia, co najmniej: źródła danych (np. dokumentacja, sprawy), nazwy raportu, kryteriów generacji raportu, określenia liczby, tytułów, zawartości, szerokości oraz widoczności na wydruku kolumn. W każdym raporcie można wykorzystać, jako prezentowane w kolumnach dane oraz jako kryteria generacji każdy z parametrów opisujących obiekty (m.in. wartości pól formularza opisującego dokumentację), których dotyczy raport. 4.3.5. Rejestry Administrator musi mieć możliwość definicji i konfiguracji dowolnej liczby rejestrów dla każdego typu obiektu rejestrowanego (tj. spraw i dokumentacji). Funkcjonalność musi umożliwiać, co najmniej zdefiniowania układu treści, źródła danych oraz określenia, które stanowiska mają prawo zasilać i przeglądać rejestr. Definicja każdego rejestru sprowadza się do określenia, co najmniej: źródła danych (wskazanie procesów dokumentacji albo spraw skojarzonych z rejestrem) i sposobu zasilania rejestru (ręczne lub automatyczne), nazwy rejestru, schematu numerowania, określenia liczby, tytułów, zawartości, szerokości kolumn. Ponadto, musi być możliwość zdefiniowania parametrów opisujących obiekty w rejestrze, które nie będą wypełniane wartościami zmiennych tylko ręcznie przez użytkowników. W każdym rejestrze można wykorzystać jako prezentowane w kolumnach dane każdy z parametrów opisujących obiekty (m.in. wartości pól formularza opisującego dokumentację), których dotyczy rejestr. 4.3.6. Słowniki ESZD. 4.3.6.1. Słownik miejscowości, ulic, numerów budynków i kodów pocztowych. ESZD musi posiadać wbudowany słownik miejscowości, ulic, numerów budynków i kodów pocztowych PNA. Dane dotyczące miejscowości i ulic muszą być zorganizowane hierarchicznie w oparciu o dane z podziału terytorialnego kraju (TERYT - na gminy, powiaty i województwa) i z nim zgodne. Dane dotyczące powiązania miejscowości, ulic i numerów budynków z kodami pocztowymi PNA muszą być zgodne z danymi udostępnianymi przez Pocztę Polską SA. Wykonawca musi zainicjować słownik aktualnymi danymi w dniu odbioru, udostępnianymi przez GUS oraz Pocztę Polską SA. Administrator musi mieć możliwość samodzielnej modyfikacji i aktualizacji zawartości słownika. 4.3.6.2. Słownik JRWA. ESZD musi posiadać słownik jednolitego rzeczowego wykazu akt (JRWA). W słowniku każda pozycja musi być opisana co najmniej: symbolem hasła, treścią hasła, ewentualnymi uwagami, kategorią archiwalną oraz datami początku i końca aktualności. Administrator musi mieć możliwość edytowania istniejących pozycji słownika, w tym modyfikacji przedziału dat aktualności i dodawania nowych wpisów. Ponadto narzędzie do zarządzania słownikiem musi umożliwiać wyszukiwanie pozycji oraz ich filtrowania co najmniej wg aktualności dla wskazanej daty. 8
W słowniku nie mogą wystąpić jednocześnie dwie pozycje o identycznym symbolu i nachodzących na siebie przedziałach czasu aktualności naraz tylko jedna pozycja o danym symbolu może być aktualna. Aplikacja musi pozwalać na wprowadzenie do słownika wielu pozycji o tym samym symbolu aktualnych dla różnych okresów. Słownik musi przechowywać historyczne wersje pozycji. 4.3.6.3. Słowniki systemowe. Administrator musi mieć możliwość zdefiniowania nowych słowników i ich wartości, które będzie można wykorzystywać w różnych miejscach aplikacji, co najmniej jako parametry opisujące dokumentację, sprawy, inwestycje ZIKiT, interesantów w bazie interesantów. Status słownika oraz statusy poszczególnych wartości słownika reguluje ich dostępność do wykorzystania w aplikacji (co najmniej aktywny, nieaktywny). Nie może być możliwości usunięcia wykorzystanej wartości słownika można ją jedynie dezaktywować. 4.3.6.4. Słownik relacji. ESZD musi udostępniać słownik relacji określający listę relacji jakimi można powiązać ze sobą 2 różne obiekty (np. dokumentację, sprawy). Każda relacja musi określać rolę pierwszego obiektu względem drugiego i drugiego względem pierwszego (np. relacja zmiany, obiekt pierwszy zmienia, a obiekt drugi jest zmieniany). Administrator musi mieć możliwość uzupełniania słownika o nowe relacje. 4.3.6.5. Słownik dekretacji. ESZD musi udostępniać słownik dekretacji do wykorzystania w procedurze dekretacji do redakcji polecenia dekretacyjnego. Administrator musi mieć możliwość zarządzania słownikiem. 4.3.6.6. Słownik sposobów dostarczenia. ESZD musi udostępniać słownik sposobów dostarczenia, wykorzystywany do opisu przesyłek przychodzących i wychodzących. Administrator musi mieć możliwość zarządzania słownikiem, w szczególności tworzenia dowolnej liczby sposobów dostarczenia przesyłek, określania ich przedziałów cenowych dla wag i gabarytów. 4.3.7. Uprawnienia. Uprawnienia do dodawania interesantów, ich aktualizacji, korekty, usuwania, scalania oraz do tworzenia, edycji, usunięcia, zatwierdzenia i zakończenia zastępstw czasowych i stałych muszą być odrębnymi uprawnieniami cząstkowymi. Uprawnienia do dekretacji muszą podlegać co najmniej następującej gradacji: przekazanie mojej komórce organizacyjnej lub stanowiskom mojej komórki organizacyjnej, przekazanie mojej i podległym komórkom organizacyjnym lub stanowiskom mojej i podległych komórek organizacyjnych, przekazanie wszystkim komórkom organizacyjnym lub stanowiskom wszystkich komórek organizacyjnych, przekazanie zespołom zadaniowym. Uprawnienia do podglądu spraw procedowanych na innych stanowiskach muszą podlegać co najmniej następującej gradacji: dostęp pełen, standardowy, podstawowy, przy czym stopień dostępu może być różny dla spraw w mojej 9
komórce organizacyjnej, podległych komórkach organizacyjnych, wszystkich pozostałych komórkach organizacyjnych. Uprawnienia do wyszukiwania spraw i dokumentacji muszą podlegać co najmniej następującej gradacji: obiekty własne, obiekty stanowisk we własnej komórce organizacyjnej, obiekty stanowisk we własnej i podległych komórkach organizacyjnych, obiekty stanowisk wszystkich komórek organizacyjnych. Uprawnienia dostępu do dokumentacji zgromadzonej w składzie bibliotecznym muszą podlegać co najmniej następującej gradacji: podgląd, dodawanie, edycja, usuwanie, zmiana katalogu. ESZD musi umożliwić administratorowi zmianę kwalifikacji spraw do kategorii JRWA (w tym znak sprawy). 4.3.8. Procesy. ESZD musi udostępniać administratorowi narzędzie do modelowania (modeler) ścieżek procesów realizowanych w aplikacji, pozwalający na tworzenie nowych i edycję i konfigurację już istniejących procesów. Narzędzie (modeler) ścieżek procesów musi być częścią składową aplikacji i być z nią w pełni zintegrowany. Nie dopuszcza się dostarczenia rozwiązania korzystającego z funkcjonalności czy wręcz instalacji zewnętrznych aplikacji lub posiadania dodatkowych licencji. Funkcjonalność umożliwia import i eksport definicji poszczególnych procesów z/do plików w formacie XPDL oraz prezentację ścieżek poszczególnych procesów w formie grafu, gdzie węzły grafu reprezentują aktywności procesu a linie możliwe przejścia między aktywnościami każda linia musi również określać dozwolony kierunek przejścia. Modeler ścieżek procesów musi być na tyle prosty, że administrator, po uprzednim przeszkoleniu lecz bez wiedzy i umiejętności programistycznych, będzie w stanie samodzielnie zdefiniować procesy o dowolnym stopniu skomplikowania, jakie można zdefiniować w dostarczonym narzędziu. Modeler ścieżek procesów musi umożliwiać co najmniej: przejście do następnego kroku procesu po spełnieniu określonych warunków (w tym: porównań wartości oraz wyników operacji logicznych i arytmetycznych), przejście do kroku poprzedniego, ustalenie dowolnej liczby kroków, ustalenie czasów na wykonanie każdego kroku z osobna, rozgałęzianie ścieżki procesu (tzw. ścieżki równoległe), wymuszenie automatycznego zasilenia wskazanych rejestrów, wymuszanie użycia określonych wartości w parametrach opisujących obiekty spraw lub dokumentacji procedowanych zgodnie z definicją procesu (co najmniej: symbol JRWA, czas rozpatrzenia, formularz, zestaw elementów struktury organizacyjnej uprawnionych do poszczególnych aktywności), określenie typów procesu (dokumentacji, sprawy), określenie domyślnych wykonawców kroku procesu z zachowaniem możliwości ich zmiany, weryfikacji poprawności definicji procesu, modyfikacji istniejących definicji procesów w tym wersjonowanie definicji procesów, włączanie i wyłączanie z użytku procesów. 4.3.9. Skanery. Administrator musi mieć możliwość zdefiniowania wielu szablonów skanowania, które będą udostępniane do wykorzystania wszystkim użytkownikom. Każdy szablon skanowania musi zostać opisany co najmniej: unikalnym identyfikatorem 10
oraz wszystkimi parametrami pozwalającymi wykonać skanowanie, zgodnie z wymogami instrukcji kancelaryjnej wskazanej wyżej w punkcie 3. 4.3.10. Dokumentacja. Administrator musi mieć możliwość zdefiniowania dowolnej liczy typów dokumentacji (np. wniosek, postanowienie, decyzja, opinia, faktura itd.) i powiązania każdego z typów z odpowiednim procesem, a w stosunku do każdego typu dokumentu z osobna musi mieć możliwość zdefiniowania zestawu parametrów go opisujących tzw. metryki dokumentu. Każda metryka dokumentu będzie mogła składać się co najmniej z. pól tekstowych, liczbowych (całkowitych i zmiennoprzecinkowych), dat, list rozwijanych jednokrotnego wyboru, list wielokrotnego wyboru, polami importu plików. Listy wyboru będą mogły być zasilane wartościami zdefiniowanymi dla każdej metryki z osobna lub wartościami pochodzącymi ze słowników systemowych. Ponadto, w ramach definicji każdej metryki dokumentu administrator musi mieć możliwość wykorzystania kontrolki, której zadaniem będzie przechowywanie identyfikatorów (jednego lub wielu) powiązanych z dokumentem interesantów (pochodzących z bazy interesantów), prezentacja danych każdego interesanta powiązanego z dokumentem (m.in. nazwa, imię, nazwisko, dane adresowe) w sposób zwięzły (np. w jednej etykiecie, jednym polu typu textarea), wskazanie roli powiązanych interesantów jaką odgrywają w stosunku do danego dokumentu (m.in. nadawca, twórca, adresat, pełnomocnik itp.). Nie dopuszcza się dostarczenia rozwiązania polegającego na prezentacji każdego parametru danych powiązanych interesantów (jak imię, nazwisko, nazwa, miejscowość, ulica itd.) w osobnych polach formularza oraz rozwiązania polegającego na zapisie wszystkich parametrów powiązanych z dokumentem interesantów w formularzu wymaga się, aby interesanci z bazy interesantów byli powiązani jedynie poprzez identyfikator. ESZD musi umożliwiać administratorowi określenie maksymalnego rozmiaru dla plików dokumentów elektronicznych wysyłanych do skrzynek odbiorczych interesantów w ESP. 4.3.11. Personalizacja. ESZD musi umożliwić każdemu użytkownikowi personalizację aplikacji co najmniej w zakresie: ustawiania nowego hasła dostępu, zarządzania wartościami we własnym podręcznym słowniku tekstów, zarządzania powiadomieniami systemowymi w zakresie listy otrzymywanych powiadomień, częstotliwości ich generowania oraz sposobu dostarczenia powiadomienia (przez komunikator wewnętrzny, wiadomość e-mail), określenia domyślnego formularza, procesu i wydruków dla dokumentacji rejestrowanej na swoim stanowisku, określenia domyślnego stanowiska pracy (dla użytkowników posiadających kilka stanowisk), określenia formaty prezentacji daty i czasu, określenia liczby dni do końca wyznaczonych terminów (np. rozpatrzenia sprawy albo wykonania polecenia) generujących ostrzeżenie o możliwości przekroczenia terminu, określenia domyślnego dostawcy podpisu elektronicznego, zdefiniowania podręcznych list ulubionych stanowisk, komórek organizacyjnych (adresatów listy wykorzystywanej przy przekazywaniu spraw i dokumentacji), najczęściej uruchamianych procesów, określenia podręcznej listy ulubionych kryteriów wyszukiwania interesantów, określenia domyślnych kryteriów 11
wyszukiwania dla każdej dostępnej wyszukiwarki z osobna, wykorzystania funkcjonalności automatycznego podpisu dekretacji i akceptacji dokumentacji. 4.3.12. Dziennik zdarzeń aplikacji (logi). ESZD musi monitorować i odnotowywać zdarzenia w aplikacji oraz umożliwiać administratorowi przeglądanie listy odnotowanych zdarzeń. Wszystkie zdarzenia muszą być przypisane do konkretnej kategorii zdarzeń, a administrator musi mieć możliwość ustalenia czy zdarzenia z danej kategorii mają być odnotowywane w dzienniku zdarzeń. Każde odnotowane zdarzenie musi być opisane co najmniej parametrami: użytkownik wykonujący zdarzenie, obiekt którego dotyczy zdarzenie, tekstowy opis zdarzenia, data i czas zdarzenia z dokładnością do sekundy, numer IP z którego wygenerowano zdarzenie, kategoria zdarzenia. Administrator musi mieć możliwość filtrowania listy zdarzeń co najmniej wg kryteriów: użytkownik generujący zdarzenie, przedział czasu zdarzeń, kategoria zdarzenia oraz eksportu przefiltrowanej listy zdarzeń do pliku tekstowego (np. TXT, PDF). Funkcjonalność musi odnotowywać zdarzenia (przeglądanie, wydruk,zmiany) dotyczące co najmniej: dokumentacji, spraw, użytkowników, struktury organizacyjnej, słowników, interesantów oraz automatycznych operacji wykonywanych przez system. Ponadto ESZD musi odnotowywać zmiany konfiguracji procesów i formularzy, zastępstwa i nieobecności na wszystkich stanowiskach, historię wykonanych kroków procesu każdej instancji procesu dokumentacji i sprawy. 4.4. Funkcjonalności ESZD. 4.4.1. Zarządzanie dokumentacją gromadzoną i przetwarzaną przez ZIKiT. 4.4.1.1. Gromadzenie dokumentacji. ESZD musi umożliwiać uprawnionym użytkownikom rejestrowanie wszelkiego rodzaju dokumentacji oraz jej późniejszą obsługę w zgodzie z wymogami określonymi w obowiązujących przepisach prawa. Uprawniony użytkownik musi mieć możliwość opisania każdego dokumentu co najmniej parametrami udostępnianymi przez metrykę dokumentu oraz parametrami mieszczącymi się w zakresie danych opisujących dokumenty w paczkach archiwalnych tzw. metadanymi. Musi istnieć możliwość edycji każdego z parametrów metryki i metadanych, a każda zmiana tych parametrów musi skutkować utworzeniem nowej wersji opisu oraz zachowania wszystkich poprzednich wersji do przeglądu. Formularze oraz kontrolki prezentujące wartości parametrów metryki i metadanych muszą być od siebie odseparowane (np. oddzielnie grupowane albo w oddzielnych zakładkach albo lub w oddzielnych formularzach). Ponadto każdy dokument musi być opisany parametrami uzupełnianymi automatycznie i pod wyłączną kontrolą aplikacji, co najmniej: unikalny identyfikator, data rejestracji, stanowisko merytoryczne, typ dokumentu, status itd. 12
Użytkownik rejestrujący/edytujący metrykę dokumentu musi mieć możliwość powiązywania pojedynczych lub hurtowo wielu interesantów z dokumentem, generacji dokumentu na podstawie szablonu, dokumentu elektronicznego zgodnego ze wzorem i będącego plikiem wynikowym formularza elektronicznego. Użytkownik procedujący dokument musi mieć możliwość złożenia podpisu elektronicznego pod dokumentem (w tych krokach procesu, które przewidują złożenie podpisu). ESZD musi umożliwiać rejestrację dokumentacji nie będącej przesyłkami przychodzącymi lub wychodzącymi (czyli tzw. wewnętrznej). Obsługa w aplikacji dokumentacji wewnętrznej musi być rządzona identycznymi regułami co dokumentacja będąca przesyłkami. ESZD musi umożliwiać odszukiwanie dokumentacji po unikalnym identyfikatorze zawierającym się w kodzie graficznym umieszczonym na wydruku. Uprawnione stanowisko musi mieć możliwość powiązania wieloma niezależnymi relacjami dokumentu z innym obiektem (np. dokumentacją, sprawą) oraz opatrywania dokumentacji komentarzami, gdzie komentarze mogą być prywatne (dostępne tylko dla autora) albo publiczne (dostępne dla wszystkich). Funkcjonalność składów chronologicznych oraz składów nośników informatycznych musi umożliwiać odnotowywanie wypożyczeń i zwrotów dokumentacji, wraz z wydrukiem odpowiednich kart wypożyczeń i zwrotów oraz odnotowywaniem historii wypożyczeń. Każde wypożyczenie i zwrot musi być opisane informacjami kto, kiedy, komu i co wypożyczył. Uprawnione stanowisko musi mieć możliwość wygenerowania listy przesyłek przychodzących w formie tradycyjnej, dla których odwzorowanie cyfrowe nie obejmuje całej przesyłki oraz listy przesyłek przychodzących dostarczonych na nośnikach informatycznych, których nie wprowadzono w pełni do ESZD. Stanowisko merytoryczne obsługujące dokumentację musi mieć możliwość zakwalifikowania dokumentu jako nietworzącego akt sprawy oraz postąpienia z nim zgodnie z obowiązującymi przepisami, tj. co najmniej przyporządkować mu symbol JRWA i odpowiednią kategorię archiwalną. Uprawnione stanowisko musi mieć możliwość zmiany terminów realizacji poleceń oraz rozpatrywania spraw związanych z daną dokumentacją. ESZD musi umożliwiać każdemu stanowisku przypisanie dokumentacji i sprawom przezeń przetwarzanych słów kluczowych (słownikowanych klasyfikatorów) oraz wyszukiwanie dokumentacji i spraw wg tych słów kluczowych. Każde uprawnione stanowisko musi mieć możliwość uzupełniania i edycji słownika słów kluczowych w ramach własnej komórki organizacyjnej. ESZD musi umożliwić uprawnionemu użytkownikowi stworzenie dokumentu w wersji roboczej i zachowanie go w ramach sprawy z odpowiednim statusem. Taki dokument musi być dostępny do dalszej 13
edycji i obróbki, jednakże nie może być dostępny (widoczny) dla innych stanowisk niż twórca. 4.4.1.2. Przesyłki przychodzące. ESZD musi umożliwiać przyjmowanie i rejestrację przesyłek przychodzących zgodnie z obowiązującymi przepisami prawa. Uprawniony użytkownik musi mieć możliwość rejestracji wszelkich przesyłek przychodzących, zarówno w formie tradycyjnej, jak i elektronicznej dostarczonej na nośniku albo za pośrednictwem ESP albo wiadomości e-mail (MS Outlook). Zarejestrowane przesyłki przychodzące automatycznie zasilają centralny rejestr przesyłek przychodzących. W trakcie rejestracji przesyłek przychodzących dostarczonych w formie tradycyjnej musi istnieć możliwość utworzenia ich cyfrowego odwzorowania. W trakcie rejestracji przesyłek przychodzących dostarczonych w formie tradycyjnej musi istnieć możliwość wygenerowania wydruku zawierającego kod graficzny zawierający unikalny identyfikator dokumentu, unikalny identyfikator dokumentu w formie numerycznej (albo alfanumerycznej), numer przesyłki z centralnego rejestru przesyłek przychodzących, datę wpływu - wygenerowany wydruk musi być możliwy do wydruku na drukarce etykiet i papierze o wymiarach max 5cm * 2,5cm. Procedura rejestracji każdej przesyłki przychodzącej musi umożliwiać wykonanie kroków w następującej kolejności: opisanie przesyłki parametrami, wygenerowane w/w wydruku, umieszczenie wydruku na oryginale przesyłki, utworzenie cyfrowego odwzorowania przesyłki zawierającego w/w wydruk, dodanie cyfrowego odwzorowania do metryki, wskazanie stanowiska otrzymującego przesyłkę. Ponadto musi być możliwość wykonania wstępnej rejestracji, sprowadzającej się do: opisania przesyłki wpływającej podstawowymi parametrami (datą wpływu, unikalnym identyfikatorem, numerem z centralnego rejestru przesyłek przychodzących, liczbą załączników) oraz wygenerowania wydruku zawierającego istniejące parametry, a następnie jej dokończona w dowolnym późniejszym terminie (m.in. dokończenie opisu, cyfrowe odwzorowanie), z tym zastrzeżeniem, że stanowisko rejestrujące w przerwie między wstępną rejestracją a jej dokończeniem może wykonywać dowolne czynności w ramach aplikacji, w szczególności wstępnie rejestrować inne przesyłki przychodzące. W trakcie rejestracji elektronicznych przesyłek przychodzących dostarczonych na nośniku informatycznym musi istnieć możliwość wprowadzenia ich do aplikacji oraz wydanie potwierdzenia przyjęcia w formie zgodnej z obowiązującymi przepisami prawa (wydruk oraz UPO). Musi istnieć możliwość przypisywania przesyłki przychodzącej do wielu wskazanych rejestrów w ramach procedury rejestracji oraz prowadzenia składów chronologicznych i składów nośników elektronicznych dla przesyłek przychodzących, zgodnie z obowiązującymi przepisami prawa. 14
W trakcie rejestracji przesyłki przychodzącej, z poziomu formularza metryki, użytkownik musi mieć możliwość sprawdzenia czy przesyłka o identycznej sygnaturze i nadawcy została już wcześniej zarejestrowania. Przez zainicjowaniem procedury rejestracji przesyłki przychodzącej, dostarczonej za pośrednictwem ESP, stanowisko rejestrujące musi mieć możliwość na żądanie weryfikacji poprawności złożonego podpisu elektronicznego i ważności certyfikatu, który posłużył złożeniu podpisu. Wymaga się, aby ESZD umożliwiał weryfikację podpisów w standardzie XAdES i profilem zaufanym portalu epuap bez uruchamiania jakiegokolwiek zewnętrznego oprogramowania wszelkie komponenty służące weryfikacji tego typu podpisów musza być zawarte w aplikacji. Musi istnieć możliwość utworzenia wielu dokumentów na podstawie jednej przesyłki przychodzącej, np. dzięki wykorzystaniu kompletu danych opisujących poprzednio rejestrowaną przesyłkę przychodzącą w formularzu kolejnej przesyłki przychodzącej. Stanowisko rejestrujące musi mieć możliwość zakwalifikowania rejestrowanej przesyłki przychodzącej, jako dokumentacji nietworzącej akt sprawy już w ramach procedury rejestracji oraz postąpienia z nią zgodnie z obowiązującymi przepisami, tj. co najmniej przyporządkować jej symbol JRWA i odpowiednią kategorię archiwalną. ESZD musi umożliwiać stanowisku kancelaryjnemu hurtowe przekazanie przesyłek przychodzących do wskazanej komórki organizacyjnej lub stanowiska, jeśli na etapie rejestracji nie wskazano ich odbiorcy. Musi istnieć możliwość edycji i uzupełnienia formularzy metryki i metadanych przesyłki przychodzącej przez stanowisko obsługi merytorycznej, już po zakończeniu procedury rejestracji przesyłki przychodzącej. 4.4.1.3. Przekazywanie dokumentacji. ESZD musi udostępniać funkcjonalność dzienników korespondencji dla każdej komórki. Dzienniki korespondencji są automatycznie zasilane wpisami na podstawie przepływu dokumentacji między komórkami, niezależnie od tego, czy dokumentacja dotyczy przesyłek przychodzących lub wychodzących czy dokumentacji wewnętrznej. Dziennik osobno odnotowuje, numeruje i prezentuje wpisy dotyczące dokumentacji opuszczającej komórkę organizacyjną i przybywającej do komórki organizacyjnej. Uprawnione stanowiska muszą mieć możliwość przeglądu dziennika korespondencji komórki i generację wydruku tegoż dziennika. ESZD reguluje przemieszczanie dokumentacji między stanowiskami zgodnie z i na podstawie ścieżki procesu, w którym dana dokumentacja się znajduje. Rozgałęzienie ścieżki procesu (czyli istnienie wielu równoległych ścieżek postępowania), umożliwia stanowisku obsługującemu wybór następnego kroku, a lista dostępnych kroków oraz stanowisk je obsługujących wynika z definicji ścieżki procesu. Musi istnieć możliwość przekazania dokumentacji innym stanowiskom z pominięciem ścieżki procesu (mechanizmów workflow) w trybach: przekazania do wiadomości 15
(anonsowania o dokumencie), zwrócenia błędnie przekazanej dokumentacji oraz udostępnienia dokumentacji w ramach sprawy. Uprawnione stanowisko musi mieć możliwość otrzymania na żądanie informacji o stanowiskach najmniej obciążonych, spośród tych którym w danym kroku można przekazać dokumentację. ESZD musi umożliwiać uprawnionym użytkownikom dekretowanie dokumentacji w trybach do dekretacji, do przyjęcia, anonsu. W zależności od uprawnień stanowiska dekretującego, dekretacja musi być możliwa na komórki organizacyjne i na poszczególne stanowiska podległe oraz niepodlegające, a także na zespoły zadaniowe. Dokumentacja otrzymana w trybie do dekretacji może być dalej dekretowana na kolejne stanowiska, lecz zgodnie z definicją procesu. Otrzymanie dokumentacji w trybie do przyjęcia umożliwia jej obsługę w sposób merytoryczny (np. utworzenie na jej podstawie sprawy lub dołączenie do istniejącej itp.). Otrzymanie dokumentacji w trybie anonsu umożliwia zapoznanie się z dokumentacją i ewentualne operacje związane z pozyskaniem uprawnień do obsługi tej dokumentacji (np. prośba o udostępnienie). ESZD umożliwia stanowisku dekretującemu przekazywanie dokumentacji (pojedynczych jak i jednocześnie wielu egzemplarzy) jednocześnie wielu komórkom organizacyjnym, stanowiskom i zespołom zadaniowym. Musi istnieć możliwość wskazania typu odbiorcy (merytoryczny, pomocniczy), trybu dekretacji w kontekście do każdego odbiorcy z osobna (do dekretacji, do przyjęcia, anons), polecenia dekretacyjnego i czasu na wykonanie polecenia oraz czasu na rozpatrzenie w odniesieniu do każdego odbiorcy merytorycznego z osobna. Każdy użytkownik dekretujący musi mieć możliwość wykorzystania do redakcji polecenia dekretacyjnego własnego podręcznego słownika tekstów oraz centralnego słownika poleceń dekretacyjnych. Dekretacja dokumentacji na komórkę organizacyjną oznacza przekazanie dokumentacji stanowisku wyznaczonemu w danej komórce organizacyjnej do odbioru korespondencji w imieniu komórki nie dopuszcza się dostarczenia rozwiązania umożliwiającego wysyłanie dokumentacji bez wskazania stanowiska odbiorcy. Dekretacja dokumentacji na zespół zadaniowy będzie sprowadzać się do przekazania dokumentacji każdemu stanowisku będącemu członkiem danego zespołu zadaniowego. Każdy merytoryczny odbiorca dokumentacji otrzymuje odrębny egzemplarz dekretowanej dokumentacji, którego obsługa i kolejne groki procedowania są od tej chwili niezależne od pozostałych egzemplarzy, a odbiorcy pomocniczy nie otrzymują egzemplarza dokumentacji, natomiast dekretowana dokumentacja może im zostać udostępniona w ramach sprawy. Stanowisko, które otrzymało dokumentację, musi mieć możliwość jej przekazania innemu stanowisku własnej komórki posiadającego prawo do obsługi takiej dokumentacji w tym samym trybie oraz zwrotu do 16
stanowiska od którego otrzymało dokumentację, o ile dokumentacja nie stała się już częścią sprawy. Stanowisko dekretujące musi mieć możliwość złożenia podpisu elektronicznego pod treścią dekretacji w ramach aplikacji (bez konieczności korzystania z aplikacji zewnętrznych). Ponadto, ESZD musi umożliwiać automatyczne składanie podpisu elektronicznego przy dekretacji dokumentacji, przy wykorzystaniu certyfikatów i kodów pin wprowadzonych w konfiguracji użytkownika. 4.4.1.4. Przesyłki wychodzące. ESZD musi umożliwiać tworzenie i rejestrację przesyłek wychodzących zgodnie z obowiązującymi przepisami prawa. Wszystkie przesyłki wychodzące, niezależnie od ich formy dostarczenia (tradycyjna, e-mail, ESP, goniec, odbiór osobisty), muszą być rejestrowane w centralnym rejestrze przesyłek wychodzących. Każda dokumentacja skierowana do wysyłki przez stanowisko przetwarzające przez tę dokumentację (np. stanowisko wystawiające dokument w sprawie) musi być automatycznie wprowadzana do rejestru przesyłek wychodzących, jako odrębna przesyłka, a dane opisujące przesyłkę są uzupełniane na podstawie ustawień i danych wprowadzonych przez stanowisko kierujące dokumentację do wysyłki (z wyjątkiem daty wysłania). Data wysłania może zostać nadana tylko i wyłącznie przez stanowisko posiadające odpowiednie uprawnienie (np. stanowisko kancelaryjne). Uprawnione stanowisko (np. stanowisko kancelaryjne) musi mieć możliwość wprowadzania do rejestru przesyłek wychodzących bezpośrednio z poziomu rejestru przesyłek wychodzących (z pominięciem skojarzenia przesyłki wychodzącej z jakąkolwiek dokumentacją). Uprawnione stanowisko musi mieć możliwość hurtowego importu przesyłek wychodzących z pliku o ustalonej przez wykonawcę strukturze i formacie (np. XML). ESZD musi umożliwiać (wg konfiguracji administratora) rejestrację przesyłek wychodzących poszczególnym stanowiskom w ramach zarezerwowanych, nienachodzących na siebie, przedziałów numeracji przesyłek dla wskazanego sposobu dostarczenia. Musi być możliwość opisania każdej przesyłki wychodzącej co najmniej następującymi parametrami: powiązania z danymi adresata z bazy interesantów (danymi osoby albo instytucji oraz danymi adresowymi), sposobem dostarczenia, statusem, datą wysyłki, numerem z rejestru, wagą, ceną, wskazaniem gońca. ESZD musi obsługiwać wysyłanie i doręczanie przesyłek wychodzących przez w różnych formach i za pośrednictwem dowolnych operatorów pocztowych, w szczególności przez Pocztę Polską SA oraz gońców. Dla wskazanego w rejestrze przesyłek wychodzących zestawu przesyłek musi być możliwość wygenerowania tzw. Pocztowej Książki Nadawczej (zgodnej ze wzorem ustalonym przez Pocztę Polską SA). Użytkownik musi mieć możliwość ograniczania zestawu przesyłek co najmniej do: przedziału 17
dat, sposobu dostarczenia, pochodzenia ze wskazanych komórek organizacyjnych, obszaru dostarczenia z dokładnością do miejscowości. Musi być możliwość przypisania ręcznego wskazanego w rejestrze przesyłek wychodzących zestawu przesyłek do gońca, a także automatycznego przypisywania przesyłek do gońców obsługujących zdefiniowane obszary adresowe. Użytkownik musi mieć możliwość ograniczania zestawu przesyłek co najmniej do: przedziału dat, pochodzenia ze wskazanych komórek organizacyjnych, obszaru dostarczenia z dokładnością do przedziałów numerów adresowych budynków wskazanej ulicy i miejscowości. Automatyczne przypisanie do przesyłki do gońca musi polegać na porównaniu adresu dostarczenia z obszarem adresowym. Uprawniony użytkownik musi mieć możliwość zarządzania listą dostępnych gońców, definiowania obszarów adresowych (poprzez podanie miejscowości, ulic, zakresów numerów budynków i stron ulic parzystych i nieparzystych) oraz przypisywania gońców do obszarów adresowych. Dla każdego gońca z osobna musi być możliwość wygenerowania zestawienia przesyłek wychodzących przeznaczonych do doręczenia, pogrupowanych miejscowościami, ulicami i przedziałami numerów. ESZD umożliwia i wspomaga rejestrację zwrotów niedostarczonych przesyłek wychodzących oraz zwrotnych potwierdzeń odbioru (tzw. ZPO), w ten sposób, że z poziomu centralnego rejestru przesyłek wychodzących w odniesieniu do każdej przesyłki o tradycyjnej formie doręczenia umożliwia szybkie uruchomienie rejestracji zwrotu albo ZPO, z jednoczesnym uzupełnieniem danych zwrotu lub ZPO na podstawie danych przesyłki wychodzącej. Zwrot lub ZPO aplikacja zapisuje jako załącznik do dokumentacji której dotyczy. ESZD umożliwia generację pojedynczego lub jednocześnie wielu uprzednio zdefiniowanych przez administratora wydruków (np. kopert, etykiet adresowych, druków ZPO itp. w tym z kodem graficznym) dla pojedynczej lub jednocześnie wielu przesyłek wychodzących, z poziomu centralnego rejestru przesyłek wychodzących. ESZD musi umożliwiać z poziomu centralnego rejestru przesyłek wychodzących wyszukiwanie przesyłek wg kryteriów je opisujących, a także po identyfikatorze zakodowanym w kodzie graficznym. Uprawnione stanowisko (np. kancelaryjne) musi mieć możliwość łączenia wielu przesyłek w jedną kopertę. 4.4.1.5. Powiązanie z zadaniami budżetowymi ESZD musi umożliwiać powiązanie dokumentacji i spraw z zadaniami budżetowymi i bieżący podgląd ich stanów, w tym: planu wyjściowego, planu aktualnego, zmian, zaangażowania, dyspozycji, należności i wykonania. 4.4.2. Zarządzanie sprawami prowadzonymi w ZIKiT. Ogólny proces przyjęcia, rejestracji i obsługi sprawy w ZIKiT przedstawia diagram stanowiący załącznik do niniejszego OPZ. Diagram przestawia jedynie przykład 18
najczęściej występującego procesu, ale nie jedynego. System musi mieć możliwość definiowania dowolnego schematu procesu, zachodzącego przy procedowaniu spraw. 4.4.2.1. Zakładanie spraw. ESZD musi umożliwiać tworzenie spraw. Sprawę można utworzyć bez dołączania do niej jakiejkolwiek dokumentacji, albo na podstawie dokumentu (np. przesyłki przychodzącej, dokumentu wewnętrznego), wiadomości e-mail, wiadomości z komunikatora wewnętrznego. Sprawa musi być możliwa do opisania co najmniej parametrami: znak sprawy (w formacie zgodnym z przepisami prawa), pierwotny znak sprawy (w dowolnym formacie), tytuł sprawy, opis sprawy, data wszczęcia, data zakończenia, termin rozpatrzenia, stanowisko merytoryczne, stanowiska pomocnicze, strony i komentarze sprawy, status systemowy, status szczegółowy z listy statusów uprzednio zdefiniowanych przez administratora i priorytet sprawy. Z poziomu narzędzia do tworzenia sprawy musi być dostępny podręczny słownik JRWA ograniczony do pozycji JRWA jakimi może się posługiwać dane stanowisko (zgodnie z konfiguracją). Stanowisko tworzące sprawę musi mieć możliwość wybrania symbolu JRWA z podręcznego słownika i użycia go do oznaczenia sprawy. ESZD musi umożliwiać zarejestrowanie sprawy w wydzielonym zbiorze (tzw. podteczce) dla wskazanego symbolu w podręcznym słowniku JRWA. Zbiory mają być wydzielane w miarę potrzeb, na bieżąco, zgodnie z przepisami prawa. Nie dopuszcza się dostarczenia rozwiązania zmuszającego do uprzedniego wydzielania zbiorów (np. przez administratora) lub określenia listy wydzielonych zbiorów przed rozpoczęciem rejestracji spraw dla danego symbolu JRWA. 4.4.2.2. Prowadzenie spraw. ESZD umożliwia przechowywanie w ramach spraw pełnej dokumentacji związanej ze sprawą, bez względu na formę dokumentacji (cyfrowe odwzorowania, naturalne dokumenty elektroniczne, wiadomości e-mail itp.). Każda sprawa jest grupowana w zbiory, które są udostępniane użytkownikom w formie tzw. spisów spraw (zgodnie z przepisami prawa), które uprawniony użytkownik może przeglądać, filtrować i opatrywać uwagami. ESZD oddzielnie prezentuje sprawy aktualnie obsługiwane, zakończone, ostatecznie zamknięte, wstrzymane, podwładnych, odnalezione. Uprawnione stanowisko musi mieć możliwość: oznaczania spraw słowami kluczowymi pochodzącymi z uprzednio zdefiniowanego słownika oraz wyszukiwanie spraw wg tego kryterium, powiązania wieloma niezależnymi relacjami sprawy z innym obiektem (np. dokumentacją, sprawą) oraz opatrywania sprawy komentarzami, gdzie komentarze mogą być prywatne (dostępne tylko dla autora) albo publiczne (dostępne dla wszystkich). Uprawnione stanowisko (co najmniej stanowisko merytoryczne oraz stanowiska pomocnicze z odpowiednio wysokimi uprawnieniami) musi 19
mieć możliwość dołączania do istniejących spraw dokumentacji wytworzonej poza sprawą (np. przesyłek przychodzących). ESZD musi umożliwiać uprawnionemu stanowisku wstrzymać lub wznowić obsługę sprawy, co musi wiązać się z automatycznym przeliczeniem czasu przeznaczonego na rozpatrzenie sprawy. Wstrzymując lub wznawiając obsługę sprawy użytkownik musi podać datę i uzasadnienie operacji. Uprawniony użytkownik musi mieć możliwość określenia listy stron sprawy, poprzez wskazanie interesantów z bazy interesantów. Uprawniony użytkownik musi mieć możliwość wygenerowania na żądanie metryki sprawy, zgodnej z przepisami prawa. Zakańczanie obsługi sprawy musi obejmować oznaczenie momentu zakończenia obsługi merytorycznej sprawy i zakończenia odliczania czasu przeznaczonego na rozpatrzenie i odrębne w czasie oznaczenie ostatecznego zakończenia procedowania sprawy. Sprawy ostatecznie zakończone można jedynie przeglądać lub wznowić ich procedowanie. ESZD musi kontrolować i nadzorować wersjonowanie dokumentacji dołączanej do sprawy. 4.4.2.3. Wystawianie dokumentacji. Uprawniony użytkownik musi mieć możliwość tworzenia (wystawiania) dokumentacji w ramach danej sprawy (np. decyzji, korespondencji, zaświadczeń itp.) i dołączania jej do sprawy. Aplikacja musi udostępniać podręczną listę dokumentów jakie można utworzyć w ramach danego procesu sprawy, zgodnie z konfiguracją ścieżki procesu oraz uprawnieniami stanowiska. Tworzone dokumenty muszą być automatycznie dołączane do sprawy. Z poziomu formularza metryki dokumentu użytkownik musi mieć możliwość powiązania dokumentu z interesantami z bazy interesantów wskazując poszczególnych interesantów lub hurtowo powiązać z dokumentem wszystkie stron sprawy przez jednokrotne uruchomienie odpowiedniej funkcji. ESZD musi umożliwić lokalny zapis lub uruchomienie w zewnętrznej aplikacji plików dokumentów w dowolnym momencie i wielokrotnie (np. celem eksportu lub wydruku), a także kopiowanie dokumentów w dowolnej liczbie w ramach aplikacji i reguł workflow. Aplikacja musi udostępniać informacje o wszystkich wytworzonych egzemplarzach (kopiach) dokumentu. 4.4.2.4. Kierowanie dokumentacji do wysyłki. Uprawnione stanowisko musi mieć możliwość skierowania do wysyłki dokumentów, których status na to pozwala (np. ostatecznie zaakceptowanych decyzji) i jest to zgodne z ich ścieżką procesu. Kierując dokument do wysyłki stanowisko musi mieć możliwość powiązania dokumentu z interesantami z bazy interesantów wskazując poszczególnych interesantów lub hurtowo powiązać z dokumentem wszystkie stron sprawy przez jednokrotne uruchomienie odpowiedniej funkcji, a także musi istnieć możliwość przypisywania dokumentu do 20