Poznań: Rozszerzenie Systemu PEKA o dodatkowe funkcjonalności
Numer ogłoszenia: 183881 - 2015; data zamieszczenia: 14.12.2015
OGŁOSZENIE O UDZIELENIU ZAMÓWIENIA - Usługi

Zamieszczanie ogłoszenia: obowiązkowe.

Ogłoszenie dotyczy: zamówienia publicznego.

Czy zamówienie było przedmiotem ogłoszenia w Biuletynie Zamówień Publicznych: nie.

Czy w Biuletynie Zamówień Publicznych zostało zamieszczone ogłoszenie o zmianie ogłoszenia: nie.

SEKCJA I: ZAMAWIAJĄCY

I. 1) NAZWA I ADRES: Zarząd Transportu Miejskiego w Poznaniu, ul. Matejki 59, 60-770 Poznań, woj. wielkopolskie, tel. 61 834 6148, faks 61 834 61 47.

I. 2) RODZAJ ZAMAWIAJĄCEGO: Administracja samorządowa.

SEKCJA II: PRZEDMIOT ZAMÓWIENIA

II.1) Nazwa nadana zamówieniu przez zamawiającego: Rozszerzenie Systemu PEKA o dodatkowe funkcjonalności.

II.2) Rodzaj zamówienia: Usługi.

II.3) Określenie przedmiotu zamówienia: Integracja Systemu PEKA z systemami kontroli biletów u przewoźników kolejowych Przewozy Regionalne sp. z o. o. oraz Koleje Wielkopolskie sp. z o. o. Stworzenie interfejsu, który umożliwiał będzie pobranie przez ww. przewoźników kolejowych danych dotyczących aktualnych (posiadanych przez klientów) biletów komunikacji miejskiej. Usługa taka powinna pozwolić także na pobranie przez przewoźników kolejowych taryf wraz ze słownikami. Dostosowanie nowych 50 tysięcy kart do Systemu - opracowanie i implementacja procedury inicjalizacji dla kart Java Card 3.0.1 JCOP242-R3 oraz wdrożenie jej w bibliotece personalizacyjnej. 3. Dokonanie modyfikacji w module obsługi MOPR (Miejskiego Ośrodka Pomocy Rodzinie) w taki sposób, aby obejmował następujące funkcje: a) oprogramowanie terminala PSB, służącego rejestracji wydania posiłku, powinno zostać zmodyfikowane w ten sposób, że o ustalonej w konfiguracji terminala godzinie zostanie wykonana procedura zamknięcia dnia oraz wysłania statystyk wydanych posiłków na serwer. b) raporty MOPR zostaną zmodyfikowane w ten sposób, że dane zliczane będą według faktycznej daty wydania posiłku, nie zaś daty spłynięcia raportu. Stworzenie kont rozliczeniowych na fakturach. System SmartCity zostanie zmodyfikowany w ten sposób, że do każdego organizatora publicznego transportu zbiorowego będzie możliwość przypisania dwóch dodatkowych kont. W związku z tym każdy organizator będzie mógł mieć przypisane łącznie trzy numery kont: a) Konto organizatora (do wystawiania faktur) b) Konto rozliczeniowe dla Biletów Okresowych (do wystawiania przez ZTM faktur hurtowych za sprzedaż Biletów Okresowych) c) Konto rozliczeniowe dla tPortmonetki (do wystawiania przez ZTM faktur hurtowych za sprzedaż tPortmonetki) Stworzenie funkcji w SmartCity, która będzie pozwalała na powiązanie ze sobą różnych kont imiennych. Zakłada się, że w grupie kont będzie istniało jedno konto główne. Po zalogowaniu się na nie do SOP, możliwe będzie pełne zarządzanie pozostałymi kontami. Po zalogowaniu się na konto inne niż główne, nie będą widoczne pozostałe konta. Stworzenie funkcji umożliwiającej wiązanie ze sobą kont imiennych po stronie SOP. Rozszerzenie Interfejsu Zarządzania Wyposażeniem o elementy związane z funkcjami zarzadzania pojazdami oraz Wirtualnym Monitorem. a) Dodanie do Urządzeń o typie VTU pól: biletomat, bileterka, niskopodłogowy. Wszystkie te pola byłyby typu TAK-NIE. b) Modyfikacja Wirtualnego Monitora w ten sposób, by pobierał dane z dodatkowego źródła (w tej chwili źródła są dwa: RJ oraz ramki z pojazdów) - słownika pojazdów i w odpowiedni sposób wyświetlałby je przy WM. c) Wystawienie nowej metody do WebService RG - getVehicles - czyli słownika wszystkich urządzeń o typie VTU. d) Import danych o pojazdach z systemu Busman. Zmiana funkcjonalności transferu transakcji w systemie - możliwość sumowania punktów tPortmonetki oraz biletów zakupionych przez klientów przy wielu różnych transakcjach. Wprowadzenie w systemie Smart City możliwości ograniczenia widoczności ulg-uprawnień w POKach w celu wyeliminowania nadmiernej ilości pozycji na liście uprawnień. Dodanie opcji -Zmiana danych- w procesie zastrzegania karty na rozwijanej liście powodów zastrzeżenia. Dodanie opcji -Poprzednia adaptacja ELS-ELD- w celu podania przyczyny zastrzegania karty lub wyrabiania duplikatu. Zmiana numeru Punktu Obsługi Klienta dla nowych kart w momencie przyłożenia karty do czytnika i zmiany statusu karty ze -Spersonalizowanej- na -Gotowa do odbioru-. Dodanie pozycji -Imię i Nazwisko- właściciela karty na potwierdzeniu odbioru karty, które drukowane jest z systemu SmartCity. Umożliwienie filtrowania firm w polu -Nazwa- po dowolnym ciągu znaków - np. po części nazwy. Wprowadzenie typu płatności: gotówka/karta/przelew przy aktywowaniu kart na okaziciela na dokumencie KP za kaucje. Przedłużanie biletów trasowanych - wprowadzenie możliwości zmiany liczby dni ważności biletu przy przedłużaniu biletów trasowanych, bez potrzeby ustalania trasy od nowa. Wprowadzenie możliwości wydrukowania, na życzenie klienta, spisu użycia punktów z funkcjonalności - Obsługa Klienta. Rozbudowa modułu w SOP o historię parkowania. Zrealizowanie 15 szt. formularzy wyposażonych w funkcję podpisu elektronicznego. Rozbudowa modułu Kontroli Biletów - dodanie możliwości wygenerowania uwag, podsumowania dnia pracy kontrolerów, zaznaczenie wykonywania innych zadań przez kontrolerów w planie grafików. Dostarczenie zaprogramowanych modułów szyfrujących do urządzeń końcowych Systemu PEKA (kasownik, PSB, autokomputer) w ilości 400 sztuk..

II.4) Wspólny Słownik Zamówień (CPV): 72.00.00.00 - Usługi informatyczne: konsultacyjne, opracowywania oprogramowania, internetowe i wsparcia 48.00.00.00 - Pakiety oprogramowania i systemy informatyczne .

SEKCJA III: PROCEDURA

III.1) TRYB UDZIELENIA ZAMÓWIENIA: Zamówienie z wolnej ręki

III.2) INFORMACJE ADMINISTRACYJNE

• Zamówienie dotyczy projektu/programu finansowanego ze środków Unii Europejskiej: nie

SEKCJA IV: UDZIELENIE ZAMÓWIENIA

IV.1) DATA UDZIELENIA ZAMÓWIENIA: 05.11.2015.

IV.2) LICZBA OTRZYMANYCH OFERT: 1.

IV.3) LICZBA ODRZUCONYCH OFERT: 0.

IV.4) NAZWA I ADRES WYKONAWCY, KTÓREMU UDZIELONO ZAMÓWIENIA:

• Bull Polska Sp. z o.o., ul. Królewska 16, 00-103 Warszawa, kraj/woj. mazowieckie.

IV.5) Szacunkowa wartość zamówienia (bez VAT): 300000,00 PLN.

IV.6) INFORMACJA O CENIE WYBRANEJ OFERTY ORAZ O OFERTACH Z NAJNIŻSZĄ I NAJWYŻSZĄ CENĄ

• Cena wybranej oferty: 363342,00

• Oferta z najniższą ceną: 363342,00 / Oferta z najwyższą ceną: 363342,00

• Waluta: PLN .

ZAŁĄCZNIK I

Uzasadnienie udzielenia zamówienia w trybie negocjacji bez ogłoszenia, zamówienia z wolnej ręki albo zapytania o cenę

• 1. Podstawa prawna

  Postępowanie prowadzone jest w trybie zamówienie z wolnej ręki na podstawie art. 67 ust. 1 pkt 1 lit. a, art. 67 ust. 1 pkt 1 lit. b ustawy z dnia 29 stycznia 2004r. - Prawo zamówień publicznych.

• 2. Uzasadnienia wyboru trybu

  Należy podać uzasadnienie faktyczne i prawne wyboru trybu oraz wyjaśnić, dlaczego udzielenie zamówienia jest zgodne z przepisami.

  Zaznaczyć należy, że umowa z dnia 30.08.2012r. nie została w pełni zrealizowana z uwagi bieg okresu gwarancji na wykonany System Poznańska Elektroniczna Karta Aglomeracyjna (PEKA). Usługi wraz z niezbędnymi dostawami dedykowanego sprzętu i oprogramowania, stanowiące przedmiot niniejszego zamówienia, mogą być wykonane jedynie przez dotychczasowego wykonawcę Systemu. Po pierwsze - Zamawiający może udzielić przedmiotowego zamówienia na usługi wraz z koniecznymi dostawami jedynie dotychczasowemu Wykonawcy zamówienia pn. System Poznańska Elektroniczna Karta Aglomeracyjna (PEKA) - spółce BULL POLSKA sp. z o.o. opierając się o przyczyny techniczne o obiektywnym charakterze oraz konieczność ochrony praw wyłącznych, wynikającą z prawa autorskiego oraz prawa własności technologii. Dlatego podstawę prawną udzielenia przedmiotowego zamówienia w stosunku do części przedmiotu stanowi treść przepisu zawarta w art. 67 ust. 1 pkt 1) podpunkt a) ustawy Pzp, (przyczyny techniczne o obiektywnym charakterze), a do innej części zastosowanie ma treść przepisu z art. 67 ust. 1 pkt 1) podpunkt b) ustawy Pzp (przyczyny związane z prawami wyłącznymi). W stosunku jednak do większości elementów przedmiotu zamówienia będą miały zastosowanie obydwie podstawy prawne. Powierzenie zamówienia osobie trzeciej wiązałoby się z ryzykiem ingerencji osób trzecich w System i utratą praw z gwarancji, tym samym m.in. prawa Zamawiającego do żądania usuwania ewentualnych awarii. Warunki gwarancji oraz usługi Wykonawcy związane z utrzymaniem Systemu PEKA w stałej sprawności są jednymi z najważniejszych elementów umowy podstawowej oraz gwarantem prawidłowego funkcjonowania Systemu, tym samym komunikacji w mieście. Drugorzędne, ale również istotne znaczenie ma fakt utraty możliwości dochodzenia kar umownych i roszczeń wynikających z nieprawidłowego działania Systemu. Dopuszczenie osób trzecich doprowadziłoby do -rozmycia- odpowiedzialności chociażby za takie okoliczności jak awaria Systemu, która pociąga za sobą konsekwencje organizacyjne i techniczne komunikacji miejskiej oraz finansowe. Nieskuteczna stałaby się jednoznaczna identyfikacja przyczyn wszelkich awarii i adresata zobligowanego do ich usunięcia, nie wspominając o kosztach, których nie wiadomo od kogo należałoby dochodzić. Niemożliwe jest na tym etapie realizacji Systemu dopuszczenie osób trzecich, gdyż wiązałoby się to z ogromnym zagrożeniem funkcjonowania całego Systemu PEKA. Ryzyko dla Systemu i funkcjonowania komunikacji byłoby ogromne. Kolejnym ważnym argumentem uzasadniającym, że niemożliwe jest udzielenie zamówienia w trybie konkurencyjnym jest fakt konieczności dostępu do kodów źródłowych, brak dostępu do technologii poufnych firmy BULL, oraz na chwilę obecną nie przekazane jeszcze prawa autorskie. Czynności stanowiące przedmiot zamówienia wymagają ingerencji w system bazy danych stanowiący przedmiot umowy głównej. Baza danych zawiera informacje poufne i wrażliwe - Zamawiający nie jest w stanie ocenić, czy i ewentualnie które jej elementy oraz w jaki sposób można byłoby udostępnić osobie trzeciej bez naruszenia prawa. Ze względów oczywistych konieczne szkolenia ze stworzonych funkcjonalności może dokonać jedynie ich twórca. Po pierwsze, ze względów opisanych powyżej, po wtóre tylko on może prowadzić prawidłowe obserwacje, identyfikować potrzeby, ewentualne braki lub możliwości oraz skutecznie wspierać przedstawicieli zamawiającego, osoby korzystające i zarządzające poprzez odpowiednie szkolenia, instrukcje i współpracę techniczną. Zadania stanowiące przedmiot zamówienia wymagają działania w istniejącej aplikacji i wymagają ingerencji w kody źródłowe. Działanie osób trzecich wiązałoby się z utratą gwarancji. Nie jest możliwe powierzenie tych zadań osobom trzecim ze względu na prawa wyłączne firmy Bull. Działania w ramach udzielonego zamówienia wymagają ingerencji w istniejące dedykowane oprogramowanie, technologię stanowiącą tajemnicę przedsiębiorstwa spółki Bull Polska. Zważywszy na powyższe konieczne jest udzielenie przedmiotowego zamówienia z zastosowaniem trybu z wolnej ręki dotychczasowemu wykonawcy Systemu Poznańska Elektroniczna Karta Aglomeracyjna (PEKA) - BULL POLSKA sp. z o.o. na podstawie art. 67 ust.1 pkt 1) podpunkt a) i b) Pzp. Udzielenie zamówienia nie narusza naczelnych zasad Prawa zamówień publicznych - zasady konkurencyjności i równego traktowania wykonawców. Stanowi wydatek racjonalny, oszczędny oraz zgodny z przepisami Ustawy prawo zamówień publicznych.