Wprowadzenie

W roku 2017 komen­to­wa­łem doku­ment, któ­ry Ministerstwo Cyfryzacji opu­bli­ko­wa­ło (Opublikowano: 22.11.2017), zaty­tu­ło­wa­ny ​„Wzorcowe klau­zu­le w umo­wach IT”. Czytam tam mię­dzy innymi:

Klauzule zosta­ły opra­co­wa­ne na zle­ce­nie Ministra Cyfryzacji przez zespół kan­ce­la­rii MARUTA WACHTA Sp. j. pod kie­row­nic­twem mec. Marcina Maruty i mec. Bartłomieja Wachty. Wykorzystano w nich rów­nież uwa­gi pra­cow­ni­ków admi­ni­stra­cji publicz­nej, zarów­no praw­ni­ków, jak i spe­cja­li­stów z dzie­dzi­ny IT. 

(źr. https://​www​.gov​.pl/​c​y​f​r​y​z​a​c​j​a​/​w​z​o​r​c​o​w​e​-​k​l​a​u​z​u​l​e​-​w​-​u​m​o​w​a​c​h​-it)

Moje uwa­gi umie­ści­łem we wpi­sie: Wzorcowe klau­zu­le w umo­wach IT. Gorąco pole­cam prze­czy­ta­nie, opi­sa­łem tam kwe­stie słow­ni­ka w Umowie, któ­ry jest klu­czem dla brzmie­nia Umowy i jej póź­niej­szej inter­pre­ta­cji. Te klau­zu­le nadal są ofi­cjal­ne na stro­nie Ministerstwa Cyfryzacji. Na otwar­tą proś­bę Ministerstwa dorę­czy­łem swo­je kry­tycz­ne uwa­gi, do dziś nie dosta­łem żad­nej odpo­wie­dzi. To było w 2017 roku. 

12 grud­nia 2023 r. (wto­rek) o godz. 10:00 mia­ła miej­sce pre­zen­ta­cja (webi­nar on-line) pro­wa­dzo­na przez praw­ni­ków kan­ce­la­rii Lawspective Litwiński Valirakis Radcowie Prawni Sp. k.. zaty­tu­ło­wa­na ​„Przed Tobą wdro­że­nie sys­te­mu IT?” link do źró­dła: https://www.linkedin.com/feed/update/urn%3Ali%3Aactivity%3A7134871019667808260/

Od stro­ny praw­nej trud­no cokol­wiek zarzu­cić pre­le­gen­tom. Niestety pre­zen­te­rzy powie­la­ją ​„mity” gło­szo­ne przez dostaw­ców opro­gra­mo­wa­nia. Generalnie pole­cam obej­rze­nie pre­zen­ta­cji (pra­wa i miej­sce pre­zen­ta­cji nale­żą do ww. kancelarii).

Tu odnio­sę do nie­któ­rych kwe­stii doty­czą­cych inży­nie­rii opro­gra­mo­wa­nia i jej sty­ku z pra­wem autor­skim oraz z know-how. To te miej­sca, w któ­rych – mom zda­niem – praw­ni­cy Ci wyka­za­li się nie­ste­ty zupeł­nym bra­kiem wie­dzy i zro­zu­mie­nia tego czym jest opro­gra­mo­wa­nie, jego two­rze­nie i wdra­ża­nie. Momentami nawet reko­men­do­wa­li szko­dli­we zapi­sy w umo­wach na wdrożenia.

Wymagania: nie piszcie sami (NIE UCZCIE SIE NA SOBIE)

Zapisano wie­le papie­ru na temat nie­spój­no­ści spe­cy­fi­ka­cji opra­co­wy­wa­nych meto­da­mi burzy mózgów spi­sa­nych języ­kiem natu­ral­nym, jed­na z nich poniżej:

Šenkýř, D.; Kroha, P. Problem of Incompleteness in Textual Requirements Specification: In Proceedings of the 14^th International Conference on Software Technologies; SCITEPRESS – Science and Technology Publications: Prague, Czech Republic, 2019; pp 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330.

Wymagania na opro­gra­mo­wa­nie to nie lista życzeń. Deweloper to fir­ma inży­nier­ska, powin­na dostać pro­jekt tech­nicz­ny jako wymaganie. 

Jeżeli ktoś Ci mówi, żeby nie pisać umo­wy same­mu i sko­rzy­stać z pomo­cy praw­ni­ka, to ja powiem: nie pisz wyma­gań sam, sko­rzy­staj z usług projektanta.

Kastomizacje vs. rozwiązania dedykowane

Kastomizacje? Jednym sło­wem: NIGDY. Bo stra­cisz gwa­ran­cję pro­du­cen­ta, a jak nie masz rękoj­mi usłu­go­daw­cy, to już nikt Ci nie pomo­że. Tu wię­cej: Kastomizacja opro­gra­mo­wa­nia stan­dar­do­we­go, aspek­ty eko­no­micz­ne: Recenzja i rekomendacje

Prawa autorskie

To kon­ty­nu­acja poprzed­nie­go punk­tu: Jak licen­cja to na opro­gra­mo­wa­nie stan­dar­do­we, jak autor­skie pra­wa mająt­ko­we, to z zasa­dy do dedy­ko­wa­nej dla Ciebie czę­ści: modu­ły dedy­ko­wa­ne two­rzy­my zawsze osob­no i zin­te­gro­wa­ne (jeże­li to moż­li­we, to w tej samej tech­no­lo­gii i śro­do­wi­sku co inte­gro­wa­ne sys­te­mu). Jednak pra­wa mająt­ko­we do ele­men­tów dedy­ko­wa­nych i suge­stia, że to eks­tra koszt (za prze­ka­za­nie praw mająt­ko­wych) to jest to nad­uży­cie ze stro­ny dostaw­cy (pole­cam tu lek­tu­rę wpi­su: Prawo autor­skie w pro­jek­tach IT)

Uzależnienie od dostawcy

Jeżeli ktoś pozwo­lił się uza­leż­nić od dostaw­cy to jest to na praw­dę dra­mat, ale moż­na tego unik­nąć. Jak? Należy mieć DOKUMENTACJĘ tego jak dzia­ła opro­gra­mo­wa­nie. Oprogramowanie stan­dar­do­we powin­no mieć co naj­mniej pod­ręcz­nik użyt­kow­ni­ka. Oprogramowanie dedy­ko­wa­ne powin­no mieć dokład­ną spe­cy­fi­ka­cję mecha­ni­zmów dzia­ła­nia (archi­tek­tu­ra, algo­ryt­my, uży­te meto­dy). Brak doku­men­ta­cji pro­wa­dzi do sytu­acji gdy tyl­ko wyko­naw­ca zna mecha­nizm dzia­ła­nia opro­gra­mo­wa­nie i w efek­cie ma mono­pol na usłu­gi utrzy­ma­nia i roz­wo­ju, a tego nie chce­my. Oczywiście, pra­wa mająt­ko­we do dedy­ko­wa­ne­go opro­gra­mo­wa­nia z zasa­dy u zama­wia­ją­ce­go i bez dopłaty. 

Migracja

Każde nowe wdro­że­nie w obec­nych cza­sach, to migra­cja ze sta­rych roz­wią­zań do nowe­go. Problem w tym, że zna­ko­mi­ta więk­szość apli­ka­cji jest zbu­do­wa­na na tak zwa­nych rela­cyj­nych bazach danych. Taka baza to set­ki wza­jem­nie połą­czo­nych tabel. pro­blem w tym, że każ­da apli­ka­cja ma inny układ tych tabel. W efek­cie prze­nie­sie­nie danych z jed­nej takiej struk­tu­ry do dru­giej w 100% jest prak­tycz­nie niemożliwe. 

Nawet jeże­li dostaw­ca obie­cu­je taką migra­cję, bar­dzo czę­sto oka­zu­je się, że jest bar­dzo kosz­tow­na, nie obej­mu­je wszyst­kich danych i bar­dzo czę­sto nie jest potrzeb­na. Z regu­ły wystar­czy prze­nie­sie­nie do nowe­go sys­te­mu kil­ku klu­czo­wych reje­strów i słow­ni­ków. Resztę moż­na udo­stęp­nić inny­mi, tań­szy­mi i pew­niej­szy­mi metodami. 

Integracja

Integracja i wyima­gi­no­wa­ny jej wiel­ki koszt to jeden z klu­czo­wych ​„stra­sza­ków” form ofe­ru­ją­cych sta­re, mono­li­tycz­ne ERP. Dzisiaj nie ma moż­li­wo­ści wdro­że­nia cze­go­kol­wiek bez inte­gra­cji, bo żad­na dzia­łal­ność gospo­dar­cza nie mie­ści się w gra­ni­cach jed­nej apli­ka­cji. Po dru­gie tak zwa­na digi­ta­li­za­cja to nic inne­go jak inte­gra­cja sys­te­mów infor­ma­tycz­nych fir­my, jej part­ne­rów han­dlo­wych i insty­tu­cji publicz­nych (ze skar­bów­ką na cze­le). Kluczem jest to, by te inte­gra­cję zro­zu­mieć i zapro­jek­to­wać przed wybo­rem dostaw­cy opro­gra­mo­wa­nia (inte­gra­cja powin­na być wymaganiem). 

Chmura

Temat rze­ka, czę­sto sły­szę (tu praw­ni­cy tak­że to suge­ro­wa­li), że to dostaw­ca w ofer­cie pro­po­nu­je (lub nie) roz­wią­za­nie chmu­ro­we. Nic bar­dziej błęd­ne­go: taka decy­zja powin­na być kon­se­kwen­cją stra­te­gii fir­my (nale­ży taką mieć) a nie dostaw­cy opro­gra­mo­wa­nia (któ­ry z zasad ofe­ru­je roz­wią­za­nia korzy­sta­ne dla nie­go). Wykonawca nigdy nie powi­nien sam decy­do­wać o tym czy sys­tem jest lokal­nie insta­lo­wa­ny czy w chmurze. 

Harmonogram

Prawnicy mówią: w umo­wie musi być har­mo­no­gram wdro­że­nia. A jakim cudem, sko­ro nie ma pro­jek­tu tego sys­te­mu, bo ​„ana­li­za wyma­gań i ana­li­za przed­wdro­że­nio­wa oraz pro­jekt sys­te­mu” to treść zle­ce­nia dla tego dostaw­cy opro­gra­mo­wa­nia? Brak pro­jek­tu tech­nicz­ne­go ozna­cza, że zbu­do­wa­nie har­mo­no­gra­mu jest nie­moż­li­we bo na eta­pie zawie­ra­nia umo­wy dostaw­ca nie wie co ma powstać! Przecież nie było jesz­cze żad­nej analizy!

Współdziałanie

Jest to bar­dzo waż­na część zawie­ra­nej umo­wy. Podstawą współ­dzia­ła­nia jest opis tego JAKIE i W JAKIEJ posta­ci mate­ria­ły ma dostar­czać zama­wia­ją­cy oraz w jakim ter­mi­nie. Ale to doty­czy tak­że DOSTAWCY, któ­ry nie powi­nien być świę­tą kro­wą. Email i tele­fon, spo­tka­nia, jako meto­da komu­ni­ka­cji to DRAMAT. Podobnym dra­ma­tem są tabli­ce on-line typu MIRO. Kluczowym celem komu­ni­ka­cji w pro­jek­cie jest wie­dza: KTO, CO, KIEDY I DO KOGO NAPISAŁ. Nie mniej klu­czo­we jest to, by doku­men­ta­cja sys­te­mu (patrz wpis: Opis Techniczny Oprogramowania) nie była zlep­kiem nota­tek i usta­leń z nie­koń­czą­cych sie spo­tkań, kolek­cjo­no­wa­nych od dnia pod­pi­sa­nia umo­wy. Powinien to być jeden, spój­ny, aktu­ali­zo­wa­ny doku­ment mają­cy jaw­nie wska­za­ne­go auto­ra. Współdziałanie to umo­wa SLA na wza­jem­ną komu­ni­ka­cję obo­wią­zu­ją­ca jed­na­ko­wo obie stro­ny umowy. 

Umowa

Co do kwe­stii czy­sto cywil­no-praw­nych nie odno­szę się, bo tu deta­le to w 100% kom­pe­ten­cje prawników. 

Jednak umo­wa na dostar­cze­nie i wdro­że­nie opro­gra­mo­wa­nia była umo­wą o dzie­ło, któ­ra musi zawie­rać OPIS PRZEDMIOTU ZAMÓWIENIA. Tym opi­sem powi­nien być opis tech­nicz­ny opro­gra­mo­wa­nia. Przedmiot takiej umo­wy (szcze­gól­nie logi­ka biz­ne­so­wa) jest czę­sto tajem­ni­cą przedsiębiorstwa. 

Tu zwra­cam uwa­gę, że sam cel zama­wia­ją­ce­go, jakim jest wdro­że­nie cze­goś nie­opi­sa­ne­go, nie jest takim opi­sem. Niestety nie są chro­nio­ne pra­wem same spi­sa­ne funk­cjo­nal­no­ści pro­gra­mu czy­li spe­cy­fi­ka­cja (lista) wyma­gań funk­cjo­nal­nych (wyrok SA w Poznaniu z dnia 4 stycz­nia 1995 r. I ACr 422/94). Precyzję opi­su dają­cą ochro­nę uzy­sku­je się dopie­ro opra­co­wu­jąc pro­jekt sto­su­jąc wzo­ry mate­ma­tycz­ne, algo­ryt­my, uni­kal­ne struk­tu­ry i sche­ma­ty blo­ko­we opi­su­ją­ce mecha­ni­zmy dzia­ła­nia i struk­tu­ry informacji.

Kolejna waż­na rzecz, to kon­se­kwen­cja powyż­sze­go: umo­wa powin­na zawie­rać rolę gene­ral­ne­go projektanta/architekta sys­te­mu, któ­ry powi­nien być po stro­nie zama­wia­ją­ce­go (ana­lo­gicz­nie jak w każ­dej innej inżynierii). 

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy sys­te­mów mogą być cen­nym ele­men­tem cyfro­wej trans­for­ma­cji, ale nigdy nie powin­ni mieć cał­ko­wi­tej, nie­kon­tro­lo­wa­nej wła­dzy nad całym przedsięwzięciem

 (źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

Zapis o moż­li­wo­ści dobro­wol­ne­go odstą­pie­nie od umo­wy, bez żad­nych kar i bez poda­wa­nia przy­czy­ny (zaprze­sta­nie współ­pra­cy), powin­no być w nią wpi­sa­ne, jako obro­na przed ven­dor lock-in i jakim­kol­wiek per­swa­zyj­nym szan­ta­żem (doty­czy to obu stron umowy).

Wdrożenie

Jeżeli wdro­że­nie pro­wa­dzi part­ner pro­du­cen­ta opro­gra­mo­wa­nia, wyłą­cze­nie rękoj­mi w umo­wie z pośred­ni­kiem to samo­bój­stwo. Gwarancje z zasa­dy daje pro­du­cent a wyłą­cza­nie rękoj­mi w takich wdro­że­niach to nie jest żaden zwy­czaj tyl­ko mani­pu­la­cja dostaw­cy! Tak więc part­ner pro­du­cen­ta, któ­ry nie ma pra­wa udzie­le­nia gwa­ran­cji na nie swój pro­dukt, powi­nien udzie­lić rękoj­mi. W prze­ciw­nym wypad­ku każ­dą nie­zgod­ność opro­gra­mo­wa­nia z jego opi­sem, kupu­ją­cy będzie musiał oso­bi­ście wyja­śniać z jego pro­du­cen­tem: życzę powo­dze­nia w kon­tak­tach z ame­ry­kań­ski­mi fir­ma­mi i nie nie tyl­ko amerykańskimi.

Umowa z dostaw­cą powin­na zawie­rać zapis o tym, że dostaw­ca (pro­du­cent) pono­si skut­ki wadli­wo­ści praw autor­skich w umo­wach, to ZAWSZE moż­na wyne­go­cjo­wać, a nawet nale­ży tego żądać. 

Umowy zwa­ne ​„wdro­że­nie agi­le” … odra­dzam :). Dlaczego? Bo nie zawie­ra­ją opi­su przed­mio­tu umo­wy inne­go niż sta­ran­ne dzia­ła­nie, a w takim przy­pad­ku odpo­wie­dzial­ność za uzy­ska­ny efekt w cało­ści spa­da na zamawiającego.

Odbiór

Przedmiotem odbio­ru jest co do zasa­dy Przedmiot Zamówienia, więc jego pre­cy­zyj­ny opis powi­nien być załącz­ni­kiem do umo­wy. Przypomnę że, lista funk­cjo­nal­no­ści nie powin­na być przed­mio­tem umo­wy z dostawcą/wykonawcą opro­gra­mo­wa­nia : idea sys­te­mu nie jest opi­sem sys­te­mu. Taką umo­wę (funk­cjo­nal­no­ści jako wyma­ga­nia) moż­na zawrzeć wcze­śniej z pro­jek­tan­tem, gdzie przed­mio­tem umo­wy jest opra­co­wa­nie opi­su tech­nicz­ne­go i – coraz czę­ściej – nad­zór autor­ski w toku pra­cy (patrz wyżej gene­ral­ny projektant).

Bardzo waż­na rzecz: NIE JEST PRAWDĄ ŻE SYSTEM MOŻE MIEĆ BŁĘDY w TRAKCIE ODBIORU!!!!!!! Wskazówką może tu być podział opro­gra­mo­wa­nia na nie­za­leż­ne moduły/komponenty, wte­dy moż­na je odbie­rać nie­za­leż­nie, ale odbie­ra­ny moduł nie moze mieć błędów!

Przedmiotem umo­wy i odbio­ru nie powin­no być ​„opro­gra­mo­wa­nie” a ​„dzia­ła­ją­cy komputer”!

Podsumowanie

Powyższe to, popar­te okre­sem 20 lat repre­zen­ta­cji nabyw­ców opro­gra­mo­wa­nia, reko­men­da­cje. Nie jedy­ne, bo na moim blo­gu znaj­dziesz czy­tel­ni­ku wię­cej takich. Powyższe nie wyczer­pu­je pro­ble­mów w umo­wach, celem moim było zwró­ce­nie uwa­gi na czę­ste pro­po­zy­cje wie­lu praw­ni­ków, poka­zu­ją­ce, że zawar­cie umo­wy na wdro­że­nie opro­gra­mo­wa­nia, bez mery­to­rycz­ne­go wspar­cia (jak sie oka­zu­je praw­nik nim nie jest) jest ogrom­nym ryzykiem. 

Biorąc pod uwa­gę fakt, że z zasa­dy dostaw­ca zaawan­so­wa­nych tech­no­lo­gii ma ogrom­ną prze­wa­gę mery­to­rycz­ną nad swo­im klien­tem, nie­za­pew­nie­nie sobie, po swo­jej stro­nie, eks­per­ta z dzie­dzi­ny inży­nie­rii opro­gra­mo­wa­nia, to pro­sta dro­ga do kłopotów. 

Jeżeli Twój praw­nik ma inne zda­nie to, zanim pod­pi­szesz nie­ko­rzyst­ną dla sie­bie umo­wę, zapra­szam na spo­tka­nie. Z jakie­goś nie­zna­ne­go mi powo­du, praw­ni­cy czę­sto bez­gra­nicz­nie wie­rzą dostaw­com opro­gra­mo­wa­nia mimo, że nie rozu­mie­ją tego co jest przed­mio­tem tych umów. A nabyw­cy opro­gra­mo­wa­nia bez­gra­nicz­nie zaś wie­rzą tym praw­ni­kom. Ot taka zaba­wa w głu­chy tele­fon, w któ­rej dostaw­ca opro­gra­mo­wa­nia naj­czę­ściej wygrywa.

Taka cie­ka­wost­ka: fra­za ​„ERP imple­men­ta­tion failu­re” w Goole, wynik: ok. ​„5,330,000 results”. Czyli gene­ral­nie ryzy­ko jest bar­dzo duże. Zwracam uwa­gę, że skrót ERP w pra­sie bran­żo­wej i w blo­gach, w zasa­dzie z zasa­dy ozna­cza zna­ne mono­li­tycz­ne pro­duk­ty w tej kategorii.