fbTrack
REKLAMA
REKLAMA

Prawo autorskie

Systemy informatyczne w firmie trzeba wprowadzać ostrożnie

Kiedy firmie informatycznej zlecamy wdrożenie systemu IT, zawieramy z nią umowę. Nieuważne sporządzenie takiego dokumentu może narazić nas na straty
Wiele codziennych czynności, takich jak wypłata pieniędzy z bankomatu, regulowanie rachunków telefonicznych czy analizowanie historii transakcji na koncie, nie byłoby możliwych bez istnienia zintegrowanych systemów komputerowych. Często obsługują one kluczowe funkcje wielu przedsiębiorstw, a od ich sprawnego funkcjonowania zależy jakość świadczonych przez firmy usług.
Systemy komputerowe są zatem ważnym elementem przy prowadzeniu zarówno wielkiego, jak i małego biznesu. Ich wdrożenie, a z czasem utrzymanie (serwis, modernizacja) wymaga jednak wielu zabiegów: uzgodnienia aspektów finansowych, technicznych i prawnych oraz skoordynowania wielu działań zarówno po stronie dostawcy, jak i klienta. W trakcie wdrażania systemu IT zawiera się kilka umów, a każdą z nich regulują odrębne przepisy. Takie umowy są też dość nietypowe, bo ich głównym przedmiotem jest oprogramowanie, czyli nie rzecz, a informacja (ciąg poleceń zapisanych w języku programistycznym). Nie można ich zatem traktować tak samo jak umowy sprzedaży samochodu czy wyposażenia biura w meble. Sporządzenie umów dotyczących wdrożenia systemu IT jest więc złożonym procesem obarczonym znacznym ryzykiem.
Wprowadzanie systemu komputerowego w przedsiębiorstwie zaczyna się od analizy stanu istniejącego oraz konsultacji wewnętrznych. Etap ten ma na celu zdefiniowanie, jakiego systemu komputerowego potrzebuje zamawiający, na jak długi okres przewiduje się jego użytkowanie, czy ma to być stosunkowo proste wdrożenie oprogramowania standardowego, czy też dużo bardziej skomplikowane wdrożenie systemu szytego na miarę, tj. napisanego zupełnie od podstaw. Następnie zamawiający musi sobie odpowiedzieć na pytanie, czy będzie w stanie serwisować system, który pragnie wdrożyć, własnymi siłami, czy też należy rozważyć podpisanie umowy na serwisowanie i utrzymanie systemu. Istnieje bardzo wiele form wyboru wykonawcy wdrożenia systemu IT. Na wybór formy mogą mieć w szczególności wpływ przepisy prawa o zamówieniach publicznych. W zależności od sytuacji zamawiający może zastosować rozmaite tryby udzielenia zamówienia: począwszy od przetargu, a na zamówieniu z wolnej ręki kończąc. Po wybraniu najkorzystniejszej oferty firmy wykonawca robi analizę przedwdrożeniową. Przedstawia koncepcje całego projektu, a jeśli zleceniobiorca będzie z niej zadowolony – realizuje wdrożenie. Jego pomysł może się jednak zamawiającemu nie spodobać. Dlatego zawierając umowę, warto ją rozdzielić na dwie części. Pierwszą na wykonanie analizy przedwdrożeniowej i drugą – już właściwą umowę wdrożeniową. Nie ma wówczas konieczności, aby wdrożenie przeprowadził podmiot, który przygotował wstępną koncepcję. Koncepcja wdrożenia nie jest programem komputerowym, stanowi jednak jego zalążek. Dlatego wykonawca powinien zastrzec w umowie, że zamawiający musi uzyskać prawa autorskie bądź licencję, które umożliwią wykorzystanie koncepcji (jeśli w przyszłości zleci się samo wdrożenie innej firmie). Umowa wdrożeniowa wymaga przede wszystkim sprawnej komunikacji między zespołem merytorycznym a prawnikami. Ogromna liczba wariantów, rozwiązań biznesowych i technicznych wpływa na mnogość (i trudność wyboru) modeli prawnych. Na pewno kluczowe aspekty prawne to m.in. precyzyjne określenie przedmiotu umowy (trudne zadanie przed powstaniem analizy), zagadnienia własności intelektualnej, w tym prawa do programów i skryptów powstałych w trakcie wdrożenia, mechanizmy kar umownych (wbrew pozorom większe nie zawsze znaczą lepsze), zasady testów i odbiorów, zarządzanie projektem i procedurą zmian (nie do uniknięcia w rozbudowanych umowach) oraz wyjątkowo trudna kwestia odstąpienia od umowy i wzajemnych rozliczeń. Bardzo ważne jest, aby umowa opisywała faktyczny przebieg wdrożenia, a nie wizje zespołu negocjacyjnego, niemające nic wspólnego z codziennością i metodyką projektową. Wojtek Kaliński, wspólnik kancelarii Kuczek Maruta i Wspólnicy Umowy wdrożeniowe to przede wszystkim klasyczna cywilistyka. Niestety, przepisy z lat 60. ubiegłego wieku w wielu sytuacjach nie sprawdzają się w nowoczesnych rozwiązaniach biznesowych. Tytułem przykładu można podać zasady wypowiadania umów czy odstępowania od nich, niezwykle rygorystyczne dla wykonawców, nieuwzględniające specyfiki wdrożeń IT (np. opóźnień). Większa elastyczność przepisów, więcej norm dyspozytywnych, gruntowna nowelizacja kodeksu cywilnego to chyba to, czego potrzebujemy najbardziej. Bardzo przydałoby się też orzecznictwo, system precedensów, który pozwoliłby zweryfikować, jakie zachowania możemy uznać za ustalony zwyczaj, gdzie przebiega granica należytej staranności w IT, jakie przypadki należy uznać za „ważne przyczyny” itp. Polskie prawo nie definiuje umowy wdrożeniowej. Nie ma jej w katalogu umów nazwanych obok umowy sprzedaży, leasingu czy też umowy-zlecenia W jaki zatem sposób skonstruować taką umowę i z jakich przepisów korzystać? Ze strony wykonawcy w ramach jednego wdrożenia występuje wiele różnych świadczeń. Instalacja i konfiguracja systemu wymaga umowy o dzieło. Przeprowadzenie szkoleń to już wykonanie usługi, natomiast prace programistyczne to świadczenia wymagające umów prawnoautorskich. Wykonawca jest także odpowiedzialny za eksploatację systemu, czyli usługi serwisowe i modyfikacje oprogramowania. Inne będą zatem sankcje za złe przeprowadzenie szkolenia pracowników, a inne za źle działający program, mimo że wszystkie te usługi są jednym kompleksowym zleceniem. Przy umowie o dzieło (np. konfiguracja systemu) stosuje się przepisy kodeksu cywilnego, a przy umowie o stworzenie utworu – przepisy prawa autorskiego. Z tym związane są odmienne przesłanki odstąpienia zamawiającego od umowy o wykonanie i inne skutki prawne odbioru jakościowego. Można zawrzeć jednak jedną umowę, którą będziemy traktować jako całość z uwagi na cel gospodarczy, zastrzegając w niej jednocześnie, według jakich przepisów sankcjonowane będą poszczególne zlecenia. Innym rozwiązaniem kwestii wielości umów jest ich ramowy podział i podpisywanie każdej oddzielnie, czasem z różnymi wykonawcami (jej postanowienia mają zastosowanie do kilku niezależnych umów). Plusem tego rozwiązania jest możliwość łatwiejszego odstąpienia od umowy, zarówno w przypadku wykonawcy, jak i zlecającego. Ponadto do każdego z wytworów intelektualnych stosuje się właściwe dla nich przepisy. Z punktu widzenia prawa własności intelektualnej różne są zasady ochrony poszczególnych rezultatów wdrożenia, czyli m.in. samego programu komputerowego (ochrona w ramach prawa autorskiego art. 74 – 772), dokumentacji czy know-how. Brakuje natomiast ochrony języka programowania, formatu plików czy algorytmów. Także interfejs nie podlega ochronie prawa autorskiego. Metodę organizacyjną okien dialogowych można chronić na podstawie ustawy o zwalczaniu nieuczciwej konkurencji. Do programu komputerowego nie mają zastosowania przepisy kodeksu cywilnego odnoszące się do rzeczy, a w szczególności dotyczące rękojmi. Z drugiej strony przepisy te mają odpowiednie zastosowanie do oprogramowania, które powstaje w wyniku wykonywania umowy o dzieło. Jednocześnie do oprogramowania mają zastosowanie przepisy prawa autorskiego. Te dwa zestawy przepisów nie są spójne i pozostawiają wiele wątpliwości dotyczących ich wzajemnych relacji. Niezależnie od tego istotne są zwyczaje obowiązujące w branży IT i specyfika oprogramowania. Warto pamiętać, że po podpisaniu protokołu odbioru wdrożenia zamawiający nie ma praw do rękojmi. Wszelkie roszczenia, spowodowane np. usterkami, trzeba przedstawić przed podpisaniem umowy końcowej. Zamawiający może się jednak zabezpieczyć na kilka sposobów, zastrzegając w umowie pewne warunki. Jednym z nich jest oświadczenie o odbiorze z żądaniem zmiany, czyli odbiór warunkowy. Innym rozwiązaniem jest podział wdrożenia na konkretne zadania, fazy czy etapy, które będą sukcesywnie odbierane. Jednak wówczas istnieje niebezpieczeństwo, że w czasie ostatecznych testów integracyjnych okaże się, że niektóre moduły ze sobą nie współgrają. Dlatego w umowie należy zastrzec nie tyle podział na etapy, ile możliwość przetestowania programu przed ostatecznym podpisaniem protokołu odbioru. Podczas wdrażania systemu niezbędne jest podejmowanie na bieżąco decyzji istotnych dla dalszego rozwoju prac. W wypadku niewielkich firm, gdzie osoba decyzyjna – prezes czy właściciel – z reguły jest na miejscu, nie ma problemu. Jednak w wypadku większych przedsiębiorstw sprawny nadzór nad pracami może się okazać pewnym utrudnieniem. Co więcej, podczas wdrażania systemu komputerowego wiele czynności powinien zatwierdzić szeregowy pracownik, a nie właściciel firmy. Z kolei w razie radykalnych zmian, np. poszerzenia zakresu prac czy odbioru końcowego, obecność osoby decyzyjnej jest niezbędna. Chodzi o kwalifikacje i niezbędną wiedzę, np. podczas odbioru etapu wdrożenia jego jakość powinien zatwierdzić pracownik merytoryczny, czyli informatyk. Warto zatem przed podpisaniem umowy poznać różnice prawne między oświadczeniami woli a oświadczeniami wiedzy, a następnie podczas organizacji wdrożenia odpowiednio umocować uczestników projektu. W wypadku wdrożenia programu IT z uwagi na złożony charakter projektu pojawia się wiele bardzo istotnych oświadczeń woli. Przykładem oświadczeń woli składanych podczas wdrożenia są te dotyczące: - wdrożenia, czyli np. odbiór jego etapu, - umowy wdrożeniowej, czyli np. zwolnienie z obowiązku poufności, odstąpienie od umowy. Takie oświadczenia mogą składać organy osoby prawnej (wykonawca/zamawiający), ale także właśnie pełnomocnik umocowany przez ten organ. Warto więc zaznaczyć w umowie, komu i w jakim zakresie powierzamy pełnomocnictwo decyzyjne. Gdy oświadczenie woli złoży osoba przez nas nieumocowana, mogą zostać wyciągnięte wobec niej konsekwencje prawne. Kwestię tę reguluje kodeks cywilny. W art. 39 § 1 jest mowa o działaniu w charakterze organu bez umocowania lub z jego przekroczeniem, natomiast w art. 103 § 1 o działaniu w charakterze pełnomocnika bez umocowania lub z jego przekroczeniem. W wypadku programów komputerowych ustawa o prawie autorskim znacznie szerzej niż w wypadku utworów należących do innych kategorii twórczości ujmuje treść praw majątkowych Osoby, które nabędą takie prawa, mogą nie tylko zwielokrotniać utwór, lecz także go modyfikować i rozpowszechniać. Dodatkowo art. 77 prawa autorskiego wyłącza większość ograniczeń autorskich praw majątkowych, w tym przede wszystkim – do użytku prywatnego. Rysujący się w ten sposób monopol autorski obejmuje w zasadzie każdą formę eksploatacji programu komputerowego podejmowaną przez użytkownika końcowego. Aby się nim stać, trzeba nabyć prawa od autora. Najczęściej dzieje się to za pośrednictwem umowy licencyjnej, ale zdarza się, że autorskie prawa majątkowe zostają przeniesione. W obu sytuacjach niezbędne jest zawarcie umowy między stronami. Ze względu na specyfikę zagadnienia, taki dokument powinien być bardzo szczegółowy. – Umowa dotycząca programów komputerowych to swoista polisa ubezpieczeniowa. Zarówno zleceniodawcy, jak i wykonawcy. Trzeba zatem bardzo dokładnie i uważnie je przygotować – tłumaczy Xawery Konarski z kancelarii prawnej Traple Konarski Podrecki. Umowy opisane w art. 41 – 68 prawa autorskiego dzielą się na przenoszące prawo oraz licencyjne. Te pierwsze powodują trwałe przeniesienie na inny podmiot autorskich praw majątkowych w zakresie wyspecyfikowanych pól eksploatacji. Natomiast umowa licencyjna polega na czasowym uzyskaniu uprawnienia do korzystania z określonych obszarów oprogramowania. W wypadku oprogramowania dedykowanego, czyli stworzonego z przeznaczeniem dla jednego odbiorcy, ma zawsze miejsce przeniesienie autorskich praw majątkowych. Natomiast oprogramowania standardowe, uniwersalne, są najczęściej udostępniane na zasadzie licencji. Umowy przenoszące autorskie prawa majątkowe mogą być kwalifikowane jako znane kodeksowi cywilnemu umowy nazwane (sprzedaż, zamiana, darowizna, umowa o dzieło) lub nienazwane. Przeniesienie prawa ma miejsce tylko w wypadku wyraźnego wskazania takiego skutku umowy (domniemanie udzielenia licencji – art. 65 prawa autorskiego). Pod rygorem nieważności wymagana jest pisemna forma umowy. W wypadku umów licencyjnych sprawa jest bardziej złożona. Dzieli się je bowiem na trzy rodzaje: - wyłączne: licencjobiorca korzysta z programu w pełnym zakresie (taka umowa musi mieć formę pisemną, zastrzeżoną pod rygorem nieważności), - o słabszej wyłączności: poza licencjobiorcą korzysta z niego także licencjodawca, - niewyłączne: program jest eksploatowany równolegle. W umowie licencyjnej należy zamieścić więc postanowienia dotyczące wyłączności korzystania z utworu oraz (a o tym często się zapomina) o zezwoleniu uprawnionemu na udzielanie sublicencji. Istotny jest także czasowy i terytorialny zakres licencji. Jeśli w umowie nie będzie odmiennych postanowień, przyjmuje się, że licencja jest udzielana na pięć lat i na terytorium państwa, na którym licencjobiorca ma swoją siedzibę. W wypadku wypowiedzenia umowy licencyjnej, niezależnie od czasu, na jaki została zawarta, trzeba to zrobić rok wcześniej. Dokładnie musi być to pełen rok kalendarzowy. Udzielenie licencji lub przeniesienie prawa może mieć miejsce z chwilą przyjęcia utworu, z chwilą zapłaty wynagrodzenia lub z chwilą dostarczenia utworu. Obrót prawami autorskimi został zorganizowany w oparciu o konstrukcję pola eksploatacji. Chodzi o sposoby korzystania z utworu. W prawie autorskim zasada umownej specyfikacji pól eksploatacji jest ujęta dość restrykcyjnie. Zgodnie z art. 41 ust. 2 umowa może dotyczyć tylko pól eksploatacji, które są znane w chwili jej zawarcia. W konsekwencji nie jest możliwe przeniesienie prawa lub udzielenie licencji w odniesieniu do całości autorskich praw majątkowych. Zgodnie z art. 41 ust. 2 prawa autorskiego umowa o przeniesienie autorskich praw majątkowych lub umowa licencyjna obejmuje wyłącznie pola eksploatacji „wyraźnie w niej wymienione”. W kwestii interpretacji restrykcyjności tego przepisu zdania są podzielone. Zdaniem jednych wymogu takiego nie spełniają umowy o przeniesienie prawa i umowy licencyjne, które mówią o „wszystkich przysługujących uprawnionemu” lub też „wszystkich wymienionych w ustawie” polach eksploatacji. Inni natomiast postrzegają wymóg specyfikacji nieco mniej restrykcyjnie. Ze względu na wyraźnie ochronną funkcję tego przepisu brak powodów jego stosowania w przypadku, gdy stroną umowy nie jest rzeczywisty twórca. Aby uniknąć nieporozumień, warto podczas podpisywania umowy uzgodnić tę kwestię. Nie ma przy tym obowiązku używania terminologii zaczerpniętej z art. 50 prawa autorskiego, który zawiera przykładowy katalog pól eksploatacji (nadawanie, reemitowanie, wprowadzanie do obrotu, najem, użyczenie), jednak ułatwia to znacznie sprecyzowanie wymogów czy żądań obu stron i pozwala uniknąć interpretacyjnych nieporozumień. Problemy interpretacyjne mogą się pojawić w jeszcze innym kontekście. Chodzi o niedoprecyzowanie samego sposobu eksploatacji. Będzie np. mowa o zwielokrotnieniu, ale bez wskazywania konkretnej techniki albo użyte będą określenia wspólne dla kilku wyodrębnionych w ustawie pól eksploatacji. W takich przypadkach należy odwołać się do ogólnych zasad wykładni oświadczeń woli, przede wszystkim art. 65 kodeksu cywilnego, wziąć pod uwagę zamiar stron i cel kontraktu, a także uwzględnić zwyczaje panujące w danej dziedzinie twórczości. Tak stwierdził Sąd Najwyższy w wyroku z 14 września 2005 r. (III CK 124/05). – Jeżeli umowa mówi ogólnie o „wydaniu drukiem w postaci książkowej” w typowej postaci, oznaczać to będzie m.in. wprowadzenie do pamięci komputera w celu przeprowadzenia prac redakcyjnych i składu książki, zwielokrotnienie techniką drukarską, a następnie wprowadzenie do obrotu egzemplarzy – tłumaczy Xawery Konarski. Uwaga! W umowach dotyczących programów komputerowych praktykowana jest zasada, że w razie niewymienienia w umowie pól eksploatacji zakres uprawnień użytkownika powinien gwarantować przynajmniej zwielokrotnianie i modyfikowanie. Oczywiście w zgodzie z zamierzonym przeznaczeniem (implementacja art. 5 ust. 1 dyrektywy 91/250/EWG). Co jednak w sytuacji, gdy w umowie wymieniono pola eksploatacji wyraźnie, ale zbyt wąsko, nadmiernie ograniczając w ten sposób zakres uprawnień użytkownika. – Zgodnie z dyrektywą 91/250/EWG nie można zakazywać „ładowania i uruchamiania” programu, a także poprawiania błędów, jeśli jest to niezbędne do korzystania z kopii legalnie kupionego oprogramowania – mówi dr Zbigniew Okoń z kancelarii prawnej Traple Konarski Podrecki. – Do uprawnień użytkownika, które nie mogą być wyłączone umową, zalicza się wszystkie podstawowe sposoby korzystania z programu, przede wszystkim zwielokrotnienia związane z jego instalacją, przygotowywaniem i uruchamianiem oraz przechowywaniem w pracy i modyfikowaniem w celu usunięcia błędów. Ponadto regulacje zawarte w art. 75 ust. 2 i 3 prawa autorskiego uprawniają do sporządzenia jednej kopii zapasowej, obserwowania, badania i testowania programu. To ważne, bo trzeba brać pod uwagę dekompilacje i ewentualne późniejsze współdziałanie tego programu z innymi. Przykładem niedozwolonych postanowień umownych będzie zakaz dekompilacji dla celów tworzenia oprogramowania substytucyjnego, zobowiązanie użytkowników do uprzedniego zwrócenia się do producenta o udostępnienie niezbędnych do dekompilacji danych czy jakiekolwiek związane z tym roszczenia finansowe. Jeżeli kupujemy wyłączne prawa do korzystania z programu komputerowego, czyli dochodzi do przeniesienia prawa autorskiego, mamy prawo do samodzielnego dysponowania utworem. Możemy przenieść nabyte prawa na kolejną osobę (albo ich część, którą określi pole eksploatacji) lub udzielić sublicencji. Udzielamy jej tylko w takim zakresie, jaki został nam udostępniony przez autora. Jednocześnie prawo autorskie nie zapewnia żadnej ochrony nabywcy w dobrej wierze. – Dlatego też nie można nabyć autorskich praw majątkowych do rozpowszechniania plakatu reklamowego od agencji reklamowej, która nie nabyła ich od grafika, autora plakatu – tłumaczy Xawery Konarski. I tu pierwsza wskazówka dla zawierających umowę dla wykonawcy. Na podstawie art. 41 ust. 1 pkt 2 prawa autorskiego możemy zakazać dalszego zbywania autorskich praw majątkowych lub wprowadzić w tym względzie odpowiednie ograniczenia. Można także zawęzić krąg osób, którym te prawa miałyby być przekazane, wprowadzić ograniczenia czasowe lub zakazać dalszego przenoszenia praw, dopuszczając jedynie udzielanie licencji. Nabywca, który zobowiązał się nie przenosić praw na osobę trzecią, ale jednak to zrobił, jest jako jedyny odpowiedzialny wobec twórcy za nienależyte wykonanie umowy. Mimo że strony mają dowolność przy wyborze rodzaju umowy, ustawodawca preferuje umowy licencyjne. Popularną formą udostępnienia na wyłączność jest umowa licencyjna. Od przeniesienia autorskich praw majątkowych różni się tym, że licencjobiorca ma wyłączność przez określony czas. Tego typu umowa nie przenosi praw, a tylko je wypożycza. Licencjobiorca uzyskuje względne uprawnienia do korzystania z utworu, do którego autorskie prawa majątkowe nadal przysługują licencjodawcy. Uwaga! Można przenosić uprawnienia nabyte na podstawie umowy licencyjnej w drodze sukcesji generalnej, a więc np. udostępnienia ich, jako składnika przedsiębiorstwa, współpracownikom. Zbywalność takich uprawnień jest dość problematyczna i nawet praktycy prawa nie są do końca zgodni w tej kwestii. Chodzi nie tyle o udzielenie sublicencji – to zostało jednoznacznie uregulowane w art. 67 ust. 3, ile o wstąpienie innej osoby w miejsce dotychczasowego licencjodawcy. Problem polega na tym, że można twierdzić, iż skoro w wyniku udzielenia licencji licencjobiorca uzyskuje prawo (wierzytelność) względem licencjodawcy, to możliwe jest przeniesienie uprawnień nabytych przez tego pierwszego na osobę trzecią w drodze przelewu wierzytelności (chyba że w umowie postanowiono inaczej). Przeważa jednak pogląd, że przeniesienie uprawnień wynikających z umowy licencyjnej na osobę trzecią wymaga zgody licencjodawcy wyrażonej w umowie. – Umowy z zakresu prawa autorskiego są umowami szczególnego zaufania, a twórcy często nie jest obojętne, kto eksploatuje jego utwór. Wydanie książki w renomowanym wydawnictwie może jej zapewnić większą sprzedaż i lepsze recenzje niż wydanie jej w wydawnictwie specjalizującym się w literaturze podrzędnej – tłumaczy Zbigniew Okoń. Składa się głównie z kilku różnych typów umów oraz wielu załączników technicznych: - umowa o wdrożeniu systemu (zazwyczaj ma formę prawną umowy o dzieło), - umowa licencyjna o używaniu oprogramowania, - umowa serwisowa (świadczenie usługi), - określona specyfikacja techniczna, - oświadczenie woli, - warunki płatności, - umowa depozytu kodu źródłowego (powierzenie kodu wybranej osobie trzeciej, która może udostępnić go klientowi w razie spełnienia określonych warunków). Warto podczas redagowania umowy zagwarantować sobie od wykonawcy: - oświadczenie o dochowaniu należytej staranności z uwzględnieniem zawodowego (profesjonalnego) charakteru jego działalności, - oświadczenie o braku przeszkód do należytego wykonania wdrożenia, - oświadczenie o świadomości znaczenia, jakie ma dla nas termin wykonania, - zobowiązanie do wykonania prac wdrożeniowych zgodnie z obowiązującymi przepisami (np. migracja danych a przepisy o ochronie danych osobowych). Zasadniczo na rynku IT istnieją dwa systemy określania sposobu wynagradzania: formuła ryczałtowa lub formuła czas i materiały (time & material). Pierwsza wersja jest typowa dla wszelkiego typu umów, w których zdefiniujemy zakres i liczbę prac do wykonania (czyli konstrukcji typowej dla klasycznej umowy o dzieło). Druga, oparta na zasadzie płatności za godzinę/dzień pracy konsultanta oraz zwrocie poniesionych kosztów, jest stosowana w sytuacjach, gdy wykonawca angażowany jest jako wsparcie wdrożenia prowadzonego zasadniczo przez samego zamawiającego. W przypadku umów serwisowych z ustalonymi poziomami usług standardowym rozwiązaniem jest ryczałt. Formuła czas i materiały dotyczy sytuacji, gdy zamawiający jedynie okazjonalnie zamawia usługę serwisową czy też usługę wsparcia, płacąc za zaangażowanie konsultanta dostawcy.
Źródło: Rzeczpospolita
REKLAMA
REKLAMA
REKLAMA
REKLAMA
NAJNOWSZE Z RP.PL
REKLAMA
REKLAMA