Tym razem kilka komentarzy do rekomendacji PZP. Najpierw to:
Art. 29 ust. 1 ustawy PZP nakłada na zamawiającego obowiązek opisania przedmiotu zamówienia w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględnienia wszystkich wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty. Zapis ten służy realizacji ustawowych zasad uczciwej konkurencji a co za tym idzie zasady równego dostępu do zamówienia, wyrażonych art. 7 ust. 1 ustawy Pzp. (Źródło: Urząd Zamówień Publicznych – Opinia dotycząca opisu przedmiotu zamówienia).
Spotykam się z tezami, że nie można używać notacji UML, BPMN itp. jako jedynej, że mino to musi być “opis słowny”. Otóż Art.22. mówi miedzy innymi, że “Warunki udziału w postępowaniu mogą dotyczyć […] 3) zdolności technicznej lub zawodowej.” co oznacza, że można od wykonawcy żądać określonych umiejętności, np. znajomości powszechnie używanych w danej branży języków notacyjnych (w szczególności opisanych na www.omg.org). Tak więc mając na uwadze
Art. 31. 1. Zamawiający opisuje przedmiot zamówienia na roboty budowlane za pomocą dokumentacji projektowej oraz specyfikacji technicznej wykonania i odbioru robót budowlanych.
i biorąc pod uwagę fakt, że roboty budowlane to jedyne, wymienione wprost w PZP, usługi o charakterze inżynieryjno-technicznym, można wywodzić, że inne o tym samym charakterze usługi, podlegają analogicznym regułom. Tak więc można opisać przedmiot zamówienia “za pomocą dokumentacji projektowej oraz specyfikacji technicznej”. Projektowanie i wytwarzanie oprogramowanie, jako inżynieria, podlega analogicznym regułom.
Z uwagi na specyfikę projektów związanych z dostarczaniem technologii IT, UZP opublikował dokument zatytułowany: UDZIELANIE ZAMÓWIEŃ PUBLICZNYCH NA SYSTEMY INFORMATYCZNE REKOMENDACJE (Urząd Zamówień Publicznych 2009 r.). Wybrałem i skomentowałem kilka, odnoszących się do kwestii opisu zamawianego oprogramowania. Warto też podkreślić, że poniższe rekomendacje UZP i moje uwagi zachowują sens także dla podmiotów nie podlegających PZP.
Rekomendacja 4.1.2.
Zamawiającym rozwijającym i utrzymującym systemy informatyczne o znacznej wartości zaleca się opracowanie tzw. polityki rozwoju systemów informatycznych. Polityka rozwoju systemów informatycznych winna określać zasady jakimi zamierza kierować się zamawiający w rozwoju systemów informatycznych. Dokument ten może obejmować w szczególności:
- wymagania odnośnie opracowywania i utrzymania planów rozwoju systemów informatycznych;
- zasady kształtowania architektury systemu;
- zasady określania i egzekwowania wymagań jakościowych;
- wymagania względem zdolność systemów do wymiany danych z innymi systemami (interoperabilność systemów);
- zakres praw przenoszonych przez wykonawcę na zamawiającego w toku realizacji zamówień na systemy informatyczne;
- wymagania odnośnie dokumentacji systemu;
- opis zasad udzielania zamówień na systemy informatyczne;
- inne istotne zasady, którym powinien podlegać rozwój systemów informatycznych.
Polityka rozwoju systemów informatycznych powinna podkreślać i wspierać konkurencyjne udzielanie zamówień na systemy informatyczne i ich rozbudowę.
Taka polityka, to część strategii, tę trzeba jednak mieć. Należy się zgodzić z autorami Rekomendacji, że zamówienia ad-hoc to bardzo zła praktyka. Rozwiązaniem jest stworzenie strategii wraz z politykami, w tym z polityką budowy i rozwoju systemu (opisałem to przy okazji architektury biznesowej).
Rekomendacja 4.3.1.
4.3.1. Wprowadzenie problemowe. Analizując funkcjonowanie systemów informatycznych w podmiotach podlegających PZP można z grubsza wyróżnić następujące fazy:
- Fazę koncepcyjną ? dotyczy ona wszystkich czynności związanych z określeniem potrzeb, przeglądem dostępnych rozwiązań, oceną możliwości ich zrealizowania u zamawiającego;
- Faza wyboru wykonawcy ? obejmuje czynności zmierzające do wyłonienia Wykonawcy wyspecyfikowanego systemu zwieńczone podpisaniem umowy z Wykonawcą;
- Faza wykonania i odbioru ? obejmuje realizację umowy z Wykonawcą zakończone odbiorem zamówionego systemu i wprowadzeniem go do bieżącej eksploatacji;
- Faza eksploatacji i dalszego rozwoju ? zbudowany system jest użytkowany przez Zamawiającego i administrowany przez odpowiednie służby Zamawiającego lub przez wybranego w tym celu Wykonawcę. Jednocześnie odbiór systemu w aktualnym stanie rzeczy rzadko stanowi koniec jego rozwoju; wręcz przeciwnie: systemy informatyczne są najczęściej stale rozwijane równolegle z ich eksploatacją. Zmiany wprowadzane w systemach informatycznych wynikają z pojawiania się nowych wymagań (np. w skutek zmiany przepisów), wykrycia i usuwania usterek itp.
Kluczowy wniosek: przed ogłoszeniem przetargu (!) na oprogramowanie i wyłonieniem jego wykonawcy, należy opracować koncepcję całego wdrożenia czyli także opisać wymagane rozwiązanie, w tym wdrożenie zmian organizacyjnych wynikających z faktu zakupu nowego narzędzia pracy co opisałem w marcu tego roku.
Rekomendacja 4.5.1.
Podział systemów informatycznych organizacji zamawiającego na wyodrębnione interfejsami i działające w oparciu o niezależne struktury danych systemy przy zachowaniu spójności aplikacji / podsystemów oraz racjonalnej i zarządzalnej liczbie powiązań między wyodrębnionymi systemami. […] Zamawiającym dysponującym / rozwijającym systemy o znacznej wartości zaleca się posiadanie opracowanej koncepcji architektury systemów informatycznych, zgodnie z którą powinny być rozwijane systemy informatyczne.
Tu konsekwencje powyższego. Raz, że konieczna jest koncepcja całości, dwa rekomendowane są wdrożenia dziedzinowych systemów i ich integracja zamiast pojedynczych mega-wdrożeń. O zaleceniu unikania wdrażania wielkich monolitycznych systemów pisałem już w 2011 roku (rekomendacje UZP pochodzą z 2009 roku).
Rekomendacja 4.7.3.
SIWZ i umowa z wykonawcą powinny sankcjonować obowiązek współpracy z wykonawcami innych, niezależnych (luźno powiązanych) podsystemów.
to jasno wskazuje, że dostawca nie może oczekiwać, że będzie monopolistą w zakresie dostarczanego systemu, nie może bojkotować autorów strategii itp. Jednak to:
Zaleca się aby SIWZ i umowa z wykonawcą określały obowiązek:
– przeniesienia w całości autorskich praw majątkowych do zakupywanego systemu, łącznie z prawem na udzielania zezwoleń na wykonywania zależnego prawa autorskiego. Zamawiający w zależności od swoich potrzeb powinien szczegółowo i jednoznacznie określić pola eksploatacji obejmujące autorskie prawa majątkowe (np. uprawniające zamawiającego do modyfikacji systemu, jego kodów źródłowych itp.);
– przeniesienie praw powinno dotyczyć również kodów źródłowych w stosunku do nowoutworzonego systemu, jego swobodnej modyfikacji. Jednocześnie, zamawiający powinien zobowiązać wykonawcę w umowie do wydania kodów źródłowych oraz pełnej dokumentacji technicznej systemu, najlepiej z chwilą odbioru przez zamawiającego systemu;
wymaga komentarza: nie jest to (przekazanie praw majątkowych do kodu) możliwe dla dostarczanego oprogramowania gotowego, standardowo dostępnego na rynku. Jednak jeżeli doprecyzujemy, że chodzi o system (komponent) dedykowany, to jak najbardziej mamy prawo i obowiązek, dbając o interes zamawiającego, żądania (zastrzegania) wszelkich praw na rzecz zamawiającego, to jak to zrobić w opisie przedmiotu zamówienia i umowie opisałem w artykule o prawach do kodu. Tu niestety znowu muszę zwrócić uwagę, że przedmiot zamówienia to opis techniczny i nie prawnik powinien decydować o tym jak powinien brzmieć a doświadczony projektant architekt.
Pominąłem tu kwestie organizacyjne i jakościowe bo te raczej rzadko stanowią problem, problemem są najczęściej kwestie funkcjonalności i sposobu ich specyfikowania. Pełna treść rekomendacji do pobrania:
