bip.ncbr.gov.pl€¦ · Web viewz powszechnych języków/środowisk programistycznych: C/C++,...

Załączniki do ogłoszenia - postępowanie nr 61/12/DK pn.: Zakup, dostosowanie do potrzeb NCBR poprzez parametryzację i wykonanie dodatkowych

komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP)---------------------------------------------------------------------------------------------------------------------

Spis treściZałącznik nr 1 do Ogłoszenia (OPZ) 21. Przedmiot zamówienia 22. Cel realizacji zamówienia 33. Słownik pojęć 34. Cel i zakres niniejszego dokumentu 45. Założenia i ograniczenia projektowe 4

5.1 Obowiązujące przepisy prawa 45.1 Założenia projektowe 6

6. Wymagania ogólne dla Systemu i platformy hostingowej 6

6.1 Integracja ze środowiskiem Zamawiającego i innymi bazami danych 66.2 Dostępność i niezawodność 76.3 Kompletność i skalowalność rozwiązania 76.4 Wymagania krytyczne w zakresie infrastruktury hostingu 86.2 Wymagania dotyczące utrzymania 96.3 Zarządzanie procesem wdrożenia 10

7. Wymagania funkcjonalne dla Systemu 108. Bezpieczeństwo informacji 229. Wymagania niefunkcjonalne 2410. Wymagania w zakresie dokumentacji 24

10.2 Wymagania ogólne 2410.3 Dokument Zarządczy 2510.4 Projekt techniczny 2610.5 Dokumentacja eksploatacyjna 2610.6 Dokumentacja – Instrukcja Użytkownika Końcowego i Zewnętrznego 2710.7 Dokumentacja powykonawcza 27

11. Szkolenia i przekazywanie wiedzy 28

11.1 Wymagania ogólne w zakresie szkoleń dla pracowników Zamawiającego 2811.2 Materiały szkoleniowe korzystania z systemu dla użytkowników zewnętrznych 29

12. Etapy i terminy realizacji zmówienia 2913. Akceptacja i zakończenie 3114. Opieka powdrożeniowa 3215. Serwis gwarancyjny 3216. Wykaz załączników do OPZ 34Załącznik 1 do OPZ 35

I. SWP - wymagania krytyczne 35II. Spis funkcjonalności istotnych, dotyczących SWP na dzień złożenia oferty 63III. Spis funkcjonalności dodatkowych, dotyczących SWP na dzień złożenia oferty 68

Załącznik 2 do OPZ 71Załącznik 3 do OPZ 72Załącznik 4 do OPZ 78Załącznik nr 2 do Ogłoszenia 79Załącznik nr 3 do Ogłoszenia 80Załącznik nr 4 do Ogłoszenia 81Załącznik nr 5 do Ogłoszenia 83Załącznik nr 6 do Ogłoszenia 86

str. 1



Załącznik nr 1 do Ogłoszenia (OPZ)

Szczegółowy opis przedmiotu zamówienia

1. Przedmiot zamówienia

Przedmiotem zamówienia jest

A. zakup i wdrożenie w NCBR gotowego, zunifikowanego, wdrożonego i eksploatowanego już na rynku systemu informatycznego EZD (Elektroniczne Zarządzanie Dokumentacją), który w dniu złożenia oferty musi spełniać co najmniej wszystkie wymagania krytyczne określone przez NCBR.,

B. zaprojektowanie i wdrożenie dodatkowych komponentów EZD, na zamówienie i zgodnie z wytycznymi NCBR. Szczegółowy opis wymaganych funkcjonalności znajduje się w dalszej części niniejszego dokumentu,

C. świadczenie usług hostingowych ww Systemu, w dalszej części zwanego Systemem SWP (System Wspomagania Pracy).

Przedmiot zamówienia obejmuje w szczególności:

a. dostawę licencji, instalację i uruchomienie oprogramowania niezbędnego do prawidłowego działania Systemu, będącego przedmiotem zamówienia na infrastrukturze Wykonawcy SWP – uruchomienie usługi hostingu,

b. wykonanie analizy przedwdrożeniowej mającej na celu uzyskanie wiedzy niezbędnej do właściwego zaprojektowania i pełnego wdrożenia Systemu zgodnie z potrzebami i oczekiwaniami Zamawiającego; wraz z określeniem szczegółowej koncepcji wdrożenia systemu,

c. zarządzanie procesem wdrożenia, między innymi opracowanie szczegółowego harmonogramu prac związanych z realizacją umowy, podziałem prac na etapy, które będą jednocześnie etapami rozliczeniowymi z Zamawiającym na podstawie protokołów odbioru produktów cząstkowych,

d. opracowanie, uzgodnienie z Zamawiającym i uruchomienie funkcjonalności Systemu zgodnie z harmonogramem i dokumentem analitycznym,

e. zaimplementowanie w Systemie zestawień, wydruków, konfiguracji i parametrów przekazanych przez Zamawiającego,

f. integrację Systemu ze wskazanymi systemami Zamawiającego, których funkcje nie zostaną zastąpione przez System, w tym:

środowisko Zamawiającego: Novell (edirectory) v. 8.8 lub Active Directory, GrupWise v.2012, ZenWorks v.11

system kadrowo-płacowy system finansowo-księgowy baza danych finansowych

str. 2



system obsługi czynności kancelaryjnych intraDOK (lub w zależności od oferty – migrację i konwersję danych z tego systemu do Systemu)

g. migrację i konwersję danych z obecnie eksploatowanych przez Zamawiającego systemów do nowego Systemu, w zakresie danych realizowanych przez funkcje, które zostaną zastąpione nowym Systemem. Zakres migracji danych zostanie uzgodniony w procesie analizy

h. integrację Systemu z zewnętrznymi systemami, w tym: ePUAP - wraz z możliwością dwukierunkowej, automatycznej wymiany

korespondencji z Elektroniczną Skrzynką Podawczą NCBR i skrzynkami osób uprawnionych do reprezentowania wnioskodawcy/wykonawcy projektu na ePUAP

z bazą danych CEIDG, pod warunkiem uruchomienia i udostępnienia przez Ministerstwo Gospodarki odpowiednich konektorów w czasie trwania umowy wdrożeniowej lub utrzymaniowej na SWP

i. opracowanie dokumentacji powdrożeniowej i pełnej dokumentacji w zakresie wdrożenia Systemu

j. szkolenie użytkowników i administratorów do efektywnej pracy w Systemie, a administratorów do skutecznego zarządzania Systemem, jego konfiguracją i parametryzacją

k. przygotowanie instrukcji/materiałów do samokształcenia dla użytkowników zewnętrznych (wnioskodawcy, wykonawcy projektów, eksperci)

l. udzielenie/sprzedaż bezterminowej licencji na korzystanie z całego Systemu, oprogramowania bazodanowego oraz wszelkiego innego oprogramowania niezbędnego do prawidłowego działania całego Systemu

m. przeniesienie majątkowych praw autorskich do wszystkich komponentów oprogramowania powstałego na zlecenie Zamawiającego

n. świadczenie usług hostingu platformy, na której został uruchomiony Systemo. świadczenie usług serwisu gwarancyjnego i pogwarancyjnego na wdrożony System wraz

z usługami dodatkowymi

2. Cel realizacji zamówienia

Celem realizacji zamówienia jest uzyskanie jednolitego, bezpiecznego, dostępnego i niezawodnego pod względem funkcjonalnym Systemu Informatycznego Wspomagającego Procesy przebiegające w NCBR , w szczególności:

procesy zarządcze procesy główne (wynikające z Ustawy o NCBR), procesy główne plus (wynikające z Ustawy i porozumień) w tym między innymi

procesów dotyczących POIG, POKL i POIŚ oraz programów międzynarodowych. procesy wspomagające

3. Słownik pojęć

System – System Informatyczny Wspomagający Pracę NCBR EZD – Elektroniczne Zarządzanie Dokumentacją JRWA – Jednolity Rzeczowy Wykaz Akt

str. 3


komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP)--------------------------------------------------------------------------------------------------------------------- API - (Application Programming Interface) - interfejs programowania aplikacji

– specyfikacja procedur, funkcji lub interfejsów umożliwiających komunikację z biblioteką, systemem operacyjnym lub innym systemem zewnętrznym w stosunku do aplikacji korzystającej z API

SDK - (Software Development Kit) - interfejs i zestaw narzędzi programistycznych umożliwiających komunikację i rozbudowę funkcjonalności biblioteki, systemu operacyjnego lub innego

CEIDG – Centralna Ewidencja i Informacja o Działalności Gospodarczej Zamawiający – NCBR Wykonawca SWP - podmiot, który ubiega się o udzielenie zamówienia na dostawę

i wdrożenie Systemu Informatycznego Wspomagającego Pracę NCBR (SWP) Wykonawca projektu – podmiot wybrany w drodze konkursu, z którym NCBR zawiera

umowę o wykonanie i finansowanie projektu

4. Cel i zakres niniejszego dokumentu

Celem niniejszego dokumentu jest dostarczenie wymagań dotyczących przedmiotu zamówienia, poprzez określenie:

a) cech Systemub) założeń i ograniczeń projektowych związanych z Systemem w NCBRc) wymagań ogólnych dla Systemud) wymagań funkcjonalnych Systemue) wymagań niefunkcjonalnych Systemuf) organizacji realizacji zamówieniag) wymagań odnośnie dokumentacjih) wymagań w zakresie udostępniania Systemu na urządzeniach Wykonawcy SWPi) wymagań w zakresie szkoleńj) wymagań związanych z odbiorem przedmiotu zamówieniak) wymagań dotyczących serwisu i gwarancji

5. Założenia i ograniczenia projektowe

5.1 Obowiązujące przepisy prawa

System musi być zgodny z obowiązującym ustawodawstwem, a w szczególności z:

1. Ustawą z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (tj. Dz. U. z 2002 r. Nr 101, poz. 926, z późn. zm.),

2. Ustawą z dnia 6 września 2001r. o dostępie do informacji publicznej (Dz.U. z 2001 r. Nr 112, poz. 1198 z późn. zm.),

3. Ustawą z dnia 18 września 2001r. o podpisie elektronicznym (Dz. U. z 2001 r. Nr 130, poz. 1450 z późn. zm.),

4. Ustawą z dnia 27 lipca 2001r. o ochronie baz danych (Dz. U. z 2001 r. Nr 128, poz. 1402 z późn. zm.),

5. Ustawą z dnia 18 lipca 2002r. o świadczeniu usług drogą elektroniczną (Dz.U. z 2002 r. Nr 144, poz. 1204 z późn. zm.),

str. 4



6. Ustawą z dnia 17 lutego 2005r. o informatyzacji działalności niektórych podmiotów realizujących zadania publiczne (Dz. U. z 2005 r. Nr 64, poz. 565 z późn. zm.),

7. Ustawa z dnia 14 lipca 1983 r. o narodowym zasobie archiwalnym i archiwach (t.j. Dz. U. 2002 r. Nr 171, poz. 1396)

8. Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia 30października 2006 roku w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz. U. Nr 206 poz. 1517).

9. Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 roku w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz. U. Nr 206 poz. 1518)

10. Rozporządzeniem Ministra Spraw Wewnętrznych i Administracji z dnia 2 listopada 2006 roku 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. Nr 206 poz. 1519)

11. Rozporządzeniem 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)

12. Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz.U. 2009 r. Nr 157 poz. 1240 art. 41 ust. 2)

13. Rozporządzenie ministra finansów z dnia 3 lutego 2010 r. w sprawie sprawozdawczości budżetowej (Dz. U. z 2010 r., Nr 20, poz. 103)

14. Ustawa z dnia 30 kwietnia 2004 r. o postępowaniu w sprawach dotyczących pomocy publicznej (Dz.U. 2004 r. Nr 123 poz. 1291 art. 35 pkt 1)

15. Rozporządzenie rady ministrów z dnia 7 sierpnia 2008 r. w sprawie sprawozdań o udzielonej pomocy publicznej, informacji o nieudzieleniu takiej pomocy oraz sprawozdań o zaległościach przedsiębiorców we wpłatach świadczeń należnych na rzecz sektora finansów publicznych (Dz. U. z 2008 r. Nr 153, poz. 952)

16. Ustawa z dnia 30 kwietnia 2010 roku o Narodowym Centrum Badań i Rozwoju (Dz. U. 2010 r., Nr 96 poz. 616)

17. Rozporządzenie MNiSW z dnia 9 września 2010 r. w sprawie nadania statutu Narodowemu Centrum Badań i Rozwoju (Dz. U. Nr 171 poz. 1153)

18. Rozporządzenie MNiSW z dnia 29 grudnia 2010 r. w sprawie niezbędnych elementów rocznego sprawozdania z działalności oraz rocznego i kwartalnego sprawozdania finansowego Narodowego Centrum Badań i Rozwoju (Dz. U. Nr 9 poz. 44)

19. Rozporządzenie MNiSW z dnia 28 października 2010 r. w sprawie warunków i trybu udzielania pomocy publicznej i pomocy de minimis za pośrednictwem Narodowego Centrum Badań i Rozwoju (Dz. U. Nr 215 poz. 1411)

20. Rozporządzenie MNiSW z dnia 17 września 2010 r. w sprawie szczegółowego trybu realizacji zadań Narodowego Centrum Badań i Rozwoju (Dz. U. Nr 178 poz. 1200)

21. Rozporządzenie MNiSW z dnia 4 stycznia 2011 r. w sprawie sposobu zarządzania przez Narodowe Centrum Badań i Rozwoju realizacją badań naukowych lub prac rozwojowych na rzecz obronności i bezpieczeństwa państwa (Dz. U. Nr 18 poz. 91)

str. 5



5.1 Założenia projektowe

1. Zamawiający zakłada, że w czasie trwania prac wdrożeniowych usługę zarządzania procesem wdrożenia (Project Management), w skład której wchodzi także obsługa administracyjna zespołów zaangażowanych we wdrożenie realizuje Wykonawca SWP

2. W trakcie realizacji projektu Wykonawca SWP będzie stosował uznaną metodykę zarządzania projektem: PRINCE2, PMI/PMBOK lub równoważną

3. Zamawiający zakłada, że kompletny plan wdrożenia zawierający:a. harmonogram pracy projektu, b. specyfikację produktów pośrednich, c. sposób prowadzenia testówd. kryteria i zasady odbiorów, e. terminy uruchomień środowisk (testowego i produkcyjnego)f. tryb i termin zapewnienia łączności do platformy hostingowej g. warunki i sposób uruchomień komponentów produkcyjnych Systemu (wraz z należnymi

opłatami hostingowymi i utrzymaniowymi) zostaną zawarte w Dokumencie Zarządczym, uzgodnione i podpisane przez Wykonawcę SWP i Zamawiającego w terminie określonym w Umowie.

4. Zamawiający zakłada, że pod koniec każdego z etapów będą prowadzone przez użytkowników testy akceptacyjny, wg scenariuszy testowych przygotowanych przez Wykonawcę SWP.

5. Zamawiający zakłada prototypowanie komponentu Systemu: Projektowanie i generowanie formularza wniosku o dofinansowanie (pkt 7 1) 2) wymagań funkcjonalnych).

6. Wymagania ogólne dla Systemu i platformy hostingowej

6.1 Integracja ze środowiskiem Zamawiającego i innymi bazami danych

1. System musi współpracować z usługami katalogowymi Novell eDirectory (v. 8.8) lub Active Directory, z wykorzystaniem LDAP

2. System musi współpracować z systemem poczty elektronicznej NCBR, opartym na środowisku GroupWisev.2012. w zakresie obsługi powiadomień i synchronizacji kalendarzy

3. System musi zostać zintegrowany z platformą ePUAP, a także mieć możliwość dwukierunkowej, automatycznej wymiany korespondencji z Elektroniczną Skrzynką Podawczą NCBR i skrzynkami osób uprawnionych do reprezentowania wnioskodawcy/wykonawcy projektu na ePUAP

4. System musi zostać zintegrowany (odczyt danych) z bazą danych CEIDG, pod warunkiem uruchomienia i udostępnienia przez Ministerstwo Gospodarki odpowiednich konektorów w czasie trwania umowy wdrożeniowej lub utrzymaniowej na SWP

5. System musi być wyposażony w standardowe mechanizmy automatycznej wymiany informacji z innymi systemami informatycznymi (np. API, SDK).

str. 6



6.2 Dostępność i niezawodność

1. Godziny gotowości serwisowej (gotowość do przyjęcia zgłoszenia błędu produkcyjnego) określa się na 24/7/365.

2. Wymagany czas dostępności systemu w trybie on-line – 99,7 % czasu 3. System będzie pracował w reżimie operacyjnym 24/7/365.4. Dostęp do udostępnionego Systemu będzie się odbywał poprzez połączenie sieci LAN

Zamawiającego przez zestawiony tunel VPN z hostowanym środowiskiem5. System będzie dostępny z zewnątrz dla upoważnionych pracowników NCBR wyłącznie

przez połączenia VPN do sieci LAN NCBR i dalej do hostowanego środowiska i Systemu6. System musi zapewniać szyfrowanie wszystkich danych przechodzących poza obręb

segmentu sieci LAN, łączącego lokalne serwery lub serwisy z wykorzystaniem protokołu https.

7. System musi cechować się wydajnością gwarantującą efektywną i komfortową pracę przy zakładanym maksymalnym obciążeniu 500 aktywnych sesji.

8. Wykonawca SWP będzie dostarczał miesięczny raport z utrzymania Systemu. Zakres i zasady raportowania oraz format raportu zostanie uzgodniony przez strony.

9. Wykonawca SWP będzie zobowiązany do bieżącej diagnostyki Systemu. Zakres zostanie ustalony na etapie analizy szczegółowej.

10. Wykonawca SWP będzie zobowiązany do cyklicznych audytów bezpieczeństwaSystemu. Zakres oraz częstotliwość zostaną ustalone na etapie analizy szczegółowej.

11. Wykonawca SWP zapewni możliwość korzystania z konsultacji, dotyczących problemów związanych z utrzymaniem Systemu w zakresie: konsultacji w zakresie analizy problemów merytorycznych, technicznych

i organizacyjnych, które dotyczą Systemu oraz wskazania niezbędnych rozwiązań wyjaśniania zgłaszanych wątpliwości związanych z bieżącą eksploatacją Systemu optymalizacji procesów przetwarzania danych przez System konsultacji w zakresie diagnozowania źródeł awarii Systemu udzielania niezbędnej pomocy w usuwaniu skutków błędów oprogramowania Systemu

12. Wykonawca SWP zapewni odpowiednie grupy kompetencji technicznych wymaganych dla eksploatacji i utrzymania Systemu w warstwie zarówno infrastruktury, jak i oprogramowania

6.3 Kompletność i skalowalność rozwiązania

1. System musi być otwarty i skalowalny. Musi umożliwiać rozbudowę pozwalającą na dostosowanie go do wzrastających wymagań NCBR wynikających z potrzeby rozszerzania zakresu wdrożenia o kolejne procesy, wymiany danych z dodatkowymi systemami informatycznymi, tworzenia nowych formularzy, raportów i rejestrów oraz z wzrastającej ilości użytkowników. Rozbudowa ta nie może być uwarunkowana wymianą istotnych elementów architektury Systemu ani znacznymi pracami programistycznymi. Należy przyjąć, że bez wymiany sprzętu i oprogramowania System musi obsłużyć komfortową pracę do 500 aktywnych sesji i minimum 500 000 dokumentów rejestrowanych i skanowanych w ciągu roku, zakładając do 5 stron na dokument, zeskanowanych do plików PDF z jakością „grayscale 256” 200x200 dpi.

2. System musi posiadać możliwość rozbudowy o dodatkowe, niedostępne w momencie oferowania funkcje, dzięki udostępnieniu API lub SDK co najmniej w jednym z powszechnych języków/środowisk programistycznych: C/C++, Java, „.Net Framework”, PHP.

str. 7


komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP)---------------------------------------------------------------------------------------------------------------------3. System musi posiadać możliwość rozbudowy o dodatkowe interfejsy, oparte co najmniej

o standardy komunikacyjne Web Services, XML i pliki tekstowe, pozwalające na bezpośrednią i automatyczną wymianę danych z innymi systemami.

4. Architektura Systemu musi być przystosowana do integracji ze swoją repliką w zapasowym centrum danych, z możliwością definiowania kierunku replikacji (opcja)

5. System musi posiadać możliwość uruchomienia interface’u uzytkownika w wersji angielskiej; przełączanie wersji językowej: PL/EN z poziomu przeglądarki

6. Interfejs użytkownika, raporty, formularze, komunikaty, powiadomienia, alerty przekazywane użytkownikowi dowolną drogą muszą być sformułowane w języku polskim lub angielskim (w zależności od wybranej wersji językowej interface’u użytkownika)

7. Interfejs administratora i przeznaczone dla niego komunikaty, mogą być generowane w języku angielskim, (np. system operacyjny serwera, serwer WWW, środowisko API itp.)

8. System musi zapewnić sprawne funkcjonowanie mechanizmów typowych dla rozwiązań z dziedziny zarządzania dokumentami (w szczególności: prawa dostępu, hierarchia dokumentów, powiadomienia i dekretacje, wersjonowanie).

9. W zakresie możliwości podstawowych, System musi być niezależny od wyboru pakietów biurowych (edytor tekstów, arkusz kalkulacyjny itp.) służących do tworzenia i uaktualniania poszczególnych dokumentów przez użytkowników.

10. System musi utrzymywać dziennik zdarzeń i dostępu do obiektów danych, spraw i dokumentów, umożliwiający odtwarzanie historii aktywności poszczególnych użytkowników Systemu.

6.4 Wymagania krytyczne w zakresie infrastruktury i usług hostingu

6.4.1. Infrastruktura hostingu musi być wyposażona w:1. System podtrzymania zasilania UPS.2. Układ automatyki samoczynnego załączania zasilania rezerwowego w przypadku zaniku

napięcia w przyłączu energetycznym.3. Agregat prądotwórczy umożliwiający autonomiczne wytwarzanie energii elektrycznej do

zasilania infrastruktury serwerowni.4. System klimatyzacji precyzyjnej.5. System kontroli dostępu składający się z kart zbliżeniowych, czytników oraz sterowników

nadzorująco-zarządzających.6. System alarmowy służący do sygnalizacji napadu i włamania.7. System telewizji przemysłowej.8. System wykrywania pożaru.9. System gaszenia gazowego.10. Całodobowy dozór budynku, w którym znajduje się serwerownia.11. Nadzór firmy ochroniarskiej.12. Zdublowane przyłącze energetyczne.13. Niezależne łącza transmisji danych od co najmniej dwóch operatorów (Internet).14. Lokalizacja hostowanej infrastruktury musi być na terenie RP.

6.4.2. Wymagania w zakresie jakości świadczonych usług hostingowych

str. 8


komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP)---------------------------------------------------------------------------------------------------------------------1. Wykonawca powinien przestrzegać standardów bezpieczeństwa opartych na brytyjskiej

normie BS 7799 np. ISO 27001. W ramach powyższych standardów powinny być zapewnione:

a. kontrola dostępu do informacji,b. zabezpieczenia na poziomie organizacyjnym wraz z aktualną polityką bezpieczeństwa,c. zarządzanie działaniem urządzeń informatycznych,d. przestrzeganie obowiązujących procedur i przepisów prawa,e. zabezpieczenie fizyczne organizacji i otoczenia,f. zarządzanie ciągłością działania,g. znajomość i stosowanie uregulowań prawnych dotyczących wymaganych działań

zapewniających bezpieczeństwo informacji, w tym GIODO w zakresie ochrony przetwarzanych danych osobowych

2. W zakresie hostingu dodatkowo działalność Wykonawcy powinna być oparta o wytyczne normy ISO 20000 i zapewnione:a. zarządzanie ciągłością działania oraz zapewnienie dostępności usług,b. zarządzanie procesem świadczenia usług,c. zarządzanie pojemnością i wydajnością,d. zarządzenie bezpieczeństwem informacji,e. zarządzanie współpracą z użytkownikami wraz z wdrożonym oprogramowaniem do

zgłaszania błędów,f. zarządzanie konfiguracją.

6.2 Wymagania dotyczące utrzymania

Zamawiający wymaga, aby Wykonawca SWP zapewniał stosowanie w praktyce nw. procedur oraz przedłożył ich treść do wglądu Zamawiającego:

1. Fault Management

a. Wykonawca SWP zapewni realizację funkcji fault management dla Systemu, obejmującej poniższe elementy: wykrywanie, izolowanie, naprawa błędów systemu, dostosowanie zmiennych środowiskowych, utrzymanie i weryfikacja logów błędów, reagowanie lub akceptacja notyfikacji błędów, śledzenie i identyfikacja uszkodzeń, przeprowadzanie testów diagnostycznych, korygowanie błędów, lokalizowanie błędów.

b. Wykonawca SWP zapewni rozwiązanie umożliwiające wysyłanie notyfikacji wykrytych błędów do administratora aplikacji.

c. Rozwiązanie musi zapewniać możliwość filtrowania błędów, kategoryzacji błędów i definiowania akcji alarmowych.

d. Wykonawca SWP dostarczy konsolę funkcji fault management, poprzez którą administrator będzie mógł monitorować stan rozwiązania i podejmować akcje. Konsola umożliwi definiowanie akcji automatycznych dla określonych zdarzeń.

2. Configuration Management

a. Wykonawca SWP zapewni realizację procesu configuration management podczas trwania projektu, a także zapewni analogiczne narzędzia dla całego cyklu życia systemu.

str. 9



b. Wykonawca SWP zapewni narzędzia monitorowania stanu spełnienia wymagań przez system oraz narzędzia analizy wpływu wprowadzania nowych wymagań/ zmian wymagań (i odpowiednio zmian systemu) na spełnienie pozostałych wymagań.

3. Performance Management

Wykonawca SWP zapewni realizację funkcji zarządzania wydajnością.

4. System Change Control

Wykonawca SWP opracuje i uzgodni z Zamawiającym proces i procedury zarządzania zmianą

6.3 Zarządzanie procesem wdrożenia

Zarządzanie procesem wdrożenia obejmuje: planowanie, sterowanie, kontrolę etapów, wsparcie administracyjne, obsługę testów i odbiorów.

Każde zadanie w projekcie powinno być odpowiednio zaplanowane przed jego wykonaniem i udokumentowane po jego wykonaniu. Dotyczy to np. dokumentowania spotkań i podjętych w ich trakcie decyzji oraz większych zadań wdrożeniowych.

Poniżej dla przykładu przedstawiono wymagania wobec dokumentacji testów akceptacyjnych:

Scenariusze testów akceptacyjnych muszą zawierać co najmniej następujące informacje:

- Diagram kontekstowy zaproponowanego rozwiązania i model zachowania,

- Ograniczenia rozwiązania, założenia i zależności,

- Ogólną charakterystykę użytkowników,

- Specyfikację testowanych wymagań funkcjonalnych,

- Plan testów akceptacyjnych, scenariusze testowe oraz sposób oszacowania niezawodności zaproponowanego rozwiązania, w tym propozycję raportowania z testów,

7. Wymagania funkcjonalne dla Systemu1

System musi zapewnić:

Lp. Komu Co Kiedy Proces

1) Pracownikowi (Administratorowi lokalnemu)

Przygotować i uruchomić formularz wniosku o dofinansowanie

Jednokrotnie, przed otwarciem naboru w konkursie

Wybór wykonawców projektów

2) Wnioskodawcy Złożyć skutecznie wniosek o dofinansowanie

W trakcie trwania naboru w konkursie


3) Pracownikowi Zebrać wnioski o W trakcie trwania Wybór wykonawców

1 Robocze wersje procedur z powiązanymi wzorami formularzy jako ilustracja kluczowych procesów wymagających wsparcia Systemem SWP – załącznik nr 4 do OPZ

str. 10



dofinansowanie naboru w konkursie

projektów

4) Pracownikowi Ocenić formalnie wniosek o dofinansowanie

W trakcie trwania oceny formalnej wniosków


5) Pracownikowi i/lub członkom Komitetu Sterującego

Przeprowadzić proces oceny merytorycznej wniosku o dofinansowanie

W trakcie trwania wyboru wykonawców projektów

Wybór wykonawców projektów/Dostawa recenzji

6) Ekspertowi Wykonać recenzje przydzielonych wniosków


Wybór wykonawców projektów/Dostawa recenzji

7) Pracownikowi i/lub członkom Komitetu Sterującego

Tworzyć listy rankingowe do podjęcia decyzji o finansowaniu oraz inne raporty w trakcie trwania wyboru wykonawców projektów



8) Pracownikowi i Wnioskodawcy i/lub członkom Komitetu Sterującego, Zespołu Nadzorującego

Zawierać umowy z wnioskodawcami

Po decyzjach o przyznaniu dofinansowania


9) Pracownikowi i Wnioskodawcy i/lub członkom Komitetu Sterującego

Obsługiwać ścieżkę odwoławczą

Po zakończonym naborze wniosków i ich ocenach, aż do odwołań od decyzji o przyznaniu dofinansowania

Rozpatrywanie protestów i odwołań

10) Ekspertowi i/lub członkom Komitetu Sterującego

Wykonać przydzielone recenzje

Po zakończonym naborze wniosków i ich ocenach, aż do odwołań od decyzji o przyznaniu dofinansowania

Rozpatrywanie protestów i odwołań/Dostawa recenzji

11) Pracownikowi i Obsługiwać zmiany w W trakcie Nadzór nad

str. 11



Wykonawcy projektu i/lub członkom Zespołu Nadzorującego

zawartych umowach realizacji projektów

wykonaniem i finansowanie projektów

12) Wykonawcy projektu i/lub członkom Komitetu Sterującego

Składać raporty okresowe i końcowe, wnioski o płatność i zmianę w realizacji projektu

W trakcie realizacji projektów

Nadzór nad wykonaniem i finansowanie projektów

13) Pracownikowi Przyjmować raporty okresowe i końcowe, wnioski o płatność i zmianę w realizacji projektu



14) Pracownikowi Rejestrować wypłaty i zaliczki



15) Pracownikowi i/lub członkom Zespołu Nadzorującego

Analizować i kontrolować projekt na podstawie raportów



16) Pracownikowi Kwalifikować należności do windykacji



17) Pracownikowi Kwalifikować projekty do kontroli planowych i doraźnych, tworzyć raporty i sprawozdania z kontroli



18) Wykonawcy projektu

Składać sprawozdanie końcowe, raporty z etapów wdrożenia, raporty ex-post i rozliczać projekt oraz przekazywać informacje o wykorzystaniu wyników



19) Pracownikowi Przyjmować W trakcie Nadzór nad

str. 12



sprawozdanie końcowe, raporty z etapów wdrożenia, raporty ex-post i rozliczać projekt oraz przekazywać informacje o wykorzystaniu wyników

realizacji projektów

wykonaniem i finansowanie projektów

20) Ekspertowi Wykonać przydzielone recenzje (wniosków o zmianę w realizacji projektu oraz raportów okresowych i końcowych)


Nadzór nad wykonaniem i finansowanie projektów/Dostawa recenzji

21) Ekspertowi Umożliwiać współpracę z NCBR w zakresie rejestracji eksperta i zawierania umów

Na wszystkich etapach

Dostawa recenzji

22) Pracownikowi Zarządzać współpracą z ekspertami (baza ekspertów) w tym obsługiwać proces wyboru ekspertów i zawierania umów


Dostawa recenzji

23) Pracownikowi i Ekspertowi

Rozliczanie wykonanych prac zleconych ekspertowi do wykonania


Dostawa recenzji

24) Pracownikowi, Ekspertowi, Wnioskodawcy, Wykonawcy projektu

Umożliwiać komunikację w realizacji wszystkich etapów od złożenia wniosku o dofinansowanie, poprzez jego ocenę i jej udostępnienie, zawieranie umów, aż do nadzoru nad wykonaniem i finansowanie projektu oraz możliwość otrzymywania


Proces komunikacyjny: Pracownik – podmioty zewnętrzne

str. 13



powiadomień o zmianach statusów projektu

25) Pracownikowi, Ekspertowi, Wnioskodawcy, Wykonawcy projektu

Obsługiwać elektroniczny obieg dokumentów i repozytorium dokumentacji


Wybór wykonawców projektów/Nadzór nad wykonaniem i finansowanie projektów/Dostawa recenzji/Rozpatrywanie protestów i odwołań/Proces komunikacyjny: Pracownik-podmioty zewnętrzne

1) 2) Przygotowanie i uruchomienie wniosku o dofinansowanie oraz złożenie wniosku

a. System powinien zawierać narzędzia do projektowania, tworzenia i modyfikowania formularzy elektronicznych (wniosków), które będą umożliwiały wnioskodawcom zgłaszanie wniosków o dofinansowanie w ramach danego konkursu. NCBR dysponuje koncepcją uniwersalnego formularza wniosku2, na podstawie którego mogłyby powstawać kolejne formularze specyficzne dla konkursów.

b. Jednostką podlegającą parametryzacji w Systemie jest konkurs zarówno w zakresie parametrów dotyczących formularza wniosku, jak i wymaganej ilości recenzji, czasów trwania poszczególnych kroków, przypomnień, alertów, obowiązujących formularzy/wzorów dokumentów powiązanych, itp.

c. Formularz musi zapewnić możliwość złożenia wniosku o dofinansowanie w postaci elektronicznej, ze wszystkimi załącznikami, a także możliwość wydrukowania i złożenia w formie papierowej z odpowiednimi podpisami i wymaganymi załącznikami w kancelarii NCBR.

d. Formularz wniosku niezależnie od trybu postępowania powinien realizować wbudowane funkcje walidujące tak, aby umożliwić wnioskodawcy automatyczną weryfikację wprowadzonych przez niego danych (szczególnie harmonogram i kosztorys).

e. System powinien umożliwiać wersjonowanie wniosków m.in. w celu przesłania przez wnioskodawcę uzupełnień i korekt – jeśli Regulamin konkursu dopuszcza takie uzupełnienia.

f. System powinien umożliwiać odblokowywanie fragmentów złożonego wniosku w celu zwrotu do poprawy przez Wnioskodawcę

3) zebranie wniosków o dofinansowanie

2 Koncepcja nie jest ostateczna, będzie podlegała doszczegółowieniu w procesie analizy przedwdrożeniowej. Projekt formularza stanowi załącznik nr 2 do OPZ

str. 14



a. System powinien umożliwiać przeglądanie złożonych wniosków, rejestrację historii korespondencji z wnioskodawcą oraz nadawanie statusów wnioskom (automatyczne i ręczne w zależności od założeń konkursu) wraz z blokadami edycji wniosku lub jego sekcji po uzyskaniu odpowiednich statusów.

b. System powinien zapewniać możliwości raportowe w zakresie bieżącego monitorowania stanu konkursu w zakresie informacji dotyczących np. liczby zgłoszonych wniosków, tytułów zgłaszanych projektów, klasyfikacja OECD, wyszukiwanie wniosków o podobnej tematyce, po tematach projektów, głównych wykonawcach, słowach i frazach kluczowych, itp. wraz z możliwością eksportu np. do MS Excel.

4) ocena formalna wniosków

a. System powinien obsługiwać ocenę formalną wniosków poprzez udostępnianie stosownych formularzy zasilanych danymi wprost z wyników procedur walidacyjnych lub też do decyzji koordynatorów projektu. W trakcie weryfikacji formalnej pracownik działu NCBR zajmującego się organizacją konkursów może zmieniać statusy złożonych wniosków, dołączać dodatkowe dokumenty (np. dosłane w trakcie wyjaśniania ew. braków lub błędów) lub modyfikować wybrane elementy złożonego wniosku, o ile Regulamin konkursu będzie dopuszczał takie działania.

5) 6) 20) przeprowadzenie procesu oceny merytorycznej i wykonanie recenzji

a. Wybór eksperta do danego wniosku powinien inicjować proces wykonania recenzji obejmujący: zawarcie umowy z ekspertem, umożliwienie ekspertowi złożenia stosowanych deklaracji i oświadczeń, udostępnienie ekspertowi dokumentacji wniosku i formularza oceny, śledzenie stanu przebiegu procesu recenzji (tworzenie historii recenzji w odniesieniu do danego konkursu, danego wniosku i danego eksperta) oraz odbiór i rozliczenie recenzji.

b. System powinien posiadać mechanizmy umożliwiające automatyczne generowanie list ekspertów wg dziedzin, specjalizacji i innych pól bazy danych oraz słów kluczowych

c. System powinien umożliwić przypisywanie propozycji wniosków do recenzjid. System powinien umożliwiać dwuetapowy przydział wniosków do poszczególnych

ekspertów: zgłoszenie kandydatur oraz akceptację wybranych ekspertów przez Komitet Sterujący

e. System powinien umożliwiać i rejestrować korespondencję z ekspertem na poszczególnych etapach recenzowania oraz umożliwiać rejestrację przesłanej przez eksperta korespondencji papierowej.

f. Ocena eksperta dokonana przez pracownika działu NCBR zajmującego się organizacją konkursów musi być integralną częścią złożonego wniosku, przy czym zarządzanie dostępem do jej treści oraz do danych osobowych eksperta powinno być wydzielone. Dane eksperta powinny być widoczne jedynie dla wybranych użytkowników. Treść recenzji powinna być widoczna dla innej (szerszej) grupy użytkowników. Prawo wglądu w treść recenzji może być nadane wnioskodawcy – będzie nadawane na określonym etapie konkursu do wszystkich recenzji związanych z danym wnioskiem. Wnioskodawca nie może uzyskać wglądu w dane osobowe eksperta.

str. 15



g. System powinien umożliwiać generowanie raportów i zestawień, np. zbiorczych raportów wg statusów recenzji, raportów z recenzji w których nastąpiło obniżenie dofinansowania, aktualnie wykonywanych recenzji na poziomie wniosku oraz eksperta, itp.

h. System powinien mieć możliwość współpracy z innymi systemami NCBR (m.in. z systemem kadrowo-płacowym i finansowo-księgowym).

8) 11) zawieranie umów i obsługa zmian

a. System powinien wspierać proces zawierania umów z wnioskodawcami i obsługiwać zmiany umów (aneksy oraz zmiany niewymagające aneksów) m.in. poprzez wersjonowanie dokumentów, śledzenie zmian i autorów oraz tworzenie tekstów jednolitych.

b. System powinien umożliwiać walidację zmian w umowach w predefiniowalnym zakresie – wybranych komponentów/sekcji umów wraz z określaniem docelowych wartości dopuszczalnych.

c. System powinien umożliwiać dokonywanie uzgodnień wybranych sekcji dokumentów, tworzenie wersji ostatecznej oraz dołączanie podpisu elektronicznego wraz z zapisem do repozytorium dokumentacji lub wydrukowanie i podpis ręczny.

d. Dokumenty drukowane z Systemu powinny być zabezpieczone, tak aby była pewność, że strona drukująca nie dokonała zmian w stosunku do treści uzgodnionej w postaci elektronicznej.

7) 9) 10) podejmowanie decyzji o przyznaniu dofinansowania i obsługa ścieżki odwoławczej do Rady Centrum lub Komitetu Sterującego

a. Po zakończeniu ocen przez ekspertów i zebraniu kompletu informacji proces oceny wniosków kończy się wyborem wniosków/u do finansowania. System ma zapewnić w tym zakresie sprawny mechanizm wspierający pracownika Działu obsługującego organizację konkursu w wyborze najlepiej ocenionych wniosków/u i zakwalifikowania ich/go do przyznania finansowania.

b. System powinien umożliwiać zadawanie złożonych zapytań i tworzenia zalgorytmizowanych kryteriów wyboru wniosków oraz tworzenia list rankingowych.

c. Wsparcie Systemu w procesie odwoławczym powinno przewidywać powtórzenie procesu naboru/korekty/uzupełnienia wniosku wraz z procedurą oceny zależną od Regulaminu konkursu.

d. Wnioski podlegające procedurze odwoławczej oraz każdy z kroków procedury powinny być w widoczny sposób oznaczone w Systemie tak, aby w historii wniosku można było prześledzić wszystkie etapy procesu, którym podlegał wniosek – od momentu zarejestrowania i złożenia w NCBR, poprzez oceny, i procedurę odwoławczą.

e. System powinien zapewnić możliwość udostępniania wnioskodawcom treści recenzji złożonych przez nich wniosków, przy czym pracownik Działu organizującego konkurs musi mieć możliwość weryfikacji czy treść recenzji nie narusza praw osób trzecich (np. danych osobowych lub tajemnicy przedsiębiorstwa) oraz ew. usunięcia z tekstu udostępnianej wersji recenzji fragmentów, które nie powinny być ujawniane (np. dane osobowe ekspertów)

f. Wnioski po zakończonej procedurze odwoławczej w zależności od decyzji albo powinny być zarchiwizowane (decyzja negatywna) albo w przypadku decyzji pozytywnej – obsługiwane w dalszych krokach jak wnioski zaakceptowane w pierwszym terminie lub powrót na ścieżkę od miejsca złożenia odwołania

str. 16



12) 13) składanie i przyjmowanie raportów okresowych i końcowych, wniosków o płatność i zmianę w realizacji projektu

a. W zakresie nadzoru nad realizacją projektu System udostępni mechanizm składania przez Wykonawcę projektu okresowych raportów, sprawozdań w postaci stosownych formularzy.

b. System musi umożliwiać analizę i weryfikację sprawozdań Wykonawców projektów przez wielu uprawnionych pracowników NCBR (work-flow)

c. Na etapie nadzoru nad realizacją projektu System musi zapewniać możliwość wykorzystania mechanizmów dostawy recenzji

d. System musi umożliwiać pracę na pozycjach raportów– odrzucenie/akceptacja. Obsługa procesu akceptacji wybranych raportów może być wielostopniowa.

e. System musi wspierać w całości proces weryfikacji składanych raportów i procedur uruchamianych wobec wykonawcy projektu, włącznie z przedterminowym zakończeniem finansowania projektu.

f. W wybranych przypadkach może zostać wszczęta procedura weryfikacyjna wobec Wykonawcy projektu – System powinien mieć możliwość rejestracji tej procedury.

14) rejestracja wypłat i zaliczek

a. W ramach rozpoczęcia prac nad projektem przez Wykonawcę projektu - System zapewni obsługę wypłacenia Wykonawcy projektu środków finansowych oraz nadzorowanie nad okresowymi rozliczeniami finansowymi Wykonawcy projektu.

b. W zakresie wniosków o płatność system powinien umożliwiać – częściowo już na poziomie formularza do okresowego sprawozdania– rozbudowaną walidację poprawności danych wprowadzanych w poszczególne pola formularza (sprawdzanie m.in. typu danych, zakresu wartości, relacji pomiędzy poszczególnymi polami, poprawności sumowań etc.)

15) analiza i kontrola projektu na podstawie raportów

a. System powinien umożliwiać obsługę wniosków o płatność i wniosków o zmianę warunków realizacji projektu

b. System powinien umożliwiać koordynatorom projektów składanie zamówień na wykonanie przez ekspertów zewnętrznych recenzji aneksów do umów i raportów okresowych z wdrożenia ex-post. Złożone zamówienie powinno zawierać szczegóły dotyczące rodzaju pracy i projektu, który ma być przedmiotem oceny.

c. Powinna istnieć możliwość dołączenia do zamówienia (wskazania zapisanej w Systemie) dokumentacji projektu oraz formularza oceny.

d. Złożone zamówienia powinny być kierowane do ekspertów, których dane znajdują się w Bazie ekspertów

e. System powinien umożliwiać śledzenie przebiegu wykonania recenzji (aż do rozliczenia recenzji) oraz prowadzenie korespondencji z ekspertami.

f. W Systemie powinien znajdować się mechanizm pozwalający na tworzenie raportów z wykonanych recenzji w odniesieniu do rodzaju wykonanych prac, projektów będących przedmiotem oceny oraz ekspertów.

str. 17



g. W Systemie powinien być mechanizm automatycznego informowania koordynatorów projektów o przekroczonych terminach w realizacji projektu

16) kwalifikacja należności do windykacji

a. System powinien wspierać działania windykacyjne w zakresie ściągania należności od Wykonawców projektów, w szczególności tworzyć raporty zawierające listę Wykonawców projektów zobligowanych do zwrotu środków, stan rozliczeń etc.

b. System powinien umożliwiać kwalifikowanie projektów do działań windykacyjnych – wezwań lub innych działań prawnych, monitorowanie stanu spraw w tym zakresie.

c. System powinien mieć możliwość współpracy z innymi systemami Zamawiającego w tym zakresie (m.in. z systemem finansowo-księgowym).

17) kwalifikacja projektów do kontroli planowych i doraźnych, raporty i sprawozdania z kontroli

a. System powinien zapewniać możliwość utrzymywania aktualnej bazy prowadzonych przez NCBR projektów zawierającej oprócz nazwy projektu i danych wykonawców również dane pozwalające na ocenę ryzyka związanego z realizacją danego projektu takich jak: wartość projektu okres i faza realizacji, liczba aneksów, liczba wniosków o zmiany, liczba zmian kierowników zadania badawczego lub części zadania badawczego.

b. System powinien wspomagać proces kwalifikowania projektów do kontroli planowych, wspomagać wybór ekspertów finansowych, tworzenie i gromadzenie raportów i sprawozdań z kontroli, korespondencji z Wykonawcą projektu, etc.

c. System powinien zapewniać obsługę zgłoszeń projektów do kontroli doraźnej wraz z rejestracją danych dotyczących kontroli oraz jej wyników.

18) 19) składanie i przyjmowanie sprawozdań końcowych i rozliczanie projektu

a. System powinien wspierać czynności wykonywane w momencie odbioru prac projektowych i rozliczania projektu. Prace te obejmują sprawozdanie końcowe Wykonawcy projektu, ew. odwołania oraz rozlicznie finansowe i wystawienie dokumentów kwitujących projekt.

21) rejestracja eksperta w bazie

a. System powinien umożliwiać obsługę procesu rejestrowania ekspertów biorących udział w ocenie wniosków konkursowych i projektów finansowanych przez NCBR oraz procesu zawierania umów z ekspertami i rozliczenia wykonanych prac.

b. System powinien wspomagać proces wyboru eksperta do wykonania oceny (wniosku, raportu, itp.) przez analizę tematyki złożonego wniosku i dopasowanie jej do profilu eksperta oraz wykluczenie konfliktu interesów. Powinien pozwalać na udostępnianie wybranych grup tematów wniosków złożonych w danym konkursie określonej grupie ekspertów (w celu złożenia deklaracji możliwości wykonania recenzji) oraz rejestrować przebieg procesu w odniesieniu do: przesłanych grup tematów, poszczególnych tematów

str. 18



oraz danego eksperta. W przypadku ekspertów, których dane znajdują się w Bazie ekspertów, propozycje wniosków do recenzji powinny pojawiać się na koncie eksperta

c. Samodzielna rejestracja eksperta w bazie ekspertów powinna być ogólnie dostępna przez stronę internetową NCBR i zawierać szczegółowe dane dotyczące osiągnięć naukowych i kompetencji zawodowych ekspertów.

d. W bazie znajdują się rekordy danych wypełnione przez samego zainteresowanego (po zalogowaniu mogą być przez niego uzupełniane i zmieniane) oraz informacje o ekspertach wprowadzone przez pracowników NCBR, a także pozyskane z innych źródeł takich jak zewnętrzne bazy danych.

e. Baza musi być zintegrowana z informacjami o zawartych umowach i wykonanych recenzjach

f. W Systemie powinien znajdować się mechanizm pozwalający na generowanie dowolnych raportów zawierających informacje o rodzaju i ilości wykonanych prac w odniesieniu do poszczególnych inicjatyw NCBR oraz w odniesieniu do danego eksperta.

g. Funkcjonalność Systemu powinna obejmować korespondencję elektroniczną z ekspertami w sprawie aktualizacji danych zawartych w bazie ekspertów oraz organizowanych przez NCBR konkursów.

h. System powinien mieć możliwość współpracy z innymi systemami NCBR w tym zakresie (m.in. z systemem kadrowo-płacowym).

22) zarządzanie współpracą z ekspertami

a. Baza ekspertów powinna być jednym z narzędzi Systemu wspierających wybór eksperta do wykonania określonej pracy eksperckiej (przy czym system powinien umożliwiać również wybór eksperta dotychczas w bazie nie zarejestrowanego).

b. Do wyboru eksperta do wykonania określonej pracy eksperckiej System powinien umożliwić wykorzystanie dotychczas zgromadzonych danych i zachowanie dotychczasowego charakteru bazy ekspertów (ogólnej dostępności do aplikacji nowych osób). Powinien pozwalać na weryfikację złożonych aplikacji oraz wykorzystanie zawartości bazy w śledzeniu przebiegu procesów recenzowania

c. Wybór eksperta z bazy ekspertów powinien być możliwy zarówno w sposób automatyczny - przez dopasowanie zawartych w bazie danych do zawartości dokumentacji wniosku lub projektu, który ma być przedmiotem oceny, jak i w sposób polegający na definicji kryteriów wyboru.

d. W systemie powinien istnieć mechanizm umożliwiający przeglądanie zawartości bazy oraz tworzenie dowolnych raportów.

e. Historia udziału eksperta w pracach zleconych przez NCBR powinna być widoczna podczas przeglądania zawartości bazy.

f. System powinien ułatwiać zarówno tworzenie grup tematów (np. z określonej specjalności naukowej) oraz grup najbardziej kompetentnych ekspertów do danej grupy tematów. Tworzenie grup tematów powinno odbywać się przez analizę danych zawartych we wniosku konkursowym a tworzenie grup ekspertów w oparciu o dane ekspertów zawarte w systemie i w bazie ekspertów

str. 19


komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP)---------------------------------------------------------------------------------------------------------------------23) rozliczanie wykonanych prac zleconych ekspertowi do wykonania

a. System powinien umożliwić rozliczanie wykonanych przez eksperta prac na podstawie potwierdzeń/akceptacji recenzji zatwierdzanych przez pracowników Działów organizujących konkurs i biorących udział w ocenie wniosków

b. Rozliczanie prac odbywa się na podstawie przedłożonych przez ekspertów rachunków o wykonanie dzieła (umowa o dzieło), które powinny być możliwe do rejestracji w Systemie kadrowo-płacowym, a następnie po ich akceptacji i wypłacie powinny jako informacja zwrotna przekazywana interface’m, z systemu finansowo-księgowego, trafiać do Systemu celem zamknięcia zlecenia dla eksperta

24) Komunikacja: Pracownik-podmioty zewnętrzne (wnioskodawcy, wykonawcy projektów, eksperci) System powinien stanowić platformę komunikacyjną z użytkownikami/kontrahentami zewnętrznymi (wnioskodawcami, wykonawcami projektów, ekspertami, zespołami nadzorującymi, itp.) wraz z parametryzacją kalendarzy, przypomnień, alertów, itp. na poziomie konkursu.

a. Dla wnioskodawców w zakresie: składania wniosków i korekt dostępu do złożonych wniosków widoczności historii zmian oraz statusu wniosków (i innych dokumentów) interakcji z pracownikami NCBR – np. w zakresie wprowadzania zalecanych korekt wszystkie komunikaty zmiany stanów/statusów wysyłane poza System dostępne

również z poziomu platformy komunikacyjnejb. Dla Wykonawców projektów w zakresie:

składania wniosków o płatność/zaliczkę, raportów okresowych i sprawozdań dostępu do złożonych dokumentów widoczności historii zmian oraz statusów złożonych dokumentów wszystkie komunikaty zmiany stanów/statusów wysyłane poza System dostępne

również z poziomu platformy komunikacyjnejc. Dla ekspertów w zakresie:

potwierdzania zamówień/zleceń recenzji realizacji zleconych recenzji (ocen merytorycznych; ocen umów, raportów, itp.) udziału w procesie akceptacji wykonanych prac przez NCBR generowania dokumentów rozliczających wykonane prace widoczności historii pracy z NCBR termin zrealizowanej zapłaty za wykonaną recenzję (pobrany z systemu finansowo-

księgowego) wszystkie komunikaty zmiany stanów/statusów wysyłane poza System dostępne

również z poziomu platformy komunikacyjnej

str. 20


komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP)---------------------------------------------------------------------------------------------------------------------25) obsługa elektronicznego obiegu dokumentów i repozytorium dokumentacji

a. obsługa czynności kancelaryjnych System musi zapewnić rejestrowanie pism przychodzących, wychodzących oraz

wewnętrznych. System będzie realizował zakładanie spraw, teczek i podteczek oraz ich numerowania

zgodnie z JRWA. System będzie automatycznie pobierał i wstępnie dekretował dokumenty składane na

skrzynkę podawczą NCBR udostępnioną na platformie ePUAPb. dokumentowanie przebiegu załatwiania spraw

System będzie posiadał możliwości projektowania ścieżek workflow System umożliwi tworzenie własnych formularzy System będzie obsługiwał pełen proces dekretacji realizowany obecnie przez NCBR

a także proces wysyłania pism, nadzoru nad ich dostarczeniem i ewentualnym zwrotem.

System umożliwi rejestrację korespondencji przychodzącej w formie papierowej, faksem oraz elektronicznie oraz wysyłkę pism elektronicznie.

System zapewni wersjonowanie dokumentów, ich akceptację i zatwierdzanie wersji ostatecznych.

System udostępni wszystkie niezbędne raporty i rejestry taki jak „Dziennik Korespondencji”.

c. gromadzenie i tworzenie dokumentacji elektronicznej System zapewni możliwość digitalizacji korespondencji przychodzącej w formie

papierowej. System będzie wspierał archiwizację dokumentów, i zapewni pracownikom NCBR

możliwość korzystania z repozytorium dokumentów m.in. w celu tworzenia potrzebnych danemu pracownikowi podręcznych zbiorów dokumentów (linków do dokumentów przechowywanych w zbiorczym Repozytorium) ze szczególnym uwzględnieniem nietypowych uprawnień dostępowych w zależności od typu dokumentu np. dla umowy udostępnianie dla wszystkich zainteresowanych w wydzielonym sub-repozytorium, i utworzenie workflow od momentu projektu do akceptacji.

Funkcjonalności w zakresie pkt a. i c. – obługa czynności kancelaryjnych oraz gromadzenie i tworzenie dokumentacji elektronicznej (w zakresie poczty przychodzącej, wychodzącej i notatek wewnętrznych) System będzie realizował w oparciu o: integrację z systemem obsługi czynności kancelaryjnych intraDOK eksploatowanym przez

Zamawiającego3

własne komponenty funkcjonalne, jednak tylko pod warunkiem migracji wszystkich danych i parametrów konfiguracyjnych z systemu obsługi czynności kancelaryjnych intraDOK eksploatowanym przez Zamawiającego

8. Bezpieczeństwo informacji

W zakresie bezpieczeństwa informacji, System musi spełniać poniższe wymagania.

3 Specyfikacja funkcjonalności systemu intraDOK stanowi załącznik nr 3 do OPZ

str. 21



1. Integracja z platformą ePUAP.2. Możliwość zastosowania kilku mechanizmów uwierzytelniania użytkownika

w dowolnych – konfigurowalnych – kombinacjach (nazwa i hasło użytkownika w Systemie, nazwa i hasło użytkownika w usługach eDirectory i Active Directory), w tym obsługa uwierzytelniania na drukarkach NCBR i wydruki podążające za użytkownikiem (opcja).

3. Ochrona zatwierdzonych dokumentów przed nieautoryzowanymi zmianami. 4. Podział użytkowników na grupy, z możliwością przynależenia do wielu grup

równocześnie.5. Przypisanie każdemu użytkownikowi jednej lub kilku ról.6. Zarządzanie użytkownikami oraz grupami w zakresie ustalania praw dostępowych.7. Ustalanie grup i rodzajów dokumentów z przypisaniem potrzebnych uprawnień do ich

odczytu i edycji.8. Pełna identyfikowalność użytkowników i przypisanie odpowiedzialności za działania

wykonane w Systemie.9. Blokowanie dostępu określonych użytkowników do zasobów Systemu.10. Zdefiniowane dla każdego użytkownika poziomy dostępu do dokumentów.11. Wyświetlanie szczegółowych danych o użytkowniku, w tym jego uprawnienia, wykonane

operacje, ważność poświadczenia bezpieczeństwa, obiegi, w których uczestniczy, etc.12. Zabezpieczenie przed nieautoryzowanym dostępem na poziomie klienta.13. Zabezpieczenie przed nieautoryzowanym dostępem na poziomie serwera.14. Dostosowywanie menu aplikacji użytkownika Systemu do jego roli w Systemie i

procesie biznesowym (widoki). Należy usunąć z menu nieużywane pozycje i skróty.15. Dziennik aktywnych zadań Systemu dostosowany do roli użytkownika w Systemie

i procesie biznesowym. Mechanizm musi być zintegrowany z Systemem uprawnień i umożliwiać użytkownikowi dostęp tylko do dozwolonych dla niego rekordów i atrybutów.

16. Raporty Systemu dostosowane do roli użytkownika w Systemie. Mechanizm zintegrowany z systemem uprawnień i umożliwiający użytkownikowi dostęp tylko do dozwolonych dla niego raportów.

17. Słowniki Systemu odpowiednie do roli użytkownika w Systemie. Mechanizm musi być zintegrowany z systemem uprawnień i umożliwiać użytkownikowi dostęp tylko do dozwolonych dla niego słowników i danych słownikowych.

18. Odpowiedni poziom uprawnień oraz dostęp do dokumentów i ich atrybutów dla osób zarządzających (dekretujących) w procesie dekretacji.

19. Transakcyjność Systemu w każdym z modułów/funkcjonalności Systemu.20. Możliwość odzyskania wszystkich możliwych do odczytania transakcji w przypadku

awarii.21. Współbieżny dostęp do tych samych danych w trybie odczytu, blokada przy modyfikacji.22. Szyfrowanie wszystkich informacji przesyłanych poza obręb serwerowego segmentu sieci

LAN.23. Pełen audyt/ rozliczalność – możliwość uzyskania informacji o dowolnej operacji

w Systemie, osobach przydzielonych do danego zadania, itp.24. Możliwość wybierania typów zdarzeń logowanych w dzienniku Systemu, z możliwością

wyboru co najmniej następujących operacji w Systemie (z godziną wystąpienia i wykorzystanym kanałem dostępu):a) zalogowania użytkownika do Systemu,

str. 22



b) wylogowania użytkownika z Systemu,c) nieudanych prób logowania do Systemu,d) dostępu do informacji,e) modyfikacji informacji,f) drukowanie informacji,g) nieudanych prób modyfikacji informacji,h) modyfikacji konfiguracji Systemu.

25. Brak możliwości modyfikowania i usuwania logów systemowych.26. Logowanie prób modyfikowania i usuwania logów systemowych.27. Przechowywanie logów systemowych przez min. 2 lata w tym min. 60 dni w trybie

on-line.28. Interfejs do przeszukiwania logów według zadanych kryteriów.29. Prowadzenie dziennika zdarzeń. Wszystkie operacje dotyczące obiegu dokumentów

zapisywane w Systemie w sposób umożliwiający określenie kolejności działań i wykonawców czynności

30. Rejestrowanie wszelkich operacji wykonywanych na dokumentach w Systemie, wraz przebytymi ścieżkami akceptacji, co w szczególności umożliwi raportowanie działań podejmowanych przez danego użytkownika, bądź w danej lokalizacji (jednostce, dziale, kancelarii).

31. Generowanie raportu o prawach dostępu użytkowników.32. System zabezpieczeń oparty o mechanizm ról, pozwalający określić możliwość

wykonania konkretnych funkcji w Systemie33. Możliwość budowania hierarchicznego modelu uprawnień.34. Możliwość określenia dokładnych praw na poziomie pojedynczego użytkownika,

pojedynczego dokumentu oraz pojedynczej funkcji Systemu.35. Integracja z eDirectory i Active Directory na poziomie użytkowników i grup. Zmiany

w katalogu użytkowników powinny być automatycznie adoptowane przez Repozytorium dokumentów.

36. Możliwość definiowania grup bezpieczeństwa dla dokumentów. Dany dokument może należeć jedynie do jednej grupy bezpieczeństwa.

37. Centralne zarządzanie wieloma repozytoriami i archiwami, zarówno elektronicznymi jak i tradycyjnymi.

38. Gwarancja niezmienności zarejestrowanych dokumentów w czasie ich życia.39. Automatyzacja zadań związanych z polityką przechowywania – min. przenoszenie do

archiwów i pomiędzy nimi, usuwanie po określonym czasie przechowywania.40. Zgodność z obowiązującym prawodawstwem odnośnie przechowywania dokumentów.41. Zabezpieczenia drukowanych dokumentów:42. Zarejestrowane dane dostępne w postaci raportów, które można eksportować do plików

w formatach CSV, XLS, HTML, XML.

9. Wymagania niefunkcjonalne

Zamawiający wymaga, aby:

str. 23



1. wszystkie świadczone w ramach Umowy usługi i powstałe komponenty funkcjonalne przed przyjęciem do eksploatacji podlegały procedurom testów akceptacyjnych i odbioru jakościowego;

2. testowanie Systemu dotyczyło pojedynczych obiegów lub funkcjonalności (w zależności od planu odbioru), co umożliwi ich sukcesywny odbiór i uruchamianie;

3. do produktów zgłaszanych do odbioru dołączana była dokumentacja projektowa, systemowa i powykonawcza, jak również instrukcja użytkownika oraz procedury eksploatacyjne wraz z instrukcjami;

4. możliwe było przeprowadzenie własnych testów akceptacyjnych przez Zamawiającego lub powtórzenie procedur testowych Wykonawcy SWP;

5. zapewniono Zamawiającemu dostęp do systemu obsługi błędów dedykowanego dla wdrożenia, który będzie obejmował zgłaszanie błędów, ich klasyfikację oraz monitoring obsługi zgłoszeń przez Wykonawcę SWP;

6. przeprowadzone zostało szkolenie zespołu użytkowników i administratorów (pracownicy Zamawiającego) w zakresie wdrożenia Systemu i jego prawidłowej eksploatacji;

7. szkolenie użytkowników przeprowadzone było w formie warsztatów w środowisku testowym - identycznym lub symulującym, z punktu widzenia użytkownika, środowisko docelowe;

8. Wykonawca SWP przedstawił wykaz zakładanych szkoleń, obejmujący co najmniej takie informacje jak: cel i zakres szkolenia, metoda i forma szkolenia, czas trwania i wymagane kwalifikacje dotyczące szkolonych osób.

10. Wymagania w zakresie dokumentacji

10.1 Wymagania ogólne

1. Zamawiający wymaga, aby wszystkie dokumenty tworzone w ramach realizacji przedsięwzięcia charakteryzowały się wysoką jakością, na którą będą miały wpływ, takie czynniki jak:a) Struktura dokumentu, rozumiana jako podział danego dokumentu na rozdziały,

podrozdziały i sekcje, w czytelny i zrozumiały sposób.b) Zachowanie standardów, a także sposób pisania, rozumianych jako zachowanie

spójnej struktury, formy i sposobu pisania dla poszczególnych dokumentów oraz fragmentów tego samego dokumentu

c) Kompletność dokumentu, rozumiana jako pełne, bez wyraźnych, ewidentnych braków przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego zagadnienia.

d) Spójność i niesprzeczność dokumentu, rozumianych jako zapewnienie wzajemnej zgodności pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu.

2. Zamawiający wymaga, aby cała dokumentacja, o której mowa powyżej, podlegała jego akceptacji, a także, aby została dostarczona w języku polskim, w wersji elektronicznej w formacie Word i PDF (na płycie CD-ROM lub innym równoważnym nośniku danych).Dopuszcza się inne formaty zapisu dokumentacji np. diagramy UML lub formaty wektorowe jak DWG,. DXF, należy jednak dołączyć przeglądarkę obsługującą

str. 24



wykorzystane formaty. Dostarczone wykresy Gantta powinny być dostarczone w formacie umożliwiającym import do programu MS Project oraz OpenProj.

3. Zamawiający wymaga, aby Wykonawca SWP przygotował i dostarczył w terminie zgodnym z harmonogramem zawartym w Dokumencie Zarządczym, następujące rodzaje dokumentacji bezpośrednio związanej z przedmiotem zamówienia:a) Dokumentację projektowąb) Dokumentację eksploatacyjnąc) Instrukcję Użytkownika Końcowego i Zewnętrznegod) Dokumentację powykonawczą

4. Wykonawca SWP jest zobowiązany do utrzymywania repozytorium dokumentacji w formie elektronicznej, z zapewnieniem dostępu pracowników i użytkowników Systemu wskazanych przez Zamawiającego przez cały czas trwania Umowy a także w czasie eksploatacji Systemu.

5. Dokumentacja powinna zostać sporządzona i udostępniona (w repozytorium) Zamawiającemu w terminach określonych w Umowie i w Harmonogramie Wdrożenia Systemu, dostarczonym przez Wykonawcę SWP i zaakceptowanym przez Zamawiającego. Dokumentacje te będą podlegały procedurze odbiorowej.

6. Zamawiający wymaga, aby Wykonawca SWP wszelkie zmiany dokonane w Systemie w okresie jego gwarancji i serwisowania, nanosił do dokumentacji i w terminie do 14 dni od wprowadzenia zmiany do Systemu publikował w repozytorium uaktualnioną dokumentację Zamawiającemu.

10.2 Dokument Zarządczy

1. W terminie wskazanym w Umowie, Wykonawca SWP opracuje i dostarczy Dokument Zarządczy, który będzie zawierać opis organizacji procesu wdrożenia Systemu, w szczególności:a) Szczegółowy Harmonogram Wdrożenia uwzględniający m.in.:

termin wykonania Projektu Technicznego, terminy udostępnienia środowiska Systemu, terminy osiągnięcia poszczególnych funkcjonalności Systemu, terminy wdrażania funkcjonalności/procesów (w zależności od zastosowanej

koncepcji wdrożenia, w tym termin opracowania i przekazania do akceptacji prototypu formularza wniosku o dofinansowanie),

terminy testów, terminy szkoleń, terminy dostarczenia Dokumentacji.

b) Wykaz produktów projektu wraz z kryteriami odbioru.c) Opis struktury organizacyjnej projektu mieszczącej się w uwarunkowaniach Umowy.d) Opis krytycznych czynników ryzyka i sukcesu.e) Opis procedur zarządzania projektem w zakresie: komunikacji, kontroli zmian,

monitorowania i raportowania postępu prac, zarządzania problemami i ryzykiem. f) Rodzaje, zasady i plan testów akceptacyjnych i odbioru poszczególnych etapów i/lub

produktów oraz odbioru końcowego Systemu, wraz z kryteriami ich akceptacji i procedurami przeprowadzenia testów.

str. 25



g) Skład osobowy zespołu wdrożeniowego.

10.3 Projekt techniczny

Projekt techniczny zostanie przedstawiony przez Wykonawcę SWP w terminie określonym w Dokumencie Zarządczym i będzie zawierał co najmniej poniższe informacje:

1. Opis koncepcji Systemu, zawierający w szczególności projekt architektury logicznej Systemu

2. Opis przyjętych rozwiązań funkcjonalnych wraz z informacjami o parametrach konfiguracyjnych, konstrukcyjnych i użytkowych, z wyspecyfikowaniem wszystkich elementów składowych.

3. Dokumentację struktury baz danych i przepływu danych wymagana przez przepisy dotyczące ochrony danych osobowych.

4. Zestawienie wszystkich składników planowanego Systemu, ich parametrów technicznych i niezbędnych licencji (w tym licencji otwartych)

5. Opis metod zapewnienia bezpieczeństwa informacji przetwarzanej w Systemie, ze wskazaniem obowiązujących regulacji prawnych, których wymagania będą spełnione dzięki zastosowanym metodom.

6. Opis metod zapewnienia jakości wprowadzanych i przetwarzanych w Systemie danych.7. Zasady i plany instalacji, uruchomienia i wdrożenia Systemu.8. Model danych przetwarzanych w Systemie.9. Procedury testowania Systemu na poszczególnych etapach wdrożenia, w szczególności

procedury testowania odtworzenia systemu po awarii.10. Procedury utrzymania Systemu, z uwzględnieniem procedur wykonywania kopii

zapasowych i poawaryjnego przywracania Systemu i danych celem osiągnięcia wymaganych przez Zamawiającego poziomów SLA usługi hostingu

10.4 Dokumentacja eksploatacyjna

1. Dokumentacja eksploatacyjna musi zawierać co najmniej:a) procedury administracyjne;b) procedury zabezpieczeń (kopie bezpieczeństwa i archiwalne);c) procedury awaryjne;d) procedury użytkownika;e) instrukcję obsługi Systemu

2. Każda z procedur powinna zawierać co najmniej:a) identyfikator i nazwę procedury;b) rodzaj procedury;c) datę utworzenia i zatwierdzenia oraz wersję procedury;d) cel i zakres procedury;e) warunki uruchomienia procedury i oczekiwany rezultat jej wykonania;f) dane osób, które opracowały procedurę, sprawdziły, zaakceptowały i zatwierdziły;

str. 26



g) opis działań, które należy wykonać, by osiągnąć postawiony cel, w tym informacja o osobach (zgodnie z zaproponowanymi rolami), które powinny wykonać dane czynności

10.5 Dokumentacja – Instrukcja Użytkownika Końcowego i Zewnętrznego

1. Dokumentacja umożliwia samodzielne i sprawne wykonywanie wszelkich operacji przez użytkownika w pracy z Systemem.

2. Dokumentacja powinna przedstawiać nie tylko elementarne operacje manipulacyjne w Systemie, ale zapewniać zadaniowy opis wykonywanych przez użytkowników działań.

3. Dokumentacja powinna być dostępna w postaci pomocy kontekstowej w Systemie (help).

10.6 Dokumentacja powykonawcza

1. Dokumentację powykonawczą Systemu stanowić będzie zaktualizowana dokumentacja projektowa uzupełniona o opis wykonanych instalacji technicznych, opis zainstalowanego oprogramowania wraz z informacjami o parametrach i sposobie konfiguracji, instrukcje techniczno-instalacyjne, instrukcje obsługi oprogramowania oraz inne dokumenty producentów, a także materiały szkoleniowe i podręczniki w zakresie dotyczącym Systemu, w tym także dokumentacja rozwojowa.

2. Dokumentację rozwojową Systemu stanowić będzie zbiór informacji niezbędnych dla dalszej samodzielnej rozbudowy Systemu przez Zamawiającego, bez konieczności wsparcia ze strony Wykonawcy SWP.

3. Dokumentacja w zakresie udostępnionej platformy sprzętowo-systemowej zawierająca przynajmniej nw. zakres informacji:

a. Słownik przyjętych skrótów i terminówb. Analiza wymagań w zakresie bezpieczeństwac. Koncepcja infrastruktury sprzętowej i systemowejd. Infrastruktura sprzętowa

i. Architektura sieciowa systemuii. Infrastruktura utrzymania hostowanych urządzeń

e. Opis infrastruktury sprzętowo-programoweji. Architektura serwerowa

ii. Komponenty sprzętoweiii. Komponenty programowe

f. Projekt infrastruktury siecioweji. Ogólna koncepcja

ii. Architektura logiczna sieciiii. Moduł dostępu do Internetu

g. Architektura warstwy bezpieczeństwa sieciowego systemuh. Monitorowanie dostępnościi. Opis architektury baz danych

i. Klastry bazy danychj. System kopii zapasowych

i. Architektura systemu kopii zapasowych i archiwizacji danychii. Podział taśm

iii. Polityki wykonywania kopii zapasowych

str. 27



k. Opis infrastruktury zasilającej, klimatyzacyjnej oraz systemów bezpieczeństwa serwerowni

l. Disaster recovery plan(wraz z nośnikami oprogramowania i kopiami)m. Dokumentacja umożliwiająca zainstalowanie Systemu na innym środowisku

produkcyjnym

11. Szkolenia i przekazywanie wiedzy

Zamawiający przewiduje trzy kategorie odbiorców szkoleń. Dwie kategorie pracownicze (użytkowników końcowych i administratorów) oraz grupę użytkowników zewnętrznych (wnioskodawców/wykonawców projektów/ekspertów), dla których mają być przygotowane materiały do samokształcenia.

Zamawiający określa maksymalną liczbę dni szkoleniowych (pulę) do wykorzystania w czasie trwania wdrożenia. Zapłata będzie dotyczyć jedynie konkretnych zamówionych i zrealizowanych szkoleń.

11.1 Wymagania ogólne w zakresie szkoleń dla pracowników Zamawiającego

1) Wykonawca SWP przeprowadzi szkolenia, w języku polskim, dla administratorów i użytkowników Systemu wytypowanych przez Zamawiającego

2) Wykonawca SWP opracuje i zaproponuje harmonogram w podziale na grupy szkoleniowe (administratorzy, użytkownicy) szkoleń zawierający

a) cel i projektowany zakres szkoleń

b) informacje o zakresie tematycznym poszczególnych szkoleń

c) metodzie i formie szkoleń

d) czasie trwania poszczególnych szkoleń

e) pożądanych kwalifikacjach osób skierowanych na szkolenia

f) ich koszcie jednostkowym oraz miejscu przeprowadzenia poszczególnych szkoleń

3) Harmonogram, o którym mowa w punkcie 10.2 3. Wykonawca SWP przedstawi do akceptacji Zamawiającego w terminach określonych w Umowie

4) Wykonawca SWP zobowiązany jest do przeprowadzenia szkoleń zgodnie z zatwierdzonym harmonogramem szkoleń.

5) Wykonawca SWP zapewni materiały szkoleniowe (w języku polskim) dla uczestników szkoleń.

6) Wykonawca SWP dostarczy multimedialne materiały szkoleniowe w postaci zapisu na płycie CDROM(lub innym równoważnym nośniku) oraz w formie papierowej

7) Wykonawca SWP zapewni prowadzenie szkoleń przez wykwalifikowaną kadrę posiadającą wiedzę teoretyczną i praktyczną z zakresu przedmiotu zamówienia

str. 28


komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP)---------------------------------------------------------------------------------------------------------------------8) Przeszkoleni administratorzy i użytkownicy otrzymają potwierdzenie ukończenia szkolenia

(certyfikat) stwierdzające, że osiągnęli oni wiedzę niezbędną do pełnienia powierzonych zadań

9) Przeprowadzenie szkoleń zostanie potwierdzone protokołem sporządzonym w dwóch jednobrzmiących egzemplarzach, po jednym dla Zamawiającego i Wykonawcy SWP, zawierającym:

a) nazwę i tematykę każdego ze szkoleń

b) datę i miejsce ich przeprowadzenia

c) imienną listę osób uczestniczących w poszczególnych szkoleniach

d) imię i nazwisko oraz specjalizację osób prowadzących szkolenie

e) czas trwania poszczególnych szkoleń

Protokół z przeprowadzenia szkoleń podlegać będzie zatwierdzeniu przez Zamawiającego.

11.2 Materiały szkoleniowe korzystania z systemu dla użytkowników zewnętrznych

Wybrany w przetargu Wykonawca SWP opracuje osobne materiały informacyjne dedykowane dla wnioskodawców, wykonawców projektów i ekspertów. Materiały w jasny i przejrzysty sposób mają pokazywać jak korzystać z systemu w sensie technicznym (logować się, odbierać i wysyłać korespondencję itp.) a także w sensie merytorycznym (znaczenie i sens poszczególnych pól formularza, najczęściej spotykane wątpliwości, zadawane pytania itp.). Materiał powinien być udostępniony interaktywnie w trybie kontekstowym oraz w postaci modułów szkoleniowych (w formie np. instrukcji. prezentacji oraz filmu instruktarzowego pokazującego sposób korzystania z systemu) do wyboru przez końcowego użytkownika zewnętrznego.

12. Etapy i terminy realizacji zmówienia

(i wynikający z nich harmonogram płatności)

W ramach przedstawianej oferty uczestnicy przetargu są (będą) proszeni o przedstawienie bardziej szczegółowej propozycji przebiegu wdrożenia. Poniżej zapisano jedynie kierunkowe założenia i wytyczne do skonstruowania tego planu.

Plan wdrożenia powinien zawierać opis oddawanych etapów wdrożenia oraz określać płatności powiązane z zakończeniem takiego etapu. W uzasadnionych przypadkach Zamawiający dopuszcza płatności cząstkowe, ale tylko po osiągnięciu określonych kroków milowych (milestones).

Harmonogram czasowo – rzeczowy

Czas trwania oznacza przeznaczony na realizację poszczególnych zadań czas liczony w dniach roboczych.

str. 29



No Name Duration Start Finish1 Podpisanie Umowy NCBR z Dostawcą 1 day 22.01.13 23.01.132 Organizacja projektu 5 days 23.01.13 30.01.133 Pzygotowanie infrastruktury i łączy 5 days 23.01.13 30.01.134 Uruchomienie hostinu środowiska testowego 1 day 30.01.13 31.01.135 Uruchomienie hostinu środowiska produkcyjnego 1 day 22.07.13 23.07.13

6E.1 Wsparcie procesu: wybór wykonawców projektów+dostawa recenzji 120 days 30.01.13 22.07.13

7 Szczegółowa analiza wymagań (nabór wniosków, oceny, umowy) 30 days 30.01.13 13.03.138 Prototyp generatora wniosków 20 days 13.03.13 10.04.139 Testy prototypu (użytkownika) 10 days 13.03.13 27.03.13

10 Decyzja w sprawie zastosowania/nie prototypu 1 day 10.04.13 11.04.1311 Budowa oprogramowania 40 days 27.03.13 24.05.1312 Testy techniczne (dostawcy) 15 days 24.05.13 17.06.1313 Testy akceptacyjne (użytkownika) 15 days 17.06.13 08.07.1314 Przygotowanie wersji produkcyjnej 10 days 08.07.13 22.07.1315 Obsługa procesu: wybór wykonawców + dostawa recenzji wdrożona 1 day 22.07.13 23.07.1316 E.2 Wsparcie procesu: nadzór nad realizacją projektów 100 days 17.06.13 06.11.13

17Analiza wymagań (odwołania, zaliczki i wypłaty, sprawozdania, oceny, aneksy itp.) 30 days 17.06.13 29.07.13

18 Budowa oprogramowania 30 days 29.07.13 10.09.13

str. 30



19 Testy techniczne (dostawcy) 15 days 10.09.13 01.10.1320 Testy akceptacyjne (użytkownika) 15 days 01.10.13 22.10.1321 Przygotowanie wersji produkcyjnej 10 days 22.10.13 06.11.1322 Obsługa procesu: nadzór nad realizacją projektów wdrożona 1 day 06.11.13 07.11.13

23E.3 Wsparcie dla Konkursów Unijnych, rozpatrywanie protestów i odwołań, interface'y 100 days 06.11.13 28.03.14

24 Szczegółowa analiza wymagań 30 days 06.11.13 18.12.1325 Budowa oprogramowania 30 days 18.12.13 31.01.1426 Testy techniczne (dostawcy) 15 days 31.01.14 21.02.1427 Testy akceptacyjne (użytkownika) 15 days 21.02.14 14.03.1428 Przygotowanie wersji produkcyjnej 10 days 14.03.14 28.03.14

29Wsparcie dla Konkursów Unijnych, rozpatrywanie protestów i odwołań, interface'y wdrożone 1 day 28.03.14 31.03.14

13. Akceptacja i zakończenie

1. Kryterium akceptacji Systemu jest zgodność z wymaganiami zawartymi w Umowie i Dokumentacji Projektowej, potwierdzona wynikami testów akceptacyjnych prowadzonych zgodnie z przyjętymi procedurami odbioru.

2. Zakończenie wdrożenia nastąpi po zatwierdzeniu protokołu odbioru końcowego przez Zamawiającego.

3. Formalnymi warunkami zatwierdzenia protokołu odbioru końcowego projektu są:a) uruchomienie przez Wykonawcę SWP oraz odbiór jakościowy przez Zamawiającego

oprogramowania Systemu dostępnego zgodnie z parametrami SLA Umowy Hostingowej, potwierdzone protokołem odbioru

b) pozytywne wyniki testów akceptacyjnych, potwierdzone protokołami akceptacji zrealizowanych testów,

c) sporządzenie przez Wykonawcę SWP pisemnego oświadczenia, potwierdzającego dostarczenie przedmiotu zamówienia spełniającego wymagania zawarte w Umowie i wszelkiej dokumentacji wskazanej w Umowie;

d) wykonanie i dostarczenie Zamawiającemu przez Wykonawcę SWP Dokumentacji Powykonawczej i Eksploatacyjnej, potwierdzone protokołem odbioru częściowego;

e) przeprowadzenie przez Wykonawcę SWP kompletu zakładanych szkoleń, potwierdzone protokołem odbioru częściowego

14. Opieka powdrożeniowa

Na mocy Umowy, Wykonawca SWP zapewni usługę opieki powdrożeniowej w zakresie:

1. Konsultacje i pomoc udzielana w zakresie funkcjonowania Systemu.2. Konsultacje telefoniczne i mailowe w zakresie funkcjonowania Systemu, udzielane dla

pracowników Zamawiającego i użytkowników zewnętrznych,

str. 31



3. Zmiany modyfikowalnych elementów Systemu, uwzględniające zmiany w obowiązującym prawodawstwie. W przypadku zmian w przepisach prawa, które powodują konieczność zmiany funkcjonowania Systemu, a które nastąpią w trakcie trwania opieki powdrożeniowej, Wykonawca SWP dostosuje System do zmieniających się przepisów prawa w terminie najpóźniej do 14 dni przed wejściem ich w życie, chyba że czas pomiędzy opublikowaniem a wejściem w życie przepisów będzie krótszy – wówczas Wykonawca SWP dostosuje System w terminie uzgodnionym z Zamawiającym.

4. Koszt usługi będzie wliczony do oferty cenowej i nie będzie objęty dodatkowymi opłatami

5. Czas świadczenia opieki powdrożeniowej będzie liczony od daty podpisania bez zastrzeżeń Protokołu Odbioru Końcowego Systemu. Czas świadczenia opieki powdrożeniowej musi trwać przez okres zaproponowany przez Wykonawcę SWP w ofercie, jednakże nie krótszy niż 12 miesięcy od terminu podpisania bez zastrzeżeń protokołu odbioru końcowego Systemu.

6. W wypadku niewywiązywania się Wykonawcy SWP ze zobowiązań opieki powdrożeniowej, Zamawiający ma prawo skorzystać, na koszt Wykonawcy SWP, z usług zastępczych bez utraty gwarancji.

7. Podjęcie działań objętych zakresem opieki powdrożeniowej nastąpi na podstawie zgłoszeń pocztą elektroniczną, telefonicznych (potwierdzonych przez e-mail) lub faksem. Zamawiający dopuszcza udostępnienie przez Wykonawcę SWP dodatkowego kanału zgłaszania potrzeby skorzystania z asysty technicznej, w postaci dedykowanego systemu informatycznego.

8. Reakcja Wykonawcy SWP na zgłoszenie nastąpi nie później niż następnego dnia roboczego, niezależnie od kanału zgłoszenia.

9. Udostępnienie aplikacji/systemu informatycznego do zgłaszania błędów Systemu oraz środowiska produkcyjnego, na którym jest eksploatowany

15. Serwis gwarancyjny

1. Po końcowym odbiorze Systemu, Wykonawca SWP będzie zobowiązany do zapewnienia serwisu gwarancyjnego dla Systemu i poszczególnych jego składników przez 36 miesięcy.

2. Wykonawca SWP gwarantuje Zamawiającemu, że wdrożony do eksploatacji System jest wolny od wad fizycznych i sprawny, a w szczególności:

a. zapewnia funkcjonalną zgodność z Umową i Dokumentacją;b. nie zawiera istotnych wad uniemożliwiających lub ograniczających eksploatację;c. jest kompatybilny z innymi systemami Zamawiającego zgodnie z założeniami

Wdrożenia i nie powoduje awarii i błędów innych systemów, z którymi współpracuje;

d. wszelkie usługi instalacyjno-wdrożeniowe są kompletne, poprawne i wykonane zgodnie z Umową i Dokumentacją

e. hostowana platforma zapewnia wszystkie standardy bezpieczeństwa oraz zapewnienia najwyższych parametrów dostępności i ciągłości działania

3. Okres gwarancji na System liczony jest od dnia podpisania bez zastrzeżeń Protokołu Odbioru Końcowego Systemu i nie może być krótszy niż 36 miesięcy.

str. 32



4. W ramach gwarancji Wykonawca SWP zobowiązuje się do nieodpłatnego usuwania wszelkich wad w funkcjonowaniu Systemu, które zostaną ujawnione w okresie obowiązywania gwarancji.

5. Zamawiający ma obowiązek zgłosić wady objęte niniejszą gwarancją niezwłocznie po ich wykryciu.

6. Termin gwarancji dla Systemu ulega przedłużeniu o czas, w ciągu którego Zamawiający nie mógł korzystać z Systemu.

7. W wypadku niewywiązywania się Wykonawcy SWP ze zobowiązań gwarancyjnych, Zamawiający ma prawo skorzystać, na koszt Wykonawcy SWP, z usług zastępczych bez utraty gwarancji.

8. Interwencja serwisu nastąpi na podstawie zgłoszeń e-mail, telefonicznych (potwierdzonych e-mail), systemem zgłaszania błędów (np. Mantis lub równorzędny) lub faksem. Każde zgłoszenie będzie potwierdzane pocztą e-mail (lub w systemie zgłaszania błędów) wraz z informacją o podjętych działań i szacowanym czasie rozwiązania zgłoszenia.

9. Usunięcie Awarii nastąpi w ciągu 24 godzin zegarowych od zgłoszenia błędu. Usunięcie odbędzie się w dwóch fazach:

a. w ciągu pierwszych 6 godzin zegarowych od wystąpienia, Wykonawca SWP określi, w jaki sposób można i należy eksploatować System, by wyeliminować ryzyko wynikające ze stwierdzonego błędu,

b. w ciągu następnych 18 godzin zegarowych Wykonawca SWP przywróci całkowitą funkcjonalność Systemu wraz z odzyskanymi danymi.

10. Przy każdej Awarii Wykonawca SWP na własny koszt powiadomi wszystkich potencjalnych użytkowników Systemu o sposobie pracy oraz terminie przywrócenia poprawnego działania Systemu

11. Usuwanie Błędu lub Usterki w Systemie nastąpi w terminie do 3 Dni Roboczych od wystąpienia błędu,

12. Wykonawca SWP sporządzi protokół usunięcia Wady, w którym określi przyczyny wystąpienia Wady oraz procedurę usunięcia i przywrócenia Systemu.

13. Obowiązki Wykonawcy SWP w okresie trwania gwarancji obejmują także instalowanie aktualizacji i poprawek, zwłaszcza związanych z poprawą bezpieczeństwa Systemu.

14. W okresie świadczenia przez Wykonawcę SWP usług gwarancyjnych oraz asysty technicznej, dopuszczalna jest przerwa konserwacyjna w pracy Systemu, ustalana z Zamawiającym przynajmniej z tygodniowym wyprzedzeniem. Przerwa ta nie może wystąpić częściej niż dwa razy w miesiącu i za każdym razem nie może trwać dłużej niż 16 godzin, wyłącznie poza standardowymi godzinami pracy Zamawiającego. Przerwa konserwacyjna spełniająca te warunki nie będzie wliczana do zdefiniowanego poziomu dostępności.

15. Wykonawca SWP zobowiązuje się do podpisania umowy na serwis pogwarancyjny na żądanie Zamawiającego. Cena świadczenia serwisu pogwarancyjnego zostanie ustalona odrębną umową serwisową.

16. Wykaz załączników do OPZ

Załącznik 1 - Wymagania krytyczne

str. 33


komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP)---------------------------------------------------------------------------------------------------------------------Załącznik 2 - Koncepcja formularza ogólnego

Załącznik 3 – Specyfikacja funkcjonalności systemu do obsługi czynności kancelaryjnych intraDOK

Załącznik 4 – Informacje dodatkowe: wersje robocze (nie wdrożone) procedur wraz z wersjami roboczymi formularzy powiązanych dla procedur: PG1-2 – Wybór wykonawców projektów, PG2-1 – Dostawa recenzji, PG1-3 – Nadzór nad wykonaniem i finansowanie projektu

str. 34



Załącznik 1 do OPZWymagania krytyczne

I. SWP - wymagania krytyczne

L.p. Opis wymagań

1. Wymagania ogólne dotyczące budowy SWP

1.1 SWP musi być zbudowany w oparciu o nowoczesne technologie posiadające wsparcie wśród wiodących na rynku producentów sprzętu i oprogramowania.

1.2 SWP musi być zbudowany w architekturze, co najmniej trójwarstwowej z wyróżnieniem warstwy danych, aplikacji oraz prezentacji.

1.3 SWP musi posiadać konstrukcję modułową, umożliwiającą niezależne, stopniowe uruchamianie różnych funkcjonalności.

1.4

Wszystkie elementy SWP muszą posiadać interfejs użytkownika w języku polskim. Jako element interfejsu Zamawiający określa również elementy konfiguracji poszczególnych części składowych systemu. W języku polskim muszą być również wyświetlane wszystkie komunikaty przekazywane przez SWP do użytkownika, włącznie z komunikatami o błędach.

1.5Praca z systemem SWP musi być możliwa z dowolnego komputera spełniającego minimalne wymagania poprzez przeglądarkę internetową: Internet Explorer v.7 plus nowsze, Fire Fox v. 3.6 plus nowsze, Chrome v. 15 plus nowsze

1.6

SWP musi udostępniać możliwość konfiguracji systemu na poziomie globalnym oraz lokalnym. Przez poziom globalny rozumie się poziom aplikacji gdzie opcja konfiguracyjna ma zastosowanie dla całej aplikacji. Przez poziom lokalny rozumie się poziom profilu konta pojedynczego użytkownika SWP gdzie opcja konfiguracyjna ma zastosowanie jedynie dla danego konta.

1.7 SWP musi uniemożliwiać dostęp do funkcji i zgromadzonych w nim danych z pominięciem mechanizmów bezpieczeństwa.

1.8SWP musi spełniać wymogi bezpieczeństwa w zakresie dostępu użytkowników do zasobów Systemu poprzez zapewnienie bezpiecznego kanału dostępu i zastosowanie mechanizmów uwierzytelniania i autoryzacji użytkownika.

1.9SWP musi filtrować i walidować dane wejściowe (np. wprowadzane przez użytkowników) w celu zminimalizowania ryzyka naruszenia integralności Systemu bądź danych.

1.10SWP musi przechowywać zawartość binarną poza bazą danych poprzez umieszczenie w bazie danych jedynie linków do zawartości binarnej (dokumenty, pliki).

1.11SWP musi umożliwiać wydzielenie usług dodatkowych odpowiedzialnych np. za indeksowanie treści czy OCR na osobny serwer w celu zwiększenia wydajności systemu.

str. 35



2. Wymagania ogólne dotyczące instrukcji obsługi i dokumentacji technicznej

2.1 SWP musi być opatrzony polskojęzyczną instrukcją obsługi przeznaczoną do oferowanej wersji.

2.2 Instrukcja musi być podzielona względem poszczególnych części składowych SWP, ich funkcjonalności.

2.3

Instrukcja musi być opracowana w sposób umożliwiający zidentyfikowanie sposobu wykonania określonej czynności. Instrukcja musi być aktualizowana po każdorazowej zmianie części składowej SWP. Instrukcja obsługi musi zawierać zrzuty ekranów odnoszące się do opisywanych funkcji.

2.4

Instrukcja SWP musi zawierać następujące elementy: opis działania i zastosowanie poszczególnej części składowej systemu z dokładnością do pojedynczej funkcji, informacje dotyczące poszczególnych funkcji zastosowanych w częściach składowych SWP w formie instrukcji krok po kroku opisującej wykonanie określonej czynności, konfigurację oraz sposób działania SWP.

2.5 Instrukcja techniczna musi być przygotowana w formacie PDF lub innym posiadającym podobne cechy.

2.6 Instrukcja musi być wyposażona w wyszukiwarkę i indeks wyrażeń.

3. Wymagania ogólne dotyczące funkcjonalności

3.1SWP musi umożliwiać zarządzanie użytkownikami przez uprawnionych pracowników, w tym m.in. tworzenie użytkowników, grup użytkowników, definiowanie ich uprawnień, blokowanie kont itp.

3.2SWP musi dawać możliwość administrowania przez uprawnionych pracowników poszczególnymi modułami Systemu w zakresie zawartości słowników, edycji szablonów itp.

3.3SWP musi posiadać mechanizmy pracy grupowej umożliwiające np.: wspólną pracę nad prowadzonymi sprawami, przekazywanie i dekretowanie dokumentów oraz ich udostępnianie innym użytkownikom.

3.4

SWP musi umożliwiać zarządzanie wielopoziomową strukturą folderów z poziomu lokalnego (przez każdego użytkownika) lub globalnego (z poziomu administratora, administrator posiada możliwość tworzenia katalogów i przydzielania dostępu do tych katalogów wybranym użytkownikom).

3.5

SWP musi posiadać mechanizm umożliwiający swobodne korzystanie z kwalifikowanego i powszechnego podpisu elektronicznego bez konieczności posiadania fachowej wiedzy. Funkcja podpisu elektronicznego musi umożliwiać podpisywanie jednego elementu SWP przez wielu użytkowników.

3.6 Musi istnieć możliwość złożenia podpisu kwalifikowanego z poziomu SWP.

3.7 SWP musi sygnalizować użytkownikowi, że dany dokument jest podpisany elektronicznie.

3.8Funkcja podpisu elektronicznego musi umożliwiać poprawne wykorzystanie certyfikatów kwalifikowanych pochodzących od dowolnego certyfikowanego wystawcy.

3.9 SWP musi posiadać mechanizm umożliwiający określenie rodzaju kanału, którym wysyłane będą powiadomienia co najmniej w zakresie:

str. 36



a) E-mailb) Powiadomienie systemowec) Pop-UPd) SMS

3.14SWP posiada możliwość oznaczenia własności dziedziczenia uprawnień na poszczególnych elementach względem elementów wyższych (np.: uprawnienia folderu mogą być dziedziczona na dokumenty i sprawy).

3.15 SWP musi uniemożliwiać edycję dokumentu, notatki tekstowej, sprawy lub pliku w przypadku, gdy jest on otwarty w tym celu przez innego użytkownika.

3.16 SWP musi umożliwiać wysłanie powiadomienia z potwierdzeniem otrzymania.

3.17SWP musi posiadać mechanizm tworzenia i zarządzania słownikami zawierającymi ujednolicone dane wykorzystywane w różnych miejscach w Systemie.

3.18 SWP musi umożliwiać dodawanie nowych słowników i używanie ich jako atrybutów obiektów w Systemie.

3.19SWP musi umożliwiać zarządzanie słownikami z możliwością dodawania, usuwania, modyfikowania (z zachowaniem historii) samych słowników lub pozycji słowników przez uprawione osoby.

3.20 SWP musi zapewniać spójność słowników tworzonych i używanych w Systemie.

3.21

SWP musi umożliwiać automatyczne generowanie linku do dowolnej sprawy i dokumentu. Wygenerowany link musi być możliwy do skopiowania i przesłania np. e-mailem. Kliknięcie na przesłany e-mailem link musi kierować bezpośrednio do odpowiedniego elementu w SWP z uwzględnieniem posiadanych uprawnień.

3.22

SWP musi umożliwiać nadawanie unikalnych identyfikatorów dokumentom i sprawom w ramach jednorodnych, słownikowych typów oraz kategorii dokumentów i spraw. (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

3.23

SWP musi umożliwiać opisanie dokumentu i spraw metadanymi, zarówno poprzez ich indywidualne wprowadzanie jak i korzystanie z szablonów metadanych dla poszczególnych typów dokumentów. (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

3.24

SWP musi posiadać funkcję umożliwiającą definiowanie wielopoziomowej struktury organizacyjnej. Poprzez tą funkcję możliwe musi być zdefiniowanie komórek organizacyjnych wraz z przypisaniem im odpowiedniej kategorii (np.: wydział, dział, sekretariat itd.), zdefiniowanie typów stanowisk służbowych (np.: dyrektor, naczelnik, kierownik) wraz określeniem osoby odpowiedzialnej za daną komórkę organizacyjną. Musi istnieć możliwość powiązania użytkowników systemu z poszczególnymi komórkami organizacyjnymi i zajmowanymi stanowiskami wraz z obsługą wyjątków.

3.25 SWP musi umożliwiać dodawanie nowych komórek organizacyjnych oraz

str. 37



modyfikowanie istniejących co najmniej w następującym zakresie:a. zmiany nazwy komórek organizacyjnych,b. zmiany podległości komórek organizacyjnych,c. likwidacji komórek organizacyjnych,d. podziału komórki organizacyjnej na kilka nowych komórek organizacyjnych,e. połączenia kilku komórek organizacyjnych w jedną nową komórkę organizacyjną wraz z zachowaniem historii i konsekwencjami w procesach pracy

3.31 SWP musi umożliwiać obsługę zespołów zadaniowych, do których należeć będą pracownicy z różnych komórek organizacyjnych.

3.32SWP musi zapewniać możliwość zablokowania dostępu do danej sprawy/dokumentu dla danego użytkownika, który wcześniej posiadał uprawnienia do tej sprawy/dokumentu.

3.33

SWP musi posiadać możliwość rozsyłania informacji o dokumencie do zdefiniowanej liczby odbiorców bez konieczności jej powielania (każdy dokument w systemie musi istnieć tylko w jednym egzemplarzu). Wszystkie adnotacje i operacje wykonywane przez użytkowników muszą być zapisywane na tym samym dokumencie.

3.34 SWP musi posiadać możliwość dołączania do dokumentów i spraw załączników w formie elektronicznej, będących innymi dokumentami lub plikami.

3.35 SWP musi posiadać możliwość zarządzania wielopoziomową strukturą folderów umożliwiających grupowanie dokumentów i spraw.

3.36

SWP musi zapewniać mechanizmy wyszukiwania w treści plików dołączonych do SWP z uwzględnieniem polskich znaków.Wyszukiwaniu powinny podlegać, co najmniej, następujące typy plików oraz ich zawartości:

dokumenty pakietu Microsoft Office (doc, docx, odf, xls, xlsx), dokumenty w formacie RTF, dokumenty w formacie PDF, pliki w formacie TXT pliki w formacie HTML pliki w formacie XML

3.44 SWP musi umożliwiać pobieranie skanów dokumentów z folderów sieciowych

3.45 SWP musi umożliwiać czytanie skanów dokumentów w formacie tiff, pdf, jpeg

3.46

SWP musi posiadać zintegrowany mechanizm skanowania dokumentów i rozpoznawania tekstu - OCR. Dokument po zeskanowaniu może zostać poddany procesowi rozpoznawania tekstu. Rozpoznany tekst musi być automatycznie dołączony do dokumentu.

3.47 SWP musi umożliwiać konfigurację wielu zasobów sieciowych w ramach obsługi skanowania masowego.

3.48 SWP musi umożliwiać określanie uprawnień do poszczególnych lokalizacji skanowania masowego.

3.49 SWP musi umożliwiać nadanie „przyjaznej” nazwy dla każdego z zasobów sieciowych w ramach skanowania masowego, wyświetlanej w interfejsie

str. 38



użytkownika.

3.50 SWP musi umożliwiać automatyczny import zeskanowanych dokumentów.

3.51

SWP musi umożliwiać konfigurację automatycznego importu dokumentów w ramach skanowania masowego co najmniej poprzez:

Określenie typu importowanego dokumentuKategorii importowanego dokumentuDocelowego folderuWłaściciela importowanego dokumentu.

3.56

SWP musi umożliwiać automatyczną rejestrację skanowanych dokumentów z uwzględnieniem rozpoznanej (za pomocą OCR) treści poprzez mapowanie odpowiednich sekcji zeskanowanego dokumentu na poszczególne pola w aplikacji:

Nazwa Opis Nadawca Data nadania Data na dokumencie Odbiorca Nr dokumentu

Musi umożliwiać także przypisanie zdefiniowanego, w konfiguracji zasobu sieciowego, atrybutu.

3.64SWP, podczas importu zeskanowanych dokumentów z określonej lokalizacji musi umożliwiać wskazanie folderu docelowego, w którym zarejestrowany zostanie dokument.

3.65Okno rejestracji zeskanowanego dokumentu wybranego ze wskazanej lokalizacji musi prezentować zarówno widok zeskanowanego dokumentu jak i formularza metadanych.

3.66 Aplikacja OCR musi automatycznie odróżniać początek i koniec Dokumentów wielostronicowych (poprzez: pustą stronę, lub kod kreskowy)

3.67 SWP musi umożliwiać obracanie obrazów skanowanych stron i zapis stanu.

3.68 SWP musi umożliwiać inteligentne usuwanie pustych stron.

3.69 Aplikacja do OCR musi działać po stronie serwera i umożliwiać rozpoznawanie tekstu bez udziału użytkownika.

3.70 Aplikacja do OCR musi rozpoznawać treść niezależnie od kierunku tekstu

3.71

SWP musi posiadać wbudowany mechanizm umożliwiający przeniesienie wybranych spraw oraz dokumentów do archiwum. Sprawy przeniesione do archiwum muszą być nadal dostępne dla użytkownika z uprawnieniami tylko do odczytu. SWP musi być przygotowany do generowania paczki archiwalnej zgodnie z obowiązującymi przepisami.

3.72 Dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności

str. 39



własnych Systemu, SWP musi umożliwiać operacje grupowe na dokumentach/sprawach, co najmniej w zakresie:

Modyfikacji, dodania oraz usunięcia: kategorii, atrybutów dodatkowych

Modyfikacji nazwy, Znakowania Przejmowania uprawnień

3.79

SWP musi umożliwiać wprowadzenie i wyświetlanie komunikatów dla użytkowników dostępnych na stronie logowania do Systemu. Komunikat musi zawierać co najmniej następujące informacje: data i treść komunikatu z możliwością ustawienia czasu wyświetlania użytkownikom.

3.80 SWP musi zapewnić mechanizm zarządzania uprawnieniami do funkcji i gromadzonych danych (obiektów) oraz określenia różnych poziomów uprawnień.

3.81 SWP musi umożliwiać przypisanie jednej osobie kilku ról (predefiniowanych zestawów uprawnień wraz z obsługą ewentualnych konfliktów/dziedziczenia)

3.82 SWP musi automatycznie nadawać uprawnienia dostępu dla dokumentów utworzonych przez użytkownika lub zadekretowanych na niego.

3.83 SWP musi umożliwiać wyświetlenie dodatkowych kolumn na liście dokumentów i spraw, np.: znak dokumentu/sprawy, dodatkowy atrybut.

4. Wymagania dotyczące zarządzania systemem

4.1 SWP musi gwarantować możliwość przydzielenia roli administratora do więcej niż jednego użytkownika.

4.2

SWP musi umożliwiać import kont użytkowników poprzez LDAP ze szczególnym uwzględnieniem eDirectory lub Active Directory (ostateczna decyzja w sprawie wyboru usługi katalogowej zostanie podjęta przez Zamawiającego przed podpisaniem umowy z Wykonawcą SWP)

4.3

Dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu, SWP musi posiadać funkcję umożliwiającą utworzenie dokumentu/sprawy na podstawie zdefiniowanego wcześniej szablonu, posiadającego co najmniej takie metadane jak:

Nazwa Typ dokumentu/sprawy np.: faktura, wniosek Podstawowa klasyfikacja np.: przychodzący, wychodzący, wewnętrzny Opis dokumentu/sprawy Adresat (możliwy do wpisania ręcznego bądź wyboru z listy

użytkowników SWP) Dodatkowe atrybuty dokumentu/sprawy np.: status pilności, lokalizacja

fizyczna, sposób dostarczenia, forma akceptacji.Szablon musi być dostępny i definiowany z poziomu GUI

4.11 SWP musi umożliwiać zorganizowanie szablonów w hierarchicznej strukturze folderów w celu ich łatwiejszego grupowania.

4.12 Z poziomu konta administratora SWP lub innego uprawnionego użytkownika

str. 40



musi istnieć możliwość zarządzania ścieżkami workflow co najmniej poprzez: włączenie/wyłączenie procesu określenie uprawnień do uruchamiania określenie uprawnień do przeglądania Konfigurację grup procesów (podfolderów) Zmianę nazwy procesu Zmianę kolejności procesów w menu

4.19 SWP musi umożliwiać dodawanie użytkownika do struktury organizacyjnej z poziomu formatki ustawień konta użytkownika.

4.20

SWP musi umożliwiać zarządzanie terminarzami przez każdego z użytkowników. Każdy użytkownik może posiadać wiele terminarzy prywatnych (dostępnych tylko dla niego) oraz dostęp do wielu terminarzy publicznych (współdzielonych pomiędzy użytkownikami). Zarządzanie dostępem do terminarzy musi odbywać się poprzez listę uprawnień, dzięki którym wybrany użytkownik może mieć dostęp do odczytu, zapisu i modyfikacji danych terminarza oraz odczytu samego terminarza.

4.21SWP umożliwia definiowanie czasu względem którego ma nastąpić powiadomienie o zbliżającym się terminie zakończenia/wystąpieniem zdarzenia (np.: powiadom o terminie zakończenia na 5 dni przed jego upływem).

4.22

SWP musi umożliwiać modyfikację JRWA (Jednolitego Rzeczowego Wykazu Akt) z poziomu interfejsu graficznego będącego częścią SWP (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

4.23

Modyfikacje poszczególnych części słownika JRWA muszą być zapisywane w historii (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

4.24

Modyfikacja słownika JRWA musi umożliwiać poprawę błędu lub uzupełnienie danych – zostanie uwzględniona we wszystkich miejscach, w których dany symbol został użyty (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

4.25

Modyfikacja słownika JRWA musi umożliwiać celową modyfikację symbolu – zostanie utworzona nowa wersja części słownika JRWA (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

4.26SWP musi oferować możliwość rozbudowy i modyfikacji bazy adresowej systemu wraz z możliwością dodawania własnych metadanych opisujących podmioty.

4.27SWP musi umożliwiać zarządzanie uprawnieniami dostępu do wybranego dokumentu/sprawy, uwzględniającego dziedziczenie uprawnień z elementu nadrzędnego oraz przypisanie uprawnień niedziedziczonych, przy czym

str. 41



dopuszczalna jest sytuacja kiedy jednocześnie występują uprawnienia dziedziczone i niedziedziczone.

4.28

SWP musi być wyposażony w zaawansowany system uprawnień, działający na zasadzie macierzy uprawnień. Uprawnienia muszą zapewnić możliwość sterowania dostępem do poszczególnych funkcji dla ról systemowych na zasadzie: zezwól, zabroń lub brak definicji.

4.29

SWP musi umożliwiać administracyjne wylogowywanie użytkowników, co najmniej w zakresie:

Wszyscy zalogowani użytkownicy Wybrani zalogowani użytkownicy Zalogowani w części użytkownika Zalogowani w części administracyjnej

5. Wymagania dotyczące przesyłania informacji i dekretacji

5.1 SWP musi umożliwiać rozsyłanie dokumentów w trybie do zapoznania się (uprawnienia tylko do odczytu).

5.2SWP musi umożliwiać obsługę sytuacji, w której pracownik na którego zadekretowano dokument przyjmuje go do realizacji lub zwraca do bezpośredniego przełożonego

6. Wymagania dotyczące bezpieczeństwa

6.1

SWP musi spełniać podstawowe warunki bezpieczeństwa poprzez: zapis wszystkich operacji wykonywanych przez użytkownika w

kontekście obiektów systemowych (np. modyfikacja dokumentu, odczyt sprawy, dodanie załącznika, modyfikacja uprawnień itp.)

Zapisywane operacje mają postać logu zawierającego informacje o: Użytkowniku, który ją wykonał Dacie oraz godzinie wykonania operacji Rodzaju wykonanej operacji W przypadku gdy operacja została wykonana przez użytkownika

pełniącego zastępstwo pojawia się dodatkowa informacja na temat zastępującego.

szyfrowanie informacji przesyłanych do użytkownika z systemu protokołem SSL,

możliwość pracy w systemie poprzez VPN

6.10 SWP musi umożliwiać jednoznaczną identyfikację użytkownika (unikalne ID w bazie danych)

6.11

SWP musi posiadać mechanizm uprawnień służący do budowania ról, grup oraz poziomów uprawnień pozwalający na odtworzenie struktury organizacyjnej. SWP musi także umożliwiać powiązanie roli bądź ról dla każdego Użytkownika lub grupy Użytkowników.

6.12 SWP musi umożliwiać przypisanie jednego Użytkownika bądź grupy Użytkowników do wielu ról jednocześnie.

6.13 SWP musi umożliwiać przypisanie jednego Użytkownika do wielu grup jednocześnie.

6.14 SWP musi posiadać możliwość autoryzacji użytkowników poprzez LDAP ze

str. 42



szczególnym uwzględnieniem eDirectory lub Active Directory (osateczna decyzja co do wyboru usługi katalogowej zostanie podjęta przez Zamawiającego najpóźniej przed podpisaniem umowy z Wykonawcą SWP). Użytkownik po zalogowaniu się do systemu operacyjnego nie musi logować się po raz kolejny do SWP. Użytkownik jest uwierzytelniany automatycznie (SSO) po wpisaniu adresu, pod którym dostępny jest SWP Użytkownik zostaje automatycznie zalogowany na swoje konto.

6.15

SWP musi rejestrować wszystkie zdarzenia dotyczące szczegółów operacji w nim wykonywanych, w szczególności operacje na dokumentach, sprawach, użytkownikach, strukturze organizacyjnej, w tym także operacji wykonywanych przez System automatycznie.

6.16

SWP musi umożliwiać przeglądanie historii zmian dotyczącej elementów z określeniem czasu i opisu zmian, informacją o osobach, które tych zmian dokonały, elementu, którego dotyczy zmiana oraz czynności, której dotyczy zmiana. Konieczne jest umożliwienie sortowania historii zmian według następujących parametrów:

użytkownika, który wykonał operację (z uwzględnieniem osoby zastępującej i zastępowanej, jeśli operacja była wykonana w zastępstwie),

daty modyfikacji.SWP musi wyróżniać zmianę, która nastąpiła poprzez opisanie elementu, w którym ta zmiana nastąpiła np.: dodano użytkownika, zmieniono nazwę sprawy, itd.

6.20

SWP musi zawierać mechanizm automatycznego tworzenia wersji dla dokumentów oraz plików (załączników). Każda modyfikacja zawartości głównej dokumentu lub załącznika powoduje automatyczne utworzenie nowej wersji. Wszystkie zmiany zostają odnotowane w SWP.

7. Wymagania dotyczące wyszukiwania informacji

7.1 SWP musi umożliwiać zatrzymanie usługi indeksowania w dowolnym momencie oraz jej wznowienie bez utraty wyników już zaindeksowanych dokumentów.

7.2SWP musi posiadać możliwość udostępnienia usług: indeksującej, wyszukującej za pośrednictwem sieciowych interfejsów komunikacyjnych (co najmniej WebServices).

7.3

SWP musi mieć możliwość zadawania zapytań w polu szybkiego wyszukiwania w postaci wyrażeń w dedykowanym do tego celu języku pozwalającym m.in. na budowę warunków logicznych, uwzględnienie wartość konkretnych pól, wykorzystanie tzw. wildcard (* i ?). Przykład zapytania: „+Znak:123* +Nazwa:Faktura*”, „ kategoria: Przychodzący”

7.4

SWP musi umożliwiać automatyczne przerywanie (po zadeklarowanym w konfiguracji czasie) zapytań mało selektywnych wymagających zbyt dużego czasu na wykonanie. W przypadku takich zapytań powinien zostać zwrócony wynik częściowy z informacją w interfejsie o tym, że zapytanie nie zostało wykonane w całości.

7.5 SWP musi domyślnie sortować wyniki zapytania według trafności.

7.6 SWP musi umożliwiać indeksowanie zadań WorkFlow oraz realizować

str. 43



wyszukiwanie po ich typowych meta danych w polu szybkiego wyszukiwania oraz poprzez wybrane kryteria określone we wzorcach wyszukiwania.

7.7

SWP musi posiadać funkcję tzw. wyszukiwania szybkiego. Za jego pomocą musi być możliwe przeszukanie wszystkich elementów po wpisaniu szukanego słowa lub wyrażenia do okna wyszukiwania, bez konieczności zawężania widoku do poszczególnych elementów SWP. Jako wyniki wyszukiwania powinny być zwrócone wszystkie elementy zawierające wyszukiwaną frazę. Elementy powinny być wyświetlone w formie płaskiej listy.

7.8 Wyszukiwanie szybkie musi umożliwiać pełnotekstowe przeszukanie elementów SWP.

7.9 Wyszukiwanie szybkie musi umożliwiać wyszukiwanie po dowolnej części znaku dokumentu/sprawy.

7.10W przypadku gdy użytkownik nie posiada uprawnień umożliwiających mu wyświetlenie treści odnalezionego elementu SWP musi poinformować go o tym podczas próby dostępu do tego elementu.

7.11 Po odnalezieniu elementów (spraw, dokumentów lub innych) SWP musi mieć możliwość filtrowania według ich typu oraz wyświetlać liczbę odnalezionych.

7.12

SWP musi posiadać graficzny moduł wyszukiwania zaawansowanego dostępnego dla każdego użytkownika pozwalający na zawężenie kryteriów wyszukiwania poprzez określenie specyficznych kryteriów takich jak:

Rodzaj elementu (np. dokumenty, sprawy, elementy JRWA, użytkownicy systemu lub struktura organizacyjna)

Typ elementu (np. faktura, umowa, wniosek, skarga, reklamacja) Kategoria elementu (np. przychodzący, wewnętrzny, wychodzący) Znak znajdujący się na dokumencie lub sprawie

7.17

Moduł zaawansowanego wyszukiwania musi dodatkowo pozwalać na doprecyzowanie kryteriów wyszukiwania z uwzględnieniem:

wskazanie folderu, w którym będzie następowało wyszukiwanie, wskazanie JRWA dla wyszukiwanych spraw i dołączonych do nich

dokumentów zakresu dat, atrybutów dodatkowych opisujących dokument lub sprawę

7.22

Moduł zaawansowanego wyszukiwania musi umożliwiać graficzne definiowanie wzorców wyszukiwania zawierających złożone zapytania umożliwiające łączenie w wynikach wyszukiwania elementów rożnego rodzaju (dokumenty, sprawy, szablony, elementy JRWA, kalendarze, osoby, użytkownicy, grupy i jednostki organizacyjne).

7.23 Wyszukiwanie zaawansowane musi umożliwiać pełnotekstowe przeszukanie elementów SWP.

7.24

Wzorce wyszukiwania muszą umożliwiać zawężanie wyników wyszukiwania poprzez określenie co najmniej następujących właściwości:

Rodzaj elementu (dokumenty, sprawy, szablony, elementy JRWA, osoby, użytkownicy systemu, grupy użytkowników i struktura organizacyjna)

Typ elementu:

str. 44



o Dokumento Element Rzeczowego Wykazu Akto Foldero Grupao Komórka organizacyjnao Notatkao Osoba fizycznao Osoba kontaktowao Osoba prawnao Raporto Skróto Sprawao Użytkowniko Wydarzenie Kategoria elementu (np. przychodzący, wewnętrzny, wychodzący) Znak znajdujący się na dokumencie lub sprawie Data Dołączony kontakt Właściciel Nazwa Treść

7.49 Mechanizm tworzenia wzorców wyszukiwania musi umożliwiać łączenie poszczególnych kryteriów za pomocą spójników logicznych „i” oraz „lub”.

7.50 Mechanizm tworzenia wzorców wyszukiwania musi umożliwiać grupowanie poszczególnych sekcji wzorca (analogicznie jak nawiasy w zdaniach logicznych).

7.51Mechanizm wzorców wyszukiwania musi umożliwiać określenie wartości danego parametru zgodnie z regułą „<”, „>” lub „≤”, „≥”. Np. element „jest typu”/„nie jest typu”, data „jest mniejsza”/”większa lub równa”

7.52 SWP musi umożliwiać zapis zdefiniowanych wzorców wyszukiwania przez każdego z użytkowników w celu ich ponownego wykorzystania.

7.53 SWP musi umożliwiać generowanie zawartości folderu wyszukiwania w oparciu o zdefiniowane i zapisane wzorce wyszukiwania.

7.54 SWP musi umożliwiać eksport zapisanych wyników wyszukiwania oraz zawartości rejestrów do pliku XLS.

8. Wymagania dotyczące obsługi dokumentów

8.1

SWP musi umożliwiać opisanie dokumentu przynajmniej następującymi metadanymi:

Typ dokumentu np.: faktura, skarga itd. Podstawowa klasyfikacja: przychodzący, wychodzący, wewnętrzny, Numer dokumentu – nadawany automatycznie, Data na dokumencie, Data rejestracji

str. 45



Data wpływu, Opis dokumentu, Kontakt (nadwca/odbiorca)

8.10 SWP musi posiadać możliwość wprowadzenia i opisania dokumentu dodatkowymi atrybutami zależnymi od rodzaju dokumentu.

8.11

Dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu, SWP musi udostępniać podgląd rejestrowanego dokumentu poprzez wyświetlenie jednocześnie formularza pozwalającego na wprowadzanie metadanych jak i graficzną prezentację rejestrowanego dokumentu.

8.12

Dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu, SWP musi posiadać centralną numerację dokumentów, gwarantującą unikalność numeracji w całym systemie. SWP musi nadawać automatycznie numer wszystkim rodzajom dokumentów.

8.13

SWP musi umożliwiać dodatkową, niezależną numerację dokumentów wybranego rodzaju lub umieszczonych w wybranym folderze. Numeracja ta może być nadawana automatycznie przez system lub ręcznie na życzenie użytkownika.

8.14

SWP musi umożliwiać podanie znaku sprawy podczas rejestracji dokumentu. Jeżeli sprawa o podanym numerze istnieje w systemie to rejestrowany dokument zostanie automatycznie do niej dołączony. (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

8.15SWP musi umożliwiać powiązanie dowolnych dokumentów ze sobą oraz ze sprawami. Z poziomu dokumentu muszą być widoczne wszystkie połączenia ze sprawami oraz innymi dokumentami.

8.16

Powiązania muszą umożliwiać odzwierciedlenie hierarchii relacji na zasadzie: podrzędny-nadrzędny nadrzędny-podrzędny równorzędny

np. akty uchylające – akty uchylane.

8.21 SWP musi umożliwiać tworzenie skrótów zarówno do spraw i dokumentów, jak również do ich załączników.

8.22

SWP musi umożliwiać rejestrację dokumentu przez każdego użytkownika oraz możliwość przekazania dokumentu do rejestracji innemu użytkownikowi. (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

8.23 Przy określaniu nadawcy/odbiorcy dokumentu SWP musi posiadać mechanizmy umożliwiające szybkie wyszukiwanie w książce teleadresowej oraz podpowiedzi najlepiej pasujących (po wybranych polach). (dla opcji oferty opartej o wariant

str. 46



migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

8.24

SWP musi posiadać zintegrowany mechanizm skanowania dokumentów i rozpoznawania tekstu – OCR. OCR musi być zintegrowany z oferowanym SWP w taki sposób by nie było konieczności uruchamiania dodatkowego oprogramowania.

8.25 Dokumenty dołączone do spraw muszą dziedziczyć znaki nadane tym sprawom z jednoczesnym zachowaniem znaku własnego.

8.26

SWP musi umożliwiać dołączenie jednego dokumentu do wielu spraw jednocześnie. W takim przypadku dokument musi dziedziczyć znaki ze wszystkich spraw, do których należy. Wszystkie znaki muszą być widoczne z poziomu dokumentu.

8.27

SWP musi umożliwiać wywołanie edycji zawartości dokumentu w formacie DOC/XLS bezpośrednio za pomocą aplikacji MS WORD/EXCEL. Zapis zmian powinien odbywać się również w aplikacji MS WORD/EXCEL i być do razu widoczny w SWP. Operacja nie może wymagać od użytkownika wykonania dodatkowych czynności, w szczególności zapisania pliku na lokalnym dysku.

8.28

SWP musi wspierać automatyczne generowanie kolejnych wersji. Nowa wersja powinna być generowana tylko w przypadku modyfikacji binarnej zawartości dokumentu. Modyfikacja metadanych dokumentu nie powinna generować kolejnej wersji.

8.29 SWP musi domyślnie wyświetlać ostatnio utworzoną wersję dokumentu.

8.30 SWP musi umożliwiać dostęp do poprzednich wersji dokumentów wszystkim użytkownikom (w zależności od uprawnień).

8.31 SWP musi umożliwiać utworzenie nowej wersji poprzez edycję zawartości tylko z bieżącej wersji dokumentu.

8.32 Użytkownik SWP nie może zmieniać treści i metadanych dokumentu w wersji innej niż bieżąca.

8.33 SWP musi umożliwiać obsługę korespondencji przychodzącej w formie elektronicznej (ePUAP, e-mail itp.).

8.34

SWP musi umożliwiać definiowanie szablonów dokumentów tekstowych obsługiwanych przez pakiety biurowe MS Office oraz Open Office z poziomu Systemu z możliwością automatycznego wstawiania do treści określonych atrybutów pobieranych z Systemu, w szczególności danych dotyczących:a. autorab. adresatac. dokumentud. sprawy

8.39SWP musi umożliwiać administrowanie szablonami, w szczególności: dodawanie, usuwanie, wersjonowanie oraz łączenie szablonów w grupy i podgrupy, nadawanie uprawnień do zarządzania szablonami.

9. Integracja z ePUAP

10.1 SWP musi być zintegrowany z platformą e-PUAP co najmniej w zakresie następujących obszarów integracji (usług) wskazanych na stronie

str. 47



http://epuap.gov.pl (Pomoc / Pomoc dla Integratorów / Dokumentacja i przykłady / Obszary integracji).a. Obsługa dokumentów (odbieranie i wysyłanie)b. Słowniki

10. Wymagania dotyczące bazy kontaktowej

10.2

Dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu, SWP musi umożliwić rejestrowanie danych adresowych nadawców i adresatów pism.

10.3

Dane adresowe muszą zawierać w szczególności:a. Imięb. Nazwiskoc. Nazwad. Nazwa skrócona (np. MSWPA, KPRM, UM itp.)e. Ulicaf. Nr domug. Nr lokaluh. Kod pocztowyi. Pocztaj. Miejscowośćk. Adres do korespondencji (ulica, nr domu, nr lokalu, kod pocztowy, poczta, miejscowość)l. Nr telefonum. Nr telefonu komórkowegon. Fakso. Adres e-mailp. Adres WWWq. Adres ESP (w szczególności adres e-mail, strony internetowej, nazwa skrzynki na ePUAP itp.)

10.21 SWP musi umożliwiać zmianę danych adresowych nadawców przez użytkowników posiadających odpowiednie uprawnienia.

10.22 SWP musi umożliwiać definiowanie innych (dowolnych) atrybutów opisujących nadawców i adresatów.

11. Wymagania dotyczące obsługi spraw

11.1

SWP musi umożliwiać łączenie dowolnej ilości spraw lub dokumentów. Połączenia muszą być widoczne z poziomu właściwości wybranego elementu. Musi istnieć możliwość dokonania połączenia typu: dokument – dokument, sprawa – sprawa, sprawa – dokument, dokument – sprawa.

11.2

SWP musi posiadać możliwość zakładania spraw przez każdego użytkownika i opisania jej co najmniej według następujących parametrów:

nazwa – nadanie nazwy sprawie,stan np.: otwarta, zamknięta, zwieszona,opis – nadanie rozszerzonego opisu sprawie,

str. 48



termin rozpoczęcia oraz termin zakończenia pracy nad sprawą,Data rozpoczęciaData planowanego zakończeniaData zakończenia (nie musi być z góry określona)Data wznowienia (nie musi być z góry określona)

11.11 SWP musi posiadać mechanizm łączący sprawę z danymi teleadresowymi podmiotu, którego ta sprawa dotyczy. Użytkownik musi posiadać możliwość połączenia sprawy z więcej niż jednym podmiotem.

11.12 SWP musi posiadać możliwość przekazywania spraw bez utraty kontroli nad ich realizacją. Użytkownik po przekazaniu sprawy musi mieć możliwość zachowania dostępu do tej sprawy.

11.13 SWP musi posiadać możliwość filtrowania spraw o przekroczonych terminach.

11.14

Dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu, SWP musi umożliwiać założenie sprawy bez konieczności natychmiastowego nadania znaku sprawy zgodnego z JRWA. Musi istnieć możliwość nadania znaku w każdej chwili oraz zmiany znaku sprawy z zachowaniem historii zmian.

11.15 SWP musi posiadać możliwość blokowania powtórnego wykorzystania tego samego znaku sprawy w przypadku jego usunięcia.

11.16

SWP musi posiadać możliwość definiowania wielu struktur znaku sprawy i przypisywania do nich odpowiednich haseł JRWA (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu).

11.17 SWP musi posiadać możliwość określania dodatkowych atrybutów niezbędnych do opisania sprawy w zależności od jej rodzaju (np. postępowanie przetargowe, skarga itp.).

11.18 SWP musi posiadać funkcjonalność umożliwiającą założenie nowej sprawy z dokumentu istniejącego w innej sprawie.

11.19SWP musi umożliwiać pracę kilku osób (praca grupowa) nad sprawą (np. komisja przetargowa ma wgląd we wszystkie dokumenty w danej sprawie, każdy z członków komisji może tworzyć nowe wersje dokumentów, lecz nowe dokumenty może dołączać tylko osoba prowadząca sprawę).

11.20 System musi umożliwiać zakładanie spraw przez pracowników posiadających odpowiednie uprawnienia.

12. Wymagania dotyczące archiwum (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

12.1 Archiwum musi być wydzielonym modułem SWP, do którego funkcji dostęp posiadają wybrani użytkownicy.

12.2 SWP musi umożliwiać oznaczenie zamkniętych spraw jako archiwalnych w sposób automatyczny po określonym w przepisach prawa czasie, zmianę

str. 49



dotychczasowych uprawnień użytkowników na „do odczytu”, nadanie uprawnień dla archiwistów oraz zapisanie daty przekazania do archiwum.

12.3SWP musi umożliwiać wyznaczenie uprawnień w zakresie możliwości tworzenia spisów zdawczo odbiorczych, spisów brakowania oraz przekazywania tych spisów do archiwum.

12.4 SWP musi umożliwiać zarządzanie uprawnieniami w zakresie dostępu do spisów zdawczo odbiorczych oraz spisów brakowania.

12.5

SWP musi umożliwiać utworzenie spisu zdawczo odbiorczego dla materiałów archiwalnych z wykorzystaniem następujących parametrów:

Komórka organizacyjna (możliwość wyboru jednocześnie wielu komórek),Symbol RWA (możliwość wyboru wielu symboli jednocześnie),Daty od - do (możliwość zawężenia zakresu, z którego ma być utworzony spis

zdawczo odbiorczy).

12.9 SWP musi umożliwiać utworzenie spisu brakowania dla dokumentacji niearchiwalnej.

12.10 SWP musi umożliwiać przekwalifikowanie wybranych akt sprawy w spisie brakowania.

12.11 SWP musi zapewniać możliwość pobrania utworzonego spisu zdawczo odbiorczego oraz spisu brakowania w postaci pliku zapisywanego na dysk.

12.12 SWP musi umożliwiać wykonywanie spisów zdawczo odbiorczych przez wybranego użytkownika dla wybranych komórek organizacyjnych np.: całego wydziału oraz wszystkich komórek podrzędnych w tym wydziale.

12.13 SWP musi numerować spis zdawczo odbiorczy po umieszczeniu go w wykazie spisów zdawczo odbiorczych.

12.14 SWP musi umożliwiać usuwanie oraz modyfikację spisów zdawczo odbiorczych oraz spisów brakowania wybranym użytkownikom zgodnie z posiadanymi przez nich uprawnieniami.

12.15 SWP musi zabezpieczać przed usunięciem spisów zdawczo odbiorczych i innych danych, które byłoby niezgodne z obowiązującymi przepisami.

12.16 SWP musi umożliwiać udostępnianie akt sprawy w formie elektronicznej wybranemu użytkownikowi SWP poprzez nadanie uprawnień do odczytu.

12.17 SWP musi umożliwiać wygenerowanie paczki archiwalnej dla spisu zdawczo odbiorczego zgodnie z istniejącymi przepisami prawa.

13. Wymagania dotyczące terminarzy

13.1SWP musi posiadać wbudowany mechanizm terminarzy umożliwiający definiowanie terminarzy indywidualnych oraz grupowych umożliwiający ustalanie i kontrolę nad terminami.

13.2 SWP musi posiadać mechanizm umożliwiający przełożonemu wgląd do terminarzy swoich podwładnych.

13.3SWP musi posiadać możliwość ustalania uprawnień do dodawania i do wglądu terminarzy dostępny dla każdego użytkownika. Uprawnienia muszą dotyczyć indywidualnie każdego terminarza.

13.4

SWP musi posiadać funkcję cyklicznego przypominania o zdarzeniach zapisanych w terminarzach. Powiadamianie musi być możliwe za pomocą wyskakującego okienka, w którym zostaną wymienione zdarzenia pochodzące ze wszystkich terminarzy, do których dostęp ma użytkownik. Musi istnieć

str. 50



możliwość odłożenia przypomnienia o zdarzeniach na określony czas dla wszystkich terminów jednocześnie oraz dla każdego z osobna lub odrzucenia powiązanego z usunięciem przypomnienia o wybranym terminie lub grupie terminów.

14. Wymagania dotyczące obsługi zastępstw

14.1 Mechanizm zastępstw nie może wymuszać konieczności przekazywania haseł do systemu SWP pomiędzy użytkownikami na czas pełnienia zastępstwa.

14.2 Każdy użytkownik systemu musi posiadać możliwość wskazania początku oraz końca okresu, w którym będzie zastępowany.

14.3Wszystkie operacje wykonywane przez zastępcę w systemie muszą zostać odnotowane i widoczne przez osobę zastępowaną. Na ich podstawie musi być możliwy do wygenerowania spis wykonanych operacji.

14.4Wszystkie elementy, na których zastępca wykonał jakiekolwiek operacje muszą zostać odnotowane w taki sposób, by możliwa była identyfikacji osoby, która je wykonała.

14.5 Musi istnieć możliwość wyznaczenia więcej niż jednej osoby zastępującej dla osoby zastępowanej.

15. Wymagania dotyczące raportów15.1 SWP musi być przygotowany do obsługi raportów.

15.2 SWP musi posiadać wbudowany moduł do uruchamiania, obsługi i generowania raportów z poziomu interfejsu SWP.

15.3SWP musi umożliwiać grupowanie raportów w hierarchiczną strukturę kategorii definiowanych przez administratora systemu. Struktura kategorii powinna mieć postać drzewiastej struktury folderów zawierających raporty.

15.4SWP musi umożliwiać nadawanie uprawnień dostępu do wybranych raportów lub całych kategorii raportowych wybranym użytkownikom i grupom użytkowników.

15.5Raporty muszą mieć możliwość konfiguracji, tak aby zakres danych prezentowanych w raporcie był zależny od uprawnień posiadanych przez użytkownika który go wykonuje.

15.6Raport musi uruchamiać się w oknie wewnątrz interfejsu SWP. Wygląd okna raportu powinien być wizualnie spójny z pozostałymi oknami SWP i powinien posiadać możliwość maksymalizacji raportu do całej strony przeglądarki.

15.7

SWP musi umożliwiać filtrowanie podczas uruchomienia raportów. Użytkownik musi mieć możliwość wyboru wartości filtrów z listy dostępnych wartości. Dostępne wartości muszą być generowane dynamicznie i obrazować aktualny stan zasobów systemu SWP (np. lista dostępnych kategorii spraw).

15.8

Moduł raportowy SWP musi umożliwiać obsługę różnych typów parametrów:Wielokrotnego wyboruJednokrotnego wyboruWartość wpisywana przez użytkownikaParametr typu data i czas.

str. 51



15.13 SWP musi umożliwiać zmianę wartości filtrów przez użytkownika wraz z ponownym przeliczeniem bez konieczności ponownego uruchamiania raportu.

15.14 Systemu musi umożliwiać wskazanie wartości parametrom raportu przez użytkownika uruchamiającego raport.

15.15 Każdy wynik raportu musi być możliwy do pobrania w co najmniej następujących formatach: XLS, PDF, DOC, CSV, HTML, TIFF.

15.16 SWP musi umożliwiać równoczesne przeglądanie wielu raportów oraz przełączanie między widokami tych raportów.

15.17 System musi umożliwiać wielokrotne i jednoczesne uruchomienie tego samego raportu z różnymi wartościami parametrów i filtrów.

15.18

SWP musi umożliwiać wprowadzanie wartości dla parametrów podczas uruchamiania raportu. System musi wspierać użytkownika w tej kwestii, np. poprzez umożliwienie wyboru wartości parametru z wykorzystaniem wspólnych okien systemu (np. okno wyszukiwania użytkownika, okno wyboru folderu z drzewa).

15.19 Użytkownik musi mieć możliwość dynamicznego filtrowania raportu na podstawie okna z filtrami raportu.

15.20SWP musi mieć możliwość automatycznego przekazywania wartości parametrom raportu podczas jego uruchomienia na podstawie kontekstu uruchomienia raportu. Np. system musi potrafić automatycznie przekazać jako parametr informację o użytkowniku uruchamiającym raport.

15.21 SWP musi umożliwiać definiowanie parametrów raportu z wykorzystaniem modułu administracyjnego.

15.22Administrator musi mieć możliwość wyboru typu parametru (np.: użytkownik, folder, wartość tekstowa) oraz krotności parametru. Na podstawie tej definicji użytkownik musi uzupełnić wartości dla wskazanych parametrów podczas uruchamiania raportu (np. wybór folderu systemowego).

15.23

Raporty w SWP muszą prezentować dane z wykorzystaniem różnych form graficznych i tabelarycznych:

Tabela Macierz Wykres

15.27

System musi obsługiwać różne typy wykresów, w szczególności: Wykres słupkowy Wykres kolumnowy Wykres kołowy Wykres punktowy Wykres liniowy Wykres warstwowy Wykresy trójwymiarowe

15.35 Wszystkie elementy prezentacyjne muszą podlegać formatowaniu na etapie budowy raportu. Formatowanie to powinno obejmować zmianę precyzji pól, zarządzanie czcionkami i kolorami prezentowanych informacji.

15.36 W raporcie musi być możliwość łączenia wielu różnych form prezentacyjnych.

str. 52



16. Wymagania dotyczące personalizacji ustawień

16.1 SWP musi umożliwiać wybór wyświetlania na listach wybranych sekcji poszczególnych elementów (dokumentu, sprawy).

16.2 SWP musi umożliwiać zmianę sortowania dokumentów i spraw względem określonych kolumn po kliknięciu na nagłówek wybranej kolumny.

16.3

SWP musi umożliwiać każdemu z Użytkowników wybór sposobu rejestracji dokumentu (kreator lub formularz) (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu)

16.4 SWP musi umożliwiać wybór dodatkowych kolumn w widoku zawartości folderu, prezentujących dodatkowe informacje zapisane w metadanych elementu.

16.5 Wszystkie ustawienia personalizacji muszą być zapisywane w profilu danego użytkownika.

17. Wymagania dotyczące obsługi procesów Workflow z poziomu systemu SWP

17.1 SWP musi umożliwiać definiowanie przez administratora dostępnych do uruchomienia procesów w formie listy lub struktury drzewiastej.

17.2 SWP musi umożliwiać definiowanie uprawnień dla użytkowników lub grup użytkowników do uruchamiania procesów.

17.3 System musi umożliwiać uruchamianie zadań realizujących proces bezpośrednio z interfejsu SWP.

17.4

SWP musi umożliwiać filtrowanie przeglądanych zadań co najmniej według następujących kryteriów:

Zadania oczekujące na wykonanie Zadania zakończone Zadania przeterminowane

17.8

System musi umożliwiać delegowanie zadań realizujących proces na użytkownika, grupę użytkowników lub listę użytkowników i grup. W przypadku zadań delegowanych do więcej niż jednego użytkownika, SWP musi umożliwiać przypisanie spośród nich wykonawcy zadania.

17.9 System musi umożliwiać powiązanie delegowanego zadania z dokumentem/sprawą w SWP.

17.10 Śledzenie przebiegu procesów powinno być dostępne bezpośrednio z interfejsu SWP.

17.11

SWP musi umożliwiać śledzenie przebiegu procesów, co najmniej w podanym zakresie:

Wyświetlenie listy wystąpień wybranego procesu Wyświetlenie listy zadań wybranego procesu

17.15

Funkcja umożliwiającą śledzenie przebiegu procesów powinna dawać możliwość odpowiedniego filtrowania wyników poprzez określenie:

Wyświetlanych instancji procesów Rodzaju wyświetlanych informacji: instancje lub zadania Statusu instancji procesu: trwające, zakończone, zatrzymane oraz

str. 53



wszystkie. Statusu zadań: np. wszystkie, w trakcie wykonywania, zakończone,

przeterminowane Zakresu dat utworzenia instancji procesu lub zadania Zakresu dat zakończenia instancji procesu lub zadania

17.22 SWP powinien umożliwiać zarządzanie dostępem do modułu śledzenia przebiegu procesu poprzez nadanie określonych uprawnień dla wybranych użytkowników.

17.23

SWP musi zapisywać dane historyczne związane z przebiegiem danego procesu poprzez:

Odnotowanie danych na temat użytkownika wykonującego zadanie Statusu zadania na poszczególnych etapach Daty wykonania zadania Data zmiany statusu

17.28 SWP musi umożliwiać konfigurację i wybór danych historycznych wyświetlanych w ramach podglądu przebiegu procesu na etapie modelowania.

17.29 SWP musi umożliwiać dostęp do zadań realizujących proces, wykorzystując do tego interfejs użytkownika systemu SWP

18. Wymagania ogólne podsystemu Workflow

19.1

Moduł WORKFLOW musi być aplikacją umożliwiającą odwzorowanie i realizację procesów przepływu pracy za pomocą graficznego narzędzia, która umożliwi odwzorowanie procedur postępowania w kontekście załatwiania spraw obsługiwanych przez Zamawiającego w systemie SWP.

19.2 Moduł WORKFLOW musi zapewniać integrację z systemem SWP w celu realizacji procesów oraz zadań związanych z prowadzonymi w SWP sprawami.

19.3 Moduł WORKFLOW musi umożliwiać pracę zarówno ze sprawami jak i dokumentami przechowywanymi w systemie SWP.

19.4Moduł WORKFLOW musi być aplikacją umożliwiającą definicję procesów w powiązaniu z użytkownikami, grupami użytkowników oraz rolami, które uczestniczą w realizacji procesów po stronie systemu SWP.

19.5 WORKFLOW musi posiadać mechanizmy pozwalające na integrację z innymi systemami co najmniej poprzez mechanizmy WebService.

19.7

Moduł WORKFLOW musi umożliwiać graficzne definiowanie procesów na poziomie biznesowym oraz ich graficzną implementację na poziomie wykonawczym. Tym samym WORKFLOW ma stanowić zarówno środowisko do przygotowania, testowania oraz uruchamiania procesów.

19.8 Wykorzystanie (obsługa) zaprojektowanej ścieżki (procesu) musi być możliwa poprzez przeglądarkę internetową.

19.9

WORFKLOW musi umożliwiać realizację następujących procesów:Inicjowane przez użytkownika - procesy zależne od inicjacji użytkownika,

umożliwiające realizację funkcji określonych w ścieżce (np.: utwórz kopię zapasową).

Interakcyjne z użytkownikami – umożliwiające realizacje procesów interakcyjnych z użytkownikami np.: poprzez wypełnianie formularzy.

Zautomatyzowane – wykonywane w pełni po stronie oferowanego rozwiązania poprzez wbudowane w niego opcje np.: wygenerowanie raportu dziennego i

str. 54



przesłanie go pocztą elektroniczną do wybranej grupy użytkowników.

19.13 Moduł musi posiadać narzędzie do graficznego budowania ścieżek workflow bez konieczności posiadania przez osoby je tworzące wiedzy programistycznej (znajomości określonego języka/ów programowania).

19.14 Moduł WORFKLOW musi umożliwiać definicję punktów w ścieżce oraz połączeń pomiędzy tymi punktami.

19.15 Moduł WORKFLOW musi umożliwiać opisanie czynności, które muszą zostać wykonane w wybranym punkcie ścieżki.

19.16 Moduł WORKFLOW musi informować poprzez odpowiednie oznaczenie graficzne w trybie wykrywania błędów (debug mode), w którym punkcie realizacji znajduje się użytkownik.

19.17 Moduł WORKFLOW musi umożliwiać w ramach zadań obsługę mechanizmu przypomnień o zadaniu do realizacji i wykrywania przekroczenia czasu ważności zadania.

19.18 Moduł WORKFLOW musi posiadać komponenty do budowania zaawansowanych reguł decyzyjnych.

19.19 Moduł WORKFLOW musi umożliwiać definiowanie formularzy i przyporządkowanie ich do poszczególnych punktów ścieżki.

19.20 Moduł WORKFLOW musi posiadać wbudowane mechanizmy równoległego wykonywania zadań.

19. Moduł projektowania ścieżek Workflow

20.1Narzędzie musi umożliwiać definiowanie poszczególnych punktów oraz zdarzeń w pojedynczej ścieżce jako osobno zdefiniowanych pozycji przedstawionych w postaci grafu z połączeniami.

20.2

Moduł WORFKLOW musi posiadać narzędzie umożliwiające zaprojektowanie i prezentację zaprojektowanej ścieżki WORFKLOW w ujęciu biznesowym w postaci schematu blokowego. Ujęcie biznesowe oznacza przedstawienie koncepcji działania określonej ścieżki a nie jej modelu wykonawczego. Model biznesowy udostępnia informacje na temat czynności realizowanych w określonej ścieżce oraz umożliwia przypisanie tych czynności określonym rolom.

20.3Podczas zmiany położenia punktów na grafie ścieżki WORFKLOW połączenia muszą automatycznie zmieniać swoje położenie w taki sposób, że nie nakładają się na poszczególne punkty.

20.4Moduł WORFKLOW musi wyświetlać miniaturę ścieżki (ang. thumbnail) podczas projektowania ścieżki. Miniatura jest pomocna w przypadku gdy projektowana ścieżka nie mieści się w całości w obszarze roboczym.

20.5

Moduł WORFKLOW musi umożliwiać przypisywanie elementom modelu biznesowego elementów określonych w modelu wykonawczym (np.: pozycja modelu biznesowego o nazwie „Kierownik działu składa zapotrzebowanie na nowy komputer” jest mapowana na formularz składania zapotrzebowania na sprzęt komputerowy).

20.6

Moduł WORFKLOW musi posiadać narzędzie umożliwiające zaprojektowanie i prezentacje modelu wykonawczego ścieżki.Model wykonawczy umożliwia wykonanie ścieżki WORFKLOW realizującej określony przez nią proces. Model wykonawczy jest ścieżką WORFKLOW gotową do uruchomienia.

str. 55



20.7

Połączenia pomiędzy punktami muszą być tworzone poprzez wskazanie myszą punktu wyjściowego, przeciągnięcie kursora nad punkt docelowy i zwolnienie przycisku myszy. Po takiej operacji połączenie musi być tworzone w sposób uniemożliwiający nakładanie go na poszczególne punkty. Ścieżki krzyżujące się muszą być oznaczone mostkiem umożliwiającym identyfikację każdej ze ścieżek.

20.8Moduł WORFKLOW musi umożliwiać wywoływanie ścieżek podrzędnych przypisanych do określonego punktu ścieżki głównej. Wynik działania ścieżki podrzędnej może mieć bezpośredni wpływ na dalszy przebieg ścieżki głównej.

20.9 Moduł WORFKLOW musi posiadać możliwość przypisywania dla każdej ścieżki głównej lub podrzędnej kolejnych ścieżek podrzędnych.

20.10 Podczas projektowania ścieżki moduł WORFKLOW musi identyfikować niepoprawnie zdefiniowane punkty (np.: dla punktu typu „wysłanie wiadomości email” informuje o braku odbiorcy wiadomości lub innego wymaganego pola).

20.11Moduł WORFKLOW musi posiadać wbudowane narzędzie umożliwiające uruchamianie zdefiniowanych ścieżek w trybie wykrywania błędów (debug mode). Tryb ten umożliwia przetestowanie działania ścieżki w celu wykrycia błędnie zdefiniowanych punktów.

20.12 Tryb "wykrywanie błędów" musi umożliwiać wykonanie ścieżki Krok po kroku z oznaczeniem każdego z wykonanych punktów.

20.13 Moduł WORFKLOW musi umożliwiać kopiowanie wybranego komponentu lub grupy komponentów łącznie z przypisanymi do nich ustawieniami. Kopiowanie musi być możliwe w obrębie jednej lub wielu ścieżek.

20.14Moduł WORFKLOW musi umożliwiać definiowanie dla każdej ścieżki globalnych parametrów opisujących ścieżkę oraz parametrów uruchomieniowych. Parametry muszą być zapisywane w plikach XML projektu ścieżki.

20.15

Moduł WORFKLOW musi posiadać wbudowane komponenty umożliwiające opisanie ścieżki poprzez użycie graficznych symboli (adnotacje). Graficzne symbole muszą być możliwe do użycia w dowolnym miejscu ścieżki. Udostępniane muszą być następujące komponenty:

Etykieta, Komponent strzałki, Komponent obrazu (umożliwiający osadzenie np.: zdjęcia itp.) Sekcja (umożliwiająca naniesienie i wizualne grupowanie określonych

komponentów na ścieżce),

20.20

Moduł WORFKLOW musi posiadać wbudowane komponenty umożliwiające kolekcję danych ze ścieżki. Komponenty kolekcji danych muszą gromadzić informacje ze ścieżki w zależności od umiejscowienia (np.: komponent kolekcji danych umieszczany jest jako trzecia pozycja w ścieżce (po dwóch poprzednich komponentach) i umożliwia gromadzenie danych pozyskanych we wcześniejszych krokach ścieżki). Wymaga się zapewnienia następujących operacji na kolekcji danych:

Dodawanie danych do kolekcji danych, Filtrowanie danych w kolekcji danych, Sortowanie danych w kolekcji danych, Wykonanie operacji w pętli dla każdego elementu w kolekcji danych,

str. 56



Wykonanie operacji w pętli dla każdego elementu w kolekcji danych z możliwością przerwania wykonywania pętli po spełnieniu określonego warunku,

Dostęp do wskazanego elementu kolekcji danych poprzez jego indeks w kolekcji,

Weryfikacja występowania określonej zmiennej w kolekcji danych, Usunięcie określonej zmiennej z kolekcji danych, Weryfikacja czy w określonej kolekcji występują zwielokrotnione

informacje20.30 Moduł WORFKLOW musi posiadać wbudowane komponenty umożliwiające

zapis informacji do pliku w formacie XML, HTML oraz TXT.

20.31

Moduł WORFKLOW musi posiadać wbudowane komponenty umożliwiające przesłanie informacji ze ścieżki na wskazany adres email lub wiele adresów email. Wymaga się umożliwienia zdefiniowania następujących danych wiadomości email:

Od, Do, Do wiadomości, Ukryte do wiadomości, Odpowiedz na adres, Wyślij potwierdzenie, Temat, Treść, Załącznik,

Dla komponentu musi być możliwe określenie: serwera poczty wychodzącej oraz portu serwera, formatu wiadomości HTML bądź TXT, priorytetu wiadomości, zapisania wysyłanej wiadomości do pliku.

20.34

Moduł WORFKLOW musi posiadać wbudowane komponenty umożliwiające wykonywanie operacji z użyciem dat. Dostępne muszą być następujące rodzaje operacji:

a) Operacje arytmetyczne na datach: dodawanie i odejmowanie sekund, minut, godzin, dni, miesięcy, lat do wskazanej daty z uwzględnieniem jedynie właściwego czasu pracy (business hours).

b) Reguły oparte na datach warunkujące zmianę przebiegu ścieżki: Data większa niż określona data, W zależności od określonego dnia tygodnia, W zależności od roku przestępnego, W zależności od określonej godziny.

20.41

Moduł WORFKLOW musi umożliwiać definiowanie zmiennych (na każdym etapie ścieżki) oraz wykonywanie na tych zmiennych następujących operacji:

Przypisywanie wartości do zmiennej, Kopiowanie wartości do innej zmiennej, Definiowanie globalnej, unikalnej wartości zmiennej (guid), Przypisanie do zmiennej wygenerowanego numeru losowego lub

wygenerowanego losowo ciągu znaków, Usunięcie zdefiniowanej zmiennej ze ścieżki.

20.47WORKFLOW musi umożliwiać wyodrębnianie fragmentów projektu do osobnych podmodeli, modeli osadzonych oraz modeli łączonych dynamicznie. Wszystkie one muszą obsługiwać przekazywanie parametrów wejściowych i wyjściowych.

str. 57



20.48 Moduł WORKFLOW musi umożliwiać rzutowanie (deserializacja) zawartości pliku XML na zmienne określonego typu zdefiniowane w ścieżce.

20.49 Moduł WORKFLOW musi umożliwiać rzutowanie (serializacja) zawartości zmiennych określonego typu zdefiniowanych w ścieżce do pliku XML.

20.50 WORKFLOW musi zapewniać możliwość operacji na systemie plików z poziomu procesów.

20.51 WORKFLOW musi zapewniać mechanizmy lokalnego przechowywania danych (na komputerze klienta) np. w folderach Temp lub w oparciu o tzw. Isolated Storage.

20.52 Moduł WORKFLOW musi posiadać możliwość logowania operacji na każdym etapie ścieżki (w dzienniku systemu operacyjnego np.: Event Log albo we własnym dzienniku).

20.53

Moduł WORKFLOW musi umożliwiać wykonywanie następujących operacji arytmetycznych na zmiennych (Dodawanie, Odejmowanie, Mnożenie, Dzielenie, Wyliczanie wartości średniej, Pobranie wartości minimalnej pośród dostępnych, Pobranie wartości maksymalnej pośród dostępnych, Filtrowanie danych liczbowych z łańcucha znaków)

20.54Moduł WORKFLOW musi posiadać możliwość definiowania modelu dialogowego dla zadania będącego jednym z komponentów ścieżki. Model dialogowy to jeden lub seria formularzy umożliwiających kolekcjonowanie danych na podstawie informacji przekazanych przez użytkownika.

20.55

Moduł WORKFLOW musi posiadać możliwość przełączenia metody wykonywania ścieżki w tryb asynchroniczny w każdym momencie jej wykonywania.Tryb asynchroniczny zwalnia użytkownika od oczekiwania na wykonanie określonej operacji np.: użytkownik wypełnia i wysyła formularz, otrzymuje komunikat o przesłaniu danych a przetwarzaniem danych zajmuje się serwer WORKFLOW, który na podstawie żądania użytkownika generuje np.: złożone zestawienie przez 10 minut.

20.57

Moduł WORKFLOW musi umożliwiać włączenie procesu monitorującego stan określonych zdarzeń (np.: wygenerowanie złożonego raportu) i wykonanie określonych działań po zaistnieniu tych zdarzeń (np.: wysłanie poczty elektronicznej powiadamiającej o wykonaniu raportu zdefiniowane jako ścieżka podrzędna WORKFLOW).

20.58 WORKFLOW musi umożliwiać obsługę logiki projektowania działania procesów w oparciu o maszynę stanów.

20.59 Moduł WORKFLOW musi posiadać możliwość definicji przeskoków do kolejnych komponentów w ścieżce identyfikowanych przez identyfikator komponentu w ścieżce, nazwa komponentu w ścieżce.

20.60 Moduł WORKFLOW musi posiadać komponent umożliwiający wstrzymanie przebiegu ścieżki na określony czas na każdym etapie ścieżki.

20.61 Moduł WORKFLOW musi umożliwiać generowanie plików XML

20.62 Moduł WORKFLOW musi umożliwiać operację na dokumentach MS Office, w szczególności generowanie plików DOC oraz modyfikację plików XLS.

20.63 Moduł WORKFLOW musi umożliwiać generowanie plików PDF w

str. 58



szczególności zgodnych z formatem PDF/A20.64 Moduł WORKFLOW musi umożliwiać stosowanie wyrażeń regularnych w

zakresie operacji na ciągach znaków.

20.65 Komunikacja pomiędzy modułem WORKFLOW a SWP musi być prowadzona za pomocą wewnętrznego, zabezpieczonego kanału komunikacji (np. celem użycia tokenu do uwierzytelniania)

20.66

Moduł WORKFLOW musi mieć możliwość interakcji ze wszystkimi standardowymi obiektami systemu SWP. W przypadku obiektów niestandardowych, musi istnieć możliwość rozszerzenia API komunikacyjnego tak, aby możliwe było zapewnienie wykonania operacji na wszystkich elementach systemu.

20.67 Operacje wykonywane z poziomu WORKFLOW, na obiektach w SWP, są wykonywane z użyciem dedykowanych komponentów integracyjnych, których sposób użycia nie odbiega od komponentów natywnych WORKFLOW.

20. Moduł projektowania formularzy dla podsystemu Workflow

21.1 Projektowanie formularzy musi odbywać się z poziomu graficznego narzędzia wbudowanego w oferowane rozwiązanie.

21.2 Projektowanie formularzy musi być możliwe w oparciu o jeden globalny lub zindywidualizowane schematy kolorystyczne.

21.3 Zaprojektowany formularz musi być możliwy do połączenia z każdym punktem wybranej ścieżki.

21.4 Po zaprojektowaniu wybrany formularz musi być możliwy do wykorzystania w wielu ścieżkach.

21.5

Po zaprojektowaniu musi istnieć funkcja podłączenia formularza w sposób umożliwiający wykorzystanie go w zakresie obsługi elektronicznych wniosków. Formularz musi zostać podłączony w taki sposób, aby w odpowiednim miejscu oprogramowania, którym dysponuje Zamawiający możliwe było przesyłanie danych za jego pomocą (np.: poprzez Biuletyn Informacji Publicznej).

21.6

Przy tworzeniu formularza musi istnieć możliwość wykorzystania następujących narzędzi i metod:

Dodaj obraz tła formularza Wytnij (CTRL + X), Kopiuj (CTRL + C), Wklej (CTRL + V)

umożliwiające wykonanie operacji na pojedynczych elementach formularza lub grupach elementów (po zaznaczeniu kilku obiektów z przyciskiem CTRL),

Waliduj – umożliwia przetestowanie prawidłowości konstrukcji formularza. W przypadku wystąpienia błędu w formularzu wyświetla odpowiedni komunikat lub serię komunikatów o błędach odpowiadających obiektom, których dotyczą,

21.10

Przy tworzeniu formularza musi istnieć możliwość wykorzystania następujących narzędzi:

Wyrównaj obiekty formularza (do lewej, do prawej, do góry, do dołu), Dopasuj wysokość/szerokość obiektu (wyrównanie

wysokości/szerokości zaznaczonych pól formularza), Ustal kolejność przechodzenia kursora (określanie kolejności pól, po

których porusza się kursor).

str. 59



21.14 Moduł WORKFLOW musi oferować możliwość przypisywania różnych akcji następujących po użyciu przycisku formularza (np.: przesłanie formularza, wyświetlenie komunikatu, weryfikacja danych formularza).

21.15

Moduł WORKFLOW musi posiadać możliwość wykorzystania zdefiniowanych metod walidacji:

- Przechwyć wszystkie błędy (w przypadku wystąpienia błędu musi zostać wyświetlony odpowiedni komunikat, który może zostać zdefiniowany przez użytkownika). W przypadku braku błędu może zostać wyświetlony komunikat potwierdzający poprawne wykonanie formularza zdefiniowany przez użytkownika.

- Przygotowanie własnych walidatorów np. PESEL, kod miejscowości, data

21.18

Moduł WORKFLOW musi posiadać możliwość obsługi zdarzeń zachodzących po:

Kliknięcie na obiekt (onclick), Wejście na obiekt (Onfocus), Najechanie kursorem myszy na obiekt (onmouseover), Opuszczenie kursora myszy znad obiektu (onmouseout), Załadowanie dokumentu (np.: formularza) do przeglądarki (onload), Podwójnie klikniecie na obiekt (ondblclick), Przyciśnięcie przycisku myszy na obiekcie (onmousedown), Zwolnienie przycisku myszy z obiektu (onmouseup), Przejście na innych obiekt (onblur).

21.11 Moduł projektowania formularzy musi udostępniać pobieranie danych z formularzy zewnętrznych

21. Wymagania dotyczące integracji procesów Workflow z systemem SWP

22.1Moduł WORKFLOW musi umożliwiać projektowanie procesów biznesowych operujących na danych, obiektach i metadanych opisujących obiekty systemu SWP.

22.2Moduł WORKFLOW musi udostępniać zestaw komponentów pozwalających operować na danych, obiektach i meta danych obiektów systemu SWP, które projektant procesów będzie mógł wykorzystać w trakcie budowy procesu.

22.3

Moduł WORKFLOW musi udostępniać co najmniej następujący zestaw funkcji operujących na systemie SWP:

Zestaw typów danych odwzorowujących dane i meta dane obiektów w SWP.

Deklarowanie i operowanie na zmiennych typów danych związanych z SWP.

Tworzenie, modyfikowanie danych i meta danych oraz usuwanie spraw. Weryfikacja statusu sprawy. Zawieszenie i wznowienie zawieszonej sprawy Zamknięcie i ponowne otwarcie już zamkniętej sprawy Tworzenie, modyfikowanie danych i meta danych oraz usuwanie

dokumentów. Tworzenie kopii dokumentów. Sprawdzenie oraz potwierdzenie czy dokument posiada zawartość.

str. 60



Kompresja zawartości dokumentu do archiwum ZIP. Konwersja dokumentu na załącznik innego obiektu biznesowego. Dodanie zawartości dokumentu w formacie XML jako nowej wersji

dokumentu. Tworzenie, modyfikowanie, usuwanie i załączanie do innych obiektów

notatek. Tworzenie zadań procesu workflow dostępnych do realizacji dla

dedykowanych użytkowników lub grup użytkowników. Tworzenie, identyfikowanie i usuwanie powiązań między

dokumentami, sprawami i zadaniami Definiowanie i obsługa kroków procesu workflow (grupowanie zadań

w etapy realizacyjne) w SWP. Definiowanie typów i kategorii dla dokumentów i spraw. Odczyt typu słownikowego dla obiektu biznesowego. Odczyt kategorii słownikowych przypisanych do obiektu biznesowego. Modyfikacja kategorii słownikowych przypisanych do obiektu

biznesowego. Odczyt elementów wybranego słownika. Odczyt atrybutów dynamicznych przypisanych do obiektu biznesowego Modyfikacja atrybutów dynamicznych przypisanych do obiektu

biznesowego. Usunięcie atrybutu dynamicznego przypisanego do obiektu

biznesowego. Pobranie obiektów biznesowych powiązanych określonym typem

połączenia. Znakowanie i odczytywanie znaków spraw i dokumentów. Operowanie na załącznikach do spraw i dokumentów. Wysyłanie powiadomień wewnętrznych do użytkowników w ramach

systemu SWP. Dodawanie i usuwanie folderów w strukturze katalogowej systemu

SWP. Kopiowanie i przenoszenie biznesowych dokumentów, spraw, notatek

w obrębie struktury katalogowej SWP. Nadawanie i odbieranie uprawnień do obiektów w systemie SWP w

oparciu o użytkowników i grupy użytkowników Tworzenie kalendarzy i definiowanie wydarzeń jednorazowych i

cyklicznych wraz opcja przypomnień. Dodawanie elementów do bazy kontaktów i ich załączanie do spraw i

dokumentów. Weryfikacja złożenia podpisu cyfrowego na danej wersji obiektu. Wprowadzanie plików użytkownika poprzez formularz webowy

procesu workflow do systemu SWP. Zapisywanie lokalnie u użytkownika plików pobranych z systemu SWP

poprzez formularz webowy procesu workflow. Zapisywanie danych zbieranych w trakcie realizacji procesu do systemu

SWP w tym historii zmian w procesie

str. 61



Konwersja dokumentów w systemie SWP do formatu PDF z poziomu procesu workflow.

Identyfikowanie użytkowników wykonujących zadania procesów workflow, odczytywanie ich danych personalnych, teleadresowych i przynależności do komórek organizacyjnych w SWP.

Identyfikowanie zastępstw na poziomie systemu SWP w wykonywaniu zadań workflow.

Sprawdzanie istnienia określonych grup funkcyjnych, pobieranie ich danych, pobieranie ich składu osobowego, sprawdzanie przynależności użytkownika do określonej grupy w SWP.

Pobranie komórek organizacyjnych o podanym typie. Pobranie komórek organizacyjnych podrzędnych względem innej

komórki. Pobranie komórek organizacyjnych o podanych symbolach. Pobranie komórek organizacyjnych, których podany użytkownik jest

menedżerem. Pobranie użytkowników należących do podanych komórek

organizacyjnych. Odczyt danych adresowych komórki organizacyjnej. Pobieranie danych o komórkach w strukturze organizacyjnej.

Umożliwienie poruszania się w obrębie struktury organizacyjnej i wykorzystanie tych danych w procesach workflow.

Wyszukiwanie obiektów w systemie SWP według zadanych wartości meta danych obiektu.

Potwierdzenie złożenia przez użytkownika podpisu cyfrowego na obiekcie biznesowym.

II. Spis funkcjonalności istotnych, dotyczących SWP na dzień złożenia oferty

L.p. Opis wymagań

1. Wymagania ogólne dotyczące budowy SWP

1.

Administracja SWP musi odbywać się z poziomu dedykowanej aplikacji umożliwiającej zarządzanie głównymi parametrami aplikacji. Aplikacja musi działać w oparciu o przeglądarkę internetową niezależnie od SWP. Oznacza to możliwość uruchomienia tej aplikacji na innym serwerze fizycznym lub hoście wirtualnym.

2. Wymagania ogólne dotyczące instrukcji obsługi i dokumentacji technicznej

1.Dla SWP instrukcja musi być zintegrowana z interfejsem Systemu. Na poziomie okna powinien być dostępny przycisk lub odnośnik, który po użyciu odsyła użytkownika do części instrukcji dotyczącej odpowiedniej funkcji.

3. Wymagania ogólne dotyczące funkcjonalności1. SWP musi posiadać możliwość wglądu do spraw z poziomu dokumentu oraz

wglądu do dokumentów z poziomu spraw zgodnie z posiadanymi uprawnieniami.

str. 62



2.

SWP musi posiadać mechanizm definiowania rejestrów dokumentów oraz przyznawania dostępu do nich wybranym użytkownikom. Definiowanie rejestru musi umożliwiać użycie wybranych kategorii (np.: faktura, skarga, deklaracja itd.). Musi istnieć możliwość nadania nazwy rejestrowi.Nazwa rejestru i pozycja rejestru pod którą znajduje się dany obiekt powinna być dostępna z poziomu tego obiektu.SWP musi umożliwiać filtrowanie zawartości rejestru.

3. SWP musi umożliwiać każdemu użytkownikowi tworzenie oraz usuwanie skrótów do folderów. Skrót musi umożliwiać wyświetlenie zawartości folderu, do którego się odnosi.

4. SWP musi umożliwiać wysyłanie wybranych powiadomień za pośrednictwem poczty e-mail. Wiadomość taka powinna zawierać bezpośredni link umożliwiający po zalogowaniu dostęp do obiektu którego dotyczy powiadomienie.

5.SWP musi być wyposażony w macierz uprawnień do funkcji systemu. Są to uprawnienia globalne i dotyczą całości funkcjonowania aplikacji. Pozwalają określić jakich funkcji użytkownik może użyć w systemie. Zarządzanie macierzą uprawnień musi być możliwe tylko poprzez aplikację administratora.

6.

W ramach funkcjonalności szybkiej rejestracji, uzupełnionej przez mechanizm OCR, SWP musi udostępniać funkcję regionalizacji rozpoznawania tekstu podczas rejestracji dokumentu. Przez regionalizację rozpoznawania tekstu należy rozumieć oznaczanie sekcji dokumentu (sekcja reprezentowana jest przez obszar tekstu dokumentu oddzielony pustymi (białymi) przestrzeniami) identyfikatorami graficznymi (np.: otoczenie sekcji dookoła linią), które po kliknięciu w nie kursorem myszy powodują przeniesienie tekstu rozpoznanego w ramach sekcji do aktywnego pola (przez pole aktywne należy rozumieć pole, dla którego ustawiono wartość FOCUS) formularza rejestracji.SWP musi umożliwiać wybranie większej ilości rozpoznanych sekcji dokumentu poprzez zaznaczenie myszką obszaru zawierającego określone, rozpoznane obszary.SWP musi umożliwiać przeniesienie wielu zaznaczonych jednocześnie sekcji dokumentu do jednego pola metadanych na formularzu.

4. Wymagania dotyczące zarządzania systemem

1.

SWP musi umożliwiać synchronizację kont w użytkowników poprzez LDAP ze szczególnym uwzględnieniem eDirectory lub Active Directory (ostateczna decyzja w zakresie wyboru usługi katalogowej zostanie podjęta przez Zamawiającego przed podpisaniem umowy z Wykonawcą SWP) .Synchronizacji powinny podlegać, co najmniej, następujące informacje:

Imię i nazwisko, Adres email, Status konta: zablokowane, aktywne.

Narzędzia do synchronizacji muszą być wbudowane w System i dostępne z poziomu GUI. W przypadku synchronizacji AD wymagane jest by narzędzie synchronizowało również strukturę AD wraz z zagnieżdżeniami.

str. 63



5. Wymagania dotyczące bezpieczeństwa1. SWP musi posiadać mechanizm atrybutów dodatkowych umożliwiający dodawanie

określonych pól co najmniej do formatek opisu dokumentu. Atrybuty może definiować użytkownik posiadający stosowne uprawnienia za pomocą aplikacji administracyjnej. Dodawać może każdy uprawniony użytkownik.

6. Wymagania dotyczące interfejsów komunikacyjnych API

6.1

SWP musi posiadać interfejs API umożliwiający wymianę danych co najmniej w zakresie zarządzania:

folderami słownikami znakowaniem dokumentami sprawami notatkami obiektami WorkFlow jednostkami organizacyjnymi użytkownikami bezpieczeństwem i autentykacją w systemie


7.1

SWP musi zapewniać normalizację w indeksie słów posiadających "polskie znaki". Dzięki temu np. w celu znalezienia frazy "gęstość" możliwe jest podanie w zapytaniu "gestosc","gęstosc" lub "gestośc". W każdym przypadku zostanie zwrócony oczekiwany wynik.

8. Wymagania dotyczące obsługi dokumentów

8.1

SWP musi posiadać mechanizm automatycznego generowania i prezentacji podglądu plików (bez konieczności uruchamiania dedykowanych aplikacji np. MS Office) bezpośrednio z poziomu systemu dla co najmniej następujących typów plików:

a. dokumenty doc, docx, odt, pdfb. arkusze kalkulacyjne xls, xlsx, odsc. pliki graficzne:

.jpg .jpeg .tif .rtf .bmp .gif .ico .png


9.1SWP musi umożliwiać zmianę języka aplikacji co najmniej dla j. polskiego i j. angielskiego


str. 64



10.1

Moduł Workflow musi dawać możliwość implementacji procesów realizujących zadania na rzecz innych systemów Zamawiającego wykorzystując udostępnione przez te systemy sieciowe interfejsy komunikacyjne (np. WebServices). Możliwość ta ma polegać na udostępnieniu funkcjonalności projektowania formularzy oraz budowy logiki biznesowej procesów funkcjonujących w organizacji (w tym również takich, które nie są bezpośrednio związane z funkcjonowaniem SWP).

10.2Projektowanie ścieżki musi odbywać się za pomocą metody przeciągnij i upuść (ang. Drag & Drop). Do ścieżki można przenosić obiekty i zdarzenia umieszczając je w dowolnym miejscu obszaru roboczego.

11. Moduł projektowania ścieżek Workflow

11.1

Moduł WORFKLOW musi posiadać możliwość wprowadzania własnych typów danych oraz tworzenia zmiennych tych typów. Typy danych muszą być tworzone za pomocą graficznego narzędzia wbudowanego w oferowane rozwiązanie. Podczas tworzenia ścieżki WORFKLOW musi istnieć możliwość wykorzystania tak zdefiniowanego typu do utworzenia zmiennych tego typu.

11.2

Integracja oprogramowania WORKFLOW i systemu SWP musi być niezauważalna dla użytkownika końcowego (System jako rozwiązanie musi zapewniać spójny interfejs w szczególności wszystkie produkty procesu muszą być osadzone jako elementy systemu SWP np. sprawa, dokument, wpis w kalendarzu itp. zaś zadania procesowe winny stanowić jeden z jego elementów). Ścieżka zaprojektowana przy pomocy oprogramowania WORFKLOW musi zostać osadzona w interfejsie SWP.

12. Moduł projektowania formularzy dla podsystemu Workflow

12.1

Przy tworzeniu formularza musi istnieć możliwość wykorzystania następujących elementów:

1) Lista rozwijalna (ang. list box),2) Obszar tekstowy (ang. text area),3) Obszar tekstowy wyposażony w edytor umożliwiający formatowanie

wpisywanych treści,4) Pole tekstowe (ang. label).5) Pole tekstowe z autouzupełnieniem (ang. text field).6) Pole zaznaczenia (checkbox),7) Pole wyboru (radio),8) Pole przesyłania pliku,9) Obszar typu IFrame,10) Pole typu miernik postępu w postaci (procentowy, zegarowy)11) Pasek postępu,12) Link umożliwiający umieszczenia adresu URL,13) Pole budowania listy (umożliwiające dodawanie i usuwanie elementów

listy),14) Kalendarz umożliwiający wybór daty poprzez wskazanie jej w oknie

kalendarza,15) Pole obrazu umożliwiające wyświetlenie obrazu pobieranego z dysku

serwera, określonego adresu URL lub określonej bazy danych,16) Cykliczne odświeżanie formularza,17) Pole umożliwiające automatycznie zamknięcie okna formularza po

str. 65



określonym czasie,18) Pole tabeli danych umożliwiające wyświetlanie, dodawanie, usuwanie,

edycję danych tabelarycznych.19) Pole „download” umożliwiające ściągnięcie określonych danych

bezpośrednio na dysk użytkownika,20) Pole grupy przycisków zaznaczenia (checkbox) umożliwiające utworzenie

pogrupowanych przycisków w jednym obszarze formularza,21) Pole grupy przycisków wyboru (radio) umożliwiające utworzenie

pogrupowanych przycisków w jednym obszarze formularza,22) Pole oznaczania obszaru umożliwiające grupowanie elementów w obszarze

tego pola,23) Pole typu wykres umożliwiające utworzenie wykresu z danych

dostarczonych poprzez (połączenie z bazą danych, odczyt danych z pliku, odczyt danych ze zmiennych procesowych),

24) Pole typu wykres (Warstwowy, Kolumnowy, Słupkowy, Liniowy, Kołowy).25) Pole typu maska, w którym wpisane informacje muszą być formatowane

względem ustalonego wzorca np.: numer telefonu,26) Pole inkrementacji numeru umożliwiające wybór określonej liczby poprzez

użycie strzałek zwiększających lub zmniejszających liczbę wyświetlaną w polu,27) Pole umożliwiające wstawienie obrazu jako przycisku.Moduł WORKFLOW musi umożliwiać oznaczanie pól atrybutem ukryty

(hidden) tak aby nie były one widoczne na formularzu.13. Wymagania dotyczące integracji procesów Workflow z systemem SWP

13.1Moduł WORKFLOW musi udostępniać interfejs programistyczny umożliwiający projektowanie własnych komponentów i funkcji pozwalając tym samym na przyszłe rozszerzenie integracji z systemem SWP.

14. Wymagania dotyczące obsługi faksów z poziomu systemu SWP

18.1 SWP musi umożliwiać integrację z wybranym systemem faksowym w celu rejestracji odbieranych faksów.

18.2

SWP musi umożliwiać automatyczne zapisywanie faksów w postaci dokumentów przechowywanych w wybranym miejscu struktury katalogów za pomocą dedykowanego mechanizmu/usługi systemowej, który(a) wykorzystuje do tego celu co najmniej zasób dyskowy/repozytorium plikowe.

18.3 SWP musi umożliwiać powiązanie faksów z prowadzonymi w SWP sprawami.18.4 SWP musi umożliwiać definiowanie uprawnień do przeglądania faksów.

III. Spis funkcjonalności dodatkowych, dotyczących SWP na dzień złożenia oferty

str. 66



L.p. Opis wymagań

1. Wymagania ogólne dotyczące funkcjonalności

1.1SWP musi umożliwiać określenie czasu nieaktywności, po którym użytkownik zostanie automatycznie wylogowany.

1.2 Musi istnieć możliwość umieszczenia w SWP pliku w dowolnym formacie.

1.3

SWP musi posiadać mechanizm przejmowania spraw i dokumentów między użytkownikami. Przejęcie danych musi skutkować przeniesieniem wszystkich informacji z konta jednego użytkownika na konto innego użytkownika. Po przejęciu danych wszystkie informacje historyczne muszą zostać zachowane.

1.4SWP musi posiadać możliwość przesyłania powiadomień pomiędzy użytkownikami, które nie muszą być powiązane ze sprawami czy dokumentami.

1.5SWP musi umożliwiać przesłanie odpowiedzi na otrzymane powiadomienie oraz możliwość przesłania dalej otrzymanego powiadomienia.

1.6Powiadomienia w interfejsie SWP muszą być rozdzielone na wysłane oraz otrzymane.

1.7Podczas rejestracji dokumentu SWP musi umożliwiać przechodzenie pomiędzy kolejnymi polami formularza rejestracji dokumentu przy pomocy przycisku TAB (tabulacji) zgodnie z ustaloną kolejnością pól.

1.8

SWP musi generować miniatury zeskanowanych dokumentów wyświetlane podczas ręcznej rejestracji (dla opcji oferty opartej o wariant migracji konfiguracji i danych z systemu obsługi czynności kancelaryjnych intraDOK eskploatowanego przez Zamawiajacego i realizacji czynności kancelaryjnych z użyciem funkcjonalności własnych Systemu).

1.9SWP musi umożliwiać wyświetlenie dowolnego firmowego symbolu graficznego oraz numeru wersji aplikacji w głównym widoku aplikacji.

2. Wymagania dotyczące bezpieczeństwa

2.1SWP musi posiadać możliwość sortowania historii zmian względem daty wykonania operacji.

2.2SWP musi posiadać możliwość eksportu historii zmian do sformatowanego pliku tekstowego (TXT).


3.1SWP musi realizować usuwanie z indeksu tzw. „stopwords” dla języka polskiego, czyli najczęstszych słów języka nie mających istotnego znaczenia w indeksowanej treści.

3.2 Okno wyszukiwania szybkiego musi być cały czas widoczne podczas pracy z SWP.

4. Wymagania dotyczące obsługi dokumentów4.1 SWP musi umożliwiać lokalizację dokumentów w postaci papierowej oraz zmianę

str. 67



informacji o lokalizacji.

4.2 SWP musi umożliwiać przenoszenie załączników pomiędzy dokumentami.

4.3SWP musi zachowywać historię zmian adresowych oraz przechowywać informacje kto, kiedy i jakie dane kontaktowe zmienił.

4.4SWP musi umożliwiać wiązanie z adresami nadawców (firm, instytucji itp.) danych osób reprezentujących wraz z ich danymi kontaktowymi oraz nazwą pełnionej funkcji lub zajmowanego stanowiska.

5. Wymagania dotyczące obsługi spraw

5.1SWP musi posiadać możliwość zakładania spraw bez dokumentów oraz na podstawie zarejestrowanego w Systemie dokumentu.

6. Wymagania dotyczące terminarzy

6.1SWP musi udostępniać następujące widoki terminarzy: dzienny, tygodniowy, miesięczny, lista zdarzeń. W każdym z tych widoków muszą zostać wyświetlone informacje na temat ustalonych terminów.

6.2SWP musi informować użytkownika o terminach nakładających się i jednocześnie proponować najbliższy wolny termin.

7. Wymagania dotyczące obsługi zastępstw

7.1 SWP musi posiadać możliwość modyfikacji osoby zastępującej.

8. Wymagania dotyczące raportów

8.1 Raporty muszą umożliwiać wydruk wyników bezpośrednio z okna raportowego.


9.1SWP musi umożliwiać dynamiczną konfigurację szerokości kolumn wyświetlających informacje o elementach systemu poprzez przeciągnięcie myszą lub zdefiniowanie odpowiedniej wartości.

9.2SWP musi umożliwiać wybór oraz zmianę kolejności wyświetlanych kolumn zawartości folderów indywidualnie dla każdego użytkownika.

9.3SWP musi umożliwiać wybór wyświetlania wybranych modułów w głównym menu aplikacji.

10. Wymagania dotyczące obsługi faksów z poziomu systemu SWP

10.1SWP musi umożliwiać przeglądanie otrzymanych faksów w celu ich weryfikacji, uzupełnienia brakujących metadanych.

10.2SWP musi umożliwiać rejestrację dokumentów typu faks z uwzględnieniem co najmniej następujących kategorii: wychodzący i przychodzący.


11.1Część modułu WORFKLOW umożliwiająca realizację pracy według zamodelowanych procesów musi umożliwiać dostosowanie języka interfejsu użytkownika do ustawień stacji klienckiej.

11.2

Moduł WORKFLOW musi być wyposażony we wbudowaną pomoc kontekstową dotyczącą pojedynczej formatki, wykorzystywanego komponentu oraz poszczególnych pól komponentu. Po wybraniu pomocy na poziomie komponentu musi pojawić się opis przyporządkowany do tego komponentu.

11.3 Moduł WORKFLOW umożliwia wykorzystanie wyrażeń arbitralnych OR, XOR, AND w zakresie realizacji warunków określonych w poszczególnych punktach

str. 68



ścieżki.

11.4Moduł WORKFLOW musi posiadać możliwość wydruku modelu ścieżki MODUŁ WORKFLOW.

str. 69



Załącznik 2 do OPZKoncepcja formularza ogólnego

plik exel do pobrania ze stronywww.ncbir.pl./bip/zamowienia-publiczne/

str. 70

http://www.ncbir.pl./bip/zamowienia-publiczne/



Załącznik 3 do OPZSpecyfikacja funkcjonalności systemu do obsługi czynności kancelaryjnych intraDOK

SPECYFIKACJA

System do obsługi czynności kancelaryjnych – rejestr korespondencji i spraw oparty o aplikację INTRADOK posiadającą następujące moduły:

Lp.

Moduł Opis Korzyści

1.

Moduł dokumenty

Umożliwia skanowanie, opisywanie i przekazywanie dokumentów do użytkowników w strukturze organizacyjnej. W ramach modułu zaimplementowano funkcje umożliwiające łączenie dokumentów między sobą, dołączanie ich do spraw oraz przenoszenie ich do wybranych folderów. Każdy zarejestrowany dokument otrzymuje swój indywidualny numer przydzielany automatycznie przez system oraz może dziedziczyć znaki spraw, do których został dołączony.

W ramach modułu istnieją funkcje umożliwiające identyfikację miejsc przechowywania dokumentów papierowych oraz potwierdzeń odbioru dokumentów.

Zapewnia kontrolę nad dokumentami przechowywanymi w systemie.

Każdy dokument istnieje tylko w jednej kopii a możliwość przekazania go w formie elektronicznej (skan, plik) niweluje potrzebę drukowania lub kserowania dokumentu.

Umożliwia przekazanie dokumentu do dowolnej grupy użytkowników.

2. Moduł Sprawy Umożliwia prowadzenie spraw zgodnie z Instrukcją Kancelaryjną oraz Rzeczowym Wykazem Akt. Zawiera szereg funkcji umożliwiających znakowanie spraw zgodnie z RWA. Każda sprawa może zostać opisana wieloma parametrami ze szczególnym uwzględnieniem terminów

Zapewnia zgodność z obowiązującymi przepisami prawa.

Umożliwia grupowanie różnych elementów w sprawach.

Nadzoruje terminowość załatwia spraw.

Przyspiesza dostęp do informacji przechowywanych w sprawach.

str. 71



Lp.


realizacji, na bazie których przestrzegane są przepisy załatwiania spraw wynikające z Kodeksu Postępowania Administracyjnego.

Sprawy mogą być zakładane hierarchicznie w relacji Nadrzędna – Podrzędna, gdzie załatwienie sprawy nadrzędnej zależy od podrzędnej.

W module dla każdej sprawy można określać osoby prowadzące oraz zarządzać dostępem do spraw zgodnie z uprawnieniami.

Każda sprawa może posiadać kilka stanów.

3.

Moduł notatki Umożliwia przesyłanie wiadomości tekstowych pomiędzy użytkownikami gwarantując zapamiętanie wszelkich informacji w SEOD. Notatki mogą być dołączane do Dokumentów oraz Spraw.

Usprawnia wymianę informacji pomiędzy użytkownikami.Zapewnia kontrolę przesyłanych informacji.

4. Moduł użytkownicy

Umożliwia zarządzanie kontami użytkowników. Dzięki funkcjom modułu możliwe jest dodawanie, usuwanie i modyfikacji kont poszczególnych użytkowników. Każdy użytkownik ma możliwość tworzenia w ramach własnego konta grupy użytkowników, z którymi najczęściej współpracuje i dzięki temu szybciej wykonywać swoje obowiązki.Moduł umożliwia kontrolę liczby zalogowanych użytkowników, możliwość wylogowania każdego

Umożliwia zarządzanie kontami użytkowników i grup.Nadzoruje i umożliwia audytowanie kont użytkowników.Podwyższa bezpieczeństwo poprzez zapis nieudanych prób dostępu.

str. 72



Lp.


użytkownika, blokowanie możliwości podwójnego logowania na jedno konto. W ramach logu systemowego zapisywane są zdarzenia związane z próbami logowania, które się nie powiodło.

5.

Moduł Struktura Organizacyjna

Umożliwia zarządzanie wielopoziomową strukturą organizacyjną poprzez tworzenie komórek, stanowisk i przypisywanie do nich użytkowników pełniących określone funkcje.Funkcje modułu umożliwiają również tworzenie podległości służbowych, z których z kolei wynikają uprawnienia dostępu do informacji przechowywanych na kontach poszczególnych użytkowników (przełożony ma wgląd do wszystkich informacji przechowywanych na kontach swoich podwładnych oraz raportów, które ich dotyczą).

Umożliwia odwzorowanie najbardziej złożonych struktur organizacji.Nadzoruje uprawnienia wynikające ze struktury organizacyjnej.

6. Moduł ustawienia

Moduł udostępnia szereg funkcji umożliwiających personalizację interfejsu użytkownika. Każdy użytkownik może w ramach własnego konta dowolnie zmieniać szerokość kolumn wyświetlających informację, układ okna odczytu zawartości dokumentu lub sprawy, wybierać kolumny, które mają być wyświetlane w dokumentach, sprawach i pozostałych elementach (kolumny zawierają informacje opisowe (metadane) dotyczące każdego elementu). Każdy użytkownik może również oznaczyć elementy o których

Umożliwia personalizację interfejsu aplikacji przez co staje się ona bardziej przyjazna.Ułatwia pracę z systemem.

str. 73



Lp.


będzie powiadamiany w przypadku wystąpienia w nich zmian. Możliwe jest również wybranie sposobu sortowania danych w kolumnach.

7.

Moduł pomoc W SEOD wbudowano moduł pomocy kontekstowej zawierający pełną instrukcję obsługi. Moduł jest zintegrowany z SEOD i zawiera wyszukiwarkę oraz indeks wyrażeń ułatwiający dotarcie do informacji.Prócz tego w ramach modułu dostarczana jest pomoc kontekstowa przypisana do pojedynczego elementu np.: okna sprawy, a nawet pola dat w sprawie odnosząca się bezpośrednio do takiego elementu.

Zapewnia stały dostęp do pomocy każdemu użytkownikowi.Skraca czas wymagany na szkolenia użytkowników.Umożliwia dokształcanie się użytkowników w każdym momencie i w dowolnym zakresie.

8. Moduł Baza Adresowa

Umożliwia kontrolę nad podmiotami, z którymi następuje wymiana informacji. Dzieli podmioty na fizyczne oraz prawne zgodnie z ustawą o Ochronie Danych Osobowych. Zapewnia śledzenia zmian następujących w ramach konta wybranego podmiotu oraz dostęp do wszelkich informacji, które z tym podmiotem były powiązane.Moduł umożliwia również eksport oraz import danych teleadresowych z innego oprogramowania np.: kadrowo – płacowego. Baza adresowa zawiera mechanizm umożliwiający dodawanie kolejnych podmiotów oraz wykorzystanie (poprzez wyszukiwanie) istniejących

Umożliwia kontrolę nad podmiotami, z którymi organizacja prowadzi korespondencję.Zapewnia spójność danych nawet w przypadku zmiany danych teleadresowych wybranego podmiotu.Zapewnia zgodność z UoODO.Umożliwia wykorzystanie danych teleadresowych podmiotu podczas pracy z SEOD bez konieczności wpisywania ich przy każdej operacji z nim związanej.

str. 74



Lp.


podmiotów podczas rejestracji.

9.

Moduł Historii Umożliwia zapis historii zdarzeń występujących w poszczególnych elementach systemu. Moduł zawiera pełną informację na temat dystrybucji dokumentu, sprawy, nadawania uprawnień itp. Poprzez udostępniane informacje istnieje możliwość identyfikacji: czasu i opisu wykonywanych operacji, informacją o osobach, które te operacje wykonały, elementu, którego dotyczy operacja oraz czynności, której dotyczy operacja.

Zapewnia kontrolę nad wszystkimi ważnymi elementami systemu.Zapewnia możliwość odtworzenia procesu wykonywanych operacji.Powoduje wzrost bezpieczeństwa aplikacji.Zabezpiecza przed możliwością wykonania nieautoryzowanych działań.

10.

Moduł Rejestry Umożliwia dodawanie, usuwanie i modyfikację rejestrów, które stanowią osobne zbiory dokumentów lub spraw o określonych parametrach. Możliwe jest utworzenie rejestru o charakterystyce Dokument przychodzący/Faktura o przydzielenie dostępu do tego rejestru wybranym użytkownikom. Rejestry mogą być tworzone na podstawie RWA zgodnie z Instrukcją Kancelaryjną. Każdy definiowany rejestr może posiadać swoją unikalną numerację.

Umożliwia dostęp do informacji o dokumentach lub sprawach zgodnie z parametrami podanymi przez użytkownika.Umożliwia dostęp do elementów systemu bez konieczności przydzielania ich użytkownikom (bezpośrednio prze rejestr).

11. Moduł RWA Moduł umożliwia zarządzanie Rzeczowym Wykazem Akt. Zawiera funkcję umożliwiającą import danych z pliku zawierającego strukturę RWA. Funkcje uprawnień RWA umożliwiają nadawanie dostępu do RWA poszczególnym użytkownikom. RWA może zostać skonfigurowane w

Pełna zgodność z przepisami obowiązującymi w Administracji Publicznej.Możliwość importu pełnego RWA wraz z podteczkami utworzonymi przez Organizację na własne potrzeby.Wsparcie dla użycia haseł RWA przez SEOD.

str. 75



Lp.


sposób umożliwiający „uczenie się” haseł klasyfikacyjnych użytych podczas znakowania spraw. Funkcje RWA mogą uniemożliwić ponowne znakowanie spraw wcześniej usuniętymi znakami teczek w celu uniknięcia błędów wynikających z niepoprawnego przyporządkowania korespondencji do spraw.

12.

Moduł Formularze

Funkcje modułu umożliwiają utworzenie formularza składającego się z wielu różnych typów pól (tekstowe, wyboru, liczbowe) wraz z walidacją danych wpisywanych do pól. Utworzone formularze mogą być wielokrotnie używane w różnych elementach: sprawach, dokumentach, procesach workflow.

Możliwość dodawania do systemu dodatkowych informacji specyficznych dla działalności prowadzonej przez wybraną organizację.

13.

Moduł Integracja z LDAP

SEOD posiada możliwość integracji z LDAP (Active Directory), który zawiera funkcje umożliwiające synchronizację danych kont użytkowników oraz utworzenie punktu pojedynczego logowania. Dzięki zastosowaniu modułu użytkownicy nie są zmuszeni do podania identyfikatora i hasła podczas dostępu do SEOD i są automatycznie logowani na konto systemu operacyjnego.Mimo wykorzystania modułu stale dostępna jest możliwość autoryzacji użytkowników w wewnętrznej bazie SEOD.

Jeden punkt logowania użytkownika.Centralna baza użytkowników ułatwiająca zarządzanie kontami.Łatwiejsze spełnienie zasad polityki bezpieczeństwa.

str. 76



str. 77



Załącznik 4 do OPZRobocze wersje procedur

z powiązanymi wzorami formularzy jako ilustracja kluczowych procesów wymagających

wsparcia Systemem SWP

plik exel do pobrania ze stronywww.ncbir.pl./bip/zamowienia-publiczne/

str. 78

http://www.ncbir.pl./bip/zamowienia-publiczne/



Załącznik nr 2 do Ogłoszenia

...............................................Nazwa i siedziba (pieczęć) Wykonawcy

Oświadczenieo spełnieniu warunków udziału w postępowaniu,

o których mowa w art. 22 ust. 1 ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2010 r. Nr 113, poz. 759 z późn. zm.)

Składając wniosek o dopuszczenie do udziału w postępowaniu prowadzonym w trybie dialogu konkurencyjnego na: Zakup, dostosowanie do potrzeb NCBR poprzez parametryzację i wykonanie dodatkowych komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP), oświadczam/y, że spełniam/y warunki określone w art. 22 ust. 1 ww. ustawy, dotyczące:1) posiadania uprawnień do wykonywania określonej działalności lub czynności, jeżeli przepisy

prawa nakładają obowiązek ich posiadania;2) posiadania wiedzy i doświadczenia;3) dysponowania odpowiednim potencjałem technicznym oraz osobami zdolnymi do

wykonania zamówienia;4) sytuacji ekonomicznej i finansowej.

…………..…………………… dnia …………. 2012 r.

……………………………………………………… (podpis/y osoby/osób reprezentujących

Wykonawcę/Wykonawców)

str. 79

Załączniki do ogłoszenia - postępowanie nr 61/12/DKpn.: Zakup, dostosowanie do potrzeb NCBR poprzez parametryzację i wykonanie dodatkowych

komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP)-----------------------------------------------------------------------------------------------------------------



Oświadczenieo braku podstaw do wykluczenia z postępowania w okolicznościach,o których mowa w art. 24 ust. 1 i 2 ustawy z dnia 29 stycznia 2004 r.

Prawo zamówień publicznych (Dz. U. z 2010 r. Nr 113, poz. 759 z późn. zm.)

Składając wniosek o dopuszczenie do udziału w postępowaniu prowadzonym w trybie dialogu konkurencyjnego na: Zakup, dostosowanie do potrzeb NCBR poprzez parametryzację i wykonanie dodatkowych komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP), oświadczam/y, że nie podlegam/y wykluczeniu z postępowania na podstawie art. 24 ust. 1 ww. ustawy.

…………..…………………… dnia …………. 2012 r.

……………………………………………………… (podpis/y osoby/osób reprezentujących


str. 80





Wykaz wykonanych usług

Składając wniosek o dopuszczenie do udziału w postępowaniu prowadzonym w trybie dialogu konkurencyjnego na: Zakup, dostosowanie do potrzeb NCBR poprzez parametryzację i wykonanie dodatkowych komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP), oświadczam/y, że w okresie ostatnich trzech lat przed upływem terminu składania wniosku o dopuszczenie do udziału w dialogu konkurencyjnym, a jeżeli okres prowadzenia działalności jest krótszy — w tym okresie, wykonaliśmy, a w przypadku świadczeń okresowych lub ciągłych również wykonujemy, usługi w zakresie niezbędnym do wykazania spełniania warunku, o którym mowa w cz. III.2.3) Ogłoszenia. Ponadto, zamieszczamy także informacje umożliwiające ocenę wniosek o dopuszczenie do udziału w postępowaniu na podstawie właściwości Wykonawcy, zgodnie z kryterium określonym w IV.1.2) Ogłoszenia.

Lp. Przedmiot zamówieniaNazwa projektu/systemu

Daty wykonania(od – do)

Odbiorcy(nazwa, adres)

Projekt, który był realizowany na terytorium Polski i dotyczył zaprojektowania i wdrażania systemu informatycznego, który obejmował bezpieczny dostęp do scentralizowanego systemu przez sieć www z wykorzystaniem przeglądarki oraz posiadał modułową strukturę, realizującą co najmniej funkcjonalność projektowania formularzy, obiegu dokumentów i spraw oraz obsługi kancelarii i repozytorium dokumentów, został stworzony dla minimum 300 nazwanych użytkowników i 15 procesów lub wyodrębnionych podprocesów.

1.Okres utrzymania ww. systemuOkres hostingu ww. systemu



str. 81



Lp. Przedmiot zamówieniaNazwa projektu/systemu

Daty wykonania(od – do)

Odbiorcy(nazwa, adres)



UWAGA: Do każdego zamówienia wymienionego w wykazie należy załączyć dokument potwierdzający, że zamówienie to zostało wykonane należycie.

…………..…………………… dnia …………. 2012 r.

…………………………………………………… (podpis/y osoby/osób reprezentujących


str. 82





Wykaz osóbSkładając wniosek o dopuszczenie do udziału w postępowaniu prowadzonym w trybie dialogu konkurencyjnego na: Zakup, dostosowanie do potrzeb NCBR poprzez parametryzację i wykonanie dodatkowych komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP), oświadczam/y, że dysponujemy osobami, które będą uczestniczyć w wykonywaniu zamówienia i spełniają warunki, o których mowa w cz. III.2.3) Ogłoszenia. Ponadto, zamieszczamy także informacje umożliwiające ocenę wniosku o dopuszczenie do udziału w postępowaniu na podstawie właściwości Wykonawcy, zgodnie z kryterium określonym w IV.1.2) Ogłoszenia.

Kierownik projektu – posiadający wyższe wykształcenie oraz kwalifikacje potwierdzone jednym ze wskazanych certyfikatów: „PRINCE2” lub IPMA lub Project Management Professional (PMP); który w ciągu ostatnich 3 lat pełnił funkcję kierownika projektu w co najmniej jednym zakończonym sukcesem projekcie, którego wynikiem jest wdrożenie systemu o ilości użytkowników końcowych min. 300.Imię i Nazwisko: …………………………………………………………………………………Architekt – posiadający wyższe wykształcenie, który w ciągu ostatnich 3 lat nabył doświadczenie w zakresie projektowania (tworzenia) architektury systemów informatycznych. Ponadto w ciągu ostatnich 3 lat nabył co najmniej 12 miesięczne doświadczenie w zakresie projektowania architektury: systemów zorientowanych na usługi (SOA), systemów w architekturze wielowarstwowej, systemów o wysokiej wydajności i niezawodności, systemów wykorzystujących bazy danych. A także w ciągu ostatnich 3 lat, brał udział w co najmniej 2 projektach, obejmujących swym zakresem budowę architektury systemów informatycznych dotyczących wdrożenia systemu EZD był odpowiedzialny za zaprojektowanie architektury IT systemu.Imię i Nazwisko: …………………………………………………………………………………Analitycy (co najmniej trzy osoby) – z których każda posiada wyższe wykształcenie oraz minimum 2-letnie doświadczenie zawodowe w zakresie analizy biznesowej lub systemowej (zespół analityków musi posiadać doświadczenie zarówno w zakresie analizy biznesowej jak i systemowej), a także w ciągu ostatnich 2 lat, w co najmniej 2 projektach, modelował procesy biznesowe lub systemowe. Ponadto co najmniej jeden z nich w ciągu ostatnich 3 lat przez okres co najmniej 6 miesięcy zarządzał zespołem zadaniowym, a także co najmniej jeden z nich posiada doświadczenie w roli analityka wiodącego (lub równoważnej roli) w realizacji minimum jednego projektu informatycznego, którego wynikiem jest wdrożenie systemu o ilości użytkowników min. 300.Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………

str. 83



Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Eksperci ds. projektowania komponentów programowych (co najmniej dwie osoby) - posiadające wyższe wykształcenie oraz minimum 5-letnie doświadczenie w projektowaniu/tworzeniu systemów informatycznych potwierdzone udziałem przez cały czas trwania projektu w co najmniej 2 projektach informatycznych zakończonych sukcesem. A także w okresie ostatnich 5 lat wykonywał w sumie co najmniej przez 2 lata zadania w zakresie administracji, strojenia, wdrożenia, dostosowania do potrzeb użytkowników systemów informatycznych.Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Ekspert ds. bezpieczeństwa - posiadający wyższe wykształcenie oraz minimum 5-letnie doświadczenie zawodowe w zakresie bezpieczeństwa teleinformatycznego; posiada doświadczenie w realizacji przynajmniej jednego projektu informatycznego w roli wiodącego eksperta ds. bezpieczeństwa teleinformatycznego; posiada ważny certyfikat związany z bezpieczeństwem teleinformatycznym (np. CompTIA Security+, Certyfikat Certified Information Systems Security Professional, Certified Information Security Manager, Certified Information Systems Auditor lub równoważny).Imię i Nazwisko: …………………………………………………………………………………Specjaliści ds. wdrożenia i utrzymania (co najmniej dwie osoby) - posiadające doświadczenie w zakresie wdrażania systemów informatycznych (w ostatnich latach odpowiadał za przeprowadzenie zakończonego sukcesem wdrożenia w którym liczba użytkowników końcowych przekracza 300 osób); a także posiadających doświadczenie w zakresie projektowania i wdrażania systemów zapewnienia ciągłości funkcjonowania (synchronizowanie i przełączanie ośrodków przetwarzania, systemy backupu, systemy do odtwarzania po awarii, rozwiązania o wysokiej niezawodności i dostępności); Ponadto posiadających doświadczenie w projektowaniu utrzymania dla systemów informatycznych, projektowaniu procesów utrzymaniowych, ról i odpowiedzialności.Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Specjaliści ds. wytworzenia oprogramowania (co najmniej trzy osoby), z których każda posiada minimum 5-letnie doświadczenie w programowaniu potwierdzone udziałem przez cały czas trwania projektu w co najmniej 2 projektach informatycznych zakończonych sukcesem; Każdy posiada doświadczenie w roli specjalisty ds. wytwarzania oprogramowania w realizacji co najmniej 2 projektów informatycznych zakończonych wdrożeniem systemu o łącznej ilości użytkowników końcowych min. 300. Przynajmniej jeden ze specjalistów posiada doświadczenie w integracji systemów z ePUAP. Przynajmniej dwóch posiada umiejętność tworzenia dokumentacji w języku polskim.Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………

str. 84



Imię i Nazwisko: …………………………………………………………………………………Imię i Nazwisko: …………………………………………………………………………………Ekspert ds. zapewnienia jakości - posiadający wyższe wykształcenie oraz doświadczenie w testowaniu aplikacji oraz znajomość procedur, metod zapewnienia jakości oprogramowania i narzędzi testowych oraz posiada doświadczenie potwierdzone udziałem w przynajmniej jednym projekcie informatycznym w roli specjalisty ds. zapewnienia jakości.Imię i Nazwisko: …………………………………………………………………………………

…………..…………………… dnia …………. 2012 r.

…………………………………………………… (podpis/y osoby/osób reprezentujących


str. 85




WNIOSEK O DOPUSZCZENIE DO UDZIAŁU W DIALOGU KONKURENCYJNYM

Do: Narodowe Centrum Badań i Rozwoju, 00–695 Warszawa, ul. Nowogrodzka 47A

Odpowiadając na ogłoszenia dotyczące postępowania o udzielenie zamówienia publicznego pn.: Zakup, dostosowanie do potrzeb NCBR poprzez parametryzację i wykonanie dodatkowych komponentów oraz hosting i wsparcie serwisowe Systemu Wspomagającego Pracę (SWP) prowadzonego w trybie dialogu konkurencyjnego

Ja/my niżej podpisany/i …………………………………………..………………………..…………………………...……………………………………..………………………………..……………………………... działając w imieniu i na rzecz: ………………...............................................................................................................................Nazwa i siedziba Wykonawcy - zgodnie z wpisem do KRS lub ewidencją działalności gospodarczejNIP: …............................................................... REGON: …......................................................Tel. …................................................................ Fax. ….............................................................. http// ….............................................................. e-mail: ….......................................................... (W przypadku składania oferty przez podmioty wspólnie ubiegające się o udzielenie zamówienia należy podać nazwy (firmy) i dokładne adresy wszystkich Wykonawców np. wspólników spółki cywilnej lub członków konsorcjum) Osoba do kontaktów: ....................................................................... (Imię Nazwisko, tel., e-mail)

1. Składam/y wniosek o dopuszczenie do udziału w dialogu konkurencyjnym. 2. Oświadczam/y, że zapoznaliśmy się z warunkami podanymi przez Zamawiającego

w Ogłoszeniu i uznajemy się związanymi określonymi w niej zasadami postępowania oraz zdobytymi informacjami niezbędnymi do przygotowania wniosku o dopuszczenie do udziału w dialogu konkurencyjnym.

3. Oświadczam/y, że zapoznaliśmy się i jesteśmy w stanie spełnić warunki podane przez Zamawiającego w Załączniku 1 do OPZ dotyczące Wymagań krytycznych.

4. Wszelką korespondencję w sprawie niniejszego postępowania należy kierować na poniższy adres: .......................................................................................................................

5. Załącznikami do niniejszego wniosku o dopuszczenie do udziału w dialogu konkurencyjnym są: 1) Oświadczenie o spełnianiu warunków z art. 22 ust. 1 ustawy, sporządzone według

Załącznika nr 2 do Ogłoszenia; 2) Oświadczenie o braku podstaw do wykluczenia, sporządzone według Załącznika nr 3 do

Ogłoszenia; 3) Wykaz wykonanych usług, sporządzony według Załącznika nr 4 do Ogłoszenia; 4) Wykaz osób, sporządzony według Załącznika nr 5 do Ogłoszenia;5) Inne………………

…………..…………………… dnia …………………. 2012 r.

str. 86



…………………………………………………………(podpis/y osoby/osób (pieczątki) reprezentujących Wykonawcę/Wykonawców)

str. 87

bip.ncbr.gov.pl€¦ · Web viewz powszechnych języków/środowisk programistycznych: C/C++,...

Documents

Transcript of bip.ncbr.gov.pl€¦ · Web viewz powszechnych języków/środowisk programistycznych: C/C++,...