W poszukiwaniu bezpieczeństwa

Prawidłowo skonstruowane umowy na dostawę i obsługę oprogramowania lub na usługę wdrożenia systemu informatycznego pozwalają nie tylko dochodzić roszczeń w przypadku niepowodzenia projektu, ale także porządkują i dyscyplinują przebieg przedsięwzięcia.

Prawidłowo skonstruowane umowy na dostawę i obsługę oprogramowania lub na usługę wdrożenia systemu informatycznego pozwalają nie tylko dochodzić roszczeń w przypadku niepowodzenia projektu, ale także porządkują i dyscyplinują przebieg przedsięwzięcia.

Dobra umowa to taka, z której obie umawiające się strony są tak samo niezadowolone. Oznacza to konieczność kompromisu. Jednak nie powinny to być tylko jawne lub zakamuflowane ustępstwa nabywcy. Niżej są podane, zebrane przez autora, refleksje na temat umów. Nie pretendują one do kompletności ani uniwersalności.

Zawarcie prawidłowej umowy wcale nie jest łatwe, ponieważ w Polsce nie ma wyspecjalizowanych prawników czy kancelarii prawnych, które znałyby wszelkie uwarunkowania wiążące się z zakupem i wdrożeniem oprogramowania. Należy sobie życzyć, aby ta luka na rynku została możliwie szybko wypełniona. W tej sytuacji interesy klienta są zagrożone. Dostawca programu lub usługi jest bowiem znacznie lepiej przygotowany do zawarcia umowy prawnej, broniącej jego interesów. Zwykle zresztą to właśnie dostawca przynosi ze sobą umowę do podpisania. Więksi dostawcy nie akceptują innych projektów umów niż te, zatwierdzone przez ich korporacje, powołując się na "standardy korporacyjne". Klient powinien dokładnie przejrzeć i potraktować przedstawioną umowę jako punkt wyjściowy do dalszych negocjacji na temat jej zawartości. Można także zaproponować własny projekt umowy.

Z kim mamy do czynienia?

Jeszcze przed podjęciem ostatecznej decyzji w kwestii wyboru partnera do procesu informatyzacji, już po przeanalizowaniu przedstawionej oferty, warto przyjrzeć się samej firmie. Nie zaszkodzi skorzystać z usług wywiadowni gospodarczej. Zdarzało się, że do rozmów przystępowały firmy, które w sensie prawnym w ogóle w Polsce nie istniały, natomiast zawierały kontrakty, z których nie były uprzejme się wywiązać, powodując znaczne straty u swych klientów. Sprawą podstawową jest również wiarygodność finansowa i organizacyjna firmy oraz jej personel, czyli odpowiedź na pytanie, czy posiadane zasoby pozwolą jej na wywiązanie się z zobowiązań, które chce podjąć. Rzeczą nieodzowną jest bezpośrednie i bez obecności dostawcy sprawdzenie jego referencji tam, gdzie oprogramowanie wdrożono w kraju. Tylko w przypadku zupełnie nowych na naszym rynku produktów można zgodzić się na wyłączną prezentację oprogramowania za granicą. Trzeba jednak pamiętać, że niektóre firmy informatyczne mają z jednym czy kilkoma klientami umowę na "dawanie dobrego świadectwa" w zamian za pewne korzyści finansowe.

Przed podpisaniem dokumentu klient powinien upewnić się, czy firma, której nazwa figuruje w umowie, jest tą samą firmą, z którą omawiane były warunki kontraktu i którą na tej podstawie i na podstawie przedstawionej charakterystyki wybrano do udziału w projekcie informatyzacji. Często zdarza się, że dla wywarcia odpowiedniego wrażenia o kontrakt ubiega się duża, znacząca firma, natomiast w celu zmniejszenia odpowiedzialności finansowej w razie problemów - do podpisania umowy jest podstawiana jej satelicka firma, o symbolicznym kapitale i zasobach ludzkich.

Część dostawców oprogramowania jest niejako dostawcami "z drugiej ręki", tzn. mają prawo do udzielania sublicencji na oprogramowanie w imieniu głównego dystrybutora w Polsce. W takim przypadku konieczne jest pisemne stwierdzenie, że nasz dostawca ma do tego prawo, oraz zapewnienie głównego dystrybutora, że w przypadku kłopotów lub katastrofy u naszego dostawcy jego obowiązki przejmie główny dystrybutor (oczywiście, nie za darmo).

Teksty umów muszą być czytelne i jasne dla nabywcy, a nie tylko dla jego prawnika. Wszelki bełkot pseudoprawniczy, niedopowiedzenia czy odwoływanie się do wielostronicowych załączników, z których część będzie określona w przyszłości, powinny być tępione z całą bezwzględnością.

Umowy i wszelkie związane z nimi dokumenty i korespondencja powinny być pisane w jęz. polskim. Teksty obcojęzyczne mogą mieć tylko charakter pomocniczy.

Do rozstrzygania spraw spornych powołane są sądy polskie, najlepiej polubowne, bo wyrokują szybciej.

Dobre rezultaty daje zawarcie dwóch umów: jednej na dostawę oprogramowania i jego obsługę, drugiej - na prace wdrożeniowe. Dzięki temu zabiegowi unika się niejasności w podziale odpowiedzialności za poszczególne elementy kontraktu. A jeśli umowa jest jedna, to jej wewnętrzna konstrukcja oraz dokładna specyfikacja powinna służyć do klarownego określenia, czego po kim należy się spodziewać, jakich rezultatów oczekiwać.

O czym jest mowa?

W umowie należy tak sprecyzować przedmiot umowy, aby dokładnie było wiadomo, kto za co odpowiada i jakie ponosi konsekwencje w przypadku niewywiązania się z podjętych zadań. Niedopuszczalne są określenia: "dostawca dołoży wszelkich starań", "uważamy, że uda się nam", "nasze wysiłki będą zmierzać", ponieważ one do umowy nic nie wnoszą. Powinny być określone miary dla przewidywanych rezultatów biznesowych, jednak do tego większość dostawców nie jest jeszcze przygotowana.

Dostawca oprogramowania odpowiada za następujące cechy oprogramowania:

poprawne tłumaczenie na język polski software'u, tekstów pomocy i dokumentacji

obsługę funkcji zgodną z polskimi przepisami, zwłaszcza z Ustawą o rachunkowości i przepisami podatkowymi

obsługę wymagań klienta sprecyzowanych w zapytaniu ofertowym albo po wstępnym badaniu potrzeb klienta przez dostawcę.

Należy wyraźnie stwierdzić w umowie obwarowując to drastycznymi sankcjami, że:

Oprogramowanie istnieje i funkcjonuje w wersji polskiej w momencie podpisywania umowy, a nie są to świetlane perspektywy. Aczkolwiek może to się wydawać mało prawdopodobne, to nawet w ostatnim okresie występują przypadki sprzedaży "działek na księżycu", oprogramowania, które nie występuje w wersji polskiej, lub jest dopiero w fazie testów i jeszcze źle funkcjonuje.

Oprogramowanie nie wymaga żadnych innych uzupełnień do poprawnego funkcjonowania w uzgodnionym zakresie oraz zastrzec, że wszelkie błędy będą usuwane na koszt dostawcy. Nagminne są próby obciążania klientów kosztami przeoczeń i poprawek.

Warto uprawiać umiarkowany konserwatyzm, tzn. kupować to, co już istnieje, funkcjonuje i można obejrzeć w działaniu w przedsiębiorstwach. Tak zwane najnowsze wersje, które wszystko potrafią łącznie z "drapaniem w pięty" i będą dostępne już za dwa miesiące po podpisaniu umowy, zwykle pojawiają się za rok, są w wersjach testowych - pełnych błędów, a w pięty i tak nie potrafią drapać.

Ile to kosztuje?

Cena za oprogramowanie - zależna od liczby licencji - powinna być dokładnie zdefiniowana. Klient powinien mieć jasność co do zależności między liczbą i rodzajem modułów a ceną za pakiet. Ponieważ w trakcie wdrożenia może się okazać, że niezbędne jest uzupełnienie i ewentualnie zwiększenie liczby licencji, w umowie więc powinno być zagwarantowane, że wynegocjowane ceny będą obowiązywać jeszcze przez rok po zakończeniu wdrożenia.

Odbiór oprogramowania nie może się sprowadzać do pokwitowania odbioru nośników (taśm magnetycznych, płyt CD i dokumentacji). Należy żądać, aby odbiór oprogramowania odbywał się po zainstalowaniu go przez dostawcę na własnym serwerze klienta. Warto sprawdzić, czy są wszystkie umówione moduły, podstawowe menu, wydruki i ekrany. Płatność należy uzależnić od tych pozytywnych testów oprogramowania. Za każde opóźnienie powyżej 14 dni klient ma prawo naliczać odsetki ustawowe, a powyżej 60 dni - do zerwania umowy z winy dostawcy i ubiegania się o zwrot utraconych korzyści. Dokumentacja w wersji polskiej powinna być dostarczona wg załączonej do umowy listy.

W przypadku błędów w oprogramowaniu działanie klienta jest uzależnione od powagi błędów. Jeśli błędy blokują działanie podstawowych systemów w przedsiębiorstwie np. finansów lub sprzedaży, ich usunięcie powinno nastąpić najpóźniej po trzech dniach od chwili zgłoszenia. Jeśli to niemożliwe, dostawca powinien wskazać, jak obejść te błędy, i umożliwić pracę zablokowanych systemów u klienta. Działanie metodą obejściową może przedłużyć się najwyżej do 45 dni. W innym przypadku umowa może być zerwana przez klienta z winy dostawcy. Jeśli błąd skutkuje blokadą poszczególnych funkcji systemu, prace naprawcze powinny być podjęte w ciągu dwóch dni, a skończyć się po tygodniu. Inaczej klient nalicza odsetki od wartości błędnego modułu. Jeśli błędy dotyczą wydruków, ekranów, czyli są mniej poważne, nie utrudniają w sposób istotny funkcjonowania firmy, powinny być usunięte nie później niż po 30 dniach.

Jeśli w oprogramowaniu niezbędne są modyfikacje, np. zmiana zakresu rabatowania albo utworzenie interfejsów do systemu płacowo-kadrowego, wówczas ich koszt powinien być określony jako iloczyn nakładu (liczba godzin) pracy i stawki godzinowej specjalisty. Modyfikacje dzielą się na drobne (wydruki, ekrany), średnie (wymagające zmian w algorytmie, bez modyfikacji struktur baz danych) i duże, czyli ze zmianami w algorytmach i bazach danych. Drobne i średnie modyfikacje klient sam może realizować lub zlecić je podwykonawcy. Duże modyfikacje zwykle przeprowadza dostawca. Wszystkie modyfikacje powinny być autoryzowane przez dostawcę. Oznacza to, że będą one utrzymywane - bez dodatkowych płatności - w kolejnych wersjach oprogramowania dla tego klienta.

Prawa autorskie do oprogramowania i dokumentacji opracowanych na rzecz i za pieniądze klienta przysługują klientowi. Ten zapis w umowie chroni klienta m.in. przed sprzedażą jego pomysłów konkurencji.

Odpłatność za oprogramowanie powinna być uiszczana w takim zakresie, w jakim jest wykorzystywane. Do szkolenia potrzeba kilkanaście licencji, dalsze powinny być udostępnione później, w miarę zaawansowania wdrożenia. Zwykle dostawca chciałby uzyskać zapłatę za licencję w maksymalnej kwocie przewidzianej z góry. Należy jednak domagać się, aby:

w ramach podpisanej umowy ogólnej na dostawę licencji dostawca udzielił kredytu kupieckiego na dostawę kolejnych transzy licencji

przy ustalonej cenie dostawy płatności za licencje były realizowane partiami zależnie od potrzeb procesu wdrożenia.

Bardzo opłacalny jest leasing oprogramowania, a także możliwość jego eksploatacji w outsourcingu w ośrodku obliczeniowym zewnętrznym. Jest to szczególnie ważne dla przedsiębiorstw małych i średnich bez własnej kadry informatycznej. Takie możliwości już są, ale jeszcze stanowczo za rzadko są praktykowane.

Co potem?

Oprogramowanie powinno być objęte 12-miesięczną gwarancją. Po upływie tego okresu dostawca powinien zaoferować serwis. W czasie trwania gwarancji poziom obsługi powinien być tak samo wysoki, jak i po jej upływie (włącznie z nowymi wersjami). Niestety, dostawcy oprogramowania nagminnie uchylają się od gwarancji i wymuszają na klientach odpłatność za serwis już od momentu nabycia pakietu. Jest to omijanie polskiego prawa. Serwis powinien obejmować usuwanie błędów i usterek zgodnie z ustalonymi terminami, usługę typu help-desk, instalację u klienta łat i uzupełnień, instalację nowych wersji na wyraźne życzenie klienta. Koszt serwisu powinien zależeć od kosztu licencji. Powinno być wyraźnie stwierdzone, czy koszt licencji liczony jest od cen katalogowych czy też od cen wynegocjowanych na licencje w określonym czasie.

Klient nie jest zobowiązany do instalacji wszystkich nowych wersji. Aktualna wersja polska powinna być obsługiwana przez trzy co najmniej lata od jej zainstalowania u klienta. Przerwa w opłatach za serwis, np. roczna, nie powinna powodować żadnych uciążliwości dla klienta, jeśli zechce do niego powrócić.

Nabywca może wypowiedzieć umowę na zakup oprogramowania w terminie 60 dni bez podania przyczyn. W przypadku postawienia dostawcy w stan likwidacji nabywca może rozwiązać umowę przed upływem 30 dni. Umowa wygasa automatycznie z winy dostawcy, jeśli wystąpi błąd blokujący działanie podstawowych systemów klienta i w ciągu 60 dni nie zostanie usunięty. Ze strony dostawcy możliwe jest zerwanie umowy z winy nabywcy, jeśli nabywca w terminie nie pokrywa zobowiązań finansowych albo w inny istotny sposób narusza prawa dostawcy. Uprawnienia dostawcy i nabywcy nie są symetryczne, ale w przypadku zerwania umowy dostawca ponosi jedynie stratę finansową, natomiast nabywcy może nawet grozić zapaść gospodarcza, np. wtedy, gdy nie będzie mógł przyjmować zamówień.

Nabywca powinien mieć prawo ubiegania się o odszkodowania za utracone korzyści, jeśli dostawca dopuścił się rażących zaniedbań.

Umowa dotycząca usług wdrożeniowych

W trakcie zawierania umowy na wykonanie usługi wdrożeniowej obowiązują te same zasady sprawdzania tożsamości, wiarygodności finansowej, organizacyjnej i personalnej dostawcy usługi.

W przypadku gdy dostawca oprogramowania - dystrybutor poleca firmę wdrożeniową, powinien także w konkretnej formie gwarantować jakość jej pracy.

Wymagane jest precyzyjne określenie, jakie procesy u nabywcy zostaną obsłużone przez jakie moduły.

Zakres wdrożenia powinien obejmować zaspokojenie potrzeb wyrażonych w zapytaniu ofertowym lub po wstępnej analizie. Oferowany zakres prac nie powinien wymagać dodatkowych, płatnych uzupełnień po to, aby wdrożony system funkcjonował w uzgodnionym zakresie. Błędy powinny być usuwane na koszt dostawcy usług.

Umowa powinna zawierać wyjaśnienie, jaka zostanie zastosowana metoda wdrożenia, bo od tego tworzy się harmonogramy i budżety, a następnie - opis krok po kroku przebiegu wdrożenia. Warto postarać się o zapis dotyczący zastosowania modelowania procesów gospodarczych. W umowie powinien być zapisany harmonogram wdrożenia i jego całościowy budżet.

Harmonogramy powinny zawierać:

wykaz prac wraz ze wskazaniem priorytetów

skorelowany z nimi plan szkoleń i warsztatów

określenie, co będzie przedmiotem odbioru po każdym etapie, fazie wdrożenia

budżety prac.

Wszelkie opóźnienia powinny być obwarowane karami umownymi w istotnej wysokości, np. odsetki ustawowe. W przypadku niepowodzeń wykonawca powtarza dany etap na swój koszt w ustalonym terminie oraz płaci odsetki. Terminarz płatności należy zharmonizować z postępem prac. Nie płacić zaliczek ani "z góry".

Jak płacić wdrożeniowcom?

Jeśli firma wdrażająca cieszy się dobrą reputacją, to płatność powinna być rozliczeniem nakładu pracy i wydatków całego projektu. W innych przypadkach w umowie trzeba zdefiniować koszty każdego etapu i całości wdrożenia. Szczegółowy rozkład płatności i terminy mogą zmienić się w ramach ujętej w budżecie kwoty, po przeprowadzeniu analizy szczegółowej potrzeb przedsiębiorstwa. Stosuje się także zlecanie prac etapami: po zakończeniu jednego etapu firma otrzymuje zlecenie na następny itd. Możliwa jest także umowa na tzw. stałą cenę, ustaloną już w kontrakcie. Jest to jednak rozwiązanie ryzykowne dla wszystkich uczestników przedsięwzięcia. Prace i płatności można także podzielić w inny sposób. Przykładowo, jeśli etapy nie są dłuższe niż miesiąc, to zapłacić 90% jego ceny po przyjęciu etapu, a 10% zatrzymać jako gwarancję na dalsze prace do końca wdrożenia. Jeśli etapy są dłuższe niż miesiąc, to np. 85% można zapłacić wcześniej w ratach miesięcznych proporcjonalnie do upływu czasu realizacji etapu, 5% po przyjęciu etapu, a pozostałe 10% zachować jako kwotę gwarancyjną do końca wdrożenia.

Projekt trwający ponad 6 miesięcy powinien zawierać klauzulę zmienności cen.

Rozwiązanie umowy następuje po rozliczeniu się stron umowy.

Od razu trzeba powiedzieć, że przedstawiona wyżej propozycja umowy między dostawcą oprogramowania lub usług wdrożeniowych a jego klientem jest rozwiązaniem, do którego należy dążyć, ale którego najprawdopodobniej nie uda się osiągnąć. Na polskim rynku dostawcy informatyczni ciągle mają przewagę nad klientami, są lepiej przygotowani do zawierania takich umów, dysponują doświadczeniem własnym i swojej korporacji. Ale w żadnym wypadku klient nie powinien rezygnować z negocjacji, albowiem nie zdarzyło się, żeby naciskany dobrymi argumentami dostawca nie odstąpił ani na krok od swoich pierwotnych propozycji.

--------------------------------------------------------------------------------

Ludwik Maciejec jest konsultantem i właścicielem firmy Usługi Informatyczne i Konsultingowe w Warszawie.


TOP 200