PRZETARGU NIEOGRANICZONEGO

SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA

w postępowaniu o udzielenie zamówienia publicznego prowadzonym w trybie

na podstawie art. 39 ustawy z 29 stycznia 2004 r. - Prawo zamówień publicznych (Dz. U. z 2015 r., poz. 2164 z późn. zm.), o wartości szacunkowej zamówienia powyżej 209 000 EURO.

Sygn. postępowania: EZ-240-66/2016

PRZEDMIOT ZAMÓWIENIA:

Opracowanie i uruchomienie e-Usług z obszarów PSG i PSH

w Państwowym Instytucie Geologicznym Państwowym Instytucie Badawczym

ZATWIERDZAM: 10.10.2016 r.

Zastępca Dyrektora Państwowego Instytutu Geologicznego Państwowego Instytutu Badawczego

Prokurent

xx Xxxxxx Xxxxxx

Użyte w niniejszym dokumencie skróty i sformułowania oznaczają:

1. „ustawa Pzp” – ustawę z 29 stycznia 2004 r. - Prawo zamówień publicznych (Dz. U. z 2015 r., poz. 2164 z późn. zm.);

2. „SIWZ” – niniejszą Specyfikację Istotnych Warunków Zamówienia;

3. „Zamawiający” – Państwowy Instytut Geologiczny – Państwowy Instytut Badawczy;

4. „Wykonawca” – zgodnie z definicją zawartą w art. 2 pkt 11) ustawy Pzp.

1. ZAMAWIAJĄCY

Państwowy Instytut Geologiczny – Państwowy Instytut Badawczy (PIG-PIB) 00-000 Xxxxxxxx

xx. Xxxxxxxxxx 0

NIP: 000-000-00-00

REGON: 000332133

2. TRYB UDZIELENIA ZAMÓWIENIA

Postępowanie o udzielenie niniejszego zamówienia prowadzone jest w trybie przetargu nieograniczonego o szacunkowej wartości zamówienia powyżej 209 000 euro, zgodnie z przepisami ustawy z 29 stycznia 2004 r.

– Prawo zamówień publicznych (Dz. U. z 2015 r. poz. 2164 z późn. zm), dalej zwaną ustawą Pzp.

3. OPIS PRZEDMIOTU ZAMÓWIENIA

3.1. Przedmiotem zamówienia jest opracowanie i uruchomienie e-Usług z obszarów PSG i PSH poprzez: wykonanie, dostawę, instalację, uruchomienie i wdrożenie oraz zakup licencji oprogramowania do uruchomienia rozwiązania rozszerzającego działający w PIG-PIB system do monitorowania procesów digitalizacji dokumentów w NAG PIG-PIB o nowe procesy i moduły.

3.2. Szczegółowy zakres przedmiotu zamówienia został określony w:

− załączniku nr 1 do SIWZ – „Opis przedmiotu zamówienia”;

− Załączniki nr 1.1 do SIWZ – „Opis próbki produktu”;

− załączniku nr 2 do SIWZ – „Istotne postanowienia umowy”.

3.3. Oznaczenie przedmiotu zamówienia wg Wspólnego Słownika Zamówień (CPV): Kod i nazwa CPV: 48517000-5 – pakiety oprogramowania informatycznego.

4. TERMIN WYKONANIA ZAMÓWIENIA

4.1. Przedmiot niniejszego zamówienia zrealizowany będzie zgodnie z nw. terminami:

4.1.1. przedmiot umowy zostanie wykonany w całości w terminie 9 miesięcy od dnia podpisania Umowy, zgodnie z harmonogramem ustalonym w DIP, przy czym odbiór ostatniej iteracji budowy Systemu nie może nastąpić później niż 7 miesięcy od daty podpisania umowy;

4.1.2. dostawa licencji oprogramowania nastąpi nie później niż w ciągu 3 dni roboczych od dnia podpisania Umowy, lecz nie później niż do dnia 29 grudnia 2016 r.;

4.1.3. usługi Maintenance będą świadczone przez okres 1 roku licząc od dnia odbioru dostawy licencji oprogramowania;

4.1.4. usługi wsparcia wdrożonego Systemu będą świadczone przez okres 2 lat licząc od dnia odbioru pierwszej Iteracji wdrożenia Systemu.

5. OFERTY CZĘŚCIOWE, WARIANTOWE

5.1. Zamawiający nie dopuszcza możliwość składania ofert częściowych.

5.2. Zamawiający nie dopuszcza składania ofert wariantowych.

6. INFORMACJA O ZAMÓWIENIACH O KTÓRYCH MOWA W ART. 67 UST. 1 PKT 6

Zamawiający nie przewiduje możliwości udzielenia zamówienia, o którym mowa w art. 67 ust. 1 pkt 6 ustawy Pzp.

7. WARUNKI UDZIAŁU W POSTĘPOWANIU

7.1. O udzielenie zamówienia mogą ubiegać się Wykonawcy, którzy spełniają określone przez Xxxxxxxxxxxxx w niniejszym rozdziale warunki udziału w postępowaniu dotyczące:

7.1.1. kompetencji lub uprawnień do prowadzenia określonej działalności zawodowej,

7.1.2. sytuacji ekonomicznej lub finansowej,

7.1.3. zdolności technicznej lub zawodowej.

7.2. W zakresie „zdolności technicznej lub zawodowej” Wykonawca zobowiązany jest wykazać, że:

7.2.1. w okresie ostatnich trzech lat przed upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy – w tym okresie, zaprojektował i wdrożył co najmniej dwa systemy teleinformatyczne zbudowane w architekturze SOA, przy czym wartość przynajmniej jednego z nich wyniosła minimum 1.500.000 PLN brutto.

W przypadku, gdy wartość zamówienia została wyrażona w walucie innej niż PLN, Wykonawca zobowiązany jest do jej przeliczenia na PLN przyjmując jako podstawę średni kurs danej waluty opublikowany przez NBP (wg tabeli A kursów średnich walut obcych) w dniu publikacji niniejszego ogłoszenia o zamówieniu w DzU UE.

7.2.2. posiada specjalizację produktową Oracle w następującym zakresie:

- WebLogic Server 12c,

- Application Development Framework 12c, lub równoważną innego producenta

7.2.3. Dysponuje osobami skierowanymi do realizacji zamówienia, w tym co najmniej:

7.2.3.1. Kierownikiem projektu (co najmniej 1 osoba) Wymagania:

a) wykształcenie wyższe o kierunku technicznym,

b) kompetencje w zakresie zarządzania złożonymi projektami informatycznymi*,

c) posiadająca certyfikat PRINCE2 Practitioner,

d) minimum 5- letnie doświadczenie poprowadzenia co najmniej 2 projektów informatycznych o wartości co najmniej 2 000 000,00 PLN netto każdy.

*pod pojęciem złożone projekty informatyczne Zamawiający rozumie projekty polegające na wdrożeniu co najmniej 2 modułów merytorycznych w ramach jednego projektu, lub projekty obejmujące w szczególności dostawę licencji, wdrożenie systemu, usługę szkolenia oraz wykonanie testów – w ramach jednego projektu.

7.2.3.2. Architekt (co najmniej 1 osoba) Wymagania:

a) wykształcenie wyższe o kierunku informatycznym,

b) kompetencjami w zakresie tworzenia architektury zintegrowanych systemów informatycznych,

c) certyfikat TOGAF,

d) minimum 5-letnie doświadczenie w zaprojektowaniu co najmniej 2 zintegrowanych systemów informatycznych zbudowanych w architekturze SOA o wartości co najmniej 1 500 000,00 PLN netto każdy.

7.2.3.3. Analitycy (co najmniej 1osoba)

Wymagania:

a) kompetencje analityczne w zakresie wykorzystania notacji UML na poziomie co najmniej poświadczonym certyfikatem UML Professional Intermediate,

b) minimum 3-letnie doświadczenie w wykonaniu analiz i projektów co najmniej 2 zintegrowanych systemów informatycznych zbudowanych w architekturze SOA o wartości co najmniej 1 500 000,00 mln PLN netto każdy.

7.2.3.4. Programiści (co najmniej 3 osoby) ze znajomością technologii Oracle oraz architektury systemu opartej o usługi (SOA).

Wymagania

certyfikat poświadczającym kompetencje w zakresie technologii Oracle,

certyfikat poświadczającym kompetencje w zakresie projektowania lub budowy architektury systemu opartej o usługi (SOA).

7.2.3.5. Administratorzy (co najmniej 1 osoba)

Wymagania

kompetencjami w zakresie administrowania, monitorowania i optymalizowania działania baz danych Oracle, na poziomie co najmniej poświadczonym certyfikatem Oracle Database 11g Administrator Certified Professional (lub Oracle Database 12c Administrator Certified Professional)

7.2.3.6. Testerzy (co najmniej 2 osoby)

Wymagania

certyfikat poświadczającym kompetencje w zakresie testowania systemów, np. ISTQB Foundation Level

Uwaga: Zamawiający nie dopuszcza możliwości wystąpienia tej samej osoby w różnych rolach wskazanych w pkt 7.2.3.1 – 7.2.3.6 SIWZ w ramach jednej oferty.

7.2.3.7. Osoby skierowane do realizacji zamówienia o których mowa w pkt 7.2.3.1 – 7.2.3.6. muszą posiadać następujące certyfikaty Oracle:

a) obszar: framework budowy aplikacji JEE

certyfikat: Oracle Application Development Framework 12c Certified Implementation Specialist – 3 osoby

b) obszar: szyna usługowa

certyfikat: Oracle SOA Suite 12c Certified Implementation Specialist - 1 osoba

c) obszar: silnik procesów biznesowych

certyfikat: Oracle Unified BPM 11g Certified Implementation Specialist 11g – 1 osoba

d) obszar: portal

certyfikat: Oracle WebCenter Portal 11g Certified Implementation Specialist – 1 osoba

e) obszar: repozytorium dokumentów,

certyfikat: Oracle WebCenter Content 11g Certified Implementation Specialist – 1 osoba

Wykonawca dysponuje co najmniej 7 osobami mogących łącznie wykazać się wymaganymi powyżej kompetencjami w zakresie tworzenia rozwiązań w oferowanej technologii, poświadczonymi certyfikatami wydanymi przez firmę Oracle, używanej w Instytucie.

WYKONAWCA W FORMULARZU JEDNOLITEGO EUROPEJSKIEGO DOKUMENTU

ZAMÓWIENIA, zwanego dalej „JEDZ” (część IV Kryteria kwalifikacji, pkt C) POWINIEN OPISAĆ ZDOLNOŚĆ TECHNICZNĄ I ZAWODOWĄ W TAKI SPOSÓB, ABY ZAMAWIAJĄCY MÓGŁ ZBADAĆ ZGODNOŚĆ Z POWYŻSZYMI WARUNKAMI UDZIAŁU W POSTĘPOWANIU OKREŚLONYMI W PKT. 7.2. SIWZ

7.3. Spełnianie warunków poprzez poleganie na potencjale „innych podmiotów”.

7.3.1. Wykonawcy, w celu potwierdzenia spełniania warunków udziału w postępowaniu, mogą polegać na zdolnościach technicznych lub zawodowych innych podmiotów, niezależnie od charakteru prawnego łączących go z nim stosunków prawnych.

7.3.2. Jeżeli zdolności techniczne lub zawodowe podmiotu, na potencjale którego Wykonawca polega, nie potwierdzają spełnienia przez Wykonawcę warunków udziału w postępowaniu, lub

zachodzą wobec tych podmiotów podstawy wykluczenia, o których mowa w art. 24 ust. 1 pkt 13-22 i ust. 5 pkt 1 ustawy Pzp, Zamawiający żąda, aby Wykonawca w terminie określonym przez Zamawiającego:

1) zastąpił ten podmiot innym podmiotem lub podmiotami lub

2) zobowiązał się do osobistego wykonania odpowiedniej części zamówienia, jeżeli wykaże zdolności techniczne lub zawodowe.

7.4. Spełnianie warunków udziału przez konsorcjum.

W przypadku Wykonawców wspólnie ubiegających się o udzielenie zamówienia (konsorcjum), warunki określone w pkt 7.2 SIWZ mogą zostać spełnione przez jednego Wykonawcę lub łącznie wszystkich Wykonawców wspólnie ubiegających się o udzielenie zamówienia.

7.5. Zamawiający oceni spełnianie warunków udziału w postępowaniu na podstawie informacji zawartych w oświadczeniach i dokumentach.

7.6. Ocena spełniania warunków wymaganych od Wykonawców nastąpi wg formuły: „spełnia – nie spełnia”.

8. PODSTAWY WYKLUCZENIA

8.1. O udzielenie zamówienia mogą ubiegać się Wykonawcy, którzy nie podlegają wykluczeniu z postępowania na podstawie art. 24 ust. 1 pkt 12-23 tj. z postępowania wyklucza się:

8.1.1. wykonawcę, który nie wykazał spełniania warunków udziału w postępowaniu lub nie został zaproszony do negocjacji lub złożenia ofert wstępnych albo ofert, lub nie wykazał braku podstaw wykluczenia;

8.1.2. wykonawcę będącego osobą fizyczną, którą prawomocnie skazano za przestępstwo:

a) o którym mowa w art. 165a, art. 181–188, art. 189a, art. 218–221, art. 228–230a, art. 250a, art. 258 lub art. 270–309 ustawy z dnia 6 czerwca 1997 r. – Kodeks karny (Dz. U. poz. 553, z późn. zm.5)) lub art. 46 lub art. 48 ustawy z dnia 25 czerwca 2010 r. o sporcie (Dz. U. z 2016 r. poz. 176),

b) o charakterze terrorystycznym, o którym mowa w art. 115 § 20 ustawy z dnia 6 czerwca 1997 r. – Kodeks karny,

c) skarbowe,

d) o którym mowa w art. 9 lub art. 10 ustawy z dnia 15 czerwca 2012 r. o skutkach powierzania wykonywania pracy cudzoziemcom przebywającym wbrew przepisom na terytorium Rzeczypospolitej Polskiej (Dz. U. poz. 769);

8.1.3. wykonawcę, jeżeli urzędującego członka jego organu zarządzającego lub nadzorczego, wspólnika spółki w spółce jawnej lub partnerskiej albo komplementariusza w spółce komandytowej lub komandytowo-akcyjnej lub prokurenta prawomocnie skazano za przestępstwo, o którym mowa w pkt 8.1.2 SIWZ;

8.1.4. wykonawcę, wobec którego wydano prawomocny wyrok sądu lub ostateczną decyzję administracyjną o zaleganiu z uiszczeniem podatków, opłat lub składek na ubezpieczenia społeczne lub zdrowotne, chyba że wykonawca dokonał płatności należnych podatków, opłat lub składek na ubezpieczenia społeczne lub zdrowotne wraz z odsetkami lub grzywnami lub zawarł wiążące porozumienie w sprawie spłaty tych należności;

8.1.5. wykonawcę, który w wyniku zamierzonego działania lub rażącego niedbalstwa wprowadził zamawiającego w błąd przy przedstawieniu informacji, że nie podlega wykluczeniu, spełnia warunki udziału w postępowaniu lub obiektywne i niedyskryminacyjne kryteria, zwane dalej

„kryteriami selekcji”, lub który zataił te informacje lub nie jest w stanie przedstawić wymaganych dokumentów;

8.1.6. wykonawcę, który w wyniku lekkomyślności lub niedbalstwa przedstawił informacje wprowadzające w błąd zamawiającego, mogące mieć istotny wpływ na decyzje podejmowane przez zamawiającego w postępowaniu o udzielenie zamówienia;

8.1.7. wykonawcę, który bezprawnie wpływał lub próbował wpłynąć na czynności zamawiającego lub pozyskać informacje poufne, mogące dać mu przewagę w postępowaniu o udzielenie zamówienia;

8.1.8. wykonawcę, który brał udział w przygotowaniu postępowania o udzielenie zamówienia lub którego pracownik, a także osoba wykonująca pracę na podstawie umowy zlecenia, o dzieło, agencyjnej lub innej umowy o świadczenie usług, brał udział w przygotowaniu takiego postępowania, chyba że spowodowane tym zakłócenie konkurencji może być wyeliminowane w inny sposób niż przez wykluczenie wykonawcy z udziału w postępowaniu;

8.1.9. wykonawcę, który z innymi wykonawcami zawarł porozumienie mające na celu zakłócenie konkurencji między wykonawcami w postępowaniu o udzielenie zamówienia, co zamawiający jest w stanie wykazać za pomocą stosownych środków dowodowych;

8.1.10.wykonawcę będącego podmiotem zbiorowym, wobec którego sąd orzekł zakaz ubiegania się o zamówienia publiczne na podstawie ustawy z dnia 28 października 2002 r. o odpowiedzialności podmiotów zbiorowych za czyny zabronione pod groźbą kary (Dz. U. z 2015 r. poz. 1212, 1844 i 1855 oraz z 2016 r. poz. 437 i 544);

8.1.11.wykonawcę, wobec którego orzeczono tytułem środka zapobiegawczego zakaz ubiegania się o zamówienia publiczne;

8.1.12.wykonawców, którzy należąc do tej samej grupy kapitałowej, w rozumieniu ustawy z dnia 16 lutego 2007 r. o ochronie konkurencji i konsumentów (Dz. U. z 2015 r. poz. 184, 1618 i 1634), złożyli odrębne oferty, oferty częściowe lub wnioski o dopuszczenie do udziału w postępowaniu, chyba że wykażą, że istniejące między nimi powiązania nie prowadzą do zakłócenia konkurencji w postępowaniu o udzielenie zamówienia.

8.2. oraz którzy nie podlegają wykluczeniu z postępowania na podstawie art. 24 ust. 5 pkt 1) ustawy Pzp, tj.

8.2.1. w stosunku do których otwarto likwidację, w zatwierdzonym przez sąd układzie w postępowaniu restrukturyzacyjnym jest przewidziane zaspokojenie wierzycieli przez likwidację jego majątku lub sąd zarządził likwidację jego majątku w trybie art. 332 ust. 1 ustawy z dnia 15 maja 2015 r. – Prawo restrukturyzacyjne (Dz. U. z 2015 r. poz. 978, 1259, 1513, 1830 i 1844 oraz z 2016 r. poz. 615) lub którego upadłość ogłoszono, z wyjątkiem wykonawcy, który po ogłoszeniu upadłości zawarł układ zatwierdzony prawomocnym postanowieniem sądu, jeżeli układ nie przewiduje zaspokojenia wierzycieli przez likwidację majątku upadłego, chyba że sąd zarządził likwidację jego majątku w trybie art. 366 ust. 1 ustawy z dnia 28 lutego 2003 r. – Prawo upadłościowe (Dz. U. z 2015 r. poz. 233, 978, 1166, 1259 i 1844 oraz z 2016 r. poz. 615);

8.3. Zamawiający może wykluczyć Wykonawcę na każdym etapie postępowania o udzielenie zamówienia.

8.4. Wykonawca, który podlega wykluczeniu na podstawie art. 24 ust. 1 pkt 13 i 14 oraz 16–20 lub ust. 5 pkt 1 ustawy Pzp, może przedstawić dowody na to, że podjęte przez niego środki są wystarczające do wykazania jego rzetelności, w szczególności udowodnić naprawienie szkody wyrządzonej przestępstwem lub przestępstwem skarbowym, zadośćuczynienie pieniężne za doznaną krzywdę lub naprawienie szkody, wyczerpujące wyjaśnienie stanu faktycznego oraz współpracę z organami ścigania oraz podjęcie konkretnych środków technicznych, organizacyjnych i kadrowych, które są odpowiednie dla zapobiegania dalszym przestępstwom lub przestępstwom skarbowym lub nieprawidłowemu postępowaniu Wykonawcy. Wykonawca nie podlega wykluczeniu, jeżeli Zamawiający, uwzględniając wagę i szczególne okoliczności czynu Wykonawcy, uzna za wystarczające dowody przedstawione na ww. podstawie.

8.5. W przypadkach, o których mowa w art. 24 ust. 1 pkt 19 ustawy Pzp, przed wykluczeniem Wykonawcy, Zamawiający zapewnia temu wykonawcy możliwość udowodnienia, że jego udział w przygotowaniu postępowania o udzielenie zamówienia nie zakłóci konkurencji.

8.6. W celu potwierdzenia spełniania warunków udziału w postępowaniu przez Wykonawców składających wspólną ofertę przesłanka nie podlegania wykluczeniu z postępowania, określona w pkt. 8.1 i 8.2 SIWZ oceniana będzie odrębnie dla każdego z Wykonawców wspólnie ubiegających się o udzielenie zamówienia.

9. WYKAZ OŚWIADCZEŃ W CELU WSTĘPNEGO POTWIERDZENIA, ŻE WYKONAWCA NIE PODLEGA WYKLUCZENIU ORAZ SPEŁNIA WARUNKI UDZIAŁU W POSTĘPOWANIU

9.1. Wykonawca zobowiązany jest dołączyć do oferty aktualne na dzień składania ofert oświadczenie złożone na formularzu jednolitego europejskiego dokumentu zamówienia (JEDZ), sporządzonego zgodnie ze wzorem standardowego formularza określonego w rozporządzeniu wykonawczym Komisji Europejskiej wydanym na podstawie art. 59 ust. 2 dyrektywy 2014/24/UE zawierające w szczególności informacje:

9.1.1. o tym, że Wykonawca spełnia warunki udziału w postępowaniu określone przez Zamawiającego w pkt 7 SIWZ,

9.1.2. o tym, że Wykonawca nie podlega wykluczeniu z powodów wskazanych w art. 24 ust. 1 pkt 13- 22 i ust. 5 pkt 1 ustawy Pzp,

9.1.3. o innych podmiotach, na zasoby których Wykonawca powołuje się w celu wykazania spełnienia warunków udziału w postępowaniu, wraz z informacją dotyczącą podstaw wykluczenia innego podmiotu, o których mowa w art. 24 ust. 1 pkt 13–22 i ust. 5 pkt 1 ustawy Pzp – jeżeli dotyczy.

9.1.3.1. Wykonawca, który polega na zdolnościach innych podmiotów, zobowiązany jest udowodnić Zamawiającemu, że realizując zamówienie, będzie miał rzeczywisty dostęp do zasobów tych podmiotów w zakresie niezbędnym do należytego wykonania zamówienia, w szczególności przedstawiając zobowiązanie tych podmiotów do oddania mu do dyspozycji niezbędnych zasobów na potrzeby realizacji zamówienia. Z treści załączonych dokumentów powinien wynikać:

9.1.3.1.1. zakres dostępnych Wykonawcy zasobów innego podmiotu,

9.1.3.1.2. sposób wykorzystania zasobów innego podmiotu, przez Wykonawcę, przy wykonywaniu zamówienia,

9.1.3.1.3. zakres i okres udziału innego podmiotu przy wykonywaniu zamówienia,

9.1.3.1.4. czy inne podmioty, na zdolności których Wykonawca polega w odniesieniu do warunków udziału w postępowaniu dotyczących wykształcenia, kwalifikacji zawodowych lub doświadczenia, zrealizują usługi, których wskazane zdolności dotyczą.

9.1.4. o podwykonawcach, na zasobach których wykonawca nie polega, jeśli jest już wiadome Wykonawcy, jakim podwykonawcom zamierza powierzyć wykonanie części zamówienia.

9.2. Szczegółowe oświadczenie złożone na formularzu jednolitego europejskiego dokumentu zamówienia (JEDZ) opracowane jest wg druku dołączonego do SIWZ – załącznik nr 4 do SIWZ

9.3. W przypadku wspólnego ubiegania się o zamówienie przez Wykonawców (konsorcjum), oświadczenie na formularzu JEDZ składa każdy z Wykonawców wspólnie ubiegających się o zamówienie. JEDZ potwierdza w szczególności brak podstaw wykluczenia i spełnianie warunków udziału w postępowaniu w zakresie, w którym każdy z Wykonawców wykazuje spełnianie warunków udziału w postępowaniu oraz brak podstaw wykluczenia.

9.4. Wykonawca, który powołuje się na zasoby innych podmiotów, składa także JEDZ dotyczący tych podmiotów, w celu wykazania braku istnienia wobec nich podstaw wykluczenia oraz spełniania warunków udziału w postępowaniu, w zakresie, w jakim powołuje się na ich zasoby.

9.5. Zamawiający nie wymaga przedstawienia formularza JEDZ przez podwykonawców, na którego zasobach Wykonawca nie polega przy wykazywaniu spełnienia warunków udziału w postępowaniu.

9.6. Jednolity Europejski Dokument Zamówienia składany jest w formie pisemnej – z oryginalnym podpisem podmiotu składającego.

9.7. Przy wypełnianiu formularza JEDZ Wykonawca może skorzystać z instrukcji jego wypełniania zamieszczonej przez Urząd Zamówień Publicznych dostępnej na stronie:

xxxxx://xxx.xxx.xxx.xx/ data/assets/pdf_file/0015/32415/Jednolity-Europejski-Dokument- Zamowienia-instrukcja.pdf

9.A. INNE DOKUMENTY JAKIE WYKONAWCA MUSI ZŁOŻYĆ W OFERCIE W CELU OCENY ZGODONOŚCI PRZEDMIOTU OFERTY ZE SIWZ – DOKUMNET TEN STANOWI TREŚĆ OFERTY

W celu dokonania oceny zgodności oferowanego przedmiotu zamówienia z treścią SIWZ, Wykonawca musi dołączyć do oferty próbkę produktu – zgodnie z wymaganiami określonymi w załączniku nr 1.1. do SIWZ „Opis próbki produktu”. Próbka produktu nie podlega uzupełnieniu.

10. OŚWIADCZENIE O GRUPIE KAPITAŁOWEJ:

10.1. Wykonawca, w terminie 3 dni od dnia zamieszczenia na stronie internetowej informacji o Wykonawcach, którzy złożyli oferty w postępowaniu, zobowiązany jest przekazać Zamawiającemu oświadczenie o przynależności lub braku przynależności do tej samej grupy kapitałowej co inni Wykonawcy, którzy złożyli oferty w postępowaniu. W stosownej sytuacji, wraz ze złożeniem oświadczenia, Wykonawca może przedstawić dowody, że powiązania z innym Wykonawcą,

który złożył ofertę w tym samym postępowaniu, nie prowadzą do zakłócenia konkurencji w postępowaniu o udzielenie zamówienia.

UWAGA: W przypadku Wykonawców wspólnie ubiegających się o udzielenie zamówienia - dokument składa każdy z Wykonawców występujących wspólnie.

10.2. Wzór oświadczenia stanowi Załącznik nr 5 do SIWZ.

11. WYKAZ OŚWIADCZEŃ LUB DOKUMENTÓW W CELU POTWIERDZENIA, ŻE WYKONAWCA NIE PODLEGA WYKLUCZENIU ORAZ SPEŁNIA WARUNKI UDZIAŁU W POSTĘPOWANIU

11.1. Zamawiający dokona w pierwszej kolejności oceny ofert, a następnie zbada, czy Wykonawca, którego oferta została oceniona jako najkorzystniejsza, nie podlega wykluczeniu oraz spełnia warunki udziału w postępowaniu.

11.2. Niemniej jednak, jeżeli będzie to niezbędne do zapewnienia odpowiedniego przebiegu postępowania o udzielenie zamówienia, Zamawiający może na każdym etapie postępowania wezwać wykonawców do złożenia wszystkich lub niektórych oświadczeń lub dokumentów potwierdzających, że nie podlegają wykluczeniu, spełniają warunki udziału w postępowaniu, a jeżeli zachodzą uzasadnione podstawy do uznania, że złożone uprzednio oświadczenia lub dokumenty nie są już aktualne, do złożenia aktualnych oświadczeń lub dokumentów.

11.3. Zamawiający wezwie Wykonawcę, którego oferta została oceniona jako najkorzystniejsza, do złożenia w wyznaczonym, nie krótszym niż 10 dni terminie aktualnych na dzień złożenia następujących oświadczeń i dokumentów potwierdzających okoliczności, o których mowa w art. 25 ust. 1 ustawy Pzp;

11.3.1 Dowodów, czy usługi wykonane w okresie ostatnich trzech lat przed upływem terminu składania ofert zostały wykonane należycie (w przypadku świadczeń ciągłych lub okresowych - są wykonywane należycie, przy czym dowody potwierdzające ich należyte wykonywanie powinny być wydane nie wcześniej niż 3 miesiące przed upływem terminu składania ofert);

Dowodami, o których wyżej mowa, są:

• referencje bądź inne dokumenty wystawione przez podmiot na rzecz którego usługi były wykonywane, z tym że w odniesieniu do nadal wykonywanych usług okresowych lub ciągłych poświadczenie powinno być wydane nie wcześniej niż na 3 miesiące przed upływem terminu składania ofert;

• oświadczenie Wykonawcy – jeżeli z uzasadnionych przyczyn o obiektywnym charakterze Wykonawca nie jest w stanie uzyskać referencji bądź innych dokumentów, o których wyżej mowa

11.3.2. Informacji z Krajowego Rejestru Karnego w zakresie określonym w art. 24 ust. 1 pkt 13, 14 i 21 ustawy Pzp, wystawionej nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert;

11.3.3. Odpisu z właściwego rejestru lub z centralnej ewidencji i informacji o działalności gospodarczej, jeżeli odrębne przepisy wymagają wpisu do rejestru lub ewidencji, w celu wykazania braku podstaw do wykluczenia w oparciu o art. 24 ust. 5 pkt 1 ustawy Pzp. W tym zakresie zastosowanie ma art. 26 ust. 6 ustawy Pzp;

11.4 Wymogi szczególne w zakresie dokumentów dotyczących innego podmiotu żądane od wykonawcy którego oferta została oceniona jako najkorzystniejsza

11.4.1. W przypadku, gdy Wykonawca, polega na zasobach innych podmiotów na zasadach określonych w art. 22a ustawy Pzp, Zamawiający żąda przedstawienia dokumentów wskazanych w pkt 11.3.2 –

11.3.3. dotyczących tych podmiotów tj.:

11.4.1.1. Informacji z Krajowego Rejestru Karnego w zakresie określonym w art. 24 ust. 1 pkt 13, 14 i 21 ustawy Pzp, wystawionej nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert

11.4.1.2. Odpisu z właściwego rejestru lub z centralnej ewidencji i informacji o działalności gospodarczej, jeżeli odrębne przepisy wymagają wpisu do rejestru lub ewidencji, w celu wykazania braku podstaw do wykluczenia w oparciu o art. 24 ust. 5 pkt 1 ustawy Pzp. W tym zakresie zastosowanie ma art. 26 ust. 6 ustawy Pzp;

11.4.2 Wymogi szczególne w zakresie dokumentów dotyczących Wykonawców wspólnie ubiegających się o zamówienie: W przypadku wspólnego ubiegania się o zamówienie przez Wykonawców (konsorcjum), dokumenty wymienione w pkt 11.3.2-11.3.3 składa każdy z Wykonawców wspólnie ubiegających się o zamówienie. Dokumenty wskazane w pkt 11.3.1 składa ten Wykonawca-członek konsorcjum, który wykazuje spełnienie odpowiedniego warunku udziału w postępowaniu.

11.5. Nie wykazanie spełniania chociażby jednego warunku, skutkować będzie wykluczeniem Wykonawcy z postępowania.

11.6. Dokumenty Wykonawców spoza Rzeczypospolitej Polskiej

11.6.1. Wykonawca mający siedzibę lub miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej zamiast dokumentu, o którym mowa w:

11.6.1.1. pkt 11.3.2 – składa informację z odpowiedniego rejestru albo, w przypadku braku takiego rejestru, inny równoważny dokument wydany przez właściwy organ sądowy lub administracyjny kraju, w którym Wykonawca ma siedzibę lub miejsce zamieszkania lub miejsce zamieszkania ma osoba, której dotyczy informacja albo dokument, w zakresie określonym w art. 24 ust. 1 pkt 13, 14 i 21 ustawy Pzp,

11.6.1.2. pkt 11.3.3 – składa dokument lub dokumenty wystawione w kraju, w którym wykonawca ma siedzibę lub miejsce zamieszkania, potwierdzające odpowiednio, że nie otwarto jego likwidacji ani nie ogłoszono upadłości.

11.6.2. Dokumenty, o których mowa w pkt 11.6.1, powinny być wystawione nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert.

11.6.3. Jeżeli w kraju, w którym Wykonawca ma siedzibę lub miejsce zamieszkania lub miejsce zamieszkania mają osoby, których dotyczą dokumenty, nie wydaje się dokumentów o których mowa w pkt 11.6.1., zastępuje się je dokumentem zawierającym odpowiednio oświadczenie Wykonawcy, ze wskazaniem osoby albo osób uprawnionych do jego reprezentacji, lub oświadczenie osoby, której dokument miał dotyczyć, złożone przed notariuszem lub organem sądowym, administracyjnym albo organem samorządu zawodowego lub gospodarczego właściwym ze względu na siedzibę lub miejsce zamieszkania wykonawcy lub miejsce zamieszkania tej osoby. Przepisy pkt. 11.6.2. stosuje się.

11.6.4. Wykonawca mający siedzibę na terytorium Rzeczypospolitej Polskiej, w odniesieniu do osób, które mają miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej, składają dokument wydany przez właściwy organ sądowy lub administracyjny państwa, w którym osoba ma miejsce zamieszkania w zakresie określonym w art. 24 ust. 1 pkt 14 i 21 ustawy Pzp. W przypadku, gdy w państwie, w którym mają miejsce zamieszkania wskazane w zdaniu pierwszym osoby, nie wydaje się takich zaświadczeń – zastępuje się je dokumentem zawierającym oświadczenie tych osób złożonym przed notariuszem lub przed właściwym ze względu na miejsce zamieszkania tych osób organem sądowym, administracyjnym albo organem samorządu zawodowego lub gospodarczego. Przepisy pkt. 11.6.2 stosuje się.

11.7. Charakter/postać dokumentów lub oświadczeń:

11.7.1. Oświadczenia, składane przez Wykonawcę i inne podmioty, na zdolnościach których polega Wykonawca, składane są w postaci oryginału. Za oryginał uważa się oświadczenie złożone w formie pisemnej podpisane własnoręcznym podpisem.

11.7.2. Dokumenty, inne niż oświadczenia, składane są w oryginale lub kopii poświadczonej za zgodność z oryginałem.

11.7.3. Poświadczenia za zgodność z oryginałem dokonywane są w formie pisemnej przez Wykonawcę albo podmiot, na którego zdolnościach polega Wykonawca albo Wykonawcę wspólnie ubiegającego się o udzielenie zamówienia publicznego – odpowiednio w zakresie dokumentów, które każdego z nich dotyczą.

11.7.4. Wszelkie poprawki lub zmiany (skreślenie, itp.) w dokumentach lub oświadczeniach muszą być podpisane własnoręcznie przez uprawnioną osobę, w miejscu dokonanej poprawki lub zmiany. Naniesione zmiany muszą być czytelne.

11.8. Reprezentacja i pełnomocnictwo

11.8.1. W przypadku, gdy Wykonawcę reprezentuje pełnomocnik, do oferty należy dołączyć pełnomocnictwo podpisane przez osobę/osoby uprawnione do reprezentowania Wykonawcy. Treść pełnomocnictwa musi jednoznacznie wskazywać czynności, do wykonywania których pełnomocnik jest upoważniony (zakres umocowania). Pełnomocnictwo należy złożyć w oryginale lub kopii poświadczonej notarialnie za zgodność z oryginałem.

11.8.2. W przypadku Wykonawców składających wspólnie ofertę, do oferty należy dołączyć pełnomocnictwo do reprezentowania wszystkich Wykonawców wspólnie ubiegających się o udzielenie zamówienia (wystawione zgodnie z art. 23 ust. 2 ustawy Pzp). Treść pełnomocnictwa musi jednoznacznie wskazywać czynności, do wykonywania których pełnomocnik jest upoważniony (zakres umocowania). Pełnomocnictwo należy złożyć w oryginale lub kopii poświadczonej notarialnie za zgodność z oryginałem.

11.8.3. Oferta musi być podpisana przez pełnomocnika/osobę umocowaną do reprezentowania Wykonawcy/Wykonawców.

11.9. Wyjątki od obowiązku złożenia dokumentów:

Wykonawca nie jest obowiązany do złożenia odpowiednich oświadczeń lub dokumentów, jeżeli:

11.9.1. Zamawiający może je uzyskać za pomocą bezpłatnych i ogólnodostępnych baz danych, w szczególności rejestrów publicznych w rozumieniu ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (ze wskazaniem adresu internetowego, wydającego urzędu lub organu, z dokładnymi danymi referencyjnymi dokumentacji – w formularzu JEDZ),

11.9.2. Zamawiający posiada aktualne oświadczenia lub dokumenty dotyczące tego Wykonawcy (ze wskazaniem nazwy i numeru postępowania o udzielenie zamówienia publicznego – w formularzu JEDZ).

12. SPOSÓB POROZUMIEWANIA SIĘ W POSTĘPOWANIU ORAZ OSOBY UPRAWNIONE DO POROZUMIEWANIA SIĘ Z WYKONAWCAMI

12.1 Komunikacja między Zamawiającym a Wykonawcami odbywa się za pośrednictwem operatora pocztowego w rozumieniu ustawy z dnia 23 listopada 2012 r. – Prawo pocztowe (Dz. U. z 2012 r. poz. 1529 oraz z 2015 r. poz. 1830), osobiście, za pośrednictwem posłańca, faksu lub przy użyciu środków komunikacji elektronicznej w rozumieniu ustawy z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz. U. z 2013 r. poz. 1422, z 2015 r. poz. 1844 oraz z 2016 r. poz. 147 i 615). Dokonany przez Wykonawcę wybór sposobu złożenia informacji/oświadczeń/dokumentów powinien uwzględniać obowiązek zachowania przez Wykonawcę wymagań w zakresie pisemnej formy oferty oraz obowiązku zachowania charakteru/postaci składanych dokumentów i oświadczeń określonych w pkt 9, 9A, 10 i 11 SIWZ.

12.2 Wykonawca może zwrócić się do Zamawiającego o wyjaśnienie treści SIWZ. Zamawiający ma obowiązek udzielić odpowiedzi na pytania Wykonawcy, pod warunkiem, że wniosek o wyjaśnienie wpłynął do Zamawiającego nie później niż do końca dnia, w którym upływa połowa wyznaczonego terminu składania ofert.

12.3 Jeżeli wniosek o wyjaśnienie treści SIWZ wpłynął w terminie późniejszym niż do końca dnia, w którym upływa połowa wyznaczonego terminu składania ofert, Zamawiający może udzielić wyjaśnień albo pozostawić wniosek bez rozpoznania. Przedłużenie terminu składania ofert nie wpływa na wydłużenie biegu terminu składania wniosków o wyjaśnienie SIWZ, na które Zamawiający ma obowiązek udzielenia odpowiedzi.

12.4 Oświadczenie, wniosek, zawiadomienie, oraz informacje, w tym pytania do SIWZ i odpowiedzi uznaje się za złożone w chwili, w której wpłynął on do siedziby adresata faksem, elektronicznie lub został doręczony w inny sposób do siedziby Zamawiającego lub Wykonawcy. Przesyłając oświadczenie, wniosek, zawiadomienie oraz informacje, w tym pytania do SIWZ i odpowiedzi, za pomocą faksu lub elektronicznie, każda strona ma obowiązek potwierdzić jej wpływ (lub poinformować o braku wpływu) na żądanie drugiej strony.

12.5 Osobą uprawnioną do kontaktu z Wykonawcami jest: Xxxxxxxx Xxxxxx (Dział Zamówień Publicznych) tel. + 00 00 000 00 00

fax x00 00 000 00 00

e- mail: xxxxxxxx.xxxxxx@xxx.xxx.xx

12.6 Wszelką korespondencję dotyczącą prowadzonego postępowania należy kierować na adres Zamawiającego:

Państwowy Instytut Geologiczny – Państwowy Instytut Badawczy (PIG-PIB) xx. Xxxxxxxxxx 0, 00-000 Xxxxxxxx

e-mail: xxxxxxxx.xxxxxx@xxx.xxx.xx

13 WYMAGANIA DOTYCZĄCE WADIUM

13.1 Zamawiający wymaga wniesienia wadium przed upływem terminu składania ofert określonego w niniejszej SIWZ w wysokości 50 000,00 PLN (pięćdziesiąt tysięcy 00/100 PLN)

13.2 Wadium może być wnoszone w jednej lub w kilku następujących formach:

13.2.1 pieniądzu;

13.2.2 poręczeniach bankowych lub poręczeniach spółdzielczej kasy oszczędnościowo-kredytowej, z tym że poręczenie kasy jest zawsze poręczeniem pieniężnym;

13.2.3 gwarancjach bankowych;

13.2.4 gwarancjach ubezpieczeniowych;

13.2.5 poręczeniach udzielanych przez podmioty, o których mowa w art. 6b ust. 5 pkt 2 ustawy z dnia 9 listopada 2000 r. o utworzeniu Polskiej Agencji Rozwoju Przedsiębiorczości (Dz. U. z 2016 r. poz. 359).

13.3 Wadium wnoszone w pieniądzu należy wpłacić na rachunek bankowy prowadzony w Getin Noble Bank SA nr konta: 52 1560 0013 2366 2335 1965 0001 w tytule przelewu: „wadium w postęp. Sygn. EZ-240-66/2016”.

13.4 Skuteczne wniesienie wadium w pieniądzu następuje z chwilą wpływu środków pieniężnych na rachunek bankowy (uznanie kwoty na rachunku Zamawiającego), o którym mowa w pkt 13.3 przed upływem terminu składania ofert.

13.5 Wadium wnoszone w formach określonych w pkt 13.2 ppkt 13.2.2-5, musi zawierać zobowiązanie gwaranta lub poręczyciela z tytułu wystąpienia zdarzeń, o których mowa w art. 46 ust. 4a i 5 ustawy Pzp, przy czym:

13.5.1 w przypadku, gdy Wykonawcy wspólnie ubiegają się o udzielenie zamówienia, dokumenty te muszą obejmować swym zakresem wszelkie roszczenia Zamawiającego z tytułu związanych z postępowaniem o udzielenie zamówienia działań lub zaniechań,

13.5.2 dokumenty te będą zawierały klauzule zapłaty sumy wadialnej na rzecz zamawiającego nieodwołanie, bezwarunkowo i na pierwsze żądanie,

13.5.3 dokumenty te zostaną złożone w oryginale.

13.6 Oryginały dokumentów, o których mowa w pkt 13.2 ppkt 13.2.2-5, należy złożyć wraz z ofertą, w osobnej kopercie.

13.7 Zamawiający informuje, iż jest obowiązany zatrzymać wadium wraz z odsetkami w przypadku ziszczenia się przesłanek, o których mowa w art. 46 ust. 4a ustawy Pzp.

14 TERMIN ZWIĄZANIA OFERTĄ

Okres związania Wykonawcy złożoną ofertą wynosi 60 dni od upływu terminu składania ofert, określonego w pkt 16 SIWZ.

15 OPIS SPOSOBU PRZYGOTOWANIA OFERT

15.1 Wykonawca przedstawia ofertę o treści odpowiadającej treści SIWZ. Propozycje rozwiązań x.xx. alternatywnych lub wariantowych nie będą brane pod uwagę, a oferta zostanie odrzucona na podstawie art. 89 ust. 1 pkt 2 ustawy Pzp.

15.2 Oferta musi zawierać co najmniej:

15.2.1 wypełniony formularz „Oferta”, który stanowi załącznik nr 3 do SIWZ;

15.2.2 wypełniony formularz cenowy, który stanowi załączniki nr 3.1do SIWZ;

15.2.3 próbkę produktu;

15.2.4 wypełniony Formularz JEDZ. Po wypełnieniu formularza JEDZ w wersji edytowalnej, stanowiącego załącznik nr 4 do SIWZ, należy JEDZ wydrukować i załączyć, odpowiednio podpisany, do oferty. Dokumenty/wykazy potwierdzające informacje zawarte w JEDZ składne są na późniejszym etapie, zgodnie z warunkami opisanymi w pkt 11.3 SIWZ.

15.2.5 dowód wniesienia wadium;

15.2.6 dokument pełnomocnictwa (jeśli dotyczy);

15.2.7 zobowiązanie podmiotu trzeciego do udostępniania zasobów, o którym mowa w pkt. 9.1.3.1 SIWZ (jeśli dotyczy).

15.3 Wykonawcy mogą wspólnie ubiegać się o udzielenie zamówienia zgodnie z art. 23 ustawy Pzp.

15.4 Brak informacji, o której mowa w pkt 9.1.4. SIWZ, będzie uznany za stwierdzenie samodzielnego wykonania zamówienia przez Wykonawcę, który złożył ofertę.

15.5 Wykonawcy ponoszą wszelkie koszty związane z przygotowaniem i złożeniem oferty oraz uczestnictwem w postępowaniu o udzielenie zamówienia publicznego.

15.6 Ofertę stanowi wypełniony druk „OFERTA”, który stanowi Załącznik nr 3 do SIWZ, z załączonymi dokumentami i oświadczeniami, wymaganymi niniejszą SIWZ.

15.7 Oferta wraz z załącznikami musi być sformułowana w języku polskim, w sposób czytelny, logiczny, pisemnie przy użyciu nośnika pisma nie ulegającego usunięciu bez pozostawienia śladów.

15.8 Zamawiający zaleca sporządzenie oferty na komputerze lub wypełnienie druków czytelnym pismem ręcznym.

15.9 Dokumenty sporządzone w języku obcym Wykonawca musi złożyć wraz z tłumaczeniem na język polski. Podczas oceny ofert Xxxxxxxxxxx będzie się opierał na tekście przetłumaczonym na język polski.

15.10 W przypadku uzyskania dokumentów, o których mowa w pkt. 11.9.1 SIWZ w języku obcym, Zamawiający żąda od Wykonawcy przedstawienia tłumaczenia na język polski wskazanych przez Wykonawcę i pobranych samodzielnie przez Zamawiającego dokumentów.

15.11 Wykonawca może przepisać druki Zamawiającego, jednakże treść zawarta we wzorach Zamawiającego nie może ulec zmianie.

15.12 Zalecane jest, aby oferta była złożona na kolejno ponumerowanych stronach. Numeracja stron powinna rozpoczynać się od numeru 1, umieszczonego na pierwszej stronie oferty.

15.13 Oferta po jej otwarciu, w terminie wyznaczonym na termin otwarcia ofert, jest jawna.

15.14 Zamawiający wymaga aby oferta, wraz ze wszystkimi załącznikami, była podpisana przez osobę upoważnioną do reprezentowania Wykonawcy.

15.15 Zamawiający zaleca złożenie oferty w taki sposób, aby nie uległa zdekompletowaniu.

15.16 Oferty składane są w jednym egzemplarzu, w nieprzejrzystej i zamkniętej kopercie lub opakowaniu.

15.17 Koperta powinna być zaadresowana na adres:

Państwowy Instytut Geologiczny – Państwowy Instytut Badawczy (PIG-PIB) xx. Xxxxxxxxxx 0, 00-000 Xxxxxxxx

oraz opisana następująco:

Oferta na „Opracowanie i uruchomienie e-Usług z obszarów PSG i PSH w Państwowym Instytucie Geologicznym Państwowym Instytucie Badawczym”

(Sygn. Postępowania: EZ-240-66/2016)

Nie otwierać przed godziną 11:15 dnia 21.11.2016 roku.

15.18 Konsekwencje złożenia oferty niezgodnie z ww. opisem ponosi Wykonawca.

15.19 W przypadku przekazania oferty do Zamawiającego za pośrednictwem operatora pocztowego, osobiście lub posłańca, Wykonawca ponosi odpowiedzialność za datę i godzinę jej wpływu do Kancelarii PIG-PIB.

15.20 Wykonawca składa tylko jedną ofertę, w której może być zaoferowana tylko jedna cena. Jeżeli Wykonawca złoży więcej niż jedną ofertę samodzielnie lub wspólnie z innymi Wykonawcami, wszystkie złożone przez niego oferty zostaną odrzucone.

15.21 Wykonawca może wprowadzić zmiany, poprawki, modyfikacje i uzupełnienia do złożonej oferty pod warunkiem, że Zamawiający otrzyma pisemne powiadomienie o wprowadzeniu zmian, poprawek itp. przed upływem terminu składania ofert. Powiadomienie o wprowadzeniu zmian musi być złożone według takich samych wymagań jak dla składania oferty z dopiskiem ZMIANA.

15.22 Koperty oznaczone dopiskiem ZMIANA zostaną otwarte przy otwieraniu oferty Wykonawcy, który wprowadził zmiany i po stwierdzeniu poprawności procedury dokonywania zmian zostaną dołączone do oferty.

15.23 Wykonawca ma prawo przed upływem terminu składania ofert wycofać się z postępowania poprzez złożenie pisemnego powiadomienia, z adnotacją na kopercie WYCOFANIE.

15.24 Koperty oznaczone napisem WYCOFANIE będą otwierane w pierwszej kolejności i po stwierdzeniu poprawności postępowania Wykonawcy jego oferta nie będzie otwierana.

15.25 Informacje zawarte w ofercie, stanowiące tajemnicę przedsiębiorstwa w rozumieniu przepisów ustawy z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji (Dz. U. z 2003 r. Nr 153 poz. 1503 z xxxx.xx.), co do których Wykonawca:

15.25.1 zastrzegł, nie później niż w terminie składania ofert, że nie mogą być udostępnione, muszą być oznaczone klauzulą: „NIE UDOSTĘPNIAĆ - INFORMACJE STANOWIĄ TAJEMNICĘ PRZEDSIĘBIORSTWA W ROZUMIENIU ART. 11 UST. 4 USTAWY O ZWALCZANIU NIEUCZCIWEJ KONKURENCJI”. Wykonawca zobowiązany jest złożyć wraz z ofertą uzasadnienie zwierające w szczególności: określenie charakteru jaki mają zastrzeżone informacje, wskazanie działań jakie zostały podjęte przez Wykonawcę w celu zachowania poufności informacji zawartych w dokumentach oraz wskazanie czy informacje stanowiące tajemnicę przedsiębiorstwa zostały wcześniej ujawnione do wiadomości publicznej.

15.25.2 Stosownie do powyższego, jeśli Wykonawca nie dopełni ww. obowiązków wynikających z ustawy, Zamawiający będzie miał podstawę do uznania, że zastrzeżenie tajemnicy przedsiębiorstwa jest bezskuteczne i w związku z tym potraktuje daną informację, jako niepodlegającą ochronie i niestanowiącą tajemnicy przedsiębiorstwa w rozumieniu ustawy o zwalczaniu nieuczciwej konkurencji.

15.25.3 Jednocześnie Zamawiający wskazuje, iż zgodnie z art. 8 ust. 3 ustawy Pzp, Wykonawca nie może zastrzec informacji, o których mowa w art. 86 ust. 4 ustawy Pzp.

15.25.4 Elementy oferty, które Wykonawca zamierza zastrzec jako tajemnicę przedsiębiorstwa w rozumieniu art. 11 ust. 4 ustawy z dnia 16 kwietnia 1993r. o zwalczaniu nieuczciwej konkurencji (Dz. U. z 2003r. Nr 153, poz. 1503 z późn. zm.) powinny zostać umieszczone w odrębnej, zaklejonej kopercie (lub zabezpieczone w inny sposób), opisanej „tajemnica przedsiębiorstwa”, dołączonej do oryginału oferty. W treści oferty powinna zostać umieszczona informacja, że dany dokument jest zastrzeżony. Wykonawca zobowiązany jest wykazać, iż zastrzeżone informacje stanowią tajemnicę przedsiębiorstwa (art. 8 ust. 3 ustawy Pzp).

16 TERMIN I MIEJSCE SKŁADANIA I OTWARCIA OFERT

16.1 Oferty należy składać na adres:

Państwowy Instytut Geologiczny – Państwowy Instytut Badawczy (PIG-PIB) xx. Xxxxxxxxxx 0, 00-000 Xxxxxxxx

Kancelaria Ogólna (parter budynku, pok. 1) czynna w godzinach 7.30 – 15.30

16.2 Termin składania ofert upływa 21.11.2016 r. o godz. 11:00

16.3 Oferty dostarczone do Zamawiającego za pośrednictwem operatora pocztowego, osobiście lub posłańca będą zakwalifikowane do postępowania przetargowego pod warunkiem ich dostarczenia do terminu określonego w pkt 16.2 SIWZ. Decyduje data i godzina wpływu do Kancelarii Ogólnej PIG-PIB.

16.4 Zamawiający niezwłocznie zawiadamia Wykonawcę o złożeniu oferty po wyznaczonym terminie na składanie ofert oraz zwraca ofertę po upływie terminu do wniesienia odwołania.

16.5 Otwarcie złożonych ofert nastąpi w dniu 21.11.2016 r. o godz. 11:15, w siedzibie Zamawiającego w xxx. X, xxx. xx 000.

16.6 Otwarcie ofert jest jawne.

16.7 Niezwłocznie po otwarciu ofert Zamawiający zamieści na stronie xxx.xxx.xxx.xx/xxxxxxxxx informacje dotyczące:

16.7.1 kwoty, jaką zamierza przeznaczy na sfinansowanie zamówienia;

16.7.2 firm oraz adresów wykonawców, którzy złożyli oferty w terminie;

16.7.3 ceny, terminu wykonania zamówienia, okresu gwarancji i warunków płatności zawartych w ofertach.

17 OPIS SPOSOBU OBLICZANIA CENY OFERTY

17.1 Wykonawca określi wszystkie ceny zgodnie z Formularzem cenowym (Załączniki nr 3.1 do SIWZ).

17.2 Wyliczoną cenę z Formularza cenowego Wykonawca przeniesie do Formularza ,,Oferta’’ – Załącznik nr 3 do SIWZ.

17.3 Zamawiający wymaga aby ceny za wykonanie I, II, III oraz IV Iteracji wdrożenia Systemu stanowiły odpowiednio 25% wartości całości wynagrodzenia pomniejszonego o wartości dostawy licencji oprogramowania, świadczenie usługi: Maintenance oraz świadczenia usługi wsparcia wdrażanego Systemu.

17.4 Wszystkie ceny określone przez Wykonawcę w Formularzu cenowym zostaną ustalone na okres ważności umowy i nie będą podlegały zmianom.

17.5 Cena w formularzu „Oferta” musi uwzględniać wszystkie wymagania niniejszej SIWZ oraz obejmować wszystkie koszty, jakie poniesie Wykonawca z tytułu należytej oraz zgodnej z obowiązującymi przepisami realizacji przedmiotu zamówienia.

17.6 Wszystkie ceny będą określone w złotych polskich (PLN) z dokładnością do dwóch miejsc po przecinku, a wszystkie płatności będą realizowane w złotych polskich, zgodnie z obowiązującymi przepisami.

17.7 Wszystkie ceny określone przez Wykonawcę w Formularzu ,,Oferta’’ zostaną ustalone na okres ważności umowy i nie będą podlegały zmianom.

17.8 Jeżeli Xxxxxxxxxxxxx zostanie złożona oferta, której wybór prowadziłby do powstania u Zamawiającego obowiązku podatkowego zgodnie z przepisami o podatku od towarów i usług, zamawiający w celu oceny takiej oferty dolicza do przedstawionej w niej ceny podatek od towarów i usług, który miałby obowiązek rozliczyć zgodnie z tymi przepisami. Wykonawca, składając ofertę, informuje Zamawiającego, czy wybór oferty będzie prowadzić do powstania u Zamawiającego obowiązku podatkowego, wskazując nazwę (rodzaj) towaru lub usługi, których dostawa lub świadczenie będzie prowadzić do jego powstania, oraz wskazując ich wartość bez kwoty podatku.

17.9 Zamawiający zwraca się o udzielenie wyjaśnień (w tym złożenie dowodów) jeżeli cena oferty lub jej istotne części składowe wydają się rażąco niska w stosunku do przedmiotu zamówienia i budzą wątpliwości Zamawiającego co do możliwości wykonania przedmiotu zamówienia zgodnie z wymaganiami określonymi przez Zamawiającego lub wynikającymi z odrębnych przepisów.

17.10 Zamawiający zwraca się o udzielenie wyjaśnień w przypadku gdy cena całkowita oferty jest niższa o co najmniej 30% od:

17.10.1 wartości zamówienia powiększonej o należny podatek od towarów i usług, ustalonej przed wszczęciem postępowania zgodnie z art. 35 ust. 1 i 2 ustawy Pzp, lub średniej arytmetycznej cen wszystkich złożonych ofert, chyba że rozbieżność wynika z okoliczności oczywistych, które nie wymagają wyjaśnienia;

17.10.2 wartość zamówienia powiększonej o należny podatek od towarów i usług, zaktualizowanej z uwzględnieniem okoliczności, które nastąpiły po wszczęciu postępowania, w szczególności istotnej zmiany cen rynkowych, Zamawiający może zwrócić się o udzielenie wyjaśnień, o których mowa w pkt 17.8 SIWZ).

18 OPIS KRYTERIÓW, KTÓRYMI ZAMAWIAJĄCY BĘDZIE SIĘ KIEROWAŁ PRZY WYBORZE OFERTY WRAZ Z PODANIEM ZNACZENIA KRYTERIÓW I SPOSOBU OCENY OFERT

18.1 Ocenie zostaną poddane oferty nie podlegające odrzuceniu.

18.2 Przy wyborze najkorzystniejszej oferty Zamawiający będzie się kierował następującymi kryteriami i ich znaczeniem:

Numer Kryterium	Nazwa kryterium	Waga podana w punktach
1	Cena	100

18.3 Liczba punktów przyznana poszczególnym ofertom zostanie obliczona z dokładnością do dwóch miejsc po przecinku albo z dokładnością wystarczającą do wykazania zróżnicowania ofert niepodlegających odrzuceniu.

18.4 Sposób obliczenia wartości punktowej w kryterium cena (Pc):

najniższa cena

Pc =

cena oferty badanej

x 100 pkt

Maksymalna liczba punktów w tym kryterium wynosi 100 pkt.

18.5 Za ofertę najkorzystniejszą uznana zostanie oferta, która otrzyma najwyższą liczbę przyznanych punktów wg. ww. kryterium.

19 INFORMACJA O FORMALNOŚCIACH JAKIE POWINNY ZOSTAĆ DOPEŁNIONE PO WYBORZE OFERTY W CELU ZAWARCIA UMOWY W SPRAWIE ZAMÓWIENIA PUBLICZNEGO

19.1 Osoby reprezentujące Wykonawcę przy podpisywaniu umowy powinny posiadać ze sobą dokumenty potwierdzające ich umocowanie do podpisania umowy, o ile umocowanie to nie będzie wynikać z dokumentów załączonych do oferty.

19.2 W przypadku wyboru oferty złożonej przez Wykonawców wspólnie ubiegających się o udzielenie zamówienia Zamawiający może żądać przed zawarciem umowy przedstawienia umowy regulującej współprac tych Wykonawców. Umowa taka winna określać strony umowy, cel działania, sposób współdziałania, zakres prac przewidzianych do wykonania każdemu z nich, solidarną odpowiedzialność za wykonanie zamówienia, oznaczenie czasu trwania konsorcjum (obejmującego okres realizacji przedmiotu zamówienia, gwarancji i rękojmi), wykluczenie możliwości wypowiedzenia umowy konsorcjum przez któregokolwiek z jego członków do czasu wykonania zamówienia.

19.3 Zamawiający poinformuje Wykonawcę, którego oferta zostanie wybrana jako najkorzystniejsza, o miejscu i terminie zawarcia umowy.

20 WYMAGANIA DOTYCZĄCE ZABEZPIECZENIA NALEŻYTEGO WYKONANIA UMOWY

20.1. W celu zapewnienia należytego wykonania umowy ustanawia się zabezpieczenie w wysokości 5% ceny całkowitej brutto.

20.2. Strony ustalają, że zabezpieczenie, o którym mowa powyżej Wykonawca wniesie przed zawarciem umowy w:

20.2.1. pieniądzu – przelewem – na rachunek Zamawiającego: Getin Noble Bank S.A. nr konta: 52 1560 0013 2366 2335 1965 0001;

20.2.2. poręczeniach bankowych lub poręczeniach spółdzielczej kasy oszczędnościowo- kredytowej, z tym że zobowiązanie kasy jest zawsze zobowiązaniem pieniężnym,

20.2.3. gwarancjach bankowych,

20.2.4. gwarancjach ubezpieczeniowych ,

20.2.5. poręczeniach udzielanych przez podmioty, o których mowa w art. 6b ust. 5 pkt 2 ustawy z dnia 9 listopada 2000 r. o utworzeniu Polskiej Agencji Rozwoju Przedsiębiorczości,

20.3. Dokument, stanowiący potwierdzenie wniesienia zabezpieczenia należytego wykonania umowy (np. kopia przelewu lub oryginał gwarancji) Wykonawca powinien złożyć do zawieranej umowy.

20.4. Dopuszcza się wnoszenie zabezpieczenia do ustalonej w ust. 1 wysokości, według wyboru Wykonawcy, w jednej lub kilku określonych wyżej formach.

20.5. W przypadku wniesienia zabezpieczenia w formie gwarancji i poręczeń muszą być one wystawione na okres obejmujący wykonanie zamówienia oraz okres rękojmi.

21. WARUNKI UMOWY O WYKONANIE ZAMÓWIENIA

21.1. Ogólne i szczegółowe warunki umowy, które uwzględnione będą w przyszłej umowie z wybranym w wyniku niniejszego postępowania Wykonawcą zamieszczone są w Istotnych postanowieniach umowy – załącznik nr 2 do SIWZ.

21.2.Wszelkie pytania i wątpliwości dotyczące Istotnych postanowień umowy, będą rozpatrywane jak dla całej SIWZ, zgodnie z art. 38 ustawy Pzp.

21.3. Konieczność powierzenia podwykonawcom realizacji jakiegoś elementu zamówienia, wynikła w trakcie realizacji zamówienia, wymaga uzyskania zgody Zamawiającego.

21.4. Powierzenie wykonania części zamówienia podwykonawcom nie zwalnia Wykonawcy z odpowiedzialności za należyte wykonanie tego zamówienia.

21.5.W przypadku zmiany lub rezygnacji z podwykonawcy (dotyczy podmiotu, na którego zasoby wykonawca powoływał się, na zasadach określonych w art. 22a ust. 1 ustawy, w celu wykazania spełniania warunków udziału w postępowaniu) Wykonawca jest obowiązany wykazać Zamawiającemu, iż proponowany inny podwykonawca lub Wykonawca samodzielnie spełnia je w stopniu nie mniejszym niż podwykonawca, na którego zasoby Wykonawca powoływał się w trakcie postępowania o udzielenie zamówienia.

21.6. Przewidywane zmiany umowy i warunki ich wprowadzenia zostały określone w Istotnych postanowieniach umowy.

21.7. Przed podpisaniem umowy Wykonawca wniesie zabezpieczenie należytego wykonania umowy w wysokości 5% ceny całkowitej podanej w Formularzu ,,Oferta’’.

22. POUCZENIE O ŚRODKACH OCHRONY PRAWNEJ PRZYSŁYGUJĄCYCH WYKONAWCY W TOKU POSTĘPOWANIA O UDZIELENIE ZAMÓWIENIA

22.1.Wykonawcom i uczestnikom konkursu, a także innym osobom, jeżeli mają lub mieli interes w uzyskaniu danego zamówienia oraz ponieśli lub mogą ponieść szkodę w wyniku naruszenia przez zamawiającego przepisów niniejszej ustawy - przysługują środki ochrony prawnej – na zasadach określonych w art. 180 – 198 ustawy PZP.

22.2. Odwołanie przysługuje od niezgodnej z przepisami ustawy czynności zamawiającego podjętej w postępowaniu o udzielenie zamówienia lub zaniechania czynności, do której zamawiający jest zobowiązany na podstawie ustawy.

22.3. Na orzeczenie Krajowej Izby Odwoławczej wydane w wyniku wniesienia odwołania - stronom oraz uczestnikom postępowania odwoławczego przysługuje skarga do sądu.

22.4. Zasady wnoszenia odwołania oraz skargi do Sądu – w tym w szczególności terminy, forma, tryb, sposób, organy właściwe do wniesienia - zostały opisane w art. 180 -198 ustawy Pzp.

23. POSTANOWIENIA KOŃCOWE

23.1. Do spraw nieuregulowanych w niniejszej SIWZ zastosowanie mają przepisy ustawy z dnia 29 stycznia 2004 r. - Prawo zamówień publicznych (Dz. U. z 2015 r. poz. 2164 z późn. zm.).

23.2.Wszelkie koszty związane z przygotowaniem oferty i udziałem w postępowaniu ponosi Wykonawca.

23.3.Wszystkie załączniki do niniejszej SIWZ stanowią jej integralną część.

24. ZAŁĄCZNIKI:

24.1. Załącznik nr 1 do SIWZ – Opis przedmiotu zamówienia;

24.2. Załączniki nr 1.1 do SIWZ – Opis próbki produktu;

24.3. Załącznik nr 2 do SIWZ – Istotne postanowienia umowy;

24.4. Załącznik nr 3 do SIWZ – Formularz „Oferta”;

24.5. Załączniki nr 3.1– Formularz cenowy;

24.6. Załącznik nr 4 do SIWZ – Formularz JEDZ;

24.7. Załącznik nr 5 do SIWZ – Oświadczenie z art. 24 ust. 1 pkt 23 – grupa kapitałowa.

Załącznik nr 1 do SIWZ

O P I S P R Z E D M I O T U Z A M Ó W I E N I A

Spis treści

1. Wprowadzenie 19

1.1. Cel dokumentu 19

1.2. Zakres produktu 19

1.3. Definicje 19

1.4. Omówienie dokumentu 19

2. Ogólny opis produktu 19 2.1. Kontekst funkcjonalny 19

2.2. Architektura systemu 20

2.3. Charakterystyka użytkowników 22

2.4. Ograniczenia 23

2.5. Wymagania prawne 25

2.6. Założenia zależności 26

3. Wymagania funkcjonalne 26 3.1. Opis otoczenia 26

3.1.1. Dane istniejące 27

3.1.2. Interfejsy z innymi systemami informatycznymi 28

3.2. Funkcjonalności systemu 30

3.2.1. Moduł e-Usług 31

3.2.2. Moduł Pracy Grupowej 35

3.2.3. Moduł Repozytorium 44

3.2.4. Komponent OCR 48

4. Wymagania poza funkcjonalne 49 4.1. Użyteczność 49

4.2. Opis procesów 50

4.3. Wydajność 52

4.4. Bezpieczeństwo 53

5. Wymaganie techniczne na platformę 55

5.1. Wymagania ogólne 55

5.2. Wymagania na repozytorium platformy 56

5.3. Wymagania na serwer aplikacji platformy 61

5.4. Wymagania na infrastrukturę integracyjną (szyna usługowa) 63

5.5. Wymagania na silnik procesów biznesowych 69

6. Zawartość przedmiotu zamówienia 73

7. Szkolenia 75

8. Wymagania na zespół Wykonawcy Błąd! Nie zdefiniowano zakładki.

1. Wprowadzenie

1.1. Cel dokumentu

Niniejszy dokument prezentuje wymagania dotyczące oprogramowania, czyli opisuje funkcjonalność budowanego oprogramowania i warunki, jakie ono musi spełniać.

1.2. Zakres produktu

Państwowy Instytut Geologiczny – Państwowy Instytut Badawczy w głównej siedzibie w Warszawie i siedmiu jednostkach regionalnych (Gdańsk, Kielce, Kraków, Lublin, Sosnowiec, Szczecin, Wrocław) zatrudnia ponad 860 osób. W zakresie działań PIG-PIB jest gromadzenie, pozyskiwanie, przetwarzanie i udostępnianie danych geologicznych oraz informacji geologicznej. W ramach niniejszego zamówienia PIG-PIB oczekuje rozbudowę posiadanego systemu o nowe funkcjonalności jakimi będą udostępnione e-Usług umożliwiające klientom zewnętrznym załatwienie sprawy z PIG-PIB droga elektroniczną. W związku z potrzebą szybkiego i sprawnego dostępu do zbiorów danych (jakimi są zbiory plikowe) zamawiający oczekuje wdrożenia jednego centralnego repozytorium w ramach którego gromadzone będę zasoby plikowe (w tym też dokumenty). Odpowiednie zarządzanie dokumentami i zbiorami plikowymi umożliwi ujednolicenie sposobu postępowania z danymi.

1.3. Definicje

ePUAP	Elektroniczna Platforma Usług Administracji Publicznej
SOPO	System Osłony Przeciwosuwiskowej
Platforma	Oprogramowanie middleware posiadane przez Zamawiającego w skład którego wchodzi: Oracle Enterprise Service Bus, Oracle Business Process Management, Oracle Webcenter Content, Oracle Webcenter Portal
System	Oprogramowanie narzędziowe wraz oprogramowaniem (formularze, procesu, usługi) wykonanym w ramach realizacji niniejszego Zamówienia w oparciu o oprogramowanie narzędziowe.
DIGIT	Aplikacja digitalizacja jest elementem systemu do obsługi procesów digitalizacji dokumentów w NAG PIG-PIB zaimplementowana na Platformie.
OAM	Oprogramowanie Oracle Access Manager
CBDG	Centralna Baza Danych Geologicznych
CBDH	Centralna Baza Danych Hydrogeologicznych
CBGI	Centralna Baza Geologii Inżynierskiej
BDOH	Bazy danych obszaru hydrogeologia

1.4. Omówienie dokumentu

2. Ogólny opis produktu

2.1. Kontekst funkcjonalny

W ramach niniejszego zamówienia wykonawca musi rozszerzać działający w PIG-PIB system do monitorowania procesów digitalizacji dokumentów w NAG PIG-PIB (DIGIT) o następujące nowe moduły i komponenty:

1. Moduł e-Usług:

a. e-Usługa „Zgłoszenie osuwiska” – świadczona przez PIG-PIB wraz z obsługą procesu.

b. e-Usługa „Stopień wykorzystania zasobów wód podziemnych” – świadczona przez PIG-PIB wraz z obsługą procesu.

c. e-Usługa „Obsługa wniosku o udostępnienie danych (NAG/PSG)” - –

świadczona przez PIG-PIB wraz z obsługą procesu.

d. e-Usługa „Obsługa wniosku o udostępnienie danych (PSH)” - świadczona przez PIG-PIB wraz z obsługą procesu.

e. e-Usługa „Georaporty” – świadczona przez PIG-PIB wraz z obsługą procesu.

2. Moduł Pracy Grupowej:

a. Komponent Komunikacji.

b. Komponent Kancelaria..

c. Komponent Skład chronologiczny.

d. Komponent Archiwum zakładowe.

e. Komponent Przepływ informacji o sprawach.

f. Komponent „Moduł raportowania”.

3. Moduł Repozytorium:

a. Repozytorium Plików „Ciężkich”.

b. Repozytorium dokumentów.

c. Repozytorium aktów własnych.

d. Repozytorium projektowe.

4. Komponent OCR.

2.2. Architektura systemu

Zaproponowane rozwiązanie zostanie wykonane w oparciu o następujące wytyczne architektoniczne:

W 1. Architektura zaproponowanego rozwiązania musi zapewniać minimum funkcjonalność klastra niezawodnościowego (active – passive).

W 2. Interfejs rozwiązania będzie oparty na przeglądarce internetowej, co oznacza, że pełna obsługa, łącznie z wprowadzaniem danych, musi być możliwa przy użyciu przeglądarki.

W 3. Architektura oferowanego rozwiązania będzie zgodna z preferowanym w PIG podejściem SOA (ang. Service Oriented Architecture) oraz BPM (ang. Business Process Management), w szczególności zapewni:

• wykorzystanie modułu portalu (Portal), pełniącego funkcję interfejsu graficznego w architekturze cienkiego klienta (przeglądarka), agregującego funkcjonalność poszczególnych aplikacji,

• wykorzystanie modułu szyny usługowej (Service Bus) odpowiedzialnego za eksponowanie, bezpieczeństwo oraz komunikację usług systemów dziedzinowych,

• wykorzystanie modułu stanowiącego repozytorium informacji niestrukturalnej (nazywanego dalej repozytorium),

• wykorzystanie modułu odpowiedzialnego za realizację procesów biznesowych (BPM) poprzez wyodrębnienie logiki procesowej z aplikacji dziedzinowych i przeniesienie jej na poziom silnika procesów biznesowych.

W 4. Nie dopuszcza się, aby funkcje związane z zarządzaniem treścią, odbywały się z pominięciem mechanizmów repozytorium. Oznacza to, że oferowane rozwiązanie, w zakresie zarządzania dokumentami - w tym w szczególności definiowania metadanych, operacji rejestrowania i wyrejestrowania dokumentu oraz wersjonowania dokumentu - musi korzystać tylko i wyłącznie z usług oferowanych przez repozytorium.

W 5. Mechanizm eksportu danych z bazy i repozytorium nie będzie wymagał żadnych dodatkowych prac ze strony Wykonawcy:

• Eksport wszystkich danych z bazy i repozytorium będzie możliwy do wykonania w każdej chwili, samodzielnie przez Zamawiającego.

• Sposób wykonania eksportu będzie udokumentowany w odpowiedniej części dokumentacji Systemu.

• Eksport danych z bazy i repozytorium nie będzie wymagał poniesienia

żadnych dodatkowych kosztów na rzecz Wykonawcy.

W 6. Rozwiązanie pozwoli Zamawiającemu x.xx. na samodzielne jego parametryzowanie w zakresie procesów BPM oraz reguł biznesowych.

W 7. System musi być budowany w oparciu o komponenty, które w łatwy sposób będzie można rozłączyć, zmodyfikować, itp.

W 8. Rozwiązanie pozwoli Zamawiającemu x.xx. na samodzielną zmianę źródła danych.

W 9. Aplikacja musi być budowana w oparciu o cykl życia produktu, usługi, procesu itp.

W 10. Wykonawca dostarczy rozwiązania w ramach elementów oznaczonych na czerwono na poniższym schemacie architektury.

W 11. Wykonawca zintegruje wszystkie elementy rozwiązania, zgodnie z przedstawionym poniżej schemacie architektury, potwierdzonym na etapie wytworzenia koncepcji projektu.

W 12. Na serwer aplikacji w trybie pasywnym nie są wymagane licencje.

INTERNET

DMZ

Firewall

Load balancer

Serwer usług publicznych

LAN

Firewall

Load balancer

Oracle WLS

Oracle SOA Oracle WCC Oracle WCP

Oracle WLS

Oracle SOA Oracle WCC Oracle WCP

Oracle WLS

Oracle SOA Oracle WCC Oracle WCP

Serwer aplikacji Serwer aplikacji Serwer aplikacji Serwer OCR

(tryb passive)

Serwer bazy danych Access Manager

Na czarno - istniejące elementy infrastruktury

Na czerwono – elementy budowane w ramach projektu

Rysunek 2. Schemat planowanej docelowej architektury rozwiązania

2.3. Charakterystyka użytkowników

Budowa platformy e-Usług poszerzy zakres udostępnianych usług elektronicznych o nowe kanały komunikacyjne ze sklasyfikowanymi interesariuszami zewnętrznymi, takimi jak:

1) organy administracji geologicznej

2) organy administracji samorządowej

3) pracownicy państwowej służby geologicznej i państwowej służby hydrogeologicznej, w zakresie niezbędnym do wykonywania ich ustawowych zadań,

4) przedsiębiorstwa i firmy geologiczne

5) organy gospodarki wodnej

6) organy i jednostki resortu środowiska

7) pozostali interesariusze posiadający interes prawny i faktyczny

8) obywatele.

Budowana platforma e-Usług wpłynie również na pracę wszystkich pracowników PIG- PIB.

2.4. Ograniczenia

W 13. Wszystkie elementy wymienione w pkt 2.1 muszą wykorzystywać funkcjonalność platformy posiadanej przez PIG-PIB. Oznacza to, że oferowane rozwiązanie musi:

• Pracować pod kontrolą serwera aplikacyjnego WebLogic Server;

• Xxxxxxxxx z dokumentów za pomocą usług WebCenter Content;

• Wykorzystywać usługi sieciowe (Web Services) za pomocą szyny Oracle Service Bus;

• Realizować procesy biznesowe za pomocą Oracle BPM.

W 14. Wymaga się aby zaproponowane rozwiązanie było oparte na posiadanych przez Zamawiającego licencjach wymienionych poniżej:

• Weblogic Suite (4 licencje na procesor)

• SOA Suite for Oracle Middleware (2 licencje na procesor)

• Unified Business Process Management Suite (zawierający WebCenter Content oraz WebCenter Portal w trybie ograniczonego wykorzystania – restricted use) (2 licencje na procesor)

• Oracle Database Enterprise Edition

rozszerzonych o dodatkowe licencje, które Wykonawca jest zobowiązany dostarczyć:

• SOA Suite for Oracle Middleware – 2 dodatkowe licencje na procesor wraz z rocznym wsparciem producenta

• Unified Business Process Management Suite – 2 dodatkowe licencje na procesor wraz z rocznym wsparciem producenta

W 15. Zamawiający dopuszcza zaoferowanie licencji technologii równoważnych (z wyjątkiem bazy, gdzie Zamawiający wymaga zastosowania rozwiązania zbudowanego z wykorzystaniem posiadanej przez Zamawiającego bazy Oracle Database) spełniających wymagania opisane w rozdziale „Wymagania techniczne na Platformę”

W 16. Na istniejącej platformie aktualnie eksploatowana jest aplikacja „DIGIT”. Nowe moduły oprogramowania nie mogą wpłynąć na funkcjonalności aplikacji „DIGIT”, chyba że Zamawiający wyrazi na to zgodę.

W 17. W przypadku zaoferowania rozwiązania równoważnego wykonawca zobowiązany jest do odtworzenia funkcjonalności aplikacji „DIGIT”.

W 18. Technologia dla serwerów publicznych i OCR będzie ustalona w trakcie Koncepcji Wdrożenia.

W 19. W przypadku zaoferowania rozwiązania i technologii równoważnych Wykonawca będzie zobowiązany do dostosowania wszystkich rozwiązań obecnie działających w PGI w oparciu o technologię Oracle (wymienioną w niniejszym rozdziale), do pracy w środowisku oferowanej technologii. Działania te muszą być wykonane własnymi siłami Wykonawcy nie później niż do dnia rozpoczęcia testów akceptacyjnych Systemu, bez angażowania zasobów Zamawiającego. Wszystkie rozwiązania muszą zachować całą dotychczasową funkcjonalność i niezawodność na obecnym poziomie. Działania związane z dostosowaniem rozwiązań do nowej technologii nie mogą w żaden sposób wpływać na produkcyjne działanie tychże rozwiązań.

W 20. W rozdziale „Otoczenie Systemu – system do monitorowania procesów digitalizacji dokumentów w NAG PIG-PIB” został zamieszczony opis rozwiązań obecnie działających w PGI w oparciu o technologię Oracle wymienioną w niniejszym rozdziale.

W 21. Wykonawca w zakresie funkcjonalności całego Systemu udzieli licencji otwartej na dowolną liczbę użytkowników środowiska produkcyjnego.

W 22. Wykonawca udzieli wszystkich niezbędnych licencji koniecznych do wdrożenia Systemu spełniającego wymagania Zamawiającego - również tych, które nie zostały szczegółowo opisane.

W 23. Infrastrukturę sprzętową po stronie serwerowej oraz odpowiednią ilość licencji oprogramowania systemowego konieczną do prawidłowego funkcjonowania całego Systemu (architektura rozwiązania opisana w Rozdziale 2.2) dostarcza Zamawiający.

Lista sprzętu i licencji oprogramowania systemowego do wykorzystania na potrzeby Systemu:

Przeznaczenie serwera	Parametry serwera	System operacyjny	Ilość szt.
Serwer aplikacji (środowisko produkcyjne, tryb Active)	CPU: 1x Intel Xeon E5-2624 3CPU: 3 GHz, 4 rdzenie RAM: 128 GB	Oracle Linux 7.1	2
Serwer aplikacji (środowisko produkcyjne, tryb Passive)	Do ustalenia w trakcie realizacji projektu	Oracle Linux 7.1	1
Serwer OCR	Do ustalenia w trakcie realizacji projektu	Windows Server / CentOS	1
Serwer usług publicznych	Do ustalenia w trakcie realizacji projektu	Windows Server / CentOS / Oracle Linux 7.1	1/2
Load balancer	Do ustalenia w trakcie realizacji projektu	Windows Server / CentOS?	1/2

W 24. Infrastrukturę urządzeń skanujących, drukarek kodów kreskowych, czytników kodów kreskowych, czytników oraz kart elektronicznych dostarcza Zamawiający.

W 25. Lista urządzeń do wykorzystania na potrzeby Systemu zostanie przeanalizowana z Wykonawca w trakcie realizacji koncepcji.

2.5. Wymagania prawne

W niniejszym rozdziale w punktach zaprezentowano wymagania dotyczące zgodności rozwiązania informatycznego z przepisami prawa obowiązującymi na terenie Rzeczypospolitej Polskiej, przepisami wewnętrznymi obowiązujących w Państwowym Instytucie Geologicznym Państwowym Instytucie Badawczym oraz odpowiednimi normami.

System musi być zgodny z:

W 26. przepisami prawa obowiązującymi na terenie RP.

W 27. Zapisami Rozporządzenia 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.

W 28. zapisami Ustawy z dnia 14 czerwca 1960 r. Kodeks Postępowania Administracyjnego (Dz.U.2000.98.1071 ze zm.).

W 29. zapisami Ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U.2002.101.926 ze. zm.) i przepisach wykonawczych, w szczególności Rozporządzeniu Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz.U.2004.100.1024).

W 30. zapisami Ustawy z dnia 6 września 2001 r. o dostępie do informacji publicznej (Dz.U.2001.112.1198 ze zm.).

W 31. zapisami Ustawy z dnia 5 sierpnia 2010 r. o ochronie informacji niejawnych (Dz.U. 2010 nr 182 poz. 1228).

W 32. zapisami Ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. z 2013 r. poz. 235).

W 33. zapisami Ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U.2001.130.1450 ze zm.).

W 34. zapisami Rozporządzenia Ministra Administracji i Cyfryzacji z dnia 6 marca 2012

r. w sprawie wzoru i sposobu prowadzenia metryki sprawy (Dz.U.2012.250).

W 35. zapisami Rozporządzenie Prezesa Rady Ministrów z dnia 27 grudnia 2011 r. w sprawie wymagań technicznych dla dokumentów elektronicznych zawierających akty normatywne i inne akty prawne, dzienników urzędowych wydawanych w postaci elektronicznej oraz środków komunikacji elektronicznej i informatycznych nośników danych (Dz.U. 2011.289.1699).

W 36. zapisami Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 30 października 2006 r. w sprawie niezbędnych elementów struktury dokumentów elektronicznych (Dz.U.2006.206.1517).

W 37. zapisami Rozporządzenia Ministra Spraw Wewnętrznych z dnia 30 października 2006 r. w sprawie szczegółowego sposobu postępowania z dokumentami elektronicznymi (Dz.U.2006.206.1518).

W 38. zapisami Rozporządzenia Prezesa Rady Ministrów z dnia 14 marca 2011 r. w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania

dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz.U.2011.206.1216).

W 39. zapisami Rozporządzenia 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.2011.14.67 ze zm.).

W 40. zapisami Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U.2012.526).

W 41. zapisami Ustawa z dnia 18 lipca 2001 r. Prawo wodne (Dz.U. 2001.115.1229).

W 42. zapisami Ustawa z dnia 9 czerwca 2011 r. — Prawo geologiczne i górnicze (Dz.U. 2011.163.981)

W 43. Należy ponadto uwzględnić obowiązujące wewnętrzne regulacje prawno – organizacyjne Zamawiającego, w tym:

• Instrukcja kancelaryjna,

• Istniejące procedury i procesy.

2.6. Założenia zależności

W trakcie realizacji wdrożenia mogą wystąpić następujące zmiany mające wpływ na realizację zamówienia, Zamawiający na etapie analizy koncepcji zobowiązany jest do podjęcia decyzji minimalizujących ryzyka wpływającą na wdrażany system w związku ze spodziewanymi zamianami:

W 44. Zmiana instrukcji kancelaryjnej w jednostce organizacyjnej. W 45. Zmiany dotyczące ustawy Prawo wodne.

W 46. OAM będzie uruchomiony przez Zamawiającego w trakcie trwania projektu budowy Systemu. Jeżeli OAM nie zostanie uruchomiony przez Zamawiającego, Wykonawca będzie zobowiązany do realizacji funkcji autentykacji i autoryzacji użytkowników z Active Directory.

3. Wymagania funkcjonalne

3.1. Opis otoczenia

Ogólne wymagania związane z otoczeniem systemu:

W 47. Komunikacja z systemem uwierzytelniania, dotycząca przydzielania uprawnienie będzie odbywać się dwustronnie.

W 48. Import dokumentów z innych systemów obiegu dokumentów i ich opisanie metadanymi w celu archiwizacji.

W 49. Integrację z platformą ePUAP

W 50. Weryfikację podpisu elektronicznego i profilu zaufanego (ePUAP).

W 51. Rozwiązanie powinno zapewnić interfejs programistyczny wykorzystujący jako standard komunikacyjny WebServices, pozwalający na bezpieczną wymianę danych z innymi systemami.

W 52. Ergonomiczne i wydajne dodawanie plików do archiwum, uwzględniające fakt, że paczki plików mogą mieć objętość kilkuset GB, z czego jeden plik może mieć objętość nawet 200 GB i więcej.

W 53. Zamawiający posiada obecnie 80 TB danych co stanowi około 1 mln plików.

W 54. W ramach zamówienia skatalogowanych zostaną próbki danych wraz z wykonawcą dla 10 typów danych plikowych.

W 55. Wykonawca zaproponuje strukturę katalogową dla wszystkich danych wymienionych w tabeli 2.

3.1.1. Dane istniejące

Dane wymagające migracji.

Zbiór danych, którymi powinien być zasilony system

Zakres danych

Dokumenty aktów własnych

Są to dokumenty w formatach pdf, doc, xls, xlsx. Dane zgromadzone są w bazie danych, wraz z opisem metadanych.

Wymagana jest migracja

dokumentów aktów własnych do repozytorium aktów własnych.

Tabela 1. Dane wymagane do migracji.

Dane o strukturze plikowej do opracowania struktury katalogowej:

	Zbiór danych, którymi powinien być zasilony system	Zakres danych
	Morskie dane geofizyczne batymetryczne	Dane pokrycia pasa dna pomiarami o dużej gęstości.
	Mapy Batymetryczne	Dane przetworzone
	Dane sonarowe	Dane przedstawiające obraz morfologii dna.
	Mapy sonarowe dna	Dane przetworzone
	Dane sejsmoakustyczne	Dane budowy wgłębnej dna morskiego.
	Numeryczny Model Terenu	Numeryczna reprezentacji powierzchni terenu.
	Numeryczny Model Pokrycia Terenu	Model powierzchni terenu uzupełniony o elementy naturalne (roślinność) i antropogeniczne (budynki, budowle)

	Zbiór danych, którymi powinien być zasilony system	Zakres danych
	Zdjęcia lotnicze	Zdjęcia lotnicze.
	Skaning lotniczy	Pliki binarne zawierające chmurę punktów pochodzącą z lotniczego skaningu laserowego.
	Skaning naziemny	Chmura punktów pomiarowych o współrzędnych X, Y, Z.
	Mapa topograficzna	Dane przetworzone.
	Ortofotomapy	Ortofotomapa to rastrowy, kartometryczny obraz terenu powstały w wyniku ortogonalnego przetworzenia zdjęć lotniczych lub scen satelitarnych.
	Geofizyka	Dyscyplina w dziedzinie nauk o Ziemi, w której bada się Ziemię jako planetę metodami naukowymi używanymi w fizyce. Do gałęzi geofizyki zaliczamy, np.: geoelektryka geofizyka otworowa geomagnetyzm grawimetria magnetometria radiometria geofizyczna sejsmika sejsmika górnicza sejsmologia sejsmologia górnicza

Tabela 2. Dane posiadającą postać plikową.

3.1.2. Interfejsy z innymi systemami informatycznymi

W niniejszej sekcji przedstawiono wykaz systemów informatycznych, z którymi nowy system powinien zostać zintegrowany.

System, z którym nowe rozwiązanie informatyczne

powinno zostać zintegrowane

Zakres integracji

Sposób integracji

Biuletyn Informacji Publicznej (BIP)

Integracja w zakresie udostępniania w BIP informacji o stanie sprawy obsługiwanej dla wskazanego

klienta.

Integracja automatyczna, API do ustalenia w trakcie projektu.

Microsoft Outlook, poczta (Exchange)	Integracja w zakresie rejestrowania maili w systemie w skrzynkach urzędowych, wysyłania maili z systemu.	Integracja automatyczna, API udostępniane przez MS Exchange.
Elektroniczna Platforma Usług Publicznych (EPUAP)	Integracja w zakresie odbierania i wysyłania dokumentów,	Integracja automatyczna, API udostępniane przez EPUAP
Integracja z infrastrukturą PKI (wewnętrzne oraz kwalifikowane CA)	Obsługa wewnętrznego oraz kwalifikowanego podpisu elektronicznego.	API udostępniane przez CA
Microsoft Active Directory (AD)	Wymiana danych pomiędzy systemem a usługą AD, synchronizacja użytkowników, struktury organizacyjnej i uprawnień.	API udostępniane przez AD
Oracle Access Manager (OAM)	Autentykacja i autoryzacja użytkowników Systemu.	API udostępniane przez OAM.
System SOPO	Integracja w zakresie wymiany danych pomiędzy systemem a zewnętrznym systemem SOPO - w procesie obsługi wniosku karty osuwiskowej.	API do ustalenia w trakcie projektu

System monitorowania procesów digitalizacji dokumentów w NAG PIB (DIGIT)	Integracja w zakresie: - wykorzystywania wspólnego repozytorium dokumentów (poprzez rozszerzenie repozytorium systemu digitalizacji) - wykorzystywania wspólnej listy zadań inicjowanych w procesach biznesowych obu systemów (poprzez rozszerzenie komponentu listy zadań systemu digitalizacji) - prowadzenia spraw dla dokumentacji obydwu systemów - archiwizacji dokumentacji systemu digitalizacji w ramach Archiwum Zakładowego	Wykorzystanie tych samych komponentów funkcjonalnych. Wykorzystanie szyny usługowej.
Bazy: CBDG, CBDH, BDGI, BDOH	Integracja w zakresie wymiany danych pomiędzy systemem a bazami posiadanymi przez zamawiającego Integracja może obejmować interfejsy aplikacji obsługujących te bazy danych.	API do ustalenia w trakcie projektu
Integracja z biblioteką HSM.	Integracja polegająca na wydłużeniu czasu oczekiwania na pliku między repozytorium a biblioteką taśmową.	Do ustalenia w trakcie projektu.
Integracja z systemami przestrzennymi zamawiającego wykonanych w technologii ESRI i Integraf.	Integracja umożliwiająca przeszukiwanie zbiorów danych po atrybutach przestrzennych.	API do ustalenia w trakcie projektu.

3.2. Funkcjonalności system

3.2.1. Moduł e-Usług

Oczekuje się, że system umożliwi przyjęcie dokumentacji elektronicznej złożonej przez portal zewnętrzny zamawiającego i/lub zewnętrznego systemu np. e-PUAP i/lub za pomocą pliku XML z wykorzystaniem usług typu WebService. Przyjęta dokumentacja elektroniczna będzie inicjowała procesy biznesowe realizowane przez moduł pracy grupowej. Procesy będą również inicjowane poprzez przyjęcie dokumentu papierowego po przypisaniu do odpowiedniego typu dokumentu.

W 56. Import danych w formacie .xml oraz komunikację z innymi systemami za pomocą XML Web Service.

W 57. Wygenerowanie schematu XSD dla konkretnego typu dokumentu w formacie XML.

W 58. Odbiór spraw/dokumentów elektronicznych złożonych na skrzynkę podawczą w ePUAP oraz wysłanie odpowiedzi na konto w ePUAP.

3.2.1.1. e-Usługa Zgłoszenie osuwiska”

System ma umożliwiać:

W 59. Możliwość realizacji procesu zgłoszenia osuwiska w formie elektronicznej, zaczynając od złożenia dokumentu elektronicznego, przez jego przetwarzanie, aż po odebranie odpowiedzi przez klienta. Procedura zgłoszenia osuwiska opisana jest na stronie xxxx://xxxxxxxxx.xxx.xxx.xx/xxxxxx/xxxx/xxxxxx/XXXX/xxxxxxxxx.

W 60. Złożenie dokumentu elektronicznego wraz z załącznikami poprzez wypełnienie formularza elektronicznego z poziomu portalu zewnętrznego.

W 61. Podpisywanie dokumentu elektronicznego podpisem elektronicznym weryfikowanym certyfikatem kwalifikowanym lub profilem zaufanym EPUAP.

W 62. Walidację danych wypełnianych na formularzu w oparciu o zaimplementowane reguły.

W 63. Generowanie z wypełnionego dokumentu elektronicznego wydruku w formie PDF.

W 64. Automatyczne przesyłanie wypełnionego dokumentu elektronicznego (wraz z wygenerowanym PDF) do komponentu Kancelaria modułu pracy grupowej i rejestrację jako dokumentację przychodzącą.

W 65. Obsługę sprawy w ramach modułu pracy grupowej.

W 66. Wygenerowanie karty osuwiskowej z danych pobranych z systemu SOPO.

W 67. Powiadomienie klienta o podjętych działaniach i decyzji – w formie elektronicznej poprzez wysłanie e-mail, odpowiedzi na konto klienta na portalu zewnętrznym, odpowiedzi na konto klienta na platformie EPUAP. Forma odpowiedzi ma być wybierana w trakcie procesu obsługi wniosku.

W 68. Integrację z systemem SOPO – poprzez wymianę pomiędzy systemami wybranych danych związanych z wnioskiem, danymi o osuwiskach.

W 69. Obsługę dokumentu elektronicznego na portalu zewnętrznym dla użytkowników anonimowych oraz uwierzytelnionych.

W 70. Udostępnienie użytkownikom na portalu zewnętrznym funkcjonalności: rejestracji, resetowania hasła, logowania do swojego konta - a w jego ramach podgląd złożonych przez użytkownika wniosków, dostęp do stanu sprawy, dostęp do odpowiedzi w ramach sprawy.

W 71. Uruchomienie procedury interwencyjnej/wizji lokalnej.

W 72. Wielopoziomowa akceptacja wykonania interwencji, zatwierdzania karty osuwiskowej i zatwierdzania zadań.

3.2.1.2. e-Usługa „Stopień wykorzystania zasobów wód podziemnych”

System ma umożliwiać:

W 73. Możliwość realizacji procesu udostępniania informacji o aktualnym stanie wykorzystania zasobów wodnych w formie elektronicznej, zaczynając od złożenia dokumentu elektronicznego, przez jego przetwarzanie, aż po odebranie odpowiedzi przez klienta.

W 74. Złożenie dokumentu elektronicznego wraz z załącznikami poprzez wypełnienie formularza elektronicznego z poziomu portalu zewnętrznego.

W 75. Podpisywanie wniosku podpisem elektronicznym weryfikowanym certyfikatem kwalifikowanym lub profilem zaufanym ePUAP.

W 76. Walidację danych wypełnianych na formularzu w oparciu o zaimplementowane reguły.

W 77. Generowanie z wypełnionego dokumentu elektronicznego wydruku w formie PDF.

W 78. Automatyczne przesyłanie wypełnionego dokumentu elektronicznego (wraz z wygenerowanym PDF) do komponentu kancelaria modułu pracy grupowej i rejestrację jako dokumentację przychodzącą.

W 79. Obsługę sprawy w ramach modułu pracy grupowej.

W 80. Powiadomienie klienta o podjętych działaniach i decyzji – w formie elektronicznej poprzez wysłanie e-mail, odpowiedzi na konto klienta na portalu zewnętrznym, odpowiedzi na konto klienta na platformie EPUAP. Forma odpowiedzi ma być wybierana w trakcie procesu obsługi wniosku.

W 81. Obsługę dokumentu elektronicznego na portalu zewnętrznym dla użytkowników anonimowych oraz uwierzytelnionych.

W 82. Udostępnienie użytkownikom na portalu zewnętrznym funkcjonalności: rejestracji, resetowania hasła, logowania do swojego konta - a w jego ramach podgląd złożonych przez użytkownika wniosków, dostęp do stanu sprawy, dostęp do odpowiedzi w ramach sprawy.

W 83. Integracja z Bazą danych o Głównych Zbiornikach Wód Podziemnych – GZWP w zakresie niezbędnym do udzielenie informacji o aktualnym stanie wykorzystania.

3.2.1.3. e-Usługa „Obsługa wniosku o udostępnienie danych (NAG/PSG)”

System ma umożliwiać:

W 84. Możliwość realizacji procesu wniosku o udostępnienie danych NAG/PSG w formie elektronicznej, zaczynając od złożenia wniosku elektronicznego, przez jego przetwarzanie, aż po odebranie odpowiedzi przez klienta. Procedura udostępniania danych NAG opisana jest na stronie xxxx://xxx.xxx.xxx.xx/xxxxxxxx-xxxxxxxx-xxxxxxxxxxx/xxxxxxxxxxx-x- udostepnianie-informacji-geologicznej.html

W 85. Złożenie wniosku wraz z załącznikami poprzez wypełnienie formularza elektronicznego z poziomu portalu zewnętrznego.

W 86. Podpisywanie wniosku podpisem elektronicznym weryfikowanym certyfikatem kwalifikowanym lub profilem zaufanym EPUAP.

W 87. Walidację danych wypełnianych na formularzu w oparciu o zaimplementowane reguły.

W 88. Generowanie z wypełnionego wniosku wydruku w formie PDF.

W 89. Automatyczne przesyłanie wypełnionego wniosku (wraz z wygenerowanym PDF) do komponentu Kancelaria modułu pracy grupowej i rejestrację jako dokumentację przychodzącą.

W 90. Obsługę sprawy w ramach modułu pracy grupowej, w szczególności: W 91. Implementację cennika udostępniania danych.

W 92. Automatyczne i/lub ręczne wyliczanie ceny za udostępnienie wnioskowanych danych na podstawie cennika.

W 93. Przesłanie w formie elektronicznej do klienta informacji o kwocie do zapłaty.

W 94. Umożliwienie klientowi zrealizowania płatności online z poziomu konta na portalu zewnętrznym oraz automatyczną aktualizację stanu płatności w ramach wniosku. Wymagana jest integracja z wskazanym przez Zamawiającego pośrednikiem płatności online, z którym Zamawiający podpisze umowę.

W 95. Powiadomienie klienta o podjętych działaniach i decyzji – w formie elektronicznej poprzez wysłanie e-mail, odpowiedzi na konto klienta na portalu zewnętrznym, odpowiedzi na konto klienta na platformie EPUAP. Forma odpowiedzi ma być wybierana w trakcie procesu obsługi wniosku.

W 96. Obsługę wniosków na portalu zewnętrznym dla użytkowników anonimowych oraz uwierzytelnionych.

W 97. Udostępnienie użytkownikom na portalu zewnętrznym funkcjonalności: rejestracji, resetowania hasła, logowania do swojego konta - a w jego ramach podgląd złożonych przez użytkownika wniosków, dostęp do stanu sprawy, dostęp do odpowiedzi w ramach sprawy.

W 98. Weryfikacja poprawności wniosku pod względem formalnym i merytorycznym, potwierdzenie posiadania zbioru danych.

W 99. Ścieżka zbierania danych uzależniona jest od posiadanych zbiorów danych i formy posiadanych danych, zarówno postać cyfrowa jak i analogowa.

3.2.1.4. e-Usługa „Obsługa wniosku o udostępnienie danych (PSH)”

System ma umożliwiać:

W 100. Możliwość realizacji procesu wniosku o udostępnienie danych PSH w formie elektronicznej, zaczynając od złożenia wniosku, przez jego przetwarzanie, aż po odebranie odpowiedzi przez klienta. Procedura udostępniania danych PSH opisana jest na stronie xxxx://xxx.xxx.xxx.xx/xxxxxxxx-xxxxxxxx- geologiczne/udostepnianie-informacji-hydrogeologicznej.html

W 101. Złożenie wniosku wraz z załącznikami poprzez wypełnienie formularza elektronicznego z poziomu portalu zewnętrznego.

W 102. Podpisywanie wniosku podpisem elektronicznym weryfikowanym certyfikatem kwalifikowanym lub profilem zaufanym EPUAP.

W 103. Walidację danych wypełnianych na formularzu w oparciu o zaimplementowane reguły.

W 104. Generowanie z wypełnionego wniosku wydruku w formie PDF.

W 105. Automatyczne przesyłanie wypełnionego wniosku (wraz z wygenerowanym PDF) do komponentu Kancelaria modułu pracy grupowej i rejestrację jako dokumentację przychodzącą.

W 106. Obsługę sprawy w ramach modułu pracy grupowej, w szczególności:

• Implementację cennika udostępniania danych

• Automatyczne i/lub ręczne wyliczanie ceny za udostępnienie wnioskowanych danych na podstawie cennika

• Przesłanie w formie elektronicznej do klienta informacji o kwocie do zapłaty

• Umożliwienie klientowi zrealizowania płatności online z poziomu konta na portalu zewnętrznym oraz automatyczną aktualizację stanu płatności w ramach wniosku. Wymagana jest integracja z wskazanym przez Zamawiającego pośrednikiem płatności online, z którym Zamawiający podpisze umowę.

W 107. Powiadomienie klienta o podjętych działaniach i decyzji – w formie elektronicznej poprzez wysłanie e-mail, odpowiedzi na konto klienta na portalu zewnętrznym, odpowiedzi na konto klienta na platformie EPUAP. Forma odpowiedzi ma być wybierana w trakcie procesu obsługi wniosku.

W 108. Obsługę wniosków na portalu zewnętrznym dla użytkowników anonimowych oraz uwierzytelnionych.

W 109. Udostępnienie użytkownikom na portalu zewnętrznym funkcjonalności: rejestracji, resetowania hasła, logowania do swojego konta - a w jego ramach podgląd złożonych przez użytkownika wniosków, dostęp do stanu sprawy, dostęp do odpowiedzi w ramach sprawy.

W 110. Zebranie danych z różnych źródeł danych (bezpośrednio z bazy danych) bez konieczności korzystania z innych narzędzi.

W 111. Wykonanie do max pięciu konektorów umożliwiających pobranie danych bezpośrednio z bazy danych CBDH.

3.2.1.5. e-Usługa „Georaporty”

System ma umożliwiać:

W 112. Możliwość realizacji procesu wniosku o wygenerowanie georaportu w formie elektronicznej, zaczynając od złożenia wniosku, przez jego przetwarzanie, aż po odebranie odpowiedzi przez klienta.

W 113. Złożenie wniosku wraz z załącznikami poprzez wypełnienie formularza elektronicznego z poziomu portalu zewnętrznego.

W 114. Podpisywanie wniosku podpisem elektronicznym weryfikowanym certyfikatem kwalifikowanym lub profilem zaufanym EPUAP.

W 115. Walidację danych wypełnianych na formularzu w oparciu o zaimplementowane reguły.

W 116. Generowanie z wypełnionego wniosku wydruku w formie PDF.

W 117. Automatyczne przesyłanie wypełnionego wniosku (wraz z wygenerowanym PDF) do komponentu Kancelaria modułu pracy grupowej i rejestrację jako dokumentację przychodzącą.

W 118. Obsługę sprawy w ramach modułu pracy grupowej, w szczególności:

• Implementację cennika składowych georaportu.

• Automatyczne wyliczanie ceny za udostępnienie wnioskowanych danych na podstawie cennika.

• Przesłanie w formie elektronicznej do klienta informacji o kwocie do zapłaty.

W 119. Powiadomienie klienta o podjętych działaniach i decyzji – w formie elektronicznej poprzez wysłanie e-mail, odpowiedzi na konto klienta na portalu zewnętrznym, odpowiedzi na konto klienta na platformie EPUAP. Forma odpowiedzi ma być wybierana w trakcie procesu obsługi wniosku.

W 120. Obsługę wniosków na portalu zewnętrznym dla użytkowników anonimowych oraz uwierzytelnionych.

W 121. Udostępnienie użytkownikom na portalu zewnętrznym funkcjonalności: rejestracji, resetowania hasła, logowania do swojego konta - a w jego ramach podgląd złożonych przez użytkownika wniosków, dostęp do stanu sprawy, dostęp do odpowiedzi w ramach sprawy.

W 122. Zebranie danych z różnych źródeł danych (bezpośrednio z bazy danych) bez konieczności korzystania z innych narzędzi.

W 123. Pobranie niezbędnych danych z narzędzi GIS (Intergraf i ESRI).

W 124. Proces, którego produktami będę produkty informacyjne w postaci zdefiniowanych georaportów, zawierającego dane tabelaryczne, mapy, opinie eksperckie itp.

W 125. W ramach zamówienia zostanie opracowanych max 5 produktów informacyjnych. W 126. Możliwa integracja z następującymi bazami:

• CBDG

• CBDH

• BDGI

W 127. W ramach tworzenie produktów informacyjnych w postaci georaportów zostanie utworzonych max 5 konektorów, sięgających po odpowiednie zbiory danych wymienionych w punkcie wyżej.

3.2.2. Moduł Pracy Grupowej

Oczekuje się, że rozwiązanie w tym zakresie zapewni zestaw funkcjonalności umożliwiających wykonanie czynności kancelaryjnych, dokumentowanie przebiegu załatwiania spraw oraz gromadzenie i tworzenie dokumentów elektronicznych oraz zapisywanie ich w repozytorium dokumentów.

W 128. Rozwiązanie musi zapewnić pracę grupową wielu użytkowników nad dokumentami i plikami. Praca grupowa w szczególności oznacza możliwość dynamicznego definiowania struktur repozytorium z poziomu portalu (przestrzenie robocze) oraz, zapewnienie wersjonowania dokumentów umieszczonych w przestrzeni roboczej.

W 129. Podpisywanie dokumentu podpisem elektronicznym kwalifikowanym i niekwalifikowanym.

W 130. Prowadzenie rejestrów i możliwość ich eksportu do formatu .xls.:

• Użytkowników Systemu i ich uprawnień

• Kontrahentów, z możliwością importu i eksportu pozycji za pomocą usługi sieciowej

• Przesyłek wpływających

• Przesyłek wychodzących

• Rozliczenie przesyłek wychodzących

• Dokumentów bez przypisania do sprawy

• Dokumentów przypisanych do projektu

• Spraw Książek nadawczych dla różnych usługodawców

• Innych, tworzonych dynamicznie na bazie metadanych dokumentu/pliku.

W 131. Wyszukiwanie dokumentów / spraw / kontrahentów / użytkowników z użyciem operatorów logicznych.

W 132. Wyświetlanie zadań z bliskim / przekroczonym terminem realizacji i umożliwić tworzenie raportów z wykonywania zadań (z uwzględnieniem uprawnień dla różnych użytkowników).

W 133. Dostęp do informacji o akceptacjach i opiniach dla dokumentu/pliku zbioru dokumentów/plików dla osób uprawnionych.

W 134. Rozpoczynanie obiegu automatycznego przez użytkownika i przez system. W 135. Zakończenie obiegu przez osobę uprawnioną w dowolnym momencie.

W 136. Wizualizację obiegów automatycznych.

W 137. Wersjonowanie obiegów automatycznych (wprowadzenie nowej wersji obiegu automatycznego nie ma wpływu na przebieg działania obiegów rozpoczętych w poprzedniej wersji).

W 138. Wyszukiwanie obiegów automatycznych.

W 139. Podgląd wszystkich (spraw) zleconych w ramach obiegu.

W 140. Podgląd listy zadań przypisanych do danej grupy użytkowników.

W 141. Obsługę podpisu elektronicznego weryfikowanego certyfikatem kwalifikowanym i wewnętrznym.

W 142. Zarządzanie systemem, w szczególności zarządzanie słownikami, bazami adresowymi, bazami rozdzielników, export i import danych, tworzenie procesów – Workflow (automatyzacja procesów powtarzalnych i wdrożenie procesów ad hoc).

W 143. Walidację wprowadzanych danych określonych na etapie koncepcji wdrożenia. W 144. Walidację danych w rejestrach określonych na etapie koncepcji wdrożenia.

W 145. Wykorzystanie certyfikatów kwalifikowanych do elektronicznego podpisywania dokumentów.

W 146. Wykorzystanie certyfikatów niekwalifikowanych do elektronicznego podpisywanie dokumentów (wykorzystania własnego systemu infrastruktury klucza publicznego (PKI) udostępnionej przez Zamawiającego).

W 147. Wielokrotne podpisywanie dokumentu elektronicznego. Rejestrację wyników prowadzonych spraw (typu: udzielona zgoda/ odmowa/sprawa bez rozstrzygnięcia itp.).

W 148. Prowadzenie historii działań wykonanych w ramach prowadzonych zadań nad dokumentami i sprawy (włącznie z uwzględnieniem terminu odbioru korespondencji przez stronę) w postaci czytelnej i możliwej do wydrukowania. Układ historii:

• Data zdarzenia

• Nazwa zdarzenia ( rejestracja dokumentu pod nr. lub założenie sprawy nr. )

• Autor

• Wynik (np. w przypadku decyzji – pozytywna/zgoda negatywna/odmowa itp.). W 149. Przechowywanie informacji o czynnościach wykonywanych w systemie (imię,

nazwisko i stanowisko osoby wykonującej czynność w systemie).

W 150. Definiowanie odrębnych rejestrów dokumentów pozwalających na dowolne grupowanie pism niezależnie od spraw.

W 151. Definiowanie szablonów dokumentów sporządzanych w edytorach tekstu z poziomu aplikacji (pisma wychodzące, wchodzące i pozostałe dokumenty).

W 152. System powinien umożliwiać obsługę akcji użytkowników w ramach obiegu dokumentu zdefiniowanych na etapie koncepcji wdrożenia, w tym:

W 153. Słownik poleceń – z możliwością rozszerzania listy wartości słownika

W 154. System powinien umożliwiać definiowanie zadań (dekretacji) przy użyciu następujących elementów:

• Autor zadania.

• Adresaci zadania (osoba, lista osób lub grupa osób, którym zlecone zostało zadanie).

• Wykonujący zadanie (jeden z adresatów, który pobrał lub do którego przypisano zadanie).

• Opis zadania.

• Polecenie

• Status zadania (do wykonania, zamknięte).

• Czas na rozwiązanie zadania.

• Data zlecenia zadania.

• Data wykonania zadania. System musi umożliwiać:

W 155. Użytkownikom dostęp do wszystkich zadań (dekretacji) do nich przypisanych („Moje zadania”).

W 156. Wykonywanie następujących akcji dla zadań (dekretacji) przypisanych do grupy użytkowników:

• „Pobierz (Realizuję)” - Zadanie zostanie przepisane z grupy do konkretnej osoby,

• „Prześlij do” - Dla uprawnionych użytkowników (przełożonych) będzie istniała możliwość przypisania dokumentu do konkretnej osoby.

W 157. Personalizację wyglądu interfejsu użytkownika, prezentowania informacji (np. sposób sortowania), sposobu powiadomień.

W 158. Hurtową dekretację – czyli dekretację co najmniej dwóch pism naraz.

W 159. Dodawanie pism do sprawy innemu pracownikowi komórki organizacyjnej – zespołu.

W 160. Przełożonym dostęp do spraw prowadzonych przez podwładnych.

3.3.2.1. Komponent Komunikacji

W 161. System musi umożliwić powiadamianie użytkowników biorących udział przy pracy nad jednym dokumentem o pojawieniu się nowego komentarz.

W 162. System musi umożliwiać tworzenie dyskusji (komentarzy z daną teczką tematyczną).

W 163. System musi powiadamiać użytkownika o wprowadzonych typach plików z koniecznością uzupełnienia metadanych o plikach.

W 164. System musi posiadać mechanizm subskrypcji - powiadamiania e¬mail o zmianach danego dokumentu, z możliwością wybrania przez użytkownika o jego włączenia.

W 165. System musi być wyposażone w mechanizm powiadamiania odpowiednich osób o zdarzeniach w obiegu dokumentów z możliwością ich wyłączenia przez użytkownika.

W 166. System musi informować użytkowników o zbliżającym się oraz przekroczonym terminie realizacji konkretnego zadania.

W 167. System musi zapewniać możliwość definiowania ograniczeń czasowych dla poszczególnych kroków, jak i dla całej ścieżki obiegu dokumentów.

W 168. Powiadomienie użytkowników o pojawieniu się nowego zaakceptowanego aktu własnego, zarówno przez System jak i drogą meilową.

W 169. Realizację zadania w ramach obiegu dokumentów, poprzez wykonanie akcji lub/i zlecenie kolejnych zadań innym użytkownikom.

W 170. Obsługę ręcznego (użytkownik samodzielnie decyduje o zleceniu kolejnych zadań podczas inicjacji obiegu i w odpowiedzi na zlecone zadanie) i automatycznego obiegu dokumentów (skorzystanie ze zdefiniowanego obiegu dokumentów).

W 171. Udostępnienie teczek tematycznych innym komórkom organizacyjnym.

W 172. Powiadomienie o zbliżających się terminach załatwienia pisma, zadania, sprawy.

W 173. System powinien pozwalać przełożonemu na zmianę terminów, z jednoczesnym odnotowaniem w historii sprawy, historii dokumentu.

W 174. Eksport i import danych słownikowych. W 175. Definiowanie wielu kalendarzy.

W 176. Definiowanie powiadomień przez administratora wg różnych parametrów. W 177. Definiowanie szablonów powiadomień.

W 178. Umożliwiać wysyłanie powiadomień e-mailem informujących pracowników o wstępnie wprowadzonych przesyłkach pilnych/terminowych.

3.3.2.2. Komponent Kancelaria

W 179. System po zarejestrowaniu dokumentu w systemie może inicjować automatyczny elektroniczny obieg dokumentów dla konkretnego typu dokumentu.

W 180. System musi inicjować automatyczny przepływ dokumentów według zdefiniowanych wcześniej ścieżek, dla wybranych typów dokumentów.

W 181. System musi umożliwiać tworzenie ad-hoc ścieżki obiegu dla danego dokumentu.

W 182. System musi pozwalać na definiowanie wielu etapów obiegu dokumentów. Na każdym etapie musi być możliwe zdefiniowanie wielu recenzentów.

W 183. Ścieżki obiegu dokumentów mogą być zarówno sekwencyjne jak i równoległe i mogą zmieniać się w zależności od akcji podjętych przez użytkowników systemu.

W 184. System musi umożliwiać podejrzenie dokumentu bez konieczności pobierania go na własną stację roboczą, jak i otwarcia przez odpowiednie narzędzie typu word, exel.

W 185. System musi pozwalać na tworzenie spraw tematycznych z dokumentami/plikami. Jeden dokument/plik może być przypisany do wielu spraw.

W 186. System musi pozwalać na rejestrowanie dokumentów oraz teczek tematycznych.

W 187. System musi być wyposażone w moduł umożliwiający bezpośredni dostęp do dokumentów z aplikacji pakietu MS Office i MS Outlook.

W 188. System musi być wyposażony w moduł umożliwiający bezpośredni zapis do repozytorium z aplikacji pakietu MS Office i MS Outlook.

W 189. Umożliwienie opiniowania i akceptowania dokumentów, z możliwością elastycznego definiowania ścieżki akceptacji w momencie inicjowania procesu z poziomu portalu.

W 190. Umożliwienie składania podpisu elektronicznego (wewnętrznego i kwalifikowanego) na dokumencie w trakcie procesu akceptacji.

W 191. Rejestracja dokumentów – rozwiązanie musi zapewnić:

• Numerację dokumentów i spraw według wymagań Zamawiającego

• Klasyfikację dokumentów według zadanego słownika

• Opisanie metadanymi, w tym x.xx.:

i. Kod JRWA

ii. Kody kreskowe (muszą być użyte do wyszukiwania i potwierdzenia przekazywania źródeł dokumentów)

• Wizualizację dokumentu (skanowanie, OCR, zapis do repozytorium, konwersję formatu i prezentację w przeglądarce)

• Przyjęcie dokumentu złożonego za pomocą systemu ePUAP. W 192. Dekretacja dokumentów – rozwiązanie musi zapewnić możliwość:

• Wielokrotnej dekretacji tego samego dokumentu do wielu różnych użytkowników

• Wybrania wielu adresatów w jednej dekretacji

• Dołączenia polecenia i terminów realizacji do dokumentu.

W 193. Możliwość generowania historii dokumentów w postaci raportów.

W 194. Edycję dokumentu w trakcie trwania obiegu tylko przez uczestników w danym momencie realizujących zadanie wymagające edycji w obiegu.

W 195. Rejestrowanie korespondencji przychodzącej, z możliwością podglądu rejestrowanego dokumentu.

W 196. Nadawanie unikatowego identyfikatora, zdefiniowanego przez Zamawiającego, dokumentom.

W 197. Rejestrację korespondencji wychodzącej. W 198. Rejestrację dokumentacji wewnętrznej.

W 199. Tworzenie i modyfikację pocztowych książek nadawczych według wymogów polskich operatorów pocztowych współpracujących z Zamawiającym.

W 200. Pracę kilku osób na raz na jednej książce nadawczej.

W 201. Automatyczne zamknięcie pocztowej książki nadawczej (wysyłka na dany dzień) i rozpoczęcie rejestracji listów, które zostaną wysłane w dniu następnym.

W 202. Obsługę korespondencji (wydruk zwrotek, kopert, etykiet, repozytorium formularzy, druków, wzorów, szablonów).

W 203. Obsługę korespondencji wewnętrznej. W 204. Wydruk dekretacji zastępczej.

W 205. Wykonywanie dekretacji wielopoziomowej. W 206. Wykonywanie akceptacji wielopoziomowej.

W 207. Edytowanie dokumentów na każdym poziomie akceptacji i zatwierdzania.

W 208. Pracę w systemie poza siedzibą urzędu przy wykorzystaniu połączenie szyfrowanego.

W 209. Ustawianie terminów załatwiania pism.

W 210. Śledzenie fizycznej lokalizacji dokumentów papierowych.

W 211. Definiowanie terminów realizacji prac dla konkretnych typów dokumentów. W 212. Ręczne uzupełnianie danych w rejestrze/ewidencji.

W 213. Wysyłkę przesyłek nie stanowiących akt sprawy.

W 214. Opisanie przesyłki wchodzącej, wychodzącej, elementów sprawy nie będących przesyłkami oraz sprawy zestawem metadanych określonych przez instrukcję kancelaryjną.

W 215. Po wprowadzeniu do systemu (za pomocą czytnika) nr R ze zwrotnych potwierdzeń odbioru, automatyczne (elektroniczne) „włożenie” zwrotki do danej sprawy.

W 216. Automatyczne podsumowanie wartości przesyłek zarejestrowanych w poszczególnych pocztowych książkach nadawczych dla poszczególnych punktów pocztowych.

W 217. Usunięcie (wstrzymanie/zwrot do pracownika) pisma z pocztowej książki nadawczej / zbiorczego zestawienia listów dopóki fizycznie przesyłka nie została wysłana.

W 218. Hurtowe wprowadzenie danych przy tworzeniu korespondencji. W 219. Generowanie własnych pocztowych książek nadawczych.

W 220. Dostęp do słownika kodów pocztowych PNA (Pocztowe Numery Adresowe) wraz z możliwością aktualizacji oraz systemu TERYT.

W 221. Bezpośrednie wysłanie pisma przez pracownika merytorycznego za pośrednictwem ePUAP.

W 222. Umieszczenie na skanie pisma wizualizacji pieczątki wpływu/ przyjęcia pisma w danym sekretariacie oraz umieszczenia treści dekretacji w obrębie pieczątki, a także wersjonowanie zmian skanu pisma.

W 223. Nadrukowywanie na pismach wysyłanych do podmiotów zewnętrznych (np. w pasku adresowym) i na kopertach, kodu kreskowego,

3.3.2.3. Komponent Skład chronologiczny

W 224. Generowanie spisów zdawczo-odbiorczych składu chronologicznego i składu informatycznych nośników danych.

W 225. Generowanie: wniosku o udostępnienie/wypożyczenie dokumentacji, protokołu z uszkodzenia lub zagubienia dokumentacji przechowywanej na papierze lub informatycznym nośniku danych.

W 226. Obsługę składów chronologicznych i składów informatycznych nośników danych w zakresie określonym na etapie koncepcji wdrożenia.

W 227. Typowanie dokumentacji do brakowania przez sporządzanie spisów dokumentacji, której czas przechowywania już upłynął z możliwością wydzielenia odpowiedników dokumentacji ze składu chronologicznego lub informatycznych nośników danych.

W 228. Sygnalizowanie konieczności sporządzenia kopii bezpieczeństwa poszczególnych informatycznych nośników danych biorąc pod uwagę czas ich przechowywania.

3.3.2.4. Komponent Archiwum zakładowe

W 229. Umożliwienie dołączenia dokumentów procedowanych w procesie akceptacji do sprawy i RWA.

W 230. Zakładanie i prowadzenie sprawy – rozwiązanie musi zapewnić możliwość:

• Założenia sprawy na podstawie dokumentu

• Założenia wielu spraw z tego samego dokumentu

• Dołączenia dokumentu do istniejącej sprawy

• Klasyfikację i oznakowanie spraw

• Dołączanie dokumentu do sprawy

• Wysyłanie dokumentu ze sprawy

• Wytwarzanie dokumentu w sprawie

• Przekazanie sprawy innemu użytkownikowi

• Wstrzymanie i wznowienie sprawy

• Zakończenie sprawy.

W 231. Możliwość odłożenia dokumentu ad/acta (bez zakładania sprawy). W 232. Możliwość generowania historii spraw w postaci raportów.

W 233. Podgląd listy (spraw) przypisanych do danej grupy użytkowników.

W 234. Dołączanie dokumentacji nieprzyporządkowanej do hasła JRWA (Jednolity Rzeczowy Wykaz Akt).

W 235. Udostępnianie spraw pracownikom innych komórek organizacyjnych.

W 236. Automatyczną numerację spraw oraz konfigurowanie (przez użytkownika) schematu numerowania dla spisów spraw, rejestrów i ewidencji.

W 237. Wydzielanie grup spraw.

W 238. Powiązanie spraw z pozycjami w dedykowanych rejestrach.

W 239. Tworzenie grup roboczych - równoległa praca nad sprawą wielu osób (z różnych komórek organizacyjnych).

W 240. Wersjonowanie RWA.

W 241. Prowadzenie i obsługę archiwum poprzez gromadzenie, ewidencję, przechowywanie, zabezpieczanie i udostępnianie dokumentacji. System powinien zachowywać historię przebiegów załatwienia spraw.

W 242. Automatyczne przekazywanie uprawnień do sprawy dla archiwisty po 2 latach od zakończenia sprawy oraz rejestrować automatycznie datę przekazania uprawnień.

W 243. Dokonywanie uprawnionych zmian w archiwum niezależnie od techniki wytworzenia dokumentu.

W 244. Generowanie: wniosku o udostępnienie/wypożyczenie dokumentacji. W 245. Definiowanie terminów realizacji prac dla ściśle określonych spraw. W 246. Tworzenie sygnatury dokumentu zgodnie z Instrukcją Kancelaryjną.

W 247. Stworzenie dokumentu bez przypisania do sprawy oraz mieć możliwość zmiany znaku sprawy (teczki tworzone są dla danego hasła JRWA).

W 248. System powinien uniemożliwiać zamknięcie sprawy, która nie ma uzupełnionych wszystkich metadanych.

W 249. Administratorowi oraz archiwiście-administratorowi dodawanie lub zmienianie metadanych do pism, spraw.

W 250. Przypisanie do jednego użytkownika różnych ról w ramach różnych spraw.

W 251. Dostęp pracownika do swoich spraw niezależnie od zmian struktury organizacyjnej.

W 252. Dołączanie do akt sprawy maili (poczty elektronicznej).

W 253. Procedowanie sprawy trybem „ad hoc" tj. poprzez definiowanie na bieżąco kolejnego użytkownika zajmującego się sprawą, bez konieczności wykorzystania uprzednio zdefiniowanej ścieżki procedowania sprawy oraz zaniechanie na dowolnym etapie procedowania sprawy zgodnie ze ścieżką i kontynuowanie jej trybem „ad hoc".

W 254. Generowanie wniosku o wycofanie i generowanie protokołu z wycofania dokumentacji z ewidencji archiwum zakładowego w przypadku wznowienia sprawy.

W 255. Typowanie dokumentacji do brakowania przez sporządzanie spisów dokumentacji, której czas przechowywania już upłynął.

W 256. Generowanie paczki archiwalnej celem przekazania materiałów archiwalnych do Archiwum Państwowego z wydzieleniem odpowiedników dokumentacji ze składu chronologicznego lub informatycznych nośników danych i sporządzeniem spisów zdawczo-odbiorczych.

W 257. Kopiowanie metadanych sprawy.

W 258. Przechowywanie informacji czy JRWA ma obieg papierowy czy elektroniczny. W 259. Oznaczanie pism dekretowanych na inne jednostki.

W 260. Prezentację historii sprawy z oznaczeniem kroku w procesie w którym znajduje się sprawa.

W 261. Wstrzymanie lub zawieszenie procedowania sprawy z wymuszeniem określenia powodu wykonania takiej czynności.

3.3.2.5. Komponent Przepływ informacji o sprawach

W 262. Umożliwienie użytkownikom komentowania dokumentów w ramach procesu zaimplementowanego w silniku procesów.

3.3.2.6. Komponent „Moduł raportowania”

W 263. System musi umożliwiać raportowanie działań podejmowanych przez danego użytkownika, bądź w danej lokalizacji (grupie, jednostce, dziale, kancelarii, roli, stanowisku)

W 264. System musi umożliwiać w każdej chwili utworzenie raportu o prawach dostępu użytkowników do zasobów plikowych.

W 265. Wygenerowane raporty powinny mieć możliwość załadowania bezpośrednio do repozytorium jako dokumenty.

W 266. Umożliwienie generowania wydruków/raportów na podstawie wyświetlonych danych z różnych źródeł.

W 267. Kontrolę uprawnień do wykonywania raportów oraz kontrolę dostępu do określonych danych lub zakresu danych raportowych.

W 268. Wykorzystanie predefiniowanych raportów. Wykonawca przygotuje w ramach całego systemu do 10 raportów predefiniowanych poza raportami wymienionymi w wymaganiach.

W 269. Generowanie własnych raportów operacyjnych (wewnętrznych) oraz analiz z danych obecnych w istniejącej bazie danych według zadanych kryteriów.

W 270. System będzie umożliwiać generowanie własnych raportów poprzez:

• Udostępnienie narzędzia do projektowania szablonu raportu i zdefiniowania danych, które mają być przez raport wygenerowane

• Udostępnienie z poziomu modułu raportowania możliwości zarządzania rejestrem raportów udostępnianych z poziomu portalu użytkownikom:

i. z nadaniem uprawnień do wykonywania raportów

ii. z definiowaniem parametrów, które użytkownik może przed wykonaniem raportu przekazać do silnika raportowego

W 271. Eksport danych/raportów/analiz do formatów .xlsx, xls oraz .pdf

W 272. Generowanie wykresów i diagramów ukazujących wybrane zależności. W 273. Generowanie wykazów osób wg zadanych kryteriów.

W 274. Generowanie zestawień statystycznych wg zadanych kryteriów. W 275. Powiadamianie proaktywne i reaktywne:

• Z wykorzystaniem narzędzi klasy BAM

• Raporty:

iii. Co najmniej dotyczące użytkowników, komórek organizacyjnych, kodów RWA, stanów sprawy, stanów dokumentu, terminów (pozostały zakres do ustalenia na etapie analizy).

W 276. Raportowanie danych zadań (postępowań) pod kątem czasów realizacji.

W 277. Tworzenie raportu obiegów automatycznych zakończonych w zadanym okresie.

W 278. Tworzenie raportu zadań rozwiązanych w zadanym okresie dla wybranego obiegu automatycznego.

W 279. Generowanie spisów spraw.

W 280. Swobodne definiowanie rejestrów i ewidencji we wbudowanym kreatorze. W 281. Ustawianie terminów załatwiania spraw.

W 282. Raportowanie i wyszukiwanie (według słów kluczowych, opisu sprawy, wielopoziomowej struktury kryteriów, wyszukiwanie pełno-tekstowe uwzględniające polską fleksję, metadanych).

W 283. Dostęp do raportów dot. aktywności pracy komórek organizacyjnych oraz poszczególnych pracowników.

W 284. Swobodne definiowanie i generowanie statystyk zestawień, dowolnych raportów z systemu obiegu dokumentów.

W 285. Automatyczne tworzenie zbiorczych zestawień listów (podsumowanie wartościowo – ilościowe zgodnie z podziałem na rodzaj przesyłki, masa/gabaryt, źródło finansowania, komórka organizacyjna, itp.) z możliwością edycji.

3.2.3. Moduł Repozytorium

W 286. Funkcje aplikacji, związane z zarządzaniem treścią, musi odbywać się z wykorzystaniem mechanizmów repozytorium. Oznacza to, że w zakresie zarządzania dokumentami/plikami - w tym w szczególności definiowania metadanych, operacji rejestrowania i wyrejestrowania dokumentu oraz wersjonowania dokumentu/pliku - musi korzystać tylko i wyłącznie z usług oferowanych przez repozytorium.

W 287. System musi korzystać z mechanizm rejestrowania i wyrejestrowania dokumentów do edycji (check-in/check-out). Wyrejestrowanie do edycji uniemożliwia zmianę dokumentu przez innego użytkownika. Możliwy jest jednak podgląd, bądź pobranie kopii oryginalnej wersji dokumentu.

W 288. System musi umożliwiać tworzenie dyskusji (komentarzy) powiązanych z danym dokumentem/plikiem.

W 289. System musi umożliwiać przechowywanie zarówno rejestrowanych dokumentów, jak i innych, nie rejestrowanych treści.

W 290. System musi umożliwiać dołączanie załączników do dokumentów.

W 291. System musi umożliwiać automatyczne uruchamianie procesu obiegu dla dokumentów/plików dodanych do systemu, na podstawie zdefiniowanych dla nich metadanych.

W 292. System musi umożliwiać wyszukiwanie poprzez pełnotekstowe przeszukiwanie treści dokumentów, według określonych parametrów (metadanych) dokumentu/pliku, oraz przez kombinację obu metod.

W 293. System musi umożliwiać wyszukiwanie dokumentu w wielu fizycznych repozytoriach poprzez ich wskazanie

W 294. System musi zawierać mechanizm opisywania dokumentów za pomocą metadanych.

W 295. System musi umożliwiać definiowanie zestawów metadanych dla poszczególnych typów dokumentów.

W 296. Dedykowani użytkownicy muszą posiadać możliwość definiowania i dodawania własnych metadanych.

W 297. System musi umożliwiać automatyczne nadawanie zestawu metadanych w zależności od miejsca przechowywania dokumentu/pliku.

W 298. System musi zapewniać to, aby sprawy tematyczne (abstrakcyjne obiekty w repozytorium zawierające fizyczne obiekty w repozytorium) mogły być opisane własnym zestawem metadanych.

W 299. System musi pozwalać na logiczne łączenie dokumentów/plików. System musi umożliwiać przejście z poziomu widoku dokumentu/pliku do innych, połączonych dokumentów/plików.

W 300. System musi umożliwiać przechowywanie dowolnych typów plików.

W 301. System musi zapewniać prowadzenie dziennika zdarzeń. Wszystkie operacje dotyczące działań na zawartości repozytorium (dokumenty) muszą być zapisywane w systemie w sposób umożliwiający określenie kolejności działań i wykonawców czynności.

W 302. System musi umożliwiać rejestrowanie wszelkich operacji wykonywanych na dokumentach/plikach w systemie.

W 303. System musi zapewniać dostęp do dokumentów za pomocą standardowych narzędzi systemów wykorzystywanych przez Zamawiającego (Windows Explorer).

W 304. System musi zapewniać funkcjonalność dostępu do repozytorium (check In dokumentu, check out dokumentu, otwarcie kopii dokumentu, skopiowanie na lokalną stację roboczą) przez uprawnionych użytkowników przy pomocy techniki przeciągnij i upuść (ang. Drag and Drop).

W 305. Generowanie przez administratora z poziomu portalu struktury repozytorium dla typu dokumentu, wraz z nadaniem uprawnień (zapisu, odczytu, usuwania) użytkownikom do zarządzania utworzoną strukturą.

W 306. Nadawanie uprawnień do struktury dokumentów zarówno dla pojedynczych użytkowników jak i grup użytkowników (tożsamych z grupami Active Directory).

W 307. Udostępnienie z poziomu portalu uprawnionym użytkownikom przeglądania i wyszukiwania dokumentów/plików w strukturach repozytorium oraz w ramach

uprawnień dodawania, edytowania wersjonowania i usuwania dokumentów/plików.

W 308. Umożliwienie tworzenia powiązań pomiędzy dokumentami/plikami w dedykowanych strukturach repozytorium.

W 309. Repozytorium dokumentów musi zezwalać na delegowanie części uprawnień administracyjnych do administratorów merytorycznych/lokalnych.

W 310. Model bezpieczeństwa implementowany w repozytorium dokumentów musi być jednolity bez względu na sposób komunikacji z repozytorium (sposób dostępu do repozytorium), w tym: dostęp z poziomu systemów operacyjnych, z poziomu aplikacji WWW oraz z poziomu API dostępnego w rozwiązaniu.

W 311. Repozytorium dokumentów musi pozwalać na integrację z serwerami katalogowymi zgodnymi ze standardem LDAP oraz Microsoft Active Directory na poziomie użytkowników i grup. Zmiany w katalogu użytkowników powinny być natychmiastowo adoptowane przez repozytorium dokumentów.

W 312. Repozytorium dokumentów musi pozwalać na definiowanie grup bezpieczeństwa dla dokumentów. Dany dokument może należeć jedynie do jednej grupy bezpieczeństwa.

W 313. Repozytorium dokumentów musi pozwalać na integrację logowania z logowaniem domenowym.

W 314. Repozytorium dokumentów musi zapewnić niezmienność zarejestrowanych dokumentów w czasie całego czasu ich życia.

W 315. Repozytorium dokumentów musi zapewniać możliwość blokowania dokumentów na potrzeby kontroli, audytu oraz postępowań prawnych.

3.2.3.1. Repozytorium Plików „Ciężkich”

W 316. System musi posiadać możliwość tworzenia miniaturek podglądów dla plików graficznych, z możliwością wybrania dla których typów plików takie miniaturki mają być tworzone.

W 317. Możliwość generowania wydruków dokumentów na podstawie zdefiniowanych szablonów dokumentów, z możliwością zasilenia szablonu zdefiniowanymi w typach plików metadanymi.

W 318. System musi umożliwiać automatyczne konwersje formatów graficznych oraz przechowywanie różnych wersji jednego dokumentu graficznego – np. system przechowuje oryginalne zdjęcie w wysokiej jakości, oraz jego automatycznie skonwertowane wersje do umieszczania w publikacjach drukowanych, stronach internetowych, wyświetlania w urządzeniach przenośnych, etc.

W 319. System musi zapewniać to, aby sprawy tematyczne mogły zawierać dowolną liczbę dokumentów dowolnego typu opisanych dowolnymi metadanymi.

W 320. Możliwość generowania historii plików w postaci raportów. W 321. Rozwiązanie ma zapewnić możliwość:

• Tworzenia struktury repozytorium dla plików ciężkich

• Zarządzania plikami ciężkimi

• Zarządzania cyklem wytwarzania półproduktów i produktów bazujących na plikach ciężkich.

W 322. Generowanie przez administratora z poziomu portalu struktury repozytorium dla paczek plików ciężkich, wraz z nadaniem uprawnień (zapisu, odczytu, usuwania) użytkownikom do zarządzania utworzoną strukturą.

W 323. Udostępnienie funkcjonalności związanych z obsługą plików w repozytorium z poziomu portalu opisanych w wymaganiach dla Modułu Pracy Grupowej.

W 324. Umożliwienie definiowania typów danych dla plików ciężkich na poziomie repozytorium i ich udostępniania na poziomie portalu poprzez dynamicznie generowane (bez potrzeby dodatkowego oprogramowania formularzy) formularze elektroniczne per typ plików.

W 325. Umożliwienie użytkownikom systemu dodawania paczek plików ciężkich wraz z równoległym opisaniem metadanych dokumentu (dla wybranego typu danych).

W 326. Umożliwienie użytkownikom systemu dodawania hurtowego wielu paczek plików ciężkich z jednorazowym opisaniem metadanych dokumentu (dla wybranego typu plików).

W 327. Udostępnianie umieszczonych w archiwum plików ciężkich poprzez funkcjonalności portalu - przeglądania struktury repozytorium oraz wyszukiwania plików po metadanych pliku z uwzględnieniem uprawnień na poziomie repozytorium.

W 328. Udostępnianie umieszczonych w archiwum plików ciężkich poprzez interfejsy integracyjne.

W 329. Stworzenie asynchronicznego procesu dodawania plików ciężkich do repozytorium, z natychmiastowym opisem metadanymi i możliwością ustawiania godzin rozpoczęcia ładowania plików do repozytorium.

W 330. Generowanie struktur w repozytorium dla opracowywanych plików będących półproduktami i produktami (w tym również dokumenty).

W 331. Tworzenie typów dokumentów powiązanych oddzielnie dla półproduktów i produktów.

W 332. Umożliwienie tworzenia powiązań pomiędzy dokumentami opisującymi pliki ciężkie (surowe), a dokumentami półproduktów i produktów.

W 333. System musi umożliwiać opisu metadanych uwzgledniających dane przestrzenna dla konkretnych typów danych w postaci plikowej.

W 334. Repozytorium musi obsłużyć pojedyncze typy plików masowych, jak i zgrupowanie różnych typy plików.

W 335. Metryki opisujące metadane muszą odnosić się zarówno do pojedynczych plików ja i grupy plików.

W 336. System musi zapewniać pobranie metadanych z pliku EXIF.

3.2.3.2. Repozytorium dokumentów

W 337. System musi zapewniać przechowywanie rejestrów kancelaryjnych w repozytorium dokumentów.

W 338. Umożliwienie definiowania dowolnych typów dokumentów na poziomie repozytorium i ich udostępniania na poziomie portalu poprzez dynamicznie generowane (bez potrzeby dodatkowego oprogramowania formularzy) formularze elektroniczne per typ dokumentu.

W 339. Możliwość generowania wydruków dokumentów na podstawie zdefiniowanych szablonów dokumentów, z możliwością zasilenia szablonu zdefiniowanymi w typach dokumentów metadanymi.

W 340. Wersjonowanie treści pism, dokumentów.

W 341. Przechowywanie dokumentów w dowolnych formatach, a w szczególności tych wymaganych przez Rozporządzenie Prezesa Rady Ministrów z dnia 14 marca 2011 r. w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych.

W 342. Bezpośrednia edycja dokumentów MS Word i MS Excel w edytorze MS Office, to jest: umożliwienie otworzenia dokumentu zamieszczonego w repozytorium bezpośrednio w edytorze MS Office, a następnie jego bezpośrednie zapisanie jako kolejna wersja dokumentu w repozytorium.

3.2.3.3. Repozytorium aktów własnych

W 343. Umożliwienie udostępniania zaakceptowanego dokumentu we wskazanym obszarze repozytorium (np. w repozytorium aktów własnych), z nadaniem uprawnień użytkownikom.

W 344. Udostępnienie funkcjonalności opisanych dla Modułu Pracy Grupowej.

W 345. Zdefiniowanie dedykowanych dla aktów własnych typów dokumentów w repozytorium.

W 346. Udostępnianie zatwierdzonych dokumentów aktów własnych pracownikom PIG- PIB.

W 347. Repozytorium aktów własnych musi być powiązane logicznie z wzorami dokumentów, szablonami dokumentów.

3.2.3.4. Repozytorium projektowe

W 348. Umożliwienie dołączenia dokumentów i plików do teczek tematycznych, teczek projektowych.

W 349. Udostępnienie funkcjonalności opisanych dla Modułu Pracy Grupowej.

W 350. Zdefiniowanie dedykowanych dla projektów typów dokumentów w repozytorium.

W 351. Utworzenie struktury katalogowej na potrzeby realizacji przedsięwzięć/projektów/tematów/zadań.

W 352. Logiczne powiazanie dokumentów z teczkami tematycznymi grupami zadaniowymi.

3.2.4. Komponent OCR

W 353. Komponent musi umożliwiać OCR wszystkich zarejestrowanych dokumentów przez kancelarię.

W 354. Komponent musi posiadać możliwość dokonania OCR pliku na wybranym dokumencie przez użytkownika.

W 355. Komponent umożliwia zamianę zeskanowanego pliku pdf na doc.

W 356. Wykonywanie OCR na zeskanowanych dokumentach dostarczonych z posiadanych przez Zamawiającego skanerów.

W 357. Skanowanie wsadowe wielu dokumentów oznaczonych kodami kreskowymi i automatyczne dołączanie zeskanowanych obrazów dokumentów do zarejestrowanej w repozytorium metryki dokumentu na podstawie rozpoznanego narzędziami OCR kodu kreskowego (w szczególności podczas realizacji procesu odwzorowania cyfrowego).

W 358. Automatyczne wprowadzanie zeskanowanych dokumentów (przy wykorzystaniu OCR) do obiegu dokumentów.

4. Wymagania poza funkcjonalne

4.1. Użyteczność

W 359. Instrukcja wykorzystania schematu XSD.

W 360. Stosowanie systemu zastępstw, z wyraźnym oznaczeniem wykonania operacji „w zastępstwie”, w szczególności na wytworzonych dokumentach.

W 361. Rozwiązanie powinno być zbudowane zgodnie z zasadami i dobrymi praktykami obszaru UX, w szczególności musi spełniać 10 heurystyk Nielsena. Niektóre z poniższych wymagań są konsekwencją konkretnej heurystyki.

W 362. Patrz xxxx://xxxxx.xxxx.xxx.xx/xxxxx/00/000/000/000/00000.xxx W 363. Patrz xxxx://xxxxx.xxx

W 364. Rozwiązanie musi umożliwić:

W 365. Przypisanie do użytkownika indywidualnych domyślnych parametrów wykonania operacji oraz domyślnych danych podpowiadanych podczas wprowadzania.

W 366. Dostosowanie interfejsu użytkownika do indywidualnych wymagań dotyczących ergonomii pracy oraz możliwości technicznych danego stanowiska roboczego (np. wielkość liter, zestaw kolorów, wygląd tabel) w ramach możliwości oferowanych przez technologię.

W 367. Wykorzystanie skróconych ścieżek dostępu do funkcjonalności, np. kombinacji klawiszy, pól do wprowadzenia nazwy funkcjonalności.

W 368. Masowe wprowadzanie / zmianę danych za pomocą wbudowanych mechanizmów przez uprawnionych użytkowników (nie tylko administratorów).

W 369. Dynamiczne sortowanie, filtrowanie oraz sumowanie danych w raportach. W 370. Śledzenie wykonanych zmian.

W 371. System musi być wyposażone w pomoc kontekstową dotyczącą sposobu wykonania danej operacji i pomoc dotyczącą formatowania wprowadzanych pól.

W 372. Wszystkie pola wprowadzane przez użytkownika powinny być walidowane w sytuacjach, w których jest to możliwe.

W 373. System musi zapewnić dotarcie do żądanych treści jak najmniejszą ilością przejść przez formatki bądź odnośniki.

W 374. System powinien posiadać spójny system elementów sterujących (ikony, przyciski, odnośniki, itp.) oraz kolorystykę stron.

W 375. Rozwiązanie musi być w pełni zintegrowane pod kątem wyszukiwania danych – funkcjonalności wyszukiwania / filtrowania / sortowania danych, powinien umożliwiać przeszukiwanie wszystkich danych zgromadzonych w systemie (z podziałem na moduły / obszary systemu, w którym dane te zostały wprowadzone).

W 376. Powinna być zapewniona możliwość przeszukiwania danych i wyświetlania wyników wyszukiwania w postaci uporządkowanej kategoriami wyników.

W 377. Rozwiązanie musi zapewnić:

W 378. Zmianę wyglądu formatek i raportów wyświetlanych na ekranach użytkowników poprzez wprowadzenie modyfikacji na serwerze.

W 379. Przerywanie i restartowanie wykonywanych zadań czaso- i pracochłonnych (np. wyszukiwanie).

W 380. Dodawanie, ukrywanie oraz zmianę kolejności kolumn zawierających informacje prezentowane w raportach.

W 381. Realizowanie transakcji testowych bez zagrożenia i zakłócenia pracy systemu produkcyjnego.

Wizualizacja aplikacji portalu wewnętrznego

W 382. Wykonawca jest zobowiązany do dostosowania interfejsu użytkownika aplikacji tj,:

• wyglądu aplikacji (układu stron)

• kolorystyki

• czcionek

• pozostałych elementów graficznych (np. logotypów)

• układu na stronach istotnych elementów (np. nawigacji, przycisków funkcyjnych, pomocy kontekstowej)

do implementacji zastosowanej w systemie monitorowania procesów digitalizacji dokumentów w NAG PIG-PIB (opisanego w rozdziale „Otoczenie Systemu – system do monitorowania procesów digitalizacji dokumentów w NAG PIG-PIB”)

Wizualizacja aplikacji portalu zewnętrznego

W 383. Wykonawca jest zobowiązany do dostosowania interfejsu użytkownika aplikacji tj,:

• wyglądu aplikacji (układu stron)

• kolorystyki

• czcionek

• pozostałych elementów graficznych (np. logotypów)

• układu na stronach istotnych elementów (np. nawigacji, przycisków funkcyjnych, pomocy kontekstowej)

do aktualnie stosowanego wzornictwa strony internetowej xxx.xxx.xxx.xx .

4.2. Opis procesów

W poniższej tabeli przedstawiono procesy, które mają zostać objęte systemem. Procesy zostaną przeanalizowane przez Wykonawcę na etapie przygotowywania koncepcji wdrożenia, a następnie wdrożone w oparciu o dostarczony silnik procesów BPM, repozytorium dokumentów oraz portal.

Nr.	Nazwa procesu	Krótki opis procesu
1.	Zarządzanie dokumentacją	Przyjmowanie przesyłek wchodzących, obsługa składów chronologicznych/informatycznych nośników danych, wielopoziomowa dekretacja, dokumentowanie przebiegu załatwiania spraw poprzez gromadzenie przyporządkowanych do właściwego JRWA dokumentów, wielopoziomowa akceptacja, podpisywanie dokumentów, wysyłanie dokumentów do adresata wewnętrznego, wysyłanie przesyłek poza PIG-PIB. Proces uruchamiany i realizowany w module pracy grupowej widoczny z poziomu portalu formowego
2.	Zarządzanie archiwum zakładowym	Prowadzenie ewidencji archiwum zakładowego, przyjmowanie Dokumentacji do archiwum zakładowego, udostępnianie/wypożyczanie dokumentacji, brakowanie dokumentacji niearchiwalnej, przekazywanie materiałów archiwalnych do Archiwum Państwowego. Proces uruchamiany i realizowany w module pracy grupowej.
3.	Zarządzanie e-Usługami	Przyjęcie dokumentu elektronicznego lub papierowego Wypełnienie wniosku/formularza: - zgłoszenia osuwiska w trybie interwencyjnym - o informację o aktualnym stopniu wykorzystania zasobów wód podziemnych - o udostępnienie danych NAG - o udostępnienie danych PSH - o wygenerowanie georaportu Dla w/w wniosków integracja z modułem kancelarii i obiegu dokumentów, wielopoziomowa akceptacja i opiniowanie, informacja zwrotna o akceptacji bądź jej braku. Procesy uruchamiane z poziomu portalu wewnętrznego i zewnętrznego.

Pozyskiwanie/Gromadzenie danych w postaci plikowej.

Zlecenie wykonania badań terenowych przez firmę zewnętrzną.

Wykonanie badań terenowych przez pracowników PIG-PIB. Pozyskanie danych z zewnętrznych systemów, np. ISOK. Pozyskanie danych z innych instytucji np. w ramach wspólnie prowadzonych projektów naukowych.

Pozyskiwanie i gromadzenie danych wynika z potrzeby realizowanych przedsięwzięć/projektów/tematów/zadań. Opisanie danych metadanymi.

Wprowadzenie danych do repozytorium.

Wśród danych zgromadzony są zarówno dane surowe bezpośrednio z aparatury pomiarowej, lub dane przetworzone z danych surowych.

Przetwarzanie danych w postaci plikowej.

Przetwarzanie danych w postaci plikowej odbywa się przez wyspecjalizowane do tego narzędzia: MDPS Xxxxxxxx, XXXXXX, XxxXxxxx, XxxxXxx Xxx 0X, Xxxxxx, Xxxxxxxxxx, LANDMARK i inne.

Dane przetworzone mogą powstawać z jednego typu danych surowych bądź z wielu danych surowych i przetworzonych.

Pobranie z zasobu sieciowego niezbędnych danych do obróbki.

W ramach przetwarzania danych powstają zarówno mapy, przekroje, warstwy, modele numeryczne, modele 3D/4D, modele CAD, usługi shp, pdf, xls itpi inne w zależności od stosowanych narzędzi do obróbki tych danych.

CzęśćWrzucenie do zasobu sieciowego pozostałych danych przetworzonych służy do tworzenia, produktów informacyjnych w ramach.

Realizacja przetwarzania wynika z realizowanych projektów dla odbiorców zewnętrznychprzez PIG-PIB.

Katalogowanie danych przetworzonych, wraz z opisem metadanych dla konkretnych obiektów danych.

Powiązanie danych przetworzonych z danymi źródłowymi niezbędnymi do utworzenia np. modelu 3D

Powiązanie z realizowanym projektem.

Zarządzania cyklem wytwarzania półproduktów i produktów informacyjnych bazujących na plikach ciężkich.

Wymaga pobrania zasobów danych plikowych, zasobów danych z bazy, zasobów danych z innych systemów.

Obróbka danych w oprogramowaniu poza repozytorium. Utworzenie nowego źródła danych i zarchiwizowania go do repozytorium (pod warunkiem posiadania formy plikowej) Powiązanie nowego pliki z zasobami wykorzystywanymi do jego opracowania.

Opisanie metadanymi charakterystycznymi dla dane źródła danych.

4.3. Wydajność

W 384. Dostarczone przez Wykonawcę rozwiązanie musi umożliwiać:

• skalowanie wydajności,

• rekonfigurację,

• osadzanie nowych usług bez zakłócania pracy innych aplikacji, przy ewentualnym czasowym zmniejszeniu wydajności Systemu.

W 385. Dla zdefiniowanych w Rozdziale 2.2 „Architektura systemu” wymagań środowiskowych, System musi spełniać określone poniżej, minimalne wymagania w zakresie wydajności oferowanego Systemu, przy założeniu że jednocześnie pracuje w Systemie 60 użytkowników.

System powinien spełniać następujące wymagania w zakresie wydajności:

W 386. Średni czas 90% operacji otworzenia strony głównej aplikacji już po zalogowaniu się do Systemu przez użytkownika nie może być dłuższy niż 5 sekund.

W 387. Średni czas 90% transakcji wyszukiwania dokumentu określonego typu po wprowadzeniu jego pól indeksowanych jako kryterium wyszukiwania nie może być dłuższy niż 5 sekund, przy założeniu że zwracana lista wyszukiwania nie jest większa niż 100 wyników.

W 388. Średni czas 90% transakcji wyświetlenia zawartości metryki dokumentu po jego wyborze z listy nie może być dłuższy niż 4 sekundy.

W 389. Średni czas 90% transakcji zapisu metryki nowego dokumentu w Systemie po użyciu funkcji zapisującej nie może być dłuższy niż 5 sekund.

W 390. Testy wydajnościowe weryfikujące wymagania wydajnościowe będą każdorazowo wykonywana z sieci lokalnej Zamawiającego.

W 391. Wykonawca będzie ponosić odpowiedzialność za brak wydajności dostarczonego Systemu na poziomie parametrów wskazanych powyżej, z wyłączeniem przypadków, gdy niespełnienie wymagań spowodowane jest w szczególności takimi przypadkami jak: awaria elementów Systemu, działania i/lub zaniechania Zamawiającego w zakresie bieżącej administracji i utrzymywania Systemu oraz infrastruktury sprzętowej i sieciowej powiązanej z Systemem.

W 392. Wykonawca zobowiązany jest przygotować narzędzia generujące wymagane obciążenie na środowisku Zamawiającego.

4.4. Bezpieczeństwo

W 393. Rozwiązanie musi spełniać wymogi ustawowe ustawy z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (t.j. Dz.U. 2002 r. Nr 101, poz. 926 z późn. zm.) oraz aktów wykonawczych dot. ochrony danych osobowych, w szczególności Rozporządzenia Ministra Spraw Wewnętrznych i Administracji z dnia 29 kwietnia 2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych (Dz. U. Nr 100, poz. 1024).

W 394. Zamawiający będzie miał możliwość przypisywania lub ograniczania dostępu do poszczególnych funkcjonalności pojedynczym użytkownikom lub grupom za pomocą uprawnień wg modelu RBAC (Kontrola dostępu oparta na rolach).

W 395. Wykonawca utworzy jedno centralne narzędzie, z poziomu którego będzie możliwe sprawdzenie do jakich elementów (modułów) systemu i szczegółowych funkcjonalności w danym module użytkownik posiada uprawnienia oraz

sprawdzić którzy użytkownicy posiadają uprawnienia do danego elementu (modułu) systemu lub wybranej funkcjonalności w danym module.

• W momencie uruchamiania systemu przez użytkownika, system będzie identyfikował, jakie grupy uprawnień są mu przypisane. Użytkownik będzie korzystał tylko z tych funkcji, które zostały zdefiniowane jako dostępne dla niego.

• Po zalogowaniu do systemu użytkownik będzie widział tylko te elementy poszczególnych komponentów systemu, do których posiada uprawnienia.

• Po zalogowaniu do systemu użytkownik będzie widział tylko te zasoby danych i informacji, do których posiada uprawnienia.

W 396. Uprawnienia będą nadawane użytkownikom lub grupom pobranym z Active Directory.

W 397. Komunikacja z systemem uwierzytelniania, dotycząca przydzielania uprawnienie będzie odbywać się dwustronnie.

W 398. Możliwość wykonania kopii bezpieczeństwa danych, aby w wypadku awarii móc bezpiecznie odtworzyć dane.

W 399. Rozwiązanie musi posiadać skuteczne mechanizmy w zakresie zapewnienia bezpieczeństwa danych oraz sterowania uprawnieniami poszczególnych użytkowników w zakresie dostępu do danych, konkretnych ekranów i opcji.

W 400. Zapewnić przypisanie grup i pojedynczych funkcjonalności do użytkownika oraz grup użytkowników (zróżnicowany dostęp w zależności od użytkownika z podziałem na wprowadzanie, akceptację i podgląd danych).

W 401. Wszelka komunikacja w ramach Systemu wychodząca poza wydzieloną sieć Zamawiającego odbywająca się przy użyciu protokołu HTTP musi być realizowana w tunelu SSL.

W 402. Zapewniać mechanizm zarządzania transakcjami gwarantujący integralność i spójność danych.

W 403. Zapewniać zgodność z obecnie funkcjonującymi u Zamawiającego rozwiązaniami w dziedzinie bezpieczeństwa, w szczególności: gromadzenia, przetwarzania i udostępniania informacji.

W 404. Zapewniać:

• poufność – polega na zagwarantowaniu, że informacje przesyłane w systemie mogą zostać odczytane tylko przez uprawnione osoby,

• uwierzytelnienie – polega na poprawnym określeniu pochodzenia komunikatu, w tym zapewnienia autentyczności jego źródła (użytkownika),

• nienaruszalność – polega na zagwarantowaniu, aby dane przechowywane w systemie oraz informacje przesyłane mogły być modyfikowane jedynie przez upoważnione osoby; do modyfikacji zaliczamy pisanie, zmiany, zmiany stanu, kasowanie, tworzenie rekordów, przetwarzanie przesyłanych pomiędzy elementami systemu komunikatów,

• rozliczalność – polega na zapewnieniu pełnej informacji na temat wszystkich podejmowanych przez każdego z użytkowników systemu działań, związanych z modyfikacją i przeglądaniem danych; dla rekordu powinna być dostępna historia zmian, z odnotowaniem jakie elementy zostały zmienione, kiedy i przez kogo,

• kontrolę dostępu – polega na zapewnieniu, iż dostęp do zasobów systemu jest w pełni kontrolowany przez administratorów zarządzających uprawnieniami użytkowników.

W 405. Być odporne na znane metody uzyskania nieautoryzowanego dostępu, w tym:

• Ataki semantyczne na adres URL

• Ataki związane z ładowaniem plików

• Ataki typu cross-site scripting

• Ataki typu CSRF

• Podrabianie zatwierdzenia formularza

• Sfałszowanie żądania HTTP

• Ujawnienie uwierzytelnień dostępu

• Wstrzykiwanie kodu SQL

• Ujawnienie danych przechowywanych w bazie

• Kradzież cookies

• Przechwytywanie sesji

• Wstrzykiwanie sesji

• Zafiksowanie sesji

• Trawersowanie katalogów

• Wstrzykiwanie poleceń systemowych

• Ujawnianie kodu źródłowego, np. plików .inc, „template”, itp.

W 406. Zapewniać możliwość automatycznego zamykania nieaktywnych sesji użytkownika w określonym czasie.

W 407. Blokować uwierzytelnionym użytkownikom dostęp po upływie określonego w konfiguracji czasu braku aktywności użytkownika.

W 408. Zagwarantować możliwość dostępu do systemu tylko dla ograniczonego zbioru identyfikowanych użytkowników, określonych przez Zamawiającego.

W 409. System praw dostępu do treści musi być zintegrowany z Repozytorium dokumentów.

W 410. Zarządzanie strukturą organizacyjną w powiązaniu z Active Directory. W 411. Przydzielenie uprawnień dla poszczególnych pracowników.

W 412. Zapewniać integralność treści dokumentów i metadanych zabezpieczając przed wprowadzeniem zmian, z wyjątkiem zmian wynikłych z ustalonych i zatwierdzonych procedur (brakowania, przekazania materiałów archiwalnych do Archiwum Państwowego, zmiany kwalifikacji archiwalnej, wznowienie sprawy).

W 413. Grupowe dodawanie stanowisk i uprawnień.

5. Wymaganie techniczne na platformę

5.1. Wymagania ogólne

W 414. Oferowane środowisko wykonawcze musi posiadać jednolitą platformę zarządzania, umożliwiającą zarządzanie wszystkimi komponentami środowiska wykonawczego z poziomu jednej konsoli dostępnej przez przeglądarkę internetową.

W 415. Oferowana aplikacja musi spełniać następujące wymagania:

• Nie dopuszcza się, aby funkcje aplikacji, związane z zarządzaniem treścią, odbywały się z pominięciem mechanizmów repozytorium. Oznacza to, że

oferowane oprogramowanie, w zakresie zarządzania dokumentami/plikami - w tym w szczególności definiowania metadanych, operacji rejestrowania i wyrejestrowania dokumentu oraz wersjonowania dokumentu - musi korzystać tylko i wyłącznie z usług oferowanych przez repozytorium.

• Wszystkie elementy oferowanego środowiska wykonawczego muszą być wykorzystywane przez oferowaną aplikację. Oznacza to, że oferowana aplikacja musi:

o Pracować pod kontrolą oferowanego serwera aplikacyjnego platformy (być aplikacją JEE),

o Xxxxxxxxx z dokumentów za pomocą usług oferowanego repozytorium,

o Wykorzystywać usługi sieciowe (Web Services) za pomocą oferowanej szyny usługowej platformy,

o Realizować procesy biznesowe za pomocą usług oferowanego silnika procesowego platformy;

W 416. Oferowane komponenty/moduły - portal, serwer aplikacyjny, szyna usługowa, silnik procesów BPM, repozytorium danych - nie mogą być wersją typu ‘Community’, tzn. muszą posiadać wykupione wsparcie (support, maintenance) producenta.

W 417. Zamawiający wskazuje technologię Java EE jako wymaganą przy tworzeniu rozwiązania. Chcąc uniknąć uzależnienia się od jednej technologii serwerowej i jednego systemu operacyjnego, Zamawiający wskazuje technologię Java EE ze względu na fakt, że gwarantuje ona otwartość w zakresie stosowania różnych platform sprzętowych, zarówno x86/x64 jak też RISC, co z kolei pozwala na stosowanie różnych platform systemów operacyjnych.

5.2. Wymagania na repozytorium platform

W 418. Oferowane rozwiązanie repozytorium dokumentów w zakresie architektury musi spełniać następujące wymagania:

• Moduły repozytorium dokumentów muszą być zgodne z technologią JEE i możliwe do uruchomienia w ramach wyspecyfikowanej platformy aplikacyjnej.

• Moduły repozytorium dokumentów muszą mieć możliwość działania w oparciu

o systemy operacyjne Windows, Linux.

W 419. Repozytorium musi zapewniać mechanizm rejestrowania i wyrejestrowania dokumentów/plików do edycji (check-in/check-out). Wyrejestrowanie do edycji uniemożliwia zmianę dokumentu przez innego użytkownika. Możliwy jest jednak podgląd, bądź pobranie kopii oryginalnej wersji dokumentu.

W 420. Repozytorium musi umożliwiać tworzenie dyskusji (komentarzy) powiązanych z danym plikiem.

W 421. Repozytorium musi umożliwiać przechowywanie zarówno rejestrowanych dokumentów, jak i innych, nie rejestrowanych treści.

W 422. Repozytorium musi umożliwiać dołączanie załączników do dokumentów.

W 423. Repozytorium inicjuje automatyczny, elektroniczny obieg dokumentów i procesów.

W 424. Repozytorium musi inicjować automatyczny przepływ dokumentów według zdefiniowanych wcześniej ścieżek.

W 425. Repozytorium musi umożliwiać tworzenie ad-hoc ścieżki obiegu dla danego dokumentu.

W 426. Repozytorium pozwala na definiowanie wielu etapów obiegu dokumentów. Na każdym etapie musi być możliwe zdefiniowanie wielu recenzentów.

W 427. Repozytorium musi umożliwiać automatyczne uruchamianie procesu dla dokumentów/plików dodanych do systemu, na podstawie zdefiniowanych dla nich metadanych.

W 428. Repozytorium musi umożliwiać wyszukiwanie poprzez pełnotekstowe przeszukiwanie treści dokumentów, według określonych parametrów (metadanych) dokumentu, oraz przez kombinację obu metod.

W 429. Repozytorium musi umożliwiać wyszukiwanie dokumentu w wielu fizycznych repozytoriach.

W 430. Repozytorium musi umożliwiać pozycjonowanie wyników wyszukiwania w zależności od popularności dokumentów/plików.

W 431. Repozytorium musi zawierać mechanizm opisywania dokumentów plików za pomocą metadanych.

W 432. Repozytorium musi umożliwiać definiowanie zestawów metadanych dla poszczególnych typów dokumentów/plików.

W 433. Repozytorium musi umożliwiać definiowanie i dodawanie własnych metadanych.

W 434. Repozytorium musi umożliwiać automatyczne nadawanie zestawu metadanych w zależności od miejsca przechowywania dokumentu.

W 435. Repozytorium musi posiadać mechanizm subskrypcji - powiadamiania e¬mail o zmianach danego dokumentu/pliku.

W 436. Repozytorium musi minimalnie umożliwiać automatyczną konwersję dokumentów MS Word, Excel, PowerPoint, Project, Visio, RTF, ASCII, do postaci umożliwiającej wyświetlenie w przeglądarce internetowej (HTML/XML i PDF).

W 437. Repozytorium musi umożliwiać automatyczne konwersje formatów graficznych oraz przechowywanie różnych wersji jednego dokumentu graficznego – np. system przechowuje oryginalne zdjęcie w wysokiej jakości, oraz jego automatycznie skonwertowane wersje do umieszczania w publikacjach drukowanych, stronach internetowych, wyświetlania w urządzeniach przenośnych, etc.

W 438. Repozytorium musi pozwalać na tworzenie spraw tematycznych z dokumentami/plikami. Jeden dokument może być przypisany do wielu spraw.

W 439. Repozytorium musi zapewniać to, aby sprawy tematyczne (abstrakcyjne obiekty w repozytorium zawierające fizyczne obiekty w repozytorium) mogły być opisane własnym zestawem metadanych.

W 440. Repozytorium musi zapewniać to, aby sprawy tematyczne mogły zawierać dowolną liczbę dokumentów dowolnego typu opisanych dowolnymi metadanymi.

W 441. Repozytorium musi pozwalać na logiczne łączenie dokumentów. System musi umożliwiać przejście z poziomu widoku dokumentu do innych, połączonych dokumentów.

W 442. Repozytorium musi umożliwiać przechowywanie dowolnych typów plików nie zależnie od tego w jakim formacie występuje.

W 443. Repozytorium musi umożliwiać przechowywanie dokumentów w wielu fizycznych repozytoriach różnego typu (w tym musi posiadać wsparcie dla takich jak

systemy plików, bazy danych, inne systemy składowania treści). Konieczna jest możliwość automatycznego przypisania do repozytorium w zależności od metadanych.

W 444. Repozytorium musi umożliwiać tworzenie formularzy dynamicznych (np. wnioski urlopowe, zapotrzebowanie na samochód). Wypełnienie formularza musi wiązać się z rejestracją nowego dokumentu w repozytorium.

W 445. Repozytorium musi umożliwiać wprowadzanie przez użytkowników komentarzy do dokumentu, bez konieczności nanoszenia ich bezpośrednio na dokumencie (bez konieczności tworzenia kolejnej wersji dokumentu w repozytorium).

W 446. Repozytorium musi zapewniać centralne zarządzanie wieloma repozytoriami i archiwami, zarówno elektronicznymi jak i tradycyjnymi.

W 447. Repozytorium musi zapewniać funkcjonowanie rejestrów kancelaryjnych.

W 448. Repozytorium musi zapewnić obsługę standardu Model Requirements for the Management of Electronic Records (MoReq).

W 449. Repozytorium musi umożliwiać wprowadzanie polityki przechowywania treści (czas przechowywania dokumentu, sposób archiwizacji, metoda usuwania, uruchomienie procesu decyzji co do dalszego trybu życia dokumentu, etc.) – zarówno zarejestrowanych (rekordów) jak i niezarejestrowanych.

W 450. Repozytorium musi umożliwiać automatyzację zadań związanych z polityką przechowywania – x.xx. przenoszenie do archiwów i pomiędzy nimi, usuwanie po określonym czasie przechowywania.

W 451. Repozytorium musi zapewnić możliwość uzyskania potwierdzenia usunięcia danego dokumentu.

W 452. Repozytorium musi zapewnić możliwość wprowadzania automatycznych polityk zarządzania treścią.

W 453. Repozytorium musi zapewniać zgodność z obowiązującym prawodawstwem odnośnie przechowywania dokumentów.

W 454. Repozytorium musi być wyposażone w mechanizm powiadamiania odpowiednich osób o zdarzeniach w obiegu dokumentów/plików.

W 455. Repozytorium musi powiadamiać kolejne osoby o konieczności podjęcia działań w systemie obiegu dokumentów. Powiadomienie musi umożliwiać bezpośrednie przejście do widoku dokumentu wymagającego działania.

W 456. Repozytorium musi informować użytkowników o zbliżającym się oraz przekroczonym terminie realizacji konkretnego zadania.

W 457. Repozytorium musi zapewniać możliwość definiowania ograniczeń czasowych dla poszczególnych kroków, jak i dla całej ścieżki obiegu dokumentów/plików

W 458. Repozytorium musi umożliwiać automatyczną eskalację zadań w przypadku przeterminowania.

W 459. Repozytorium musi pozwalać na rejestrowanie dokumentów/plików oraz teczek tematycznych.

W 460. Repozytorium musi umożliwiać automatyczne uruchamianie w zewnętrznym silniku procesów biznesowych procesu obiegu dla dokumentów/plików dodanych do systemu, na podstawie zdefiniowanych dla nich metadanych.

W 461. Repozytorium musi umożliwiać wywołanie zewnętrznych aplikacji (trigger) na podstawie zdarzeń powstałych w repozytorium, w tym: dodanie nowego

dokumentu, pojawienie się nowej wersji dokumentu, określenie wartości metadanych dla dokumentu, utworzenie lub modyfikacja teczki tematycznej.

W 462. Repozytorium musi obsługiwać standard JSR170 (Java Content Repository). Oznacza to możliwość obsługi portalu wewnętrznego lub zewnętrznego zgodnego z tym standardem.

W 463. Repozytorium musi posiadać dostępne API do wywoływania funkcji repozytorium (zarządzanie dokumentami, bezpieczeństwo, audyt) z wykorzystaniem usług typu WebServices.

W 464. Repozytorium musi zapewniać prowadzenie dziennika zdarzeń. Wszystkie operacje dotyczące działań na zawartości repozytorium muszą być zapisywane w systemie w sposób umożliwiający określenie kolejności działań i wykonawców czynności.

W 465. Repozytorium musi umożliwiać rejestrowanie wszelkich operacji wykonywanych na dokumentach/plikach w systemie, wraz przebytymi ścieżkami akceptacji.

W 466. W szczególności Repozytorium musi umożliwiać raportowanie działań podejmowanych przez danego użytkownika, bądź w danej lokalizacji (grupie, jednostce, dziale, kancelarii)

W 467. Repozytorium musi umożliwiać w każdej chwili utworzenie raportu o prawach dostępu użytkowników.

W 468. Wszystkie wygenerowane raporty muszą mieć możliwość trafienia jako dokumenty do repozytorium.

W 469. Repozytorium dokumentów musi zapewnić jednolity panel administracyjny dostępny za pomocą przeglądarki WWW.

W 470. Repozytorium musi zapewniać mechanizm kontroli uprawnień i zabezpieczenia dostępu do dokumentów i funkcji systemu.

W 471. System zabezpieczeń musi być oparty o mechanizm ról, pozwalający określić możliwość wykonania konkretnych funkcji w systemie.

W 472. Repozytorium musi mieć możliwość budowania hierarchicznego modelu uprawnień.

W 473. Repozytorium musi zapewniać możliwość określenia dokładnych praw na poziomie pojedynczego użytkownika, pojedynczego dokumentu oraz pojedynczej funkcji systemu.

W 474. Repozytorium musi zezwalać na delegowanie części uprawnień administracyjnych do administratorów merytorycznych/lokalnych.

W 475. Model bezpieczeństwa implementowany w repozytorium dokumentów musi być jednolity bez względu na sposób komunikacji z repozytorium (sposób dostępu do repozytorium), w tym: dostęp z poziomu systemów operacyjnych, z poziomu aplikacji WWW oraz z poziomu API dostępnego w rozwiązaniu.

W 476. Repozytorium musi pozwalać na integrację z serwerami katalogowymi zgodnymi ze standardem LDAP oraz Microsoft Active Directory na poziomie użytkowników i grup. Zmiany w katalogu użytkowników powinny być natychmiastowo adoptowane przez repozytorium.

W 477. Repozytorium musi pozwalać na definiowanie grup bezpieczeństwa dla dokumentów/plików. Dany dokument/plik może należeć jedynie do jednej grupy bezpieczeństwa.

W 478. Repozytorium musi pozwalać na integrację logowania z logowaniem domenowym.

W 479. Repozytorium musi zapewnić niezmienność zarejestrowanych dokumentów/plików w czasie całego czasu ich życia.

W 480. Repozytorium musi zapewniać możliwość blokowania dokumentów/plików na potrzeby kontroli, audytu oraz postępowań prawnych.

W 481. Repozytorium musi zapewniać dostęp do dokumentów/plików za pomocą standardowych narzędzi systemów wykorzystywanych przez Zamawiającego (Windows Explorer).

W 482. Repozytorium musi zapewniać funkcjonalność dostępu do repozytorium (check In dokumentu, check out dokumentu, otwarcie kopii dokumentu, skopiowanie na lokalną stację roboczą) przez uprawnionych użytkowników przy pomocy techniki przeciągnij i upuść (ang. Drag and Drop).

W 483. Repozytorium musi być wyposażone w moduł umożliwiający bezpośredni dostęp do repozytorium dokumentów z aplikacji pakietu MS Office i MS Outlook.

W 484. Repozytorium musi umożliwiać dostęp do dokumentów za pomocą przeglądarki internetowej.

W 485. Interfejs webowy musi umożliwiać personalizację i dostosowanie do preferencji użytkownika. Musi pozwalać na umieszczanie x.xx. zachowanych wyszukiwań, własnych odnośników, linków do subskrybowanych dokumentów, najczęściej wykorzystywanych funkcji, etc.

W 486. Repozytorium musi umożliwiać budowę Platformy wymiany informacji i bazy dokumentów/plików.

W 487. Repozytorium musi umożliwiać budowanie serwisów internetowych, tj.: wewnętrznych i zewnętrznych portali informacyjnych, baz wiedzy, bazy plików oraz baz dokumentów w taki sposób, aby nie wymagało to od użytkownika zaawansowanej wiedzy technicznej (przy pomocy graficznych edytorów dostępnych przez przeglądarkę).

W 488. Repozytorium musi udostępniać narzędzie do budowy serwisów internetowych.

W 489. Repozytorium musi umożliwiać wielokrotne wykorzystywanie tych samych komponentów (fragmentów nawigacyjnych, menu, statycznych treści) do budowy wielu serwisów.

W 490. Repozytorium musi umożliwiać publikowanie w serwisach dokumentów przechowywanych w Repozytorium. Jeden dokument może być wykorzystany w wielu serwisach.

W 491. Repozytorium musi umożliwiać publikację treści na stronach WWW, pobieranych bezpośrednio z dokumentów MS Office, nadając im zdefiniowany, jednolity dla danej części serwisu styl i format.

W 492. Repozytorium musi umożliwiać edycję treści w serwisie, bezpośrednio na stronie internetowej, za pomocą edytora WYSIWYG.

W 493. Repozytorium musi umożliwiać wykorzystanie zintegrowanego obiegu dokumentów do akceptacji treści publikowanych w serwisach.

W 494. Repozytorium musi umożliwiać automatyczną aktualizację w serwisach treści, opartych na dokumentach z repozytorium, w momencie pojawienia się nowej wersji danego dokumentu.

W 495. System praw dostępu do treści musi być zintegrowany z Repozytorium dokumentów.

5.3. Wymagania na serwer aplikacji platformy

W 496. Wsparcie dla pełnej implementacji Java EE w wersji 7.

W 497. Wsparcie i certyfikacja dla Java (JRE) w wersji 8.0 lub nowszej. Wsparcie producenta w zakresie oprogramowania Java (JRE) oraz serwera aplikacji.

W 498. Zarządzanie serwerem aplikacyjnym poprzez konsolę WWW oraz wsparcie dla klientów JMX i REST.

W 499. Możliwość przechowywania logów transakcyjnych serwera aplikacyjnego w bazie danych.

W 500. Wsparcie dla standardów Java:

• Java API for JSON Processing (JSR-353) w wersji 1.0

• Java API for XML-Based Web Services (JAX-WS) w wersjach 2.2, 2.1, 2.0

• Java API for RESTful Web Services (JAX-RS) w wersji 2.0

• Java API for WebSocket w wersji 1.1

• Java EE EJB w wersjach 3.2, 3.1, 3.0, 2.1, 2.0, 1.1

• Java EE JMS w wersjach 2.0, 1.1, 1.0.2b

• Java EE Servlet w wersjach 3.1, 3.0, 2.5, 2.4, 2.3, 2.2

• Java Transaction API w wersji 1.2

• JAX-B w wersjach 2.2, 2.1, 2.0

• JAX-P w wersjach 1.3, 1.2, 1.1

• JAX-R w wersji 1.0

• JAX-RPC w wersji 1.1

• JMX w wersji 2.0

• JPA w wersji 2.1, 2.0, 1.0

• SOAP Attachments for Java (SAAJ) w wersji 1.3, 1.2

• Streaming API for XML (StAX) w wersji 1.0. W 501. Wsparcie dla innych standardów:

• X.509 w wersji v3

• LDAP w wersji v3

• TLS w wersji v1.1, v1.2

• SNMP w wersjach XXXXx0, XXXXx0, XXXXx0.

W 502. Obsługa mechanizmów autoryzacji i mapowania ról przy użyciu standardu XACML 2.0.

W 503. Wbudowana możliwość klastrowania połączeń JDBC.

W 504. Wbudowana możliwość klastrowania JMS (w tym automatyczne przełączanie klientów JMS w momencie failover serwerów JMS).

W 505. Możliwość klastrowania obiektów typu singelton w aplikacjach.

W 506. Wbudowana obsługa zaawansowanych mechanizmów kolejkowych (JMS): grupowanie komunikatów przesyłanych do JMS z gwarancją zachowania kolejności ich przetworzenia (konsumpcji) wynikającą z kolejności ich utworzenia (produkcji).

W 507. Wbudowana możliwość konfiguracji ochrony serwerów aplikacyjnych (i aplikacji) przed przeciążeniem. Dla przykładu: jeśli liczba żądań do serwera/aplikacji jest zbyt duża, serwer przekieruje nowe żądania do innych instancji w klastrze.

W 508. Automatyczny restart serwera i/lub aplikacji w sytuacji ich zawieszenia (braku odpowiedzi), pojawienia się błędów o braku pamięci lub zbyt długiego wykonywania się wątków (stuck threads).

W 509. Możliwość rozdziału ruchu (protokołów) na różne interfejsy sieciowe (lub adresy IP). Np. możliwość rozdzielenia ruchu administracyjny/monitoringu od ruchu aplikacyjnego do ruchu związanego z funkcjonowaniem klastra (replikacja sesji)

– dane związane z tymi funkcjami mogą być przesyłane poprzez inne karty sieciowe/podsieci, itp.

W 510. Możliwość automatycznego i ręcznego restartu (migracji) instancji serwerów aplikacyjnych na innych fizycznych maszynach w razie awarii, wraz z przeniesieniem istotnych dla przetwarzania danych (np. zawartość kolejek JMS, logi transakcji rozproszonych JTA). Automatyczna rekonfiguracja serwerów aplikacyjnych po restarcie (zmiana adresu IP, itp.).

W 511. Wprowadzanie zmian w konfiguracji środowiska serwerów aplikacyjnych odbywa się w sposób transakcyjny (albo wszystkie zmiany zostaną poprawnie wprowadzone albo żadna zmiana nie będzie wprowadzona).

W 512. Możliwość automatycznego tworzenia skryptów konfiguracyjnych (rejestrowanie wykonywanych zmian, a następnie ich zapisywanie do pliku, tak, aby później taki plik uruchomić w postaci skryptu).

W 513. Wbudowany mechanizm automatycznej naprawy transakcji (transaction recovery) podczas restartu serwera aplikacyjnego.

W 514. Wbudowany moduł do diagnostyki pracy serwera aplikacyjnego i uruchomionych w nim aplikacji. Możliwość dynamicznego dodawania poprzez konfigurację własnego kodu diagnostycznego do określonych miejsc w aplikacji i jej komponentach.

W 515. Wbudowane wsparcie dla współdzielenia kodu (np. bibliotek) pomiędzy wieloma aplikacjami (Web, EJB, Web services). Biblioteki (JAR, WAR, EAR, EJB) są instalowane w serwerze aplikacyjnym jednokrotnie i wiele aplikacji może z nich skorzystać. Możliwość zainstalowania wielu wersji bibliotek równocześnie.

W 516. Możliwość konfiguracji, która wersja biblioteki będzie wykorzystywana przez aplikację. Konfiguracja odbywa się w sposób deklaratywny (za pomocą deployment deskryptor’ów) – nie poprzez kopiowanie kodu bibliotek do aplikacji. Przykład – wiele implementacji JSF działających równocześnie w serwerze aplikacyjnym.

W 517. Możliwość przechowywania istotnych informacji dotyczących sesji użytkownika (w tym sesja http, konteksty usług typu Servlet oraz konteksty usług typu Session EJB) w zewnętrznej pamięci cache poza głównym procesem maszyny wirtualnej Java. Oprogramowanie umożliwia mechanizmy klastrowania aplikacji w powyższy sposób, czyli z wykorzystaniem cache’a zewnętrznego.

W 518. Wsparcie dla replikacji sesji w pamięci pomiędzy wieloma instancjami serwerów aplikacyjnych uruchomionych na wielu fizycznych maszynach. Replikacja sesji zapewnia wysoką wydajność, w tym możliwość replikowania sesji w trybie primary-secondary (czyli zarządzanie maksymalnie dwiema kopiami sesji użytkownika w klastrze), replikowanie sesji z użyciem trybów IP unicast i multicast, a także wspiera replikację sesji pomiędzy klastrami serwerów aplikacyjnych (intra-cluster) poprzez sieci LAN/MAN/WAN.

W 519. Wbudowana obsługa Logging Last Resource - optymalizacji transakcji rozproszonych (XA).

W 520. Możliwość realizacji odpowiedniego poziomu bezpieczeństwa w zakresie:

• uwierzytelniania

• kontroli dostępu

• zarządzania użytkownikami, grupami i rolami

• tworzenia, przechowywania i walidacji certyfikatów, haseł, kluczy

• audytowania zdarzeń bezpieczeństwa

• wsparcia dla pojedynczego logowania SSO.

W 521. Dostępność mechanizmów uwierzytelniania i szyfrowania usług takich jak: użytkownik/hasło, passphrase, weryfikacja hostów, brak uwierzytelniania, tunelowanie wywołań SSL, certyfikaty X.509

W 522. Wbudowana, dostępna poprzez konfigurację, integracja z katalogami użytkowników, grup i ról – LDAP, Active Directory, bazy danych, Windows XX, X.000, SAML.

W 523. Możliwość jednoczesnego podłączenia wielu usług katalogowych, w tym różnego typu (np. równocześnie LDAP, Active Directory, bazy danych, Web service, systemy autentykacji i autoryzacji firm trzecich.)

W 524. Opisana w dokumentacji (wraz z przykładami) możliwość tworzenia własnych implementacji usług security: uwierzytelnienia, autoryzacji, mapowania ról, mapowania uwierzytelnień, baz danych kluczy/certyfikatów, walidacji poprawności kluczy/certyfikatów (CLV/CLR), audytowania, itd.

5.4. Wymagania na infrastrukturę integracyjną (szyna usługowa)

W 525. Oprogramowanie działa na serwerze aplikacji JEE (Java Enterprise Edition).

W 526. Oprogramowanie zawiera następujące, preintegrowane komponenty realizujące określone funkcje w środowisku integracyjnym:

• xxxxx xxxxxxxx (ESB) - realizująca lekką, bezstanową mediację pomiędzy dostawcami i konsumentami usług

• silnik procesów integracyjnych (BPEL) - odpowiedzialny za orkiestrację usług, czyli komponowanie ich w logicznie ułożone sekwencje lub strumienie wywołań, realizujące złożone transakcje biznesowe

• monitoring biznesowy - Business Activity Monitoring (BAM) - klasa rozwiązań do monitorowania biznesowego w czasie rzeczywistym. Odpowiada za składowanie danych pierwotnych, obróbkę danych i generowanie obiektów reprezentujących wskaźniki (KPI, SLA), budowanie reprezentacji graficznej i prezentację zdefiniowanych raportów

• zarządzanie dostępem i bezpieczeństwem usług - moduł realizujący koncepcję polityk, definiujących sposób działania lub dostępność usługi, odpowiada za centralne zarządzanie, monitorowanie i egzekucję polityk przypisanych do interfejsów usług sieciowych

• silnik reguł biznesowych - pozwalający wyekstrahować logikę biznesową z poziomu usług lub procesów do dedykowanego repozytorium

• silnik przetwarzania zdarzeń (rozwiązanie klasy Complex Event Processing) - środowisko do budowy wysokowydajnych aplikacji zdarzeniowych, czyli rozwiązań analizujących szybkozmienny strumień informacji (zdarzeń) i wykrywających w czasie zbliżonym do rzeczywistego sytuacje opisane przez projektanta odpowiednim zbiorem reguł

• zintegrowane środowisko programistyczne – narzędzie umożliwiające definiowanie, implementację, testowanie, debug i wdrażanie wytworzonych usług, procesów i aplikacji na środowisko wykonawcze

• adaptery – zestaw komponentów pozwalających komunikować się w określonym protokole lub standardzie.

W 527. Oprogramowanie posiada wbudowane mechanizmy klastrowania krytycznych elementów w celu zapewnienia wysokiej dostępności rozwiązania.

W 528. Oprogramowanie posiada mechanizmy load-balancing’u umożliwiające dystrybucję ruchu na wiele węzłów klastra (równoważenie obciążenia).

W 529. Oprogramowanie umożliwia skalowanie, rekonfigurację oraz osadzanie nowych usług bez zakłócania pracy innych aplikacji czy realizowanych operacji biznesowych.

W 530. Oprogramowanie umożliwia skalowanie pionowe (maszyny wieloprocesorowe) oraz poziome (farmy serwerów). W szczególnościw przypadku skalowania poziomego, rozbudowa farmy o kolejne węzły nie wymaga wyłączenia i reinstalacji pracujących serwerów.

W 531. Oprogramowanie zawiera wbudowane wsparcie dla buforowania odpowiedzi otrzymanych z zewnętrznych systemów.

W 532. Oprogramowanie zawiera wbudowany system kolejkowy na potrzeby komunikacji asynchronicznej.

W 533. Oprogramowanie jest wyposażone w narzędzia do monitorowania i zarządzania wytworzonym oprogramowaniem.

W 534. Oprogramowanie umożliwia zarządzanie i monitorowanie całego środowiska (w szczególności komponentów: ESB, silnika procesów) z jednej konsoli administracyjnej

W 535. Konsola administracyjna umożliwia jednolity dostęp do pełnego katalogu usług i procesów uruchomionych na poszczególnych komponentach (ESB, silnik procesów integracyjnych).

W 536. Oprogramowanie posiada konsolę dostępną z poziomu przeglądarki internetowej, pozwalającą na zarządzanie środowiskiem oraz parametrami poszczególnych usług i procesów.

W 537. Oprogramowanie posiada model uprawnień oparty na predefiniowanych rolach pozwalających rozgraniczyć różne grupy użytkowników operujących na środowisku wykonawczym. Istnieje możliwość integracji z istniejącym katalogiem użytkowników działającym w oparciu o protokół LDAP.

W 538. Oprogramowanie umożliwia agregowanie metryk ilościowych i jakościowych usług i procesów (oraz ich składowych) oraz ich prezentację w konsoli administracyjnej.

W 539. Oprogramowanie udostępnia mechanizmy definiowania SLA dla poszczególnych usług oraz alertowania w przypadku przekroczenia SLA.

W 540. Oprogramowanie umożliwia ograniczenie wywołań usług, ochronę wydajności adapterów oraz zajętości kolejek.

W 541. Oprogramowanie umożliwia instalowanie wytworzonych usług i procesów na

środowisku wykonawczym za pomocą:

• środowiska deweloperskiego (IDE)

• konsoli administracyjnej dostępnej z przeglądarki

• skryptów

• API.

W 542. Oprogramowanie posiada Java API pozwalające na:

• aktualizację konfiguracji zasobów zdefiniowanych na środowisku

• dostosowanie środowiska (zmienne środowiskowe, referencje)

• monitoring i zarządzanie zasobami

• eksport/import zasobów, instalację zasobów na środowisku uruchomieniowym.

W 543. Oprogramowanie umożliwia dostęp do statystyk poprzez JMX Monitoring API.

W 544. Oprogramowanie umożliwia zmianę wielkości puli wątków (per usługa) obsługujących przychodzące synchroniczne żądania http.

W 545. Oprogramowanie posiada graficzne środowisko do modelowania usług i procesów integracyjnych, z możliwością komponowania usług/procesów z gotowych elementów (drag&drop) i deklaratywną konfigurację tych elementów.

W 546. Oprogramowanie posiada kreatory wspierające programistę w konfiguracji poszczególnych kroków procesu integracyjnego.

W 547. Oprogramowanie posiada graficzne komponenty do modelowania danych (np. schematów XSD) oraz definiowania transformacji danych (np. transformat XQuery i XSLT).

W 548. Oprogramowanie posiada graficzny komponent do modelowania reguł biznesowych, sterujących procesem integracyjnym. Komponent umożliwia definiowanie reguł w postaci wyrażeń logicznych oraz tabel decyzyjnych.

W 549. Środowisko programistyczne posiada mechanizm konfiguracyjnej definicji metryk, automatycznie przekazywanych do centralnego repozytorium danych monitorowanych.

W 550. Środowisko deweloperskie posiada mechanizm bezpośredniej instalacji zbudowanych usług i procesów na środowisko wykonawcze.

W 551. Oprogramowanie dla warstwy usług posiada możliwość rekonfiguracji i uruchomienia usługi na środowisku wykonawczym z poziomu przeglądarki internetowej (aplikacja web).

W 552. Oprogramowanie udostępnia narzędzia do testowania wytworzonych usług, procesów, logiki integracyjnej oraz transformat komunikatów.

W 553. Oprogramowanie posiada narzędzie do debugowania logiki integracyjnej usług i procesów.

W 554. Oprogramowanie umożliwia budowanie projektów integracyjnych w oparciu o standard SCA (Service Component Architecture).

W 555. Oprogramowanie w ramach kompozytów SCA umożliwia walidację, filtrowanie i transformację komunikatów przychodzących, a następnie przekierowanie ich do odpowiedniego procesu integracyjnego lub usługi.

W 556. Oprogramowanie umożliwia orkiestrację usług w postaci procesów integracyjnych zgodnych ze standardem WS-BPEL 2.0.

W 557. Oprogramowanie umożliwia ekspozycję procesu integracyjnego BPEL w postaci usługi.

W 558. Oprogramowanie umożliwia wzbudzenie procesu integracyjnego BPEL zgodnie ze zdefiniowanym harmonogramem.

W 559. Oprogramowanie umożliwia natywne wywołanie kodu Java umieszczonego w przepływie procesu integracyjnego BPEL.

W 560. Oprogramowanie umożliwia obsługę warstwy danych zgodnie z koncepcją Service Data Objects (SDO).

W 561. Oprogramowanie umożliwia wywoływanie usług zewnętrznych w sposób synchroniczny oraz asynchroniczny.

W 562. Oprogramowanie umożliwia realizację scenariuszy integracyjnych zarówno w modelu synchronicznym, jak i asynchronicznym, a także łączenie tych modeli.

W 563. Oprogramowanie posiada wbudowaną funkcjonalność definiowania logiki biznesowej (sterującej przepływem w procesie BPEL) poprzez reguły biznesowe.

W 564. Silnik reguł biznesowych jest zgodny ze standardem JSR-94.

W 565. Oprogramowanie umożliwia definiowanie ścieżek obsługi wyjątków (systemowych, własnych wyjątków oraz obsługę zbiorczą).

W 566. Oprogramowanie umożliwia definiowanie transakcji kompensacyjnych (wykonanie operacji odwrotnych, w przypadku wystąpienia błędu w procesie wchodzącym w interakcje z systemami nie obsługującymi transakcji globalnych).

W 567. Oprogramowanie umożliwia definiowanie zadań interaktywnych w ramach procesów integracyjnych (np. obsługa błędów przez administratora). Zapewnione jest środowisko dostępowego do obsługi wygenerowanych zadań.

W 568. Oprogramowanie umożliwia wersjonowanie procesów integracyjnych BPEL, z możliwością koegzystencji różnych wersji procesów na środowisku wykonawczym.

W 569. Oprogramowanie umożliwia monitorowanie stanów i danych w procesach integracyjnych BPEL, z możliwością automatycznego przekazywania informacji z poziomu procesu do centralnego repozytorium danych monitorowanych.

W 570. Oprogramowanie wspiera następujące standardy:

• WSDL 1.1

• SOAP 1.1 and 1.2

• SOAP with Attachments (SwA)

• SOAP Message Transmission Optimization Mechanism (MTOM) with XML- binary Optimized Packaging (XOP)

• WS-ReliableMessaging 1.0, 1.1, and 1.2

• WS-Addressing 1.0

• WS-AT 1.0, 1.1, and 1.2

• XACML 2.0

• WS-Inspection

• Web Services Interoperability Basic Profile (WS-I BP) 1.1

• Web Services Interoperability Basic Security Profile (WS-I BSP) 1.0.

W 571. Oprogramowanie zapewnia pełne wsparcie obsługi dokumentów XML, w tym:

• tworzenia i parsowania komunikatów XML,

• walidacji komunikatów na podstawie definicji XMLSchema,

• obsługi dużych dokumentów XML (do 100MB),

• transformacji komunikatów – dokument XML na inny dokument XML oraz pomiędzy dokumentem XML i innym formatem (w obie strony).

W 572. Oprogramowanie umożliwia transformację komunikatów za pomocą języka XQuery 1.0.

W 573. Oprogramowanie umożliwia transformację komunikatów za pomocą języka XSLT 1.0.

W 574. Oprogramowanie umożliwia używanie własnych funkcji XPath.

W 575. Oprogramowanie umożliwia wywołanie kodu Java z poziomu logiki integracyjnej.

W 576. Oprogramowanie posiada funkcjonalność translacji protokołów pozwalającą na podłączanie i komunikowanie usług posiadających różne protokoły komunikacyjne.

W 577. Oprogramowanie umożliwia wykorzystanie dowolnej kombinacji obsługiwanych protokołów w ramach usługi.

W 578. Oprogramowanie posiada adapter bazodanowy, umożliwiający:

• wykonywanie zapytań na tabelach/widokach,

• wywoływanie funkcji i procedur bazodanowych,

• okresowe odpytywanie bazy danych o nowe lub zmienione rekordy,

• wspierający XA,

certyfikowany x.xx. z następującymi bazami danych:

• Oracle Database

• MS SQL

• IBM DB2

W 579. Oprogramowanie posiada adapter Web Service pozwalający na komunikację SOAP po HTTP/HTTPS.

W 580. Oprogramowanie posiada adaptery kolejkowe umożliwiające komunikację z następującymi systemami kolejkowymi:

• JMS (Weblogic JMS, Tibco EMS, IBM Websphere MQSeries, Active MQ)

• Oracle AQ

• MSMQ.

W 581. Oprogramowanie posiada adaptery plikowe pozwalające na:

• operacje w systemie plików (read/write, listing)

• komunikację z serwerem FTP/FTPS/SFTP.

W 582. Oprogramowanie posiada adapter umożliwiający komunikację:

• e-mail (SMTP, POP3, IMAP)

• sms

• komunikator (XMPP).

W 583. Oprogramowanie posiada adapter umożliwiający wywołanie usługi w oparciu o interfejsy EJB (2.1, 3.0).

W 584. Oprogramowanie posiada adapter do usług katalogowych (LDAP).

W 585. Oprogramowanie zawiera wbudowane wsparcie dla budowania usług w modelu REST, w szczególności:

• obsługę komunikatów JSON oraz XML

• obsługę argumentów żądań, przekazywanych jako parametry w URL

• konfigurator do budowy interfejsów REST dostępny w środowisku programistycznym

• kreator interfejsu REST dla usług/procesów działających w modelu SOAP. W 586. Warstwa komunikacyjna oprogramowania umożliwia zachowanie:

• integralności,

• niezaprzeczalności,

• poufności;

• autentyczności komunikacji.

W 587. Oprogramowanie dostarcza mechanizmy uwierzytelnienia klientów zarówno na poziomie transportu, jak i komunikatu.

W 588. Oprogramowanie umożliwia uwierzytelnienie za pomocą niestandardowych tokenów zawierających informację o kliencie wywołującym usługę.

W 589. Oprogramowanie umożliwia raportowanie informacji o incydentach w zakresie bezpieczeństwa, w szczególności nieudanego logowania.

W 590. Oprogramowanie posiada mechanizm zarządzania i zabezpieczania usług i procesów w oparciu o polityki.

W 591. Oprogramowanie posiada centralny moduł do zarządzania politykami.

W 592. Oprogramowanie udostępnia zestaw predefiniowanych polityk bezpieczeństwa oraz polityk zarządczych. Istnieje możliwość dodawania własnych polityk.

W 593. Oprogramowanie umożliwia wykorzystanie oraz zmianę używanej polityki zarówno na poziomie developmentu (programiści), jak i w środowiskach wykonawczych (administratorzy).

W 594. Oprogramowanie umożliwia zarządzanie danymi do uwierzytelniania (credentials) oraz repozytoriami certyfikatów (keystores) poprzez REST API.

W 595. Oprogramowanie wspiera standard Oauth 2.0 w zakresie usług REST i SOAP.

W 596. Oprogramowanie umożliwia definiowanie polityk w oparciu o następujące standardy:

• WS-Policy

• WS-PolicyAttachment

• WS-Security

• WS-SecurityPolicy

• SAML

• Kerberos

• X.509

• OAuth 2.0

• XML Signature

• XML Encryption

• WS-Addressing

• WS-ReliableMessaging

• WS-Trust

• WS-SecureConversation.

W 597. Moduł monitorowania (BAM) umożliwia przetwarzanie i wizualizację:

• Parametrów wydajnościowych procesów (czas trwania poszczególnych kroków/ procesów, rozkład zadań/ścieżek)

• Danych biznesowych przekazywanych z poziomu procesów/usług

• Informacji pomocniczych nie związanych bezpośrednio z platformą integracyjną (dane słownikowe, dane historyczne, dane z innych systemów).

W 598. Moduł monitorowania (BAM) umożliwia agregację danych na podstawie pojedynczych zdarzeń rejestrowanych w systemie (x.xx. funkcje: min, max, sum, avg, count, count distinct).

W 599. Moduł monitorowania udostępnia mechanizm definiowania powiadomień generowanych dynamicznie na podstawie rejestrowanych informacji

W 600. Moduł monitorowania zawieranarzędzie umożliwiające osobom merytorycznym tworzenie raportów na podstawie zdefiniowanych obiektów danych (bez konieczności kodowania).

W 601. Raporty tworzone w module BAM wspierają mechanizm drill-down, umożliwiający przechodzenie pomiędzy różnymi poziomami raportu z zachowaniem określonego kontekstu.

W 602. Moduł BAM zawiera mechanizm automatycznego odświeżania raportów w momencie pojawienia się w systemie nowych/zaktualizowanych danych (bez konieczności ręcznego odświeżania raportów).

W 603. Moduł BAM umożliwia filtrowanie informacji prezentowanych w raportach w zależności od informacji o zalogowanym użytkowniku.

5.5. Wymagania na silnik procesów biznesowych

W 604. Oprogramowanie działa na serwerze aplikacji zgodnym ze standardem JEE (Java Enterprise Edition), którego możliwości opisano w dokumencie „Serwer aplikacji”.

W 605. Możliwość budowania projektów zgodnie ze standardem SCA (Service Component Architecture).

W 606. Możliwość modelowania procesów w notacji BPMN 2.0.

W 607. Możliwość modelowania procesów w notacji BPEL (wersja 1.1 oraz 2.0). W 608. Możliwość importowania modeli procesów zdefiniowanych w notacji XPDL.

W 609. Możliwość projektowania procesów w postaci diagramów (poprzez interfejs graficzny; elementy dodawane do modelu metodą drag&drop).

W 610. Możliwość definiowania parametrów poszczególnych elementów modelu poprzez dedykowane kreatory (np. definicja czynności automatycznej ze zdalnym wywołaniem usługi; definicja zbioru reguł biznesowych; definicja czynności manualnej).

W 611. Możliwość projektowania, konfiguracji i uruchamiania procesów na środowisku wykonawczym z poziomu przeglądarki internetowej.

W 612. Możliwość mapowania ról w procesie biznesowym na użytkowników i grupy w katalogu użytkowników (np. LDAP).

W 613. Możliwość definiowania kalendarza pracy organizacji, z uwzględnieniem dni roboczych, dni wolnych, godzin pracy oraz stref czasowych.

W 614. Możliwość definiowania torów (swimlanes) obrazujących role w procesie biznesowym.

W 615. Możliwość definiowania w procesie czynności manualnych, realizowanych jako zadania przez użytkowników końcowych.

W 616. Możliwość definiowania w procesie czynności automatycznych, realizujących poprzez zdalne wywołania funkcje udostępnione przez komponenty zewnętrzne (usługi).

W 617. Możliwość definiowania w procesie synchronicznej komunikacji z usługami oraz innymi procesami.

W 618. Możliwość definiowania w procesie asynchronicznej komunikacji z usługami oraz innymi procesami.

W 619. Możliwość dekompozycji procesów na podprocesy.

W 620. Możliwość definiowania logiki biznesowej w procesie poprzez zbiory reguł biznesowych.

W 621. Możliwość grupowania czynności w procesie.

W 622. Możliwość obsługi błędów/wyjątków na poziomie czynności.

W 623. Możliwość obsługi błędów/wyjątków na poziomie podprocesu. W 624. Możliwość obsługi błędów/wyjątków na poziomie procesu.

W 625. Możliwość zbiorczej obsługi błędów/wyjątków, nieposiadających specyficznych

ścieżek obsługi.

W 626. Możliwość zdefiniowania w procesie akcji pozwalających na zdalne zainicjowanie czynności znajdujących się poza przepływem procesu (np. zapytanie o dane instancji procesu; zdalna aktualizacja danych instancji procesu).

W 627. Możliwość zdefiniowania w procesie czynności pozwalających kontrolować proces (lub jego konkretne etapy) pod względem czasowym (np. akcja realizowana w wyniku przedłużającego się terminu realizacji etapu; periodyczna weryfikacja danych instancji procesu).

W 628. Możliwość definiowania w procesie czynności wykonywanych cyklicznie.

W 629. Możliwość definiowania w procesie czynności wykonywanych równolegle na elementach kolekcji danych.

W 630. Możliwość definiowania w procesie ścieżek wykonywanych równolegle.

W 631. Możliwość zdefiniowania rozgałęzienia przepływu procesu na wykluczające się ścieżki.

W 632. Możliwość zdefiniowania rozgałęzienia przepływu procesu na ścieżki alternatywne.

W 633. Możliwość automatycznego uruchomienia procesu w wyniku zdalnego wywołania określonego interfejsu (np. web service).

W 634. Możliwość automatycznego uruchomienia procesu w wyniku pojawienia się pliku w zdefiniowanym zasobie (system plików, FTP).

W 635. Możliwość automatycznego uruchomienia procesu w wyniku pojawienia się / modyfikacji rekordu w bazie danych.

W 636. Możliwość automatycznego uruchomienia procesu w wyniku pojawienia się wiadomości e-mail na zdefiniowanym koncie serwera poczty.

W 637. Możliwość automatycznego uruchomienia procesu według określonej charakterystyki czasowej (harmonogramowanie).

W 638. Możliwość manualnego uruchomienia procesu przez użytkownika końcowego (z poziomu formularza w przeglądarce).

W 639. Możliwość definicji modelu procesu z wieloma zdarzeniami startowymi.

W 640. Możliwość wysłania do inicjatora procesu komunikatu, informującego o zakończeniu procesu (poprawnie lub błędnie).

W 641. Możliwość opublikowania komunikatu, informującego o zdarzeniu w procesie (np. zakończenie procesu).

W 642. Możliwość definiowania zakresu zadań do wykonania i kamieni milowych w realizacji procesu.

W 643. Możliwość definiowania własnego modelu danych oraz zmiennych przechowujących informacje o instancji procesu oraz wymaganych do komunikacji z komponentami zewnętrznymi (np. usługami).

W 644. Możliwość definiowania własnych typów danych reprezentujących złożone obiekty biznesowe w procesie.

W 645. Możliwość importowania definicji typów danych (np. schematy XML).

W 646. Możliwość definiowania w sposób graficzny transformacji pomiędzy typami danych w procesie (przypisania pomiędzy atrybutami, złożone transformacje, np. w postaci XSLT).

W 647. Możliwość importowania definicji transformacji typów danych (np. XSLT).

W 648. Możliwość obsługi procesów o niedeterministycznym przepływie (każda instancja może mieć inny przepływ składający się z predefiniowanych czynności).

W 649. Możliwość obsługi procesów eksperckich, w których decyzję o wykonaniu kolejnych akcji w ramach procesu podejmuje człowiek na podstawie swojej wiedzy oraz kontekstu zawartego w dostępnych danych oraz dokumentach (knowledge work based).

W 650. Możliwość przeprowadzenia analizy procesu poprzez wykonanie symulacji na zadanym modelu lub modelach.

W 651. Możliwość zdefiniowania wielu scenariuszy symulacji dla jednego modelu.

W 652. Możliwość wykonywania symulacji na bazie danych szacunkowych (bez konieczności wdrażania procesu na środowisko produkcyjne).

W 653. Możliwość wykonywania symulacji na bazie danych rzeczywistych (pobranych z poziomu silnika, realizującego konkretny proces w środowisku produkcyjnym).

W 654. Możliwość definiowania parametrów symulacji w zakresie charakterystyk:

• czasowych (wartości stałe lub wyliczane zgodnie z zadanym rozkładem, np. Gaussa)

• kosztowych (na poziomie czynności i zasobu)

• dostępności i utylizacji zasobów

• sposobu obsługi zadań (kolejki, priorytetyzacja)

• prawdopodobieństwa wybrania określonych ścieżek w procesie.

W 655. Możliwość śledzenia na diagramie procesu ścieżek przejścia (dla instancji wygenerowanych w ramach symulacji).

W 656. Możliwość prezentacji wyników symulacji w postaci wykresów oraz tabel. W 657. Możliwość analizy wyników symulacji pod kątem:

• czasowym

• kosztowym

• ilościowym.

W 658. Możliwość wygenerowania raportu z przeprowadzonej symulacji.

W 659. Możliwość definiowania logiki biznesowej w postaci reguł biznesowych.

W 660. Możliwość zmiany reguł biznesowych w sposób niezależny od definicji procesu.

W 661. Integracja silnika reguł biznesowych oraz silnika procesów zarówno w warstwie developmentu, jak i w środowisku wykonawczym.

W 662. Możliwość budowania reguł w postaci wyrażeń jeśli – to. W 663. Możliwość budowania reguł w postaci tabel decyzyjnych.

W 664. Możliwość eksportu/importu tabeli decyzyjne do/z narzędzia MS Excel. W 665. Możliwość agregacji danych z faktów.

W 666. Aplikacja do zmiany reguł biznesowych dostępna dla użytkowników biznesowych poprzez przeglądarkę internetową.

W 667. Możliwość budowania własnych klientów do budowania reguł biznesowych (dostępne SDK).

W 668. Wsparcie standardu JSR-94.

W 669. Możliwość testowania i debugowania reguł biznesowych.

W 670. Możliwość wystawienia zbioru reguł biznesowych w postaci usługi decyzyjnej (dostępnej przez web service).

W 671. Interfejs użytkownika końcowego dostępny poprzez przeglądarkę internetową W 672. Certyfikowane wsparcie dla przeglądarek:

• Internet Explorer

• Mozilla Firefox

• Apple Safari

• Google Chrome

W 673. Aplikacje dostępowe dla użytkowników końcowych dostępne w języku polskim.

W 674. Aplikacje dostępowe dla użytkowników końcowych dostępne w języku angielskim.

W 675. Wybór języka w aplikacji dostępowej zależny od ustawień przeglądarki lub atrybutu lokalizacji w katalogu użytkowników.

W 676. Możliwość prezentacji użytkownikom końcowym zakresu zadań do wykonania w ramach procesu, kamieni milowych oraz zaawansowania prac w kontekście przewidzianych zadań.

W 677. Możliwość osadzenia aplikacji dostępowej w portalu procesowym.

W 678. Możliwość definiowania zadań z możliwością przypisania ich do ról, grup lub użytkowników.

W 679. Możliwość definiowania zadań z możliwością określania danych prezentowanych użytkownikom, z uwzględnieniem uprawnień do odczytu/modyfikacji poszczególnych obiektów i/lub atrybutów.

W 680. Możliwość definiowania zadań z możliwością specyfikowania powiadomień wysyłanych użytkownikom.

W 681. Możliwość definiowania zadań z możliwością określenia obsługi terminów wykonania zadania (w tym eskalacji, odnowienia zadania).

W 682. Możliwość definiowania zadań wieloetapowych w ramach pojedynczego kroku w procesie (zadania przekazywane pomiędzy rolami/grupami/użytkownikami zgodnie ze zdefiniowanym przepływem workflow).

W 683. Możliwość przypisania zadania do roli zdefiniowanej w procesie.

W 684. Możliwość przypisania zadania bezpośrednio do grupy użytkowników (grupa w katalogu użytkowników, np. LDAP).

W 685. Możliwość przypisania zadania bezpośrednio do konkretnego użytkownika (z katalogu użytkowników, np. LDAP).

W 686. Możliwość dynamicznego wyznaczania użytkowników/grup odpowiedzialnych za wykonanie zadania na podstawie parametrów procesu (np. za pomocą reguł biznesowych).

W 687. Obsługa wzorca umożliwiającego głosowanie w ramach zadania.

W 688. Obsługa wzorca umożliwiającego przekazywanie zadania w workflow na podstawie hierarchii zdefiniowanej w katalogu użytkowników (tzw. Management Chain).

W 689. Możliwość monitorowania stanów i danych w procesach biznesowych, z mechanizmem automatycznego przekazywania mierników z poziomu procesu do centralnego repozytorium danych monitorowanych (repozytorium BAM).

W 690. Graficzny edytor raportów BAM, dostępny z przeglądarki, pozwalający użytkownikom biznesowym na tworzenie interaktywnych raportów wizualizujących kluczowe parametry procesów.

W 691. Możliwość harmonogramowania generacji raportów procesowych, z możliwością zdefiniowania sposobu dystrybucji raportu.

W 692. Możliwość ograniczania dostępu do raportów oraz danych w raportach (np. widoczność danych sprzedażowych tylko dla określonej grupy produktów lub obszaru).

W 693. Możliwość definiowania alertów bazujących na miernikach.

6. Zawartość przedmiotu zamówienia

1. Dostarczenie oprogramowania objętego licencją.

2. Przeprowadzenie analizy wymagań, której wynikiem będzie Koncepcja Wdrożenia zawierająca produkty specjalistyczne:

o Szczegółowy harmonogram realizacji projektu

o Architektura Systemu – fizyczna i logiczna

o Raport z Analizy, zawierający:

▪ Opis koncepcji realizacji Systemu, z uwzględnieniem: integracji elementów Systemu, modelu uprawnień.

▪ Szczegółowy opis Procesów Biznesowych objętych Wdrożeniem (w standardzie BPMN 2.0).

▪ Kanoniczny model danych dla plików masowych.

▪ Wymagania – uszczegółowienie wymagań SIWZ.

Opracowane produkty będą wynikiem zrealizowanych przez Wykonawcę zadań:

o Szczegółowe określenie celów projektu

o Analiza posiadanej infrastruktury i oprogramowania oraz wymagań technicznych, biznesowych, funkcjonalnych i niefunkcjonalnych

o Doprecyzowanie wymagań

o Kategoryzacja wymagań

o Wskazanie zależności pomiędzy wymaganiami

o Agregowanie wymagań

o Usuwanie sprzeczności

o Ustalenie priorytetów

o Opisanie procesów realizujących cele

o Optymalizacja procesów

3. Wdrożenie Systemu:

o Instalacja i konfiguracja środowiska produkcyjnego i testowego.

o Budowa Systemu, która będzie przebiegać w ustalonych w Koncepcji Wdrożenia iteracjach mających na celu dostarczenie stabilnej wersji części Systemu, z których każda będzie uwzględniać realizację i dostarczenie:

▪ Szczegółowy opis funkcjonalności rozwiązania, zawierający:

• Opis rozwiązania

• Model dziedzinowy

• Szczegółowa specyfikacja przypadków użycia, uwzględniająca opisanie komunikacji pomiędzy obiektami reprezentującymi

ekrany interfejsu użytkownika, logikę biznesową i dane systemu w ramach poszczególnych przypadków użycia,

• Komponenty logiczne i interfejsy komunikacji

• Ekrany aplikacji, z uwzględnieniem opisania pól na ekranach, walidacji, pomocy kontekstowej

• Podstawy realizacji

• Mapa pokrycia wymagań

▪ Implementacja rozwiązania

▪ Plan testów i scenariusze testowe, zawierające:

• proponowany czas trwania testu

• podstawowe informacje na temat przedmiotu testów,

• zakres testów (wykaz wymagań dla każdej z testowanych aplikacji biznesowych),

• scenariusz testów danej Funkcjonalności, wraz z informacją o konfiguracji (jeżeli jest wymagana dodatkowa), kryteria akceptacyjne.

▪ Prezentacja stabilnej wersji rozwiązania

▪ Testy akceptacyjne

▪ Uruchomienie wersji pilotażowej na środowisku testowym Zamawiającego

4. Dostarczenie zestawu dokumentacji powdrożeniowej:

o Projekt Funkcjonalny – kompletna dokumentacja zawierająca elementy Koncepcji Wdrożenia oraz Szczegółowe opisy funkcjonalności rozwiązania dostarczane podczas Wdrożenia Systemu.

o Projekt Techniczny - dokumentację opisującą szczegółową konfigurację

komponentów, ich wzajemnych relacji i powiązań umożliwiających zainstalowanie, uruchomienie i poprawną pracę poszczególnych aplikacji i systemów. Projekt techniczny musi obejmować co najmniej następujące informacje:

▪ Model architektury logicznej (listę i opis komponentów, wraz z wykazem oprogramowania, za pomocą którego dany komponent jest realizowany, interfejsy logiczne pomiędzy komponentami Systemu)

▪ Model architektury technicznej (wykaz oprogramowania standardowego, wykaz oprogramowania dedykowanego budowanego w ramach niniejszego postępowania, konfigurację oprogramowania, opis interfejsów z systemami zewnętrznymi wraz ze specyfikacją komunikacji, rozmieszczenie oprogramowania w architekturze fizycznej)

▪ Architektura fizyczna (opis dostarczonego sprzętu w tym nazwa/typ urządzenia, rola w systemie, parametry, numer seryjny; architektura fizyczna rozwiązania, architektura sieciowa, projekt instalacji dostarczanego rozwiązania, konfigurację urządzeń)

▪ Model projektowy (model bazy danych, interfejsy międzysystemowe,

▪ Dokumentacja procesu wytwórczego dla oprogramowania dedykowanego budowanego na potrzeby niniejszego zamówienia (opis standardów pisania kodów źródłowych, opis wykorzystanych technologii w tym języki programowania, biblioteki).

o Dokumentacja developerska opisująca szczegółowy zaimplementowane procesy i usługi.

o Dokumentacja użytkownika w podziale na role, w tym też role administracyjne aplikacji;

o Dokumentacja administratorów w podziale na role, która zawierać będzie co

najmniej:

▪ Procedury administracyjne

▪ Procedury instalacji i konfiguracji

▪ Procedury bieżących działań administracyjnych

▪ Procedury okresowych/planowanych działań administracyjnych

▪ Procedury aktualizacji standardowych elementów dostarczonego rozwiązania

▪ Procedury awaryjne (w tym wykonanie kopii bezpieczeństwa – pełnej oraz przyrostowej, postępowanie w przypadku awarii systemu)

▪ Procedur Disaster Recovery ze scenariuszami awarii oraz procedur działań odtworzeniowych i uruchomieniowych mających na celu zminimalizowanie strat danych oraz zminimalizowanie czasu niedostępności usług;

o Dokumentacja wytwarzanego oprogramowania, która będzie zawierać najmniej:

▪ Kody źródłowe

▪ Procedury kompilacji kodu źródłowego

▪ Opis kodu źródłowego

5. Realizację szkoleń, w tym dostarczenie planu szkoleń,

6. Migrację inicjalną danych do Systemu,

7. Uruchomienie testowe i produkcyjne całego Systemu,

8. Zapewnienie asysty powdrożeniowej

9. Zapewnienie serwisu gwarancyjnego i wsparcia;

7. Szkolenia

Wykonawca przeprowadzi w lokalizacji Zamawiającego następujące szkolenia: W 1. Szkolenie użytkownika , w podziale na role:

• Pracownik – 8 godzin

• Administrator – 8 godzin

• Kierownik – 4 godziny

• Dyrekcja – 4 godziny

Wykonawca przeprowadzi szkolenia użytkownika dla 10 grup użytkowników.

W 2. Szkolenie technologiczne, w wymiarze 240 godzin (1 grupa szkoleniowa obejmująca maksimum 5 osób), w podziale na obszary funkcjonalne:

• Portal

• Repozytorium dokumentów

• BPM, BAM i reguły biznesowe

• SOA i zagadnienia integracji

• Weblogic

• EM/Consola

• Aplikacja – ADF

• Administrowanie/Utrzymanie systemu.

OPIS PRÓBKI PRODUKTU

Załącznik nr 1.1. do SIWZ

Spis Treści

1. Założenia 78

2. Scenariusz cyklu życia sprawy w Systemie. 79

2.1 Oczekiwany rezultat 79

2.2 Przebieg scenariusza 79

3. Scenariusz wieloetapowej dekretacji dokumentu. 80

3.1 Oczekiwany rezultat 80

3.2 Przebieg scenariusza 80

4. Scenariusz - Rejestracja dokumentu w aplikacji Systemu z jednoczesnym umieszczeniem go w repozytorium 81

4.1 Oczekiwany rezultat 81

4.2 Przebieg scenariusza 81

5. Scenariusz - Integracja portalu z repozytorium I 82

5.1 Oczekiwany rezultat 82

5.2 Przebieg scenariusza 82

6. Scenariusz - Integracja portalu z repozytorium II 82

6.1 Oczekiwany rezultat 82

6.2 Przebieg scenariusza 83

7. Scenariusza - Mechanizm zatwierdzania plików do publikacji w portalu 84

7.1 Oczekiwany rezultat 84

7.2 Przebieg scenariusza 84

8. Scenariusz - Integracja repozytorium z Windows Explorer, MS Word, MS Excel i MS Power Point 85

8.1 Oczekiwany rezultat 85

8.2 Przebieg scenariusza 85

9. Scenariusz – Mechanizm OCR wielostronicowych plików PDF zawierających w treści jedynie elementy graficzne (bez przeszukiwalnej treści tekstowej) 86

9.1 Oczekiwany rezultat 86

9.2 Przebieg scenariusza 86

10. Scenariusz – Mechanizm wsadowego OCR wielostronicowych plików PDF zawierających w treści jedynie elementy graficzne (bez przeszukiwalnej treści tekstowej) 87

10.1 Oczekiwany rezultat 87

10.2 Przebieg scenariusza 87

11. Scenariusz - Wykorzystanie mechanizmu konwersji plików w repozytorium 89

11.1 Oczekiwany rezultat 89

11.2 Przebieg scenariusza 89

12. Scenariusz - Wykorzystanie mechanizmu konwersji plików w repozytorium do postaci PDF i do postaci przeglądarki HTML/JS (navigable slideshow) 90

12.1 Oczekiwany rezultat 90

12.2 Przebieg scenariusza 90

1. Założenia

Podstawowe założenie, które przyjęto przy konstrukcji próbki przewiduje, że funkcjonalności weryfikowane tą próbką muszą być możliwe do zrealizowania bez konieczności uzależnienia ich działania od poprawności i sposobu funkcjonowania systemów zewnętrznych.

Funkcjonalności opisane w scenariuszach 9 i 10 muszą być zrealizowane z wykorzystaniem komponentu OCR, zbudowanego poza funkcjonalnościami repozytorium dokumentów.

Sprawdzane funkcjonalności nie stanowią kompletu funkcjonalności związanych z działaniem repozytorium i aplikacji, które powinny być z nim zintegrowane.

Prezentacja musi być wykonana na jednym środowisku, obejmującym jeden portal dostępowy oraz pozostałe niezbędne komponenty, w tym repozytorium, silnik procesów biznesowych i bazę danych.

2. Scenariusz cyklu życia sprawy w Systemie.

2.1 Oczekiwany rezultat

• Wykazanie, że prezentowane rozwiązanie obsługuje podstawowe fazy cyklu

życia sprawy

2.2 Przebieg scenariusza

Lp.	Rola	Czynność
1	Kancelaria	Logowanie do aplikacji Systemu (dalej – aplikacja).
2	Kancelaria	Rejestracja nowego dokumentu w module kancelaryjnym: - opisanie dokumentu metadanymi - dołączenie do dokumentu pliku.
3	Kancelaria	Przekazanie dokumentu do roli odpowiedzialnej za dekretację
4	Dekretacja	Realizacja zadania dekretacji – przekazanie do użytkownika odpowiedzialnego za realizację.
5	Referent	Założenie sprawy z dokumentu
6	Referent	Wytworzenie dokumentu wychodzącego (decyzja w sprawie)
7	Grupa opiniowanie	Opiniowanie dokumentu
8	Akceptacja	Akceptacja dokumentu
9	Referent	Zamknięcie sprawy
10	Upoważniony użytkownik	Przeglądanie historii sprawy

3. Scenariusz wieloetapowej dekretacji dokumentu.

3.1 Oczekiwany rezultat

• Wykazanie, że prezentowane rozwiązanie obsługuje podstawowe fazy cyklu dekretacji dokumentu wraz z wykazaniem, że dokument może zostać zadekretowany równolegle do wielu użytkowników, jak też że każdy z tych użytkowników może założyć sprawę z dokumentu

3.2 Przebieg scenariusza

Lp.	Rola	Czynność
1	Kancelaria	Logowanie do aplikacji Systemu (dalej – aplikacja).
2	Kancelaria	Rejestracja nowego dokumentu w module kancelaryjnym: - opisanie dokumentu metadanymi - dołączenie do dokumentu pliku.
3	Kancelaria	Przekazanie dokumentu do roli odpowiedzialnej za dekretację
4	Dekretacja	Realizacja zadania dekretacji – przekazanie dokumentu równolegle do 3 użytkowników odpowiedzialnych za realizację, wraz z opatrzeniem dokumentu różnymi poleceniami dla każdego z użytkowników
5	Dekretacja	Po zalogowaniu na konto jednego z użytkowników którzy otrzymali dokument ponowna dekretacja – przekazanie dokumentu równolegle do 3 użytkowników odpowiedzialnych za realizację, wraz z opatrzeniem dokumentu różnymi poleceniami dla każdego z użytkowników
6	Referent	Na losowo wskazanym koncie jednego z użytkowników założenie sprawy z dokumentu

4. Scenariusz - Rejestracja dokumentu w aplikacji Systemu z jednoczesnym umieszczeniem go w repozytorium

4.1 Oczekiwany rezultat

• Wykazanie, że składnicą dokumentów jest repozytorium - dokumenty nie są rejestrowanie w bazie Systemu .

• Wykazanie, ze System korzysta z usług repozytorium.

• W repozytorium znajduje się dokument z metadanymi dopisanymi w aplikacji

4.2 Przebieg scenariusza

Lp.	Rola	Czynność
1	Użytkownik	Logowanie do aplikacji Systemu (dalej – aplikacja).
2	Użytkownik	Rejestracja nowego dokumentu w module kancelaryjnym: - opisanie dokumentu metadanymi - dołączenie do dokumentu pliku.
3	Użytkownik	Logowanie do repozytorium.
4	Użytkownik	Wyszukanie dokumentu za pomocą natywnego narzędzia repozytorium.

5. Scenariusz - Integracja portalu z repozytorium I

5.1 Oczekiwany rezultat

• Mechanizm integracji portal - repozytorium zapewnia wyświetlenie najnowszej wersji dokumentu dzięki mechanizmom repozytorium.

• Nie jest konieczna ręczna interwencja w mechanizmach portalu w celu wymiany dokumentu w portalu na najnowszy.

• Wykazanie, że zarządzanie wersją odbywa się w repozytorium i portal korzysta z usług repozytorium.

5.2 Przebieg scenariusza

Lp.	Rola	Czynność
1	Dowolny użytkownik	Logowanie do portalu i wybranie Dokumentu z zakładki umieszczonej na portalu, przeglądanie dokumentu (poprzez jego pobranie) .
2	Autor treści	Operacja check-out w repozytorium na dokumencie który jest przeglądany.
3	Autor treści	Edycja dokumentu - wprowadzenie zmian, które zostaną zweryfikowane w następnych krokach.
4	Autor treści	Zapisanie - operacja check-in w repozytorium.
5	Dowolny użytkownik	Ponowne pobranie dokumentu z tego samego miejsca w portalu i potwierdzenie widoczności zmian w dokumencie w porównaniu z poprzednią wersją.

6. Scenariusz - Integracja portalu z repozytorium II

6.1 Oczekiwany rezultat

• Mechanizm integracji portal - repozytorium zapewnia wyświetlenie w Portalu najnowszej treści. Treść wyświetlana jest w portalu w postaci fragmentu strony

HTML - w repozytorium jest przechowywana w postaci pliku podlegającego przeszukiwaniu i wersjonowaniu

• Nie jest konieczna ręczna interwencja w mechanizmach portalu w celu wymiany treści w portalu na najnowszą.

• Wykazanie, że zarządzanie wersją odbywa się w repozytorium i portal korzysta z usług repozytorium.

6.2 Przebieg scenariusza

Lp.	Rola	Czynność
1	Dowolny użytkownik	Logowanie do portalu i wybranie treści z podstrony umieszczonej na portalu, przeglądanie treści dokumentu (wyświetlonej bezpośrednio na stronie portalu)
2	Autor treści	Operacja check-out w repozytorium na treści, która jest przeglądana.
3	Autor treści	Edycja dokumentu - wprowadzenie zmian, które zostaną zweryfikowane w następnych krokach.
4	Autor treści	Zapisanie - operacja check-in w repozytorium.
5	Dowolny użytkownik	Ponowne sprawdzenie treści w tym samym miejscu w portalu i potwierdzenie widoczności zmian w porównaniu z poprzednią wersją.

7. Scenariusza - Mechanizm zatwierdzania plików do publikacji w portalu

7.1 Oczekiwany rezultat

• Wykazanie, że aplikacja wykorzystuje silnik procesów BPM komunikujący się z repozytorium dokumentów.

7.2 Przebieg scenariusza

Lp.	Rola	Czynność
1	Użytkownik dodający	Wykonanie operacji check-in uruchamia proces akceptacji dla danego typu dokumentu.
2	Użytkownik akceptujący	Uruchomienie łącza do nowego procesu: W procesie: • Treść dokumentu (nie łącze) jest wyświetlana na ekranie akceptacji. • Akceptujący może obejrzeć graficzną postać procesu w którym bierze udział. • Akceptujący wyraża zgodę na umieszczenie dokumentu w repozytorium.
3	Użytkownik dodający	Podgląd pliku w portalu w zakładce dla niego przewidzianej - nowy lub zmodyfikowany plik jest widoczny.
4	Użytkownik dodający	Operacja check-in dla kolejnego dokumentu lub check-in dla uprzednio wyrejestrowanego pliku (akceptacja nowej wersji).
5	Użytkownik akceptujący	Weryfikacja dokumentu - odmowa umieszczenia dokumentu w repozytorium. Treść dokumentu (nie łącze) jest wyświetlana na ekranie akceptacji. Akceptujący może obejrzeć graficzną postać procesu, w którym bierze udział.
6	Użytkownik dodający	Podgląd pliku w repozytorium - brak pliku lub poprzednia wersja pliku.

Scenariusz - Integracja repozytorium z Windows Explorer, MS Word, MS Excel i MS Power Point

7.3 Oczekiwany rezultat

• Możliwość dodawania do repozytorium i edycji dokumentów istniejących w repozytorium bezpośrednio z poziomu narzędzi Windows Explorer, MS Word, MS Excel i MS PowerPoint.

7.4 Przebieg scenariusza

Lp.	Rola	Czynność
1	Użytkownik	Dostęp do repozytorium z poziomu Windows Explorer.
2	Użytkownik	Przeniesienie 'drag and drop' dokumentu do katalogu repozytorium widocznego w Windows Explorer skutkuje monitem o uzupełnienie metadanych dokumentu.
3	Użytkownik	Po uzupełnieniu - przegląd dokumentu w repozytorium i potwierdzenie jego dodania i widoczności uzupełnionych w punkcie 2 metadanych.
4	Użytkownik	Edycja nowego dokumentu w Word/Excel/Powerpoint
5	Użytkownik	Operacja check-in w Word/Excel/PowerPoint.
6	Użytkownik	Potwierdzenie obecności nowego dokumentu w repozytorium
7	Użytkownik	Wykonanie operacji check-out na dowolnym dokumencie repozytorium w aplikacjach Word/Excel/Powerpoint Wprowadzenie zmian do dokumentu i wykonanie operacji check-in
8	Użytkownik	Weryfikacja naniesionych zmian w dokumencie z poziomu mechanizmów repozytorium

8. Scenariusz – Mechanizm OCR wielostronicowych plików PDF zawierających w treści jedynie elementy graficzne (bez przeszukiwalnej treści tekstowej)

8.1 Oczekiwany rezultat

Oczekuje się aby wejściowy plik PDF zawierający treść w postaci np. skanów kolejnych stron wieleostronnicowego dokumentu lub publikacji był przetworzony w następujący sposób:

• Teksty znajdujące się w poszczególnych ilustracjach stanowiących zawartość dokumentu PDF powinny zostać poddane OCR

• Na bazie uzyskanych treści tekstowych na każdą stronę dokumentu PDF zawierającą warstwę graficzną powinna zostać nałożona w odpowiednich miejscach warstwa tekstowa, tak aby w efekcie:

o dokument mógł być przeszukiwany pełnotekstowo oraz

o była możliwa operacja ręcznego kopiowania tekstu (Ctrl+C) z treści poszczególnych stron za pomocą typowego klienta PDF (Acrobat Reader) w taki sposób, jak możliwe jest to w przypadku dokumentów

.doc z treściami tekstowymi

• Po przetworzeniu dokumentu warstwa graficzna dokumentu powinna pozostać nie zmieniona, zmianie nie ulega liczba stron, położenie elementów graficznych itp.

Próbka plików poddawanych testowi składać się będzie z co najmniej 5 plików, każdy zawierający co najmniej 20 stron

8.2 Przebieg scenariusza

Lp.	Rola	Czynność
1	Użytkownik	Rejestracja z poziomu aplikacji pliku typu PDF do repozytorium.
2.	Użytkownik	Wysłanie z poziomu aplikacji pliku do przetwarzania OCR opisanego wyżej (założenia i rezultaty opisane w punkcie 9.1)
3.	Użytkownik	Po „powrocie” dokumentu z OCR sprawdzenie, czy przetworzony dokument został zarejestrowany jako nowa wersja
4.	Użytkownik	Weryfikacja możliwości pełnotekstowego wyszukania dokumentu
5.	Użytkownik	Weryfikacja możliwości kopiowania dowolnego akapitu z dowolnej

strony w przetworzonym dokumencie

9. Scenariusz – Mechanizm wsadowego OCR wielostronicowych plików PDF zawierających w treści jedynie elementy graficzne (bez przeszukiwalnej treści tekstowej)

9.1 Oczekiwany rezultat

Oczekuje się efektu OCR zgodnego z opisanym w punkcie 9.1. W bieżącym scenariuszu proces OCR funkcjonować ma „wsadowo”, zaś OCR podlegać będą dokumenty udostępnione na zasobie FTP.

Wykazać należy również, iż dokumenty pobierane z zasobu FTP przetwarzane są równolegle. Dodatkowo istnieć musi możliwość skonfigurowania procesu wsadowego OCR tak, aby uruchamiał się on automatycznie o zadanej godzinie.

Mechanizm OCR powinien być zintegrowany z mechanizmem procesowym (BPM lub BPEL) tak, aby możliwe było monitorowanie jego stanu za pośrednictwem narzędzi administracyjnych silnika procesów.

Fakt równoległego przetwarzania kolejki dokumentów wykazać należy prezentując czasy startu i zakończenia odpowiednich procesów.

Próbka plików poddawanych testowi składać się będzie z co najmniej 10 plików, każdy zawierający co najmniej 50 stron.

9.2 Przebieg scenariusza

Lp.	Rola	Czynność
1	Użytkownik	Zapis plików PDF próbki na zasób FTP
2.	Użytkownik	Wysłanie z poziomu aplikacji sygnału do uruchomienia przetwarzania OCR minimum 2 dokumentów o zadanej godzinie.
3.	Użytkownik	Po automatycznym uruchomieniu procesu OCR wykazanie, iż dokumenty przetwarzane są równolegle (przynajmniej 2 równoległe operacje przetwarzania)
4.	Użytkownik	Po zakończeniu OCR sprawdzenie, czy przetworzone pliki zostały zarejestrowane w repozytorium w ramach wybranych

		dokumentów (Lp 2).
4.	Użytkownik	Weryfikacja możliwości pełnotekstowego wyszukania wybranego dokumentu
5.	Użytkownik	Weryfikacja możliwości kopiowania dowolnego akapitu z dowolnej strony w dowolnym z przetworzonych dokumentów

10.Scenariusz - Wykorzystanie mechanizmu konwersji plików w repozytorium

10.1 Oczekiwany rezultat

• Repozytorium dokonuje w tle konwersji zarejestrowanego pliku (w tym przypadku do PDF) do postaci przeszukiwalnej.

• Możliwość wyszukania dodanego pliku po zawartej w nim treści.

10.2 Przebieg scenariusza

Lp.	Rola	Czynność
1	Użytkownik	Użytkownik rejestruje pliki typu DOC, XLS, PNG.
2	Użytkownik	Przeszukanie repozytorium na okoliczność wystąpienia konkretnej treści (występującej w zarejestrowanym w punkcie 1 pliku)
3	Użytkownik	Weryfikacja listy rezultatów na okoliczność wystąpienia zarejestrowanego pliku.

11.Scenariusz - Wykorzystanie mechanizmu konwersji plików w repozytorium do postaci PDF i do postaci przeglądarki HTML/JS (navigable slideshow)

11.1 Oczekiwany rezultat

• Repozytorium dokonuje w tle konwersji zarejestrowanego pliku do postaci pliku PDF.

• Repozytorium dokonuje w tle konwersji zarejestrowanego pliku do postaci prezentacji (slideshow) zakodowanego w HTML/JS.

• Każda strona dokumentu prezentowana jest jako pojedynczy slajd

• Postać slideshow można umieścić w treści strony WWW (np. w portalu) i jest ona dostępna dla użytkowników bez konieczności instalowania dodatkowego oprogramowania na stacji klienckiej

11.2 Przebieg scenariusza

Lp.	Rola	Czynność
1	Użytkownik	Użytkownik rejestruje pliki typu DOC, XLS, PNG.
2	Użytkownik	W interfejsie natywnym repozytorium użytkownik wyszukuje plik i pobiera jego wersję skonwertowaną do PDF
3	Użytkownik	Powyższą czynność użytkownik wykonuje w aplikacji korzystającej z repozytorium jako składnicy dokumentów
4	Użytkownik	W interfejsie natywnym repozytorium użytkownik wyszukuje plik i wyświetla jego podgląd w postaci slideshow
5	Użytkownik	Powyższą czynność użytkownik wykonuje w aplikacji korzystającej z repozytorium jako składnicy dokumentów

2. Opis zasad przygotowania i przeprowadzenia demonstracji Próbki

I. Ogólne zasady

1. Zamawiający zastrzega sobie prawo sprawdzania w toku oceny oferty wiarygodności przedstawionych przez Wykonawców dokumentów, oświadczeń, wykazów, danych i informacji.

2 Zamawiający zastrzega sobie prawo do przeprowadzenia testów podczas demonstracji próbki na co najmniej 3 ww. scenariuszach.

3. Zamawiający zastrzega sobie prawo sprawdzania w toku oceny oferty, czy zadeklarowane przez Wykonawcę w Ofercie funkcjonalności oferowanego Systemu są zgodne ze stanem faktycznym. Zamawiający żąda złożenia wraz z ofertą Próbki przedmiotu oferty w części dotyczącej oprogramowania, w postaci zainstalowanego i skonfigurowanego na komputerze/komputerach systemu w taki sposób, by Xxxxxxxxxxx mógł zweryfikować oświadczenia Wykonawcy co do właściwości przedmiotu zamówienia zawartych w ofercie Wykonawcy lub wymaganiach SIWZ. Przygotowanie Próbki w sposób uniemożliwiający zaprezentowanie wszystkich właściwości, o których mowa powyżej, będzie traktowane jako niezgodność oferty z wymaganiami SIWZ i spowoduje odrzucenie oferty na podstawie art. 89 ust. 1 pkt 2 ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2015 r., poz. 2164 z późn. zm.), dalej ustawa Pzp.

4. W celu oceny zgodności z SIWZ oferowanego rozwiązania, Wykonawca zostanie poproszony przez Zamawiającego o wykonanie demonstracji Próbki, która to procedura w dalszej części nazywana będzie „Demonstracją Próbki” lub krótko „Demonstracją”.

5 Zadeklarowane funkcjonalności uznaje się za zgodne ze stanem faktycznym, jeśli demonstracja wykaże, że wszystkie deklarowane funkcjonalności rzeczywiście są zawarte w systemie. Jeżeli w trakcie Demonstracji nie uda się Zamawiającemu zidentyfikować w próbce jakiejkolwiek właściwości przedmiotu zamówienia wymaganej przez SIWZ lub zadeklarowanej w ofercie przez Wykonawcę, wówczas Zamawiający uzna, że próbka jest niezgodna z treści SIWZ i podlega odrzuceniu.

6. Demonstracja odbędzie się w siedzibie Zamawiającego w obecności Komisji Przetargowej, powołanej przez Zamawiającego. Demonstracja próbek odbędzie się zgodnie z kolejnością składania ofert do Zamawiającego. Informacje o terminach Demonstracji próbki Zamawiający przekaże jednocześnie wszystkim Wykonawcom.

7. Demonstracja będzie odbywać się zgodnie z postanowieniami zawartymi w niniejszym Załączniku.

8. Z uwagi na równe traktowanie wszystkich Wykonawców Zamawiający nie dopuszcza żadnych odstępstw od sposobu prowadzenia prezentacji opisanego w niniejszym Załączniku.

9. Demonstracja będzie przeprowadzona przez Komisję Przetargową Zamawiającego w obecności upoważnionych przedstawicieli Wykonawcy, którego próbka podlega weryfikacji. Ze strony Zamawiającego w Weryfikacji, poza osobami wchodzącymi w skład Komisji Przetargowej, będzie mogło uczestniczyć maksymalnie 3 osoby będące biegłymi i posiadające niezbędną wiedzę merytoryczną i techniczną. Demonstracja będzie odbywała się na środowisku prezentacyjnym przygotowanym przez Wykonawcę.

10. Środowisko demonstracyjne będzie zainstalowane i skonfigurowane na sprzęcie komputerowym Wykonawcy.

11. W celu przygotowania przez Wykonawcę środowiska demonstracyjnego ma on obowiązek przygotować testowe próbki danych zgodnie z wymaganiami opisanymi w SIWZ.

12. Wykonawca zobowiązany będzie do przeprowadzania Demonstracji rozwiązania na ekranie z użyciem co najmniej jednego rzutnika multimedialnego w sposób umożliwiający obserwację Weryfikacji wszystkim obecnym na niej osobom.

13. Przeprowadzenie Demonstracji będzie udokumentowane pisemnym protokołem sporządzonym przez Zamawiającego celem włączenia go do akt postępowania przetargowego.

14. W trakcie weryfikacji Zamawiający będzie mógł zadawać pytania Wykonawcy w zakresie wymaganych funkcjonalności opisanych w Ofercie Wykonawcy, zmierzające wyłącznie do ustalenia czy dana funkcjonalność zadeklarowana w oświadczeniu Wykonawcy jest rzeczywiście realizowana przez oferowane rozwiązanie.

15. W trakcie Demonstracji Wykonawca będzie mógł udzielać Zamawiającemu dodatkowych informacji, które zostaną zamieszczone w protokole.

16. Zamawiający ma prawo żądać zmodyfikowania wartości parametrów, bądź danych wprowadzanych do systemu na wartości podane przez niego, celem sprawdzenia czy demonstrowana funkcjonalność nie jest przez Wykonawcę symulowana.

II. Przygotowanie Próbki oprogramowania do Demonstracji

17. Próbka oprogramowania powinna zostać przygotowana w postaci oprogramowania zainstalowanego co najmniej na jednym komputerze osobistym (stacjonarnym lub przenośnym).

18. Do oferty, jako próbkę oprogramowania, należy dołączyć jedynie pamięci masowe (dyski twarde, SSD lub inne nośniki) wewnętrzne lub zewnętrzne i zawierające całość oprogramowania będącego Próbką, jak i również oprogramowania systemowego, niezbędnego do funkcjonowania Próbki takiego, jak np. system operacyjny, oprogramowanie bazodanowe, etc.

19. Na potrzeby Demonstracji Próbki, Wykonawca dostarczy nie wcześniej niż w dniu przeprowadzania Demonstracji niezbędne środowisko testowe składające się z:

1) komputera, na którym będzie odbywała się demonstracja Próbki;

2) rzutnika multimedialnego;

3) niezbędne kable łączące i zasilające oraz listwy zasilające (Zamawiający zapewni zasilanie 230V z uziemieniem);

4) w przypadku chęci dokonania demonstracji na więcej niż jednym komputerze pozostałego niezbędnego wyposażenia.

III. Minimalne parametry Próbki oprogramowania:

Próbka musi zawierać co najmniej:

1) system operacyjny oraz zainstalowane i skonfigurowane oprogramowanie, stanowiące przedmiot oferty Wykonawcy, niezbędne do przeprowadzenia demonstracji i weryfikacji wszystkich funkcjonalności opisanych w Opisie Przedmiotu Zamówienia.

2) mechanizm wykonywania zrzutów ekranowych w postaci plików JPG lub PNG;

3) oprogramowanie niezbędne do korzystania z demonstrowanych aplikacji.

IV. Procedura i forma przekazania Próbki

W celu zapewnienia jednakowych warunków Demonstracji Próbki wszystkim Wykonawcom uczestniczącym w postępowaniu, Wykonawcy i Zamawiający będą postępować zgodnie z następującą procedurą:

20. Oprogramowanie, wchodzące w skład weryfikowanej Próbki powinno być zainstalowane na nośnikach pamięci masowych, które Wykonawca przekaże Zamawiającemu i włączy do zbiorczego opakowania oferty.

21. Pozostałe elementy sprzętowe stanowiące środowisko testowe, w tym komputery, które będą niezbędne do demonstracji działania Próbki zostaną dostarczone przez Wykonawcę na jedną godzinę przed wyznaczonym terminem rozpoczęcia Demonstracji Próbki.

22. Pamięci masowe muszą być zapakowane w nieprzezroczyste opakowanie uniemożliwiające jego otwarcie bez pozostawienia śladów (np. opieczętowane). Zamawiający zaleca, aby dyski były umieszczone dodatkowo w opakowanie ochronne (np. w folię bąbelkową lub styropian), które również uniemożliwią jego otwarcie bez pozostawienia śladów (np. opieczętowane). Dla bezpieczeństwa Zamawiający zezwala na załączenie do oferty dodatkowej kopii nośników pamięci masowych z zainstalowaną Próbką systemu także zapakowane w nieprzezroczyste opakowanie uniemożliwiające jego otwarcie bez pozostawienia śladów (np. opieczętowane).

23. Zamawiający przekaże Wykonawcy zdeponowane Próbki na 45 minut przed rozpoczęciem demonstracji Próbki, wszelkie czynności przygotowawcze do prezentacji Wykonawca będzie realizował w obecności Komisji Przetargowej.

24. Podczas przeprowadzenia Demonstracji Próbki Wykonawca może korzystać tylko i wyłącznie z dostarczonego do Zamawiającego sprzętu oraz zdeponowanych nośników pamięci oraz narzędzi niezbędnych do zamontowania i podłączenia pamięci masowych do komputerów a także niezbędnych akcesoriów podłączeniowych oraz urządzeń dostarczonych przez Zamawiającego jak rzutniki, kamery wideo czy niezbędne listwy zasilające.

25. Niedopuszczalne jest:

1) wgrywanie z zewnętrznych źródeł (przy pomocy nośników zewnętrznych lub innych środków komunikacji, np.: sieci bezprzewodowej) nowych danych i programów, poza danymi testowymi przekazanymi przez Zamawiającego,

2) instalowanie bądź uaktualnianie zainstalowanego oprogramowania z zewnętrznych źródeł,

3) rozbudowywanie elementów sprzętowych.

26. Dostarczony do Zamawiającego sprzęt komputerowy służący do stworzenia środowiska demonstracyjnego nie może zawierać zainstalowanych żadnych dodatkowych nośników danych. Zamawiający zastrzega sobie prawo do przeglądnięcia sprzętu oraz obecności przy instalowaniu zdeponowanych dysków.

27. Wykonawca zobowiązany jest do wizualizacji przeprowadzanej Demonstracji na ekranie z użyciem co najmniej jednego rzutnika multimedialnego lub innego wielkoformatowego urządzenia wyświetlającego dostarczonego przez Xxxxxxxxxxxxx celem umożliwienia obserwacji Demonstracji wszystkim obecnym na niej osobom.

28. Zadeklarowane w ofercie funkcjonalności uznaje się za zgodne ze stanem faktycznym, jeśli wykonana demonstracja wykaże, że deklarowane funkcjonalności rzeczywiście są zawarte w oferowanym

systemie i działają prawidłowo, zgodnie z ich przeznaczeniem tzn., że Próbka ma właściwości opisane w ofercie Wykonawcy i wymaganiach SIWZ. Niezidentyfikowanie w trakcie trwania Demonstracji w Próbce określonej właściwości przedmiotu oferty uznawane jest przez Zamawiającego za brak takiej właściwości w odniesieniu do oferowanego przez Wykonawcę rozwiązania i będzie skutkowało odrzuceniem oferty tegoż Wykonawcy na podstawie art. 89 ust . 1, pkt 2ustawy Pzp.

29. Data i godzina wykonywania demonstracji przez Wykonawców zostanie ustalona przez Zamawiającego wg następujących zasad:

1) Kolejność demonstracji wyznaczona jest kolejnością składania ofert do Zamawiającego.

2) Demonstracje próbek z poszczególnymi Wykonawcami będą odbywały się w kolejne dni robocze. Zamawiający ma prawo wyznaczyć termin demonstracji próbki na kolejny dzień roboczy, następujący po dniu przekazania informacji o terminie demonstracji próbki.

3) W przypadku spóźnienia się Wykonawcy na wyznaczoną godzinę demonstracji próbki, Zamawiający odczeka 3 godziny, w przypadku nie stawienia się Wykonawcy w tym terminie Zamawiający uzna ofertę za niezgodną z SIWZ i oferta taka zostanie odrzucona na podstawie art. 89 ust. 1 pkt 2 ustawy

4) Zmiana terminu Demonstracji (godziny lub daty i godziny) może nastąpić tylko w przypadku zaistnienia tzw. „siły wyższej".

V. Procedura przeprowadzania testów:

1. Demonstracja, czyli badanie (oględziny) Próbki, dokonana będzie poprzez realizację scenariuszy testowych i sprawdzeniu czy Próbkę cechują te funkcjonalności, które Wykonawca potwierdził w formularzu oferty i które wymagane są zapisami SIWZ. Zamawiający zastrzega sobie możliwość sprawdzenia jedynie części zadeklarowanej przez Wykonawcę funkcjonalności.

2. Wykonawca w trakcie Demonstracji zobowiązany jest zapisywać, na żądanie Zamawiającego, zrzuty ekranów i pliki raportów na nośnik pamięci masowej w kartotece o nazwie Zrzuty.

3. Zamawiający szacuje czas pojedynczej demonstracji wraz z jej przygotowaniem na 4-8 godzin.

4. Przebieg demonstracji będzie protokołowany.

UWAGA!

Zamawiający przedstawia w formie załącznika do niniejszych wytycznych próbne pliki na których odbędzie się demonstracja próbek Wykonawców.

Załącznik nr 2 do SIWZ

ISTOTNE POSTANOWIENIA UMOWY

Umowa nr ……….

zawarta w dniu r. w Warszawie pomiędzy:

Państwowy Instytut Geologiczny - Państwowy Instytut Badawczy

z siedzibą w Warszawie (kod pocztowy 00-975), przy xx. Xxxxxxxxxx 0, wpisanym do Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy dla m. st. Warszawy XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem KRS: 0000122099, posiadającym numer NIP: 525-000-80- 40 oraz numer REGON 000332133, zwanym dalej „Zamawiającym”, który reprezentuje:

Pan – p.o. Dyrektora Państwowego Instytutu Geologicznego – Państwowego Instytutu

Badawczego

a firmą …………………………………..

z siedzibą …………….. (kod pocztowy ……………), przy ul. …………………….., wpisaną do Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy dla ……….. …..Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem KRS: …………………………, posiadającą numer NIP:

……………………… oraz numer REGON …………………, zwaną dalej „Wykonawcą”, którą reprezentuje:

Pan Członek Zarządu

zwanymi dalej „Stronami” lub „Stroną” niniejszej umowy, zwanej dalej „Umową”.

Umowa została zawarta w wyniku przeprowadzonego postępowania o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego zgodnie z ustawą z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (t.j. Dz. U. z 2015 r. poz. 2164), – nr postępowania EZ /2016

Nazwa	Definicja
Awaria	Oznacza Wadę powodującą brak możliwości wykorzystywania którejkolwiek z funkcji Systemu przez wszystkich użytkowników.
Błąd Krytyczny	Oznacza Wadę powodującą takie działanie lub brak działania funkcji użytkownika, które uniemożliwia użytkownikom Systemu realizację przynajmniej jednej głównej funkcjonalności Systemu.
Błąd Niekrytyczny	Oznacza Wadę o niewielkim stopniu uciążliwości dla Zamawiającego, niebędącą Awarią ani Błędem Krytycznym.
BA	Business Analytics
BI	Business Intelligence
COTS	(Commercial Of the Shelf) Wytwarzane seryjnie, gotowe komercyjne oprogramowanie, standardowo dostępne na rynku dla każdego nabywcy w sprzedaży hurtowej lub detalicznej w formie gotowego produktu, przynajmniej od 3 lat.
Czas Reakcji	Czas od momentu zgłoszenia Wady do momentu potwierdzenia Wady przez Wykonawcę.
DIP	Dokumentacja Inicjowania Projektu - podstawowy dokument zarządczy projektu, zgodnie z metodyką PRINCE2 2009, opisujący x.xx. sposób realizacji prac i zarządzania projektem.
Dzień roboczy	Każdy dzień od poniedziałku do piątku z wyłączeniem dni ustawowo wolnych od pracy w Rzeczpospolitej Polskiej oraz dni ustalonych za wolne zarządzeniem

	Dyrektora PIG-PIB.
Incydent	Oznacza każde nieprawidłowe działanie Systemu Informatycznego; Incydent może być spowodowany w szczególności Wadą.
Iteracja wdrożenia Systemu	Etap wdrożenia Systemu szczegółowo opisany w rozdziale 5 OPZ.
Kierownik Projektu	Przedstawiciel Zamawiającego / Wykonawcy odpowiedzialny za zarządzanie zespołem po stronie Zamawiającego / Wykonawcy, upoważniony do odbiorów wykonanego Przedmiotu Umowy poprzez podpisywanie Protokołów Odbioru oraz upoważniony do podpisywania wszelkich dokumentów zawierających ustalenia powstające w trakcie realizacji Umowy.
Maintenance	Usługa wsparcia dla Oprogramowania.
Oprogramowanie narzędziowe	Oprogramowanie typu COTS będące częścią Systemu, zainstalowane na potrzeby Systemu.
OPZ	Opis przedmiotu zamówienia, będący załącznikiem nr …. do SIWZ.
Plan Testów Akceptacyjnych, PTA	Dokument opisujący testy funkcjonalne i niefunkcjonalne Systemu wykonywane przez Zamawiającego, których celem jest weryfikacja działania Systemu pod kątem spełnienia wymagań Zamawiającego. PTA zawiera scenariusze testowe, które składają się z kroków testowych opisujących interakcję użytkownika z Systemem oraz oczekiwane rezultaty poprawnego wykonania kroku.
Projekt	Projekt (zgodnie z metodyką PRINCE2), w ramach którego będzie realizowane niniejsze zamówienie.
Protokół Przekazania	Dokument podpisany przez upoważnionych przedstawicieli Zamawiającego i Wykonawcy, którego wzór stanowi Załącznik nr …. do Umowy.
Protokół Odbioru	Dokument podpisany przez upoważnionych przedstawicieli Zamawiającego i Wykonawcy, którego wzór stanowi Załącznik nr …. do Umowy.
PSH	Państwowa Służba Hydrogeologiczna.
SPD PSH	System przetwarzania danych PSH.
Wada	Oznacza Awarię, Błąd Krytyczny lub Błąd Niekrytyczny, którego przyczyną jest niewłaściwe funkcjonowanie Systemu.
SIWZ	Specyfikacja Istotnych Warunków Zamówienia wraz z załącznikami, będąca Załącznikiem nr … do Umowy.
System	Oprogramowanie narzędziowe wraz oprogramowaniem (raporty, analizy, kokpity) wykonanym w ramach realizacji niniejszego Zamówienia w oparciu o oprogramowanie narzędziowe.
Zamówienie	Niniejsze zamówienie.

§ 1

Przedmiot Umowy

1. Przedmiotem Umowy jest opracowanie i uruchomienie e-Usług z obszarów PSG i PSH poprzez: wykonanie, dostawę, instalację, uruchomienie i wdrożenie oraz zakup licencji oprogramowania do uruchomienia rozwiązania rozszerzającego działający w PIG-PIB system do monitorowania procesów digitalizacji dokumentów w NAG PIG-PIB o nowe procesy i moduły opisane szczegółowo w Opisie Przedmiotu Zamówienia (OPZ), stanowiącym wraz ze Specyfikacją Istotnych Warunków Zamówienia (SIWZ) Załącznik nr 1 do Umowy.

2. Oferowane rozwiązanie musi rozszerzać działający w PIG-PIB system do monitorowania procesów digitalizacji dokumentów w NAG PIG-PIB o następujące nowe procesy i moduły:

A. Moduł e-Usług:

a. e-Usługa „Zgłoszenie osuwiska.” świadczona przez PIG-PIB wraz z obsługą procesu.

b. e-Usługa „Stopień wykorzystania zasobów wód podziemnych.” – świadczona przez PIG- PIB wraz z obsługą procesu.

c. e-Usługa „Obsługa wniosku o udostępnienie danych (NAG/PSG)” - świadczona przez PIG-PIB wraz z obsługą procesu.

d. e-Usługa „Obsługa wniosku o udostępnienie danych (PSH)” - świadczona przez PIG- PIB wraz z obsługą procesu.

e. e-Usługa „Georaporty” – świadczona przez PIG-PIB wraz z obsługą procesu.

B. Moduł Pracy Grupowej:

a. Komponent Komunikacji.

b. Komponent Kancelaria.

c. Komponent Skład chronologiczny.

d. Komponent Archiwum zakładowe.

e. Komponent Przepływ informacji o sprawach.

f. Komponent „Moduł raportowania”.

C. Moduł Repozytorium:

a. Repozytorium Plików „Ciężkich”,

b. Repozytorium dokumentów,

c. Repozytorium aktów własnych,

d. Repozytorium projektowe.

D. Komponent OCR.

3. Wykonawca dostarczy w terminie 5 dni roboczych od dnia podpisania Umowy lub odpowiednio na 5 dni roboczych przed rozpoczęciem kolejnej iteracji projekt szczegółowego Harmonogramu realizacji zadań, do akceptacji przez Zamawiającego. Zatwierdzenie Harmonogramu lub wniesienie uwag przez Zamawiającego nastąpi w terminie do 5 dni roboczych od dnia dostarczenia jego projektu.

4. W miarę postępu prac Wykonawca jest zobowiązany do aktualizacji Harmonogramu w zakresie raportującym poziom realizacji poszczególnych zadań.

5. Dla dostarczonego oprogramowania systemowego Wykonawca zapewni wymagane wsparcie od jego producenta lub podmiotu uprawnionego przez producenta do dnia wygaśnięcia gwarancji na dostarczony System.

6. Szczegółowy Opis Przedmiotu Zamówienia (OPZ), w tym wymaganych funkcjonalności Systemu zawiera Załącznik nr 1 do Umowy.

§ 2

Termin i miejsce wykonania

1. Przedmiot Umowy zostanie wykonany w całości w terminie 9 miesięcy od dnia podpisania Umowy, zgodnie z harmonogramem ustalonym w DIP, przy czym odbiór ostatniej iteracji budowy Systemu nie może nastąpić później niż 7 miesięcy od daty podpisania umowy.

2. Dostawa licencji oprogramowania nastąpi nie później niż w ciągu 3 dni roboczych od dnia podpisania Umowy, lecz nie później niż do dnia 29 grudnia 2016 r.;

3. Usługi Maintenance będą świadczone przez okres 1 rok licząc od dnia odbioru dostawy licencji oprogramowania.

4. Usługi wsparcia wdrożonego Systemu będą świadczone przez okres 2 lat licząc od dnia odbioru pierwszej Iteracji wdrożenia Systemu.

5. Miejscem realizacji Przedmiotu Umowy jest siedziba Zamawiającego, chyba że Strony Umowy ustalą inaczej.

§ 3

Wynagrodzenie i warunki płatności

1. Łączne wynagrodzenie umowne z tytułu realizacji Umowy wynosi ………………………zł netto (słownie: …………………………… złotych), powiększone o kwotę podatku od towarów i usług (VAT), w wysokości ……………0 zł (słownie: ………………… złotych), co stanowi kwotę

…………….. zł brutto (słownie złotych).

2. Wynagrodzenie za wykonanie Przedmiotu Umowy wynosi:

a. Za dostawę licencji oprogramowania …………………… zł netto (słownie:…………………….), powiększone o kwotę podatku od towarów i usług (VAT), w

wysokości ………………… zł (słownie: …………………. złotych), co stanowi kwotę

…………….. zł brutto (słownie złotych).

b. Za wykonanie I Iteracji wdrożenia Systemu - 25% wartości netto Umowy pomniejszonej o wartości określone w pkt a, f i g, tj. …………… zł netto (słownie: …………………..

złotych), powiększone o kwotę podatku od towarów i usług (VAT), w wysokości

………………….. zł (słownie: …………. złotych), co stanowi kwotę ………… zł brutto (słownie złotych).

c. Za wykonanie II Iteracji wdrożenia Systemu - 25% wartości netto Umowy, pomniejszonej o wartości określone w pkt a, f i g, tj. …………… zł netto (słownie: …………………..

złotych), powiększone o kwotę podatku od towarów i usług (VAT), w wysokości

………………….. zł (słownie: …………. złotych), co stanowi kwotę ………… zł brutto (słownie złotych).

d. Za wykonanie III Iteracji wdrożenia Systemu - 25% wartości netto Umowy, pomniejszonej o wartości określone w pkt a, f i g, tj. …………… zł netto (słownie: …………………..

złotych), powiększone o kwotę podatku od towarów i usług (VAT), w wysokości

………………….. zł (słownie: …………. złotych), co stanowi kwotę ………… zł brutto (słownie złotych).

e. Za wykonanie IV Iteracji wdrożenia Systemu - 25% wartości netto Umowy, pomniejszonej o wartości określone w pkt a, f i g, tj. …………… zł netto (słownie: …………………..

złotych), powiększone o kwotę podatku od towarów i usług (VAT), w wysokości

………………….. zł (słownie: …………. złotych), co stanowi kwotę ………… zł brutto (słownie złotych).

f. Za świadczenie usługi: Maintenance ……………….. zł netto (słownie złotych),

powiększone o kwotę podatku od towarów i usług (VAT), w wysokości zł

(słownie: …………. złotych), co stanowi kwotę ……………… zł brutto (słownie ………….

złotych)

g. Za świadczenie usługi: wsparcia wdrażanego Systemu maksimum zł

netto (słownie: ………………… złotych), powiększone o kwotę podatku od towarów i usług (VAT), w wysokości …………………… zł (słownie złotych), co stanowi kwotę

……………….. zł brutto (słownie ……………. złotych), przy wykorzystaniu przez Zamawiającego całej puli roboczogodzin do wykorzystania na zlecanie usług wsparcia

wdrażanego Systemu.

3. Wynagrodzenie łączne, o którym mowa w ust. 1 obejmuje wszelkie koszty związane z wykonywaniem całego Przedmiotu Umowy z uwzględnieniem podatku od towarów i usług VAT, innych opłat i podatków.

4. Warunkiem wystawienia faktury przez Wykonawcę i wypłaty wynagrodzenia jest prawidłowo podpisany przez obie Strony Protokół Odbioru, przy czym przez prawidłowo podpisany Protokół uznaje się Protokół podpisany bez uwag.

5. Zapłata wynagrodzenia, o którym mowa w pkt. 2 pkt. a i f nastąpi na podstawie faktury wystawionej przez Wykonawcę po podpisaniu przez Strony Protokołu Odbioru dostawy licencji oprogramowania.

6. Wynagrodzenie z tytułu wykonania poszczególnych zleceń usługi wsparcia stanowić będzie iloczyn roboczogodzin oraz jednostkowej stawki za roboczogodzinę ustalonej jako …………. zł netto (słownie: ……………… złotych) plus należny podatek VAT co stanowi kwotę brutto zł

(słownie złotych).

7. Zapłata wynagrodzenia, o którym mowa w ust. 2 pkt. g nastąpi każdorazowo na podstawie faktury wystawionej przez Wykonawcę po podpisaniu przez Strony Protokołu Odbioru każdej zleconej usługi wsparcia, w wysokości określonej na formularzu zlecenia danej usługi wsparcia, zgodnie z formularzem stanowiącym Załącznik nr 5 do Umowy.

§ 4

Obowiązki Zamawiającego

1. Zamawiający zobowiązany jest do udostępnienia posiadanych informacji, materiałów i dokumentacji na wniosek Wykonawcy, oraz zapewni zdalny dostęp do systemów bazodanowych PIG-PIB poprzez

szynę usług w zakresie niezbędnym dla prawidłowej realizacji Przedmiotu Umowy.

2. Zamawiający zapewni współpracę swoich pracowników z przedstawicielami Wykonawcy w okresie realizacji Umowy.

3. Zamawiający zobowiązuje się do niezwłocznego ustosunkowywania się do problemów zgłaszanych przez Wykonawcę.

4. W ramach realizacji Przedmiotu Umowy, Zamawiający zobowiązuje się do zapewnienia Wykonawcy warunków niezbędnych do realizacji Umowy, a w szczególności zapewni:

1) dostęp do swojej lokalizacji upoważnionym pracownikom Wykonawcy;

2) wstęp przedstawicielom Wykonawcy do pomieszczeń w miejscach niezbędnych do wykonania czynności związanych z instalacją, wdrożeniem Systemu i świadczeniem usług wsparcia, Maintenance i gwarancji;

3) wstęp do pomieszczeń o charakterze serwerowni w celu wykonania niezbędnych czynności związanych z instalacją oraz wdrożeniem Systemu, będzie odbywał się pod nadzorem pracowników Zamawiającego, a za wszelkie zawinione szkody odpowiedzialność ponosi Wykonawca;

4) zdalny dostęp do Systemu z wykorzystaniem połączeń internetowych lub łączy komutowanych, z uwzględnieniem możliwości techniczno-organizacyjnych i warunków Zamawiającego (wymagane jest w tym przypadku wydanie odrębnej, pisemnej zgody Zamawiającego);

5) wyznaczenie osoby pełniącej funkcję Kierownika Projektu po stronie Zamawiającego oraz Przewodniczącego Komitetu Sterującego i Głównego Użytkownika w Komitecie Sterującym w rozumieniu metodyki PRINCE2;

6) wydanie przedstawicielom Wykonawcy upoważnień do przetwarzania danych osobowych pracowników Zamawiającego, z uwagi na zakres wykonywanych czynności;

7) W przypadku gdy wystąpi konieczność powierzenia przetwarzania danych osobowych pracowników Zamawiającego Wykonawcy umowy Zgodnie z ustawą (UODO) z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U. z 2016 r., poz.922), Zamawiający podpisze z Wykonawcą odrębną Umowę o powierzeniu przetwarzania danych osobowych, w celu realizacji niniejszej umowy, której wzór stanowi Załącznik Nr 9 do Umowy.

§ 5

Obowiązki Wykonawcy

1. Wykonawca zobowiązuje się wykonać Przedmiot Umowy z zachowaniem najwyższych standardów jakości, zapewniając realizację zadań i prac oraz produktów, jakie zostały określone w OPZ.

2. Wykonawca zobowiązuje się do zapewnienia środków, narzędzi i nadzoru, niezbędnych do wykonania Przedmiotu Umowy, a ponadto wykonać Przedmiot Umowy z należytą starannością, przy zachowaniu zasad współczesnej wiedzy i najlepszych praktyk, właściwych dla rodzaju usługi będącej Przedmiotem Umowy, obowiązujących w tym zakresie przepisów.

3. Wykonawca zobowiązany jest do zastosowania wszystkich rozwiązań informatycznych oraz wykonania wszelkich usług wymaganych w celu instalacji, konfiguracji i wdrożenia Systemu oraz świadczenia usług wsparcia, Maintenance i gwarancji (w tym zarządzania projektem, zapewnienia jakości, testowania i przekazania do eksploatacji) według najlepszych obowiązujących standardów uwzględniających optymalne założenia technicznie i ekonomicznie, zgodnie z wymaganiami, procedurami i odpowiednimi przepisami oraz wszelkimi innymi źródłami wskazanymi w Umowie.

4. Wykonawca zobowiązuje się do realizacji Umowy terminowo, z należytą starannością i zgodnie z obowiązującymi zasadami najlepszej praktyki zawodowej oraz obowiązującymi przepisami prawa i postanowieniami Umowy.

5. Wykonawca oświadcza, że posiada umiejętności i kwalifikacje oczekiwane od kompetentnego dostawcy systemów informatycznych, zgodnie z zasadami dobrej praktyki zawodowej, stosowanej w sektorze informatycznym, które są niezbędne do należytego wykonania Przedmiotu Umowy.

6. Wykonawca potwierdza, iż zawiera Umowę po odpowiednim zapoznaniu się z danymi przekazanymi przez Zamawiającego oraz oświadcza, że zapewnia prawidłowe działanie Systemu wykonanego w

Document Metadata

Table of Contents

PRZETARGU NIEOGRANICZONEGO

Document Metadata