Wprowadzenie

W roku 2017 komentowałem dokument, który Ministerstwo Cyfryzacji opublikowało (Opublikowano: 22.11.2017), zatytułowany “Wzorcowe klauzule w umowach IT”. Czytam tam między innymi:

Klauzule zostały opracowane na zlecenie Ministra Cyfryzacji przez zespół kancelarii MARUTA WACHTA Sp. j. pod kierownictwem mec. Marcina Maruty i mec. Bartłomieja Wachty. Wykorzystano w nich również uwagi pracowników administracji publicznej, zarówno prawników, jak i specjalistów z dziedziny IT.

(źr. https://www.gov.pl/cyfryzacja/wzorcowe-klauzule-w-umowach-it)

Moje uwagi umieściłem we wpisie: Wzorcowe klauzule w umowach IT. Gorąco polecam przeczytanie, opisałem tam kwestie słownika w Umowie, który jest kluczem dla brzmienia Umowy i jej późniejszej interpretacji. Te klauzule nadal są oficjalne na stronie Ministerstwa Cyfryzacji. Na otwartą prośbę Ministerstwa doręczyłem swoje krytyczne uwagi, do dziś nie dostałem żadnej odpowiedzi. To było w 2017 roku.

12 grudnia 2023 r. (wtorek) o godz. 10:00 miała miejsce prezentacja (webinar on-line) prowadzona przez prawników kancelarii Lawspective Litwiński Valirakis Radcowie Prawni Sp. k.. zatytułowana “Przed Tobą wdrożenie systemu IT?” link do źródła: https://www.linkedin.com/feed/update/urn%3Ali%3Aactivity%3A7134871019667808260/

Od strony prawnej trudno cokolwiek zarzucić prelegentom. Niestety prezenterzy powielają “mity” głoszone przez dostawców oprogramowania. Generalnie polecam obejrzenie prezentacji (prawa i miejsce prezentacji należą do ww. kancelarii).

Tu odniosę do niektórych kwestii dotyczących inżynierii oprogramowania i jej styku z prawem autorskim oraz z know-how. To te miejsca, w których – mom zdaniem – prawnicy Ci wykazali się niestety zupełnym brakiem wiedzy i zrozumienia tego czym jest oprogramowanie, jego tworzenie i wdrażanie. Momentami nawet rekomendowali szkodliwe zapisy w umowach na wdrożenia.

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

Zapisano wiele papieru na temat niespójności specyfikacji opracowywanych metodami burzy mózgów spisanych językiem naturalnym, jedna z nich poniżej:

Šenkýř, D.; Kroha, P. Problem of Incompleteness in Textual Requirements Specification: In Proceedings of the 14th International Conference on Software Technologies; SCITEPRESS – Science and Technology Publications: Prague, Czech Republic, 2019; pp 323–330. https://doi.org/10.5220/0007978003230330.

Wymagania na oprogramowanie to nie lista życzeń. Deweloper to firma inżynierska, powinna dostać projekt techniczny jako wymaganie.

Jeżeli ktoś Ci mówi, żeby nie pisać umowy samemu i skorzystać z pomocy prawnika, to ja powiem: nie pisz wymagań sam, skorzystaj z usług projektanta.

Kastomizacje vs. rozwiązania dedykowane

Kastomizacje? Jednym słowem: NIGDY. Bo stracisz gwarancję producenta, a jak nie masz rękojmi usługodawcy, to już nikt Ci nie pomoże. Tu więcej: Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje

Prawa autorskie

To kontynuacja poprzedniego punktu: Jak licencja to na oprogramowanie standardowe, jak autorskie prawa majątkowe, to z zasady do dedykowanej dla Ciebie części: moduły dedykowane tworzymy zawsze osobno i zintegrowane (jeżeli to możliwe, to w tej samej technologii i środowisku co integrowane systemu). Jednak prawa majątkowe do elementów dedykowanych i sugestia, że to ekstra koszt (za przekazanie praw majątkowych) to jest to nadużycie ze strony dostawcy (polecam tu lekturę wpisu: Prawo autorskie w projektach IT)

Uzależnienie od dostawcy

Jeżeli ktoś pozwolił się uzależnić od dostawcy to jest to na prawdę dramat, ale można tego uniknąć. Jak? Należy mieć DOKUMENTACJĘ tego jak działa oprogramowanie. Oprogramowanie standardowe powinno mieć co najmniej podręcznik użytkownika. Oprogramowanie dedykowane powinno mieć dokładną specyfikację mechanizmów działania (architektura, algorytmy, użyte metody). Brak dokumentacji prowadzi do sytuacji gdy tylko wykonawca zna mechanizm działania oprogramowanie i w efekcie ma monopol na usługi utrzymania i rozwoju, a tego nie chcemy. Oczywiście, prawa majątkowe do dedykowanego oprogramowania z zasady u zamawiającego i bez dopłaty.

Migracja

Każde nowe wdrożenie w obecnych czasach, to migracja ze starych rozwiązań do nowego. Problem w tym, że znakomita większość aplikacji jest zbudowana na tak zwanych relacyjnych bazach danych. Taka baza to setki wzajemnie połączonych tabel. problem w tym, że każda aplikacja ma inny układ tych tabel. W efekcie przeniesienie danych z jednej takiej struktury do drugiej w 100% jest praktycznie niemożliwe.

Nawet jeżeli dostawca obiecuje taką migrację, bardzo często okazuje się, że jest bardzo kosztowna, nie obejmuje wszystkich danych i bardzo często nie jest potrzebna. Z reguły wystarczy przeniesienie do nowego systemu kilku kluczowych rejestrów i słowników. Resztę można udostępnić innymi, tańszymi i pewniejszymi metodami.

Integracja

Integracja i wyimaginowany jej wielki koszt to jeden z kluczowych “straszaków” form oferujących stare, monolityczne ERP. Dzisiaj nie ma możliwości wdrożenia czegokolwiek bez integracji, bo żadna działalność gospodarcza nie mieści się w granicach jednej aplikacji. Po drugie tak zwana digitalizacja to nic innego jak integracja systemów informatycznych firmy, jej partnerów handlowych i instytucji publicznych (ze skarbówką na czele). Kluczem jest to, by te integrację zrozumieć i zaprojektować przed wyborem dostawcy oprogramowania (integracja powinna być wymaganiem).

Chmura

Temat rzeka, często słyszę (tu prawnicy także to sugerowali), że to dostawca w ofercie proponuje (lub nie) rozwiązanie chmurowe. Nic bardziej błędnego: taka decyzja powinna być konsekwencją strategii firmy (należy taką mieć) a nie dostawcy oprogramowania (który z zasad oferuje rozwiązania korzystane dla niego). Wykonawca nigdy nie powinien sam decydować o tym czy system jest lokalnie instalowany czy w chmurze.

Harmonogram

Prawnicy mówią: w umowie musi być harmonogram wdrożenia. A jakim cudem, skoro nie ma projektu tego systemu, bo “analiza wymagań i analiza przedwdrożeniowa oraz projekt systemu” to treść zlecenia dla tego dostawcy oprogramowania? Brak projektu technicznego oznacza, że zbudowanie harmonogramu jest niemożliwe bo na etapie zawierania umowy dostawca nie wie co ma powstać! Przecież nie było jeszcze żadnej analizy!

Współdziałanie

Jest to bardzo ważna część zawieranej umowy. Podstawą współdziałania jest opis tego JAKIE i W JAKIEJ postaci materiały ma dostarczać zamawiający oraz w jakim terminie. Ale to dotyczy także DOSTAWCY, który nie powinien być świętą krową. Email i telefon, spotkania, jako metoda komunikacji to DRAMAT. Podobnym dramatem są tablice on-line typu MIRO. Kluczowym celem komunikacji w projekcie jest wiedza: KTO, CO, KIEDY I DO KOGO NAPISAŁ. Nie mniej kluczowe jest to, by dokumentacja systemu (patrz wpis: Opis Techniczny Oprogramowania) nie była zlepkiem notatek i ustaleń z niekończących sie spotkań, kolekcjonowanych od dnia podpisania umowy. Powinien to być jeden, spójny, aktualizowany dokument mający jawnie wskazanego autora. Współdziałanie to umowa SLA na wzajemną komunikację obowiązująca jednakowo obie strony umowy.

Umowa

Co do kwestii czysto cywilno-prawnych nie odnoszę się, bo tu detale to w 100% kompetencje prawników.

Jednak umowa na dostarczenie i wdrożenie oprogramowania była umową o dzieło, która musi zawierać OPIS PRZEDMIOTU ZAMÓWIENIA. Tym opisem powinien być opis techniczny oprogramowania. Przedmiot takiej umowy (szczególnie logika biznesowa) jest często tajemnicą przedsiębiorstwa.

Tu zwracam uwagę, że sam cel zamawiającego, jakim jest wdrożenie czegoś nieopisanego, nie jest takim opisem. Niestety nie są chronione prawem same spisane funkcjonalności programu czyli specyfikacja (lista) wymagań funkcjonalnych (wyrok SA w Poznaniu z dnia 4 stycznia 1995 r. I ACr 422/94). Precyzję opisu dającą ochronę uzyskuje się dopiero opracowując projekt stosując wzory matematyczne, algorytmy, unikalne struktury i schematy blokowe opisujące mechanizmy działania i struktury informacji.

Kolejna ważna rzecz, to konsekwencja powyższego: umowa powinna zawierać rolę generalnego projektanta/architekta systemu, który powinien być po stronie zamawiającego (analogicznie jak w każdej innej inżynierii).

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem

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

Zapis o możliwości dobrowolnego odstąpienie od umowy, bez żadnych kar i bez podawania przyczyny (zaprzestanie współpracy), powinno być w nią wpisane, jako obrona przed vendor lock-in i jakimkolwiek perswazyjnym szantażem (dotyczy to obu stron umowy).

Wdrożenie

Jeżeli wdrożenie prowadzi partner producenta oprogramowania, wyłączenie rękojmi w umowie z pośrednikiem to samobójstwo. Gwarancje z zasady daje producent a wyłączanie rękojmi w takich wdrożeniach to nie jest żaden zwyczaj tylko manipulacja dostawcy! Tak więc partner producenta, który nie ma prawa udzielenia gwarancji na nie swój produkt, powinien udzielić rękojmi. W przeciwnym wypadku każdą niezgodność oprogramowania z jego opisem, kupujący będzie musiał osobiście wyjaśniać z jego producentem: życzę powodzenia w kontaktach z amerykańskimi firmami i nie nie tylko amerykańskimi.

Umowa z dostawcą powinna zawierać zapis o tym, że dostawca (producent) ponosi skutki wadliwości praw autorskich w umowach, to ZAWSZE można wynegocjować, a nawet należy tego żądać.

Umowy zwane “wdrożenie agile” … odradzam :). Dlaczego? Bo nie zawierają opisu przedmiotu umowy innego niż staranne działanie, a w takim przypadku odpowiedzialność za uzyskany efekt w całości spada na zamawiającego.

Odbiór

Przedmiotem odbioru jest co do zasady Przedmiot Zamówienia, więc jego precyzyjny opis powinien być załącznikiem do umowy. Przypomnę że, lista funkcjonalności nie powinna być przedmiotem umowy z dostawcą/wykonawcą oprogramowania : idea systemu nie jest opisem systemu. Taką umowę (funkcjonalności jako wymagania) można zawrzeć wcześniej z projektantem, gdzie przedmiotem umowy jest opracowanie opisu technicznego i – coraz częściej – nadzór autorski w toku pracy (patrz wyżej generalny 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ł oprogramowania na niezależne moduły/komponenty, wtedy można je odbierać niezależnie, ale odbierany moduł nie moze mieć błędów!

Przedmiotem umowy i odbioru nie powinno być “oprogramowanie” a “działający komputer”!

Podsumowanie

Powyższe to, poparte okresem 20 lat reprezentacji nabywców oprogramowania, rekomendacje. Nie jedyne, bo na moim blogu znajdziesz czytelniku więcej takich. Powyższe nie wyczerpuje problemów w umowach, celem moim było zwrócenie uwagi na częste propozycje wielu prawników, pokazujące, że zawarcie umowy na wdrożenie oprogramowania, bez merytorycznego wsparcia (jak sie okazuje prawnik nim nie jest) jest ogromnym ryzykiem.

Biorąc pod uwagę fakt, że z zasady dostawca zaawansowanych technologii ma ogromną przewagę merytoryczną nad swoim klientem, niezapewnienie sobie, po swojej stronie, eksperta z dziedziny inżynierii oprogramowania, to prosta droga do kłopotów.

Jeżeli Twój prawnik ma inne zdanie to, zanim podpiszesz niekorzystną dla siebie umowę, zapraszam na spotkanie. Z jakiegoś nieznanego mi powodu, prawnicy często bezgranicznie wierzą dostawcom oprogramowania mimo, że nie rozumieją tego co jest przedmiotem tych umów. A nabywcy oprogramowania bezgranicznie zaś wierzą tym prawnikom. Ot taka zabawa w głuchy telefon, w której dostawca oprogramowania najczęściej wygrywa.

Taka ciekawostka: fraza “ERP implementation failure” w Goole, wynik: ok. “5,330,000 results”. Czyli generalnie ryzyko jest bardzo duże. Zwracam uwagę, że skrót ERP w prasie branżowej i w blogach, w zasadzie z zasady oznacza znane monolityczne produkty w tej kategorii.

O integracji i unikaniu kastomizacji monolitów poprzez wdrażanie dziedzinowych podsystemów napisałem tu wiele. Tym razem kilka komentarzy do krótkiego tekstu pewnego dostawcy monolitu ERP. Tekst krótki więc cytowanie stanowi niemalże jego połowę ale cóż, prawo cytowania treści bezpośrednio komentowanych…

Artykuł

Choć wyspecjalizowane pod konkretny obszar systemy oferują szerokie możliwości i najłatwiej je dopasować do potrzeb organizacji, może okazać się, że wraz z rozwojem firmy przestaną być efektywne. (źr.: 6 przesłanek, które mogą wskazywać, że powinieneś wdrożyć kompleksowe oprogramowanie)

Pierwsze zdanie to prawda, a drugie (zaczynając sie od “może”) sugeruje, że nie zawsze. Popatrzmy jak autor argumentuje drugie zdanie, pisząc że systemy wyspecjalizowane “wraz z rozwojem firmy przestaną być efektywne” (wszystkie cytaty z powyższego źródła).

1. Nieefektywna integracja danych
Stosowanie kilku rozwiązań informatycznych wiąże się z koniecznością zapewnienia skutecznej wymiany danych pomiędzy nimi. Zazwyczaj nie jest ona tak efektywna jak w przypadku jednego systemu z różnymi modułami.

Niestety nie jest to prawda. Poziom standaryzacji interfejsów od dawna pozwala robić to w sposób niezauważalny dla użytkownika. Powiem tylko tyle, że każdy zgodny z prawem system ERP/FK wysyła dane (JPK) do systemów rządowych, bez potzreby żadnej ręcznej integracji, i nie ma z tym żadnego problemu. Dla czytelników, którzy tego nie wiedzą, informacja: każde pobranie gotówki z bankomatu czy też dokonanie płatności kartą płatniczą w sklepie, to każdorazowo wynik współracy (integracja) co najmniej kilkunastu zintegrowanych systemów co najmniej kilku firm i instytucji. Warto też wiedzieć, że dane z różnych dziedzin bardzo często nie są możliwe do umieszczenia w jednej i tej samej bazie danych (to zresztą główne źródło problemów kastomizacji systemów monolitycznych), forsowanie architektury monolityczne jest wręcz wysoce szkodliwe [zotpressInText item=”{5085975:75V9UDPB}”].

Dostęp do wszystkich dokumentów i danych w jednym centralnym systemie pozwala księgowości na dokładną analizę w czasie zbliżonym do rzeczywistego, a to umożliwia lepsze zarządzanie finansami całej organizacji.

Dowody księgowe (podstawowe dokumenty w FK/ERP) stanowią mniej niż 20% wszystkich dokumentów operacyjnych, reszta i tak jest poza ERP. To co widzimy jako dokumenty w systemach ERP (np. Faktura) to tak na prawdę raporty ad-choc z tych baz danych, nie ma tam ŻADNYCH dokumentów. Aby były, należy jest dodatkowo archiwizować jako pliki PDF i/lub XML.

2. Błędy i opóźnienia
W przypadku konieczności ręcznego wprowadzania danych do kilku systemów, przedsiębiorstwo naraża się na opóźnienia, a także błędy.

Nie ma takiej potrzeby w środowisku zintegrowanym. Integracja kilku różnych dziedzinowych systemów między służy temu, by nie wprowadzać dokumentów więcej niż raz.

3. Systemy od różnych dostawców
Choć w codziennej pracy może nie stanowić to dużego utrudnienia, w przypadku jakiejkolwiek awarii systemów, fakt, że pochodzą od różnych dostawców, może być kłopotliwy. Wiąże się bowiem z koniecznością skontaktowania z kilkoma osobami, żeby móc rozwiązać problem.

Jest dokładnie odwrotnie: jak sie zepsuje monolit to NIC nie działa. Jak awarii ulegnie jeden z podsystemów dziedzinowych, reszta działa poprawnie, co jest dla odmiany OGROMNĄ zaletą rozproszonej architektury. Kontaktujemy się wyłącznie z administratorem tego co nie działa. Poprawnie wykonana integracja to także separacja skutków takich awarii.

4. Utrudnienie dla pracowników
Korzystanie z kilku systemów może stanowić dodatkowe wyzwanie dla pracowników, którzy muszą nauczyć się pracy na zróżnicowanym oprogramowaniu, często z innymi funkcjonalnościami, interfejsem i sposobem działania.

To także nie jest prawda: systemy dziedzinowe, jak sama nazwa wskazuje, są adresowane do określonych grup zawodowych czy kompetencji. Jeżeli gdziekolwiek pojawia się wyżej opisana sytuacja, to jest to raczej skutek bałaganu, który należy uporządkować przed wdrożeniem.

5. Nadmierne obciążenie działów IT
Korzystając z wielu rozwiązań informatycznych, konieczne jest stworzenie zespołu IT, który będzie miał odpowiednią wiedzę i doświadczenie w każdym z nich.

Kolejna nieprawda: dział IT z zasady zajmuje się administracją a nie rozwojem tych aplikacji. Za utrzymanie i rozwój odpowiada dostawca programowania w ramach stałej corocznej opłaty i licencji.

6. Utrudniona organizacja pracy z domu
Wciąż wiele firm pracuje w trybie home office, co wymaga od przedsiębiorstw zapewnienia dostępu do wszystkich koniecznych do pracy systemów, informacji czy dokumentów. Nie wszystkie aplikacje są dostosowane do pracy poza biurem.

Owszem, stare i wiekowe systemy ERP w architekturze klient/serwer się do tego praktycznie nie nadają. Każdy nowoczesny system, to w całości dostępna przez przeglądarkę aplikacja, z którą pracować można gdziekolwiek.

Obserwujemy, że niektóre firmy obawiają się zmian, nawet gdy rozwiązania, z których korzystają, nie w pełni spełniają ich potrzeby lub są już nieco przestarzałe. Często myślą o wysokich kosztach kompleksowych systemów. I choć rzeczywiście, konieczna jest inwestycja finansowa i czasowa, to utrzymanie jednego rozwiązania zamiast kilku mniejszych jest w dłuższej perspektywie kosztowo bardziej opłacalne.

To także jest nieprawda, choćby dlatego, że wdrażanie dedykowanych podsystemów dziedzinowych nie wymaga żadnych kastomizacji dlatego i wdrożenie i później upgrade są znacznie tańsze niż wdrożenie i dostosowanie monolitu.

Podsumowanie

Nie raz myślałem, że nie będę już musiał pisać takich artykułów ale znowu jest okazja. Nie raz pisałem, że dostawcy systemów ERP, bardzo często, bez żadnych skrupułów wykorzystują niewiedzę swoich klientów. Tu mamy kolejny taki przykład. Nawet jeżeli istnieją tak złe wdrożenia, że artykuł ten mówi prawdę, to jest to tylko opis wyjątkowych złych wdrożeń.

Pisanie, że “Choć wyspecjalizowane pod konkretny obszar systemy oferują szerokie możliwości i najłatwiej je dopasować do potrzeb organizacji, może okazać się, że wraz z rozwojem firmy przestaną być efektywne.” jest szkodliwą manipulacją.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

Od czasu do czasu jestem proszony o audyty dokumentacji projektów. Ma to miejsce, albo gdy jestem angażowany do projektu będącego kolejnym podejściem do wdrożenia, albo w sporach, także przedsądowych, między dostawcą oprogramowania i zamawiającym. Bywa, że jest to już etap pisania opinii dla sądu. Tu razem kilka spostrzeżeń z tych analiz.

Na marginesie. W sporach przedsądowych i sądowych wynik ekspertyzy absolutnie nie może być “zamówiony”, czego niestety często oczekują, nie raz wręcz żądają pod groźbą odmowy zapłaty za tę usługę, zamawiający takie ekspertyzy. Bywa to tym bardziej żenujące, że roszczenia takie wysuwają czasami prawnicy zlecających, czyli osoby znające prawo i – teoretycznie – stosujący zasady etyki w swojej pracy.

Wiele lat uważałem, że winni są dostawcy, którzy powinni wykazać się możliwie najwyższym profesjonalizmem, a tego nie robią. Jakiś czas temu zmieniłem jednak zdanie (nie o profesjonalizmie dostawców).

Poza realizowanymi projektami, prowadzę także szkolenia oraz zajęcia ze studentami studiów niestacjonarnych i podyplomowych: to nie raz doświadczeni praktycy. Na wykładach i ćwiczeniach staram się pokazać “jak to robić dobrze”, jednym z elementów tego “jak to robić dobrze” jest “jak nie robić tego źle” i dyskusje na ten temat.

Dlaczego zmieniłem zdanie?

Zarówno własne doświadczenie, jak i dyskusje ze studentami, przekonały mnie, że generalnie celem dostawcy jest maksymalizacja zysków. Co mi stale mówią uczący się u mnie praktycy? Klient nasz pan, mamy robić wszystko co chce klient bo on za to płaci, a to, czy to co klient chce ma sens, nie ma znaczenia bo to problem klienta (chyba każdy konsultant i programista dostawcy słyszy to od swojego przełożonego raz dziennie).

Jak klient nie wie czego chce, to na jego koszt próbujemy.

W 2018 artykuł o porażce wdrożenia w LIDL kończyłem słowami:

Dziwi mnie, że wszyst­kie te, doświad­czo­ne poraż­ką, fir­my mają dostęp do tej samej wie­dzy co np. ja, a mimo to zarzą­dy tych firm wie­rzą bez­gra­nicz­nie dostaw­com opro­gra­mo­wa­nia i wie­rzą, że opi­sy­wa­ne od lat przy­czy­ny pora­żek u nich nie wystąpią? (źr.: Porażka za 2 mld zł. Lidl wycofuje się z wdrożenia SAP – Jarosław Żeliński IT-Consulting)

We wnioskach z porażki HERTZ w 2019 roku czytamy:

ZARZĄDZANIE ARCHITEKTURĄ IT WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem (źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

więc winny jest zamawiający…

Umowa efektu a staranne działanie

W prawie cywilnym wyróżniono dwie podstawowe formy świadczenia zamówionej usługi:

1. Umowa o dzieło
2. Umowa zlecenia

Scharakteryzowane zostały w następujący sposób:

Umowa o dzieło

Art. 627. Przez umowę o dzieło przyjmujący zamówienie zobowiązuje się do wykonania oznaczonego dzieła, a zamawiający do zapłaty wynagrodzenia.

Zlecenie

Art. 734. § 1. Przez umowę zlecenia przyjmujący zlecenie zobowiązuje się do dokonania określonej czynności prawnej dla dającego zlecenie.

§ 2. W braku odmiennej umowy zlecenie obejmuje umocowanie do wykonania czynności w imieniu dającego zlecenie. Przepis ten nie uchybia przepisom o formie pełnomocnictwa.

[zotpressInText item=”{5085975:CRCTGBQT}”].

W powszechnej i utrwalonej opinii prawników i w orzecznictwie przyjmuje się, że:

“Umowa zlecenia jest umową starannego działania. Zleceniobiorca zobowiązuje się do starannego działania i za to właśnie odpowiada, a nie, jak w przypadku umowy o dzieło, za rezultat pracy. W umowie należy więc dokładnie opisać czynności, jakie ma wykonywać zleceniobiorca, by później można było ocenić, czy zlecenie zostało wykonane oraz czy zostało wykonane w sposób staranny.” [zotpressInText item=”{5085975:QDAU3MZU}”]. A także, że “…można stwierdzić, iż w zobowiązaniach starannego działania dłużnik zobowiązuje się jedynie do dołożenia należytej staranności w zmierzaniu do ustalonego celu, z tym że jego osiągnięcie pozostaje poza treścią stosunku zobowiązaniowego. Natomiast w przypadku zobowiązania rezultatu na dłużniku ciąży powinność osiągnięcia oznaczonego z góry, sprecyzowanego rezultatu, przy czym ten rezultat to określony fakt, w nastąpieniu którego wierzyciel jest zainteresowany, prawny i ekonomiczny skutek oznaczony w treści zobowiązania, nie zaś sama czynność, którą dłużnik powinien podjąć.” [zotpressInText item=”{5085975:EJ6PPMEQ}”].

Podsumowując można stwierdzić, że

1. Umowa o dzieło to umowa, w której dający zamówienie z góry opisuje to co chce otrzymać (dzieło), a przyjmujący zamówienie zobowiązuje się to dostarczyć (wykonać dzieło).
2. Zlecenie to umowa, w której przyjmujący zlecenie działa w imieniu dającego zlecenie, w konsekwencji za efekt zleconej pracy odpowiada dający zlecenie.

Znakomita większość umów na dostarczenie oprogramowania to, umowy starannego działania, a tak zwane umowy “agile” mają taki charakter z zasady. Tu za uzyskany efekt zawsze odpowiada Zamawiający.

A jeżeli dostawca jest nierzetelny? Jest takie ryzyko, jednak odpowiedzialnością zamawiającego jest także nadzór na pracami wykonawcy!

Proces dostarczenia oprogramowania

Inżynieria oprogramowania, na tle innych obszarów inżynierii, jest młodą dziedziną, która nie wykształciła dedykowanego prawodawstwa, tak jak np. inżynieria budowlana, która ma “swoje” prawo budowlane. Z tego też powodu, jedynym źródłem opisów postępowania są tak zwane dobre praktyki, standardy oraz analogie, stosowane także – w obszarze inżynierii – do prawa budowlanego.

Na diagramie ‘Iteracyjno-przyrostowy proces tworzenia oprogramowania’ zobrazowano standardowy proces dostarczania rozwiązania jakim jest oprogramowanie [zotpressInText item=”{5085975:GMJDZZJ4}”]. Obecnie, z uwagi na tempo zmian w gospodarce, zaleca się by jedna ‘pętla iteracyjna rozwoju i utrzymania’ nie przekraczała w czasie jednego roku budżetowego, jednak preferowanym okresem jest pół roku z uwagi na to, że sztywne uzależnianie wdrażania oprogramowania wspomagającego zarządzanie, od rygorów rocznych okresów budżetowych było by znaczącym utrudnieniem w toku wdrażania zmian w firmach.

Projekty małe to projekty będące pojedynczą iteracją. Dobrą praktyką postępowania dla projektów większych jest dzielenie ich na przyrostowe iteracje (w kolejnych cyklach pętli iteracji wdrażane są kolejne funkcjonalności lub moduły) [zotpressInText item=”{5085975:IWL4AAEZ}”]. Z reguły robi to wtedy wykonawca przyjmujący zamówienie [zotpressInText item=”{5085975:IWL4AAEZ}”]. Co do zasady, za specyfikowanie wymagań i jakość tej specyfikacji, w każdym rodzaju inżynierii, odpowiada zamawiający [zotpressInText item=”{5085975:N4KMEKC8}”]. Zamawiający jest jedynym tu podmiotem, znającym swój cel biznesowy, jako podmiot zamawia u dostawcy produkt a nie efekt biznesowy jaki ma zamiar osiągnąć, za efekt efekt biznesowy z zasady odpowiada “biznes” [zotpressInText item=”{5085975:6J8ZX2MR}”]. 

W tym miejscu, należy zwrócić uwagę na bardzo ważny fakt: w przypadku umowy efektu, kolejne iteracje to uszczegółowienie i implementacja funkcjonalności opisanych w umowie, a nie kolejne nowe funkcjonalności. Nowe funkcjonalności powstają w toku rozwoju JUŻ WDROŻONEGO I POPRAWNIE DZIAŁAJĄCEGO oprogramowania.

Wdrożenie

Projekty wdrożeniowe (dostarczanie oprogramowania) mogą być realizowane przez bieżące zlecanie konkretnych prac usługodawcy, lub poprzez opisanie oczekiwanego efektu jako wymaganego rozwiązania i zawarcie Umowy o dzieło z przyjmującym zamówienie, co zobrazowano na diagramie Podsumowanie stanu wiedzy. W obu przypadkach Zamawiający ponosi skutki swojej decyzji bo:

1. jako zleceniodawca (umowy T&M) sam ustala co i jak ma zostać wykonane,
2. jako zamawiający określony efekt (umowy o dzieło), sam ustala oczekiwany efekt (produkt) w dniu zawarcia umowy (jako opis przedmiotu zamówienia).

Odpowiedzialność przyjmującego zamówienia polega albo na starannym działaniu, albo na zgodności tego co dostarczy z tym co zamówiono, w rozumieniu oczekiwanego efektu. Jeżeli przedmiotem zamówienia jest oprogramowanie, czyli narzędzie pracy zamawiającego, tylko zamawiający ponosi odpowiedzialność za skutki wdrożenia tego co zamówił [zotpressInText item=”{5085975:WRPWYI5X},{5085975:5VXLI5XY}”]. Dostawca odpowiada wyłącznie za przedmiot umowy [zotpressInText item=”{5085975:EJ6PPMEQ}”].

Tak więc zamawiający zawsze dostanie to co chce, ale nie koniecznie to co jest mu faktycznie potrzebne. Innymi słowy, na rynku rządzonym przez dochody i zyski, dostawca oprogramowania zawsze będzie pracował pod dyktando zamawiającego (lub za jego zgodą) i będzie to robił do wyczerpana budżetu zamawiającego.

Bardzo ciekawe są blogi dostawców oprogramowania. Wielu ich autorów faktycznie stara się, ale cóż… jeden z ciekawszych wpisów na ten temat jest zatytułowany “The art (and science) of collecting requirements: top 3 mistakes vendors make“. Autor z perspektywy dostawcy, zwraca uwagę na trzy kluczowe przyczyny porażek: uznanie, że to użytkownik odpowiada za wymagania, mieszanie wymagań z pomysłami na ich realizację, niedoceniania macierzy śladowania. To, popełnianie tych błędów, niestety jest najczęściej spotykaną cechą analiz prowadzanych właśnie przez dostawców oprogramowania, a za wszystko i tak płaci nabywca. W bardziej naukowy sposób (szczególnie krytykując wymagania pisane językiem naturalnym przez zamawiającego) opisali to bardzo dokładnie Šenkýř i Kroha [zotpressInText item=”{5085975:LXK8VA68}”].

Konkluzja jest taka, że za nieudane wdrożenia odpowiada zawsze zamawiający.

Główną winą zamawiającego jest to, że zamawia usługi, których istoty nie rozumie więc pozostawia wykonawcę praktycznie bez nadzoru, oddając mu niemalże nieograniczone uprawnienia co do zakresu projektu. Pierwszym zaś samobójczym krokiem jest zlecenie analizy wymagań i projektowanie wybranemu wcześniej dostawcy oprogramowania. Biorąc pod uwagę rynkowy konflikt interesu dostawcy i odbiorcy (zamawiający maksymalizuje żądania a dostawca maksymalizuje zysk), jest to prosta droga do porażki, jaką jest także znaczne przepłacenie.

Pytani pracownicy dostawców zawsze odpowiadają, że przecież celem jest “dowiezienie projektu”, niestety nie jest jednak żadną sztuką “w końcu dostarczyć oprogramowanie”. Sztuką jest to zrobić zgodnie z obietnicą daną pierwszego dnia projektu, a z własnego wieloletniego doświadczenia wiem, że to możliwe. Sztuką jest także to, by dalszy rozwój i utrzymanie nie były najdroższym projektem świata.

Szanowni państwo: podpisując z dostawcą oprogramowania umowę “czas i materiał”, i zlecając temu dostawcy także analizę wymagań, kopiecie sobie grób.

Za co odpowiada dostawca? Za staranne działanie, jednak stosowanie nieadekwatnych metod nie jest działaniem niestarannym, i dlatego w sądach z reguły przegrywają zamawiający a nie dostawcy oprogramowania. Wykazanie starannego działania przez dostawcę oprogramowania jest bardzo proste: comiesięczne opłacone faktury “za pracę” dostawcy oprogramowania są tak naprawdę uznaniem jego starannego działania przez zamawiającego. Pozostaje tu jedynie kwestia etyki dostawcy, ale to temat na osobne opracowanie.

Tak więc podejmując decyzję o wdrożeniu pomyślcie Państwo o ryzyku:

Zamiast podsumowania: negatywna selekcja

Jedną z ciekawszych rzeczy w mojej karierze zawodowej są prawnicy i księgowi. Sa to role bardzo znaczące w firmach, a zarazem bardzo niebezpieczne bo mają i realną władzę decyzyjną i najczęściej cechują się dużym konserwatyzmem a wiedza tych osób o informatyce jest bardzo pobieżna. Problem pojawia się, gdy taka osoba zaczyna decydować o projekcie informatycznym nie mając do tego kompetencji. Praktyka pokazuje, że wiele kastomizacji systemów ERP to skutek wymagań postawionych przez te dwie role.

Obie te role mają duża odpowiedzialność w firmach, dlatego na etapie zawierania umów często stosują bardzo restrykcyjne formy “ochrony interesu swojego mocodawcy”, co bardzo często skutkuje negatywną selekcją dostawców (niekorzystne dla sienie umowy zawierają tylko desperaci). Bardzo ciekawy opis tego zjawiska opisała mec. Renata W. Lewicka w swoim artykule “ZASKAKUJĄCE ODKRYCIE: WISHFUL THINKING RZĄDZI W IT“. Księgowi mają także tendencje to zachowawczego stosowania metod rachunkowości, do jakich są przyzwyczajeni, co często koliduje z nowoczesnymi systemami FK oferowanymi na rynku.

I nie piszę tu o swoich doświadczeniach a tym co widzę w audytowanych firmach.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

 

Krótki wstęp

Od czasu do czasu są takie momenty, że świat podsuwa mi gotowe teksty do publikacji.  Każdy kto mnie zna i czyta wie, że od lat odradzam wdrażanie wielkich monolitów ERP, uzasadnienie tego z moich ust najczęściej jest jednak odbierane jako moje spekulacje (mimo, że zawsze uzasadniam swoje zdanie a przykładów nie brakuje). A o tym sądzą dyrektorzy firm?

(more…)