SPCG for FinTech (cz. 2) – Jakie IP powstaje w ramach projektów FinTech?

SPCG for FinTech (cz. 2) – Jakie IP powstaje w ramach projektów FinTech?

Czytaj: 6 min

We wcześniejszym wpisie z cyklu SPCG for FinTech [Know your IP] podkreślaliśmy znaczenie praw własności intelektualnej, do rozwiązań technologicznych, z których korzysta instytucja finansowa. Jednak pod określeniem prawa własności intelektualnej kryją się różne rodzaje dóbr niematerialnych oraz różne mechanizmy powstawania tych praw. Świadomość tych różnic przekłada się na efektywniejsze planowanie strategii zarządzania własnością intelektualną instytucji finansowej – zarówno wytwarzanej wewnętrznie, jak i pozyskiwanej od kontrahentów.

Własność intelektualna („IP”), to w uproszczeniu dobra niematerialne, które ze względu na cechy nadanie im przez twórcę mogą podlegać ochronie za pomocą praw wyłącznych. Wyłączność prawna do tych dóbr niematerialnych oznacza, że „właściciel” prawa jako jedyny jest uprawniony do korzystania z tego dobra niematerialnego i decydowania, jaka osoba trzecia może z tego dobra korzystać. Na przykład, autor fotografii decyduje, czy zezwoli komukolwiek na tworzenie jej kopii oraz jej rozpowszechnianie w mediach społecznościowych.

Zarówno w Polsce, jak i w innych państwach, ochrona własności intelektualnej opiera się na dwóch podstawowych filarach – ochronie utworów za pomocą przepisów ustawy o prawie autorskim i prawach pokrewnych („prawo autorskie”) oraz ochronie dóbr własności przemysłowej (np. wynalazki, wzory przemysłowe, znaki towarowe) za pomocą przepisów ustawy prawo własności przemysłowej („prawa własności przemysłowej” to m.in. patent na wynalazek, prawo z rejestracji wzoru przemysłowego, prawo ochronne na znak towarowy). W ramach każdego z tych filarów możliwe jest uzyskanie ochrony na dobro niematerialne, ochrona ta będzie zasadniczo ograniczona czasowo oraz terytorialna. Jednak filozofia stojąca za uzyskiwaniem ochrony jest zdecydowanie różna.

Prawo autorskie

Utwór chroniony jest prawem autorskim od chwili jego ustalenia, chociażby miał postać nieukończoną, jeśli tylko spełnia warunki określone w ustawie (odznacza się oryginalnością oraz indywidualnym charakterem). Moment powstania utworu jest trudny do uchwycenia, zasadniczo chodzi tutaj o chwilę, gdy tworzony materiał jest oryginalny i odzwierciedla indywidualny charakter twórcy – zwłaszcza w kontekście programów komputerowych określa się te warunki łącznie, jako „własną intelektualną twórczość autora”.

Wyłączność prawna, czyli w tym przypadku – prawa autorskie – powstaje bez konieczności dopełnienia żadnych formalności. Jednym słowem, prawa autorskie powstaną niezależnie od tego, czy twórca jest tym zainteresowany. Prawa autorskie do utworu powstają zarówno w Polsce, jak i w innych państwach świata, przy czym między zasadami prawnoautorskiej ochrony utworów w różnych państwach występują pewne różnice. Ochrona, przynajmniej w jej wymiarze majątkowym, trwa przez cały okres życia twórcy lub tego współtwórcy, który przeżył pozostałych a następnie przez 70 lat licząc od pierwszego pełnego roku po śmierci twórcy lub tego współtwórcy, który przeżył pozostałych [1]. Jednym słowem warunki powstania ochrony są prawnoautorskiej niewygórowane, obejmuje ona terytorium niemal wszystkich państw świata i trwa dosyć długo.

Prawa własności przemysłowej

Z niewielkimi wyjątkami, prawa własności przemysłowej powstają na mocy decyzji wydanej przez urząd patentowy właściwy dla terytorium, dla którego zgłaszający ubiega się o ochronę. Inaczej niż w przypadku prawa autorskiego, jeżeli zainteresowany – twórca lub osoba, która nabyła od twórcy prawo do dokonania zgłoszenia – nie wykaże inicjatywy, prawo wyłączne nie powstanie w ogóle albo tylko na wybranych terytoriach. Przykładowo, jeżeli twórca dokonał wynalazku [2], to musi przygotować dokumentację zgłoszeniową (podanie, opis wynalazku, zastrzeżenia patentowe), uiścić opłatę zgłoszeniową i przedłożyć całość urzędowi patentowemu. Urząd w pierwszej kolejności sprawdzi poprawność wniosku o udzielenie patentu a następnie ustali, czy zgłoszone rozwiązanie faktycznie jest przemysłowo stosowalne, nowe i ma poziom wynalazczy. W razie odpowiedzi pozytywnej, urząd wyda decyzję o przyznaniu patentu [3]. Na podobnych zasadach wydawane są decyzje odnośnie wzorów przemysłowych oraz znaków towarowych, przy czym zakres badania zgłoszenia może być odmienny np. w przypadku zgłoszenia wzoru przemysłowego Urząd Patentowy RP sprawdza głównie wymogi formalne. Taką operację należy przeprowadzić w każdym państwie, w którym chce się uzyskać ochronę np. przed Niemieckim Urzędem ds. Patentów i Znaków Towarowych, brytyjskim Urzędem ds. Własności Intelektualnej. W pewnym zakresie dostępne są prawa wyłączne o zakresie regionalnym (np. znak towarowy UE) albo międzynarodowe procedury, które ułatwiają uzyskanie praw własności przemysłowej w większej liczbie państw.

Sposób uzyskiwania praw własności przemysłowej sprawia, że – inaczej niż w przypadku utworów – bardzo łatwe jest ustalenie, czy jakieś dobro niematerialne jest chronione w danym państwie, czego dokładnie ono dotyczy oraz kto jest właścicielem prawa. Daje to możliwość zorientowania się przykładowo, czy:

  • rozwiązania, nad którymi pracuje Spółka zostały już opatentowane i korzystanie z nich może stanowić naruszenie patentu;
  • „wglądu” w technologie, które rozwijają konkurenci, nieraz zanim technologia zostanie udostępniona klientom jako dopracowany produkt.

 

IP w projektach FinTech

Rozwiązania FinTech opierają się przede wszystkim na oprogramowaniu, czy to udostępnianym klientowi (np. aplikacja mobilna banku), czy używanym jedynie wewnętrznie (np. program komputerowy służący do analizy danych dotyczących transakcji przeprowadzonych przez klientów). Fundamentalna rola funkcjonalności programów komputerowych – nazywanych czasem maszynami zbudowanymi ze słów – sprawia, że są one chronione dwojako. Z jednej strony treść programu komputerowego może być utworem, z drugiej strony, oferowana przez program funkcja może mieć znaczenie dla wynalazku.

W świetle przepisów prawa autorskiego programem komputerowym jest kod źródłowy lub wynikowy o określonej treści, a także, pod pewnymi warunkami, przygotowawcze materiały projektowe [4]. Dla ochrony prawem autorskim nie ma znaczenia czy program został ukończony, czy jest pozbawiony błędów bądź czy ma istotną wartość majątkową dla Spółki. Wystarczy, żeby programista piszący kod dokonał swobodnego wyboru ujęcia pewnych kwestii w kodzie, aby kod ten odzwierciedlał własną intelektualną twórczość tego programisty. Próg „własnej intelektualnej twórczości” jest dość łatwy do pokonania i dotyczy on także przypadków, w których programista nie koduje programu samodzielnie, ale jest członkiem większego zespołu rozwijającego oprogramowanie napisane pierwotnie przez inny zespół – np. wewnętrzny zespół banku rozwija oprogramowanie zakupione od zewnętrznego dostawcy.

Wyłączność prawna wynikająca z praw autorskich do programów komputerowych jest szersza niż w przypadku innych utworów i obejmuje ona m.in.:

  • tworzenie kopii programu, w tym kopii fragmentów programu w pamięci tymczasowej, co jest nieraz niezbędne do samego uruchomienia programu;
  • wprowadzanie jakichkolwiek zmian do programu komputerowego, w tym przysłowiowej zmiany jednego znaku w kodzie źródłowym.

Z tego powodu istotne jest nabywanie autorskich praw majątkowych od wszystkich osób zaangażowanych w proces powstawania oprogramowania dla Spółki. „Luki” w tym zakresie uniemożliwiają pełne korzystanie z programów komputerowych. Czasochłonnym wyzwaniem może być nawet samo ustalenie, co dokładnie stworzył dany pracownik – w rezultacie jak szeroka jest wspomniana luka i jakich systemów informatycznych Spółki ona dotyczy.

Ochrona patentowa oprogramowania jest dużo bardziej złożona niż ochrona prawem autorskim a możliwość jej uzyskania różni się w zależności od terytorium. W uproszczeniu, w USA patentowanie programów komputerowych jest generalnie łatwiejsze niż w Europie. Europejskie wątpliwości wynikają przede wszystkim z faktu, że program komputerowy jako taki nie ma charakteru technicznego [5] i patentowanie programów komputerowych „jako takich” jest wprost wyłączone w krajowych przepisach np. w Polsce. Zmusza to zgłaszających do pewnej ekwilibrystyki w zgłaszaniu rozwiązań, które dotyczą procesów lub urządzeń „wspomaganych komputerowo” bądź programów komputerowych wywołujących tzw. dalszy skutek techniczny [6]. Europejski Urząd Patentowy udzielił na przykład patentu na „elektroniczne uwierzytelnienie podpisu odręcznego, moduł i oprogramowanie komputerowe” (EP2474937), „sposób i urządzenie do wykrywania ryzyka transakcji” (EP3242236) oraz „bezpieczne transakcje na urządzeniach mobilnych” (EP3114599).

Skoro patentowanie programów komputerowych stanowi wyzwanie a one same są i tak chronione prawem autorskim, to jaki sens ma staranie się o ochronę patentową? Prawo autorskie chroni utwór o określonym sposobie wyrażenia np. program komputerowy o konkretnym kodzie źródłowym. Program komputerowy nawet tym samym językiem programowanie, ale inaczej nie będzie naruszał praw autorskich do oryginalnego programu. Nie ma znaczenia, że drugi program oferuje użytkownikowi te same funkcje, co pierwszy. Patent jest natomiast udzielany na rozwiązanie techniczne np. bardziej efektywne przetwarzanie danych przez system zarządzania bazą danych [7] wynikające z zastosowania nowego programu komputerowego. Nie ma znaczenia, jaką dokładnie treść ma kod źródłowy. Dlatego stosowanie chronionego rozwiązania będzie naruszało patent niezależnie od tego, jaki dokładnie program komputerowy zostanie użyty przez naruszającego.

Inne elementy produktu opartego o rozwiązania FinTech również mogą stanowić własność intelektualną. Zarówno taką, która jest automatycznie chroniona prawem autorskim, jak i taką, dla której można uzyskać prawa własności przemysłowej. Te pierwsze to przede wszystkim wszystkie elementy tekstowe i graficzne np. podręcznik, graficzny interfejs użytkownika aplikacji mobilnej lub serwisu internetowego, ulotki informacyjne, a te drugie to znak towarowy dla logotypu albo wzór przemysłowy dla ikon i wspomnianego już interfejsu użytkownika.

W kolejnych wpisach z cyklu SPCG for FinTech wyjaśnimy, jak zorganizować proces nabywania praw do IP tworzonego wewnętrznie przez instytucję finansową oraz IP nabywanego od kontrahentów np. software house’ów – tak aby instytucja uzyskała te prawa w możliwie najszerszym zakresie.

Przypisy:

[1] W niektórych przypadkach ten okres jest liczony odmiennie. Tytułem przykładu, dla pracowniczych programów komputerowych czas ochrony liczony jest od daty rozpowszechnienia takiego programu, a gdy program nie został rozpowszechniony, to od daty jego stworzenia.

[2] Wynalazek to rozwiązanie techniczne, które jest przemysłowo stosowalne, nowe i ma poziom wynalazczy.

[3] Maksymalny czas ochrony to 20 lat od daty zgłoszenia.

[4] Chodzi tutaj o materiały, które bez dodatkowego wysiłku można „przełożyć” na kod źródłowy lub wynikowy.

[5] Technika jest rozumiana zasadniczo jako oddziaływanie ma świat materialny za pomocą narzędzi stosowanych nauk przyrodniczych.

[6] Dalszy skutek techniczny to skutek wykraczający poza normalne oddziaływanie programu komputerowego i komputera.

[7] A tym samym niższe użycie pamięci komputera.

 

Napisz do autora:

Marcin Balicki

adwokat
Senior Associate

SPCG for FinTech (cz. 1) – Know your IP

SPCG for FinTech (cz. 1) – Know your IP

Czytaj: 3 min

Niejedna regulacja prawna nakłada na instytucje finansowe obwiązek wdrożenia i stosowania procedur polegających na identyfikowaniu swoich klientów i uzyskiwaniu pewnych, odpowiednich oraz trafnych informacji na ich temat (know your customer). Żadne przepisy nie obligują jednak instytucji finansowych do dbałości o skuteczne nabywanie i efektywne zarządzanie własnością intelektualną.

Tymczasem, współcześnie najważniejszym aspektem usług finansowych mogą być nowoczesne rozwiązania technologiczne (FinTech), oparte przykładowo na zrobotyzowanej automatyzacji procesów bądź korzystaniu z baz danych blockchain. W rezultacie, z wyjątkiem złożonej z plastiku, chipa i paska magnetycznego karty płatniczej, usługi i produkty FinTech składają się wyłącznie z własności intelektualnej (IP). Świadomość, jakimi dokładnie zasobami IP dysponuje instytucja finansowa przekłada się bezpośrednio na jakość i bezpieczeństwo świadczonych usług, a także na wyniki finansowe. Przykładowo oprogramowanie dostarczane na „standardowych” licencjach przez korporacje technologiczne może służyć do obiegu skanów dokumentów przesyłanych przez klientów. Brak pewności, co do liczby i typu posiadanych licencji może prowadzić do sporu z dostawcą i konieczności zapłaty przeważnie bardzo wysokiego dodatkowego wynagrodzenia albo do nabywania licencji „na zapas” ponad rzeczywiste zapotrzebowanie. To tylko jeden z przykładów, jak znajomość używanego IP bezpośrednio przekłada się na biznes. Dlatego IP powinno być przez instytucję finansową ewidencjonowane nie mniej dokładnie niż środki klientów.

Przygotowanie dokumentacji oraz wdrożenie procesów wewnętrznych pozwalających na zarządzenie własnością intelektualną tworzoną wewnętrznie w instytucji finansowej jest zalecane z co najmniej kilku powodów:

  • unikanie luk w prawach własności intelektualnej do produktów lub usług, z których instytucja finansowa korzysta na własne potrzeby lub które udostępnia osobom trzecim (możliwość wykazania nabycia stosownych praw od pracownika lub współpracownika);
  • możliwość stosowania preferencyjnych 50% kosztów uzyskania przychodów oraz ulgi IP BOX, odróżnianie projektów, do których stosowana jest ulga badawczo-rozwojowa a ulga IP BOX;
  • dokumentacja obejmująca techniczne lub technologiczne tajemnice przedsiębiorstwa będzie mogła zostać w przyszłości zgłoszona do depozytu prowadzonego przez Urząd Patentowy RP

W przypadku własności intelektualnej nabytej lub licencjonowanej od osób trzecich ewidencjonowanie własności intelektualnej jest istotne z następujących powodów:

  • unikanie luk w prawach własności intelektualnej do produktów lub usług, z których instytucja finansowa korzysta na własne potrzeby lub które udostępnia osobom trzecim (możliwość wykazania nabycia lub licencjonowania stosownych praw od podwykonawcy lub dostawcy);
  • zarządzanie licencjami na oprogramowanie oraz optymalizacja ich wykorzystania przez instytucję finansową, w tym przygotowanie do ewentualnego audytu licencjodawcy bądź odsprzedaż zbędnych licencji;
  • ustalenia, jakie elementy większej całości (np. systemu informatycznego) zostały stworzone przez osobę trzecią i osoba ta ponosi za nie odpowiedzialność (np. w razie wykrycia wad prawnych);
  • określenie w jakim zakresie instytucja finansowa korzysta z własności intelektualnej w oparciu o tzw. wolne licencje, zwłaszcza z oprogramowania open source. Może być to istotne np. w przypadku wykrycia lub powstania luki bezpieczeństwa w takim oprogramowaniu.

Kompletne i prawidłowe informacje o własności intelektualnej używanej przez instytucję finansową jest też ważne przy budowaniu strategii zarządzania IP np. kalkulowania kosztów wymiany oprogramowania licencjonowanego na stworzone wewnętrznie lub odwrotnie. Taka ewidencja pozwala też wychwycić ewentualne ryzyka w tym zakresie – np. plan udostępnienia klientom usługi bazującej na oprogramowania, do którego instytucja finansowa może nie mieć pełni praw.

Zewidencjonowanie własności intelektualnej instytucji finansowej jest pierwszym krokiem do ustalenia pełni korzyści, jakie może ona przynieść. Po pierwsze, określenie silnych i słabych stron instytucji w poszczególnych obszarach – np. oparcia kluczowych wewnętrznych procesów na oprogramowaniu własnym lub zoptymalizowanym kosztowo oprogramowaniu licencjonowanym, ale jednocześnie wątpliwości odnośnie prawidłowego nabycia praw do kluczowych elementów usługi świadczonej klientom. Po drugie, zidentyfikowanie kierunków dalszej ekspansji technologicznej instytucji finansowej – docelowo nawet wypracowanie technologicznie unikalnej usługi i osiągnięcie przewagi konkurencyjnej nad konkurentami lub pozycji negocjacyjnej do wzajemnego licencjonowania technologii z konkurentami lub spółkami technologicznymi. Po trzecie, dokonanie wyceny kluczowego IP, w szczególności znaków towarowych, wynalazków i oprogramowania, a w rezultacie– ich ostatecznego wpływu na wartość całej instytucji. Po czwarte, budowanie wizerunku instytucji finansowej jako dysponującej zasobami do samodzielnego budowania usług opartych na nowych technologiach.

W kolejnych wpisach cyklu SPCG for FinTech przybliżymy zasady, na jakich możliwa jest ochrona własności intelektualnej rozwiązań FinTech oraz jak zorganizować możliwie najbardziej efektywne i pełne nabycie takiej własności intelektualnej przez instytucję finansową. Przedstawiane przez nas rozwiązania będą służyły przede wszystkim zwiększeniu bezpieczeństwa prawnego oraz efektywności zarządzania własnością intelektualną w instytucji finansowej oraz obniżeniu kosztów prowadzenia działalności – czy to przez korzystanie z preferencji podatkowych, czy optymalizację używanych licencji.

Instytucje finansowe nie działają jednak w regulacyjnej próżni – wręcz przeciwnie. Niemal każda nowa istotna technologia zaprzęgnięta do świadczenia usług finansowych to pytania o zgodność działania instytucji finansowej z przepisami prawa i stanowiskami polskiego i europejskich regulatorów. W tym kontekście szczególną uwagę należy zwrócić na przepisy i oczekiwania nadzorcze w obszarze outsourcingu regulowanego i zarządzania ryzykiem w instytucji finansowej.

Podsumowując, rozwiązanie technologiczne, które ma stać się usługą dla klienta instytucji finansowej to nie tylko wyzwania inżynieryjne i programistyczne, ale i prawne. Liczymy, że cykl SPCG for FinTech ułatwi instytucjom finansowym mierzenie się z tymi wyzwaniami.

 

Napisz do autorów:

Marcin Balicki

adwokat
Senior Associate

Malwina Przyborowska SPCG

Malwina Przyborowska

radca prawny
Senior Associate

Kluczowe obszary w umowach wdrożeniowych

Kluczowe obszary w umowach wdrożeniowych

Czytaj: 6 min

Truizmem jest już twierdzenie, że sektor IT w Polsce rozwija się dynamicznie. Pandemia wirusa Sars-Cov-2 ten prężny rozwój jeszcze przyspieszyła. Jak pokazuje raport „Wpływ Covid-19 na Branżę Software House w Polsce”, przygotowany przez organizację SoDA, mediana tempa wzrostu polskich spółek IT utrzymuje się na poziomie 20% [1]. Co więcej, jak wskazują autorzy, aż „jedna trzecia firm stwierdziła, że pandemia COVID-19 miała na nie pozytywny wpływ[2].

Przejście pracowników i kontrahentów na pracę zdalną, ograniczenia epidemiologiczne i inne czynniki związane z pandemią, wymusiły digitalizację działania wielu organizacji. Zauważalny i niezwykle ciekawy jest zwłaszcza „trend” migracji przedsiębiorstw do chmury [3] (o zaletach i ryzykach prawnych migracji do chmury będziemy jeszcze pisać). Wciąż jednak znaczna część projektów stanowią wdrożenia oprogramowania w modelu on-premise (tj. na infrastrukturze organizacji), które mają wiele niepodważalnych zalet (np. pełna kontrola nad danymi, kontrola na aktualizacjami, mniejsze ryzyko vendor lock-in, możliwość modyfikacji rozwiązań pod konkretne potrzeby zamawiającego).
Co z punktu widzenia prawnego jest kluczowe, aby zapewnić sukces projektom wdrożeniowym lub przynajmniej zmniejszyć szanse ich niepowodzenia?
O jakie obszary należy zadbać, aby implementacja rozwiązania IT zakończyła się powodzeniem?
W niniejszej publikacji postaramy się odpowiedzieć na te pytania.

Zakres prac

Zakres prac to istotny obszar umów wdrożeniowych. Zakres prac determinuje bowiem „CO” i „JAK” ma być zrealizowane w ramach projektu.
„CO”, czyli jakie dokładnie oprogramowanie wchodzi w skład oferowanego przez dostawcę rozwiązania (oprogramowanie standardowe, oprogramowanie dedykowane, oprogramowanie open source etc.), jakie wymagania funkcjonalne lub pozafunkcjonalne ma spełniać rozwiązanie, czy też jakie procesy biznesowe ma ono obsługiwać.
„JAK”, czyli określenie koncepcji i sposobu zrealizowania ww. wymagań zamawiającego, oraz opisanie jakie cele muszą zostać osiągnięte bądź warunki spełnione, aby wdrożenie zostało uznane za wykonane prawidłowo.

Dla obu stron umowy powinno być jasne co ma zostać osiągnięte w wyniku realizacji wdrożenia (tzn. „CO” i „JAK” ma być wdrożone w przedsiębiorstwie zamawiającego). Tyle że dokładne sprecyzowanie zakresu prac na etapie zawierania umowy będzie często niemożliwe (i nie zawsze potrzebne). Dobrą praktyką jest załączanie do umowy wymagań zamawiającego odnoszących się do rozwiązania IT będącego przedmiotem wdrożenia (określenie „CO”) oraz zobowiązanie wykonawcy do realizacji analizy przedwdrożeniowej, której celem będzie m.in. określenie koncepcji i sposobu implementacji ww. wymagań w konkretnym środowisku informatycznym (opisanie „JAK”). Często dopiero po wykonaniu takiej analizy będzie znany dokładny kształt wdrażanego rozwiązania, zakres prac i związana z tym zakresem wysokość wynagrodzenia lub sposób jego kalkulowania. Warto też zadbać, aby analiza: i) opierała się na wymaganiach zamawiającego, a nie założeniach dostawcy; ii) nie zmieniała wymagań zamawiającego (chyba że zamawiający wyrazi zgodę na taką zmianę); iii) była maksymalnie precyzyjna i nie posługiwała się pojęciami nieostrymi. Prawidłowo wykonana analiza powinna być bowiem podstawą dalszej współpracy stron. Podkreślamy, że chodzi tutaj o analizę wykonaną prawidłowo – błędy popełnione przy okazji wykonywania analizy mogą położyć się cieniem na dalszych fazach realizacji projektu. Stworzenie analizy przedwdrożeniowej może też zawczasu uchronić strony przed zaangażowaniem się w projekt, który nie przyniesie rezultatów zakładanych przez zamawiającego – np. w granicach założonego budżetu nie będzie możliwe wdrożenie rozwiązania IT oferowanego przez dostawcę [4].

Wagę dokumentu analizy obrazuje jedna z prowadzonych przeze mnie spraw, w której Klient zwrócił się o pomoc prawną w związku z przedłużającym się odbiorem analizy. Klient odmawiał dokonania jej odbioru z uwagi na nieprecyzyjność treści dokumentu. Analiza w wielu miejscach nie opisywała koncepcji wdrożenia funkcji rozwiązania (tzn. „JAK”), lecz zawierała wprost skopiowane fragmenty z Opisu Przedmiotu Zamówienia dotyczące wymagań zamawiającego lub odsyłała do dalszych ustaleń w ramach wdrożenia. Kolejne iteracje odbiorowe zakończyły się niepowodzeniem, a strony zajęły przeciwne stanowiska (dostawca zarzucał Klientowi nieprzekazywanie potrzebnych mu informacji, zaś Klient dostawcę o nienależyte wykonanie analizy). Spór zakończył się złożeniem przez Klienta oświadczenia o odstąpieniu od umowy i rozliczeniem dotychczas wykonanych prac przez dostawcę. Decyzja Klienta podyktowana była dużym opóźnieniem w realizacji analizy, a także obawą, iż – z uwagi na nieprecyzyjność analizy – wdrożenie zostanie wykonane nieprawidłowo. Dlatego tak ważny jest moment odbioru analizy. Po akceptacji dokumentu analizy przez zamawiającego, nawet jeżeli zawiera ona nieścisłości, wykonanie umowy przez dostawcę zgodnie z jej treścią będzie co do zasady prawidłowym wykonaniem umowy.

Niedokładne określenie zakresu prac często prowadzi również do sporów w trakcie realizacji prac wdrożeniowych (tj. czy sporne prace są lub nie są objęte zakresem prac). Stosunkowo rzadko jednak konflikty pomiędzy stronami kończą się sporami sądowymi. Jednakże wszelkie tego rodzaju nieporozumienia hamują realizację projektu i angażują czas pracowników stron, ich zewnętrznych dostawców lub nawet doradców.

Zarządzanie zmianą

Nawet maksymalnie precyzyjne opisanie zakresu prac lub zobowiązań dostawcy nie powinno oznaczać, że ich zmiana w trakcie realizacji projektu nie będzie możliwa. Wręcz przeciwnie. Tego rodzaju sztywność byłaby dla projektów wdrożeniowych niepraktyczna. W trakcie wdrożenia okazuje się często, że niektóre funkcje wdrażanego rozwiązania nie mają dla zamawiającego uzasadnienia ekonomicznego lub technicznego, albo zamawiający jest zainteresowany implementacją dodatkowych funkcji. Dlatego też dobrze napisana umowa wdrożeniowa powinna zapewniać stronom pewną dozę swobody w zmianie zakresu prac. Na poziomie umownym taka swoboda jest gwarantowana poprzez postanowienia określające tzw. procedurę zarządzania zmianą.

Celem procedur zarządzania zmianą jest jak najszybsze i zarazem najprostsze umożliwienie dokonania zmian umowy, najczęściej w zakresie dotyczącym: i) zakresu prac, ii) budżetu oraz iii) harmonogramu. Należy przy tym pamiętać, że zakres, budżet oraz harmonogram są ściśle powiązane. Zmiana zakresu prac pociąga za sobą zmianę wysokości wynagrodzenia oraz harmonogramu realizacji projektu. I odwrotnie, zmiana wysokości wynagrodzenia (np. zmniejszenie budżetu na projekt) powoduje zazwyczaj konieczność rezygnacji przez zamawiającego z niektórych prac w ramach wdrożenia (ograniczenie zakresu prac).

Tym samym postanowienia związane z procedurą zarządzania zmianą to kolejny kluczowy obszar, o który strony powinny zadbać w ramach negocjacji umowy. Zarządzanie zmianą jest szczególnie ważne, gdy projekt jest realizowany zwinnie. Zakres prac w metodykach zwinnych (backlog) jest bowiem „żywy” i ulega ciągłym zmianom. Temu tematowi poświęcimy oddzielny wpis na blogu.

Klarowny podział obowiązków stron (obowiązek współdziałania)

W naszej praktyce widzieliśmy już wiele sporów, których powodem był niejasny podział obowiązków stron w ramach umowy. Skutek takiego niejasnego podziału prac może być przeróżny, czasem wręcz katastrofalny dla całego przedsięwzięcia… Od gigantycznych opóźnień, aż po złożenie przez jedną ze stron oświadczenia o odstąpieniu od umowy (wykonawca opierając się na art. 640 KC, tj. braku współdziałania zamawiającego; zamawiający zazwyczaj na art. 491 KC czy art. 635 KC, tj. zwłoki wykonawcy).

Dlatego też warto zadbać o klarowny i maksymalnie precyzyjny podział obowiązków stron w ramach umowy. Postanowienia typu „Zamawiający zobowiązuje się do współdziałania z Wykonawcą”, „Zamawiający będzie należycie współpracował przy realizacji Umowy” czy „Zamawiający udzieli wszelkich informacji, których zażąda Wykonawca, w terminie nie dłuższym niż X dni roboczych od dnia wystosowania żądania” mogą okazać się niewystarczające i prowadzić do wielu sporów.

Dobrym rozwiązaniem jest opracowanie kompleksowego załącznika, który wprost przesądzi zakres wymaganego od zamawiającego współdziałania [5]. W ramach takiego załącznika dostawca powinien wyczerpująco określić, jakich działań oraz informacji oczekuje od zamawiającego w trakcie wdrożenia (np. infrastruktury lub zdalnego dostępu o określonych przez dostawcę parametrach, wskazanej przez dostawcę liczby licencji oprogramowania, sal projektowych). Zamawiający powinien również uzyskać zapewnienie dostawcy, iż zakres jego współdziałania określony w umowie będzie wystarczający do prawidłowego wykonania umowy.

Dobrą praktyką jest również rozstrzygnięcie z góry o dostępności personelu zamawiającego, którego obecność jeść niezbędna do współpracy z pracownikami dostawcy. Nie chodzi tutaj tylko o koordynatorów projektu oraz dział IT, ale również o pracowników, którzy docelowo będą korzystać z wdrażanego oprogramowania (interesariuszy).

Sposób realizacji wdrożenia

Często zdarza się, że treść umowy wdrożeniowej rozmija się z rzeczywistością projektową. Natomiast w razie ewentualnego sporu sąd i prawnicy będą wykładali umowę literalnie (tak jak jest napisana), a nie przez pryzmat praktyki realizacji projektu. Wobec tego, aby uniknąć ewentualnych nieporozumień, sposób realizacji wdrożenia opisany w umowie (tj. opis przebiegu prac, podział ról, kompetencje pracowników) powinien jak najlepiej odzwierciedlać rzeczywistość i założenia biznesowe stron. Istotne jest w szczególności prawidłowe opisanie kompetencji kierowników projektu lub komitetu sterującego oraz sposobu podejmowania decyzji (np. w formie wiadomości e-mail lub poprzez odpowiednie wpisy w narzędziu zarządzania projektem). Brak przestrzegania przez strony postanowień umowy w zakresie sposobu realizacji wdrożenia może prowadzić do wielu problematycznych sytuacji, np. takich, w których decyzje kierowników projektu okazują się dla stron niewiążące (w sytuacji, gdy decyzje zostały podjęte niezgodnie z procedurą opisaną w umowie).

Podsumowanie

Prawidłowe oraz możliwie pełne i precyzyjne opisanie przedmiotu umowy, jasny podział obowiązków między stronami i pewna doza elastyczności co do warunków współpracy znacząco podnoszą szanse na zakończenie projektu sukcesem. Nasza praktyka pokazuje, że spory wokół umów wdrożeniowych dotyczą najczęściej wątpliwości co do zakresu prac oraz współdziałania wymaganego od zamawiającego. Warto tym wątpliwościom zapobiegać już na etapie pisania umowy.

Biznesowo oraz prawnie newralgicznych obszarów istotnych dla powodzenia wdrożenia jest oczywiście więcej (np. prawa autorskie, odpowiedzialność stron, w tym kary umowne, klauzule indemnifikacyjne, odstąpienie od umowy, exit plan). Poświęcimy im kolejne wpisy na naszym blogu.

Przypisy:

[1] Źródło: https://sodapl.com/storage/reports/June2021/53LY4721e7GjlWYjgOBt.pdf, str. 11 (dostęp: 02.03.2022 r.).

[2] Ibidem, str. 3.

[3] O ciekawym trendzie migracji przedsiębiorstw do chmury więcej w raporcie „The evolving path to cloud adoption” przygotowanym przez Colt Technology Services (źródło: https://www.colt.net/go/cloud-research-report/, dostęp 02.03.2022 r.). Analitycy Gartnera również przewidują, że wydatki przedsiębiorstw związane z migracją rozwiązań IT do chmury wzrosną, a w 2024 r. wydatki przedsiębiorstw związane z korzystaniem rozwiązań chmurowych będą stanowić 14,2% wszystkich (globalnych) wydatków organizacji na rozwiązania IT (źródło: https://www.information-age.com/public-cloud-end-user-spending-grow-18-2021-gartner-123492692/).

[4] Stąd też dobrą praktyką jest wprowadzenie do umowy tzw. umownego prawa odstąpienia zamawiającego, z którego zamawiający może skorzystać po wykonaniu analizy. Tego rodzaju odstąpienie powinno odnieść skutek „na przyszłość” oraz nie powinno pozbawiać dostawcy wynagrodzenia za już wykonane prace (odstąpienie nie jest bowiem związane z nienależytym wykonaniem umowy przez dostawcę, lecz uznaniem przez zamawiającego, że wdrożenie danego rozwiązania jest niecelowe).

[5] Czasami strony dołączają do umowy zaawansowane macierze odpowiedzialności RACI, które w sposób bardzo wyczerpujący przypisują określone zadania odpowiednim rolom projektowym.

 

Napisz do autora:

Aleksandra Modzelewska SPCG

Aleksandra Modzelewska

adwokat
Associate

Pin It on Pinterest