Produkt czy funkcjonalność? Praktyka zamówień publicznych z perspektywy dostawcy oprogramowania

Transkrypt

1 Produkt czy funkcjonalność? Praktyka zamówień publicznych z perspektywy dostawcy oprogramowania Jarosław Kowalski Prezes Zarządu jkowalski@novell.pl

2 Całe spektrum dostawców w Polsce 2

3 Państwo podmiot czy przedmiot? 3

4 Podstawy prawne

5 Podstawy prawne Prawo zamówień publicznych z 29 stycznia 2004 r. Art. 7. > 1. Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców. Art. 29. > Przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję. > Przedmiotu zamówienia nie można opisywać przez wskazanie znaków towarowych, patentów lub pochodzenia, chyba że jest to uzasadnione specyfiką przedmiotu zamówienia i zamawiający nie może opisać przedmiotu zamówienia za pomocą dostatecznie dokładnych określeń, a wskazaniu takiemu towarzyszą wyrazy lub równoważny.» 5 Orzecznictwo określa sposób budowania zamówień równoważnych

6 Podstawy prawne Prawo zamówień publicznych z 29 stycznia 2004 r. 6 Art. 30 > Zamawiający opisuje przedmiot zamówienia za pomocą cech technicznych i jakościowych, z zachowaniem Polskich Norm przenoszących normy europejskie lub norm innych państw członkowskich Europejskiego Obszaru Gospodarczego przenoszących te normy. > Opisując przedmiot zamówienia za pomocą norm, aprobat, specyfikacji technicznych i systemów odniesienia, o których mowa w ust. 13, zamawiający jest obowiązany wskazać, że dopuszcza rozwiązania równoważne opisywanym. > Zamawiający może odstąpić od opisywania przedmiotu zamówienia z uwzględnieniem przepisów ust. 13, jeżeli zapewni dokładny opis przedmiotu zamówienia poprzez wskazanie wymagań funkcjonalnych.

7 Podstawy prawne Ustawa z 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne 7 Art. 1 określa m.in. zasady > ustalania minimalnych, gwarantujących otwartość standardów informatycznych, wymagań dla systemów teleinformatycznych > dostosowania systemów teleinformatycznych używanych do realizacji zadań publicznych do minimalnych, gwarantujących otwartość standardów informatycznych > dostosowania rejestrów publicznych i wymiany informacji w formie elektronicznej z podmiotami publicznymi do minimalnych, gwarantujących otwartość standardów informatycznych w celu ochrony interesu publicznego, w tym zachowania przez Państwo możliwości swobody wyboru technologii w procesach informatyzacji realizacji zadań publicznych.

8 Podstawy prawne Rozporządzenie RM z 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych > 8 2. Systemy teleinformatyczne używane przez podmioty publiczne do realizacji zadań publicznych [...] powinny zostać wyposażone w składniki sprzętowe i oprogramowanie:» a) umożliwiające wymianę danych z innymi systemami teleinformatycznymi używanymi do realizacji zadań publicznych za pomocą protokołów komunikacyjnych i szyfrujących określonych w załączniku nr 1 do rozporządzenia, stosownie do zakresu działania tych systemów,» b) zapewniające dostęp do zasobów informacji udostępnianych przez systemy teleinformatyczne używane do realizacji zadań publicznych przy wykorzystaniu formatów danych określonych w załączniku nr 2 do rozporządzenia. Zarówno ustawa, jak i rozporządzenie jest w trakcie procesu nowelizacji

9 Rola standardów w zapewnieniu interoperacyjności systemów IT

10 Standardy otwarte w UE Kiedy standard (normę) uznajemy za otwarty? Aby osiągnąć interoperacyjność w kontekście ogólnoeuropejskich usług administracji elektronicznej, wytyczne muszą się skupiać na otwartych normach. Poniżej podaje się minimalne parametry, jakimi muszą się charakteryzować specyfikacja i dołączone do niej dokumenty, aby można je uznać za otwartą normę: Norma została przyjęta i będzie utrzymywana przez organizację o celu niezarobkowym, a jej ciągły rozwój będzie realizowany na podstawie otwartej procedury decyzyjnej dostępnej dla wszystkich zainteresowanych stron (decyzja w drodze konsensusu lub większością głosów, itd.). Norma została opublikowana, a specyfikacja normy jest dostępna bezpłatnie lub za symboliczną opłatą. Konieczne jest, aby wszyscy mogli kopiować, rozpowszechniać i wykorzystywać ją bezpłatnie lub za symboliczną opłatą. Własność intelektualna tj. ewentualne istniejące patenty (części) normy jest nieodwołalnie udostępniona bez jakichkolwiek opłat. Brak jakichkolwiek ograniczeń w zakresie ponownego użycia normy. źródło: 10 Europejskie ramy interoperacyjności w zakresie ogólnoeuropejskich usług administracji elektronicznej, wersja 1.0, listopad 2004

11 Wybrane standardy rynkowe 11

12 Praktyka w postępowaniu

13 Przykład specyfikacji w przetargach publicznych Warszawa, dnia 15 maja 2007 r. SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA (SIWZ) Dostawa oprogramowania i licencji dla stacji roboczych i serwerów wraz z opieką serwisową dla Kancelarii Prezydenta RP. Windows Server Standard All Lng Lic/SA Pack MVL - 10 szt, Windows Server Enterprise All Lng Lic/SA Pack MVL - 4 szt, Office SharePoint Server All Lng Lic/SA Pack MVL - 1 szt, Exchange Server Enterprise All Languages Lic/SA Pack MVL - 2 szt, System Management Server Enterprise Edition All Lng Lic/SA Pack MVL with SQL Technology - 1 szt, SQL Server Standard Edition Win32 All Lng Lic/SA Pack MVL 1 Processor License 2 szt, Microsoft Operations Manager Server All Languages Lic/SA Pack MVL with SQL Technology - 1 szt, MOM Enterprise Operations Management License All Lng Lic/SA Pack MVL - 18 szt. 13

14 Przykład specyfikacji w przetargach publicznych Wrocław, dnia 17 grudnia 2007 r. PL-Wrocław: Serwery 2007/S SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA (SIWZ) Zakup sprzętu komputerowego, wyposażenia i oprogramowania na potrzeby systemu poczty elektronicznej w Urzędzie Marszałkowskim Województwa Dolnośląskiego. System pracy grupowej posiadający następującą funkcjonalność: a) b) c) d) e) f) g) h) i) j) k) l) m) n) 14 obsługa poczty elektronicznej z możliwością śledzenie statusu, szyfrowania i podpisu elektroniczny kalendarz i grupowy terminarz możliwość jednoczesnego wyświetlania kalendarza dla wielu użytkowników planowanie całodniowych i wielodniowych spotkań wbudowany obieg dokumentów (workflow) umożliwiający wysłanie sekwencyjnie wg kolejności współużytkowane foldery i książki adresowe filtrowanie spamu na poziomie serwera i dodatkowo na poziomie klienta zarządzanie dokumentami obejmujące możliwości... zintegrowany komunikator korzystający z protokołu XMPP sprawdzanie pisowni książka adresowa zintegrowana z usługami katalogowymi (LDAPv3) dostęp do systemu przez przeglądarkę klient dla systemu dostępny dla platform: Windows, Linux, Macintosh współpraca z urządzeniami przenośnymi Windows Mobile, Palm OS, Symbian OS

15 Swobodna interpretacja PZP 15 Praktyka zawierania umów ramowych Zakup minimalnej liczby licencji, a następnie rozszerzanie puli Klauzula istniejącej infrastruktury informatycznej, czyli de facto uzależnienie od innych produktów będących w użyciu u zamawiającego Zakup systemów bez przekazania autorskich praw majątkowych, skutkuje uzależnieniem zamawiającego od jednego wykonawcy

16 Analiza zamówień na oprogramowanie lipec 2006 czerwiec 2007 czerwiec-wrzesień

17 Analiza zamówień na usługi IT 17

18 Fundamentalne pytania

19 Wolna konkurencja? Czy producent jest zawsze dostawcą? W przeważającej mierze produkty z obszaru IT są rozwijane i produkowane za granicą Większość zamówień jest realizowana przez polskich dostawców (integrator lub reseller), a nie przez producentów Czy umowa ramowa ogranicza konkurencję? Art. 100 ustęp 4. PZP > 19 Zamawiający nie może wykorzystywać umowy ramowej do ograniczania konkurencji. Do podpisania umowy ramowej także jest wymagane przeprowadzenie postępowania przetargowego 11 podmiotów posiada status LAR i oferuje produkty w ramach umowy Select

20 Rozwiązania równoważne 20 Zgodnie z orzecznictwem nie wystarczy wyłącznie zawrzeć w specyfikacji dopuszczenia rozwiązań równoważnych KIO/UZP 254/08 KIO/UZP 33/07 KIO/UZP/10/07 UZP/ZO/0-937/07 UZP/ZO/0-913/07 UZP/ZO/0-943/07 UZP/ZO/0-806/07 UZP/ZO/0-670/07 UZP/ZO/0-431/07

21 Rozwiązania równoważne 21 Z orzecznictwa KIO UZP Produkt równoważny to taki, który ma te same cechy funkcjonalne, co wskazany w SIWZ konkretny z nazwy lub pochodzenia produkt. Jego jakość nie może być gorsza od jakości określonego w specyfikacji produktu. Oferta równoważna to taka, która przedstawia przedmiot zamówienia o właściwościach takich samych lub zbliżonych do tych, które zostały określone w SIWZ, lecz oznaczonych innym znakiem towarowym, patentem lub pochodzeniem. Nie jest to oferta identyczna ze wskazanym przedmiotem zamówienia. Zamawiający w SIWZ powinien doprecyzować zakres dopuszczalnej równoważności ofert.

22 Art. 55 PZP. Negocjacje z ogłoszeniem standardem w zamówieniach IT? 22 Specyfiką rozwiązań teleinformatycznych jest ich złożoność i dynamiczny rozwój Większość produktów jest rozwijana/produkowana za granicą Istnieje konieczność bezustannego monitorowania rynku Negocjacje z ogłoszeniem pozwalają: Zachować neutralność i równo traktować dostawców Wszyscy producenci i dostawcy mają szansę prezentacji swoich rozwiązań i najnowszych wersji produktów Zamawiający pozyskują wiedzę z rynku i dane do poprawnego sformułowania specyfikacji

23 Proces zakupów w modelu korporacyjnym

24 Określenie specyfikacji i wybór dostawców Kolejne rundy zbierania ofert Negocjacje (w miarę potrzeb) Planowanie wydatków Określenie i specyfikacja potrzeb 24 Co rok (lub w miarę potrzeb) Wstępne zbieranie ofert Badanie rynku i określenie źródeł zakupu

25 Zamawianie i kontrola Negocjacje Planowanie wydatków Kontroling wydatków Na bieżąco Kolejne rundy zbierania ofert (w miarę potrzeb) Kontrola jakości Wstępne zbieranie ofert Zamawianie/ administracja Określenie i specyfikacja potrzeb 25 Badanie rynku i określenie źródeł zakupu

26 Pożądane efekty modelu biznesowego Pełny przegląd dostępnych rozwiązań Wybór odpowiednich narzędzi Casus Francji, Danii i Holandii gdzie administracja musi uzasadnić zastosowanie komercyjnego oprogramowania w miejsce oprogramowania open source Stałe podnoszenie kwalifikacji pracowników 26 Nie zawsze istnieje potrzeba wdrażania najnowszej wersji lub najbardziej rozbudowanego produktu Oszczędności wynikające z zastosowania alternatywnych produktów/usług Konkurs piękności wśród producentów i dostawców Zarówno na etapie wyboru, opracowania specyfikacji, jaki i wdrożenia rozwiązania Ograniczenie do minimum pola do protestów

27

28 Produkt czy funkcjonalność? Praktyka zamówień publicznych z perspektywy dostawcy oprogramowania Jarosław Kowalski Prezes Zarządu jkowalski@novell.pl

29 Całe spektrum dostawców w Polsce 2 2

30 Państwo podmiot czy przedmiot? 3 3

31 Podstawy prawne

32 Podstawy prawne Prawo zamówień publicznych z 29 stycznia 2004 r. Art. 7. > 1. Zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców. Art. 29. > Przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję. > Przedmiotu zamówienia nie można opisywać przez wskazanie znaków towarowych, patentów lub pochodzenia, chyba że jest to uzasadnione specyfiką przedmiotu zamówienia i zamawiający nie może opisać przedmiotu zamówienia za pomocą dostatecznie dokładnych określeń, a wskazaniu takiemu towarzyszą wyrazy lub równoważny.» 5 Orzecznictwo określa sposób budowania zamówień równoważnych 5

33 Podstawy prawne Prawo zamówień publicznych z 29 stycznia 2004 r. 6 Art. 30 > Zamawiający opisuje przedmiot zamówienia za pomocą cech technicznych i jakościowych, z zachowaniem Polskich Norm przenoszących normy europejskie lub norm innych państw członkowskich Europejskiego Obszaru Gospodarczego przenoszących te normy. > Opisując przedmiot zamówienia za pomocą norm, aprobat, specyfikacji technicznych i systemów odniesienia, o których mowa w ust. 13, zamawiający jest obowiązany wskazać, że dopuszcza rozwiązania równoważne opisywanym. > Zamawiający może odstąpić od opisywania przedmiotu zamówienia z uwzględnieniem przepisów ust. 13, jeżeli zapewni dokładny opis przedmiotu zamówienia poprzez wskazanie wymagań funkcjonalnych. 6

34 Podstawy prawne Ustawa z 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne 7 Art. 1 określa m.in. zasady > ustalania minimalnych, gwarantujących otwartość standardów informatycznych, wymagań dla systemów teleinformatycznych > dostosowania systemów teleinformatycznych używanych do realizacji zadań publicznych do minimalnych, gwarantujących otwartość standardów informatycznych > dostosowania rejestrów publicznych i wymiany informacji w formie elektronicznej z podmiotami publicznymi do minimalnych, gwarantujących otwartość standardów informatycznych w celu ochrony interesu publicznego, w tym zachowania przez Państwo możliwości swobody wyboru technologii w procesach informatyzacji realizacji zadań publicznych. 7

35 Podstawy prawne Rozporządzenie RM z 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych > 8 2. Systemy teleinformatyczne używane przez podmioty publiczne do realizacji zadań publicznych [...] powinny zostać wyposażone w składniki sprzętowe i oprogramowanie:» a) umożliwiające wymianę danych z innymi systemami teleinformatycznymi używanymi do realizacji zadań publicznych za pomocą protokołów komunikacyjnych i szyfrujących określonych w załączniku nr 1 do rozporządzenia, stosownie do zakresu działania tych systemów,» b) zapewniające dostęp do zasobów informacji udostępnianych przez systemy teleinformatyczne używane do realizacji zadań publicznych przy wykorzystaniu formatów danych określonych w załączniku nr 2 do rozporządzenia. Zarówno ustawa, jak i rozporządzenie jest w trakcie procesu nowelizacji 8

36 Rola standardów w zapewnieniu interoperacyjności systemów IT

37 Standardy otwarte w UE Kiedy standard (normę) uznajemy za otwarty? Aby osiągnąć interoperacyjność w kontekście ogólnoeuropejskich usług administracji elektronicznej, wytyczne muszą się skupiać na otwartych normach. Poniżej podaje się minimalne parametry, jakimi muszą się charakteryzować specyfikacja i dołączone do niej dokumenty, aby można je uznać za otwartą normę: Norma została przyjęta i będzie utrzymywana przez organizację o celu niezarobkowym, a jej ciągły rozwój będzie realizowany na podstawie otwartej procedury decyzyjnej dostępnej dla wszystkich zainteresowanych stron (decyzja w drodze konsensusu lub większością głosów, itd.). Norma została opublikowana, a specyfikacja normy jest dostępna bezpłatnie lub za symboliczną opłatą. Konieczne jest, aby wszyscy mogli kopiować, rozpowszechniać i wykorzystywać ją bezpłatnie lub za symboliczną opłatą. Własność intelektualna tj. ewentualne istniejące patenty (części) normy jest nieodwołalnie udostępniona bez jakichkolwiek opłat. Brak jakichkolwiek ograniczeń w zakresie ponownego użycia normy. źródło: 10 Europejskie ramy interoperacyjności w zakresie ogólnoeuropejskich usług administracji elektronicznej, wersja 1.0, listopad

38 Wybrane standardy rynkowe 11 11

39 Praktyka w postępowaniu

40 Przykład specyfikacji w przetargach publicznych Warszawa, dnia 15 maja 2007 r. SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA (SIWZ) Dostawa oprogramowania i licencji dla stacji roboczych i serwerów wraz z opieką serwisową dla Kancelarii Prezydenta RP. Windows Server Standard All Lng Lic/SA Pack MVL - 10 szt, Windows Server Enterprise All Lng Lic/SA Pack MVL - 4 szt, Office SharePoint Server All Lng Lic/SA Pack MVL - 1 szt, Exchange Server Enterprise All Languages Lic/SA Pack MVL - 2 szt, System Management Server Enterprise Edition All Lng Lic/SA Pack MVL with SQL Technology - 1 szt, SQL Server Standard Edition Win32 All Lng Lic/SA Pack MVL 1 Processor License 2 szt, Microsoft Operations Manager Server All Languages Lic/SA Pack MVL with SQL Technology - 1 szt, MOM Enterprise Operations Management License All Lng Lic/SA Pack MVL - 18 szt

41 Przykład specyfikacji w przetargach publicznych Wrocław, dnia 17 grudnia 2007 r. PL-Wrocław: Serwery 2007/S SPECYFIKACJA ISTOTNYCH WARUNKÓW ZAMÓWIENIA (SIWZ) Zakup sprzętu komputerowego, wyposażenia i oprogramowania na potrzeby systemu poczty elektronicznej w Urzędzie Marszałkowskim Województwa Dolnośląskiego. System pracy grupowej posiadający następującą funkcjonalność: a) b) c) d) e) f) g) h) i) j) k) l) m) n) 14 obsługa poczty elektronicznej z możliwością śledzenie statusu, szyfrowania i podpisu elektroniczny kalendarz i grupowy terminarz możliwość jednoczesnego wyświetlania kalendarza dla wielu użytkowników planowanie całodniowych i wielodniowych spotkań wbudowany obieg dokumentów (workflow) umożliwiający wysłanie sekwencyjnie wg kolejności współużytkowane foldery i książki adresowe filtrowanie spamu na poziomie serwera i dodatkowo na poziomie klienta zarządzanie dokumentami obejmujące możliwości... zintegrowany komunikator korzystający z protokołu XMPP sprawdzanie pisowni książka adresowa zintegrowana z usługami katalogowymi (LDAPv3) dostęp do systemu przez przeglądarkę klient dla systemu dostępny dla platform: Windows, Linux, Macintosh współpraca z urządzeniami przenośnymi Windows Mobile, Palm OS, Symbian OS 14

42 Swobodna interpretacja PZP 15 Praktyka zawierania umów ramowych Zakup minimalnej liczby licencji, a następnie rozszerzanie puli Klauzula istniejącej infrastruktury informatycznej, czyli de facto uzależnienie od innych produktów będących w użyciu u zamawiającego Zakup systemów bez przekazania autorskich praw majątkowych, skutkuje uzależnieniem zamawiającego od jednego wykonawcy 15

43 Analiza zamówień na oprogramowanie lipec 2006 czerwiec 2007 czerwiec-wrzesień

44 Analiza zamówień na usługi IT 17 17

45 Fundamentalne pytania

46 Wolna konkurencja? Czy producent jest zawsze dostawcą? W przeważającej mierze produkty z obszaru IT są rozwijane i produkowane za granicą Większość zamówień jest realizowana przez polskich dostawców (integrator lub reseller), a nie przez producentów Czy umowa ramowa ogranicza konkurencję? Art. 100 ustęp 4. PZP > 19 Zamawiający nie może wykorzystywać umowy ramowej do ograniczania konkurencji. Do podpisania umowy ramowej także jest wymagane przeprowadzenie postępowania przetargowego 11 podmiotów posiada status LAR i oferuje produkty w ramach umowy Select 19

47 Rozwiązania równoważne 20 Zgodnie z orzecznictwem nie wystarczy wyłącznie zawrzeć w specyfikacji dopuszczenia rozwiązań równoważnych KIO/UZP 254/08 KIO/UZP 33/07 KIO/UZP/10/07 UZP/ZO/0-937/07 UZP/ZO/0-913/07 UZP/ZO/0-943/07 UZP/ZO/0-806/07 UZP/ZO/0-670/07 UZP/ZO/0-431/07 20

48 Rozwiązania równoważne 21 Z orzecznictwa KIO UZP Produkt równoważny to taki, który ma te same cechy funkcjonalne, co wskazany w SIWZ konkretny z nazwy lub pochodzenia produkt. Jego jakość nie może być gorsza od jakości określonego w specyfikacji produktu. Oferta równoważna to taka, która przedstawia przedmiot zamówienia o właściwościach takich samych lub zbliżonych do tych, które zostały określone w SIWZ, lecz oznaczonych innym znakiem towarowym, patentem lub pochodzeniem. Nie jest to oferta identyczna ze wskazanym przedmiotem zamówienia. Zamawiający w SIWZ powinien doprecyzować zakres dopuszczalnej równoważności ofert. 21

49 Art. 55 PZP. Negocjacje z ogłoszeniem standardem w zamówieniach IT? 22 Specyfiką rozwiązań teleinformatycznych jest ich złożoność i dynamiczny rozwój Większość produktów jest rozwijana/produkowana za granicą Istnieje konieczność bezustannego monitorowania rynku Negocjacje z ogłoszeniem pozwalają: Zachować neutralność i równo traktować dostawców Wszyscy producenci i dostawcy mają szansę prezentacji swoich rozwiązań i najnowszych wersji produktów Zamawiający pozyskują wiedzę z rynku i dane do poprawnego sformułowania specyfikacji 22

50 Proces zakupów w modelu korporacyjnym

51 Określenie specyfikacji i wybór dostawców Kolejne rundy zbierania ofert Negocjacje (w miarę potrzeb) Planowanie wydatków Określenie i specyfikacja potrzeb 24 Co rok (lub w miarę potrzeb) Wstępne zbieranie ofert Badanie rynku i określenie źródeł zakupu 24

52 Zamawianie i kontrola Negocjacje Planowanie wydatków Kontroling wydatków Na bieżąco Kolejne rundy zbierania ofert (w miarę potrzeb) Kontrola jakości Wstępne zbieranie ofert Zamawianie/ administracja Określenie i specyfikacja potrzeb 25 Badanie rynku i określenie źródeł zakupu 25

53 Pożądane efekty modelu biznesowego Pełny przegląd dostępnych rozwiązań Wybór odpowiednich narzędzi Casus Francji, Danii i Holandii gdzie administracja musi uzasadnić zastosowanie komercyjnego oprogramowania w miejsce oprogramowania open source Stałe podnoszenie kwalifikacji pracowników 26 Nie zawsze istnieje potrzeba wdrażania najnowszej wersji lub najbardziej rozbudowanego produktu Oszczędności wynikające z zastosowania alternatywnych produktów/usług Konkurs piękności wśród producentów i dostawców Zarówno na etapie wyboru, opracowania specyfikacji, jaki i wdrożenia rozwiązania Ograniczenie do minimum pola do protestów 26

54