Lp. Opis wymagania 1 Wymagania ogólne dotyczące budowy SEOD

BDG/12/2011/PN
zał. nr 3
Wymagania funkcjonalne
Spełnienie wymogów
Lp. Opis wymagania
TAK/NIE
1
Wymagania ogólne dotyczące budowy SEOD
1.1
SEOD musi umożliwiać wydajną, efektywną i ergonomiczną pracę
co najmniej 400 pracowników równocześnie, z dostępem przez
przeglądarkę internetową w środowisku LAN oraz WAN
równocześnie. Centralna lokalizacja serwera SEOD w Wyższym
Urzędzie Górniczym z dostępem przez LAN i WAN.
1.2
SEOD musi być przygotowany na rozbudowę w przyszłości i
obsługę dodatkowej ilości użytkowników. Docelowa pojemność w
perspektywie 5 lat to 550 użytkowników.
Udzielone licencje SEOD oraz wszystkich komponentów
1.3
potrzebnych do użytkowania SEOD, w tym komponentów firm
trzecich, muszą być bezterminowe, a ich użytkowanie nie może
wiązać się i być uzależnione w przyszłości, od ponoszenia przez
Zamawiającego dodatkowych kosztów.
1.4
Zamawiający nie wymusza konkretnego rozwiązania planu
licencyjnego, pod warunkiem, że użytkownicy kończący pracę w
systemie (odchodzący na emeryturę, zwalniani itp.) będą uzyskiwać
status np. nieaktywny oraz zwalniać licencję dla nowego
użytkownika, jednocześnie pozostając w systemie, celem
identyfikacji spraw które prowadzili w przeszłości, bez konieczności
przekazywania ich zamkniętych spraw innemu użytkownikowi.
Użytkownicy tacy nie mogą się też pojawiać na listach wyboru
aktualnie aktywnych użytkowników. Inaczej mówiąc SEOD musi
pozwalać niezmiennie w czasie na pracę co najmniej 400 aktywnym
użytkownikom.
W wypadku zaoferowania wariantu licencyjnego w postaci ilości
1.5
jednocześnie zalogowanych użytkowników i automatycznego
zamykania sesji po określonym czasie nieaktywności, SEOD musi
pozwalać na konfigurację czasu po którym nastąpi wylogowanie
sesji użytkownika do min. 120 min Użytkownicy muszą posiadać
aktywną sesję pomimo braku aktywności przez min.120 min
SEOD musi posiadać wbudowane i możliwe do wskazania funkcje
1.6
zbudowane z użyciem mechanizmów AJAX. Funkcje takie powinny
występować co najmniej w:
• Rejestracji dokumentu – podczas pobierania danych
podmiotu będącego adresatem lub nadawcą dokumentu
• Generowaniu listy folderów (przynajmniej na jednym z
silników baz danych)
• Podczas generowania listy użytkowników przy rozsyłaniu
dokumentów lub przydzielaniu spraw
• Podczas weryfikowania sumy kontrolnej pliku
dołączonego do sprawy lub dokumentu
Strona 1 z 51
1.7
1.8
1.9
1.10
1.11
1.12
• Podczas korzystania z funkcji przejęcia danych
(przekazywanie danych pomiędzy użytkownikami systemu)
• Podczas edycji danych pracownika (przy wyborze
stanowiska pracy)
• Module delegacji, przy wyborze środka lokomocji
• Module urlopów przy wyliczaniu liczby dni urlopu
SEOD musi być zbudowany w architekturze, co najmniej
trójwarstwowej.
Serwer SEOD musi być niezależny od platformy systemowej, i
powinien poprawnie funkcjonować pod kontrolą systemów
operacyjnych z rodziny UNIX np. Linux oraz Windows.
Aplikacja musi mieć budowę modułową umożliwiającą
uruchamianie kolejnych funkcji poprzez zmianę parametrów
konfiguracji systemu. Przez moduł rozumie się wydzieloną
funkcjonalność systemu, której uruchomienie odnosi efekt w postaci
pojawienia się nowych funkcji i elementów w SEOD np.:
Terminarze, JRWAUG, Delegacje itp.
Budowa modułowa musi umożliwiać stopniowe uruchamianie
kolejnych funkcjonalności wraz ze wzrostem wiedzy oraz potrzeb
użytkowników, przeprowadzone przez użytkownika na prawach
administratora, poprzez zmianę parametrów systemu, bez potrzeby
zmiany kodów programu i pomocy programisty.
Żadne informacje wprowadzone do SEOD nie mogą być z niego
usunięte, nawet przez Administratora. Jedyną możliwością usunięcia
elementów z SEOD jest proces brakowania akt.
Wszystkie elementy SEOD muszą posiadać interfejs w języku
polskim. Jako element interfejsu zamawiający określa również
elementy konfiguracji poszczególnych części składowych systemu –
szczególnie część użytkownika oraz część administracyjną, jak
również wszystkie aplikacje wymagane przy pracy z systemem
SEOD. W języku polskim muszą być również wyświetlane
wszystkie komunikaty przekazywane przez SEOD, włącznie z
komunikatami o błędach.
SEOD musi być zbudowany w oparciu o dostępne na rynku i
stabilnie działające komponenty, które zostaną skonfigurowane i
uruchomione przez Wykonawcę w postaci spójnego systemu.
Konieczne jest by dostarczone komponenty posiadały wsparcie
producenta przez okres co najmniej równy wymaganej gwarancji na
system.
Strona 2 z 51
1.13
Wykonawca musi być producentem dostarczanego Systemu i musi
być uprawniony do wprowadzania modyfikacji w kodzie źródłowym
aplikacji. W przypadku gdy wykonawca oferuje moduły firmy
trzeciej musi być upoważniony przez producenta oprogramowania
do wprowadzania modyfikacji w kodzie źródłowym aplikacji, celem
ewentualnego dostosowania, obecnie i w przyszłości, systemu do
potrzeb Zamawiającego.
Modyfikacja kodów źródłowych nie jest przedmiotem postępowania.
1.14
Dostarczony SEOD musi być w pełni konfigurowalny bez
konieczności modyfikacji kodu źródłowego, w którym został
utworzony. Niedopuszczalne jest by dostarczone oprogramowanie
wymagało parametryzacji poprzez modyfikację kodu aplikacji oraz
angażowania programistów.
Wszystkie elementy SEOD muszą umożliwiać poprawną pracę
poprzez przeglądarkę internetową co najmniej: Internet Explorer w
wersji 8 lub nowszej, Firefox w wersji 3 lub nowszej, Chrom w
wersji 10 lub nowszej.
Skanowanie dokumentów, podpis elektroniczny, funkcje integracji z
zewnętrznym oprogramowaniem pocztowym np. Microsoft Outlook,
edycja plików - mogą być realizowane poprzez aplikacje instalowane
po stronie stacji roboczej.
SEOD musi udostępniać możliwość konfiguracji na poziomie
globalnym oraz lokalnym.
1. Przez poziom globalny należy rozumieć poziom aplikacji,
gdzie opcja konfiguracyjna ma zastosowanie dla całej aplikacji –
dostępny dla użytkowników posiadających specjalne
uprawnienia. Wymagane jest minimalnie konfigurowanie:
a. wspólnej struktury organizacyjnej,
b. folderów publicznych,
c. rejestrów dokumentów,
d. słowników.
2. Przez poziom lokalny należy rozumieć poziom profilu konta
pojedynczego użytkownika SEOD gdzie opcja konfiguracyjna
ma zastosowanie jedynie dla tego konta – dostępny dla
wszystkich użytkowników systemu. Wymagane jest minimalnie:
a. Włączanie i wyłączanie powiadomień o nowych
elementach przesłanych do użytkownika,
b. Wybór sortowania (rosnąco, malejąco, alfabetycznie)
elementów systemu tj. spraw, dokumentów, notatek,
1.15
1.16
c. Określenie kolumn widocznych na listach obiektów tj.
dokumenty, sprawy, rejestry, lista nowych dokumentów
(oczekujących na zarejestrowanie)
Strona 3 z 51
1.17
1.18
1.19
1.20
1.21
d. Określanie domyślnego ustawienia dla filtrów
dokumentów i spraw,
e. Określanie domyślnego rozmiaru i nazwy czcionki
używanej podczas tworzenia raportów we wbudowanym
w aplikację edytorze WYSIWYG
f. Definiowania kont poczty e-mail
g. Definiowania zakresu godzin wyświetlanych w
terminarzach
h. Określania domyślnego celu rozsyłania dokumentu
oraz przydzielenia sprawy
i. Określenia w jakim profilu użytkownika aplikacja
domyślnie ma być uruchamiana (np. administrator,
użytkownik zwykły czy operator skanujący)
SEOD musi posiadać możliwość zarządzania strukturą folderów z
poziomu lokalnego (przez każdego użytkownika) oraz globalnego (z
poziomu użytkownika posiadającego specjalne uprawnienia –
posiadającego możliwość tworzenia folderów i przydzielania
dostępu do tych folderów wybranym użytkownikom).
Foldery powinny być rozumiane jako kontenery służące do
przechowywania informacji takich jak dokumenty lub sprawy i być
niezależne od systematyki wynikającej z Jednolitego Rzeczowego
Wykazu Akt Urzędów Górniczych.
SEOD musi posiadać obsługę mechanizmu przeciągnij i upuść (ang.
Drag And Drop) umożliwiając przenoszenie dokumentów, spraw,
notatek do wybranych folderów utworzonych w SEOD.
SEOD musi być zabezpieczony przed lukami bezpieczeństwa
wynikającymi z technologii, w której został stworzony. Szczególny
nacisk musi zostać położony na zabezpieczenie aplikacji przed
wstrzykiwaniem kodu SQL (SQL injection) oraz Cross Site
Scripting. Odpowiednie mechanizmy zabezpieczające powinny być
wbudowane w aplikację. W przypadku wykrycia próby wykonania
ataku metodą SQL injection, system powinien wyświetlić (lub
zapisać w logach aplikacji) komunikat informujący o wykryciu
próby ataku.
SEOD musi gromadzić pliki dokumentów,skany, załączniki do
spraw, w odrębnym repozytorium plikowym. W bazie danych mogą
znajdować się jedynie metadane opisujące dokumenty, pliki, raporty
itp. elementy wchodzące w skład spraw prowadzonych w SEOD.
SEOD musi umożliwiać rozdzielenie repozytorium plikowego oraz
bazy danych na odrębne serwery.
Aplikacja musi zabezpieczać repozytorium plikowe tak aby nie było
ono bezpośrednio dostępne dla użytkowników (nie mogą to być stałe
hiperłącza do plików).
Strona 4 z 51
1.22
1.23
1.24
1.25
SEOD musi posiadać możliwość współpracy z przynajmniej jednym
silnikiem bazy danych opartym o technologię „open source”, co
najmniej MySQL 5 lub nowszy lub PostgreSQL 8 lub nowszy, oraz
przynajmniej jednym komercyjnym silnikiem bazy danych, co
najmniej MSSQL.
SEOD musi posiadać mechanizm zabezpieczający pliki
przechowywane w repozytorium plikowym przed ich zmianą. Nawet
jeśli plik w repozytorium plikowym zostanie zmieniony – aplikacja
musi umożliwiać użytkownikowi zweryfikowanie takiego pliku.
Zabezpieczenie powinno być oparte co najmniej o algorytm MD5.
SEOD musi posiadać funkcję umożliwiającą wgląd do
skompresowanych plików w formatach co najmniej: ZIP, GZIP,
TAR, dołączanych do SEOD. Funkcja musi umożliwiać
wyświetlenie zawartości skompresowanego pliku bez konieczności
zapisywania go na stacji roboczej użytkownika i rozpakowywania.
SEOD musi spełniać podstawowe warunki bezpieczeństwa poprzez:
zapis operacji wykonywanych przez użytkownika w zakresie:
Zapis notatki do sprawy i do dokumentu,
Odczyt nowego dokumentu i nowej sprawy przesłanej do
użytkownika,
Zapis i modyfikacja pliku dodanego do dokumentu i sprawy,
Zablokowanie dostępu do sprawy lub dokumentu,
Utworzenie sprawy,
Nadanie lub usunięcie znaku sprawie,
Dołączenie oraz odłączenie dokumentu do/od sprawy,
Dodanie oraz usunięcie pliku dołączonego do dokumentu oraz
sprawy,
Dodanie notatki tekstowej do sprawy oraz dokumentu,
Akceptacja oraz odrzucenie pliku,
Przekazanie do akceptacji pliku,
Połączenie sprawy z wybranym kontaktem z bazy adresowej,
Dołączenie oraz odłączenie użytkownika do/od terminarza,
Modyfikacja opisu oraz innych parametrów sprawy,
Dołączenie oraz odłączenie maila do/od sprawy,
Wysłanie dokumentu mailem.
zapis w historii wszystkich zmian zachodzących w sprawach,
dokumentach lub innych elementach mających wpływ na
prowadzone sprawy.
szyfrowanie informacji przesyłanych pomiędzy użytkownikiem a
systemem z użyciem protokołu SSL,
możliwość pracy w systemie poprzez VPN z określonej lokalizacji
geograficznej.
Strona 5 z 51
1.26 Wszystkie elementy SEOD muszą być dostępne poprzez Graficzny
Interfejs Użytkownika tzw. GUI, zgodny co do zasady i obsługi z
tzw. okienkowymi systemami operacyjnymi i dostępny przez
przeglądarkę internetową.
1.27 SEOD musi umożliwiać rejestracje chronologiczną spraw zgodnie z
JRWAUG odrębnie dla każdej jednostki organizacyjnej
Zamawiającego
2
Instrukcja obsługi .
2.1
SEOD musi być opatrzony polskojęzyczną instrukcją obsługi
przeznaczoną do oferowanej wersji (zwanej dalej instrukcją)
opisującą szczegółowo zarówno aspekty techniczne (instalację,
konfigurację, wymagane komponenty do poprawnej pracy) oraz
funkcjonalne wszystkich elementów.
Instrukcja musi być podzielona zgodnie z częściami składowymi
2.2
SEOD oraz jego modułami/funkcjonalnościami.
2.3
Instrukcja musi być opracowana w sposób umożliwiający
zidentyfikowanie sposobu wykonania określonej czynności np.:
Zakładanie sprawy - użyj funkcji „Załóż sprawę” znajdującej się w
… itd. Instrukcja musi być aktualizowana po każdorazowej zmianie
części składowej SEOD dokonywanej po stronie Zamawiającego.
Instrukcja musi zawierać zrzuty ekranów odnoszące się do
opisywanych funkcji.
2.4
Instrukcja SEOD musi zawierać co najmniej następujące elementy:
opis działania i zastosowanie poszczególnej części składowej
systemu z dokładnością do pojedynczej funkcji, oraz przycisków
interfejsu wykorzystywanych do wykonywania konkretnych
operacji w systemie.
informacja dotycząca poszczególnych funkcji zastosowanych w
częściach składowych SEOD musi być przekazana w formie
instrukcji krok po kroku opisującej wykonanie określonej
czynności.
2.5
Instrukcja opisująca funkcjonalność musi być przygotowana w
postaci:
instrukcji dostępnej co najmniej z poziomu SEOD (przeglądarki
internetowej) w postaci HTML albo XML,
pliku pomocy Windows Help (CHM),
piku PDF.
Zawartość dokumentacji elektronicznej powinna być odpowiednio
zindeksowana.
2.6
Instrukcja w formacie CHM, PDF lub innym tekstowym powinna
być wyposażona w indeks wyrażeń oraz musi umożliwiać proste
wyszukiwanie w treści.
Strona 6 z 51
2.7
2.8
2.9
3
3.1
Dla SEOD instrukcja musi być zintegrowana z interfejsem
użytkownika; zawierać dostęp do spisu treści oraz wyszukiwania z
poziomu SEOD. Treści zawarte w instrukcji dostępnej z poziomu
interfejsu użytkownika muszą być identyczne jak dostarczane w
plikach chm, html oraz pdf.
Wymagane jest załączenie instrukcji oferowanego SEOD do oferty
na nośnikach elektronicznych: płycie CD lub DVD. Na podstawie
załączonej instrukcji nastąpi weryfikacja funkcjonalności
oprogramowania będącego przedmiotem postępowania. W zakresie
objętym instrukcją Zamawiający wymaga dostarczenia produktu
gotowego, tj. istniejącego na dzień opublikowania postępowania.
Wykonawca wskaże w odrębnym dokumencie miejsca (numery,
zakresy stron) w instrukcji obsługi opisujące realizację każdego
wymagania funkcjonalnego. Dokument winien być złożony jako
integralna część oferty.
Administracja systemem
SEOD musi posiadać narzędzia umożliwiające jego konfigurację
poprzez graficzny interfejs (GUI). Konfiguracji poprzez graficzny
interfejs muszą podlegać:
• Struktura organizacyjna oraz podległości służbowe,
• Rejestry dokumentów i spraw, Jednolity Rzeczowy
Wykaz Akt Urzędów Górniczych,
• Znak separatora w znaku sprawy i oznaczenia dokumentu
(do wyboru co najmniej znaki: ‘/’ i ‘.’)
• Budowa znaku sprawy i oznaczenia dokumentu w
sprawie (tak aby były zgodne z instrukcją kancelaryjną
Zamawiającego)
• Definicje rodzajów stanowisk (np.: dyrektor, naczelnik)
przypisanych do opisu każdego ze stanowisk,
• Definicje kategorii dokumentów, plików, notatek i spraw
umożliwiające grupowanie tych elementów według kategorii.
• Cele (np.: do realizacji, do dekretacji), w których przesyła
się dokument,
• Definicje sposobów dostarczenia dokumentu,
• Definicje folderów i przydzielania dostępu do tych
folderów wybranym użytkownikom (foldery rozumiane jako
kontenery dla dokumentów),
o Do wybranego folderu możliwe musi być
przypisanie reguły globalnej umożliwiającej
przeniesienie wybranego dokumentu do tego folderu.
• Definicje stanów spraw (np.: zamknięta, archiwalna,
zawieszona),
Strona 7 z 51
4
4.1
4.2
• Definicje formularzy umożliwiające użycie następujących
typów pól:
o Pole tekstowe,
o Pole liczbowe,
o Pole opisu,
o Pole wyboru (check),
o Pole opcji (radio),
o Pole kombo,
o Pole listy,
o Pole daty.
• Szablony dokumentów,
• Definiowanie terminarzy i przydzielanie uprawnień
dostępu do nich użytkownikom,
• Użytkownicy,
• Rezerwacje zasobów i przydzielanie uprawnień do ich
rezerwacji wybranym użytkownikom,
• Definicje urlopów,
• Definicje zastępstw,
• Definicje delegacji,
• Definicje ścieżek procesów workflow,
• Definicje skrytek i skrzynek przewidzianych do integracji
z ePUAP
Dokumenty
Podczas rejestracji dokumentu SEOD musi umożliwiać
przechodzenie pomiędzy kolejnymi polami formularza rejestracji
przy pomocy przycisku TAB (tabulacji).
SEOD musi umożliwiać opisanie dokumentu przynajmniej
następującymi metadanymi:
• Podstawowa klasyfikacja: przychodzący, wychodzący,
wewnętrzny.
• Numer dokumentu – nadawany automatycznie przez
SEOD podczas rejestracji dokumentu, unikalny,
jednoznacznie identyfikujący rejestrowany dokument w
obrębie całego systemu (na podstawie jednego wspólnego
rejestru chronologicznego wszystkich pism w roku przychodzących, wychodzących i wewnętrznych - 6 znaków
numerycznych z poprzedzającymi zerami),
• Sposób dostarczenia – pole słownikowe np.: list zwykły,
email, ESP itd.
• Oznaczenie komórki do której kwalifikowany jest
dokument – pole słownikowe,
• Kategoria dokumentu – pole słownikowe np.: podanie,
wniosek, skarga itd.
Strona 8 z 51
• Adresat/Nadawca - do wyboru z listy adresowej SEOD (z
automatycznym wypłnieniem zdefiniowanych pól) na
podstawie pierwszych wprowadzonych liter (podpowiedzi
kontekstowe) oraz możliwy do wpisania ręcznego w wypadku
niedopasowania do istniejącego w bazie, z uwzględnieniem
danych teleadresowych, co najmniej pola:
4.3
4.4
o Osoba prawna lub fizyczna,
o Skrót,
o NIP,
o REGON,
o PESEL,
o Skrytka pocztowa,
o Miasto,
o Kod pocztowy,
o Ulica,
o Numer budynku,
o Numer lokalu,
o Kraj,
o Województwo,
o Powiat,
o Gmina,
• Data ważności,
• Numer nadawczy,
• Opis dokumentu,
• Słowa kluczowe,
• Lokalizacja fizyczna,
• Dowolnie zdefiniowane pola – dostosowywane do
wybranej kategorii rejestrowanego dokumentu.
SEOD musi posiadać możliwość rozsyłania dokumentów do
zdefiniowanej liczby odbiorców bez konieczności jej powielania
(każdy dokument w systemie musi istnieć tylko w jednym
egzemplarzu). Wszystkie adnotacje i operacje wykonywane przez
użytkowników powinny być zapisywane na tym samym dokumencie.
SEOD musi posiadać możliwość dołączania do dokumentów i spraw
elementów w formie elektronicznej, co najmniej: plików, informacji
w postaci tekstowej edytowanej z poziomu SEOD, dokumentów
zarejestrowanych w SEOD, spraw założonych w SEOD.
Strona 9 z 51
4.5
4.6
4.7
4.8
4.9
4.10
4.11
SEOD musi posiadać możliwość zarządzania wielopoziomową
strukturą folderów (wyświetlającą zagnieżdżoną strukturę folderów
w postaci drzewa), umożliwiającą grupowanie dokumentów i spraw.
W tym celu każdy użytkownik musi posiadać dostęp do
odpowiedniej funkcji umożliwiającej mu wybór lokalizacji, w której
ma zostać utworzony, usunięty lub zmieniony folder.
SEOD musi umożliwiać wydrukowanie poświadczenia przyjęcia
pisma. Poświadczenie musi zawierać informacje jednoznacznie
identyfikujące dokument, datę jego rejestracji oraz przez kogo został
on przyjęty i przez kogo został złożony. Funkcja musi być dostępna
z poziomu interfejsu SEOD po rejestracji dostarczonego dokumentu.
SEOD musi umożliwiać powiadamianie użytkownika o zmianach
zachodzących na jego koncie. Powiadomienia muszą dotyczyć co
najmniej: otrzymania nowego dokumentu, otrzymania nowej sprawy,
dołączenia do dokumentu lub sprawy pliku, dołączenia do
dokumentu lub sprawy notatki tekstowej. Przesyłana informacja
powinna zawierać tytuł oraz treść. Treść powinna w jednoznaczny
sposób identyfikować element, którego dotyczy powiadomienie.
SEOD musi umożliwiać włączanie oraz wyłączanie powiadamiania
użytkownika o zmianach w elementach, do których ten ma dostęp.
Wyłączenie powiadamiania powinno być dostępne na poziomie
grupy elementów jak i pojedynczego elementu np.: dla wszystkich
spraw, dla wybranej sprawy.
SEOD musi umożliwiać ustawienie następujących parametrów,
zapisywanych w metadanych dokumentu, podczas dekretacji:
cel – pole słownikowe umożliwiające wybór celu dekretacji,
zwrotu dekretacji
pilny – oznaczenie dokumentu jako pilny,
data ważności – data ważności dokumentu,
notatka służbowa – umożliwiające wpisanie informacji dla
odbiorcy.
uwagi do dekretacji – umożliwiające przekazanie uwag dot.
dekretowanego dokumentu do adresata dekretacji.
SEOD musi zawierać mechanizm tworzenia wersji dla plików,
dokumentów oraz notatek tekstowych. Użytkownik musi mieć
możliwość dodania kolejnej wersji pliku. Wszystkie zmiany muszą
zostać odnotowane automatycznie w SEOD. SEOD musi
sygnalizować próbę użycia nieaktualnej wersji poprzez wyświetlenie
odpowiedniej informacji ostrzegawczej w interfejsie użytkownika.
Wyszukiwanie proste musi umożliwiać pełnotekstowe przeszukanie
elementów SEOD. Przez wyszukiwanie pełnotekstowe rozumie się
przeszukiwanie w treści elementów dołączanych do spraw, czy
dokumentów (w treści raportów, notatek, plików tekstowych).
Strona 10 z 51
4.12
4.13
4.14
4.15
4.16
W przypadku gdy użytkownik nie posiada uprawnień
umożliwiających mu wyświetlenie treści odnalezionego elementu,
SEOD musi informować o tym fakcie podczas dostępu do tego
elementu poprzez wyświetlenie odpowiedniego komunikatu.
Po odnalezieniu elementów (spraw, dokumentów lub innych) SEOD
powinien grupować je w formie zakładek według ich typu (sprawy,
dokumenty itd.) oraz wyświetlać liczbę trafień odnalezionych dla
wybranego typu.
SEOD powinien wyróżniać kolorem odnalezioną frazę w liście
wybranych elementów umożliwiając użytkownikowi identyfikację
jej wystąpienia.
Podczas wyszukiwania prostego możliwe powinno być użycie
następujących znaków specjalnych:
• % (procent) – umożliwiający wyszukanie innych słów za,
przed lub za oraz przed wyszukiwanym słowem, np.:
%słowo, Słowo%, %słowo%,
• (podkreślenie) – umożliwiające wyszukanie słów, których
pełne znaczenie nie jest znane. Ilość znaków podkreślenia w
słowie oznacza ilość znaków, które powinny zostać
zastąpione, np.: sł__o (zostanie odnalezione słowo),
____słowo (zostanie odnalezione np.: pomysłowo),
• „” cudzysłów – umożliwiający odnalezienie wyrazów
następujących po sobie,
• + (plus) – słowo za znakiem + plus (pomiędzy znakiem
plus a następującym po nim słowie nie może występować
spacja) musi znajdować się w wyszukiwanej frazie (dla słowa
po znaku + stawiany jest warunek AND, a dla pozostałych
słów w wyrażeniu OR). W przypadku gdy w wyrażeniu
występuje znak +słowo i nie zostanie ono odnalezione w
zasobach systemu to wynik powinien wynosić zero mimo, że
pozostałe słowa zostaną odnalezione.
• – (minus) – słowo napisane za znakiem – (minus)
(pomiędzy znakiem minus a następującym po nim słowie nie
może występować spacja) zostanie wykluczone z
wyszukiwanej frazy (dla słowa po znaku - stawiany jest
warunek AND, a dla pozostałych słów w wyrażeniu OR).
Zwrócone powinny być tylko te wyrażenia, które nie
zawierają tego słowa.
SEOD musi posiadać mechanizm rejestracji dokumentów dostępny
dla dowolnej liczby jednostek organizacyjnych Zamawiającego,
rozproszonych geograficznie, z możliwością rozróżnienia w którym
punkcie był rejestrowany każdy z dokumentów oraz jakie osoby
dokonały rejestracji każdego z dokumentów.
Strona 11 z 51
4.17
4.18
4.19
4.20
4.21
4.22
SEOD musi umożliwiać rozdzielenie procesu rejestracji dokumentu
co najmniej na podprocesy: rejestracji i skanowania, w taki sposób
by każda z tych czynności była możliwa w innej lokalizacji
geograficznej (poprzez lokalizację geograficzną należy rozumieć
inny komputer, pokój w budynku, różne pokoje w różnych
budynkach, różne budynki w różnych miastach itd.). Równocześnie
użytkownik obsługujący wszystkie lub tylko przypisane podprocesy
musi mieć możliwość pracy bez przelogowywania się (podawania
loginu i hasła) pomiędzy rolami (kontami) – jednokrotne logowanie.
SEOD musi umożliwiać lokalizację dokumentów w postaci
papierowej oraz możliwość zmiany informacji o lokalizacji.
Informację powinien zmienić każdy użytkownik za pomocą
odpowiedniej funkcji w SEOD. W celu zmiany informacji o
lokalizacji fizycznej użytkownik powinien wybierać z listy osób
posiadających dostęp do dokumentu odpowiednią i wysyłać jej
żądanie akceptacji przekazanego dokumentu. Użytkownik, do
którego przekazano żądanie staje się odpowiedzialny za oryginał
dokumentu, dopiero po potwierdzeniu przez niego faktu odebrania
oryginału dokumentu. Do czasu potwierdzenia odebrania
dokumentu, osoba przekazująca oryginał, powinna mieć możliwość
wycofania informacji o przekazaniu oryginału dokumentu.
Akceptacja musi oznaczać zmianę informacji o użytkowniku
posiadającym wersję papierową dokumentu.
SEOD musi umożliwiać łączenie dowolnych dokumentów ze sobą
oraz ze sprawami. Z poziomu dokumentu muszą być widoczne
wszystkie połączenia ze sprawami oraz innymi dokumentami.
Połączenia muszą być widoczne w formie tekstowej lub graficznej
umieszczonej w metadanych lub informacjach uzupełniających
dokumentu.
SEOD musi umożliwiać rejestrację dokumentu przez każdego
użytkownika oraz możliwość przekazania dokumentu do rejestracji
innemu użytkownikowi (z odpowiednimi uprawnieniami).
Rejestracja dokumentu polegać będzie na wypełnieniu formatki
opisującej ten dokument oraz zatwierdzeniu tego opisu. Jeżeli
użytkownik opisuje skan dokumentu to podczas rejestracji musi
wraz z formatką na jednym ekranie (w tym samym czasie) widzieć
treść rejestrowanego dokumentu, bez przełączania okien.
SEOD musi posiadać możliwość rejestracji kosztów w przypadku
rejestracji korespondencji związanej z opłatami. W przypadku
rejestracji dokumentu musi istnieć możliwość dodania informacji
np.: o kosztach poniesionych w związku z doręczeniem przesyłki.
Dokumenty przyłączone do spraw muszą dziedziczyć znaki nadane
tym sprawom wraz z indywidualnym oznaczeniem dokumentu.
Strona 12 z 51
4.23
4.24
4.25
4.26
4.27
5
SEOD musi umożliwiać dołączenie jednego dokumentu do wielu
spraw jednocześnie. W takim przypadku dokument musi dziedziczyć
znaki ze wszystkich spraw, do których został dołączony. Wszystkie
znaki muszą być widoczne z poziomu dokumentu. Po wybraniu
odpowiedniego znaku musi nastąpić przekierowanie do
odpowiedniej sprawy, a sprawa wyświetlona zgodnie z
uprawnieniami użytkownika.
Po najechaniu na znak sprawy (z poziomu dokumentu) musi pojawić
się informacja dostępna dla wszystkich użytkowników posiadających
wybrany dokument dołączony do sprawy, składająca się z
następujących elementów:
• Nazwa sprawy nadana przez użytkownika,
• Opis wybranego hasła z JRWAUG,
• Numer sprawy (w wybranej komórce organizacyjnej oraz
roku),
• Właściciel sprawy (Imię i Nazwisko),
• Data utworzenia,
• Data rozpoczęcia pracy nad sprawą,
• Data zakończenia pracy nad sprawą,
• Stan sprawy.
Funkcja korespondencji seryjnej SEOD musi być dostępna za
pomocą kreatora, który krok po kroku przeprowadza użytkownika
przez proces jej tworzenia.
Po uruchomieniu kreatora korespondencji seryjnej dostępne muszą
być następujące opcje:
• wybór adresatów – możliwość wyboru określonych
podmiotów połączonych ze sprawą. Dostępne powinny być
przynajmniej pola: Nazwa (Imię i Nazwisko), Ulica i numer
domu, Kod i Miejscowość,
• koperty i dokumenty (koperty – umożliwia wydruk
seryjny kopert, dokumenty – umożliwia wydruk seryjny
dokumentów na podstawie zdefiniowanych w systemie
szablonów, w obu przypadkach poprzez naniesienie na nie
danych teleadresowych),
• ustawienia rozmiaru strony/koperty (A4, A3 i co najmniej
5 najbardziej popularnych wydruków),
• wybór w zakresie wydrukowania znaku sprawy na
kopercie,
• wybór szablonu z repozytorium zdefiniowanych
szablonów, na podstawie którego powstanie dokument.
Każdy z użytkowników systemu powinien posiadać możliwość
rejestracji nowych dokumentów z plików załączanych do sprawy (o
ile administrator nada użytkownikowi takie uprawnienie).
Sprawy
Strona 13 z 51
5.1
5.2
5.3
5.4
5.5
5.6
SEOD musi posiadać mechanizmy pracy grupowej umożliwiające
np.: wspólną pracę nad prowadzonymi sprawami i dokumentami.
Przez wspólną pracę należy rozumieć dostęp do tych samych
informacji dowolnej grupie użytkowników bez pojawiania się
konfliktów w jednym czasie.
SEOD musi posiadać możliwość wglądu do spraw z poziomu
dokumentu oraz wglądu do dokumentów z poziomu spraw zgodnie z
posiadanymi uprawnieniami.
SEOD musi zapewnić możliwość zablokowania dostępu do danej
sprawy/dokumentu dla danego użytkownika któremu wcześniej
sprawa/dokument został przydzielony. Po zablokowaniu dostępu
użytkownik traci wgląd do wybranej sprawy lub/i dokumentu oraz
wszystkich informacji, które były z nimi powiązane.
Administrator SEOD musi posiadać możliwość definiowania
wzorców spraw. Wzorce spraw muszą umożliwiać powiązanie z
kategoriami JRWAUG. Każdy wzorzec sprawy powinien mieć
możliwość zdefiniowania etapów załatwiania sprawy.
SEOD musi być wyposażony w mechanizm akceptacji, który
umożliwia co najmniej:
Akceptację przez jednego użytkownika – element jest
zaakceptowany tylko przez jednego użytkownika (jeden z jeden)
Przesłanie dokumentu do wielu i akceptację przez jednego z nich –
element jest zaakceptowany gdy tę operację wykona jeden z grupy
użytkowników (np.: jeden z trzech)
Przesłanie i akceptacje przez wielu użytkowników – element jest
zaakceptowany gdy tę operację wykona większość użytkowników
(np.: dwóch z trzech)
Przesłanie i akceptację przez wszystkich – element jest
zaakceptowany gdy tę operację wykonają wszyscy użytkownicy
(np.: trzech z trzech)
SEOD musi umożliwiać przesyłanie do akceptacji plików
załączonych do spraw czy zeskanowanych dokumentów oraz
informacji w postaci tekstowej stworzonej poprzez wbudowany w
SEOD edytor WYSIWYG.
Istotne jest aby akceptacja była odrębnym mechanizmem – a nie
prostym procesem Workflow – tak aby nie było konieczności
definiowania procesu workflow do realizacji mechanizmu
akceptacji.
SEOD musi umożliwiać przeglądanie historii zmian dotyczącej
elementów z określeniem czasu i opisu zmian, informacją o
osobach, które tych zmian dokonały, elementu, którego dotyczy
zmiana oraz czynności, której dotyczy zmiana. Konieczne jest
umożliwienie filtrowania historii zmian według następujących
parametrów:
użytkownika, który wykonał operację,
Strona 14 z 51
5.7
5.8
5.9
5.10
elementu, którego zmiana dotyczy (minimalnie 4 parametry:
dokument, sprawa, notatka, plik),
czynności (minimalnie trzy parametry: modyfikacja, dodanie,
usunięcie).
SEOD musi wyróżniać zmianę, która nastąpiła poprzez opisanie
elementu, w którym ta zmiana nastąpiła np.: dodano użytkownika,
zmieniono nazwę sprawy, itd.
SEOD musi posiadać możliwość sortowania historii zmian
względem daty wykonania operacji.
SEOD musi posiadać eksport historii zmian do sformatowanego
pliku tekstowego, w którym dane oddzielone są separatorami.
Historia zmian musi obejmować co najmniej zdarzenia w:
sprawie,
dokumencie,
strukturze organizacyjnej,
koncie użytkownika,
bazie teleadresowej,
zastępstwie,
pliku dołączonym do systemu,
notatce tekstowej dołączonej do systemu,
rezerwacjach zasobów
JRWAUG
SEOD musi umożliwiać graficzną prezentację informacji o
użytkownikach posiadających dostęp do wybranych elementów np.:
spraw lub dokumentów w postaci drzewa o strukturze hierarchicznej
(wielopoziomowej). Na podstawie tej informacji musi istnieć
możliwość identyfikacji użytkownika, który przydzielił określony
zasób opatrzony datą przydzielenia oraz kiedy wybrany użytkownik
odczytał przydzielone mu informacje.
SEOD musi umożliwiać hierarchiczne łączenie dowolnej ilości
spraw w relacji nadrzędna – podrzędna.
SEOD musi posiadać możliwość wyznaczenia osób lub osoby
prowadzącej sprawę posiadającej pełne uprawnienia do prowadzonej
sprawy. Musi istnieć również możliwość zdefiniowania referenta
sprawy.
SEOD musi posiadać możliwość zakładania spraw przez każdego
użytkownika i opisania jej co najmniej według następujących
parametrów:
znak sprawy – zgodny z instrukcją kancelaryjną Zamawiającego
nazwa – nadanie nazwy sprawie,
stan - np.: otwarta, zamknięta, zawieszona,
opis – nadanie rozszerzonego opisu sprawie,
termin rozpoczęcia oraz termin zakończenia pracy nad sprawą,
priorytet – np.: pilny, ważny, normalny.
Strona 15 z 51
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
SEOD musi również umożliwiać przypisanie dodatkowych
parametrów dla spraw za pomocą formularzy dynamicznie
przydzielanych do spraw o określonej kategorii lub powiązanych z
odpowiednim wzorcem.
SEOD musi posiadać mechanizm automatycznie łączący sprawę z
danymi teleadresowymi podmiotu, którego ta sprawa dotyczy.
Użytkownik musi posiadać możliwość połączenia sprawy z więcej
niż jednym podmiotem.
SEOD musi posiadać funkcję określenia cykliczności przypomnień
dla realizowanych spraw.
SEOD musi umożliwiać dzielenie spraw na sprawy podrzędne i
delegowania ich do różnych osób. System musi być wyposażony w
mechanizm umożliwiający hierarchiczne tworzenie spraw w
strukturze nadrzędna – podrzędna i przedstawienie tego połączenia
w postaci drzewa z zagnieżdżonymi sprawami podrzędnymi.
SEOD musi posiadać możliwość przekazywania spraw bez utraty
kontroli nad ich realizacją. Użytkownik po przekazaniu sprawy musi
mieć możliwość zachowania dostępu do tej sprawy. Przekazanie
sprawy powinno być realizowane poprzez wskazanie osoby
prowadzącej lub ustalenia referenta dla danej sprawy.
SEOD powinien generować spis spraw z użyciem co najmniej
następujących parametrów:
• komórka organizacyjna,
• symbol z JRWAUG,
• rok,
• data rozpoczęcia Od,
• data zakończenia Do,
• stan sprawy (np.: zakończona, otwarta itd.).
Raport powinien być generowany do postaci tabelarycznej i możliwy
do pobrania i zapisu w wersji XLS oraz PDF.
SEOD musi powiadamiać o przekroczonych terminach załatwienia
spraw poprzez oznaczanie tych spraw oraz możliwość filtrowania
spraw o przekroczonych terminach. Wyróżnienie powinno się
odbywać poprzez oznaczenie elementu specjalną flagą, a na listach
powinna to być widoczna np. ikona sygnalizująca przekroczenie
czasu załatwienia sprawy.
SEOD musi umożliwiać założenie sprawy bez konieczności
natychmiastowego nadania znaku sprawy zgodnego z JRWAUG.
Musi istnieć możliwość nadania znaku sprawy w każdej chwili oraz
zmiana znaku sprawy. Zmiana znaku sprawy musi być odnotowana
w historii sprawy.
System musi umożliwiać ponowne wykorzystanie usuniętego znaku
sprawy.
Strona 16 z 51
5.19
5.20
5.21
5.22
5.23
6
6.1
6.2
SEOD musi posiadać możliwość blokowania powtórnego
wykorzystania tego samego symbolu sprawy w przypadku jego
usunięcia lub zmiany.
SEOD musi posiadać funkcję umożliwiającą prowadzenie
korespondencji seryjnej z poziomu sprawy. Korespondencja
powinna być prowadzona względem podmiotów połączonych ze
sprawą.
SEOD musi informować o sprawach z przekroczonym terminem
poprzez wyskakujące okno zawierające spis wszystkich tych spraw
zgodnie z widokiem użytkownika.
SEOD musi umożliwiać definiowanie czasu względem którego ma
nastąpić powiadomienie o zbliżającym się terminie zakończenia
sprawy (np.: powiadom o terminie zakończenia na 5 dni przed jego
upływem).
SEOD musi umożliwiać automatyczne grupowanie elementów
należących do sprawy w formie drzewa rozdzielając takie elementy
jak: dokumenty, pliki, raporty, formularze, elementy do akceptacji.
Dodatkowo drzewo rozdzielające elementy powinno automatycznie
rozdzielać elementy ze względu na ich kategorię np. odrębna gałąź
dla dokumentów przychodzących skategoryzowanych jako wniosek,
skarga itp. To samo powinno dotyczyć plików czy raportów o ile
użytkownik określi ich kategorię.
Notatki
SEOD musi posiadać możliwość przesyłania notatek pomiędzy
użytkownikami, które nie muszą być powiązane ze sprawami czy
dokumentami. Notatka musi pełnić rolę wiadomości informacyjnej
przesyłanej pomiędzy użytkownikami systemu.
SEOD musi umożliwiać zdefiniowanie treści notatki za pomocą
wbudowanego w SEOD edytora WYSIWYG. Edytor powinien
pozwalać przynajmniej na takie podstawowe operacje formatowania
tekstu jak:
• Wybór czcionki
• Wybór rozmiaru czcionki
• Określenie nagłówków
• Pogrubienia, pochylenia, podkreślenia lub przekreślenia
czcionki
• Wstawiania tabel
• Ustawienia tekstu: do lewej, do prawej, do środka,
wyjustowanie
• Punktowanie
• Akapity
• Indeks górny, indeks dolny
• Wklejanie z edytorów zewnętrznych z możliwością
usunięcia formatowania
• Kolorowanie czcionek i tła
Strona 17 z 51
6.3
7
7.1
7.2
7.3
7.4
7.5
7.6
Edytor notatek musi pozwalać na wybór trybu pełnoekranowego,
drukowania tworzonej notatki oraz wstawiania hiperłączy.
Użytkownicy
SEOD musi posiadać funkcję umożliwiającą kontrolę liczby
zalogowanych użytkowników, oraz zdalne wylogowanie wszystkich
bądź wybranych użytkowników. Funkcja musi być dostępna dla
użytkownika posiadającego stosowne uprawnienia.
SEOD musi posiadać możliwość definicji przez każdego
użytkownika grup złożonych z użytkowników SEOD. Poprzez
użycie odpowiedniej funkcji każdy z użytkowników musi mieć
możliwość wpisania nazwy grupy np.: „Komisja powypadkowa ….”
i dodania do tej grupy odpowiednich użytkowników. Po
zdefiniowaniu użytkownik będzie mógł posługiwać się tą grupą w
celu przekazywania do jej członków informacji. Użytkownik musi
posiadać możliwość oznaczenia tej grupy jako domyślnej co
automatycznie zawęzi widok do członków tej grupy podczas
przekazywania informacji.
SEOD musi posiadać mechanizm przejmowania spraw i
dokumentów między użytkownikami. Przejęcie danych musi
skutkować przeniesieniem wszystkich informacji z konta jednego
użytkownika na konto innego użytkownika. Funkcja przejęcia
danych musi oferować możliwość przejęcia jednorazowo wszystkich
informacji pomiędzy profilami wybranych użytkowników lub wybór
poszczególnych danych które zostaną przejęte. Po przejęciu danych
wszystkie informacje historyczne muszą zostać zachowane (ze
szczególnym wskazaniem na informację na temat użytkownika,
który wykonał określone operacje w SEOD). Mechanizm musi być
dostępny z poziomu modułu administratora systemu wchodzącego w
skład SEOD.
SEOD musi umożliwiać ustalenie poziomu uprawnień do
modyfikacji bazy adresowej podmiotów, oraz określenie, który z
użytkowników może zarządzać bazą adresową na poziomie
usuwania, łączenia oraz modyfikowania wpisów. Takich
użytkowników musi być dowolnie definiowana ilość, w
szczególności wszyscy użytkownicy.
SEOD musi gwarantować możliwość przydzielenia roli
administratora do więcej niż jednego użytkownika systemu poprzez
nadanie mu odpowiednich uprawnień.
SEOD musi umożliwiać dodawanie użytkownika do struktury
organizacyjnej z poziomu formatki ustawień konta użytkownika.
Strona 18 z 51
7.7
7.8
7.9
7.10
8
8.1
SEOD musi umożliwiać przeglądanie danych dotyczących
logowania użytkowników do systemu. Rejestrowane muszą być
próby udanego i nieudanego logowania z datą i godziną. Dostęp do
tych informacji posiada administrator systemu. Informacje na temat
logowania użytkowników muszą być dostępne bezpośrednio z
poziomu interfejsu SEOD – w panelu administratora.
Użytkownik posiadający uprawnienia administracyjne musi posiadać
dostęp do informacji na temat obciążenia pracowników względem
wykonywanych czynności w określonych punktach zdefiniowanych
ścieżek workflow. Zestawienie obciążenia powinno być
przedstawione w czytelny sposób np. w formie tabelarycznej
pokazującej listę pracowników oraz ilość punktów przydzielonych
do pracowników.
SEOD musi umożliwiać użytkownikowi wybranie adresatów
informacji kierując się listą:
użytkowników zajmujących określone stanowisko np.: Dyrektor
Urzędu Górniczego, Naczelnik,
użytkowników w komórce organizacyjnej np.: Departament X,
Biuro Y,
użytkowników należących do grup zdefiniowanych przez
użytkownika np.: Sekretariaty, Kancelarie,
bezpośrednio do wybranego użytkownika.
SEOD musi umożliwiać jednoznaczną identyfikację użytkownika.
Wszystkie operacje zapisywane w historii i w logach aplikacji muszą
być przyporządkowane do konkretnego użytkownika.
Struktura organizacyjna
Użytkownik posiadający podwładnych musi mieć możliwość wglądu
do posiadanych przez nich dokumentów oraz spraw poprzez
dedykowaną funkcje wyświetlającą wszystkich podwładnych oraz
odwołania do posiadanych przez nich dokumentów oraz spraw.
Funkcja musi wyświetlać w widoku tabelarycznym (matrycy)
poszczególnych użytkowników wraz z informacją ilościową o
posiadanych sprawach: sumarycznie, przeterminowanych,
załatwionych w terminie, załatwionych po terminie, oczekujących na
załatwienie, anulowanych, zamkniętych; dokumentach odebranych,
nieodebranych oraz o aktywnych procesach workflow, w których
uczestniczy każdy użytkownik. Opisana informacja musi być
dostępna poprzez zestawienie tabelaryczne bez konieczności
wchodzenia w profil poszczególnych użytkowników.
Strona 19 z 51
8.2
9
9.1
9.2
9.3
9.4
9.5
10
10.1
11
11.1
SEOD musi posiadać funkcję umożliwiającą definiowanie
wielopoziomowej struktury organizacyjnej oraz definicję podległości
służbowych. Funkcja ta musi umożliwiać zdefiniowanie jednostek
organizacyjnych wraz z przypisaniem im odpowiedniej kategorii
(np.: OUG XYZ, departament, biuro, wydział itp.) oraz podległości
służbowych wraz z przyporządkowaniem im odpowiedniego
stanowiska np.: dyrektor, naczelnik. Modyfikacje struktury
organizacyjnej są zapisywane w postaci historii zmian i nigdy nie
mogą zostać utracone.
Ustawienia
SEOD powinien, dla ułatwienia użytkownikom pracy z systemem,
posiadać miejsce gdzie zaraz po zalogowaniu użytkownik będzie
informowany o nowych elementach typu: dokument, sprawa,
elementy oczekujące na akceptację itp. Gdzie po kliknięciu na
element użytkownik zostanie przeniesiony do treści danego
elementu. Informacje o nowych elementach powinny być widoczne
zaraz po zalogowaniu do systemu w centralnym miejscu interfejsu
aplikacji.
SEOD musi umożliwiać dynamiczną konfigurację szerokości
kolumn wyświetlających informacje o elementach systemu.
Mechanizm powinien działać w sposób analogiczny do modyfikacji
ustawień szerokości kolumn w arkuszach kalkulacyjnych pakietów
biurowych.
SEOD musi umożliwiać włączanie i wyłączanie powiadamiania o
aktualizacjach w sprawach i dokumentach, dla każdego użytkownika
indywidualnie.
SEOD musi umożliwiać ukrywanie wybranych kolumn opisujących
dokument lub sprawę. Każdy użytkownik powinien posiadać
możliwość wyboru kolumn, które są widoczne w jego profilu,
dostosowując wygląd list elementów do własnych preferencji.
SEOD musi umożliwiać użytkownikowi zmiany sortowania
dokumentów i spraw względem określonych kolumn, dostosowując
domyślny sposób sortowania list elementów do własnych
preferencji.
Pomoc
Pomoc musi zapewniać możliwość wyświetlenia okna
kontekstowego powiązanego z aktualnie wybraną funkcją SEOD.
Reguły
SEOD musi posiadać mechanizm ustalania Reguł, umożliwiających
sortowanie dokumentów, spraw i poczty elektronicznej względem
folderów, do których dostęp ma użytkownik.
Funkcja powinna umożliwiać stworzenie reguły względem
następujących parametrów opisujących:
• Dokument:
Strona 20 z 51
•
o Opis dokumentu – względem części lub całego
opisu,
o Kategoria,
o Sposób dostarczenia (np.: email, ręcznie),
o Przekazania w celu,
o Oznaczenia flagą (ważny, pilny),
o Przekazany przez (wybór określonego
użytkownika systemu, który przekazał dokument),
o Nadawca/Odbiorca.
Sprawa:
o Przekazana przez (wybór określonego użytkownika
systemu, który przekazał sprawę),
o Nazwa sprawy – względem części lub całej nazwy,
o Znak sprawy – względem części lub całego znaku,
12
12.1
12.2
o Priorytet (pilna, ważna, zwykła),
o Stan (zawieszona, w toku, zamknięta).
• Poczta elektroniczna:
o Pole Od, Do, Temat – względem części lub całego
opisu,
o Występuje,
o Zawiera dokładnie,
o Rozpoczyna się od,
o Kończy się na.
Mechanizm musi działać analogicznie do tworzenia reguł w
popularnych programach pocztowych.
Baza adresowa
SEOD musi posiadać wbudowany mechanizm tworzenia słowników
miejscowości i ulic oraz umożliwiać powiązanie tych danych z
podziałem terytorialnym kraju na gminy, powiaty i województwa.
SEOD musi posiadać mechanizm rozbudowy i modyfikacji
słowników bazy adresowej poprzez wbudowane mechanizmy
importu danych udostępnianych przez GUS z systemu TERYT.
SEOD musi wykorzystywać informacje zawarte w bazie adresów
np.: do rejestracji dokumentów. SEOD musi automatycznie
wypełniać pola formatki powiązane z danymi słownikowymi.
Możliwe powinno być np.: wypełnienie danych adresowych
kontrahenta (pełna nazwa, ulica, numer budynku, lokalu, kod
pocztowy, miasto NIP itd.) po odnalezieniu go w bazie adresowej
systemu. SEOD musi posiadać zawężający widok danych w
zależności od parametrów wybranych podczas uzupełniania danych
podmiotu.
Strona 21 z 51
12.3
12.4
12.5
13
13.1
13.2
13.3
13.4
13.5
13.6
SEOD musi oferować możliwość rozbudowy i modyfikacji bazy
adresowej systemu z poziomu użytkowników posiadających
uprawnienia, nadane przez administratora systemu, do modyfikacji
bazy adresowej, wraz z możliwością dodawania atrybutów
opisujących podmioty oraz generowania raportu przedstawiającego
dokumenty i sprawy powiązane z podmiotami zdefiniowanymi w
bazie adresowej.
SEOD musi pozwalać na wybór podmiotu z bazy adresowej podczas
rejestracji dokumentu. Wybór powinien następować poprzez
wybranie pozycji podpowiadanej przez SEOD na podstawie
informacji wprowadzonych przez użytkownika rejestrującego
dokument. System powinien podpowiadać wszystkie podmioty,
które spełniają parametry zapytania. Np. po wprowadzeniu 3-5
znaków z nazwy podmiotu SEOD powinien zaproponować listę
dostępnych do wyboru podmiotów, a następnie po wyborze jednego
z nich, wypełnić wszystkie zdefiniowane w bazie adresowej pola
opisujące podmiot.
SEOD musi pozwalać na odnalezienie podmiotu w bazie adresowej
na etapie rejestracji dokumentu na podstawie wypełnionego jednego
z pól adresowych np: wypełnienie pola NIP – wówczas po wyborze
odpowiedniej funkcji (np.: dopasuj, szukaj itp.), powinien
podpowiedzieć podmiot spełniający to zapytanie.
Skanowanie
Moduł ten musi umożliwiać współpracę ze skanerami
dokumentowymi zgodnymi ze sterownikiem TWAIN.
Moduł musi pozwolić na odwzorowanie cyfrowe (zeskanowanie)
dokumentu z wybranymi parametrami, następnie wprowadzenie go
do SEOD.
Moduł skanowania powinien być dostępny zarówno w wersji
aplikacji desktopowej jak i w wersji webowej.
Moduł skanowania w wersji desktopowej powinien posiadać
instalator w formacie .MSI
Skanowane dokumenty powinny pojawiać się na liście, która
umożliwi grupowe wprowadzenie dokumentów do SEOD, np.:
poprzez zaznaczenie na liście skanów dokumentów, pola typu
checkbox. Aplikacja musi umożliwiać grupowe zaznaczenie
wszystkich dokumentów jednym kliknięciem np. przez kliknięcie w
nagłówek tabeli w kolumnie odpowiedzialnej za zaznaczanie
dokumentów.
Moduł skanowania musi umożliwiać dokonanie transformacji
zeskanowanego obrazu co najmniej w następującym zakresie:
• Obrót skanu (odwzorowania cyfrowego dokumentu) o 90
stopni w dowolną stronę
• Wybranie opcji pokazywania miniatur stron w przypadku
skanu wielostronicowego
Strona 22 z 51
13.7
13.8
13.9
14
14.1
14.2
15
15.1
15.2
15.3
15.4
• Możliwość zamiany kolejności stron
• Możliwość usuwania stron
Moduł skanowania musi umożliwiać wysyłanie skanów
dokumentów co najmniej przez otoczenie sieciowe i przez FTP.
Moduł skanowania musi umożliwiać zdefiniowanie następujących
trybów skanowania:
• Wszystkich skanowanych dokumentów / stron jako jeden
plik – jeden dokument
• Wszystkich skanowanych dokumentów / stron jako
oddzielne pliki – oddzielne dokumenty
• Możliwość dodawania nowych stron do dokumentu
• Możliwość skanowania dokumentu jako jeden dokument,
nawet w przypadku gdy podajnik skanera nie pozwala na
wprowadzanie wszystkich kartek dokumentu za jednym
razem (skanowanie ciągłe do jednego pliku)
Moduł skanowania musi umożliwiać definiowanie profili
skanowania (zapisanych parametrów skanowania).
Formularze dla dokumentów
SEOD musi posiadać możliwość przypisywania formularzy do
formatki rejestracji dokumentu oraz nadawania uprawnień
umożliwiających używanie zdefiniowanych formularzy przez
określonych użytkowników. Formularz powinien pojawiać się po
wyborze odpowiedniej kategorii dokumentu. Formularze muszą
umożliwiać dokonanie opisu dokumentu dodatkowymi cechami
(metadanymi), a uprawnienia do definiowania dodatkowych
formularzy musi mieć użytkownik specjalny.
SEOD musi posiadać mechanizm dynamicznych formularzy
umożliwiający dodawanie określonych pól co najmniej do formatek
opisu dokumentu, oraz procesów Workflow, tak aby możliwe było
przydzielenie osobnego formularza dla każdego z kroków procesu.
Rezerwacje
Administrator SEOD musi posiadać możliwość zdefiniowania listy
przedmiotów współdzielonych pomiędzy użytkownikami jak i
ustalenia uprawnień dla tych przedmiotów oraz uprawnień do
zarządzania nimi. Uprawnienia muszą umożliwiać co najmniej
określenie: kto posiada uprawnienia do rezerwacji danego zasobu,
oraz kto może dokonywać rezerwacji w imieniu innych
użytkowników.
SEOD musi umożliwiać dodawanie, modyfikacje, usuwanie
zasobów przeznaczonych do rezerwacji.
SEOD musi umożliwiać grupowanie zasobów przeznaczonych do
rezerwacji (np.: grupa samochody czy sale konferencyjne, w której
dostępne są konkretne przedmioty).
SEOD musi umożliwiać nadawanie uprawnień do pojedynczych
zasobów (np.: wybranego samochodu) w zakresie:
Strona 23 z 51
15.5
15.6
16
16.1
16.2
16.3
17
możliwości rezerwacji zasobu,
wglądu w rezerwacje,
możliwości usuwania rezerwacji zasobu,
możliwośći rezerwacji zasobu oraz przeglądania rezerwacji z
użyciem kalendarza,
widoku kalendarza rezerwacji z podziałem co najmniej na: dzień,
tydzień, miesiąc,
oznaczania różnym kolorem rezerwacji wykonanych przez różnych
użytkowników,
możliwości dokonania rezerwacji z dokładnością do 15 minut.
W SEOD musi istnieć możliwość wykonania rezerwacji w imieniu
innej osoby wraz z odnotowaniem faktu kto i dla kogo dokonał
rezerwacji.
SEOD musi informować użytkownika o rezerwacjach nakładających
się. Informacja musi być wyświetlana już w momencie próby
dodania nakładającego się wpisu w rezerwacjach.
Rejestry
SEOD musi posiadać mechanizm definiowania rejestrów
dokumentów oraz przydzielania dostępu do nich wybranym
użytkownikom. Podczas definiowania uprawnień do rejestru musi
istnieć możliwość wybrania zakresu uprawnień do rejestru dla
wybranego użytkownika przynajmniej na poziomie: odczyt, pełny.
Definiowanie rejestru musi umożliwiać użycie co najmniej
następujących pól: klasyfikacja dokumentu (przychodzący,
wychodzący, wewnętrzny), kategoria (np.: wniosek, skarga, decyzja
itd.), komórka organizacyjna, kontakt z bazy adresowej.
SEOD musi pozwalać na nadanie nazwy oraz symbolu rejestrowi.
SEOD musi umożliwiać przydzielanie spraw/dokumentów do
odrębnych rejestrów spraw/dokumentów, które to rejestry mogą być
odrębnie numerowane. Mechanizm numeracji elementów w
rejestrach musi pozwalać na ustalanie formatu numeracji poprzez
możliwość zastosowania takich elementów jak: numer kolejny,
symbol komórki, miesiąc, rok. Mechanizm numeracji powinien
również pozwalać na ustalanie wartości początkowych. SEOD musi
również pozwalać na określenie typu numeracji: np. ciągły,
miesięczny, roczny. SEOD musi automatycznie grupować elementy
rejestrów do osobnych folderów z podziałem na lata. Np. 2011, 2012
itd.
Terminarze
Strona 24 z 51
17.1
17.2
17.3
17.4
SEOD musi umożliwiać zarządzanie terminarzami z poziomu panelu
administracyjnego. Administrator powinien posiadać możliwość
utworzenia terminarza i przypisania go jednemu lub wielu
użytkownikom, tak aby w zależności od uprawnień przydzielonych
do danego terminarza użytkownicy mogli wprowadzać i zarządzać
zmianami w danym terminarzu.
SEOD musi posiadać wbudowany mechanizm terminarzy
umożliwiający definiowanie terminarzy indywidualnych,
grupowych oraz globalnych umożliwiający ustalanie i kontrolę nad
terminami. Definiowanie terminarzy musi być proste – tzn. opierać
się o odpowiednie wypełnienie pól formularzy wyświetlanych w
interfejsie aplikacji (przeglądarce internetowej).
Użytkownik musi posiadać możliwość udostępnienia całego swojego
terminarza, z uprawnieniami tylko do wglądu lub do zapisu, innemu
użytkownikowi.
SEOD musi posiadać możliwość ustalania uprawnień do dodawania
i do wglądu terminarzy dostępny dla każdego użytkownika.
Uprawnienia muszą dotyczyć indywidualnie każdego terminarza.
17.5
Wpisy o terminach dokonane przez różnych użytkowników w
udostępnionym terminarzu muszą być oznaczone innym kolorem.
17.6 SEOD musi udostępniać następujące widoki terminarzy: dzienny,
tygodniowy, miesięczny. W każdym z tych widoków muszą zostać
wyświetlone informacje na temat ustalonych terminów.
17.7 SEOD musi informować użytkownika o terminach nakładających się
w momencie próby wprowadzenia takiego kolidującego terminu i
jednocześnie proponować najbliższy wolny termin.
17.8 SEOD musi umożliwiać wpisanie do terminarza, na dany dzień,
dowolnej liczby zdarzeń tzw. „całodziennych” o nakładających się
terminach np. planowane przez różne jednostki na ten sam dzień
kontrole zewnętrzne.
17.9 SEOD musi posiadać funkcję cyklicznego przypominania o
zdarzeniach zapisanych w terminarzach. Powiadamianie musi być
możliwe za pomocą wyskakującego okienka, w którym zostaną
wymienione zdarzenia pochodzące ze wszystkich terminarzy, do
których dostęp ma użytkownik. Musi istnieć możliwość odłożenia
przypomnienia o zdarzeniach na określony czas dla wszystkich
terminów jednocześnie oraz dla każdego z osobna lub odrzucenia
powiązanego z usunięciem przypomnienia o wybranym terminie lub
grupie terminów.
17.10 SEOD musi umożliwiać wyeksportowanie wszystkich zdarzeń z
terminarza do pliku CSV. SEOD musi umożliwiać eksport
przynajmniej następujących pól: data rozpoczęcia, data zakończenia,
tytuł, opis.
Strona 25 z 51
17.11 SEOD musi posiadać funkcję umożliwiającą synchronizację
wbudowanego terminarza z komercyjnym oprogramowaniem
Microsoft Outlook (w wersji 2000, 2003, 2007 i nowszej).
JRWAUG
18
18.1 SEOD musi umożliwiać modyfikację JRWAUG tylko przez
uprawnionego użytkownika (lub administratora) z poziomu
interfejsu graficznego będącego częścią SEOD. Modyfikacje
JRWAUG są zapisywane w postaci historii zmian. Historia zmian
powinna zawierać co najmniej informacje na temat tego kto dokonał
zmiany, kiedy ona nastąpiła, co zostało zmienione, jakiego symbolu
JRWAUG dotyczyła, oraz czy była to modyfikacja czy rozbudowa
JRWAUG.
18.2 SEOD musi posiadać narzędzia umożliwiające import JRWAUG z
pliku tekstowego o odpowiednio sformatowanej strukturze.
Mechanizm importu powinien umożliwiać zaimportowanie struktury
JRWAUG przygotowanej co najmniej w pliku w formacie CSV.
18.3 SEOD musi umożliwiać nadanie znaku JRWAUG na etapie
zakładania sprawy, lub już po założeniu sprawy.
18.4 SEOD musi umożliwiać usuwanie znaku sprawy JRWAUG, oraz na
ponowne nadanie znaku sprawy.
18.5 SEOD musi uniemożliwiać usuwanie znaków spraw w sposób
powodujący powstawanie „pustych” wpisów w ewidencji spraw.
19
Edytor
19.1 SEOD musi uniemożliwiać edycję dokumentu lub pliku w
przypadku gdy jest on otwarty w tym celu przez innego
użytkownika. SEOD musi umożliwiać definicję maksymalnego
czasu blokowania plików pobranych do edycji i automatycznie
odblokowywać plik po przekroczeniu zdefiniowanego czasu. SEOD
musi informować użytkownika o zablokowaniu edycji dokumentu
poprzez wyświetlenie informacji zawierającej Imię i Nazwisko
użytkownika, przez którego dostęp do pliku został zablokowany.
19.2
SEOD musi posiadać mechanizm umożliwiający modyfikację
dokumentów pakietu komercyjnego Microsoft Office Word (w
wersji co najmniej 2003 lub nowszy). Użytkownik musi posiadać
możliwość zapisania informacji z poziomu aplikacji macierzystej
bezpośrednio w systemie. Po kliknięciu na plik MS Word
umieszczony w SEOD ten otwierany jest w programie MS Word. Po
modyfikacji pliku musi istnieć możliwość zapisania
zmodyfikowanego pliku bezpośrednio w SEOD z poziomu MS
Word. Plik powinien być zapisany jako kolejna wersja uprzednio
edytowanego pliku.
Strona 26 z 51
19.3
20
20.1
20.2
20.3
21
21.1
21.2
22
22.1
22.2
22.3
Dopuszcza się aby moduł edytora był dostępny jako komponent
ActiveX, jednocześnie dostarczany SEOD musi posiadać instalator
edytora w formacie .MSI – tak aby Administrator mógł zainstalować
komponent ActiveX za pomocą mechanizmów domenowych (Group
Policy). SEOD powinien również umożliwiać automatyczną
instalację komponentu przy założeniu, że konfiguracja przeglądarki
na to pozwala. Taka instalacja może się odbywać tylko przy
pierwszym uruchomieniu edytora.
Drag & Drop
SEOD musi umożliwiać przenoszenie elementów pomiędzy
folderami SEOD za pomocą mechanizmu Drag & Drop –
użytkownik wskazuje element, klikając myszą, a następnie przeciąga
go do folderu docelowego.
Mechanizm Drag & Drop nie może pozwalać na „wymieszanie”
elementów w folderach. Np.
SEOD nie może pozwolić na przeniesienie obiektu typu „sprawa” do
folderu np. typu „dokument”.
W przypadku próby przeniesienia obiektu do niewłaściwego folderu
SEOD musi poinformować użytkownika o próbie wykonania
niedozwolonej operacji.
Formularze dla spraw
SEOD musi pozwalać na zdefiniowanie formularzy dynamicznych
dla zdefiniowanych wzorców spraw. Do każdego symbolu sprawy z
JRWAUG może zostać przydzielony odrębny wzorzec, a co za tym
idzie formularz opisujący daną sprawę. Za pomocą formularzy
dynamicznych musi istnieć możliwość opisania sprawy dowolnymi
polami tj. text, textarea, drop down list, radiobutton, checkbox.
SEOD musi pozwalać na wyszukiwanie spraw wg. atrybutów
wchodzących w skład formularzy dynamicznych opisujących
sprawy.
Zastępstwa
Mechanizm zastępstw nie może wymuszać przekazywania haseł
pomiędzy użytkownikami na czas nieobecności.
Każdy użytkownik systemu, zgodnie z uprawnieniami, musi
posiadać możliwość wskazania początku oraz końca okresu, w
którym będzie zastępowany.
Wszystkie operacje wykonywane przez zastępcę w systemie muszą
zostać odnotowane. Na ich podstawie powinien być tworzony spis
wykonanych operacji, w taki sposób aby osoba powracająca do
swoich obowiązków po zakończeniu zastępstwa była w stanie
zapoznać się z operacjami jakie zastępujący wykonywał w obrębie
konta zastępowanego. Wszystkie elementy, na których zastępca
wykonał jakiekolwiek operacje muszą być przedstawione w postaci
zbiorczej listy lub raportu.
Strona 27 z 51
22.4
22.5
22.6
23
23.1
24
24.1
24.2
24.3
SEOD musi posiadać możliwość modyfikacji zastępstwa w taki
sposób aby istniała możliwość zmiany osoby zastępowanej bądź
zastępującej.
Wszystkie operacje realizowane przez zastępcę muszą zostać
zapisane w historii zdarzeń i umożliwiać identyfikację osoby, która
je wykonała.
Mechanizm zastępstw musi umożliwiać określenie do jakich
elementów należących do osoby zastępowanej, zastępca otrzyma
dostęp na czas pełnionego zastępstwa. Mechanizm zastępstw
powinien umożliwiać zdefiniowanie dostępu do co najmniej
następujących elementów: dokumenty, sprawy, elementy do
akceptacji, elementy do dekretacji, notatki, poczta, rezerwacje,
delegacje, urlopy, zastępstwa, foldery publiczne.
Szablony dokumentów
SEOD musi wspomagać przygotowanie szablonów dokumentów do
otwartego formatu RTF, zawierających obok definiowanej stałej
treści, predefiniowane pola, wśród których muszą znaleźć się:
data aktualna,
dane teleadresowe odbiorcy z podziałem na nazwę, imię i
nazwisko, ulicę, numer domu, numer lokalu, kod, miasto,
numer dokumentu,
znak sprawy, do której należy dokument,
imię i nazwisko osoby odpowiedzialnej za sprawę.
Predefiniowane pola muszą być automatycznie wypełniane przez
SEOD na żądanie użytkownika podczas generowania dokumentu na
podstawie szablonu. Użytkownik musi mieć możliwość modyfikacji
treści dokumentu i uzupełniania go o dowolne informacje.
Podpis elektroniczny
SEOD musi posiadać mechanizm umożliwiający swobodne
korzystanie z kwalifikowanego i powszechnego podpisu
elektronicznego bez konieczności posiadania fachowej wiedzy.
Funkcja podpisu elektronicznego powinna umożliwiać podpisywanie
jednego elementu SEOD przez wielu użytkowników.
Funkcjonalność podpisu powinna umożliwiać stosowanie podpisu w
formacie XAdES (ETSI TS 101 903 1.3.2) lub nowszy oraz PKCS#7
w zależności od konfiguracji systemu. SEOD musi zapewniać użycie
podpisu opakowanego i opakowującego.
Funkcja podpisu elektronicznego musi umożliwiać poprawne
wykorzystanie certyfikatów kwalifikowanych pochodzących od
wszystkich certyfikowanych wystawców.
SEOD musi umożliwiać złożenie podpisu na dokumencie lub pliku
załączonym do sprawy dowolnej liczbie osób.
Strona 28 z 51
24.4
SEOD musi umożliwiać zweryfikowanie poprawności złożonego
podpisu przez każdego z użytkowników, którzy podpisali dokument.
25
25.1
Foldery publiczne
SEOD musi umożliwiać zdefiniowanie folderów dostępnych dla
dowolnie zdefiniowanej przez administratora systemu listy
użytkowników. Foldery publiczne powinny być widoczne dla
wszystkich użytkowników posiadających do nich wgląd, i powinny
być zdefiniowane w identyczny sposób u każdego z użytkowników.
Administrator SEOD może w każdej chwili nadać lub odebrać
uprawnienia do folderu kolejnym użytkownikom.
Active Directory
SEOD musi umożliwiać synchronizację kont użytkowników poprzez
LDAP ze szczególnym uwzględnieniem Active Directory.
Synchronizacji powinny podlegać, co najmniej, następujące
informacje:
• Imię i nazwisko,
• Adres email,
• Numer telefonu,
• Stan konta: zablokowane, aktywne.
Mechanizm integracji z Active Directory powinien pozwalać co
najmniej na:
• Kopiowanie kont wybranych lub wszystkich aktywnych
kont z Active Directory,
• Synchronizację informacji o kontach z Active Directory –
np. w przypadku gdy SEOD posiada informację o n –
użytkownikach, a w między czasie w Active Directory został
dodany nowy n+1 użytkownik, SEOD podczas synchronizacji
powinien odnaleźć takie nowe konto i umożliwić
zaimportowanie go do SEOD.
Mechanizm integracji z Active Directory nie może ograniczać
SEOD do pracy tylko i wyłącznie z LDAP/Active Directory. SEOD
musi działać poprawnie także w środowiskach bez LDAP/Active
Directory. Integracja z Active Directory nie może również być
integracją online. SEOD musi umożliwiać pracę użytkownikom
nawet w przypadku gdy Active Directory nie jest dostępne.
Pobieranie informacji z Active Directory o użytkownikach powinno
być inicjowane przez Administratora SEOD. Integracja online
powinna służyć jedynie do zintegrowanego uwierzytelniania
systemowego użytkowników podczas uruchamiania SEOD.
Użytkownik autoryzowany w domenie, uruchamiając SEOD, jest
automatycznie logowany na swoje konto w SEOD – o ile jego konto
w SEOD istnieje (zostało pobrane z Active Directory, lub dodane
ręcznie przez Administratora).
25.2
26
26.1
26.2
26.3
Strona 29 z 51
26.4
26.5
26.6
26.7
27
27.1
27.2
27.3
27.4
27.5
Mechanizm integracji SEOD z Active Directory nie może
uniemożliwiać dodania konta użytkownika SEOD, który nie posiada
konta w Active Directory. W takim przypadku użytkownik podczas
logowania do systemu będzie musiał podać login i hasło aby SEOD
autoryzował użytkownika.
SEOD musi pozwalać na poprawną pracę także w środowiskach
bezdomenowych. W takim przypadku użytkownik podczas
logowania do systemu będzie musiał podać login i hasło aby SEOD
autoryzował użytkownika.
SEOD musi umożliwiać kopiowanie kont użytkowników poprzez
LDAP.
Możliwość autoryzacji użytkowników poprzez LDAP ze
szczególnym uwzględnieniem Active Directory oznacza że
użytkownik po zalogowaniu się do systemu operacyjnego nie może
logować się po raz kolejny do SEOD. Użytkownik musi być
uwierzytelniany automatycznie po wpisaniu adresu, pod którym
dostępny jest SEOD i skierowany na przypisane do niego konto.
Delegacje
SEOD musi posiadać moduł delegacji umożliwiający rozliczenie
delegacji pracownikom posiadającym konto w SEOD.
Administrator SEOD musi mieć możliwość nadawania uprawnienia
użytkownikom do administrowania delegacjami lub uprawnienie
tylko do wprowadzania delegacji w zakresie jednostek
organizacyjnych Zamawiającego.
Moduł delegacji musi umożliwiać wprowadzenie delegacji oraz – po
zakończeniu delegacji, na jej rozliczenie.
Użytkownik posiadający uprawnienia do administrowania
delegacjami, musi posiadać dostęp do:
• Delegacji do zatwierdzenia
• Zaliczek do zatwierdzenia
• Rachunków do zatwierdzenia
• Dokumentów (dołączanych do rozliczenia delegacji)
• Podziału na delegacje odbywane samochodem
prywatnym, służbowym oraz innymi środkami transportu
(kolej, autobus)
• Delegacji oczekujących na zatwierdzenie
• Opcji umożliwiającej masowe zatwierdzanie delegacji
Moduł delegacji musi pozwalać użytkownikowi na wprowadzenie
informacji o delegacji poprzez wypełnienie formularza delegacji.
Formularz delegacji musi zawierać następujące pola:
• Numer delegacji (tylko do odczytu, generowany
automatycznie przez SEOD)
• Numer polecenia (tylko do odczytu, generowany
automatycznie przez SEOD)
• Pełniona funkcja – lista rozwijalna
Strona 30 z 51
27.6
27.7
27.8
27.9
28
28.1
28.2
28.3
28.4
• Miejsce wyjazdu – słownik miejscowości
• Czas trwania delegacji – godzina wyjazdu i godzina
powrotu
• Cel delegacji – lista rozwijalna lub pole tekstowe, w
zależności od wyboru użytkownika wypełniającego formularz
delegacji
• Środki lokomocji
• Wyżywienie (delegacja z wyżywieniem lub bez)
• Osoba delegująca
• Zastępca
• Uwagi
SEOD musi automatycznie definiować zastępstwo w przypadku gdy
użytkownik wypełniając formularz delegacji zdefiniuje zastępcę.
SEOD musi pozwalać wybranym użytkownikom na rozliczanie i
zatwierdzanie delegacji.
SEOD na liście delegacji musi prezentować i odpowiednio zmieniać
automatycznie status delegacji:
• Niezatwierdzona
• Zatwierdzona
• W toku
• Rozliczona
SEOD musi umożliwiać definiowanie ustawień ewidencji przebiegu
pojazdu oraz na drukowanie karty ewidencji przebiegu pojazdu.
Urlopy
Moduł urlopy musi umożliwiać uprawnionemu użytkownikowi
wprowadzenie informacji niezbędnych do poprawnego wyliczania
ilości dostępnego urlopu.
Moduł powinien pozwalać na wprowadzenie takich informacji jak:
• Ilość dostępnego urlopu na żądanie
• Ilość dostępnego urlopu z tytułu opieki nad dzieckiem
• Ile godzin ma dzień roboczy dla pełnego etatu.
SEOD w części pozwalającej na określenie uprawnień
użytkowników do modułu urlopu musi umożliwiać określenie
przynajmniej:
• Czy użytkownik posiada uprawnienia do raportów dot.
wykorzystania urlopów
• Czy uprawnienia dotyczące zarządzania urlopami dotyczą
wszystkich pracowników czy tylko wybranych pracowników
• Czy użytkownik posiada uprawnienia do anulowania
wniosków urlopowych
W przypadku zmiany uprawnień do modułu urlopów SEOD musi
zapisywać w historii listę tych zmian.
Strona 31 z 51
28.5
28.6
28.7
28.8
28.9
29
29.1
Użytkownik posiadający uprawnienia administrowania urlopami
powinien mieć możliwość wprowadzenia dla pracowników
informacji o ich zatrudnieniu. SEOD musi umożliwiać,
użytkownikowi definiującemu dane o zatrudnieniu pracownika,
wprowadzenie co najmniej następujących informacji:
• Data od kiedy pracownik jest zatrudniony
• Data do kiedy pracownik jest zatrudniony lub na
określenie, że okres zatrudnienia nie jest ograniczony
• Wymiar etatu np. ½, ¼, 1/8, itd.
• Podstawa urlopu (pierwsza praca, 20 dni, 26 dni)
• Urlop dodatkowy (szkolny, służba cywilna)
• Opieka nad dzieckiem
• Uwagi
Użytkownik posiadający uprawnienia do administrowania urlopami
pracowników musi posiadać dostępną funkcję Oblicz urlop, która
pozwoli na obliczenie urlopu na podstawie danych o zatrudnieniu
pracownika.
SEOD musi umożliwiać wygenerowanie szczegółowego raportu dot.
wykorzystania urlopów pracownikowi posiadającemu odpowiednie
uprawnienia. Raport powinien w sposób tabelaryczny przedstawiać
ilość wykorzystanego urlopu w godzinach i minutach, dla każdego z
typu urlopów oraz sumę. Zestawienie powinno jednocześnie
pokazywać wszystkich pracowników do których użytkownik posiada
uprawnienia administracji urlopami.
SEOD w mechanizmie urlopów powinien w folderze Wnioski
(wnioski urlopowe) dzielić wnioski na następujące foldery:
• Nowe
• Zweryfikowane
• Zaakceptowane
• Anulowane
• SEOD podczas wprowadzania nowego urlopu musi
umożliwiać wprowadzenie w formularzu elektronicznym
następujących informacji:
• Rok
• Data od
• Data do
• Długość urlopu w dniach i godzinach z przeliczeniem na
godziny
• Rodzaj urlopu
• Zastępca (z listą aktywnych pracowników SEOD)
• Uwagi
Komunikator
SEOD musi współpracować z aplikacją umożliwiającą wymianę
informacji pomiędzy użytkownikami – tzw. komunikator, w sposób
analogiczny do programów komercyjnych np. GaduGadu.
Strona 32 z 51
29.2
29.3
29.4
29.5
29.6
29.7
29.8
29.9
29.10
29.11
29.12
29.13
29.14
29.15
29.16
29.17
29.18
Komunikator musi zapewnić możliwość powiadamiania
użytkownika o zmianach zachodzących pośród informacji w SEOD
poprzez wyskakujący komunikat zawierający informację o
aktualizacji.
Komunikator musi umożliwiać dwukierunkowe rozmowy tekstowe
pomiędzy użytkownikami systemu.
Komunikator musi umożliwiać przechowywanie listy użytkowników
na serwerze.
Komunikator musi informować o zmianach statusów użytkowników
przy użyciu ikon oraz okien z aktualnym statusem użytkownika.
Komunikacja pomiędzy użytkownikami powinna być poprzedzona
autoryzacją przez użytkownika, do którego kierowana jest rozmowa.
Komunikator powinien umożliwiać konstruowanie wizytówki w
oparciu o dane zawarte w systemie oraz pola uzupełniane przez
użytkownika.
Komunikator powinien umożliwiać przeglądanie wizytówek przez
każdego użytkownika systemu.
Komunikator powinien umożliwiać przesyłanie plików pomiędzy
użytkownikami poprzez połączenie szyfrowane, z zastosowaniem
protokołu SFTP bądź innego równoważnego.
Komunikator powinien umożliwiać współdzielenie plików
pomiędzy użytkownikami.
Komunikator powinien umożliwiać zabezpieczanie utworzonej
wielopoziomowej struktury katalogów hasłem.
Komunikator powinien umożliwiać informowanie użytkownika
animowaną ikoną o nowej wiadomości.
Komunikator powinien umożliwiać ustawienie formatowania tekstu
(rodzaju czcionki, typu czcionki, rozmiaru oraz stylu) dla
wiadomości przychodzących oraz wychodzących.
Komunikator powinien umożliwiać włączenie i wyłączenie funkcji
wyświetlania ikon odzwierciedlających emocje (tzw. emotikony) dla
wiadomości tekstowych.
Komunikator powinien umożliwiać przesłanie tekstu z opcją
wyświetlenia tekstu czcionką o stałej długości znaku bez
formatowania i dzielenia tekstu (np. do wysyłania tabel itp.)
Komunikator powinien umożliwiać podłączenie kompozycji
graficznych zmieniających interfejs aplikacji w zakresie tła, koloru
okien, ikon.
Komunikator powinien umożliwiać włączenie i wyłączenie skrótów
klawiaturowych umożliwiających szybką zmianę statusu.
Komunikator musi umożliwiać skonfigurowanie możliwości
uruchamiania po zalogowaniu się użytkownika do systemu
operacyjnego.
Strona 33 z 51
29.19 Komunikator musi umożliwiać skonfigurowanie wyświetlania
informacji dotyczących dostępności użytkowników.
29.20 Komunikator musi umożliwiać skonfigurowanie możliwości
ukrywania użytkowników ze statusem nieaktywny (offline).
29.21 Serwer z którym współpracuje komunikator musi współpracować z
serwerem relacyjnych baz danych SQL.
29.22 Autoryzacja użytkowników powinna być możliwa poprzez LDAP
ze szczególnym uwzględnieniem Active Directory.
29.23 Serwer komunikatora musi pracować poprawnie pod kontrolą
systemu operacyjnego Linux (Unix) oraz Windows.
29.24 Serwer komunikatora musi przechowywać wszystkie wiadomości
przekazywane pomiędzy użytkownikami.
30
BIP - współpraca
30.1 Funkcja publikacji do BIP zintegrowana w SEOD musi pozwalać na
poprawną bezpośrednią integrację z zewnętrznym Biuletynem
Informacji Publicznej, w taki sposób by możliwe było umieszczenie
informacji dotyczących spraw z SEOD w strukturze stron BIP.
Funkcja umożliwiająca publikację do BIP musi być oparta o
mechanizm Webservices.
Aktualnie Zamawiający wykorzystuje aplikację BIP z firmy Hoga.pl
http://www.wug.bip.info.pl ,i z tą aplikacją musi współpracować
SEOD.
Dostawa aplikacji Biuletynu Informacji Publicznej NIE JEST
przedmiotem zamówienia.
30.2 W ramach publikacji informacji do BIP z poziomu SEOD muszą być
przekazywane następujące informacje:
znak sprawy (taki sam jak w SEOD) – „numer sprawy”,
stan sprawy,
data rozpoczęcia sprawy – „data utworzenia”,
data zakończenia sprawy – „data rozpatrzenia”
30.3 SEOD musi umożliwiać przekazywanie informacji w oparciu o
szablony XML zawierające opisaną strukturę przekazywanych
informacji.
30.4 Opublikowana do BIP sprawa z poziomu SEOD musi być w SEOD
oznaczona odpowiednią ikoną.
30.5 SEOD w przypadku modyfikacji sprawy musi umożliwić
uaktualnienie opublikowanej do BIP sprawy – szczególnie jej stanu.
Publikowanie informacje muszą być agregowane względem sprawy,
której dotyczą.
Identyfikatorem agregacji jest znak sprawy.
31
Wielojęzyczność interfejsu
31.1 SEOD powinien umożliwiać ustawienie co najmniej 2 języków
interfejsu aplikacji - w wersji polskiej (podstawowy) i angielskiej.
30.6
Strona 34 z 51
31.2 SEOD musi pozwolić aby każdy z użytkowników mógł wybrać
jeden z dwóch języków niezależnie.
Poczta elektroniczna
32
32.1 SEOD musi posiadać możliwość zarządzania kontami poczty
elektronicznej obsługiwanymi w SEOD z poziomu użytkownika
pełniącego rolę administratora systemu. Administrator musi
posiadać możliwość utworzenia konta poczty elektronicznej i
przypisania go jednemu lub wielu użytkownikom.
32.2 SEOD musi posiadać wbudowanego klienta poczty elektronicznej
obsługującego co najmniej protokoły POP3 oraz SMTP.
Klient poczty elektronicznej musi stanowić integralną całość pod
względem graficznym i funkcjonalnym SEOD.
32.3 Wbudowany klient poczty elektronicznej musi posiadać co najmniej
następujące funkcje:
• Utwórz wiadomość – umożliwia utworzenie nowej
wiadomości,
• Odpowiedz – umożliwia udzielenie odpowiedzi nadawcy
wraz z cytowaniem i oznaczenie cytowanego tekstu
napisanego przez nadawcę,
• Odpowiedz wszystkim – umożliwia udzielenie
odpowiedzi nadawcy wraz z przesłaniem jej na pozostałe
adresy email wymienione w polu Do, Do wiadomości oraz
Ukryty do wiadomości wraz z cytowaniem i oznaczenie
cytowanego tekstu napisanego przez nadawcę,
• Prześlij dalej – umożliwia przesłanie poczty
elektronicznej kolejnemu odbiorcy,
• Przenieś – umożliwia przenoszenie poczty elektronicznej
pomiędzy folderami na wybranym koncie,
• Drukuj – umożliwia wydrukowanie poczty
elektronicznej,
• Dołącz – umożliwia dołączenie poczty elektronicznej do
sprawy lub dokumentu,
• Odbierz – umożliwia ręczne odebranie poczty
elektronicznej,
• Usuń – umożliwia usunięcie wybranej poczty
elektronicznej,
• Znajdź – umożliwia uruchomienie wyszukiwania poczty
elektronicznej,
• Rejestruj – umożliwia rejestrację poczty elektronicznej
jako dokumentu w systemie w sposób analogiczny do
rejestracji dokumentu zeskanowanego.
32.4 SEOD musi udostępniać możliwość konfiguracji konta poczty
elektronicznej każdemu użytkownikowi lub tylko administratorowi
w zależności od globalnej konfiguracji SEOD.
Strona 35 z 51
SEOD musi zapewniać możliwość konfiguracji dowolnej liczby kont
poczty elektronicznej dla każdego użytkownika.
32.6 SEOD musi posiadać funkcję umożliwiającą przypisanie
pojedynczego konta poczty elektronicznej użytkownikowi bądź
grupie użytkowników.
32.7 SEOD musi umożliwiać rejestrację poczty elektronicznej jako
dokumentów w systemie z podziałem na treść i załączniki. Funkcja
Rejestracji musi być dostępna z poziomu klienta poczty
elektronicznej wbudowanego w SEOD i dostępna dla użytkownika
zgodnie z nadanymi uprawnieniami.
32.8 SEOD musi umożliwiać dołączanie poczty elektronicznej do
dokumentów lub spraw. Dołączenie musi być możliwe z poziomu
klienta poczty elektronicznej wbudowanego w system.
32.9 SEOD musi posiadać możliwość przeszukania każdego z kont
poczty elektronicznej względem następujących parametrów:
• Od – pole nadawcy poczty elektronicznej
• Do – pole odbiorcy poczty elektronicznej
• Temat – pole tematu poczty elektronicznej
• Treść – pole treści poczty elektronicznej
• W podfolderach – możliwość przeszukania wszystkich
bądź wybranych podfolderów na koncie
32.10 SEOD musi umożliwiać wysyłanie i odbieranie poczty
elektronicznej wraz z załącznikami poprzez zdefiniowane konta
pocztowe.
32.11 SEOD musi umożliwiać wysyłanie poczty elektronicznej w formacie
HTML. SEOD powinien poprawnie obsługiwać wiadomości
odbierane i wysyłane jako wiadomości w formacie HTML i formacie
tekstowym.
33
Automatyczny przepływ dokumentów
33.1 SEOD musi umożliwiać zdefiniowanie ścieżki automatycznego
przepływu dokumentów.
33.2 Mechanizm automatycznego przepływu dokumentów musi
umożliwiać operatorowi rejestrującemu dokument wybranie co
najmniej jednej ze ścieżek wg. której dokument ma zostać
automatycznie przesyłany pomiędzy użytkownikami.
33.3 Mechanizm automatycznego przepływu dokumentów musi
umożliwiać zdefiniowanie formularzy dynamicznych, które będą
wypełnianie przez użytkowników na poszczególnych etapach
przepływu dokumentu.
33.4 Graficzna prezentacja zdefiniowanej ścieżki automatycznego
przepływu dokumentów musi być zrealizowana w dwuwymiarowej
grafice wektorowej.
32.5
Strona 36 z 51
33.5
33.6
33.7
33.8
34
34.1
34.2
34.3
34.4
34.5
Mechanizm automatycznego przepływu dokumentów musi oferować
graficzny modeler ścieżki przepływu dokumentów oparty o
rozwiązanie którego specyfikacja jest jawna i nie podlega żadnym
prawom patentowym.
Mechanizm pozwalający na graficzne modelowanie ścieżek
przepływu dokumentów musi pozwalać na rozszerzenie
funkcjonalności poprzez dodanie własnych elementów i właściwości
przy pomocy standardowych technik XML.
Mechanizm pozwalający na graficzne modelowanie ścieżek
przepływu dokumentów musi być niezależny od platformy
systemowej.
Mechanizm pozwalający na graficzne modelowanie ścieżek musi
również zapewniać możliwość łączenia obiektów w sposób
graficzny – poprzez łączenie punków strzałkami, które mogą być
swobodnie kształtowane za pomocą krzywych Beziera.
Moduł Workflow
Oferowany z SEOD moduł Workflow musi być w pełni zgodny ze
specyfikacją XPDL opracowaną przez Workflow Management
Coalition (WfMC).
Zamawiający dopuszcza zaoferowanie modułu z inną specyfikacją,
posiadającą podobne zastosowanie i charakterystykę jednak
oferowane rozwiązanie musi wspierać co najmniej eksport i import
definicji procesów zgodnie ze standardem XPDL. Specyfikacja ta
musi posiadać wsparcie i być stosowana przez powszechnie znanych
producentów oprogramowania na świecie.
Zgodność ze specyfikacją XPDL winna być potwierdzona przez
autorów oferowanej specyfikacji, w formie pisemnej (dokument
potwierdzający zgodność) lub opublikowana jako powszechnie
dostępna informacja w Internecie na stronach autorów specyfikacji
XPDL.
Na listę zgodności musi zostać wpisany oferowany System
Elektronicznego Obiegu Dokumentów.
Kopia potwierdzenia (lub wydruk z ogólno dostępnej strony
internetowej, z podaniem adresu) winna być złożona jako integralna
część oferty.
Administrator systemu musi posiadać możliwość zarządzania
procesami / ścieżkami workflow. Interfejs aplikacji musi pozwolić w
prosty sposób (bez znajomości języków programowania) na
definiowanie nowych procesów / ścieżek workflow.
Workflow musi być wyposażony w graficzne narzędzie
umożliwiające definiowanie ścieżki dostępne z poziomu
przeglądarki internetowej.
Strona 37 z 51
34.6
34.7
34.8
34.9
34.10
34.11
34.12
34.13
34.14
34.15
34.16
Narzędzie musi umożliwiać rozmieszczanie elementów ścieżki
(punktów ścieżki) metodą przeciągnij i upuść (ang. drag and drop).
Przenoszenie elementów oraz ich łączenie musi być możliwe do
wykonania za pomocą urządzenia wskazującego (myszki
komputerowej).
Narzędzie do graficznego modelowania ścieżek workflow musi
umożliwiać tworzenie graficznego schematu procesu w
dwuwymiarowej grafice wektorowej.
Narzędzie do graficznego modelowania ścieżek workflow musi być
oparte o rozwiązanie którego specyfikacja jest jawna i nie podlega
żadnym prawom patentowym
Narzędzie do graficznego modelowania ścieżek Workflow musi
pozwalać na rozszerzenie jego funkcjonalności poprzez dodanie
własnych elementów i właściwości przy pomocy standardowych
technik XML.
Narzędzie do graficznego modelowania ścieżek Workflow musi być
niezależne od platformy systemowej.
Narzędzie do graficznego modelowania ścieżek musi również
zapewniać możliwość łączenia obiektów w sposób graficzny –
poprzez łączenie punków strzałkami, które mogą być swobodnie
kształtowane za pomocą krzywych Beziera
Workflow musi umożliwiać definicję punktów (kroków) w ścieżce
oraz połączeń pomiędzy tymi punktami.
Workflow musi umożliwiać opisanie czynności, które muszą zostać
wykonane w wybranym punkcie ścieżki.
Workflow musi informować poprzez odpowiednie oznaczenie
graficzne, w którym punkcie realizacji znajduje się użytkownik.
Poprzez odpowiednie oznaczenie graficzne rozumie się oznaczenie
punktu w odmiennym kolorze w stosunku do pozostałych punktów
ścieżki.
Workflow musi zapisywać pełną historię wszystkich zdarzeń, które
miały miejsce w ścieżce wraz z oznaczeniem daty i godziny
wykonania oraz użytkownika, który wykonywał wybraną operację.
W historii zdarzeń powinny się zawierać co najmniej informacje
takie jak: kto wykonał daną operację, kiedy to nastąpiło, daty
zakończenia i rozpoczęcia punktów i ścieżek.
Workflow musi umożliwiać wykorzystanie wyrażeń arbitralnych
XOR, AND w zakresie realizacji warunków określonych w
poszczególnych punktach ścieżki.
Strona 38 z 51
34.17 Workflow musi umożliwiać definiowanie formularzy i
przyporządkowanie ich do poszczególnych punktów ścieżki oraz
podpisywanie tych formularzy podpisem elektronicznym przez wielu
użytkowników. Podczas definicji formularzy dostępne muszą być
następujące typy pól: data, data i czas, lista wyboru, plik, pole
tekstowe, pole text area, checkbox, radiobutton, pole typu dokument
– pozwalające na podpięcie identyfikatora dokumentu z SEOD do
formularza, pole typu sprawa pozwalające na podpięcie do
formularza identyfikatora sprawy. Dodatkowo musi istnieć
możliwość wskazania źródła danych zasilających wartości dla
danych pól. Powinny to być co najmniej: właściciel ścieżki,
zalogowany użytkownik, właściciel sprawy, numer zadania, lista
aktywnych użytkowników systemu.
34.18 SEOD musi umożliwiać zarządzanie rolami, do których mogą zostać
przypisani użytkownicy. Po zdefiniowaniu roli i przypisaniu do niej
użytkowników, workflow musi umożliwiać wykorzystanie jej
podczas definicji kolejnych ścieżek. Powinna istnieć możliwość
wykorzystania zdefiniowanej roli dowolną ilość razy w każdej ze
ścieżek. Definicja roli powinna być możliwa na etapie definiowania
ścieżki. W każdej chwili definiowania ścieżki lub jej modyfikowania
musi istnieć możliwość zdefiniowania nowej roli.
34.19 SEOD musi posiadać możliwość definiowania przedziału czasu z
dokładnością przynajmniej do 1 dnia, w którym musi zostać
wykonana ścieżka oraz czasu wykonania czynności dla każdego z
punktów ścieżki. Musi istnieć mechanizm weryfikujący czas
przypisany w poszczególnych punktach do ogólnego czasu
przypisanego ścieżce tak by nie było możliwe przekroczenie czasu
przypisanego ścieżce bez poinformowania o tym uczestników
ścieżki lub punktu w ścieżce.
34.20 SEOD musi informować uczestników punktu i ścieżki o czasie
pozostałym do realizacji całej ścieżki oraz punktu w tej ścieżce.
34.21 Mechanizm Workflow powinien być wbudowany w SEOD.
Workflow musi być w pełni dostępny w języku polskim – zarówno
mechanizm po stronie użytkownika jak i administratora,
definiującego ścieżki Workflow. Mechanizm Workflow powinien
pozwalać administratorowi na zdefiniowanie dowolnej ilości
ścieżek. Każdy element mechanizmu Workflow powinien być
dostępny za pośrednictwem graficznej przeglądarki internetowej.
35
Faks
Strona 39 z 51
35.1
35.2
36
36.1
36.2
SEOD musi posiadać możliwość automatycznego rejestrowania
faksów. Zamawiający dopuszcza stosowanie aplikacji zewnętrznej
do obsługi faksów o ile nie będzie to wymagało wykonywania
dodatkowych czynności przez użytkowników. Tzn. aplikacja
powinna automatycznie wprowadzać faks do rejestru dokumentów
SEOD – ewentualny opis dokumentu w SEOD musi być możliwy z
poziomu przeglądarki internetowej.
Faksy wpływające powinny być automatycznie (okresowo)
wprowadzane do SEOD. Faks powinien trafiać na listę nowych
dokumentów, gdzie każdy z operatorów posiadających uprawnienia
do dokumentów danej komórki, będzie miał możliwość
zarejestrowania dokumentu.
Integracja SEOD z MS Outlook
Z poziomu Microsoft Outlook (w wersji co najmniej 2000, 2003 i
2007) musi istnieć możliwość rejestracji poczty email jako
dokumentu w SEOD poprzez wypełnienie formatki dokumentu.
Instalator pluginu pocztowego musi być dostępny w formacie .MSI
Integracja SEOD z Elektroniczną Skrzynką Podawczą
SEOD powinien posiadać mechanizmy pozwalające na integrację
rozwiązania pełniącego rolę Elektronicznej Skrzynki Podawczej
(ESP). SEOD powinien bezproblemowo współpracować co najmniej
z rozwiązaniem dostępnym na platformie ePUAP w wersji aktualnej
na dzień podpisania umowy.
37.2 SEOD powinien posiadać mechanizmy pozwalające na integrację z
dowolną Elektroniczną Skrzynką Podawczą pozwalającą na
integrację za pomocą webservices.
Moduł Skanowania WEB
38
38.1 SEOD powinien posiadać możliwość skanowania bezpośrednio z
poziomu wbudowanego narzędzia uruchamianego i osadzonego w
oknie przeglądarki, zintegrowanego z SEOD. Dopuszcza się
stosowanie tego narzędzia z poziomu stacji roboczej.
38.2 Moduł aplikacji do skanowania dostępny z poziomu przeglądarki
internetowej może być instalowany po stronie stacji roboczej
użytkownika, ale tylko przy jego pierwszym uruchomieniu.
Archiwum spraw
39
39.1 SEOD musi posiadać wbudowany mechanizm umożliwiający
przeniesienie wybranych spraw oraz dokumentów w poszczególnych
jednostkach organizacyjnych Zamawiającego do archiwum danej
jednostki organizacyjnej Zamawiającego. Sprawy przeniesione do
archiwów zakładowych muszą być nadal dostępne dla użytkownika z
uprawnieniami tylko do odczytu.
SEOD musi posiadać możliwość generowania paczki archiwalnej
zgodnie z obowiązującymi przepisami.
37
37.1
Strona 40 z 51
SEOD musi posiadać mechanizm pozwalający na import oraz export
paczki archiwalnej zgodny z Rozporządzeniem 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. Import musi być
dostępny z poziomu SEOD poprzez wskazanie pliku stanowiącego
paczkę archiwalną
39.3 Archiwum musi być modułem SEOD, do którego dostęp mogą
posiadać tylko wybrani użytkownicy jednostek organizacyjnych
Zamawiającego zgodnie z nadanymi przez administratora
uprawnieniami.
39.4 SEOD musi umożliwiać przenoszenie zamkniętych spraw do
archiwum.
39.5 SEOD musi umożliwiać nadanie uprawnień w zakresie możliwości
tworzenia spisów zdawczo-odbiorczych oraz przekazywania tych
spisów do archiwum. Tworzenie spisów zdawczo-odbiorczych oraz
ich przekazywanie do archiwum powinno być proste, oparte o
mechanizm kreatora.
39.6 SEOD musi umożliwiać zarządzanie uprawnieniami w zakresie
dostępu do spisów zdawczo-odbiorczych.
39.7 SEOD musi zapewniać możliwość tworzenia wykazów
(zestawienie) spisów zdawczo-odbiorczych.
39.8 SEOD musi umożliwiać utworzenie spisu zdawczo-odbiorczego z
wykorzystaniem następujących parametrów:
• Komórka organizacyjna (możliwość wyboru jednocześnie
wielu komórek),
• Symbol JRWAUG (możliwość wyboru wielu symboli
jednocześnie),
Daty od - do (możliwość zawężenia zakresu, z którego ma być
utworzony spis zdawczo-odbiorczy).
39.9 SEOD musi zapewniać możliwość wydruku opisu teczki zgodnie z
obowiązującym u Zamawiającego wzorem.
39.10 SEOD musi umożliwiać przeprowadzenie procesu akceptacji spisu
zdawczo-odbiorczego, w którym możliwa jest akceptacja lub
odrzucenie spisu. Akceptacja spisów zdawczo-odbiorczych powinna
opierać się o wbudowany w system mechanizm akceptacji, a nie
powinna być procesem workflow.
39.11 SEOD musi umożliwiać wykonywanie spisów zdawczo odbiorczych
przez wybranego użytkownika dla wybranych komórek
organizacyjnych np.: całego urzędu, departamentu czy biura oraz
wszystkich komórek podrzędnych w tej jednostce.
39.12 SEOD musi numerować kolejno spis zdawczo-odbiorczy po
umieszczeniu go w wykazie spisów zdawczo-odbiorczych.
39.2
Strona 41 z 51
39.13 SEOD musi umożliwiać zarządzanie uprawnieniami w zakresie
możliwości dołączania spisów zdawczo-odbiorczych do wykazu
spisów. Nadawanie uprawnień powinno odbywać się z poziomu
panelu administratora SEOD.
39.14 SEOD musi umożliwiać dodawanie uwag do pojedynczej teczki
(sprawy) umieszczonej w spisie zdawczo-odbiorczym.
39.15 SEOD musi umożliwiać modyfikację kategorii archiwalnej dla
wybranej teczki umieszczonej w spisie zdawczo-odbiorczym.
39.16 SEOD musi umożliwiać usuwanie oraz modyfikację spisów
zdawczo-odbiorczych wybranym użytkownikom zgodnie z
posiadanymi przez nich uprawnieniami.
39.17 SEOD musi zabezpieczać przed usunięciem spisów zdawczoodbiorczych i innych danych, które byłoby niezgodne z
obowiązującymi przepisami.
39.18 SEOD musi umożliwiać udostępnianie akt w formie elektronicznej
wybranemu użytkownikowi SEOD. Mechanizm udostępniania akt
musi być analogiczny do udostępniania akt w formie papierowej,
odpowiednio zmieniony do obsługi akt elektronicznych.
39.19 SEOD musi umożliwiać odnotowanie faktu udostępnienia akt
przechowywanych w formie papierowej nie sklasyfikowanych w
formie elektronicznej. SEOD musi umożliwić dodanie wpisu, który
będzie wskazywał na to, że akta w formie papierowej zostały
udostępnione konkretnej osobie, oraz kiedy miało to miejsce.
39.20 SEOD musi zapewniać możliwość oznaczania ram czasowych, w
których dokumentacja będzie udostępniana.
39.21 SEOD musi zapewniać ewidencję udostępnionych akt w formie listy
lub raportu oraz informować o przekroczonych terminach
udostępnienia.
39.22 SEOD musi umożliwiać udostępnianie całych teczek aktowych oraz
pojedynczych spraw przekazanych do archiwum.
39.23 SEOD musi zapewniać możliwość przeszukiwania zasobu
archiwalnego względem metadanych opisujących materiały
przekazane do archiwum (dokumenty, sprawy i inne elementy
wytworzone podczas pracy w SEOD).
39.24 SEOD musi zapewniać zapis historii zdarzeń wykonywanych
względem materiałów przekazanych do archiwum.
40
OCR - rozpoznawanie tekstu
40.1 SEOD musi posiadać możliwość współpracy ze zintegrowanym
mechanizmem skanowania dokumentów i rozpoznawania tekstu –
OCR.
40.2 SEOD musi umożliwiać działanie mechanizmu OCR po stronie
serwera i umożliwiać rozpoznawanie tekstu automatycznie, bez
udziału użytkownika.
Strona 42 z 51
40.3
40.4
41
41.1
41.2
41.3
41.4
Aplikacja OCR musi poprawnie rozpoznawać dokumenty w języku
polskim, a także językach wszystkich krajów Europy oraz
dodatkowo w rosyjskim.
Aplikacja OCR musi umożliwiać obsługę formatów:
• PDF: zapis do formatu PDF (w wersji 1.6 oraz
wcześniejszej), włączając PDF/Archive (PDF/A).
• BMP: 2-bit – nieskompresowany czarno-biały,
16-bit – nieskompresowany Mask,
24-bit – nieskompresowany Palette i TrueColor,
32-bit – nieskompresowany Mask,
• PCX, DCX: 2-bit – nieskompresowany czarno-biały,
4- i 8-bit – skala szarości, TrueColor
• JPEG: skala szarości, kolor,
• JPEG 2000: skala szarości – Part 1, kolor – Part 1,
• TIFF: czarno-biały – nieskompresowany, CCITT3,
CCITT3FAX, CCITT4, Packbits, ZIP, LZW,
skala szarości – nieskompresowany, Packbits, JPEG, ZIP,
LZW,
TrueColor - nieskompresowany, JPEG, ZIP, LZW,
Palette - nieskompresowany, Packbits, ZIP, TIFF,
• GIF: czarno biały – skompresowany LZW,
skala szarości – skompresowany LZW,
TrueColor – skompresowany LZW,
• PNG: czarno biały, skala szarości, kolor.
Integracja SEOD z ePUAP
Mechanizm integracji z ePUAP musi zapewniać możliwość
definiowania/dodawania nowych skrzynek z poziomu panelu
administratora SEOD
Mechanizm integracji z ePUAP musi zapewniać możliwość
edytowania parametrów zdefiniowanych skrzynek z poziomu panelu
administratora SEOD. SEOD musi pozwalać na edycję co najmniej
następujących parametrów skrzynki: Nazwa podmiotu powiązanego
ze skrzynką, Nazwa skrzynki, Adres skrzynki, komórka
organizacyjna (urząd) do której skrzynka jest przyporządkowana,
Termin doręczenia (termin ważności doręczenia, czas po którym
doręczenie jest uznawana za nieudane).
Mechanizm integracji z ePUAP musi zapewniać możliwość
zdefiniowania dowolnej ilości skrzynek z poziomu panelu
administratora SEOD.
Mechanizm integracji z ePUAP musi zapewniać możliwość
przyporządkowania poszczególnych skrzynek do odpowiednich
jednostek organizacyjnych Zamawiającego.
Strona 43 z 51
41.5
41.6
41.7
41.8
Mechanizm integracji z ePUAP musi zapewniać możliwość
pobierania dokumentów wraz z UPP (Urzędowe Poświadczenie
Przedłożenia) lub UPD (Urzędowe Poświadczenie Doręczenia) ze
skrzynki ePUAP z rozdzieleniem na skrzynki zdefiniowane w
obrębie skrzynki (konta) na żądanie użytkownika systemu.
Dokumenty pobierane z platformy ePUAP powinny trafiać na listę
dokumentów oczekujących na rejestrację w SEOD
SEOD powinien automatycznie wypełniać pola opisujące dokument
– na podstawie metadanych zawartych w dokumencie pobieranym z
platformy ePUAP. Powinny to być co najmniej pola opisujące
nadawcę dokumentu. SEOD powinien również automatycznie
oznaczać sposób dostarczenia takiego dokumentu jako dokumentu
pochodzącego z ePUAP.
SEOD automatycznie musi wyszukiwać w swojej bazie podmiotów
informacje czy dany podmiot nie znajduje się już w bazie
podmiotów SEOD. Jeśli tak – dane opisujące nadawcę powinny być
automatycznie wypełniane na etapie rejestracji dokumentu w SEOD.
41.9 SEOD musi prezentować podgląd dokumentu już podczas jego
rejestracji. Podgląd musi być widoczny w tym samym oknie co
formularz służący do zarejestrowania dokumentu w SEOD.
41.10 SEOD musi automatycznie oznaczać dokumenty pochodzące z
platformy ePUAP.
41.11 SEOD musi umożliwiać utworzenie sprawy na podstawie
odebranego dokumentu. SEOD musi zapewniać możliwość wysłania
odpowiedzi do ePUAP bezpośrednio z SEOD. Np. z poziomu
dokumentu lub sprawy założonej w SEOD. Odpowiedź (plik,
formularz) musi być umieszczona w odpowiedniej kopercie XML,
tak aby była akceptowana przez platformę ePUAP.
41.12 Użytkownik SEOD, pracujący nad dokumentem, który pochodzi z
ePUAP, musi widzieć podgląd dokumentu (wizualizacja wysłanego
formularza). SEOD musi również zapewniać możliwość pobrania
dokumentu (pliku xml zawierającego dane) na komputer lokalny
danego użytkownika.
41.13 SEOD musi zapewniać, że załączniki znajdujące się w dokumencie
pochodzącym z ePUAP będą widoczne w SEOD również jako
załączniki do zarejestrowanego w SEOD dokumentu. Np. pliki .doc,
.txt, .odt. SEOD musi umożliwiać użytkownikowi możliwość
pobrania samego załącznika.
41.14 Integracja SEOD z ePUAP musi umożliwić uprawnionym
użytkownikom pełną komunikację z ePUAP bez konieczności
logowania się użytkowników na platformie ePUAP.
Strona 44 z 51
41.15 Integracja SEOD z ePUAP musi umożliwiać obsługę formularzy
zdefiniowanych za pomocą edytora formularzy ePUAP. Poziom
integracji musi umożliwiać odebranie tak wypełnionego formularza,
rozpoznanie przez SEOD jego kategorii oraz automatyczne
przeniesienie metadanych identyfikujących dokument/formularz do
pól opisujących dokument w SEOD.
41.16 Integracja SEOD z ePUAP musi umożliwiać automatyczne
odesłanie odpowiedzi na dokument wpływający z ePUAP do
wszystkich stron zainteresowanych w prowadzonej w SEOD
sprawie.
41.17 SEOD musi umożliwiać odesłanie do ePUAP podpisanych
elektronicznie (podpis kwalifikowany i/lub niekwalifikowany)
dokumentów będących odpowiedzią na dokument wpływający z
ePUAP.
41.18 SEOD musi umożliwiać odesłanie dokumentów do ePUAP w tzw.
trybie UPD (Urzędowe Poświadczenie Doręczenia) – z żądaniem
potwierdzenia dostarczenia dokumentu.
42
Raporty / Wyszukiwanie
42.1 SEOD musi posiadać mechanizm definicji raportu z danych, do
których dostęp ma użytkownik. SEOD musi umożliwiać
wygenerowanie co najmniej następujących raportów w formacie co
najmniej .xls lub .pdf:
• raport zarejestrowanych dokumentów z uwzględnieniem
pól: przedział czasowy od do, numery dokumentów od do,
kategoria dokumentu, komórka organizacyjna, sposób
dostarczenia dokumentu, nadawca, adresat, podział na
przychodzące, wychodzące wewnętrzne, osoba rejestrująca
dokument.
Powinna istnieć możliwość dodania do raportu kolumn:
podpis i lokalizacja, umożliwiających odpowiednio
podpisanie się na wydrukowanym raporcie określonego
użytkownika np.: odbierającego dokument oraz wydruk
lokalizacji fizycznej, w której umieszczono dokument
papierowy.
• książka doręczeń z uwzględnieniem następujących pól:
data wprowadzenia dokumentu, numer kolejny dokumentu,
kategoria dokumentu, data na dokumencie, znak na
dokumencie, nadawca, adresat, opis dokumentu, data odbioru,
data zwrotu.
• książka pocztowa nadawcza w pełni zgodna ze wzorem
ogłoszonym przez Pocztę Polską z uwzględnieniem pól:
przedział czasowy od do, numery dokumentów od do,
komórka organizacyjna, typ listu (zwykły, polecony),
• spraw i dokumentów powiązanych z wybranym
podmiotem,
Strona 45 z 51
42.2
42.3
42.4
42.5
42.6
42.7
• bazy adresowej umożliwiający podział na podmioty
prawne i fizyczne, oraz zawierający wszystkie pola opisujące
podmiot,
• spis dokumentów i spraw, do których dostęp posiadają
podwładni wybranego użytkownika z uwzględnieniem pól:
imię i nazwisko, sprawy (otwarte, zamknięte), dokumenty,
przedział czasowy od do,
• spis spraw wybranej komórki organizacyjnej z
uwzględnieniem pól: przedział czasowy od do, właściciel
sprawy, osoby prowadzące sprawy,
• spis spraw i dokumentów własnych zawierający
informacje o elementach, których użytkownik jest
właścicielem bądź uczestniczy jako osoba prowadząca z
uwzględnieniem pól: przedział czasowy od do,
Raporty powinny być dostępne z poziomu dedykowanych funkcji,
nie poprzez wyszukiwanie, tak aby użytkownik nie musiał za
każdym razem definiować parametrów raportu a jedynie zmieniać
np. zakres dat.
SEOD musi umożliwiać podgląd raportów w formie graficznej
widocznej na ekranie oraz ich eksport co najmniej do formatów xls,
pdf.
SEOD musi posiadać funkcję tzw. wyszukiwania prostego. Za jego
pomocą musi być możliwe przeszukanie wszystkich elementów po
wpisaniu szukanego słowa lub wyrażenia do okna wyszukiwania,
bez konieczności zawężania widoku do poszczególnych elementów
SEOD.
Okno wyszukiwania prostego musi być cały czas widoczne podczas
pracy z SEOD przynajmniej w zakresie prac realizowanych przez
użytkowników załatwiających sprawy.
Funkcja wyszukiwania prostego musi zapamiętywać przynajmniej
10 ostatnio wpisanych wyrażeń lub słów przez użytkownika i
umożliwiać ich wybór z listy. Po wyborze szukane wyrażenie
powinno być automatycznie wpisywane do okna wyszukiwania.
SEOD musi umożliwiać tworzenie raportu ze zdefiniowanego
zapytania wyszukującego w obiektach systemu – za pomocą
mechanizmu wyszukiwania. System musi zapewnić
wyeksportowanie wyników wyszukiwania do formatu co najmniej
.xls lub .pdf.
SEOD musi umożliwiać wygenerowanie eksportu do pliku .xls
wybranego zakresu danych opisujących dokumenty, uwzględniając
również pola formularzy dynamicznych np. w przypadku dokumentu
typu faktura, opisywanego polami kwota netto, kwota brutto – tak
aby raport taki umożliwiał np. sumowanie pól liczbowych w
zewnętrznej aplikacji typu arkusz kalkulacyjny.
Strona 46 z 51
42.8
43
43.1
SEOD musi umożliwić wybór kolumn, które mają być
wyeksportowane do pliku arkusza kalkulacyjnego .xls.
Gwarancja i serwis SEOD
Wykonawca jest zobowiązany do zapewnienia 36 miesięcznego
okresu gwarancyjnego dla dostarczonego rozwiązania SEOD w tym
zapewnienia aktualizacji komponentów SEOD do wydawanych
nowych (poprawionych) wersji.
Spełnienie
warunków
44. Sprzęt komputerowy –
44.1
45
45.1
45.2
45.3
45.4
Konfiguracja rozwiązania oraz specyfikacja parametrów
minimalnych:
TAK/NIE
SEOD musi poprawnie pracować w oparciu o następującą
konfigurację sprzętową
będącą integralną częścią postępowania:
Serwer systemu SEOD wraz z macierzą dyskową NAS do
wykonywania backupu systemu oraz osprzętem dodatkowym w
postaci skanerów dokumentowych, zapasowego źródła zasilania,
przełącznika 1Gb/s, szafy serwerowej oraz przełącznika KVM..
Serwer bazodanowy dla systemu SEOD – 1 sztuka
powinien posiadać parametry nie gorsze niż:
Płyta główna: :
Dedykowana, serwerowa, wyprodukowana i zaprojektowana przez
producenta serwera,
min 18 gniazd pamięci RAM,
min 2 sloty PCIe x8
min 4 sloty PCIe 4x
(min. dwa porty PCIe x4 powinny być możliwe do użycia jako PCIe
x8 jeżeli sąsiedni slot jest pusty)
min 10 portów USB (w tym min. 3 z przodu, 4 z tyłu i 2 w środku)
2 porty RS-232 (w tym jeden dostępny zarówno dla systemu jak i dla
kontrolera zdalnego zarządzania)
2 porty VGA (1 z przodu, 1 z tyłu)
Obudowa:
RACK 19”, max.2U
Procesory:
Dwa procesory klasy serwerowej w architekturze x86, będące w
produkcji nie dłużej niż 2 lata:
- 64 bity,
- min. 4 rdzenie, 8 wątków,
- cache min. 8 MB
Pamięć:
Min: 32 GB RAM typu Advanced ECC, registered,
DDR3 co najmniej 1333 MHz, z opcją aktywnej rezerwy i zapisu
lustrzanego,
obsadzone min. 2 gniazda w trybie niezależnym,
Strona 47 z 51
45.5
45.6
45.7
45.8
45.9
45.10
45.11
45.12
możliwość rozbudowy do 192 GB
HDD:
6 sztuk dysków twardych typu SATA II, hot-plug, nie mniejsze niż
500 GB, 3,5”, 7200 krpm każdy, wewnętrzne, pracujące w macierzy
sprzętowej RAID 5.
Serwer musi posiadać możliwość jednoczesnej instalacji dysków
SATA i SAS.
Kontrolery:
SATA, 2 kanałowy SATA dla DVD i backupu, SAS 6G min. 8
portów:
z obsługą min. RAID 5/6
Napęd:
DVD-RW wewnętrzny
Panel serwisowy z wyświetlaczem LCD
Karty sieciowe:
Dwie karty Ethernet 10/100/1000 Mb/s
Jedna karta Ethernet 10/100 Mb/s do komunikacji z kontrolerem
zdalnego zarządzania
Zasilanie:
Dwa redundantne zasilacze 800 W na zasilacz, zgodne ze
standardem EPA,
hot-plug,
Sprawność min. 92% przy obciążeniu 50%
(potwierdzone międzynarodowym raportem badawczym
honorowanym w Unii Europejskiej)
Chłodzenie:
Nadmiarowe redundantne wentylatory typu hot-plug
Oprogramowanie:
Oprogramowanie zarządzające i diagnostyczne producenta serwera,
pozwalające na konfigurację kontrolera RAID, instalację systemów
operacyjnych, zdalne zarządzanie, diagnostykę i przewidywanie
awarii w oparciu o zintegrowany w serwerze system monitorujący.
45.13 Kontroler zdalnego zarządzania:
Zgodny z IPMI 2.0, pozwalający na zdalny restart serwera i pełne
zarządzanie z przejęciem konsoli tekstowej.
Dedykowana karta sieciowa dla kontrolera zdalnego zarządzania z
możliwością przeniesienia tej komunikacji na inną kartę sieciową
współdzieloną z systemem operacyjnym
45.14 System operacyjny serwera:
Serwer musi być dostarczony z zainstalowanym systemem
operacyjnym pozwalającym na pełną realizację całego Projektu
SEOD, z odpowiednią do Projektu ilością licencji.
Strona 48 z 51
45.15
45.16
45.17
46
46.1
46.2
46.3
46.4
46.5
46.6
46.7
46.8
47
47.1
47.2
47.3
47.4
47.5
47.6
47.7
47.8
47.9
47.10
Wymagana bezwzględna kompatybilność serwera z oferowanym w
ramach projektu systemem operacyjnym, potwierdzona
oświadczeniem Wykonawcy lub certyfikatem kompatybilności
serwera z oferowanym systemem operacyjnym.
Certyfikaty i normy:
Serwer musi być produkowany zgodnie z normą ISO 9001 oraz
spełniać normę EnergyStar
Oferowany serwer musi być dostarczony z całym niezbędnym do
działania wyposażeniem (kable połączeniowe, zasilające itp),
wszystkie niezbędne instrukcje, licencje oprogramowania oraz
nośniki ze sterownikami
Gwarancja:
Wymagana gwarancja na oferowany serwer to 36 miesięcy z
gwarantowanym czasem naprawy w ciągu 24 godzin od zgłoszenia,
możliwość zgłoszeń usterek 7x24h, potwierdzone oświadczeniem
producenta serwera
Macierz dyskowa NAS – 1 sztuka
o parametrach nie gorszych niż:
Obudowa:
RACK 19” max.2U
Obsługa dysków co najmniej SATA II, o pojemności do 2TB
Możliwość pracy w konfiguracji RAID 0/1/5/6
z funkcją rozbudowy i zmiany trybu bez utraty danych
4 dyski twarde o pojemności 1TB, pracujące w konfiguracji RAID 5
Współpraca z zasilaczami awaryjnymi UPS po USB lub SNMP
Monitorowanie stanu dysków
Redundantne zasilanie
Dwie karty sieciowe 1000 Mb/s
Zapasowe źródło zasilania UPS – 1 sztuka
o parametrach nie gorszych niż:
Obudowa: RACK 19’’
Układ automatycznej regulacji napięcia AVR
Sinus podczas pracy na baterii
Programowanie godziny włącz/wyłącz
Porty komunikacyjne RS232, USB
Gniazda zasilające – 8
Diody sygnalizacyjne oraz alarmy dźwiękowe stanu baterii i
urządzenia.
Instrukcja obsługi
Oprogramowanie zgodne z oferowanym systemem operacyjnym
Urządzenie powinno być wyprodukowane zgodnie z wymaganiami
normy jakości ISO 9001 lub równoważnej na cały proces produkcji
Strona 49 z 51
47.11 Moc pozwalająca na podtrzymanie całości konfiguracji sprzętowej
przez okres min. 20 minut i bezpieczne zamknięcie serwera oraz
wyłączenie macierzy dyskowej.
48 Skanery dokumentowe - 2 sztuki
Współpracujące z systemem SEOD, o parametrach nie gorszych
niż:
48.1 Moduł skanowania dwustronnego w standardzie
48.2 Obciążenie miesięczne min: 1000 stron
48.3 Podajniki na dokumenty min: 100 stron
48.4 Certyfikat EnergyStar – wymagany wpis w bazie na stronach http://www.euenergystar.org, lub oświadczenie producenta.
49
49.1
49.2
49.3
49.4
49.5
49.6
Szafa serwerowa – 1 sztuka:
Rodzaj: 19”, stojąca
Wymiary: 600mm x 1000mm
Wysokość: 42U
Stelaż 19’’,
Zamykana na klucz
Drzwi przednie– trzypunktowe, z zamkiem, stalowe, z perforacją o
zwiększonej przewiewności
49.7 Scianka tylna – zdejmowalna, zamykana na zamek, stalowa, z
perforacją o zwiększonej przewiewności
49.8 Ścianki boczne – pełne, stalowe, demontowane, zamykane na zamek
49.9
49.10
49.11
49.12
50
50.1
50.2
50.3
50.4
50.5
50.6
50.7
51
51.1
51.2
51.3
51.4
51.5
51.6
51.7
51.8
51.9
51.10
Szkielet na cokole z wysuwaną ramą wsporczą
Trzy pary belek nośnych w rozstawie 19”, regulowanych
Wyposażenie: Listwa zasilająca i linki uziemienia
Obciążenie min: 600 kg
Konsola KVM do szafy serwerowej – 1 sztuka:
konsola w pełni sprzętowa,
montaż szuflady w stelażu 19’’,
pojedyńcza szyna,
z monitorem: 15’’
8 portów PC/KVM
wybór zarządzanego komputera: przycisk oraz skrót klawiszowy,
wysuwana klawiatura z touchpadem
Przełącznik sieciowy Gigabitowy – 1 sztuka:
16 x port 1Gb/s
4 x SFP (współdzielone)
Zarządzalny, warstwa 2,
Graficzny interfejs użytkownika przez www
VLAN, 256 grup statycznych
QoS
Mirroring portów
ARP-spoofing
Agregacja łączy 802.3ad
ACL, oparte o MAC/IP
Strona 50 z 51
51.11 Uwierzytelnianie 802.1X RADIUS
51.12 Przystosowany do montażu w standardowej szafie 19’’
51.13 Wyłączanie nieaktywnych portów w celu zmniejszenia zużycia
energii tzw. zielone urządzenie ("green line"/"green IT").
52 Wszystkie dostarczone urządzenia winny być wyposażone w
niezbędne kable zasilające i połączeniowe, niezbędne
oprogramowanie, sterowniki oraz instrukcje obsługi w języku
polskim, oraz dokumenty potwierdzające spełnianie wymagań SIWZ
w szczególności wszystkie certyfikaty spełniania wymaganych norm.
52.1 Wykonawca winien dołączyć do oferty pełną specyfikację
oferowanego sprzętu obejmującą :
typ, dokładny model, pełną konfigurację oraz producenta
zaoferowanych komponentów sprzętowych.
zgodnie z załącznikiem nr 9 do SIWZ.
52.2 Wykonawca jest zobowiązany do zapewnienia 36 miesięcznego
okresu gwarancyjnego i serwisowego dla wszystkich dostarczonych
komponentów sprzętu komputerowego
.........................................., dnia. ....................... 2011r.
…..……………..….................................................
(imię i nazwisko oraz czytelny podpis osoby/ osób
uprawnionych do reprezentowania wykonawcy)
Strona 51 z 51