Wysokość wynagrodzenia jest przedmiotem negocjacji biznesowych. Warto jednak wprowadzić do umowy mechanizmy zabezpieczające interesy zamawiającego w tym obszarze.

 

Modele wynagrodzenia

Dwa najpopularniejsze modele wynagrodzenia to:

1. time&material – wysokość wynagrodzenia to iloczyn faktycznej pracochłonności po stronie zespołu dostawcy oraz wskazanej w umowie stawki za 1 dzień jego pracy;

2. fixed price (ryczałtowe) – dostawca otrzyma wskazane w umowie wynagrodzenie, niezależne od faktycznej pracochłonności projektu.

 

Najkorzystniejszy jest dla zamawiającego model wynagrodzenia ryczałtowego. Pozwala on lepiej zaplanować budżet projektu. Ponadto dostawca ma większą motywację, żeby sprawnie realizować wdrożenie – nie otrzyma bowiem wynagrodzenia w przypadku przekroczenia oszacowanej przez niego pracochłonności.

 

Harmonogram płatności

W przypadku większych projektów strony często ustalają harmonogram płatności. Uzgadniają w nim, kiedy wykonawca będzie mógł wystawić fakturę obejmującą określoną część wynagrodzenia.

Z perspektywy zamawiającego warto, aby płatności były zależne od odbiorów poszczególnych etapów projektu. Dzięki temu faktura będzie mogła zostać wystawiona dopiero po tym, jak zweryfikujemy dany etap wdrożenia w ramach procedur odbiorowych.

Zalecamy również, żeby możliwie dużą część wynagrodzenia za dany etap opłacić dopiero po odbiorze końcowym wdrożenia. Im większa kwota będzie płatna po zakończeniu całości projektu, tym większa będzie motywacja dostawcy, żeby go dokończyć.

 

Dodatkowe koszty za prace w lokalizacji zamawiającego

Wykonawcy często zastrzegają w ofercie, że prace realizowane w lokalizacji zamawiającego będą dodatkowo płatne. Wynika to konieczności przyjazdu personelu wykonawcy do biura zamawiającego.

Umowa powinna przewidywać, jakie będą stosowane stawki za dojazd oraz nocleg. Pozwoli to lepiej kontrolować budżet projektu. Najczęściej rekomendujemy stawkę za 1 km dojazdu oraz ryczałtową stawkę na nocleg.

 

Wycena zmiany zakresu

Realizacja projektu wdrożeniowego może wiązać się ze zmianą zakresu prac. Najczęściej oznacza to  zwiększenie wynagrodzenia wykonawcy.

Warto wskazać w umowie stawki za 1 dzień pracy wykonawcy, które będą brane pod uwagę przy wycenie takiej zmiany.

Nie unikniemy ryzyka zawyżenia pracochłonności zmiany przez nierzetelnego dostawcę, ale przynajmniej będziemy mieli punkt zaczepienia w trakcie rozmów biznesowych o jej wycenie.

Autor: Maciej Tabor, ekspert z zakresu prawa nowych technologii w kancelarii Lawspective Litwiński Valirakis Radcowie Prawni Sp.k. Wspiera zamawiających oraz wykonawców w projektowaniu i negocjacjach umów IT.

E-mail: maciej.tabor@lawspective.pl

 

Żaden producent oprogramowania nie jest skłonny do udostępnienia kodów źródłowych swoich produktów. Są jednak sytuacje, kiedy przekazanie kodów jest uzasadnione.

Kod źródłowy pilnie strzeżony

Jedną z form utrwalenia programu komputerowego jest zapis w postaci kodu źródłowego, wykonywany przy użyciu języka oprogramowania. Dysponując programem w takiej formie, programista jest w stanie dowolnie zmieniać jego kształt, kopiować i wykorzystywać jego elementy w innym produkcie. Aby nie dopuścić do wykorzystania przez konkurencję efektów prac swoich programistów, producenci oprogramowania utajniają kod źródłowy. Użytkownicy otrzymują oprogramowanie w formie gotowej aplikacji.

W takiej sytuacji jedynie producent ma faktyczną możliwość usuwania błędów oprogramowania. Dla tzw. pudełkowych (gotowych) programów sprowadza się to najczęściej do oferowania aktualizacji oprogramowania oraz usług utrzymania. Czas, w jakim taka oferta pozostanie aktualna, zależy od producenta oprogramowania.

Jeżeli jednak u zamawiającego został wdrożony system dedykowany, krytyczny dla działalności przedsiębiorstwa, warto zapewnić sobie możliwość samodzielnej naprawy oprogramowania. Rozwiązaniem może być tutaj depozyt kodów źródłowych.

Depozyt kodów źródłowych

Na podstawie umowy zawieranej z osobą trzecią – depozytariuszem:

• licencjodawca (najczęściej to producent oprogramowania) oddaje na przechowanie utrwalone na trwałym nośniku kody źródłowe i jednocześnie
• upoważnia licencjobiorcę – zamawiającego – do odbioru tych kodów w przypadku zaistnienia określonych okoliczności.

Mowa tutaj o sytuacjach, w których możliwość utrzymania (naprawy błędów) oprogramowania przez licencjodawcę zostanie wyłączona. Tak się dzieje np. w przypadku zaprzestania oferowania usług utrzymania dla oprogramowania wchodzącego w skład systemu albo w ogóle zaprzestania działalności przez licencjodawcę.

Co w umowie depozytu?

Umowa depozytu powinna szczegółowo regulować aspekty techniczne, w szczególności zobowiązać licencjodawcę do przedłożenia wszelkich elementów niezbędnych dla programisty do odtworzenia prawidłowo działającego programu komputerowego w wersji aplikacyjnej. Mowa m.in. o dokumentacji technicznej, bibliotekach, narzędziach instalacyjnych.

Należy uwzględnić również obowiązek licencjodawcy do aktualizacji wszystkich tych elementów.

Jednocześnie, na mocy umowy pomiędzy licencjodawcą a zamawiającym, ten ostatni musi uzyskać, najpóźniej z chwilą podjęcia kodów źródłowych z depozytu, uprawnienie do modyfikacji oprogramowania oraz korzystania z tak zmienionej jego wersji. Należy bowiem pamiętać, że niezależnie od formy, w jakiej program komputerowy został wyrażony, zawsze objęty jest ochroną prawa autorskiego.

Zapamiętaj z tego artykułu: Kody źródłowe są pilnie strzeżone przez producentów oprogramowania.  Są jednak sytuacje, w których zamawiający może je uzyskać.

Autor: Anna Adamek, radca prawny w kancelarii Lawspective Litwiński Valirakis Radcowie Prawni Sp.k.

E-mail: anna.adamek@lawspective.pl

W ramach wdrożenia wykonawca dostarcza szereg rezultatów swoich prac, tzw. produktów. Mowa przede wszystkim o systemie informatycznym, jego dokumentacji i dokumencie analizy. Zamawiający powinien uzyskać uprawnienia do korzystania z nich.

Nabycie tych uprawnień może nastąpić na podstawie:

• licencji lub
• umowy przeniesienia autorskich praw majątkowych.

Może się zdarzyć, że zamawiający do różnych elementów uzyska inny zakres uprawnień. Na przykład: do standardowej wersji oprogramowania  – licencję, natomiast do dodatkowych modułów stworzonych w ramach wdrożenia – autorskie prawa majątkowe.

Licencja

Licencja pozwala na korzystanie przez zamawiającego z rezultatów umowy, ale prawa do nich pozostaną przy wykonawcy.

Zakres uprawnień zamawiającego w ramach licencji wyznaczają:

• określone w umowie sposoby korzystania z utworów (tzw. pola eksploatacji);

uwaga: pamiętajmy, że jeśli mamy otrzymać prawo do modyfikowania oprogramowania, to powinniśmy również uzyskać prawo do korzystania ze zmienionej wersji oprogramowania;

• zakres terytorialny: niewskazanie terytorium oznacza jego ograniczenie do państwa naszej siedziby.

Zamawiający często zapominają o pułapkach związanych z okresem obowiązywania licencji. I tak:

• jeśli nie wskażemy okresu obowiązywania licencji, to wynosi on 5 lat;
• licencja udzielona na dłużej niż 5 lat po upływie tego terminu może zostać wypowiedziana przez wykonawcę na rok naprzód, na koniec roku kalendarzowego albo na zasadach określonych w umowie;
• licencję na czas nieokreślony wykonawca może w taki sam sposób od razu wypowiedzieć.

Pamiętajmy, że prawo polskie nie przewiduje możliwości udzielania licencji dożywotniej. Dlatego do umów wprowadzamy klauzule ograniczające możliwość jej wypowiedzenia przez dostawcę na tyle, na ile jest to dopuszczalne.

Przeniesienie autorskich praw majątkowych

Alternatywą wobec licencji jest nabycie autorskich praw majątkowych. Jest to opcja zdecydowanie korzystniejsza dla zamawiającego. Swoje uprawnienia do korzystania z systemu nabywa na stałe i może nimi swobodnie dysponować. Przeniesienie praw autorskich wyłączy też możliwość legalnego oferowania przez wykonawcę oprogramowania innym klientom.

Taki model często stosuje się, jeśli wykonawca opracuje w ramach umowy system dedykowany dla zamawiającego. Przeniesienie praw następuje wyłącznie w zakresie (tzw. polach eksploatacji) wskazanym w umowie.

Dla pełnej swobody korzystania z oprogramowania zamawiający powinien również uzyskać prawo do jego modyfikowania i korzystania ze zmienionej wersji. Istotny jest też dostęp zamawiającego do kodów źródłowych systemu. W przeciwnym wypadku modyfikacja nie będzie technicznie możliwa.

Pamiętajmy, że dla ważności przeniesienia umowa musi być formie pisemnej. Dopuszczalny jest kwalifikowany podpis elektroniczny.

Zapamiętaj z tego artykułu: umowa powinna regulować nabycie przez zamawiającego praw do jej rezultatów. W umowie licencyjnej uważajmy na pułapki, które mogą nas dużo kosztować.

Autor: Anna Adamek, radca prawny w kancelarii Lawspective Litwiński Valirakis Radcowie Prawni Sp.k.

E-mail: anna.adamek@lawspective.pl

Odbiór to jeden z kluczowych momentów wdrożenia. Warto o tym pamiętać już przy podpisywaniu umowy z wykonawcą. Dzięki określeniu w niej procedur i kryteriów odbiorowych można sprawdzić, czy dostawca należycie wywiązał się ze swoich zobowiązań.

Odbiory to moment weryfikacji przez zamawiającego poprawności wykonania dzieła (np. wdrożenia). Najczęściej dopiero na tym etapie  zamawiający może sprawdzić rezultat prac dostawcy.

 

Co na to Kodeks cywilny?

Zamawiający zobowiązany jest do odbioru dzieła, które wykonawca wykonał zgodnie z umową. Prawda, że niewiele? Pozostawia to duże pole do dyskusji z dostawcą, a to rodzi ryzyko sporu.

 

Kryteria odbioru

Warto możliwe szeroko określić w umowie katalog kryteriów odbioru. Ich spełnienie przy wdrożeniu jest warunkiem odbioru. Lista powinna obejmować przede wszystkim wymagania zamawiającego wynikające z umowy.

Warto też wskazać, że katalog kryteriów odbioru jest otwarty. Ograniczymy w ten sposób ryzyko wynikające z nieprecyzyjnych wymagań zamawiającego.

 

Procedury odbiorowe

Umowa powinna opisywać procedury odbiorowe. Wskażmy w niej:

• rodzaje testów realizowanych w ramach procedury,
• która strona odpowiada za ich realizację,
• termin na uwzględnienie przez dostawcę naszych uwag.

 

Odbiór etapów i odbiór końcowy

Wdrożenie często przebiega w etapach. Mogą one podlegać oddzielnym odbiorom, a projekt kończy się odbiorem końcowym.

Umowa powinna przewidywać, że odbiorowi końcowemu podlega wdrożenie jako całość. Dzięki temu zamawiający będzie mógł na końcu projektu zweryfikować całość prac, a nie tylko ich ostatni etap.

 

Odbiór jednostronny przez dostawcę

Unikajmy prawa jednostronnego odbioru przez wykonawcę w przypadku milczenia zamawiającego. Możemy w ten sposób stracić szansę na weryfikację przedmiotu odbioru.

Jeśli wprowadzamy takie prawo, wskażmy że przed jednostronnym odbiorem wykonawca wezwie nas i wyznaczy dodatkowy termin na zgłoszenie uwag lub dokonanie odbioru.

 

Start produkcyjny, okres stabilizacji

Umowa może przewidywać, że warunkiem odbioru jest poprawny start produkcyjny systemu. Pozwala on ocenić, czy system prawidłowo uruchamia się produkcyjnie.

Z kolei okres stabilizacji pozwala stwierdzić, jak system działa na środowisku produkcyjnym. Warto wskazać, że okres stabilizacji kończy się po ustabilizowaniu systemu, a nie w danym terminie.

Przykładowo, można wskazać, że okres stabilizacji trwa przez dany okres, ale przedłuża się do momentu, w którym w systemie nie występują błędy o określonych kategoriach.

Zapamiętaj z artykułu: Wskaż w umowie procedury i kryteria odbiorowe. Dzięki temu będziesz  mógł sprawdzić, czy dostawca należycie wywiązał się z umowy.

 

Autor: Maciej Tabor, ekspert z zakresu prawa nowych technologii w kancelarii Lawspective Litwiński Valirakis Radcowie Prawni Sp.k. Wspiera zamawiających oraz wykonawców w projektowaniu i negocjacjach umów IT.

E-mail: maciej.tabor@lawspective.pl