SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt

1 Załącznik nr 1 do SIWZ SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA I. Cel realizacji Projektu Projekt Lubuski e-urząd umożliwi realizację podstawowych usług Systemów informatycznych administracji publicznej w województwie, powiatach i gminach w oparciu o założenia idei społeczeństwa informacyjnego i realizacji szeroko pojętych usług dla obywateli i przedsiębiorstw. Wdrożenie Systemu ma zapewnić obywatelom jasny, efektywny i zunifikowany sposób kontaktu z Urzędem na poziomie Gminy, Powiatu i Urzędu Marszałkowskiego. Jednocześnie Projekt ma umożliwić wykorzystanie wspólnej funkcjonalności Systemu przez urzędy powiatowe i gminne, gdzie zwykle nie jest opłacalna budowa i utrzymanie odpowiedniej infrastruktury niezbędnej dla realizacji usług dla obywateli i przedsiębiorstw. Projekt obejmuje swoim zasięgiem województwo lubuskie. Projekt Lubuski e-urząd jest realizowany przy udziale środków Europejskiego Regionalnego Programu Operacyjnego w ramach Lubuskiego Regionalnego Programu Operacyjnego na lata II. Ogólny Opis Przedmiotu Zamówienia Realizacja zadania polega na pełnieniu roli wykonawcy prac związanych z inwestycją pn: Lubuski e- Urząd. Zakres prac wykonawcy obejmuje dostawę sprzętu komputerowego (urządzeń teleinformatycznych), systemu elektronicznego obiegu dokumentów, prace wdrożeniowe oraz szkolenia związane z realizacją Projektu. Celem realizacji zadania jest zwiększenie dostępności oraz jakości usług świadczonych drogą elektroniczną (e-administracja) przez Jednostki Samorządu Terytorialnego województwa lubuskiego poprzez rozbudowę lokalnej infrastruktury społeczeństwa informacyjnego oraz połączenie z produktami wdrożonymi przez Generalnego Wykonawcę w ramach Projektu Lubuski e-urząd. Przedmiot Zamówienia obejmuje: Dostawę, montaż wraz z uruchomieniem, konfigurację oraz świadczenie usług serwisu gwarancyjnego sprzętu komputerowego (urządzeń teleinformatycznych) wyspecyfikowanego w Zadaniach nr 2, 3, 4, 5, 6, 7 oraz 8 na warunkach określonych w treści poszczególnych Zadań oraz Specyfikacji Istotnych Warunków Zamówienia. Wdrożenie Systemu Elektronicznego Obiegu Dokumentów (SEOD) w zakresie: 1) wdrożenie Systemu Elektronicznego Obiegu Dokumentów, S t r o n a 1

2 2) integracja Systemu Elektronicznego Obiegu Dokumentów z Regionalną Platformą Komunikacji Elektronicznej (Cyfrowy Urząd), 3) wykonanie i zamieszczenie formularzy elektronicznych procedur obsługi Interesanta na Regionalnej Platformie Komunikacji Elektronicznej (Cyfrowy Urząd), 4) przeszkolenie użytkowników oraz administratorów, na warunkach określonych w treści poszczególnych Zadań oraz Specyfikacji Istotnych Warunków Zamówienia. Przedmiot Zamówienia podzielono na 8 Zadań: Tabela 1 Wykaz zadań Zadanie nr Produkt projektu Ilość 1. Wdrożenie Systemu Elektronicznego Systemu Obiegu Dokumentów 18 Partnerów Projektu/ 645 użytkowników 2. Serwer 3 sztuki 3. Macierz dyskowa 1 sztuka 4. Pamięć RAM do serwerów blade 36 sztuk 5. Firewall 2 sztuki 6. Biblioteka taśmowa LTO 5 1 sztuka + 25 szt. taśm 7. PDU 1 sztuka 8. Microsoft Windows Server 2008R2 User Call 3300 sztuk III. Miejsce realizacji dostaw i usług Dostawy i usługi realizowane będą w siedzibie Zamawiającego oraz siedzibach następujących Jednostek Samorządu Terytorialnego (Partnerów) oraz ich podległych jednostek organizacyjnych, jeżeli wynika to ze specyfiki danego Zadania i zostało określone w jego treści: 1) Gmina Babimost 2) Gmina Bledzew 3) Gmina Bobrowice 4) Gmina Bogdaniec 5) Gmina Bojadła 6) Gmina Brody 7) Gmina Brzeźnica 8) Gmina Bytnica 9) Gmina Bytom Odrzański 10) Gmina Cybinka 11) Gmina Czerwieńsk 12) Gmina Dąbie 13) Gmina Deszczno S t r o n a 2

3 14) Gmina Dobiegniew 15) Gmina Drezdenko 16) Gmina Gozdnica 17) Gmina Górzyca 18) Gmina Iłowa 19) Gmina Jasień 20) Gmina Kargowa 21) Gmina Kłodawa 22) Gmina Kolsko 23) Gmina Kostrzyn nad Odrą 24) Gmina Kożuchów 25) Gmina Krosno Odrzańskie 26) Gmina Krzeszyce 27) Gmina Lipinki Łużyckie 28) Gmina Lubiszyn 29) Gmina Lubniewice 30) Gmina Lubrza 31) Gmina Lubsko 32) Gmina Łagów 33) Gmina Łęknica 34) Gmina Małomice 35) Gmina Maszewo 36) Gmina Międzyrzecz 37) Gmina Niegosławice 38) Gmina Nowe Miasteczko 39) Gmina Nowogród Bobrzański 40) Gmina Ośno Lubuskie 41) Gmina Otyń 42) Gmina Przewóz 43) Gmina Przytoczna 44) Gmina Pszczew 45) Gmina Rzepin 46) Gmina Santok 47) Gmina Siedlisko 48) Gmina Skąpe 49) Gmina Skwierzyna 50) Gmina Sława 51) Gmina Słońsk 52) Gmina Słubice 53) Gmina Stare Kurowo 54) Gmina Strzelce Krajeńskie 55) Gmina Sulechów S t r o n a 3

4 56) Gmina Sulęcin 57) Gmina Szczaniec 58) Gmina Szlichtyngowa 59) Gmina Szprotawa 60) Gmina Świdnica 61) Gmina Świebodzin 62) Gmina Torzym 63) Gmina Trzciel 64) Gmina Trzebiechów 65) Gmina Trzebiel 66) Gmina Tuplice 67) Gmina wiejska Gubin 68) Gmina wiejska Nowa Sól 69) Gmina wiejska Żagań 70) Gmina wiejska Żary 71) Gmina Witnica 72) Gmina Wschowa 73) Gmina Wymiarki 74) Gmina Zabór 75) Gmina Zbąszynek 76) Gmina Zielona Góra 77) Gmina Zwierzyn 78) Miasto Gorzów Wlkp. 79) Miasto Gubin 80) Miasto Nowa Sól 81) Miasto Zielona Góra 82) Miasto Żagań 83) Miasto Żary 84) Powiat Gorzowski 85) Powiat Krośnieński 86) Powiat Międzyrzecki 87) Powiat Nowosolski 88) Powiat Słubicki 89) Powiat Strzelecko-drezdenecki 90) Powiat Sulęciński 91) Powiat Świebodziński 92) Powiat Wschowski 93) Powiat Zielonogórski 94) Powiat Żagański 95) Powiat Żarski S t r o n a 4

5 Dane teleadresowe Partnerów Projektu uczestniczących w realizacji Projektu Lubuski e-urząd zawiera Załącznik nr 5 do SIWZ. Szczegółowy zakres dostaw oraz usług dla poszczególnych Partnerów Projektu przedstawiony został w poszczególnych kartach produktów Projektu (Zadaniach). IV. Termin wykonania zamówienia i harmonogram Przedmiot Umowy musi być zrealizowany w okresie 4 miesięcy od daty podpisania Umowy. Przedmiot Umowy będzie realizowany zgodnie z zatwierdzonym przez Zamawiającego harmonogramem rzeczowo-finansowym. Wykonawca zobowiązany jest przedłożyć Zamawiającemu do zatwierdzenia harmonogram rzeczowo-finansowy w terminie 5 dni roboczych od dnia podpisania Umowy. Zamawiający zatwierdzi harmonogram rzeczowo-finansowy w ciągu 3 dni roboczych od daty jego przedłożenia do zatwierdzenia. Na wniosek każdej ze Stron po uzyskaniu wzajemnej akceptacji harmonogram rzeczowo-finansowy może ulec zmianie pod warunkiem, że terminy końcowe realizacji poszczególnych Zadań Przedmiotu Zamówienia przedstawione w tabeli nr 2 nie ulegną zmianie. Płatności, które należy uwzględnić w harmonogramie będą realizowane w terminie 30 dni od daty otrzymania prawidłowo wystawionej faktury VAT. Wystawienie faktur następuje po podpisaniu przez Zamawiającego Protokołu Odbioru: za dostarczony Przedmiot Umowy, za wykonane usługi (montaż i uruchomienie, prace wdrożeniowe Systemów informatycznych, itp.), zgodnie z warunkami określonymi w Załączniku nr 1 do SIWZ oraz Załączniku nr 2 do SIWZ. Terminy końcowe realizacji poszczególnych elementów Przedmiotu Zamówienia przedstawia poniższa tabela Tabela 2 Terminy końcowe realizacji elementów Przedmiotu Zamówienia Lp. Produkt projektu Termin 1. Dostawa, montaż i uruchomienie sprzętu teleinformatycznego oraz Oprogramowania Systemowego, Licencji dostępowych 2 miesiące od daty podpisania umowy 2. Wdrożenie Systemu Elektronicznego Obiegu Dokumentów 4 miesiące od daty podpisania umowy V. Wymagania prawne Oferowane przez Wykonawcę rozwiązania muszą być na dzień odbioru zgodne z aktami prawnymi regulującymi pracę urzędów administracji publicznej oraz usług urzędowych realizowanych drogą elektroniczną (e-usług). Oferowane rozwiązania muszą być zgodne w szczególności z następującymi przepisami: 1) Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. z 2005 r. Nr 64, poz. 565 z późn. zm.). S t r o n a 5

6 2) Ustawa z dnia 14 czerwca 1960 Kodeks Postępowania Administracyjnego (Dz.U. z 2000r Nr 98, poz z późn. zm.). 3) Ustawa z dnia 6 września 2001 r. o dostępie do informacji publicznej (Dz.U. z 2001 r. Nr 112, poz.1198 z późn. zm.). 4) Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U. z 2001 r. Nr 130, poz z późn. zm.). 5) Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz.U. z 2002 r. Nr 144, poz z późn. zm.). 6) Ustawa z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U. z 2002 r. Nr 101, poz. 926 z późn. zm.). 7) Ustawa z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz.U. z 2010 r. Nr 182 poz. 1228). 8) Ustawa z dnia 5 lipca 2002 r. o ochronie niektórych usług świadczonych drogą elektroniczną opartych lub polegających na dostępie warunkowym (Dz.U. z 2002 r. Nr 126 poz z późn. zm.). 9) Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz.U. z 2001 r. Nr 128 poz z późn. zm. 10) Ustawa z dnia 29 sierpnia 1997 r. Ordynacja podatkowa (Dz.U z 2005 r. Nr 8, poz. 60 z późn. zm.). 11) Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (Dz.U. z 2011 r. Nr 123 poz. 698). 12) Rozporządzenie Ministra Administracji i Cyfryzacji z dnia 6 marca 2012 r. w sprawie wzoru i sposobu prowadzenia metryki sprawy (Dz.U. z 2012 r. poz. 250). 13) Rozporządzenie Prezesa Rady Ministrów z dnia 18 stycznia 2011 r. w sprawie instrukcji kancelaryjnej, jednolitych rzeczowych wykazów akt oraz instrukcji w sprawie organizacji i zakresu działania archiwów zakładowych (Dz.U. z 2011 r. Nr 14, poz. 67 z późn. zm.). 14) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 21 kwietnia 2011 r. w sprawie szczegółowych warunków organizacyjnych i technicznych, które powinien spełniać system teleinformatyczny służący do identyfikacji użytkowników (Dz.U. z 2011 r. Nr 93, poz. 545). 15) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 27 kwietnia 2011 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej (Dz.U. z 2011 r. Nr 93, poz. 546). 16) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 27 kwietnia 2011 r. w sprawie zasad potwierdzania, przedłużania ważności, wykorzystania i unieważniania profilu zaufanego elektronicznej platformy usług administracji publicznej (Dz.U. z 2011 r. Nr 93, poz. 547). 17) Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r. w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz.U. z 2011 r. Nr 206, poz. 1216). 18) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U. z 2004 r. Nr 100, poz.1024). S t r o n a 6

7 19) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 r. w sprawie wymagań technicznych formatów zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne przekazywane do archiwów państwowych (Dz.U. z 2006 r. Nr 206, poz. 1519). 20) Rozporządzenie Rady Ministrów dnia 8 stycznia 2002 r. w sprawie organizacji przyjmowania i rozpatrywania skarg i wniosków (Dz.U. z 2002 r. Nr 5, poz. 46). 21) Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz.U. z 2005 r. Nr 205 poz. 1692). 22) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz.U. z 2006 r. Nr 206 poz. 1518). 23) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz.U. z 2006 r. Nr 206 poz. 1517). 24) Rozporządzenie Ministra Spraw Wewnętrznych i Administracji z dnia 18 stycznia 2007 r. w sprawie Biuletynu Informacji Publicznej (Dz.U. z 2007 r. Nr 10 poz. 68). 25) Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz.U. z 2005 r. Nr 217 poz. 1836). 26) Rozporządzenie Ministra Kultury z dnia 16 września 2002 r. w sprawie postępowania z dokumentacją, zasad jej klasyfikowania i kwalifikowania oraz zasad i trybu przekazywania materiałów archiwalnych do archiwów państwowych (Dz.U. z 2002 r. Nr 167 poz. 1375). 27) Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z dnia 16 maja 2012 r. poz. 526). VI. Wymagania w zakresie zarządzania, dokumentacji projektu oraz komunikacji 1. Projekt ma być realizowany z wykorzystaniem metodyki zarządzania projektami PRINCE2. PRINCE2 jest strukturalną metodyką efektywnego zarządzania projektami. Zgodnie z metodyką realizacja Przedmiotu Zamówienia jest projektem, którego realizacja ma wytworzyć określone produkty. W związku z tym Wykonawca zobowiązany jest postępować w trakcie realizacji zgodnie z metodyką PRINCE2 lub równoważną oraz przedstawić w terminie 5 dni roboczych po podpisaniu umowy harmonogram projektu zgodny z tą metodyką. 2. Współpraca Zamawiającego z Wykonawcą będzie prowadzona zgodnie ze sporządzonym przez Wykonawcę Planem realizacji projektu w zakresie dotyczącym: a. osób funkcyjnych i ich zakresów odpowiedzialności, b. komunikacji w projekcie pomiędzy Stronami, c. obiegu dokumentów, d. zarządzania zmianami i ryzykiem. S t r o n a 7

8 3. W razie audytu lub kontroli realizacji prac Wykonawca zobowiązany jest do współpracy z Zamawiającym oraz Inżynierem Projektu, a w szczególności w celu przygotowania niezbędnych dokumentów dla instytucji kontrolujących. 4. W celu obniżenia kosztów związanych z komunikacją pomiędzy Wykonawcą a Zamawiającym Wykonawca zobowiązany jest dostarczyć Zamawiającemu na czas realizacji Umowy 2 aparaty telefonii komórkowej GSM. Przekazanie aparatów telefonicznych ma nastąpić w terminie 14 dni od dnia podpisania Umowy. Z przekazanych aparatów telefonicznych będą korzystać wyznaczone przez Zamawiającego osoby odpowiedzialne za nadzorowanie z jego strony realizacji Projektu. Wykonawca zobowiązany jest do pokrywania kosztów opłat abonamentowych związanych z użytkowaniem tych aparatów telefonicznych. Opłacany przez Wykonawcę abonament ma zapewnić bezpłatne połączenia telefoniczne z osobami wyznaczonymi przez niego do realizacji Przedmiotu Umowy. Zamawiający zwróci przekazane aparaty telefoniczne w dniu podpisania Protokołu Odbioru Końcowego Projektu. 5. Wykonawca zobowiązany jest przeprowadzać konsultacje z Zamawiającym w siedzibie Zamawiającego lub wskazanym przez Zamawiającego miejscu w liczbie min. 60 godzin w całym okresie realizacji zamówienia, nie rzadziej niż raz na tydzień. Zamawiający ma prawo w każdym momencie zażądać od Wykonawcy przeprowadzenia konsultacji, podając termin i miejsce nie później niż 3 dni przed planowanymi konsultacjami. Dodatkowo (poza określonym powyżej 60 godzinnym limitem) możliwe jest prowadzenie konsultacji za pośrednictwem poczty, poczty elektronicznej, faksu, telefonu w godzinach pracy Zamawiającego. Ze strony Wykonawcy we wszystkich konsultacjach musi brać udział Kierownik lub z-ca Kierownika Zespołu Wykonawcy, o którym mowa w 3 ust 14 Umowy (stanowiącej załącznik nr 7 do SIWZ). Na prośbę Zamawiającego w wybranych konsultacjach będą brali udział inni eksperci ze strony Wykonawcy. Definicje Dla potrzeb realizacji niniejszego zamówienia ustala się znaczenie następujących pojęć stosowanych w SIWZ: 1 Linia wsparcia - zespół ludzi oraz narzędzia zapewnione przez Wykonawcę dedykowane do kontaktów formalnych z autorami Zgłoszeń oraz zapewnienia poprawnej logistyki realizacji Zgłoszeń. 2 Linia wsparcia - zespół konsultantów realizujących Zgłoszenia, zapewniany przez Autorów Oprogramowania. Administrator - osoba posiadająca uprawnienia do dokonywania modyfikacji w ustawieniach i konfiguracji Systemu. Pod pojęciem mieści się Administrator merytoryczny i Administrator techniczny. Aktualizacja - dostarczenie i instalowanie uaktualnień lub nowych wersji Oprogramowania Aplikacyjnego lub jego poszczególnych modułów. Aktualizacja obejmuje udzielenie lub zapewnienie Zamawiającemu lub Partnerowi Projektu licencji na korzystanie z nowych wersji Oprogramowania w ramach wynagrodzenia objętego Umową. Analiza Przedwdrożeniowa określa między innymi szczegółowo sposób realizacji przez Oprogramowanie wymagań funkcjonalnych określonych w treści Specyfikacji Istotnych Warunków S t r o n a 8

9 Zamówienia. Analiza Przedwdrożeniowa nie obejmuje definiowania procesów biznesowych w Urzędzie. Zamawiający oraz Partnerzy (JST) posiadają już zdefiniowane procesy biznesowe i do obsługi tych procesów muszą być dopasowane funkcjonalności oferowanego produktu. Analiza Przedwdrożeniowa będzie realizowana etapowo. Szczegółowy zakres analizy określony został w karcie zadania. Asysta Techniczna - usługa świadczona przez Wykonawcę, polegająca na bieżącym wsparciu Użytkowników Końcowych, pracowników Zamawiającego lub Partnerów Projektu w zakresie eksploatacji i obsługi Systemu zgodnie z Załącznikiem nr 4 do SIWZ. Asysta Stanowiskowa - Asysta świadczona przez Wykonawcę w siedzibie Zamawiającego lub Partnera Projektu zgodnie z Załącznikiem nr 4 do SIWZ. Autor Oprogramowania - podmiot posiadający autorskie prawa majątkowe i obowiązki wynikające z nadzoru autorskiego oraz gwarancji, w stosunku do Oprogramowania dostarczonego w ramach Projektu. Awaria - stan niesprawności Oprogramowania uniemożliwiający jego funkcjonowanie, powodujący jego unieruchomienie. Baza Produkcyjna baza danych Zamawiającego lub Partnera Projektu bieżąco eksploatowana do celów operacyjnych. Baza Testowa aktualna kopia Bazy Produkcyjnej Zamawiającego lub Partnera Projektu, służąca do przeprowadzania testów akceptacyjnych, weryfikowania problemów i testowania patch-y serwisowych. Baza Szkoleniowa baza Zamawiającego lub Partnera Projektu, służąca do podnoszenia umiejętności użytkowników Oprogramowania Aplikacyjnego. Biblioteka dokumentów - Zbiór dokumentów urzędowych zorganizowanych we wspólnym miejscu w Systemie. Błąd - opis stanu Produktu niezgodny z zapisami SIWZ i Umowy, w szczególności Nienormalne Działanie Systemu, lub niepoprawnie zrealizowany element Dokumentacji. Błąd Oprogramowania nienormalne działanie Systemu / Oprogramowania, tzn. sytuacja, w której zachowanie Systemu / Oprogramowania albo wynik działania jest odmienny od zamierzonego określonego w Dokumentacji Użytkowej Oprogramowania, które nie jest spowodowane niezgodnym z Dokumentacją działaniem Użytkownika Końcowego. W przypadku, gdy powyższa dokumentacja nie opisuje danej sytuacji, Strony przyjmują odwołanie się do wymagań funkcjonalnych określonych w dokumentacji przetargowej. Błąd Krytyczny błąd Oprogramowania, dla którego nie ma alternatywnego sposobu wykonania operacji w Oprogramowaniu (nie istnieje możliwość obejścia). Błąd Poważny - błąd Oprogramowania, dla którego istnieje alternatywny sposób wykonania operacji w Oprogramowaniu (istnieje możliwość obejścia). Błąd Drobny każdy inny błąd niebędący Błędem Poważnym ani Błędem Krytycznym. Centralna Baza Danych (CBD) - repozytorium - element Systemu, w którym gromadzi się, przetwarza, przechowuje Zasoby Informacyjne Systemu. S t r o n a 9

10 Czas Reakcji na Zgłoszenie - czas, jaki jest liczony od momentu zarejestrowania Zgłoszenia w Internetowym Systemie Obsługi Help Desk lub od przekazania Zgłoszenia Wykonawcy do powiadomienia Zgłaszającego o sposobie i terminie realizacji Zgłoszenia. Dokument - urzędowy dokument, zapisany w formacie XML, biorący udział w procesach workflow w Urzędzie. Dzień Roboczy - dzień kalendarzowy od poniedziałku do piątku za wyjątkiem dni ustawowo wolnych. Dzień - dzień kalendarzowy. Dokumentacja - wszelkiego rodzaju dokumenty wytworzone w ramach realizacji Projektu. Pojęcie obejmuje Dokumentację Techniczną, Szkoleniową, Użytkową oraz Wdrożeniową oraz inne dokumenty uzgodnione przez Strony. Dokumentacja Techniczna - zestaw dokumentów dotyczących Systemu, w tym, co najmniej: - opis dostarczanych, implementowanych funkcji będący uszczegółowieniem wymagań (funkcji) wskazanych w opisie Przedmiotu Zamówienia, - reguły integracji danych, - model danych i opis struktur bazy danych oraz opis procedur wbudowanych dla poszczególnych schematów bazy (pełen opis tablic, pól, relacji oraz ról), - opis zabezpieczeń, - ostateczny stan implementacji rozwiązania w zakresie struktury bazy danych w modelu klas UML oraz tabelarycznie z rozwarstwieniem tematycznym dla warstw informacyjnych, - reguły i parametry konfiguracji rozwiązania (parametry systemowe, narzędziowe) w zakresie, który umożliwi Zamawiającemu samodzielne odtworzenie stanu rozwiązania przy wykorzystaniu wyłącznie do tego celu przekazanej przez Wykonawcę dokumentacji. - opis konfiguracji, opis interfejsów, opis czynności administracyjnych, - instrukcje konfiguracji serwera bazy danych Systemu, - procedury archiwizacji bazy danych oraz procedur przywracania konfiguracji, - opis konfiguracji środowiska Systemowego - opis użytych bibliotek (funkcji, parametrów), - opis techniczny rodzajów i zastosowanych protokołów komunikacji, - opis techniczny procedur aktualizacyjnych - przygotowanie (w trakcie wdrożenia modułu EOD) procedury działania na okoliczność wystąpienia awarii systemu. Procedury awaryjne obejmują: Komu zgłosić awarię, Postępowanie w okresie oczekiwania na reakcję serwisu, Osoby kontaktowe, koordynatorów dla danego typu awarii, Ewentualne rekonfiguracje modułu EOD w celu zapewnienia właściwego dalszego działania. oraz inne dokumenty uzgodnione przez Strony. Dokumentacja Szkoleniowa - dokument zawierający zestaw ćwiczeń szkoleniowych. Dokumentacja Użytkowa - dokument napisany w języku zrozumiałym dla przeciętnego docelowego użytkownika, opisujący sposób wykorzystania wszystkich funkcji Oprogramowania S t r o n a 10

11 w trakcie jego eksploatacji, zawierający w szczególności opis poszczególnych funkcji danego Modułu, wskazujący "jak" i "co" zrobić w określonej sytuacji, opisujący komunikaty o błędach oraz sposób wspomagania i tworzenia własnych raportów (dostęp do struktury bazy danych), zawierający szczegółowe zasady instalacji, opisujące krok po kroku cały proces instalacji, konfiguracji, obsługi oraz konserwacji wszystkich składników Systemu, opisujący również procedury naprawcze na wypadek wystąpienia Awarii poszczególnych elementów/modułów, celem przywrócenia stanu normalnej pracy, w tym sposobu przywrócenia kopii awaryjnej, zawierający wszelkie instrukcje dotyczące obsługi Systemu w szczególności Instrukcje Użytkownika i instrukcje Administratora Systemu. Dokumentacja Wdrożeniowa - dokumentacja powstająca w trakcie realizacji Wdrożenia, obejmująca opis procesu dostosowania Oprogramowania do wymagań Zamawiającego (opis konfiguracji i parametryzacji Oprogramowania), opis interfejsów. Dostawa - przemieszczenie Przedmiotu Zamówienia w postaci sprzętu teleinformatycznego oraz licencji i nośników Oprogramowania, Oprogramowania Narzędziowego od Wykonawcy do Zamawiającego obejmujące transport oraz wniesienie do wskazanego przez Zamawiającego pomieszczenia w terminach uzgodnionych pomiędzy Wykonawcą a Zamawiającym. ESOD, EOD patrz SEOD Formularz - schemat, na którego podstawie tworzone są dokumenty urzędowe, pozwala na tworzenie dokumentów XML w oparciu o schematy danych XSD oraz style XSL. Godziny Robocze - godziny zegarowe od 7.00 do w ramach Dnia Roboczego. Gwarancja Jakości - świadczenia realizowane przez Wykonawcę na warunkach opisanych w Załączniku nr 4 do SIWZ. Help Desk - część organizacji Wykonawcy (dział, sekcja, zespół lub wyznaczona grupa osób) odpowiedzialna za przyjmowanie Zgłoszeń od osób uprawnionych do ich dostarczania oraz kontrolę ich rozwiązania. Incydent - każde Zdarzenie występujące po stronie Systemu lub po stronie prawidłowej obsługi i użytkowania Systemu, niebędące częścią normalnego działania Systemu, w szczególności działanie Systemu niezgodne z wymaganiami Zamawiającego określonymi w SIWZ i Dokumentacji. Infrastruktura Sprzętowa - serwery oraz inne urządzenia będące w posiadaniu Zamawiającego lub Partnera Projektu, przeznaczone na potrzeby realizacji Projektu. Internetowy System Obsługi Help Desk - system internetowy prowadzony przez Wykonawcę, stanowiący rejestr Zgłoszeń i podstawowe narzędzie do zarządzania realizacją zgłoszenia. Inżynier Projektu podmiot sprawujący nadzór inwestorski w zakresie technicznym, terminowym, finansowym oraz sprawozdawczym nad Projektem. Istotna Funkcja Oprogramowania - funkcja, której brak uniemożliwia wykorzystanie danego modułu Oprogramowania Aplikacyjnego i uniemożliwia działanie Zamawiającego lub Partnera Projektu w zakresie funkcjonalnym tego modułu Oprogramowania. Kierownik Projektu patrz Kierownik Projektu Zamawiającego. Kierownik Projektu Wykonawcy - osoba z ramienia Wykonawcy uprawomocniona do jego reprezentowania w zakresie realizacji Umowy odpowiedzialna za jej prawidłową realizację. S t r o n a 11

12 Kierownik Projektu Zamawiającego - osoba reprezentująca Zamawiającego w zakresie realizacji Umowy, odpowiedzialna za jej prawidłową realizację. Kod Źródłowy - słowniki, skrypty, definicje, pliki źródłowe bazy danych, jak również biblioteki, algorytmy oraz jakiekolwiek inne symboliczne lub konwencjonalne przedstawienie zapisu informacji, niezbędne do kompilacji, wykonania i utrzymania, funkcjonowania i utrzymania Systemu, z wyłączeniem Oprogramowania Systemowego. Moduł - część Systemu tworząca logiczną całość, dostarczająca zbiór funkcjonalności określony w OPZ. Modyfikacja - każda proponowana zmiana Systemu lub jego funkcjonalności, odbiegająca od stanu i funkcjonalności Systemu opisanego w SIWZ i Dokumentacji, zgłoszona przez Użytkownika Końcowego w formie Zgłoszenia. Modyfikacja kodu źródłowego - każda zmiana kodu źródłowego Standardowego Oprogramowania Aplikacyjnego, dokonana przez Wykonawcę w ramach wykonywania obowiązków wynikających z realizacji zamówienia. Naprawa - dla Incydentu i Problemu: spowodowanie przez Wykonawcę Normalnego Działania Systemu, w tym usunięcie zgłoszonych Błędów, na zasadach określonych w treści Specyfikacji Istotnych Warunków Zamówienia. Nienormalne Działanie Systemu - stan Systemu lub jego działanie w sposób nie zgodny z SIWZ i Dokumentacją. Normalne Działanie Systemu - stan Systemu lub jego działanie w sposób zgodny z SIWZ i Dokumentacją. Okienko serwisowe - czas wyznaczony na zgłaszanie Błędów Oprogramowania oraz Awarii. Okienko serwisowe obowiązuje w godzinach od 7.00 do 16:00 w Dni Robocze. Oprogramowanie - Oprogramowanie Aplikacyjne lub Oprogramowanie Osób Trzecich. Oprogramowanie Aplikacyjne - Standardowe Oprogramowanie Wykonawcy wraz z Modyfikacjami Wykonawcy. Oprogramowanie Osób Trzecich - Oprogramowanie komputerowe inne niż Oprogramowanie Aplikacyjne, wchodzące w skład Systemu z wyłączeniem Oprogramowania Narzędziowego oraz Oprogramowania Systemowego. Oprogramowanie Narzędziowe - Oprogramowanie i licencje dostępowe niezbędne do prawidłowego funkcjonowania Oprogramowania lub zarządzania zainstalowanymi urządzeniami lub do usprawniania i modyfikowania Oprogramowania Systemowego potrzebne do działania Systemu zgodnie z wymaganiami Zamawiającego określonymi w treści Specyfikacji Istotnych Warunków Zamówienia. Oprogramowanie Systemowe - odpowiednie Oprogramowanie i licencje dostępowe realizujące funkcje niezbędne do uruchomienia i działania urządzeń, na których zostało zainstalowane. OPZ - patrz: Szczegółowy Opis Przedmiotu Zamówienia. Organy administracji publicznej - rozumie się przez to ministrów, centralne organy administracji rządowej, wojewodów, działające w ich lub we własnym imieniu inne terenowe organy administracji rządowej (zespolonej i niezespolonej), organy jednostek samorządu terytorialnego oraz organy i podmioty wymienione w art. 1 pkt 2 (KPA Art. 5, 2 pkt 3). S t r o n a 12

13 Organy jednostek samorządu terytorialnego rozumie się przez to organy gmin, powiatu, województwa, związków gmin, związków powiatów, wójta, burmistrza (prezydenta miasta), starostę, marszałka województwa oraz kierowników służb, inspekcji i straży działającej w imieniu wójta, burmistrza (prezydenta miasta), starosty lub marszałka województwa, a ponadto samorządowe kolegia odwoławcze. Partner Projektu Jednostka Samorządu Terytorialnego (JST) województwa lubuskiego uczestnicząca w realizacji Projektu Lubuski e-urząd Poświadczenie przedłożenia - urzędowe poświadczenie odbioru zgodnie z rozporządzeniem w sprawie warunków organizacyjno-technicznych doręczania dokumentów elektronicznych podmiotom publicznym. Poświadczenie doręczenia - urzędowe poświadczenie odbioru zgodnie z rozporządzeniem w sprawie struktury i sposobu sporządzania pism w formie dokumentów elektronicznych oraz warunków organizacyjno technicznych ich doręczania. Pytania Wykonawców i odpowiedzi Zamawiającego zbiór wszystkich zapytań i odpowiedzi do Szczegółowego Opisu Przedmiotu Zamówienia udzielonych w trakcie postępowania przetargowego. PRINCE2 - strukturalna metodyka efektywnego zarządzania projektami. Zgodnie z metodyką realizacja Przedmiotu Zamówienia jest projektem, którego realizacja ma wytworzyć określone produkty. Problem - nieznana przyczyna Incydentu. Produkt - produkt zarządczy i specjalistyczny rozumiany w myśl metodyki PRINCE2, który ma być dostarczony przez Wykonawcę w ramach Zamówienia zgodne z SIWZ, w szczególności Oprogramowanie oraz Oprogramowanie Narzędziowe, Dokumentacja, a także wszelkie materiały i informacje, w tym niepodlegające ochronie prawa autorskiego, stworzone lub opracowane przez Wykonawcę i dostarczone Zamawiającemu w ramach realizacji Przedmiotu Zamówienia. Projekt - projekt pn: Lubuski e-urząd finansowany ze środków Unii Europejskiej w ramach Lubuskiego Regionalnego Programu Operacyjnego na lata Priorytet I. Rozwój infrastruktury wzmacniającej konkurencyjność regionu Działanie: 1.3 Rozwój społeczeństwa informacyjnego. Propozycja zmian Systemu (Modyfikacja) - każda proponowana zmiana Systemu lub jego funkcjonalności, odbiegająca od stanu i funkcjonalności Systemu opisanego w SIWZ i Dokumentacji, zgłoszona przez Użytkownika Końcowego w formie Zgłoszenia. Protokół Odbioru - Protokół Odbioru Zadania lub Protokół Odbioru Produktu lub Protokół Odbioru Końcowego. Protokół Odbioru Końcowego - protokół potwierdzający realizację zadań w ramach Zadań I-VIII. Protokół Odbioru Zadania - protokół potwierdzający realizację wskazanych w OPZ Zadań do wykonania. Pytania Wykonawców i odpowiedzi Zamawiającego - zbiór wszystkich zapytań i odpowiedzi do Szczegółowego Opisu Przedmiotu Zamówienia udzielonych w trakcie postępowania przetargowego. S t r o n a 13

14 Rozwiązanie Zgłoszenia - dla Incydentu i Problemu: spowodowanie przez Wykonawcę Normalnego Działania Systemu, dla Zapytania: spowodowanie przez Wykonawcę odpowiedzi na Zapytanie w taki sposób, aby wyjaśnił wszystkie przyczyny i przesłanki Zgłoszenia Zapytania przez Użytkownika Końcowego, dla Modyfikacji - wypełnienie wszystkich zadań Wykonawcy wynikających z Zarządzania Zmianą. SEOD System Elektronicznego Obiegu Dokumentów. SIWZ Specyfikacja Istotnych Warunków Zamówienia w postępowaniu przetargowym prowadzonym w trybie przetargu nieograniczonego pt. Pełnienie roli wykonawcy prac związanych z inwestycją pn: Lubuski e-urząd. System - System Informatyczny udostępniający funkcjonalność oferowaną przez Wykonawcę, na który składają się w szczególności Oprogramowanie oraz Oprogramowania Narzędziowe System Rejestracji Zgłoszeń - spójny system procedur, narzędzi informatycznych mający na celu zrealizowanie wszystkich wymagań Zamawiającego dotyczących przyjmowania i Rozwiązywania Zgłoszeń, w szczególności uruchomienie usługi Internetowego System Obsługi Help Desk w ramach Asysty i Gwarancji Jakości. Szkolenia - spójny, zorganizowany, dostarczony przez Wykonawcę system dedykowanych dla Zamawiającego szkoleń, o których mowa w SIWZ, przeprowadzony w sposób umożliwiający samodzielne użytkowanie oraz samodzielną obsługę i utrzymanie całego Systemu i jego wszystkich elementów przez Zamawiającego zgodnie z Załącznikiem nr 3 do SIWZ. Umowa - Umowa wraz z jej Załącznikami i wszelkimi Aneksami zawarta pomiędzy Zamawiającym, a Wykonawcą w wyniku udzielenia Zamówienia publicznego w postępowaniu prowadzonym w trybie przetargu nieograniczonego pt. Pełnienie roli wykonawcy prac związanych z inwestycją pn: Lubuski e-urząd. Urządzenie - element Infrastruktury Sprzętowej. Usterka - każdy stan lub działanie Systemu lub Produktu, w tym działanie w trybie awaryjnym, niezgodne z SIWZ i Dokumentacją. Utwór - wykonane w ramach realizacji Przedmiotu Zamówienia przez Wykonawcę wszelkie projekty koncepcje, opracowania, bazy danych, programy komputerowe oraz wszelkie inne utwory w rozumieniu przepisów ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (tj. Dz. U. z 2006 r., Nr 90, poz. 631 z późn.zm.). Uwaga - opis niezgodności Produktu z wymaganiami Zamawiającego opisanymi w SIWZ i Załącznikach do SIWZ stanowiących jego integralną część, w szczególności każda Wada, Błąd lub Usterka. Użytkownik Końcowy - Użytkownik lub inny system informatyczny bezpośrednio eksploatujący funkcje Systemu. Wada - wada konstrukcyjna, materiałowa lub wykonawcza powodująca nienormalny stan lub nienormalne działanie Systemu. Wdrożenie - całokształt prac wykonanych przez Wykonawcę w celu umożliwienia samodzielnej eksploatacji Oprogramowania przez pracowników Zamawiającego, a w szczególności czynności S t r o n a 14

15 takich jak: dostawa, instalacja, konfiguracja Oprogramowania, przygotowanie danych testowych, wykonanie testów weryfikacyjnych i wydajnościowych, przygotowanie szablonów oraz scenariuszy testowych, współudział w testach akceptacyjnych, opracowanie i dostarczenie Dokumentacji Technicznej i użytkownika, przeprowadzenie migracji i ładowanie danych, przeprowadzenie prezentacji funkcjonalności Systemu, szkolenie pracowników Zamawiającego oraz świadczenie usług Asysty Technicznej na etapie uruchomienia Modułów Systemu celem doprowadzenia do normalnej, prawidłowej eksploatacji Systemu. Wiodące Przeglądarki WWW pięć najpopularniejszych, stabilnych przeglądarek internetowych wg serwisu na dzień złożenia oferty. Wykonawca - oznacza osobę fizyczną, osobę prawną albo jednostkę organizacyjną nieposiadającą osobowości prawnej, która zostanie wyłoniona w niniejszym postępowaniu o udzielenie zamówienia publicznego. Zadanie wydzielona część Przedmiotu Zamówienia wyszczególniona w Załączniku nr 1 do SIWZ. Zamawiający - Województwo Lubuskie - Urząd Marszałkowski Województwa Lubuskiego. Zapytanie - rodzaj Zgłoszenia polegający na zdefiniowaniu pytania do Wykonawcy dotyczącego Systemu jego obsługi i funkcjonowania przez Użytkownika Końcowego. Zarządzanie Incydentem - efektywna działalność Wykonawcy mająca na celu przywrócenie Normalnego Działania Systemu w możliwie jak najkrótszym czasie, minimalizując zakłócenia w pracy w taki sposób, aby zapewnić osiągnięcie możliwie najwyższego poziomu dostępności Systemu. Zarządzanie Problemem - efektywna działalność Wykonawcy mająca na celu znalezienie przyczyny Incydentu i sposobu na przywrócenie poprawnego działania Systemu poprzez usunięcie przyczyny Incydentu. Zasoby Informacyjne Systemu (Zasoby Informacyjne) - zbiór danych i ich metadanych lub inna informacja przechowywana i przetwarzana w Systemie będących własnością Zamawiającego. Zdarzenie - Zapytanie, Modyfikacja oraz każde nienormalne działanie Systemu, które ma negatywny wpływ na działanie Systemu, jego elementów lub funkcjonalności, tzn. sytuacja, w której zachowanie Oprogramowania albo wynik działania jest odmienny od zamierzonego określonego w Dokumentacji Użytkowej Oprogramowania, które nie jest spowodowane niezgodnym z Dokumentacją działaniem Użytkownika Końcowego. Kategorie Zdarzeń: Kategoria A (sytuacja awaryjna / Awaria) (Zdarzenie Krytyczne) Zdarzenie wynikające z przyczyn leżących po stronie Systemu lub po stronie prawidłowej obsługi i użytkowania Systemu - powodujące całkowite zatrzymanie pracy lub niedostępność Systemu lub jednego z Modułów, utratę danych, naruszenie ich spójności lub zdarzenie uniemożliwiające działanie jednej z funkcji Systemu lub Modułu, tak, że dalsza praca dowolnej części Systemu lub jednego z Modułów uniemożliwia prowadzenie bieżącej działalności Zamawiającego przy użyciu Systemu. Do kategorii A należą, między innymi takie zdarzenia jak: spadek wydajności Systemu (Wydłużenie czasu odpowiedzi Systemu powyżej 1 minuty); S t r o n a 15

16 Użytkownik Końcowy nie może zapisać lub odtworzyć wyników pracy; System nie odpowiada na żądania Użytkownika; System generuje komunikat błędu; System pomimo posiadanych przez Użytkownika Końcowego uprawnień odmawia dostępu, lub udostępnia zasób osobie nieuprawnionej; działania w Systemie nie są możliwe do zrealizowania; nastąpiła utrata Zasobów Informacyjnych z Systemu. Kategoria B Zdarzenie wynikające z przyczyn leżących po stronie Systemu lub po stronie prawidłowej obsługi i użytkowania Systemu - powodujące nieprawidłowe działanie Systemu lub jednego z Modułów, ale umożliwiające jego użytkowanie. Zdarzenie kategorii B charakteryzuje się zmniejszeniem funkcjonalności Systemu, znacząco utrudniającym korzystanie z Systemu. Do kategorii B należą, między innymi takie zdarzenia jak: spadek wydajności Systemu (Wydłużenie czasu odpowiedzi Systemu od 10 do 60 sekund) nieprawidłowe działanie Systemu, lub jego części tj. każde działanie niezgodne z przeznaczeniem Systemu, Modułu, usługi Systemu, lub niespełnienie wymogów stawianych Systemowi przez Zamawiającego w Dokumentacji. występują istotne ograniczenia w działaniu Systemu, (ale nie powodujące przeciążenia systemu); nastąpiła awaria powodująca ograniczenie wydajności Systemu lub konieczność przełączenia się na rozwiązanie zapasowe z wyłączeniem sytuacji objętych kategorią A; wystąpiły błędy odczytu/zapisu danych- bez utraty danych; tzn. nieprawidłowe wyświetlanie odczytanych danych, lub niepoprawna forma zapisania danych; Kategoria C Zdarzenie wynikające z przyczyn leżących po stronie Systemu lub po stronie prawidłowej obsługi i użytkowania Systemu lub inne niż w kategoriach A i B, w wyniku, którego, dowolna część Systemu - oprogramowanie, platforma sprzętowa, akcesoria, itp.; utraciła swoją funkcjonalność. Do kategorii C należą, między innymi takie zdarzenia jak spadek wydajności Systemu (Wydłużenie czasu odpowiedzi Systemu od 5 do 10 sekund); każdy inne Zdarzenie niebędące Zdarzeniem Kategorii A lub B. Zespół Wdrożeniowy Wykonawcy - zespół pracowników Wykonawcy posiadający niezbędną wiedzę i doświadczenie z zakresu poszczególnych aplikacji Systemu oferowanego przez Wykonawcę oraz usług związanych z ich wdrożeniem. Zespół Wdrożeniowy Zamawiającego - zespół składający się z pracowników Zamawiającego posiadających merytoryczną, gospodarczą i ekonomiczną wiedzę w zakresie każdego z wdrażanych Systemów oraz ewentualnie pracowników działów informatyki, oddelegowanych decyzją Zamawiającego do zadań związanych z Wdrożeniem Systemu. Zgłoszenie - Incydent lub Problem zgłoszony przez Użytkownika Końcowego dotyczący Systemu. W szczególności Zgłoszeniem mogą być również Modyfikacje, Zapytania oraz Zmiany Konfiguracji Systemu. Zmiana Konfiguracji Systemu - jakakolwiek zmiana parametrów Systemu wobec zdefiniowanych w SIWZ i Dokumentacji. S t r o n a 16

17 XML - XML (ang. Extensible Markup Language) to uniwersalny język formalny przeznaczony do reprezentowania różnych danych w ustrukturalizowany sposób. XSD - Język definicji schematu XML (XML Schema Definition) służy do definiowania struktury dokumentów XML. Jego podstawowym zadaniem jest umożliwianie aplikacjom takiego opisywania dokumentów XML, aby inne aplikacje używające tych dokumentów mogły zakładać, że dokument jest zgodny z przewidzianą strukturą. Język XSD, popierany przez konsorcjum World Wide Web Consortium (W3C), zawiera dziesiątki definicji i poleceń deklaracyjnych, które umożliwiają opis struktury dokumentów. XSLT i XSL - XSL (ang. Extensible Stylesheet Language) - opisuje sposób prezentacji i przekształceń dokumentów zapisanych w XML. XSLT (ang. Extensible Stylesheet Language: Transformations) jest podzbiorem XSL. Język XSL jest używany do definiowania formatowania dokumentów XML, a język XSLT zawiera szablony i polecenia służące do manipulowania strukturą danych VII. Promocja W ramach realizacji prac związanych z Umową Wykonawca zobowiązany jest do stosowania Wytycznych Instytucji Zarządzającej Lubuskim Regionalnym Programem Operacyjnym w zakresie informacji i promocji dla beneficjentów, stanowiących Załącznik nr 6 do SIWZ. VIII. Szczegółowy Opis Przedmiotu Zamówienia Opisane poniżej wymagania stanowią zakres minimalnych oczekiwań Zamawiającego dla dostaw sprzętowych. Zamawiający dopuszcza równoważność rozwiązań: 1. Wszędzie tam, gdzie Przedmiot Zamówienia jest opisany poprzez wskazanie znaków towarowych, patentów lub pochodzenia, Zamawiający dopuszcza zastosowanie przez Wykonawcę rozwiązań równoważnych w stosunku do opisanych w SIWZ, pod warunkiem, że będą one posiadały, co najmniej takie same lub lepsze parametry techniczne i funkcjonalne, i nie obniżą określonych w SIWZ standardów. 2. W przypadku, gdy Wykonawca zaproponuje urządzenia, instalacje, materiały i inne elementy równoważne, zobowiązany jest wykonać i załączyć do oferty zestawienie wszystkich zaproponowanych urządzeń, instalacji, materiałów oraz innych elementów równoważnych i wykazać ich równoważność w stosunku do urządzeń, instalacji, materiałów i innych elementów opisanych w SIWZ, stanowiącej Opis Przedmiotu Zamówienia ze wskazaniem nazwy, strony i pozycji, których dotyczy. 3. Wszystkie zaproponowane przez Wykonawcę równoważne urządzenia, instalacje, materiały lub inne elementy muszą: a. posiadać parametry techniczne i funkcjonalne nie gorsze od określonych w SIWZ, b. zapewniać pełną kompatybilność sprzętową i programową z rozwiązaniami określonymi w SIWZ, c. posiadać stosowne dopuszczenia i atesty. S t r o n a 17

18 Wszystkie dostarczane przez Wykonawcę urządzenia muszą być wyposażone w przewody zasilające / sygnałowe niezbędne do uzyskania jego pełnej funkcjonalności, a w szczególności do jego podłączenia do sieci energetycznej, sieci komputerowej LAN / WAN lub serwerów w zależności od pełnionej funkcji. IX. Licencjonowanie Oprogramowania Oprogramowanie, Oprogramowanie Systemowe, Oprogramowanie Narzędziowe oraz sprzęt teleinformatyczny będą przez cały okres trwałości projektu (5 lat od jego zakończenia) własnością Zamawiającego (Urząd Marszałkowski Województwa Lubuskiego) i bezpłatnie użyczone przez niego dla Partnerów Projektu. Partnerzy Projektu będą je eksploatować w okresie wdrożenia i trwałości Projektu. Po zakończeniu okresu trwałości Projektu Oprogramowanie, Oprogramowanie Systemowe, Oprogramowanie Narzędziowe oraz sprzęt teleinformatyczny zostanie formalnie przekazany do Partnerów Projektu i stanie się ich własnością. Wykonawca zobowiązany jest uwzględnić powyższe wymagania przy doborze odpowiedniego sposobu licencjonowania oferowanego Oprogramowania, Oprogramowania Systemowego oraz Oprogramowania Narzędziowego. S t r o n a 18

19 Zadanie nr 1: System Elektronicznego Obiegu Dokumentów Lp. Zawartość karty Opis 1 Specyfikacja techniczna / funkcjonalna Przedmiotu Zamówienia Zakres przedmiotu zamówienia obejmuje dostawę wraz z wdrożeniem Systemu Elektronicznego Obiegu Dokumentów oraz integrację Systemu Elektronicznego Obiegu Dokumentów z Regionalną Platformą Komunikacji Elektronicznej (Cyfrowy Urząd) na warunkach określonych w niniejszej Karcie produktu oraz na warunkach określonych w Specyfikacji Istotnych Warunków Zamówienia. Wykonawca nie ma obowiązku opracowania formularzy za pomocą Edytora formularzy Regionalnej Platformy Komunikacji Elektronicznej, może je wykonać dowolnym narzędziem, jednakże pliki muszą być w formacie UTF-8 bez BOM (Byte Order Mark) i dla plików formularzy (Orbeon Forms) standard W3C XFORMS w najnowszej obowiązującej wersji. Formularze muszą być interaktywne i posiadać walidację zamieszczonych pól, jak również obsługiwać podstawowe formuły matematyczne typu suma i iloczyn. Dla każdego formularza musi być opracowana i dołączona karta opisująca sposób realizacji sprawy zawierającą, co najmniej: Ogólny opis. Miejsce załatwienia sprawy. Czas realizacji. Wymagane dokumenty. Opłaty. Tryb odwoławczy. Podstawa prawna. Aktualnie Zamawiający oraz Partnerzy Projektu używają następujących rozwiązań: RBIP, BIP ( S t r o n a 19

20 o Dostawca: Konsorcjum firm Sygnity S.A. i Max Elektronik S.A. Regionalna Platforma Komunikacji Elektronicznej: o Dostawca: Konsorcjum firm Sygnity S.A. i Max Elektronik S.A. o Wersja oprogramowania:..1 Elektroniczna Skrzynka Podawcza wersja 3.0,..2 Edytor Formularzy Elektronicznych wersja 2.0,..3 Szyna Integracyjna ESB wersja 1.0,..4 Moduł do zarządzania usługami szyny integracyjnej ESB wersja 1.0,..5 Moduł ewidencji opłat i płatności wersja 1.0 Specyfikacja wymagań funkcjonalnych i pozafunkcjonalnych dla Systemu Elektronicznego Obiegu Dokumentów: System Elektronicznego Obiegu Dokumentów musi spełniać następujące wymagania minimalne: System Elektronicznego Obiegu Dokumentów (SEOD) ma pełnić istotną rolę w realizacji codziennych zadań pracowników Zamawiającego i Partnerów Projektu. W ESOD mają być gromadzone wszystkie pisma, które za pośrednictwem formularzy elektronicznych oraz tradycyjnych kancelarii wpływają codziennie do urzędu. ESOD ma wspierać proces rozpatrywania spraw zapewniając mechanizmy przekazywania dokumentów pomiędzy komórkami i pracownikami. W ESOD mają być rejestrowane także pisma wychodzące i wewnętrzne powstające w codziennej pracy. System ESOD musi umożliwiać wymianę elektronicznej korespondencji między osobami pracującymi w różnych lokalizacjach. System ESOD musi umożliwiać wymianę korespondencji elektronicznej pomiędzy Zamawiającym oraz Partnerami Projektu a podmiotami zewnętrznymi w sposób spełniający wymagania prawa w tym zakresie. Wymiana powinna odbywać się z wykorzystaniem Elektronicznej Skrzynki Podawczej (ESP) oraz urządzenia do generowania Urzędowego Potwierdzenia Odbioru (HSM) w celu zapewnienia zgodności z prawem (w zakresie przepisów dotyczących doręczania dokumentów w sposób elektroniczny). Wymagania techniczne S t r o n a 20

21 System musi być zbudowany w architekturze trójwarstwowej. Rozdzielone powinny być: warstwa prezentacji, logiki biznesowej oraz bazy danych Interfejs aplikacji musi być dostępny za pomocą przeglądarki internetowej, min.: o Internet Explorer 8 i wyższe o Opera 11.x i wyższe o Firefox 23.x i wyższe o Chrome 30 i wyższe System musi mieć możliwość pracy, co najmniej pod kontrolą systemu Windows (XP lub nowszy) w zakresie stacji klienckiej System musi mieć możliwość pracy co najmniej pod kontrolą systemu Windows (Server 2008 R2 lub nowszy) lub Linux co najmniej dystrybucja SuSe 12.0 lub nowsza w zakresie serwera bazy danych i serwera aplikacyjnego System musi pracować w oparciu o relacyjną bazę danych. Ze względu na możliwość dalszego rozwoju oraz planowany przyrost danych System musi umożliwiać pracę z wykorzystaniem zarówno komercyjnej jak i darmowej bazy danych Migracja danych pomiędzy bazami danych (komercyjna -> darmowa oraz darmowa-> komercyjna) nie może powodować utraty żadnej części danych Ze względu na bezpieczeństwo danych, wszystkie dane przetwarzane przez System powinny być przechowywane w bazie danych i chronione przez mechanizmy zabezpieczeń silnika bazy danych. Przechowywanie danych związanych ze sprawą poza bazą danych dopuszczalne jest jedynie po zakończeniu procesu archiwizacji danej sprawy Oferowany System musi posiadać możliwość tworzenia kopii bezpieczeństwa bazy danych. Baza danych musi mieć możliwość przechowywania informacji o rozmiarze co najmniej 10 GB. Dostarczone narzędzia powinny posiadać możliwość definiowania harmonogramów automatycznego wykonywania kopii pełnej lub przyrostowej. O wyborze rodzaju wykonywania kopii decyduje Administrator Systemu. Sposób obsługi mechanizmu musi być szczegółowo opisany w Dokumentacji Użytkowej dla administratorów System musi posiadać interfejsy komunikacyjne w postaci metod WebServices Interfejsy komunikacyjne Systemu powinny być zgodne ze standardami SOAP, WSDL i XML System musi umożliwiać takie skonfigurowanie interfejsów komunikacyjnych, aby były one dostępne poprzez standardowy protokół HTTP oraz S t r o n a 21

22 poprzez zabezpieczony protokół HTTPS szyfrowany zgodnie ze standardem SSL. Wybór oraz skonfigurowanie typu połączenia powinno być możliwe przez Zamawiającego bez potrzeby ingerencji ze strony Wykonawcy Dane w systemie SEOD muszą być zabezpieczone przed utratą w trybie czasu rzeczywistego przed awarią pojedynczych urządzeń pamięci masowych. Jeśli zostaje uszkodzony komputer kliencki, to zniszczeniu ulec mogą tylko zmiany, które wprowadzone zostały na tym komputerze w edytowanych w momencie awarii dokumentach. Wymagania funkcjonalne w zakresie administrowania Systemu System musi posiadać wyodrębniony moduł administracyjny dostępny za pomocą przeglądarki internetowej. Dostęp do tego modułu mogą uzyskać jedynie użytkownicy z odpowiednimi uprawnieniami Dostęp do modułu administracyjnego musi być zdefiniowany przynajmniej w postaci dwóch ról administracji Systemowej, oraz administracji lokalnej. Użytkownik posiadający uprawnienia do administracji Systemowej będzie mógł zmieniać wszystkie parametry Systemu. Administrator z uprawnieniami lokalnymi musi posiadać możliwość modyfikacji tylko parametrów dotyczących komórek struktury organizacyjnej, dla których ma przypisane uprawnienie administratora Moduł administracyjny musi umożliwiać zarządzanie słownikami Systemowymi, w zakresie dodawania, usuwania oraz modyfikacji wpisów w słownikach System musi uniemożliwić usuwanie oraz edycję wpisów niezbędnych do jego prawidłowego działania W przypadku usuwania wpisów ze słownika, nie może zostać naruszona integralność bazy danych. Usuwanie wpisów słownika powinno być logiczne (poprzez ustawienie odpowiedniej flagi). Dopuszcza się usuwanie fizyczne pozycji słownikowych jedynie w przypadku, gdy dana pozycja słownika nie została jeszcze wykorzystana w Systemie przez użytkowników System musi udostępniać przynajmniej następujące słowniki: o słownik rodzajów spraw (RWA) o słownik rodzajów pism o słownik załączników - rodzajów plików, jakie mogą być dodawane do pism lub spraw jako załączniki. Słownik musi umożliwić S t r o n a 22

23 zdefiniowanie co najmniej rozszerzenia pliku, oraz maksymalnego dopuszczalnego rozmiaru pliku danego typu o słownik kategorii archiwalnych o słownik typów dekretacji o słowniki związane z danymi adresowymi słownik miast, gmin, powiatów, województw o słownik stanowisk o słownik sposobów wysyłki System musi posiadać wbudowane słowniki dotyczące danych adresowych: gmin, powiatów, województw oparte na danych z systemu TERYT System musi umożliwiać ręczną oraz automatyczną aktualizację słowników TERYT. Ręczna aktualizacja powinna polegać na wskazaniu plików aktualizacyjnych. Automatyczna aktualizacja powinna skutkować pobraniem przez system odpowiednich plików udostępnianych w Internecie oraz zaktualizowanie na ich podstawie danych w słowniku System SEOD musi posiadać aktualną bazę kodów pocztowych możliwą do aktualizacji z wykorzystaniem Spisu Pocztowych Numerów Adresowych Poczty Polskiej System SEOD musi posiadać wbudowany słownik miejscowości i ulic w oparciu o dane z podziału terytorialnego kraju na gminy, powiaty i województwa (TERYT). We wszystkich formatkach obejmujących dane adresowe musi być możliwe wykorzystane słownika do wprowadzania danych. Słownik musi posiadać aktualne informacje na podstawie danych udostępnianych przez GUS Uprawniony użytkownik systemu SEOD musi posiadać możliwość rozbudowywania słownika TERYT w przypadku brakujących danych. System SEOD nie może uzależniać określenia adresu interesanta od istnienia miejscowości czy ulicy w bazie TERYT System musi umożliwiać wiązanie rodzajów pism z rodzajami spraw (i odwrotnie) w celu zwiększenia ergonomii pracy użytkowników, poprzez inteligentne ograniczanie listy rodzajów udostępnianych użytkownikowi w kontekście wybranych wcześniej danych (np. ograniczenie listy rodzajów pism w kontekście rodzaju sprawy, w której tworzone jest pismo) Dla każdego rodzaju sprawy System musi umożliwić określenie liczby dni potrzebnych na jej rozpatrzenie. Ponadto, administrator musi mieć możliwość określenia liczby dni, po których sprawa zostanie oznaczona jako zagrożona przekroczeniem terminu. Poza standardowymi wartościami, System musi umożliwić zdefiniowanie trybów postępowania (np. tryb administracyjny, tryb odwoławczy itp.) dla każdego z tych trybów administrator musi określić oddzielne parametry dotyczące terminu rozpatrzenia i przypomnienia. S t r o n a 23

24 System musi umożliwiać definiowanie rodzajów pism wchodzących i wychodzących. System musi umożliwiać tworzenie szablonów pism wychodzących. Powinna istnieć możliwość tworzenia szablonów w formacie *.doc lub *.rtf lub za pomocą niezależnego od aplikacji zewnętrznych wbudowanego edytora. W szablonie pisma powinna być możliwość zdefiniowania znaczników, które będą automatycznie zamieniane na wartości znajdujące się w Systemie. Minimalny zakres znaczników: o Dane nadawcy o Dane adresata (imię, nazwisko, adres, nazwa instytucji) o Znak pisma/sprawy o Lista adresatów, którzy otrzymują pismo do wiadomości o Data pisma o Kod kreskowy (identyfikator pisma) System musi posiadać możliwość współpracy z edytorem Microsoft Office w wersji 2003 lub nowszej w zakresie podglądu i tworzenia pism wychodzących Dla każdego rodzaju sprawy System musi umożliwiać definiowanie dowolnych statusów powiązanych ze stanem sprawy. Informacja o stanie i statusie danej sprawy będzie przedmiotem integracji Systemu z Regionalną platformą komunikacji elektronicznej (Cyfrowy Urząd) System musi umożliwiać definiowanie i przechowywanie informacji o powiązaniu formularzy elektronicznych z poszczególnymi rodzajami spraw, oraz przechowywanie informacji o komórkach organizacyjnych do których może trafić dany wniosek System musi umożliwiać rozpoczęcie pracy w ciągu roku, z zachowaniem kontynuacji dotychczasowej numeracji pism, spraw, spisów zdawczoodbiorczych oraz numerów kancelaryjnych, poprzez możliwość zdefiniowania wartości początkowych przez administratora Systemu System musi umożliwiać zdefiniowanie formatu znaku sprawy, pisma oraz rejestru zgodnie z Instrukcją Kancelaryjną. System musi umożliwiać definiowanie spraw oraz wydzielonych grup spraw. Symbol spraw musi być automatycznie nadawany przez System. System musi umożliwiać również przeglądanie spraw obowiązujących w danym dniu w przeszłości System musi umożliwiać prowadzenie obsługi kancelaryjnej zarówno w systemie tradycyjnym, jak i w systemie Elektronicznego Zarządzania Dokumentacją (EZD), w zależności od decyzji kierownika jednostki. S t r o n a 24

25 System musi umożliwiać przejście jednostki z systemu tradycyjnego do systemu EZD bez utraty danych przechowywanych w SEOD. System musi umożliwić ewidencjonowanie obiegu (lokalizacja, czas przemieszczenia, użytkownik) dokumentów papierowych (dla których istnieje odwzorowanie cyfrowe oraz dla których nie zostało ono wykonane) oraz nośników. System musi umożliwiać definiowanie Rzeczowego Wykazu Akt z określeniem przyszłej daty rozpoczęcia jego obowiązywania. System musi umożliwiać również przeglądanie RWA obowiązującego w danym dniu w przeszłości Przełączenie na nowy Rzeczowy Wykaz Akt oraz wykorzystanie nowych teczek powinno odbywać się w pełni automatycznie zgodnie z datą obowiązywania bez potrzeby ingerencji ze strony Administratora System musi umożliwiać definiowanie dowolnej ilości rejestrów dodatkowych. Rejestry muszą umożliwiać gromadzenie pism lub spraw danego rodzaju, pochodzących z określonych komórek struktury organizacyjnej System musi umożliwiać tworzenie rejestrów ręcznych oraz automatycznych. W przypadku rejestrów ręcznych, użytkownik sam będzie wskazywał dokumenty, które powinny trafić do rejestru. Zawartość rejestrów automatycznych powinna być kontrolowana i aktualizowana przez System System musi umożliwiać tworzenie rejestrów z podaniem zakresu dat dokumentów, które się w nim znajdą. W przypadku tworzenia rejestrów z datami przeszłymi System musi umożliwić automatyczne uzupełnienie rejestru odpowiednimi dokumentami System musi udostępniać administratorowi funkcję globalnego zablokowania dostępu użytkowników do Systemu, np. na czas wykonywania czynności administracyjnych lub konserwacyjnych. Zablokowanie systemu powinno zostać poprzedzone wysłaniem odpowiedniego komunikatu do aktualnie zalogowanych użytkowników oraz ich automatyczne wylogowanie po upłynięciu określonego czasu System musi umożliwiać definiowanie struktury organizacyjnej zgodnej ze schematem organizacyjnym Zamawiającego lub Partnerów Projektu. Struktura organizacyjna może składać się z dowolnej liczby zagnieżdżonych komórek. Do każdej z komórek może zostać przypisana dowolna liczba użytkowników. Każda komórka powinna posiadać co najmniej swoją nazwę oraz kod System SEOD musi umożliwiać wyszukiwanie w strukturze organizacyjnej stanowisk/komórek, użytkowników z uwzględnieniem statusu stanowiska. System SEOD musi umożliwiać import użytkowników z pliku CSV o określonej strukturze. System SEOD musi udostępniać każdemu użytkownikowi aktualną książkę teleadresową użytkowników SEOD w postaci struktury organizacyjnej, użytkownikiem przypisanym do stanowiska, nr telefonu, adresem , miejscem pracy i uwagami, jak również umożliwia wyszukiwania w S t r o n a 25

26 książce po całej zawartości. Dla każdej komórki organizacyjnej powinna być możliwość przypisania jej adresu, bądź skopiowania go z komórki nadrzędnej System musi umożliwiać przeniesienie wszystkich pism i spraw znajdujących się w danej komórce na inną komórkę System musi umożliwiać zautomatyzowane przeniesienie wszystkich pism i spraw danego pracownika innemu pracownikowi System musi umożliwić zdefiniowanie dowolnej liczby kancelarii. Musi istnieć możliwość przypisania dowolnej liczby kancelarii do dowolnej liczby komórek (jedna kancelaria może obsługiwać wiele komórek, jedna komórka może mieć przypisanych wiele kancelarii) System musi umożliwiać zarządzanie użytkownikami, poprzez tworzenie, usuwanie, blokowanie oraz przypisywanie użytkowników do komórek. Jeden użytkownik może pracować w wielu komórkach System musi umożliwiać przypisywanie użytkownikom ról oraz uprawnień do spraw (co najmniej w zakresie wyszukiwania i rejestrowania spraw) i rejestrów System musi umożliwiać definiowanie grup użytkowników oraz przypisywanie im uprawnień. Uprawnienia przypisane grupie użytkowników powinny być przypisywane użytkownikom należącym do danej grupy W celu ułatwienia zarządzania System musi umożliwiać szybkie wyszukiwanie użytkowników i komórek w strukturze organizacyjnej poprzez zawężanie listy dostępnych rekordów w miarę wpisywania kolejnych znaków imienia, nazwiska użytkownika lub nazwy komórki. System musi również umożliwiać ograniczenie listy wyświetlanych danych do listy samych komórek lub samych użytkowników System musi umożliwiać przyspieszenie procesu dodawania użytkowników/stanowisk poprzez możliwość tworzenia nowego użytkownika/stanowiska na podstawie użytkownika/stanowiska wcześniej zdefiniowanego w Systemie. W takim wypadku, nowotworzony użytkownik/stanowisko musi posiadać takie same uprawnienia jak użytkownik/stanowisko wzorcowe System musi informować o wpłynięciu dokumentu na skrzynkę użytkownika. System musi wysyłać na skrzynkę użytkownika powiadomienia o wpłynięciu dokumentu dekretowanego/przekazanego do danego użytkownika. Każdy użytkownik systemu SEOD musi posiadać możliwość samodzielnego dostosowania listy otrzymywanych powiadomień do swoich potrzeb. Powiadomienia muszą być prezentowane użytkownikowi w systemie SEOD za pomocą wyskakującego okna typu popup, niezależnie od miejsca S t r o n a 26

27 w SEOD, w którym w danym momencie znajduje się użytkownik. Nawet po zamknięciu powiadomienia przez użytkownika musi posiadać on możliwość przejrzenia listy wszystkich otrzymanych powiadomień w przeszłości. System SEOD musi umożliwiać przesyłanie powiadomień na adres użytkownika, jako wiadomość wewnętrzną, zdarzenie w terminarzu Powiadomienia w systemie SEOD muszą zawierać bezpośredni odnośnik do obiektu (dokumentu, sprawy), którego powiadomienie dotyczy. Powiadomienia w systemie SEOD w szczególności muszą dotyczyć: o Przychodzących wiadomości wewnętrznych, o Udostępnienia użytkownikowi sprawy, o Utworzenia nowej sprawy w komórce organizacyjnej i/lub podległych komórkach, o Otwarcia dokumentu przesłanego, zadekretowanego do innego użytkownika, o Otrzymania dokumentu do akceptacji, o Zaakceptowania dokumentu, o Dodania komentarza do sprawy przez innego użytkownika, o Upłynięcia terminu rozpatrzenia sprawy, o Dodania zdarzenia do terminarza przez innego użytkownika, o Przeterminowania etapu rozpatrzenia sprawy, o Pojawienia się nowego pisma do dekretacji lub ponownej dekretacji, o Pojawienia się nowego pisma do przyjęcia, o Zmiany dekretacji użytkownika przez innego użytkownika, o Dołączenie dokumentu do sprawy przez innego użytkownika, o Zatwierdzenia dokumentu przez kolejnego użytkownika zatwierdzającego w ścieżce akceptacji dokumentu, o Odrzucenia dokumentu przez kolejnego użytkownika zatwierdzającego w ścieżce akceptacji dokumentu. o Alertów dotyczących upływu terminu rozpatrywania sprawy. o Informacji o wysłaniu pisma tj. określenie daty fizycznej wysyłki w rejestrze przesyłek wychodzących. S t r o n a 27

28 Użytkownik musi mieć możliwość decydowania o rodzaju otrzymywanych powiadomień System musi umożliwiać definiowanie zastępstw na czas nieobecności polegających na udzieleniu pełnomocnictwa innemu użytkownikowi do wykonywania czynności w imieniu użytkownika nieobecnego. Pełnomocnictwo powinno być definiowane w określonym przedziale czasu. Dostęp do danych nieobecnego użytkownika musi być kontrolowany przez System i odbierany wraz z upłynięciem daty końcowej System musi posiadać funkcjonalność logowania zmian wykonanych podczas zastępstwa. Powinna istnieć możliwość przeglądania zmian wprowadzonych przez osobę zastępującą z dokładnością do edytowanych przez nią pól, oraz wartości poprzedniej oraz wprowadzonej Dla każdego rodzaju pisma i sprawy System musi umożliwiać definiowanie dowolnych dodatkowych atrybutów zgodnie z potrzebami użytkowników. System musi umożliwiać tworzenie atrybutów co najmniej następujących typów: o Pole tekstowe o Data o pole wyboru (check box) Dla każdego atrybutu Administrator musi móc przypisać etykietę tekstową oraz określić jego obligatoryjność System musi automatycznie logować wszystkie wykonywane przez Użytkowników oraz Administratorów operacje. W szczególności System musi logować zdarzenia typu otwarcie dokumentu/sprawy, podgląd załącznika, edycja dokumentu itp. W zakresie działań administracyjnych System musi logować wszystkie zdarzenia w szczególności modyfikację pozycji słowników z zachowaniem początkowej i końcowej wartości. System nie może umożliwiać edycji zawartości logów System musi umożliwić podgląd logów w danym okresie w kontekście użytkownika (np. wszystkie operacje wykonywane przez użytkownika X w okresie od do ) oraz w kontekście obiektu pisma lub sprawy (np. wszystkie operacje wykonane na piśmie o numerze kancelaryjnym XYZ w okresie od do ). System musi umożliwiać wydruk logów w postaci raportu System musi przechowywać wszystkie logi od początku wdrożenia systemu, bez możliwości usunięcia ich. Poza dziennikiem zdarzeń system SEOD musi rejestrować, prezentować użytkownikowi i przechowywać historię: o Zmian w strukturze organizacyjnej. o Historię obiegu sprawy i dokumentu, zawierającą informację co najmniej o wszystkich zmianach statusów, czynnościach wykonanych na danym etapie przez użytkowników, o punktach zatrzymania oraz datach i czasach wykonania poszczególnych czynności. System SEOD S t r o n a 28

29 musi prezentować historię obiegu sprawy także w postaci grafu odzwierciedlającego przebieg realizowanej ścieżki procesu. o Historię zmian metryk wszystkich dokumentów i spraw dokonywanych przez użytkowników posiadających stosowne uprawnienia. o Historię spraw użytkownika, zawierającą listę wszystkich spraw i dokumentów, nad którymi użytkownik pracuje bądź pracował, z możliwością filtrowania w niej. o Historię wszystkich zmian dokonanych na interesancie w słowniku interesantów. o Historię wszystkich nieobecności w systemie wraz osobami zastępującymi, czasem trwania zastępstwa i historią procesu wniosku systemowego o nieobecność. o Historię przekazywania akt do archiwum. o Historię zmian w Jednolitym Rzeczowym Wykazie Akt. System musi umożliwiać określanie zakresu dostępu do dokumentów tajnych oraz określanie poziomu dostępu do teczek System musi umożliwiać korzystanie z definicji procesów WorkFlow. Administrator musi posiadać możliwość wiązania definicji procesu z rodzajem sprawy System SEOD musi prezentować historię sprawy w postaci graficznej z oznaczeniem kroku w procesie, w którym znajduje się sprawa. Na żądanie interesanta System musi umożliwiać wygenerowanie raportu z jego danymi osobowymi oraz w razie potrzeby modyfikację danych osobowych przechowywanych w systemie. Dla osób fizycznych musi istnieć możliwość wydruku zakresu przetwarzanych danych osobowych przetwarzanych w systemie SEOD zgodnie z wytycznymi GIODO w tym zakresie. System SEOD musi umożliwiać rejestrowanie wyrażenia sprzeciwu wobec przetwarzania danych osobowych, o których mowa w art. 32, ust.1, pkt. 8 ustawy o ochronie danych osobowych. System SEOD musi umożliwiać eksport danych interesantów do pliku CSV, XLS, PDF. System SEOD musi umożliwiać tworzenie korespondencji seryjnej z użyciem szablonów w przypadku tworzenia dokumentów o tej samej treści (za wyjątkiem adresata) adresowanych do wielu odbiorców. Sposób generowania korespondencji seryjnej nie może blokować możliwości edycji wykorzystanego przez użytkownika szablonu korespondencji do momentu zatwierdzenia jego treści. S t r o n a 29

30 System musi umożliwiać definiowanie pism wychodzących w postaci formularzy elektronicznych w strukturze XML udostępnianych użytkownikom Systemu. Formularz elektroniczny musi być tworzony za pomocą odpowiedniego kreatora, prowadzącego Administratora przez proces tworzenia zakresu funkcjonalnego, struktury formularza oraz wizualizacji jego postaci wynikowej. Edytor musi pozwalać co najmniej na: tworzenie formularzy metodą drag&drop, import/eksport formularzy do i z pliku XML, definiowanie pól słownikowych, zamieszczanie dowolnych elementów tekstowograficznych oraz treści pomocy kontekstowej w ramach wzoru dokumentu, definiowanie reguł walidacji pól wzoru dokumentu, tworzenie list rozwijanych, pól wielokrotnego wyboru etc. Administrator musi mieć możliwość definiowania dowolnych struktur danych, wykorzystania dostępnych w systemie struktur oraz definiowania stałych bloków tekstu. Pola formularza powinny być wypełniane automatycznie przez System na podstawie danych przechowywanych w bazie danych np. automatycznie pobierane i podpowiadane dane adresowe interesanta lub wprowadzane przez użytkowników w przypadku braku takich danych. Zamawiający wymaga, aby po zakończeniu wdrożenia mógł on samodzielnie zmieniać i modelować procesy WorkFlow, formularze elektroniczne dla procedur administracyjnych będących przedmiotem wdrożenia. Zamawiający nie dopuszcza rozwiązania, w których mechanizmy procedur WorkFlow oraz formularzy elektronicznych są na stałe modelowane w kodzie wdrażanego Elektronicznego Systemu Obiegu Dokumentów. System musi umożliwiać uwierzytelnianie użytkowników w oparciu o własną bazę danych lub zewnętrzy system uwierzytelniania użytkowników (LDAP, Active Directory). Administrator musi mieć możliwość wyboru stosowanego systemu uwierzytelniania. Wymagania funkcjonalne w zakresie obsługi kancelaryjnej System musi obsługiwać logowanie na podstawie identyfikatora i hasła. System musi być wyposażony w mechanizm wymuszenia zmiany hasła co określony okres czasu. System musi sprawdzać złożoność hasła zgodnie z wymaganiami ustawy o ochronie danych osobowych System musi umożliwiać rejestrację pism wpływających do urzędu. Użytkownik musi mieć możliwość podania takich atrybutów pisma jak: temat pisma, znak nadany przez instytucję zewnętrzną, daty wpływu, temat pisma, liczba załączników. System musi pozwalać na klasyfikację korespondencji zgodnie z właściwością. W celu uniknięcia nadużyć System musi automatycznie zapisywać datę rejestracji pisma na podstawie daty systemowej bez możliwości modyfikacji. W przypadku pism pochodzących z formularzy elektronicznych pobranych z elektronicznej skrzynki podawczej data rejestracji powinna być tworzona na podstawie daty pobranej z dokumentu Urzędowego Potwierdzenia Odbioru (UPO) System musi umożliwiać rejestrację i obsługę pism wewnętrznych System musi umożliwić szybką rejestrację pism polegającą na podaniu tylko podstawowych danych (adresat, liczba załączników) zakończoną automatycznym nadaniem numeru kancelaryjnego. System musi pozwolić na wykonanie pozostałych czynności związanych z rejestracją pisma w S t r o n a 30

31 późniejszym czasie lub przez innego użytkownika System SEOD musi posiadać mechanizm umożliwiający sprawdzenie podczas rejestracji dowolnego pisma czy przesyłka wpływająca nie została już zarejestrowana (np. jako faks przychodzący), w tym poprzez sprawdzenie znaku pisma wpływającego oraz nadawcy. System SEOD musi umożliwiać rejestrowanie pism, które nie mogą być otwarte przez kancelarię, dziennik podawczy czy sekretariat (np. oferta przetargowa). Użytkownik, któremu doręczono dokument musi mieć możliwość dokonania pełnej rejestracji. System SEOD musi umożliwiać konfigurację i obsługę składów chronologicznych, oddzielnie dla przesyłek przychodzących i wychodzących, z możliwością odnotowania stopnia odwzorowania przesyłek papierowych. System SEOD musi umożliwiać konfigurację i obsługę składów nośników informatycznych, z możliwością odnotowywania stopnia wprowadzenia przesyłek w formie elektronicznej. System SEOD musi wspomagać obsługę Zwrotnego Potwierdzenia Odbioru (ZPO) w zakresie rejestracji i znakowania kodem kreskowym. System SEOD musi rejestrować Zwrotne Potwierdzenie Odbioru (ZPO), jako załącznik do korespondencji, której dotyczy. Jeżeli przesyłka zawiera wiele dokumentów, to w systemie SEOD musi być dostępna informacja o ZPO z poziomu każdego dokumentu zawartego w przesyłce zbiorczej. System SEOD musi posiadać wbudowany faks-serwer umożliwiający zarejestrowanie wpływającego faksu, wysyłanie korespondencji za pomocą faksu, powiadamianie nadawcy o terminie i statusie wysłanego faksu lub związanych z nim problemów, usuwanie faksów niepodlegających rejestracji. System SEOD musi umożliwiać rejestrację wielu dokumentów z jednej przesyłki wpływającej (koperta zawierająca wiele dokumentów od tego samego nadawcy) poprzez możliwość wykorzystania w sposób automatyczny całego zestawu danych z rejestracji poprzedniego pisma. System SEOD musi umożliwiać oznaczanie kopert z przesyłkami kodami kreskowymi. System SEOD musi pozwalać na hurtową i jednoczesną generację dowolnej liczby wskazanych wydruków (np. kopert, etykiet adresowych, zwrotek) dla wskazanych przesyłek wychodzących w rejestrze przesyłek wychodzących. Przykładowo, użytkownik musi mieć możliwość hurtowego i jednoczesnego wygenerowania po jednej kopercie i zwrotce dla wskazanej liczby przesyłek. Możliwość łączenia wielu pism do jednej koperty (przesyłki) musi być dostępna w systemie SEOD dla każdego referenta w zakresie własnych spraw, dla sekretariatów w zakresie własnych komórek oraz dla pracowników kancelarii/dzienniku podawczym w zakresie wszystkich przesyłek. System SEOD musi wspierać obsługę doręczeń przesyłek poprzez gońców. System SEOD musi pozwalać zdefiniować administratorowi słownik S t r o n a 31

32 rejonów (obszarów pracy) gońców, poprzez określenie zakresów adresowych (miejscowości, ulic, zakresów numerów budynków z podziałem na parzyste i nieparzyste). Do każdego rejonu musi istnieć możliwość przypisania wielu zakresów adresowych. Do każdego rejonu musi istnieć możliwość przypisania jednego gońca. Każda przesyłka w systemie SEOD musi posiadać możliwość przypisania do gońca w sposób ręczny, poprzez wskazanie grupy przesyłek i przypisanie ich do gońca. Każda przesyłka w systemie SEOD musi posiadać możliwość przypisania do gońca automatycznie. W takim wypadku system SEOD musi automatycznie przypisać przesyłki gońcom, o ile adres przesyłki przynależy do zdefiniowanego rejonu i do danego rejonu został przypisany goniec. Dla każdego gońca z wybranego dnia system SEOD musi generować raporty dla doręczanej korespondencji. System SEOD musi umożliwiać oznaczenie korespondencji jako doręczonej przez gońca także po dniu doręczenia. System SEOD musi w rejestrze przesyłek wychodzących umożliwiać szybkie rejestrowanie zwrotów oraz zwrotek, poprzez użycie odpowiedniej funkcji przy wybranym piśmie. System SEOD musi umożliwiać też odszukanie przesyłki za pomocą odczytanego kodu kreskowego umieszczonego na zwrotce. Rejestracja musi skutkować automatycznym pojawieniem się zarejestrowanego zwrotu/zwrotki w teczce sprawy przy właściwym dokumencie lub powiadomieniem o tym fakcie użytkownika prowadzącego sprawę (zależnie od konfiguracji). System musi pozwalać na dodawanie załączników do pism. Załączniki powinny być dodawane w formie plików pobieranych z systemu plików stacji roboczej lub bezpośrednio ze skanera System musi umożliwiać opisanie każdego załącznika nazwą. W przypadku plików pobieranych z systemu plików System musi automatycznie zaproponować nazwę wynikającą z nazwy pliku System musi kontrolować rozmiar i typ dodawanego pliku zgodnie z ustawieniami zdefiniowanymi przez Administratora systemu System musi umożliwiać dodawanie załączników w postaci skanów dokumentów. Obsługa procesu skanowania nie może powodować konieczności uruchamiania żadnych dodatkowych aplikacji. Moduł do skanowania musi być integralną częścią Systemu Moduł do skanowania musi umożliwiać wykonywanie przynajmniej następujących czynności: o Określanie rozdzielczości skanu o Określanie trybu kolorów (kolor, czarno-biały, skala szarości) S t r o n a 32

33 o Określanie typu pliku wynikowego, oraz stopnia kompresji o Określanie typu skanu: jedno/dwustronny System musi obsługiwać skanery z automatycznym podajnikiem oraz automatycznym duplexem. System musi wspomagać skanowanie dwustronne i wielostronicowe przy wykorzystaniu skanerów nie posiadających takich funkcji aby jak najbardziej wspomóc użytkownika System musi pozwalać użytkownikowi na wprowadzanie dowolnych dodatkowych informacji. Rodzaj dodatkowych informacji ich typ oraz wymagalność powinny być definiowane przez Administratora dla dowolnego rodzaju pisma i sprawy System musi obsługiwać rejestrację spraw z wykorzystywaniem Jednolitego Rzeczowego Wykazu Akt zgodnego z Instrukcją Kancelaryjną System musi pozwalać na rejestrację sprawy na podstawie pisma. Ponadto musi pozwalać na dołączanie i odłączanie pism od sprawy System musi automatycznie podpowiadać rodzaj sprawy na podstawie określonego rodzaju pisma oraz udostępniać funkcję automatycznego założenia sprawy na żądanie użytkownika System musi umożliwiać tworzenie spraw z urzędu bez konieczności wskazania pisma wiodącego System musi umożliwiać kopiowanie pism. Każda kopia pisma powinna być oznaczona kolejnym numerem oraz opisem z przyczyną wykonania kopii System musi pozwalać na anulowanie pism do czasu, gdy nie została na jego podstawie założona już sprawa System musi umożliwiać oznaczanie pism swobodnych jako załatwione bez konieczności rejestracji sprawy. Możliwość obsługi pism swobodnych powinna być konfigurowalna z możliwością wyłączenia jej przez Administratora systemu System musi pozwalać na obsługę pism przychodzących z następujących źródeł: o Pisma składane papierowo, o Faksy, o Wnioski elektroniczne, o Wiadomości . System musi automatycznie ustawiać stan sprawy na podstawie akcji wykonywanych przez użytkownika. Dla każdego ze stanów sprawy, S t r o n a 33

34 Administrator może określić dowolną liczbę statusów, które mogą zostać wybrane przez użytkownika. System musi posiadać interfejsy umożliwiające eksport informacji o stanach i statusach spraw do Regionalnej Platformy Komunikacji Elektronicznej (Cyfrowy Urząd). System musi być również wyposażony w możliwość eksportu informacji o stanach i statusach spraw do BIP wdrożonego w ramach projektu Lubuski e-urząd System musi pozwalać na dekretację pism i spraw w oparciu o strukturę organizacyjną. System musi umożliwiać dekretowanie do rozpatrzenia lub przekazywać do wiadomości W trakcie dekretacji system musi umożliwić użytkownikowi dodanie opisu lub wybranie sposobu dekretacji ze zdefiniowanego słownika. W celu uproszczenia pracy System musi podpowiadać osoby, do których były wykonywane ostatnie dekretacje lub umożliwić wybranie z listy zdefiniowanej indywidualnie przez użytkownika System musi pozwalać na dekretację do użytkowników oraz do całych komórek (z możliwością uwzględnienia komórek podrzędnych) Dla każdego pisma i sprawy System musi umożliwiać podgląd historii dekretacji (z zapisami poszczególnych dekretacji oraz związanych z nimi poleceń lub typów) oraz historii dokumentu, zawierającej operacje na nim wykonywane (np. rejestracja pisma, zakończenie sprawy itp.). System musi również odnotowywać każdą zmianę stanu i statusu sprawy oraz ewentualnej zmiany planowanego terminu zakończenia sprawy Dekretacja w systemie SEOD musi umożliwiać nadanie terminów realizacji dla całej sprawy jak i poszczególnych pism poprzez wskazanie terminu realizacji polecenia dekretacyjnego, z możliwością zmiany tych czasów zgodnie z uprawnieniami. System SEOD musi umożliwiać hurtową dekretację czyli dekretację co najmniej dwóch pism jednocześnie z zaznaczeniem stanowisk, komórek, jednostek organizacyjnych, zespołów zadaniowych. System SEOD musi pozwalać na wskazanie, którzy z wybranych adresatów dekretacji, są merytorycznymi a którzy pomocniczymi oraz które stanowiska i komórki otrzymują powiadomienia o piśmie. System musi umożliwiać pracę grupową polegającą na możliwości wglądu do danej sprawy przez wielu użytkowników i dołączania przez nich dowolnych pism. Użytkownik będący inicjatorem pracy w grupie musi mieć możliwość w dowolnym momencie zebrania efektów dotychczasowych prac i odebrania pozostałym użytkownikom dostępu do sprawy Każda zmiana treści pisma przez kolejnych użytkowników powinna powodować utworzenie nowej wersji treści. System musi umożliwiać tworzenie nowych wersji, przeglądanie wersji poprzednich oraz w razie potrzeby oznaczenie dowolnej z wersji treści jako wersji aktualnej System musi umożliwiać udostępnianie pism/spraw do wiadomości innym użytkownikom. Użytkownik musi mieć możliwość żądania potwierdzenia odebrania pisma/sprawy S t r o n a 34

35 System musi umożliwiać użytkownikom dostęp do zawartości teczek, do których mają nadane uprawnienia System musi umożliwiać użytkownikom dostęp do zawartości rejestrów, do których mają nadane uprawnienia. Ponadto użytkownik z odpowiednimi uprawnieniami musi mieć możliwość dodawania pism/spraw do rejestru zgodnie z jego przeznaczeniem Każdy użytkownik w ramach nadanych mu uprawnień musi mieć możliwość wglądu do teczek i rejestrów historycznych poprzez wybór roku, dla którego mają być one wyświetlane System musi udostępniać zestaw raportów niezbędnych do pracy urzędu. Użytkownik musi mieć możliwość określenia podstawowych parametrów raportów (np. okres za jaki raport będzie generowany, sposób sortowania itp.). System musi umożliwiać wygenerowanie co najmniej następujących raportów: o Pocztowa książka nadawcza o Raport dekretacji o Raport z książki doręczeń o Raport pism przychodzących o Raport pism przychodzących przekazanych o Raport pism wychodzących o Raporty przeznaczone dla kierownika (w tym statystyka, sprawy nieodebrane, sprawy przeterminowane, sprawy w toku, sprawy zakończone, pisma nieodebrane i pisma odebrane) o Rejestr zwrotów o Spis spraw System musi umożliwić definiowanie raportów cyklicznych, przesyłanych na zadany adres . System SEOD musi posiadać możliwość generowania raportów na podstawie szablonu raportu, który jest wykonywany przez uprawnionych użytkowników. Szablon raportu systemu SEOD musi umożliwiać definiowanie co najmniej: S t r o n a 35

36 o Nazwy kolumny, o Wartości jakie zawiera każda kolumna, o Zawartości kolumn, po których użytkownik ma możliwość sortowania raportu, o Danych, względem których wyniki w raporcie mają być grupowane, o Określenie warunków/parametrów raportu, które określa użytkownik przed jego uruchomieniem. o Określenie czy wygenerowany raport ma zawierać podsumowanie wartości w kolumnach zawierających liczby. Wartości możliwe do umieszczenia w raporcie muszą obejmować co najmniej: o Nr dokumentu w rejestrze przesyłek wpływających, o Znak sprawy, o Data wpływu/wszczęcia sprawy, o Liczba dni pozostałych na rozpatrzenie sprawy, o Czas rozpatrywania sprawy, o Status sprawy, o Symbol hasła z JRWA, o Opis sprawy, o Dane pracownika prowadzącego sprawę (imię i nazwisko oraz stanowisko), o Rodzaj przesyłki (tj. sposób doręczenia pisma np. list zwykły, polecony, kurier itd.) o Nazwa procesu, o Komórka organizacyjna aktualnie zajmująca się sprawą/dokumentem, o Priorytet nadany sprawie/dokumentowi, o Termin zakończenia sprawy, o Oddzielnie każdy z atrybutów wnioskodawcy (ze słownika interesantów), o Oddzielnie każdy element metryki dokumentu lub sprawy. System SEOD musi posiadać mechanizm wykonywania automatycznego raportów co określony interwał czasu (np. co tydzień, co miesiąc, co S t r o n a 36

37 rok). Wygenerowany raport użytkownik musi mieć możliwość wydrukować i wyeksportować do plików w formatach XLS, DOC, PDF. Użytkownik musi mieć możliwość ukrycia dowolnych kolumn przed wydrukiem bądź dokonaniem eksportu danych. System SEOD musi udostępniać statystyki dotyczące aktywności i sprawności pracy komórek organizacyjnych (wydziałów, referatów) oraz poszczególnych pracowników dotyczące m.in. czasu rozpatrywania spraw, liczby wydawanych dokumentów etc. Statystyki systemu SEOD muszą obejmować swoim zakresem co najmniej: o Czasy załatwiania spraw za dowolny okres czasu dla dowolnie wskazanych procesów i komórek organizacyjnych. o Czasy załatwiania poleceń dekretacji za dowolny okres czasu dla dowolnie wskazanych procesów i komórek organizacyjnych. o Liczby wszczętych, a także załatwionych spraw za dowolny okres czasu dla dowolnie wskazanych JRWA oraz komórek organizacyjnych. o Liczby wszczętych, a także załatwionych spraw za dowolny okres czasu dla dowolnie wskazanych procesów oraz komórek organizacyjnych. o Wątki dekretacji w układzie: kto, na kogo i w jakiej ilości dekretował. o Liczby wydanych dokumentów za dowolny okres czasu dla dowolnych komórek organizacyjnych. o Liczbę przesyłek wychodzących ze względu na formę wysyłki, kwotę oraz wagę wraz z podsumowaniem. o Liczbę przesyłek wychodzących ze względu na formę wysyłki według komórek organizacyjnych. o Przepływ dokumentów pomiędzy użytkownikami/stanowiskami wewnątrz komórki dla dowolnie wybranych par stanowisk/komórek oraz operacji typu: dekretacja, cofnięcie do ponownej dekretacji, przekazaniu do zatwierdzenia, zatwierdzeniu/odrzuceniu dokumentu oraz przekazanie do wiadomości. o Statusy doręczeń korespondencji w sprawie. System SEOD musi posiadać możliwość zaprezentowania statystyk w postaci graficznej. System SEOD musi pozwalać na grupową akceptację wielu dokumentów z różnych spraw, skierowanych przez różnych użytkowników, w tym S t r o n a 37

38 także grupowe podpisywanie dokumentów. System musi zapewnić prowadzenie i wydruk metryki sprawy zgodnie z obowiązującymi przepisami. System musi być wyposażony w mechanizm informowania pracowników i przełożonych o zbliżającym się terminie załatwienia sprawy. Sprawy przeterminowane powinny być specjalnie wyróżniane w Systemie System musi posiadać mechanizm monitorowania spraw prowadzonych w komórkach przez kierowników tych komórek umożliwiający kontrolę terminów realizacji. W razie potrzeby kierownik musi mieć możliwość przejmowania dysponowania nad wybranymi sprawami System musi umożliwiać zmianę terminu zakończenia sprawy przez uprawnionych pracowników System musi umożliwiać wybranie trybu procedowania sprawy na podstawie trybów zdefiniowanych przez Administratora. Wybór trybu musi powodować ustawienie daty przypomnienia o kończącym się terminie obsługi sprawy oraz daty rozpatrzenia sprawy System musi udostępniać mechanizm pracy w zastępstwie za innego użytkownika na podstawie udzielonego wcześniej pełnomocnictwa. Mechanizm ten musi pozwalać na dostęp i obsługę wszystkich dokumentów zastępowanego pracownika System musi posiadać mechanizm inteligentnego wyszukiwania pism i spraw. Wyszukiwanie powinno odbywać się w oparciu o podane wartości atrybutów (również dodatkowych atrybutów zdefiniowanych przez Administratora). System musi umożliwiać wyszukiwanie pełnotekstowe Wyszukiwanie w systemie SEOD musi umożliwiać wykorzystywanie symboli wieloznacznych (w tym typu % oznaczający dowolny ciąg znaków) i łączenia wielu różnych i tych samych kryteriów wyszukiwania za pomocą operatorów AND oraz OR. System musi posiadać możliwość ograniczenia zakresu wyszukiwania do wyszukiwania spośród pism utworzonych na podstawie formularzy elektronicznych pochodzących z Elektronicznej Skrzynki Podawczej (Regionalnej Platformy Komunikacji Elektronicznej (Cyfrowy Urząd)) System musi być wyposażony w definiowanie wyszukiwań do późniejszego wykorzystania przez możliwość zapisania parametrów wyszukiwania pod zdefiniowaną przez użytkownika dowolną nazwą System musi posiadać wbudowane kalendarze. Każdy z użytkowników musi posiadać dostęp do własnego kalendarza z możliwością dodawania do niego dowolnych zdarzeń. Użytkownik musi mieć możliwość określenia typu zdarzenia oraz jego opisu. Użytkownik musi mieć również możliwość definiowania zdarzeń całodniowych oraz cyklicznych. System ma umożliwiać przeglądanie kalendarzy podwładnych i edycję zdarzeń. Kalendarz z terminarzem musi pozwalać co najmniej na: S t r o n a 38

39 o tworzenie przez każdego z użytkowników wielu kalendarzy o dowolnej nazwie, zarówno do własnego użytku jak i współużytkowanych przez innych użytkowników. o nadanie przez właściciela terminarza uprawnień innym użytkownikom lub komórkom organizacyjnym uprawnień do odczytu i/lub zapisu i/lub zatwierdzania zdarzeń niezależnie. o stworzenie widoku kalendarza, stanowiącego sumę zawartości dowolnej liczby dostępnych dla danego użytkownika kalendarzy. o tworzenie własnego słownika kategorii zdarzeń umieszczanych w kalendarzu i oznaczania zdarzeń kolorem lub ikoną graficzną. o umieszczanie w kalendarzach innych użytkowników zdarzeń za ich zgodą (tzn. wymagających potwierdzenia) lub bez niej w zależności od posiadanych uprawnień. o rezerwację dostępnych danemu użytkownikowi zasobów takich jak sale, samochody służbowe, rzutniki multimedialne etc., prowadząc kalendarz rezerwacji zasobu. System SEOD musi umożliwiać dodanie dowolnej liczby zasobów przez użytkowników posiadających stosowne uprawnienie i ich udostępnienie do odczytu jak i zapisu dowolnej liczbie użytkowników i/lub grup. o podczas rezerwowania zasobu jak i użytkowników musi być możliwe sprawdzenie dostępności współuczestników zdarzenia bądź zajętości zasobów. o zapraszanie dowolnej liczby współuczestników i rezerwację dowolnej liczby zasobów jednocześnie do każdego zdarzenia. o wyświetlanie kalendarzy w układzie dziennym, tygodniowym, miesięcznym oraz ciągłym. o dla dowolnego zdarzenia możliwość włączenia przypomnienia na określony przez użytkownika czas przed rozpoczęciem zdarzenia. Przypomnienie musi być prezentowane w postaci wyskakującego okienka pop-up, a użytkownik musi posiadać możliwość odkładania. System musi posiadać funkcje niezbędne do archiwizacji spraw zgodnie z obowiązującymi przepisami prawa w tym zakresie. System musi posiadać dodatkowy zintegrowany moduł archiwum zakładowego. System musi wspierać użytkownika w przygotowywaniu spisów zdawczoodbiorczych. Sprawy przekazane do archiwum powinny być usuwane z bazy danych ESOD, natomiast System musi nadal umożliwiać wgląd do metryczek tych spraw (zawierających przynajmniej znak, daty obowiązywania i ostatniego dysponenta sprawy) System musi umożliwiać wypożyczanie spraw z archiwum, podgląd informacji o sprawie oraz zmianę kategorii archiwalnej sprawy przechowywanej w archiwum System musi obsługiwać brakowanie spraw zgodnie z ich kategorią archiwalną System musi wspomagać użytkownika w przygotowywaniu paczki archiwalnej dla Archiwum Państwowego poprzez przygotowywanie S t r o n a 39

40 automatycznych spisów zdawczo-odbiorczych, wykazu akt, oraz zapisanie spraw w strukturze wymaganej przez Archiwum Państwowe. Po skutecznym przekazaniu spraw do Archiwum Państwowego System musi automatycznie usunąć dane spraw na podstawie potwierdzenia z Archiwum Państwowego System musi umożliwiać konfigurację indywidualnego widoku pism / spraw dla danego użytkownika poprzez możliwość dodawania/ukrywania widoczności atrybutów pism/spraw oraz ustalenia kolejności sortowania danych. Użytkownik musi mieć możliwość zapisania konfiguracji. Użytkownik w każdej chwili musi mieć możliwość przywrócenia wartości domyślnych System musi umożliwiać filtrowanie widoków pism/spraw na podstawie określonych przez użytkownika wartości. Dodatkowo musi umożliwiać eksport dowolnego widoku pism / spraw do pliku w formacie arkusza kalkulacyjnego System musi posiadać możliwość składania podpisów elektronicznych pod wygenerowanymi dokumentami oraz możliwość weryfikacji podpisanych dokumentów. System musi obsługiwać formaty podpisu elektronicznego zgodnie z polskim prawodawstwem System musi posiadać pełną obsługę metadanych zgodnie z przepisami prawa w tym zakresie. Metadane powinny być generowane w sposób automatyczny tak, aby proces obsługi metadanych był jak najbardziej wygodny dla użytkownika. Metadane powinny być przypisane co najmniej dla pism, spraw oraz załączników System musi być wyposażony w centralną bazę danych korespondentów, pozwalającą na przechowywanie historycznych danych teleadresowych korespondenta w każdej sprawie System musi mieć funkcjonalność pozwalającą na sprawdzenie zduplikowanych wpisów w bazie danych korespondentów oraz umożliwiającą połączenie tych wpisów w jeden System musi umożliwiać wyświetlenie listy jednostek posiadających konta w Systemie Regionalna Platforma Komunikacji Elektronicznej (Cyfrowy Urząd) oraz wysłanie do nich dokumentów elektronicznych bez konieczności wcześniejszego wprowadzania ich danych do bazy danych korespondentów Ze względu na ergonomię interfejs użytkownika musi posiadać menu kontekstowe umożliwiające szybkie uruchomienie najczęściej wykorzystanych funkcji. System musi dostosowywać zawartość menu kontekstowego w zależności od typu obiektu i etapu procedowania Wymagania funkcjonalne w zakresie obsługi kodów kresowych S t r o n a 40

41 System musi umożliwiać wygenerowanie kodu kreskowego dla każdego pisma przychodzącego System musi umożliwiać wydruk kodu kreskowego, w celu umieszczenia go na oryginale dokumentu System musi umożliwiać wyszukiwanie pism na podstawie odczytanego kodu kreskowego (wygenerowanego przez System) System musi generować kody kreskowe w standardzie Code 128 System musi obsługiwać czytniki kodów kreskowych, które nie są przedmiotem niniejszego zamówienia System musi obsługiwać drukarki etykiet kodów kreskowych, które nie są przedmiotem niniejszego zamówienia Wymagania funkcjonalne w zakresie integracji z Regionalną Platformą Komunikacji Elektronicznej (Cyfrowy Urząd) Zakres prac wdrożeniowych związanych z integracją Wykonanie prac wdrożeniowych polegających na integracji Systemu Elektronicznego Obiegu Dokumentów z podsystemem komunikacji Regionalnej Platformy Komunikacji Elektronicznej - Cyfrowy Urząd (dokumentacja techniczna interfejsu komunikacyjnego CU - Załącznik nr 8 do SIWZ) zrealizowanej w ramach projektu Lubuski e-urząd (Załącznik nr 9 do SIWZ), mającej na celu umożliwienie komunikacji elektronicznej wszystkich JST uczestniczących w Projekcie Lubuski e-urząd za pomocą Systemów Elektronicznego Obiegu Dokumentów. W komunikacji tej pośredniczyć będzie system Elektronicznej Skrzynki Podawczej uruchomiony w ramach Projektu Lubuski e Urząd. Realizacja Przedmiotu zamówienia ma zapewnić co najmniej: Możliwość pobierania do systemu SEOD wniosków elektronicznych złożonych przez Interesanta do Partnera Projektu za pośrednictwem Elektronicznej Skrzynki Podawczej (ESP), Przekazywanie do systemu Elektronicznej Skrzynki Podawczej (ESP) informacji i stanów / statusów spraw powstałych na podstawie pobranych wniosków elektronicznych, Możliwość wysyłania pism urzędowych (decyzji, odpowiedzi) z systemu SEOD na konto Interesanta w systemie Elektronicznej Skrzynki Podawczej (ESP) jako odpowiedź w sprawie, Możliwość przesyłania dokumentów w formie elektronicznej do innego Partnera Projektu (JST uczestniczące w Projekcie Lubuski e-urząd ) za S t r o n a 41

42 pośrednictwem systemu Elektronicznej Skrzynki Podawczej (ESP) z poziomu systemu SEOD, Możliwość jednoczesnego przesyłania dokumentów w formie elektronicznej do kilku Partnerów Projektu za pośrednictwem systemu Elektronicznej Skrzynki Podawczej (ESP) z poziomu systemu SEOD. Wszystkie powyższe scenariusze dotyczą obiektów (Zamawiającego, Partnerów Projektu i Interesantów) posiadających aktywne konta w systemie Regionalnej Platformy Komunikacji Elektronicznej - Cyfrowy Urząd. Przedmiotem zamówienia jest również uruchomienie u każdego Partnera Projektu integracji SEOD z Platformą Komunikacji Elektronicznej (Cyfrowy Urząd). Wymagania w zakresie Oprogramowania Narzędziowego Serwer bazy danych ma umożliwiać na tworzenie baz danych o rozmiarze co najmniej 10 GB 2 Ilość Wykonawca zobowiązany jest udzielić Zamawiającemu nie wyłącznej Licencji na korzystanie z Oprogramowania aplikacyjnego oraz niezbędnego do jego działania Oprogramowania Narzędziowego. Licencja musi być udzielona na czas nieokreślony dla 18 Partnerów Projektu (JST) wskazanych w punkcie 4 niniejszej karty produktu dla nieograniczonej liczby użytkowników końcowych. 3 Prace wdrożeniowe Wykonawca przeprowadzi prace wdrożeniowe w podziale na cztery etapy: Analiza przedwdrożeniowa, Instalacja, dostawa licencji Oprogramowania oraz Oprogramowania Narzędziowego, Konfiguracja oraz parametryzacja Systemu Szkolenia, Odbiory. I etap: Analiza przedwdrożeniowa - będzie obejmować: Przygotowanie przez Wykonawcę opisu danych konfiguracyjnych, które powinny zostać przygotowane przez Partnerów (np. dane adresowe, S t r o n a 42

43 NIP itp.) Przesłanie do Partnerów arkuszy konfiguracyjnych w celu pozyskania danych wraz z instrukcją wypełniania arkuszy opracowanie przez Wykonawcę 20 definicji procesów (procedur WorkFlow) wspomaganych przez System Elektronicznego Obiegu Dokumentów dla Partnerów. Wykaz procedur został umieszczony w Załączniku nr 10 do SIWZ Wyspecyfikowanie oraz opracowanie przez Wykonawcę 20 formularzy na CU (opublikowanych na epuap), Wykaz formularzy został umieszczony w Załączniku nr 10 do SIWZ. Przygotowanie oraz przedstawienie do akceptacji Zamawiającego szczegółowego harmonogramu szkoleń oraz wdrożenia Systemu Elektronicznego Obiegu Dokumentów u Partnerów Wykonawca zobowiązany jest do zaproponowania scenariuszy testowych wdrażanego Systemu. Zaakceptowane przez Zamawiającego scenariusze będą podstawą do przeprowadzenia odbiorów. Partnerzy przekażą dane konfiguracyjne w przygotowanych przez Wykonawcę arkuszach konfiguracyjnych w terminie 20 Dni od daty ich otrzymania od Wykonawcy. II etap: Instalacja, dostawa licencji Oprogramowania oraz Oprogramowania Narzędziowego, Konfiguracja oraz parametryzacja Systemu - będzie obejmować: Instalację Oprogramowania oraz Oprogramowania Narzędziowego na serwerach będących przedmiotem niniejszego zamówienia lub wskazanych przez Partnera Wprowadzenie 20 procesów (procedur WorkFlow) obsługiwanych przez System Elektronicznego Obiegu Dokumentów Wprowadzenie dla każdego z Partnerów wybranych przez niego 10 procedur Wprowadzenie danych konfiguracyjnych dla Partnera Wprowadzenie danych konfiguracyjnych dla Użytkowników Końcowych Wprowadzenie danych konfiguracyjnych niezbędnych do połączenia Systemu Elektronicznego Obiegu Dokumentów z Regionalną Platformą Komunikacji Elektronicznej Wykonawca zobowiązany jest do przeprowadzenia testów akceptacyjnych w siedzibie każdego z Partnerów Projektu. Niedopuszczalne jest S t r o n a 43

44 zdalne przeprowadzenie testów. W testach musi uczestniczyć pracownik Wykonawcy oraz przedstawiciel Partnera Projektu. III etap: Szkolenia obejmować będą: Szkolenia administratorów: o Liczba osób: 20 (po 1 osobie od każdego z Partnerów Projektu (JST) uczestniczących w realizacji zadania oraz 2 osoby ze strony Zamawiającego)) o Czas trwania szkolenia: 18 godzin dydaktycznych o Forma szkolenia: wykłady oraz warsztaty praktyczne o Oczekiwany efekt: pozyskanie wiedzy teoretycznej oraz praktycznej pozwalającej na samodzielne administrowanie Systemem Elektronicznego Obiegu Dokumentów w zakresie obsługi wdrażanych procedur administracyjnych o Miejsce szkolenia: zgodnie z Załącznikiem nr 3 do SIWZ Szkolenia użytkowników merytorycznych: o Liczba osób: 627 (od każdego z Partnera wydelegowana liczba osób zgodnie z wykazem zamieszczonym w punkcie 4 niniejszej karty produkty pomniejszona o 1 (Administrator)) o Czas trwania szkolenia: 12 godzin dydaktycznych o Forma szkolenia: wykłady oraz warsztaty praktyczne o Oczekiwany efekt: pozyskanie wiedzy teoretycznej i praktycznej pozwalającej na samodzielną obsługę Systemu Elektronicznego Obiegu Dokumentów w zakresie obsługi wdrażanych procedur administracyjnych. o Miejsce szkolenia: zgodnie z Załącznikiem nr 3 do SIWZ Szkolenia stanowiskowe: o Liczba grup: 18 o Czas trwania szkolenia: 8 godzin dydaktycznych o Forma szkolenia: warsztaty praktyczne o Oczekiwany efekt: pozyskanie praktycznych umiejętności użytkowania Systemu S t r o n a 44

45 o Miejsce szkolenia: siedziba Partnera Projektu Szkolenia muszą być przeprowadzone na zasadach określonych w Załączniku nr 3 do SIWZ. IV etap: Odbiory obejmować będą: 4 Specyficzne warunki dostaw / prac wdrożeniowych sprawdzenie przez Zamawiającego poprawności wprowadzonych danych instalacyjnych i konfiguracyjnych sprawdzenie przez Zamawiającego poprawności definicji procedur oraz ich prawidłowości działania w odniesieniu do treści zatwierdzonej Analizy Przedwdrożeniowej sprawdzenie przez Zamawiającego zainstalowanego Systemu Elektronicznego Obiegu Dokumentów pod względem jego zgodności z wymaganiami SIWZ oraz jego poprawności działania, w tym sprawdzenie poprawności połączenia Systemu Elektronicznego Obiegu Dokumentów z Regionalną Platformą Komunikacji Elektronicznej w zakresie przyjmowania i wysyłania dokumentów oraz wysyłania dokumentów do innego podmiotu sprawdzenie przez Zamawiającego (zgodnie z zaakceptowanymi scenariuszami testowymi) zainstalowanego Systemu u trzech wybranych Partnerów Projektu pod względem jego zgodności z wymaganiami SIWZ oraz jego poprawności działania, w tym sprawdzenie poprawności połączenia Systemu Elektronicznego Obiegu Dokumentów z Regionalną platformą komunikacji elektronicznej w zakresie przyjmowania i wysyłania dokumentów oraz wysyłania dokumentów do innego Partnera sprawdzenie przez Partnerów Projektu poprawności wprowadzonych danych konfiguracyjnych dla Partnera i Użytkowników końcowych oraz prawidłowości działania wprowadzonych procedur Zamawiający wymaga wdrożenia Systemu Elektronicznego Obiegu Dokumentów w następujących terminach: Etap Etap wdrożenia Termin Uwagi 1. Analiza Przedwdrożeniowa 2 miesiące od daty podpisania Umowy 2. Instalacja, dostawa licencji Oprogramowania oraz Oprogramowania Narzędziowego, Konfiguracja oraz 3 miesiące od daty podpisania Umowy S t r o n a 45

46 parametryzacja 3. Szkolenia 4 miesiące od daty podpisania Umowy 4. Odbiory 4 miesiące od daty podpisania Umowy Przed przystąpieniem do przeprowadzenia szkoleń Wykonawca zobowiązany jest do: przygotowania i przekazania: o Dokumentacji Technicznej, o Dokumentacji Wdrożeniowej, o Dokumentacji Szkoleniowej. przygotowania i przekazania Dokumentacji Użytkowej dla: o administratorów, o użytkowników merytorycznych. Dokumentacja powinna być dostarczona Zamawiającemu w formie elektronicznej oraz 1 egzemplarzu w wersji papierowej. Zamawiający wymaga przeprowadzenia wdrożenia Systemu Elektronicznego Obiegu Dokumentów u następujących Partnerów Projektu: Lp. Beneficjent Ilość użytkowników podlegających wdrożeniu Specyficzne warunki dostaw / prac wdrożeniowych 1. Powiat Nowosolski 100 Instalacja na serwerze wskazanym przez Partnera: Serwer typ B 2. Gmina Bobrowice 18 Instalacja na serwerze wskazanym przez S t r o n a 46

47 3. Gmina Bytnica Gmina Kolsko Gmina wiejska Nowa Sól Gmina Otyń Gmina Siedlisko Gmina Szczaniec Gmina Zwierzyn Gmina Czerwieńsk Gmina Drezdenko Gmina Nowe Miasteczko Gmina Witnica Gmina Kostrzyn nad Odrą Gmina Krosno Odrzańskie Gmina Babimost 27 Partnera: Serwer typ A Instalacja na serwerze wskazanym przez Partnera: Serwer typ A Instalacja na serwerze wskazanym przez Partnera: Serwer typ A Instalacja na serwerze wskazanym przez Partnera: Serwer typ A Instalacja na serwerze wskazanym przez Partnera: Serwer typ A Instalacja na serwerze wskazanym przez Partnera: Serwer typ A Instalacja na serwerze wskazanym przez Partnera: Serwer typ A Instalacja na serwerze wskazanym przez Partnera: Serwer typ B Instalacja na serwerze wskazanym przez Partnera: Serwer typ A Instalacja na serwerze wskazanym przez Partnera: Serwer typ A Instalacja na serwerze wskazanym przez Partnera: Serwer typ B Instalacja na serwerze wskazanym przez Partnera: Serwer typ A S t r o n a 47

48 17. Gmina Dobiegniew Gmina Nowogród Bobrzański 29 Instalacja na serwerze wskazanym przez Partnera: Serwer typ A Instalacja na serwerze wskazanym przez Partnera: Serwer typ A Specyfikacja serwerów: Fujitsu Primergy TX200S6, System opreacyjny MS Windows Server 2008 R2 Serwer typ A: Intel XEON E5645 2,4 GHz 12 MB, 3x4GB DDR3, 4x HD SAS 6G 300 GB Serwer typ B: 2 x Intel XEON E5645 2,4 GHz 12 MB, 2x 3x4GB DDR3, 4x HD SAS 6G 300 GB, 2x HD SAS 6G 450GB 5 Warunki serwisu gwarancyjnego Wykonawca jest zobowiązany do udostępnienia oraz utrzymywania wersji testowej SEOD przez 5 lat. System może być zainstalowany na serwerach Wykonawcy lub Zamawiającego. Wersja testowa SEOD musi być zgodna z wersją produkcyjną zainstalowaną u Partnerów Projektu. Serwis gwarancyjny Wykonawca udzieli gwarancji na dostarczone Oprogramowanie na okres 60 miesięcy licząc od daty odbioru Systemu zapewniając jednocześnie serwis gwarancyjny. Wszelkie koszty gwarancji wraz z serwisem gwarancyjnym są w pełni włączone do ceny ofertowej. Koszt udzielania gwarancji wliczony jest do wynagrodzenia jakie otrzyma Wykonawca za realizację umowy. W okresie gwarancji wszelkie koszty usuwania wad i awarii oraz zmian ponoszone przez Wykonawcę, których przyczyna leży po jego stronie ponosi Wykonawca. Wsparcie użytkowników Help Desk W okresie trwania gwarancji Wykonawca zapewnieni usługę Help Desk. Asysta techniczna Wykonawca zobowiązany jest świadczyć bezpłatną asystę techniczną do momentu wykorzystania przysługującej Zamawiającemu puli godzin asysty technicznej.. Okres i zakres asysty technicznej rozpoczyna się z dniem podpisania protokołu zakończenia wdrożenia Systemu. Świadczenie serwisu gwarancyjnego, wsparcia użytkowników Help Desk oraz Asysty technicznej ma być realizowane na zasadach określonych w S t r o n a 48

49 6 Etapy realizacji dostaw oraz prac wdrożeniowych podlegające formalnym odbiorom 7 Wymagania odnośnie treści oferty Załączniku nr 4 do SIWZ. Formalnemu odbiorowi podlegają następujące etapy prac wdrożeniowych: o Analiza przedwdrożeniowa, o Instalacja, dostawa licencji Oprogramowania oraz Oprogramowania Narzędziowego, Konfiguracja oraz parametryzacja Systemu o Szkolenia, o Wdrożenie Systemu (odbiór końcowy realizacji zadania). Odbiory prac wdrożeniowych odbywają się zgodnie z procedurą określoną w Załączniku nr 2 do SIWZ, Podpisany przez Zamawiającego Protokół Odbioru Zadania potwierdzający zrealizowanie bez uwag wszystkich prac wdrożeniowych etapu stanowi podstawę płatności: o Analiza przedwdrożeniowa 10% wartości wynagrodzenia za prace wdrożeniowe Zadania, o Instalacja, dostawa licencji Oprogramowania oraz Oprogramowania Narzędziowego, Konfiguracja oraz parametryzacja Systemu 20% wartości wynagrodzenia za prace wdrożeniowe Zadania, o Szkolenia 20% wartości wynagrodzenia za prace wdrożeniowe Zadania, o Wdrożenie Systemu (odbiór końcowy realizacji zadania) 50% wartości wynagrodzenia za prace wdrożeniowe zadania. Na potwierdzenie, że oferowany System Elektronicznego Obiegu Dokumentów spełnia wymagania określone przez Zamawiającego Wykonawca zobowiązany jest dołączyć do oferty następujące dokumenty: Wykonawca zobowiązany jest do wskazania producenta oraz nazwy oraz wersji oferowanego Oprogramowania oraz Oprogramowania Narzędziowego oraz sposobu jego licencjonowania wraz ze wszystkimi niezbędnymi komponentami dla spełnienia oczekiwanych wymagań (wg Załącznik nr 12 do SIWZ). S t r o n a 49

50 Zadanie nr 2: Serwer Lp. Zawartość karty Opis 1 Specyfikacja techniczna / Zakres przedmiotu zamówienia obejmuje dostawę, montaż wraz z uruchomieniem Serwerów na warunkach określonych funkcjonalna przedmiotu zamówienia w niniejszej Karcie produktu oraz na warunkach określonych w Specyfikacji Istotnych Warunków Zamówienia. Serwer musi spełniać następujące wymagania minimalne: Obudowa o do instalacji w serwerowej szafie RACK 19 lub typu wieża z możliwością instalacji szafie RACK 19 w zależności od informacji zawartych w punkcie 4 Specyficzne warunki dostaw / prac wdrożeniowych; o wysokość nie więcej niż 5U po zamontowaniu w szafie RACK; o możliwość instalacji minimum 6 dysków twardych hot-plug i hot-swap w dostarczonej konfiguracji bez konieczności rozbudowy lub wymiany jakichkolwiek komponentów; o obudowa zaprojektowana na potrzeby oferowanego modelu serwera. Płyta główna o dedykowana płyta serwerowa; o dwa gniazda procesora, wsparcie dla procesorów wielordzeniowych; o minimum 12 banków pamięci obsługujące minimum 96GB pamięci typu registered o minimum 5 złącz PCI Express o prędkości minimum x4; o minimum 1 złącze PCI 32bit; o zaprojektowana i wyprodukowana przez producenta serwera; o zainstalowany układ szyfrowania zgodny z TPM 1.2 (konfigurowalny z pozycji BIOS). BIOS o możliwość zabezpieczenia hasłem dostępu do Systemu operacyjnego i dostępu do BIOS serwerazabezpieczenia te muszą działać niezależnie od siebie; o możliwość odczytania z BIOS serwera informacji o numerze seryjnym, numerze inwentaryzacyjnym (asset tag), możliwość odczytania z BIOS dokładnych informacji o procesorach (model, typ, częstotliwości FSB, prędkości rzeczywista, ilość pamięci cache); o możliwość wyłączenia pracy wielordzeniowej procesora z pozycji BIOS. Procesory S t r o n a 50

51 o zainstalowany co najmniej jeden wielordzeniowy procesor serwerowy, o maksymalny pobór mocy dla procesora 95 W; o procesory osiągające w zaoferowanym modelu serwera wynik minimum 302 punktów w teście SPECint_rate2006 w kolumnie Results Peak (Zamawiający wskazuje adres publikacji testów który został wykorzystany przez Zamawiającego do określenia wymogów minimalnych dla procesora. W przypadku zmiany adresu publikacji testów Zamawiający akceptuje wynik testu SPECint_rate2006 zaproponowanego procesora znajdującego się pod innym adresem w ramach strony o Zamawiający wymaga zaproponowania procesora, dla którego istnieje wynik w ramach testu SPECint_rate2006 na stronie o Zamawiający wymaga dostarczenia do oferty wydruku rezultatu testu SPECint_rate2006 zaproponowanego procesora potwierdzającego spełnienie powyższego warunku. Pamięć RAM o 16 GB RAM (w konfiguracji 2 x 8GB); o wsparcie dla technologii korekcji błędów Advanced ECC, scrubbing i Chipkill; o wsparcie sprzętowe kontrolera pamięci dla zapisu lustrzanego pamięci. Kontroler macierzowy o kontroler dysków typu SAS 2.0, minimum 8 portów z obsługą RAID 0,1,10,5,50,6,60 z pamięcią cache minimum 512MB oraz podtrzymaniem bateryjnym pamięci cache. Dyski twarde o 2 dyski SATA o pojemności min. 1TB, 7200 obr./min., hot-plug, hot-swap; o 2 dyski SAS o pojemności min. 300 GB, obr./min., hot-plug, hot-swap. Napędy zintegrowane o zintegrowana nagrywarka DVD +/- RW (obsługa DVD+R, DVD-R, DVD DL) wraz z oprogramowaniem do nagrywania płyt DVD dla zaoferowanego Systemu operacyjnego; o zintegrowany napęd LTO5, SAS 160GB pojemności natywnej, transfer min. 120MB/s wraz z odpowiednim kontrolerem wraz z oprogramowaniem do wykonywania kopii bezpieczeństwa; o 1 kartridż czyszczący do napędu LTO, 7 kartridży typu LTO5 (możliwość zapisania min. 160GB skompresowanych danych). S t r o n a 51

52 Interfejsy sieciowe o zintegrowana trwale karta sieciowa 1Gbit/s dla komunikacji Systemowej (RJ-45), wymagane wsparcie dla PXE, iscsi, Teamingu; o zintegrowana trwale karta sieciowa 10/100Mbit, RJ-45 dedykowana dla kontrolera zdalnego zarządzania, z możliwością przekierowania komunikacji kontrolera zarządzania na kartę 1Gbit. Interfejsy zintegrowane o 1 x RS-232-C (9 pin); o min.7 portów USB 2.0 (w tym min. 2 na panelu przednim, min. 1 wewnętrzny, min. 4 z tyłu); o możliwość zainstalowania wewnętrznego klucza USB (pamięci flash). Interfejsy kontrolne i serwisowe o zintegrowany w obudowie na przednim panelu wyświetlacz ciekłokrystaliczny lub inne rozwiązanie równoważne oferujące możliwość bezpośredniej weryfikacji/identyfikacji (bez dostępu do wnętrzna obudowy oraz software zarządzającego), co najmniej: model i numer seryjny serwera; MAC address karty LAN i karty zarządzającej LAN; identyfikacja usterki magistrali PCI/karty PCI; identyfikacja usterki wentylatorów; identyfikacja usterki HDD; identyfikacja usterki podtrzymania pamięci cache kontrolera; identyfikacja usterki zasilacza; identyfikacja usterki pamięci RAM; identyfikacja usterki CPU; identyfikacja zbyt wysokiej temperatury wewnątrz obudowy; o wbudowana dioda identyfikacyjna przód/tył (możliwość zdalnego włączenia identyfikacji wizualnej serwera poprzez software zarządzający) Zarządzanie zdalne o zintegrowany trwale z płytą główną kontroler zdalnego zarządzania zgodny ze standardem IPMI 2.0 umożliwiający zdalne uruchomienie, wyłączenie i restart serwera; o pełne zarządzanie sprzętowe: monitorowanie pracy kluczowych układów, wentylatorów, zasilaczy, S t r o n a 52

53 napędów, temperatur, itp., logowanie błędów w zakresie ustalonym przez administratora; o dostęp do interfejsu karty zarządzającej za pomocą przeglądarki MS Internet Explorer lub Mozilla Firefox bez konieczności instalowania jakiegokolwiek software specyficznego dla producenta sprzętu; o funkcja przekierowania konsoli graficznej (minimum 2 niezależne połączenia) i mapowania napędów zdalnych, bądź ich obrazów (CD, DVD, FDD, klucz USB); o połączenie z kartą zarządzającą musi być szyfrowane minimum 128-bitowym kluczem SSL; o monitorowanie zużycia energii serwera w trybie dziennym, miesięcznym, rocznym oraz wizualizacja raportów w postaci wykresów graficznych, kontrola zużycia energii w trybie rzeczywistym; o funkcja konfiguracji i ograniczania zużycia energii elektrycznej przez serwer bezpośrednio z pozycji konsoli graficznej karty sprzętowej (tryby minimalnego zużycia energii, pełnej wydajności); o funkcja umożliwiająca konfigurację i automatyczne przełączanie się pomiędzy trybami zużycia energii w czasie, w ciągu tygodnia z dokładnością do godzin (wymagane z uwagi na różne obciążenie maszyny w czasie); o wsparcie dla integracji z Active Directory i LDAP; o wsparcie dla aktualizacji firmware karty zarządzającej online, bez konieczności restartu serwera; o dostarczone wraz z serwerem Oprogramowanie zarządzające i diagnostyczne wyprodukowane i wspierane przez producenta serwera umożliwiające m.in.: konfigurację kontrolera RAID bez konieczności konfiguracji bezpośrednio w BIOS kontrolera; instalację Systemów operacyjnych wspieranych przez producenta serwera (z nośników fizycznych lub zdalnie przez sieć LAN) wraz ze sterownikami; wykrywanie usterek z wyprzedzeniem monitorowanie i zarządzanie kontrolerami RAID i zainstalowanymi dyskami twardymi Karta graficzna o zintegrowana karta graficzna; o złącze VGA dostępne z tyłu obudowy; o obsługa rozdzielczości minimum 1600x1200. Bezpieczeństwo o zintegrowany czujnik otwarcia obudowy umożliwiający rozsyłanie za pomocą protokołu SNMP komunikatów o otwarciu obudowy; o obudowa musi posiadać zintegrowany, fabryczny zamek obudowy, który blokuje dostęp do klatek S t r o n a 53

54 dysków twardych, napędów optycznych i taśmowych i do wnętrza obudowy serwera (nie dopuszcza się kłódek lub zabezpieczeń wystających poza obrys obudowy z jakiejkolwiek strony). Zasilanie i chłodzenie o dwa, redundantne zasilacze o mocy maksymalnej 920 W każdy, typu hot-plug o sprawności minimalnej 90% przy typowym obciążeniu 50%; o redundantne wentylatory chłodzące wnętrze obudowy. Wymienne w trybie hot-plug; o dostarczone dwa przewody zasilające z wtyczką używaną w Polsce, min. 1,8m. System operacyjny o System musi wykorzystywać co najmniej 2 fizyczne procesory x64 oraz co najmniej 32 GB pamięci RAM o System musi automatycznie weryfikować cyfrowe sygnatury sterowników w celu sprawdzenia, czy sterownik przeszedł testy jakości przeprowadzone przez producenta Systemu o System musi mieć możliwość dynamicznego obniżania poboru energii przez rdzenie procesorów nie wykorzystywane w bieżącej pracy. Mechanizm ten musi uwzględniać specyfikę procesorów wyposażonych w mechanizmy HyperTherading. o System musi umożliwiać instalację i pracę na wolumenach które: pozwalają na zmianę rozmiaru w czasie pracy Systemu, umożliwiają tworzenie w czasie pracy Systemu migawek, dających użytkownikom końcowym (lokalnym i sieciowym) prosty wgląd w poprzednie wersje plików i folderów, umożliwiają kompresję "w locie" dla wybranych plików i/lub folderów, umożliwiają zdefiniowanie list kontroli dostępu (ACL). o System musi być wyposażony w mechanizmy klasyfikowania i indeksowania plików (dokumentów) w oparciu o ich zawartość. o System musi umożliwiać szyfrowanie dysków przy pomocy mechanizmów posiadających certyfikat FIPS lub równoważny wydany przez NIST lub inną agendę rządową zajmującą się bezpieczeństwem informacji. o System musi umożliwiać uruchamianie aplikacji internetowych wykorzystujących technologię ASP.NET o System musi umożliwiać dystrybucję ruchu sieciowego HTTP pomiędzy kilka serwerów. o System musi umożliwiać wirtualizację Systemową (pozwalać na tworzenie maszyn wirtualnych z innym, zgodnym z platformą sprzętową Systemem operacyjnym). o System musi umożliwiać instalację sieciową, w której obraz Systemu przesyłany jest przy pomocy S t r o n a 54

55 transmisji multicast. o System musi umożliwiać automatyczną aktualizację w oparciu o poprawki publikowane przez producenta. o System musi umożliwiać instalację poprawek poprzez wgranie ich do obrazu instalacyjnego. o System musi udostępniać mechanizmy zdalnej administracji oraz mechanizmy (również działające zdalnie) administracji przez skrypty. o System musi umożliwiać zarządzanie przez wbudowane mechanizmy zgodne ze standardami WBEM oraz WS-Management organizacji DMTF. o System musi obsługiwać protokoły: TCP/IP, IPv6, IPSec. o System musi być wyposażony w: usługi sieciowe DHCP oraz DNS wspierający DNSSEC, usługi katalogowe oparte o LDAP i pozwalające na uwierzytelnianie użytkowników stacji roboczych Windows XP i nowszych, bez konieczności instalowania dodatkowego Oprogramowania na tych stacjach, usługi pozwalające na dystrybucję Oprogramowania na stacje z Systemami Windows XP i nowszymi, bez konieczności instalowania dodatkowego Oprogramowania na stacjach, usługi pracy zdalnej pozwalające na udostępnienie całych pulpitów i/lub pojedynczych aplikacji, usługi centrum certyfikacji PKI. o System musi umożliwiać zmianę języka interfejsu i posiadać co najmniej polską i angielską wersję językową. o System musi być objęty polskojęzycznym, autoryzowanym przez producenta cyklem szkoleń i zestawem materiałów szkoleniowych. o System musi mieć polskojęzyczne wsparcie producenta sprzętu. o Zaoferowane Licencje muszą spełniać warunki opisane w pkt. IX Licencjonowanie Oprogramowania Niezawodność / jakość wytwarzania o do oferty należy załączyć dokumenty potwierdzające, że oferowany sprzęt jest produkowany zgodnie z normami ISO 9001 oraz ISO S t r o n a 55

56 Inne o dostarczona fabrycznie w zestawie mysz i klawiatura Qwerty w układzie US (objęte fabryczną gwarancją producenta serwera) o elementy, z których zbudowane są serwery muszą być produktami producenta tych serwerów lub być przez niego certyfikowane oraz muszą być objęte gwarancją producenta, potwierdzoną przez oryginalne karty gwarancyjne. Wykonawca zobowiązany jest dołączyć do oferty oświadczenie Wykonawcy lub producenta oferowanego serwera. 2 Ilość 3 sztuki 3 Prace wdrożeniowe Do czynności Wykonawcy w ramach montażu i uruchomienia Serwera należy: Ustalenie z Partnerem projektu terminu przeprowadzenia prac Rozpakowanie urządzenia, sprawdzenie, czy nie wystąpiły uszkodzenia Sprawdzenie warunków wymaganych do pracy urządzenia (temperatura, zasilanie, dostępne miejsce) Instalacja serwera zgodnie ze specyfikacjami produktu Oznakowanie sprzętu naklejką Zebranie wszystkich opakowań i oddanie ich do dyspozycji Partnera Projektu Fizyczne podłączenie urządzenia do sieci energetycznej oraz komputerowej Instalacja zaoferowanego Systemu operacyjnego Konfiguracja serwera do pracy w sieci komputerowej Dobór i optymalizacja ustawień wydajnościowych wg wymagań Partnera Skonfigurowanie serwera do wysyłania zgłoszeń serwisowych do Automatycznego System zgłoszeń serwisowych oraz monitorowania infrastruktury teleinformatycznej Sporządzenie raportu z przeprowadzonych prac 4 Specyficzne warunki dostaw / prac wdrożeniowych Miejsca dostawy, montażu i uruchomienia: Lp. Beneficjent Ilość Specyficzne warunki dostaw / prac wdrożeniowych S t r o n a 56

57 1. Gmina Siedlisko 1 Obudowa typ Tower 2. Gmina Kolsko 1 Montaż w szafie rack (wymagane dostarczenie zestawu do montażu umożliwiającego pełne wysunięcie serwera z szafy rack wraz z ramieniem do prowadzenia kabli) 3. Gmina Witnica 1 Montaż w szafie rack (wymagane dostarczenie zestawu do montażu umożliwiającego pełne wysunięcie serwera z szafy rack wraz z ramieniem do prowadzenia kabli) 5 Warunki serwisu gwarancyjnego Gwarancja: 60 miesięcy gwarancji producenta serwera realizowanej w miejscu instalacji sprzętu z gwarancją naprawy w trzecim dniu roboczym od momentu zgłoszenia Serwis urządzeń musi być realizowany przez producenta lub autoryzowanego partnera serwisowego producenta wymagane oświadczenie Wykonawcy potwierdzające, że serwis będzie realizowany przez Producenta lub autoryzowanego partnera serwisowego producenta (należy dołączyć do oferty) Serwis urządzeń musi być realizowany zgodnie z wymaganiami normy ISO 9001 do oferty należy dołączyć dokument potwierdzający, że serwis urządzeń będzie realizowany zgodnie z tą normą. Dostarczany sprzęt musi być fabrycznie nowy (niewyprodukowany wcześniej niż 6 miesięcy przed datą dostawy) i pochodzić z oficjalnego kanału dystrybucyjnego producenta. Wykonawca zobowiązany jest dołączyć do oferty oświadczenie, że oferowany do przetargu sprzęt spełnia ten wymóg. Możliwość automatycznej aktualizacji i pobrania sterowników do oferowanego modelu sprzętu w najnowszych S t r o n a 57

58 certyfikowanych wersjach bezpośrednio z sieci Internet za pośrednictwem strony WWW producenta sprzętu. Awaria urządzenia wynikła z ponadnormatywnych parametrów zasilania nie zalicza się do sprzętowych awarii gwarancyjnych i nie powoduje konieczności pokrycia kosztów wymiany urządzenia w ramach gwarancji przez Wykonawcę. Zapewnienie stabilnego napięcia dla komputerów, sprzętu sieciowego należy do Zamawiającego / Partnera. 6 Etapy realizacji dostaw oraz prac 1. Dostawa: wdrożeniowych podlegające formalnym odbiorom Formalnemu odbiorowi podlega dostawa do każdego z Partnerów Projektu w ilościach określonych w punkcie 4 niniejszej karty produktu zgodnie z procedurą określoną w Załączniku nr 2 do SIWZ, Podpisany przez Zamawiającego protokół odbioru wszystkich dostaw w ramach zadania stanowi podstawę płatności za dostawę dla zadania. Procedurę odbioru dostaw w ramach zadania określa Załącznik nr 2 do SIWZ. 2. Montaż i uruchomienie: Formalnemu odbiorowi podlega montaż i uruchomienie przedmiotu dostawy u każdego z Partnerów Projektu zgodnie z wykazem określonym w punkcie 4 niniejszej karty produktu zgodnie z procedurą określoną w Załączniku nr 2 do SIWZ, Podpisany przez Zamawiającego protokół odbioru montażu i uruchomienia potwierdzający zrealizowanie wszystkich prac wdrożeniowych u Partnerów Projektu stanowi podstawę płatności. 7 Wymagania odnośnie treści oferty Na potwierdzenie, że oferowany Serwer spełnia wymagania określone przez Zamawiającego Wykonawca zobowiązany jest dołączyć do oferty następujące dokumenty: Wykonawca zobowiązany jest do wskazania producenta oraz marki oraz modelu oraz numerów katalogowych oferowanego serwera. Wykonawca zobowiązany jest do wskazania producenta oraz marki oraz modelu oraz numerów katalogowych wszystkich niezbędnych komponentów serwera zgodnie z Załącznikiem nr 12 do SIWZ protokół testów SPEC dla oferowanego modelu serwera poświadczony przez producenta serwera lub wydruk protokołu potwierdzającego osiągnięty wynik ze strony: dokument poświadczający, że oferowany serwer jest produkowany zgodnie z normami ISO 9001 lub równoważny dokument poświadczający, że oferowany serwer jest produkowany zgodnie z normami ISO lub S t r o n a 58

59 równoważny komponenty, z których zbudowane są serwery muszą być produktami certyfikowanymi przez producenta serwerów oraz muszą być objęte gwarancją producenta, potwierdzoną przez oryginalne karty gwarancyjne. Wykonawca zobowiązany jest dołączyć do oferty oświadczenie producenta lub Wykonawcy o spełnieniu wskazanego wymagania oświadczenie, że serwis serwera będzie realizowany przez producenta lub autoryzowanego partnera serwisowego producenta dokument poświadczający, że serwis serwera będzie realizowany zgodnie z normą ISO 9001 lub równoważną oświadczenie, że oferowany do przetargu serwer będzie fabrycznie nowy (nie wyprodukowany wcześniej niż 6 miesięcy przed datą dostawy) i będzie pochodzić z oficjalnego kanału dystrybucyjnego producenta S t r o n a 59

60 Zadanie nr 3: Macierz dyskowa Lp. Zawartość karty Opis 1 Specyfikacja techniczna / Zakres przedmiotu zamówienia obejmuje dostawę macierzy dyskowej na warunkach określonych w niniejszej Karcie funkcjonalna przedmiotu zamówienia produktu oraz na warunkach określonych w Specyfikacji Istotnych Warunków Zamówienia. Macierz dyskowa musi spełniać następujące wymagania minimalne: Obudowa o rozwiązanie musi być dostarczony ze wszystkimi komponentami do instalacji w standardowej szafie RACK 19 z zajętością maks 2U w tej szafie; o obudowa musi zawierać układ nadmiarowy dla modułów zasilania i chłodzenia umożliwiający wymianę tych elementów w razie awarii bez konieczności wyłączania macierzy; o obudowa powinna posiadać widoczne elementy sygnalizacyjne do informowania o stanie poprawnej pracy lub awarii/macierzy; o rozbudowa o dodatkowe moduły dla obsługiwanych dysków powinna odbywać się wyłącznie poprzez zakup takich modułów bez konieczności zakupu dodatkowych licencji lub specjalnego oprogramowania aktywującego proces rozbudowy; o moduły dla rozbudowy o dodatkowe dyski i przestrzeń dyskową muszą mieć obudowy o zajętości nie większej niż 2U, przy montażu w szafach przemysłowych standardu 19 ; o moduły dla rozbudowy muszą być wyposażone w nadmiarowy układ zasilania i chłodzenia. Pojemność o rozwiązanie musi umożliwiać instalację min 24 dysków formatu 2,5 wykonanych jako dyski SAS/FC lub NearLine-SAS/SATA II, musi także umożliwiać instalację dysków SolidStateDrive; o rozwiązanie musi posiadać możliwość dołączania półek rozszerzeń umożliwiających rozbudowę do 120 dysków, macierz powinna posiadać możliwość późniejszej rozbudowy wyłącznie poprzez zakup elementów sprzętowych. Kontrolery o rozwiązanie musi posiadać 2 kontrolery pracujące w układzie nadmiarowym typu active-active, z minimum 2GB pamięci podręcznej każdy; o w przypadku awarii zasilania dane nie zapisane na dyski, przechowywane w pamięci CACHE muszą być S t r o n a 60

61 zabezpieczone metodą trwałego zapisu na dysk lub pamięć nieulotną niewymagającą podtrzymania bateryjnego bądź zabezpieczone poprzez podtrzymanie bateryjne pamięci CACHE przez minimum 120 godzin o kontrolery muszą posiadać możliwość ich wymiany bez konieczności wyłączania zasilania całego urządzenia; o macierz powinna pozwalać na wymianę kontrolera RAID bez utraty danych zapisanych na dyskach nawet w przypadku konfiguracji z jednym kontrolerem RAID; o w układzie z zainstalowanymi dwoma kontrolerami RAID zawartości pamięci podręcznej obydwu kontrolerów musi być identyczna tzw. cache mirror; o każdy z kontrolerów RAID powinien posiadać dedykowany interfejs RJ-45 dla potrzeb serwisowych Interfejsy FC o oferowana macierz musi mieć minimum po 4 porty FC dla bezpośredniego podłączenia serwerów lub dla dołączenia do sieci SAN, wyprowadzone na każdy kontroler RAID. o porty powinny pracować z prędkością min. 8 Gb/s oraz umożliwiać poprawną pracę także z prędkością 4Gb/s. o interfejsy FC nie mogą być wykorzystywane do innych transmisji (zarządzanie lub konfiguracja macierzy) niż dane do zapisu / odczytu danych na zdefiniowane woluminy Poziomy RAID o macierz musi zapewniać poziom zabezpieczenia danych na dyskach definiowany poziomami RAID: 0,1, 1+0, 5,5+0, 6 (lub inna z podwójną parzystością) Wspierane dyski o oferowana macierz musi wspierać dyski: SAS/FC wykonane w technologii hot-plug o pojemnościach min. 600GB i prędkości obrotowej min obrotów na minutę; NL-SAS (NearLine SAS)/SATA II wykonane w technologii hot-plug o pojemnościach min. 750GB i prędkości obrotowej 7200 obrotów na minutę; elektroniczne SolidStateDrive wykonane w technologii hot-plug o pojemnościach min. 100GB liczba dysków SSD obsługiwanych w macierzy musi wynosić min 9 szt.; o interfejsy obsługiwanych dysków muszą być wyposażone w min. 2 porty pracujące w reżimie full-duplex (jednoczesną transmisję danych przez dwa porty). S t r o n a 61

62 o oferowana macierz musi być dostarczona z zainstalowanymi min 24 szt. dysków SAS/FC 600GB i prędkości obrotowej min obrotów na minutę; o Inne macierz musi wspierać mieszaną konfigurację dysków SAS/FC, NearLine-SAS/SATA II i SSD, w obrębie pojedynczego modułu obudowy; macierz musi wspierać dla min jednej z obsługiwanych technologii dyskowych mechanizm automatycznej przedawaryjnej migracji zapisów i składowanych danych na dysk zapasowy; macierz musi wspierać technologię energooszczędne typu Drive Spin Down lub wyłączanie dysków nieaktywnych w trybie ręcznym i automatycznym z wykorzystaniem mechanizmu typu time scheduler czyli w zadanym i/lub powtarzalnym oknie czasowym; macierz musi umożliwiać definiowanie i obsługę dysków zapasowych tzw. hot-spare w trybach: hot-spare dedykowany dla zabezpieczenia tylko wybranej grupy dyskowej RAID; hot-spare dla zabezpieczania dowolnej grupy dyskowej RAID. Opcje software owe o macierz musi być wyposażona w system kopii migawkowych (snapshot) z licencją na min 8 kopii migawkowych z możliwością rozszerzenia licencji do min kopii migawkowych; o macierz musi wspierać Microsoft Volume ShadowCopy Services (VSS), licencja wliczona w koszt macierzy; o macierz musi wspierać Microsoft Virtual Disk Services (VDS), licencja wliczona w koszt macierzy; o macierz musi umożliwiać zdefiniowanie min woluminów (LUN), licencja wliczona w koszt macierzy; o macierz powinna umożliwiać podłączenie logiczne z serwerami poprzez kilka redundatnych ścieżek logicznych FC; o macierz musi umożliwiać aktualizację oprogramowania wewnętrznego i kontrolerów RAID bez konieczności wyłączania macierzy i bez konieczności wyłączania podłączonych serwerów; o macierz musi umożliwiać dokonywanie w trybie on-line (tj. bez wyłączania zasilania i bez przerywania przetwarzania danych w macierzy) operacji: zmiana rozmiaru woluminu; zmiana poziomu RAID; dodawanie nowych dysków do istniejącej grupy dyskowej; o macierz musi posiadać wsparcie dla systemów operacyjnych: MS Windows Server 2003/2008, S t r o n a 62

63 2008R2/2012, SuSE Linux, RedHat Linux, SUN Solaris, VMWare 5.0/5.1, Citrix XEN Server; o w cenie macierzy musi być zawarty koszt licencji na oprogramowanie obsługujące technologię typu multipath (obsługa nadmiarowości dla ścieżek transmisji danych pomiędzy macierzą i serwerem) dla połączeń FC. Wymagane wsparcie oprogramowania dla systemów operacyjnych klasy: MS Windows, Linux, VMware. Cena musi uwzględniać użytkowanie oprogramowania w okresie gwarancji bez żadnych dodatkowych kosztów; o macierz musi umożliwiać wystawienie woluminu logicznego o maksymalnej pojemności min. 16TB; o macierz musi posiadać wbudowane tzw. storage-based, mechanizmy zdalnej replikacji danych z innymi macierzami tego samego typu, z wykorzystaniem protokołu transmisji Fibre Channel. Replikacja musi być obsługiwana w trybie synchronicznym i asynchronicznym oraz musi zawierać funkcjonalność replikacji z jednej macierzy źródłowej na min. 4 macierze docelowe, Zamawiający posiada macierz dyskową Fujitsu Eternus DX90 i NetApp FAS2040-R5; o aktywacja mechanizmu replikacji powinna odbyć się wyłącznie na drodze uruchomienia właściwej licencji, bez konieczności późniejszego zakupu elementów sprzętowych (dopuszcza się aby zarządzanie replikacją było realizowane za pomocą stacji zewnętrznej, nie dopuszcza się jednak replikacji typu hostbased ). o macierz musi być wyposażona w mechanizm umożliwiający enkrypcję (kluczem o długości min. 128 bitów) na poziomie LUN ów, wraz z macierzą powinny zostać dostarczone ewentualne niezbędne licencje umożliwiające szyfrowanie bez ograniczeń co do ilości danych oraz ilości serwerów Konfiguracja, zarządzanie o oprogramowanie do zarządzania musi być zintegrowane z systemem operacyjnym systemu pamięci masowej bez konieczności dedykowania oddzielnego serwera do obsługi tego oprogramowania; o komunikacja z wbudowanym oprogramowaniem zarządzającym macierzą musi być możliwa w trybie graficznym np. poprzez przeglądarkę WWW oraz w trybie tekstowym; o pełne zdalne zarządzanie macierzą powinno być możliwe bez konieczności instalacji żadnych dodatkowych aplikacji na stacji administratora, przez dodatkowe aplikacje Zamawiający nie rozumie środowiska uruchomieniowego typu Java zainstalowanego na stacjach administratora; Inne o system musi zapewniać możliwość samodzielnego i automatycznego powiadamiania producenta i administratorów Zamawiającego o usterkach za pomocą wiadomości wysyłanych poprzez protokół S t r o n a 63

64 SNMP lub SMTP. Niezawodność / jakość wytwarzania o do oferty należy załączyć dokumenty potwierdzające, że oferowany sprzęt jest produkowany zgodnie z normami ISO 9001 oraz ISO Ilość 1 sztuka 3 Prace wdrożeniowe Do czynności Wykonawcy w ramach dostawy macierzy dyskowej należy: Ustalenie z Zamawiającym terminu dostawy Rozpakowanie urządzenia, sprawdzenie, czy nie wystąpiły uszkodzenia 4 Specyficzne warunki dostaw / prac wdrożeniowych Miejsca dostawy, montażu i uruchomienia: Lp. Beneficjent Ilość Specyficzne warunki dostaw / prac wdrożeniowych 1. Urząd Marszałkowski Województwa Lubuskiego 1 5 Warunki serwisu gwarancyjnego Gwarancja i serwis 60 miesięcy gwarancji producenta na macierz realizowanej w miejscu instalacji sprzętu z gwarancją naprawy w następnym dniu roboczym od momentu zgłoszenia Serwis urządzeń musi być realizowany przez producenta lub autoryzowanego partnera serwisowego producenta wymagane oświadczenie Wykonawcy potwierdzające, że serwis będzie realizowany przez Producenta lub autoryzowanego partnera serwisowego producenta (należy dołączyć do oferty) Serwis urządzeń musi być realizowany zgodnie z wymaganiami normy ISO 9001 do oferty należy dołączyć dokument potwierdzający, że serwis urządzeń będzie realizowany zgodnie z tą normą. S t r o n a 64

65 Dostarczany sprzęt musi być fabrycznie nowy (niewyprodukowany wcześniej niż 6 miesięcy przed datą dostawy) i pochodzić z oficjalnego kanału dystrybucyjnego producenta. Wykonawca zobowiązany jest dołączyć do oferty oświadczenie, że oferowany do przetargu sprzęt spełnia ten wymóg. Możliwość automatycznej aktualizacji i pobrania sterowników do oferowanego modelu sprzętu w najnowszych certyfikowanych wersjach bezpośrednio z sieci Internet za pośrednictwem strony WWW producenta sprzętu. Awaria urządzenia wynikła z ponadnormatywnych parametrów zasilania nie zalicza się do sprzętowych awarii gwarancyjnych i nie powoduje konieczności pokrycia kosztów wymiany urządzenia w ramach gwarancji przez Wykonawcę. Zapewnienie stabilnego napięcia dla komputerów, sprzętu sieciowego należy do Zamawiającego / Partnera. 6 Etapy realizacji dostawy 1. Dostawa: Formalnemu odbiorowi podlega dostawa do Zamawiającego w ilości określonej w punkcie 2 niniejszej karty produktu Podpisany przez Zamawiającego protokół odbioru dostawy w ramach zadania stanowi podstawę płatności za dostawę dla zadania. 7 Wymagania odnośnie treści oferty Na potwierdzenie, że oferowana macierz dyskowa spełnia wymagania określone przez Zamawiającego Wykonawca zobowiązany jest dołączyć do oferty następujące dokumenty: Wykonawca zobowiązany jest do wskazania producenta oraz marki oraz modelu oraz numerów katalogowych oferowanej macierzy dyskowej. Wykonawca zobowiązany jest do wskazania producenta oraz marki oraz modelu oraz numerów katalogowych wszystkich niezbędnych komponentów macierzy dyskowej zgodnie z Załącznikiem nr 12 do SIWZ dokument poświadczający, że oferowana macierz dyskowa jest produkowana zgodnie z normami ISO 9001 lub równoważny dokument poświadczający, że oferowana macierz dyskowa jest produkowana zgodnie z normami ISO lub równoważny komponenty, z których zbudowana jest macierz dyskowa muszą być produktami certyfikowanymi przez S t r o n a 65

66 producenta macierzy dyskowej oraz muszą być objęte gwarancją producenta, potwierdzoną przez oryginalne karty gwarancyjne. Wykonawca zobowiązany jest dołączyć do oferty oświadczenie producenta lub Wykonawcy o spełnieniu wskazanego wymagania. oświadczenie, że serwis macierzy dyskowej będzie realizowany przez producenta lub autoryzowanego partnera serwisowego producenta dokument poświadczający, że serwis macierzy dyskowej będzie realizowany zgodnie z normą ISO 9001 lub równoważną oświadczenie, że oferowana do przetargu macierz dyskowa będzie fabrycznie nowa (nie wyprodukowana wcześniej niż 6 miesięcy przed datą dostawy) i będzie pochodzić z oficjalnego kanału dystrybucyjnego producenta S t r o n a 66

67 Zadanie nr 4: Pamięć RAM do serwerów blade Lp. Zawartość karty Opis 1 Specyfikacja techniczna / funkcjonalna Przedmiotu Zamówienia Zakres Przedmiotu Zamówienia obejmuje dostawę pamięci RAM do serwerów blade na warunkach określonych w niniejszej Karcie produktu oraz na warunkach określonych w Specyfikacji Istotnych Warunków Zamówienia. Zamawiający posiada 18 serwerów typu blade Fujitsu Primergy BX924S2 i planuje ich rozbudowę o dodatkowe moduły pamięci RAM. Pamięć RAM do serwerów blade musi spełniać następujące wymagania minimalne: Pamięć RAM 8GB (1x8GB), ECC o wsparcie dla technologii korekcji błędów Advanced ECC, scrubbing i Chipkill; o wsparcie sprzętowe kontrolera pamięci dla zapisu lustrzanego pamięci. Specyfikacja posiadanych serwerów blade Inne o pamięci muszą być produktami certyfikowanymi przez producenta serwerów oraz muszą być objęte gwarancją producenta serwera, potwierdzoną przez oryginalne karty gwarancyjne. Wykonawca zobowiązany jest dołączyć do oferty oświadczenie producenta lub Wykonawcy o spełnieniu wskazanego S t r o n a 67