Po kilku latach współpracy okazuje się, że formalnie można rozpisać nowe postępowanie, ale realnie tylko dotychczasowy wykonawca jest w stanie je wykonać. Każdy inny podmiot musiałby najpierw odtworzyć wiedzę o systemie, przejąć dokumentację, poznać środowisko i nauczyć się zależności, które często istnieją wyłącznie w głowach zespołu utrzymaniowego.
Tak właśnie rodzi się monopol wykonawcy – nie z powodu jakości jego usług, lecz przez błędnie skonstruowane zamówienie.
Błędy zamawiających, które prowadzą do monopolu
Najczęściej vendor lock-in nie jest skutkiem jednego błędu, ale serii zaniedbań po stronie zamawiającego. Pierwszym jest brak wymogu przekazania pełnej dokumentacji technicznej i repozytoriów kodu źródłowego. Drugim – dopuszczenie do sytuacji, w której wykonawca tworzy rozwiązanie w oparciu o zamknięte technologie, własne biblioteki i niestandardowe integracje. Trzecim – brak prawa do korzystania z kodu źródłowego, procedur wdrożeniowych, środowisk testowych czy instrukcji odtworzenia systemu. W efekcie urząd ma system, ale nie ma nad nim kontroli.
Czytaj też w LEX: Certyfikacja wykonawców – co się zmieni i jak się przygotować w praktyce >
Vendor lock-in szczególnie często występuje w zamówieniach na utrzymanie i rozwój systemów IT. Zamawiający chcą szybko wdrożyć rozwiązanie, więc skupiają się na cenie, harmonogramie i funkcjonalności. Rzadziej zadają pytanie, co stanie się za trzy lub pięć lat, gdy trzeba będzie zmienić wykonawcę albo ogłosić nowe postępowanie.
To właśnie wtedy pojawia się problem. Nowy wykonawca pyta o dokumentację, kod źródłowy, opis architektury, prawa autorskie, instrukcje wdrożenia, dostęp do środowisk i historię zmian. Zamawiający często nie ma niczego poza umową i kontaktem do poprzedniego wykonawcy.
Zobacz też w LEX: Podział ryzyk w umowie w sprawie zamówienia publicznego >
W praktyce oznacza to, że konkurencja staje się iluzoryczna. Formalnie postępowanie jest otwarte, ale realnie jedynie dotychczasowy wykonawca może złożyć ofertę bez ogromnego ryzyka. Inni wykonawcy kalkulują koszty wejścia, niepewność i konieczność odtwarzania wiedzy, po czym rezygnują z udziału. To z kolei prowadzi do wzrostu cen i osłabienia pozycji negocjacyjnej zamawiającego.
Utrzymanie systemów IT – moment, w którym problem wychodzi na jaw
Vendor lock-in nie jest więc wyłącznie problemem technicznym. To problem konkurencyjności rynku i racjonalnego wydatkowania środków publicznych. W Europie problem jest już dobrze rozpoznany. Według badań cytowanych przez ekspertów zajmujących się zamówieniami ICT, co najmniej 40 proc. zamawiających publicznych dostrzega zjawisko uzależnienia od jednego dostawcy, najczęściej z powodu braku interoperacyjności i przenoszalności danych.
Co ważne, vendor lock-in może wystąpić nawet wtedy, gdy system opiera się na rozwiązaniach open source. Sam otwarty kod nie wystarczy, jeśli tylko jeden wykonawca posiada wiedzę o architekturze, integracjach i sposobie utrzymania systemu. Badania dotyczące zamówień publicznych pokazują, że również w projektach open source pojawiają się miękkie formy uzależnienia – wynikające z braku dokumentacji, niewystarczających testów, ograniczonej komunikacji czy zbyt wygórowanych wymagań dla nowych wykonawców.
Czytaj też w LEX: Sztuczna inteligencja w administracji samorządowej >
Jak więc ograniczyć ryzyko vendor lock-in?
Po pierwsze, już na etapie opisu przedmiotu zamówienia należy wymagać przekazania pełnej dokumentacji technicznej, repozytoriów kodu źródłowego, instrukcji wdrożeniowych, konfiguracji środowisk oraz opisu integracji.
Po drugie, warto wymagać stosowania otwartych standardów, interoperacyjnych formatów danych i rozwiązań, które mogą być rozwijane przez różnych wykonawców. Proprietarne formaty i zamknięte interfejsy są jedną z głównych przyczyn uzależnienia od dostawcy.
Po trzecie, umowa powinna przewidywać obowiązek bieżącej aktualizacji dokumentacji oraz wsparcia przy przekazaniu systemu nowemu wykonawcy. Samo przekazanie kodu bez wiedzy o tym, jak go uruchomić, zbudować i utrzymywać, jest często niewystarczające.
Zobacz też w LEX: Informatyzacja podmiotów JST >
Po czwarte, warto rozważyć odpowiednie mechanizmy dla kodu źródłowego, szczególnie przy systemach krytycznych, polegają one na zdeponowaniu kodu, dokumentacji i materiałów technicznych u niezależnego podmiotu, który udostępni je zamawiającemu w przypadku upadłości wykonawcy, zaprzestania wsparcia lub innych określonych zdarzeń. Takie rozwiązanie chroni ciągłość działania i ogranicza ryzyko całkowitego uzależnienia od jednego dostawcy.
Po piąte, zamawiający powinien planować wyjście z relacji z wykonawcą już na etapie zawierania umowy. Paradoksalnie to właśnie dobra strategia zakończenia współpracy najlepiej zabezpiecza jej prawidłowy przebieg. Wskazuje się, że skuteczne ograniczenie vendor lock-in wymaga myślenia o migracji, przenoszalności danych i zmianie dostawcy od samego początku projektu.
Vendor lock-in nie powstaje dlatego, że wykonawca działa nieuczciwie. Powstaje dlatego, że zamawiający zbyt późno zaczyna myśleć o tym, co stanie się po zakończeniu współpracy.
A może zainteresuje cię w LEX: Centralny Rejestr Umów bez taryfy ulgowej! >
W zamówieniach publicznych nie wystarczy kupić system. Trzeba jeszcze zadbać o to, aby po kilku latach ktoś inny niż dotychczasowy wykonawca również był w stanie go rozwijać. Inaczej konkurencyjny przetarg staje się tylko formalnością, a monopol wykonawcy – nieuniknioną konsekwencją źle przygotowanego zamówienia.
Grzegorz Bebłowski, właściciel w Kancelarii Doradztwa Zamówień Publicznych
