Szczególne klauzule umowy

Wprowadzenie standardowych klauzul obowiązujących strony podczas prac wdrożeniowych ma trzy zasadnicze cele. Po pierwsze gwarantuje, że przekazywane podczas oceny ofert i negocjacji ogólne informacje o elastyczności, szybkości i wszechstronności systemu, znalazły swoją konkretną egzemplifikację również po podpisaniu umowy wdrożeniowej. Po drugie, zabezpiecza warunki realizacji dodatkowych zleceń wynegocjowane w momencie, gdy klient posiadał najsilniejszą pozycję przetargową. Po trzecie, zapewnia utrzymanie ochrony dotyczącej np. zachowania gwarantowanych czasów dostępu do poszczególnych elementów systemu, które stały się przedmiotem dodatkowych zamówień CR.

Pierwszy cel związany jest ściśle z cechami systemu bazowego, określonymi w poprzednim rozdziale, jako jego elastyczność i skalowalność. Jeżeli na etapie

415

192

przedsprzedażowym, oferent przedstawił tego typu informacje nie ma powodu, aby nie znalazły się one również w umowie. Przeciwdziała to powstaniu przykrych niespodzianek, gdyby okazało się, że przyjmowany jako pewien standard stopień elastyczności systemu, nie jest jednak tak duży, jak to początkowo przedstawiano.

Aby przeciwdziałać nadmiernemu wzrostowi kosztów wskutek realizacji zleceń CR,

wskazane jest wprowadzenie do umowy zapisu o stosowaniu tej samej, wynegocjowanej w ramach pierwotnego zlecenia stawki osobodnia, dla wszystkich zleceń dodatkowych.

Ponadto w celu zapewnienia odpowiedniej dyscypliny realizacji tych zleceń, należy wprowadzić zapis o stosowaniu kar umownych w tej samej wysokości (lub w procentowej relacji do wartości CR). Standardowe formularze zamówień, zwykle nie zawierają takich zabezpieczeń, a data wykonania zlecenia określana jest jedynie orientacyjnie.

Z kolei aby utrzymać zasadę nie przerzucania odpowiedzialności za wykonywane prace z dostawcy oprogramowania na zleceniodawcę, ważne jest aby w umowie zapisać dwie kluczowe zasady świadczenia usług CR: neutralności w stosunku do gwarantowanego czasu reakcji systemu oraz neutralności w stosunku do pozostałej jego funkcjonalności.

Pierwsza zasada wyłącza możliwość tłumaczenia wolnego / spowolnionego działania

aplikacji, wykonywaniem obciążających serwery czynności dodatkowych, nie znanych w momencie podpisania umowy. Oczywiście może się zdarzyć, że założone przez Grupę

Wdrożeniową zmiany, rzeczywiście nie będą obojętne z punktu widzenia wydajności systemu. Jeśli jednak sytuacja taka ma miejsce, firma wdrożeniowa powinna w jasny sposób o tym poinformować, tak aby decyzja w sprawie wykonania tych zmian mogła zostać podjęta ze świadomością wszelkich konsekwencji.

Druga zasada nakłada na zespół projektowy dostawcy obowiązek podjęcia wysiłku koncepcyjnego, mającego na celu takie przygotowanie CR, aby po jego wykonaniu nie okazało się, że część pozostałej funkcjonalności utraciła swoje dotychczasowe właściwości.

Nie chodzi tu o całkowite jej unieruchomienie (wówczas, pełna odpowiedzialność spoczywa i tak na przyjmującym zlecenie bez stosowania specjalnych zapisów), lecz o drobne, acz

często istotne niuanse. Np. zlecenie wykonania nowego modułu do wyszukiwania klientów,

zawierającego np. więcej kryteriów czy operatorów logicznych, może wiązać się z koniecznością rezygnacji ze standardowych komponentów wyszukiwania dostarczonego

przez producenta systemu bazowego. Po realizacji zlecenia okaże się wówczas, że np. pierwotne możliwości konfiguracyjne kryteriów domyślnych umieszczane w ramach

centralnego profilu użytkownika, w nowej wyszukiwarce, napisanej od podstaw przez pracowników zespołu projektowego, już nie działają. Jeśli CR nie wskazywał wprost na to, że

193

miały one zostać zachowane, z formalnego punktu widzenia zlecenie zostało zrealizowane.

Zapewne koszt zmian uwzględniających zachowanie tych elementów byłby wyższy, jednak i tym razem, to od świadomej decyzji członków Grupy Wdrożeniowej powinno zależeć, czy

mimo to zlecenie takie powinno być wykonane czy nie. W tym wypadku wystarczyłby zapis w umowie mówiący o tym, iż „Zleceniobiorca gwarantuje, iż wszelkie wykonywane przez

niego w ramach CR prace dodatkowe, nie będą w żadnym stopniu ograniczały lub wyłączały

działania w części lub całości funkcjonalności systemu w stosunku do sytuacji wyjściowej, z pominięciem ściśle określonych w CR elementów i tylko tych elementów. Jeśli zasada ta nie

będzie mogła zostać zachowana, zleceniobiorca poinformuje o tym pisemnie zleceniodawcę przed podpisaniem CR”.

Innym elementem zobowiązań umownych, istotnych z punktu widzenia sprawnego przeprowadzenia zlecenia, jest jasne określenie obowiązków klienta w ramach realizacji umowy. Oprócz konieczności wykonywania testów akceptacyjnych416

i ponoszenia kosztów prac wdrożeniowych, klient ma zwykle obowiązek przekazania Zespołowi Projektowemu odpowiedniego know-how. Zalicza się do niego wiedzę o integrowanych z systemem CRM źródłach danych, obejmującą m.in. założenia modułów eksportu/importu danych, arkusze opisu obiektów danych, opisy i schemy struktury plików eksportu/importu (lub innych metod integracji), itd. Jeżeli własny dział IT przedsiębiorstwa miewał w przeszłości problemy ze sprostaniem narzuconym harmonogramom, lub też wykonanie dokumentacji integracji będzie zlecone firmie zewnętrznej, warto zabezpieczyć się w umowie wdrożeniowej na taką ewentualność. O ile to technicznie wykonalne, przygotowanie integracji powinno zatem zostać wyodrębnione jako osobne zadanie, którego czas realizacji określono elastycznie, jedynie datą ostatecznej gotowości. W ten sposób poślizg po stronie klienta, nie powinien mieć wpływu na opóźnienia całego projektu.

Decydując się na wdrożenie systemu informatycznego, przedsiębiorstwo wykupuje licencję na wykorzystanie systemu bazowego417. Jednak również i elementy systemu przekształcone w ramach wdrożenia, podlegają prawu autorskiemu, jako wyodrębniony utwór konfiguracji systemu. Aby wzmocnić standardowo stosowane zapisy o zachowaniu poufności informacji przekazanych sobie przez strony w trakcie realizacji umowy oraz w celu ochrony know-how firmy uzewnętrznionego w ostatecznej postaci systemu, warto wprowadzić do niej

416

Tu należy zadbać o zagwarantowanie odpowiednio długiego czasu na dokonanie czynności sprawdzających, równego co najmniej terminom realizacji odpowiedzi na zgłaszane poprawki, jakie zarezerwował sobie zleceniobiorca.

417

Z pominięciem sytuacji, gdy umowę licencyjną zastępuje tylko umowa o świadczeniu usług dostępu do systemu (w praktyce sytuacja bardzo rzadka).

194

zapisy określające przekazanie autorskich praw majątkowych. Nie oznacza to możliwości nieskrępowanego dysponowania licencjami na system (np. ich odsprzedaży), ale jeśli zostaną one przekazane w stosunku do odpowiednich tzw. pól eksploatacji, zablokuje to z kolei możliwość szybkiej proliferacji dopracowanego przez organizację systemu, wśród jej konkurentów. Aby takie zapisy były skuteczne, należy również w stosunku do dokumentacji projektowej⁴¹⁸, zabezpieczyć autorskie prawa majątkowe w następujących pola eksploatacji:

- utrwalenie i zwielokrotnienie dowolną techniką, (w tym wytworzenie egzemplarzy utworów dowolną techniką, m.in. drukarską, reprograficzną, zapisu magnetycznego lub cyfrową),

- wprowadzenie do pamięci komputera, - wystawienie,

- wyświetlenie,

- odtworzenie, nadanie (przewodowe i bezprzewodowe, w tym satelitarne) i reemitowanie oryginału lub egzemplarza utworu,

- najem oryginału lub egzemplarza utworu, - dzierżawa oryginału lub egzemplarza utworu,

- użyczenie oryginału lub egzemplarza utworu, oryginału lub egzemplarza utworu, - wprowadzanie do obrotu oryginału lub egzemplarza utworu,

- wprowadzenie i wykorzystanie w sieci Internet.

W przypadku oprogramowania, autorskie prawa majątkowe należy zabezpieczyć w następujących polach eksploatacji:

- trwałe i czasowe zwielokrotnienie programu komputerowego w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie,

- tłumaczenie, przystosowywanie, zmiany układu i jakiekolwiek inne zmiany w programie komputerowym,

- rozpowszechnianie, w tym wprowadzanie do obrotu, użyczenie oraz najem programu komputerowego lub jego kopii.

Zaproponowane w niniejszym rozdziale zapisy do umowy wdrożeniowej mogą niekiedy wydać się zbyt szczegółowe i biurokratyczne. Umowy nie zawiera się jednak na „dobre czasy”, ale po to, by zabezpieczyć swoje interesy w razie wystąpienia mniej korzystnych okoliczności. W żadnym wypadku nie oznacza to stosowania zasady podejrzliwości i nieufności wobec dostawców oprogramowania. Stanowią one jedynie ramy,

418

195

w których cieszące się równouprawnieniem strony, w oparciu o zasadę partnerstwa mogą przystąpić do udanego technicznego wdrożenia systemu CRM.