szczegółowy opis przedmiotu zamówienia

Transkrypt

BDG/12/2011/PN
zał. nr 2
SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA
I. Słownik.
Określenia użyte w szczegółowym opisie przedmiotu zamówienia oznaczają:
Słownik
Skrót/Termin
Wyjaśnienie
AJAX
(ang. Asynchronous JavaScript and XML, asynchroniczny JavaScript i
XML) – technologia tworzenia aplikacji internetowych, w której
interakcja użytkownika z serwerem odbywa się bez przeładowywania
całego dokumentu, w sposób asynchroniczny. Umożliwia to bardziej
dynamiczną interakcję z użytkownikiem niż w tradycyjnym modelu, w
którym każde żądanie nowych danych wiąże się z przesłaniem całej
strony HTML.
Architektura
trójwarstwowa
(ang. three-tier architecture lub three-layer architecture) – architektura
typu klient-serwer, w której interfejs użytkownika, przetwarzanie danych i
składowanie danych są rozwijane w postaci osobnych modułów, zwykle
na oddzielnych platformach;
Architektura tego typu pozwala aktualizować lub zastępować
poszczególne części systemów informatycznych niezależnie od siebie, w
miarę jak zmieniają się warunki techniczne np.: zmiana systemu
operacyjnego na komputerze użytkownika (np. z Windows na Linux lub
odwrotnie), wpływa jedynie na warstwę interfejsu użytkownika, ale nie na
przetwarzanie i składowanie danych.
BIP
Biuletyn Informacji Publicznej
Dokument
Przez dokument należy rozumieć element, dla którego został odnotowany
w dzienniku korespondencji moment wejścia lub wyjścia.
Dokument
elektroniczny
Stanowiący odrębną całość znaczeniową zbiór danych uporządkowanych
w określonej strukturze wewnętrznej i zapisany na informatycznym
nośniku danych.
Dziennik
korespondencji
Rejestr, w którym odnotowuje się informacje na temat korespondencji
przychodzącej i wychodzącej. Rolę dziennika korespondencji może pełnić
System Elektronicznego Obiegu Dokumentów.
Edytor
WYSIWYG
(ang. ‘What You See Is What You Get’) , akronim stosowany w
informatyce dla określenia metod, które pozwalają uzyskać wynik w
publikacji identyczny lub bardzo zbliżony do obrazu na ekranie.
EPUAP
Elektroniczna Platforma Usług Administracji Publicznej
Formularz
Formularz utworzony poprzez narzędzia zawarte w interfejsie SEOD, na
1
Słownik
Skrót/Termin
Wyjaśnienie
dynamiczny
podstawie którego następuje uzupełnienie SEOD dodatkowymi
informacjami np.: dodanie dodatkowych pól do formularza rejestracji
dokumentu.
Funkcja,
Funkcjonalność
Istniejąca w aplikacji część, odpowiadająca za wykonywanie
automatycznie lub półautomatycznie (z udziałem człowieka) określonych
czynności. Najczęściej jej działanie wiąże się z w wywołaniem jej z
poziomu interfejsu użytkownika.
Jednolity
Rzeczowy Wykaz
Akt Urzędów
Górniczych ,
JRWAUG
Wykaz haseł wyrażający rzeczową klasyfikację dokumentacji
rejestrowanej w urzędach górniczych niezależnie od ich struktury
organizacyjnej, oparty o dziesiętny sposób sygnowania haseł
klasyfikacyjnych oraz zawierający kwalifikację archiwalną akt.
Jednostka
organizacyjna
Urząd Górniczy, departament, biuro, wydział oraz inne komórki
zdefiniowane w regulaminie organizacyjnym Zamawiającego
Komponent
Pojedynczy element wymagany do poprawnej realizacji przedmiotu
Zamówienia. Może nim być sprzęt, oprogramowanie, dokumentacja itd.
Komunikator
Aplikacja umożliwiającą komunikację pomiędzy użytkownikami na
zasadzie podobnej do komercyjnych rozwiązań, takich jak: np. GaduGadu
Metadane
zestaw logicznie powiązanych z dokumentem elektronicznym
usystematyzowanych informacji opisujących ten dokument, ułatwiających
jego wyszukiwanie, kontrolę, zrozumienie i długotrwałe przechowanie
oraz zarządzanie.
Moduł
Wydzielona funkcjonalność systemu, której uruchomienie odnosi efekt w
postaci pojawienia się nowych funkcji i elementów w SEOD, poprzez
zmianę parametrów konfiguracyjnych działania aplikacji. Uruchomienie
oraz wyłączenie modułu nie może zależeć od dokonywania modyfikacji
kodu źródłowego aplikacji i musi być możliwe do wykonania przez
użytkownika nie posiadającego wiedzy technicznej.
N, n
Litera N (n) opisuje nieokreśloną liczbę wystąpień elementu i może
przyjmować różne wartości w zależności od konfiguracji dokonywanej
przez Pracownika (posiadającego stosowne uprawnienia).
Natywne
Wbudowane w dostarczane rozwiązanie, dostarczane w standardzie,
dostępne „z pudełka”, w pełni zintegrowane.
Obiekt
Funkcja, zestaw funkcji, mechanizm lub wynik działania funkcji mający
swoje odniesienie w aplikacji, często opisany metadanymi, który może
udostępniać Graficzny Interfejs Użytkownika. Obiektem może być Klient,
Konto Użytkownika itp.
Otwarty standard
Technologia, której pełna specyfikacja została upubliczniona np.: w
Internecie, przez organizację która zajmuje się opracowywaniem tego
standardu. Cechą charakterystyczną jest zagwarantowanie możliwości jej
2
Słownik
Skrót/Termin
Wyjaśnienie
nieodpłatnego wykorzystania.
Profil zaufany
Konto użytkownika, którego wiarygodność została potwierdzona poprzez
weryfikację danych osobowych podczas osobistego stawiennictwa w
urzędzie z dowodem tożsamości.
SEOD
System Elektronicznego Obiegu Dokumentów – aplikacja lub zestaw
aplikacji komputerowych umożliwiających realizację zadań w zakresie
rejestracji oraz zarządzania dokumentami i sprawami, będących
przedmiotem działania Urzędów Górniczych
Spis spraw
formularz na nośniku papierowym lub informatycznym służący do
chronologicznego rejestrowania spraw w obrębie teczki założonej zgodnie
z wykazem akt w danym roku kalendarzowym na danym stanowisku
pracy
Ścieżka Workflow Graficznie zaprezentowana ścieżka, według której realizowany jest proces
przepływu pracy odzwierciedlający zakres pracy wykonywany w
kontekście zadania zleconego użytkownikowi lub wielu użytkownikom.
Ścieżka workflow składa się z punktów, które zawierają czynności oraz
akcje umożliwiające realizację określonych czynności. Pojedynczy punkt
może być np.: formularzem, który wypełni użytkownik lub zdarzeniem
wysyłającym pocztę elektroniczną na wybrany adres email.
Teczka
Teczka wiązana, skoroszyt, koperta, segregator, katalog wirtualny,
zestawienie tabelaryczne (lista komputerowa) itp., służąca do
przechowywania jednorodnych lub rzeczowo pokrewnych akt spraw
ostatecznie załatwionych, objętych tą samą grupą akt ustaloną wykazem
akt, jak również teczka obejmująca dokumentacje jednej sprawy oraz
teczka zbiorcza; stanowi przeważnie odrębną jednostkę archiwalną.
Workflow
(ang. Work flow) - przepływ pracy - w sensie szerszym, pojęcie
określające sposób przepływu informacji pomiędzy rozmaitymi obiektami
biorącymi udział w jej przetwarzaniu; w węższym sensie to określenie
sposobu przepływu dokumentów pomiędzy pracownikami wykonującymi
pewien zalgorytmizowany zespół czynności.
Znak sprawy,
Oznaczenie
dokumentu w
sprawie,
Klasyfikator
Znak sprawy oznacza nadanie sprawie oraz dokumentom w sprawie
następującego oznakowania zgodnego z instrukcją kancelaryjną
Zamawiającego:
Znak sprawy: ABC1)/02012)/00723)/20114)
1)
Symbol literowy komórki organizacyjnej, okręgowego urzędu
górniczego albo specjalistycznego urzędu górniczego, zgodny z
oznaczeniem wprowadzonym przez regulamin organizacyjny
Wyższego Urzędu Górniczego albo regulamin organizacyjny
okręgowych urzędów górniczych oraz Urzędu Górniczego do Badań
Kontrolnych Urządzeń Energomechanicznych – 3 znaki.
3
Słownik
Skrót/Termin
Wyjaśnienie
2)
3)
4)
Symbol klasyfikacyjny (liczbowy) sprawy przewidziany w Jednolitym
Rzeczowym Wykazie Akt Urzędów Górniczych (JRWAUG)
Kolejny numer, pod którym sprawa została zarejestrowana w systemie
w ramach hasła klasyfikacyjnego przewidzianego w jednolitym
rzeczowym wykazie akt urzędów górniczych w komórce
organizacyjnej – 4 znaki z poprzedzającymi zerami
oznaczenie roku kalendarzowego, w którym sprawa została
zarejestrowana w systemie w ramach hasła klasyfikacyjnego
przewidzianego w jednolitym rzeczowym wykazie akt urzędów
górniczych – 4 znaki
Oznaczenie dokumentu w sprawie:
ABC1)/02012)/00723)/20114)/0017535)/YYY6)
5)
6)
ESS
[dane 1)—4): znak sprawy]
Kolejny numer dokumentu w danym roku kalendarzowym, nadany
przez system na podstawie wspólnego rejestru spraw przychodzących,
wychodzących i wewnętrznych - 6 znaków z poprzedzającymi zerami
Unikalny symbol literowy referenta sprawy, co do zasady zgodny z
inicjałami referenta sprawy i ew. oznaczeniem liczbowym lub
literowym np. JK1
Elektroniczny System Serwisowy – umowna nazwa systemu (aplikacji)
dostępna poprzez przeglądarkę internetową umożliwiająca centralne
zarządzanie zgłoszeniami serwisowymi poprzez dwukierunkową wymianę
informacji pomiędzy Zamawiającym a Wykonawcą.
4
II. System Elektronicznego Obiegu Dokumentów (SEOD) – Koncepcja i Wymagania
Funkcjonalne
Szczegółowy opis przedmiotu zamówienia
Lp.
Opis wymagania
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.
1.3
Udzielone licencje SEOD oraz wszystkich komponentów 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.
1.5
W wypadku zaoferowania wariantu licencyjnego w postaci ilości 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
1.6
SEOD musi posiadać wbudowane i możliwe do wskazania funkcje 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
• 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
1.7
1.8
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.
5
Lp.
Opis wymagania
1.9
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.
1.10 Ż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.
1.11 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.
1.12 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.
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.
1.15 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.
1.16 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,
6
Lp.
Opis wymagania
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,
c. Określenie kolumn widocznych na listach obiektów tj. dokumenty,
sprawy, rejestry, lista nowych dokumentów (oczekujących na
zarejestrowanie)
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)
1.17 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.
1.18 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.
1.19 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.
1.20 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.
1.21 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).
7
Lp.
Opis wymagania
1.22 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.
1.23 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.
1.24 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.
1.25 SEOD musi spełniać podstawowe warunki bezpieczeństwa poprzez:
• zapis operacji wykonywanych przez użytkownika w zakresie:
o Zapis notatki do sprawy i do dokumentu,
o Odczyt nowego dokumentu i nowej sprawy przesłanej do
użytkownika,
o Zapis i modyfikacja pliku dodanego do dokumentu i sprawy,
o Zablokowanie dostępu do sprawy lub dokumentu,
o Utworzenie sprawy,
o Nadanie lub usunięcie znaku sprawie,
o Dołączenie oraz odłączenie dokumentu do/od sprawy,
o Dodanie oraz usunięcie pliku dołączonego do dokumentu oraz sprawy,
o Dodanie notatki tekstowej do sprawy oraz dokumentu,
o Akceptacja oraz odrzucenie pliku,
o Przekazanie do akceptacji pliku,
o Połączenie sprawy z wybranym kontaktem z bazy adresowej,
o Dołączenie oraz odłączenie użytkownika do/od terminarza,
o Modyfikacja opisu oraz innych parametrów sprawy,
o Dołączenie oraz odłączenie maila do/od sprawy,
o 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.
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.
2.2
Instrukcja musi być podzielona zgodnie z częściami składowymi SEOD oraz jego
8
Lp.
Opis wymagania
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.
2.7
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.
2.8
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.
2.9
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.
3
Administracja systemem
3.1
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.
9
Lp.
Opis wymagania
• 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),
• 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
4
Dokumenty
Podczas rejestracji dokumentu SEOD musi umożliwiać przechodzenie pomiędzy
4.1
kolejnymi polami formularza rejestracji przy pomocy przycisku TAB (tabulacji).
SEOD musi umożliwiać opisanie dokumentu przynajmniej następującymi
4.2
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.
• 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:
10
Lp.
Opis wymagania
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
4.3
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
4.4
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.
SEOD musi posiadać możliwość zarządzania wielopoziomową strukturą folderów
4.5
(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.
4.6
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
4.7
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
4.8
11
Lp.
Opis wymagania
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
4.9
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.
4.10 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.
4.11 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).
4.12 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.
4.13 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.
4.14 SEOD powinien wyróżniać kolorem odnalezioną frazę w liście wybranych elementów
umożliwiając użytkownikowi identyfikację jej wystąpienia.
4.15 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
12
Lp.
Opis wymagania
być tylko te wyrażenia, które nie zawierają tego słowa.
4.16 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.
4.17 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
4.18
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.
4.19 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.
4.20 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.
4.21 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.
4.22 Dokumenty przyłączone do spraw muszą dziedziczyć znaki nadane tym sprawom
wraz z indywidualnym oznaczeniem dokumentu.
4.23 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.
4.24 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
13
Lp.
Opis wymagania
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.
4.25 Funkcja korespondencji seryjnej SEOD musi być dostępna za pomocą kreatora, który
krok po kroku przeprowadza użytkownika przez proces jej tworzenia.
4.26 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.
4.27 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).
5
Sprawy
SEOD musi posiadać mechanizmy pracy grupowej umożliwiające np.: wspólną pracę
5.1
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
5.2
do dokumentów z poziomu spraw zgodnie z posiadanymi uprawnieniami.
SEOD musi zapewnić możliwość zablokowania dostępu do danej sprawy/dokumentu
5.3
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.
5.4
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:
5.5
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.:
14
Lp.
Opis wymagania
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
5.6
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ę,
• 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
5.7
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
5.8
nadrzędna – podrzędna.
SEOD musi posiadać możliwość wyznaczenia osób lub osoby prowadzącej sprawę
5.9
posiadającej pełne uprawnienia do prowadzonej sprawy. Musi istnieć również
możliwość zdefiniowania referenta sprawy.
15
Lp.
Opis wymagania
5.10 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.
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.
5.11 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.
5.12 SEOD musi posiadać funkcję określenia cykliczności przypomnień dla realizowanych
spraw.
5.13 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.
5.14 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.
5.15 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.
5.16 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.
5.17 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.
5.18 System musi umożliwiać ponowne wykorzystanie usuniętego znaku sprawy.
5.19 SEOD musi posiadać możliwość blokowania powtórnego wykorzystania tego samego
symbolu sprawy w przypadku jego usunięcia lub zmiany.
5.20 SEOD musi posiadać funkcję umożliwiającą prowadzenie korespondencji seryjnej z
16
Lp.
Opis wymagania
poziomu sprawy. Korespondencja powinna być prowadzona względem podmiotów
połączonych ze sprawą.
5.21 SEOD musi informować o sprawach z przekroczonym terminem poprzez
wyskakujące okno zawierające spis wszystkich tych spraw zgodnie z widokiem
użytkownika.
5.22 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).
5.23 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ę.
6
Notatki
6.1
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.
6.2
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
6.3
7
7.1
7.2
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
17
Lp.
Opis wymagania
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
7.3
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
7.4
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ż
7.5
jednego użytkownika systemu poprzez nadanie mu odpowiednich uprawnień.
SEOD musi umożliwiać dodawanie użytkownika do struktury organizacyjnej z
7.6
poziomu formatki ustawień konta użytkownika.
SEOD musi umożliwiać przeglądanie danych dotyczących logowania użytkowników
7.7
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
7.8
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ę
7.9
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.
7.10 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.
8
Struktura organizacyjna
8.1
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
18
Lp.
Opis wymagania
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.
8.2
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.
9
Ustawienia
SEOD powinien, dla ułatwienia użytkownikom pracy z systemem, posiadać miejsce
9.1
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
9.2
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.
9.3
SEOD musi umożliwiać włączanie i wyłączanie powiadamiania o aktualizacjach w
sprawach i dokumentach, dla każdego użytkownika indywidualnie.
9.4
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.
9.5
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.
10
Pomoc
10.1 Pomoc musi zapewniać możliwość wyświetlenia okna kontekstowego powiązanego z
aktualnie wybraną funkcją SEOD.
11
Reguły
11.1 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:
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
19
Lp.
Opis wymagania
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,
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.
12
Baza adresowa
12.1 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.
12.2 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.
12.3 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.
12.4 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.
12.5 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.
20
Lp.
Opis wymagania
13
Skanowanie
13.1 Moduł ten musi umożliwiać współpracę ze skanerami dokumentowymi zgodnymi ze
sterownikiem TWAIN.
13.2 Moduł musi pozwolić na odwzorowanie cyfrowe (zeskanowanie) dokumentu z
wybranymi parametrami, następnie wprowadzenie go do SEOD.
13.3 Moduł skanowania powinien być dostępny zarówno w wersji aplikacji desktopowej
jak i w wersji webowej.
13.4 Moduł skanowania w wersji desktopowej powinien posiadać instalator w formacie
.MSI
13.5 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.
13.6 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
• Możliwość zamiany kolejności stron
• Możliwość usuwania stron
13.7 Moduł skanowania musi umożliwiać wysyłanie skanów dokumentów co najmniej
przez otoczenie sieciowe i przez FTP.
13.8 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)
13.9 Moduł skanowania musi umożliwiać definiowanie profili skanowania (zapisanych
parametrów skanowania).
14
Formularze dla dokumentów
14.1 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.
14.2 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.
21
Lp.
Opis wymagania
15
Rezerwacje
15.1 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.
15.2 SEOD musi umożliwiać dodawanie, modyfikacje, usuwanie zasobów przeznaczonych
do rezerwacji.
15.3 SEOD musi umożliwiać grupowanie zasobów przeznaczonych do rezerwacji (np.:
grupa samochody czy sale konferencyjne, w której dostępne są konkretne
przedmioty).
15.4 SEOD musi umożliwiać nadawanie uprawnień do pojedynczych zasobów (np.:
wybranego samochodu) w zakresie:
o możliwości rezerwacji zasobu,
o wglądu w rezerwacje,
o możliwości usuwania rezerwacji zasobu,
o możliwośći rezerwacji zasobu oraz przeglądania rezerwacji z użyciem
kalendarza,
o widoku kalendarza rezerwacji z podziałem co najmniej na: dzień, tydzień,
miesiąc,
o oznaczania różnym kolorem rezerwacji wykonanych przez różnych
użytkowników,
o możliwości dokonania rezerwacji z dokładnością do 15 minut.
15.5 W SEOD musi istnieć możliwość wykonania rezerwacji w imieniu innej osoby wraz z
odnotowaniem faktu kto i dla kogo dokonał rezerwacji.
15.6 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.
16
Rejestry
16.1 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.
16.2 SEOD musi pozwalać na nadanie nazwy oraz symbolu rejestrowi.
16.3 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.
17
Terminarze
17.1 SEOD musi umożliwiać zarządzanie terminarzami z poziomu panelu
administracyjnego. Administrator powinien posiadać możliwość utworzenia
22
Lp.
Opis wymagania
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.
17.2 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).
17.3 Użytkownik musi posiadać możliwość udostępnienia całego swojego terminarza, z
uprawnieniami tylko do wglądu lub do zapisu, innemu użytkownikowi.
17.4 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.
17.11 SEOD musi posiadać funkcję umożliwiającą synchronizację wbudowanego
terminarza z komercyjnym oprogramowaniem Microsoft Outlook (w wersji 2000,
2003, 2007 i nowszej).
18
JRWAUG
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.
23
Lp.
Opis wymagania
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.
19.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.
20
Drag & Drop
20.1 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.
20.2 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”.
20.3 W przypadku próby przeniesienia obiektu do niewłaściwego folderu SEOD musi
poinformować użytkownika o próbie wykonania niedozwolonej operacji.
21
Formularze dla spraw
21.1 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.
21.2 SEOD musi pozwalać na wyszukiwanie spraw wg. atrybutów wchodzących w skład
formularzy dynamicznych opisujących sprawy.
22
Zastępstwa
22.1 Mechanizm zastępstw nie może wymuszać przekazywania haseł pomiędzy
24
Lp.
Opis wymagania
użytkownikami na czas nieobecności.
22.2 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.
22.3 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.
22.4 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.
22.5 Wszystkie operacje realizowane przez zastępcę muszą zostać zapisane w historii
zdarzeń i umożliwiać identyfikację osoby, która je wykonała.
22.6 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.
23
Szablony dokumentów
23.1 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.
24
Podpis elektroniczny
24.1 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.
24.2 Funkcja podpisu elektronicznego musi umożliwiać poprawne wykorzystanie
certyfikatów kwalifikowanych pochodzących od wszystkich certyfikowanych
wystawców.
24.3 SEOD musi umożliwiać złożenie podpisu na dokumencie lub pliku załączonym do
sprawy dowolnej liczbie osób.
24.4 SEOD musi umożliwiać zweryfikowanie poprawności złożonego podpisu przez
25
Lp.
Opis wymagania
każdego z użytkowników, którzy podpisali dokument.
25
Foldery publiczne
25.1 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.
25.2 Administrator SEOD może w każdej chwili nadać lub odebrać uprawnienia do folderu
kolejnym użytkownikom.
26
Active Directory
26.1 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.
26.2 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.
26.3 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).
26.4 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.
26.5 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.
26.6 SEOD musi umożliwiać kopiowanie kont użytkowników poprzez LDAP.
26.7 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
26
Lp.
Opis wymagania
jest SEOD i skierowany na przypisane do niego konto.
27
Delegacje
27.1 SEOD musi posiadać moduł delegacji umożliwiający rozliczenie delegacji
pracownikom posiadającym konto w SEOD.
27.2 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.
27.3 Moduł delegacji musi umożliwiać wprowadzenie delegacji oraz – po zakończeniu
delegacji, na jej rozliczenie.
27.4 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
27.5 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
• 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
27.6 SEOD musi automatycznie definiować zastępstwo w przypadku gdy użytkownik
wypełniając formularz delegacji zdefiniuje zastępcę.
27.7 SEOD musi pozwalać wybranym użytkownikom na rozliczanie i zatwierdzanie
delegacji.
27.8 SEOD na liście delegacji musi prezentować i odpowiednio zmieniać automatycznie
status delegacji:
• Niezatwierdzona
• Zatwierdzona
• W toku
• Rozliczona
27.9 SEOD musi umożliwiać definiowanie ustawień ewidencji przebiegu pojazdu oraz na
drukowanie karty ewidencji przebiegu pojazdu.
27
Lp.
Opis wymagania
28
Urlopy
28.1 Moduł urlopy musi umożliwiać uprawnionemu użytkownikowi wprowadzenie
informacji niezbędnych do poprawnego wyliczania ilości dostępnego urlopu.
28.2 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.
28.3 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
28.4 W przypadku zmiany uprawnień do modułu urlopów SEOD musi zapisywać w
historii listę tych zmian.
28.5 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
28.6 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.
28.7 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.
28.8 SEOD w mechanizmie urlopów powinien w folderze Wnioski (wnioski urlopowe)
dzielić wnioski na następujące foldery:
• Nowe
• Zweryfikowane
• Zaakceptowane
• Anulowane
28.9
• SEOD podczas wprowadzania nowego urlopu musi umożliwiać
wprowadzenie w formularzu elektronicznym następujących informacji:
• Rok
• Data od
28
Lp.
Opis wymagania
• Data do
• Długość urlopu w dniach i godzinach z przeliczeniem na godziny
• Rodzaj urlopu
• Zastępca (z listą aktywnych pracowników SEOD)
• Uwagi
29
Komunikator
29.1 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.
29.2 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.
29.3 Komunikator musi umożliwiać dwukierunkowe rozmowy tekstowe pomiędzy
użytkownikami systemu.
29.4 Komunikator musi umożliwiać przechowywanie listy użytkowników na serwerze.
29.5 Komunikator musi informować o zmianach statusów użytkowników przy użyciu ikon
oraz okien z aktualnym statusem użytkownika.
29.6 Komunikacja pomiędzy użytkownikami powinna być poprzedzona autoryzacją przez
użytkownika, do którego kierowana jest rozmowa.
29.7 Komunikator powinien umożliwiać konstruowanie wizytówki w oparciu o dane
zawarte w systemie oraz pola uzupełniane przez użytkownika.
29.8 Komunikator powinien umożliwiać przeglądanie wizytówek przez każdego
użytkownika systemu.
29.9 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.
29.10 Komunikator powinien umożliwiać współdzielenie plików pomiędzy użytkownikami.
29.11 Komunikator powinien umożliwiać zabezpieczanie utworzonej wielopoziomowej
struktury katalogów hasłem.
29.12 Komunikator powinien umożliwiać informowanie użytkownika animowaną ikoną o
nowej wiadomości.
29.13 Komunikator powinien umożliwiać ustawienie formatowania tekstu (rodzaju
czcionki, typu czcionki, rozmiaru oraz stylu) dla wiadomości przychodzących oraz
wychodzących.
29.14 Komunikator powinien umożliwiać włączenie i wyłączenie funkcji wyświetlania ikon
odzwierciedlających emocje (tzw. emotikony) dla wiadomości tekstowych.
29.15 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.)
29.16 Komunikator powinien umożliwiać podłączenie kompozycji graficznych
zmieniających interfejs aplikacji w zakresie tła, koloru okien, ikon.
29.17 Komunikator powinien umożliwiać włączenie i wyłączenie skrótów klawiaturowych
umożliwiających szybką zmianę statusu.
29.18 Komunikator musi umożliwiać skonfigurowanie możliwości uruchamiania po
zalogowaniu się użytkownika do systemu operacyjnego.
29.19 Komunikator musi umożliwiać skonfigurowanie wyświetlania informacji
dotyczących dostępności użytkowników.
29
Lp.
Opis wymagania
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.
30.6 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.
31.2 SEOD musi pozwolić aby każdy z użytkowników mógł wybrać jeden z dwóch
języków niezależnie.
32
Poczta
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
30
Lp.
Opis wymagania
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.
32.5 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
SEOD
musi
umożliwiać wysyłanie i odbieranie poczty elektronicznej wraz z
32.10
załącznikami poprzez zdefiniowane konta pocztowe.
32.11 SEOD musi umożliwiać wysyłanie poczty elektronicznej w formacie HTML. SEOD
31
Lp.
Opis wymagania
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.
33.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.
33.6 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.
33.7 Mechanizm pozwalający na graficzne modelowanie ścieżek przepływu dokumentów
musi być niezależny od platformy systemowej.
33.8 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.
34
Moduł Workflow
34.1 Oferowany z SEOD moduł Workflow musi być w pełni zgodny ze specyfikacją
XPDL opracowaną przez Workflow Management Coalition (WfMC).
34.2 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.
34.3 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.
34.4 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.
34.5 Workflow musi być wyposażony w graficzne narzędzie umożliwiające definiowanie
ścieżki dostępne z poziomu przeglądarki internetowej.
Narzędzie
musi umożliwiać rozmieszczanie elementów ścieżki (punktów ścieżki)
34.6
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
32
Lp.
Opis wymagania
(myszki komputerowej).
34.7 Narzędzie do graficznego modelowania ścieżek workflow musi umożliwiać tworzenie
graficznego schematu procesu w dwuwymiarowej grafice wektorowej.
34.8 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
34.9 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.
34.10 Narzędzie do graficznego modelowania ścieżek Workflow musi być niezależne od
platformy systemowej.
34.11 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
34.12 Workflow musi umożliwiać definicję punktów (kroków) w ścieżce oraz połączeń
pomiędzy tymi punktami.
34.13 Workflow musi umożliwiać opisanie czynności, które muszą zostać wykonane w
wybranym punkcie ścieżki.
34.14 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.
34.15 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.
34.16 Workflow musi umożliwiać wykorzystanie wyrażeń arbitralnych XOR, AND w
zakresie realizacji warunków określonych w poszczególnych punktach ścieżki.
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
33
Lp.
Opis wymagania
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
35.1 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.
35.2 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.
36
Integracja SEOD z MS Outlook
36.1 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.
36.2 Instalator pluginu pocztowego musi być dostępny w formacie .MSI
37
Integracja SEOD z Elektroniczną Skrzynką Podawczą
37.1 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.
38
Moduł Skanowania WEB
38.1 SEOD musi 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.
39
Archiwum spraw
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.
34
Lp.
Opis wymagania
SEOD musi posiadać możliwość generowania paczki archiwalnej zgodnie z
obowiązującymi przepisami.
39.2 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 zdawczoodbiorczego, 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.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 zdawczo-odbiorczych i innych
35
Lp.
Opis wymagania
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.
40.3 Aplikacja OCR musi poprawnie rozpoznawać dokumenty w języku polskim, a także
językach wszystkich krajów Europy oraz dodatkowo w rosyjskim.
40.4 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.
36
Lp.
Opis wymagania
41
Integracja SEOD z ePUAP
41.1 Mechanizm integracji z ePUAP musi zapewniać możliwość definiowania/dodawania
nowych skrzynek z poziomu panelu administratora SEOD
41.2 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).
41.3 Mechanizm integracji z ePUAP musi zapewniać możliwość zdefiniowania dowolnej
ilości skrzynek z poziomu panelu administratora SEOD.
41.4 Mechanizm integracji z ePUAP musi zapewniać możliwość przyporządkowania
poszczególnych skrzynek do odpowiednich jednostek organizacyjnych
Zamawiającego.
41.5 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.
41.6 Dokumenty pobierane z platformy ePUAP powinny trafiać na listę dokumentów
oczekujących na rejestrację w SEOD
41.7 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.
41.8 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
37
Lp.
Opis wymagania
ePUAP.
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,
• 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ć
38
Lp.
Opis wymagania
parametrów raportu a jedynie zmieniać np. zakres dat.
42.2 SEOD musi umożliwiać podgląd raportów w formie graficznej widocznej na ekranie
oraz ich eksport co najmniej do formatów xls, pdf.
42.3 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.
42.4 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.
42.5 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.
42.6 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.
42.7 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.
42.8 SEOD musi umożliwić wybór kolumn, które mają być wyeksportowane do pliku
arkusza kalkulacyjnego .xls.
43
Gwarancja i serwis SEOD
43.1 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.
III. System Elektronicznego Obiegu Dokumentów (SEOD) – Konfiguracja i Wymagania
sprzętowe:
39
44.
44.1
45
45.1
45.2
45.3
45.4
45.5
45.6
45.7
45.8
45.9
45.10
Sprzęt komputerowy –
Konfiguracja rozwiązania oraz specyfikacja parametrów minimalnych:
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,
możliwość rozbudowy do 192 GB
HDD:
6 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:
40
45.11
45.12
45.13
45.14
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
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.
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
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.
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’’
41
47.2
47.3
47.4
47.5
47.6
47.7
47.8
47.9
47.10
47.11
48
48.1
48.2
48.3
48.4
49
49.1
49.2
49.3
49.4
49.5
49.6
49.7
49.8
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
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
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.
Skanery dokumentowe - 2 sztuki
Współpracujące z systemem SEOD, o parametrach nie gorszych niż:
Moduł skanowania dwustronnego w standardzie
Obciążenie miesięczne min: 1000 stron
Podajniki na dokumenty min: 100 stron
Certyfikat EnergyStar – wymagany wpis w bazie na stronach http://www.euenergystar.org , lub oświadczenie producenta.
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
Ścianka tylna – zdejmowalna, zamykana na zamek, stalowa, z perforacją o
zwiększonej przewiewności
Ścianki boczne – pełne, stalowe, demontowane, zamykane na zamek
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
42
51.7
51.8
51.9
51.10
51.11
51.12
51.13
52
52.1
52.2
Mirroring portów
ARP-spoofing
Agregacja łączy 802.3ad
ACL, oparte o MAC/IP
Uwierzytelnianie 802.1X RADIUS
Przystosowany do montażu w standardowej szafie 19’’
Wyłączanie nieaktywnych portów w celu zmniejszenia zużycia energii tzw. zielone
urządzenie („green line”/”green IT”).
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.
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.
Wykonawca jest zobowiązany do zapewnienia 36 miesięcznego okresu
gwarancyjnego i serwisowego dla wszystkich dostarczonych komponentów sprzętu
komputerowego
IV. Wdrożenie i Szkolenia
Wdrożenie przebiegać będzie w dwóch etapach:
43
Etap I - realizacja do końca 2011 roku:
a)
b)
c)
d)
Analiza przedwdrożeniowa
Dostawa i montaż sprzętu w siedzibie Wyższego Urzędu Górniczego.
Uruchomienie i konfiguracja wszystkich komponentów sprzętowych i oprogramowania.
Wdrożenie podstawowej funkcjonalności SEOD (rejestracja pism) w pierwszej jednostce
organizacyjnej Zamawiającego – w Wyższym Urzędzie Górniczym
e) Szkolenie pierwszej grupy użytkowników kluczowych.
Etap II – do 01 października 2012 roku:
a) Wdrożenie pozostałych funkcjonalności SEOD w WUG
b) wdrożenie SEOD dla pozostałych jednostek organizacyjnych Zamawiającego wg. zał nr 8
„Lokalizacje”.
c) Przeprowadzenie szkoleń użytkowników wg. założonego planu.
Prace wdrożeniowe będą obejmować:
1) Analizę przedwdrożeniową obejmującą:
a) ustalenie ścieżek obiegu prowadzonej dokumentacji w poszczególnych urzędach
górniczych (12 głównych jednostek organizacyjnych Zamawiającego), min. 3 ścieżki
obiegu w każdej jednostce organizacyjnej.
b) ustalenie odpowiedzialności za dokumenty
c) identyfikację prowadzonych dzienników i rejestrów, wymagających zdefiniowania
d) identyfikację zgodności instrukcji kancelaryjnej Zamawiającego oraz Jednostkowego
Rzeczowego Wykazu Akt Urzędów Górniczych z oferowanym SEOD i identyfikacja
obszarów zmian konfiguracji oferowanego SEOD.
Analiza przedwdrożeniowa powinna się zakończyć Koncepcją Wdrożenia Systemu ukazującą
wykaz niezbędnych czynności do wykonania podczas wdrożenia oraz określeniem
szczegółowego Harmonogramu Realizacji Wdrożenia.
2) Montaż całej infrastruktury sprzętowej (szafa, UPS, serwery, przełączniki, macierze)
w pomieszczeniach Zamawiającego.
3) Uruchomienie oprogramowania na dostarczonym przez Wykonawcę sprzęcie
komputerowym wraz z jego pełną konfiguracją oraz konfigurację elementów sieci
(przy wsparciu Zamawiającego), tak aby uzyskać założoną funkcjonalność
i dostępność oprogramowania, zgodnie z założeniami projektu.
4) Wdrożenie i konfiguracje SEOD dla poszczególnych urzędów górniczych (jednostek
organizacyjnych), wykonaną na podstawie analizy przedwdrożeniowej.
5) Szkolenie użytkowników które obejmie grupę administratorów, grupę użytkowników
kluczowych, osoby kierownictwa Urzędów Górniczych oraz grupę użytkowników
końcowych. Szkolenia odbędą się wg. ustalonego podczas analizy przed wdrożeniowej
schematu szkoleń wraz z harmonogramem, skorelowanym z wdrożeniami SEOD w
poszczególnych jednostkach organizacyjnych.
44
6) Szkolenie administratorów, maksymalnie 5 osób, odbędzie się w siedzibie Wyższego
Urzędu Górniczego w Katowicach, potrwa makymalnie 8 godzin i będzie obejmować
wszystkie aspekty zarządzania SEOD oraz tworzenia formularzy, szablonów, ścieżek
Workflow itp. Szkolenie zostanie zakończone uzyskaniem certyfikatów potwierdzających
nabyte umiejętności. Podczas całego wdrożenia, na bieżąco, będzie następował transfer
wiedzy do administratorów uczestniczących w projekcie, obejmujący zagadnienia
konfiguracji technicznej SEOD.
7) Szkolenie grupy użytkowników kluczowych, maksymalnie 100 osób, odbędzie się w
siedzibie Wyższego Urzędu Górniczego, w grupach o uzgodnionej z Wykonawcą
liczebności i będzie obejmować wszystkie aspekty używania SEOD z pominięciem
procedur administracyjnych. Użytkownicy kluczowi powinni nabyć umiejętności radzenia
sobie z konfiguracją SEOD na poziomie użytkownika zaawansowanego, tak aby móc
pełnić rolę lokalnego Help-Desku dla użytkowników końcowych i osób kierownictwa,
oraz konfigurować środowisko pracy i rozwiązywać problemy użytkowników na
poziomie głównych jednostek organizacyjnych Zamawiającego. Szkolenie zostanie
zakończone uzyskaniem certyfikatów potwierdzających nabyte umiejętności.
8) Szkolenia osób kierownictwa Urzędów Górniczych, maksymalnie 60 osób, będą
przeprowadzone w uzgodnionych wcześniej terminach, w siedzibie Wyższego Urzędu
Górniczego. Szkolenia będą obejmować aspekty codziennego używania SEOD ze
szczególnym uwzględnieniem narzędzi monitoringu podległych pracowników oraz
terminowości spraw i będą polegały na prezentacji systemu SEOD, trwającej nie dłużej
jak 4 godziny dla grupy.
9) Szkolenia użytkowników końcowych, pozostałe osoby, będą przeprowadzane
sukcesywnie w ramach wdrożenia w uzgodnionych terminach, w siedzibach Urzędów
Górniczych, w salach udostępnionych przez te urzędy. Szkolenia te będą obejmować
prezentację podstawowych aspektów używania SEOD z pominięciem procedur
administracyjnych, monitorowania pracy podległych pracowników oraz funkcji
zaawansowanych oraz ewentualną asystę wdrożeniową pracowników realizowaną przez
przedstawicieli Wykonawcy przy pomocy wcześniej przeszkolonych użytkowników
kluczowych. Terminy zostaną uzgodnione każdorazowo po wdrożeniu części SEOD
obejmującej dany urząd.
10) Prezentacje oraz asysta wdrożeniowa obejmie pracowników w następujących
lokalizacjach: WUG, OUG Katowice, OUG Rybnik, OUG Gliwice oraz pracowników
UGBKUE. W pozostałych lokalizacjach Zamawiającego system będą obsługiwać,
wcześniej przeszkoleni użytkownicy kluczowi.
11) Szkolenia użytkowników kluczowych i osób kierownictwa zostaną przeprowadzone w
grupach o ustalonej z Wykonawcą liczebności, uzależnionej od możliwości Wykonawcy
w zapewnieniu sprzętu komputerowego (notebooki, switche, okablowanie) do
przeprowadzenia efektywnego szkolenia. Zamawiający przewiduje wstępnie grupy 15
osobowe. Grupy te mogą ulec zwiększeniu do maksymalnie 20 osób, pod warunkiem
zapewnienia narzędzi informatycznych przez Wykonawcę. Cykl szkoleń będzie trwał
przez cały okres wdrożenia systemu.
45
12) Oryginały list obecności na poszczególnych szkoleniach, po potwierdzeniu przez
Kierownika Projektu Zamawiającego oraz Kierownika Projektu Wykonawcy, zostaną
włączone do dokumentacji Projektu, pozostającej u Zamawiającego.
V.
LOKALIZACJE
Prace projektowe będą prowadzone w siedzibie Wyższego Urzędu Górniczego:
Wyższy Urząd Górniczy
ul. Poniatowskiego 31,
40-055 Katowice.
W tej lokalizacji wymagane jest prowadzenie wszelkich prac projektowych (organizacja
spotkań, realizacja większości wsparcia instruktażowego, instalacja i uruchomienie sprzętu).
Wyższy Urząd Górniczy koordynuje współpracę z pozostałymi jednostkami zaangażowanymi
w projekt:
1. Okręgowy Urząd Górniczy w Gliwicach
ul. Jasna 31b, 44-122 Gliwice
2. Okręgowy Urząd Górniczy w Katowicach
ul. Obroki 87, 40-929 Katowice
3. Okręgowy Urząd Górniczy w Kielcach
Al. IX Wieków Kielc 3, 25-516 Kielce
4. Okręgowy Urząd Górniczy w Krakowie
ul. Lubicz 25, 31-503 Kraków
5. Okręgowy Urząd Górniczy w Krośnie
ul. Armii Krajowej 3, 38-402 Krosno
6. Okręgowy Urząd Górniczy w Lublinie
ul. Magnoliowa 2, 20-143 Lublin
7. Okręgowy Urząd Górniczy w Poznaniu
ul. Gdyńska 45, 61-016 Poznań
8. Okręgowy Urząd Górniczy w Rybniku
ul. Bolesława Chrobrego 8, 44-200 Rybnik
9. Okręgowy Urząd Górniczy w Warszawie
ul. Wilcza 46, 00-679 Warszawa
10. Okręgowy Urząd Górniczy we Wrocławiu, lokalizacje:
- ul. Kotlarska 41, Wrocław
- ul. Lotników 1, Wałbrzych
- Lubin, ul. M. Skłodowskiej – Curie 183
46
11. Urząd Górniczy do Badań Kontrolnych Urządzeń Energomechanicznych
ul. Obroki 87, 40-929 Katowice.
47

szczegółowy opis przedmiotu zamówienia

Transkrypt

Podobne dokumenty

Załącznik nr 1 do SIWZ – Szczegółowa specyfikacja techniczno

Załącznik nr 1 do SIWZ - Szczegółowy opis przedmioyu zamówienia

Załącznik do OPZ nr 9 - Centrum Onkologii

Załącznik nr 2 do SIWZ

ZAPYTANIE O CENĘ

załącznik nr 1 - założenia funkcjonalne systemu

pobierz - ministerstwo rozwoju

Specyfikacja strony internetowej