Studium Wykonalności dla projektu „e-Zamówienia - elektroniczne zamówienia publiczne' Strona 1 z 121

STUDIUM WYKONALNOŚCI

dla projektu

„e-Zamówienia - elektroniczne zamówienia publiczne"

31 marca 2017 r.

Spis treści

Słownik.............................................................................................................................................6

1    Nazwa Projektu.......................................................................................................................8

2    Wnioskodawca........................................................................................................................8

2.1    Dane Wnioskodawcy.......................................................................................................8

2.2    Partnerzy.........................................................................................................................8

2.2.1    Liczba partnerów.........................................................................................................8

2.2.2    Uzasadnienie wyboru partnerów................................................................................8

2.2.3    Zgodność prawna wyboru partnerów.........................................................................9

2.3    Doświadczenie wnioskodawcy i partnera w realizacji    projektów...................................9

2.4    Opis wcześniej zrealizowanych projektów......................................................................9

3    Streszczenie Projektu............................................................................................................14

3.1    Krótki opis Projektu.......................................................................................................14

3.2    Planowany okres realizacji Projektu..............................................................................15

3.3    Opis stanu obecnego.....................................................................................................16

3.3.1    Aktualne rozwiązania IT w UZP w zakresie    zamówień    publicznych..........................16

4    Cele........................................................................................................................................18

4.1.1    Cel szczegółowy - Zwiększenie jakości dokumentów zamówienia, tj. zapewnienie

zgodności przygotowywanych dokumentów z wymaganiami ...................................................... 19

4.1.2    Cel szczegółowy - Możliwość efektywnego monitorowania, analiz i kontroli procesu

postępowania o udzielenie zamówienia publicznego ................................................................... 19

4.1.3    Cel szczegółowy - Optymalizacja kosztów    i czasu    trwania postępowania o udzielenie

zamówienia publicznego...............................................................................................................20

4.1.4    Wsparcie interesariuszy w wypełnieniu    ustawowego    obowiązku elektronizacji

postępowań o udzielenie zamówienia publicznego ...................................................................... 21

4.2    Spójność celów Projektu z celami organizacji i dokumentów strategicznych ............... 21

4.2.1    Zgodność z dokumentami strategicznymi.................................................................21

4.2.2    Właściwość merytoryczna.........................................................................................23

4.2.3    Zgodność z celami    POPC -    Działanie    2.1....................................................................23

4.3    Korzyści społeczne ......................................................................................................... 24

5    Odbiorcy Projektu..................................................................................................................27

5.1    Charakterystyka użytkowników....................................................................................27

5.2    Identyfikacja problemu i potrzeb..................................................................................28

5.3    Analiza Opcji - Opis możliwych rozwiązań problemu i    zaspokojenia potrzeb............... 30

5.3.1    Liczba wariantów rozwiązań potrzeb ........................................................................ 30

5.3.2    Opis wariantów rozwiązania ..................................................................................... 30

5.3.3    Zaangażowanie użytkowników w pracach nad rozwiązaniami ................................. 31

5.4    Wybrane rozwiązanie wraz z uzasadnieniem ................................................................ 32

5.4.1    Charakterystyka wariantów......................................................................................33

5.4.2    Złożoność techniczna systemu..................................................................................33

5.4.3    Funkcjonalność systemu............................................................................................34

5.4.4    Wykonalność organizacyjna......................................................................................34

5.4.5    Zarządzanie powstałym systemem...........................................................................34

5.4.6    Korzyści dla użytkowników końcowych.....................................................................35

5.5 Analiza wariantów - porównania i oceny możliwych do zastosowania rozwiązań inwestycyjnych..................................................................................................................................35

5.5.1    Analiza wariantów (opcji)..........................................................................................35

5.5.2    Analiza wielokryterialna............................................................................................35

5.5.3    Wybór rozwiązania....................................................................................................36

6    Produkty projektu..................................................................................................................37

6.1    Funkcjonalności.............................................................................................................37

6.1.1    Liczba funkcjonalności...............................................................................................37

6.1.2    Opis funkcjonalności..................................................................................................37

6.1.3    Dojrzałość e-usług Projektu.......................................................................................42

6.2    Analiza procesów biznesowych i optymalizacja procesów ........................................... 46

6.3    Wprowadzone innowacje .............................................................................................. 53

6.4    Weryfikacja produktów przez    użytkowników ............................................................... 54

6.4.1    Metodologia weryfikacji produktów przez użytkowników.......................................54

6.4.2    Zaangażowanie użytkowników w weryfikację produktów........................................55

6.4.3    Częstotliwość zaangażowania użytkowników w weryfikację produktów.................55

6.4.4    Charakterystyka grupy kontrolnej grupy użytkowników...........................................55

6.4.5    Opis weryfikacji produktów przez użytkowników.....................................................56

7    Analiza otoczenia...................................................................................................................58

7.1    Gotowość legislacyjna...................................................................................................58

7.1.1    Możliwość realizacji Projektu....................................................................................58

7.1.2    Analiza otoczenia prawnego......................................................................................58

7.2    Prawa Autorskie............................................................................................................59

7.2.1    Otwarta licencja.........................................................................................................59

7.2.2    Uzasadnienie wyboru odpowiedniego modelu prawnego........................................ 59

8    Budżet....................................................................................................................................60

8.1    Koszty ogólne................................................................................................................60

8.2    Analizy ........................................................................................................................... 60

8.2.1    Analiza kosztów i korzyści ......................................................................................... 60

8.3    Nakłady na poszczególne elementy    projektu................................................................69

8.4    Analiza kosztów utrzymania..........................................................................................69

8.5 Analiza ekonomiczno - finansowa..................................................................

9    Zarządzanie projektem...........................................................................................

9.1    Metoda i przebieg realizacji Projektu.............................................................

9.1.1    Metoda prowadzenia Projektu...................................................................

9.1.2    Metoda prowadzenia Projektu...................................................................

9.1.3    Przebieg realizacji Projektu........................................................................

9.1.4    Przebieg realizacji Projektu........................................................................

9.1.5    Zadania Projektu.........................................................................................

9.2    Analiza i monitorowanie ryzyka.....................................................................

9.3    Promocja Projektu..........................................................................................

10    Analiza techniczna..................................................................................................

10.1    Planowana architektura rozwiązania.............................................................

10.1.1    Sposób realizacji Projektu......................................................................

10.2    Standardy architektoniczne i technologiczne ...............................................

10.2.1    Architektura systemu ............................................................................

10.2.2    Wymagania hostingu..............................................................................

10.3    Wydajność i skalowalność planowanego systemu.........................................

10.4    Komplementarność Projektu wobec istniejących i planowanych

administracji państwowej..................................................................................................

10.5    Wykorzystanie zasobów.................................................................................

10.6    Utrzymanie.....................................................................................................

10.7    Szkolenia.........................................................................................................

10.7.1    Utrzymanie kompetencji .......................................................................

10.7.2    Metodyka szkoleń...................................................................................

10.7.3    Szkolenia zdalne ....................................................................................

10.7.4    Kosztorys szkoleń...................................................................................

10.8    Infrastruktura ................................................................................................

10.8.1    Opis infrastruktury.................................................................................

10.8.2    Gotowość infrastruktury........................................................................

10.8.3    Informacje dotyczące istniejącej infrastruktury.....................................

10.8.4    Informacje dotyczące stworzenia potencjalnej infrastruktury...............

11    Zapewnienie bezpieczeństwa teleinformatycznego..............................................

11.1    Zabezpieczenia systemowe............................................................................

11.2    Bezpieczeństwo danych.................................................................................

11.3    Bezpieczeństwo aplikacji................................................................................

11.4    Testy bezpieczeństwa systemu......................................................................

11.5    Bezpieczeństwo infrastruktury ......................................................................

11.6 Zestawienie zasobów niezbędnych do zapewnienia wymaganego poziomu

bezpieczeństwa...............................................................................................................................116

12    Pomoc publiczna i pomoc de minimis.................................................................................118

12.1    Pomoc publiczna..........................................................................................................118

12.2    Pomoc de minimis.......................................................................................................119

13    Analiza wykonalności...........................................................................................................121

Słownik

1 Nazwa Projektu

2 Wnioskodawca

2.1 Dane Wnioskodawcy

Ministerstwo Cyfryzacji, ul. Królewska 27, 00-060 Warszawa Ministerstwo Cyfryzacji - Piotr Biłas, piotr.bilas@mc.gov.pl

2.2 Partnerzy

2.2.1 Liczba partnerów

Urząd Zamówień Publicznych, ul. Postępu 17a, 02-676 Warszawa

Urząd Zamówień Publicznych - Arkadiusz Koperski, e-zamowienia@uzp.gov.pl

2.2.2 Uzasadnienie wyboru partnerów

Minister Cyfryzacji zgodnie z przyjętą „Strategią Informatyzacji Państwa - Plan Działań Ministra Cyfryzacji" realizuje zadania, których celem jest usprawnienie działania administracji publicznej, a co za tym idzie funkcjonowania państwa polskiego dzięki informatyzacji. Projekty realizowane przez Ministra Cyfryzacji koncentrują się na integrowaniu rozproszonych zasobów informatycznych państwa i zapewnieniu ich interoperacyjności, a także ustandaryzowaniu informacji publicznej dzięki czemu korzystanie z usług e-administracji będzie mogło być realizowane w sposób cyfrowy.

Urząd Zamówień Publicznych (UZP) jest jedynym, centralnym organem administracji rządowej właściwym w sprawach zamówień publicznych, w zakresie określonym ustawą z dnia 29 stycznia 2004 r. Prawo zamówień publicznych. Jest na rynku jedyną jednostką merytoryczną, odpowiedzialną za kreowanie warunków dla nowoczesnego procesu udzielania zamówień publicznych i podnoszenia poziomu ich innowacyjności poprzez między innymi zapewnienie zgodności regulacji polskiego systemu zamówień publicznych z prawem europejskim.

Zrealizowanie Projektu „e-Zamówienia - elektroniczne zamówienia publiczne" jest możliwe tylko i wyłącznie dzięki połączeniu posiadanej przez MC bezpiecznej infrastruktury centralnej oraz kompetencji technicznych z zakresu realizacji i prowadzenia projektów IT, z ekspercką wiedzą merytoryczną UZP w zakresie nadzoru i wprowadzania regulacji europejskich z zakresu prawa zamówień publicznych. Zadania realizowane przez MC i UZP są komplementarne w ramach projektu. Żaden z Partnerów ze względu na zakres i cele swojej działalności nie był by w stanie zrealizować projektu samodzielnie.

Wybór UZP jako Partnera Projektu nie wymaga przeprowadzenia otwartej procedury wyboru jako iż UZP jest instytucją publiczną. Nie ma zastosowania art. 33 ustawy z dnia 11 lipca 2014 (Dz. U. z 2016 r., poz. 217 ze zm., tzw. „ustawa wdrożeniowa) gdyż UZP nie jednostką podległą lub nadzorowaną przez MC (UZP jest podległa i nadzorowana przez MR).

Między stronami zawarto w dniu 29.03.2017 r. stosowną Umowę - porozumienie określające:

•    prawa i obowiązki stron;

•    zakres i formę udziału Partnerów w Projekcie;

•    Partnera wiodącego uprawnionego do reprezentowania Partnerstwa;

•    sposób przekazywania dofinansowania na pokrycie kosztów ponoszonych przez Partnerów Projektu, umożliwiający określenie kwoty dofinansowania udzielonego dla Lidera Partnerstwa oraz Partnera;

•    sposób postępowania w przypadku naruszenia lub niewywiązania się stron z Umowy.

2.2.3 Zgodność prawna wyboru partnerów

TAK

2.3 Doświadczenie wnioskodawcy i partnera w realizacji projektów

2.4 Opis wcześniej zrealizowanych projektów

W celu usprawnienia i zwiększenia efektywności zarządzania projektami w MC aktualna struktura Ministerstwa została dostosowana do warunków niezbędnych do realizacji projektów, a pracownicy Ministerstwa włączeni zostali w przygotowanie założeń projektów już na pierwszym etapie ich konstruowania. Koordynacja wszystkich projektów na poziomie utworzonego w MC Biura Zarządzania Portfelem Projektów ma na celu zapewnienie komplementarności nie tylko projektów

MC, ale także innych projektów z administracji publicznej objętych zakresem portfela oraz bieżący monitoring ich postępu.

Podczas gdy Ministerstwo przejmuje rolę zarządczą w projektach, sama techniczna ich realizacja pozostaje po stronie wyspecjalizowanych jednostek podległych lub nadzorowanych przez MC. W strukturze MC zakłada się powołanie zespołów projektowych oraz Komitetów Sterujących dedykowanych do poszczególnych projektów.

Ministerstwo Cyfryzacji w dotychczas prowadzonych projektach bazowało na metodyce Prince2, jako znanej i powszechnie uznawanej metodyce zarządzania projektami. Natomiast wykonawcy realizujący umowy zawarte z Ministerstwem (na podstawie Pzp) wykorzystywali metodyki zwinne w odniesieniu do dostarczania produktów

W tabeli poniżej znajdują się przykłady projektów, w które Ministerstwo Cyfryzacji było zaangażowane w przeszłości. Wnioski z ich realizacji stały się podstawą założeń oraz planowanego sposobu realizacji obecnie przygotowywanych projektów. Doświadczenie zdobyte podczas realizacji projektów realizowanych przez Beneficjentów będzie wykorzystane przy realizacji Projektu e-Zamówienia.

3 Streszczenie Projektu

3.1 Krótki opis Projektu

Projekt e-Zamówienia - elektroniczne zamówienia publiczne zapewni zbudowanie efektywnego, spełniającego potrzeby i oczekiwania interesariuszy systemu zamówień publicznych w Polsce.

Projekt obejmuje:

•    Budowę Platformy e-Zamówienia podległej administracji rządowej z Centralnym Repozytorium Danych, udostępniającej bezpłatnie Usługę Monitorowania i Analiz, Biuletyn Zamówień Publicznych, zabezpieczenia składanych ofert i wniosków, aukcji i licytacji elektronicznej.

•    Wystandaryzowanie usług, pozwalających na przeprowadzenie całego procesu udzielenia zamówienia publicznego,. Platforma udostępni zestandaryzowane API pozwalające na wymianę danych i dokumentów oraz umożliwiające integrację usług w procesie.

Platforma e-Zamówienie obejmować będzie następujące moduły:

•    Centralne Repozytorium Danych

•    Biuletyn Zamówień Publicznych

•    Moduł Monitorowania i Analiz, w tym BI (ang. Business Intelligence)

•    Aukcje i licytacje elektroniczne

•    eSender

•    Moduł przyjmowania i zabezpieczania ofert/ wniosków do terminu ich otwarcia

Platforma e-Zamówienia zapewni kompletność i spójność informacji o funkcjonowaniu rynku zamówień publicznych w Polsce umożliwiając skuteczne i efektywne sprawowanie funkcji nadzorczych i sprawozdawczych poprzez funkcjonalność zbierania i udostępniania danych dotyczących procesu udzielania zamówień publicznych z portali oferujących e-usługi w tym obszarze.

Dzięki realizacji Projektu, jego odbiorcy uzyskają m.in.

-    łatwiejszy, sprawniejszy i szybszy proces przygotowania postępowań o udzielenie zamówień publicznych, w tym wykorzystanie raz wprowadzonych danych do przygotowania wielu dokumentów/formularzy oraz przeprowadzenia licytacji i aukcji, możliwość przesłania ogłoszeń w sprawie zamówienia zarówno do BZP jak i TED (ustandaryzowanie formularzy oraz ich walidacja), automatyzację sprawozdawczości rocznej - zamawiający;

-    szybki i łatwy dostęp do wszystkich ogłoszeń o zamówieniach oraz pozostałych informacji o postępowaniach o udzielenie zamówienia, przesyłanie ofert/wniosków na platformę e-zamówienia - wykonawcy/oferenci;

-    bezpośredni nadzór i kontrola nad wszystkimi postępowaniami zamówień publicznych, możliwość analiz i raportów w dowolnym momencie - Prezes UZP;

-    szybszy dostęp do niezbędnych informacji dotyczących postępowań - organy kontroli (tj. Sądy, NIK), Krajowa Izba Odwoławcza (KIO).

W wyniku realizacji Projektu podstawowymi środkami komunikacji i wymiany informacji na wszystkich etapach postępowania o udzielenie zamówienia będą elektroniczne środki informacji i komunikacji. Projekt obejmuje elektronizację nowych usług, bądź poprawę funkcjonalności oraz e-dojrzałości istniejących usług w obszarze zamówień publicznych.

Planowana architektura Platformy pozwoli na rozwój e-usług oferowanych przez dowolnych oferentów (dostawców) oprogramowania.

Zamawiający i wykonawcy będą mogli realizować proces udzielania zamówień publicznych na dowolnej platformie własnej lub udostępnionej przez inny podmiot, jednakże poprzez koncepcję Centralnego Repozytorium Danych zapewniony zostanie dostęp do niezbędnych danych i dokumentów niezależnie od miejsca rejestracji interesariusza procesu. Planowany moduł Monitorowania i Analiz pozwoli na bieżące śledzenie procesu zarówno przez Prezesa UZP (obowiązek ustawowy), jak i przez zamawiających - własne postępowania. Moduł BI pozwoli na przekrojowe analizy danych zagregowanych o toczących się oraz zakończonych już postępowaniach.

Planowane rozwiązanie łączy rozwiązanie scentralizowane z jednoczesnym udziałem wielu platform komercyjnych lub własnych zamawiających i opiera się o następujące założenia:

1.    Proces udzielania zamówienia publicznego realizowany jest poprzez usługi oferowane przez komercyjne platformy lub platformy poszczególnych zamawiających (w tym systemy EZD).

2.    Platformy te wspierać będą poszczególne etapy procesu postępowania o udzielenie zamówienia publicznego od momentu przygotowywania ogłoszenia o zamówieniu (lub wstępnego ogłoszenia o zamówieniu) do podpisania umowy z wyłonionym oferentem i publikacji ogłoszenia o udzielonym zamówieniu lub ogłoszenia o zmianie umowy.

3.    Każdy zamawiający i wykonawca może korzystać z usług dowolnej platformy w procesie udzielania zamówienia publicznego bez względu na to na jakiej dokonał rejestracji.

4.    W trakcie kolejnych etapów postępowania o udzielenie zamówienia publicznego do Repozytorium z platform przekazywane będą metadane, dane ustrukturyzowane powstające w procesie zamówień publicznych niezbędne do prawidłowego przeprowadzenia postępowania (szczegółowy zakres danych do analizy).

5. Na Platformie nie będą przetwarzane informacje oznaczone klauzulą tajności w rozumieniu Ustawy o ochronie informacji niejawnych z 5.08.2010 r.

Przyjęte założenia umożliwią dostęp do pełnej informacji o każdym postępowaniu, bez względu na to na jakiej platformie zostało zainicjowane. Pełna standaryzacja przepływów pracy (workflow), procedur, protokołów wymiany danych, itp. gwarantuje jednolitość danych potrzebną dla późniejszego raportowania i analizy rynku oraz skuteczny dostęp do informacji.

E-usługi oferowane przez Platformę e-Zamówienia będą bezpłatnie udostępniane wszystkim interesariuszom.

Wyżej opisane podejście sprawia, że każdy zarejestrowany na dowolnej platformie dostawca ma dostęp do całego rynku zamówień publicznych.

Projekt uwzględnia rozwiązania i obowiązki nałożone na państwa członkowskie UE zaimplementowane w obowiązujących przepisach i dyrektywach unijnych dotyczących zamówień publicznych.

3.2 Planowany okres realizacji Projektu

3.3 Opis stanu obecnego

Od 2008r. Prezes UZP wydaje Biuletyn Zamówień Publicznych (BZP) wyłącznie w formie elektronicznej.

BZP oferuje następujące e-usługi:

-    dostęp dla Zamawiających do formularzy elektronicznych ogłoszeń z zakresu zamówień publicznych i zamieszczenie ich w BZP

-    dostęp dla Zamawiających do formularza elektronicznego rocznych sprawozdań o udzielonych zamówieniach publicznych i przesyłanie ich do Prezesa UZP

-    przegląd i subskrypcja ogłoszeń zamieszczonych w BZP.

W 2015 r. w Polsce 35 tysięcy podmiotów miało status Zamawiających. Są to użytkownicy, którym przyznano kody autoryzacji do zamieszczania ogłoszeń i przesyłania Prezesowi UZP rocznych sprawozdań. W systemie subskrypcji ogłoszeń jest zarejestrowanych ponad 16 tysięcy użytkowników.

W obszarze zamówień publicznych administracja rządowa oferuje kilka podstawowych e-usług za pomocą funkcjonujących systemów teleinformatycznych. W chwili obecnej Urząd Zamówień Publicznych udostępnia:

•    Biuletyn Zamówień Publicznych (BZP) wraz z modułem składania rocznych sprawozdań z udzielonych zamówień,

•    Platformę Aukcji,

•    Platformę Licytacji.

BZP umożliwia zarejestrowanym zamawiającym przygotowywanie i zamieszczanie ogłoszeń (np. o zamówieniu, udzieleniu zamówienia, konkursie) zgodnych z wzorami wymaganymi przez ustawę Pzp w postępowaniach o wartości z przedziału od 30.000 euro do progów unijnych. W ograniczonym zakresie udostępniona jest możliwość wyszukiwania ogłoszeń wg dostępnych kryteriów oraz ich subskrypcja przez wykonawców. Platformy aukcji i licytacji udostępniają funkcje przeprowadzenia aukcji albo licytacji.

Oferowane usługi charakteryzują się niskim poziomem dojrzałości, nie są zintegrowane i nie spełniają wymagań interoperacyjności. Przestarzałe narzędzia posiadają ograniczoną funkcjonalność i w konsekwencji efektywne wprowadzanie zmian kształtu i zakresu formularzy ogłoszeń nie jest możliwe. Bazowanie na obecnie oferowanych przez UZP e-usługach nie jest więc uzasadnione zarówno pod względem technologicznym, jak i ekonomicznym. Z tytułu utrzymania obecnych usług UZP ponosi rocznie koszty w wysokości 272 tys. zł. Urząd nie posiada również praw autorskich do ww. modułów, co uniemożliwia rozwój i modyfikację.

Dostępne w chwili obecnej usługi nie pozwalają na przeprowadzenie w pełni elektronicznie procesu udzielenia zamówienia publicznego. Nie istnieje również spójne i kompletne źródło danych na temat zamówień publicznych w Polsce. Brakuje efektywnych narzędzi i usług umożliwiających monitorowanie i analizę danych już zbieranych przez UZP.

3.3.1 Aktualne rozwiązania IT w UZP w zakresie zamówień publicznych

System Biuletyn Zamówień Publicznych został opracowany w 2007 roku i od tego czasu był wielokrotnie modyfikowany i dostosowywany zarówno do wymogów funkcjonalnych jak również wydajnościowych.

Ze względu na to, iż:

1. Podstawowa technologia używana w BZP do zbierania danych od użytkowników to XFORMS przy dużych i skomplikowanych formularzach jest trudna w utrzymaniu, nieskalująca się oraz powolna przy dużej ilości danych na ekranie. Technologia XForms wymusza przy

przetwarzaniu formularza przeliczanie wszystkich pól, co przy znacznej ilości walidowanych pól powoduje spowolnienie działania systemu w stopniu niedopuszczalnym. Powoduje to, że poziom weryfikacji wprowadzanych informacji jest niewystarczający.

2.    Struktura bazy danych jest przygotowana pod samo BZP - struktura danych w bazie danych zakłada trzymanie całych sesji w postaci plików XML w tabeli - nie jest to optymalne rozwiązanie

3.    Sama aplikacja napisana jest „na miarę" nie pozwala na dołączanie dodatkowych modułów

4.    Aplikacja nie jest zgodna z KRI (Krajowe Ramy Interoperacyjności) - np. brak zdefiniowanych usług webservice dostępu do danych.

5.    FrontEnd (część wizualna) aplikacji nie jest dostoswany do urządzeń przenośnych (nie obsługuje HTML5)

6.    Portal nie spełnia wymagań WCAG.

Niezasadnym ekonomicznie i technologicznie jest dalsza jego rozbudowa, a architektura systemu uniemożliwia integrację z innymi usługami planowanymi na platformie e-Zamówienia.

Zastosowana technologia XForms ze względu na swoją specyfikę działania - centralne przetwarzanie sesji na serwerze, nie na stacji hosta - powoduje, że przy istotnym zwiększeniu obciążenia wymagana byłaby znaczna rozbudowa infrastruktury serwerowej. Biorąc pod uwagę, że system jest hostowany w 2 niezależnych lokalizacjach.

Projekt platformy aukcji i licytacji został rozpoczęty w połowie 2007 roku z wykorzystaniem technologii JavaScript, JQuery, AJAX w warstwie prezentacji, PHP i Apache w warstwie aplikacji oraz bazy MySQL (serwer baz danych php-mysql-5.2.13-1 oraz mysql server 5.1.41) w oparciu o systemy operacyjne Linux Debian i Fedora.

System licytacji elektronicznych został udostępniony interesariuszom w roku 2009, zaś aukcje w styczniu 2010 r.

System zbudowany jest z wykorzystaniem przestarzałych narzędzi, nie wspieranych obecnie przez producenta. Urząd nie posiada autorskich praw majątkowych i kodów źródłowych, przez co niemożliwa jest rozbudowa systemu w niezbędnym zakresie.

Architektura systemu oraz niski poziom dojrzałości oferowanych e-usług uniemożliwia integrację z innymi usługami planowanymi na platformie e-Zamówienia.

Autor oprogramowania i posiadacz praw autorskich, jest jedynym podmiotem uprawnionym do dokonywania w nim zmian, modyfikacji i aktualizacji (dotychczas świadczy usługę opieki administracyjnej, wsparcia technicznego i wsparcia użytkowników Platform licytacji i aukcji elektronicznych).

Dokonywane modyfikacje obejmują jedynie zmiany związane wadliwym działaniem Systemu, natomiast nie obejmują zmian mających na celu zwiększenie, czy też poprawienie funkcjonalności.

4 Cele

Celem Projektu jest efektywny, spełniający potrzeby i oczekiwania interesariuszy zelektronizowany proces udzielania zamówień publicznych w Polsce.

Zbudowane w ramach Projektu e-usługi ułatwią i skrócą postępowania o udzielenie zamówienia publicznego przeprowadzane zgodnie z ustawą Pzp zarówno dla zamawiających (w większości administracja publiczna) jak i dla wykonawców. Dodatkowo Projekt przyczyni się do usprawnienia działania organów kontroli w obszarze zamówień publicznych, tj. Prezesa UZP, NIK, CBA oraz KIO.

Kolejnym założeniem Projektu jest ustandaryzowanie danych, pozyskiwanie ich na bieżąco do CRD (poprzez API), dzięki czemu sprawozdawczość zostanie zautomatyzowana oraz możliwe będzie efektywne monitorowanie i kontrola procesu udzielania zamówień publicznych. Jednocześnie dostęp do informacji o rynku zamówień publicznych będzie „powszechny" dla wszystkich interesariuszy.

Poniżej zaprezentowano cele szczegółowe realizowane przez projekt. Każdy z nich został określony na podstawie analizy potrzeb i problemów zaprezentowanych w innych częściach opracowania. Cele te są logicznie powiązane ze sobą zakładając z jednej strony podnoszenie jakości i dostępności danych i usług w obszarze zamówień publicznych, a z drugiej korzyści wynikających z dostępu do tych danych i usług.

Schemat - drzewo celów

Schemat - powiązanie problemów z celami

4.1.1 Cel szczegółowy - Zwiększenie jakości dokumentów zamówienia, tj. zapewnienie zgodności przygotowywanych dokumentów z wymaganiami

Zamawiający zobowiązani do stosowania przepisów Prawo zamówień publicznych (Pzp) obecnie tworzą szablony i wzory wielu dokumentów (np. oświadczenia, informacja o wyborze oferty) we własnym zakresie, co powoduje wiele niejasności i błędów a także braków w publikowanych dokumentach. Ich wyjaśnianie i poprawa zajmuje dużo czasu i wydłuża procedurę udzielenia zamówienia publicznego. Trudności te na początku dotyczą Zamawiającego, a w dalszych etapach postępowania, także Oferentów/Wykonawców. Ze względu na brak rozwiązania, które umożliwia re-używalność danych, interesariusze zmuszeni są wprowadzać wielokrotnie te same dane do różnych dokumentów (np. ogłoszenie o zamówieniu, SIWZ, ogłoszenie o zmianach w ogłoszeniu o zamówieniu), co powoduje ryzyko błędu i niespójności (a to skutkuje dodatkowymi czynnościami do wykonania oraz naraża zamawiających realizujących swoje zamówienia ze środków unijnych na ryzyko korekty).

Powyższy cel Projektu, tj. zwiększenie jakości dokumentów będzie osiągnięty poprzez ustandaryzowanie usług i formularzy/dokumentów pozwalających na prawidłowe przeprowadzenie postępowań o udzielenie zamówienia. Pozwoli to maksymalnie wyeliminować błędy o charakterze formalnym, zapewni kompletność wymaganych danych oraz zgodność z aktualnym stanem prawnym, a metadane będą przechowywane w repozytorium. Ponadto przygotowanie ustandaryzowanych formularzy gwarantuje ich walidację na etapie wprowadzania danych przez zamawiających jak i wykonawców.

4.1.2 Cel szczegółowy - Możliwość efektywnego monitorowania, analiz i kontroli procesu postępowania o udzielenie zamówienia publicznego

Brak spójności i kompletnego źródła danych oraz narzędzi do ich analizy powoduje utrudnienia w wykonywaniu zadań związanych z monitorowaniem i kontrolą systemu zamówień publicznych. Dane zbiorcze dostępne są z dużym opóźnieniem ze względu na przyjęty model sprawozdawczości (dane dotyczące całego roku są przesyłane przez Zamawiających do 1 marca następnego roku). Prezes UZP zobowiązany zapisami w ustawie Pzp do opracowywania i przedstawiania Radzie Ministrów oraz Komisji Europejskiej licznych sprawozdań, nie dysponuje obecnie sprawnymi i efektywnymi narzędziami do raportowania analiz. Powyższe utrudnienia dotyczą też Zamawiających, którzy wobec licznych danych wprowadzanych do nieustandaryzowanych formularzy/dokumentów poszczególnych postępowań, nie mają możliwości ich agregowania i analizowania (w tym porównywania). Również obywatele czy wykonawcy/przedsiębiorcy zainteresowani informacjami z rynku zamówień publicznych napotykają na powyższe utrudnienia.

Centralne Repozytorium Danych budowane w ramach Projektu e-Zamówienia pozwoli na natychmiastowy dostęp do kompletnych ustrukturyzowanych danych dotyczących rynku zamówień publicznych, w tym wszystkich ogłoszeń z BZP i TED, Protokołów otwarcia ofert, Planów zamówień publicznych, Protokołów z postępowania. Dzięki temu rozwiązaniu każdy z interesariuszy zaspokoi swoje potrzeby: Prezes KIO oraz organy kontrolne w łatwy i szybki sposób otrzymają pełne dane do monitorowania, analiz i kontroli zamówień publicznych, dostęp do danych będzie możliwy „na życzenie", Wykonawcy/przedsiębiorcy będą mieć łatwy i szybki dostęp do pełnych informacji o rynku zamówień publicznych.

4.1.3 Cel szczegółowy - Optymalizacja kosztów i czasu trwania postępowania o udzielenie zamówienia publicznego

Dużym problemem Zamawiających obecnie jest wielokrotne wpisywanie tych samych danych (np. danych zamawiającego lub danych dotyczących danego postępowania np. przedmiot zamówienia, danych zamawiającego, termin i miejsce składania i otwarcia ofert oraz inne ustrukturyzowane dane) w kilku formularzach/dokumentach (ogłoszenie o zamówieniu, SIWZ czy innych w zależności od rodzaju informacji i przebiegu procedury). Dlatego, też skrócenie czasu potrzebnego na przygotowanie ogłoszeń jest istotnym czynnikiem wypływającym na koszt funkcjonowania Zamawiajacego. W tym miejsu należy podkreślić fakt, że wśród Zamwiajacych są nie tylko urzędy administracji publicznej, ale także w dużym stopniu, spółki działające w oparciu o prawo handlowe (wartość udzielonych zamowień sektorowych to ponad 21% ogólnej wartości rynku).

W przypadku MŚP pracochłonne przygotowywanie ofert wraz z wszystkimi wymaganymi załącznikami, robione jest kosztem czasu przeznaczonego na zasadniczą działalność firmy, ograniczając jej rozwój i uniemożliwiając udział w większej ilości postępowań. Powszechna praktyka przygotowywania ofert w formie papierowej powoduje zwiększenie kosztów po stronie Wykonawców (koszt papieru, materiałów eksploatacyjnych jak również koszt dostarczenia oferty do Zamawiającego - kurier, delegacja), a po stronie Zamawiającego pracochłonność w ocenie i porównaniu otrzymanych dokumentów.

Realizacja Projektu znacznie zoptymalizuje koszty i czas trwania postępowania. Zamawiający, dzięki raz wprowadzonym danym i przechowywaniu ich w Centralnym Repozytorium Danych, będzie mógł ponownie je wykorzystywać do opracowania różnych dokumentów/formularzy (ogłoszenie o zamówieniu, ogłoszenie o udzieleniu zamówienia, ogłoszenie o zmianie ogłoszenia, i inne ogłoszenia, TED, SIWZ, protokół z postępowania, protokół otwarcia ofert, itp.). Poprzez ustandaryzowanie usług oraz wymiany danych, API wraz CRD zostanie skrócony czas tworzenia wszystkich dokumentów zamówienia, w tym w szczególności elementów SIWZ (będących powieleniem lub rozwinięciem informacji z ogłoszenia o zamówieniu), kolejnych ogłoszeń (w tym o zmianie, czy o udzieleniu zamówienia), ustrukturyzowanego protokołu postępowania (w olbrzymiej mierze tworzony będzie automatycznie z wykorzystaniem wprowadzonych wcześniej danych). W dalszych etapach dane te będzie można wykorzystać do tworzenia analiz, raportów, kontroli i sprawozdań przez Zamawiających, Wykonawców, Prezesa UZP, czy organy kontroli.

W wyniku realizacji Projektu nastapi centralizacja ustrukturyzowanych informacji o zamówieniach publicznych w jednym Centralnym Repozytorium Danych. Wykonawcy zainteresowaniu udziałem w postępowaniach otrzymają jedno miejsce pozyskiwania informacji począwszy od ogłoszeń o zamówieniach a kończąc na wynikach przetargów. Możliwa będzie także subskrybcja innych informacji wg określonych kryteriów (m.in. rodzaj zamówień, kategorii, określonych CPV, słów kluczowych, obszaru geograficznego, itp.) dla zainteresowanych tematyką zamówień publicznych. Dostęp do części tych danych obecnie generuje koszty z racji ich rozproszenia, braku do bezpośrednego dostępu do kompletu danych.

4.1.4 Wsparcie interesariuszy w wypełnieniu ustawowego obowiązku elektronizacji postępowań o udzielenie zamówienia publicznego

Zgodnie z art. 22 ust. 1 Dyrektywy Parlamentu Europejskiego i Rady 014/24/UE z dnia 26 lutego 2014r. w sprawie zamówień publicznych, uchylającej dyrektywę 2004/18/WE, „Państwa członkowskie zapewniają, że wszelka komunikacja i wymiana informacji odbywająca się na mocy niniejszej dyrektywy, w szczególności elektroniczne składania ofert, przeprowadzane są z wykorzystaniem elektronicznych środków komunikacji zgodnie z wymogami niniejszego artykułu". Natomiast zgodnie z art. 10a ust. 1 ustawy Pzp termin, od którego obowiązywać będzie składanie ofert i wniosków oraz wszelkiej korespondencji miedzy Zamawiającym a Wykonawcą przy „użyciu środków komunikacji elektronicznej", upływa 18.10.2018 r.

Zgodnie z założeniami Projektu Platforma, wspierając uczestników procesu zamówień publicznych, będzie przyjmować i zabezpieczać integralność ofert i wniosków do terminu ich otwarcia.

Projekt e-Zamówienia wpisuje się w jeden z 11-tu priorytetowych obszarów e-usług wyszczególnionych w Programie Operacyjnym Polska Cyfrowa na lata 2014-2020: zamówienia publiczne. Wypełnia zalecenia Rady w sprawie krajowego programu reform (CSR 2014 r.) Projekt będzie miał oddziaływanie ogólnokrajowe, będzie interoperacyjny z innymi systemami. Przedsięwzięcie bezpośrednio wspiera Oś priorytetową II Programu Operacyjnego Polska Cyfrowa 2014-2020 pn. „E-Administracja i otwarty rząd".

4.2 Spójność celów Projektu z celami organizacji i dokumentów strategicznych

4.2.1 Zgodność z dokumentami strategicznymi

Cele Projektu e-Zamówienia wpisują się w cele określone w strategii Sprawne Państwo 2020. Projekt przyczynia się do realizacji następujących celów:

CEL OTWARTY RZĄD

1.1 Otwarcie zasobów sektora publicznego poprzez udostępnienie ustrukturyzowanych danych z obszaru zamówień publicznych wraz z API oraz narzędzi (BI) umożliwiających analizę zintegrowanych danych

CEL ZWIĘKSZENIE SPRAWNOŚCI INSTYTUCJONALNEJ PAŃSTWA

2.3. Efektywne i funkcjonalne urzędy administracji publicznej poprzez udostępnienie jednolitego systemu w chmurze, tworzonego we współpracy z interesariuszami procesu udzielania zamówień publicznych

CEL DOBRE PRAWO

4.1. Optymalizacja procedur administracyjnych - poprzez optymalizację procesów w obszarze zamówień publicznych

4.2. Procedury nastawione na realizację celów - poprzez udostępnienie aplikacji biznesowych i standardów zapewniających efektywną elektronizację procesu zamówień publicznych w fazie preaward.

CEL EFEKTYWNE ŚWIADCZENIE USŁUG PUBLICZNYCH

5.5. Standaryzacja i zarządzanie usługami publicznymi ze szczególnym uwzględnieniem technologii cyfrowych - poprzez udostępnienie jednolitych usług w chmurze oraz stworzenie standardów dokumentów używanych w procesie udzielania zamówienia publicznego, a tym samym zwiększającą efektywność działania administracji.

Zakres Projektu obejmuje wypracowanie wzorów dokumentów elektronicznych oraz formularzy elektronicznych w obszarze BZP i innych usług oferowanych bezpośrednio użytkownikom Platformy e-Zamówienia. (w rozumieniu ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne).

W przypadku usług oferowanych przez Portale e-usług w zakresie Projektu jest wypracowanie standardów danych dla poszczególnych dokumentów, formularzy (np. plan zamówień publicznych, zaproszenie do składania ofert). Standaryzacja danych oznacza zdefiniowanie zakresu i formatu danych, które z Portali e-usług będą przesyłane na Platformę e-Zamówienia do CRD lub na odwrót. Standaryzacja obejmie też metadane z procesu udzielania zamówienia publicznego.

Przedsięwzięcie wspiera zarówno cel strategiczny jak i cel operacyjny Programu Zintegrowanej Informatyzacji Państwa. Usługi tworzone i standaryzowane w ramach Projektu są zgodne z Katalogiem rekomendowanych usług określonych w załączniku nr 2 do PZIP, pkt 6 ppkt Zamówienia publiczne.

Cel Strategiczny „zwiększenie liczby wysokiej jakości publicznych e-usług w Polsce, mierzony odsetkiem korzystających z nich obywateli i przedsiębiorców, sytuującym Polskę w 2020 roku w pierwszej siódemce krajów Unii Europejskiej.";

Cel Operacyjny „zapewnienie interoperacyjności istniejących oraz nowych systemów teleinformatycznych administracji publicznej, przy równoczesnym eliminowaniu powielającej się funkcjonalności, co doprowadzi do stworzenia spójnego, logicznego i sprawnego systemu informacyjnego państwa, dostarczającego na poziomie wewnątrzkrajowym i europejskim usługi kluczowe dla obywateli i przedsiębiorców, w sposób efektywny kosztowo i jakościowo."

Cele Projektu, wpisują się również Program Zintegrowanej Informatyzacji Państwa. Zgodnie z rekomandacjami do katalogu podstawowych e-usług, należą usługi związane z realizacją Zamówień publicznych. Wśród tych usług zostały wskazane:

1.    Usługa zamieszczania ogłoszeń w odpowiednich publikatorach, tj. Biuletynie Zamówień Publicznych, Dzienniku Urzędowym Unii Europejskiej oraz stronie internetowej zamawiającego, np. w Biuletynie Informacji Publicznej;

2.    Generowanie przez jednostki zamawiające dokumentacji postępowań przekazywanej wykonawcom i jej udostępnienie drogą elektroniczną;

3.    Możliwość składania przez wykonawców wszystkich niezbędnych dokumentów wymaganych przez zamawiającego, tj. np. wniosków o dopuszczenie do udziału w postępowaniu wraz ze wszystkimi dokumentami elektronicznymi potwierdzającymi spełnienie warunków udziału w postępowaniu;

4.    Złożenie przez wykonawców ofert wraz z dokumentami elektronicznymi potwierdzającymi spełnianie przez oferowane dostawy, usługi bądź roboty budowlane postawionych przez zamawiającego warunków; miałyby być one zabezpieczone przed nieuprawnionym ich otwarciem przed upływem wyznaczonego terminu składania ofert;

5.    Komunikacja między zamawiającym a wykonawcami; dzięki zapewnieniu weryfikacji tożsamości nadawcy oraz pochodzenia od niego przesyłanych treści zapewnione byłoby bezpieczeństwo tychże komunikacji;

6.    Automatyczna ocena ofert oraz wniosków o dopuszczenie do udziału w postępowaniu, w przypadku gdy możliwe będzie skwantyfikowanie wybranych warunków udziału w postępowaniu oraz kryteriów oceny ofert;

7.    W ramach przejrzystości procedur przetargowych przewidziano możliwość automatycznego i bieżącego dokumentowania czynności podjętych przez zamawiających i wykonawców w trakcie postępowania o udzielenie zamówienia publicznego, określonych w protokole postępowania;

8. Usługi dostępu do danych z ogłoszeń - świadczone w szczególności na rzecz wykonawców analizujących możliwość udziału w postępowaniach o udzielenie zamówienia publicznego, wprowadzenia na rynek zamówień publicznych oferowanych przez siebie produktów lub usług, a także podmiotów pozyskujących i przetwarzających dane dotyczące systemu zamówień publicznych;

9. Usługi dostępu do danych z postępowań - świadczonej na rzecz podmiotów zewnętrznych, w tym organów administracji publicznej realizujących funkcje nadzorcze w stosunku do zamawiających.

4.2.2 Właściwość merytoryczna

Ministerstwo Cyfryzacji

Zgodnie z ustawą z dnia 4 września 1997 r. o działach administracji rządowej, Art 12a (dział Informatyzacja) do zadań ministra właściwego ds. cyfryzacji należą m.in.:

1)    informatyzacja administracji publicznej oraz podmiotów wykonujących zadania publiczne;

2)    systemy i sieci teleinformatycznych administracji publicznej;

3)    wspieranie inwestycji w dziedzinie informatyzacji;

10) bezpieczeństwo cyberprzestrzeni.

Na tej podstawie stwierdzić można właściwość merytoryczną MC do udziału w projekcie e-zamówienia.

Urzad Zamówień Publicznych

Właściwość merytoryczna Prezesa UZP w obszarze zamówień publicznych wynika z ustawy Prawo zamówień publicznych. Zakres Projektu wpisuje się w zadania określone w artykule 154 Pzp. Realizacja Projektu wynika wprost z przyjętego przez Prezesa UZP Planu Informatyzacji Zamówień Publicznych w Polsce przyjętego przez KRMC 19 grudnia 2012. Plan określa ramy informatyzacji zamówień publicznych i wskazuje kluczowe założenia Projektu e-Zamówienia.

4.2.3 Zgodność z celami POPC - Działanie 2.1

Projekt e-Zamówienia wpisuje się w jeden z 11-tu priorytetowych obszarów e-usług wyszczególnionych w Programie Operacyjnym Polska Cyfrowa na lata 2014-2020: zamówienia publiczne, w szczególności zapis „rozwiązania dotyczące skutecznego stosowania unijnych przepisów w zakresie zamówień publicznych poprzez stosowne mechanizmy rozwiązania gwarantujące przejrzystość postępowań o udzielanie zamówienia".

Zgodnie z powyższym Projekt przewiduje:

• budowę Platformy e-Zamówienia umożliwiającej wraz z usługami zewnętrznymi przeprowadzanie za pomocą środków elektronicznych całego procesu postępowania o udzielenie zamówienia,

•    wsparcie (poprzez standaryzację) elektronizacji procesu postępowania o udzielenie zamówienia w trybach inicjowanych przez publikację ogłoszenia oraz procesu dynamicznego systemu zakupów i aukcji elektronicznych,

•    integrację z systemami zewnętrznymi, które pozwalać mogą/będą na:

o automatyczne, bieżące dokumentowanie czynności podjętych w trakcie postępowania,

o automatyczne generowanie dokumentacji postępowania,

o automatyczną ocenę ofert oraz wniosków o dopuszczenie do udziału w postępowaniu, w przypadku gdy możliwe będzie skwantyfikowanie wybranych warunków udziału w postępowaniu oraz kryteriów oceny ofert dając użytkownikom Platformy możliwości obsługi w pełni zinformatyzowanego procesu udzielenia zamówienia publicznego.

Projekt wypełnia zalecenia Rady ws. krajowego programu reform (CSR 2014 r.) Będzie interoperacyjny z innymi systemami. Przedsięwzięcie bezpośrednio wspiera Oś priorytetową II Programu Operacyjnego Polska Cyfrowa 2014-2020 pn. „E-Administracja i otwarty rząd". Dodatkowo nastąpi poprawa warunków otoczenia biznesu poprzez: redukcję kosztów rozpoczynania i prowadzenia działalności gospodarczej (w tym pojedynczy punkt kontaktowy podatki i cła, ubieganie się o zamówienia publiczne, e-fakturowanie).

Projekt będzie miał oddziaływanie ogólnokrajowe, z udostępnianych elektronicznie usług i informacji w zakresie zamówień publicznych będą korzystać wykonawcy/przedsiębiorcy czy zamawiający ze wszystkich regionów Polski. Będzie również interoperacyjny z innymi systemami, gdyż planowane rozwiązanie pozwoli zamawiającym i wykonawcom/przedsiębiorcom realizować proces udzielania zamówień publicznych na dowolnej platformie własnej lub udostępnionej przez inny podmiot, jednakże poprzez koncepcję Centralnego Repozytorium Danych zapewniony zostanie dostęp do niezbędnych danych i dokumentów niezależnie od miejsca rejestracji interesariusza procesu.

4.3 Korzyści społeczne

Stworzenie w ramach projektu systemu zamówień publicznych na bazie Platformy e-Zamówienia, zgodnie z założonymi celami, pozwoli zwiększyć jakość dokumentów/formularzy, umożliwi efektywne monitorowanie, analizę i kontrolę procesu postępowań o udzielenie zamówienia publicznego, optymalizacje koszty i czas trwania postępowania o udzielenie zamówienia publicznego oraz wesprze interesariuszyw wypełnieniu ustawowego obowiązku elektronizacji postępowań o udzielenie zamówienia publicznego.

W wyniku realizacji Projektu nastapi centralizacja informacji o zamówieniach publicznych. W Centralnym Repozytorium Danych będą przechowywane ustrukturyzowane dane , które są obecnie rozproszone i nieustandaryzowane. Wykonawcy zainteresowaniu bezpośrednim udziałem w postępowaniach przetargowych otrzymają jedno miejsce pozyskiwania informacji począwszy od ogłoszeniach o zamówieniach a kończąc na, wynikach postępowań. Dostępna będzie także subskrybcja informacji z ogłoszeń i innych informacji wg określonych kryteriów (m.in. rodzaj zamówień, kategorii, określonych CPV, słów kluczowych, obszaru geograficznego, itp.) dla wszystkich zainteresowanych tematyką zamówień publicznych, nie tylko potencjalnych Wykonawców. Obecnie takie informacje są rozproszone w różnych miejscach. Dostęp do części tych danych obecnie generuje koszty z racji ich rozproszenia, braku do bezpośrednego dostępu do kompletu danych.

Wartość

5 Odbiorcy Projektu

5.1 Charakterystyka użytkowników

Interesariuszami Projektu - dzięki ustandaryzowaniu usług oraz lepszej jakości i łatwości dostępu danych w zakresie zamówień publicznych - będą w szczególności: zamawiający, wykonawcy, organy kontroli.

Poniżej zaprezentowano główne grupy interesariuszy Projektu wraz z określeniem wielkości wpływu na Projekt i nastawieniem do jego realizacji:

5.2 Identyfikacja problemu i potrzeb

Kluczowy problem w obszarze zamówień publicznych w Polsce to nieefektywny i niedostosowany do potrzeb interesariuszy proces udzielania zamówienia publicznego. Do zidentyfikowanych problemów pośrednich należą:

•    Utrudniony dostęp do informacji o postępowaniach o udzielenie zamówienia,

•    Nieustandaryzowany format udostępnianych informacji,

•    Pracochłonność przygotowywania sprawozdawczości (zamawiający, organy monitorująco-kontrolne),

•    Wysoki koszt i pracochłonność przygotowania dokumentów zamówienia, ofert i wniosków (zamawiający, wykonawcy).

Elektronizacja zamówień publicznych może stać się istotnym instrumentem uzyskiwania w postępowaniach takich efektów jak: ograniczenie barier w dostępie do zamówień, obniżenie kosztów postępowań, podniesienie poziomu przejrzystości procedur, a także otwarcie zamówień na jak najszerszy konkurencyjny rynek firm. W ten sposób zamawiający ma również szanse uzyskać większą efektywność wydatkowania publicznych pieniędzy, w tym unijnych środków.

Utrudniony dostęp do informacji o postępowaniach o udzielenie zamówienia

Przyczynami tego negatywnego zjawiska są nieustandaryzowane miejsce i format udostępnianych informacji.

Ogłoszenia o zamówieniu obecnie publikowane są przez UZP w Biuletynie Zamówień Publicznych. Jednak w ograniczonym zakresie udostępniona jest możliwość wyszukiwania ogłoszeń wg dostępnych kryteriów oraz ich subskrypcja przez wykonawców.

Zgodnie z badaniami opublikowanymi w dokumencie „Nowe podejście do zamówień publicznych -raport 2012" przygotowanym przez PARP, podmioty MSP (wykonawcy) obecne na rynku zamówień publicznych najczęściej pozyskują informacje o zamówieniach z internetowych bezpłatnych informatorów, bezpośrednio od przedstawicieli zamawiającego lub z jego stron internetowych. Jednak wg badań, żaden z badanych nie wskazał jako źródła informacji Biuletynu Zamówień Publicznych.

W kolejnych etapach postepowania, jawność informacji związanych z postępowaniem o udzielenie zamówienia publicznego regulowana jest art. 96 Pzp. Zgodnie z powyższą regulacją, w trakcie prowadzenia postępowania o udzielenie zamówienia, zamawiający sporządza pisemny protokół z postępowania o udzielenie zamówienia. Oferty, opinie biegłych, oświadczenia, informacja z zebrania, zawiadomienia, wnioski, inne dokumenty i informacje składane przez zamawiającego i wykonawców oraz umowa w sprawie zamówienia publicznego stanowią załączniki do protokołu.

Obecnie w większości wypadków Zamawiający udostępnia powyższe informacje w formie papierowej w wyznaczonym przez niego terminie. Opóźniony dostęp do informacji uniemożliwia podjęcie optymalnych decyzji w procesie zamówień publicznych.

Nieustandaryzowany format udostępnianych informacji

Brak spójnego i kompletnego źródła danych oraz narzędzi do ich analizy skutkuje utrudnieniami w wykonywaniu zadań związanych z monitorowaniem i kontrolą systemu zamówień publicznych (rola Prezesa UZP i organów kontrolnych). Dane zbiorcze dostępne są z dużym opóźnieniem ze względu na przyjęty model sprawozdawczości (dane dotyczące całego roku przesyłane w terminie do końca I-ego kwartału roku następnego). Prezes UZP zobowiązany ustawą Pzp do opracowywania i przedstawiania Radzie Ministrów, Komisji Europejskiej szeregu sprawozdań nie dysponuje sprawnymi i efektywnymi narzędziami do raportowania analiz. Powyższe utrudnienia dotyczą też firm analitycznych oraz obywateli zainteresowanych informacjami z rynku zamówień, o czym świadczą liczne pytania kierowane do Prezesa UZP.

Pracochłonność przygotowywania sprawozdawczości (zamawiający, organy monitorująco-kontrolne)

Wymagane w sprawozdawczości informacje są rozproszone. Wobec nieporównywalności danych wprowadzanych do nieustandaryzowanych dokumentów poszczególnych postępowań nie jest możliwe agregowanie ich i efektywne analizowanie przez poszczególnych zamawiających. Dane przechowywane są w różnych dokumentach, w różnych formatach. Całość procesu przygotowywania wymaganych sprawozdań w konsekwencji jest bardzo pracochłonna. Mimo olbrzymich nakładów pracy przekazywane informacje są niepełne i nie spełniają potrzeb interesariuszy.

Wysoki koszt i pracochłonność przygotowania dokumentów zamówienia, ofert i wniosków (zamawiający, wykonawcy).

Zamawiający zobowiązani do stosowania przepisów Pzp tworzą szablony i wzory wielu dokumentów (m.in. wzory oświadczeń, informacje o wyborze oferty itp.) we własnym zakresie. Tak przygotowywane dokumenty są często źródłem wielu niejasności i błędów. Ich wyjaśnianie wymaga dużo czasu i wydłuża procedurę. Trudności te na początku procesu dotykają zamawiających przygotowujących dokumenty zamówienia, a w dalszych etapach wykonawców. Ze względu na fakt, iż istniejące rozwiązania nie zapewniają re-używalności danych, interesariusze zmuszeni są do kilkukrotnego wprowadzania tych samych informacji w różnych dokumentach (np. ogłoszenia i SIWZ), a tym samym wzrasta ryzyko błędów i niespójności. W przypadku MŚP pracochłonne przygotowywanie ofert lub wniosków wraz ze wszystkimi załącznikami, dokonywane jest kosztem czasu przeznaczonego na prowadzenie podstawowej działalności (biznesu), ograniczając rozwój firm, jak również uniemożliwiając uczestnictwo w większej liczbie postępowań. Powszechna praktyka przygotowywania ofert w formie papierowej powoduje znaczną pracochłonność po stronie zamawiających w ocenie i porównaniu otrzymanych dokumentów. Efektem wyżej opisanych uwarunkowań jest mała liczba ofert składanych przez Wykonawców i w konsekwencji ich niska konkurencyjność.

Proces doskonalenia zamówień publicznych wychodzi naprzeciw zaspokojeniu kluczowych problemów w tym zakresie. Istotne zmiany w tym zakresie wynikają z Dyrektywy Parlamentu Europejskiego i Rady 014/24/UE z dnia 26 lutego 2014r oraz jej krajowej implementacji.

Ustawa Pzp obliguje do stosowania procedur zamówień publicznych około 35 tys. zamawiających tj. urzędów i instytucji szeroko rozumianego sektora finansów publicznych, z czego około 15 tys. zamawiających rocznie udziela zamówień poprzedzonych ogłoszeniem o zamówieniu (postępowania powyżej progu krajowego 30 000 € i wyłączone z stosowania Pzp).

Potencjalnymi zainteresowanymi udziałem w procedurach Pzp mogą być wszystkie krajowe (ok. 2 mln wg CEIDG, 300 000 spółek handlowych wg GUS) i zagraniczne podmioty gospodarcze.

5.3 Analiza Opcji - Opis możliwych rozwiązań problemu i zaspokojenia potrzeb

5.3.1 Liczba wariantów rozwiązań potrzeb

5.3.2 Opis wariantów rozwiązania

Poniżej przedstawiono opisy 3 wariantów, które na etapie prac analitycznych nad tworzeniem fiszki oraz wniosku o dofinansowanie wraz z załącznikami były analizowane. Warianty te wychodzą naprzeciw zdiagnozowanym potrzebom użytkowników oraz wynikają z krajowych i UE wymogów prawnych . Po zdefiniowaniu wariantów zostały one poddane priorytetyzacji oraz ocenie, który z nich jest wariantem optymalnym biorąc pod uwagę: potrzeby, koszty, czas realizacji oraz planowane funkcjonalności budowanego rozwiązania informatycznego. Szczegółowe warunki wyboru rozwiązania optymalnego zostały przedstawione w dalszej części niniejszego dokumentu.

5.3.2.1    Wariant 0 - Zaniechania

Nie podjęte zostaną żadne działania.

Rozwiązanie to nie zapewnia spójności systemu zamówień publicznych w Polsce, nie wspiera interesariuszy, w szczególności zamawiających, w realizacji ustawowych obowiązków związanych z elektronizacją procesu zamówień. Uniemożliwia pełne, prawidłowe, realizowane na bieżąco monitorowania funkcjonowania systemu zamówień przez Prezesa UZP oraz terminowe tworzenie wymaganej sprawozdawczości. Z tytułu utrzymania obecnych usług UZP ponosi rocznie koszty w wysokości 272 tys. zł.

Od 18.10.2018 r. obowiązkowa będzie elektronizacja zamówienień publicznych dla zamówień o wartości powyżej 30 000 €. Wariant 0 nie pozwala na jej realizację. W przypadku nie zrealizowania obowiązku elektronizacji budżet Państwa narażony będzie na ponoszenie kar finansowych nakładanych przez Komisję Europejską.

5.3.2.2    Wariant 1 - Budowa Platformy e-Zamówienia udostępniającą komplet e-usług

Wariant przewiduje budowę centralnej Platformy udostępnionej wszystkim Zamawiającym i umożliwiającej przeprowadzenie za pomocą środków elektronicznych całości postępowania o udzielenie zamówienia publicznego od przygotowania i publikacji ogłoszenia o zamówieniu, poprzez udostępnienie specyfikacji istotnych warunków zamówienia, zmianę dokumentów zamówienia, składania pytań i publikacji odpowiedzi, składanie i ocenę ofert, wniosków o dopuszczenie do udziału w postępowaniu, do ogłoszenia o udzieleniu zamówienia publicznego lub informacji o unieważnieniu postępowania.

Zakres prac przewidziany w ramach tego wariantu w znaczący sposób przekracza obligatoryjne działania w obszarze elektronizacji określone w Pzp i Dyrektywie (w szczególności komunikacja elektroniczna oraz proces składania ofert i wniosków). Obejmuje elektronizację wewnętrznego procesu (workflow) zamawiajacego i wykonawcy (przygotowanie i składanie ofert).

Budowa i udostępnienie wszystkich e-usług na Platformie centralizuje system zamówień publicznych w Polsce, nie uwzględnia istniejących rozwiązań wspierających proces zamówień. I ogranicza konkurencyjność. Z racji wielkości przedsięwzięcia wybór tego wariantu nie gwarantuje wdrożenia kompletu funkcjonalności w terminie określonym w art. 18 ustawy z dnia 22 czerwca 2016 r. o zmianie ustawy - Prawo zamówień publicznych oraz niektórych innych ustaw (Dz. U. poz. 1020, z późn. zm.)

5.3.2.3 Wariant 2 - Rozwiązanie hybrydowe

Wariant ten obejmuje budowę Platformy e-Zamówienia z Centralnym Repozytorium Danych oferującej wybrane usługi (m.in. BZP, aukcje, licytacje) dla zamówień publicznych powyżej 30 000 euro oraz automatyzuje sprawozdawczość w tym dotyczącą zamówień poniżej 30 000 euro. Zapewni integralność procesu postępowania o udzielenie zamówień publicznych w Polsce poprzez wystandaryzowanie usług pozwalających na jego prawidłowe przeprowadzenie oraz dokumentów i danych zbieranych i udostępnianych w Repozytorium. Planowana architektura rozwiązania (oparta o model SOA, udostępniająca API zewnętrznym podmiotom) umożliwi integrację Platformy z istniejącymi i nowymi systemami oferującymi e-usługi w obszarze zamówień publicznych.

Zamawiający i wykonawcy realizować będą mogli proces zamówień publicznych na dowolnej platformie własnej lub komercyjnej jednakże poprzez koncepcję Centralnego Repozytorium Danych zapewniony zostanie dostęp do niezbędnych danych i dokumentów niezależnie od miejsca rejestracji interesariusza procesu. Planowany moduł Monitorowania i Analiz pozwoli na bieżące śledzenie procesu zarówno przez Prezesa UZP (obowiązek ustawowy), jak i przez Zamawiających i Wykonawców. Moduł BI pozwoli na przekrojowe analizy danych zagregowanych.

Wariant stanowiący rozsądny kompromis pomiędzy wymaganiami ustawowymi w zakresie elektronizacji elementów procesu zamówień publicznych jak i potrzebami interesariuszy.

Jest możliwy do realizacji w perspektywie czasowej do 18.10.2018 r.

Jednocześnie nie zamyka drogi do elektronizacji innych czynności procesu zgodnie z potrzebami interesariuszy.

5.3.3 Zaangażowanie użytkowników w pracach nad rozwiązaniami

Beneficjent zidentyfikował grupy docelowe budowanego rozwiązania, założył udział użytkowników końcowych w realizacji Projektu już na etapie zbierania wymagań funkcjonalnych oraz pozafunkcjonalnych, tak aby na wczesnym etapie projektu zidentyfikować kluczowe potrzeby, które zostaną przełożone na wymagania definiowane w SIWZ. Następnie użytkownicy będą angażowani w trakcie testów produktów dostarczanych w ramach realizacji projektu (szczegółowy opis tego zagadnienia został przedstawiony w rozdziale 6.4 Weryfikacja produktów przez użytkowników).

W przywołanym rozdziale przedstawione zostały działania mające na celu optymalizację UX i zadania (w tym prototypowanie, testy A/B czy udział użytkowników końcowych na każdym etapie definiowania wymagań i założeń a następnie ich testowania) związane z zapewnieniem ergonomii system w trakcie realizacji Projektu.

W poniższej tabeli przedstawiono udział Lidera oraz Partnera w tracie realizacji projektu z podziałem zadań pomiędzy poszczególne podmioty (tabela ma charakter podsumowania).

5.4 Wybrane rozwiązanie wraz z uzasadnieniem

Wybrany został wariant 2 (pkt 5.2.3.2), obejmujący budowę Platformy e-Zamówienia z Centralnym Repozytorium Danych oferującej wybrane usługi (m.in. BZP, aukcje, licytacje) dla zamówień publicznych powyżej 30 000 euro z możliwością integracji z istniejącymi systemami oferującymi e-usługi z obszaru zamówień publicznych.

Zapewnienie kompletności wymaganych danych pozwoli na maksymalne wyeliminowanie błędów o charakterze formalnym. Dzięki CRD zapewniona zostanie zgodność dokumentów z

aktualnym stanem prawnym, a raz wprowadzone dane będą mogły zostać ponownie wykorzystane w systemie bez potrzeby ich ponownego dostarczania (reużywalność danych ogranicza istotnie ryzyko błędów o charakterze omyłek pisarskich czy braków). To pozwoli na skrócenie czasu przygotowania pojedynczego ogłoszenia do BZP i TED oraz innych dokumentów zamówienia. Zautomatyzowanie sprawozdawczości, dzięki przekazywaniu z wykorzystaniem API ustandaryzowanych danych na bieżąco do CRD, zmniejszy obciążenia administracyjne zamawiających, a wszystkie podmioty biorące udział w rynku zamówień publicznych otrzymają natychmiastowy dostęp do kompletnych danych dotyczących rynku zamówień publicznych. Ważnym aspektem jest ograniczenie kosztów zabezpieczenia ofert i wniosków do terminu ich otwarcia w wyniku zbudowania nowoczesnego i bezpiecznego rozwiązania dla wszystkich zamawiających, którzy w innym przypadku musieliby wdrożyć własne rozwiązania na własny koszt. Ten element Platformy jest jednym z najbardziej kosztotwórczych elementów. Dlatego też, przyjęty wariant 2 zapobiega zwielokrotnieniu wydatków w skali kraju i daje gwarancję uzyskania jednolitego i wysokiego poziomu bezpieczeństwa systemu, co jest bardzo istotne zwłaszcza w przypadku małych i średnich zamawiających. Wariant 2 adresuje wszystkie obowiązki interesariuszy w zakresie elektronizacji procesu zamówień publicznych wynikające z Pzp i Dyrektywy, a jednocześnie jego zakres, w odróżnieniu od wariantu 1-go, daje gwarancję realizacji kluczowych modułów do ustawowego terminu tj. 18 października 2018 roku.

Architektura rozwiązania w wybranym wariancie umożliwi rozwój e-usług w obszarze zamówień publicznych zarówno na Platformie e-Zamówienia, jak i na zewnętrznych Portalach e-Usług (zamawiających) zgodnie z powstającymi potrzebami.

5.4.1 Charakterystyka wariantów

Dla przedstawionych możliwych wariantów zostały rozpoznane zalety i wady dla Wariantu 1 (Budowa Platformy e-Zamówienia udostępniającą komplet e-usług) oraz Wariantu 2 (hybrydowy) podzielone na grupy kryteriów. W analizie wariantów nie uwzględniono Wariantu 0 (zaniechania) ze względu na znacząco odbiegającego od planowanego zakresu Projektu i brak osiągnięcia znaczących korzyści w zamówień publicznych zarówno dla Zamawiających jak i Wykonawców oraz innych zainteresowanych nie biorących bezpośredniego udziału w procesie zamówień publicznych.

W celu wybrania najkorzystniejszego rozwiązania wykorzystano metodę analizy wielokryterialnej wariantów bazującą na jakościowej metodzie wyboru wariantów inwestycyjnych, tj. porównaniu ich wad i zalet.

5.4.2 Złożoność techniczna systemu

5.4.3 Funkcjonalność systemu

5.4.4 Wykonalność organizacyjna

5.4.5 Zarządzanie powstałym systemem

5.4.6 Korzyści dla użytkowników końcowych

5.5 Analiza wariantów - porównania i oceny możliwych do zastosowania rozwiązań inwestycyjnych

5.5.1 Analiza wariantów (opcji)

Głównym celem analizy wariantów jest wskazanie rozwiązania, które pozwala na uzyskanie pożądanych korzyści użytkowych i społecznych. Analiza opcji polega na dokonaniu porównania i oceny możliwych do zastosowania rozwiązań inwestycyjnych zidentyfikowanych na etapie analizy wykonalności. Celem tej analizy jest wskazanie, które z ww. rozwiązań jest najkorzystniejsze (optymalne wg zdefiniowanych mierzalnych kryteriów).

5.5.2 Analiza wielokryterialna

Analizie wielokryterialnej poddano 2 Wariant inwestycyjne.

Dla każdego kryterium przypisano określone wagi. Jako podstawową wagę przyjęto wartość = 1 gdyż uznano iż posiadają podobne znaczenie dla Projektu.

Dla kryterium „Złożoność techniczna systemu" przypisano wagę o wartości = 2 ze względu na jej wpływ na wymagania techniczne realizacji i wynikająca z tego implikacje dla jego wykonania.

Kluczowym odbiorcą i użytkownikiem tworzonego projektu jest końcowy użytkownik jako odbiorca danych publicznych i jako wagę dla kryterium „Korzyści dla użytkowników końcowych" przyjęto wartość = 3.

Każde z kryterium może przyjmować wartości z przedziału 1 do 3, przy czym wartość = 1 oznacza wartość najsłabiej charakteryzującą określone kryterium a wartość najwyższą = 3 oznacza wartość najsilniej pozytywnie charakteryzującą określone kryterium.

Przy przypisywaniu wartości dla poszczególnych kryterium wzięte zostały zalety i wady tych kryteriów, które zawarte są rozdziale „Charakterystyka wariantów".

Analiza wielokryterialna

W analizie wielokryterialnej najwyższą ocenę na podstawie 5 różnych kryteriów uzyskał Wariant 2 hybrydowy.

5.5.3 Wybór rozwiązania

Z analizy merytorycznej oraz technicznej analizowanych wariantów wynika, iż najkorzystniejszym wariantem jest Wariant 2 hybrydowy.

W aspekcie zwiększenia ilościowego i jakościowego zamówień publicznych wybrany został Wariant 2 hybrydowy, który zapewni Zamawiającym jak i Wykonawcom usprawnienie i optymalizację procesu zamówień publicznych, jednocześnie będzie stanowił stosunkowo niewielkie obciążenie techniczne i umożliwi dalszy jego rozwój.

6 Produkty projektu

6.1    Funkcjonalności

6.1.1    Liczba funkcjonalności

6.1.2 Opis funkcjonalności

Platforma e-Zamówienia obejmować będzie następujące moduły

•    Centralne Repozytorium Danych

•    Biuletyn Zamówień Publicznych - zastępujący obecnie funkcjonujący

•    Moduł Monitorowania i Analiz wykorzystujący także narzędzia BI

•    Moduł Aukcji i Licytacji Elektronicznych - zastępujący obecnie funkcjonujący

•    eSender

•    Moduł Przyjmowania i Zabezpieczania ofert / wniosków do terminu otwarcia

1. Centralne Repozytorium Danych - przechowuje metadane dotyczące prowadzonych postępowań oraz ustrukturyzowane dane niezbędne do monitorowania i analiz rynku zamówień publicznych, w tym ze wszystkich ogłoszeń.

•    W repozytorium (CRD) przechowywane są dane ustandaryzowane (ustrukturyzowane)

•    Dane powinny być wprowadzane do systemu w oparciu o interaktywne formularze dostępne na Portalach e-usług lub Platformie e-Zamówienia (ogłoszenia, rejestracja interesariuszy, aukcje) poprzez API.

• Podstawową zasadą jest:

o jednokrotne wprowadzanie danych

o nie zwiększanie zakresu danych w stosunku do aktualnie określonego zakresu w Pzp

i.    które „udostępniane są na stronie internetowej" , „na stronie podmiotowej Biuletynu Informacji Publicznej"

ii.    o których „Zamawiający informuje niezwłocznie wszystkich wykonawców"

o zbieranie wszystkich danych na bieżąco, co umożliwi automatyzację sprawozdawczości, która obecnie realizowana jest w oparciu o roczne sprawozdania

•    Dane składowane w CRD mają umożliwić:

a.    Re-używalność danych przez Zamawiających i Wykonawców.

b.    Monitorowanie postępowań.

c.    Analizę rynku zamówień publicznych.

Ustrukturyzowane dane pozyskiwane do CRD z usług Platform e-Usług lub usług Platformy e-Zamówienia obejmą w szczególności: o Dane z rejestracji użytkowników.

o Dane z ogłoszeń (podlegających publikacji w BZP i TED) - w całości ustandaryzowane. o Dane z planów postępowań o udzielenie zamówień. (art. 13a Pzp) o Informacje o zamiarze przeprowadzenia dialogu technicznego. (art. 31b Pzp) o Dane z ustandaryzowanej części SIWZ o Dane z otwarcia ofert. (art. 86) o Dane dotyczące aukcji/licytacji

o Dane z wyboru najkorzystniejszej oferty (art. 92) lub unieważnieniu postępowania (art. 93 Pzp)

o Dane z informacji o zamiarze zawarcia umowy

o Dane z protokołów „małych" postepowań (do 30 tys. euro) w ustalonym zakresie zgodnym z zakresem danych obecnie pozyskiwanych w sprawozdaniach rocznych po zakończeniu danego postępowania.

o Metadane nt. pytań/odpowiedzi do SIWZ ( fakt zadania pytania, udzielenia odpowiedzi, daty, miejsce udostępnienia wyjaśnień (URL)). o Metadane z komunikacji pomiędzy interesariuszami procesu. ( w tym nt. składanych ofert/wniosków)

o Dane z umów (w zakresie uzgodnionym z MR - Platforma e-fakturowanie). o Dane dotyczące odwołań (wnoszenia, informowania stron, sprzeciwu, wyroku).

2.    Biuletyn Zamówień Publicznych - repozytorium wszystkich ogłoszeń dotyczących zamówień publicznych. Moduł ten obejmuje w szczególności następujące komponenty:

o zamieszczanie ogłoszeń - odpowiedzialny za przygotowanie i publikację ogłoszeń.

o zapytań - odpowiedzialny za przeszukiwanie bazy ogłoszeń; umożliwia wyszukiwanie za pomocą analizy tekstowej (tzw. full text search) i wyszukiwanie przez skojarzenia (tzw. wyszukiwanie semantyczne), umożliwia też wyszukiwanie zamówień po wybranych polach (tzw. advanced search)

o powiadomień i subskrypcji - wysyła powiadomienia o nowych ogłoszeniach w dziedzinach/kategoriach wybranych przez użytkownika.

BZP będzie pełnił funkcję centralnego publikatora ogłoszeń, tzn. będzie miejscem publikacji wszystkich ogłoszeń (powyżej i poniżej „progów unijnych") przy zachowaniu jednolitej struktury danych. Ułatwi tym samym dostęp do wszystkich ogłoszeń oraz umożliwi ich całościową analizę.

3.    Moduł Monitorowania i Analiz - umożliwia przegląd i wyszukiwanie informacji dotyczących konkretnych postępowań oraz udostępnia funkcjonalności pozwalające na przetwarzanie danych dotyczących wszystkich zamówień w celach statystycznych, analitycznych oraz kontrolnych.

Moduł będzie służył wszystkim interesariuszom zamówień publicznych. Oferować będzie usystematyzowane, „przyjazne" narzędzie wspomagające realizację zadań w zakresie monitorowania, kontroli i sprawozdawczości. Umożliwi nie tylko monitoring i kontrolę poszczególnych postępowań, ale także całego rynku zamówień publicznych w Polsce. W ramach Modułu udostępnione zostanie narzędzie Business Intelligence pozwalające na wygodne raportowanie, przetwarzanie i analizę zebranych danych zintegrowanych, przekrojowych. Obecnie bezpośredni dostęp do danych jest możliwy tylko dla osoby posiadającej specjalistyczną wiedzę informatyczną w zakresie eksploracji baz danych. Oferowane usługi byłyby udostępnione na zewnątrz i umożliwiałyby dokonywanie analiz potencjału rynku zamówień publicznych przez zamawiających i wykonawców.

Powstanie Modułu Monitorowania i Analiz byłoby zwieńczeniem działań związanych z powstaniem Platformy, jednakże jego koncepcja powinna powstać na pierwszym etapie budowy, ponieważ źródłowe dla Modułu MiA dane zostaną pozyskane w innych modułach.

4.    Moduł Aukcji i Licytacji Elektronicznych — umożliwiający przeprowadzanie aukcji i licytacji elektronicznej w ramach postępowań o udzielenie zamówienia publicznego.

Ze względu na przestarzałą technologię istniejącego rozwiązania oraz brak integracji z pozostałymi modułami planowanej Platformy, konieczna jest budowa nowego modułu aukcji i licytacji.

5.    Moduł eSender - Moduł realizujący usługę przesyłania ogłoszeń w wymaganym formacie do publikacji w TED i pobierania potwierdzeń publikacji ogłoszenia w Dzienniku Urzędowym UE.

Usługa eSendera klasy C (realizująca funkcjonalność skrzynki pocztowej przekazującej do TED ogłoszenia w odpowiednim formacie, nie wnikając w ich merytoryczną stronę) przywróci e-usługę kiedyś świadczoną przez UZP oraz zapewni jedno miejsce dostępowe do usług związanych z przygotowaniem i publikacją wszystkich ogłoszeń (komplet usług).

Integralną częścią eSendera jest usługa przygotowywania ogłoszeń w formacie wymaganym przez publikator TED (zgodnie z obowiązującymi formularzami). Czas procedowania o ustalenie statusu eSendera obejmuje okres około 6 miesięcy.

6.    Moduł Przyjmowania i Zabezpieczania ofert / wniosków wraz z HSM

Kluczowy, z punktu widzenia elektronizacji procesu, jest etap składania ofert. Konieczność elektronizacji tej usługi wprost została określona w art. 22 ust. 1 Dyrektywy Parlamentu Europejskiego i Rady 014/24/UE z dnia 26 lutego 2014 r. w sprawie zamówień publicznych, uchylającej dyrektywę 2004/18/WE „Państwa członkowskie zapewniają, że wszelka komunikacja i wymiana informacji odbywająca się na mocy niniejszej dyrektywy, w szczególności elektroniczne składanie ofert, przeprowadzane są z wykorzystaniem elektronicznych środków komunikacji zgodnie z wymogami niniejszego artykułu.".

Zgodnie z Art.10a. ust.1 ustawy Pzp od 18.10.2018 r. składanie ofert i wniosków oraz wszelka komunikacja między zamawiającym a wykonawcami obowiązkowo będzie odbywała się przy „użyciu środków komunikacji elektronicznej".

Oferty (lub wnioski o dopuszczenie do udziału w postępowaniu) składane będą na Platformie e-Zamówienia. W celu zagwarantowania integralności i nienaruszalności złożonych ofert do terminu ich otwarcia, wykonawcy będą zobowiązani do ich szyfrowania z wykorzystaniem dwóch par kluczy szyfrujących: zamawiających i wygenerowanych na Platformie e-Zamówienia. Wraz z upływem ww. terminu, zaszyfrowane oferty z kluczem prywatnym wygenerowanym na Platformie będą przekazywane Zamawiającym. Od tego momentu odpowiedzialność za np. zawartość oferty, zachowanie tajemnicy przedsiębiorstwa, ochronę danych osobowych spoczywać będzie na zamawiających. Za generowanie kluczy, ich udostepnianie    oraz

oznaczania znakiem daty i czasu odpowiedzialny będzie sprzętowy moduł HSM charakteryzujący się wysoką wydajnością operacji kryptograficznych, umożliwiający generowanie i przechowywanie materiału kryptograficznego wewnątrz urządzenia posiadającego certyfikaty bezpieczeństwa oraz zapewniający silne, dwuskładnikowe uwierzytelnianie do funkcji administracyjnych.

Istotnym systemem wspierającym bezpieczeństwo będzie wysyłki logów ze wszystkich czynności, w tym ze składania/przesyłania ofert/wniosków do wybranego dodatkowego centrum danych zlokalizowanego w Instytucji Publicznej. Lokalizacja taka minimalizuje ryzyko manipulacji danymi pełniąc rolę zaufanej strony trzeciej. Sama funkcjonalność wysyłki logów, zapewni możliwość niezależnej rejestracji czynności niezależnie od zewnętrznego Centrum Danych, wynajętego na zasadach hostingu na potrzeby Platformy e-Zamówienia.

Działanie modułów Platformy wspierać będą w szczególności następujące komponenty:

•    Manager Tożsamości - umożliwiający rejestrację, identyfikację, uwierzytelnienia (autentykację) oraz autoryzację interesariuszy postępowania o udzielenie zamówienia publicznego.

•    Zarządca Kluczy - odpowiedzialny za generowanie i udostępnianie kluczy szyfrujących w celu realizacji zabezpieczeń kryptograficznych ofert / wniosków

•    Administracyjny - wspomagający realizację zadań Administratora Merytorycznego.

•    Komponent Edukacyjny - udostępniający interaktywne materiały instruktażowe i tworzący statystyki wykorzystywania ich przez użytkowników

•    System Obsługi Zagadnień (SOZ)- odpowiedzialny za rejestrację i obsługę zgłoszeń użytkowników (help desk).

Na poniższym schemacie przedstawiono diagram poglądowy dla funkcjonowania Platformy e-Zamówienia.

Schemat funkcjonowania Platformy e-Zamówienia

m Ted

Platforma eZamowienia

Zamawiający

W ramach projektu te komponenty, które zostaną udostępnione użytkownikom końcowym będą spełniały wymagania dostępności WCAG 2.0 na poziomie AA wskazane w załączniku nr 4 do Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram

Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych. W ramach testów funkcjonalnych na etapie weryfikacji systemu w testach akceptacyjnych przewidziano testy weryfikujące poziom dostępności WCAG 2.0. na poziomie AA (testy te będą obejmować zarówno weryfikację pełnej listy wymagań dla poziomu AA jak i ich ocenę przez dedykowaną grupę docelową w ramach testów prowadzonych zgodnie ze zdefiniowanymi scenariuszami).

6.1.3 Dojrzałość e-usług Projektu

Podstawowym celem budowy Platformy e-Zamówienia jest udostepnienie e-usług wspomagających przeprowadzenie postępowania o udzielenie zamówienia publicznego, które jest interakcją pomiędzy zamawiającym (A), a wykonawcą (B). Oferowane na Platformie usługi elementarne A2B wspomagają ten proces.

Pod pojęciem usługi A2B rozumiana jest usługa świadczona przez Zamawiającego za pomocą Platformy e-Zamówienia na rzecz Wykonawcy (Oferenta) uczestniczącego w procesie zamówień publicznych jako potencjalny Wykonawca.

W szczególności dotyczy to kluczowych usług, tj. publikacji ogłoszeń, aukcji i licytacji oraz przyjmowania i zabezpieczania ofert / wniosków składanych przez wykonawców.

Publikacja wszystkich ogłoszeń ułatwi dostęp do informacji o całym rynku zamówień wykonawcom (włączając postępowania powyżej progów unijnych). Istotną grupą interesariuszy przygotowujących ogłoszenia przedstawiciele biznesu realizujący zamówienia sektorowe. Ogłoszenia o udzieleniu zamówienia przez nich publikowane (powyżej progów sektorowych) stanowią ok 14% ogłoszeń tego typu zamieszczanych w TED, a ich wartość to ponad 21% ogólnej wartości rynku zamówień w Polsce wg danych za rok 2015.

Centralne Repozytorium Danych zapewnia miejsce przechowywania i udostępniania aktualnych danych nt. zamówień publicznych umożliwiając jednocześnie rozwój usług w obszarze zamówień publicznych na różnych platformach zewnętrznych. Głównymi odbiorcami oferowanej przez CRD usługi wymiany danych ustrukturyzowanych są operatorzy Portali e-Usług (biznes). Podczas prezentacji publicznej Projektu wyrazili oni pozytywną opinię na temat usługi.

CRD służyć także będzie do przyjmowania i zabezpieczania ofert/wniosków składanych przez wykonawców (usługa A2B).

W oparciu o dane CRD funkcjonować też będą usługi modułu Monitorowania i Analiz. Będzie on dostarczać usług zarówno typu A2A jak i A2B/A2C. Organom kontroli i nadzoru będzie oferować usługę monitorowania i analizy funkcjonowania systemu zamówień (A2A), obejmującą m.in. dostęp do danych i dokumentów nt zamówień publicznych zgodnie z procedurą, możliwość generowania raportów, sprawozdawczość ad hoc. Wykonawcom, obywatelom, NGO i wszystkim zainteresowanym natomiast, udostępni usługę analityki biznesowej (BI) danych z obszaru zamówień publicznych (A2B / A2C), pozwalającą na korzystanie z gotowych oraz tworzenie własnych zestawień, raportów, statystyk z rynku zamówień publicznych.

Produktami Projektu są głównie e-usługi typu I A2B.

W poniższej tabeli przedstawiono e-usługi, które zostaną udostępnione w ramach realizacji projektu wraz z identyfikacją grup interesariuszy, do których skierowane są usługi oraz korzyści z ich wdrożenia .

Tabela usług i funkcjonalności - "e-Zamówienia - elektroniczne zamówienia publiczne"

Konieczność realizacji Projektu wynika wprost z Dyrektywy Parlamentu Europejskiego i Rady 014/24/UE z dnia 26 lutego 2014 r. Zakres funkcjonalny każdej z e-usług Projektu wynika z przepisów prawa w zależności od etapu na jakim znajduje się dane postępowanie.

Wszystkie planowane e-usługi oferują pełną transakcyjność, dwustronną interakcję, indywidualizację stąd poziom ich dojrzałości został określony na 4 lub 5.

Realizacja poszczególnych e-usług odbywa się drogą elektroniczną, za wyjątkiem czynności jakie przepisy prawa dopuszczają w drodze nieelektronicznej (np. przekazywanie załączników nieelektronicznych do ofert dla usługi nr 3 - przyjmowanie ofert).

Dla usług nr 2,3, 4 poziom 5 dojrzałości wynika z faktu, iż dostosowane są do indywidualnych potrzeb i sytuacji ich klientów (personalizacja), np. dokumenty uprzednio są wypełniane danymi przez usługodawcę dla zalogowanych użytkowników, w tym kolejne ogłoszenia, które w ramach danego postępowania są pre-wypełniane w oparciu o dane z wcześniej utworzonych. Realizacja e-usług nie wymaga wykonania płatności. W przypadku usług 2,3,4 przewidziano funkcje polegające na wyjściu z inicjatywą wyświadczenia usługi przez podmiot publiczny, np. przypominanie usługobiorcom o konieczności pewnych działań w związku z regułami biznesowymi w procesie, powiadamianie zainteresowanych wykonawców o zmianach w ogłoszeniach, SIWZ, itp. w postępowaniach, w których biorą udział lub subskrybują.

E-usługi potencjalnie obejmować będą ok. 35 000 Zamawiających oraz wszystkie podmioty gospodarcze i inne instytucje i organizacje (ok. 2 mln) pragnące uczestniczyć w procedurach PZP powyżej 30 000 € jako Wykonawcy.

Usługa nr 5 - Analityka biznesowa (BI) potencjalnie jest dla całego społeczeństwa i każdej grupy społecznej.

Analizę popytu oparto na dotychczasowych rocznych danych o liczbie rzeczywistych Zamawiających (ok. 15 000), tj. publikujących ogłoszenia w BZP lub TED, potencjalnych Zamawiających (ok. 35 000), tj. składających roczne sprawozdania z udzielonych zamówień, ok. 300 000 ogłoszeń, ok. 125 000 postępowań powyżej 30 000 €, ok. 23 000 subskrybentów ogłoszeń w BZP.

W roku 2015 wartość rynku zamówień publicznych udzielanych na podstawie przepisów ustawy - Pzp (dane na podstawie sprawozdań rocznych) wyniosła 116,3 mld zł., tj. ok. 6,50% produktu krajowego brutto (PKB), w tym kwota zamówień publicznych dla postępowań o wartości od najniższego progu ustawowego (30 000 euro) do progów unijnych wyniosła 33,1 mld zł, a dla postępowań o wartości powyżej progów unijnych - ok. 83,2 mld zł.

Zadaniem Projektu e-Zamówienia jest zwiększenie efektywności i transparentności procesu zamówień publicznych w Polsce poprzez wystandaryzowanie i udostępnienie szeregu e-usług wspomagających ten proces.

W ramach Projektu zwiększony zostanie poziom i jakość monitorowania wszystkich zamówień, w tym tych, których wartość nie przekraczała wyrażonej w złotych równowartości najniższego progu ustawowego - 30 000 euro (o wartości rynku ok. 31,2 mld zł) oraz zamówień sektorowych (o wartości rynku ok. 56,8 mld zł), objętych obowiązkiem sprawozdawczości rocznej.

Projekt nie obejmuje porządkowania rejestrów publicznych, lecz wykorzystywać będzie rejestry, np. KRS, KRK, CEDG, Teryt, Regon, NIP.

Usługa nr 5 - Analityka biznesowa (BI) przyczyni się bezpośrednio do ponownego wykorzystania danych na temat rynku zamówień publicznych.

Wskaźniki produktu w zakresie e-usług

❖    Liczba    usług publicznych udostępnionych on-line o stopniu dojrzałości 3    - 0    szt.

❖    Liczba    usług publicznych udostępnionych on-line o stopniu dojrzałości co    najmniej 4    - 5 szt.

❖    Liczba    udostępnionych usług wewnątrzadministracyjnych (A2A)    - 1    szt.

W ramach Projektu udostępnione zostaną informacje sektora publicznego. Projekt udostępni API do obustronnej wymiany informacji.

Dzięki przekazywaniu z wykorzystaniem API ustandaryzowanych danych, zmniejszy się obciążenie administracyjne interesariuszy procesu, a wszyscy zainteresowani rynkiem zamówień publicznych otrzymają natychmiastowy dostęp do kompletnych danych.

Realizacja projektu została zaplanowana w sposób zapewniający interoperacyjność z innymi systemami administracji państwowej, wdrożonymi lub planowanymi do wdrożenia. Platforma e-Zamówienia zintegrowana będzie z systemami zewnętrznymi wykorzystywanymi w procesie realizacji postępowania przetargowego.

6.2 Analiza procesów biznesowych i optymalizacja procesów

W poniższej tabeli przedstawiono opisy procesów/procedur, które zostaną uproszczone (w tym usprawnione) w ramach realizacji Projektu (poprzez wdrożenie nowych e-usług lub funkcji Platformy e-Zamówienia) oraz wskazano usługi w Projekcie realizujące ww. procesy/funkcjonalności.

Przykładowy opis (diagram BPMN) procesu udzielania zamówienia publicznego (od planu do publikacji ogłoszenia o zamówieniu)

W tabeli poniżej zamieszczono podstawowe czynności wykonywane w ramach procesu udzielania zamówienia publicznego. Opisano przebieg poszczególnych czynności w stanie obecnym i

^p

anowanym w Projekcie e-Zamówienia.

6.3 Wprowadzone innowacje

6.4 Weryfikacja produktów przez użytkowników

6.4.1 Metodologia weryfikacji produktów przez użytkowników

Interfejs aplikacji Platformy e-Zamówienia zostanie zaprojektowany i wykonany zgodnie z zaleceniami dotyczącymi User Experience/Usability. Wymagania dotyczące Projektu Technicznego Platformy e-Zamówienia, które obejmują aspekty wyglądu i dostosowania produktów od strony użytkowej zostały wypisane poniżej:

Projekt techniczny (dokumentacja analityczna i techniczna) przewidziany do realizacji w trakcie realizacji zadania Powstanie założeń systemu wykonany będzie w oparciu o wymagania określone w SIWZ, ofercie Wykonawcy oraz wyniki analiz . W szczególności obejmować będzie elementy niezbędne do prowadzenia następnie weryfikacji i walidacji produktów końcowych przez użytkowników:

Szczegółowe makiety interfejsów graficznych poszczególnych Modułów uwzględniające wyniki testów przeprowadzonych z udziałem grup kontrolnych (docelowych grup odbiorców), zrealizowane zgodnie z następującymi wymaganiami:

-    projektowanie realizowane będzie zgodnie z zasadami „projektowania zorientowanego na użytkownika" (ang. User centered design - UCD),

-    efektem projektowania będą:

•    projekt interfejsu graficznego, który będzie wygodny w użyciu i estetyczny (wymóg potwierdzenia opiniami grup kontrolnych),

•    scenariusze testowe do przyszłej implementacji,

•    nowe wymagania, które zostaną zidentyfikowane przez grupy kontrolne, a nie są oczywiste na danym etapie Projektu.

-    na podstawie dostarczonych diagramów BMM (Business Motivation Model) oraz listy wymagań funkcjonalnych i niefunkcjonalnych Wykonawca:

•    wykona makiety statyczne poszczególnych widoków, uwzględniając również urządzenia mobilne (zgodność z RWD - Responsive Web Design),

•    przeprowadzi testy wykonanych makiet statycznych,

•    wykona makiety funkcjonalne, które będą umożliwiały Użytkownikom interakcje z systemem, czyli przechodzenie pomiędzy ekranami przygotowanymi w punkcie

1.2.3 tiret 1-tiret 2 powyżej,

•    przeprowadzi testy w oparciu o złożone scenariusze, składające się z kilku kroków,

•    powtórzy każdy z powyższych punktów w kilku iteracjach, w zależności od efektów,

-    Jakość makiet w trakcie odbioru mierzona będzie liczbą błędów oraz szybkością reakcji testerów określonych w planie testów.

Weryfikacja produktów typu system teleinformatyczny przez użytkowników podzielona będzie na dwa etapy:

Etap prototypowania docelowego rozwiązania - gdy definiowany i projektowany będzie optymalny wygląd interfejsu aplikacji/portalu udostępnionego użytkownikom końcowym. Na tym etapie stosowane będą testy prowadzone metodą A/B. Testy te mogą się odbywać na makietach lub prototypie docelowego rozwiązania. Testy mają na celu zebranie potrzeb docelowych użytkowników na zwizualizowanych ekranach systemu, dodatkowo mają za zadanie usprawnienie działania portalu/systemu poprzez optymalne rozmieszczenie okien, przycisków czy testów na danym układzie strony/ekranu tak aby jak najbardziej uprościć działanie użytkownika (zmniejszając liczbę kliknięć, czy potwierdzeń, itp.). Dodatkowo na tym etapie będą wybierane docelowe layouty.

Etap weryfikacji i walidacji oprogramowania przy kontroli użyteczności docelowej produktu obejmować będzie testy prowadzone metodami:

a.    Testów UAT (ang. User Acceptance Test - testy akceptacyjne), które pozwalają na ocenę przez użytkowników końcowych czy zaimplementowane funkcjonalności są zgodne z wyspecyfikowanymi potrzebami użytkowników oraz czy system w pełni realizuje procesy biznesowe.

b.    Testów dynamicznych polegających na weryfikacji czy poprawnie działa całość systemu lub jego wybrany komponent poprzez uruchomienie danego procesu biznesowego i zweryfikowanie czy dane wyjściowe są zgodne z oczekiwanymi wynikami.

Testy te są elementem testów w fazie odbioru danego komponentu lub pełnej wersji systemu (poza testami integracyjnymi, wydajnościowymi czy testami bezpieczeństwa).

6.4.2 Zaangażowanie użytkowników w weryfikację produktów

6.4.3 Częstotliwość zaangażowania użytkowników w weryfikację produktów

6.4.4 Charakterystyka grupy kontrolnej grupy użytkowników

6.4.4.1 Opis grupy użytkowników

Planuje się zaangażować do grupy kontrolnej grupy użytkowników następujących reprezentantów:

W podziale wg specyfiki zamówienia:

1) Operatorzy platform zewnętrznych - w zakresie integracji rozwiązań (w tym API)

Przedstawiciele wybranych Zamawiających czyli przedstawiciele podmiotów, które ogłaszają postępowania a następnie w pełni je obsługują, z podziałem co najmniej na:

a.    Urzędy marszałkowskie

b.    Urzędy gmin i powiatów

c.    Ministerstwa i Urzędy Centralne

Przedstawiciele UZP (w obszarze procesów biznesowych - weryfikacja ich kompletności oraz spójności i zgodności z wymaganiami prawnymi oraz innymi zdefiniowanymi wytycznymi obowiązującymi w ramach prowadzonych postępowań).

Dla wszystkich reprezentantów powyżej wskazanych podgrup docelowych zakłada się iż będą oni w wieku od 23 lat do 65 lat, z podziałem minimalnym 70% kobiet i 30% mężczyzn. Rozkład związanych z zamieszkaniem w przypadku grup docelowych zakłada iż maksymalnie 40% grupy docelowej to będą mieszkańcy miast wojewódzkich.

Dla każdej z grup przewiduje się minimalnie 2 osoby uczestniczące w weryfikacji systemu lub danego komponentu.

Zakłada się iż osoby oddelegowane do grupy docelowej będą znać zasady i wymagania wynikające z ustawy Pzp, a także wcześniej składały oferty w postępowaniach przetargowych lub obsługiwały postępowanie przetargowe po stronie zamawiającego.

Wśród przedstawicieli grup docelowych zostaną także zaangażowani do weryfikacji produktów:

•    Niepełnosprawni

•    Osoby słabo widzące (m.in. na potrzeby weryfikacji czy wytyczne WCAG 2.0 zostały poprawnie zaimplementowane)

•    Osoby anglojęzyczne

•    Osoby nie posiadające dużego doświadczenia w pracy przy komputerze (np. praktykanci czy osoby po 60 roku życia)

Z uwzględnieniem proporcji w grupach reprezentatywnych uczestników procesu zamówień publicznych

Powyższa lista nie stanowi katalogu zamkniętego i w kolejnych etapach projektu może być i za pewne będzie rozszerzana zgodnie z bieżącymi potrzebami projektowymi.

6.4.4.1 Inkluzywny charakter grupy użytkowników

6.4.5 Opis weryfikacji produktów przez użytkowników

Zakłada się podzielenie weryfikacji produktów przez użytkowników na dwa etapy:

1)    Prototypowania

2)    Weryfikacji gotowych produktów (w ramach testów akceptacyjnych)

Plan badań z użytkownikami jest następujący:

1)    Po zebraniu grupy docelowej zostanie im przestawiony cel badania, jego zakres oraz oczekiwany wynik/efekt

2)    Z każdym użytkownikiem zostanie przeprowadzone wprowadzenie do badania (omówienie systemu, przedstawienie i wyjaśnienie scenariuszy, itp.)

3)    Po potwierdzeniu przez uczestników weryfikacji/walidacji systemu/komponentu rozpocznie się właściwe badanie wg scenariuszy lub w ramach tzw. testów swobodnych w zależności od potrzeb oraz decyzji Kierownika Testów

4)    Po zakończeniu badania zostanie ono podsumowane w postaci raportu lub notatki, które będą akceptowane przez użytkownika (tak aby zebrać jak najwięcej informacji z przeprowadzonego badania - celem nie może być tylko identyfikacja błędów ale również ocena czy system poprawnie realizuje procesy biznesowe, czy wspiera użytkownika w czynnościach np. walidacja wprowadzanych danych, itp. a także co warto byłoby zmienić lub usprawnić w kolejnej iteracji budowy lub modyfikacji systemu/komponentu z punktu widzenia osoby, która docelowo będzie korzystać z tego rozwiązania).

Cele jakie pozwolą osiągnąć metody opisane w sekcji 6.4.1 są następujące:

1)    Dla metody badań wskazanych na etapie prototypowania zakłada się, iż docelowy interfejs oraz wygląd ekranów zostanie ustalony z użytkownikami docelowymi na wstępnym etapie budowy systemu tym samym gwarantując iż będzie on dostoswany do potrzeb i wymagań użytkowników

2)    Weryfikacja produktów końcowych w fazie testów akceptacyjnych ma na celu potwierdzenie, iż funkcjonalności, które zostały zaimplementowane w pełni adresują potrzeby biznesowe użytkowników oraz gwarantują iż procesy biznesowe będą poprawnie realizowane (zgodnie z ustalonymi scenariuszami). Dodatkowo w tej fazie testów możliwa jest analiza czy wszystkie procesy biznesowe czy funkcjonalności są zaimplementowane w komponencie czy całym systemie.

Po zakończonych testach w fazie wstępnej czyli na etapie prototypowania dane będą zbierane w postaci raportu, który będzie wkładem do Projektu technicznego systemu w obszarze interfejsów oraz procesów biznesowych. Na podstawie zgłoszonych uwag przez osoby uczestniczące w badaniach będzie prowadzony proces analityczny przez analityków po stronie Wykonawcy przy nadzorze ze strony Zamawiającego oraz podmiotu wspierającego tak aby wszelkie kluczowe uwagi oraz sugestie zgłoszone w trakcie badań były ujęte w doprecyzowaniu przypadków użycia lub wymaganiach funkcjonalnych oraz pozafunkcjonalnych.

Po zakończonych testach w fazie odbiorowej z każdego badania powstanie zbiorczy raport podsumowujący jego przebieg. W raporcie odnotowane zostaną informacje o przeprowadzonych działaniach tj. scenariuszach jakie były wykonywane przez uczestników badania oraz o ich wynikach -czy scenariusz zakończył się wynikiem pozytywnym czy negatywnym. Jeśli wynik jest negatywny to konieczne będzie opisanie jakie błędy lub braki zidentyfikowano i czy są one podstawą do odrzucenia produktu. Dodatkowo odnotowywane będą wnioski i sugestie, które po ocenie przez zespół analityków i architektów po stronie Zamawiającego może być podstawą do przygotowania wniosków o zmianę.

Raporty z przebiegu testów o których mowa powyżej będą generowane automatycznie z systemu wspierającego przebieg testów (typu np. Jira) na każdym jego etapie.

7 Analiza otoczenia

Systemy e-zamówień w Europie i na świecie realizują obecnie podobne usługi. Różnice występują w zakresie elektronizacji, poziomie obowiązkowości, transparentności, sposobie wdrażania regulacji. Jeśli chodzi o architekturę i modele biznesowe podejście jest również bardzo niejednorodne w skali Europy. Poziom elektronizacji i automatyzacji procesów w zamówieniach publicznych w poszczególnych krajach w dużej mierze zależy od dostępności i jakości innych e-usług. Dotyczy to zwłaszcza tzw. usług zaufania oraz usług oferowanych przez krajowych integratorów danych z rejestrów państwowych. W niektórych krajach zbudowano lub są planowane platformy centralne (Chorwacja, Cypr, Gruzja, Bośnia i Hercegowina), w innych funkcjonuje kilka platform publicznych lub prywatnych (np. Niemcy, Francja, Portugalia) w dużej mierze uwarunkowane to jest podziałem administracyjnym. Czasem bardzo istotną rolę odgrywają CPB (centralni zamawiający), którzy realizują wszystkie zakupy dla administracji centralnej.

7.1    Gotowość legislacyjna

7.1.1    Możliwość realizacji Projektu

7.1.2 Analiza otoczenia prawnego

Projekt e-Zamówienia - elektroniczne zamówienia publiczne, wychodzi naprzeciw wprowadzonemu nowelizacją ustawy Prawo zamówień publicznych z dnia 22 czerwca 2016 r. (Dz. U. z 2016 r., poz. 1020) obowiązkowi elektornizacji procesu udzielenia zamówień publicznych. Nowelizacja ustawy Prawo zamówień publicznych wprowadziła ten obowiązek w związku z implementacją postanowień Dyrektywy Parlamentu Europejskiego i Rady nr 2014/24/UE z dnia 26 lutego 2014 r. w sprawie zamówień publicznych, uchylająca dyrektywę 2004/18/WE (Dz. Urz. UE L 94 z 28.03.2014, str. 65, z późn. zm.) oraz Dyrektywy Parlamentu Europejskiego i Rady nr 2014/25/UE z dnia 26 lutego 2014 r. w sprawie udzielania zamówień przez podmioty działające w sektorach gospodarki wodnej, energetyki, transportu i usług pocztowych, uchylająca dyrektywę 2004/17/WE (Dz. Urz. UE L 94 z 28.03.2014, str. 243, z późn. zm.).

Zgodnie z regulacjami krajowymi i unijnymi powszechne przejście na pełny elektroniczny proces prowadzenia postępowań o zamówienie publiczne powinno nastąpić do dnia 18 października 2018 r.

W Fiszce Projektu e-Zamówienia przedstawiono, że realizacja Projektu będzie wymagała zmian legislacyjnych w Ustawie Pzp w zakresie przekazywania na Platformę e-Zamówienia wybranych ustrukturyzowanych danych i oraz aktów wykonawczych określających zakres i format danych.

W wyniku dalszych analiz prawnych na etapie przygotowywania Studium Wykonalności stwierdzono jednak, iż ustawodawca krajowy co do zasady nowelizacją ustawy Prawo zamówień publicznych z dnia 22 czerwca 2016 r. (Dz. U. z 2016 r., poz. 1020) wprowadził regulacje prawne niezbędne do realizacji Projektu.

Regulacją nie zostały objęte jedynie wymagania techniczne i organizacyjne użycia środków komunikacji elektronicznej w postępowaniu o udzielenie zamówienia oraz sposób sporządzania i przechowywania dokumentów elektronicznych a także sposób i tryb ich przekazywania, udostępniania i usuwania. W tym zakresie ustawodawca w art. 10g ustawy Prawo zamówień publicznych upoważnił Prezesa Rady Ministrów do określenia w drodze rozporządzenia powyższych kwestii.

Uwzględniając konieczność wydania przedmiotowego rozporządzenia, 17 marca 2017 r. jego projekt został przekazany do ponownych uzgodnień międzyresortowych, termin na zgłoszenie uwag upłynął 29 marca 2017 r.

Aktualnie projekt rozporządzenia znajduje się na etapie po uzgodnieniach i konsultacjach publicznych, a przed skierowaniem projektu rozporządzenia na Komitet Rady Ministrów do Spraw Cyfryzacji.

Projekt rozporządzenia opatrzony jest nr 91 w Wykazie prac legislacyjnych Prezesa Rady Ministrów.

Biorąc pod uwage powyższe stwierdzić należy, iż obecne otoczenie prawne pozwala na realizację Projektu.

7.2 Prawa Autorskie

7.2.1 Otwarta licencja

7.2.2 Uzasadnienie wyboru odpowiedniego modelu prawnego

Projekt będzie preferował rozwiązania o otwartym kodzie (Open Source), lecz nie wyklucza także wykorzystania komercyjnego oprogramowania w szczególnie ważnych elementach systemu celem zapewnienia bezpieczeństwa systemu oraz składanych ofert przetargowych, wydajności, dostępności, ergonomii oraz ciągłości działania. W przypadku rozwiązań Open Source nie przewiduje się publikacji kodu źródłowego wytworzonego oprogramowania ze względu na konieczność zapewnienia wysokiego poziomu bezpieczeństwa systemu, a zwłaszcza modułu przyjmowania i zabezpieczania ofert. Zaufanie interesariuszy do systemu jest sprawą kluczową, biorąc pod uwagę, że wartość rynku zamówień publicznych (udzielanych na podstawie Pzp) w Polsce rocznie wynosi ponad 116 mld zł.

Zastosowanie komercyjnego oprogramowania nie będzie mogło powodować uzależnienia od konkretnego dostawcy czy rozwiązania technicznego (vendor lockingu) ani powodować konieczności ponoszenia dodatkowych niezasadniomnych kosztów licencji.

Wykonawca będzie miał obowiązek przekazania pełnych kodów źródłowych, opisu interfejsów, struktur danych do indywidulanie wytworznej części systemu niezależnie czy to będzie Open Source czy oprogramowanie komercyjne. Dla gotowych komponentów oraz bibliotek firm trzecich wykonawca zobowiązany będzie do przekazania opisu interfejsów oraz struktur danych oraz licencji na ich wykorzystywanie bez ponoszenia dodatkowych opłat z wyraźnym wskazaniem rekomendowanego lub obowiązkowego wsparcia m.in. aktulizacja do nowszej wersji, suport bazy danych, możliwość przejścia z wersji otwartej na komercyjną).

8 Budżet

8.1 Koszty ogólne

Całkowity koszt projektu wyniesie: 19 570 000,00 zł brutto (16 508 943,09 netto - podany koszt netto został oszacowany jako koszt brutto pomniejszony i wartość VAT). W tym, udział partnerów wyniesie odpowiednio:

•    Ministerstwo Cyfryzacji - 17 810 000,00 zł brutto,

•    Urząd Zamówień Publicznych - 1 760 000,00 zł brutto.

Wskazany koszt projektu w podziale na poszczególne lata został przedstawiony szczegółowo w modelu analizy finansowej załączonej do wniosku o dofinansowanie i wynosi:

•    w    roku    2017 -    1 360 162,60netto / 1 597 100,00brutto,

•    w    roku    2018 -    10 715 447,16netto / 13 069 500,00brutto,

•    w    roku    2019 -    3 689 024,39netto / 4 245 400,00brutto,

•    w    roku    2020 -    596 666,67 netto / 658 000,00brutto.

Koszt realizacji projektu zostanie sfinansowany ze środków Programu Operacyjnego Polska Cyfrowa, działanie 2.1. „Wysoka dostępność i jakość e-usług publicznych" oraz ze środków budżetu państwa, w następujących proporcjach:

•    z funduszy zagranicznych: 13 971 518,54 zł netto / 16 562 091,00 zł brutto,

•    z budżetu państwa: 2 537 424,55 zł netto / 3 007 909,00 zł brutto.

8.2 Analizy

8.2.1 Analiza kosztów i korzyści

Przedstawiona w niniejszym rozdziale analiza kosztów projektu została sporządzona na podstawie następujących założeń:

o wartości finansowe zostały przedstawione w PLN, w cenach nominalnych, o podawane ceny towarów i usług są cenami brutto, ponieważ partnerzy nie mogą odzyskać podatku VAT,

o w odniesieniu do stawek podatkowych (w tym podatku VAT) zastosowano ich bieżące wartości, zgodnie z odpowiednimi obowiązującymi przepisami, o za rok obrotowy przyjęto rok kalendarzowy,

o na potrzeby przeprowadzonej analizy przyjęto horyzont czasowy obejmujący 10-letni okres odniesienia, licząc or roku rozpoczęcia projektu, tj. lata 2017-2026, o w analizie nie uwzględniono rezerwy na nieprzewidziane wydatki.

Analiza korzyści z realizacji projektu jest ujęta w rozdziale 8.5 Analiza ekonomiczno - finansowa.

Poniżej przedstawiono uzasadnienie dla przedstawionego w rozdziale 8.2.1 Analiza kosztów i korzyści szacunku kosztów realizacji projektu oraz nakładów na utrzymanie trwałości projektu w 10-letnim okresie odniesienia, w podziale na:

o oprogramowanie wytwarzane o zakup licencji oprogramowania standardowego o zakup infrastruktury o wynajem infrastruktury (chmura) o koszty szkoleń o koszty osobowe o inne

Oprogramowanie wytwarzane

Głównym zadaniem w ramach realizacji projektu będzie „Budowa i wdrożenie Platformy e-Zamówienia". W ramach tego zadania, wykonawca wytworzy i wdroży Platformę e-Zamówienia w oparciu o oprogramowanie open-source, zatem większość kosztu budowy i wdrożenia platformy oszacowano na podstawie szacunkowego kosztu zatrudnienia specjalistów. Koszt ten, zakwalifikowany jako „oprogramowanie wytwarzane", wyniesie łącznie 12 380 952,38 zł brutto.

Koszt wytworzenia oprogramowania został oszacowany na podstawie prognozy zatrudnienia specjalistów wykonawcy, z uwzględnieniem następujących prac / etapów w ramach realizacji przedmiotu zamówienia:

•    zarządzanie,

•    powstanie założeń rozwiązań systemu, w tym architektury,

•    wypracowanie standardu usług i danych, API przez wykonawcę, wymagań na certyfikację, integracji z innymi systemami (np. e-fakturowanie),

•    wersja beta,

•    testy akceptacyjne, w tym audyt bezpieczeństwa systemu,

•    zdolność do certyfikacji bezpieczeństwa i standardów usług i danych,

•    rozpoczęcie rejestracji Zamawiających,

•    uruchomienie podstawowych usług zamówień publicznych,

•    nadzór autorski nad eksploatacją w okresie stabilizacji systemu,

•    uruchomienie usług monitorowania i analiz w tym BI, benchmarki do nowych danych,

•    uruchomienie usługi sprawozdawczości,

•    uruchomienie usługi kontroli elektronicznej,

•    integracja CRD z usługą odwołania elektronicznego.

Dla tak zdefiniowanych prac / etapów przypisano poziom zaangażowania specjalistów (Project Manager, Biuro Projektu, account, scrum master, Backend developer/Security Engineer, Frontend developer, UX designer, Graphic designer, Tester, IT analytics/architect, DevOps, Communication) i oszacowano koszt ich zaangażowania w trakcie realizacji projektu. Szczegółowe oszacowanie kosztów wytworzenia oprogramowania przedstawiono w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „Koszt platformy_szac".

Należy podkreślić, że koszt ten, pomimo że został oszacowany na podstawie zaangażowania specjalistów wykonawcy, w projekcie będzie zakwalifikowany jako koszt zakupu wartości niematerialnych i prawnych, gdyż z perspektywy wnioskodawcy nie będą ujmowane koszty zatrudnienia pracowników wykonawcy ale koszt dostarczonego oprogramowania (wytworzonego przez tych specjalistów).

Postępowanie o udzielenie zamówienia zostanie ogłoszone po złożeniu Wniosku o Dofinansowanie, tak aby bezpośrednio po podpisaniu porozumienia możliwe było rozpoczęcie prac przez Wykonawcę. Podział kosztów jakie Zamawiający będzie ponosił w zakresie oprogramowania wytwarzanego w poszczególnych latach oszacowano w oparciu o główne etapy zamówienia w tym:

•    w 2017 roku - 800 000,00 zł brutto - projekt techniczny,

•    w 2018 roku - 9 380 952,38 zł brutto - główne funkcjonalności systemu (uruchomienie produkcyjne w październiku),

•    w 2019 roku - 2 000 000,00 zł brutto - dodatkowe funkcjonalności (integracja CRD z usługą odwołania elektronicznego),

•    w 2020 roku - 200 000,00 brutto - dokumentacja końcowa.

Wydatki są kwalifikowalne w ramach kategorii: a) Środki trwałe i wartości niematerialne i prawne / i) Oprogramowanie - wydatki na pokrycie kosztów stworzenia, zakupu, leasingu, dzierżawy i najmu oprogramowania, wydatki na wdrożenie oprogramowania.

Beneficjent będzie preferował wykonanie systemu z wykorzystaniem otwartego oprogramowania Open Souce lecz nie wyklucza znaczącego wykorzystania komercyjnego oprogramowania w szczególnie ważnych elementach systemu celem zapewnienia bezpieczeństwa systemu oraz poufność i integralność składanych ofert wydajności, dostępności, ergonomii oraz ciągłości działania.

System informatyczny do reliazji Platformy e-Zamówienia który jest produktem Projektu, musi zapewniać jak najwyższe standardy w tym zakresie. Równie istotne jest zapewnienie trwałości Projektu poprzez zagwarantowane dalszego rozwoju każdego z wykorzystywanych komponentów rozwiązania, w szczególności tych które wykonane zostaną jako dedykowane dla tego Projektu. Uzyskanie wymaganego poziomu gwarancji na oprogramowanie Open Source, usuwanie błedów w oprogramowaniu, zapewnienie wsparcia technicznego dla komponentów powstałych w ramach otwartej licencji jest znacznie trudniejsze niż dla oprogramowania komercyjnego gdzie jego producent podejmuje zwykle znacznie szersze i skutecznie działania w tym zakresie oraz dysponuje zapleczem firm współpracujących zwiększając zakres wsparcia technicznego. W modelu Open Source część komponentów jest rozwijana a część już nie jest rozwijana i musi być stworzona od nowa lub zastąpiona innymi.

Wykonawca zobowiązany będzie do przekazania pełnych kodów źródłowych, opis interfejsów, struktur danych do indywidulanie wytworznej część systemu niezależnie czy to będzie w będzie Open Source czy oprogramowanie komercyjne. Dla gotowych kompomnentów oraz bibliotek firm trzecich wykonawca zobowiązany będzie do przekazania opisu interfejsów oraz struktur danych oraz licencji na ich wykorzystywanie bez ponoszenia dodatkowych opłat z wyraźnym wskazaniem rekomendowanego lub obowiązkowego wsparcia m.in. aktulizacja do nowszej wersji, suport bazy danych, możliwość przejścia z wersji otwartej na komercyjną.

Szczegółowe wymagania w tym zakresie będą określone na etapie Opisu Przedmiotu Zamówienia.

Zakup licencji oprogramowania standardowego

Jak wskazano w poprzedniej sekcji, platforma będzie wytwarzana w oparciu o oprogramowanie open source, jednak ze względu na wymagania związane z bezpieczeństwem informacji oraz późniejszym utrzymaniem i rozwojem systemu przez Zamawiającego w okresie odniesienia konieczne jest uwzględnienie nakładów na zakup oprogramowania, w tym:

•    HSM - 2 szt, po jednej na każde centrum przetwarzania,

•    narzędzia programistyczne - przekazanie licencji Beneficjentowi po uruchomieniu produkcyjnym, tak aby Beneficjent mógł dokonywać modyfikacji (np. dostosowania do zmian w prawie),

•    licencje bazy danych z szyfrowaniem - narzędzia open source nie zapewnią wystarczającego poziomu bezpieczeństwa dla bazy danych, w której przechowywane będą oferty, a te dokumenty są szalenie wrażliwe i jakiekolwiek włamanie i wykradzenie oferty zawierającej dane chronione tajemnicą przedsiębiorstwa może mieć poważne skutki.

Na podstawie analizy rynku przyjęto, że koszt ww. narzędzi wyniesie nie mniej niż 5% kosztów oprogramowania wytwarzanego. Przyjęto, że licencje zostaną odebrane w 2018 roku, gdy nastąpi uruchomienie produkcyjne systemu.

Dodatkowo, jako zakup licencji oprogramowania standardowego wykazano oprogramowanie dostarczane wraz z laptopami kupowanymi na potrzeby zespołu projektowego. Koszt ten zostanie poniesiony w 2017 roku. Szczegółowy szacunek kosztów zakupu, w oparciu o ceny jednostkowe, jest przedstawiony w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „Założenia".

Wydatki są kwalifikowalne w ramach kategorii: a) Środki trwałe i wartości niematerialne i prawne / i) Oprogramowanie - wydatki na pokrycie kosztów stworzenia, zakupu, leasingu, dzierżawy i najmu oprogramowania, wydatki na wdrożenie oprogramowania.

Zakup infrastruktury

W skład kosztów zakupu infrastruktury wchodzi sprzęt biurowy (multimedialny i komputerowy) kupowany na potrzeby realizacji projektu, w tym: laptopy kupowane w 2017 roku oraz projektory multimedialne, wydajne urządzenia wielofunkcyjne, i tablety w 2018 roku. Zakupiony sprzęt będzie wykorzystywany wyłącznie na potrzeby zespołu projektowego, a w okresie trwałości projektu - na potrzeby zespołu utrzymania.

Szczegółowy szacunek kosztów zakupu, w oparciu o ceny jednostkowe, jest przedstawiony w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „Założenia".

Wydatki są kwalifikowalne w ramach kategorii: a) Środki trwałe i wartości niematerialne i prawne / ii) Sprzęt informatyczny - wydatki na zakup i dostawę sprzętu informatycznego.

Wynajem infrastruktury (chmura)

Założono, że Wykonawca umowy na budowę i wdrożenie Platformy e-Zamówienia zrealizuje usługę hostingu w modelu chmury obliczeniowej. Usługa hostingu zostanie uruchomiona z chwilą przekazania systemu do testów akceptacyjnych (czerwiec 2018 r). Hosting będzie przeznaczony do obsługi wszystkich modułów i komponentów Platformy e-Zamówienia w środowiskach produkcyjnym, testowym i szkoleniowym. Dodatkowo Wykonawca udostępni Zamawiającemu kolokację zasobów niezbędnych do uruchomienia komponentu Zarządca Kluczy, w tym modułów HSM.

Wykonawca zapewni możliwość przeniesienia usługi do Wspólnej Infrastruktury Państwa.

Koszt hostingu oszacowano na 100 000 zł brutto na kwartał (tj. 400 000 zł brutto w skali roku). Łączny koszt hoostingu w czasie realizacji projektu wyniesie 700 000 brutto (usługa świadczona będzie w sumie przez 7 kwartałów).

Wydatki są kwalifikowalne w ramach kategorii: b) Usługi zewnętrzne / ii) Usługi informatyczne -wydatki na pokrycie kosztów usług: zapewnienia dostępu do sieci Internet, hostingu, kolokacji i innych.

Koszty szkoleń

W trakcie realizacji projektu przewidziano szkolenia dla zespołu projektowego:

•    zarządcze (SCRUM, PRINCE2/Agile)

•    analityczne (BPM, UML)

•    testowanie, utrzymanie (ITIL)

•    bezpieczeństwo

•    projektowanie UX

oraz szkolenia dla użytkowników końcowych i administratorów oraz Help Desk.

Wsparcie Zespołu Projektowego w realizacji Projektu związane ze szkoleniami będzie w szczególności obejmować:

•    przygotowanie kadry zarządzającej do prowadzenia Projektu zgodnie z metodykami OGC i SCRUM,

•    przygotowanie pracowników Beneficjenta w zakresie sposobu realizacji prac analitycznych,

•    przygotowanie Zespołu Projektowego w zakresie zarządzania wymaganiami,

•    przygotowanie pracowników Beneficjenta w zakresie sposobu realizacji usług utrzymaniowych;

W celu zapewnienia efektywnej współpracy z ekspertami i wykonawcami platformy przewidywane są szkolenia Zespołu Projektowego w obszarach:

•    tworzenia architektury systemów IT,

•    prowadzenia testów systemów IT,

•    aspektów bezpieczeństwa systemów IT

•    technologicznych.

Drugi pakiet szkoleń to szkolenia dla administratorów merytorycznych, które zostaną dostarczone przez wykonawcę Platformy. Szkolenia będą adresowane do osób pełniących rolę Help Desk (6 osób) oraz administratorów merytorycznych (4 osoby). Ponadto, opracowane zostaną materiały samokształceniowe

Dodatkowo, przeprowadzonych zostanie 5 seminariów/konferencji, każde adresowane do 200 użytkowników.

Szczegółowy szacunek kosztów zakupu, w oparciu o ceny jednostkowe, jest przedstawiony w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „Założenia".

Wydatki są kwalifikowalne w ramach kategorii: f) Szkolenia / i) szkolenia, seminaria i warsztaty dla pracowników instytucji korzystających z produktów projektu, w tym e-learning, oraz ii) szkolenia dla osób zaangażowanych we wdrażanie projektu.

Koszty osobowe

Koszty osobowe obejmą wynagrodzenia zespołu projektowego po stronie MC i UZP oraz koszty pośrednie.

W ramach kosztu wynagrodzeń pracowników wykonujących merytoryczne zadania bezpośrednio związane z głównymi celami i produktami Projektu przewidziano 12 etatów kalkulacyjnych (6 po stronie MC i 6 po stronie UZP) dla zespołu projektowego. Poniżej przedstawiono skład zespołu projektowego po stronie każdego z partnerów, ze wskazaniem ról i wymiaru etetu dla każdej roli:

Zespół projektowy MC:

Zespół projektowy UZP:

Dla przytoczonych ról projektowych przewidziano wynagrodzenie miesięczne brutto (koszt pracodawcy) na poziomie:

•    Kierownik Projektu, Starszy analityk biznesowy - 8 350,00 zł,

•    pozostałe etaty - 8 330,00 zł.

Poziom wynagrodzeń przewidziany dla członków zespołu projektowego jest zgodny z poziomem wynagrodzenia pracowników wnioskodawcy i partnera, dla analogicznych ról/odpowiedzialności.

Szczegółowy szacunek kosztów wynagrodzeń, w oparciu o ceny jednostkowe, jest przedstawiony w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „Założenia".

Wydatki są kwalifikowalne w ramach kategorii: e) Wynagrodzenia pracowników wykonujących merytoryczne zadania bezpośrednio związane z głównymi celami i produktami Projektu.

W zakresie kosztów pośrednich planowane są wydatki związane z zaangażowaniem osób wykonujących czynności niezwiązane bezpośrednio z głównymi celami i produktami projektu, jak koszty wynagrodzeń osób zaangażowanych w obsługę techniczną projektu, w tym obsługę kadrową, księgową, obsługę w zakresie zamówień, etc. Koszt oszacowano jako jeden etat kalkulacyjny oraz budżet przeznaczony na zlecenia / dodatki funkcyjne dla osób angażowanych w miarę potrzeb.

Po stronie MC, role jakie będą angażowane, w ramach potrzeb, i finansowane z kosztów pośrednich to m.in.:

•    Specjalista    ds.    promocji,

•    Specjalista    ds.    rozliczeń finansowych,

•    Specjalista    ds.    zakupów i    postępowań przetargowych,

•    Specjalista    ds.    legislacji,

•    Radca prawny,

•    Specjalista ds. wsparcia rozliczeń finansowych,

•    Specjalista ds. Kadry i szkoleń,

•    Specjalista ds. Komunikacji.

Skład zespołu wspierającego, finansowanego z kosztów pośrednich, po stronie UZP obejmie następujące role:

•    Ekspert ds. zamówień publicznych,

•    Specjalista ds. rozliczania kosztów w projekcie (ds. rozliczeń),

•    Specjalista ds. Zakupów i podstępowań przetargowych,

•    Analityk Ekspert ds. prawnych.

Wydatki są kwalifikowalne w ramach kategorii: h) Wydatki poniesione na pokrycie kosztów pośrednich.

W okresie utrzymania, w ramach kosztów wynagrodzeń przewidziano:

•    5 etatów po stronie UZP,

•    5 etatów po stronie MC.

Poniższa tabela przedstawia, jakie role i w jakim wymiarze etatu będą angażowane przez partnerów w okresie utrzymania, w ramach wskazanego limitu p 5 tatów na partnera. Wskazane role w okresie utrzymania wynikają z metodyki ITIL, która będzie stosowana na etapie utrzymania trwałości produktów projektu.

(*) Łączy zarządzanie drzewem dwóch usług - utrzymania i rozwój. Menedżer ds. zarządzania poziomem świadczenia usługi (właściciel procesu) - jest odpowiedzialny za negocjowanie umów serwisowych oraz zapewnienie, że są one spełnione. Sprawia, że wszystkie procesy zarządzania usługami IT, umowy OLA oraz kontrakty z dostawcami zewnętrznymi (ang. UC) są zgodne z celami poziomu usług. Do jego zadań należy także monitorowanie oraz raportowanie poziomu usług.

Przewiduje się łączenie poszczególnych ról.

Szczegółowy szacunek kosztów wynagrodzeń jest przedstawiony w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „Założenia".

Inne

W tej grupie mieszczą się pozostałe grupy wydatków składające się na koszt Projektu, obejmujące:

•    w okresie realizacji projektu: nadzór ekspercki nad wykonaniem projektu, promocję, oraz testy,

•    w okresie utrzymania: hosting, utrzymanie systemu/asystę techniczną, nakłady na promocję oraz coroczny audyt bezpieczeństwa.

Szczegółowy szacunek kosztów jest przedstawiony w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „Założenia". Poniżej przedstawiono zakres usług planowanych w ramach poszczególnych kategorii wydatków.

Nadzór ekspercki nad wykonaniem projektu:

Beneficjent zamierza korzystać ze wsparcia eksperckiego zewnętrznej firmy, wybranej w postępowaniu przetargowym, która będzie uzupełniała kompetencje zespołu projektowego do momentu zakończenia wdrożenia wszystkich planowanych usług.

Wsparcie obejmie m.in:

• udział w spotkaniach z Wykonawcą Platformy e-Zamówienia oraz występowanie w charakterze doradcy po stronie Zespołu Projektowego;

• wsparcie w przeglądach, opiniowaniu i odbiorach produktów realizowanych przez wykonawców, dostarczających usługi i produkty dla Projektu;

•    wsparcie w prowadzeniu audytów w poszczególnych obszarach Projektu;

•    wsparcie prac w realizacji warsztatów analitycznych;

•    wsparcie w pracach związanych z merytorycznym odbiorem produktów w tym weryfikacją poprawności zaproponowanej architektury rozwiązania, budowy wymagań funkcjonalnych i niefunkcjonalnych;

•    wsparcie w zakresie odbioru kodów źródłowych.

Koszt zaangażowania nadzoru eksperckiego oszacowano na podstawie analizy rynku jako 10% wartości budowy i wdrożenia Platformy. Szczegółowe założenia odnośnie podziału koszu w latach są przedstawione w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „Założenia".

Wydatki są kwalifikowalne w ramach kategorii: b) Usługi zewnętrzne / iii) Usługi wspomagające realizację projektu - usługi doradcze w trakcie realizacji projektu, w tym zapewnienie wsparcia technicznego.

Promocja

W ramach działań informacyjno-promocyjnych zaplanowanych na cały czas trwania Projektu przewidywane są następujące czynności (opracowanie produktów promocji):

•    opracowanie Logo i księgi marki,

•    organizacja konferencji informacyjno-promocyjnych,

•    opracowanie ulotek i plakatów i innych materiałów promocyjnych,

•    wydanie broszury informacyjnej,

•    wykonanie prezentacji multimedialnych,

•    działania informacyjno-promocyjne w internecie,

•    działania informacyjno-promocyjne w środkach masowego przekazu.

Szczegółowy szacunek kosztów jest przedstawiony w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „Założenia".

Wydatki są kwalifikowalne w ramach kategorii: g) Informacja i promocja / iii) wydatki poniesione w związku z organizacją konferencji promujących projekt, oraz iv) poniesione w związku z realizacją działań informacyjno-promocyjnych, w tym m.in. kampanii, promocji w mediach elektronicznych i tradycyjnych.

Specjalistyczne testy akceptacyjne (Audyt bezpieczeństwa informacji)

Specjalistyczne, kompleksowe testy akceptacyjne obejmą m.in. testy bezpieczeństwa, akceptacyjne (wydajnościowe, UAT, integracyjne) oraz akceptacyjne kodów źródłowych (automatyczne)i wraz z planem wszystkich testów i scenariuszami testowym. Wskazany zakres testów zostanie wykonany przez niezależny podmiot zewnętrzny wybrany w postępowaniu o udzielenie zamówienia publicznego, natomiast akceptacyjne testy merytoryczne zostaną wykonane przez zespół projektowy MC/UZP.

Szczegółowy szacunek kosztów jest przedstawiony w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „Założenia".

Wydatki są kwalifikowalne w ramach kategorii: b) Usługi zewnętrzne / iii) Usługi wspomagające realizację projektu - - usługi doradcze w trakcie realizacji projektu, w tym zapewnienie wsparcia technicznego.

Szczegółowy opis założeń w odniesieniu do ujętych w kategorii „Inne" kosztów utrzymania został przedstawiony w rozdziale 8.4 Analiza kosztów utrzymania.

8.3 Nakłady na poszczególne elementy projektu

UWAGA:

Tabela nie zawiera całości nakładów na realizację Projektu. Elementy projektu wymienione w tabeli (zgodnie z formularzem studium wykonalności), pomijają następujące koszty ujęte w budżecie projektu:

8.4 Analiza kosztów utrzymania

Celem analizy kosztów utrzymania jest przedstawienie kompletnej i wiarygodnej prognozy kosztów, jakie Partnerzy będą ponosili w związku z utrzymaniem trwałości produktów wdrożonych w ramach projektu. Koszty utrzymania są następnie ujmowane w analizie ekonomiczno-finansowej, jako element przepływów pieniężnych w okresie utrzymania, wpływając na wysokość oszacowanych wskaźników efektywności finansowej i ekonomicznej. W niniejszym rozdziale przedstawiono sposób oszacowania kosztów utrzymania produktów projektu.

Roczny koszt utrzymania Platformy oszacowano na 1 335 600 zł netto (1 497 060 zł brutto), co w perspektywie 5 lat oznacza nakłady na utrzymanie na poziomie 6 678 000 zł netto (7 485 300 zł brutto). Na te kwoty składają się następujące elementy:

•    obsługa po stronie UZP - merytoryczna, Help Desk, administrator,

•    obsługa po stronie MC - techniczna, Help Desk, administrator,

•    hosting,

•    utrzymanie systemu, asysta techniczna,

•    promocja i informacja,

•    audyt bezpieczeństwa - coroczny.

Poniżej przedstawiono założenia, na podstawie których oszacowano poszczególne składowe kosztów utrzymania.

Obsługa po stronie UZP

Koszt obejmie 5 etatów kalkulacyjnych po stronie UZP, w ramach których pełnione będą zadania w zakresie obsługi merytorycznej, Help Desk i administratora. Przy zakładanym koszcie miesięcznym pracodawcy na poziomie 5 280 zł, oznacza to roczny koszt wynagrodzeń po stronie UZP na poziomie 316 800 zł brutto.

Przewidywany poziom wynagrodzeń odpowiada wynagrodzeniom pracowników partnera, dla analogicznych ról / odpowiedzialności. Szczegółowy wykaz ról i wymiaru etatów dla tych ról przedstawiono w rozdziale: 8.2.1 Analiza kosztów i korzyści, sekcja: Koszty osobowe.

Obsługa po stronie MC

Koszt obejmie 5 etatów kalkulacyjnych po stronie MC, w ramach których pełnione będą zadania w zakresie obsługi technicznej, Help Desk i administratora. Przy zakładanym koszcie miesięcznym pracodawcy na poziomie 5 280 zł, oznacza to roczny koszt wynagrodzeń po stronie MC na poziomie 316 800 zł brutto.

Przewidywany poziom wynagrodzeń odpowiada wynagrodzeniom pracowników wnioskodawcy, dla analogicznych ról / odpowiedzialności. Szczegółowy wykaz ról i wymiaru etatów dla tych ról przedstawiono w rozdziale: 8.2.1 Analiza kosztów i korzyści, sekcja: Koszty osobowe.

Hosting

Roczny koszt usługi hostingu oszacowano na 300 000 zł netto (369 000 zł brutto) w skali roku. Przewidywany koszt eksploatacji w okresie trwałości jest niższy niż w okresie realizacji projektu ponieważ:

•    system będzie ustabilizowany i znane będzie rzeczywiste obciążenie systemu potwierdzoną pierwszym okresem jego eksploatacji i wykonawca hostingu będzie posiadał wiedzę o obciążeniach w szczytowych okresach,

•    hosting w okresie realizacji będzie realizowany jako element składowy budowy systemu co siłą rzeczy obarczony jest większym ryzykiem niż w okresie eksploatacji.

•    rynek usług hostingowych w Polsce jest na etapie intensywnego rozwoju i brak jeszcze pełnej konkurencyjności,

•    okres realizacji Projektu będzie niewiele krótszy niż 2 lata a umowa w okresie eksploatacji (trwałości) będzie min. 3 letnia, co pozwoli na uzyskanie niższej ceny na poziomie kwartalnym.

Utrzymanie systemu, asysta techniczna

Usługi w zakresie utrzymania systemu i asysty technicznej będą świadczone w miarę potrzeb, w ramach zamówionego limitu 2 000 roboczogodzin rocznie. Przy szacowanym koszcie 150 zł netto za roboczogodzinę, oznacza to roczny koszt utrzymania systemu i asysty technicznej na poziomie 300 000 zł netto (369 000 zł brutto).

Promocja i informacja, audyt bezpieczeństwa

W okresie trwałości Projektu przewidziano także nakłady niezbędne na zapewnienie informacji o usługach dostępnych na Platformie (72 000 zł netto / 88 560 zł brutto na działania informacyjno-promocyjne w internecie i środkach masowego przekazu) oraz coroczny audyt bezpieczeństwa, konieczny ze względu na wrażliwość przechowywanych danych (30 000 zł netto / 36 900 zł brutto.

8.5 Analiza ekonomiczno - finansowa

Celem zaprezentowanej analizy finansowej jest oszacowanie wysokości wydatków, jakie konieczne są do zabezpieczenia prawidłowej realizacji i funkcjonowania Projektu, zarówno w okresie jego realizacji, jak i w okresie świadczenia usług wdrożonych w ramach Projektu.

Analiza finansowa potwierdza, że planowane w ramach projektu wydatki są uzasadnione i racjonalne z punktu widzenia założonych celów i zakresu projektu. Prognozy finansowe projektu zostały przedstawione w formie sprawozdań finansowych: rachunku zysków i strat, rachunku przepływów pieniężnych oraz bilansu, zgodnych z Ustawą z dnia 29 września 1994 r. o rachunkowości.

Analiza finansowa opiera się na następujących założeniach:

•    analiza finansowa została przeprowadzona w oparciu o metodologię zdyskontowanego przepływu środków pieniężnych,

•    wartości finansowe zostały przedstawione w PLN, w cenach nominalnych,

•    podawane ceny towarów i usług są cenami brutto, ponieważ wnioskodawcynie nie mogą odzyskać podatku VAT,

•    w odniesieniu do stawek podatkowych (w tym podatku VAT) zastosowano ich bieżące wartości, zgodnie z odpowiednimi obowiązującymi przepisami,

•    stopę dyskontową dla analizy finansowej przyjęto na poziomie 4% (jednakową dla całego okresu referencyjnego),

•    stopę dyskontową dla analizy ekonomicznej przyjęto na poziomie 5% (jednakową dla całego okresu referencyjnego),

•    za rok obrotowy przyjęto rok kalendarzowy,

•    na potrzeby przeprowadzonej analizy przyjęto horyzont czasowy obejmujący 10-letni okres odniesienia, licząc or roku rozpoczęcia projektu, tj. lata 2017-2026,

•    analizę finansową przeprowadzono dla całego projektu oraz odrębnie dla każdego z partnerów,

•    w analizie nie uwzględniono rezerwy na nieprzewidziane wydatki.

Nakłady inwestycyjne

Nakłady inwestycyjne zostały oszacowane dla całego okresu realizacji Projektu, obejmującego etapy przygotowania, inicjowania i realizacji projektu. Podsumowanie nakładów inwestycyjnych projektu przedstawiono w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „SW wyniki", tabele „Nakłady inwestycyjne projektu w podziale na kategorie i podkategorie (w zł)" oraz „Nakłady inwestycyjne projektu - w podziale na zadania i kategorie (w zł)".

Pierwsza ze wskazanych tabel przedstawia wysokość wydatków w podziale na kategorie i podkategorie, zgodnie z wykazem wydatków kwalifikowalnych dla POPC, działanie 2.1, w tym:

1)    Środki trwałe i wartości niematerialne i prawne / Sprzęt informatyczny,

2)    Środki trwałe i wartości niematerialne i prawne / Oprogramowanie,

3)    Usługi zewnętrzne / Usługi informatyczne,

4)    Usługi zewnętrzne / Usługi wspomagające realizację projektu,

5)    Szkolenia,

6)    Informacja i promocja,

7)    Wynagrodzenia pracowników wykonujących merytoryczne zadania bezpośrednio związane z głównymi celami i produktami projektu,

8)    Wydatki poniesione na pokrycie kosztów pośrednich.

Natomiast tabela „Nakłady inwestycyjne projektu - w podziale na zadania i kategorie (w zł)" przedstawia wartość każdego z zadań w ramach realizacji projektu:

1)    Zadanie 1 Budowa i wdrożenie Platformy e-Zamówienia,

2)    Zadanie 2    Wsparcie w    realizacji    projektu,

3)    Zadanie 3    Szkolenia,

4)    Zadanie 4 Zakup sprzętu biurowego (multimedialnego i komputerowego),

5)    Zadanie 5    Promocja,

6)    Zadanie 6    Zarządzanie    i    obsługa    projektu,

7)    Koszty pośrednie,

wskazując dodatkowo w ramach jakich kategorii finansowane są wydatki w tych zadaniach.

Uzasadnienie wysokości nakładów inwestycyjnych przedstawiono w rozdziale 8.2.1 Analiza kosztów i korzyści.

Harmonogram rzeczowo-finansowy

Harmonogram rzeczowo-finansowy nakładów inwestycyjnych Projektu został przedstawiony w modelu analizy finansowej załączonym do wniosku o dofinansowanie. Wersja uproszczona HRF, pokazująca wydatki w podziale na lata, ujęta jest w zakładce „SW wyniki:, tabela: „Harmonogram rzeczowo-finansowy realizacji przedsięwzięcia w wartościach brutto (w zł)", natomiast pełna wersja harmonogramu rzeczowo - finansowego realizacji Projektu stanowi załącznik do Wniosku o Dofinansowanie.

Harmonogram rzeczowo-finansowy odzwierciedla założenia odnośnie wysokości nakładów opisane w rozdziale 8.2.1 Analiza kosztów i korzyści i jest spójny z analizą wykonalności technicznej.

Amortyzacja

Dla potrzeb analizy finansowej obliczono strumień amortyzacji przyjmując do szacunków nakłady na nowe środki trwałe, zakładając, że inwestycje zrealizowane w danym roku wchodzą na stan majątkowy rok później.

Zgodnie z wytycznymi dla projektów finansowanych ze środków europejskich w rachunku zysków i strat projektu uwzględnione zostaną odpisy amortyzacyjne ustalone metodą uproszczoną zgodnie z rozporządzeniem Ministra Finansów. Amortyzację ustalono metodą uproszczoną (od wartości brutto ponieważ beneficjent nie ma możliwości odzyskania podatku VAT od niniejszego projektu). Dla obliczenia amortyzacji przyjęto następujące stawki:

•    zakupione wartości niematerialne i prawne: oprogramowanie (licencje) - 50%,

•    wytworzone aktywa trwałe (oprogramowanie spec.) - 50%,

•    zakupione środki trwałe: zespoły komputerowe - 30%.

Z uwagi na fakt, iż po zakończeniu okresu referencyjnego większości inwestycji ma wciąż wartość, zwaną rezydualną, należy ją uwzględnić w analizie przepływów pieniężnych. Wartość aktywów trwałych projektu wyliczona na koniec horyzontu czasowego zwana wartością rezydualną inwestycji, obliczona została metodą księgowych odpisów amortyzacyjnych - wg następującej formuły:

(+) Wartość początkowa nakładów inwestycyjnych

(-) suma odpisów amortyzacyjnych dokonanych w okresie eksploatacji

(+) wartość nakładów odtworzeniowych

(-) suma odpisów amortyzacyjnych odtworzonego majątku dokonanych w okresie eksploatacji.

Plan amortyzacji w przyjętym okresie analizy (obejmującym przygotowanie projektu oraz okres odniesienia liczony jako 10 lat od podpisania umowy o dofinansowanie projektu), wraz z wyliczeniem wartości rezydualnej, przedstawiono w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „SW wyniki", tabela „Plan amortyzacji i wyliczenie wartości rezydualnej".

Nakłady odtworzeniowe

Na potrzeby niniejszej analizy przyjęto nakłady odtworzeniowe odpowiadające postępowi w zużyciu środków inwestycyjnych zakupywanych w ramach projektu. Zgodnie z tym założeniem, w miarę zużywania sprzętu (mierzonego postępem w amortyzacji), ponoszone są nakłady na jego odtworzenie.

Plan nakładów odtworzeniowych w przyjętym okresie analizy (obejmującym 10-letni okres odniesienia) przedstawiono w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „SW wyniki", tabela „Plan nakładów odtworzeniowych".

Prognoza przychodów i kosztów operacyjnych przedsięwzięcia

W przedmiotowym projekcie możliwe jest oddzielenie kosztów operacyjnych oraz nakładów inwestycyjnych związanych z projektem od ogólnego strumienia kosztów operacyjnych i nakładów inwestycyjnych beneficjenta. W związku z tym odpowiednim modelem analizy finansowej jest model prosty (analiza standardowa).

Projekt nie generuje przychodów operacyjnych. Koszty eksploatacyjne projektu, w tym: prognozowane koszty utrzymania i rozwoju usług i systemów teleinformatycznych objętych projektem, zostały skalkulowane na podstawie planowanych wydatków koniecznych do zapewnienia prawidłowego korzystania z projektu. W kalkulacji ujęto zmniejszenie kosztów utrzymania infrastruktury po stronie UZP, które zostanie uzyskane po wdrożeniu produkcyjnym Platformy, gdy UZP nie będzie dłużej ponosić kosztów utrzymania części obecnie istniejącej infrastruktury. Na dzień dzisiejszy, UZP ponosi łącznie koszt w wysokości 272 tys. zł na utrzymanie systemów informatycznych w tym:

•    BZP -um. 52/16 z POLCOM - 125 000 zł brutto,

•    Platforma Aukcji i Licytacji - 123 000 zł brutto,

• hosting - um. 39/15 - 24 000 zł brutto.

Koszty te przestaną być ponoszone przez UZP po wdrożeniu produkcyjnym Platformy, tj. od 2019 roku. W związku z powyższym, w analizie finansowej wykazano zmniejszenie kosztu społecznego, w wysokości 272 000 zł rocznie, od 2019 roku.

Przychody i koszty operacyjne projektu w okresie odniesienia przedstawiono w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „SW wyniki", tabela „Przychody i koszty operacyjne projektu".

Zapotrzebowanie na kapitał obrotowy - w okresie realizacji oraz eksploatacji projektu

Z uwagi na charakter przedmiotowego projektu nie dokonano kalkulacji zapotrzebowania na kapitał obrotowy. Projekt nie generuje przychodów i podatek VAT stanowi koszt kwalifikowany. W analizowanym projekcie zapotrzebowanie na kapitał obrotowy nie występuje.

Prognoza rachunku zysków i strat projektu

Prognoza rachunku zysków i strat opiera się na wcześniej określonych wartościach finansowych. Rachunek zysków i strat został przygotowany zgodnie z Ustawą z dnia 29 września 1994 r. o rachunkowości. Projekt nie jest projektem przynoszącym dochód.

Kluczowe wartości rachunku zysków i strat w okresie odniesienia zaprezentowane zostały w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „SW wyniki", tabela „Pro forma rachunek zysków i strat".

Prognoza rachunku przepływów pieniężnych projektu

Prognoza rachunku przepływów pieniężnych związanych z Projektem określa wielkości środków pieniężnych, które powinny być zabezpieczone przez Beneficjenta, aby jego realizacja nie stanowiła zagrożenia dla płynności finansowej. Ze względu na fakt, że Beneficjent jest jednostką administracji publicznej, w każdym roku koszt projektu, a następnie koszt utrzymania i rozwoju usług i systemów teleinformatycznych objętych projektem, jest pokrywany z zapotrzebowania na środki z budżetu państwa.

Z uwagi na brak konieczności sporządzania bilansu rachunek przepływów pieniężnych opracowano w sposób uproszczony.

Kluczowe wartości rachunku przepływów pieniężnych w okresie odniesienia zaprezentowane zostały w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „SW wyniki", tabela „Pro forma sprawozdanie z przepływów pieniężnych".

Podsumowanie analizy trwałości finansowej projektu

Projekt nie generuje dochodów i jest realizowany przez jednostkę sektora finansów publicznych, nie wykazuje więc efektywności finansowej typowej dla biznes planu. Celem analizy finansowej nie jest zatem określenie należnej wielkości dofinansowania. Ocena finansowej trwałości projektu służy określeniu wysokości wydatków, jakie są konieczne do zabezpieczenia prawidłowej realizacji i funkcjonowania projektu, zarówno w okresie realizacji projektu, jak i w okresie trwałości projektu.

Ocenę efektywności finansowej przeprowadzono dla każdego z analizowanych wariantów realizacji projektu. Analiza objęła oszacowanie finansowej efektywności inwestycji oraz kapitału przy pomocy wskaźników:

•    finansowa zaktualizowana wartość netto (FNPV/C), finansowa wewnętrzna stopa zwrotu

(FRR/C),

•    finansowa zaktualizowana wartość netto (FNPV/C), finansowa wewnętrzna stopa zwrotu

(FRR/C).

Finansowa zaktualizowana wartość netto inwestycji (FNPV(C)) i finansowa wewnętrzna stopa zwrotu z inwestycji (FRR(C)) porównują koszty inwestycji z dochodem i mierzą, w jakim stopniu z dochodów projektu można sfinansować inwestycję, bez względu na źródła lub metody finansowania.

Finansowa zaktualizowana wartość netto inwestycji stanowi sumę wynikającą z różnicy między zdyskontowaną wartością oczekiwanych przychodów a oczekiwanymi kosztami inwestycji i kosztami operacyjnymi projektu (zdyskontowanymi).

Finansową wewnętrzną stopę zwrotu z inwestycji definiuje się jako stopę dyskontową dającą FNPV o wartości zero.

Finansowa wartość bieżąca netto kapitału (FNPV(K)) stanowi sumę zdyskontowanych przepływów pieniężnych netto na rzecz beneficjentów krajowych (łącznie publicznych i prywatnych) z tytułu realizacji projektu. Odpowiednia finansowa stopa zwrotu z kapitału (FRR(K)) z tytułu tych przepływów określa zwrot z kapitału ujęty w punktach procentowych.

W obliczeniach FNPV(K) i FRR(K) uwzględniane są wszystkie źródła finansowania, z wyjątkiem wkładu UE.

Oszacowanie trwałości finansowej projektu przedstawiono w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „SW wyniki", tabele „Finansowa efektywność inwestycji" oraz „Finansowa efektywność kapitału". Dla przyjętej stopy dyskontowej na poziomie 4%, wartości wskaźników wynoszą odpowiednio:

•    finansowa zaktualizowana wartość netto z inwestycji (FNPV/C): -67 100 444 zł,

•    finansowa wewnętrzna stopa zwrotu z inwestycji (FRR/C): -- brak wyniku ,

•    finansowa zaktualizowana wartość netto z kapitału (FNPV/K): -67 100 444 zł,

•    finansowa wewnętrzna stopa zwrotu z kapitału (FRR/K): brak wyniku,

Dla wskaźnika „Finansowa wewnętrzna stopa zwrotu z kapitału (FRR/K)" formuła zwraca błąd, ponieważ przy danym szeregu czasowym funkcja nie ma rozwiązania.

Uzyskane wyniki świadczą, że przedmiotowy projekt nie może być rozpatrywany w kategoriach projektów komercyjnych. Niemniej jednak ujemna wartość FNPV nie oznacza, że dany projekt nie powinien zostać zrealizowany - uzasadnieniem dla realizacji projektu jest jego opłacalność w kategoriach społecznych, co wykazano poniżej.

Analiza ekonomiczna (analiza kosztów i korzyści społecznych)

Przeprowadzona analiza finansowa wykazała, że przedmiotowy projekt jest przedsięwzięciem nieopłacalnym, gdyby oceniać go wyłącznie w perspektywie wskaźników efektywności finansowej. Niemniej jednak, projekty o takim charakterze należy także ocenić w perspektywie ich oddziaływania społecznego. Dla potrzeb przedmiotowego projektu analiza kosztów i korzyści społecznych została przygotowana przy wykorzystaniu jakościowej i ilościowej ekonomicznej analizy kosztów i korzyści.

Ekonomiczną analizę kosztów i korzyści projektu, przeprowadzono przy następujących założeniach:

•    analizę przeprowadzono w złotych polskich dla okresów rocznych,

•    do wyznaczenia wskaźników opłacalności wykorzystano metodologię zdyskontowanych przepływów środków pieniężnych (DCF),

•    na potrzeby przeprowadzonej analizy przyjęto horyzont czasowy obejmujący 10 lat, analogicznie do analizy finansowej

•    do szacowania ekonomicznych strumieni pieniężnych przyjęto kalkulację w cenach stałych (nie uwzględniono wpływu inflacji na poziom cen),

•    do ustalenia wartości bieżącej przepływów pieniężnych przyjęto stopę dyskontową stosowaną dla analizy ekonomicznej, na poziomie 5%,

•    wyznaczono następujące wskaźniki ekonomicznej efektywności:

o ekonomiczna wartość bieżąca netto (ENPV), o ekonomiczna wewnętrzna stopa zwrotu (ERR), o relacja Korzyści do Kosztów (B/C).

Główne korzyści z realizacji projektu określone zostały w rozdziale 4.3 Korzyści społeczne. Część spośród tak zdefiniowanych korzyści jest trudna do zwymiarowania, czy to ze względu na ich jakościowy charakter (np. podniesienie poziomu bezpieczeństwa) czy trudność w określeniu danych (w szczególności poziomu bazowego). Niemniej jednak, na potrzeby oceny analizowanych wariantów dokonano próby zwymiarowania części ze zdefiniowanych korzyści, w tym:

1)    Ograniczenie czasu potrzebnego na przygotowanie ogłoszeń, dokumentów zamówienia oraz ich aktualizację

2)    Ograniczenie czasu potrzebnego na opracowanie raportów (sprawozdawczość dla UZP)

3)    Ograniczenie czasu potrzebnego na dostęp do i analizę raportów (po stronie UZP)

4)    Oszczędność kosztów składania ofert (po stronie Zamawiających)

Ad. 1) Ograniczenie czasu potrzebnego na przygotowanie ogłoszeń, dokumentów zamówienia oraz ich aktualizację.

Na potrzeby oszacowania wartości korzyści przyjęto docelowy zakres oddziaływania rocznie na poziomie 125 tys. postępowań. Jeżeli przyjmiemy, że po stronie Zamawiającego, oszczędność czasu potrzebnego na przygotowanie ogłoszeń, dokumentów zamówienia oraz ich aktualizację, uzyskana dzięki możliwości ponownego skorzystania z raz wprowadzonych danych, wyniesie nawet godzinę na jedno zamówienie (tj. 1/8 dnia roboczego), to przy przeciętnym wynagrodzeniu brutto urzędnika (wg. GUS) na poziomie 3 690 miesięcznie, łączna docelowa wartość korzyści w skali roku wyniesie 3 093 750 zł.

Ad. 2) Ograniczenie czasu potrzebnego na opracowanie raportów (sprawozdawczość dla UZP)

Na potrzeby oszacowania wartości korzyści przyjęto docelową liczbę zamawiających, którzy skorzystają z usługi sprawozdawczości elektronicznej na poziomie 35 000 rocznie. Jeżeli przyjmiemy, że po stronie Zamawiającego, oszczędność czasu potrzebnego na opracowanie raportów (sprawozdawczość dla UZP), uzyskana dzięki możliwości skorzystania z usługi sprawozdawczości dla UZP, wyniesie nawet 3/4 dnia roboczego rocznie, to przy przeciętnym wynagrodzeniu brutto urzędnika (wg. GUS) na poziomie 3 690 miesięcznie, łączna docelowa wartość korzyści w skali roku wyniesie 5 197 500 zł.

Ad. 3) Ograniczenie czasu potrzebnego na dostęp do i analizę raportów (po stronie UZP)

Analogicznie, jeżeli przyjmiemy, że po stronie UZP, oszczędność czasu potrzebnego na dostęp do do danych uzyskanych dzięki automatyzacji pozyskiwania danych oraz ich standaryzację (zamiast dotychczasowych sprawozdań ), wyniesie nawet 1/10 dnia roboczego rocznie, to przy przeciętnym wynagrodzeniu brutto urzędnika (wg. GUS) na poziomie 3 690 miesięcznie, łączna docelowa wartość korzyści w skali roku wyniesie 693 000 zł.

4) Oszczędność kosztów składania ofert (po stronie Zamawiających)

Na potrzeby oszacowania wartości korzyści przyjęto docelowy zakres oddziaływania rocznie na poziomie 125 tys. postępowań, przy czym średnia liczba ofert w postępowaniu kształtuje się na poziomie 2,7 szt. Jeżeli przyjmiemy, że 30% z tych ofert jest dostarczanych z wykorzystaniem usługi kuriera (średnia opłata rzędu 50 zł za przesyłkę do 1 kg, dostarczoną do 12:00), podczas gdy pozostałe są dostarczane jako przesyłka polecona z poświadczeniem odbioru bądź samodzielnie (dla obydwu wariantów przyjęto koszt dostarczenia przesyłki do 1 kg zgodnie z cennikiem Poczty Polskiej, gdyż nawet w przypadku samodzielnego dostarczenia oferty należy liczyć się z kosztem związanym z zużyciem paliwa lub opłata za przejazd komunikacją miejską plus kosztem czasu pracownika który dostarczy ofertę), wówczas , łączna docelowa wartość korzyści w skali roku wyniesie 7 188 750 zł.

Projekt nie generuje dodatkowych kosztów społecznych, poza kosztami ujętymi w analizie finansowej, tj. nakładami inwestycyjnymi w trakcie realizacji projektu oraz kosztami eksploatacyjnymi w okresie następującym po zakończeniu realizacji projektu. W analizie uwzględniono wszystkie właściwe kategorie kosztów, zarówno w okresie realizacji projektu, jak i po jego zakończeniu.

W analizie uwzględniono wszystkie fazy cyklu życia tworzonych lub rozwijanych usług, tj:

•    A+P - Analiza i Projektowanie

•    B - Budowa

•    B+W - Budowa i Wdrożenie

•    W - Wdrożenie

•    Ś - Świadczenie

Szczegółowe obliczenia ekonomicznych przepływów pieniężnych oraz uzyskane wyniki dla analizowanych wariantów przedstawiono w modelu analizy finansowej załączonym do wniosku o dofinansowanie, zakładka „SW wyniki", tabele „Ekonomiczna analiza kosztów i korzyści - ENPV i ERR" oraz „Ekonomiczna analiza kosztów i korzyści - B/C".

Obliczone w ramach ekonomicznej analizy kosztów i korzyści wskaźniki, mają odpowiedzieć na pytanie, czy projekt jest opłacalny ze społecznego punktu widzenia. W tym celu dla każdego z wariantów oszacowano następujące wskaźniki efektywności ekonomicznej:

•    ekonomiczna zaktualizowana wartość netto (ENPV) - różnica między zdyskontowanymi całkowitymi korzyściami i kosztami społecznymi,

•    ekonomiczna wewnętrzna stopa zwrotu (ERR) - stopa dająca wartość zerową dla ENPV,

•    ekonomiczny wskaźnik Korzyści/Koszty (B/C) - tj. iloraz sumy zdyskontowanych korzyści ekonomicznych i sumy zdyskontowanych kosztów.

Wartość ENPV powinna dla całości zaangażowanego kapitału osiągnąć wartość dodatnią, a EIRR - wyższą od przyjętej stopy dyskonta.

Dla przyjętej stopy dyskontowej na poziomie 5%, wartości wskaźników wynoszą odpowiednio:

•    ekonomiczna zaktualizowana wartość netto (ENPV): 20 341 763 zł,

•    ekonomiczna wewnętrzna stopa zwrotu (ERR): 33,47 %,

•    ekonomiczny Wskaźnik Korzyści/Koszty (B/C): 1,40.

Wyniki analizy wskazują jednoznacznie że analizowane przedsięwzięcie jest pozytywne w perspektywie społecznej. Ekonomiczna zaktualizowana wartość netto (ENPV) jest wyższa od zera, a oczekiwane korzyści dwukrotnie przewyższają konieczne do poniesienia nakłady inwestycyjne i utrzymaniowe. Także wewnętrzna stopa zwrotu znacznie przekracza przyjętą stopę dyskontową.

9 Zarządzanie projektem

9.1    Metoda i przebieg realizacji Projektu

9.1.1    Metoda prowadzenia Projektu

Do zarządzania Projektem wykorzystane zostaną założenia metodyki Prince2:    2009,

poszczególne produkty natomiast będą realizowane przy wykorzystaniu metodologii zwinnej SCRUM - przy założeniu, że rynek nie będzie w stanie zapewnić gotowego rozwiązania. W realizacji Projektu zastosowane będą wnioski z analizy przeprowadzonej przez CPPC - Opinia prawna w sprawie możliwości i sposobu wykorzystania metodyki Agile (SCRUM) w projektach informatycznych realizowanych z zastosowaniem ustawy - Prawo zamówień publicznych.

Dodatkowo należy stwierdzić w oparciu o opinie CPPC z dnia 30 listopada 2016 r. pn.: Opinia prawna w sprawie możliwości i sposobu wykorzystania metodyki Agile w projektach informatycznych realizowanych z zastosowaniem ustawy - Prawo zamówień publicznych, iż aktualna regulacja polskiej ustawy prawo zamówień publicznych przewiduje szereg mechanizmów pozwalających na realizacje projektów IT w sektorze publicznym zgodnie ze zwinnymi metodykami wytwarzania i zarządzania projektami informatycznymi.

Głównym zwinnym elementem projektu będzie Product Backlog dla poszczególnych produktów. Na liście Product Backlog znajdować się będą wszystkie przyszłe funkcjonalności wskazanych systemów, które w miarę rozwoju projektów będą doprecyzowywane w ramach procesu uszczegółowiania (Refinement).

Dokumentacja Projektu będzie przechowywana w sposób pozwalający na integrację ze zbudowaną w chmurze Platformą.

Fazy poszczególnych projektów zostaną podzielone na miesięczne Sprinty w ramach, których zespół będzie pracować nad osiągnięciem konkretnych celów zdefiniowanych na początku każdego Sprintu. Zadania w sprincie muszą być opisane z perspektywy członków zespołu oraz posiadać kryteria akceptacji. Sprint rozpoczyna się spotkaniem planującym, a kończy spotkaniem podsumowującym połączonym z przekazaniem efektów prac.

Faza testowania oprogramowania będzie nierozłącznie związana z wytwarzaniem oprogramowania.

Projekt nastawiony jest na osiągnięcie korzyści jako mierzalnej poprawy, osiągniętej dzięki rezultatowi, będącemu efektem zmiany spowodowanej wykorzystaniem wyników, produktów wykonania Umowy. W związku z tym metodyka zarządzania wykonaniem Umowy będzie w tym celu uwzględniać także elementy metodyki MSP (Managing Successful Programmes), szczególnie w celu zbudowania dającego się zarządzać środowiska programu, utrzymania go oraz zapewnienia sposobu w jaki program powinien współpracować ze swoimi projektami oraz z władzą wyższą w organizacji.

9.1.2 Metoda prowadzenia Projektu

Organizacja wdrożenia

Lider Projektu

Zasady współpracy stron reguluje zawarta Umowa Partnerska.

Odpowiedzialność Lidera Projektu obejmuje:

1)    koordynacji przygotowania realizacji i realizacji Projektu;

2)    reprezentowania Stron przed Instytucją Pośredniczącą;

3)    złożenia Wniosku o dofinansowanie Projektu;

4)    zawarcia w imieniu i na rzecz Stron Umowy o dofinansowanie Projektu, w wypadku wybrania Projektu do finansowania;

5)    zarządzania Projektem, zgodnie z obowiązującą u Lidera Partnerstwa metodyką zarządzania projektami w tym: koordynowania, dokumentowania, monitorowania i nadzorowania prawidłowości realizacji zadań w ramach Projektu, wykonywanych przez Strony;

6)    przeprowadzenia i udzielenia zamówień publicznych

7) przygotowania dokumentacji przetargowej, w tym opracowania Opisu Przedmiotu zamówienia przy merytorycznym wsparciu Partnera w zakresie wymagań funkcjonalnych, wytycznych dotyczących wymagań niefunkcjonalnych w zakresie bezpieczeństwa, SLA, wydajności platformy elektronicznych zamówień lub innych niezbędnych informacji merytorycznych służących do opracowania dokumentacji przetargowej;

8) zapewnienie prawidłowości operacji finansowych, w szczególności poprzez wdrożenie systemu zarządzania i kontroli finansowej Projektu;

9)    przedkładania wniosków o płatność do Instytucji Pośredniczącej celem rozliczenia wydatków w Projekcie;

10)    gromadzenia w niezbędnym zakresie informacji o uczestnikach Projektu i ich przekazywania do Instytucji Pośredniczącej;

11)    informowania Instytucji Pośredniczącej o problemach w realizacji Projektu;

12)    udostępnianie Partnerowi informacji i dokumentów niezbędnych do wykonania ich obowiązków w ramach realizacji Projektu będących w posiadaniu Lidera Partnerstwa i możliwych do udostępnienia oraz uzgadnianie treści dokumentów przedkładanych do Instytucji Pośredniczącej.

Organizacja wewnętrzna Projektu

1)    W celu prawidłowej realizacji Partnerstwa powołuje się Komitet Sterujący Projektu oraz Kierownika Projektu.

2)    Partnerzy powołują Komitet Sterujący, którego zadaniem jest podejmowanie decyzji natury strategicznej związanych z działalnością Partnerstwa

3)    Do kompetencji Komitetu Sterującego należą:

1)    wszystkie sprawy o znaczeniu strategicznym dla realizacji Projektu;

2)    opracowanie i zatwierdzenie planu ratowniczego dla Projektu w przypadku jego zagrożenia;

3)    rozstrzyganie konfliktów pomiędzy Liderem Projektu a Partnerem

4)    Kierownik Projektu odpowiada za:

1)    bieżące zarządzanie i administrowanie Projektem;

2)    zarządzanie finansami i przygotowywanie odpowiedniej dokumentacji w związku z realizacją Projektu, w tym przedkładania Wniosków o płatność;

3)    utrzymywanie kontaktów z Komitetem Sterującym, informowanie go o postępach prac oraz innych ważnych sprawach dotyczących realizacji Projektu;

4)    monitorowanie prac nad przygotowaniem i realizacją Projektu;

5) zbieranie i identyfikowanie potencjalnych problemów i zagrożeń dla realizacji Projektu, jakie powinny zostać rozpatrzone przez Komitet Sterujący;

6)    zapewnienie sprawnego systemu komunikacji pomiędzy uczestnikami Partnerstwa;

7) pozyskiwanie, gromadzenie i archiwizację dokumentacji związanej z realizacją Projektu;

8)    nadzór i kontrolę przestrzegania zgodności realizacji Projektu z Wytycznymi oraz przepisami prawa;

9)    nadawanie kształtu, zasad i zakresu polityki promocyjnej Projektu;

10)    nadawanie kierunku prac, tak aby zapewnić odpowiedni postęp prac;

11)    inicjowanie niezbędnych zmian w budżecie Projektu skutkujących zmianą Umowy o dofinansowanie Projektu;

12)    inicjowanie niezbędnych zmian w alokacji prac pomiędzy uczestnikami Partnerstwa.

Pierwszym istotnym krokiem będzie przygotowanie Dokumentacji Inicjującej Projekt obejmującego:

1.    Uzasadnienie biznesowe,

2.    Strategia zarządzania jakością,

3.    Strategia zarządzania komunikacją,

4.    Strategia zarządzania ryzykiem,

5.    Strategia zarządzania konfiguracją,

6.    Plan projektu,

7.    Plan etapu,

8.    Opis Produktu końcowego i produktów,

9.    Plan przeglądu korzyści,

10.    Rejestry, które zakładane są w trakcie etapu inicjowania projektu

a.    Rejestr Ryzyka,

b.    Rejestr Zmian,

c.    Rejestr Zagadnień,

d.    Rejestr Jakości,

e.    Plan Jakości Projektu,

f.    Plan Komunikacji,

g.    Plan Etapów,

h.    Raport Końcowy Etapu,

i.    Raport Realizacji Projektu,

j.    Rejestr Doświadczeń.

Wszystkie dokumenty będą przygotowywane zgodnie z ustalonym schematem a następnie zatwierdzone przez Komitet Sterujący.

Komunikacja w Projekcie

Plan Komunikacji będzie szczegółowo opisany zarówno sposób komunikacji w Projekcie, jak i przedmiot komunikacji określający, co, kiedy i przez kogo ma podlegać przedmiotowi komunikacji. Plan komunikacji zostanie zdefiniowany, wdrożony i utrzymywany przez cały okres realizacji i wdrażania projektu. Plan komunikacji projektu będzie:

1.    definiował wszystkich interesariuszy procesu komunikacji,

2.    określał zakres uczestnictwa interesariuszy,

3.    zawierał zakres udostępnianych informacji,

4.    opisywał sposób, format dostarczania informacji w procesie komunikacji,

5.    określał dostawców informacji,

Struktura organizacyjna Projektu:

•    Komitet Sterujący - nadzorujący całość prac,

•    Komitet ds. zmian

•    Kierownik Projektu,

•    Kierownicy Zespołów:

•    ze strony Partnera,

•    ze strony Wykonawcy,

•    Zespoły Zadaniowe obejmujące wyznaczonych pracowników Lidera i Partnera oraz konsultantów i przedstawicieli Wykonawcy odpowiedzialne za wytworzenie określonych produktów

Wybór wykonawców robót, dostaw i usług realizujących zadania w Projekcie będzie dokonywany zgodnie z obowiązującą ustawą PZP, co wypełnia zasadę obowiązującą w Unii Europejskiej stosowania odpowiedniego ustawodawstwa krajowego w odniesieniu do wydatkowania środków z funduszy wspólnotowych.

Ministerstwo Cyfryzacji wdrożyło system zarządzania portfelem projektów, którego głównymi celami są:

-    zapewnienie koordynacji projektów realizowanych przez Ministerstwo Cyfryzacji,

-    zapewnienie nadzoru nad projektami realizowanymi w Ministerstwie Cyfryzacji,

-    ukierunkowanie projektów na realizację celów strategicznych,

-    standaryzacja procesów zarządzania projektami w Ministerstwie Cyfryzacji.

Zasady zarządzania portfelem projektów w MC zostały określone w Zarządzeniu Ministra Cyfryzacji z dnia 24 października 2016 r. w sprawie zatwierdzania projektów do realizacji oraz sposobu organizacji zarządzania projektami. Przygotowywanie, inicjowanie, realizacja i zamykanie projektów odbywa się zgodnie z przepisami ww. zarządzenia.

9.1.3 Przebieg realizacji Projektu

9.1.4 Przebieg realizacji Projektu

Projekt będzie realizowany od 2017-10-01 do 2020-03-31

Szczegółowy harmonogram projektu z wykresem Gantta stanowi załącznik Nr 8 do Wniosku o Dofinansowanie.

Poniżej przedstawiono kamienie milowe Projektu

9.1.5 Zadania Projektu

Zadania zaplanowane w Projekcie podzielono na 6 kategorii. Każde z nich ma swoją specyfikę ze względu na przedmiot działań lub cel.

Zadanie 1 Budowa i wdrożenie Platformy e-Zamówienia

Zadanie w sposób bezpośredni odnosi się do celu Projektu - jego rezultatem jest wytworzenie głównego Produktu przedsięwzięcia. Zadanie to obejmie szereg działań, począwszy od przygotowania szczegółowych Założeń rozwiązań systemu poprzez Wypracowanie standardów usług i danych (w oparciu o prace przygotowawcze już rozpoczęte), a skończywszy na udostępnieniu modułów i usług Platformy. Zadanie obejmuje też wykonanie Komponentu edukacyjnego i jego wdrożenie oraz testy i odbiory produktów z audytem bezpieczeństwa informacji. Szczegółowy opis produktów wytworzonych w ramach zdania 1 zawiera rozdział 6.1.2 Studium Wykonalności pt. Opis funkcjonalności, natomiast poszczególne kroki w działaniach i ich kolejność obrazuje szczegółowy Harmonogram, stanowiący załącznik do SW.

Zadanie 2 Wsparcie w realizacji projektu

Realizacja zadania gwarantuje ciągły ekspercki nadzór nad przebiegiem prac projektowych, wdrożeniowych, testów zapewniając wysoką jakość wytwarzanych Produktów, ich zgodność z założeniami oraz efektywność działań, a tym samym przyczyni się do osiągnięcia wskaźników produktu i rezultatu bezpośredniego. Bezstronność i obiektywność wykonawców w tym zadaniu zostanie zagwarantowana przez wybór niezależnego od Wykonawcy Platformy podmiotu w postępowaniu o udzielenie zamówienia publicznego.

Zadanie 3 Szkolenia

Zadanie obejmuje szereg działań, których celem jest zapewnienie kompetencji zespołów zajmujących się realizacją Projektu oraz jego odbiorców. Przewidziano zarówno podnoszenie kompetencji zarządczych i technologicznych zespołów projektowych, jak również stałe podnoszenie kompetencji jak największej grupy potencjalnych odbiorców Platformy poprzez wytworzenie i udostępnienie multimedialnych materiałów instruktażowych, jak i organizację seminariów / konferencji dla szerokiego grona użytkowników merytorycznych.

Efektywne i realizowane w sposób ciągły działania w zadaniu Szkolenia umożliwią uzyskanie szerokiego i kompetentnego grona odbiorców Produktów, a tym samym przyczynią się do realizacji celów Projektu.

Zadanie 4 Zakup sprzętu biurowego (multimedialnego i komputerowego)

Realizacja zadania zapewni sprzęt niezbędny do efektywnego działania zespołu projektowego, umożliwi sprawną komunikację w Projekcie i wytworzenie profesjonalnych, zgodnych ze standardami dokumentów w odpowiednich formatach, co zagwarantuje jednoznaczność przekazywanych informacji wykonawcom, ekspertom, itp.

Zadanie 5 Promocja

Zaplanowanie działań promocyjnych równolegle z zawarciem umowy na wykonanie Zadania 1 pozwoli na poszerzenie kręgu potencjalnych użytkowników zewnętrznych. Realizacja zadania w powiązaniu z działaniami z Zadania 3 przyczyni się do osiągnięcia wskaźników Projektu.

Zadanie 6 Zarządzanie i obsługa Projektu

Działania podejmowane w zadaniu zapewnią ciągły nadzór i komunikację oraz elastyczność i szybką reakcję na zmieniające się uwarunkowania w trakcie realizacji Projektu oraz śledzenie wskaźników stopnia realizacji celów. Przyjęte metodyki prowadzenia Projektu i wytwarzania produktów, pozwolą w sposób najbardziej efektywny osiągnąć zakładane cele w terminach zaplanowanych w harmonogramie. Dodatkowo powołanie do Zespołu projektowego osób o wysokich kompetencjach i doświadczeniu przyczyni się do sprawnej realizacji zaplanowanych zadań.

9.2 Analiza i monitorowanie ryzyka

Ryzyka wpływające na realizację projektu

Ryzyka wpływające na utrzymanie efektów

Szanse

Niepożądane skutki (negatywne rezultaty)

9.3 Promocja Projektu

Odpowiednio z wytycznymi oznaczone zostaną znakiem UE oraz znakiem FE:

•    wszystkie dokumenty publikowane przez beneficjenta tj. dokumentacja przetargowa, ogłoszenia, analizy, raporty, wzory umów, wzory wniosków;

•    wszystkie dokumenty i materiały przeznaczone dla uczestników projektu tj. zaświadczenia, certyfikaty, zaproszenia, materiały informacyjne, programy szkoleń, listy obecności, prezentacje multimedialne, umowy, korespondencja;

•    wszystkie inne działania promocyjne, jeżeli zostaną w projekcie wykorzystane tj. ulotki, broszury, publikacje, notatki prasowe, strony internetowe, materiały filmowe, materiały promocyjne, konferencje, spotkania.

Ponadto dokumenty będą miały loga Lidera oraz Partnera a także inne informacje wymagane wytycznymi czy stosowane zgodnie z dobrym praktykami.

Zgodnie z wytycznymi miejsce realizacji projektu zostanie oznaczone tablicą informacyjną. Jej wielkość to min. 80x120 cm a treść będzie zawierała:

-    nazwę beneficjenta,

-    tytuł projektu,

-    cel projektu,

-    zestaw logo - znaki EFRR i UE,

-    adres portalu www.mapadotacji.gov.pl.

Przewiduje się wykonanie tablicy informacyjnej z możliwie najlepszych jakościowo i najtrwalszych materiałów, aby posłużyła także jako tablica pamiątkowa w okresie trwałości Projektu.

Beneficjent posiada własną stronę internetową, na której umieszczone zostaną zgodnie z wytycznymi informacje nt. Projektu:

-    znak Unii Europejskiej,

-    znak Funduszy Europejskich,

-    krótki opis projektu: cele projektu, planowane efekty, wartość projektu, wkład Funduszy Europejskich.

Informacja o dofinansowaniu projektu będzie także obecna wizualnie i przekazywana osobom i podmiotom uczestniczącym w projekcie podczas wszelkich innych działań, takich jak: konferencje, warsztaty, szkolenia. Oznakowanie będzie mieć formę np. plansz informacyjnych, plakatów lub stojaków itp.

Kampania informacyjno-promocyjna projektu będzie realizowana w oparciu o wytyczne dla okresu programowania UE 2014-2020. Działania informacyjno-promocyjne będą odpowiednio koordynowane i prowadzone przez delegowane komórki organizacyjne Beneficjenta.

Działania informacyjne i promocyjne prowadzone w ramach Projektu będą także dokumentowane w postaci elektronicznej.

Zaplanowano w Projekcie wyłonienie Wykonawcy, który będzie wykonywał szereg prac związanych z promocją Projektu. Poniżej zaprezentowano główne działania promocyjne zaplanowane w Projekcie:

Działania promocyjne zaplanowane w Projekcie

Koszty promocji zostały określone w oparciu o rozeznanie rynku oraz analizę kosztów w podobnych działaniach realizowanych przez Wnioskodawcę oraz inne podmioty administracji rządowej.

Kampania informacyjna i promocyjna projektu będzie uwzględniać specyfikę odbiorców i produktów tworzonych w Projekcie i nakierowana będzie użytkowników końcowych korzystających z udostępnianych danych lub informowanie o możliwościach systemu dla osób dotąd nie korzystających z udostępnianych informacji. Szczegółowy projekt kampanii promocyjnej i informacyjnej będzie uwzględniał wymagania promowania Projektu, Programu Operacyjnego Polska Cyfrowa oraz funduszy europejskich poprzez środki reklamy wizualnej.

10 Analiza techniczna

10.1Planowana architektura rozwiązania 10.1.1Sposób realizacji Projektu

Poniżej przedstawiono kluczowe elementy i założenia projektu mające istotny wpływ na sposób jego realizacji:

1.    Nie przewiduje się zakupu infrastruktury sprzętowej (serwerowej) wraz systemami operacyjnymi, bazami danych oraz systemem kopii zapasowych, niezbędnej do eksploatacji Platformy e-Zamówienia (planowane jest wykorzystanie infrastruktury zewnętrznego dostawcy - usługa hostingu).

2.    Platforma e-Zamówienia będzie własnością Beneficjenta.

3.    Serwis, utrzymanie i administrowanie Platformą e-Zamówienia będzie realizował wykonawca Platformy lub jego podwykonawca w okresie gwarancji, później wyłoniony w postępowaniu o udzielenie zamówienia publicznego wykonawca - operator/administrator Platformy).

4.    Wykonawca wyłoniony w postępowaniu na zakup i wdrożenie Platformy e-Zamówienia, w ramach pierwszego etapu prac opracuje projekt , obejmujący ostateczne rozwiązania w zakresie technicznym i logicznej budowie systemu. Pozwoli to zapewnić realizację wymagań opisanych w Studium Wykonalności, w tym dla infrastruktury teleinformatycznej, które zostaną doprecyzowane w SIWZ.

5.    Administratorzy merytoryczni UZP i techniczni MC będą administrowali Platformą w zakresie wynikającym z przyjętej polityki bezpieczeństwa i zadań.

6.    Instancja służąca m.in. zabezpieczeniu logów, generowania i dostawy kluczy prywatnych służących do odszyfrowania ofert w momencie upłynięcia terminu ich otwarcia będzie oddzielona od głównej instancji i administrowana przez MC (do rozważenia na etapie tworzenia SIWZ wymóg na innego dostawcę hostingu dla tej instancji).

7.    Zapewnienie niezależności pomiędzy dysponowaniem prawami do Platformy (oprogramowania), a korzystaniem z konkretnej infrastruktury, w ramach której Platforma e-Zamówienia jest wdrożona. Oznacza to, że na etapie tworzenia istotnych postanowień umowy, zostaną zawarte wymagania, które zagwarantują Beneficjentowi, że prawa do Platformy e-Zamówienia jak i danych, wraz z ich strukturą, będą własnością Beneficjenta. Zapisy umowy na dostawę i wdrożenie Platformy e-Zamówienia, zapewnią nieodpłatne udostępnienie wszystkich niezbędnych składników Platformy e-Zamówienia, w celu jej przeniesienia (migracji) do nowego dostawcy usług hostingowych.

8.    Zapewnienie majątkowych praw autorskich do Platformy e-Zamówienia w celu umożliwienia powierzenia jej rozbudowy lub modyfikacji innemu wykonawcy, wybranemu w ramach kolejnego postępowania.

9.    Interoperacyjność zastosowanych rozwiązań (KRI, EIF, standardy danych, itp.).

10.    Zgodność z obowiązującym prawem (w szczególności dot. ochrony danych osobowych oraz tajemnicy przedsiębiorstwa, ustawy o informatyzacji, ustawy o świadczeniu usług drogą elektroniczną itp.).

10.2Standardy architektoniczne i technologiczne 10.2.1Architektura systemu

Platforma zbudowana będzie w oparciu o mikroserwisy - SOA wprowadzone już na poziomie Architektury. Każdy z mikroserwisów będzie niezależny od pozostałych i jedynym miejscem styku pomiędzy serwisami będzie API, definiowane jako kombinacja URI, metod http i formatu oraz struktury przesyłanych danych. Mikroserwisy komunikują się ze sobą za pomocą protokołu http lub kolejek zgodnych AMPQ (funkcje obsługiwane przez kolejki muszą być nadal dostępne w API). Mikroserwisy są modyfikowane i wdrażane niezależnie od siebie. Każdy z mikroserwisów jest modyfikowany, instalowany i zarządzany niezależnie od pozostałych.

Oprogramowanie wytwarzane będzie z wykorzystaniem podejścia Continuous Integration (CI) i Continuous Deployment.

10.2.1.1 Informacje o API

Kluczowym elementem modelu jest standardowy interfejs API, który umożliwia interakcję pomiędzy Repozytorium i platformami, jak również komunikację z interesariuszami procesu.

1.    API poszczególnych części Platformy powinno być zgodne z wytycznymi REST i ułatwić współpracę komponentów napisanych w różnych językach programowania i frameworkach.

2.    API powinno składać się z URI, metod http (wykorzystywanych zgodnie z protokołem -nadmierne wykorzystanie lub ograniczenie się jedynie do metod GET i POST jest niedopuszczalne) i danych.

3.    Obiekty przesyłane do i z API powinny być w formacie JSON, a pliki z odpowiadającym im typem MIME (dopuszczalne uogólnienie to octet-stream).

4.    Format przesyłanych danych lub budowa API nie może wymuszać po stronie klienta ograniczenia do jednego konkretnego języka programowania ani biblioteki lub framework'a.

Standardowy, udostępniony publicznie interfejs API umożliwia interakcję pomiędzy Repozytorium i platformami, jak również komunikację z interesariuszami procesu i wszystkimi zainteresowanymi podmiotami.

Podczas przeprowadzania postępowań o udzielenie zamówienia publicznego platformy współpracujące e-Zamówienia będą używały API do:

•    przekazywania w obie strony danych o ofertach i oferentach;

•    przekazywania danych z określonych dokumentów powstających w procesie;

•    przekazywania w obie strony metadanych o zdarzeniach w procesie;

•    autentykacji i pobierania kluczy;

•    przekazywania zaszyfrowanych ofert.

Natomiast wszystkie zainteresowane podmioty będą mogły pobierać:

•    Metadane (ustrukturyzowane informacje o danych, zdarzeniach, dokumentach powstających w procesach postępowań o udzielenie zamówienia publicznego) zgodnie zakresem uprawnień;

•    Dane ze wszystkich ogłoszeń (powyżej i poniżej progów unijnych).

•    Wybrane ustrukturyzowane dane z SIWZ (wymagane opracowanie formularzy);

•    Dane z otwarcia ofert / wniosków;

•    Dane z protokołu z postępowania (co umożliwi rezygnację z rocznych sprawozdań);

•    Wybrane ustrukturyzowane dane z umów i ich aneksów (wymagane opracowanie formularzy);

•    Wybrane ustrukturyzowane dane z Planu Zamówień (wymagane opracowanie formularzy).

10.2.1.2 Sprawdzenie zgodności z WCAG 2.0

Interfejs aplikacji będzie spełniał zalecenia WCAG 2.0 na poziomie AA oraz normę EN 301 549 V1.1.2 (2015-04). Sprawdzenie poziomu dostępności interfejsów i treści systemów informatycznych zostanie przeprowadzone audytem eksperckim specjalistów w zakresie dostępności stron a także poprzez testy interfejsu prowadzone przez wyselekcjonowaną grupę użytkowników końcowych (w ramach testów akceptacyjnych rozwiązania). Wynikiem audytu będzie lista elementów standardu WCAG 2.0, wskazanych w załączniku nr 4 do Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, wraz z określeniem poziomu spełnienia wymagań co najmniej na poziomie wskazanym w rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (tekst jedn. Dz.U. z 2016 r., poz. 113).

W trakcie projektowania interfejsów graficznych będą brane pod uwagę następujące normy:

•    PN-EN ISO 9241-210:2011 „Projektowanie ukierunkowane na człowieka w przypadku systemów interaktywnych",

•    PN-EN ISO 9241-151:2008 „Wytyczne dotyczące interfejsów użytkownika stosowanych w sieci World Wide Web",

•    PN-EN ISO 9241-11:2002 „Wskazówki dotyczące użyteczności"

•    PN-EN ISO 9241-143:2012 „Formularze"

10.2.1.3 Standardy i technologie

1.    Rozwiązanie powinno mieć postać zestawu modułowych aplikacji Web wykorzystujących nowoczesne technologie z zakresu automatycznej wymiany danych opartej o infrastrukturę web services REST.

2.    Warstwy backendowa oraz frontendowa powinny być w całości rozdzielone. Komunikacja pomiędzy nimi powinna odbywać się tylko i wyłącznie poprzez API oparte o http zgodne z REST i/lub WebSocket. Nie jest dopuszczalne konstruowanie web services w oparciu o SOAP.

3.    Komunikacja powinna odbywać się za pomocą formatu JSON/XML.

4.    System powinien zapewnić poprawne funkcjonowanie rozwiązania na dowolnej platformie sprzętowej, systemie operacyjnym czy serwerze aplikacji. Aplikacja będzie komunikować się z zewnętrznymi serwisami za pomocą web serwisów REST, przy wykorzystaniu szyfrowanego połączenia SSL. Projekt będzie możliwy do skalowania we wszystkich trzech podstawowych warstwach (tj. frontend, backend i baza danych), co pozwoli w razie potrzeby na rozszerzenie zakresu wykorzystania o nowe procesy i kolejnych Użytkowników. Każdy z serwisów musi być skalowalny niezależnie od pozostałych (np. mikroserwis odpowiedzialny za publikację ogłoszeń ma być niezależny od mikroserwisu odpowiedzialnego za uwierzytelnianie).

5.    Warstwa backend - wymagania:

5.1.    Rozwiązanie zostanie wykonane w oparciu o Architekturę modułową.

5.2.    Moduły będą się komunikować za pomocą http, WebSocket lub kolejki obsługującej protokół AMPQ.

5.3.    Konieczne jest zapewnienie możliwości rozproszenia poszczególnych Modułów tak, aby system mógł działać w różnych lokalizacjach.

5.4.    Konieczna jest możliwość skalowania wszerz każdego z mikroserwisów niezależnie od pozostałych.

6.    Bazy danych dla każdego mikroserwisu są niezależne od pozostałych i nie mogą być współdzielone (tj. jeden logiczny komponent/mikroserwis komunikuje się z jedną bazą danych - wiele instancji tego samego komponentu/mikroserwisu może komunikować się z jedną bazą danych).

7.    Warstwa UI (Frontend) - wymagania:

7.1.    Aplikacje wchodzące w skład Platformy powinny mieć strukturę modułową.

7.2.    Aplikacje muszą spełniać standardy RWD (Responsive Web Design) i działać zarówno na urządzeniach mobilnych (smartfony, tablety), jak i na laptopach oraz komputerach stacjonarnych.

7.3.    Aplikacje wchodzące w skład Platformy muszą spełniać standardy dostępności dla niepełnosprawnych (Web Accessibility Initiative, Web Content Accessibility Guidelines (WCAG) 2.0)

7.4.    Aplikacje wchodzące w skład Platformy powinny zostać zaprojektowane w formule Single Page, z wykorzystaniem HTML5/CSS3 oraz wiodących frameworków JavaScript.

7.5.    Interfejs aplikacji zostanie zaprojektowany i wykonany zgodnie z zaleceniami dotyczącymi User Experience/Usability.

10.2.1.4 Interoperacyjność

Realizacja Projektu została zaplanowana w sposób zapewniający interoperacyjność z innymi systemami administracji państwowej, wdrożonymi lub planowanymi do wdrożenia. Platforma e-Zamówienia zintegrowana będzie z Portalami e-Usług wykorzystywanymi w procesie realizacji postępowania przetargowego udzielenie zamówienia publicznego.

Platforma e-Zamówienia zintegrowana będzie z Portalami e-Usług Zamawiajacych i/lub wykonawców wykorzystywanymi w procesie realizacji postępowania o udzielenie zamówienia publicznego - wymiana danych przez API lub systemami z których dane/pliki będą wysyłane oraz przekazywane poprzez Platformę e-Zamówienia do Zamawiających.

Realizacja Projektu została zaplanowana w sposób zapewniający realizację wymogów wynikających z Rozporządzenia Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz.U. z 2012 r., poz. 526 z późn. zm.).

10.2.2Wymagania hostingu

Wybrany w drodze postępowania o udzielenie zamówienia publicznego wykonawca świadczyć będzie usługi hostingu.

Zapewni on niezbędne zasoby infrastrukturalne zapewniające poprawną pracę Platformy e-Zamówienia. Zasoby ten będą obejmować moc obliczeniową oraz przestrzeń dyskową niezbędną do obsłużenia wolumenu danych oraz zapytań zgodnie z danymi, które zostały przedstawione w rozdziale 10.3.

W poniższych punktach ujęte zostały główne założenia dla tej usługi:

1.    Wykonawca zrealizuje usługę hostingu w modelu chmury obliczeniowej.

2.    Hosting będzie przeznaczony do obsługi wszystkich Modułów i Komponentów Platformy e-Zamówienia w środowiskach produkcyjnym, testowym i szkoleniowym .

3.    Usługa Hostingu będzie świadczona w taki sposób, aby zapewnić bezproblemową przenaszalność Platformy e-Zamówienia na dowolne inne, wskazane przez Zamawiającego zasoby, w szczególności do Wspólnej Infrastruktury Państwa.

4.    Rozwiązanie hostingowe będzie zainstalowane w obiekcie Data Center (zarówno głównym jak i backup'owym) zaprojektowanym i zbudowanym zgodnie ze standardem TIA-942 na poziomie co najmniej Tier III.

5.    Infrastruktura hostingu będzie zbudowana i zarządzana w sposób zapewniający zgodność z wymaganiami norm lub ich odpowiednikami obowiązujących na terenie Europejskiego Obszaru Gospodarczego: PN-EN 1047-2:2009; PN/ISO 27001:2007; ISO/IEC 27002:2005 lub nowsze.

6.    Poszczególne Centra Danych powinny być oddalone od siebie o minimum 10 km minimalizując wpływ ewentualnych katastrof na funkcjonowanie Platformy e-Zamówienia. Centra danych muszą zapewniać strefy buforowe. CPD nie może pełnić innych funkcji użytkowych, poza funkcjami bezpośrednio związanymi z elektronicznym przetwarzaniem danych.

7.    Skalowalność wewnątrz środowisk będzie realizowana przy wykorzystaniu wirtualizacji i systemu balansowania ruchem. Takie rozwiązanie gwarantować będzie spełnienie wymagań wydajnościowych dla rozwiązania gwarantujących czasy odpowiedzi systemu zgodnie z oczekiwaniami użytkowników końcowych (ewentualne opóźnienia będzie narzucać łącze po stronie użytkownika a nie wydajność infrastruktury).

8.    Usługa hostingu będzie spełniać wymagania SLA postawione przez Beneficjenta (zostaną one szczegółowo opisane w SIWZ obejmującej specyfikację wymagań na usługę hostingu) -parametry te będą obejmować dostępność, wydajność, niezawodność, bezpieczeństwo wraz z czasami reakcji oraz czasem przełączania się pomiędzy centrami danych (GCPD a CZPD) tak, aby zagwarantować poziom SLA, który zapewni nieprzerwaną dostępność usług, w szczególności usługi przyjmowania ofert lub wniosków. Jest to kluczowa usługa systemu warunkująca zaufanie interesariuszy do całego rozwiązania.

9.    Zamawiający będzie posiadać zdalny dostęp do zasobów wydzielonych w ramach zamówienia na usługę hostingu (dostęp ten będzie posiadać pełne uprawnienia administracyjne). Środowisko produkcyjne Platformy e-Zamówienia musi zapewniać redundancję geograficzną - oddzielone przynajmniej dwa, niezależne centra danych (niezależność DC pod kątem świadczenia usług „produkcyjnych", a nie pod kątem zdublowania pełnej funkcjonalności DC_1 w DC_2) zlokalizowane w miejscach, które gwarantują ciągłość działania w przypadku awarii jednego z centrów przetwarzania danych. Podstawowe wymagania dotyczące DC_1 oraz DC_2 dotyczą ich certyfikacji. Dostaca usług hostingowych będzie musiał posiadać co najmniej następujące certyfikaty:

Certyfikat w zakresie gwarancji jakości świadczonych usług - ISO 9001:2008 Certyfikat bezpieczeństwa w zakresie „Outsourcingów IT" - ISO 27001:2005

10.    Dostawca usług hostingowych musi dla wszystkich DC zapewniać w zakresie dostępu do operatorów telekomunikacyjnych następujące parametry:

a. Co najmniej 2 operatorów telekomunikacyjnych, posiadających własne światłowodowe kable telekomunikacyjne do DCC traktowane jako przyłącza

światłowodowe minimum 12 włókien poprowadzone od własnej sieci do CPD operatora.

b.    DC powinno być wyposażone w redundantny węzeł dostępu do sieci Internet z wykorzystaniem routerów, switchy, firewall, Intrusion Prevention System.

c.    DC musi posiadać własną publiczną adresację IP.

11. Dostawca usług hostingowych musi dla DC_1 oraz DC_2 zapewniać w zakresie zasilania energią elektryczną co najmniej:

a.    Redundancję infrastruktura zasilania CPD energetyki zawodowej na poziomie trafo GPZ 110/15 kV.

b.    Co najmniej 2 tory zasilające NN w każdym pomieszczeniu serwerowym. Wszystkie tory zasilające muszą gwarantować taką samą moc maksymalną zasilania.

c.    Poziom redundancji urządzeń UPS dla każdego toru zasilającego NN z osobna na poziomie 2N.

d.    Agregaty prądotwórcze.

Zgodnie z założeniami Projektu w momencie udostępnienia zasobów w Wspólnej Infrastrukturze Państwa o nie gorszych parametrach świadczenia usług, nastąpi przeniesienie tam usługi.

10.3Wydajność i skalowalność planowanego systemu

Skalowalność wewnątrz środowisk będzie realizowane przy wykorzystaniu wirtualizacji i systemu balansowania ruchem. Takie rozwiązanie gwarantować będzie spełnienie wymagań wydajnościowych dla rozwiązania gwarantujących czasy odpowiedzi systemu zgodnie z oczekiwaniami użytkowników końcowych (ewentualne opóźnienia będzie narzucać łącze po stronie użytkownika a nie wydajność infrastruktury).

System jest przeznaczony do obsługi zamówień publicznych, których liczba w skali roku jest stabilna. Zgodnie z Pzp, zamawiający mają obowiązek publikować ogłoszenia w Dzienniku Urzędowym Unii Europejskiej, o ile ich wartość przekracza tzw. „progi unijne". W latach 2013-2016 w TED (Tender Electronic Daily - http://ted.europa.eu/TED/main/HomePage.do) - Suplemencie ww. Dz.U. UE opublikowano następujące ilości ogłoszeń o przetargach (o zamówieniu i konkursie):

W tym polscy zamawiający opublikowali ok. 12 % wszystkich ogłoszeń o zamówieniach i konkursach:

Przedstawione dane dotyczą okresu, który obejmował postępowania prowadzone zgodnie z ustawą Pzp, gdy tzw. próg stosowalności ustawy wynosił 14 tys. euro do 16 kwietnia 2014 roku oraz 30 tys. euro po tej dacie. Spowodowało to, że liczba wszystkich postępowań, które są prowadzone zgodnie z ustawa Pzp zmniejszyła się. Przez postępowanie należy rozumieć cały proces od utworzenia

ogłoszenia o zamówieniu do ogłoszenia o udzieleniu zamówienia lub unieważnieniu postępowania, a nie pojedynczą operację.

W systemie publikacji ogłoszeń i przesyłania rocznych sprawozdań zarejestrowanych było 54526 użytkowników (stan na luty 2016 r.). To są zamawiający, którym przyznano kody autoryzacji do zamieszczania ogłoszeń i przesyłania Prezesowi UZP rocznych sprawozdań.

W systemie subskrypcji ogłoszeń na koniec 2015 roku zarejestrowanych 22.894 użytkowników, przy czym 9.324 posiada 1 aktywną subskrypcję, 5.163 dwie, a 3.031 trzy aktywne subskrypcje. Do subskrybentów dziennie wysyłane jest w godzinach 0.00 - 5.00 około 14 tys. wiadomości e-mail. Liczba wejść na stronę BZP w celu wyszukiwania ogłoszeń w 2015 roku wyniosła ok. 1.137.000. (dane z raportu Mail by Sender).

Zamówienia udzielone wykonawcom zagranicznym w postępowaniach polskich zamawiających wynosiły:

liczby składanych ofert w latach 2013-2016:

Poniższa tabela przedstawia dane dotyczące liczby ogłoszeń publikowanych w BZP i TED oraz