POPC Wsparcie

Kryterium, które wnioskodawcom stwarza duże problemy, wiąże się z uzyskaniem praw do korzystania z oprogramowania w sposób zabezpieczający interesy wnioskodawcy. Ma ono zminimalizować vendor-locking, czyli uzależnienie się od konkretnych dostawców rozwiązań infrastrukturalnych, a tym samym zminimalizować koszty utrzymania i rozwoju produktów wytworzonych w ramach projektu. Jest to szczególnie ważne, bo brak planu działań, które zmniejszają ryzyko uzależnienia się od dostawcy oprogramowania, może doprowadzić do niekontrolowanego wzrostu kosztów utrzymania rozwiązania.

Vendor locking może wystąpić głównie w produktach projektu typu oprogramowanie. Uzależnienie się od fizycznej infrastruktury dostawcy jest minimalne z powodu standardów funkcjonowania takich urządzeń. W efekcie możemy łączyć urządzenia różnych producentów. Wyjątkiem w zakresie infrastruktury sprzętowej jest jej wynajem w modelu IaaS. Wtedy działania prewencyjne podejmujemy na zasadach podobnych jak przy kupnie oprogramowania.

By zmniejszyć ryzyko uzależnienia się od dostawcy oprogramowania, kupujemy system z modułów dziedzinowych od niezależnych dostawców, które powiąże ze sobą poprzez interfejsy API. W ten sposób stworzymy jeden zintegrowany system. W nim wymienimy pojedyncze moduły (funkcjonalności) bez konieczności wymiany całego systemu. Ten model jest jednak trudny do realizacji w obecnej sytuacji rynkowej dostawców oprogramowania. Dodatkowo wymaga w strukturach zamawiającego zespołu, który odpowiada za stworzenie i utrzymanie modelu danych dla całej organizacji. Dopiero taki model pozwoli opisać wymagania poszczególnych modułów (kupowanych jako osobne systemy), tak aby po ich integracji poprzez API (najlepiej na szynie danych) stworzyć docelowy system.

Obecnie przeważają jednak rozwiązania, w których jeden wykonawca dostarcza jeden system. System taki obejmuje wszystkie wymagane funkcjonalności, pomimo że są to często zupełnie różne dziedzinowo obszary, np. księgowość, magazyn, serwis internetowy – komunikacja z odbiorcami usług, kadry czy podatki. Z uwagi na uwarunkowania rynkowe często nie ma innego wyboru niż kupno właśnie jednego zintegrowanego systemu.

Niezależnie od wybranego przez wnioskodawcę modelu planowanego rozwiązania spośród opisanych powyżej wnioskodawca musi zadbać o kilka elementów w zakresie wymagań prawnych w stosunku do dostawcy oprogramowania. Już na etapie dokumentacji aplikacyjnej powinien zaplanować i wskazać sposób, w jaki zapewni sobie prawa majątkowe zarówno do kodów źródłowych, struktur baz danych, jak i dokumentacji.

Wnioskodawcy w ramach POPC większość zakupów robią na podstawie Prawa zamówień publicznych. Jedynym etapem, na którym mogą zagwarantować sobie prawa w przedmiotowym zakresie, jest postępowanie przetargowe.

Przy rozwiązaniu z oprogramowaniem typu COTS w dokumentacji przetargowej rozróżnijmy obszary poprzez zdefiniowanie pojęć (np. oprogramowanie COTS, oprogramowanie aplikacyjne), które pozwolą rozdzielić standardowe funkcjonalności dostarczane przez producenta oprogramowania typu COTS i funkcjonalności (tj. wszystkie zmiany) dokonywane przez wykonawcę zamówienia. Wtedy wykonawca spełni wymagania opisane poniżej dla części, której będzie autorem. Inaczej może zakwestionować prawo do przeniesienia praw majątkowych do kodu źródłowego oprogramowania COTS (najczęściej nie jest ich autorem) i w efekcie poniższe wymagania nie będą uzasadnione.

By ograniczyć ryzyko uzależnienia się od dostawcy oprogramowania, wnioskodawca w dokumentacji aplikacyjnej powinien wykazać, że w ramach przyszłych umów zawieranych z wykonawcami wyłonionymi w ramach przetargu uwzględni następujące obszary dotyczące pozyskania praw majątkowych:

• kodów źródłowych tych elementów oprogramowania, które zostanie wytworzone przez wykonawców systemu
• do dokumentacji technicznej oraz praw majątkowych do tej dokumentacji, obejmującej wszystkie elementy rozwiązania z wyjątkiem oprogramowania typu COTS
• do dysponowania strukturami baz danych
• do dysponowania elementami baz danych: procedury składowane, widoki, tabele, perspektywy itp.
• do bezpośredniego dostępu do bazy danych i możliwości przekazywania danych jako kopii bazy danych
• do dysponowania dokumentacją, w tym udostępniania jej podmiotom trzecim
• do wykonywania kopii bezpieczeństwa całego rozwiązania
• do wykorzystania oprogramowania do promowania całego rozwiązania – publicznych prezentacji
• do aktualizacji elementów rozwiązania do zmian przepisów prawa powszechnie obowiązującego, w tym przez zlecanie realizacji tych modyfikacji podmiotom trzecim
• do uzyskania kopii wszystkich danych w określonym standardzie z chwilą zakończenia trwania umowy w projekcie, w którym infrastrukturę fizyczną kupimy w modelu IaaS, PaaS lub SaaS (czyli w chmurze). W ten sposób jesteśmy pewni, że dane przechowywane na obcej infrastrukturze są naszą własnością, a dane w określonym standardzie dostaniemy z chwilą (tuż przed) zakończenia obowiązywania umowy pomiędzy nami a dostawcą usług. Pozwoli to na ewentualną migrację systemu do innego dostawcy usług chmurowych

Przy kupnie oprogramowania typu COTS i licencji zamkniętych rozważmy premiowanie w postępowaniu wykonawców czy dostawców zapewniających, np.

• dłuższy okres bezpłatnego serwisu posprzedażowego
• możliwość upgrade'u oprogramowania lub licencji na zasadach producenta oprogramowania COTS, niezbędnego do poprawnego świadczenia e-usługi będącej przedmiotem projektu w dłuższym okresie
• szkolenia albo transfer wiedzy na rzecz zespołu zamawiającego
• bezpłatne przeglądy lub audyty oprogramowania
• zmiany w systemie w zakresie dostosowywania do zmieniających się przepisów prawa powszechnie obowiązującego. Monitorowanie zmian prawnych i aktualizacja systemu są obowiązkiem wykonawcy, zmiany są przeprowadzone z chwilą wejście w życie danego przepisu
• oferowanie zamawiającemu nowych wersji systemu z inicjatywy wykonawcy
• zapewnienie optymalnego sposobu licencjonowania oprogramowania – jeśli kupujemy rozwiązanie z oprogramowaniem typu COTS, osobno określamy liczbę licencji dla komponentu COTS, a osobno dla tej części, którą wykonuje samodzielnie wykonawca (elementy, które są modyfikowane/dostosowywane/dopisywane), wykonawca powinien dostarczyć wszystkie elementy wykonywanego przez siebie oprogramowania na licencji na nieograniczoną liczbę użytkowników i bez ograniczeń obszaru, na którym licencje są wykorzystywane, a także z prawem udzielania sublicencji dla podmiotów zależnych od zamawiającego

Autorzy: Magdalena Krawczuk, Wojciech Ciesielski

 

Artykuły powiązane: