Od kilku dobrych lat na popularności zyskiwała tzw. chmura, czyli systemy stawiane i utrzymywane na serwerach zewnętrznego dostawcy, który dbał nie tylko o serwis ale również utrzymanie i rozwój oprogramowania. Popularność tego modelu wynikała nie tylko ze względu na szeroką ofertę dostawców tego typu rozwiązań, którzy dostarczając kompleksowe rozwiązanie mogli łatwiej optymalizować marżę i zarządzać rozwojem produktu. Kluczowy był sposób, w jaki wpisywał się on w potrzeby klientów.
Oprogramowanie „w chmurze” dawało kuszącą wygodę zdjęcia z własnych struktur IT odpowiedzialności za infrastrukturę systemu. Dlatego zarówno działy zakupowe jak i te zaangażowane w realizację procesów biznesowych w firmach jak mantrę powtarzały „SaaS” w różnych odmianach. Zarówno w sektorze prywatnym, jak i w organizacjach sektora publicznego, gdzie przejście w chmurę dawało takie same korzyści, ale napotykało dużo więcej prawnych ograniczeń.
Mimo niezaprzeczalnych plusów, nieco w cieniu pozostawała jednak kwestia dość kluczowe dla ciągłości działania i bezpieczeństwa biznesu. Skoro wchodzimy w jakieś rozwiązanie i uzależniamy się od korzyści z niego płynących, musimy wiedzieć jak żyć kiedy ktoś wyciągnie wtyczkę. Odpowiedź na tak postawione pytanie dla specjalistów od prawa nowych technologii ma swoją nazwę – strategia wyjścia.
Po co nam strategia wyjścia
Sposób sprzedaży oprogramowania w modelu SaaS jest dość ustandaryzowany. Sprzedawca ma gotowe rozwiązanie, które oferuje klientowi. Najczęściej jako tzw. „box” czyli rozwiązanie „pudełkowe”. Może to być ogólny ERP lub oprogramowanie do obsługi określonego procesu, ale zwykle ma z góry określony zakres funkcjonalności i możliwości personalizacji. Im więcej personalizacji i wymiany danych z innymi systemami w firmie (lub bazami danych), tym więcej czasu zajmuje wdrożenie, bo trzeba zaplanować zakres integracji. Standardowe regulaminy i umowy zaproponowane przez dostawcę określają wszystkie podstawowe elementy korzystania z systemu, w tym zakres dostępności systemu.
W naturalny sposób może pojawić się pytanie, skoro kupujemy „gotowca”, to po co mamy planować wyłączenie takiego oprogramowania z użycia. Skoro je włączyliśmy, to przecież możemy je wyłączymy, czyli zdezaktywować dostępy i włączyć inny system. Brzmi dziecinnie prosto. Ale w praktyce takie nie jest. Bo każdy system działa na danych, które do niego wprowadzamy, przechowujemy w nim i dalej przetwarzamy. We własnej infrastrukturze mamy kontrolę na tym, gdzie i jak długo takie dane są. Działając w systemie będącym pod opieką podmiotów trzecich, płacimy utratą kontroli za komfort używania. Dlatego strategia wyjścia, którą należy rozumieć jako opis działań jakie zostaną zrealizowane przez dostawcę systemu oraz firmę, która korzysta z SaaS’a, jest gwarancją sprawnego przeprowadzenia migracji.
Od czego zaczyna się tworzenie strategii wyjścia
Firmy przed decyzją o zakupie SaaS’a powinny zadać sobie kilka pytań o to, jak będzie wyglądało używanie takiego oprogramowania w codziennej działalności i jak głęboko zakorzeni się ono w biznesie. Muszą pozwolić odpowiedzieć na takie pytania jak:
- czy dane są wgrywane do systemu czy zaciągane na bieżąco i zapisywane do bazy danych na lokalnym serwerze,
- co się stanie się z danymi wprowadzonymi do systemu kiedy skończy się subskrypcja,
- kto ma nadzór nad konfiguracją API systemu do innych firmowych rozwiązań,
- czy dostawca wykonuje kopie zapasowe oprogramowania w modelu SaaS, jaki jest ich zakres i okres retencji,
- jakie są sposoby rozwiązania umowy na dostęp do systemu i ile będzie czasu na migrację do innego rozwiązania,
- czy mamy inne rozwiązanie zastępcze czy w razie zakończenia subskrypcji trzeba będzie rozpocząć procedurę zakupową.
Wydaje się proste, prawda? Jednak sformułowanie odpowiednich zapisów w umowach dotyczących zakupu systemów jest trudne. Z jednej strony dlatego, że trzeba je odpowiednio włączyć do już gotowej treści przygotowanej we wzorcowej umowie przez dostawcę. Z drugiej strony przed ujawnianiem szczegółowych danych o konfiguracji infrastruktury dostawca może się bronić z powodów bezpieczeństwa. Zwłaszcza, że w modelu SaaS odpowiedzialność za kod powinna być w całości po stronie dostawcy (jeżeli interesuje Cię ta tematyka zapraszam do artykułu na temat odpowiedzialności za kod).
Dlatego do umowy powinny trafić zapisy koniecznie niezbędne do zapewnienia odpowiedniego współdziałania stron przy zakończeniu współpracy. Minimum treści, maksimum efektu – taki skutek jest możliwy jeżeli zespół zakupowy ma odpowiednie doświadczenie w takich tematach.
Co jeżeli nie mamy możliwości negocjowania zapisów umowy na SaaS?
W zależności od formy prowadzenia działalności to zarząd lub właściciel firmy finalnie decydują, czy akceptują ryzyko wejścia w jakąś technologię. Jest tak zarówno w firmach, które funkcjonują w oparciu o systemy zarzadzania budowane zgodnie z normami ISO jak (gdzie odpowiedzialność zarządu za akceptację ryzyk i szans jest literalnie zapisany w dokumentacji systemowej), jak i w pozostałej części rynku, która działa tylko w ramach kodeksu spółek handlowych i zgodnie z zasadami prawa cywilnego.
Oznacza to tyle, że wybierając określony produkt w pierwszej kolejności trzeba sprawdzić, czy kwestie zakończenia współpracy są szczegółowo uregulowane w dokumentach przedstawionych przez sprzedawcę. Jeżeli nie – decyzja o nawiązaniu współpracy musi być poprzedzona ustaleniem, czy dostawca podejdzie do rozmów i wprowadzeniu zmian w swoich standardowych dokumentach. Jak wiadomo BIG TECHy nie negocjują z małymi klientami, jeżeli w ogóle z kimkolwiek.
Czy systemu, dla którego dostawca nie ustalił z nami strategii wyjścia mamy nie wdrażać? Oczywiście, że nie. Ale cała praca spoczywa na kupującym, który musi sam zaplanować swoje działania związane z zakończeniem współpracy i zanalizować związane z tym ryzyko dla swojego biznesu.
