1. Skróty terminów używanych w dokumencie...2

Transkrypt

1 Szczegółowy opis przedmiotu zamówienia na Zaprojektowanie, wykonanie i wdrożenie Lokalnego Systemu Informatycznego obsługującego Instytucję Pośredniczącą oraz Instytucje Wdrażające, Programu Operacyjnego Infrastruktura i Środowisko Spis treści 1. Skróty terminów używanych w dokumencie Wymagania dotyczące przedmiotu zamówienia Cel budowy LSI Zakres usług w ramach zamówienia Założenia Systemu LSI Scenariusz wdrożenia Wymagania funkcjonalne Rejestracja danych Wymagania funkcjonalne Modułu Rejestracja danych - Interfejs Systemu LSI, Import danych z GWoD, GWoP Moduł wymiany danych Sprawozdawczość Monitorowanie Poświadczenia i deklaracje wydatków Raporty, Statystyki, Wizualizacje graficzne Komunikacja wewnętrzna Zarządzanie dokumentami Przykładowe typy przechowywanych dokumentów: Administracja Systemem LSI Wymagania niefunkcjonalne Architektura techniczna (sprzętowa i systemowa) Wymagania ogólne technologiczne Platforma sprzętowa Platforma systemowa Wymagania jakościowe Wymagania usługi utrzymania Systemu LSI (np. Gwarancja, Wsparcie techniczne, Rozwój Systemu) Wymagania Bezpieczeństwa Wymagania wydajnościowe Wolumen danych Zalecane technologie i standard Szkolenia Referencje do dokumentów Zarządzanie realizacją projektu... 29

2 1. Skróty terminów używanych w dokumencie Administrator Zamawiającego Administrator Merytoryczny Systemu LSI, Beneficjent/Wnioskodawca Podmiot ubiegający się lub korzystający z dofinansowania, COBIT (Control Objectives For Information and Related Technology) - standard audytu systemów informatycznych, Dni robocze - dni od poniedziałku do piątku za wyjątkiem dni ustawowo wolnych od pracy), Etap Ciąg działań związanych z wykonaniem Umowy, wskazanych jako Etap w SIWZ, Godziny pracy Systemu - 7:30 17:30 w dni robocze, GWoD Generator Wniosków o Dofinansowanie, GWoP Generator Wniosków o Płatność, IC Instytucja Certyfikująca, IP Instytucja Pośrednicząca POIiŚ Ministerstwo Środowiska, IW Instytucja Wdrażająca (instytucja pośrednicząca II stopnia) POIiŚ w sektorze środowisko, LSI-IW Lokalny system informatyczny wdrożony przez IW, IZ (MRR) Instytucja Zarządzająca dla POIiŚ Ministerstwo Rozwoju Regionalnego, KSI Krajowy System Informatyczny (SIMIK 07-13), Moduł Zbiór funkcjonalności spełniających określone zadania, MRR Ministerstwo Rozwoju Regionalnego, Obiekt Zbiór danych wraz z ich relacjami dotyczących jednego projektu (w dalszej części dokumentu może pojawiać się odwołanie do obiektu w rozumieniu raportu, lub zestawienia), POIiŚ Program Operacyjny Infrastruktura i Środowisko, Roboczogodzina 60 minut przeznaczone na realizację zadań w ramach rozwoju Systemu, SIMIKXML - Moduł systemu KSI realizujący import danych w postaci plików XML z LSI do KSI, SIWZ Specyfikacja Istotnych Warunków Zamówienia wraz z załącznikami, System, System LSI, LSI Rozwiązanie informatyczne do obsługi pakietu projektów w obszarze odpowiedzialności Ministerstwa Środowiska jako Instytucji Pośredniczącej POIiŚ, będące przedmiotem niniejszego Zamówienia, Usługi utrzymania Systemu świadczenie przez okres 36 miesięcy liczony od dnia podpisania przez obie strony Protokołu Odbioru Etapu IV z wynikiem pozytywnym: gwarancji i wsparcia technicznego Systemu od dnia podpisania przez obie strony Protokołu Odbioru Etapu II z wynikiem pozytywnym, rozwoju Systemu od dnia podpisania przez obie strony Protokołu Odbioru Etapu IV z wynikiem pozytywnym, Użytkownik Użytkownik Systemu LSI, Wykonawca Potencjalnie każda firma, która otrzyma niniejszy dokument w celu złożenia i przedstawienia oferty w oczekiwanym przez Zamawiającego zakresie, Wytyczne zbiór dokumentów programowych wydawanych przez Ministra Rozwoju Regionalnego wraz z załącznikami, 2

3 XML - Extensible Markup Language uniwersalny język formalny przeznaczony do budowania struktur danych, Zamawiający - Ministerstwo Środowiska Departament Programu Operacyjnego Infrastruktura i Środowisko. 2. Wymagania dotyczące przedmiotu zamówienia 2.1. Cel budowy LSI Celem Systemu oraz wymaganiem Zamawiającego jest otrzymanie jako rozwiązania Systemu, który wspomaga wspólne zarządzanie całym pakietem projektów i związanych z nimi obiektów realizowanych w ramach osi priorytetowych I-V i XIV - XV POIiŚ. Narzędzie powinno zbierać i rejestrować dane głównie za pośrednictwem IW, monitorować i agregować je w celu analizy, niezbędnej sprawozdawczości oraz zasilania danymi systemu KSI. Najważniejsze cele budowy Systemu LSI to wspomaganie wspólnego zarządzania rejestrowanymi obiektami, zbiorcze analizy efektywności projektów zgłaszanych do dofinansowania i realizowanych przez Beneficjentów, śledzenie budżetów, harmonogramów realizacji projektów, stanu poniesionych wydatków, sporządzanie prognoz wydatków w ramach projektów, aktualizacja danych, wspomaganie komunikacji między Użytkownikami, wspomaganie jednolitego raportowania, tworzenia statystyk, wspomaganie jednolitych standardów informacji o projektach dla Użytkowników, raportów tabelarycznych i wizualnych. System LSI powinien utrzymywać wspólne repozytorium dokumentów dla wszystkich projektów realizowanych przez Beneficjentów, dostarczać mechanizmy komunikacji wewnętrznej oraz wspierać zarządzanie, utrzymywanie Systemu przez Administratorów Zamawiającego Zakres usług w ramach zamówienia Zakres usług w ramach zamówienia Zaprojektowanie, wykonanie i wdrożenie Lokalnego Systemu Informatycznego obsługującego Instytucję Pośredniczącą oraz Instytucje Wdrażające, Programu Operacyjnego Infrastruktura i Środowisko obejmuje: 1) Przeprowadzenie analizy potrzeb użytkowników końcowych (analizy biznesowej oraz funkcjonalnej), tj. zdefiniowanie potrzeb użytkowników końcowych względem Systemu LSI oraz analiza dokumentów programowych, w szczególności załączników do Wytycznych określających zakres danych przetwarzanych przez System. 2) Realizację usług projektowych (projekt techniczny i wykonawczy, dokumentacja, zarządzanie projektowe). 3) Wykonanie Systemu (stworzenie, dostarczenie, wdrożenie, instalacja, konfiguracja oraz testowanie Systemu) spełniające wymagania Zamawiającego określone w SIWZ. 4) Wsparcie Zamawiającego w przeprowadzeniu testów akceptacyjnych Systemu. 5) Zapewnienie infrastruktury sprzętowej i systemowej przy założeniu, że Zamawiający nie posiada pomieszczeń i infrastruktury wymaganych do prawidłowego i bezpiecznego funkcjonowania Systemu. Infrastruktura ta powinna być umiejscowiona w lokalizacji zapewnionej przez Wykonawcę. 6) Administrację platformą sprzętową i systemową oraz bazami danych i aplikacjami wchodzącymi w skład Systemu od dnia podpisania Protokołu Odbioru Etapu II z wynikiem pozytywnym do upływu 36 miesięcy od dnia podpisania Protokołu Odbioru Etapu IV z wynikiem pozytywnym. 7) Dostawę licencji Wykonawcy, firm trzecich, niezbędnych do uruchomienia i działania Systemu LSI. 3

4 8) Szkolenia dla Użytkowników i Administratorów Zamawiającego, opracowanie szkolenia e- learningowego włącznie z zapewnieniem stanowiskowych instrukcji szkoleniowych dla użytkowników i Administratorów Zamawiającego. 9) Usługi utrzymania Systemu LSI w zakresie: a) Gwarancji, b) Wsparcia technicznego w zakresie wszystkich komponentów sprzętowych i programowych Systemu, c) Rozwoju Systemu. 10) Dostarczenie dokumentacji Systemu w wersji elektronicznej i papierowej: a) opisu Systemu, w tym dokumentacji analitycznej sporządzonej w trakcie etapu analizy Systemu, b) dokumentacji technicznej, w tym dokumentacji projektowej, instrukcji instalacji i konfiguracji Systemu oraz instrukcji odtworzenia Systemu (w przypadku przenoszenia Systemu na inną infrastrukturę), c) procedur bezpieczeństwa, d) dokumentacji eksploatacyjnej dla Administratorów Zamawiającego, uwzględniającej zasady administracji Systemem oraz wymiany i weryfikacji danych z KSI, e) dokumentacji eksploatacyjnej użytkownika. 11) Przekazanie niezbędnych licencji, kodów źródłowych i majątkowych praw autorskich oraz innych komponentów Systemu LSI Założenia Systemu LSI Podstawowe założenia Systemu LSI: 1) System jest nastawiony na wsparcie użytkowników uczestniczących we wdrażaniu i nadzorowaniu projektów celem zapewnienia skutecznej realizacji zadań Ministerstwa Środowiska jako IP. 2) Podstawą przetwarzania i systematyki w Systemie będą obszary dotyczące obsługi następujących modułów: a) Rejestracji danych, b) Importu danych, c) Sprawozdawczości, d) Monitorowania projektów, e) Raportów/Statystyk, Wizualizacji graficznych, f) Poświadczeń i deklaracji wydatków, g) Wymiany danych, h) Komunikacji wewnętrznej, i) Zarządzania dokumentami, j) Administracji Systemem LSI. 3) System umożliwi przetwarzanie i obsługę danych źródłowych m.in. poprzez: a) Przyjmowanie (m.in. import danych wygenerowanych przez Generator Wniosków o Dofinansowanie (GWoD), Generator Wniosków o Płatność (GWoP) i inne systemy i narzędzia - XLS, XML, XSD, DOC, PDF i innych), rejestrację nowych danych rejestrowych (formularze Systemu) i zapisywanie przychodzących od Wnioskodawcy lub Beneficjenta pozostałych danych, dokumentów, informacji dotyczących wdrażanych projektów, b) Agregację danych w tym przygotowanie raportów, zestawień itp. oraz danych niezbędnych dla sprawozdawczości Zamawiającego, c) Wsparcie rejestrowania nowej wersji dokumentu/obiektu pod tym samym numerem rejestrowym Systemu LSI (wersjonowanie), d) Przypisywanie dokumentów do obiektów, 4

5 e) Eksport danych do formatów XLS, RTF, PDF, XML, DOC, JPG, TIF, f) Udostępnienie danych rejestrowych poprzez formularze Systemu, g) Udostępnienie mechanizmów do tworzenia raportów i statystyk, h) Udostępnienie mechanizmów do administrowania i konfiguracji danych w Systemie, i) Import do Systemu LSI danych z GWoD / LSI-IW / GWoP, / systemu raportowania KSI (format XLS), j) Eksport danych do KSI, k) Zapisywanie dokumentów elektronicznych w repozytorium dokumentów Systemu, l) Tworzenie szeregu statystyk, zestawień i wizualizacji, m) Przesyłanie do wnioskodawcy lub Beneficjenta korespondencji elektronicznej związanej z wnioskiem, umową lub innymi obiektami Systemu, n) Tworzenie wizualizacji i statystyk na tle mapy administracyjnej kraju z uwzględnieniem podziału administracyjnego wg województw, powiatów, gmin i miejscowości, o) Przygotowanie danych do prezentowania na stronach WWW (eksport danych/raportów z Systemu LSI, pozwalający na umieszczenie na stronach internetowych, w szczególności w formie tabelarycznej i wizualnej), p) Dołączanie dokumentów elektronicznych do Systemu, możliwość ładowania kilku załączników danego rodzaju oraz możliwość wersjonowania plików, q) Efektywne przesyłanie plików dołączanych do dokumentów przy założonych wolumenach. 4) System powinien zawierać zestaw usług (funkcjonalności) oferowanych w różnym zakresie dla następujących podstawowych grup użytkowników: a) Pracowników IP i IW, b) Wybranych (ok. trzydziestu) Beneficjentów. 5) Stały dostęp do Systemu LSI przy uwzględnieniu różnych poziomów uprawnień. 6) System powinien umożliwiać bezpieczne logowanie użytkowników i zarządzanie dostępem do danych i funkcjonalności. 7) System powinien być dostępny przez przeglądarki WWW wymienione w pkt 4.1, przy wykorzystaniu przez użytkownika dowolnego systemu operacyjnego kompatybilnego z daną przeglądarką, bez konieczności dodatkowej instalacji oprogramowania specjalistycznego (z wyłączeniem oprogramowania wspierającego przesyłanie załączników do Systemu) Zamawiający dopuszcza instalację oprogramowania na wybranych stanowiskach (maksymalnie 5) pozwalającego na tworzenie rozbudowanych raportów. 8) Zakres merytoryczny informacji prezentowanych w Systemie, dostęp do poszczególnych funkcjonalności oraz możliwość ich wykorzystania zależy od profilu użytkownika i uprawnień przypisanych do profilu. 9) System LSI powinien przygotowywać dane gotowe do zasilania dla systemu KSI. 10) Architektura Systemu musi uwzględniać oczekiwanie ciągłego zaplanowanego rozwoju Systemu. Powinna uwzględniać i charakteryzować się cechami: skalowalnością, elastycznością, możliwościami zarządzania i konfigurowania podstawowych danych dla Systemu. Niezależnie od przyjętych rozwiązań Wykonawca zobowiązany będzie do zapewnienia lub świadczenia usług wsparcia, również dla użytych narzędzi. 11) Zamawiający nie oczekuje budowy funkcjonalności typowych dla systemów finansowoksięgowych. 12) Zamawiający nie przewiduje implementacji Systemu Obiegu Dokumentów lub też integracji z istniejącymi SOD. 13) System powinien posiadać funkcjonalność powiadamiania o zdarzeniach. System będzie obsługiwał wieloetapowe procesy biznesowe, np., weryfikacja wniosków o płatność. 5

6 14) Zapewnienie możliwości weryfikacji zgodności dokumentów papierowych generowanych z Systemu LSI z ich elektronicznymi odpowiednikami z wykorzystaniem unikalnych identyfikatorów. 15) Procesy biznesowe zdefiniowane w Systemie będą jednolite dla wszystkich instytucji obsługiwanych przez System (IP, IW, Beneficjent) Scenariusz wdrożenia Podejście etapowe Wdrożenie Systemu będzie realizowane w ramach czterech etapów: 1) I Etap analiza biznesowa i funkcjonalna Systemu oraz przygotowanie i dostarczenie dokumentacji, o której mowa w pkt ) II Etap wykonanie i wdrożenie następujących modułów Systemu: a) Rejestracja danych, b) Import danych, c) Sprawozdawczość, d) Administracja Systemem LSI oraz aktualizacja dokumentacji, o której mowa w pkt ) III Etap wykonanie następujących modułów Systemu: a) Poświadczenia i deklaracje wydatków, b) Monitorowanie projektów, c) Raporty/Statystyki, Wizualizacje graficzne oraz aktualizacja dokumentacji, o której mowa w pkt ) IV Etap wykonanie i wdrożenie (łącznie z Etapem III) następujących modułów Systemu: a) Wymiana danych, b) Komunikacja wewnętrzna, c) Zarządzanie dokumentami oraz dostarczenie i aktualizacja dokumentacji, o której mowa w pkt. 4.2, a także dostarczenie kodów źródłowych oraz konfiguracji baz danych i innych komponentów Systemu. Zamawiający będzie miał możliwość użytkowania Systemu LSI, po podpisaniu Protokołu Odbioru Etapu II z wynikiem pozytywnym. 3. Wymagania funkcjonalne Poniżej przedstawione zostały wymagania Zamawiającego zgrupowane w podstawowe moduły funkcjonalne. System musi dokonywać wersjonowania plików z zachowaniem informacji archiwalnych oraz przedstawiać podstawowe informacje o użytkowniku, który dokonał zmian oraz ich zakresu. Dla wybranych Beneficjentów Zamawiający przewiduje dostęp do Systemu LSI (Moduł Rejestracja danych oraz Moduł Komunikacja wewnętrzna). Beneficjent może wprowadzać dane oraz przeglądać informacje dotyczące monitorowania własnych wniosków/projektów. 6

7 System powinien udostępniać dane w zależności od zdefiniowanego profilu użytkownika (w tym IP, IW, Beneficjentom) Rejestracja danych Moduł niezbędny do zarejestrowania danych dotyczących obiektów, tj. potwierdzeń przyznania dofinansowania, Decyzji KE, umów o dofinansowanie, kontroli, prognoz płatności, prognoz wydatków, rejestru obciążeń na projekcie. W module tym powinny znaleźć się wszystkie pola wymagane w KSI oraz dodatkowe pola określone przez Wykonawcę na etapie analizy biznesowej, z zastrzeżeniem, że moduł ten nie obejmuje rejestracji danych z wniosków o dofinansowanie i wniosków o płatność. Automatyczne nadawanie numeru dokumentu zgodnego z formatem KSI. Będzie to jeden z numerów dokumentu przechowywany w Systemie, na podstawie reguł dotyczących jego struktury, czasu i sposobu jego nadania. Dokumenty rejestrowane w Systemie LSI są powiązane ze sobą przez obiekt nadrzędny tj. projekt. Obiektami podrzędnymi są: wniosek o dofinansowanie, umowa o dofinansowanie, wnioski o płatność, kontrole, rejestr obciążeń na projekcie, itp. Po pozyskaniu danych z procesu Rejestracji, System powinien umożliwić regularne uruchamianie akcji w obszarze monitorowania projektów np. kontroli, procesów monitorowania, uzupełnianie danych, tworzenia zestawień i list monitorowanych projektów. Ponadto moduł ten powinien spełniać następujące wymagania: 1) Wprowadzanie i modyfikacja danych. 2) Formularze ekranowe powinny odzwierciedlać strukturę wzoru dokumentu, którego dotyczą. 3) Sprawdzanie poprawności wpisywanych danych poprzez podpowiedź dopuszczalnych wartości pól oraz poprzez walidację wartości pól, W przypadku wystąpienia błędów System powinien je wyświetlać oraz wskazywać miejsce i przyczynę błędu wraz z możliwością wydrukowania ich pełnego zestawienia. 4) Umożliwiać rejestrację następujących statusów: a) Roboczy (na etapie rejestrowania), b) Wprowadzony (po zakończeniu rejestracji), c) Weryfikowany (przez wiele grup użytkowników), d) Zatwierdzony/do poprawy/odrzucony, dla każdego obiektu status może być użyty wielokrotnie celem odzwierciedlenia powtórzenia czynności, np. ponowna ocena wniosku o dofinansowanie. System powinien zachowywać historię zmian statusów dla danego obiektu ze wskazaniem kto i kiedy danej zmiany dokonał. Ponadto dla każdego projektu/wniosku o dofinansowanie, do którego jest przypisany status Weryfikowany powinna istnieć możliwość zarejestrowania poszczególnych etapów weryfikacji wybieranych z listy rozwijalnej. 5) Umożliwienie dołączania załączników w postaci plików w formatach XLS, DOC, PDF, plików graficznych (skany dokumentów) przez wywołanie odpowiednich funkcji z modułu Zarządzanie dokumentami. 6) W przypadku zastosowania list słownikowych, umożliwienie Administratorowi Zamawiającego dodania kolejnych pozycji na liście lub uruchomienia funkcjonalności pozwalającej na wprowadzenie pozycji spoza listy. 7

8 Interfejs natywny Modułu Rejestracja danych Systemu LSI powinien być zbieżny (zgodność: z Księgą Identyfikacji Wizualnej Narodowej Strategii Spójności i Zasadami promocji projektów dla beneficjentów Programu Operacyjnego Infrastruktura i Środowisko i graficzna) z interfejsem rejestracji w GWoD (informacja i sposób procesowania/generowania wniosków dostępna pod adresem internetowym Wymagania funkcjonalne Modułu Rejestracja danych - Interfejs Systemu LSI, Zadania Modułu Rejestracja danych 1) Dostarczenie wsparcia funkcjonalnego dla IP oraz IW. 2) Rejestracja danych dla obiektów, w tym załączników również skompresowanych (np. formaty ZIP, RAR). 3) Generowanie listy niezgodności, nieprawidłowości lub braku danych wraz mechanizmem powiadomienia Beneficjenta. 4) Ustawienie statusów dla obiektów Zakres dokumentów Rejestracja danych i uzupełnianie podstawowych danych będzie dotyczyć następujących obiektów Systemu LSI: 1) Wnioski o Dofinansowanie. 2) Decyzje KE / Potwierdzenia przyznania dofinansowania. 3) Umowy o dofinansowanie oraz ewentualne Aneksy. 4) Wnioski o Płatność. 5) Kontrole. 6) Prognozy wydatków. 7) Prognozy wnioskowania o płatność. 8) Rejestr obciążeń na projekcie. 9) Deklaracje wydatków przychodzące do instytucji. 10) Deklaracje wydatków własne instytucji. 11) Nieprawidłowości Zakres danych rejestrowych (specyficzne) Zapisy poniższego rozdziału należy traktować jedynie jako wskazówkę co do zakresu gromadzonych i przetworzonych danych. Zamawiający oczekuje dokonania pełnej analizy zakresu danych i funkcjonalności Systemu przez Wykonawcę na etapie analizy biznesowej. Początkowy zakres pól rejestrowych powinien zostać opracowany na podstawie: 1) wzoru informacji miesięcznej i sprawozdań okresowych będących załącznikami do Wytycznych w zakresie sprawozdawczości POIiŚ ( 2) wzoru poświadczenia i deklaracji wydatków będącego załącznikiem do Zaleceń w zakresie systemu obiegu środków finansowych w ramach POIiŚ ( spx#zakladka=5). 3) wzoru umowy o dofinansowanie ( spx#zakladka=2). 4) pól wymaganych w KSI. 8

9 Dane te będą podlegać zmianom w czasie prowadzonej Analizy i Projektu technicznego (Wykonawca będzie mógł zasugerować zmiany specyfikacji). Rejestracja danych dotyczących Umowy o Dofinansowanie powinna odbywać się na podstawie danych z Wniosku o Dofinansowanie. Użytkownik powinien mieć możliwość zmiany poszczególnych pól, przy pierwszej rejestracji Umowy o Dofinansowanie, lecz System powinien umożliwiać raportowanie rozbieżności. System powinien umożliwiać wprowadzenie miesięcznych kursów EURO Europejskiego Banku Centralnego celem zapewnienia możliwości dokonania przeliczenia w Module Raportowania. System powinien również umożliwiać rejestrowanie danych dotyczących Harmonogramów realizacji poszczególnych projektów w oparciu o: 1) Formularze dostępne dla użytkowników Systemu. 2) Pliki XLS zawierające odpowiednie ograniczenia edycji oraz pozwalające na ładowanie danych do Systemu 1. Pliki te powinny być generowane z Systemu odpowiednio dla każdego z projektów i zawierać aktualne dane. Aktualizacja harmonogramów w oparciu o pliki XLS winna odbywać się wg następującej sekwencji: a) generowanie plików XLS z Systemu zawierających aktualny harmonogram, b) aktualizacja harmonogramu w plikach XLS, c) import zaktualizowanych harmonogramów. Dane dotyczące harmonogramów będą zbierane i przetwarzane na poziomie poszczególnych zadań w projekcie określonych w załączniku nr 3 do wzoru umowy o dofinansowanie. Zamawiający nie oczekuje mechanizmów opisujących relacje pomiędzy poszczególnymi zadaniami w projekcie. Każde z zadań podzielone powinno być na dwa etapy: 1) Procedura przetargowa. 2) Realizacja zadania. W ramach rejestracji i aktualizacji harmonogramów zbierane powinny być następujące dane: 1) Nazwa zadania. 2) Numer zadania. 3) Początek etapu procedura przetargowa rozumiany jako wszczęcie postępowania. 4) Koniec etapu procedura przetargowa rozumiany jako rozstrzygnięcie postępowania przetargowego. 5) Początek etapu Realizacja zadania rozumiany jako podpisanie umowy. 6) Koniec etapu Realizacja zadania rozumiany jako realizacja ostatniej płatności. 7) Wartość zadania w podziale na wydatki kwalifikowane i nie kwalifikowane. 8) Płatności w podziale na poszczególne kwartały. 1 Zamawiający planuje następujące wykorzystanie plików XLS do zasilania systemu LSI: 1) Na podstawie zgłoszenia Beneficjenta użytkownik systemu generuje plik XLS zawierający dane z harmonogramu zapisane w systemie. 2) Beneficjent dokonuje w wygenerowanym Pliku XLS zmian poszczególnych wartości (np. daty Koniec etapu procedura przetargowa. 3) Beneficjent przekazuje zmieniony Plik XLS do użytkownika. 4) Użytkownik aktualizuje harmonogram poprzez załadowanie pliku XLS do Systemu LSI. Podejście takie wymaga przygotowania odpowiednich zabezpieczeń i mapowania dla generowanych przez system plików XLS. Pierwsze ładowanie danych dotyczących harmonogramów odbywać się będzie po wypełnieniu przez Beneficjentów plików XLS nie zawierających żadnych danych. 9

10 Uwaga: na potrzeby budowy Systemu LSI przyjmuje się, że Koniec etapu procedura przetargowa oraz Początek etapu Realizacja zadania są tożsame. Dla typów danych określonych w pkt. 3-6 i 8 konieczne jest zapewnienie rejestracji następujących statusów: 1) Planowany. 2) Faktyczny. Uwaga: Status Planowany winien mieć możliwość rejestracji wielu wersji, natomiast status Faktyczny rozumiany jest jako stan w którym dane zdarzenie nastąpiło. Niezależnie od powyższego konieczne jest zapewnienie możliwości wersjonowania całych harmonogramów. Dane powinny być prezentowane w formie tabelarycznej oraz wykresu Gantta. W obszarze weryfikacji i akceptacji Wniosków o Płatność, konieczne jest wprowadzanie danych o zrealizowanych poszczególnych płatnościach na rzecz Beneficjenta Import danych z GWoD, GWoP Moduł niezbędny do zarejestrowania danych wygenerowanych przez GWoD, GWoP oraz LSI - IW. Zakres danych importowanych z GWoP do Systemu LSI musi obejmować wszystkie dane, które w ramach GWoP będą rejestrowane przez Beneficjentów i przez IW (Załącznik 1b do wytycznych do sprawozdawczości POIiŚ). Zakres danych importowanych z GWoD do Systemu LSI musi obejmować wszystkie dane, które w ramach GWoD będą rejestrowane przez Beneficjentów i przez IW (Załącznik XXI i XXII do Rozporządzenia 1828/2006). Początkowy zakres pól importowanych powinien zostać opracowany na podstawie: 1) wzoru wniosku o dofinansowanie ( spx?zakladka=2#zakladka=1), 2) wzoru wniosku o płatność będącego załącznikiem do Wytycznych w zakresie sprawozdawczości POIiŚ ( oraz wzoru będącego obecnie w konsultacjach prowadzonych przez IZ ( spx?zakladka=3#). W obszarze Wniosków o dofinansowanie i Wniosków o płatność Wykonawca dostarczy obsługę tych wniosków (w tym import, weryfikacja i akceptacja pobranych danych). Zakres zamówienia obejmie migrację danych z następujących źródeł: 1) wnioski o dofinansowanie w formacie XML, 2) wnioski o płatność w formacie XML, 3) umowy o dofinansowanie wraz z aneksami, w formacie XML. Wykonawca powinien opracować projekt migracji danych, która będzie realizowana w trakcie wdrożenia Systemu. Szczegółowy zakres danych do migracji zostanie zdefiniowany przez Wykonawcę na etapie analizy biznesowej. Struktura plików XML dla wniosków o dofinansowanie i wniosków o płatność będzie określona przez Zamawiającego, a struktura plików XML dla umów o dofinansowanie będzie określona przez Wykonawcę na etapie 10

11 projektowania i budowy modułu importu danych. Wykonawca będzie zobowiązany do opracowania schematów XSD dla wniosków o dofinansowanie Moduł wymiany danych System musi posiadać moduł wymiany danych, który umożliwi obsługę procesu komunikacji z KSI i LSI-IW. Komunikacja będzie realizowana poprzez pliki XML oraz poprzez serwisy internetowe (webservice). Nie przewiduje się bezpośredniej komunikacji z innymi systemami informatycznymi bądź bazami danych. Definicje struktury dokumentów XML (XML Schema) będą określone przez Wykonawcę. W wyjątkowych przypadkach XML Schema będą wymagały uzgodnienia z administratorami istniejących LSI-IW, w szczególności z Narodowym Funduszem Ochrony Środowiska i Gospodarki Wodnej. Zakres danych importowanych do Systemu LSI będzie tożsamy z zakresem danych rejestrowanych bezpośrednio w Systemie poprzez interfejs użytkownika. Bieżące pozyskiwanie danych z LSI-IW musi obejmować wszystkie dane, które mogą być rejestrowane w Systemie LSI poprzez interfejs użytkownika. Wszystkie importowane dane będą przygotowane w postaci plików XML i importowane przez użytkowników poprzez Webservice lub ręcznie poprzez funkcję importowania. Struktura poszczególnych plików XML będzie określona przez Wykonawcę na etapie projektowania i budowy Modułu wymiany danych. Na podstawie przykładowych schematów XSD wykorzystywanych przy imporcie danych do KSI, (pliki Schematy XML do pobrania ze strony: z zakładki Analizy raporty i podsumowania / Krajowy System Informatyczny). Wykonawca będzie zobowiązany do opracowania schematów XSD dla wniosków o dofinansowanie, wniosków o płatność oraz danych z LSI-IW. Moduł powinien posiadać następujące funkcje: 1) Importowany plik XML może zawierać dane dotyczące jednego obiektu (np. wniosku o płatność) lub wielu obiektów tego samego typu (wiele wniosków o płatność różnych Beneficjentów). 2) Musi być zaprojektowany w sposób prosty i intuicyjny tj. wymiana danych powinna być możliwa do wykonania przez użytkownika nieposiadającego wiedzy informatycznej. Preferowane jest takie rozwiązanie, gdzie akcja użytkownika sprowadza się do wskazania pliku XML, który zamierza importować do LSI. 3) Importowane dane podlegają walidacji podczas procesu importu. W przypadku niepomyślnej walidacji odrzucane są tylko rekordy niespełniające założonych reguł. Pozostałe rekordy z importowanego pliku przechodzą do kolejnego etapu przetwarzania, 4) Rekordy odrzucone podczas importu zapisywane są w oddzielnym pliku. 5) System będzie posiadał ekran operatora, gdzie dla określonych grup obiektów możliwa będzie modyfikacja (edycja) odrzuconych rekordów. Po modyfikacji danych, System umożliwi ponowne zaimportowanie danych do Systemu. 6) Wszystkie operacje importu są rejestrowane w logu importu. Log importu zawiera informacje od początku działania Systemu. Log importu zawiera co najmniej następujące informacje: a) Data i godzina rozpoczęcia operacji importu, b) Login użytkownika wykonującego operację, c) Identyfikacja projektu, d) Typ importowanych danych (np. wniosek o płatność), 11

12 e) Liczba importowanych rekordów w pliku XML, f) Liczba rekordów, które poprawnie przeszły etap walidacji, g) Liczba rekordów, które nie przeszły etapu walidacji, h) Informacja o błędach dla każdego odrzuconego rekordu, w logu znajduje się informacja o polu (danej atomowej), która nie spełniła reguł walidacji oraz opis błędu, i) Data i godzina zakończenia operacji importu, j) Ogólny status operacji. Log importu jest wyświetlany (i na życzenie drukowany) użytkownikowi wykonującemu import danych, 7) Import danych kończy się potwierdzeniem przez użytkownika poprawności operacji importu. Po etapie walidacji, importowane rekordy mają status robocze i nie stanowią jeszcze integralnej części z pozostałymi danymi w Systemie. System umożliwia przegląd danych będących w trybie roboczym. Użytkownik potwierdza poprawność importu wybierając przycisk Import danych zakończono pozytywnie. W przypadku konieczności wycofania danych użytkownik wybiera przycisk Wycofaj. W tym przypadku rekordy w trybie roboczym są usuwane z Systemu. W logu importu zapisywana jest informacja o wycofaniu ze wskazaniem, której operacji importu i których rekordów dotyczy wycofanie. 8) Pełny log importu jest dostępny dla Administratora Zamawiającego. Z logu importu nie są usuwane żadne informacje. 9) System ostrzega użytkownika w przypadku próby importu danych, które już są przechowywane w Systemie (na przykład w przypadku pomyłkowego importu drugi raz tego samego wniosku o płatność). 10) Import rekordu, który jest już przechowywany w Systemie jest dopuszczalny w trybie modyfikuj (odpowiedni znacznik przyjmuje określoną wartość). W tym przypadku poprzednie wartości rekordu zostaną zapamiętane w Systemie jako dane historyczne i będą dostępne dla Administratora Zamawiającego. Opisany wyżej mechanizm wymiany danych nie obejmuje transferu załączników (w tym skanów dokumentów papierowych). Obsługa załączników odbywa się w ramach modułu Zarządzanie dokumentami. Dodatkowo System musi umożliwiać wyeksportowanie danych do plików w formacie XML w formatach zgodnych z definicjami tych plików określonymi na potrzeby importu danych, czyli System musi umieć sam wygenerować wszystkie pliki XML, które importuje, zgodne z odpowiednimi XSD. Funkcjonalność eksportu danych powinna obejmować między innymi: 1) Wygodne określenie zakresu danych do eksportu według zadanych kryteriów. Na przykład wskazanie rodzaju obiektów do eksportu, wskazanie projektu, beneficjenta lub umowy, wskazanie czasu lub innego parametru zawężającego liczbę danych dla eksportowanych obiektów, etc. Katalog kryteriów zostanie dookreślony przez Wykonawcę na etapie analizy biznesowej. 2) Możliwość powtórzenia sesji eksportu danych dla określonego wcześniej zakresu. 3) Operacje eksportu danych powinny być rejestrowane w logu eksportu. Zakres rejestrowanych danych oraz obsługa i funkcjonalność logu eksportu powinna być 12

13 analogiczna jak dla logu importu. System musi realizować komunikację z KSI zgodnie z procedurami Interfejsu komunikacji pomiędzy Krajowym Systemem Informatycznym a lokalnymi systemami informatycznymi znajdującymi się na stronie w zakładce Analizy raporty i podsumowania / Krajowy System Informatyczny. Komunikacja następuje poprzez pliki XML, formaty plików muszą być zgodne z dokumentem Specyfikacja protokołu integracji LSI i KSI (do pobrania ze strony: w zakładce Analizy raporty i podsumowania / Krajowy System Informatyczny). Komunikacja z KSI musi być ujęta w ramach opisanych wyżej funkcjonalności Modułu wymiany danych. IW zostaną zobowiązane do dostosowania swoich systemów do wymogów zgodnie ze specyfikacją dostarczaną przez Wykonawcę w trakcie realizacji przedmiotu zamówienia. W ramach projektu Wykonawca powinien opracować i dostarczyć dokumentację techniczną, mechanizm wymiany oraz pozostałe wskazania dla tych IW, które zdecydują się na użytkowanie innego systemu niż System LSI Sprawozdawczość Moduł ten dostarcza możliwości stworzenia/zaprojektowania/edycji sprawozdań tj. przygotowywania systematycznych raportów/sprawozdań dotyczących przechowywanych w LSI danych. Ponadto moduł przygotowuje dane do przesłania m.in. do MRR. Zestawienia te powinny być generowane w określonych terminach, lub w trybie ad hoc i formatach zgodnych z zasadami sprawozdawczości określonymi w Wytycznych MRR w zakresie sprawozdawczości POIiŚ. Sprawozdania powinny być definiowane i przygotowywane na podstawie danych dotyczących obiektów gromadzonych w Systemie oraz danych dodatkowych, specyficznych dla poszczególnych sprawozdań. Dane dodatkowe powinny być również przechowywane i wersjonowane w Systemie Monitorowanie Moduł ten powinien umożliwiać wyszukiwanie wg różnych kryteriów (zapytań) np. wg IW, województw, powiatów, gmin, miejscowości, monitorowanie zarejestrowanych projektów/danych dotyczących zdarzeń w projekcie /wykonywanych prac oraz wspomagać prace użytkowników Systemu LSI, w tym sygnalizację zbliżających się zdarzeń, płatności, opóźnień i innych aktywności projektowych poprzez powiadomienia mailowe oraz monity zbiorcze przy logowaniu. Zdarzenia podlegające automatycznemu monitorowaniu, będą określone na etapie analizy biznesowej i funkcjonalnej Wymagania funkcjonalne Modułu Monitorowanie 1) Ogólne wymagania: a) Wyszukiwanie projektów wg zadanego klucza, b) Przeglądanie kart projektów i informacji o projektach, c) Bezpośredni dostęp do wszystkich obiektów/dokumentów związanych z projektem, d) Umożliwienie kontroli terminów poprzez automatyczne akcje Systemu LSI lub poprzez mechanizm filtrów, powiadomień, e) Automatyczne informowanie o terminach działań i zakończonych etapach projektów, 13

14 f) Automatyczna kontrola terminów realizacji zadań (definiowane wartości terminów w modułach Monitorowanie, Administracja Systemem LSI, Komunikacja wewnętrzna, itp.), g) Planowanie i przygotowywanie kontroli, h) Rejestrowanie kontroli i informacji pokontrolnych, nieprawidłowości, zaleceń, i) Zbieranie wskaźników projektów, j) Możliwość eksportu i zapisania danych w zestawieniach dla projektów, k) Wprowadzanie dodatkowych dokumentów do Systemu LSI w powiązaniu z projektem, l) Rejestrowanie nieprawidłowości związanych z monitorowanymi danymi, m) Utrzymanie archiwum danych (wersjonowanie). 2) Monitorowanie: a) Wyszukiwanie i zestawienie danych o projekcie, wniosku tj. przekroczonych terminach, budżetach, niezgodnościach, b) Przeglądanie harmonogramów projektów/grupowanie, c) Aktualizacja i wizualizacja postępów rzeczowych i finansowych projektów uzupełnianych danymi przez IW lub Beneficjentów, d) Nadawanie priorytetów projektom lub znaczników do szczegółowego monitorowania przez użytkowników Systemu LSI, e) Współpraca z modułem Komunikacja wewnętrzna w celu procesowania lub przesyłania informacji o danym projekcie pomiędzy użytkownikami lub grupami użytkowników, f) Agregacja danych i wartości pozycji projektowych i wskaźników (np. sumowanie wartości, liczenie wartości procentowych) wraz z utrzymaniem archiwum danych (wersjonowanie), g) Umożliwienie monitorowania wskaźników w ramach danych osi priorytetowych. 3) Kontrole : a) Planowanie Kontroli (projektów, systemowych, Rocznych Planów Działań Pomocy Technicznej) wraz z mechanizmami przypominania, b) Rejestracje Kontroli wraz z utrzymaniem archiwum danych (wersjonowanie) i. Projektów, ii. Systemowych, iii. Realizacji Rocznych Planów Działań Pomocy Technicznej, c) Obsługa kart kontroli projektu w tym rejestracja, uzupełnianie, weryfikacja terminów aktualizacja danych z kontroli wraz z zestawieniem zaleceń pokontrolnych, nieprawidłowości, dat realizacji zaleceń, d) Prowadzenie rejestru informacji i zaleceń pokontrolnych. Wyszukiwanie danych musi odbywać się poprzez określanie przez użytkownika warunków logicznych, które mają spełniać poszukiwane dane. Warunków logicznych może być wiele i muszą być łączone za pomocą operatorów logicznych (i, lub, etc). Funkcja wyszukiwania powinna pozwalać na wyszukanie fragmentu zdania lub słowa w polach tekstowych. Użytkownik powinien mieć możliwość zapamiętania w Systemie i późniejszego odszukania i ponownego użycia zdefiniowanych przez siebie warunków wyszukiwania. W wyniku wyszukania danych użytkownik otrzymuje listę dokumentów/obiektów i ma możliwość określenia sposobu sortowania i zaznaczania poszczególnych wierszy. Każda lista powstała w wyniku wyszukania dokumentów/obiektów posiada podsumowanie wszystkich kolumn zawierających kwoty. Wszystkie podsumowania powinny mieć dwie podsumy: dla wierszy 14

15 zaznaczonych i dla wierszy niezaznaczonych. Lista dokumentów/obiektów wyszukanych poprzez funkcję wyszukiwania musi mieć możliwość eksportu do pliku w formacie XLS. Funkcjonalność taka winna być dostępna dla wszystkich użytkowników Poświadczenia i deklaracje wydatków Moduł ten powinien umożliwiać wygenerowanie Poświadczeń i deklaracji wydatków, zarówno na poziomie IW jak i IP, na podstawie wniosków o płatność /Poświadczeń i deklaracji wydatków, zgodnie z następującymi wzorami: 1) Załącznik nr 2a i 2b do Zaleceń w zakresie systemu obiegu środków finansowych w ramach POIiŚ. 2) Załącznik nr 3a i 3b do Zaleceń w zakresie systemu obiegu środków finansowych w ramach POIiŚ. 3) Załącznik nr 3 do Wytycznych Ministra Rozwoju Regionalnego w zakresie warunków certyfikacji oraz przygotowania prognoz wniosków o płatność do Komisji Europejskiej w Programach Operacyjnych w ramach Narodowych Strategicznych Ram Odniesienia na lata Raporty, Statystyki, Wizualizacje graficzne Moduł ten dostarcza możliwości stworzenia/zaprojektowania/edycji raportów lub zdefiniowania systematycznych raportów, umożliwia graficzne i/lub tabelaryczne przedstawienie danych, na podstawie standardowych, lub zdefiniowanych przez użytkowników analiz. Powinien umożliwiać: analizę statystyczną na danych Systemu, wizualizację wyników w podziale na obszary (np. na tle mapy administracyjnej kraju/województwa/powiatu/gminy/ miejscowości). Wizualizacja wyników w Systemie LSI w podziale na obszary powinna być generowana w formacie wektorowym umożliwiającym zaimportowanie tak powstałej mapy do popularnych pakietów biurowych oraz dowolne skalowanie (druk wysokiej jakości). Moduł powinien umożliwiać wyświetlanie pożądanych informacji w formie numerycznej jak i graficznej (gradient, zróżnicowane kolory) w oparciu o podstawową mapę administracyjną kraju. Podział na województwa (widoczne granice państwa i województw) w przypadku wizualizacji danych dla całego kraju, podział na powiaty w przypadku wizualizacji województwa itd. Najniższy poziom gminy i miejscowości. Wykonawca zobowiązany jest zapewnić dane wektorowe podziału administracyjnego kraju i miejscowości. System powinien posiadać generator pism. Szablony pism powinny być generowane przez wybranych użytkowników. Szablony pism/dokumentów powinny być zapamiętane w Systemie i podczas generowania pisma wypełniać się danymi z bazy. Statystyki będą elementem systemu raportowego i pozwolą na agregowanie danych w standardowych zestawieniach tabelarycznych. Statystyki powinny być oparte na wszystkich danych zgromadzonych w Systemie. W obszarze statystyk moduł Raportowania powinien pozwalać na sporządzanie zestawień w dowolnym układzie i zakresie z możliwością ich publikacji dla następujących obszarów danych: 1) Ilości złożonych wniosków w całym programie, w danej osi priorytetowej, działaniu, poddziałaniu według stanu na wybrany dzień (z możliwością pokazania podstawowych danych dotyczących projektu i Beneficjenta). 15

16 2) Wartości złożonych wniosków w całym programie, w danej osi priorytetowej, działaniu, poddziałaniu według stanu na wybrany okres zapytania, z możliwością pokazania podstawowych danych dotyczących projektu i Beneficjenta). 3) Typu złożonych wniosków. 4) Lokalizacji geograficznej złożonych wniosków. 5) Ilości/wartości wniosków poddanych poszczególnym etapom oceny w danej osi priorytetowej, działaniu, poddziałaniu według zadanych terminów z informacją o wyniku i statusie oceny. 6) Poziomu dofinansowania (procentowo i wartościowo) wniosków, w danej osi priorytetowej, działaniu, poddziałaniu według stanu na wybrany dzień. 7) Lokalizacji wniosków poddanych poszczególnym etapom oceny ze względu na siedzibę Beneficjenta, lokalizację IW, w podziale na powiaty i gminy. 8) Lokalizacji wniosków poddanych poszczególnym etapom oceny ze względu na miejsce realizacji projektu. 9) Zestawienia statusów na jakim etapie oceny znajduje się dany wniosek, ile wniosków oczekuje na ocenę i jak długo. 10) Informacji o wniesionych środkach odwoławczych. 11) Liczby projektów w których zostały przekroczone zadeklarowane terminy. 12) Zestawienia informacji o przeprowadzonych kontrolach w tym informacji: Nazwa beneficjenta, IW, Numer umowy o dofinansowanie, Nazwa projektu, Przedmiot zamówienia, Wartość zamówienia (w zł), Czy projekt był kontrolowany pod kątem prawidłowości stosowania ustawy prawo zamówień publicznych, Opis czy dokonane ustalenie/stwierdzone uchybienie skutkowało korektami finansowymi. 13) Liczby zarejestrowanych wniosków. 14) Liczby zatwierdzonych wniosków. 15) Zestawienia Kontroli. System musi zapewnić wizualizacje graficzne raportów/statystyk (w postaci wykresów słupkowych, wykresów kołowych i/lub innych wizualizacji m.in. w odniesieniu do podziału administracyjnego) Wymagania funkcjonalne Modułu Raporty/Statystyki/Wizualizacje graficzne Moduł powinien dostarczać 3 podstawowe obszary funkcjonalne: tworzenie, edycję i rozwój raportów, gotowe predefiniowane raporty Systemu LSI oraz wizualizacje graficzne. Powinien istnieć podział między użytkowników z uprawnieniami do tworzenia rozbudowanych raportów (maksymalnie 5) i użytkowników końcowych. Podstawowe wymagania modułu raportującego dla obu grup użytkowników powinny obejmować: 1) Dostarczenie gotowych raportów, szablonów raportów. 2) Dostarczenie mechanizmu tworzenia wyrażeń filtrujących, w tym nakładanie na zestawienie kilku filtrów jednocześnie oraz listowania wyników zapytań w postaci tabelarycznej. 3) Raporty powinny być przygotowywane w trybie WYSIWYG (What you see is what you get). 4) Generacji raportu w zakresie informacji o statusie i danych projektu po wskazaniu konkretnego projektu, którego ma dotyczyć oraz określeniu zakresu danych do umieszczenia w nim. 16

17 5) Dostarczyć mechanizm parametryzacji raportu (zdefiniowanie odmiennych wartości parametrów w polach raportu np. zakresy dat, obszary administracyjne, itp.). 6) System powinien umożliwić publikację raportów w podstawowych formatach plików np. XLS, PDF, XML, HTML, DOC, RTF. 7) Moduł powinien umożliwiać prezentowanie zestawień graficznych (np. słupkowych, liniowych, kołowych, innych) dla wszystkich raportów i statystyk, np. przedstawienie danych z uwzględnieniem podziału administracyjnego. 8) Przy wizualizacji tabelarycznej raportu udostępnienie edycji wyników raportowych (np. ukrywanie, przestawianie kolumn). 9) Udostępnianie danych w postaci pozwalającej na ewentualne powiadomienia użytkowników Systemu o krytycznych elementach raportu (np. uwidocznienie przekroczenia dat, braki w aktualizacji danych itp.). 10) Integrowanie się z systemem komunikacji w celu uruchomienia powiadomień i przesłania informacji do określonych grup lub użytkowników. 11) Dostarczenie funkcji klawiszy decyzyjnych. Zamawiający nie dopuszcza konieczności instalacji aplikacji desktopowych dla użytkowników końcowych z wyłączeniem wybranych stanowisk (maksymalnie 5) pozwalających na tworzenie rozbudowanych raportów i definiowanie szablonów pism. Ponadto podstawowe wymagania modułu raportującego dla użytkowników z uprawnieniami do tworzenia rozbudowanych raportów (maksymalnie 5) powinny obejmować: 1) Możliwość tworzenia nowych i edycji starych szablonów raportów, zapytań do Systemu LSI, dodawania wyrażeń matematycznych i logicznych (funkcjonalność powinna być dostępna dla użytkowników nie posiadających szczegółowej wiedzy informatycznej). 2) Możliwość planowania terminów generacji cyklicznych raportów oraz generowania raportów ad hoc. 3) Możliwość definiowania sposobu wizualizacji graficznej statystyk i raportów (np. format wykresów słupkowych, wykresów kołowych, wizualizacji w odniesieniu do podziału administracyjnego) z wykorzystaniem gotowych komponentów graficznych. Nowo utworzone szablony raportów powinny trafiać do repozytorium dokumentów i być dostępne dla wszystkich użytkowników Komunikacja wewnętrzna Moduł Komunikacji wewnętrznej LSI powinien pozwalać na przekazywanie informacji do wybranych użytkowników lub grup użytkowników. Za pomocą tego narzędzia możliwe będzie przekazywanie informacji lub wykonywanie notatek dotyczących poszczególnych obiektów Systemu, w tym powiadamianie o kluczowych zadaniach z cyklu życia projektu. W przypadku zdarzenia w projekcie, lub opóźnienia tego zdarzenia, System winien w sposób automatyczny powiadomić wskazanych użytkowników o tym zdarzeniu / opóźnieniu Zarządzanie dokumentami Moduł powinien umożliwić pozyskiwanie dokumentów elektronicznych (takich jak obrazy, dokumenty aplikacji biurowych, skany faktury i inne) oraz zarządzanie nimi. Obsługa dokumentów zbieranych dla obiektów oraz ich odpowiednie przyporządkowanie. 17

18 Moduł ten powinien być integralną częścią pozostałych modułów tak by umożliwiał z każdego wymaganego formularza wprowadzenie dokumentu lub uzyskanie podglądu dokumentów będących elementami obiektu. Moduł powinien charakteryzować się następującymi cechami i umożliwiać: 1) Zapisywanie dokumentów elektronicznych (pliki elektroniczne, skany) w centralnym repozytorium. 2) Rejestrowanie i obsługę wielu typów dokumentów (dokumentów Beneficjentów do wniosku, umów, faktur, innych typów dokumentów). 3) Wyszukiwanie dokumentów po zadanych kryteriach (np. filtrowanie listy dokumentów). 4) Przeglądanie dokumentów w wielu formatach (np. DOC, RTF, XLS, TIF, JPG, PDF). 5) Integrację z pozostałymi modułami Systemu LSI poprzez dedykowaną zakładkę (np. poprzez filtr wyszukiwania, okno listy dokumentów spełniających dane kryteria lub będących częścią wniosku/umowy, okno przeglądania dokumentów itp.). 6) Dodawanie dokumentów do listy załączników danego obiektu. 7) Zarządzanie wersjami dokumentów. 8) Śledzenie historii zmian dotyczącej dokumentów i danych opisowych. Dołączanie dokumentów elektronicznych do Systemu powinno umożliwić zmianę formatu i rozdzielczości podczas ładowania pliku. Format pliku i jego rozdzielczość powinny być przypisane do rodzaju dokumentu. Poziomy rozdzielczości dla poszczególnych dokumentów zostaną określone w trakcie analizy biznesowej. Dla Administratorów Zamawiającego powinna być możliwość przyjmowania innych rozdzielczości. Należy uwzględnić możliwość ładowania kilku załączników danego rodzaju (np. 3 decyzji lokalizacyjnych) oraz możliwość wersjonowania plików. Wykonawca dokona uzupełnienia załączników historycznych przekazanych przez Zamawiającego, dotyczących następujących dokumentów: 1) Załączników do wniosków o dofinansowanie. 2) Załączników do wniosków o płatność. 3) Załączników do umów o dofinansowanie i aneksów. Zestaw załączników zostanie przekazany przez Zamawiającego przed rozpoczęciem budowy modułu Zarządzanie dokumentami, a następnie zostanie uzupełniony o załączniki, związane z dokumentami zarejestrowanymi w trakcie budowy modułu Zarządzanie dokumentami Przykładowe typy przechowywanych dokumentów: Poniżej przedstawiono przykładowe typy dokumentów dotyczące prowadzonych konkursów, które będą załączone w ramach rejestracji projektów. Pojedynczy dokument może być w praktyce przechowywany w wielu plikach. 1) Studium wykonalności - (aktualne, przygotowane zgodnie kierunkowo z zakresem studium wykonalności dla odpowiedniego działania w ramach PO IiŚ). Wszystkie tabele finansowe w wersji elektronicznej powinny zostać zapisane w formacie XLS i zawierać aktywne formuły. Studium wykonalności powinno zawierać mapę lokalizacji projektu (zalecana skala 1:25 000). 2) Deklaracja instytucji wraz z mapą - Deklaracja instytucji odpowiedzialnej za monitoring obszarów Natura 2000 wraz z mapą w skali 1: (lub w większej) określającą 18

19 lokalizację projektu oraz obszarów Natura Wzór deklaracji stanowi załącznik I do Załącznika XXI Rozporządzenia Rady (WE) 1828/ ) Dodatkowa dokumentacja oceny oddziaływania na środowisko - Dokumentacja związana z przeprowadzonym postępowaniem ws. oceny oddziaływania na środowisko, zgodna z dyrektywą Rady z dnia 27 czerwca 1985r. nr 85/337/EWG, dyrektywą Rady z dnia 21 maja 1992r. nr 92/43/EWG, dla wszystkich zadań objętych projektem (dokumenty wskazane w punkcie F3.2.2 wniosku) kopie poświadczone za zgodność z oryginałem. 4) Decyzje lokalizacyjne - Wykaz prawomocnych decyzji lokalizacyjnych (Warunki zabudowy i zagospodarowania terenu/ Ustalenie lokalizacji inwestycji celu publicznego) lub/ i uchwał zatwierdzających miejscowe plany zagospodarowania przestrzennego (dla całego zakresu przedsięwzięcia). 5) Pozwolenia na budowę - Wykaz pozwoleń na budowę. 6) Harmonogram - Harmonogram realizacji projektu (wykres Gantta). 7) Wykaz zamówień publicznych, oświadczenia o SIWZ - Wykaz zamówień publicznych wraz z oświadczeniem wnioskodawcy o posiadaniu SIWZ dla wskazanych zamówień i oświadczeniem, że wszystkie zamówienia dokonywane były / będą na zasadach oraz w trybie ustawy Prawo Zamówień Publicznych (z wyjątkiem ustawowo wyłączonych). 8) Oświadczenia o posiadaniu procedur - Oświadczenie wnioskodawcy, iż posiada wewnętrzne procedury dla zamówień, w przypadku których nie stosuje się ustawy Prawo Zamówień Publicznych. 9) Oświadczenie wkładu własnego - Oświadczenie wnioskodawcy o zapewnieniu zabezpieczenia wkładu własnego. 10) Porozumienie - Porozumienie zawarte pomiędzy wnioskodawcą a podmiotem, który jest upoważniony do ponoszenia wydatków kwalifikowanych w ramach danego projektu (o ile takie porozumienie zostało zawarte) kopia poświadczona za zgodność z oryginałem. 11) Status spółki - Statut, akt powołujący spółkę/ jednostkę/ związek oraz wypis z KRS (aktualny) - jeśli dotyczy. 12) Uchwała rady - Uchwała Rady Gminy lub organu założycielskiego upoważniająca do złożenia wniosku oraz przyjęcia do realizacji przedsięwzięcia. 13) Oświadczenie o strukturze - Oświadczenie o strukturze organizacyjnej Jednostki Realizującej Projekt (o ile została powołana). 14) Oświadczenie wnioskodawcy o nie wykluczeniu - Oświadczenie wnioskodawcy o nie wykluczeniu z ubiegania się o dofinansowanie na podst. art. 211 ustawy z dnia 30 czerwca 2005 o finansach publicznych. 15) Oświadczenie o kwalifikowalności VAT - Oświadczenie o kwalifikowalności VAT zgodnie z Wytycznymi w zakresie kwalifikowania wydatków w ramach PO IiŚ. 16) Oświadczenie poprawności wydatków - Oświadczenie wnioskodawcy potwierdzające, że wydatki zaliczone do kwalifikowanych poniesione przed złożeniem wniosku przez inny podmiot, zostały poniesione zgodnie z zasadami kwalifikowania wydatków oraz przyjęcie odpowiedzialności za prawidłowe poniesienie tych wydatków. 17) Oświadczenie o niewspółfinansowaniu - Oświadczenie wnioskodawcy o niewspółfinansowaniu projektu z innych instrumentów UE. 18) Oświadczenie o planie inwestycyjnym - Oświadczenie gminy o zapisie planowanej inwestycji w wieloletnim planie inwestycyjnym gminy lub w uchwale budżetowej w załączniku dotyczącym wieloletnich programów inwestycyjnych (o ile dotyczy). 19) Oświadczenie dotyczące gruntu - Oświadczenie wnioskodawcy o posiadaniu prawa do dysponowania gruntem. 20) Oświadczenie poprawności danych - Oświadczenie wnioskodawcy, iż informacje zawarte we wniosku i jego załącznikach są zgodne ze stanem prawnym i faktycznym oraz że przedłożone dokumenty są kompletne. 19

20 21) Oświadczenie o efektywności energetycznej - Oświadczenie wnioskodawcy o zapewnieniu efektywności energetycznej zaproponowanych rozwiązań technicznych. 22) Oświadczenie o systemie księgowym - Oświadczenie wnioskodawcy o posiadaniu odrębnego systemu księgowego lub stosowaniu odpowiedniego kodu księgowego dla wszystkich operacji związanych z projektem (nie stosuje się w przypadku projektów zrealizowanych przed złożeniem wniosku o dofinansowanie). 23) Oświadczenie o procedurach - Oświadczenie wnioskodawcy o posiadaniu i stosowaniu procedur. 24) Oświadczenie o dokumentacji przetargowej - Oświadczenie wnioskodawcy o posiadaniu dokumentacji przetargowej. 25) Oświadczenie o współfinansowaniu - Oświadczenie wnioskodawcy o współfinansowaniu środków trwałych. 26) Oświadczenie o kontroli - Oświadczenie o wyrażeniu zgody na poddanie się kontroli (dot. projektów, których realizacja rozpoczęła się przed złożeniem wniosku o dofinansowanie). 27) Wykaz aglomeracji projektu - Wykaz aglomeracji objętych projektem wraz z powołaniem na aktualne rozporządzenie wojewody i oświadczenie, że zakres projektu jest zgodny z Metodyką wyznaczania w ramach aglomeracji zakresu sieci kanalizacyjnej, która może być objęta finansowaniem z Funduszu Spójności. 28) Karta oceny projektu - Dokument opisujący szczegóły oceny projektu. 29) Lista sprawdzająca - Dokument opisujący szczegóły oceny projektu dla każdego etapu oceny. Poniżej przedstawiono przykładowe typy dokumentów dotyczących umowy: a) Umowa, b) Opis projektu, c) Harmonogram projektu - Pozwolenia i decyzje administracyjne, Przetargi ogłoszenia, rozstrzygnięcia, Kontrakty wartość całkowita, kwalifikowalna, współfinansowanie, finansowanie, etapy realizacji jeśli wskazane tzw. kamienie milowe, rozpoczęcie robót, d) Plan finansowania Projektu, e) Plan wystąpień o dofinansowanie, f) Oświadczenie o kwalifikowalności VAT - Oświadczenie o kwalifikowalności VAT zgodnie z Wytycznymi w zakresie kwalifikowania wydatków w ramach PO IiŚ, g) Zestawienie wskaźników monitorowania projektu. Dla pozostałych obiektów typy dokumentów zostaną zdefiniowane przez Wykonawcę na etapie analizy biznesowej i funkcjonalnej Administracja Systemem LSI Moduł powinien umożliwiać Administratorowi Zamawiającemu konfigurowanie, zakładanie kont użytkowników i zarządzanie nimi. Udostępnianie funkcjonalności użytkownikom przypisywanie profili dostępowych, zarządzanie zabezpieczeniami, zarządzanie i administrowanie danymi Systemu. Przy zakładaniu nowego konta użytkownika, powinna istnieć możliwość skopiowania uprawnień już istniejącego konta użytkownika. Moduł Administracji powinien zapewnić minimum następujące podstawowe wymagania funkcjonalne: 1) Możliwość definiowania/edycji użytkowników, ról, profili, grup dla użytkowników. 20