Tym razem kil­ka komen­ta­rzy do reko­men­da­cji PZP. Najpierw to: 

Art. 29 ust. 1 usta­wy PZP nakła­da na zama­wia­ją­ce­go obo­wią­zek opi­sa­nia przed­mio­tu zamó­wie­nia w spo­sób jed­no­znacz­ny i wyczer­pu­ją­cy, za pomo­cą dosta­tecz­nie dokład­nych i zro­zu­mia­łych okre­śleń, uwzględ­nie­nia wszyst­kich wyma­gań i oko­licz­no­ści mogą­cych mieć wpływ na spo­rzą­dze­nie ofer­ty. Zapis ten słu­ży reali­za­cji usta­wo­wych zasad uczci­wej kon­ku­ren­cji a co za tym idzie zasa­dy rów­ne­go dostę­pu do zamó­wie­nia, wyra­żo­nych art. 7 ust. 1 usta­wy Pzp. (Źródło: Urząd Zamówień Publicznych – Opinia doty­czą­ca opi­su przed­mio­tu zamówienia).

Spotykam się z teza­mi, że nie moż­na uży­wać nota­cji UML, BPMN itp. jako jedy­nej, że mino to musi być ​„opis słow­ny”. Otóż Art.22. mówi mie­dzy inny­mi, że ​„Warunki udzia­łu w postę­po­wa­niu mogą doty­czyć […] 3) zdol­no­ści tech­nicz­nej lub zawo­do­wej.” co ozna­cza, że moż­na od wyko­naw­cy żądać okre­ślo­nych umie­jęt­no­ści, np. zna­jo­mo­ści powszech­nie uży­wa­nych w danej bran­ży języ­ków nota­cyj­nych (w szcze­gól­no­ści opi­sa­nych na www​.omg​.org). Tak więc mając na uwadze 

Art. 31. 1. Zamawiający opi­su­je przed­miot zamó­wie­nia na robo­ty budow­la­ne za pomo­cą doku­men­ta­cji pro­jek­to­wej oraz spe­cy­fi­ka­cji tech­nicz­nej wyko­na­nia i odbio­ru robót budowlanych.

i bio­rąc pod uwa­gę fakt, że robo­ty budow­la­ne to jedy­ne, wymie­nio­ne wprost w PZP, usłu­gi o cha­rak­te­rze inży­nie­ryj­no-tech­nicz­nym, moż­na wywo­dzić, że inne o tym samym cha­rak­te­rze usłu­gi, pod­le­ga­ją ana­lo­gicz­nym regu­łom. Tak więc moż­na opi­sać przed­miot zamó­wie­nia ​„za pomo­cą doku­men­ta­cji pro­jek­to­wej oraz spe­cy­fi­ka­cji tech­nicz­nej”. Projektowanie i wytwa­rza­nie opro­gra­mo­wa­nie, jako inży­nie­ria, pod­le­ga ana­lo­gicz­nym regułom. 

Z uwa­gi na spe­cy­fi­kę pro­jek­tów zwią­za­nych z dostar­cza­niem tech­no­lo­gii IT, UZP opu­bli­ko­wał doku­ment zaty­tu­ło­wa­ny: UDZIELANIE ZAMÓWIEŃ PUBLICZNYCH NA SYSTEMY INFORMATYCZNE REKOMENDACJE (Urząd Zamówień Publicznych 2009 r.). Wybrałem i sko­men­to­wa­łem kil­ka, odno­szą­cych się do kwe­stii opi­su zama­wia­ne­go opro­gra­mo­wa­nia. Warto też pod­kre­ślić, że poniż­sze reko­men­da­cje UZP i moje uwa­gi zacho­wu­ją sens tak­że dla pod­mio­tów nie pod­le­ga­ją­cych PZP. 

Rekomendacja 4.1.2. 

Zamawiającym roz­wi­ja­ją­cym i utrzy­mu­ją­cym sys­te­my infor­ma­tycz­ne o znacz­nej war­to­ści zale­ca się opra­co­wa­nie tzw. poli­ty­ki roz­wo­ju sys­te­mów infor­ma­tycz­nych. Polityka roz­wo­ju sys­te­mów infor­ma­tycz­nych win­na okre­ślać zasa­dy jaki­mi zamie­rza kie­ro­wać się zama­wia­ją­cy w roz­wo­ju sys­te­mów infor­ma­tycz­nych. Dokument ten może obej­mo­wać w szczególności:

• wyma­ga­nia odno­śnie opra­co­wy­wa­nia i utrzy­ma­nia pla­nów roz­wo­ju sys­te­mów informatycznych;
• zasa­dy kształ­to­wa­nia archi­tek­tu­ry systemu;
• zasa­dy okre­śla­nia i egze­kwo­wa­nia wyma­gań jakościowych;
• wyma­ga­nia wzglę­dem zdol­ność sys­te­mów do wymia­ny danych z inny­mi sys­te­ma­mi (inte­ro­pe­ra­bil­ność systemów);
• zakres praw prze­no­szo­nych przez wyko­naw­cę na zama­wia­ją­ce­go w toku reali­za­cji zamó­wień na sys­te­my informatyczne;
• wyma­ga­nia odno­śnie doku­men­ta­cji systemu;
• opis zasad udzie­la­nia zamó­wień na sys­te­my informatyczne;
• inne istot­ne zasa­dy, któ­rym powi­nien pod­le­gać roz­wój sys­te­mów informatycznych.

Polityka roz­wo­ju sys­te­mów infor­ma­tycz­nych powin­na pod­kre­ślać i wspie­rać kon­ku­ren­cyj­ne udzie­la­nie zamó­wień na sys­te­my infor­ma­tycz­ne i ich rozbudowę.

Taka poli­ty­ka, to część stra­te­gii, tę trze­ba jed­nak mieć. Należy się zgo­dzić z auto­ra­mi Rekomendacji, że zamó­wie­nia ad-hoc to bar­dzo zła prak­ty­ka. Rozwiązaniem jest stwo­rze­nie stra­te­gii wraz z poli­ty­ka­mi, w tym z poli­ty­ką budo­wy i roz­wo­ju sys­te­mu (opi­sa­łem to przy oka­zji archi­tek­tu­ry biz­ne­so­wej). 

Rekomendacja 4.3.1. 

4.3.1. Wprowadzenie pro­ble­mo­we. Analizując funk­cjo­no­wa­nie sys­te­mów infor­ma­tycz­nych w pod­mio­tach pod­le­ga­ją­cych PZP moż­na z grub­sza wyróż­nić nastę­pu­ją­ce fazy:

1. Fazę kon­cep­cyj­ną ? doty­czy ona wszyst­kich czyn­no­ści zwią­za­nych z okre­śle­niem potrzeb, prze­glą­dem dostęp­nych roz­wią­zań, oce­ną moż­li­wo­ści ich zre­ali­zo­wa­nia u zamawiającego;
2. Faza wybo­ru wyko­naw­cy ? obej­mu­je czyn­no­ści zmie­rza­ją­ce do wyło­nie­nia Wykonawcy wyspe­cy­fi­ko­wa­ne­go sys­te­mu zwień­czo­ne pod­pi­sa­niem umo­wy z Wykonawcą;
3. Faza wyko­na­nia i odbio­ru ? obej­mu­je reali­za­cję umo­wy z Wykonawcą zakoń­czo­ne odbio­rem zamó­wio­ne­go sys­te­mu i wpro­wa­dze­niem go do bie­żą­cej eksploatacji;
4. Faza eks­plo­ata­cji i dal­sze­go roz­wo­ju ? zbu­do­wa­ny sys­tem jest użyt­ko­wa­ny przez Zamawiającego i admi­ni­stro­wa­ny przez odpo­wied­nie służ­by Zamawiającego lub przez wybra­ne­go w tym celu Wykonawcę. Jednocześnie odbiór sys­te­mu w aktu­al­nym sta­nie rze­czy rzad­ko sta­no­wi koniec jego roz­wo­ju; wręcz prze­ciw­nie: sys­te­my infor­ma­tycz­ne są naj­czę­ściej sta­le roz­wi­ja­ne rów­no­le­gle z ich eks­plo­ata­cją. Zmiany wpro­wa­dza­ne w sys­te­mach infor­ma­tycz­nych wyni­ka­ją z poja­wia­nia się nowych wyma­gań (np. w sku­tek zmia­ny prze­pi­sów), wykry­cia i usu­wa­nia uste­rek itp.

Kluczowy wnio­sek: przed ogło­sze­niem prze­tar­gu (!) na opro­gra­mo­wa­nie i wyło­nie­niem jego wyko­naw­cy, nale­ży opra­co­wać kon­cep­cję całe­go wdro­że­nia czy­li tak­że opi­sać wyma­ga­ne roz­wią­za­nie, w tym wdro­że­nie zmian orga­ni­za­cyj­nych wyni­ka­ją­cych z fak­tu zaku­pu nowe­go narzę­dzia pra­cy co opi­sa­łem w mar­cu tego roku. 

Rekomendacja 4.5.1.

Podział sys­te­mów infor­ma­tycz­nych orga­ni­za­cji zama­wia­ją­ce­go na wyod­ręb­nio­ne inter­fej­sa­mi i dzia­ła­ją­ce w opar­ciu o nie­za­leż­ne struk­tu­ry danych sys­te­my przy zacho­wa­niu spój­no­ści apli­ka­cji / pod­sys­te­mów oraz racjo­nal­nej i zarzą­dzal­nej licz­bie powią­zań mię­dzy wyod­ręb­nio­ny­mi sys­te­ma­mi. […] Zamawiającym dys­po­nu­ją­cym / roz­wi­ja­ją­cym sys­te­my o znacz­nej war­to­ści zale­ca się posia­da­nie opra­co­wa­nej kon­cep­cji archi­tek­tu­ry sys­te­mów infor­ma­tycz­nych, zgod­nie z któ­rą powin­ny być roz­wi­ja­ne sys­te­my informatyczne. 

Tu kon­se­kwen­cje powyż­sze­go. Raz, że koniecz­na jest kon­cep­cja cało­ści, dwa reko­men­do­wa­ne są wdro­że­nia dzie­dzi­no­wych sys­te­mów i ich inte­gra­cja zamiast poje­dyn­czych mega-wdro­żeń. O zale­ce­niu uni­ka­nia wdra­ża­nia wiel­kich mono­li­tycz­nych sys­te­mów pisa­łem już w 2011 roku (reko­men­da­cje UZP pocho­dzą z 2009 roku). 

Rekomendacja 4.7.3.

SIWZ i umo­wa z wyko­naw­cą powin­ny sank­cjo­no­wać obo­wią­zek współ­pra­cy z wyko­naw­ca­mi innych, nie­za­leż­nych (luź­no powią­za­nych) podsystemów. 

to jasno wska­zu­je, że dostaw­ca nie może ocze­ki­wać, że będzie mono­po­li­stą w zakre­sie dostar­cza­ne­go sys­te­mu, nie może boj­ko­to­wać auto­rów stra­te­gii itp. Jednak to:

Zaleca się aby SIWZ i umo­wa z wyko­naw­cą okre­śla­ły obowiązek:

- prze­nie­sie­nia w cało­ści autor­skich praw mająt­ko­wych do zaku­py­wa­ne­go sys­te­mu, łącz­nie z pra­wem na udzie­la­nia zezwo­leń na wyko­ny­wa­nia zależ­ne­go pra­wa autor­skie­go. Zamawiający w zależ­no­ści od swo­ich potrzeb powi­nien szcze­gó­ło­wo i jed­no­znacz­nie okre­ślić pola eks­plo­ata­cji obej­mu­ją­ce autor­skie pra­wa mająt­ko­we (np. upraw­nia­ją­ce zama­wia­ją­ce­go do mody­fi­ka­cji sys­te­mu, jego kodów źró­dło­wych itp.);

- prze­nie­sie­nie praw powin­no doty­czyć rów­nież kodów źró­dło­wych w sto­sun­ku do nowo­utwo­rzo­ne­go sys­te­mu, jego swo­bod­nej mody­fi­ka­cji. Jednocześnie, zama­wia­ją­cy powi­nien zobo­wią­zać wyko­naw­cę w umo­wie do wyda­nia kodów źró­dło­wych oraz peł­nej doku­men­ta­cji tech­nicz­nej sys­te­mu, naj­le­piej z chwi­lą odbio­ru przez zama­wia­ją­ce­go systemu;

wyma­ga komen­ta­rza: nie jest to (prze­ka­za­nie praw mająt­ko­wych do kodu) moż­li­we dla dostar­cza­ne­go opro­gra­mo­wa­nia goto­we­go, stan­dar­do­wo dostęp­ne­go na ryn­ku. Jednak jeże­li dopre­cy­zu­je­my, że cho­dzi o sys­tem (kom­po­nent) dedy­ko­wa­ny, to jak naj­bar­dziej mamy pra­wo i obo­wią­zek, dba­jąc o inte­res zama­wia­ją­ce­go, żąda­nia (zastrze­ga­nia) wszel­kich praw na rzecz zama­wia­ją­ce­go, to jak to zro­bić w opi­sie przed­mio­tu zamó­wie­nia i umo­wie opi­sa­łem w arty­ku­le o pra­wach do kodu. Tu nie­ste­ty zno­wu muszę zwró­cić uwa­gę, że przed­miot zamó­wie­nia to opis tech­nicz­ny i nie praw­nik powi­nien decy­do­wać o tym jak powi­nien brzmieć a doświad­czo­ny pro­jek­tant architekt. 

Pominąłem tu kwe­stie orga­ni­za­cyj­ne i jako­ścio­we bo te raczej rzad­ko sta­no­wią pro­blem, pro­ble­mem są naj­czę­ściej kwe­stie funk­cjo­nal­no­ści i spo­so­bu ich spe­cy­fi­ko­wa­nia. Pełna treść reko­men­da­cji do pobrania:

(źr: https://​www​.uzp​.gov​.pl/​_​_​d​a​t​a​/​a​s​s​e​t​s​/​p​d​f​_​f​i​l​e​/​0​0​2​5​/​2​7​5​7​4​/​R​e​k​o​m​e​n​d​a​c​j​e​_​U​Z​P​2​0​w​s​.​_​z​a​m​o​w​i​e​c​5​8​4​_​n​a​_​s​y​s​t​e​m​y​_​i​n​f​o​r​m​a​t​y​c​z​n​e​.​pdf)