Nie zawsze bezbłędnie – jakie błędy najczęściej popełniają Zamawiający, ogłaszając przetarg na systemy informatyczne?
Zakup systemów informatycznych to złożony proces, który wymaga od zamawiających rzetelnego przygotowania. Niestety, bardzo często dochodzi do sytuacji w których zamawiający nie ma specjalistycznej wiedzy dotyczącej przedmiotu zamówienia – samodzielnie sporządzają SWZ, opisują przedmiot umowy oraz sporządzają wzór umowy, który nie jest dostosowany do systemu, który chce nabyć.
Jakie błędy najczęściej popełniają Zamawiający?
- Opis przedmiotu zamówienia:
- Często Zamawiający źle sporządzają opis przedmiotu zamówienia, który stanowi podstawowy element specyfikacji warunków zamówienia. Podstawowym obowiązkiem zamawiającego jest dokonanie opisu w sposób jednoznaczny i wyczerpujący. Oznacza to, że opis ten powinien zapewniać, że wykonawcy będą w stanie – bez dokonywania dodatkowych interpretacji – zidentyfikować, co jest przedmiotem zamówienia. Opis przedmiotu zamówienia powinien być sformułowany w taki sposób, aby pozwalał wykonawcom na przygotowanie oferty i obliczenie ceny. Tym samym, kalkulując cenę danego zamówienia, wykonawca, po przeczytaniu opisu przedmiotu zamówienia powinien dokładnie wiedzieć, co się na takie zamówienie składa oraz jakie elementy cenotwórcze musi on uwzględnić kalkulując taką cenę. Tylko w takim przypadku możliwe będzie złożenie porównywalnych ofert. Niejasności, czy niejednoznaczności opisu przedmiotu zamówienia prowadzić mogą do sytuacji, w której poszczególni wykonawcy wycenią całkiem inny zestaw elementów składających się na ofertę, co doprowadzi z kolei do sytuacji, w której oferty nie będą porównywalne, w szczególności np. oferta z najniższą ceną nie będzie ofertą najkorzystniejszą, gdyż po prostu jej niska cena będzie wynikiem braku ujęcia w cenie wszystkich niezbędnych elementów. Stąd też to w interesie każdego zamawiającego leży odpowiednio szczegółowe, dokładne i jednoznaczne opisanie przedmiotu zamówienia.
- Opisując przedmiot zamówienia dotyczący systemu informatycznego zamawiający powinien dokładnie wskazać, do jakich elementów dostarczanych w wyniku wdrożenia lub zainstalowania tego systemu chce uzyskać prawa do korzystania. Opisując zakres uprawnień zamawiający powinien w szczególności pamiętać o tym, że w wyniku wdrożenia systemu informatycznego powstaje zwykle nie tylko program komputerowy, ale także innego rodzaju produkty, które również mogą stanowić utwory chronione prawem autorskim, takie jak dokumentacja (w tym przewodniki, analiza przedwdrożeniowa, projekty techniczne, prezentacje), user stories, itp. Tym samym, zamawiający powinien wyraźnie w SWZ wskazać jakie uprawnienia chce uzyskać i do czego konkretnie – pamiętając także o uwzględnieniu dokumentacji i innych utworów niestanowiących programów komputerowych, które będą dostarczane zamawiającemu w ramach realizacji umowy będącej wynikiem przeprowadzonego zamówienia. Często dochodzi do sytuacji w których zamawiający nie wskazuje jakie jeszcze inne elementy składają się na przedmiot zamówienia albo nie zgadza się aby np. instrukcja dotycząca oprogramowania albo warunki gwarancji stanowiły załącznik do umowy.
- Zamawiający bardzo często nie mają świadomości tego, iż jeśli oczekują wydania przez wykonawcę kodów źródłowych do dostarczanych elementów lub całości systemu informatycznego powinien to jasno i wyraźnie wskazać w SWZ, opisując przy tym wymagania w odniesieniu do przekazywanych kodów źródłowych. Czym innym niż majątkowe prawo autorskie do korzystania z programowania jest faktyczny dostęp do kodów źródłowych tego oprogramowania, które są z technicznego punktu widzenia konieczne dla swobodnego modyfikowania i wprowadzania zmian w takim programie. Sposób zapisania kodów źródłowych stanowi bowiem często chronione know-how wykonawcy, a tym samym, konieczność ich wydania przez wykonawcę może być przez niego odrębnie wyceniana i może mieć znaczenia dla ofertowanej przez niego ceny na realizację danego zamówienia.
- Umowa
- Zamawiający bardzo często nie mają pojęcia jaka metodyka wdrożeniowa będzie stosowana przy danym projekcie. Należy pamiętać, że inaczej będzie wyglądać umowa opisująca wdrożenie realizowane zgodnie z metodyką kaskadową, a inaczej umowa opisująca wdrożenie w jednej z metodyk zwinnych lub mieszanych. Nierzadko dochodzi do sytuacji w których wzór umowy przygotowywany przez Zamawiającego nie może być zastosowany w danym przypadku.
- Zamawiający często nie wskazują jakiego rozwiązania oczekują. Czy ma to być dostarczenie rozwiązania on premises czy też rozwiązanie chmurowe. Np. jeśli zamawiający ogłosi postępowanie na oprogramowanie udostępniane w modelu chmury, a w ramach umowy wskaże oczekiwanie dotyczące przeniesienia praw autorskich, to podejrzewam, że żaden wykonawca nie zgłosi się do przetargu.
- Zamawiający bardzo często kumulują kary umowne za to samo zdarzenie (np. kumulowania kar umownych za przekroczenie dozwolonego czasu przywrócenia działania usługi, jeśli jednocześnie nalicza kary umowne za niedotrzymanie wymaganej dostępności). Co do zasady powinni tego unikać.
- Zgodnie z ustawą Prawo zamówień publicznych jednym elementów umowy powinno być wskazanie „łącznej maksymalnej wysokości kar umownych, których mogą dochodzić strony”. Niestety, bardzo często brakuje takiego zapisu w umowach przygotowywanych przez zamawiających. Sugerując dodanie takiego zapisu wykonawcy często dostają informację, że zamawiający nie wyraża na to zgody ze względu na to, że zapis ten naruszałby jego prawa.
- Przeniesienie praw/ licencja
- Zamawiający chcąc „jak najlepiej zabezpieczyć swoje interesy” często wymaga przeniesienia majątkowych praw autorskich. Należy jednak zwrócić uwagę, ze jeżeli przedmiot zamówienia obejmuje budowę rozwiązania od podstaw, poprzez wytworzenie nowego oprogramowania, specyficznego dla danego zamawiającego, to w pełni uzasadniona może być rekomendacja, by zamawiający nabył w jak najszerszym zakresie majątkowe prawa autorskie do stworzonego dla niego produktu. Jeżeli natomiast przedmiotem zamówienia jest oprogramowanie standardowe, które będzie w toku wdrożenia podlegało wyłącznie odpowiedniej konfiguracji, to oczekiwanie przez zamawiającego przeniesienia na niego majątkowych praw autorskich do takiego systemu jest zazwyczaj nieadekwatne i wielu wykonawców ze względu na powyższe nie wystartuje w przetargu. Powyższe wynika z tego, iż zamawiający bardzo często nie rozumieją jaka jest różnica pomiędzy oprogramowaniem bazowym, a dedykowanym.
- Bardzo często dochodzi do sytuacji w których przedmiotem świadczenia jest rozwiązanie o charakterze standardowym, a podmiot zainteresowany zawarciem umowy z zamawiającym nie jest jednocześnie producentem tego rozwiązania. Taki scenariusz może ziścić się w różnego rodzaju projektach. Przykładowo, może wystąpić w przypadku dostaw sprzętu komputerowego (sprzedawca nie musi być producentem świadczącym gwarancję), dostaw standardowego oprogramowania komputerowego (wykonawca często nie jest uprawniony do udzielenia bezpośrednio zamawiającemu licencji na korzystanie z oprogramowania) czy niektórych usług chmurowych (wykonawca biorący udział w postępowaniu nie zawsze dysponuje infrastrukturą niezbędną do ich świadczenia). Biorąc pod uwagę powyższe zróżnicowanie, Zamawiający powinien uwzględnić fakt, że rozwiązania dostępne w różnych modelach prawnych lub biznesowych mogą być względem siebie w pełni komplementarne, a wskazanie konkretnego modelu jako wymaganego, może okazać się dyskryminacyjne. Niestety, pomimo zadawania pytań naprowadzających zamawiającego na zmianę toku myślenia rzadko kiedy udaje się tą zmianę uzyskać, co doprowadza wielu wykonawców do rezygnacji z udziału w przetargu.
- Jeśli oczekiwaniem zamawiającego jest to, aby wykonawca przeniósł na niego majątkowe prawa autorskie, np. w odniesieniu do oprogramowania dedykowanego, powinien jasno i jednoznacznie wskazać w SWZ takie oczekiwanie wraz z wyjaśnieniem, co rozumie pod pojęciem oprogramowania dedykowanego oraz wyraźnym wskazaniem zakresu przeniesienia praw. Zaznaczenia wymaga jednocześnie fakt, że zamawiający zwykle dążą do nabycia majątkowych praw autorskich do poszczególnych elementów systemu w przypadku, w którym chcą nabyć poszczególne części systemu na własność i uzyskać niezależność od wykonawcy, w tym możliwość swobodnego modyfikowania i rozwoju oprogramowania.
- W związku bardzo różnymi modelami licencjonowania oprogramowania występującymi na rynku IT oraz sposobami udostępniania oprogramowania do korzystania, a także mając na uwadze przepis art. 66 pr. aut., zgodnie z którym umowa licencyjna uprawnia do korzystania z utworu na terytorium państwa, w którym licencjobiorca ma swoją siedzibę, chyba że w umowie postanowiono inaczej, zamawiający powinien jasno wskazać wymagania co do zakresu terytorialnego korzystania z systemu informatycznego, dostosowując wymagania do swoich rzeczywistych potrzeb. Tym samym, jeśli oczekiwaniem zamawiającego jest to, aby zamawiający mógł instalować system informatyczny w dowolnym miejscu, w tym, aby system mógł być instalowany w chmurze obliczeniowej – zamawiający powinien jasno wyrazić takie oczekiwanie w SWZ, może mieć ono bowiem znaczenie dla ustalenia ceny przez wykonawcę. Podobnie również, jeśli oczekiwaniem zamawiającego jest to, aby użytkownicy systemu informatycznego mogli korzystać z systemu – bez względu na ich lokalizację, czyli bez żadnych ograniczeń terytorialnych, to również kwestia ta powinna być wskazana przez zamawiającego w wymaganiach SWZ.
Oczywiste jest bowiem to, że wykonawcy IT oferujący standardowe rozwiązania IT i czerpiący dochody z udzielania licznych licencji na korzystanie z takiego oprogramowania nie będą zainteresowani przenoszeniem majątkowych praw autorskich do takiego oprogramowania na zamawiającego, bo przeniesienie takie wykluczyłoby dalszą możliwość licencjonowania takiego oprogramowania.
- Bardzo często zdarzają się również sytuację, w których zamawiający wiedząc, że wykonawca nie jest producentem danego systemu wymaga zupełnie innych warunków licencyjnych niż te, których udziela producent. Ze względu na powyższe wielu wykonawców nie decyduje się na wzięcie udziału w przetargu albo z niego rezygnuje.
- Gwarancja
Zamawiający często żądając gwarancji nie bada rynku pod tym kątem jakiej gwarancji udziela producent. Przez co często dochodzi do sytuacji w której zamawiający domaga się udzielenia gwarancji na okres dłuższy niż gwarancja producenta. Również często dochodzi do sytuacji w których na naprawę oprogramowania zamawiający wyznacza 3 dniowy okres, co jest w przypadku wielu wykonawców niewykonalne. Za każdy dzień opóźnienia zamawiający chce nakładać kary.
Zamawiając sprzęty informatyczne, zamawiający często nie biorą pod uwagę tego, że serwisy danych urządzeń znajdują się za granicą. Z czym wiąże się wydłużenie czasu naprawy danego sprzętu ze względu na jego transport np. do Francji. Identycznie kształtuje się sytuacja z dostępnością części do danego sprzętu. Wpisując w umowie, że części do danego urządzenia mają być dostępne przez okres np. 10 lat (przy takim rozwoju elektroniki!) zniechęcają jedynie wielu wykonawców do wystartowania w przetargu.
Podsumowując, przygotowanie treści projektowanych postanowień umowy bez dogłębnej wiedzy o przedmiocie zamówienia oraz przebiegu jego realizacji, jest błędem, na który nie może sobie pozwolić żaden zamawiający. Dotyczy to co prawda większości branż, jednak szczególnie w wypadku zamówień na systemy informatyczne, nie można pozwolić sobie na przygotowanie projektu umowy w oderwaniu od realiów przedmiotu zamówienia. Dlatego tak ważne jest żeby przy pracy nad SWZ, opisem przedmiotu zamówienia czy projektem umowy pracowali specjaliści, którzy będą zwracali również uwagę na pytania do SWZ zadawane przez wykonawców, a nie odrzucali proponowane przez nich zmiany bez dogłębnej analizy.