Dobra licencja to podstawa

Zakup licencji na oprogramowanie klasy ERP to niełatwe zadanie, zwłaszcza że wiąże się z negocjacjami wielu istotnych warunków, które mogą mieć długotrwały wpływ na budżet kosztów organizacji.

2017-05-11 12:20:17

Przemyślana współpraca z dostawcą, oparta na dalekosiężnej strategii pozwala zabezpieczyć się przed niezaplanowanymi kosztami. Podstawą do tego jest jednak dogłębna znajomość zagadnień zakupu licencji. O problematyce aspektów prawnych tego procesu opowiada Marcin Maruta, senior partner w kancelarii Maruta Wachta sp. j.

Czego dowiesz się z tego artykułu?

  • Jakie formy licencji dla systemów ERP są obecnie dostępne na rynku i z czego to wynika?
  • W jakim stopniu możliwe jest negocjowanie zapisów umowy licencyjnej z dostawami systemów ERP?
  • Jakie obszary ryzyk związane są z zakupem systemów ERP?
  • Jak radzić sobie w przypadku audytów?

 

Jakie formy licencji dla systemów ERP są obecnie dostępne na rynku i z czego to wynika?

Zacznijmy od tego, że są trzy główne modele udostępniania oprogramowania – bez zawierania umowy (niespotykane w ERP, ale np. częste w przypadku firmware), na mocy umowy licencyjnej (standard w modelach on-premise) i bardzo modna ostatnio chmura – czyli umowa oświadczenie usług.

W przypadku licencji trudno mówić o formach – można rozróżniać kanały dystrybucji (licencja bezpośrednia, przez pośrednika, sublicencja), ale dla użytkownika kluczowy jest tekst umowy. Można zaryzykować tezę, że umowy mają dwie warstwy – „formalnoprawną”, traktującą o polach eksploatacji, terytorium, zasadach wypowiadania itp., oraz „merytoryczną”, opisującą kluczowe definicje jak procesor czy użytkownik, zasady określonych czynności, jak np. wirtualizacja, integracja, metryki licencyjne (PVU, core, nameduser)1. W warstwie formalnej modele umów są dość podobne u wielu dostawców. W warstwie merytorycznej modeli jest bez liku i każdy dostawca stosuje specyficzne rozwiązania.

Z punktu widzenia formy zawierania umowy możemy rozróżnić między umowami pisemnymi (podpisanymi) a zawieranymi elektronicznie, głównie poprzez „kliknięcie” akceptacji warunków. Pośrodku leżą – najczęstsze w przypadku ERP – umowy pisemne z licznymi odesłaniami do warunków w Internecie. Skuteczność takich odesłań jest dyskusyjna, w systemie np. zamówień publicznych taka praktyka jest niedopuszczalna.

W jakim stopniu możliwe jest negocjowanie zapisów umowy licencyjnej z dostawami systemów ERP?

Oczywiście zależy to od pozycji nabywcy, rodzaju oprogramowania (aplikacje prościej niż bazy danych), a nawet momentu, w którym negocjujemy (koniec roku obrotowego czy kwartału danego dostawcy). Te negocjacje są jak najbardziej możliwe i wskazane – co niezwykle istotne, mogą mieć na celu nie tyle zmianę reguł licencji, ile ich doprecyzowanie. Licencje na systemy ERP są nie tylko skomplikowane (bywa, że mają po kilkaset stron, zwłaszcza gdy uwzględniamy zawartość na stronach WWW dostawcy), ale też niejednoznaczne – i jeżeli np. możemy podczas zawierania umowy potwierdzić zgodność licencyjną naszej architektury, oczywiście należy to bezwzględnie czynić. Duża część naszej pracy to właśnie tak rozumiane negocjacje.

Czego kupujący zazwyczaj nie wiedzą o licencjach na użytkowanie systemów ERP?

W mojej opinii podstawowym grzechem jest przyjmowanie licencji „as is”. Negocjujemy dokładnie umowy wdrożeniowe czy rozwojowe, ale licencje traktujemy jako tekst niewzruszalny, m.in. ze względu na ich objętość i trudność materii. Ale to właśnie w nich tkwią długofalowe koszty i ryzyka, na czele z audytem i koniecznością wysokich dopłat (na rynku polskim mieliśmy kilkukrotnie do czynienia z roszczeniami na kwoty powyżej 100 mln zł). Jeżeli miałbym wymienić, czego kupujący nie wiedzą, to w szczególności nie rozumieją wspomnianej warstwy merytorycznej – nie wiedzą, jakie są konsekwencje integracji zwłaszcza niebezpośredniej, wirtualizacji czy nawet pojęć kluczowych jak użytkownik – stąd np. zaskoczenie, że użytkownikiem może być maszyna i potrzeba na nią odrębną, płatną licencję.

Jakie obszary ryzyk uznaje Pan za główne, jeśli rozważamy zabezpieczenie interesów organizacji kupującej systemy ERP?

Zdecydowanie warstwę merytoryczną. Warstwa formalna to abecadło – musimy o nią zadbać, szczególnie gdy chcemy uzyskać prawa do modyfikacji czy rozpowszechniania, które standardowo nie są przyznawane. Powinniśmy pomyśleć o terytorium użytkowania oprogramowania czy zasadach wypowiadania. Ale jest to praca w 90% dla prawników i zaniedbania w tym obszarze są stosunkowo rzadkie. Część merytoryczna to crème de la crème umów licencyjnych i tutaj możemy osiągnąć największą korzyść biznesową. Wystarczy czasami drobna zmiana w architekturze kodu czy w definicji klienta i możemy oszczędzić setki tysięcy złotych. Tutaj bez dużego doświadczenia w konkretnej licencji i konkretnym rozwiązaniu informatycznym wiele nie pomożemy. Zupełnie inaczej patrzy się na licencje SAP, Oracle czy Microsoft. Inne metryki, inna filozofia, inne zagrożenia. Chyba nie ma osoby, która by znała bardzo dobrze wszystkie te licencje.

Jakie najważniejsze obszary powinny zostać uwzględnione w licencji, jeśli zależy nam na rozwijaniu systemu własnymi siłami?

Dużo zależy od rozwiązania jakie chcemy wrdażać. Teoretycznie z prawnego punktu widzenia kluczowe jest tzw. prawo do modyfikacji i prawo do kodu źródłowego. Tyle że w rozwiniętych systemach jak SAP czy Oracle po pierwsze nikt nam tego nie da, po drugie – w ogóle tego nie potrzebujemy, bo i tak kodów źródłowych nie będziemy modyfikować. Jeśli chodzi o standardowe rozwiązania, w 9 na 10 przypadkach muszą nam wystarczyć narzędzia udostępnianie przez producenta. W przypadku rozwiązań dedykowanych (a są duże firmy, które stworzyły własne ERP) należy wziąć pod uwagę zarówno prawa do modyfikacji, i kody.

Trzeba pamiętać, że podczas wdrożenia i eksploatacji systemu powstają rozszerzenia, konfiguracje, moduły, skrypty czy nawet struktury baz danych. Do tego typu rozwiązań, często tworzonych przez firmy wdrożeniowe, a nie przez producentów, koniecznie należy nabyć odpowiednie uprawnienia, bo dalsza ich modyfikacja wymaga odpowiednich instrumentów prawnych.

I ostatnia rzecz – jeśli myślimy o integracji oprogramowania (a zawsze myślimy) zadbajmy, by reguły licencyjne dla  „przyłączonych” rozwiązań były jasne. Na przykład w SAP jakakolwiek integracja (nawet przez takie narzędzia jak Netweaver czy PI) niesie ryzyko dopłat. Potwierdza to ostatni wyrok w Wielkiej Brytanii, gdzie SAP wygrał z klientem spór o integrację ich ERP z Salesforce, nie zgadzając się na konieczność „olicencjonowania” użytkowników po stronie Salesforce. Wartość sporu to blisko 60 mln funtów.

Jak zapewnić sobie wsparcie dostawcy po okresie wdrożenia?

Znowu zależy, co rozumiemy przez wsparcie. Mamy umowy serwisowe producentów, które z reguły dają nam prawa do nowych wersji, dostęp do bazy wiedzy i mniej albo bardziej niejasne SLA, z reguły bez żadnych sensownych sankcji w przypadku niedotrzymania tych zobowiązań. To kosztuje średnio 19–25% opłat licencyjnych rocznie i jest w kilkuletnim TCO największą wartością czy zmartwieniem.

Jeśli chcemy dedykowanego wsparcia, z reguły zatrudniamy do tego wyspecjalizowane firmy, często te, które wykonały wdrożenie – one odpowiadają m.in. za całą część dedykowaną. Razem to olbrzymie koszty, a jakość usługi zależy m.in. od precyzyjnej umowy.

Na Zachodzie powoli przebija się tzw. niezależny support, czyli firmy, które serwisują duże rozwiązania dużych dostawców (na czele z Oracle i SAP) za zdecydowanie mniejsze kwoty, ale przy większej niepewności prawnej, no i oczywiście bez prawa do nowych wersji. Dla wielu użytkowników może to być rozsądne rozwiązanie, jeżeli godzą się z tymi ograniczeniami.

Jakie obszary związane ściśle z licencjami na użytkowanie oprogramowania są Pana zdaniem najważniejsze w trakcie negocjowania warunków zakupu?

Ponownie – obszar merytoryczny. Obszar formalny to „must be”, ale prawdziwe spory, ryzyka audytowe i koszty tkwią w metrykach, architekturze kodu i tych kilkuset stronach dokumentacji licencyjnej. Dla zobrazowania problemu: policzyłem ostatnio w umowie IBM same akronimy – to ponad 50 pozycji, za którymi kryją się nierzadko (jak np. PVU) całe mechanizmy biznesowe i prawne. Celem klienta powinno być zrozumienie kiedy, za co i ile płaci. Proszę wierzyć, to tylko brzmi prosto i banalnie – w rzeczywistości nigdy tego w 100% nie wiemy.

Jak radzić sobie z przestarzałą licencją na użytkowanie systemów ERP?

Formalnie nie ma czegoś takiego jak przestarzała licencja. Umowa licencyjna trwa tak długo, aż nie wygaśnie (jeśli jest czasowa) bądź nie zostanie wypowiedziana (na marginesie: strach przed wypowiedzeniem jest powszechny, choć w praktyce to niezwykle rzadki przypadek).

To, co się może zdarzyć, to nieaktualna wersja systemu – jak mamy umowę serwisową, z reguły posiadamy prawo do upgrade`u. Jeśli nie mamy, pojawia się kłopot – odnowienie serwisu zazwyczaj oznacza obowiązek opłat „wstecz”, czasami nawet w wysokości 150% wartości podstawowej. Nie opłaca się. To duży problem, można rozważać m.in. odkup licencji, czyli zakupienie nowej wersji – dobrze to brzmi, ale w praktyce jest bardzo trudne, bo producenci dbają o przychody z zaległego serwisu. Inne rozwiązanie stanowi zakup „używanego” oprogramowania, czyli obrót z drugiej ręki – zdobywający popularność w segmentach powszechnie używanego oprogramowania (np. Office), praktycznie niewidoczny w przypadku ERP.

Zupełnie odrębną kwestią jest tekst licencji – przy nowych zakupach czy audytach producenci będą namawiali nas do zaakceptowania najbardziej aktualnej wersji. W większości przypadków jest to (z prawnego punktu widzenia) nieopłacalne – nowe warunki są z reguły mniej korzystne, poprzez wykreślenie np. tańszych rodzajów użytkowników (limiteduser), pogorszenie warunków wirtualizacji (spory wokół Vmware) czy wprowadzenie nowych obowiązków (np. narzędzi typu ILMT). Upgrade licencji to poważna operacja prawna i licencyjna i powinniśmy do niej podchodzić tak jak do zakupu nowej licencji.

Co robić w przypadku audytów?

Przede wszystkim zaakceptować fakt, że one będą. Ich ilość rośnie, jak się czyta np. bazy Gartnera, widać, jak duży jest to problem. Nieoficjalnie mówi się, że dla części vendorów audyty to 30% przychodów z licencji.

Jeżeli jest to zdarzenie prawie pewne, powinniśmy być na nie gotowi. Zarówno proceduralnie (szczerze polecamy procedury compliance w tym zakresie, łącznie z pakietem umów dla audytora dookreślających zakres i zasady przeprowadzenia audytu), jak i merytorycznie (zebrane umowy, narzędzia SAM2).

Bazując na doświadczeniu z kilkudziesięciu takich projektów, radzę, po pierwsze, nie dopuszczać do audytu bez określenia jego zakresu, czasu, zasobów i narzędzi – np. czy do systemu będą wprowadzane skrypty. Po drugie, zweryfikować, w jakim zakresie można dopuścić audytora – np. nie można do danych stanowiących tajemnicę bankową. Po trzecie, zadbać o interesy firmy poprzez podpisanie co najmniej umów NDA3 i o powierzeniu przetwarzania danych osobowych dostosowanych do audytu (standardowe umowy zazwyczaj się nie sprawdzają). Po czwarte, zaproponować jeden kanał komunikacji i konsekwentnie go stosować. Po piąte, na bieżąco weryfikować wyniki audytu, w szczególności w ramach tzw. raportów wstępnych – audytorzy prawie zawsze używają aktualnych procedur i metodyk, które mogą nie być kompatybilne z naszymi umowami. A nawet prawie na pewno nie są, jeżeli nie obowiązuje nas najnowsza wersji licencji. Po szóste, nie wierzyć w pierwsze wyniki audytu, gdyż są one często zawyżane. Po siódme, negocjować. Tak naprawdę obu stronom zależy na rozsądnym rozwiązaniu i można osiągnąć wiele podczas takich negocjacji, zwłaszcza gdy ich elementem są nowe zakupy. Po ósme, optymalnie jest wcześniej przeprowadzić własny audyt.

Najważniejsze przesłanie z audytów (pomijam piractwo) – bardzo trudno jest jednoznacznie przesądzić, na czym polega „zgodne z licencją” czy „zgodne z prawem” używanie skomplikowanych systemów ERP. Liczba stosowanych rozwiązań technologicznych i prawnych powoduje, że to bardziej sztuka interpretacji umowy i reguł audytu połączona z koniecznością długofalowych relacji z vendorem niż prosta checklista.

Na ile narzędzia SAM są pomocne?

Od „raczej” do „bardzo”, przy czym w ich użyciu tkwi jedna pułapka. Każde z tych narzędzi przyjmuje pewną metodologię badania m.in. zgodności licencyjnej. I mamy to samo wyzwanie jak przy audycie – niekoniecznie ta metodologia jest zgodna z naszymi umowami. Co więcej, wnioski z różnych narzędzi mogą się różnić ze względu na zastosowany algorytm – kiedyś nasz klient użył dwóch czołowych rozwiązań (jedno autoryzowane przez producenta, drugie niezależne) i różnice sięgały kilkunastu procent. Czyli kilku milionów złotych.

Ale co do zasady takie narzędzia są konieczne przy pewnej skali. Po pierwsze, pomogą zewidencjonować to, co mamy i co używamy (kluczowe np. w przypadku korzystania z opcji). Po drugie, informują nas o zdarzeniach, które mogą spowodować obowiązki licencyjne (ponownie: włączenie opcji). W rozbudowanych strukturach trudno jest zarządzać licencjami bez takiego wsparcia, my podczas naszych audytów też z nich korzystamy. Krótko mówiąc – to na pewno bardzo dobre narzędzie do inwentaryzacji i wstępnych szacunków, natomiast ostrożnie z wiarą w wyniki zgodności licencyjnej. 

ZNAJDŹ NAS: