Załącznik nr 7c do specyfikacji Szczegółowy opis przedmiotu zamówienia Pakiet 3 Integracja systemu SIDAS firmy Madkom S.A. z oprogramowaniem dziedzinowym firmy Korelacja - Systemy Informatyczne Sp. z o.o. 1. Przedmiotem zamówienia jest integracja systemu SIDAS firmy Madkom S.A. z oprogramowaniem dziedzinowym firmy Korelacja - Systemy Informatyczne Sp. z o.o. dla partnerów - Urzędów Gminy: a) Chełmiec, b) Kamionka Wielka, c) Łącko d) Rytro, e) MiG Piwniczna Zdrój, f) Miasta Grybów, g) Łabowa, h) Łososina Dolna, i) Nawojowa, j) Gródek nad Dunajcem, k) Korzenna, l) MiG Stary Sącz 2. Integracja z systemami zewnętrznymi 1) Moduł musi posiadać funkcjonalność Brokera Integracyjnego z innymi systemami zewnętrznymi. 2) Moduł musi posiadać funkcjonalność wczytania danych z Ewidencji Ludności w celu założenia i późniejszej aktualizacji m.in. książki adresowej w systemie SIDAS EZD 3) Moduł musi posiadać funkcjonalność otrzymywania / przejmowania pism wygenerowanych przez niżej wymienione użytkowane u poszczególnych Partnerów Projektu systemy dziedzinowe: Podatki (rolny, leśny, od nieruchomości) Systemy Dziedzinowe Rozliczenie Opłat za Odpady Komunalne Podatek od Środków Transportowych Rozliczenie Opłat za Wodę i Ścieki Partner Projektu Urząd Gminy Chełmiec X X X Urząd Gminy Kamionka Wielka X X X Urząd Gminy Łososina Dolna X X X X Urząd Gminy Nawojowa X X X Urząd Gminy Rytro X X X Urząd Gminy Gródek nad Dunajcem X X X Urząd Miejski w Grybowie X X X Urząd Gminy Korzenna X X X Urząd Gminy Łabowa X X X Urząd Miasta i Gminy Piwniczna -Zdrój X X X Urząd Miejski w Starym Sączu X X X 1
Urząd Gminy Łącko X X X Tabela 1 Wykaz użytkowanych przez Partnerów projektu Systemów Dziedzinowych produkcji Korelacja SI, które muszą zostać obsłużone przez broker integracyjny. 3. Moduł przekazywania pism do SIDAS EZD (produkcji MADKOM SA) z systemów dziedzinowych 1) Moduł musi współpracować z mechanizmem automatycznego generowania pism w wymienionych w Tabeli 1 systemach dziedzinowych. 2) Moduł musi posiadać opcję przekazywania pism z w/w systemów do użytkowanych przez Partnerów Projektu systemu SIDAS EZD. 3) Moduł musi stanowić integralną część posiadanych systemów dziedzinowych, nie może utrudniać wykonywania codziennych czynności w systemie. 4) Moduł musi posiadać podgląd wystawionych pism. 5) Moduł nie może wymagać od użytkownika, który pracuje w systemie dziedzinowym dodatkowego logowania, uwierzytelnienia itp. 6) Przekazywanie pism musi odbywać się drogą elektroniczną, bez wykorzystania zewnętrznych urządzeń takich jak: drukarki, skanery itp. 7) Moduł musi umożliwiać podczas wystawiania pism na określenie i odnotowanie co najmniej takich informacji jak: a) sygnatury pisma; b) odnotowanie osoby wystawiającej / generującej pismo; c) podgląd danych adresata pisma; d) daty utworzenia pisma. 4. Wymagania Brokera Integracyjnego z systemami zewnętrznymi (w tym epuap, BIP) 1) Broker Integracyjny w szczególności musi uczestniczyć w komunikacji obejmującej: a) automatyczne pobieranie wniosków z dowolnej skrytki podmiotu na platformie epuap i dalsze przekazywanie ich do systemu SIDAS EZD, b) automatyczne przekazywanie z systemu SIDAS EZD do skrytek na platformie epuap dokumentów powstających, jako ostateczne rozpatrzenie sprawy np. decyzje, c) automatyczne odbieranie dokumentów oraz pism z użytkowanych obecnie modułów dziedzinowych (zgodnie z Tabelą 1) do użytkowanego przez Partnerów Projektu systemu SIDAS EZD, d) automatyczne przekazywanie z użytkowanego obecnie przez Partnerów Projektu systemu SIDAS EZD statusów spraw do Regionalnego Systemu Biuletynów Informacji Publicznej Województwa Małopolskiego (RSBIP WM), dotyczy to partnerów użytkujących system BIP RSBIP WM, e) automatyczne przekazywanie z użytkowanego obecnie przez Partnerów Projektu systemu SIDAS EZD zawartości rejestrów publicznych do Regionalnego Systemu Biuletynów Informacji Publicznej Województwa Małopolskiego (RSBIP WM), dotyczy to partnerów użytkujących system BIP RSBIP WM. Wymagania funkcjonalne: 1) Broker Integracyjny musi pozwalać na integrację użytkowanego obecnie przez Partnerów Projektu systemu SIDAS EZD z platformą epuap, oraz obecnie użytkowanymi systemami wymienionymi w części dotyczącej Integracja z systemami zewnętrznymi w zakresie przekazywania dokumentów elektronicznych. 2) Integracja z platformą epuap musi obejmować pobierania wartości słowników z epuap. 3) Broker Integracyjny musi posiadać mechanizm tworzenia, implementowania, wdrażania, uruchamiania i konfigurowania usług wymiany danych pomiędzy systemami zewnętrznymi. 4) Usługi Brokera Integracyjnego muszą być komplementarne, tj. elementarne, tworzone jako konfiguracja pewnych modułów lub posiadać większą logikę integracyjną (np. sekwencja wywołań kilku usług). 2
5) Broker Integracyjny musi zakładać istnienie usług prywatnych i publicznych, tj.: a) usługi prywatne muszą być dostępne jedynie w obrębie platformy integracyjnej i nie mogą być bezpośrednio wywoływane przez klientów systemu, ich zadaniem jest realizowanie atomowych operacji, z których budowane są usługi publiczne. b) usługi publiczne muszą być widoczne dla klientów platformy integracyjnej poprzez punkt dostępu do definicji usługi (adres URL) - stanowiący adres sieciowy dokumentu WSDL opisującego usługę. 6) Każda usługa publiczna musi realizować konkretny scenariusz (proces) integracyjny. Wymagane jest aby wspólnym protokołem komunikacyjnym usług publicznych był protokół SOAP, a protokołem transportowym przynajmniej HTTP lub HTTPS. 7) Każda usługa musi zawierać: a) unikalną nazwę; b) definicję wejścia i wyjścia usługi; c) adres sieciowy; d) implementację logiki realizowanej przez usługę; e) metadane ją opisujące; f) listę błędów zgłaszanych przez usługę; g) dokumentację. 8) Broker Integracyjny musi zapewniać pełne wsparcie obsługi dokumentów XML. 9) W ramach obsługi dokumentów XML, Broker Integracyjny musi wspierać możliwość: a) tworzenia, parsowania i przekształcania komunikatów XML, b) walidacji komunikatów na podstawie definicji XMLSchema i DTD, c) obsługi dużych komunikatów (w tym obsługi dużych plików), d) poprawnej obsługi stron kodowych obsługujących polskie znaki. 10) W ramach obsługi protokołu SOAP dla usług konsumowanych jak i udostępnianych Broker Integracyjny musi zapewniać: a) możliwość konsumowania oraz udostępniania usług w standardzie co najmniej: WSDL 1.1, SOAP 1.1; b) standard WS-Security (przynajmniej dla usług konsumowanych); c) pożądane jest, aby platforma wspierała inne standardy WS określone specyfikacjami konsorcjum OASIS (http://www.oasis-open.org); 11) Broker Integracyjny musi dostarczać usługi transformacji komunikatów XML w modelu jeden do wielu, co najmniej przy wykorzystaniu języka XSLT (XSL Transformations, Extensible Stylesheet Language Transformations). 12) Broker Integracyjny musi umożliwiać routing komunikatów, oparty na treści dokumentów XML i regułach biznesowych. 13) Broker Integracyjny musi umożliwiać filtrowanie komunikatów na podstawie zawartości, przy wykorzystaniu kryteriów wprowadzonych przez użytkownika. 14) Broker Integracyjny musi umożliwiać realizację procesów integracyjnych w oparciu o model synchroniczny i asynchroniczny. 15) Broker Integracyjny musi posiadać mechanizmy load-balancing wykorzystywane w sytuacjach zwiększonego obciążenia. 16) Broker Integracyjny musi umożliwiać skalowanie, rekonfigurację, osadzanie nowych usług bez zakłócania pracy innych aplikacji czy realizowanych operacji biznesowych. 17) Broker Integracyjny musi zapewniać transakcje w procesach biznesowych. 18) Warstwa komunikacyjna Brokera Integracyjnego musi umożliwiać zachowanie integralności, niezaprzeczalności, poufności i autentyczności komunikacji. 19) Broker Integracyjny musi umożliwiać raportowanie informacji o incydentach w zakresie bezpieczeństwa. 3
20) Broker Integracyjny musi umożliwiać szyfrowanie i podpisywanie komunikatów XML w standardzie XAdES. 21) Minimalna długość klucza szyfrującego w przypadku zastosowania algorytmów symetrycznych musi wynosić 128 bitów, natomiast w przypadku zastosowania algorytmów asymetrycznych 1024 bity. 22) Broker Integracyjny musi umożliwiać weryfikację statusu unieważnienia certyfikatu poprzez mechanizm CRL. 23) Broker Integracyjny musi umożliwiać generowanie i zarządzanie certyfikatami. 24) Broker Integracyjny musi przenosić komunikaty pomiędzy systemami zewnętrznymi za pośrednictwem dowolnej liczby brokerów. 25) Komunikaty muszą posiadać zdolność do przenoszenia dowolnych plików. W przypadku plików XML Broker Integracyjny musi zapewnić możliwość weryfikacji zgodności przenoszonego dokumentu ze schemą XSD oraz wizualizację dokumentu. 26) W ramach konfigurowania usług Brokera Integracyjnego musi być możliwe wskazanie czy w komunikacji z danym systemem zewnętrznym występuje on w roli klienta czy serwera. 27) Broker Integracyjny musi obsługiwać różnoraką autoryzację systemów zewnętrznych w tym co najmniej: a) poprzez login i hasło aplikacji, b) poprzez certyfikat, c) poprzez adres serwera nadawcy komunikatu. 28) Broker Integracyjny musi posiadać wbudowany dziennik zdarzeń pozwalający na przeglądanie i filtrowanie logów dotyczących realizowanych usług. Szczegółowość logów musi być co najmniej na poziomie kroków procesu biznesowego realizującego daną usługę. 29) Broker Integracyjny musi posiadać możliwość wysyłania komunikatów diagnostycznych. 30) Broker Integracyjny musi posiadać możliwość podejrzenia historii obsługiwanych komunikatów z prezentacją co najmniej źródła, celu, rodzaju komunikatu. W ramach przeglądania kolejki Broker Integracyjny musi pozwalać co najmniej na: a) eksport komunikatu do pliku tekstowego lub pobranie komunikatu w pliku XML, b) prezentowanie statusu transmisji komunikatu, c) w przypadku błędu umożliwić podejrzenie szczegółów dotyczących błędu. 31) Broker Integracyjny musi posiadać mechanizmy zapisu i odzyskiwania przesyłanych komunikatów w przypadku awarii. 32) Broker Integracyjny musi dbać o prawidłową dwukierunkową wymianę danych pomiędzy modułami/systemami do niego podpiętymi. 33) Broker Integracyjny musi stanowić jednolitą i spójną platformę za pomocą której przekazywane są dane (w tym dokumenty) między modułami/systemami. 34) Broker Integracyjny musi umożliwiać komunikację w dowolnej sieci opartej o protokół TCP/IP. 35) Broker Integracyjny musi posiadać wydzielony moduł administracyjny pozwalający na definiowanie schematów (usług brokera) połączeń z wykorzystaniem istniejących interfejsów komunikacyjnych innych modułów/systemów, a także z wykorzystaniem interfejsów sieciowych udostępnianych przez Broker Integracyjny. 5. Integracja z platformą epuap 1) Moduł musi być zintegrowany z platformą epuap 2) Integracja modułu z platformą epuap musi umożliwiać wymianę danych między oboma systemami, zgodnie z wymienionymi poniżej w następnych punktach regułami, po jednorazowej konfiguracji konta/skrytki Partnera projektu na platformie epuap, bez konieczności jakiejkolwiek późniejszej ingerencji w konfigurację konta/skrytki lub konieczności logowania pracowników Partnerów projektu lub Wykonawcy celem obsługi dokumentów przychodzących do skrytki Partnera projektu lub przesyłanych z systemu SIDAS EZD do kont interesantów na platformie epuap. 4
3) Moduł musi automatycznie pobierać dokumenty skierowane do Partnera Projektu w platformie epuap, periodycznie co najmniej co określony odstęp czasu. Administrator modułu musi mieć możliwość zdefiniowania maksymalnego odstępu czasu między kolejnymi automatycznymi wywołaniami funkcji pobierania dokumentów z platformy epuap. Pobranie dokumentów z platformy epuap do systemu SIDAS EZD zakończone sukcesem musi powodować na platformie epuap usunięcie tych dokumentów z listy możliwych do pobrania. 4) Moduł musi udostępniać listę dokumentów które wpłynęły z platformy epuap. 5) Pozycje na liście dokumentów które wpłynęły z platformy epuap muszą być opisane co najmniej: a) danymi konta w platformie epuap nadawcy dokumentu, b) nazwą wzoru dokumentu z CRWD, c) unikalnym identyfikatorem dokumentu w module Elektronicznego Obiegu Dokumentów, d) datą i czasem wpływu, będącą datą i czasem wygenerowania Urzędowego Poświadczenia Odbioru lub Urzędowego Poświadczenia Przedłożenia wygenerowanym dla dokumentu e) plikiem wizualizacji dokumentu w formacie PDF, z poziomu listy możliwym na żądanie użytkownika do zapisania na lokalnym nośniku pamięci masowej lub otworzeniu w powiązanej z typem pliku aplikacji, f) plikiem oryginału dokumentu, z poziomu listy możliwym na żądanie użytkownika do zapisania na lokalnym nośniku pamięci masowej lub otworzeniu w powiązanej z typem pliku aplikacji, g) plikiem wizualizacji Urzędowego Poświadczenia Odbioru lub Urzędowego Poświadczenia Przedłożenia wygenerowanym dla dokumentu w formacie PDF, z poziomu listy możliwym na żądanie użytkownika do zapisania na lokalnym nośniku pamięci masowej lub otworzeniu w powiązanej z typem pliku aplikacji, h) plikiem oryginału Urzędowego Poświadczenia Odbioru lub Urzędowego Poświadczenia Przedłożenia wygenerowanym dla dokumentu, z poziomu listy możliwym na żądanie użytkownika do zapisania na lokalnym nośniku pamięci masowej lub otworzeniu w powiązanej z typem pliku aplikacji. 6) Moduł w odniesieniu do każdej pozycji na liście dokumentów które wpłynęły z platformy epuap musi umożliwiać co najmniej: a) Uprawnionemu użytkownikowi rejestrację pozycji jako przesyłki przychodzącej w Centralnym Rejestrze Przesyłek Przychodzących. Rejestracja przesyłki przychodzącej musi polegać co najmniej na wskazaniu procesu workflow z którym dana przesyłka zostanie powiązana, wskazaniu formularza rejestracji przesyłki, wypełnieniu pól formularza, przekazaniu do odpowiedniej komórki lub stanowiska merytorycznego. Przesyłki przychodzące z platformy epuap muszą podlegać takim samym regułom rejestracji i obiegu jak przesyłki przychodzące z innych źródeł (np. nadsyłane pocztą). b) Wykonywaną na żądanie weryfikację podpisu elektronicznego dokumentu przesłanego z platformy epuap. c) Wykonywaną na żądanie weryfikację podpisu elektronicznego Urzędowego Poświadczenia Odbioru lub Urzędowego Poświadczenia Przedłożenia wygenerowanego dla danego dokumentu. d) Wyświetlenie listy załączników dołączonych do pliku dokumentu przesłanego z platformy epuap. e) Wyświetlenie treści wskazanego załącznika do danego dokumentu w aplikacji skojarzonej z typem pliku załącznika. 7) Dokumenty Urzędowego Poświadczenia Odbioru lub Urzędowego Poświadczenia Przedłożenia dotyczące dokumentów przychodzących z platformy epuap muszą być trwale skojarzone z dokumentem którego dotyczą i być dostępne wraz z dokumentem na wszystkich listach systemu SIDAS EZD. Przekazanie dokumentu do komórki lub stanowiska merytorycznego musi powodować automatyczne przekazanie Urzędowego Poświadczenia Odbioru lub Urzędowego Poświadczenia Przedłożenia dotyczącego danego dokumentu, tak aby użytkownik aktualnie zajmujący się danym dokumentem miał zapewniony łatwy dostęp do Urzędowego Poświadczenia Odbioru lub Urzędowego Poświadczenia Przedłożenia. 5
8) Moduł musi powiązywać dokument przesłany z platformy epuap z odpowiednim interesantem z systemowej ewidencji interesantów, utworzonym na podstawie danych konta z portalu epuap nadawcy. 9) Moduł musi zmuszać użytkowników rejestrujących w Centralnym Rejestrze Przesyłek Przychodzących dokumenty przesyłane z platformy epuap do umieszczania informacji o możliwości/konieczności wysyłki do nadawcy w formie elektronicznej dokumentów powiązanych z nadesłanym dokumentem. 10) Moduł musi umożliwiać pracownikom merytorycznym kierowanie dokumentów (przesyłek wychodzących) do kont interesantów na platformie epuap. 11) Dokumenty wytworzone przez użytkowników modułu Elektronicznego Obiegu Dokumentów (pracowników Partnera projektu) i skierowane do wysyłki na platformę epuap, moduł musi automatycznie wysyłać, periodycznie co najmniej co określony odstęp czasu. Administrator modułu musi posiadać możliwość zdefiniowania maksymalnego odstępu czasu między kolejnymi automatycznymi wywołaniami funkcji wysyłania dokumentów do platformy epuap. 12) Zarejestrowane i przyporządkowane do dokumentów (przesyłek wychodzących) Urzędowe Poświadczenia Doręczenia lub Poświadczenia Niedoręczenia Dokumentu muszą być widoczne i dostępne z widoku szczegółowego akt sprawy w tym samym miejscu/widoku co dokument (przesyłka wychodząca). Zarejestrowane Urzędowe Poświadczenia Doręczenia lub Poświadczenia Niedoręczenia Dokumentu muszą być opisane co najmniej: a) formą dokumentu (tradycyjna albo elektroniczna), b) datą odbioru dokumentu (przesyłki wychodzącej), c) datą wpływu Urzędowe Poświadczenia Doręczenia lub Poświadczenia Niedoręczenia Dokumentu do modułu Elektronicznego Obiegu Dokumentów, d) danymi interesanta będącego adresatem dokumentu (przesyłki wychodzącej), e) wskazaniem identyfikatora dokumentu (przesyłki wychodzącej) z Centralnego Rejestru Przesyłek Wychodzących z którym jest powiązane Urzędowe Poświadczenia Doręczenia lub Poświadczenia Niedoręczenia Dokumentu, f) plikiem wizualizacji Urzędowego Poświadczenia Doręczenia lub Poświadczenia Niedoręczenia Dokumentu w formacie PDF, z poziomu widoku szczegółowego akt sprawy możliwym na żądanie użytkownika do zapisania na lokalnym nośniku pamięci masowej lub otworzeniu w powiązanej z typem pliku aplikacji, g) plikiem oryginału Urzędowego Poświadczenia Doręczenia lub Poświadczenia Niedoręczenia Dokumentu, z poziomu widoku szczegółowego akt sprawy możliwym na żądanie użytkownika do zapisania na lokalnym nośniku pamięci masowej lub otworzeniu w powiązanej z typem pliku aplikacji. 13) Moduł musi umożliwiać wykonywaną na żądanie weryfikację podpisu elektronicznego Urzędowego Poświadczenia Doręczenia przesłanego z platformy epuap. 6. Integracja z BIP (w sytuacji gdy Partnerzy projektu korzystają z BIP Urzędu Marszałkowskiego w Krakowie.) 1) Moduł musi być zintegrowany z systemem BIP Partnera Projektu w zakresie: a) automatycznego (tj. bez udziału użytkownika/operatora) z wykorzystaniem Brokera Integracyjnego przesyłania statusów spraw prowadzonych w systemie SIDAS EZD. b) automatycznego (tj. bez udziału użytkownika/operatora) z wykorzystaniem Brokera Integracyjnego przesyłania rejestrów i ich zawartości prowadzonych w systemie SIDAS EZD 2) Moduł w zakresie przesyłania statusów spraw musi: a) automatycznie przesyłać dane w odstępach czasowych zgodnie z ustalonym harmonogramem, musi istnieć możliwość dowolnego skonfigurowania częstotliwość przesyłania statusów spraw 3) automatycznie przesyłać wraz z unikalnym identyfikatorem spraw także status systemowy (krok procesu na którym znajduje się rozpatrywanie sprawy), status wprowadzony ręcznie przez referenta 6
prowadzącego sprawę, przewidywany czas do zakończenia rozpatrywania sprawy oraz dane referenta prowadzącego i dbać o właściwą prezentacje danych na stronie przedmiotowej BIP Partnera Projektu. 4) Moduł w zakresie przesyłania rejestrów i ich zawartości musi: a) przesyłać dane w odstępach czasowych zgodnie z ustalonym harmonogramem, musi być możliwość dowolnego skonfigurowania częstotliwość przesyłania zawartości rejestrów b) pozwalać na wskazanie dowolnie wybranych kolumn rejestru podlegających publikowaniu w BIP c) pozwalać na wskazanie dowolnej liczby rejestrów, z których dane są prezentowane w BIP d) pozwalać na przesyłanie i publikowanie na przedmiotowej stronie BIP plików dołączonych do wpisów w rejestrze e) pozwalać na przeszukiwanie w systemie BIP zawartości rejestrów, w tym także przeszukiwania w załącznikach dołączonych do wpisów w rejestrze. 7. Wymagania dotyczące wdrożenia i szkoleń 1) Wykonawca zobowiązany jest do wdrożenia rozwiązania tj. instalacji, konfiguracji i uruchomienia u każdego z Partnerów, 2) Wykonawca zobowiązany jest do przeszkolenia (u każdego z Partnerów) wszystkich pracowników na stanowiskach, na których będzie wykorzystywana funkcjonalność integracji, a ich przeszkolenie jest niezbędne do prawidłowej pracy rozwiązania, 3) Wykonawca zobowiązany jest dostarczyć drukowaną dokumentacje w języku polskim opisującą czynności wykonywane na poszczególnych stanowiskach dotyczące integracji, 4) Wykonawca zobowiązany jest do przeszkolenia (u każdego z Partnerów) administratora systemu w zakresie administracji wdrożonym rozwiązaniem. 8. Gwarancja, licencja opieka serwisowa i asysta techniczna Wykonawca udzieli gwarancji oraz asysty technicznej wraz z obsługą serwisową, w tym obsługą HelpDesk na przedmiot zamówienia na okres 24 miesięcy od daty podpisania bez zastrzeżeń końcowego protokołu odbioru. Wykonawca, stosownie do ustawy o prawie autorskim i prawach pokrewnych z 4 lutego 1994 r. (t.j. Dz. U. z 2006 r. Nr 90, poz. 631, z późn. zm.) oświadcza, że z momentem ukończenia prac nad wdrożeniem integracji, udziela Partnerom projektu na rzecz których świadczy usługi opisane niniejszym zamówieniem nieodpłatnej i nieograniczonej w czasie licencji niewyłącznej na korzystanie z wdrożonej aplikacji, na następujących polach eksploatacji: a) wyświetlania, odtwarzania, przekazywania, udostępniania i stosowania b) wielokrotnego wprowadzania do pamięci komputerów, c) przechowywania oprogramowania na serwerze Licencjobiorcy, d) dokonywania wszelkich modyfikacji programowych w zakresie korzystania z niego w celach pierwotnych, e) tworzenia nowych wersji i adaptacji (tłumaczenie, przystosowanie, zmianę układu lub jakiekolwiek inne zmiany), f) rozpowszechniania w sieciach zamkniętych w obrębie pracowników Licencjobiorcy g) korzystania z aplikacji na własny użytek. Licencja jest niewyłączna i zostaje udzielona nieodpłatnie. Licencja zostaje udzielona na czas nieoznaczony. Licencjodawca udostępni Licencjobiorcy wszelkich informacji dotyczących programu. Licencjobiorca nie ma prawa do publicznego rozpowszechniania, wprowadzania do obrotu, w tym najmu, sprzedaży lub dzierżawy programu oraz kopii oprogramowania. Licencjobiorca nie ma prawa przenosić praw wynikających z licencji. 9.1. Gwarancja minimalne wymagania: 1) Okres gwarancji 24 miesiące od daty podpisania bez zastrzeżeń końcowego protokołu odbioru. 7
2) Zdalnie lub w razie konieczności w siedzibie Partnera usuwanie usterek i awarii oprogramowania. 3) Zdalnie lub w razie konieczności w siedzibie Partnera usuwanie błędów baz danych (w tym brak spójności i integralności danych, itp.) niepolegające na błędnej obsłudze. 4) Skonfigurowanie lub udzielenie pomocy technicznej przy konfiguracji integracji 5) Dokonywanie aktualizacji systemu w miarę modyfikacji i ulepszania własnych aplikacji. 6) Dokonywanie przeglądu stanu systemu nie rzadziej niż raz na kwartał i przekazywanie Partnerowi raportu potwierdzającego wykonanie czynności. 7) Informowanie Partnera o dostępnych aktualizacjach/poprawkach oprogramowania, sterowników, bibliotek (system operacyjny serwerów, macierzy dyskowych, urządzeń sieciowych, baz danych, innych elementów istotnych dla bezpieczeństwa i właściwego funkcjonowania integracji. 8) Zadbanie, aby sprawdzenie dostępności aktualizacji/poprawki odbyło się przed każdym przeglądem systemu, w szczególności sprawdzenie, czy dana aktualizacja/poprawka nie wpływa negatywnie na działanie integracji. 9) Zdalne instalowanie w siedzibie Partnera powyższych aktualizacji/ poprawek (jeżeli oprogramowanie komercyjne dopuszcza pobranie aktualizacji w ramach licencji). 10) Zapewnienie prawidłowego (nieograniczonego czasowo i funkcjonalnie) działania integracji. W okresie gwarancji Wykonawca obowiązany będzie usunąć na własny koszt: a) wszelkich wad polegających m.in. na: ograniczeniu realizacji funkcji integracji uciążliwości w realizacji jednej z funkcji integracji nieprawidłowych wynikach generowanych przez aplikacje pola danych, których poprawności nie da się potwierdzić pola wykorzystywane niezgodnie z przeznaczeniem, błędach w sprawozdaniach b) usterek (awarii) - polegających m.in. na: zatrzymaniu lub poważnych zakłóceniach pracy integracji, niemożności realizacji jednej z jego funkcji, przy czym nie istnieje obejście lub jego zastosowanie wymaga nakładów nieuzasadnionych z ekonomicznego punktu widzenia Zamawiającego, jednoczesnym wystąpieniu szeregu wad, gdy można wykazać, że występujące jednocześnie wady mają ten sam skutek, co awaria, częstym, nieprzewidywalnym lub nieuniknionym zatrzymaniu lub zakłócaniu pracy integracji poważnym uszkodzeniu bazy danych oraz zasobu danych bądź też nieuzasadnionej konieczności dodatkowego ręcznego przetwarzania danych. 11) Błędy i awarie oprogramowania w okresie gwarancji są usuwane na koszt dostawcy integracji. 12) Spełnienie oczekiwań wymaganej wydajności lub pojemności, sytuacja taka jest uważana za wadę integracji i usuwana na zasadach określonych w gwarancji. 13) Zapewnienie następujących priorytetów i maksymalnych czasów usunięcia Wad (Czasy naprawy) w okresie gwarancji, liczone od momentu zgłoszenia Wady przez zamawiającego: a) dla zgłoszeń o priorytecie Krytycznym, oznaczającym przerwę w pracy integracji lub jego wdrożonej funkcjonalności - 1 dzień roboczy; b) dla zgłoszeń o priorytecie Wysokim, oznaczającym ograniczenie wydajności integracji lub jego funkcjonalności, pozwalające jednak na dalszą pracę w systemie oraz w modułach/systemach połączonych interfejsami - 5 dni roboczych; c) dla pozostałych zgłoszeń, określonych jako zgłoszenia o priorytecie Niskim - 14 dni roboczych 14) Skonfigurowanie integracji kopii zapasowych i przeprowadzenie testu poprawności działania w ramach przeglądów okresowych. 15) Zapewnienie rekonfiguracji bądź ponownej instalacji integracji i przywrócenie danych z kopii po awarii sprzętu. 8
16) Czas naprawy oprogramowania użytkowego odnosi się do oprogramowania użytkowego dostarczonego zamawiającemu, do którego dostawca oprogramowania posiada możliwość prawną i techniczną ingerencji w kod źródłowy. 17) Przez naprawę dla awarii programowej rozumiane są: a) naprawy wadliwego oprogramowania, b) rekonfiguracje wadliwych ustawień, c) naprawy baz danych, d) naprawy zawartości baz danych (w tym brak spójności i integralności danych, itp.). 18) Przedstawienie w trakcie odbioru końcowego pełnej dokumentacji powykonawczej obejmującej: a) opis użytych bibliotek (funkcji, parametrów), b) opis techniczny rodzajów i zastosowanych protokołów komunikacji, c) szczegółowy schemat baz danych integracji, uwzględniający powiązania i zależności między tabelami, d) opis techniczny procedur aktualizacyjnych e) dostarczenie wszelkie niezbędnych materiałów uzupełniających do powyższej dokumentacji powykonawczej, które są konieczne do właściwej eksploatacji integracji (instrukcje obsługi każdego podmodułu, struktury i powiązania baz danych zgodnie w szczególności z przepisami prawa dotyczącymi ochrony danych osobowych) 19) Przygotowanie (w trakcie wdrożenia integracji) procedury działania na okoliczność wystąpienia awarii integracji. Procedury awaryjne obejmują: a) Komu zgłosić awarię, b) Postępowanie w okresie oczekiwania na reakcję serwisu, c) Osoby kontaktowe, koordynatorów dla danego typu awarii, 20) Ewentualne rekonfiguracje integracji w celu zapewnienia właściwego dalszego działania. 9.2. Asysta Techniczna i opieka serwisowa minimalne wymagania: 1) Okres asysty technicznej 24 miesiące od daty podpisania bez zastrzeżeń końcowego protokołu odbioru. 2) Asysta techniczna oprogramowania polegająca w szczególności na dostarczaniu i instalacji uaktualnień oprogramowania wymaganych przez nowe przepisy prawne lub związanych z ogólnym rozwojem systemu w zakresie podmodułów, na które została udzielona licencja. 3) Asysta techniczna bazy danych polegająca w szczególności na: a) usuwaniu uszkodzeń danych zawartych w bazie danych oraz ich skutków powstałych w wyniku nieprawidłowego działania integracji, b) aktualizacji struktur bazy danych wymaganych przez nowe wersje oprogramowania lub nowe przepisy prawne lub związanych z ogólnym rozwojem systemu c) tworzeniu w bazie danych nowych struktur, które stanowią zabezpieczenie przed wprowadzaniem błędnych danych, powielaniem danych, naruszeniem integralności danych, skasowaniem danych, nadmiernym przyrostem danych i innymi niepożądanymi zjawiskami obniżającymi jakość bazy danych d) modyfikacji lub rozszerzaniu integracji o podmoduły zwiększające jego funkcjonalność i użyteczność, a będących w zakresie działań realizowanych przez zamawiającego e) integracji systemu z systemami stworzonymi przez Ministerstwo Administracji i Cyfryzacji lub dotyczącymi dokumentów elektronicznych oraz Biuletynu Informacji Publicznej w przypadku ich uruchomienia w czasie trwania asysty. 4) Udzielanie konsultacji pracownikom wskazanym przez Partnera w zakresie obsługi integracji. 5) Udostępnienie Helpdesku w godzinach roboczych pracy Partnera. 6) Usunięcie negatywnych skutków będących wynikiem modyfikacji wprowadzonych przez producenta systemu w ramach asysty technicznej. 9
10. PERSONEL WYKONAWCY 1) Zamawiający wymaga, aby zamówienie realizowane było przez osoby posiadające odpowiednie kwalifikacje, zasób wiedzy i doświadczenie zawodowe zapewniające właściwą realizację przedmiotu zamówienia. 2) Wykonawca winien zapewnić odpowiednią liczbę osób realizujących zamówienie gwarantującą prawidłowe wykonanie zamówienia. Zamawiający wymaga, aby Wykonawca dysponował odpowiednią kadrą (co najmniej 3 osoby), posiadającą odpowiednie wykształcenie, doświadczenie i kwalifikacje zawodowe, spełniającą poniższe warunki: a) co najmniej 1 osoba przewidziana do roli Kierownika Projektu, posiadająca wykształcenie wyższe oraz minimum 3 letnie doświadczenie w zarządzaniu realizacją projektów informatycznych wg metodyki Prince2 lub innej równoważnej, potwierdzone udziałem proponowanego specjalisty na stanowisku Kierownika Projektu w przynajmniej 1 zakończonym sukcesem (tj. odebranym przez Zamawiającego) projekcie informatycznym polegającym na dostawie, instalacji, wdrożeniu, konfiguracji i przeszkoleniu użytkowników systemu informatycznego o funkcjonalnościach brokera integracyjnego systemów dziedzinowych z systemem EOD oraz posiadająca znajomość najlepszych praktyk w zakresie zarządzania projektami - potwierdzoną certyfikatem potwierdzającym posiadaną wiedzę z zakresu metodyki zarządzania projektami Prince2 lub innej równoważnej, b) co najmniej 2 osoby, które pełnić będą rolę Specjalistów ds. Wdrożenia, posiadające wykształcenie wyższe oraz minimum 3 letnie doświadczenie zawodowe w zakresie wdrażania systemów elektronicznego obiegu dokumentów (EOD). Każdy z proponowanych specjalistów, musi posiadać doświadczenie na stanowisku wdrożeniowca systemu elektronicznego obiegu dokumentów (EOD), potwierdzone udziałem proponowanych specjalistów na stanowisku wdrożeniowca Systemu Elektronicznego Obiegu Dokumentów (EOD), w przynajmniej 2 zakończonych sukcesem (każdy) - tj. odebranych przez Zamawiającego projektach polegających na: dostawie, instalacji, wdrożeniu, konfiguracji i przeszkoleniu użytkowników System Elektronicznego Obiegu Dokumentów (EOD, a proponowani specjaliści musieli w nim wykonywać istotne zadanie merytoryczne lub polegających na opracowaniu i uruchomieniu integracji systemu SIDAS firmy Madkom S.A. z oprogramowaniem Korelacji Systemy Informatyczne Sp. z o.o. 3) Najpóźniej w ciągu 5 dni od dnia podpisania umowy na realizację zamówienia Wykonawca ma obowiązek dostarczyć Zamawiającemu potwierdzone za zgodność z oryginałem przez Wykonawcę kserokopie dokumentów proponowanych osób /personel Wykonawcy/, potwierdzających posiadanie przez nie wykształcenia, doświadczenia i kwalifikacji określonych w ppkt 2). W zakresie dokumentów potwierdzających posiadanie wymaganego wykształcenia Wykonawca zobowiązany jest przedłożyć Zamawiającemu dyplom ukończenia studiów wyższych, natomiast w zakresie dokumentów potwierdzających posiadanie wymaganego doświadczenia Wykonawca jest zobowiązany przedłożyć Zamawiającemu dokumenty potwierdzające wymagane doświadczenie zawodowe. Potwierdzeniem doświadczenia mogą być w szczególności: listy referencyjne, poświadczenia, umowy, faktury VAT/rachunki, świadectwa pracy itp. 4) Niedostarczenie dokumentów, o których mowa w ppkt 3) skutkować będzie odstąpieniem od umowy z winy Wykonawcy. 5) Za certyfikat równoważny w stosunku do wymaganego certyfikatu APM Group Ltd Prince2 na poziomie co najmniej Foundation Zamawiający uznaje: a) certyfikat AIPM (Australian Institute for Project Management) na poziomie co najmniej Level 5, b) certyfikat IPMA (International Project Management Association) na poziomie co najmniej Level D, c) certyfikat PMI (Project Management Institute) na poziomie co najmniej Project Management Professional (PMP), 10
d) certyfikat APM (Association for Project Management) na poziomie co najmniej Certified Project Manager, e) certyfikat ASAPM (American Society for the Advancement of Project Management) na poziomie co najmniej Project Manager of medium or less-complex Project (acpm1). 6) W okresie realizacji zamówienia (nie wliczając w to okresu asysty technicznej oraz opieki autorskiej) osoba realizująca zamówienie (stanowiąca personel Wykonawcy) może zostać zmieniona na inną osobę przez wykonawcę jedynie na wniosek Zamawiającego lub w sytuacjach wyjątkowych (śmierć, udokumentowana długotrwała choroba, itp.), za zgodą Zamawiającego, pod warunkiem, że zastępująca ją osoba spełniać będzie wymogi odpowiednio określone powyżej. 11