Technologie mają to do siebie, że dynamicznie się zmieniają. Wraz ze zmianą potrzeb biznesowych lub operacyjnych, zwiększa się zapotrzebowanie na rozwój istniejących technologii lub wdrożenie nowych rozwiązań. Nierzadko zdarza się jednak, że zmiana technologii — na nowszą, bezpieczniejszą, czy wydajniejszą — nawet jeśli nie jest skomplikowana w praktyce od strony informatycznej, to może być trudna (lub niemożliwa) do przeprowadzenia z uwagi na umowy łączące strony. W tym artykule podpowiem jak ułatwić sobie przejście suchą stopą do nowego rozwiązania IT.
Zapewne większość czytelników zna powiedzenie, że „umowę zawiera się na złe czasy”. Prawnicy stają na głowie, aby zabezpieczyć swoich klientów, w tym także umożliwić im bezpieczne wyjście z umowy, czyli ją rozwiązać — czy to na skutek jej wypowiedzenia, czy odstąpienia (w zależności od rodzaju umowy). Powodów takiego „rozwodu” może być wiele, począwszy od braku spełnienia wymagań funkcjonalnych lub wydajnościowych, poprzez naruszenie zasad bezpieczeństwa, na utracie zaufania kończąc. Na pierwszy rzut oka, rozwiązanie umowy powinno zakończyć współpracę stron, uściśnięcie sobie dłoni i rozejście się w swoich kierunkach. Inaczej jednak kwestia ta wygląda w przypadku umów związanych z systemami informatycznymi — rozwiązanie umowy może być dopiero początkiem problemów.
Powiedzmy, że spółka zawiera z dostawcą oprogramowania umowę licencji na korzystanie z systemu do zarządzania procesem produkcji i sprzedaży, wraz z panelem do zarządzania relacjami z klientami, służącym do składania i rozliczania zamówień. System dostarczany jest w modelu SaaS (eng. Software as a Service), w którym dostawca zobowiązał się również do świadczenia usług utrzymania i serwisu systemu, w tym w szczególności do usuwania zgłoszonych błędów. Spółka nie musi zatem inwestować w infrastrukturę IT, na której posadowiony byłby system i na której przechowywane byłyby dane w nim przetwarzane. Zarówno system, jak i dane przechowywane są w chmurze obliczeniowej dostawcy. Obie strony są zadowolone.
Po dwóch latach korzystania z systemu, na rynku pojawia się rozwiązanie, które swoją wydajnością i funkcjonalnościami prześciga system, z którego dotychczas korzystała spółka. W dodatku, jego cena jest korzystniejsza od ceny dotychczasowego systemu. Spółka podejmuje zatem decyzję o zmianie dostawcy — rozwiązuje umowę z zachowaniem określonego w niej okresu wypowiedzenia. Powstaje jednak pytanie — co z wszystkimi danymi, które były przetwarzane w dotychczasowym systemie i były przechowywane w infrastrukturze dostawcy? Zaczyna się walka z czasem i wertowanie postanowień umowy.
Podejmując decyzję o zakończeniu współpracy (bez względu na przyczynę) spółka powinna mieć komfort, że w sposób bezpieczny i płynny dokona „przesiadki” na inny system. W tym celu umowa powinna regulować kwestię tzw. exitu, czyli działań jakie obie strony umowy zobowiązane są podjąć w razie rozwiązania umowy. Słowem-kluczem w tym kontekście jest migracja, czylibezpieczny transfer danych do innego systemu (lub transfer systemu i danych do innej infrastruktury), zapewniający przy tym ciągłość działalności operacyjnej spółki. Już na etapie zawierania umowy, warto przewidzieć zobowiązanie dostawcy do aktywnego udziału w takiej migracji.
W pierwszej kolejności, w toku negocjacji umowy strony powinny wypracować dokumentację migracyjną (czyli tytułowy exit plan), która w jasny sposób opisze dokładny scenariusz przeprowadzenia migracji.
Pierwszym z elementów takiego scenariusza powinno być bezpieczeństwo. Przed rozpoczęciem transferu jakichkolwiek danych, dostawca powinien przeprowadzić testy bezpieczeństwa, które wykluczą ryzyko utraty lub uszkodzenia danych w tracie transferu. W przypadku negatywnego wyniku testów, dostawca powinien być zobowiązany do wyeliminowania nieprawidłowości w ściśle określonym terminie.
Przed rozpoczęciem migracji dostawca powinien być również zobowiązany do wykonania kopii zapasowych danych (pomijając, czy do wykonywania kopii był zobowiązany w okresie obowiązywania umowy, co jest rekomendowane w tego typu umowach). W przypadku wystąpienia jakiegokolwiek błędu w trakcie migracji związanego z transferem danych, spółka będzie mogła odtworzyć dane z kopii zapasowej (backupu). Łatwo sobie wyobrazić, że utrata lub uszkodzenie danych może przynieść opłakane skutki, w szczególności jeśli system ma kluczowe znaczenie dla funkcjonowania spółki. Brak danych dotyczących klientów, brak możliwości zarządzania procesem produkcji, brak monitoringu stanów magazynowych i do tego brak możliwości składania weryfikacji i rozliczania zamówień. Ogólnie rzecz biorąc — katastrofa.
Kolejnym elementem exit planu powinien być opis struktury i organizacji bazy danych. Z jednej strony pozwoli on na odpowiednie przygotowanie danych do migracji, zaś z drugiej strony może ułatwić nowemu dostawcy „zrozumienie” struktury i upload danych do nowego systemu.
Następnie crème de la crème exit planu, czyli przebieg migracji. Scenariusz w tej części powinien odpowiadać na trzy pytania — kto, co i kiedy? Strony przed zawarciem umowy powinny ustalić, która z nich będzie odpowiedzialna za podjęcie konkretnych czynności migracyjnych i w jakich terminach.
Wykonanie opisanych w exit planie czynności to jeszcze nie koniec migracji. Kolejnym etapem są testy (tak, znowu). Po dokonaniu transferu danych, spółka wraz z nowym dostawcą powinna przeprowadzić testy akceptacyjne, które zweryfikują czy migracja przebiegła pomyślnie, czy została zapewniona prawidłowość, kompletność, integralność i bezpieczeństwo transferu danych oraz — przede wszystkim — czy dane nie uległy utracie lub uszkodzeniu.
Po przeprowadzeniu testów akceptacyjnych zakończonych pozytywnym wynikiem, spółka powinna dokonać odbioru migracji, czyli potwierdzić, że dane zostały prawidłowo przetransferowane oraz nie występują jakiekolwiek błędy z nimi związane. Podpisanie przez strony protokołu odbioru potwierdzającego prawidłowe wykonanie wszystkich obowiązków określonych w exit planie powinno zasadniczo kończyć współpracę stron — dopiero w tym momencie spółka powinna móc powiedzieć, że rozstała się z dostawcą.
Miejscem na opisanie powyższego scenariusza exit planu jest odpowiedni załącznik do umowy. Treść umowy powinna przy tym jasno wskazywać zobowiązanie dostawcy do umożliwienia, uczestniczenia oraz wspierania transferu wszelkich danych do innego systemu wskazanego przez spółkę, w sposób i na zasadach określonych w exit planie. Co również ważne, umowa powinna przewidywać obowiązek dostawcy do współdziałania przy migracji z każdą osobą trzecią wskazaną przez spółkę (np. dostawcą nowego systemu), a także obowiązek udzielania wszelkich informacji, instrukcji oraz udostępniania dokumentów odnoszących się do systemu dostawcy, niezbędnych do zapewnienia płynnego i bezpiecznego przeniesienia danych. Należy bowiem pamiętać, że migracja najczęściej polega na „wystawieniu” danych z systemu przez jedną stronę oraz ich odbiór i posadowienie na innych systemie przez drugą stronę.
Warto również z góry w umowie ustalić wynagrodzenie dostawcy za uczestnictwo w migracji. Niestety często można spotkać zapisy umowne, zgodnie z którymi „wysokość wynagrodzenia zostanie uzgodniona w toku negocjacji stron prowadzonych w dobrej wierze”. A co w przypadku, gdy jednak takiego wynagrodzenia strony nie uzgodnią w przyszłości? Wówczas uzyskanie od dostawcy wsparcia przy migracji będzie utrudnione, a spółka w najlepszym przypadku zostanie z „paczką” danych w jakimś formacie, której nie będzie mogła łatwo wykorzystać. Podobnie zresztą kwestia wygląda w przypadku całego exit planu oraz scenariuszy testowych — lepiej uzgodnić ich treść przed podpisaniem umowy.
Jeśli wysokości wynagrodzenia nie da się określić w chwili zawarcia umowy, alternatywą jest wynagrodzenie rozliczane w modelu time&material (czyli ilość roboczogodzin lub roboczodni poświęconych przez dostawcę pomnożona przez określoną w umowie stawkę), choć i w tym przypadku warto wynegocjować górny limit wysokości takiego wynagrodzenia.
Podsumowując, negocjując warunki kontraktu IT, warto zabezpieczyć się na wypadek rozwodu z dostawcą. I to niezależnie czy do rozwodu dochodzi „bez orzekania o winie”, czy z „orzeczeniem o winie jednej ze stron”. Wypracowanie skutecznego i egzekwowalnego exit planu może oszczędzić nerwów i — przede wszystkim — pieniędzy. Nie dojdzie do tego jednak bez ścisłej współpracy dwóch na pozór odmiennych światów — czyli prawa i informatyki. Prawnik może pomóc zabezpieczyć klienta przed uwięzieniem w technologii i pomóc w transferze od strony formalnych zobowiązań kontraktowych dostawcy, zaś informatyk będzie czuwał nad prawidłowością, bezpieczeństwem i wykonaniem exit planu od strony stricte operacyjnej i informatycznej.
