Jak Urząd kupuje system?

Czy powrócimy do procedury otwierania kopert z cenami tylko dla ofert ocenionych technicznie jako dobre? Czy Zamawiający potrafią lepiej skorzystać z ograniczonej możliwości weryfikacji podmiotowej w procedurze dopuszczania do przetargu ograniczonego? Oto niektóre pytania, które nasuwają się po lekturze artykułu, "Konstelacja spod psiej gwiazdy" Zbigniewa Olejniczaka, twórcy koncepcji systemu "Syriusz" mającego zastąpić systemy PULS i POMOST.

Tandeta

Czas do daty startu systemu upływa stale. Upływa też przed ogłoszeniem przetargu i w trakcie procedury zakupu. Data startu przeważnie jest datą sztywną, gdyż nikt nie przesunie początku roku budżetowego. Czas, faktycznie przeznaczony na realizację, nie może być bezkarnie skracany z jakiegokolwiek powodu. Skutkiem skracania realizacji jest tandeta. Jeśli w warunkach przetargu widoczne jest nierealne oszacowanie czasu, to poważni wykonawcy nie składają ofert lub doliczają kwotę ubezpieczenia ryzyka do ceny. Oba wyjścia promują tandetę i nieodpowiedzialnych sprzedawców.

Znane są przypadki (np. CEPiK), gdzie większość czasu przewidzianego przez ustawodawcę na stworzenie systemu została skonsumowana przed ogłoszeniem SIWZ na procedury przygotowawcze i poszukiwanie budżetu. Jeszcze śmieszniejszy był przetarg na portal dla Ministerstwa Finansów ogłoszony za min. Kołodki. Znakomita specyfikacja techniczna została wprasowana w czas na realizację do 31 grudnia! Zwycięska firma podpisała umowę 29 grudnia, by dać się wyrzucić za niewykonanie zadania w terminie zaraz po 2 stycznia.

Takie same cechy można deklarować lub wykazać. Formę wybiera twórca SIWZ. Większość wystawi tabelkę sprawdzającą, pytając: Czy oferowane oprogramowanie może (...)? Tak. Oczywiście, że może(...) - odpowie handlowiec premiowany za sprzedaż, mimo że naprawdę ta możliwość należy do kategorii far futures. Ryzyko wpadki nie istnieje, gdyż u Zamawiającego weryfikują to prawnicy, którzy badają jedynie zgodność tekstów, nie zaś oczywiste fakty.

A gdyby zapytać w SIWZ: Proszę podać przykład instalacji oferowanego oprogramowania, pracującej produktywnie w języku polskim, w której wykorzystywana jest (...)? Pracy trochę więcej, lecz pole dla swobodnego uprawiania popularnego gatunku literackiego zwanego sales fiction zanika. A w razie domniemania nieprawdy jest szansa na sprawdzenie.

Prawa własności do oprogramowania

Prawnik wie, że bez praw do oprogramowania jest w niewoli jego twórcy. Żąda więc przekazania kupującemu praw do oprogramowania. Paradoksalnie skutkuje to wyłączeniem z gry wszystkich poważnych dostawców, sprzedających oprogramowanie wielu klientom. Tanie oddanie prawa własności biednemu urzędowi oznacza zamknięcie biznesu z tym produktem i faktyczne przejęcie odpowiedzialności za produkt przez urząd.

Ale czy można tę potrzebę spełnić inaczej? Oczywiście tak. Wystarczy wymagać od wykonawcy, by stworzył możliwości samodzielnego obsługiwania systemu przez Zamawiającego lub podmiot zastępczy, przez niego wskazany.

Producent oprogramowania musi przekazać Zamawiającemu pełny kod źródłowy oprogramowania wraz z mechanizmem automatycznego utrzymywania zgodności kodu z wersją wykonywalną, niezależnie od pochodzenia poprawek i modyfikacji lub rozszerzeń. Wiadomo, że każdy duży system ma megabajty zmian miesięcznie.

Oferent musi przekazać Zamawiającemu licencjonowane środowisko rozwojowe z licencjami uprawniającymi do prowadzenia pełnego cyklu prac nad modyfikacjami lub rozszerzeniem funkcjonalności, a także upoważnienie kontraktowe do wprowadzania zmian w systemie, bez umniejszania praw Zamawiającego dotyczących niezmienionych części oprogramowania. Jakiekolwiek ograniczenia w tym względzie winny eliminować oferenta.

Warto wprowadzić do kryteriów wyboru wykonawcy sprawdzenie, czy jest na rynku dostateczna liczba firm wdrożeniowych, mających personel o kwalifikacjach potwierdzonych przez producenta oprogramowania. Gdy takich firm brak, lub jest ich mniej niż np. 10 niezależnych podmiotów, to mamy niedostateczne szanse na właściwe usługi, zastępujące producenta w konserwacji oprogramowania polegającej też na obsłudze kodu źródłowego, gdyby producenta dotknął zły los. W ostatnich latach zostały zlikwidowane lub upadłość ogłosiły liczne firmy informatyczne. W Polsce takie jak TCH, Tornado 2000, 2Si, czy też wrocławskie JTT i STGroup czy operator internetowy Formus.

Rozrzutność biedaka

Producenci oprogramowania realizują gwarancję poprzez tzw. asystę techniczną, ujmującą (razem lub odrębnie) serwis oprogramowania i dostarczanie nowych wersji. Dystrybutor musi doliczyć do kwoty licencji ponad 20% za każdy rok gwarancji, wliczając w to okres korzystania z oprogramowania poświęcony na wdrożenie. Konkurs na jak najdłuższą gwarancję, jako kryterium oceny ofert, jest dramatyczną pomyłką. Oznacza dobrowolne opłacanie przyszłych kosztów bieżących z góry, z budżetu inwestycji. Tak maleją faktyczne środki inwestycyjne, a Urzędnik, nieświadom skutków własnych pomysłów, chodzi w blasku chwały!

Programować czy użyć standardu?

Urzędnik wie, że jego instytucja jest wyjątkowa. Metodyki projektów informatycznych są zwykle opracowane wokół procesu budowy oprogramowania. Wdrażanie systemów gotowych, standardowych, wymaga specyficznej metodyki. Informatyk po szkole jej nie zna. Stąd w licznych specyfikacjach przetargowych tak silne nastawienie na programowanie.

Cóż z tego, że zakup standardowego systemu oznacza możliwość skorzystania z wiedzy i wzorcowych procesów gospodarczych i administracyjnych z tysięcy organizacji. Około 90% procesów jest absolutnie standardowe w danej klasie organizacji. Zakup systemu standardowego powoduje wybór oprogramowania profesjonalnie przetestowanego, nieograniczonego funkcjonalnie do odtwarzania stanu aktualnego zgodnie z SIWZ. Uniezależnia zamawiającego od pojedynczego autora lub ich małej grupy. Minimalizuje ryzyko niepowodzenia projektu. Wreszcie daje przyszłą pełną możliwość skorzystania, bez dodatkowych działań integratorskich, z tysięcy standardowych funkcji i procesów, dziś nieleżących w zakresie zamówienia.

Jarosław Konieczny jest pracownikiem koncernu informatycznego.