Kasterski i Wspólnicy

Kancelaria Prawnicza Spółka komandytowa

Przetarg na IT, duży i mały...


Przetargi na systemy IT podzielić trzeba w pierwszej kolejności na publiczne (realizowane w oparciu o przepisy Prawa zamówień publicznych) i niepubliczne (organizowane przez zamawiających, których ustawodawca nie uszczęśliwił rygorami PZP). Nie zajmuję się w tym wpisie też dostawami sprzętu (komputerów, drukarek) czy dostawami oprogramowania standardowego (np. biurowego) bez jego wdrożenia, bo one mają też nieco inną specyfikę. Dziś tylko o przetargach na systemy w ramach których wykonawca ma dostarczyć i wdrożyć oprogramowanie dedykowane dla potrzeb konkretnego klienta oraz przetargach, w których istotnym elementem zamówienia jest dostosowanie oprogramowania do potrzeb klienta oraz jego wdrożenie. Poniższe uwagi dotyczą też postępowań na tzw. utrzymanie systemu.

Już pobieżny przegląd ogłoszeń prowadzi do wniosku, że postępowania na zakup rozwiązań informatycznych podzielić można na dwie duże grupy – na przetargi wyraźnie adresowane przez zamawiających do firm dużych oraz do firm małych.

Przy okazji wspomnijmy, że są jeszcze dwie grupy firm IT na rynku:
- średniacy, zwykle okazujący się za drodzy by coś wygrać w klasie okręgowej, za mali zaś, by startować samemu w superlidze. Zatem, albo pojawiają się w konsorcjach (lub jako podwykonawcy) albo obsadzają nisze (w których często posiadają unikalne referencje i kompetencje),
- wykonawcy całkiem mali, w tym firmy jedno lub kilkoosobowe. Wykonawcy tacy zwykle nie mają szans samemu ubiegać się o zamówienie, więc, jeśli mają po temu kwalifikacje, pełnią w dużych projektach role doradcze lub występują w roli podwykonawców, członków personelu etc.

Do kogo adresowany jest przetarg rozpoznać łatwo po wymaganiach, jakie stawia zamawiający w ogłoszeniu.

Półka wyższa – wymagany jest od wykonawców spory potencjał finansowy, wysokie obroty (rzędu kilkudziesięciu i więcej milionów zł rocznie), doświadczenia we wdrażaniu / utrzymaniu wielkich systemów, opartych o zróżnicowane, czasem unikalne na rynku, technologie. Wymagania określają też minimalny skład zespołu wykonawcy, w skład którego wchodzić ma kilku - kilkunastu specjalistów z różnych dziedzin, kwalifikujących się wieloletnim doświadczeniem zawodowym, posiadających na potwierdzenie kwalifikacji stosowne certyfikaty.

Wymagania stawiane wykonawcom w takich postępowaniach są niemal zawsze przedmiotem walki w KIO, wykonawcy ich niespełniający usiłują bowiem wykazać że są one zbyt wysokie, nie uzasadnione realnymi potrzebami i służyć mogą eliminowaniu konkurencji. Niezależnie od przyświecających zamawiającym motywacji, ustawienie poprzeczki na wysokim poziomie oznacza, że ostatecznie o zamówienie walczyć będzie najczęściej jedynie kilka największych firm (czasem tworzących konsorcja w celu łącznego spełnienia wyśrubowanych wymagań. Czasem w postępowaniach takich uczestniczą filie znanych koncernów międzynarodowych, o ile nie wyeliminuje ich trudny do zaakceptowania w korporacyjnej rzeczywistości podział ryzyka czy też oczekiwania zamawiającego odnośnie np. przeniesienia praw autorskich.

Oferowane w rezultacie takich postępowań ceny rozpoczynają się od poziomu kilku milionów, kończą na setkach milionów, harmonogramy projektów rozpisane bywają na okres kilku lat, w pracach uczestniczą zespoły składające się nawet z setek specjalistów. O niepowodzeniach takich projektów piszą gazety, jednak, co też trzeba przyznać, znakomita część informatycznej infrastruktury państwa zbudowanej w ten właśnie sposób po prostu działa (nawet jeśli z problemami lub też nie tak jak tego należałoby oczekiwać, czego jednak przyczyny są tematem na odrębny wpis). Emerytury są wypłacane, podatki naliczane, prawa jazdy i dowody osobiste wydawane itd., itd. I nawet jeśli przy kodowaniu czasem pracują studenci, to produkty ich pracy (zwykle) poddawane są wewnętrznej kontroli, oni sami (zwykle) są nadzorowani przez ludzi, którzy mają odpowiednie doświadczenie zaś wykonawca (zwykle) jest w stanie opanować pojawiające się kryzysy a przynajmniej nimi profesjonalnie zarządzać.

Półka niższa – tu wymagania wydają się łatwe do spełnienia dla niemal każdego, kto działa w tej branży na rynku, w oparciu o doświadczenia własne lub jedynie użyczone (na co pozwala prawo europejskie, a w ślad za nim również polskie). Tu, jako dowód posiadania kwalifikacji, wystarczają pojedyncze projekty, wymagane zespoły są często kilkuosobowe, wymagania finansowe żadne lub niewysokie. Konkurencja jest więc znacznie większa, odwołania rzadsze (bo wartość projektu nie uzasadnia ryzykowania utraty 15 tysięcy złotych tytułem opłaty), rokowania odnośnie sukcesu lub porażki projektu - trudniejsze. Wartość tych zamówień to od kilkudziesięciu do kilkuset tysięcy złotych – wielcy świata IT w ogóle nimi się nie interesują, ich ceny bowiem radykalnie wykraczają poza przeznaczony przez zamawiającego na dany cel budżet. Projekty takie rzadko budzą sensację i zwykle dobrze się kończą, o ile zamawiający nie popełni błędu zlecając wykonawcom z tej grupy przeprowadzenia projektu, który obiektywnie przekracza ich możliwości (z czego, niestety, czasem nikt z zainteresowanych nie zdawał sobie sprawy).

Problemy tu zaczynają się, gdy zamawiający zakupi tanio usługę, do wykonania której potrzebne są kompetencje niedostępne dla wybranego wykonawcy a budżet projektu nie pozwala na ich zakup od zewnętrznych konsultantów. Konsekwencje tego bywają opłakane. Rynek zna historie przypadków, kiedy kierownik projektu nie był w stanie ocenić jakości pracy swoich pracowników, zaangażowanych w licznych projektach, często dostępnych jedynie zdalnie. Nierzadkie są przypadki, gdy wykonawca projektując system opiera się wyłącznie na wiedzy teoretycznej, wynikającej z lektury dokumentacji a nie na doświadczeniach (najlepiej własnych). Liczne są projekty źle lub wcale nie zarządzane, prowadzone metodą pospolitego ruszenia. Zagrożeń dla projektu często nie jest świadomy ani wykonawca ani jego klient (a przynajmniej jego kierownictwo).

Kłopoty wynikające ze źle lub szczątkowo opisanych wymagań, źle przeprowadzonego etapu analitycznego, błędów w wyborze technologii, braku wiedzy o zachowaniu sprzętu i oprogramowania w rzeczywistym środowisku produkcyjnym, ograniczonej skalowalności, braku interoperacyjności, podatności na zagrożenia zewnętrzne, powodują, w najlepszym razie, przedłużające się w nieskończoność wdrożenie, gdyż zamawiający czasem dopiero w czasie testów odbiorczych dowiaduje się, co zamówił i jak bardzo to coś nie jest zgodne z jego potrzebami. Zwykle jednak kryzys rozpoczyna się wcześniej, czasem nawet już po pierwszym spotkaniu z wykonawcą po podpisaniu umowy. Gorzej, jeśli zamawiający o wpadce dowiaduje się już po starcie produkcyjnym systemu od jego użytkowników albo od dowcipnisiów wykorzystujących dziury w zabezpieczeniach. Wtedy często okazuje się, że nie tylko nie może liczyć na wsparcie wykonawcy (nie posiadającego kompetencji, zasobów ani minimum odpowiedzialności), ale nawet nie może, na pociechę, naliczyć kar umownych, gdyż system jest (formalnie) zgodny z zawartą umową…


Rafał Kasterski
blog comments powered by Disqus