Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



07.06.2022

Red Hat Enterprise Linux 9

Red Hat zaprezentował system operacyjny Red Hat Enterprise Linux 9 (RHEL 9)...
07.06.2022

Technologiczna piaskownica

Koalicja partnerów KIR, IBM, Chmura Krajowa, PKO Bank Polski, Urząd Komisji Nadzoru...
07.06.2022

Sztuczna inteligencja w...

OVHcloud wprowadziło na rynek AI Notebooks – najnowszy element w ofercie usług...
07.06.2022

Spójna ochrona brzegu sieci

Fortinet zaprezentował FortiOS 7.2 – najnowszą wersję swojego flagowego systemu...
07.06.2022

Zarządzanie transferem

Firma Progress wypuściła nową wersję oprogramowania do zarządzania transferem plików...
07.06.2022

Notebook ekstremalny

Panasonic przedstawił 14-calowy Toughbook 40, notebook do pracy w ekstremalnych...
07.06.2022

Zestaw startowy dla robotyki

Firma AMD przedstawiła najnowszy produkt w portfolio adaptacyjnych modułów SOM...
07.06.2022

Precyzja kadrowania

Najnowsze rozwiązania klasy pro firmy Poly mają sprostać zmieniającym się potrzebom...
07.06.2022

Serwer klasy korporacyjnej

QNAP zaprezentował nowy model serwera NAS, TS-h1886XU-RP R2, który działa na systemie...

Kierowanie zmianą w projektach informatycznych

Data publikacji: 07-06-2022 Autor: Agata Marcinkowska, Adrianna Żyrek

Negocjując umowy IT, strony często skupiają się na zagwarantowaniu trwałości warunków współpracy. Tymczasem zmiana jest nieodzownym elementem wielu projektów i usług informatycznych. Wprowadzenie adekwatnych mechanizmów zarządzania zmianą zapewnia stronom jasne reguły postępowania.

 

Zmiana dotyka wielu umów, zwłaszcza tych długoterminowych, dotyczących złożonych wdrożeń lub współpracy w obszarze usług IT. Jest nieunikniona choćby ze względu na zmieniające się potrzeby lub procesy biznesowe klienta, zmiany technologii czy warunków rynkowych. Umowy „odporne na zmianę”, w szczególności takie, które nie przewidują żadnych procedur kontroli zmian lub traktują zmianę jako nieprawdopodobną bądź z gruntu niekorzystną dla stron, w wielu przypadkach wymagają czasochłonnych (i często kosztownych) renegocjacji albo po prostu nie są wykonywane (w takim przypadku nierzadko realizacja projektów lub usług informatycznych opiera się na ustnym uzgodnieniu stron, bez odzwierciedlenia w warunkach umowy, z czym mogą wiązać się określone ryzyka).


Brak uwzględnienia w umowie czytelnych zasad zarządzania zmianą może prowadzić m.in. do nieadekwatnych rezultatów projektu czy niepowodzeń (projekt jest realizowany zgodnie z jego pierwotnymi warunkami mimo zmian kluczowych potrzeb klienta). Efektem mogą być też spory stron. Strony mogą spierać się zwłaszcza o to, czy dane zdarzenie w ogóle stanowi „zmianę” (i kto ponosi jej ryzyko, w tym koszty), czy też jest to element pierwotnego zakresu kontraktu, jak i o to, czy doszło do nienależytego wykonania umowy na skutek „nieautoryzowanej” zmiany. Dlatego dążenie do pełnego usztywnienia warunków kontraktowych w wielu przypadkach nie jest realistyczne lub osiągalne ani korzystne dla stron umowy.


W artykule tym przedstawiono zagadnienia dotyczące zarządzania zmianą w umowach IT. Wskazano na wybrane istotne aspekty, które warto wziąć pod uwagę w trakcie kształtowania i negocjowania umów w obszarze projektów i usług IT. Dobór odpowiednich rozwiązań w tym zakresie zależeć będzie jednak każdorazowo od uwarunkowań dotyczących konkretnej umowy.


> Rodzaje zmian


Zarządzanie zmianą można zdefiniować jako identyfikowanie i kontrolowanie modyfikacji pierwotnego zakresu prac (w ramach projektu, świadczenia usług informatycznych) i warunków ich realizacji. To zagadnienie uwzględniane w metodykach i dobrych praktykach zarządzania projektami czy usługami IT. Zmienność i dynamizm projektów IT stanowi podstawę zwinnych metodyk zarządzania projektami IT, gdzie zmiana jest niejako wpisana w istotę projektu informatycznego (np. Agile, Scrum). Zarządzanie zmianą stanowi również jedną z praktyk zarządzania usługami ITIL 4, gdzie zmiana jest definiowana jako „dodanie, modyfikacja lub usunięcie czegokolwiek, co mogłoby mieć bezpośredni lub pośredni wpływ na usługi informatyczne”.


Nie sposób opisać wszystkich możliwych rodzajów zmian w przypadku umów IT. Jedynie przykładowo można wskazać na niektóre z nich.


Zmiana może dotyczyć zakresu projektu lub usług informatycznych, wówczas są to zmiany funkcjonalne. W szczególności chodzi o to, czy strony przewidują możliwość rozszerzania lub redukcji zakresu projektu informatycznego (np. nowe elementy funkcjonalne, objęcie wdrożeniem nowych procesów biznesowych zamawiającego lub spółek z grupy, rozszerzenie zakresu modyfikacji standardowych funkcjonalności systemu IT w stosunku do pierwotnie przewidzianych, rezygnacja z części zakresu projektu) lub usługi (zmiana parametrów lub zakresu usługi). Zwłaszcza w przypadku projektów wdrożeniowych warto rozważyć, co stanowić będzie zmianę zakresu prac, a co jego uszczegółowienie czy też skonkretyzowanie, które nie powoduje zmiany przedmiotu umowy. W przypadku rozwiązań standardowych, w tym opartych na modelu SaaS, warto też rozważyć uwzględnienie w umowie kwestii zmian funkcjonalnych wprowadzanych przez dostawcę w trakcie cyklu życia rozwiązania, w tym zmian w stosunku do jego pierwotnej specyfikacji na skutek aktualizacji lub podnoszenia wersji rozwiązania, a także zagadnienia dotyczące zakończenia cyklu życia rozwiązania i potrzeby jego zastąpienia nową wersją.


Kolejny przykład zmian dotyczy czasu trwania projektu lub usługi. Mogą pojawić się okoliczności, które skutkować będą potrzebą zakończenia projektu lub usługi w terminie wcześniejszym niż pierwotnie zakładany.


Zmiany mogą dotyczyć też terminu wykonania prac. Przykładowe powody zmiany w harmonogramie prac wdrożeniowych to: kolizja z innymi projektami realizowanymi w przedsiębiorstwie zamawiającego przez innych wykonawców, które powodują potrzebę wstrzymania lub zmiany terminu wykonania prac w danym projekcie; konieczność uwzględnienia w harmonogramie prac ewentualnych okresów zamrożeń prac na środowiskach produkcyjnych klienta, np. z powodu wewnętrznej polityki klienta wprowadzającej zakaz prac na środowisku produkcyjnym w określonych terminach; przesunięcie dat cząstkowych realizacji prac, zmiana ich kolejności; opóźnienia po stronie wykonawcy – zwłaszcza jeżeli wpływają na pozostałe prace w ramach danego projektu.


Inny przykład to zmiany w przepisach prawa lub decyzje organu nadzoru, np. w trakcie projektu wdrożeniowego, wpływające na zmianę lub powstanie nowego procesu biznesowego czy też na zmianę funkcjonalności zamawianego systemu informatycznego. Dlatego celowe jest rozważenie przez strony, czy i jakie zmiany w przepisach prawa mogą wpłynąć na rozwiązanie informatyczne stanowiące przedmiot umowy.


Możliwe są też zmiany kluczowych zasobów wykonawcy, w tym personelu, np. odejście członków personelu, potrzeba zwiększenia zasobów osobowych w przypadku zwiększenia zakresu projektu lub usług outsourcingowych.


Zmiana może zajść w strukturze przedsiębiorstwa zamawiającego, np. pojawienie się nowych lokalizacji (biur, placówek, sklepów) lub ich zlikwidowanie, mające wpływ na projekt wdrożeniowy lub usługę.

 

Kolejna sytuacja to zmiany w grupach kapitałowych po stronie kupującego, czyli powstanie nowych spółek, inne przekształcenia w grupie przedsiębiorstw, mogące wpływać na projekt wdrożeniowy lub usługę.

 

Zmiana może dotyczyć zakresu licencji nabywanych od podmiotu trzeciego (producenta) na potrzeby prac wdrożeniowych. Przykładowo po rozpoczęciu prac wdrożeniowych może okazać się, że zakupione licencje – pod względem ich liczby lub rodzaju – są nieadekwatne, przeszacowane bądź niewystarczające w stosunku do potrzeb zamawiającego.


Warto wspomnieć też o zmianie parametrów infrastruktury hostingowej (np. zwiększenie mocy obliczeniowej, zmiana jej lokalizacji, zmiana dostawcy infrastruktury hostingowej, potrzeba migracji na inną platformę hostingową), a także zmianie parametrów SLA usługi lub jej zakresu (np. czy SLA jest stałe, czy zmienne w zależności od okresu, rozszerzenie usługi na nowe obszary lub systemy przedsiębiorstwa, modyfikacje rozwiązania).


Na koniec należy też wymienić nowe ryzyko jako przykład możliwej zmiany. To np. siła wyższa, epidemia, zmiana potrzeb biznesowych, na skutek których projekt czy usługa przestają być potrzebne dla zamawiającego, inflacja czy zakłócenie łańcuchów dostaw z uwagi na sytuację geopolityczną.


> Ramy kontraktowe


W projektach IT często najtrudniejszą częścią projektowania procedur zarządzania zmianą oraz postanowień umów, które regulują ten aspekt, jest zdefiniowanie, czym jest zmiana. Dlatego określając ramy kontraktowe współpracy stron, w szczególności przy kształtowaniu inicjalnego zakresu projektu czy usług informatycznych, warto zdefiniować „zmianę”. Wiąże się to nieodzownie z koniecznością czytelnego określenia w umowie oraz zrozumienia przez obie strony – w ten sam sposób – pierwotnego zakresu projektu lub usług IT.


Przy konstruowaniu umowy kluczowe jest więc, po pierwsze, opisanie, co jest objęte pierwotnym zakresem, warunkami prac – poprzez precyzyjne zdefiniowanie zakresu umowy i obowiązków stron. Po drugie, strony muszą rozważyć, czy bazowe parametry projektu lub usługi mogą się zmieniać, a jeśli tak, to w jakim zakresie i w jakich przypadkach (przykłady zmian podane zostały powyżej – ich katalog nie jest wyczerpujący). Wreszcie, po trzecie, ważne jest odniesienie się w umowie do ww. przypadków zmian poprzez wprowadzenie odpowiednich mechanizmów kontraktowych, w tym określenie trybu zmiany, zasad postępowania stron w takim przypadku, zasad alokacji kosztów, ryzyka zmiany. Wybrane aspekty formalne i proceduralne związane z zarządzaniem zmianą w projekcie IT opisano poniżej.


> Procedura kontroli zmian


Nie istnieje jedna, uniwersalna procedura zarządzania zmianą, która „sprawdzi się” w każdym projekcie IT. Efektywna procedura w praktyce wymaga bowiem dostosowania do specyfiki konkretnej współpracy podejmowanej pomiędzy stronami (tj. do realiów danego projektu wdrożeniowego lub dotyczącego usług IT, sposobu określenia pierwotnego zakresu projektu, jego budżetu). Można jednak wskazać pewne elementy standardowe, które co do zasady powinny zostać uwzględnione w każdej tego typu procedurze, ponieważ ze swojej istoty służy ona prawidłowemu zidentyfikowaniu zmiany (odróżnieniu danego zakresu prac od inicjalnego zakresu umowy) oraz ustaleniu, czy i w jaki sposób zostanie ona zaimplementowana w ramach współpracy stron.


SPOSÓB IMPLEMENTOWANIA


Jednym ze standardowych elementów procedury jest określenie trybu, w jakim zmiana ma zostać wprowadzona. Projektując procedurę kontroli zmian, w celu uelastycznienia umowy warto przede wszystkim wziąć pod uwagę, w jakim trybie zmiana ma być implementowana do zakresu kontraktu. Jak już zostało zasygnalizowane, zmiany mogą mieć różny charakter, co często będzie determinowało tryb, w jakim zostaną wprowadzone do umowy.


W szczególności można w tym zakresie wyróżnić zmiany „automatyczne”, zmiany na skutek jednostronnej dyspozycji lub oświadczenia jednej ze stron oraz zmiany dokonywane w wyniku wspólnych uzgodnień stron umowy, oparte na uzgodnionej procedurze kontroli zmian:

 

  • Zmiany „automatyczne” są realizowane, jeżeli zaistnieją przesłanki określone przez strony w umowie. W takim przypadku co do zasady zmiana powinna zostać uwzględniona przez stronę zobowiązaną do jej wdrożenia niejako „z automatu” (ewentualnie po powzięciu wiadomości o okolicznościach faktycznych będących podstawą do dokonania zmiany), ponieważ realizuje się obowiązek danej strony wynikający pierwotnie z umowy. Taki charakter mogą mieć przykładowo zmiany wynikające ze zmian prawnych (np. uwzględnienie zmian wynikających z przepisów prawa, które pojawiają się w trakcie realizacji prac wdrożeniowych), obowiązek podnoszenia poziomu zabezpieczeń technicznych czy automatyczna waloryzacja wynagrodzenia należnego wykonawcy.
  • Zmiany na skutek jednostronnej dyspozycji lub oświadczenia jednej ze stron są realizowane w sytuacjach wyraźnie określonych w umowie, lecz do zainicjowania zmiany konieczne jest oświadczenie lub żądanie uprawnionej strony umowy (np. dotyczące zawieszenia realizacji usługi na określony czas lub wstrzymania projektu IT, uruchomienia nowej, zdefiniowanej w umowie usługi, redukcja zakresu usług). W zależności od rodzaju zmiany postanowienia prawne mogą zostać skonstruowane np. jako prawo „opcji”, gdzie przykładowo nowa usługa zdefiniowana w umowie aktywuje się po złożeniu przez stronę uprawnioną jednostronnego oświadczenia o chęci skorzystania z niej lub też w przypadku redukcji projektu jako prawo do czasowego zawieszenia danych usług lub częściowego wypowiedzenia umowy o świadczenie usług lub umownego odstąpienia od umowy (należy pamiętać, że oświadczenie o wypowiedzeniu czy odstąpieniu prowadzi do definitywnych skutków – zakończenia stosunku prawnego w danym zakresie; z kolei zawieszenie usług lub projektu ma charakter tymczasowy).


[...]

 

Agata Marcinkowska – radca prawny w kancelarii Barta & Kaliński sp. j. Specjalizuje się w projektach związanych z problematyką nowych technologii, w szczególności prawa IT i umów dotyczących projektów informatycznych, a także prawa ochrony danych osobowych.
Adrianna Żyrek – aplikantka radcowska, prawnik w kancelarii Barta & Kaliński sp. j. Specjalizuje się w projektach związanych z problematyką nowych technologii, w szczególności prawa autorskiego, a także prawa ochrony danych osobowych.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"