SPECYFIKACJA

SPECYFIKACJA

ISTOTNYCH WARUNKÓW ZAMÓWIENIA

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

PRZETARGU NIEOGRANICZONEGO

na podstawie art. 39 ustawy z 29 stycznia 2004 r. - Prawo zamówień publicznych (tekst jedn. Dz. U. z 2013 r. poz. 907 z późn. zm.), o wartości szacunkowej zamówienia poniżej 207 000 EURO.

PRZEDMIOT ZAMÓWIENIA:

Dostawa licencji oprogramowania wraz z 12 miesięczną asystą techniczną oraz warsztatami dla Państwowego Instytutu Geologicznego – Państwowego Instytutu Badawczego

Sygn. postępowania: EZ-240-22/2015

ZATWIERDZAM:

Data: 10.03.2015 r.

Kierownik

Państwowego Instytutu Geologicznego Państwowego Instytutu Badawczego

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

1. „ustawa Pzp” – ustawę z 29 stycznia 2004 r. - Prawo zamówień publicznych (tekst. jedn. Dz. U. z 2013 r. poz. 907 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 poniżej 207 000 euro, zgodnie z przepisami ustawy z 29 stycznia 2004 r. – Prawo zamówień publicznych (tekst jedn. Dz. U. z 2013 r. poz. 907 z późn. zm.).

3. OPIS PRZEDMIOTU ZAMÓWIENIA

3.1. Przedmiotem zamówienia jest Dostawa licencji oprogramowania wraz z 12 miesięczną asystą techniczną oraz warsztatami dla Państwowego Instytutu Geologicznego – Państwowego Instytutu Badawczego.

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

załączniku nr 1 do SIWZ – „Opis przedmiotu zamówienia” - (dalej również „OPZ”); 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:

48000000-8 Pakiety oprogramowania i systemy informatyczne 72611000 - 6 Usługi w zakresie wsparcia technicznego

4. TERMIN WYKONANIA ZAMÓWIENIA

Przedmiot niniejszego zamówienia, zrealizowany będzie przy uwzględnieniu terminów realizacji wskazanych przez Wykonawcę, zgodnych z wymaganiami Zamawiającego.

5. OFERTY CZĘŚCIOWE, WARIANTOWE

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

5.2. Zamawiający nie dopuszcza możliwości składania ofert wariantowych.

6. INFORMACJA O PRZEWIDYWANYCH ZAMÓWIENIACH UZUPEŁNIAJĄCYCH

Zamawiający nie przewiduje możliwości udzielenia zamówień uzupełniających, o których mowa w art. 67 ust. 1 pkt 7 ustawy Pzp.

7. WARUNKI UDZIAŁU W POSTĘPOWANIU. BRAK PODSTAW DO WYKLUCZENIA WYKONAWCY

7.1. O udzielenie zamówienia mogą ubiegać się Wykonawcy, którzy spełniają warunki z art. 22 ust. 1 ustawy Pzp, dotyczące:

7.1.1. posiadania uprawnień do wykonywania określonej działalności lub czynności, jeżeli przepisy prawa nakładają obowiązek ich posiadania;

7.1.2. posiadania wiedzy i doświadczenia;

7.1.3. dysponowania odpowiednim potencjałem technicznym oraz osobami zdolnymi do wykonania zamówienia;

7.1.4. sytuacji ekonomicznej i finansowej.

7.2. O udzielenie zamówienia mogą ubiegać się Wykonawcy, którzy spełniają warunek udziału w postępowaniu dotyczący braku podstaw do wykluczenia z postępowania o udzielenie zamówienia publicznego w okolicznościach, o których mowa w art. 24 ust. 1 ustawy Pzp.

8. OPIS SPOSOBU DOKONYWANIA OCENY SPEŁNIANIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU

Nie dotyczy

9. ZASADY DOKONYWANIA OCENY SPEŁNIANIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU

9.1. Spełnianie warunków opisanych w pkt. 7 SIWZ należy potwierdzić poprzez złożenie oświadczeń oraz dokumentów, o których mowa w pkt. 10 SIWZ.

9.2. Ocena spełniania skonkretyzowanych przez Zamawiającego warunków udziału w postępowaniu zostanie dokonana wg formuły spełnia – nie spełnia.

9.3. Z treści załączonych do oferty dokumentów musi wynikać jednoznacznie, iż Wykonawca wykazał spełnianie warunków udziału w postępowaniu.

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

10. DOKUMENTY SKŁADANE W CELU WYKAZANIA SPEŁNIANIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU ORAZ BRAKU PODSTAW DO WYKLUCZENIA

10.1. W celu oceny spełniania przez Wykonawcę warunków, o których mowa w art. 22 ust. 1 ustawy Pzp, których opis sposobu oceny spełniania został dokonany w pkt. 8 SIWZ, Zamawiający żąda następujących oświadczeń i dokumentów:

10.1.1. Oświadczenia o spełnianiu warunków udziału w postępowaniu, o których mowa w art. 22 ust. 1 ustawy Pzp - na formularzu zgodnym z treścią załącznika nr 4 do SIWZ.

10.2. W celu wykazania braku podstaw do wykluczenia Wykonawcy z postępowania o udzielenie zamówienia w okolicznościach, o których mowa w art. 24 ust. 1 ustawy Pzp, Zamawiający żąda następujących dokumentów:

10.2.1. Oświadczenia o braku postaw do wykluczenia z postępowania o udzielenie zamówienia w okolicznościach, o których mowa w art. 24 ust. 1 ustawy Pzp - na formularzu zgodnym z treścią załącznika nr 5 do SIWZ.

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.2. Aktualnego 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. 1 pkt 2 ustawy, wystawionego nie wcześniej niż 6 miesięcy przed upływem terminu składania ofert.

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.

11. DODATKOWE DOKUMENTY/PEŁNOMOCNICTWO

11.1. Do oferty należy załączyć dokument/-y określające zasady reprezentacji oraz osoby uprawnione do reprezentacji Wykonawcy.

11.2. W przypadku, gdy Wykonawcę reprezentuje pełnomocnik, do oferty należy dołączyć pełnomocnictwo, z którego wynika zakres umocowania, podpisane przez osoby uprawnione do reprezentowania Wykonawcy. Pełnomocnictwo musi być złożone w oryginale albo w kopii poświadczonej notarialnie.

11.3. Wykonawca zgodnie z art. 26 ust. 2d ustawy ma obowiązek złożyć oświadczenie zawierające listę podmiotów należących do tej samej grupy kapitałowej, o której mowa w art. 24 ust. 2 pkt 5 ustawy Prawo zamówień publicznych, albo informację o tym, że Wykonawca nie należy do grupy kapitałowej. Wzór oświadczenia stanowi załącznik nr 6 do SIWZ.

12. OŚWIADCZENIA I DOKUMENTY, JAKIE MAJĄ DOSTARCZYĆ WYKONAWCY MAJĄCY SIEDZIBĘ LUB MIEJSCE ZAMIESZKANIA POZA TERYTORIUM RZECZPOSPOLITEJ POLSKIEJ W CELU POTWIERDZENIA SPEŁNIANIA WARUNKÓW UDZIAŁU W POSTĘPOWANIU (wymagania dla Wykonawców zagranicznych)

12.1. Wykonawcy mający siedzibę lub miejsce zamieszkania poza terytorium Rzeczpospolitej Polskiej składają dokumenty wymienione w pkt. 10 SIWZ z zastrzeżeniem, że zamiast dokumentów, o których mowa w pkt. 10.2 SIWZ:

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

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

12.3. Jeżeli w kraju miejsca zamieszkania osoby lub w kraju, w którym Wykonawca ma siedzibę lub miejsce zamieszkania, nie wydaje się dokumentów, o których mowa w pkt. 12.1.1, zastępuje się je dokumentem zawierającym oświadczenie, w którym określa się także osoby uprawnione do reprezentacji Wykonawcy, złożone przed właściwym organem sądowym, administracyjnym albo organem samorządu zawodowego lub gospodarczego odpowiednio kraju miejsca zamieszkania osoby lub kraju, w którym Wykonawca ma siedzibę lub miejsce zamieszkania, lub przed notariuszem. Postanowienia pkt. 12.2 SIWZ stosuje się odpowiednio.

13. WYMAGANIA

DOTYCZĄCE

DOKUMENTÓW

SKŁADANYCH

PRZEZ

WYKONAWCÓW

13.1. Wymagania dotyczące dokumentów składanych przez Wykonawców reguluje x.xx. rozporządzenie Prezesa Rady Ministrów z 19 lutego 2013 r. w sprawie rodzajów dokumentów, jakich może żądać Zamawiający od Wykonawcy oraz form, w jakich te dokumenty mogą być składane (Dz. U. z 2013 r., poz. 231).

13.2. Oświadczenia, o których mowa w pkt. 10.1.1 oraz 11.3 SIWZ należy przedstawić w oryginale, pozostałe dokumenty, o których mowa w pkt. 10 SIWZ oraz pkt. 12 SIWZ

mogą być złożone w oryginale lub kopii poświadczonej i opatrzonej klauzulą „za zgodność z oryginałem” przez Wykonawcę, z zastrzeżeniem pkt. 13.3 SIWZ. Dokument wielostronicowy przedłożony w formie kopii winien być potwierdzony za zgodność z oryginałem na każdej zapisanej (ponumerowanej) stronie.

13.3. Zgodnie z § 7 ust. 2 rozporządzenia Prezesa Rady Ministrów z 19 lutego 2013 r. w sprawie rodzajów dokumentów, jakich może żądać Zamawiający od Wykonawcy oraz form, w jakich te dokumenty mogą być składane (Dz.U. 2013, poz. 231), w przypadku Wykonawców wspólnie ubiegających się o udzielenie zamówienia oraz w przypadku innych podmiotów, na zasobach których Wykonawca polega na zasadach określonych w art. 26 ust. 2b ustawy, kopie dokumentów dotyczących odpowiednio Wykonawcy lub tych podmiotów są poświadczane za zgodność z oryginałem odpowiednio przez Wykonawcę lub te podmioty.

13.4. Pełnomocnictwo musi być złożone w oryginale albo w kopii poświadczonej notarialnie.

13.5. Pisemne zobowiązanie innego podmiotu do oddania Wykonawcy do dyspozycji niezbędnych zasobów na okres korzystania z nich przy wykonywaniu zamówienia,

o którym mowa w art. 26 ust. 2b ustawy Pzp, musi być złożone w oryginale.

13.6. Złożenie dokumentu w niewłaściwej formie (np. niepoświadczonej przez Wykonawcę za zgodność z oryginałem odpisy lub kopie) traktowane będzie jak jego brak.

13.7. Postępowanie o udzielenie zamówienia prowadzi się w języku polskim. Dokumenty, oświadczenia oraz pełnomocnictwa sporządzone w języku obcym są składane wraz z tłumaczeniem na język polski.

14. OFERTA SKŁADANA PRZEZ WYKONAWCÓW WSPÓLNIE UBIEGAJĄCYCH SIĘ O UDZIELENIE ZAMÓWIENIA

14.1. Wykonawcy ubiegający się wspólnie o udzielenie zamówienia ustanawiają pełnomocnika do reprezentowania ich w postępowaniu, albo reprezentowania ich w postępowaniu i zawarcia umowy w sprawie zamówienia publicznego. Pełnomocnictwo należy dołączyć do oferty. Pełnomocnictwo musi być złożone w oryginale albo w kopii poświadczonej notarialnie.

14.2. W przypadku wyboru przez Zamawiającego oferty złożonej przez Wykonawców ubiegających się wspólnie o udzielenie zamówienia, mogą oni zostać zobowiązani, najpóźniej przed podpisaniem umowy w sprawie niniejszego zamówienia publicznego, do przedłożenia umowy regulującej ich współpracę.

14.3. Wykonawcy ubiegający się wspólnie o udzielenie zamówienia ponoszą solidarnie odpowiedzialność prawną za realizację zamówienia. Problematykę zobowiązań solidarnych regulują przepisy kodeksu cywilnego.

14.4. Każdy z Wykonawców wspólnie ubiegających się o udzielenie zamówienia zobowiązany jest samodzielnie wykazać spełnianie warunku braku podstaw do wykluczenia z postępowania o udzielenie zamówienia w okolicznościach, o których mowa w art. 24 ust. 1 oraz 24 ust. 2 ustawy Pzp. Pozostałe warunki udziału w postępowaniu, określone w pkt. 8 SIWZ, Wykonawcy wspólnie ubiegający się o udzielenie zamówienia muszą spełniać łącznie.

14.5. Oferta składana przez Wykonawców występujących wspólnie musi zostać utworzona z dokumentów wymienionych w pkt. 10 SIWZ (w razie konieczności – także w pkt. 12 SIWZ) z zastrzeżeniem, iż dokumenty wymienione w pkt. 10.2 SIWZ (i odpowiednio w pkt. 12 SIWZ), składane są przez każdego z Wykonawców osobno.

14.6. Oferta Wykonawców występujących wspólnie musi być podpisana i oznaczona w taki sposób, by prawnie zobowiązywała wszystkie podmioty wspólnie ubiegające się

o udzielenie zamówienia.

15. PODWYKONAWCY

15.1. Zamawiający żąda wskazania przez Wykonawcę w ofercie części zamówienia, której wykonanie powierzy podwykonawcom.

15.2. Informacje o powierzeniu realizacji części zamówienia podwykonawcy należy podać w formularzu „Oferta” (załącznik nr 3 do SIWZ).

16. INFORMACJE O SPOSOBIE POROZUMIEWANIA SIĘ ZAMAWIAJĄCEGO Z WYKONAWCAMI

16.1. Oświadczenia, wnioski, zawiadomienia oraz wszelkie informacje Zamawiający i Wykonawcy przekazują pisemnie, faksem lub drogą elektroniczną, z zastrzeżeniem pkt. 16.2 SIWZ.

16.2. Forma pisemna zastrzeżona jest dla złożenia oferty wraz z załącznikami, w tym dokumentów składanych w celu wykazania spełniania warunków udziału w postępowaniu, a także zmiany oferty.

16.3. Jeżeli Zamawiający lub Wykonawca przekazują dokumenty lub informacje faksem lub drogą elektroniczną, każda ze stron na żądanie drugiej niezwłocznie potwierdza fakt ich otrzymania.

17. OSOBY UPRAWNIONE DO POROZUMIEWANIA SIĘ Z WYKONAWCAMI

Xxxx Xxxxxxxxxxxx (Dział Zamówień Publicznych) tel. + 00 00 000 00 00

fax x00 00 000 00 00

lub e- mail: xxxx.xxxxxxxxxxxx@xxx.xxx.xx

18. TRYB UDZIELANIA WYJAŚNIEŃ DOTYCZĄCYCH TREŚCI SPECYFIKACJI ISTOTNYCH WARUNKÓW ZAMÓWIENIA

18.1. Wykonawca może zwracać się do Zamawiającego o wyjaśnienia treści SIWZ, kierując swoje zapytania pisemnie, faksem lub drogą elektroniczną na adres:

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

nr faksu: + 48 22 459 20 23, e-mail: xxxx.xxxxxxxxxxxx@xxx.xxx.xx

18.2. Zgodnie z art. 38 ust. 1 ustawy Pzp Zamawiający jest obowiązany udzielić wyjaśnień niezwłocznie, jednak nie później niż na 2 dni przed upływem terminu składania ofert, pod warunkiem, że wniosek o wyjaśnienie treści SIWZ 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. Zamawiający przekaże treść zapytań wraz z wyjaśnieniami wszystkim Wykonawcom, którym przekazano SIWZ, bez ujawniania źródła zapytania oraz zamieści na stronie internetowej na której udostępniono SIWZ.

18.3. W uzasadnionych przypadkach Zamawiający może w każdym czasie, przed upływem terminu składania ofert, zmienić treść SIWZ. Dokonane w ten sposób zmiany Zamawiający przekaże niezwłocznie wszystkim Wykonawcom, którym przekazano SIWZ oraz zamieści na stronie internetowej na której zamieszczono SIWZ.

19. WYMAGANIA DOTYCZĄCE WADIUM

Zamawiający nie wymaga wniesienia wadium.

20. TERMIN ZWIĄZANIA OFERTĄ

20.1. Termin związania ofertą wynosi 30 dni. Bieg terminu rozpoczyna się wraz z upływem terminu składania ofert.

20.2. Zgodnie z art. 85 ust. 2 ustawy Pzp, Wykonawca samodzielnie lub na wniosek Zamawiającego może przedłużyć termin związania ofertą, z tym że Zamawiający może tylko raz, co najmniej na 3 dni przed upływem terminu związania ofertą, zwrócić się do Wykonawców o wyrażenie zgody na przedłużenie tego terminu o oznaczony okres, nie dłuższy jednak niż 60 dni.

21. OPIS SPOSOBU PRZYGOTOWANIA OFERTY

21.1. Ofertę należy złożyć w formie pisemnej pod rygorem nieważności.

21.2. Oferta musi zawierać co najmniej:

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

21.2.2. wypełniony „Formularz cenowy”, który stanowi załącznik nr 3a do SIWZ;

21.2.3. oświadczenia i dokumenty, o których mowa w pkt. 10 i 11.3 SIWZ (w razie konieczności – także w pkt. 12 SIWZ);

21.2.4. dokument pełnomocnictwa (jeśli dotyczy).

21.3. Oferta powinna być podpisana przez osobę uprawnioną do reprezentowania Wykonawcy, zgodnie z formą reprezentacji Wykonawcy określoną w rejestrze lub innym dokumencie, właściwym dla danej formy organizacyjnej Wykonawcy albo przez odpowiednio umocowanego przedstawiciela Wykonawcy.

21.4. Ofertę należy sporządzić zgodnie z treścią SIWZ oraz treścią zawartą w formularzach stanowiących załączniki do SIWZ.

21.5. Wykonawca może złożyć ofertę na własnych formularzach, jednakże ich treść musi być zgodna z treścią formularzy załączonych do SIWZ.

21.6. Oferta musi być napisana w języku polskim, pismem czytelnym.

21.7. Wszystkie zapisane strony oferty, za wyjątkiem oryginału dokumentu, który nie jest wystawiony przez Wykonawcę, a stanowi część składową oferty, powinny być opatrzone podpisem wraz z pieczątką osoby lub osób uprawnionych do występowania w obrocie prawnym w imieniu Xxxxxxxxx, bądź przez upoważnionego przedstawiciela Wykonawcy (w tym przypadku upoważnienie do podpisywania dokumentów musi być dołączone do oferty).

21.8. Wszystkie strony oferty muszą być spięte w sposób uniemożliwiający dekompletację oferty, ponumerowane kolejnymi numerami. Dopuszcza się własną numerację dokumentów ofertowych pod warunkiem zachowania ciągłości numeracji stron.

21.9. Wszelkie poprawki lub zmiany w tekście oferty powinny być naniesione czytelnie oraz opatrzone podpisem wraz z pieczątką osoby uprawnionej i dodatkowo opatrzone datą dokonania poprawki. Złożenie oferty zawierającej rozwiązania alternatywne spowoduje odrzucenie oferty.

21.10. Każdy Wykonawca może złożyć w niniejszym postępowaniu tylko jedną ofertę. Za równoznaczne ze złożeniem więcej niż jednej oferty przez tego samego Wykonawcę zostanie uznana sytuacja, w której ten sam podmiot występuje w dwóch lub więcej ofertach składanych wspólnie lub jest samodzielnym Wykonawcą, a jednocześnie jest uczestnikiem oferty wspólnej.

21.11. Zastrzeżeniu podlegają tylko te dokumenty wchodzące w skład oferty, które zawierają tajemnicę przedsiębiorstwa w rozumieniu art. 11 ust. 4 ustawy z dnia 16 kwietnia 1993r. o zwalczaniu nieuczciwej konkurencji (tj. Xx. X. x 0000 x. Xx 000, poz. 1503 z późn. zm.). Wykonawca musi w sposób nie budzący wątpliwości zastrzec nie później niż w terminie

składania ofert, które informacje stanowiące tajemnicę przedsiębiorstwa nie mogą być udostępniane oraz wykazać, że zastrzeżone informacje stanowią tajemnicę przedsiębiorstwa.

Informacje te powinny być umieszczone w osobnym wewnętrznym opakowaniu, trwale ze sobą połączone i ponumerowane oraz oznaczone klauzulą: „NIE UDOSTĘPNIAĆ – INFORMACJE STANOWIĄ TAJEMNICĘ PRZEDSIĘBIORSTWA W ROZUMIENIU ART. 11 UST. 4 USTAWY O ZWALCZANIU NIEUCZCIWEJ KONKURENCJI”.

Wykonawca nie może zastrzec informacji, o których mowa w art. 86 ust 4 ustawy

22. ZALECENIA DOTYCZĄCE OPAKOWANIA I OZNAKOWANIA OFERT

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

22.2. Koperta powinna być zaadresowana na adres:

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

oraz powinna być opisana następująco:

Oferta na: Dostawa licencji oprogramowania wraz z 12 miesięczną asystą techniczną oraz warsztatami dla Państwowego Instytutu Geologicznego – Państwowego

Instytutu Badawczego Sygn. postępowanie EZ-240-22/2015.

Nie otwierać przed godziną 12:15, 18.03.2015 roku.

22.3.Konsekwencje złożenia oferty niezgodnie z w/w opisem ponosi Wykonawca.

23. TERMIN I MIEJSCE SKŁADANIA OFERT

23.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)

23.2. Termin składania ofert upływa 18.03.2015 r. o godz. 12:00

23.3.Oferty nadesłane pocztą będą zakwalifikowane do postępowania przetargowego pod warunkiem ich dostarczenia przez pocztę do terminu określonego w pkt. 23.2 SIWZ. Decyduje data wpływu do Kancelarii Ogólnej PIG-PIB poświadczona stemplem z wpisaną godziną.

23.4.Zamawiający niezwłocznie zawiadamia Wykonawcę o złożeniu oferty po terminie oraz zwraca ofertę niezwłocznie.

24. OTWARCIE OFERT

24.1. Otwarcie złożonych ofert nastąpi w dniu 18.03.2015 r. o godz. 12:15, w siedzibie Zamawiającego w bud A, pok. nr 220.

24.2.Otwarcie ofert jest jawne.

24.3.Bezpośrednio przed otwarciem ofert Zamawiający poda kwotę, jaką zamierza przeznaczyć na sfinansowanie zamówienia.

24.4. Po otwarciu każdej z ofert, do wiadomości zebranym, zostaną podane dane zgodnie z art. 86 ust. 4 ustawy Pzp.

24.5. Zamawiający na wniosek Wykonawcy nieobecnego na otwarciu ofert przekaże informacje, o których mowa w pkt. 24.3 i 24.4 SIWZ.

25. ZMIANA I WYCOFANIE OFERTY

25.1. Wykonawca przed upływem terminu do składania ofert ma prawo:

25.1.1. wycofać ofertę poprzez złożenie pisemnego powiadomienia z napisem na kopercie

„WYCOFANIE”;

25.1.2. zmienić ofertę - powiadomienie o wprowadzeniu zmian musi być złożone wg takich samych zasad jak składana oferta, odpowiednio oznakowane z dopiskiem

„ZMIANA”.

26. OPIS SPOSOBU OBLICZANIA CENY OFERTY

26.1. Cena w formularzu „Oferta” musi obejmować wszystkie koszty związane z realizacją przedmiotu zamówienia.

26.2.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.

26.3.Jeżeli Zamawiającemu zostanie złożona oferta, której wybór prowadziłby do powstania obowiązku podatkowego Zamawiającego zgodnie z przepisami o podatku od towarów i usług w zakresie dotyczącym wewnątrz wspólnotowego nabycia towarów, Zamawiający w celu oceny takiej oferty doliczy do przedstawionej w niej ceny podatek od towarów i usług, który miałby obowiązek wpłacić zgodnie z obowiązującymi przepisami.

26.4.Zamawiający zwraca się o udzielenie wyjaśnień jeżeli cena oferty wydaje się rażąco niska w stosunku do przedmiotu zamówienia i budzi 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, w szczególności jest niższa o 30% od wartości zamówienia lub średniej arytmetycznej cen wszystkich złożonych ofert.

26.5.Obowiązek wykazania, że oferta nie zawiera rażąco niskiej ceny spoczywa na Wykonawcy.

27. OPIS KRYTERIÓW, KTÓRYMI ZAMAWIAJĄCY BĘDZIE SIĘ KIEROWAŁ PRZY WYBORZE OFERTY WRAZ Z PODANIEM ZNACZENIA KRYTERIÓW

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

27.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 2	Cena (Cof) Termin dostawy licencji do Zamawiającego (Tof)	90 10

27.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.

27.4.Sposób obliczenia wartości punktowej w kryterium:

27.4.1. Cena:

Cof =

najniższa cena cena oferty badanej

x 90 pkt

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

27.4.2. Termin dostawy licencji do Zamawiającego

Tof =

termin najkrótszy

termin wskazany w ofercie badanej

x 10 pkt

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

Maksymalny termin dostawy licencji do Zamawiającego to 3 dni. Minimalny termin dostawy licencji do Zamawiającego to 1 dzień.

Jeżeli wykonawca złoży ofertę, w której zaoferuje termin wykonania zamówienia dłuższy niż 3 dni lub krótszy niż 1 dzien wówczas jego oferta zostanie odrzucona (jako niezgodna z SIWZ). Nie podanie terminu wykonania również będzie skutkowało odrzuceniem oferty.

27.5. Za ofertę najkorzystniejszą uznana zostanie oferta, która będzie przedstawiała najkorzystniejszy bilans kryteriów wymienionych powyżej (otrzyma najwyższą liczbę przyznanych punktów), pozostałe oferty zostaną sklasyfikowane zgodnie z ilością uzyskanych punktów.

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

28.1. W przypadku, gdy jako najkorzystniejsza zostanie uznana oferta złożona przez Wykonawców wspólnie ubiegających się o udzielenie zamówienia, przed podpisaniem umowy Wykonawcy ci mogą zostać zobowiązani do przedłożenia Zamawiającemu umowy regulującej ich współpracę.

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

29. WARUNKI UMOWY O WYKONANIE ZAMÓWIENIA

29.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.

29.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.

29.3. Przewidywane zmiany umowy i warunki ich wprowadzenia zostały określone w załączniku nr 2 do SIWZ – Istotne postanowienia umowy.

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

30.1. Wykonawcom, a także innemu podmiotowi, jeżeli ma lub miał interes w uzyskaniu zamówienia oraz poniósł lub może ponieść szkodę w wyniku naruszenia przez Zamawiającego przepisów ustawy Pzp, przysługują środki ochrony prawnej na zasadach przewidzianych w Dziale VI ustawy Pzp (art. 179 – art. 198 a-g).

30.2. Odwołanie wnosi się do Prezesa Krajowej Izby Odwoławczej w formie pisemnej albo elektronicznej opatrzonej bezpiecznym podpisem elektronicznym weryfikowanym za pomocą ważnego kwalifikowanego certyfikatu.

30.3. Odwołujący przesyła kopię odwołania Zamawiającemu przed upływem terminu do wniesienia odwołania w taki sposób, aby mógł on zapoznać się z jego treścią przed upływem tego terminu.

30.4. Odwołanie wnosi się w terminach określonych w ustawie Pzp w art. 182 ustawy Pzp.

31. POSTANOWIENIA KOŃCOWE

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

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

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

32. ZAŁĄCZNIKI:

32.1. Załącznik nr 1 do SIWZ – Opis przedmiotu zamówienia; 32.2.Załącznik nr 2 do SIWZ – Istotne postanowienia umowy; 32.3.Załącznik nr 3 do SIWZ – Formularz „Oferta”; 32.4.Załącznik nr 3a do SIWZ – „Formularz cenowy”; 32.5.Załącznik nr 4 do SIWZ – Oświadczenie z art. 22 ustawy Pzp;

32.6.Załącznik nr 5 do SIWZ – Oświadczenie z art. 24 ust. 1 ustawy Pzp;

32.7.Załącznik nr 6 do SIWZ – Oświadczenie z art. 24 ust. 2 pkt.5 ustawy Pzp.

Załącznik nr 1 do SIWZ

OPIS PRZEDMIOTU ZAMÓWIENIA

1. Przedmiot zamówienia:

Dostawa licencji oprogramowania wraz z 12 miesięczną asystą techniczną oraz warsztatami dla Państwowego Instytutu Geologicznego – Państwowego Instytutu Badawczego

Aktualnie posiadane licencje:

Nazwa licencji	Ilość	Rodzaj
SOA Suite for Oracle Middleware	2	Procesor
Oracle Internet Application Server Enterprise Edition	2	Procesor

Tabela 1: Posiadane licencje

Aktualnie powyższe oprogramowanie jest częścią środowiska Zamawiającego. W środowisku tym działa szereg aplikacji, z czego duża część zawiera moduły napisane w technologii Oracle Forms i osadzone na serwerze Oracle Internet Application Server Enterprise Edition. Repozytorium danych dla tych aplikacji stanowi baza Oracle Database Enterprise Edition.

Wymagane licencje:

Nazwa licencji	Ilość	Rodzaj	Uwagi
SOA Suite for Oracle Middleware lub równoważne	2	Procesor	Usługa wsparcia technicznego świadczona na poziomie Software Updates License & Support.
Weblogic Suite lub równoważne	4	Procesor	Usługa wsparcia technicznego świadczona na poziomie Software Updates License & Support.
Unified Business Process Management Suite lub równoważne	2	Procesor	Usługa wsparcia technicznego świadczona na poziomie Software Updates License & Support.
SOA Suite for Oracle Middleware lub równoważne	20	NUP	Usługa wsparcia technicznego świadczona na poziomie Software Updates License & Support.
WebLogic Suite lub równoważne	20	NUP	Usługa wsparcia technicznego świadczona na poziomie Software Updates License & Support.
Unified Business	20	NUP	Usługa wsparcia technicznego świadczona na

Process Management Suite lub równoważne poziomie Software Updates License & Support.

Tabela 2: Lista licencji wymaganych po migracji.

Wykonawca zobowiązany jest do dostarczenia Certyfikatów Asysty Technicznej dla oprogramowania wymienionego w pkt. 1, tabela 2.

Wykonawca zobowiązany jest do udzielenia wsparcia zamawiającemu przy instalacji dostarczonego oprogramowania na środowisku produkcyjnym.

Licencje muszą być dostarczone do 31.03.2015 roku.

Zamawiający dopuszcza możliwość przedstawienia w ofercie oprogramowania równoważnego, innego niż podane w Tabeli nr 2, w opisie przedmiotu zamówienia, pod warunkiem, że oferowane oprogramowanie będzie spełniało następujące wymagania:

1. Wymagania odnośnie standardów jakie musi spełniać infrastruktura serwera aplikacji: Infrastruktura serwera aplikacji musi posiadać wsparcie dla Java SE wersja 7 oraz 8.

Infrastruktura serwera aplikacji musi być certyfikowaną platformą w zgodzie ze standardem Java EE wersja 6.

Infrastruktura serwera aplikacji musi zapewniać zgodność ze standardami WS-*, a w szczególności z WS-Security, WS-Policy.

Infrastruktura serwera aplikacji musi być certyfikowaną platformą wobec Spring Framework. Infrastruktura serwera aplikacji musi posiadać wbudowaną integrację EJB 3.0 i Spring.

Infrastruktura serwera aplikacji musi posiadać wbudowane wsparcie dla specyfikacji Commons J Work Manager API i Timer API.

Infrastruktura serwera aplikacji musi posiadać wbudowane wsparcie dla specyfikacji JSR-88 – plany wdrożeń (Deployment Plan).

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę standardu Web services WS-ReliableMessaging 1.1 i WS-ReliableMessaging Policy 1.1.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę standardu Web services WS-Trust 1.3.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę standardu Web services WS-SecureConversation 1.3.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę standardu Web services WS-Security 1.1.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę standardu Web services WS-SecurityPolicy 1.2.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę standardu Web Service MTOM\XOP – SOAP Message Transmission Optimization Mechanism/XML-binary Optimized Packaging.

2. Wymagania odnośnie obsługi standardów bezpieczeństwa jakie musi spełniać infrastruktura serwera aplikacji:

Infrastruktura serwera aplikacji musi posiadać możliwość realizacji odpowiedniego poziomu bezpieczeństwa w zakresie:

o uwierzytelniania

o kontroli dostępu

o zarządzania użytkownikami, grupami i rolami

o tworzenia, przechowywania i walidacji certyfikatów, haseł, kluczy

o audytowania zdarzeń bezpieczeństwa

o wsparcia dla mechanizmu pojedynczego logowania SSO.

Infrastruktura serwera aplikacji musi dostarczać mechanizmy uwierzytelniania i szyfrowania usług takie jak: użytkownik/hasło, passphrase, weryfikacja hostów, brak uwierzytelniania, tunelowanie wywołań SSL, certyfikaty X.509.

Infrastruktura serwera aplikacji musi posiadać wbudowaną, dostępną poprzez konfigurację, integrację z katalogami użytkowników, grup i ról – LDAP, Active Directory, bazy danych, Windows XX, X.000, SAML, własne.

Infrastruktura serwera aplikacji musi posiadać 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łasne).

Infrastruktura serwera aplikacji musi posiadać opisaną 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, audytowania, itd.

Infrastruktura serwera aplikacji musi posiadać obsługę specyfikacji: -Java Authentication and Authorization Service (JAAS), -Java Secure Sockets Extensions (JSSE), -Java Cryptography Extensions (JCE), - Java Authorization Contract for Containers (JACC).

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę standardów SAML 1.1, SAML 2.0 lub wyższych.

Infrastruktura serwera aplikacji musi posiadać wbudowaną integrację w ramach Single-Sign-On (SSO) z takimi technologiami jak SAML (1.1, 2.0), Kerberos (SPENEGO, Windows 2000 i 2003, .NET), Web service (SAML).

Infrastruktura serwera aplikacji musi posiadać obsługę mechanizmów autoryzacji i mapowania ról przy użyciu standardu XACML 2.0.

Infrastruktura serwera aplikacji musi posiadać możliwość konfiguracji dynamicznego członkostwa ról, np. uwzględniającego datę i czas, zawartość wybranych elementów w komunikatach SOAP (Web services), wartość atrybutów żądań HTTP, wartość atrybutów sesji HTTP, czy parametrów metod EJB.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę standardu Common Secure Interoperability Version 2 (CSIv2).

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę protokołu SNMP v3 wraz z HMAC-MD5-96, HMAC-SHA-96.

3. Wymagania dotyczące realizacji wydajności oraz mechanizmów wysokiej dostępności jakie musi spełniać infrastruktura serwera aplikacji

Infrastruktura serwera aplikacji musi posiadać publicznie dostępne raporty (benchmarki) dotyczące wydajności serwera aplikacyjnego (np. Spec Java Application Server). Raporty powinny zawierać szczegółowe informacje o zastosowanej konfiguracji serwera aplikacyjnego, JVM, bazy danych, sprzętu i innych komponentów użytych podczas testowania.

Infrastruktura serwera aplikacji musi posiadać wbudowane automatyczne samostrojenie się serwera aplikacyjnego (self-tuning).

Infrastruktura serwera aplikacji musi posiadać wbudowaną możliwość klastrowania połączeń JDBC

Infrastruktura serwera aplikacji musi posiadać wbudowaną możliwość klastrowania JMS (w tym automatyczne przełączanie klientów JMS w momencie failover serwerów JMS)

Infrastruktura serwera aplikacji musi posiadać możliwość klastrowania obiektów typu singelton w aplikacjach.

Infrastruktura serwera aplikacji musi posiadać obsługę klastrowania dla mechanizmu Store-and- Forward.

Infrastruktura serwera aplikacji musi posiadać obsługę klastrowania Web-services zgodnych z WS-ReliableMessaging.

4. Wymagania dotyczące funkcjonalności, jakie musi spełniać infrastruktura serwera aplikacji

Infrastruktura serwera aplikacji musi posiadać wbudowane wsparcie dla współdzielenia kodu (np. bibliotek) pomiędzy wieloma aplikacjami (Web, EJB, Web services). Biblioteki (JAR, WAR, EAR, EJB) powinny być instalowane w serwerze aplikacyjnym jednokrotnie i wiele aplikacji może z nich skorzystać. Wymagana jest możliwość zainstalowania wielu wersji bibliotek równocześnie. Wymagana jest możliwość konfiguracji, która wersja biblioteki będzie wykorzystywana przez aplikację. Konfiguracja musi odbywać się w sposób deklaratywny (za pomocą deployment deskryptor’ów) – nie poprzez kopiowanie kodu bibliotek do aplikacji.

Infrastruktura serwera aplikacji musi posiadać możliwość konfiguracji komponentów w aplikacjach webowych (np. servletów, filtrów servletów, web services) za pomocą adnotacji (ang. Annotations) Java 5 (dotyczy także parametrów specyficznych dla danego serwera aplikacyjnego).

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę żądań HTTP w sposób asynchroniczny (czyli możliwość rozdzielenia obsługi HTTP request i HTTP response na różne wątki).

Infrastruktura serwera aplikacji musi posiadać wbudowane wsparcie dla przechowywania (persistence) sesji webowych i EJB w pliku, bazie danych i pamięci.

Infrastruktura serwera aplikacji musi posiadać 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. programowanie musi umożliwiać mechanizmy klastrowania aplikacji w powyższy sposób, czyli z wykorzystaniem cache’a zewnętrznego.

Infrastruktura serwera aplikacji musi posiadać wsparcie dla replikacji sesji w pamięci pomiędzy wieloma instancjami serwerów aplikacyjnych uruchomionych na wielu fizycznych maszynach. Replikacja sesji musi 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.

Infrastruktura serwera aplikacji musi posiadać wbudowaną możliwość konfiguracji priorytetów obsługi żądań, priorytetów aplikacji i ich komponentów. Wymagana jest możliwość przypisywania reguł SLA do użytkowników, aplikacji i ich komponentów (np.

servletów, EJB). Reguły SLA powinny obejmować takie cechy jak: wagi (priorytety – np. % czasu procesorów gwarantowany dla aplikacji i/lub ich komponentów), czasy odpowiedzi, min/max liczba wątków, itp.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę pul połączeń do baz danych z uwierzytelnieniem połączeń. Tworzenie pul połączeń JDBC, w których jest możliwość zmapowania użytkowników serwera aplikacyjnego na użytkowników zdefiniowanych w bazie danych. Musi być możliwość wykonania mapowania typu „user id per connection”.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę wprowadzania zmian w kodzie Java w aplikacjach na serwerze bez konieczności re-deployment’u aplikacji ani restartu serwera aplikacyjnego (hot Java class swapping).

Infrastruktura serwera aplikacji musi posiadać możliwość uruchamiania wielu działających równocześnie wersji tej samej aplikacji (ang. side-by-side deployment). Klienci, którzy rozpoczęli pracę z wcześniejszą wersją aplikacji powinni pracować z tą wersją aplikacji. Nowi klienci powinni pracować z nową wersją aplikacji. Serwer musi zapewnić automatyczne wyłączanie poprzednich wersji aplikacji, w momencie, gdy ich użytkownicy zakończą pracę.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę integracji z technologią Microsoft COM. Możliwość wywoływania obiektów COM z poziomu aplikacji Java EE. Możliwość wywoływania kodu aplikacji Java EE z poziomu klientów COM.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę Logging Last Resource - optymalizacji transakcji rozproszonych (XA).

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę 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).

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę zaawansowanych mechanizmów kolejkowych (JMS): możliwość łączenia komunikatów JMS w jednostki (grupy), a następnie przetwarzanie jednostek. Klient JMS nie może przetwarzać danej jednostki, dopóki w JMS nie pojawią się wszystkie komunikaty wchodzące w skład danej jednostki. Przetwarzanie różnych jednostek (niezależnych od siebie grup komunikatów) powinno być jednak możliwe.

Infrastruktura serwera aplikacji musi posiadać wbudowany interfejs do JMS dla aplikacji napisanych w C (JMS C API).

Infrastruktura serwera aplikacji musi posiadać wbudowany interfejs do JMS dla aplikacji napisanych w Microsoft .NET C# (JMS C# API).

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę zawieszania i wznawiania transakcji rozproszonych (XA) w ramach JTA API (suspend/resume).

Infrastruktura serwera aplikacji musi posiadać wbudowany mechanizm współpracy z zewnętrznymi menedżerami transakcji rozproszonych (third-party, foreign transaction managers).

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę propagacji dodatkowych danych w ramach żądań (content propagation).

Infrastruktura serwera aplikacji musi posiadać obsługę mechanizmu Store-and-Forward, czyli gwarantowanego, niezawodnego przesyłania komunikatów pomiędzy instancjami serwerów aplikacyjnych.

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę asynchronicznych Web services (klient Web service, po wywołaniu Web service, nie musi zatrzymać się w oczekiwaniu na odpowiedź z Web service. Odpowiedź jest asynchronicznie przekazywana do klienta w późniejszym czasie).

Infrastruktura serwera aplikacji musi posiadać wbudowaną obsługę Web services, które mogą wykonywać operacje na kliencie (callback Web service).

Infrastruktura serwera aplikacji musi posiadać wbudowane wsparcie dla buforowanego wywoływania Web services.

Infrastruktura serwera aplikacji musi posiadać wbudowane wsparcie dla zewnętrznych dostawców usług kolejkowych (np. MQSeries) wraz z przenoszeniem kontekstów security i transakcyjnego.

5. Wymagania dotyczące mechanizmów administracji, zarządzania oraz monitorowania, jakie musi spełniać infrastruktura serwera aplikacji transakcyjnego.

Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać zarządzanie i monitorowanie wieloma serwerami aplikacyjnymi z jednej konsoli.

Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać zarządzanie i monitorowanie wielu aplikacji wdrożonych na różnych instancjach serwera aplikacyjnego.

Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać zarządzanie klastrami serwerów aplikacyjnych.

Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać monitorowanie zasobów serwerów aplikacyjnych takich jak póle połączeń JDBC, kolejki JMS, źródła danych.

Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać monitorowanie w czasie rzeczywistym zdarzeń płynących z wielu serwerów aplikacyjnych z możliwością wyspecyfikowania: - Poziomów zdarzeń krytycznych oraz ostrzeżeń - Różnych metod notyfikacji o zdarzeniach - Definiowanie reguł notyfikacyjnych - Możliwości podpięcia akcji naprawczych pod zdarzenie.

Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać centralne zarządzanie incydentami i problemami.

Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać raportowanie wydajności systemów z możliwością: - Wyspecyfikowania zakresu czasowego wyświetlanych danych.

Wyświetlania danych z różnych komponentów na jednym raporcie (wykresie) - Zapisania aktualnych danych wydajnościowych jako wzorca do porównywania z przyszłymi danymi.

Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać dostęp do logów zarządzanych serwerów aplikacyjnych z możliwością: - Filtrowania po czasie wpisu do logów - Filtrowania poziomie zalogowanej informacji (error, warning, etc.) - Pobrania pliku logu lub wyeksportowania wiadomości do pliku.

Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać możliwości monitorowania poziomu dostępności usługi (SLA) względem zdefiniowanych parametrów (mierników).

Moduł Zarządzania infrastruktury serwera aplikacji musi umożliwiać monitorowanie i diagnostyka JVM: - Bez konieczności wprowadzania specyficznych zmian w kodzie aplikacji - Bez konieczności restartu serwera - Pełny wgląd w dane maszyny wirtualnej Java (wątki, stos, etc) - Analiza wpływu działania maszyny wirtualnej Java na bazę danych i odwrotnie.

Infrastruktura serwera aplikacji musi posiadać wbudowaną 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 powinien przekierować nowe żądania do innych instancji w klastrze.

Infrastruktura serwera aplikacji musi umożliwiać 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.

Infrastruktura serwera aplikacji musi posiadać możliwość ograniczenia liczby sesji HTTP w serwerze tworzonych przez daną aplikację.

Infrastruktura serwera aplikacji musi posiadać 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.

Infrastruktura serwera aplikacji musi posiadać 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.).

Infrastruktura serwera aplikacji musi posiadać możliwość konfiguracji i zarządzania środowiskiem serwerów aplikacyjnych równocześnie poprzez: konsole webowe, skrypty (np. Jython), programowo (Java API), SNMP.

Infrastruktura serwera aplikacji musi posiadać możliwość łatwego rozszerzania funkcjonalności oferowanych przez konsole administracyjne. Rozszerzenia nie powinny wymagać zmian w kodzie istniejących konsol. Rozszerzenia nie powinny wymagać zmian w przypadku przyszłych aktualizacji (upgrade wersji serwera aplikacyjnego, itp.).

Infrastruktura serwera aplikacji musi posiadać możliwość wprowadzania zmian w konfiguracji środowiska serwerów aplikacyjnych w sposób transakcyjny (albo wszystkie zmiany zostaną poprawnie wprowadzone albo żadna zmiana nie będzie wprowadzona).

Infrastruktura serwera aplikacji musi posiadać 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).

Infrastruktura serwera aplikacji musi posiadać wbudowany mechanizm automatycznej naprawy transakcji podczas restartu serwera aplikacyjnego.

Infrastruktura serwera aplikacji musi posiadać 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.

6. Wymagania dotyczące architektury szyny usługowej

Infrastruktura szyny usługowej musi być oparta o serwer aplikacji zgodny ze standardem JEE (Java Enterprise Edition). Serwer aplikacji musi spełniać wymagania zawarte w sekcji Środowisko Aplikacyjne.

Infrastruktura szyny usługowej musi posiadać mechanizmy programowego klastrowania krytycznych elementów architektury ESB.

Infrastruktura szyny usługowej musi posiadać mechanizmy równoważenia obciążenia (load- balancing) wykorzystywane w sytuacjach zwiększonego obciążenia.

Infrastruktura szyny usługowej musi umożliwiać skalowanie, rekonfigurację, osadzanie nowych usług bez zakłócania pracy innych aplikacji czy realizowanych operacji biznesowych.

Infrastruktura szyny usługowej musi być wysoce skalowalna i musi zapewniać możliwość skalowania pionowego (maszyny wieloprocesorowe) jak i poziomego (farmy serwerów).

Dokładanie kolejnych serwerów do grupy nie może wymagać wyłączenia i reinstalacji pracujących serwerów.

Infrastruktura szyny usługowej musi umożliwiać odtworzenie stanu systemu sprzed awarii. Odtworzenie obejmuje całość działań, jakie trzeba wykonać aby system funkcjonował zgodnie z założeniami w szczególności: konfigurację szyny, serwera aplikacyjnego, na którym działa, systemu operacyjnego, powiązanych baz danych oraz wszystkich innych elementów systemu umożliwiających bezawaryjną pracę systemu.

Infrastruktura szyny usługowej musi zawierać wbudowane wsparcie dla buforowanego wywoływania Web services (buforowanie w Infrastrukturze Cache).

7. Wymagania dotyczące funkcjonalności szyny usługowej

Infrastruktura szyny usługowej musi posiadać mechanizm definiowania, implementacji, wdrażania i zarządzania usługami realizującymi dostęp do integrowanych systemów.

Usługi mogą być elementarne, tworzone jako konfiguracja pewnych modułów lub posiadać większą logikę integracyjną (np. sekwencja wywołań kilku usług).

Infrastruktura szyny usługowej zakłada istnienie usług prywatnych i publicznych. Usługi prywatne są dostępne jedynie w obrębie platformy integracyjnej i nie mogą być bezpośrednio wywoływane przez klientów systemu. Ich zadaniem jest realizowanie atomowych operacji, z których budowane są usługi publiczne.

Usługi publiczne muszą być widoczne dla klientów platformy integracyjnej poprzez:

o punkt dostępu do usługi stanowiący adres sieciowy usług w ramach infrastruktury ESB,

o punkt dostępu do definicji usługi (adres URL) - stanowiący adres sieciowy dokumentu WSDL opisującego usługę.

Każda usługa publiczna realizuje konkretny scenariusz (proces) integracyjny. Wspólnym protokołem komunikacyjnym usług publicznych i prywatnych musi być SOAP, a protokołem transportowym HTTP lub HTTPS. W przypadku komunikacji asynchronicznej wspólnym protokołem transportowym musi być transport oparty o kolejki (np. JMS). Funkcjonalność tworzona w ramach szyny usług musi być udostępniana w postaci atomowych usług.

Usługi systemu muszą być opisane w Katalogu Usług. Każda pozycja katalogu opisując usługę zawiera:

o unikalną nazwę,

o definicję wejścia i wyjścia usługi,

o implementację logiki realizowanej przez usługę,

o metadane ją opisujące (zgodne ze specyfikacją Web Services Metadata Exchange (WS- MetadataExchange)),

o listę błędów zgłaszanych przez usługę,

o dokumentację.

Infrastruktura szyny usługowej musi być zgodna ze standardami:

o WSDL 1.1,

o SOAP 1.2,

o SOAP with Attachments,

o UDDI 3.0.

Infrastruktura szyny usługowej musi zapewniać pełne wsparcie obsługi dokumentów XML. W ramach obsługi dokumentów XML, ESB musi wspierać możliwość:

o tworzenia i parsowania komunikatów XML,

o walidacji komunikatów na podstawie definicji XML Schema i DTD,

o obsługi dużych dokumentów XML (do 100MB),

o transformacji komunikatów – dokument XML na inny dokument XML oraz pomiędzy dokumentem XML i innym formatem (w obie strony),

o poprawnej obsługi stron kodowych obsługujących polskie znaki.

W ramach obsługi protokołu SOAP i Web Services dla usług konsumowanych jak i udostępnianych ESB musi zapewniać:

o możliwość konsumowania oraz udostępniania usług w standardzie webservices (WSDL 1.1, SOAP 1.1 i 1.2, SOAP with Attachements),

o standard WS-Security,

o standard WS-Policy,

o pożądane jest, aby platforma wspierała inne standardy WS określone specyfikacjami konsorcjum OASIS (xxxx://xxx.xxxxx-xxxx.xxx),

o wykorzystanie rejestrów UDDI (rejestr taki należy utworzyć w ramach systemu, ESB ma mieć także możliwość współpracy z zewnętrznymi rejestrami UDDI).

Infrastruktura szyny usługowej musi dostarczać usługi transformacji komunikatów XML w modelach jeden do wielu i wiele do jednego, co najmniej przy wykorzystaniu języka XSLT 1.0 (XSL Transformations, Extensible Stylesheet Language Transformations).

Infrastruktura szyny usługowej musi dostarczać usługi translacji komunikatów.

Infrastruktura szyny usługowej musi dostarczać usługi translacji protokołów pozwalające na podłączanie usług według różnych protokołów. ESB musi zapewniać dowolne łączenie obsługiwanych protokołów między sobą.

Infrastruktura szyny usługowej musi umożliwiać routing komunikatów, oparty na treści dokumentów XML i regułach biznesowych.

Infrastruktura szyny usługowej musi umożliwiać filtrowanie komunikatów na podstawie zawartości, przy wykorzystaniu parametrów definiowanych przez użytkownika.

Infrastruktura szyny usługowej musi umożliwiać trwałe przechowywanie komunikatów pod warunkiem, że nie prowadzi to do zbytniego obciążenia systemu.

Infrastruktura szyny usługowej musi umożliwiać realizację scenariuszy integracyjnych w oparciu o model synchroniczny i asynchroniczny.

Infrastruktura szyny usługowej musi umożliwiać nadawanie priorytetu komunikatom w warstwie transportowej (komunikacja asynchroniczna). W szczególności Infrastruktura szyny

usługowej musi obsługiwać nadawanie priorytetów komunikatom na podstawie treści komunikatu.

Infrastruktura szyny usługowej musi także umożliwiać zmianę wielkości puli wątków (per usługa) obsługujących synchroniczne żądania http.

Infrastruktura szyny usługowej musi umożliwiać integrację relacyjnych baz danych na poziomie danych i wywoływania procedur bazodanowych.

Infrastruktura szyny usługowej musi umożliwiać integrację aplikacji zbudowanych w technologiach J2EE, .Net.

Infrastruktura szyny usługowej musi wspierać co najmniej następujące standardy komunikacji: SOAP, JMS, JCA, HTTP, HTTPS, FTP, SFTP.

Infrastruktura szyny usługowej musi zawierać wbudowane wsparcie do udostępniania Web services typu REST.

8. Wymagania dotyczące bezpieczeństwa dla szyny usługowej

Warstwa komunikacyjna szyny usługowej musi umożliwiać zachowanie:

o integralności,

o niezaprzeczalności,

o poufności,

o autentyczności komunikacji.

Infrastruktura szyny usługowej musi umożliwiać raportowanie informacji o incydentach w zakresie bezpieczeństwa w szczególności nieuprawnionego logowania i informowania o incydentach na szynie.

Bezpieczeństwo usług zbudowanych w oparciu o technologię Web Services musi bazować na standardzie OASIS WS-S (Web Services Security).

Infrastruktura szyny usługowej musi umożliwiać szyfrowanie i podpisywanie komunikatów XML zgodnie z obowiązującymi przepisami.

Infrastruktura szyny usługowej musi umożliwiać podpisywanie komunikatów XML zgodnie ze standardem Advanced Electronic Signature (XAdES).

Minimalna długość klucza szyfrującego w przypadku zastosowania algorytmów symetrycznych musi wynosić 128 bitów, natomiast w przypadku zastosowania algorytmów asymetrycznych – 1024 bity.

Infrastruktura szyny usługowej musi umożliwiać weryfikację statusu unieważnienia certyfikatu poprzez mechanizm CRL.

Infrastruktura szyny usługowej musi umożliwiać weryfikację statusu certyfikatu poprzez mechanizm OCSP.

9. Wymagania dotyczące administracji i zarządzania dla szyny usługowej

Infrastruktura szyny usługowej musi umożliwiać ograniczenie wywołań usług, ochronę wydajności adapterów oraz zajętości kolejek.

Infrastruktura szyny usługowej musi być wyposażona w narzędzia do monitorowania i zarządzania wytworzonego oprogramowania.

Wraz z oprogramowaniem szyny usługowej muszą zostać dostarczone niezbędne skrypty oraz narzędzia wspierające przełączanie aktywności pomiędzy węzłami szyny usług.

Infrastruktura szyny usługowej musi zapewniać wsparcie w zakresie realizacji testów wydajnościowych i funkcjonalnych: zaślepki, symulatory, skrypty automatyzujące testy, konsola wywoływania ręcznego usług.

Infrastruktura szyny usługowej musi zapewniać możliwość kontroli wprowadzanych zmian oraz ich cofnięcia.

Infrastruktura szyny usługowej musi zapewniać możliwość eksportu ustawień konfiguracyjnych, a następnie importu na innej instancji szyny usług.

10. Wymagania dotyczące architektury dla silnika procesów integracyjnych

Infrastruktura silnika procesów integracyjnych musi być oparta o serwer aplikacji zgodny ze standardem JEE (Java Enterprise Edition).

Infrastruktura silnika procesów integracyjnych musi posiadać mechanizmy programowego klastrowania krytycznych elementów architektury.

Infrastruktura silnika procesów integracyjnych musi umożliwiać budowanie projektów integracyjnych w oparciu o standard SCA (Service Component Architecture).

11. Wymagania dotyczące funkcjonalności dla silnika procesów integracyjnych

Infrastruktura silnika procesów integracyjnych musi umożliwiać modelowania procesów w notacji BPMN 2.0.

Infrastruktura silnika procesów integracyjnych musi umożliwiać w ramach kompozytów SCA walidację, filtrowanie i transformację komunikatów przychodzących, a następnie przekierowanie ich do odpowiedniego procesu integracyjnego.

Infrastruktura silnika procesów integracyjnych umożliwi orkiestrację usług w postaci procesów integracyjnych zgodnych ze standardem WS-BPEL 2.0.

Infrastruktura silnika procesów integracyjnych umożliwi wywoływanie usług z poziomu procesu w sposób synchroniczny i asynchroniczny.

Infrastruktura silnika procesów integracyjnych musi umożliwiać orkiestrację usług komunikujących się poprzez różne protokoły transportowe (wspierane poprzez zestaw dostarczanych adapterów komunikacyjnych).

Infrastruktura silnika procesów integracyjnych musi udostępniać adapter bazodanowy, umożliwiający komunikację (co najmniej wykonywanie zapytań oraz procedur składowanych, wsparcie XA) z następującymi bazami danych: - Oracle Database - MS SQL - IBM DB2.

Infrastruktura silnika procesów integracyjnych musi udostępniać adapter kolejkowy umożliwiający komunikację wg następujących standardów: JMS, MQ, AQ, MS MQ.

Infrastruktura silnika procesów integracyjnych udostępni adapter plikowy pozwalający na: - operacje w systemie plików (read/write, listing) - komunikację z serwerem FTP/FTPS.

Infrastruktura silnika procesów integracyjnych musi udostępniać adapter Web Service pozwalający na komunikację SOAP po HTTP/HTTPS.

Infrastruktura silnika procesów integracyjnych musi umożliwiać komunikację z usługami według wzorca REST.

Infrastruktura silnika procesów integracyjnych musi udostępniać zoptymalizowany dwukierunkowy adapter, pozwalający na efektywną komunikację pomiędzy silnikiem procesów integracyjnych a szyną usługową (ESB).

Infrastruktura silnika procesów integracyjnych musi umożliwiać ekspozycję procesu integracyjnego w postaci usługi.

Infrastruktura silnika procesów integracyjnych musi umożliwiać wzbudzenie procesu integracyjnego zgodnie ze zdefiniowanym harmonogramem.

Infrastruktura silnika procesów integracyjnych musi umożliwiać natywne wywołanie kodu Java umieszczonego w przepływie procesu integracyjnego.

Infrastruktura silnika procesów integracyjnych musi umożliwiać obsługę warstwy danych zgodnie z koncepcją Service Data Objects (SDO).

Infrastruktura silnika procesów integracyjnych musi umożliwiać definiowanie ścieżek obsługi wyjątków (systemowych, własnych wyjątków oraz obsługę zbiorczą).

Infrastruktura silnika procesów integracyjnych musi umożliwiać definiowanie transakcji kompensacyjnych, wykonujących operacje odwrotne w przypadku wystąpienia błędu w procesie wchodzącym w interakcje z systemami nietransakcyjnymi.

Infrastruktura silnika procesów integracyjnych musi umożliwiać definiowanie zadań interaktywnych w ramach procesów integracyjnych (np. obsługa błędów przez administratora). Wymagane jest zapewnienie środowiska dostępowego do obsługi wygenerowanych zadań.

Infrastruktura silnika procesów integracyjnych musi umożliwiać wersjonowanie procesów integracyjnych, z możliwością koegzystencji różnych wersji procesów na środowisku wykonawczym.

Infrastruktura silnika procesów integracyjnych musi umożliwiać konfigurowalne zarządzanie stanem procesów integracyjnych, z możliwością utrwalania stanu procesu do bazy danych. Pożądana możliwość wykorzystywania Infrastruktury Cache do przechowywania stanu procesów.

Infrastruktura silnika procesów integracyjnych musi umożliwiać zdefiniowanie w ramach jednego kompozytu SCA zestawu procesów integracyjnych wraz hierarchią wywołań pomiędzy nimi (procesy nadrzędne i pod-procesy).

Infrastruktura silnika procesów integracyjnych musi umożliwiać definiowanie logiki biznesowej (sterującej przepływem w procesie) poprzez reguły biznesowe.

Infrastruktura silnika procesów integracyjnych musi posiadać silnik reguł biznesowych, który jest zgodny ze standardem JSR-94.

Infrastruktura silnika procesów integracyjnych musi umożliwiać monitorowanie stanów i danych w procesach integracyjnych, z możliwością transparentnego przekazywania mierników z poziomu procesu do centralnego repozytorium danych monitorowanych (repozytorium BAM, ang. Business Activity Monitoring).

12. Wymagania dotyczące rozwoju i tworzenia dla silnika procesów integracyjnych

Infrastruktura silnika procesów integracyjnych musi udostępniać graficzne środowisko do modelowania procesów integracyjnych, z możliwością komponowania procesów z gotowych elementów (drag&drop).

Infrastruktura silnika procesów integracyjnych musi udostępniać kreatory wspierające programistę w konfiguracji poszczególnych kroków procesu integracyjnego.

Infrastruktura silnika procesów integracyjnych musi udostępniać graficzne komponenty do modelowania danych (np. schematów XSD) oraz definiowania transformacji danych (np. transformat XSLT).

Infrastruktura silnika procesów integracyjnych musi udostępniać graficzny komponent do modelowania reguł biznesowych sterujących procesem integracyjnym. Komponent musi umożliwiać definiowanie reguł w postaci wyrażeń logicznych oraz tabeli decyzyjnych.

Środowisko deweloperskie dla Infrastruktury silnika procesów integracyjnych musi udostępniać mechanizm konfiguracyjnej definicji mierników (KPI) przekazywanych do centralnego repozytorium danych monitorowanych (repozytorium BAM).

Środowisko deweloperskie umożliwi automatyczny wdrożenie (ang. Deployment) zbudowanych procesów na środowisko wykonawcze.

13. Wymagania dla środowiska zarządzania procesami biznesowymi

Oprogramowanie musi pozwalać na modelowanie struktur organizacyjnych.

Oprogramowanie musi posiadać interfejs graficzny oparty o przeglądarkę internetową, umożliwiający projektowanie procesów w postaci diagramów, uwzględniających aktorów biorących udział w procesie (role), opisujących typ realizowanej czynności, wykorzystywane aplikacje i dokumenty oraz zadania przez nich wykonywane.

Oprogramowanie musi umożliwiać wprowadzanie opisu procesów, a w szczególności:

o Początku i końca procesu.

o Celu procesu, w tym poprzez opis tekstowy.

o Nazwy procesu.

o Aktywnych łączników do innych modeli procesów.

o Określenie osoby zarządzającej procesem.

Oprogramowanie musi umożliwiać modelowanie w narzędziu hierarchii procesów i funkcji .

Oprogramowanie musi umożliwiać budowanie w narzędziu map procesów przez zespół kilku osób równolegle.

Oprogramowanie musi umożliwiać tworzenie w narzędziu map procesów typu "swimlane" (działania w pionowych lub poziomych torach dla jednostek/komórek organizacyjnych).

Oprogramowanie musi umożliwiać tworzenie w narzędziu hierarchicznych struktur danych

Oprogramowanie musi umożliwiać eksportowanie w narzędziu procesów np. na portal procesowy (portal firmowy).

Oprogramowanie musi umożliwiać przeprowadzenie w narzędziu symulacji zmian procesu pod kątem ilościowym np. skrócenie czasu obsługi procesu.

Oprogramowanie musi umożliwiać przeprowadzenie w narzędziu symulacji zmian procesu pod kątem jakościowym np. usunięcie realizowanych czynności w procesie.

Oprogramowanie musi umożliwiać wykorzystanie w narzędziu symulacji biorąc pod uwagę kalendarz pracy dla organizacji.

Oprogramowanie musi umożliwiać wykonanie w narzędziu symulacji w odniesieniu do utworzonych modeli procesów.

Oprogramowanie musi umożliwiać przeprowadzenie w narzędziu symulacji polegających na:

o Weryfikacji czasochłonności procesu i jego poszczególnych etapów.

o Wykonaniu analiz dotyczących zasobów (ludzkich/systemowych) w procesie. Oprogramowanie musi umożliwiać monitorowanie danych w narzędziu w czasie rzeczywistym zgodnie z terminologią Business Activity Monitoring, w tym dotyczących:

▪ danych, które powinny być prezentowane w formie graficznej (wykresy) oraz/lub w formie tabelarycznej (listy),

▪ musi umożliwiać tworzenie zestawień hierarchicznych (tzw. drill down) – pozwalających na przejście od informacji ogólnej na poziom bardziej szczegółowy.

Oprogramowanie musi umożliwiać prezentację w narzędziu danych poprzez ich wizualizację na wielu poziomach szczegółowości, w postaci interaktywnych list zestawień, wykresów, zestawień wskaźnikowych (kokpitów menadżerskich).

Oprogramowanie musi umożliwiać prezentację w narzędziu wybranych KPI z wartością faktyczną i wartością oczekiwaną.

Oprogramowanie musi umożliwiać generowanie w narzędziu alertów w postaci komunikatów, wiadomości mailowych oraz automatycznego uruchamiania procesów reagując na raportowane zdarzenia.

Oprogramowanie musi umożliwiać publikowanie w narzędziu/rozwiązaniu modeli procesowych w postaci stron WWW.

Oprogramowanie musi umożliwiać prezentację w narzędziu/rozwiązaniu w formie graficznej (mapa np. w formacie: jpg) całego procesu. W przypadku procesów głównych i podprocesów, umożliwia prezentację wg podziału procesów i ich logicznego powiązania.

Oprogramowanie musi umożliwiać prezentację w formie graficznej zaawansowania danej instancji procesu (ścieżka przejścia, zrealizowane kroki w procesie, aktualny stan procesu).

Oprogramowanie musi umożliwiać importowanie do narzędzia/rozwiązania gotowych procesów z narzędzi do modelowania.

Oprogramowanie musi umożliwiać przekształcenia map procesów w postać możliwą do dalszej dystrybucji np. do postaci tabelarycznej procedury i eksportu jej do formatu MS Word lub PDF.

Oprogramowanie musi umożliwiać zastosowanie notacji BPMN i BPMN 2.0.

Oprogramowanie musi umożliwiać przekształcenia, zapis, eksport oraz import modeli biznesowych (BPMN) w formatach np.: XPDL, BPEL, BPMN 2.0.

Oprogramowanie musi umożliwiać tworzenie procesu w oparciu o gotowe komponenty logiki jak i usługi – współpraca z UDDI.

Oprogramowanie musi umożliwiać orkiestrację procesów z uwzględnieniem zadań wykonywanych przez użytkowników (lub grup użytkowników) oraz z wykorzystaniem funkcjonalności istniejących aplikacji i systemów.

Oprogramowanie musi umożliwiać synchroniczne lub asynchroniczne wywoływanie procesów na podstawie zdarzeń zewnętrznych.

Oprogramowanie musi umożliwiać uruchamianie procesu w wyniku zdarzenia w postaci:

o pojawienia się w odpowiednim katalogu pliku lub przesyłki email,

o pojawienia się określonego rekordu w bazie danych. Dodatkowo uruchomienie procesu jest możliwe zgodnie z wcześniej ustalonym harmonogramem.

Oprogramowanie musi umożliwiać obsługę procesów wymagających interakcji z użytkownikiem.

Oprogramowanie musi posiadać mechanizm notyfikacji użytkowników pozwalający powiadamiać odpowiednie osoby o zdarzeniach zachodzących w procesie.

Oprogramowanie musi posiadać generator interfejsu użytkownika – pozwoli on na automatyczną generację formularzy na podstawie struktur danych przechowujących informacje w procesie.

Oprogramowanie musi posiadać mechanizmy walidacji danych wprowadzanych przez użytkownika.

Oprogramowanie musi posiadać mechanizmy kontroli terminów wykonania poszczególnych zadań / etapów w procesie (deadlines).

Oprogramowanie musi posiadać mechanizmy automatycznego przekierowania zadań w procesie pod nieobecność pracownika (urlop, choroba).

Oprogramowanie musi umożliwiać zmiany sposobu działania procesu "w locie" (bez ingerencji programistycznej) przez uprawnionych użytkowników (np. odebranie zadania, cofnięcie procesu do określonego punktu).

Oprogramowanie musi posiadać interfejs użytkownika dostępny poprzez przeglądarkę internetową.

Oprogramowanie musi posiadać interfejs użytkownika w technologii Web2.0, dający możliwość personalizacji stron przez pracowników.

Oprogramowanie musi umożliwiać wielokrotne użycie elementów interfejsu w innych aplikacjach – wsparcie dla JSR-168 (portlety) i JSR-286.

Oprogramowanie musi umożliwiać obieg dokumentów oraz generowanie formularzy na bazie danych procesu.

Oprogramowanie zawiera silnik procesowy pozwalający na wykonywanie w środowisku produkcyjnym zaprojektowanych modeli procesów. Silnik procesowy musi wspierać standardy opisu procesów: BPEL, BPMN 2.0.

Oprogramowanie musi uwzględniać wykorzystanie reguł biznesowych jako mechanizmu do definiowania polityk biznesowych.

Oprogramowanie musi zawierać interfejs dostępowy silnika reguł biznesowych zgodny z JSR- 94.

Oprogramowanie musi umożliwiać równoległe procesowanie różnych wersji tego samego procesu (w przypadku, gdy wdrożono nową wersję, ale istnieją instancje rozpoczęte jeszcze na starej wersji).

Oprogramowanie musi umożliwiać wystawianie interfejsów do utworzonych procesów biznesowych (np. w postaci web service’u pozwalającego uruchomić proces) i wystawienie go na Szynie Usługowej.

Oprogramowanie musi posiadać silnik procesów biznesowych oparty na serwerze aplikacji zgodnym ze standardem J2EE .

14. Wymagania szczegółowe na komponent „Repozytorium”

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

Komponent repozytorium dokumentów.	dokumentów	musi	zapewniać mechanizmy wersjonowania
Komponent repozytorium dokumentów.	dokumentów	musi	zawierać mechanizm tworzenia wersji
Komponent repozytorium	dokumentów	musi	zapewniać 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.

Komponent repozytorium dokumentów 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.

Komponent repozytorium dokumentów musi umożliwiać wyszukiwanie dokumentu w wielu fizycznych repozytoriach.

Komponent repozytorium dokumentów musi umożliwiać pozycjonowanie wyników wyszukiwania w zależności od popularności dokumentów.

Komponent repozytorium dokumentów musi zawierać mechanizm opisywania dokumentów za pomocą metadanych.

Komponent repozytorium dokumentów musi umożliwiać definiowanie zestawów metadanych dla poszczególnych typów dokumentów.

Komponent repozytorium dokumentów musi umożliwiać definiowanie i dodawanie własnych metadanych.

Komponent repozytorium dokumentów musi umożliwiać automatyczne nadawanie zestawu metadanych w zależności od miejsca przechowywania dokumentu.

Komponent repozytorium dokumentów musi umożliwiać tworzenie dyskusji (komentarzy) powiązanych z danym dokumentem.

Komponent repozytorium dokumentów musi posiadać mechanizm subskrypcji - powiadamiania e-mail o zmianach danego dokumentu.

Komponent repozytorium dokumentów musi minimalnie umożliwiać automatyczną konwersję dokumentów MS Word, Excel, PowerPoint, Project, Publisher, Visio, RTF, ASCII, do postaci umożliwiającej wyświetlenie w przeglądarce internetowej (HTML/XML i PDF).

Komponent repozytorium dokumentów 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.

Komponent repozytorium dokumentów musi umożliwiać przechowywanie zarówno rejestrowanych dokumentów, jak i innych, nierejestrowanych treści.

Komponent repozytorium dokumentów musi umożliwiać dołączanie załączników do dokumentów

Komponent repozytorium dokumentów musi pozwalać na tworzenie spraw tematycznych z dokumentami. Jeden dokument może być przypisany do wielu spraw.

Komponent repozytorium dokumentów musi zapewniać to, aby teczki tematyczne (abstrakcyjne obiekty w repozytorium zawierające fizyczne obiekty w repozytorium) mogły być opisane własnym zestawem metadanych.

Komponent repozytorium dokumentów musi zapewniać to, aby sprawy tematyczne mogły zawierać dowolną liczbę dokumentów dowolnego typu opisanych dowolnymi meta danymi.

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

Komponent repozytorium dokumentów musi umożliwiać przechowywanie dowolnych typów plików (dokumentów tekstowych, arkuszy, prezentacji, wiadomości e-mail, grafik, filmów, plików wykonywalnych, plików CAD, etc).

Komponent repozytorium dokumentów 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.

Komponent repozytorium dokumentów 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.

Wypełnienie formularza musi umożliwiać automatyczne uruchomienie obiegu dokumentu.

Komponent repozytorium dokumentów musi umożliwiać skanowanie i przetwarzanie skanowanych dokumentów oraz dodawanie ich do repozytorium

Komponent repozytorium dokumentów musi obsługiwać skanery z obsługą standardu XXXXX oraz wspierać obsługę skanerów sieciowych oraz skanowanie masowe.

Przetwarzanie skanowanych dokumentów musi oferować funkcję OCR oraz przetwarzanie do formatu PDF, z możliwością wyszukiwania słów zawartych w dokumencie.

Komponent repozytorium dokumentów musi obsługiwać automatyczny, elektroniczny obieg dokumentów i spraw tematycznych.

Komponent repozytorium dokumentów musi umożliwiać automatyczny przepływ dokumentów według zdefiniowanych wcześniej ścieżek.

Komponent repozytorium dokumentów musi umożliwiać tworzenie ad-hoc ścieżki obiegu dla danego dokumentu

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

Ś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

Komponent repozytorium dokumentów musi umożliwiać automatyczne uruchamianie procesu obiegu dla dokumentów dodanych do systemu, na podstawie zdefiniowanych dla nich metadanych.

Komponent repozytorium dokumentów 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).

Komponent repozytorium dokumentów musi być wyposażony w mechanizm powiadamiania odpowiednich osób o zdarzeniach w obiegu dokumentów.

Komponent repozytorium dokumentów 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.

Komponent repozytorium dokumentów musi informować użytkowników o zbliżającym się oraz przekroczonym terminie realizacji konkretnego zadania.

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

Komponent repozytorium dokumentów musi umożliwiać automatyczną eskalację zadań w przypadku przeterminowania.

Komponent repozytorium dokumentów musi zapewniać prowadzenie dziennika zdarzeń. Wszystkie operacje dotyczące dokumentów muszą być zapisywane w systemie w sposób umożliwiający określenie kolejności działań i wykonawców czynności

Komponent repozytorium dokumentów musi zapewniać możliwość podglądu stanu realizacji zadań.

Komponent repozytorium dokumentów musi umożliwiać rejestrowanie wszelkich operacji wykonywanych na dokumentach w systemie, wraz przebytymi ścieżkami akceptacji.

Komponent repozytorium dokumentów musi umożliwiać raportowanie działań podejmowanych przez danego użytkownika, bądź w danej lokalizacji (jednostce, dziale, kancelarii)

Komponent repozytorium dokumentów musi umożliwiać w każdej chwili utworzenie raportu o prawach dostępu użytkowników.

Wszystkie wygenerowane raporty muszą mieć możliwość trafienia jako dokumenty do komponentu repozytorium

Komponent repozytorium dokumentów musi zapewnić jednolity panel administracyjny dostępny za pomocą przeglądarki WWW.

Komponent repozytorium dokumentów musi zapewniać mechanizm kontroli uprawnień i zabezpieczenia dostępu do dokumentów i funkcji systemu.

System zabezpieczeń musi być oparty o mechanizm ról, pozwalający określić możliwość wykonania konkretnych funkcji w systemie

Komponent repozytorium dokumentów musi mieć możliwość budowania hierarchicznego modelu uprawnień.

Komponent repozytorium dokumentów musi zapewniać możliwość określenia dokładnych praw na poziomie pojedynczego użytkownika, pojedynczego dokumentu oraz pojedynczej funkcji systemu.

Komponent repozytorium dokumentów musi zezwalać na delegowanie części uprawnień administracyjnych do administratorów lokalnych

Komponent 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.

Komponent 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.

Komponent repozytorium dokumentów musi pozwalać na integrację logowania z logowaniem domenowym.

Komponent repozytorium dokumentów musi pozwalać na rejestrowanie dokumentów oraz teczek tematycznych.

Komponent repozytorium dokumentów musi zapewniać centralne zarządzanie wieloma repozytoriami i archiwami, zarówno elektronicznymi jak i tradycyjnymi.

Komponent repozytorium dokumentów musi zapewniać funkcjonowanie rejestrów kancelaryjnych

Komponent repozytorium dokumentów musi zapewnić obsługę standardu Model Requirements for the Management of Electronic Records (MoReq)

Komponent repozytorium dokumentów musi zapewnić niezmienność zarejestrowanych dokumentów w czasie całego czasu ich życia.

Komponent repozytorium dokumentów 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.

Komponent repozytorium dokumentów musi umożliwiać automatyzację zadań związanych z polityką przechowywania – min. przenoszenie do archiwów i pomiędzy nimi, usuwanie po określonym czasie przechowywania.

Komponent repozytorium dokumentów musi zapewnić możliwość uzyskania potwierdzenia usunięcia danego dokumentu.

Komponent repozytorium dokumentów musi zapewnić możliwość wprowadzania automatycznych polityk zarządzania treścią.

Komponent repozytorium dokumentów musi zapewniać zgodność z obowiązującym prawodawstwem odnośnie przechowywania dokumentów

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

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

Komponent repozytorium dokumentów 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).

Komponent repozytorium dokumentów musi być wyposażony w moduł dla systemu MS Windows umożliwiający bezpośredni dostęp do repozytorium dokumentów z aplikacji pakietu MS Office i Outlook.

Komponent repozytorium dokumentów musi umożliwiać dostęp do dokumentów za pomocą przeglądarki internetowej.

Komponent repozytorium dokumentów musi obsługiwać standard JSR170 (Java Content Repository). Oznacza to możliwość obsługi portalu wewnętrznego lub zewnętrznego zgodnego z tym standardem.

Interfejs webowy musi umożliwiać personalizację i dostosowanie do preferencji użytkownika. Musi pozwalać na umieszczanie min. zachowanych wyszukiwań, własnych odnośników, linków do subskrybowanych dokumentów, najczęściej wykorzystywanych funkcji, etc.

Komponent repozytorium dokumentów musi umożliwiać budowę Platformy wymiany informacji i bazy dokumentów

Komponent repozytorium dokumentów musi umożliwiać budowanie serwisów internetowych, tj.: wewnętrznych i zewnętrznych portali informacyjnych, baz wiedzy, 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ę).

Komponent repozytorium dokumentów musi udostępniać narzędzie do budowy serwisów internetowych.

Komponent repozytorium dokumentów musi umożliwiać wielokrotne wykorzystywanie tych samych komponentów (fragmentów nawigacyjnych, menu, statycznych treści) do budowy wielu serwisów.

Komponent repozytorium dokumentów musi umożliwiać publikowanie w serwisach dokumentów przechowywanych w Repozytorium Dokumentów. Jeden dokument może być wykorzystany w wielu serwisach.

Komponent repozytorium dokumentów 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.

Komponent repozytorium dokumentów musi umożliwiać edycję treści w serwisie, bezpośrednio na stronie internetowej, za pomocą edytora WYSIWYG

Komponent repozytorium dokumentów musi umożliwiać wykorzystanie zintegrowanego obiegu dokumentów do akceptacji treści publikowanych w serwisach.

Komponent repozytorium dokumentów musi umożliwiać automatyczną aktualizację w serwisach treści, opartych na dokumentach z repozytorium, w momencie pojawienia się nowej wersji danego dokumentu.

System praw dostępu do treści musi być zintegrowany z Komponentem repozytorium dokumentów.

15. Wymagania szczegółowe na komponent „Portal”

Komponent portal musi być zbudowana w oparciu o technolgię JEE uruchamianą na serwerze aplikacyjnym Java

Komponent portal musi zapewniać architekturę wysokiej dostępności (HA) w opariu o klastry serwera aplikacyjnego

Komponent portal musi zapewniać możliwość rozszerzania klastra portalowego o dowolną ilość maszyn bez potrzeby zatrzymywania pracy dotychczas istniejących węzłów klastra.

Komponent portal musi dostarczać w pełni funkcjonalne repozytorium dokumentów do zarządzania artykułami, blogami, stronami wiki oraz innymi dokumentami dowolnego formatu przechowywanych w repozytorium dokumentów i wizualnie udostępnianych na stronach portalowych.

Komponent portal musi dostarczać silnik procesów biznesowych i integracyjnych opartych o standard BPEL4WS.

Komponent portal musi dostarczać wyszukiwarkę treści do indeksowania wszelkiej treści publikowanej na portalu w formie: artykułów, blogów, wiki, for dyskusyjnych, ogłoszeń i dokumentów

Komponent portal musi zapewniać pojedyncze logowanie pomiędzy poszczególnymi komponentami webowymi obsługiwanymi w przeglądarce internetowej w szczególności: repozytorium dokumentów, portalem, aplikacją dostępową do procesów biznesowych oraz narzędziami administracyjnymi.

Wyżej wymienione komponenty platformy portalowej takie jak repozytorium dokumentów, silnik procesów biznesowo integracyjnych, system pojedynczego logowania, a także wyszukiwarka muszą być sciśle zintegrowane ze sobą i pochodzić od tego samego dostawcy oprogramowania.

Wszystkie wymienione komponenty platformy portalowej (serwer aplikacyjny, platforma portalowa, repozytorium dokumentów, silnik procesów biznesowo integracyjnych, system pojedynczego logowania, a także wyszukiwarka) muszą być zarządzane z jednego narzędzia administracyjnego z co najmniej następującymi możliwościami:

o Włączanie i wyłączanie węzłów klastra serwera aplikacyjnego

o Monitorowanie zużycia pamięci przez poszczególne komponenty

o Monitorowanie zużycia procesora

o Monitorowanie dostępu do portletów

o Monitorowanie dostępu do stron portalowych

o Monitorowanie dostępu do dokumentów,

Komponent portal musi zapewniać mechanizmy ochrony usług poprzez impementację standardu WS-Security

Komponent portal musi implementować następujące standardy:

o JSR-301 – JSF Portlet Bridge

o JSR-168 – Portelt specyfication

o JSR-286 – Portlet specification v2

o WSRP 1.0 oraz 2.0 – Portlet communication

o JSR – 227 Data bindigs & Data access

o WSDL - Webservice description language

Komponent portal musi umożliwiać osadzanie re-używalnych komponentów w postaci

o portletów XXX 000,

o portletów XXX 000,

o ADF TaskFlows,

o Google Gadgets,

o Microsoft WebParts jako portlety WSRP

Użytkownicy komponentu portal muszą być zdefiniowani w zewnętrznym katalogu użytkowników zgodnym ze standardem LDAP.

Komponent portal musi umożliwiać dwie metody budowania przestrzeni portalowych:

o W narzędziu deweloperskim (IDE) – dla programistów

o W aplikacji portalowej bez potrzeby programowania, a tylko przy użyciu metod deklaratywnych z wykorzystaniem dostępnych portletów i komponentów – dla użytkowników biznesowych.

Komponent portal musi umożliwiać zakładanie nowych obszarów portalowych przez zwykłych użytkowników końcowych z odpowiednimi uprawnieniami

Komponent portal musi udostępniać każdemu użytkownikowi domyślny obszar prywatny (eng. private space) z pełną dowolnością co do:

o konfiguracji stron,

o układu komponentów na stronie,

o domyślnego języka,

o udostępniania zawartości innym użytkownikom

Komponent portal musi umożliwiać zakładanie nowych obszarów portalowych (eng. business spaces) tylko uprawnionym użytkownikom biznesowym bez konieczności programowania.

Komponent portal musi umożliwiać zakładanie nowych obszarów portalowych z gotowych szablonów w których pre-konfigurowane są następujące elementy:

o domyślny zestaw stron

o domyślny zestaw usług (np. dokumenty, fora dyskusyjne, blogi, wiki itp)

o domyślny profil obszaru (np. portal projektowy, portal wymiany dokumentów, portal dyskusyjny, portal grup zainteresowania)

o domyślne role i uprawnienia

Komponent portal musi udostępniać następujący zestaw gotowych usług z rodziny Web 2.0

o Forum dyskusyjne

o Wiki

o Blogi

o Ogłoszenia

o Kalendarz prywatny i grupowy (w ramach obszaru)

o Repozytorium dokumentów

o Wyszukiwarka treści

o Tagowanie oraz chmura tagów

o Łączenie treści (np. łącze między zdarzeniem w kalendarzu, a dokumentem, wątkiem na forum dyskusyjnym, ogłoszeniem czy stroną typu Wiki lub Blog)

o Tablice ogłoszeń

o Listy spraw

o Listy znajomych i strukturę hierarchiczną firmy

o Klient poczty elektronicznej (w opariu o istniejący serwer pocztowy)

o Usługa obecności (eng. presence)

o Ankiety

o Raporty (do tworzenia graficznych wykresów na podstawie danych istniejących w relacyjnej bazie danych lub jako wywołanie usługi sieciowej typu WebService).

Do wymienionych usług w powyższym punkcie, komponent portal musi ustostępniać zestaw gotowych re-używalnych komponentów interfejsu użytkownika zorganizowanych w portlety XXX 000, 000 lub ADF Task Flows.

Komponent portal musi posiadać możliwość publikowania treści zgromadzonej w repozytorium dokumentów na stronach protalowych jako:

o edytowalny tekst

o multimedia (obrazy i filmy)

o galerie zdjęć

o listy dokumentów do pobrania

o przeglądarki folderów sieciowych repozytorium dokumentów

o podglądu dokumentów różnych formatów w postaci PDF

Komponent portal musi umożliwiać tworzenie stron formacie Wiki lub Blog zwykłym uprawnionym do tego użytkownikom. Strony Wiki oraz artykuły na Blogach muszą być organizowane jako dokumenty HTML i przechowywane bezpośrednio w repozytorium dokumentów. Nie dopuszcza się przechowywania treści Wiki i Blog bezpośrednio w bazie danych czy bezpośrednio w systemie plików.

Komponent portal musi zapewniać możliwość tworzenia ankiet przez użytkowników biznesowych oraz ich publikowanie na stronach portalowych. Dodatkowo, musi zapewniać wyświetlanie wstępnych i końcowych rezultatów głosowania użytkowników.

Komponent portal musi posiadać gotowe portlety JSR-168 lub ADF TaskFlow do realizacji funkcji klienta poczty elektronicznej oraz listy zadań generowanych przez silnik procesów biznesowych operty o standard BPML i BPEL.

Komponent portal musi umożliwiać tworzenie przez zaawansowanych użytkowników raportów w oparciu o dane zgromadzone w relacyjnej bazie danych lub jako wykonanie usługi typu WebService. Format wyjściowy raportu musi być w postaci tabeli lub wykresu graficznego.

Dodatkowo, moduł analityczny aplikacji portalowej musi zapewniać wyświetlanie pre- definiowanych raportów dotyczących ruchu na portalu i używanych komponentów.

Komponent portal musi udostępniać użytkownikom zintegrowaną wyszukiwarkę treści, która w ramach pojedynczego zapytania jednocześnie ma wyszukiwać w różnych źródłach danych.

Komponent portal musi udostępniać możliwość deklaratywnego tworzenia nowych komponentów wizualizacyjnych bazujących na danych zgromadzonych w bazie danych lub w wyniku wywołania usług sieciowych WebService. Wizualizacja danych powinna odbywać się poprzez wyświetlenie:

o tabeli z danymi

o graficznych wykresów bazujących na danyych

o formularzy z możliwością wprowadzenia wartości i uruchomienia usługi WebService w oparciu o wprowadze dane

Do komponentu portalowego musi istnieć jej wersja mobilna na telefony iPhone możliwa do ściągnięcia z Apple AppStore.

W aplikacji mobilnej iPhone musi być możliwość podglądu tych samych treści co za pomocą komponentu portalowego.

Uwierzytelnienie do aplikacji mobilnej iPhone musi używać tych samych kont użytkowników co do aplikacji na komputery stacjonarne.

Komponent portal musi dostarczać gotową aplikację w systemie Android i iOS do dostępu do repozytorium dokumentów.

Oprócz dedykowanej aplikacji mobilnej na telefony iPhone, komponent portal musi pozwalać na poprawne wyświetlanie zawartości stron na minimum następujących przeglądarkach: Mozilla Firefox 3.55 i wyższe, Google Chrome 33.0.1750 i wyższe, IE 8 i wyższe, Safari 6 i wyższe.

Komponent portal musi udostępniać zestaw adapterów do integracji z narzędziami biurowymi takimi jak:

o MS Outlook

o MS Office

Adaptery dla MS Office i MS Outlook muszą udostępniać co najmniej następujące funkcjonalności w tych narzędziach:

o dostęp do przestrzeni prywatnej użykownika oraz przestrzeni grupowych do których ma zdefiniowane uprawnienia

o Widok dokumentów, aktywności, grup dyskusyjnych, zdarzeń grupowych oraz członków

o Możliwość zapisania emaila, załącznika lub dokumentu Office bezpośrednio w przestrzeni portalowej

o stworzenie nowej przestrzeni na podstawie emaila lub dokumentu Office

o edycja dokumentów MS Office znajdujących się w przestrzeni portalowej bezpośrednio w aplikacji na stacji roboczej użytkownika wraz z automatycznym zapisaniem zmian w nowej wersji dokumentu.

Komponent portalowy wyświetlany w mobilnych przeglądarkach internetowych na urządzeniach z systemem iOS i Adroid musi poprawnie obsługiwać gesty wielodotykowe (ang. Multi-touch gestures)

Komponent portal musi udostępniać administratorowi możliwość wejścia w rolę zwykłego użytkownika i podglądu stron a także edycję stron i zawartości w imieniu tego użytkownika.

Zwykły użytkownik może przekazać uprawnienia do wejścia w jego rolę innemu użytkownikowi na z góry określony czas i w każdej chwili może odwołać te uprawniania

Komponent portal musi umożliwiać osadzanie re-używalnych komponentów w postaci portletów XXX 000, 000, XXX TaskFlows, Google Gadgets

2. Dostawa oprogramowania równoważnego.

W przypadku oprogramowania równoważnego muszą być spełnione warunki:

1. Zakup licencji oprogramowania równoważnego pozwala na legalne używanie posiadanych przez Zamawiającego licencji oprogramowania Oracle.

2. Oprogramowania równoważne musi być kompatybilne i w sposób niezakłócony współdziałać z oprogramowaniem ORACLE funkcjonującym u Zamawiającego.

3. Wymagane oprogramowanie równoważne musi być dostępne z oficjalnych nośników instalacyjnych producenta oprogramowania od pierwszego dnia umowy.

4. Oprogramowanie równoważne nie może zakłócić pracy środowiska systemowo- programowego Zamawiającego.

5. Warunki i zakres usługi wsparcia dla oprogramowania równoważnego muszą spełnić minimum następujące wymagania:

o dostarczania aktualizacji programów, poprawek, alarmów dot. zabezpieczeń i pakietów poprawek krytycznych,

o dostarczania aktualizacji związanych z zmianami wymagań prawnych,

o dostarczania skryptów podwyższających wersje,

o certyfikacji dla nowych produktów/wersji produktów innych firm,

o dostarczania wersji produktów i technologii obejmujących ogólne wersje poprawione, wybranych wersji programów zawierających nowe funkcje i aktualizacje,

o całodobowej obsługi zgłoszeń serwisowych we wszystkie dni tygodnia - świadczenia pomocy technicznej w zakresie obsługi zgłoszeń w formie elektronicznej lub telefonicznej, w dni robocze w godzinach 9:00-17:00 w języku polskim oraz przez 24 godziny na dobę, 7 dni w tygodniu w języku angielskim,

o obsługi klientów w kwestiach pozatechnicznych w dni robocze w godzinach 9:00- 17:00,

o Okres asysty technicznej przez 12 miesięcy od dnia dostarczenia produktu.

Wykonawca oferujący produkt równoważny musi wykazać spełnienie wszystkich warunków określonych powyżej, a także zobowiązać się do:

1. Dokonania wspólnie z Zamawiającym instalacji oraz testowania oprogramowania równoważnego w środowisku sprzętowo-programowym Zamawiającego.

2. W przypadku, gdy zaoferowane przez Wykonawcę równoważne oprogramowanie:

x. xxx będzie właściwie współpracować ze sprzętem i oprogramowanie funkcjonującym u Zamawiającego, i/lub

b. spowoduje zakłócenia w funkcjonowaniu pracy środowiska sprzętowo- programowego u Zamawiającego, i/lub

c. nie będzie posiadało funkcjonalności takich samych jak wyżej wymienione wymagania,

Wykonawca pokryje wszystkie koszty związane z przywróceniem i sprawnym działaniem infrastruktury sprzętowo-programowej Zamawiającego oraz na własny koszt dokona niezbędnych modyfikacji przywracających właściwe działanie środowiska sprzętowo - programowego Zamawiającego oraz na własny koszt dokona niezbędnych modyfikacji przywracających właściwe działanie środowiska sprzętowo – programowego Zamawiającego, również po odinstalowaniu oprogramowania równoważnego.

3. W przypadku wystąpienia zdarzenia opisanego w ust 2 Zamawiający ma prawo odstąpić od Umowy.

3. Warsztaty

Wykonawca zobowiązany jest przeprowadzić warsztaty:

1. Wykonawca zobowiązany jest do przeprowadzenia Warsztatów dla użytkowników podstawowych oraz administratorów z dostarczonego oprogramowania.

2. Warsztaty powinny być specyficzne dla każdej z grup oprogramowania.

3. Warsztaty dla użytkowników podstawowych Wykonawca zobowiązany jest przeprowadzić dla grupy 8 osób Zamawiającego. Warsztat powinny obejmować podstawy z modelowania i implementacji procesów w dostarczonym oprogramowaniu.

4. Warsztaty dla administratorów Wykonawca zobowiązany jest przeprowadzić dla grupy 5 osób Zamawiającego. Warsztat powinny obejmować podstawy administrowania zakupionym oprogramowaniem.

5. Czas trwania warsztatów dla użytkowników podstawowych oraz administratorów nie może być krótszy niż jeden dzień (8 godzin) na grupę użytkowników podstawowych oraz jeden dzień (8 godzin) na grupę administratorów. Warsztaty dla grupy użytkowników podstawowych oraz grupy administratorów nie mogą odbywać się w tym samym terminie.

6. Zakres warsztatów użytkowników podstawowych z oprogramowania musi umożliwiać użytkownikom samodzielną pracę z właściwym wykorzystaniem podstawowych funkcjonalności oprogramowania.

7. Zakres warsztatów z administrowania oprogramowaniem musi umożliwiać administratorom zapoznanie się z podstawowymi funkcjami w zakresie administrowania oprogramowaniem.

8. Szczegółowy zakres, terminy oraz materiały warsztatowe muszą być uzgodnione z Zamawiającym w planie szkoleń.

9. Sale i sprzęt do szkoleń, wraz z cateringiem zapewnia Wykonawca.

10. Po zakończeniu warsztatów Wykonawca zobowiązany jest do sporządzenia raportu.

Załącznik nr 2 do SIWZ

Istotne postanowienia umowy

UMOWA /2015

zawarta w dniu. r. w Warszawie pomiędzy:

Państwowym Instytutem Geologicznym- Państwowym Instytutem Badawczym z siedzibą w Warszawie przy ul. Rakowieckiej 4, wpisanym do Krajowego Rejestru Sądowego pod nr KRS 0000122099 prowadzonym przez Sąd Rejonowy dla m. st. Warszawy w Warszawie, XIII Wydział Gospodarczy KRS, NIP 000-000-00-00, w imieniu którego działają:

zwanym w dalszej części umowy Zamawiającym,

a

……………………………………………………………………………………………………… zwaną dalej Wykonawcą

W rezultacie dokonanego przez Xxxxxxxxxxxxx wyboru oferty w trybie przetargu nieograniczonego (EZ-240-22/2015), zgodnie z ustawą z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (tekst jednolity Dz. U. z 2013 r., poz. 907 z późn. zm.)-dalej „PZP”, została zawarta umowa o następującej treści:

§1. Przedmiot Umowy

1. Przedmiotem Umowy jest dostawa licencji oprogramowania wraz z usługą 12-miesięcznej asysty technicznej oraz przeprowadzenie warsztatów dla Zamawiającego, zgodnie z ofertą Wykonawcy z dnia……………, Formularzem cenowym (Załącznik nr …….. do niniejszej Umowy), a w szczególności zgodnie z wymogami wskazanymi w Opisie Przedmiotu Zamówienia (dalej „OPZ”) (Załącznik nr ……… do niniejszej umowy).

2. Wykonawca udziela Zamawiającemu bezterminowej, niewyłącznej licencji na korzystanie z oprogramowania. Warunki licencyjne określa umowa licencyjna producenta oprogramowania (stanowiąca Załącznik nr ……), którą Wykonawca musi dostarczyć przed podpisaniem niniejszej umowy.

3. Wykonawca dostarczy przedmiot umowy w formie elektronicznej na nośniku CD lub umożliwi Zamawiającemu dostęp do stron internetowych i pobranie plików instalacyjnych wraz z dokumentacją producenta, potwierdzając do dnia odbioru protokolarnego (o którym mowa w § 6 niniejszej umowy), udzielenie Zamawiającemu licencji na oprogramowanie – certyfikatu licencyjnego i asysty 12 -miesięcznej.

4. Warsztaty, o których mowa w ust.1 Wykonawca jest zobowiązany przeprowadzić nie później niż 30 dni od dnia podpisania Umowy.

§ 2. Wartość Przedmiotu Umowy

1. Z tytułu należytego i zgodnego z warunkami Umowy wykonania przez Wykonawcę Przedmiotu Umowy, o którym mowa w §1 ust. 1, Zamawiający zobowiązuje się zapłacić zgodnie z Załącznikiem nr 1 do niniejszej Umowy wynagrodzenie łączne w wysokości :

Cena netto:

Kwota podatku VAT (stawka VAT 23%):

Cena oferty brutto:

(słownie brutto:) Z czego:

kwota… zł netto plus podatek VAT wg obowiązującej stawki z tytułu

dostawy licencji oprogramowania wraz z usługą 12-miesięcznej asysty technicznej.

kwota………………………………….......zł netto plus podatek VAT wg obowiązującej stawki z tytułu przeprowadzenia warsztatów dla Zamawiającego.

2. Wynagrodzenie, o którym mowa w ust. 1, obejmuje wszelkie koszty, jakie poniesie Wykonawca z tytułu należytej i zgodnej z niniejszą Umową oraz obowiązującymi przepisami - realizacji Przedmiotu Umowy, w tym koszt dostawy, do siedziby Zamawiającego.

§ 3. Warunki płatności

1. Zapłata za Przedmiot Umowy dokonana będzie przelewem na konto Wykonawcy , na podstawie faktury VAT, przedłożonej po zrealizowaniu Przedmiotu Umowy wraz z kopią protokołów odbioru / odbiorów częściowych w terminie 30 dni od dnia przekazania Zamawiającemu faktury wraz z kopią protokołu odbioru podpisanego bez zastrzeżeń przez Zamawiającego.

2. Płatność uważa się za zrealizowaną w dniu wypływu środków pieniężnych z konta Zamawiającego.

3. Wykonawca wystawi fakturę na: Państwowy Instytut Geologiczny- Państwowy Instytut Badawczy, xx. Xxxxxxxxxx 0, 00-000 Xxxxxxxx, posiadający numer NIP 000-000-00-00.

4. Płatność będzie dokonana na nr rachunku bankowego Wykonawcy w terminie 14 dni

od dnia przekazania faktury Zamawiającemu.

§ 4. Terminy realizacji Umowy

1. Przedmiot Umowy wraz z dokumentami potwierdzającymi udzielenie licencji należy dostarczyć do dnia 31 marca 2015 r. do siedziby Zamawiającego w Warszawie, xx. Xxxxxxxxxx 0.

2. Wykonawca zobowiązany jest również do świadczenia na rzecz Zamawiającego wsparcia technicznego obejmującego dostarczone licencje oprogramowania przez okres

…………….miesięcy licząc od daty podpisania Protokołu odbioru bez zastrzeżeń.

3. Warsztaty zostaną przeprowadzone w terminie ustalonym z Zamawiającym, z zastrzeżeniem postanowień § 1 ust.4.

§ 5. Gwarancja

1. Wykonawca udziela gwarancji na warunkach określonych umową licencyjną producenta oprogramowania – zgodnie z Załącznikiem nr ….., nie krótszej jednak niż na okres

……………….miesięcy liczonych od dnia podpisania Protokołu odbioru.

2. Wykonawca wykona zobowiązania wynikające z gwarancji w ciągu 5 dni od daty powiadomienia go przez Zamawiającego o stwierdzonej wadzie.

3. Bieg terminu gwarancji rozpoczyna się z chwilą dokonania przez Zamawiającego odbioru przedmiotu umowy bez zastrzeżeń (data podpisania protokołu odbioru).

4. Wykonawca zobowiązuje świadczyć całodobową obsługę zgłoszeń serwisowych we wszystkie dni tygodnia: tel. ………………………..……., adres e-mail: ……………………..

§ 6. Odbiory

1. Z czynności odbioru przedmiotu umowy Strony sporządzą Protokół odbioru z udziałem przedstawicieli obu Stron.

2. Do podpisywania Protokołów odbioru upoważnione są:

-ze strony Zamawiającego:

-ze strony Wykonawcy:

3. Bez podpisów wszystkich osób upoważnionych do podpisania Protokołu odbioru czynność odbioru jest bezskuteczna.

4. Protokoły odbioru „bez zastrzeżeń” stanowią podstawę do wystawienia faktury VAT przez Wykonawcę.

5. Zamawiający dopuszcza odbiór Przedmiotu umowy w częściach: I część – odbiór po dostarczeniu licencji, II – część – odbiór po przeprowadzeniu warsztatów.

§ 7. Odstąpienie od Umowy i kary umowne

1. W okresie trwania Umowy Zamawiający jest uprawniony do odstąpienia od Umowy z winy Wykonawcy w trybie natychmiastowym w przypadku kiedy Wykonawca opóźni się z realizacją przedmiotu umowy o ponad czternaście dni w stosunku do terminu określonego w § 4 umowy. W takim przypadku Wykonawca zapłaci Zamawiającemu karę umowną w wysokości 20 % wartości umowy, o której mowa w § 2 ust.1 Umowy.

2. Zamawiający może odstąpić od umowy w przypadku, gdy zaoferowane przez Wykonawcę oprogramowanie: a) nie będzie właściwie współpracować ze sprzętem i oprogramowanie funkcjonującym u Zamawiającego, i/lub b) spowoduje zakłócenia w funkcjonowaniu pracy środowiska sprzętowo-programowego u Zamawiającego, i/lub c) nie będzie posiadało funkcjonalności opisanych w OPZ.

3. Zamawiający może dochodzić na zasadach ogólnych odszkodowania przewyższającego kary umowne.

4. W przypadku zwłoki w płatności za Przedmiot Umowy Zamawiający zapłaci Wykonawcy odsetki ustawowe za każdy dzień zwłoki.

§ 8. Postanowienia końcowe

1. Ewentualne spory wynikłe na tle realizacji niniejszej umowy będą rozstrzygane przez Sąd właściwy dla siedziby Zamawiającego.

2. Wszelkie zmiany i uzupełnienia umowy wymagają formy pisemnej pod rygorem nieważności.

3. W sprawach nie uregulowanych Umową mają zastosowanie przepisy kodeksu cywilnego oraz ustawy Prawo zamówień publicznych.

4. Niniejsza Umowa wchodzi w życie w dniu jej podpisania przez strony.

5. Niniejsza Umowa została zawarta w 2 jednobrzmiących egzemplarzach, 1 egzemplarz dla Zamawiającego i 1 egzemplarz dla Wykonawcy.

Za Zamawiającego : Za Wykonawcę:

...................................... ......................................

Załącznik nr 3 do SIWZ

Dane Wykonawcy / Wykonawców występujących wspólnie

Adres Wykonawcy: kod, miejscowość ulica, nr lokalu

Nr telefonu:

Nr faksu:

E-mail:

REGON:

NIP:

O F E R T A

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

00-000 Xxxxxxxx, xx. Xxxxxxxxxx 0

Nawiązując do ogłoszenia o przetargu nieograniczonym sygn. EZ-240-22/2015 na:

Dostawa licencji oprogramowania wraz z 12 miesięczną usługą wsparcia technicznego oraz usługą szkoleniową dla Państwowego Instytutu Geologicznego – Państwowego Instytutu Badawczego

My niżej podpisani działając w imieniu i na rzecz:

………………………………………………………………………………………………….

(nazwa (firma) dokładny adres Wykonawcy/Wykonawców)

(w przypadku składania oferty przez Wykonawców wspólnie ubiegających się o udzielenie zamówienia należy podać nazwy(firmy) i adresy wszystkich tych Wykonawców)

I. Oferujemy wykonanie dostawy objętej przedmiotem zamówienia, określonej w specyfikacji istotnych warunków zamówienia za:

Cena oferty brutto* ...................................

słownie: zł.

*-zgodnie z formularzem cenowym

II. Termin dostawy licencji do Zamawiającego wynosi (dni) od daty podpisania umowy, jednak

nie później niż do 31.03.2015 r.

III. Okres gwarancji: zgodnie z § 5 Istotnych postanowień umowy.

IV. Oświadczamy, że:

1. Zapoznaliśmy się z treścią SIWZ, a w szczególności z opisem przedmiotu zamówienia i z postanowieniami umowy oraz, że wykonamy zamówienie na warunkach i zasadach określonych tam przez Zamawiającego.

2. Otrzymaliśmy konieczne informacje do przygotowania oferty. Akceptujemy wskazany w SIWZ termin związania ofertą, w razie wybrania naszej oferty zobowiązujemy się do podpisania umowy na warunkach zawartych w SIWZ w miejscu i terminie wskazanym przez Xxxxxxxxxxxxx.

3. Zamówienie wykonamy samodzielnie*/

Część zamówienia (określić zakres przewidywany do powierzenia podwykonawcom)

…………………………………………………………………………………………-

zamierzamy powierzyć podwykonawcom*……………………………………

(nazwa i adres podwykonawcy)

Świadom (-i) odpowiedzialności karnej oświadczam (-y), że załączone do oferty dokumenty opisują stan prawny i faktyczny aktualny na dzień złożenia niniejszej oferty (art. 297 k.k.).

4. Dokumenty zawarte na stronach od .........................do ......................... zawierają informacje stanowiące tajemnicę przedsiębiorstwa w rozumieniu przepisów o zwalczaniu nieuczciwej konkurencji i nie mogą być ujawniane pozostałym uczestnikom postępowania (wypełnić jeśli dotyczy);

5. Wszelką korespondencję w dotyczącą niniejszego zamówienia należy kierować na:

Imię i nazwisko

Instytucja

Adres

Nr faks

Nr telefonu

Adres e-mail

6. Na kolejno ponumerowanych stronach składamy całość oferty. Załącznikami do niniejszej

oferty, stanowiącymi jej integralną cześć są: 1) ……………………………

2) ……………………………

3) ……………………………

4) ……………………………

5) ……………………………

6) ……………………………

*odpowiednio skreślić albo wypełnić

Lp. Nazwisko i imię osoby (osób) uprawnionej(ych) do reprezentowania Wykonawcy lub posiadającej (ych) pełnomocnictwo Podpis(y) osoby(osób) uprawnionej(ych) Miejscowość i data

Załącznik nr 3a do SIWZ

FORMULARZ CENOWY

Składając w imieniu ofertę w Państwowym

Instytucie Geologicznym – Państwowym Instytucie Badawczym w Warszawie przy ul. Rakowieckiej 4 na „Dostawę licencji oprogramowania wraz z 12 miesięczną usługą wsparcia technicznego oraz usługą szkoleniową dla Państwowego Instytutu Geologicznego – Państwowego Instytutu Badawczego” oferujemy realizację przedmiotu zamówienia zgodnie z podanymi niżej cenami:

nr poz.	przedmiot zamówienia	rodzaj	oferowane oprogramowanie – nazwa oprogramowania	ilość	cena jednostkowa netto	wartość netto	kwota podatku VAT (23%)	cena brutto
a	b	c	d	e	f	g (f x e)	h	i (g+h)
1	SOA Suite for Oracle Middleware lub równoważne	procesor		2
2	Weblogic Suite lub równoważne	procesor		4
3	Unified Business Process Management Suite lub równoważne	procesor		2
4	SOA Suite for Oracle Middleware lub równoważne	NUP		20
5	WebLogic Suite lub równoważne	NUP		20
6	Unified Business Process Management Suite lub równoważne	NUP		20
7	Warsztaty			1
			Razem (cena oferty)					*

* cenę Razem brutto należy przenieść do Formularza ,,Oferta’’

……............................................, dnia ....................... ………................................................................

Podpis Wykonawcy lub upoważnionego

przedstawiciela Wykonawcy

Załącznik nr 4 do SIWZ

OŚWIADCZENIE WYKONAWCY

O SPEŁNIANIU WARUNKÓW UDZIAŁU W POSTĘPOWANIU

My, niżej podpisani, działając w imieniu i na rzecz:

.....................................................................................................................................................

.....................................................................................................................................................

.....................................................................................................................................................

(nazwa /firma/ i adres Wykonawcy/ wykonawców wspólnie ubiegających się o udzielenie zamówienia)

niniejszym oświadczamy, że ubiegając się o zamówienie publiczne na

Dostawę licencji oprogramowania wraz z 12 miesięczną usługą wsparcia technicznego oraz usługą szkoleniową dla Państwowego Instytutu Geologicznego – Państwowego Instytutu Badawczego

spełniamy warunki o których mowa w art. 22 ust. 1 ustawy Prawo zamówień publicznych (t. j. Dz. U. z 2013 r. poz. 907 z późń. zm.).

Lp. Nazwisko i imię osoby (osób) uprawnionej(ych) do reprezentowania Wykonawcy lub posiadającej (ych) pełnomocnictwo Podpis(y) osoby(osób) uprawnionej(ych): Miejscowość i data:

Załącznik nr 5 do SIWZ

OŚWIADCZENIE

O BRAKU PODSTAW DO WYKLUCZENIA Z POSTĘPOWANIA

My niżej podpisani, działając w imieniu i na rzecz:

.....................................................................................................................................................

.....................................................................................................................................................

.....................................................................................................................................................

(nazwa /firma/ i adres Wykonawcy)

niniejszym oświadczamy, że ubiegając się o zamówienie publiczne na:

Dostawę licencji oprogramowania wraz z 12 miesięczną usługą wsparcia technicznego oraz usługą szkoleniową dla Państwowego Instytutu Geologicznego – Państwowego Instytutu Badawczego

nie podlegamy wykluczeniu z postępowania o udzielenie zamówienia publicznego na podstawie art. 24 ust. 1 ustawy Prawo zamówień publicznych (t. j. Dz. U. z 2013 r. poz. 907 z późn. zm.).

Lp. Nazwisko i imię osoby (osób) uprawnionej(ych) do reprezentowania Wykonawcy lub posiadającej (ych) pełnomocnictwo Podpis(y) osoby(osób) uprawnionej(ych): Miejscowość i data:

Załącznik nr 6 do SIWZ

OŚWIADCZENIE

My, niżej podpisani, działając w imieniu i na rzecz:

.....................................................................................................................................................

.....................................................................................................................................................

.....................................................................................................................................................

(nazwa /firma/ i adres Wykonawcy/ Wykonawców wspólnie ubiegających się o udzielenie zamówienia)

niniejszym oświadczamy, że ubiegając się o zamówienie publiczne na:

Dostawę licencji oprogramowania wraz z 12 miesięczną usługą wsparcia technicznego oraz usługą szkoleniową dla Państwowego Instytutu Geologicznego – Państwowego Instytutu Badawczego

□ należymy do tej samej grupy kapitałowej, o której mowa w art. 24 ust. 2 pkt 5 z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2013 r. poz. 907 z późn. zm.), w skład której wchodzą następujące podmioty: ………………………….

□ nie należymy do grupy kapitałowej*

Lp. Nazwisko i imię osoby (osób) uprawnionej(ych) do reprezentowania Wykonawcy lub posiadającej (ych) pełnomocnictwo
Podpis(y) osoby(osób) uprawnionej(ych):
Miejscowość i data:

* zaznaczyć odpowiednie